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 Areas
The 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. The model is flexible. You can add buckets for disciplines or quality attributes depending on where you need more focus.
Practices, Activities, and Artifacts Matrix
The beauty of the frame is that you can collect and share principles, patterns, and practices for key activities and artifacts using meaningful buckets:
| Knowledge Area | Practices | Activities | Artifacts |
|---|---|---|---|
| Management | – | – | – |
| Requirements and Analysis | – | – | – |
| Architecture and Design | – | – | – |
| Development | – | – | – |
| Testing | – | – | – |
| Deployment | – | – | – |
| Maintenance | – | – | – |
| Security Engineering | – | – | – |
| Performance Engineering | – | – | – |
You can imagine filling out the practices, activities and artifacts for each area. It’s a simple, but effective way to share your software engineering knowledge or create a center of excellence.
Objectives
I set the following objectives for the Engineering Practices Project:
- Provide customer guidance for software engineering practices and techniques
- Refine and enhance successful software practices
- Reduce mistakes and improve software quality
- Bake quality attributes (security, performance, … etc.) into the life cycle
- Build a community around best software development practices
- Increase precision around context
How I Created the Categories
I wanted the Engineering Practices frame to be inclusive and flexible. I wanted to play well with the Software Engineering Body of Knowledge (SWEBOK) . I also wanted to play well with various Microsoft initiatives including MSF. Most importantly, I wanted it to be useful for customers and map to what they already know where possible. This made it easier to organize our patterns & practices solution assets in a meaningful way.
Creating the categories was an iterative process. I gathered all the principles, practices, patterns, techniques, activities, and artifacts that I ever came across. I vetted against all the various software methodologies and life cycle models I ever came across. Lastly, I tested and vetted with various customers, both internally and externally until the buckets started to stick.
Core Activity Backdrop
The beauty of the core activities is that they are drawn from experience whiteboarding life cycles with customer after customer:
The core activities aren’t fancy, but they are effective.
Security Overlay
Here’s where the power of the core activities starts to shine. You can overlay security activities on top of the core activities:
Performance Overlay
You can also overlay key performance engineering activities on top of the core activities:
Wrap Up
Well, that’s the story of the Engineering Practices Frame. It has a long history and a happy ending. It helped shape MSF Agile, the patterns & practices product model, and the ALM frame. You can see the influence on MSF if you look to the security and performance sections.
Additional Resources
- Engineering Practices (Guidance Share)
- Security Engineering (Guidance Share)
- Performance Engineering (Guidance Share)
- SWEBOK (SWEBOK.org)
My Related Posts
patterns & practices Solution Engineering
The Story of the Engineering Practices Frame…
I shared the story of our patterns & practices Engineering Practices Frame on Shaping Software . …