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, Ian F. Alexander and Neil Maiden write about the two levels of software engineering process.

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.

Other possible names for this level might be ‘macro’ systems engineering, as opposed to ‘micro’ systems engineering.  Actually this is quite a good name.  Unfortunately (and with no disrespect intended), Booch (1994) used the term in the context of Object Oriented development with a somewhat different meaning.

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.

Key Take Aways

Here’s my key take aways:

• There’s two levels of systems engineering.
• You can think of it as Macro vs. Micro systems engineering .
• ‘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’ 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.

My Related Posts

• Software Engineering ‘in the large’
• Software Engineering ‘in the small’
• A Process for Generating a Software Process
• Four Reasons Why Defining an Effective Software Process is Tough
• Waterfall, In the Large, and In the Small