While working on patterns & practices Security guidance, I pushed the idea of “Visual Threats and Countermeasures.” I wanted a simple way to show customers how to quickly whiteboard their application and find issues. It was very effective for finding hot spots and drilling in. I added some examples of our visual threats and countermeasures on Guidance Share.
In Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle
A variant of the Incremental model appears to be the ‘Extreme Programing (XP)’ approach put forward in Beck (2000) in which integrity of the system architecture across all increments is maintained by periodic design ‘refactoring.’
While I’m not a fan of Big Design Up Front, I am a fan leveraging the following techniques up front to help reduce risk:
I think these lightweight techniques help avoid dead-ends and help you figure out what you know, don’t know, and need to know next.
How do you know when you’re signing up for Mission Impossible? If your project has a short time frame to design, build, and deliver, and there’s high risk around the requirements and technology, there’s a good chance your project scenario is Mission Impossible. In Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle
Alexander and Maiden show a table that summarizes the project situation:
| Questions | Answers |
|---|---|
| Is there a business need to get the product to market in the shortest time possible? | Yes |
| Is there a very rapid rate of technological evolution relative to design and delivery lead-times (implying very short product lifetimes)? | Yes |
| Do you really know at the outset what exactly the problem is, what the requirements are, what solutions might be relevant, or whether the stakeholders really know what they want? | No |
| Is likely candidate technology proven? | No |
| Do you have doubts about the validity of the requirements discovery process? | Yes |
You can combine the Evolutionary, Incremental and High-Risk software process models. Evolutionary, Incremental, and High-Risk are software process models for systems engineering ‘in the large’. In the Evolutionary model, the complete cycle of activities is repeated for each version. In the Incremental model, increments are individually designed, tested, and delivered at successive points in time. In the High-Risk model, the ‘in the large’ sequence involves successive phases in which project risks (user need, requirements, technology and fitness for purpose) are reduced in a controlled, step-wise fashion. In Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle
How do you choose between an Evolutionary, Incremental, or High-Risk software process model? Evolutionary, Incremental, and High-Risk are software process models for systems engineering ‘in the large’. In the Evolutionary model, the complete cycle of activities is repeated for each version. In the Incremental model, increments are individually designed, tested, and delivered at successive points in time. In the High-Risk model, the ‘in the large’ sequence involves successive phases in which project risks (user need, requirements, technology and fitness for purpose) are reduced in a controlled, step-wise fashion. In Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle
Evolutionary, Incremental, and High-Risk are software process models for systems engineering ‘in the large’. In the Evolutionary model, the complete cycle of activities is repeated for each version. In the Incremental model, increments are individually designed, tested, and delivered at successive points in time. In the high-risk model, the project is divided into phases and each phase helps constrain risk. In Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle
According toe Alexander and Maiden, the Evolutionary model for software engineering is structured as follows:
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
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.
In software engineering, you can think of two levels: micro-level and macro-level. On the micro-level, this is systems engineering ‘in the small.’ On the macro-level, there’s systems engineering ‘in the large.’ The two levels are complimentary. In Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle
Alexander and Maiden identify systems engineering ‘in the large’ stages:
In software engineering, you can think of two levels: micro-level and macro-level. On the micro-level, this is systems engineering ‘in the small.’ On the macro-level, there’s systems engineering ‘in the large.’ The two levels are complimentary. In Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle
Alexander and Maiden identify the following systems engineering ‘in the small’ activities:
There is no one-size-fits-all process model. The answer is to use a meta-process, or a process for generating a software process. You need to accommodate both the macro (in the large) and micro (in the small) systems engineering. In Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle
Alexander and Maiden write that you need to explicitly accommodate systems engineering ‘in the large’ and ‘in the small’:
Next,
