i have exams coming up (this Wed actually) and its the lovely topic of Systems Design. Or Requirements engineering, or Systems engineering or whatever term you know it as.

I'm highly expecting questions asking me to critically analyse a model, be it RUP, OPEN, VORD or whatever and justify what I say.

Problem is, I don't understand the idea behind Systems Design well enough to do that. I look at all the models and yes they use different terms and yes their diagrams are different... But ultimately, what's the practical difference? They all do the same thing...

Gather requirements
Design architecture
Implement system
Test it
Distribute it to user

Can anyone shed any light on this?

For example SSADM techniques are literally DATAflow oriented whereas RUP looks at events, but SSADM does handle events and RUP can handle data (not sure about the latter actually, maybe there is a difference!).

But to be perfectly honest with you, I wouldn't want to be in your position because when it comes to being stuck at an exam kind of like the one you've mentioned, you never really THINK your way out of it, the (very static) anwsers exist and they're in one place, your course notes unforunately, this is one of those cramming situations I'm afraid. You have to find their opinion of the differences because out of shear practicalities, I haven't found a simple concise answer to your query and I've used a good amount of methodologies in work and at home.

Good luck, it's probably not impossible anyway.

P.S. I am a programmer though, perhaps someone closer to the design stage does know the difference. http://www.wikipedia.org, if the explanations there don't help their should at least be links to places/communities that do know the differences. Sorry I couldn't offer any more help, programmers like me usually only USE these methodologies and occasionaly (make that often) tell the people making them to make them more clearer in Version 2.4.5.3.4 and so on.

Waterfall doesn't provide measures for prototyping.
My response: So? Just add it in after architecture and do it anyway!

Legalistically ticking to exactly what a model says sounds like a very stupid idea to me. I understand the need for documentation and diagrams to be consistant. But to say that one set of diagrams is better than another is silly...

If it was a static exam, I'd be very happy... but it's not :| Past papers show it to be very justifyish opiniony oriented..

Waterfall Model! That takes me back, very logical stuff, in fact what I use nowadays is kind of similar but even MORE focused on the iteration.

Here's the questions (2 out of 3, I picked the 2 I knew most of... which doesnt say much)

1. From a planning point of view, a systems engineering model can be used to define the different types of activities that are necessary to complete a project.

a) Outline why a simple linear process model has shortcomings and explain how such a model can be re-organised to produce a layered model. Identify each of its sub-processes, explaining their use and identify the documents which are produced. Hence, or otherwise, discuss how the model needs to change for the development of large or complex systems.

b) Evaluate the use of 'stage gates' in systems engineering to control risk.

2. A software company has employed you as a systems engineering consultant. To date the company has not had a formal approach to requirements engineering.

a) What arguments would you give the company to justify the introduction of a formal approach to requirements engineering? VORD and CORE are two possible methods that you could recommend the company to use. Explain and justify which method you would recommend for the company?

b) Provide the company with an assessment of the DOORS requirements management tool.

--------------------

As I said... head in car door... *slammity slammity slam*

I know very little of UML, so I skipped that one if favour of those I could bluff more in.

In brighter news, I learnt that my guess answer for Stage Gates was right, checked them up in my notes... It was ONE slide. Out of a good 100 page book of slides. Stage Gates was on one of them... ugh.

Needless to say the rest of them weren't in my notes at all, but it was a test of our System Designer minds to pull the information out of a freaking hat.

Future exams:

I have Intelligent Systems - Clustering, K-nearest neighbour, Bayes, Naive Bayes, Decision Trees etc.

It's gonna be a lot of formula work, which I'm fine with cause its all just following the pattern.... I just wish we had a lecturer that actually TAUGHT rather than come in half-drunk on Fri morning and end up making calculation mistakes the rest of the day

Best exam would be next Wed, it's Interactive Computing. XML, XSLT, JavaScript, DTDs, XHTML, XPATH.

Lots of lovely coding and problem solving. Already been told by the lecturer it's going to be questions like "This DTD is faulty, please identify the flaws and fix them" or "Use XSLT to transform this XML"

I'm much better at that

Where did everybody elses input go?

There's nothing like a talk about design methodologies to deter forum members/clear a room, now I know what not to do in a social situation.

I wish I had a drunk teacher, there was one guy who drank a lot but unfortunately he could hold his drink so nothing funny happened.

Well good luck with the rest of it, it can't be harder than the design methodologies anyway, what are you looking to do when you leave?

You use the design metholodogy discussion when you WANT to clear a room... I gotta remember that... lol

Teacher wasn't so much drunk as he was HUNGOVER. Basic math evaded him.

When I leave. somewhere somehow Games Design calls my name.

------------------
MM out-
Thought travels much faster than sound, it is better to think something twice, and say it once, than to think something once, and have to say it twice.
"Frogs and Fauns! The tournament!" - Professor Winneynoodle/HanClinto

But in terms of what we were talking about, Systems Design is for like designing a piece of software, the software is the system, but because it could comprise several pieces of software and such, it's just called a system. So we do things like draw graphs, write out events and data types and with that information we can actually make (code) the software (or even a game!) There are several ways to visualise this, so we have different Systems Design techniques, but I guess people probably apply these kinds of techniques to anything that could be called a system, I suppose these methodologies might work (with a little modifcation) on say teams of people or animals. Even the universe has been defined as a system. We were just talking about software though.

Answer you question?

------------------
MM out-
Thought travels much faster than sound, it is better to think something twice, and say it once, than to think something once, and have to say it twice.
"Frogs and Fauns! The tournament!" - Professor Winneynoodle/HanClinto

quote:

---

Originally posted by Mene-Mene:
First sentence confusing. Rest answers me. Seems like its over-evaluating, but I'm sure it must be helpful at commercial level.

---

The only reason I don't call it a complete and utterly waste of time is that it's good to be organised. It's good to be consistent with diagrams and terminology.

But... they really push it too far...

------------------
MM out-
Thought travels much faster than sound, it is better to think something twice, and say it once, than to think something once, and have to say it twice.
"Frogs and Fauns! The tournament!" - Professor Winneynoodle/HanClinto

Intelligent Systems - 60
Interactive Computing - 49 (dunno how I did badly here)
Software Systems Engineering - 65

Pass rate is 40.

So yes, I did in fact pass Systems Design very very safely...

Three cheers for random guesswork, logic and dumb luck!

------------------
MM out-
Thought travels much faster than sound, it is better to think something twice, and say it once, than to think something once, and have to say it twice.
"Frogs and Fauns! The tournament!" - Professor Winneynoodle/HanClinto
I reserve the full right to change my views/theories at any time.