Home » Archive

Articles in the Process Category

Guest Posts, Process »

[22 Jun 2009 | 14 Comments | ]
Patterns and Practices of Lean Software Development

Lean Thinking is a paradigm of production and can’t easily be reduced to a process recipe. The particular form of any Lean process will always depend upon the form of the product that is created by that process. However, any Lean process will realize a few essential principles. If we apply these Lean principles to software development, we may find some practices that express those principles in a way that is useful and sensible for the medium.

Guest Posts, Process »

[15 Jun 2009 | 10 Comments | ]
Introduction to Lean Software Development

Editor’s note: This is a guest post on Lean Software Development by Corey Ladas. If you don’t know Corey, he’s a product development methodologist. He brings more to the table than most on engineering process because of his background working on integrated mechanical / electrical / software products.  What I like about Corey is his ability to take start of the art and bridge the gap with state of the practice. He has an uncanny ability to boil complex things down into their essence. without further ado, here’s Corey with …

Design, patterns & practices, Process, Project-Management, Requirements »

[19 May 2009 | 6 Comments | ]
Customer Connected Engineering

Customer Connected Engineering (CCE) is a practices we use across our patterns & practices teams for engaging customers throughout the life cycle. We involved customers during the planning, development, and release of our deliverables. This is a draft slide set that shares how we do Customer Connected Engineering inside patterns & practices, including our key practices and guiding principles.

Process »

[21 Sep 2008 | 2 Comments | ]

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 …

Frames, patterns & practices, Process »

[16 Sep 2008 | One Comment | ]

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

Process »

[18 Aug 2008 | 2 Comments | ]

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 …

Process »

[18 Aug 2008 | 4 Comments | ]

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 …

Process »

[18 Aug 2008 | 4 Comments | ]

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 …

Process »

[18 Aug 2008 | 3 Comments | ]

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 …

Process »

[17 Aug 2008 | Comments Off | ]

Do you need to adopt all of the Extreme Programming (XP) practices to get results?  Can you adopt the XP practices piecemeal?  In Extreme Programming Explained: Embrace Change (2nd Edition) (The XP Series), Kent Beck writes that you can adopt XP practices piecemeal, but the more you adopt, the more synergy you get.
The Full Value of XP Comes When All the Practices are in Place
Beck writes:
The full value of XP will not come until all the practices are in place.  Many of the practices can be adopted piecemeal, but their …

Process »

[23 Jun 2008 | Comments Off | ]

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 …

Process »

[23 Jun 2008 | 6 Comments | ]

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 …

Process »

[23 Jun 2008 | Comments Off | ]

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

Process »

[23 Jun 2008 | 3 Comments | ]

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 …

Process »

[22 Jun 2008 | One Comment | ]

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 …

Process »

[22 Jun 2008 | 5 Comments | ]

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 …

Process »

[22 Jun 2008 | 3 Comments | ]

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

Process »

[22 Jun 2008 | Comments Off | ]

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 …

Process »

[22 Jun 2008 | 3 Comments | ]

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

Process »

[22 Jun 2008 | One Comment | ]

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 …