You are on page 1of 38

Microsoft Solutions Framework MSF v4

Strategic Consultant rafal@projectbotticelli.co.uk Project Botticelli Ltd


This presentation is based on work by Microsoft TechNet, MSDN and various Microsoft authors including, with
TEAVNOST: 200 special thanks: Ramprabhu Rathnam, Tony Northrup, and Austin Wilson

Rafal Lukawiecki

Objectives
Convince you that non-technical reasons impact project success a lot Show you an approach to product management that has proven to be very successful Explain the recent developments

TEAVNOST: 200

Agenda
Introduction to Frameworks Components of MSF v3 and v4 Future

TEAVNOST: 200

Why Projects Fail? What are Frameworks?


TEAVNOST: 200

Introduction:

MSF
Microsoft Solutions Framework
Established in 1991, made public in 1993 (v1), fully revised in 1998 (v2), January 2003 (v3) and now in March 2006 (v4) Product development framework for creating software and infrastructure deployment

Related to MOF, Microsoft Operational Framework


Which concentrates on the management of IT infrastructure
TEAVNOST: 200

IT Lifecycle

Microsoft Solutions Framework

TEAVNOST: 200

Microsoft Operations Framework

Does it Work?
Yes, as long as you chose the right bits of MSF for your project High-profile projects that used MSF
www.nasdaq.com and www.marriott.com (Aris Corp, now Ciber, www.ciber.co.uk) UK Government Gateway (eGov) Visual Studio, Windows 2003, Windows XP
TEAVNOST: 200

Whats a Framework?
Unlike a methodology, a framework is a set of conceptual tools and best practices However, in many ways MSF v4 is closer to a methodology than v3

TEAVNOST: 200

Root Causes of Failure


Separation of goal and function Separation of business and technology Lack of common language and process Failure to communicate and act as a team Processes that are inflexible to change Solution?
TEAVNOST: 200

When projects fail, its rarely technical.


Jim Johnson, The Standish Group

Average cost overrun: 45% Time overrun: 63% Functionality delivered on average: 67%
Standish Group

A good and tested framework!

10

Evolution from MSF v3 to v4

TEAVNOST: 200

11

MSF Partner Council Who Advised v4

TEAVNOST: 200

12

Evolution to MSF v4

TEAVNOST: 200

13

Status
MSF v3 is fully released and available
Study course MOC #1846

MSF v4 for Application Development (both Agile and CMMI) have just shipped on 29 March 2006
Download guidance from www.microsoft.com/msf

MSF v4 for Infrastructure Deployment and other flavours (Solutions, Consulting, etc.) are under development at present
This is news! Good news.

TEAVNOST: 200

14

Agility
Agility of the development process is the key to being able to cope with inevitable changes (spec, environment, business) or planning errors The price of it is a certain unpredictability of the process
Finish date, final cost, feature set

TEAVNOST: 200

Generally, agility is great for small and medium projects in existing and tested dev environments

15

CMMI
Capability-Maturity Model Integration describes 5 (or 6) levels of process-based predictability of an organisation (or department) in terms of their ability to produce quality software Level 5 is best. Most companies are 0 or 1. MSF v4 can help you work at level 3 or more. Moving towards higher levels is done by adopting highly predictable (but not so agile) processes Great for larger or more formal projects, especially in more critical environments By the way, MSF and CMMI are not strangers: KPMG published a paper on how MSF v1 could help you with CMM already in 1995!

TEAVNOST: 200

16

Observation
MSF v3 seems more formal than MSF for Agile Software Development
We lose some of the structure and modelling from v3 and replace them with a more integrated agile process

MSF v3 seems less formal than MSF for CMMI Process Improvement
Structures from v3 are becoming more process-improvement oriented
TEAVNOST: 200

17

What About Extreme Programming?


Extreme Programming (XP), which was created after MSF, has similarities
XP is less predictable than necessary for more formal projects
But great for very agile projects Similarities regarding the Zero Defect Mindset and Daily Builds

MSF for Agile Software Development seems more predictable, controllable and even more agile than XP MSF CMMI Process Improvement, naturally, is less agile than XP, but seems the most predictable
TEAVNOST: 200

18

Key Components of MSF

TEAVNOST: 200

19

A Team of Peers (v4 Agile)

TEAVNOST: 200

20

Scaling the Team Model


Feature & Function Teams Technique Example:

TEAVNOST: 200

21

Designing Software within MSF


UML (Unified Modelling Language) has a great tradition, though we may need to evolve towards a service-oriented approach
UML2? Perhaps, but its possible to be more direct in design.

Domain Specific Languages!


Great conceptual integration both with MSF and with the tools (VSTS) Further, possible, integration with SDM and TEAVNOST: 200 DSI

22

Project Management in v4
One of the most powerful features of Visual Studio Team System is its automation of project management
Workstreams, Work Items, and Roles concepts Uses Team Foundation Server Relies on Microsoft Project-style planning documents
TEAVNOST: 200

23

MSF Process Model v3


Deployment Complete

Release Readiness Approved

Vision/Scope Approved

MSF
Scope Complete Project Plans Approved

TEAVNOST: 200

24

Deploy

MSFv4

Envision

Stabilize

Release 1

Plan
Build
TEAVNOST: 200

25

Process Modelling in v4
MSF v4 introduces a new model of Governance and Enactment which replace the traditional process model
This caters for different types of processes, which are now defined at the level of methodology, rather than the framework This makes MSF v4 much more suited to work in teams both very small and very big, as opposed to what v3 could have ever catered for
TEAVNOST: 200

27

Iterations
Achievement of a pre-determined level of quality Based on planning of feature-sets Mechanism to correct project plan deviations

TEAVNOST: 200

28

Governance
Process mapped onto specific iterations

TEAVNOST: 200

29

Cycles
The foundation of every days coordinated work of the team

TEAVNOST: 200

30

Daily (Nightly) Build


Building the product in a deployable form on a daily basis
A daily build is
A strong indicator that a team is functional Guarantee against component integration problems A way to make the product and its progress visible The heartbeat of the development process

A key function of VSTF (see later)


TEAVNOST: 200

32

Knowing When You Can Ship MSF v4 defines:


Minimum Acceptance Level (Scenarios)
Relates to Core Functionality Set

Quality Criteria

Test Thresholds
Code Coverage for Unit Tests Other, context-driven (bugs per developer)

VSTS manages tracking and reporting of these quality criteria during all phases of the project
TEAVNOST: 200

33

Work Items
Activities and Workstreams manage the concept of a work item, which describes an assignable, individual piece of effort that needs to be done:
Bug Quality of Service Requirement Scenario Risk (not yet in the beta of VSTS, but soon) Task

TEAVNOST: 200

34

enacts ProcessModule 1..* parentwork PatternsCookbook

enacts SecurityGroup performer Role 1 1..* 1 responsibleRole 0..*

Process Model

1..*

subwork work

Activity 0..1 0..1 1 1..* 0..* 1..* parentwork Discipline Guidance enacts 1..* Step subwork ProcessHelp Constraint Assignment WorkActivityItem Iteration enacts 0..1 0..* ProjectTask 0..1 0..1 WorkItem 1 Phase 0..*

enacts

enacts

ResponsibilityKind 1..*input work_product_responsibility enacts WorkProduct output * Artifact SourceArtifact PortalArtifact WorkProductInState constrainedElement ActivityInclusion lifeCycle 1 ReferencedArtifact

1..*

StateMachine

State enacts WorkProductItem

TEAVNOST: 200
1 0..*

35

Team System
Ingenious: tool that implements MSF!
As soon as you create a new project in VSTS you get to chose which version of MSF v4 you want to use!

VS 2005 TS manages the flow of work items between team members, as well as overlooks their progress Individual versions for
Developer Architect Tester

Reporting and management tools for project manager and other team members
Includes Outlook, Excel and Project Support
TEAVNOST: 200

36

Future

TEAVNOST: 200

37

MSF and Software Development


Without a doubt, the emphasis of MSF v4 is on software development
The MSF team is now firmly a part of the Visual Studio group within Microsoft

Tying the framework to the tools (VSTS) was the masterstroke that gave MSF a very prosperous future
And vice-versa: the method adds value to the tools, beyond what any Microsoft competitor could offer today
TEAVNOST: 200

38

MSF for Infrastructure Deployment


While initially there was a little confusion, it has now been confirmed that MSF v4 will cater for Infrastructure Deployment too While the detail is being finalised, please consider using MSF v3 or MOF for purely infrastructure deployment oriented projects
Consider using the more flexible process approaches from v3 Soft skills, whichever version, like all good ideas, age only like wine, anyway

TEAVNOST: 200

39

Summary
Projects fail for non-technical reasons A framework such as MSF fixes those problem You dont have to use all of MSF at once If you use some bits you increase your chance of succeeding Visual Studio Team System is a marvellous implementation of MSF principles
TEAVNOST: 200

40

Resources
www.microsoft.com/msf
MSF for Agile Software Development:
lab.msdn.microsoft.com/teamsystem/workshop/msfagile/defau lt.aspx lab.msdn.microsoft.com/teamsystem/workshop/msfcmmi/defa ult.aspx msdn.microsoft.com/vstudio/enterprise/msf/ forums.microsoft.com/msdn/ShowForum.aspx?ForumID=63 www.microsoft.com/mof

MSF for CMMI Process Improvement:


MSF v3:

MSF Forum: MOF:

TEAVNOST: 200

You might also like