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 :)
