Is building software the same as manufacturing a physical product?  Can you really create an assembly line for software?   In the book A Practical Guide to Enterprise Architecture (Coad Series), James McGovern, Scott W. Ambler, Michael E. Stevens, James Linn, Vikas Sharan, and Elias K. Jo write about how you should use the metaphor with caution.
Use the Manufacturing Metaphor for Software with CautionMcGovern, Ambler, Stevens, Linn, Sharan, and Jo write the following:
Before dropping everything and setting up an assembly for creating software products, it should be noted that the …

One of my earlier projects on the patterns & practices team at Microsoft was originally called Life-Cycle Practices.  Later, I renamed it to Life-Cycle Templates.  Finally, I settled on Engineering Practices.   Engineering Practices became a key organizing theme for our work and served as the foundation for our ALM frame.
Knowledge AreasThe Engineering Practices Frame uses the following categories to organize software development knowledge.

Management
Requirements and Analysis
Architecture and Design
Development
Testing
Deployment
Maintenance
Security Engineering
Performance Engineering

Notice that the top buckets map to disciplines while the bottom buckets (Security Engineering and Performance Engineering) map to quality attributes.  …

This is one of my favorite figures that shows how we do solution engineering in patterns & practices at Microsoft:
 
Architectural Scenarios
It all starts with a scenario.  It has to be a meaningful problem.  You can’t evaluate an architecture in a vacuum.  In order for us to build useful baseline architectures, we need to pick the right scenarios that flex the right engineering decisions.
Patterns
Patterns are simply problem and solution pairs.  In our case, we tend to focus on application, architecture or solution level patterns.
Baseline Architectures
Baseline architectures are skeletal applications.  They’re just …

Extreme Programming (XP) is a lightweight software development methodology based on principles of simplicity, communication, feedback, and courage.   I like to be able to scan methodologies to compare approaches.  To do so, I create a skeleton of the activities, artifacts, principles, and practices.    Here are my notes on XP:
Activities

Coding
Testing
Listening
Designing

Artifacts

Acceptance tests
Code
Iteration plan
Release and iteration plans
Stories
Story cards
Statistics about the number of tests, stories per iteration, etc.
Unit tests
Working code every iteration

12 Practices
Here’s the 12 XP practices:

Coding Standards
Collective Ownership
Continuous Integration
On-Site Customer
Pair Programming
Planning Game
Refactoring
Short Releases
Simple Design
Sustainable Pace
System Metaphor
Test-Driven Development

For a visual of …

The Microsoft Solutions Framework (MSF) provides people and process guidance—the proven practices of Microsoft—to help teams and organizations become more successful in delivering business-driven technology solutions to their customers.  Note that this MSF is not the same as the MSF Agile process included in VSTS.  I like to be able to scan process methodologies.  To do so, I create a skeletal view of the activities, artifacts, … etc.   Here’s my notes on the Microsoft Solution Framework circa 2005, which might be a bit dated, but provide a quick lens into …

I like to be able to scan process methodologies so I create skeletal views that let me quickly see the key activities, artifacts, principles, and practices of a methodology.  MSF for Agile Software Development is a scenario-driven, context-based, agile software development process.   Here’s my notes on MSF Agile circa 2005, which might be somewhat dated, but at least give me a quick lens into the main ideas:
Principles

Partner with customers
Foster open communications
Work toward a shared vision
Quality is everyone’s job every day
Stay agile, adapt to change
Make deployment a habit
Flow of value

Mindsets

Quality …

I like to be able to scan process methodologies so that I can quickly compare approaches.  I found my old notes on Rational Unified Process (RUP).  I think they’re circa 2005, so they could be a bit dated:
Six Key Principles

Adapt the process
Balance stakeholder priorities
Collaborate across teams
Demonstrate value iteratively
Elevate the level of abstraction
Focus continuously on quality

Activities
Analysis and Design

Assess viability of Architectural Proof-of-Concept (Architect)
Architectural Analysis (Architect)
Identify Design Mechanisms (Architect)
Identify Design Elements (Architect)
Construct Architectural Proof-of-Concept (Architect)
Incorporate Existing Design Elements (Architect)
Describe the Run-time Architecture (Architect)
Describe Distribution (Architect)
Capsule Design (Capsule Designer)
Database Design (Database …

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:

Questions
Answers

Is there a business need to get the product to market in the shortest time possible?
Yes

Is …

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 …

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, …

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 …

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.
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 …

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, Ian F. Alexander and Neil Maiden write about systems engineering ‘in the large.’ 
Systems Engineering ‘in the large’ Stages
Alexander and Maiden identify systems engineering ‘in the large’ stages:

Explore Concept
Proof of Concept
Full Development
Production
Installation
In-Service Support
Disposal

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, Ian F. Alexander and Neil Maiden write about systems engineering ‘in the small.’ 
Systems Engineering ‘In the small’ Activities
Alexander and Maiden identify the following systems engineering ‘in the small’ activities:

User Requirements Definition (URD)
System Requirements Definition (SRD)
System Design / Architecture (SD/A)
Preliminary Design (PD)
Detailed Design (DD)
Implementation …

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, Ian F. Alexander and Neil Maiden write about using a meta process to choose the most effective process model for your projects.  
Accommodate ‘in the large’ and ‘in the small’ Explicitly
Alexander and Maiden write that you need to explicitly accommodate systems engineering ‘in …

If you build software, you’ve most likely heard of the Waterfall model and the problems associated with it. In Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle, Ian F. Alexander and Neil Maiden provide constructive criticism of the Waterfall model.
Waterfall Model Elements
Alexander and Maiden outline the key sequence of stages in the waterfall model based on Royce (1970).

Requirements Discovery
Requirements Validation
System Specification
System Design
Coding, First of Class
Integration & Testing
Operations & Maintenance

Defining effective software development processes is difficult.  One the one hand, you need to support constructive systems engineering.  On the other hand, you need to be flexible enough to reflect the needs of projects. In Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle, Ian F. Alexander and Neil Maiden provide four reasons why defining software development process is difficult.
Four Reasons Why Defining Effective Software Processes is Tough
Alexander and Maiden identify four reasons why defining effective software development process is difficult:

Muddled ‘process levelling’
Insufficient attention paid to ‘project characterization’ at the …

There’s lots of ways to slice and dice software process. In Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle, Ian F. Alexander and Neil Maiden show the waterfall model, systems engineering ‘in the large’ , and systems engineering ‘in the small.’
Waterfall Life Cycle Elements
Alexander and Maiden outline the key sequence of steps in the waterfall model based on Royce (1970).

Requirements Discovery
Requirements Validation
System Specification
System Design
Coding, First of Class
Integration & Testing
Operations & Maintenance