A magazine where the digital world meets the real world.
On the web
- Home
- Browse by date
- Browse by topic
- Enter the maze
- Follow our blog
- Follow us on Twitter
- Resources for teachers
- Subscribe
In print
What is cs4fn?
- About us
- Contact us
- Partners
- Privacy and cookies
- Copyright and contributions
- Links to other fun sites
- Complete our questionnaire, give us feedback
Search:
The FUNdamentals of Software Engineering
Science is way of increasing our understanding of the world. Engineering is about building practical things that make a difference. "Computer Science" is a bit weird because, despite its name, it isn't just a science subject - it is more a melting pot where science and engineering (and business management, maths, the social sciences and the arts) meet. That may be why there are so many different names for very similar university degrees. They all have similar cores but differ in the focus of the extras.
Computer Science isn't just about understanding computers, coming up with theories about them that can be tested by experiment. It is also about building new systems in the first place. Today's computer systems are vastly complex things. They aren't just thrown together by programmers but need engineering and management skill. That is why software engineering is an important part of any computer science related course.
So what is it about? A bunch of things to do with how best to manage the way software is developed, whatever that software does. Ideally the software should be delivered on time, to budget and without bugs. Things shouldn't go wrong because you know what you are doing and not just by luck.
Learning from Failure
Unlike other branches of Engineering, Software Engineering is still in its infancy - people have been designing and building buildings and bridges for millennia, trains and the like for centuries, but they have only been writing large programs for fifty years or so. That means the best way of doing it is still evolving: we are still learning. As a result there are still lots of high profile failures to learn from. Here are some of the most famous failures with software engineering morals.
Knowing When to Stop
Software Engineering is a big area, combining lots of different topics: how best to develop designs, how to find out what the customer wants you to design in the first place, how best to work in a team or manage teams, and so on. One critical area is about ways to test your programs to find the problems that are bound to be lurking there before you release it and they bite your customers.
Because of their complexity there are always likely to be some problems with software. The best you can do is to keep testing for long enough that the bugs that remain are trivial ones that won't matter. A big question though is how long is long enough? If you haven't found bugs how do you know they don't matter? That is where another aspect of software engineering comes in to do with predicting risk. So what do the results of football matches have to do with it...?
