Tải bản đầy đủ (.pdf) (22 trang)

Tài liệu Module 3: Process Model pdf

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (196.3 KB, 22 trang )

Module 3: Process Model
3
THIS PAGE LEFT INTENTIONALLY BLANK
0RGXOH#6=#3URFHVV#0RGHO##6²6
2EMHFWLYHV
At the end of this module, you will be able to

Understand the process model for infrastructure
deployment at a high level

Understand the benefits of versioned releases

Understand the relationships among project
variables

Understand the concept of managing trade-offs
6²7# # 0RGXOH#6=#3URFHVV#0RGHO
/HVVRQV
Lessons
1. Process Model for Infrastructure
Deployment
2. Versioned Releases
3. Managing Project Trade-offs
0RGXOH#6=#3URFHVV#0RGHO##6²8
/HVVRQ#4=#3URFHVV#0RGHO#IRU#,QIUDVWUXFWXUH#'HSOR\PHQW
Lesson 1:
Process Model for
Infrastructure Deployment
A high-level overview of the
MSF process model for
infrastructure deployment


6²9# # 0RGXOH#6=#3URFHVV#0RGHO
3ULQFLSOHV#RI#WKH#0LFURVRIW#'HSOR\PHQW#3URFHVV

Schedule for an uncertain future

Minimize uncertainty through effective risk
management

Use frequent builds and quick tests to
maximize product stability and predictability

Cycle rapidly

Focus creativity by evolving features and
constraining resources

Establish fixed schedules

Use small teams working in parallel with
frequent synchronization points
This slide and the one that follows describe the fundamental concepts and
guiding principles that underlie Microsoft’s development process.


Add buffer (additional) time to project schedules to help the project team
accommodate unexpected problems and changes.


For most projects, the ability to manage risk is the limiting factor for project
success.



A regular solution build is the single most-reliable indicator that the team is
functioning and development is progressing.


Versioned releases enable the project team to respond to continuous
changes.


Microsoft’s general development approach is to constrain development
resources and budget, which focuses creativity, forces decision-making, and
optimizes the release date.


Internal time limits keep pressure on the project team to prioritize features
(referred to as time-boxing) and activities, as well as to make critical trade-
off decisions.


A large team can work as many small teams in parallel if team members
periodically synchronize their activities and deliverables.
0RGXOH#6=#3URFHVV#0RGHO##6²:
3ULQFLSOHV#RI#WKH#0LFURVRIW#'HSOR\PHQW#3URFHVV#
+FRQWLQXHG,

Break large projects into manageable parts that
can be delivered in a few months

Use vision statements and outline specifications

to guide projects—baseline early, freeze late

Avoid scope creep

Use proof-of-concept prototyping to allow for
predevelopment testing

Apply zero-defect mindset

Apply no-blame milestone reviews
These are additional principles of the MSF process:


Microsoft’s fundamental development strategy is to divide large projects
into multiple versioned releases, with no separate maintenance phase.


Use high-level vision statements and outline specifications to get projects
going, rather than trying to write a complete and detailed specification at the
outset.


The vision statement and specifications help the team maintain proper focus
and trace critical features to the original requirements, as well as filter out
any additional features that creep into plans after the project has been
defined.


Prototyping allows predevelopment testing from many perspectives,
especially usability, and helps create a better understanding of user

interaction. It also leads to better product specifications.


To maximize product stability and predictability, the team should be able to
bring the solution to a release condition and keep it there indefinitely.


As soon as a milestone is achieved, conduct a milestone review to highlight
lessons learned, especially things done well. This is the mechanism by
which learning is consolidated and institutionalized.
6²;# # 0RGXOH#6=#3URFHVV#0RGHO
(OHPHQWV#RI#WKH#6ROXWLRQ
Installation
Process
Training
Selected
Technologies
Documentation
Support
Communications
The term “solution” in this course refers to the synthesis of all of these
elements, the broad categories for those things the team needs to be successful
during the deploying phase.
Projects may vary in complexity and the amount of effort necessary for
development. Many of these elements may not be necessary in a relatively
simple deployment, although the more complex, larger-scale deployment efforts
will most likely require all of these.


Selected technologies may be new to the enterprise or organization, or may

be upgrades, updates, or added components. Technologies may include
hardware, software, peripherals, or network components.


Training applies to everyone who will be using or supporting the new
technology being deployed.


Documentation refers to all the information needed to install, maintain,
support, and use the solution.


Support processes include the procedures necessary to perform backups,
restorations, disaster recovery, troubleshooting, and help desk functions.


External communications involve keeping outside stakeholders apprised of
the progress of the deployment and how the solution will affect them.


Installation processes are the steps performed to install, and at times
uninstall, the selected technologies.

×