Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

russell (1413)

russell
  (email not shown publicly)
http://russell.matbouli.org/

Journal of russell (1413)

Wednesday January 16, 2002
09:14 PM

Public transport rant, Software Engineering and Databases

[ #2209 ]
I had my first exam of the year on Monday at 2pm. I left my house sometime around 12.15pm, thinking I had plenty of time before my exam. I got to Botanic Station at about 12.30pm or so (I was reading over stuff on the way there). The next train wouldn't be until 13.18, which was okay, I would likely get to the exam hall with 10 or 15 minutes to spare (the train takes ~ 20 minutes and there's a walk from the station to the uni). But no! With Translink, the train didn't get me there until after 2.15pm or so :( Thankfully, I didn't really need the extra time, as I didn't know enough to take a full 2h for this half-module's exam :)
</rant>

Moral of the story - don't rely on public transport being at all timely.

When studying for the exam, I did start to understand the subject (Software Systems Engineering was the title). I read most of "Software Design" by David Budgen in preparation, which turned out to be quite a good introduction to the subject.
(Okay, I shouldn't need an introduction as I'd already studied a few modules of systems analysis type topics, but I was never interested in the topic before, so it kinda wooshed over my head.)

If you don't know anything about software engineering, here's how I see it in brief overview format:
  • You want the software to be "good quality" and other abstract notions. You need to think about what this would entail and itemise / realise it. (This applies more to software that you're writing for yourself, I suppose.)
  • The software has to be useful. You need to find out what the users want the software to do. In some cases, you need to find out who the users are and think about it from their viewpoints (in the case of different classes of users).
  • The software has to be usable. This is HCI I guess. Not part of this course. I get the feeling that some people have forgotten that computers are here to help people, and that software should just be something that is easy to use and do its task efficiently.
  • The system has to meet the requirements you drew up at the start. Seems obvious. I reckon you get so bogged down in the details that you lose sight of the original goal though.
  • You have to test it to make sure it works. Don't make assumptions.

Methodology is about looking at the software engineering process and trying to create a framework that would help the novice designer. The various methods that have been drawn up are just meant to help you look at it logically.

The problem seems to be that in an academic context, this loses all meaning. It isn't really explained in the way that "you're bound to run into the same problems as software engineers before you, here's how they looked at the problems and came to solutions", but more in a "here is a method, learn it, regurgitate it for the exam, produce meaningless diagrams for coursework, *stamp* there, you've passed the module".

Anyway, enough about that. The next exam is "advanced database systems". I quite like studying databases. At least you know where you stand :)

I have a friend, let's call him Eoin [0], who says that he wants to get rid of all databases as his contribution to the planet. This seems rather... stupid to me. Most applications in the domain I'm thinking about need a database. He says "use a flat file instead". But, uh, isn't a flat file just another database, albeit an ad-hoc proprietry one? If we're going to use a database, why not try to do it right? I think that's what this module is about, or some of it at least.

[0] He also tends to program in assembly language, and hates Perl. We don't exactly see eye to eye on certain issues :)

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.