Modularisation

Right, I have an exam coming up and I'm allowed to take in whatever material into the exam I want and however much of it as I want so I'm scouting around to gain more information and make some notes.

Since the theme is modularisation it means that any question about it can be asked so I'm just going through some basic things at the moment.

Estimatation - how would estimation improve (or get worse) if modularisation was implemented?
Design - same applies

I'm just doing two for now to work though it.

Yes, I'm fully aware that non-modularised programming is pre-60's era - it's just for learning purposes ;)

If anyone has any idea of any decent ones I'd be appreciative, I can't put it into words and can't think of scenarios etc.

Cheers! :)

1 What type of exam is this?
2 What qualification does it build towards?

All my exams, you can't.

I recommend using wikipedia printouts of the summary points.

1) It's an exam for a software engineering unit, open book.
2) It builds towards a degree in Computer Science.

In my exam (singular) you can.

I didn't find anything decent on the wikipedia.

Quote:

---

Originally Posted by Kezzer

Estimatation - how would estimation improve (or get worse) if modularisation was implemented?
Design - same applies

---

Estimation of what?

Design wise modular software is a complete turn around in development methodology compaired to a monolithic development tree. In fact a lot software still uses monolithic development methodology for the reason is a) lack of training in modular development b) some complexity and c) because it takes more time, and therefore money to develop.

however what modular software brings is a) shorter build times and b) overall a more maintainable program/system.

You need to be more specific with your questions.

It's too late now, I've taken the exam. It was open book and you didn't have to hand in the material you used after the exam. However, I don't think I did very well as the questions were ones such as "How does modularisation help with prototyping?" and "How does modularisation give the ability to change design which reflects a specification?"

I can't say I was prepared for those kinds of questions.

wow, i would be caught off-guard with those questions too..
I mean really, I've never heard of a prototype/proof of concept written in a modular fashion, it takes too much time to agree and setup the framework.

I'm not sure what they're looking for with the latter question either, I mean once you commit yourself to a modular framework it takes a lot of work to change it. Although if you use a 'plugin' architecture its pretty easy to expand the specifications of a system.

My friend is doing a degree in games development, and a lot of work he gets is kind of irrelivent and out of touch with realworld development. His 1st year for e.g. was a lot of Java, where the onous should have been on C/C++ from the start.

Well, one of my answers to prototyping was that typically the phrase goes (as written by Fred Brookes) "Build one to throw away - you will anyhow!" and I mentioned that this phrase should be changed to "Build one to dismantle!" because if you modularise the prototype then it directly related to reusability which means the components you build in the prototype can be reusable thus saving time and money.

The latter question was difficult but high cohesion would've been acceptable. Pointing out that a certain bit of the program does "THIS" allows change. Also, ability to change design is ok with modular design because modules are independant from one another therefore meaning that it doesn't rely on other parts of the design (decoupling).

I couldn't say much more on it. I'm knowledgeable in the programming area but not the software engineering area which is what is required (and what the exam was trying to teach). I can safely say I didn't do very well as there were 5 points to be raised in every question whereas I rose 2 to 4 points in each question only and only half of those were any good. Shame though, I think I studied hard but was unprepared.