Software from a Systems (Engineering) Perspective
Are software and systems engineering ready for specialization?
No doubt about it. Software which used to be the b*** stepchild of systems, only given attention rudely, and when there was no other alternative, has now moved to a position of prominence in the system equation.
Why? Forces moving in two directions: (1) the capability of software to perform more and more complex tasks; (2) the heavy expense required to build ASICs to carry out tasks that software can perform. Add to this the complexity being demanded by customers, and software is now appearing as the only way to go.
Can MDA help? Yes it can. SE is moving away from imperative code to declarative code (viz. Flex and MXML) and looking to graphical modeling notations such as UML and SysML for help in working with components at a higher level of abstraction.
What's different when software is a system component?
The code is no longer the focus of attention. In the Royce iterative Waterfall Model, one needed code to keep things going. Now the big three (from SysML) are:
No doubt about it. Software which used to be the b*** stepchild of systems, only given attention rudely, and when there was no other alternative, has now moved to a position of prominence in the system equation.
Why? Forces moving in two directions: (1) the capability of software to perform more and more complex tasks; (2) the heavy expense required to build ASICs to carry out tasks that software can perform. Add to this the complexity being demanded by customers, and software is now appearing as the only way to go.
Can MDA help? Yes it can. SE is moving away from imperative code to declarative code (viz. Flex and MXML) and looking to graphical modeling notations such as UML and SysML for help in working with components at a higher level of abstraction.
What's different when software is a system component?
The code is no longer the focus of attention. In the Royce iterative Waterfall Model, one needed code to keep things going. Now the big three (from SysML) are:
- Requirements
- Tests that validate the requirements
- An implementation block (of either hardware or software)
posted by frankc at 5:18 AM
1 Comments:
Illuminating blog post. I submit to superior knowledge, but I'd like to humbly point out one detail:
As an engineer with 7 years of experience in developing software and following several methodologies; and as a programmer of 12 years since when I started writing open source code in high school, the only mantra that has been jack hammered into my skull is that of Torvalds (accidentally, I may add).
In the end, process becomes just a number we meet. The only thing that matters is the result (the forgiving front end, the triggers firing off a db and every bug report I have to handle)
The minute the architects get done with the diagrams and UML-ing, and the project management hands out implementation tasks the _only_ design approach we programmers follow is the most intuitive one: BDUF (big design up front)
This is not too contrary to your view of separating code as a distinct process step, however, the only thing that runs in the minds of the programming team is code. So every BDUF step will still be thought out in terms of algorithms, if statements, classes and data structures.
This will determine and possibly contradict the final outcome as thought of by the architects and the system designer. Prethought architecture is heavily compromised for whatever works.
Which is why I keep thinking the only way to substantial progress in software process is to involve the code, right from the Waterfall Step 1.
Too bad we only think linearly in terms of laying out a software process, when programming is anything but.
If it looked like I unwittingly made a plug for agile development, I'd like to apologize. Its overformalized when the whole spirit of Agile was to allow for nebulousness.
Post a Comment
<< Home