LUC Project Management of Golden Opportunity for Revcon Question

+Appendix A to Chapter 4
Stages of Systems Engineering
Project Management for Engineering,
Business, and Technology
Prepared by
John Nicholas, Ph.D.
Loyola University Chicago
Information Classification: General
Stages of the Systems Engineering
Process
Information Classification: General
Stage 1 of the Systems Engineering Process:
Needs Identification and Conceptual Design
Main tasks of this stage
• Define stakeholder needs and requirements
• Feasibility analysis
• High-level requirements analysis
• System-level synthesis
• Create system specification
Information Classification: General
Stage 1: Needs Identification and Conceptual Design
•
•
Identify the stakeholders, including the client or customer
and others who will be affected by or able to impact
(contribute to, support, or block) the system.
Develop a clear conception of the need or problem begins
by asking basic questions:
1. How did the problem or need arise?
2. Who believes it to be a problem or feels the need?
3. Is this the root problem or need, or is it a manifestation of some
other, deeper problem?
4. Why is a solution important? How much money (or time, etc.) will it
save? What is the value of the system?
5. How important is the need? Would resources be better applied to
another need?
Information Classification: General
Stage 1: Needs Identification and Conceptual Design
Requirements Definition
High-level requirements incorporate everything important about the
system, including
•
Objectives. The overarching aim of the system in terms of several
objectives, each elaborated in terms of a set of requirements.
•
Life cycle. How the system will be built, tested, distributed,
marketed, financed, operated, maintained, and disposed of
(includes ancillary issues, “side items,” and environmental impacts.
•
Operational modes. The multiple environments and different
ways in which the system will be used. Each constitutes a different
set of requirements.
•
Constraints. Policies, procedures, and standards; available
materials, knowledge, and technology; and limited time, funding,
and resources.
•
Interfaces. An interface occurs wherever a system receives input
from or provides output to other systems. Requirements specify
the interfaces and mandated or pre-specified inputs or outputs at
each.
•
Requirements stated in the language of the stakeholders are
compiled in the stakeholder requirements document (SRD).
Information Classification: General
Stage 1: Needs Identification and Conceptual Design
Requirements Definition
Feasibility
•
Given high-level requirements,next step is to identify
alternative high-level (system-level) solutions.
•
These are evaluated in terms of costs, risks,
effectiveness, and benefits using studies and models.
System Requirements Analysis
•
Next step: specify what the system must do to be able
to meet the requirements in the SRD; this is purpose
of system requirements.
•
System requirements tell the designers the functions
the system must perform and the physical
characteristics it must possess to meet requirements
in the SRD.
Information Classification: General
Stage 1: Needs Identification and Conceptual Design
Requirements Definition
System requirements analysis addresses three kinds of
requirements: functional, performance, verification.
Functional Requirements
•
These specify the functions the system must perform to
meet requirements in the SRD, including those for
support, operation and maintenance.
•
A tool for analyzing and defining functional requirements
is the functional flow block diagram, FFBD. Each block
represents a function that the system must perform to
satisfy objectives or requirements.
Information Classification: General
Functional flow block diagram, FFBD
Each block represents a function; each function is defined in
greater detail by decomposing it into sub-functions
3.3
Information Classification: General
Stage 1: Needs Identification and Conceptual Design
Requirements Definition
Performance Requirements
•
Associated with each functional requirement are
performance requirements
•
Functional requirement state what the system must do;
performance requirements specify how well it must do it
•
Are usually specified in physical parameters, e.g.,
speed, acceleration, weight, tolerance, power, force,
time.
Verification Requirements
•
Accompanying each performance requirement is a set
of verification requirements
•
These specify the procedures, measures, and tests to
verify that the performance requirement has been met
Information Classification: General
Stage 1: Needs Identification and Conceptual Design
Synthesis
Addresses the relationships among the system-level
requirements and alternative ways to satisfy
them; e.g.
• Create newly designed or technologies and parts
• Procure existing—”off the shelf” (OTS)—designs
and products
–
•
OTS items can be readily purchased or built; they are
often preferable to newly designed ones because they
are readily available and sometimes less costly
When no OTS item is available and creating a
new design would be too costly, risky, or timeconsuming, the requirements must be revised.
Information Classification: General
Stage 1: Needs Identification and Conceptual Design
Synthesis
Result of synthesis is the “system specification.”
The system specification
• Is a comprehensive list of all the functions the
new system must satisfy
• Identifies a firm or tentative solution (whether the
item will be developed or bought) for each
function.
• Serves as a guide for designers in the stages of
preliminary and detailed system design.
Information Classification: General
Stage 2 of the Systems Engineering Process:
Preliminary Design
Main tasks of Preliminary Design
• Translate system-level functional requirements
into design requirements for the subsystems.
• Perform tradeoff studies of high-level elements
comprising the system
• Allocate the system-level requirements among
the subsystems.
Information Classification: General
Stage 2: Preliminary Design
Identify Functions of Subsystems
•
•
•
Repeat the FFBD process to decompose the
system-level functions into subsystem-level
functions
As before, define functional, performance, and
verification requirements for each function.
The degree of detail of the FFDBs is whatever
necessary to define each subsystem and permit
decisions about whether each function can be
met with an OTS design or product or must be
designed and built from scratch.
Information Classification: General
Stage 2: Preliminary Design
Grouping of Functions
System architecture
• Next step is to group the identified functions
and requirements according to the desired
physical architecture of the system (i.e., how
the major components in the system are
configured or arranged to satisfy the functions
of the system.
• Example, architecture for a bicycle:
–
–
Major components: two wheels, frame, seat, pedals
and chain, handle bar.
Configuration: wheel attached at each end of frame;
front wheel pivots on frame; seat mounted on frame;
pedals attached to frame but linked by chain to rear
wheel.
Information Classification: General
Stage 2: Preliminary Design
Grouping of Functions
Configuration Items
• Each subsystem that will perform a major
function is called a configuration item or CI.
• From here on, the history of each CI will be
documented and monitored throughout the
system’s complete life cycle—its design,
production, and operation.
• Documenting and tracking the CI’s is called
configuration management.
–
The purpose is to ensure that any changes in the
design, production, or usage of the CI do not alter
or degrade its ability to meet the functional
requirements.
Information Classification: General
Stage 2: Preliminary Design
Requirements Allocation
•
As of this point, the design consists of
(1) a list of the functional requirements
(2) a high-level design of the system—the major subsystem or
CI’s, and the system architecture
•
•
•
Next step is to “allocate” the functional
requirements to the CIs, i.e., assign
responsibility for each functional requirement to
one or more of the CI’s.
Purpose is to ensure that every functional
requirement will be addressed by at least one
subsystem or CI.
Resulting allocations are shown in an
“allocation” or “traceability” matrix
Information Classification: General
Allocation (Traceability) Matrix
Information Classification: General
Stage 2: Preliminary Design
Requirements Allocation
•
•
•
•
Since each CI represents something that will
ultimately be a physical item—a piece of
hardware, software, etc., assignment of functional
requirements to CI’s represents a subtle change in
thinking—from what must be done to how the
system will do it.
Allocation of requirements results in setting
specific technical targets for each CI.
Achieving these targets is critical, so the
estimated and actual performance of each CI is
closely monitored.
If it becomes clear that a target cannot be
achieved, then the allocations are readjusted.
Information Classification: General
Stage 2: Preliminary Design
Interfaces
•
•
•
•
All subsystems rely on outputs of other functions, and
provide inputs to still other functions—they interface.
All interfaces must be identified and requirements set
for each.
FFBDs provide information about interfaces. Each
FFBD arrow represents interface between functions.
– Physical—connections, joints, supports, pipes
– Electronic—analog or digital signals, electricity
– Hydraulic/pneumatic—liquid or gas
– Software—data
– Environment—temperature, pressure, humidity,
radiation, magnetism
– Procedural—completion of a procedural step so
another next step can begin
Identifying the interfaces is necessary for setting inputoutput requirements of every subsystem and element.
Information Classification: General
Stage 2: Preliminary Design
Synthesis and Evaluation
•
•
•
•
•
Designing each CI and its elements involves choosing
design alternatives and deciding to use an OTS designs
or products, or to create new ones.
Selection of alternatives considers the synthesis of
components—the impact of each design decision on
other components and the overall system.
With each decision, the form and configuration of the CI’s
evolves and the appearance of the system takes shape.
By the end of preliminary design: system architecture will
have been established; system-level requirements will
have been allocated among the CI’s.
The architecture and allocation form the “allocated
baseline” design
Information Classification: General
Example: CI’s and Allocated Baseline
Design
Information Classification: General
Stage 3 of the Systems Engineering Process:
Detailed Design and System Development
Project moves from “concepts on paper” to a ready-to-build
design
•
Decisions made: will subsystems/ components be manual,
automatic, electronic, mechanical, hydraulic, etc.?
•
Available, OTS components are selected based on surveys
or comparison tests in a laboratory
•
Newly developed components are tested experimentally
using models to verify the designs
•
System is checked under a variety of conditions and
operational modes.
•
Modifications are made to remove oversights and
deficiencies and to improve the system.
•
The capability (facilities and resources) to produce the
system (the “process design”) is developed
Information Classification: General
Stage 4 of the Systems Engineering Process:
System Construction and/or Production
Begins as soon as the design is approved and “frozen.”
•
During this stage the system is either
(1) mass produced
(2) produced in limited quantities with different
features or
(3) built as a single item.
•
The stage involves acquiring materials, managing
inventory, and controlling production/construction
operations to uphold performance, quality, reliability,
safety, and other requirements.
Information Classification: General
Stage 5 of the Systems Engineering Process:
System Operation and Support Phase
Customer operates the system; system ultimately wears out
or becomes obsolete.
•
Developer might provide support; e.g.:
–
–
–
–
•
in deploying, installing, and checking out the system
assisting in day-to-day operation with field service and
maintenance support
Modifying or enhancing the system
Closing or phasing out, and disposing of the system at the end
of its life cycle.
Close-out and disposal of the system can be a major
consideration in the design and operation of the system,
especially so for systems that have potential to degrade
the surrounding environment.
Information Classification: General
Designer Burt Rutan (center), and pilots Mike
Melville (left) & Brian Binney
Information Classification: General
Chapter 4
Project Definition and System
Definition
Project Management for Engineering,
Business, and Technology
Prepared by
John Nicholas, Ph.D.
Loyola University Chicago
Project Life Cycle
Phase A: Conception phase
Initiation stage
Feasibility stage
Proposal preparation
Phase D: Operation phase
System maintenance
and evaluation
System
improvement
(To Phase A:
Repeat cycle)
Phase B: Definition phase
Project definition
System definition
User and system
requirements
Phase C: Execution phase
Design stage
Production/build stage
Fabrication
Testing
System
Implementation stage
termination
Training
Acceptance tests
System
Installation
replacement
Termination
Phase B: Definition
◼
Assume have the following upon entering this
stage
❑
❑
❑
❑
❑
Project has been approved and funded.
An SOW in RFP and proposal
Initial list of user requirements
A “rudimentary” project plan, as necessary for
specifying technical content, time, and price in the
proposal
Contract with SOW (“CSOW)
Phase B: Definition (cont’d)
◼
Principle tasks during Phase B
(not necessarily in this order)
❑
Organize project team: hold “kickoff”
❑
Clarify in detail user requirements
❑
Prepare detailed system requirements
❑
Prepare project master plan
❑
Review requirements and plan with
customer
Phase B: Definition Tasks
◼
In little projects, Phase B is short since
❑
◼
much definition already happened in proposal
preparation
In big projects, Phase B can be lengthy
❑
sometimes taking years
Project Definition vs. System
Definition
Project Kickoff Meeting
The first formal meeting of the project team members and key stakeholders.
◼ A formal presentation with a question-and-answer period at the end.
◼ The project manager plans and runs the meeting.
◼ Runs 1.5-2 hours
◼ Purpose is to announce the project
❑ communicate what the project is about
❑ develop common expectations
❑ generate enthusiasm and commitment to project goals and deliverables.
◼ Covers
❑ who is the project manager
❑ project SOW, goals, and deliverables
❑ proposed project plan—budget, schedule, main work packages
❑ constraints and risks
❑ customers and other key stakeholders, their needs and requirements
❑ project organization structure and key team members
❑ immediate next steps.
◼ Held for every project and every major effort associated with the project
◼
Phase B: Primary Definition Tasks
User/customer
Needs
Define User/customer
Requirements
System Definition
Create Project
Master Plan
Project Definition
Define System
Requirements
and Specifications
Project Definition
◼
◼
◼
During Definition, the project master plan and end-item
requirements and specifications are defined.
The system requirements and specification address
“what” the end-item of the project must do.
The project master plan describes “how” project will
deliver end-item that meets system requirements and
specifications
Define User/customer
Define System
Requirements
◼
Iterative process
❑
❑
Details of the specifications are
defined; master plan is expanded to
reflect details
As master plan is expanded, project
constraints/opportunities/resources are
identified, which leads to revisions in
specifications
Requirements
and Specifications
Create Project
Master Plan
Project Definition = Project Planning
Project Definition
What goes into a project plan (the “execution” plan)?
Ask:
❑ What?
❑ How?
❑ Who?
❑ When?
❑ How long?
❑ Where?
❑ How much?
❑ How well?
◼
Project Definition = Project Planning
◼
Proposal addressed these questions, but
usually not in much detail.
Project Master Plan
◼
Project master plan addresses these questions
to the satisfaction of project core team (people
who will do work)
◼
Addresses all matters about project in sufficient
detail for managers to organize and direct work
to meet performance, cost, and time targets and
for team to begin work
◼
Level of detail in the master plan far exceeds
level in the proposal
Common Elements of Project Master Plan
1.
What? Scope Statement, Charter, or SOW
2.
What? Detailed requirements
3.
How? Detailed work definition (WBS or PBS and
work package/work task details)
4.
Who? Responsibility for work tasks
5.
What? Detailed schedules with milestones
6.
How much? Project budget and cost accounts
Common Elements of Project Plan (cont’d)
7. What
if? Risk plan
8. How
well, what, how? Performance tracking
and control
9. Other
elements of the plan, as needed for, e.g.
Work review and testing
• Quality control
• Documentation Implementation
• Communication/meetings
• Procurement
• Contracting and contract administration
•
Phased (Rolling Wave)Project
Planning
◼
◼
At the start of the project, often there are too many
unknowns, so the plan must be developed in phases
The initial plan is somewhat rough though adequate to
estimate project resources, time, and cost
❑ explain all this to the customer
❑
◼
As the project progresses,
the unknowns decrease
❑ details of the plan are filled in
❑ a more-detailed plan is created for the next most immediate
phase of the project
❑
◼
As project moves through the successive phases and
stages, detailed plans are prepared with more-specific
deliverables and schedules.
Phased Project Planning
Phased Project Planning
◼ Sometimes each phase concludes with a milestone or
phase-gate review
❑ The customer or management review the deliverables and
project performance
❑ If satisfied, they approve the deliverables and pay
for work done thus far.
◼ They also review the detailed plan for the next phase,
❑
If satisfied they authorize the next phase.
Authorization to begin the next phase represents a
commitment by the customer and management to
support the phase
◼ If the project has to be terminated, it is terminated at the
end of a phase.
◼
Phased Project Planning
System Definition
◼
System requirements and specifications elaborate in
detail on the technical performance of end-item
◼
Tell designers and builders what project end-item
(deliverable) must be and do
◼
Are a translation of user requirements into technical
requirements
◼
Users are ignorant of most
system requirements
Define User/customer
Requirements
Define System
Requirements
and Specifications
Create Project
Master Plan
Project Charter
For internal projects, the charter describes the project to stakeholders.
◼ Sometimes it is used to generate interest in a proposed project.
◼ Often it is used to announce authorization of an approved project.
in the organization and establish the project manager’s authority to
gather and make use resources.
◼ It provide a good overview of the project and may include
❑ the project objectives and scope
❑ stakeholders and their stakes,
❑ estimated budget and schedule
❑ risks
❑ assumptions and constraints
❑ resources
❑ key roles and the people them.
◼ Sometimes it is used as the project plan; more commonly it is
somewhat brief
Project Charter
◼
Charter is the scope document internal projects
❑
May include everything in Scope Statement plus
◼
risk limits
◼
customer needs
◼
spending limits
◼
key players on project team.
❑
Issued by senior management to legitimize project
❑
Gives project manager authority to initiate work
and apply resources to project.
Charter Contents
◼
◼
◼
◼
◼
◼
◼
◼
◼
◼
◼
Background
Project Objectives
Scope or SOW
Deliverables
Assumptions
Constraints
Approach
Schedule
Project Team
Risk
Management Plan
Front End Loading
◼
◼
A variation of phased project planning used by some industries.
Has three phases, FEL-1, FEL-2, and FEL-3 that overlap the
Conception and Definition Phases.
❑
❑
❑
FEL-1 confirms project is compatible with organizational strategy.
Output is a preliminary business case that confirms feasibility of the
proposed investment.
FEL-2 “shapes” project in terms of scope, technology selection, and
execution strategy. Output of is a detailed business case plus a scope
statement that enables reliable cost and schedule forecasts.
FEL-3 is “project definition” and includes preparation of a detailed project
execution plan, advanced conceptual design, and some detailed system
design FEL-3 often divided into sub-phases such as “facilities
planning/execution planning”, “pre-feasibility/ feasibility”, and
“select/FEED (Front-End Engineering Design)”. Output is a project
execution plan, conceptual (ready for detail) design, basic engineering
plan, and detailed project charter.
System Definition and Requirements
Definition
Requirements Definition is Important!
◼
Project failure often stems from ambiguous or
incomplete requirements
◼
Example: “I want this room painted blue.”?
This statement is ambiguous and incomplete.
❑
Doesn’t say what type of blue or how much of
room to paint.
Must specify exact color (paint spec. #) and exact
part of room (e.g., “only walls”)
Requirements Definition is Important!
◼
Without clear requirements, contractor
❑
Cannot know “what” is wanted
❑
Hence, cannot know how to provide it
❑
Hence, cannot define the necessary project work
(“how” the project must be done)
Requirements Definition
Start with User Requirements
◼
Most customers are somewhat unclear as to
what their requirements are.
◼
Role of PM is to work with customer/user to
clearly define requirements. This is a contractor
responsibility since the project must fulfill
customer’s requirements.
Requirements Definition
◼
Requirements are
❑
the “whats” that the project seeks to provide
❑
the basis for project planning
❑
the basis for determining project completion
❑
define the contractor’s obligation to customer
❑
◼
a principle cause of project cost and schedule
overruns
Despite their importance, good requirements are not
necessarily easy to create
Problems with Requirements Definition
1.
Incorrect Requirements: Wrong Needs
(“Needs” = user’s/customer’s problem)
❑
Incorrect Definition of Needs
❑
Shifting or Vagueness of Needs
❑
Needs of Wrong User
❑
Conflicting Needs of Multiple Users
❑
Distortions of Needs by Experts
Problems with Requirements Definition
(cont’d)
2.
Imprecise or Ambiguous Requirements (Subject
to Multiple Interpretations)
❑
Human Language
❑
Deliberate Imprecision for Flexibility
❑
Nebulous Projects
❑
User’s Lack of Expertise
❑
Project Planner’s Oversight
Problems with Requirements Definition
(cont’d)
Shifting Requirements
3.
•
•
•
•
User’s Change of Mind
Insurmountable Obstacles
New Opportunities
Seeking Perfection
Over-Specification of Requirements
4.
•
•
•
Initiative Discouraged
Requirements Ignored
Insufficient Information
Problems with Requirements Definition
(cont’d)
5.
Under-Specification of Requirements
❑
Chaotic project planning resulting in cost and
schedule overruns
Guidelines for Defining User Requirements
1.
State each requirement clearly; have both user
and project staff sign-off on it
2.
Assume if a requirement can be
misinterpreted, it will be misinterpreted
3.
Accept that changes to project are inevitable
and things will not go precisely as planned
Guidelines for Defining User Requirements
(cont’d)
4.
Include pictures, graphs, models, and other
non-verbal exhibits in requirements formulation
5.
Carefully monitor changes to requirements
once project has begun
6.
Educate both user and project staff about
problems associated with specifying
requirements
System Requirements Definition
◼
System requirements and specifications are a
translation of user requirements into technical
requirements
◼
They elaborate in detail on the technical performance of
end-item
◼
They tell designers and builders what project end-item
(deliverable) must be and do
◼
Often, users are ignorant
of system requirements
Define User/customer
Requirements
Define System
Requirements
and Specifications
(in most cases, that’s okay)
Create Project
Master Plan
Requirements Definition, example
Customer/user need
Reusable three-person space vehicle that can be
launched twice within two weeks
Requirements Definition
Customer/user need
Reusable three-person space vehicle that can be
launched twice within two weeks
Customer/user objectives and constraints
• Win X-Prize ($10 M)
• Develop technology upon which to build a entire system
to carry paying passengers into space.
• Develop vehicle that will be FAA certified.
Requirements Definition
Customer/user need
Reusable three-person space vehicle that can be
launched twice within two weeks
Customer/user objectives and constraints
• Win X-Prize ($10 M)
• Develop technology upon which to build a entire
system to carry paying passengers into space.
• Develop vehicle that will be FAA certified.
Customer/user requirements, examples
1.0 Climb to 100 km.
2.0 Comfortable, enjoyable flight
3.0 Capable of 2-week turnaround
etc.
Requirements Definition
Customer/user requirements, examples
1.0 Climb to 100 km.
2.0 Comfortable, enjoyable flight
3.0 Capable of 2-week turnaround
etc.
◼
◼
◼
◼
These requirements must be translated into system requirements
System requirements are the technical requirements
They tell the project team what the end-item system must do
A functional requirement is a kind of system requirement
❑
It specifies the functions the end-item system must perform to
meet the user requirements
❑
Associated with functional requirements are performance
requirements that specify the required level of performance
Requirements Definition
Customer need
Reusable three-person space vehicle that can be
launched twice within two weeks
Customer objectives and constraints
• Win X-Prize ($10 M)
• Develop technology upon which to build a entire
system to carry paying passengers into space.
• Develop vehicle that will be FAA certified.
Customer requirements, examples
1.0 Climb to 100 km.
2.0 Comfortable, enjoyable flight
3.0 Capable of 2-week turnaround
etc.
System requirements, examples
• functional
• performance
• verification
1.0 Climb to 100 km.
1.1 Function: Engine generates enough thrust
Performance: 73,500 kN (16,523 lbf).
Verification: simulation; mockup tests; ground tests of
ignition, ramp up, steady state, shut down
2.0 Comfortable, enjoyable flight
2.1 Function: Cabin temperature at comfortable level
Performance: 75-85 degrees F
Verification: ground tests, extreme environment chamber; flight tests
3.0 2-week turnaround
3.1 Function: Refueling takes less than 2 weeks
Performance: Actual refueling procedure should take 3 days max
Verification: simulated refueling procedure; refueling tests, etc.
Requirements Priority and Margin
Each requirement should have a specified priority and margin.
Priority Level
◼ The relative importance of the requirement
◼ In case multiple requirements conflict the priority level determines
which can be bent and which not.
Margin
◼ The amount by which the requirement can vary.
For example, “max temperature 85 degrees F ; margin 2
degrees ” says that, if necessary, max temperature can be
exceeded by up to 2 degrees.
Requirements Definition
Customer need
Reusable three-person space vehicle that can be
launched twice within two weeks
Customer objectives and constraints
• Win X-Prize ($10 M)
• Develop technology upon which to build a entire
system to carry paying passengers into space.
• Develop vehicle that will be FAA certified.
Customer requirements, examples
1.0 Climb to 100 km.
2.0 Comfortable, enjoyable flight
3.0 Capable of 2-week turnaround
etc.
System requirements
• functional
• performance
• verification
1.0 Climb to 100 km.
1.1 Function: Engine generates enough thrust
Performance: 73,500 kN (16,523 lbf).
Verification: simulation; mockup tests; ground tests
of ignition, ramp up, steady state, shut down
2.0 Comfortable, enjoyable flight
2.1 Function: Cabin temperature at comfortable level
Performance: 75-85 degrees F
Verification: ground tests, extreme environment
chamber; flight tests
3.0 2-week turnaround
3.1 Function: Refueling takes less than 2 weeks
Performance: Actual refueling procedure should take 3 days max
Verification: simulated refueling procedure; refueling tests, etc.
Requirements
Breakdown Structure
Technical Performance
Measurements
Project percent complete
Requirements Breakdown Structure
System Specifications
◼
Guide actual project work; are written by and for project
specialists—systems analysts, programmers, engineers, product
and process designers, consultants, etc.
◼
Address all areas of the project—design, fabrication, installation,
operation, and maintenance.
◼
Enable traceability
❑
Throughout the systems development cycle numerous changes
and tradeoffs will be made to requirements and specifications
❑
Tracing the impact of changes in some specifications and
requirements to others is called “traceability.”
❑
Traceability involves keeping track of specifications, tying them to
physical components, tracing their impacts, and controlling
changes so requirements are met and do not conflict.
❑
Managing traceability is called configuration management and
change control.
System Specifications
◼
Define in more detail the system requirements.
❑
Example shows system specifications derived from system
requirements, which are derived from user requirements.
Waterfall Development Methodology
◼
◼
◼
Requirements definition and system design and testing: happen
iteratively, particularly when the project end-item is complex.
Requirements cannot be defined without some amount of prior
design work, and design work cannot be completed without some
amount of prior fabrication and testing.
Overall process cascades down, with back-loops and repeated
steps. Work that flows like this is called the waterfall process.
Rapid Prototyping
▪ It can be difficult to conceptualize a system when no system exists
like the one to be developed.
▪ Requiring the customer to specify and sign-off on requirements early
in the project is risky.
▪ Rapid prototyping:
▪ A rapid prototype (RP) model is prepared. It is a rudimentary
incomplete model that initially is somewhat simple and
inexpensive to produce.
▪ It represents key parts of the system but not the complete system,
and is somewhat easy to create and modify.
▪ The customer experiments with the RP to assess the system’s
functionality and determine any modifications or additions.
▪ After a few iterations of experimenting and modifying
requirements, the final requirements and design concept are
firmed up.
▪ RP process ensures that drawings and requirements are finalized
only after the customer has accepted them as represented by the RP
model.
Agile Project Management (elaborated in
Chapter 14)
Agile Project Management is a variant of iterative life cycle and
agile management where deliverables are submitted in stages.
◼ End-item is divided into pieces so that the functionality of the
end-item is developed and delivered in increments.
◼ Agile applies to development projects, especially software
where the functionality of the end-item system can be
achieved piecemeal through incremental development of
modules to the system
◼ Breaks the project into small (modularized) pieces.
◼ Emphasis on delivering the smallest “workable piece” of
functionality and business value early on, and continually
improving and adding functionality throughout the life of the
project.
Agile Project Management
◼
◼
Each workable piece is addressed one at a time, in a short
time frame (called a sprint). Each is completely developed,
tested, and delivered every 2-4 weeks.
❑ The piece adds a complete portion of functionality to the
end-item.
❑ The piece can be utilized by the customer, even if other
aspects of the end-item are not delivered or do not perform
as expected.
E.g. one “workable piece” of a word processor is spellchecker.
❑ The piece would be developed by itself. When completed,
it adds functionality to the word processor even if other
aspects of the word processor are incomplete.
❑ Before the spellchecker is completed, users can still work
with the word processor, but without the spellchecker.
Why Agile Project Management?
For certain kinds of projects, agile can
◼ Reduce development costs
◼ Improve software reliability
◼ Decrease time to development
◼ Reduce the number of errors developers make
◼ Eliminate the cost of a failed end-item system.
◼ Pieces of the system that have been developed will
work, even if other intended pieces of the system are not
yet in place.
◼ The customer receives workable results that can be put
into operation, even if the project is cancelled.
Agile Example: Agile-Scrum Process
Scrum—commonly used in software development
24-hr daily Scrum
Product
Backlog:
customer
compiles highlevel list of
product
features
Sprint Backlog:
Team/customer
select functionality
for the upcoming
sprint; team converts
features a sprint
backlog list of
specific tasks
Customer updates
product backlog
and team estimates
features
Adapted from: Integrating Agile Development in the Real World, Peter
Schuh; Charles River Media; 2004. ISBN-10: 1584503645
–a very good reference on the topic!
30-day Sprint
Iteration
Delivered
features
Teams in Project and System Definition
How do you keep everyone in the project focused on those
requirements?
How do you develop a project plan that will be able to account for those
requirements?
◼
A: make the system and project definition a team effort
❑
incorporate the perspectives of everyone with a stake in the
project
◼
customers, suppliers, functional areas such as engineering,
marketing, manufacturing, customer service, and purchasing, and
users and operators.
◼
The more these individuals and groups have a hand in defining
requirements and the plan, better the system requirements will
account for their needs throughout the systems life cycle
◼
Common team approaches in Definition are Concurrent
Engineering (chapter 15) and QFD.
Need: Reusable three-person space vehicle that can
be launched twice within two weeks
Deliverable: Burt Rutan’s SpaceshipOne, 2004
Space Ship One in Flight