Software Engineering, your guide to Better Programs and Formal Documentation: Part 1 - MSF Fundamentals

I've been studying Microsoft's MSF approach to solution requirements and share what I've learned. You may start wondering, "Why do I need to go through all the hassle of making a requirements document or documentation for that matter?". Well think of it this way, when you buy plastic models (aircraft, cars, miniatures, etc.), there is a instruction manual included to help you contruct your model. Now try constructing the model without the instructions. You may be able to arrive at the general form of the model by comparing work with the model's box art, but you may not use up all the parts and even end up with an incomplete model. Taking this analogy and applying it to software development, many will agree that the exact or something close to it has already happened to you.

MSF CONCEPTS
The main difference of the MSF process model is that it is a combination of both the waterfall and spiral model. Unlike the waterfall model, where milestones are reached in a very linear manner, and you are not allowed to backtrack, the MSF model uses the spiral model's ability to perform iterations when needed. The MSF process model is divided into 5 phases; the Envisioning Phase, Planning Phase, Developing Phase, Stabilizing Phase, and the Deploying Phase.

THE MSF TEAM
The MSF team model is composed of the following:

1. Product Management - handles the project scoping and deployment.
2. Program management- is responsible for delivering the project constraints.
3. Development - responsible for the implementation of the solution.
4. Testing - evaluates and validates design functionality and makes sure that the solution is consistent with the project's vision and scope.
5. Release Management - ensures that the solution is deployed without any hitches.
6. User Experience - collects and analyzes customer/client feedback.

THE MSF TRADEOFF TRIANGLE
One of the concepts I really enjoyed and always try to implement is the MSF's Tradeoff triangle. We are given three tradeoff to manage: Resources, Schedule and Features (RSF). A fourth tradeoff can be added - Quality. But is usually omitted to ensure a quality solution to a project. The RSF is used as follows, we assign the priorities of the RSF by applying one of the follwing: Fixed, Chosen, and Adjustable. Only one priotity can be added to each RSF tradeoff. An example: Given a Fixed number of Resources, we Chose a Schedule, and Adjust Features set accordingly. Another example, With a Fixed Schedule, we Chose the Features set, and Adjust the Resources available to us. Still with me? I hope you get the gist, it's quite effective and brutally simple once you realize you could have done this a long time ago.

Well, that ends Part 1 of the series, I do hope you stay tuned cuz I plan on posting more of the series every two (working =p) days.




Permalink