What’s the difference between an architectural style, an architectural pattern, and a system metaphor?   An architectural style is a central, organizing concept for a system.  An architectural pattern describes a coarse-grained solution at the level of subsystems or modules and their relationships.  A system metaphor is more conceptual and it relates more to a real-world concept over a software engineering concept.  In A Practical Guide to Enterprise Architecture (The Coad Series), James McGovern, Scott W. Ambler, Michael E. Stevens, James Linn, Vikas Sharan, and Elias K. Jo write about the difference between architectural styles, architectural patterns and system metaphors.

Continue Reading >>

What’s the difference between an architectural pattern and a system metaphor?  An architectural pattern describes a coarse-grained solution at the level of subsystems or modules and their relationships.  A system metaphor is more conceptual and it relates more to a real-world concept over a software engineering concept.  In A Practical Guide to Enterprise Architecture (The Coad Series), James McGovern, Scott W. Ambler, Michael E. Stevens, James Linn, Vikas Sharan, and Elias K. Jo write about the difference between architectural patterns vs. system metaphors.

Continue Reading >>

Adding people to late projects makes them later.  This can be counter-intuitive.  In Requirements-Led Project Management: Discovering David’s Slingshot, by Suzanne Robertson and James Robertson explain how adding people to late projects makes them later.

The Least Knowledgeable People Prevent the Most Knowledgeable People from Working
According to Suzanne and James, adding people to a late project, makes the project later:

The problem of adding people means disrupting the rhythm that your existing team has established.  It increases the number of communication paths. New people penalize the existing team.  When new members arrive, they almost certainly have to ask questions.  And the most obvious people to ask are the most skilled – and therefore the most valuable to you –people on the team.  So you end up with the least knowledgeable people preventing the most knowledgeable people from working.

Key Take Aways
I’ve lead many projects over the years, and I have found that adding people to late projects does make them later. Here’s my key take aways:

• Adding people can disrupt the rhythm.
• Adding people increases the number of communication paths.
• Adding people can slow down the existing team.
• The least knowledgeable people prevent the most knowledgeable people from working.

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, Ian F. Alexander and Neil Maiden mention periodic design refactoring:

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:

• System stories up front (where system stories include the ‘ilities and quality attributes, such as performance, security, reliability, … etc.)
• Architectural spikes (time-boxed exploration to do some focused, end-to-end tests around high-risk areas)
• Candidate architectures
• Tests for success

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, Ian F. Alexander and Neil Maiden write about Mission Impossible scenarios.  

Example Scenario

Alexander and Maiden show a table that summarizes the project situation:

Continue Reading >>

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, Ian F. Alexander and Neil Maden explain how to effectively combine the Evolutionary, Incremental, and High-Risk process models.

Continue Reading >>

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, Ian F. Alexander and Neil Maden provide scenario-based guidance for choosing between Evolutionary, Incremental and High-Risk software process models.

Continue Reading >>

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, Ian F. Alexander and Neil Maiden write about the Evolutionary, Incremental, and High-Risk software process models for systems engineering ‘in the large.’

Evolutionary Model

According toe Alexander and Maiden, the Evolutionary model for software engineering is structured as follows:

• Version 1:  User Requirements Definition, System Requirements Definition, System Design/Architecture, Preliminary Design, Detailed Design, Implementation, Test and Integration, Acceptance and Certification.
• Version 2:  User Requirements Definition, System Requirements Definition, System Design/Architecture, Preliminary Design, Detailed Design, Implementation, Test and Integration, Acceptance and Certification.
• Version 3:  User Requirements Definition, System Requirements Definition, System Design/Architecture, Preliminary Design, Detailed Design, Implementation, Test and Integration, Acceptance and Certification.

Continue Reading >>

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.

Continue Reading >>