There’s two Levels of software engineering process: macro (‘in the large’) and micro (‘in the small’). In Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle
Key Take Aways
Here’s my key take aways:
- Two levels of systems engineering – You can think of it as Macro vs. Micro systems engineering .
- In the Large – ‘in the large’ is associated with the following: phase’, ‘concept exploration’, ‘proof of concept’, ‘feasibility study’, ‘project definition’, ‘full development’, in-service maintenance’, ‘in-service upgrade’, ‘disposal’ and so on.
- In the Small – ‘in the small’ is concerned with the sequences of activities: user requirements, system requirements, architecture, system design, subsystem identification and specification, preliminary design, detailed design, implementation, test and integration, acceptance tests, certification, training, commissioning, and handover.
The First Level – In the Large
Alexander and Maiden write that the first level of systems engineering is ‘in the large’ (macro):
The first level is about systems engineering ‘in the large’. It is a level that we find words like ‘phase’, ‘concept exploration’, ‘proof of concept’, ‘feasibility study’, ‘project definition’, ‘full development’, in-service maintenance’, ‘in-service upgrade’, ‘disposal’ and so on. It can also be thought of as the macro picture of an entire project from cradle to grave, comprising a number of subprojects that make up the whole life cycle. It is at this level that risk can be managed most effectively. Budgets can be assessed on the best information available at the time and allocated in digestible portions. Sensible high-level review points can be inserted at which management takes stock of whether the overall project is proceeding as required and whether money is being well spent..
The Second Level – in the Small
Alexander and Maiden write that the second level of systems engineering is ‘in the small’ (micro):
We call this systems engineering ‘in the small.’ It concerns sequences of activities such as: user requirements, system requirements, architecture, system design, subsystem identification and specification, preliminary design, detailed design, implementation, test and integration, acceptance tests, certification, training, commissioning, and handover.
Why This Separation Between ‘in the large’ and ‘in the small’
According to Alexander and Maiden, ‘in the large’ and ‘in the small’ are complimentary:
Why have we made this separation between ‘in the large’ and ‘in the small’? Simply because ‘in the small’ is necessary but not sufficient for general systems development and project management. ‘In the large’ is needed to handle the sufficiency issue – that is, the bits that the ‘in the small’ process does not address.
My Related Posts
