Post on 08-Jul-2018
8/19/2019 spm notes 1-5%281%29
1/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
UNIT I
DEVELOPMENT LIFE CYCLE PROCESS
1.1 Overview of software develo!e"t life #$#le
There are various software development approaches defined and designed which are used/employed
during development process of software, these approaches are also referred as “Software Development
Process Models” (eg !aterfall model, incremental model, "#model, iterative model, etc$ %ach process
model follows a particular life cycle in order to ensure success in process of software development
Software life cycle models descri&e phases of the software cycle and the order in which those phases are
e'ecuted %ach phase produces delivera&les reuired &y the ne't phase in the life cycle )euirements
are translated into design *ode is produced according to the design which is called development phase
+fter coding and development the testing verifies the delivera&le of the implementation phase against
reuirementsThere are following si' phases in every Software development life cycle model
- )euirement gathering and analysis
. Design
0mplementation or coding
1 Testing
2 Deployment
3 Maintenance
1% Re&'ire!e"t (at)eri"( a"d a"al$sis* 4usiness reuirements are gathered in this phase This
phase is the main focus of the pro5ect managers and sta6e holders Meetings with managers, sta6e
holders and users are held in order to determine the reuirements li6e7 !ho is going to use the
system8 9ow will they use the system8 !hat data should &e input into the system8 !hat data should
&e output &y the system8 These are general uestions that get answered during a reuirements
gathering phase +fter reuirement gathering these reuirements are analy:ed for their validity and the
possi&ility of incorporating the reuirements in the system to &e development is also studied
;inally, a )euirement Specification document is created which serves the purpose of guideline for the
ne't phase of the model
+% Desi("* 0n this phase the system and software design is prepared from the reuirement specificationswhich were studied in the first phase System Design helps in specifying hardware and system
reuirements and also helps in defining overall system architecture The system design specifications
serve as input for the ne't phase of the model
,% I!le!e"tatio" - Codi"(*
8/19/2019 spm notes 1-5%281%29
2/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
% Testi"(* +fter the code is developed it is tested against the reuirements to ma6e sure that the
product is actually solving the needs addressed and gathered during the reuirements phase During this
phase unit testing, integration testing, system testing, acceptance testing are done
/% Delo$!e"t* +fter successful testing the product is delivered / deployed to the customer for their use
0% Mai"te"a"#e*
8/19/2019 spm notes 1-5%281%29
3/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
process num&er
program counter (P*$
stac6 pointer (SP$
general purpose register contents
floating point register contents
memory state
0/< state
scheduling information
accounting information
9ow can several processes share one *P>8
8/19/2019 spm notes 1-5%281%29
4/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
The goal of the PSP is to help developers produce :ero#defect, uality products on schedule @ow#defect
and :ero defect products have &ecome the reality for some developers and TSP teams, such as the
Motorola division in ;lorida that achieved :ero defects in over -C pro5ects through implementing PSP
techniues
PSP strucure
PSP training follows an evolutionary improvement approach an engineer learning to integrate the PSP
into his or her process &egins at the first level # PSP # and progresses in process maturity to the final
level # PSP.- %ach @evel has detailed scripts, chec6lists and templates to guide the engineer through
reuired steps and helps the engineer improve his own personal software process 9umphrey
encourages proficient engineers to customise these scripts and templates as they gain an understanding
of their own strengths and wea6nesses
Pro#ess
The input to PSP is the reuirements7 reuirements document is completed and delivered to the engineer
PSP23 PSP2.1 I"trod'#es ro#ess dis#ili"e a"d !eas're!e"t%
PSP has phases planning, development (design, coding, test$ and a post mortem + &aseline is
esta&lished of current process measuring time spent on programming, faults in5ected/removed, si:e of a
program 0n a post mortem, the engineer ensures all data for the pro5ects has &een properly recorded andanalysed PSP- advances the process &y adding a coding standard, a si:e measurement and the
development of a personal process improvement plan (P0P$ 0n the P0P, the engineer records ideas for
improving his own process
PSP13 PSP1.1 I"trod'#es esti!ati"( a"d la""i"(%
4ased upon the &aseline data collected in PSP and PSP-, the engineer estimates how large a new
program will &e and prepares a test report (PSP-$ +ccumulated data from previous pro5ects is used to
estimate the total time %ach new pro5ect will record the actual time spent This information is used for
tas6 and schedule planning and estimation (PSP--$
PSP+3 PSP+.1 I"trod'#es &'alit$ !a"a(e!e"t a"d desi("%
PSP. adds two new phases design review and code review Defect prevention and removal are the
focus at the PSP. %ngineers learn to evaluate and improve their process &y measuring how long tas6s
4
8/19/2019 spm notes 1-5%281%29
5/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
ta6e and the num&er of defects they in5ect and remove in each phase of development %ngineers
construct and use chec6lists for design and code reviews PSP.- introduces design specification and
analysis techniues
(PSP is a legacy level that has &een superseded &y TSP$
8/19/2019 spm notes 1-5%281%29
6/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
• productivity
• reuse percentage
• cost performance inde'
• planned value
• earned value
• predicted earned value
• defect density
• defect density &y phase
• defect removal rate &y phase
• defect removal leverage
• review rates
• process yield
• phase yield
• failure cost of uality (*
8/19/2019 spm notes 1-5%281%29
7/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
0n com&ination with the Personal Software Process (PSP$, the Tea! Software Pro#ess (TSP$ provides a
defined operational process framewor6 that is designed to help teams of managers and engineers
organi:e pro5ects and produce software products that range in si:e from small pro5ects of several
thousand lines of code (G@S Department of Defense was pu&lished in Jovem&er
. The &oo6 &y !atts 9umphrey,Introduction to the Team Software Process, presents a view the TSP
intended for use in academic settings, that focuses on the process of &uilding a software production team,
esta&lishing team goals, distri&uting team roles, and other teamwor6#related activities
9ow TSP !or6s
4efore engineers can participate in the TSP, it is reuired that they have already learned a&out the PSP,
so that the TSP can wor6 effectively Training is also reuired for other team mem&ers, the team lead, and
management
The TSP software development cycle &egins with a planning process called the launch, led &y a coach
who has &een specially trained, and is either certified or provisional The launch is designed to &egin the
team &uilding process, and during this time teams and managers esta&lish goals, define team roles,
assess ris6s, estimate effort, allocate tas6s, and produce a team plan During an e'ecution phase,
developers trac6 planned and actual effort, schedule, and defects, meeting regularly (usually wee6ly$ to
report status and revise plans + development cycle ends with a Post Mortem to assess performance,
revise planning parameters, and capture lessons learned for process improvement
The coach role focuses on supporting the team and the individuals on the team as the process e'pert
while &eing independent of direct pro5ect management responsi&ility The team leader role is different
from the coach role in that, team leaders are responsi&le to management for products and pro5ect
outcomes while the coach is responsi&le for developing individual and team performance
7
http://en.wikipedia.org/wiki/Personal_Software_Processhttp://en.wikipedia.org/wiki/Personal_Software_Process
8/19/2019 spm notes 1-5%281%29
8/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
-2 U"ifiedro#esses
The U"ified Software Develo!e"t Pro#ess or U"ified Pro#ess is a popular iterative and
incremental software development process framewor6 The &est#6nown and e'tensively documented
refinement of the >nified Process is the )ational >nified Process ()>P$ P or from )>P, and so the names tend to &e used interchangea&ly
The name Unified Process as opposed toRational Unified Process is generally used to descri&e the
generic process, including those elements which are common to most refinements The Unified
Process name is also used to avoid potential issues of trademar6 infringement since Rational Unified
Processand RUP are trademar6s of 04M The first &oo6 to descri&e the process was titled The Unified
Software Development Process (0S4J #.-#2K-3I#.$ and pu&lished in -III &y 0var Laco&son, rady
4ooch and Lames )um&augh Since then various authors unaffiliated with )ational Software have
pu&lished &oo6s and articles using the name Unified Process, whereas authors affiliated with )ational
Software have favored the name Rational Unified Process
>nified Process *haracteristics
8
http://en.wikipedia.org/wiki/Iterative_and_incremental_developmenthttp://en.wikipedia.org/wiki/Iterative_and_incremental_developmenthttp://en.wikipedia.org/wiki/Software_development_processhttp://en.wikipedia.org/wiki/Rational_Unified_Processhttp://en.wikipedia.org/wiki/OpenUPhttp://en.wikipedia.org/wiki/Agile_Unified_Processhttp://en.wikipedia.org/wiki/Rational_Unified_Processhttp://en.wikipedia.org/wiki/IBMhttp://en.wikipedia.org/wiki/Special:BookSources/0201571692http://en.wikipedia.org/wiki/Ivar_Jacobsonhttp://en.wikipedia.org/wiki/Grady_Boochhttp://en.wikipedia.org/wiki/Grady_Boochhttp://en.wikipedia.org/wiki/James_Rumbaughhttp://en.wikipedia.org/wiki/Rational_Softwarehttp://en.wikipedia.org/wiki/Rational_Softwarehttp://en.wikipedia.org/wiki/Rational_Softwarehttp://en.wikipedia.org/wiki/Iterative_and_incremental_developmenthttp://en.wikipedia.org/wiki/Iterative_and_incremental_developmenthttp://en.wikipedia.org/wiki/Software_development_processhttp://en.wikipedia.org/wiki/Rational_Unified_Processhttp://en.wikipedia.org/wiki/OpenUPhttp://en.wikipedia.org/wiki/Agile_Unified_Processhttp://en.wikipedia.org/wiki/Rational_Unified_Processhttp://en.wikipedia.org/wiki/IBMhttp://en.wikipedia.org/wiki/Special:BookSources/0201571692http://en.wikipedia.org/wiki/Ivar_Jacobsonhttp://en.wikipedia.org/wiki/Grady_Boochhttp://en.wikipedia.org/wiki/Grady_Boochhttp://en.wikipedia.org/wiki/James_Rumbaughhttp://en.wikipedia.org/wiki/Rational_Softwarehttp://en.wikipedia.org/wiki/Rational_Softwarehttp://en.wikipedia.org/wiki/Rational_Software
8/19/2019 spm notes 1-5%281%29
9/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
Iterative a"d I"#re!e"tal
Diagram illustrating how the relative emphasis of different disciplines changes over the course of the
pro5ectThe >nified Process is an iterative and incremental development process The %la&oration,
*onstruction and Transition phases are divided into a series of time&o'ed iterations (The 0nception phase
may also &e divided into iterations for a large pro5ect$ %ach iteration results in an increment , which is a
release of the system that contains added or improved functionality compared with the previous
release+lthough most iterations will include wor6 in most of the process disciplines (e.g.)euirements,
Design, 0mplementation, Testing$ the relative effort and emphasis will change over the course of the
pro5ect
Use Case Drive"
0n the >nified Process, use cases are used to capture the functional reuirements and to define the
contents of the iterations %ach iteration ta6es a set of use cases or scenarios from reuirements all the
way through implementation, test and deployment
4r#)ite#t're Ce"tri#
The >nified Process insists that architecture sit at the heart of the pro5ect teamHs efforts to shape the
system Since no single model is sufficient to cover all aspects of a system, the >nified Process supports
multiple architectural models and views
9
http://en.wikipedia.org/wiki/Iterative_and_incremental_developmenthttp://en.wikipedia.org/wiki/Use_casehttp://en.wikipedia.org/wiki/Scenario_(computing)http://en.wikipedia.org/wiki/Iterative_and_incremental_developmenthttp://en.wikipedia.org/wiki/Use_casehttp://en.wikipedia.org/wiki/Scenario_(computing)
8/19/2019 spm notes 1-5%281%29
10/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
nified Process reuires the pro5ect team to focus on addressing the most critical ris6s early in the
pro5ect life cycle The delivera&les of each iteration, especially in the %la&oration phase, must &e selected
in order to ensure that the greatest ris6s are addressed first
Pro5ect @ifecycle
The >nified Process divides the pro5ect into four phases
• 0nception
• %la&oration
• *onstruction
• Transition
I"#etio" P)ase
0nception is the smallest phase in the pro5ect, and ideally it should &e uite short 0f the 0nception Phase is
long then it may &e an indication of e'cessive up#front specification, which is contrary to the spirit of the
>nified Process
The following are typical goals for the 0nception phase
• %sta&lish a 5ustification or &usiness case for the pro5ect
•
%sta&lish the pro5ect scope and &oundary conditions•
8/19/2019 spm notes 1-5%281%29
11/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
Develop an appro'imate vision of the system, ma6e the &usiness case, define the scope, and produce
rough estimate for cost and schedule
Ela6oratio" P)ase
During the %la&oration phase the pro5ect team is e'pected to capture a healthy ma5ority of the system
reuirements 9owever, the primary goals of %la&oration are to address 6nown ris6 factors and to
esta&lish and validate the system architecture *ommon processes underta6en in this phase include the
creation of use case diagrams, conceptual diagrams (class diagrams with only &asic notation$
and pac6age diagrams (architectural diagrams$
The architecture is validated primarily through the implementation of an %'ecuta&le +rchitecture 4aseline
This is a partial implementation of the system which includes the core, most architecturally significant,
components 0t is &uilt in a series of small, time &o'ed iterations 4y the end of the %la&oration phase the
system architecture must have sta&ili:ed and the e'ecuta&le architecture &aseline must demonstrate that
the architecture will support the 6ey system functionality and e'hi&it the right &ehavior in terms of
performance, scala&ility and cost
The final %la&oration phase delivera&le is a plan (including cost and schedule estimates$ for the
*onstruction phase +t this point the plan should &e accurate and credi&le, since it should &e &ased on
the %la&oration phase e'perience and since significant ris6 factors should have &een addressed during
the %la&oration phase
Co"str'#tio" P)ase
*onstruction is the largest phase in the pro5ect 0n this phase the remainder of the system is &uilt on the
foundation laid in %la&oration System features are implemented in a series of short, time&o'ed iterations
%ach iteration results in an e'ecuta&le release of the software 0t is customary to write full te't use cases
during the construction phase and each one &ecomes the start of a new iteration *ommon >M@ (>nified
Modelling @anguage$ diagrams used during this phase include +ctivity, Seuence, *olla&oration, State
(Transition$ and 0nteraction
11
http://en.wikipedia.org/wiki/Use_case_diagramhttp://en.wikipedia.org/wiki/Class_diagramhttp://en.wikipedia.org/wiki/Package_diagramhttp://en.wikipedia.org/w/index.php?title=Executable_Architecture_Baseline&action=edit&redlink=1http://en.wikipedia.org/wiki/Use_case_diagramhttp://en.wikipedia.org/wiki/Class_diagramhttp://en.wikipedia.org/wiki/Package_diagramhttp://en.wikipedia.org/w/index.php?title=Executable_Architecture_Baseline&action=edit&redlink=1
8/19/2019 spm notes 1-5%281%29
12/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
Tra"sitio" P)ase
The final pro5ect phase is Transition 0n this phase the system is deployed to the target users ;eed&ac6
received from an initial release (or initial releases$ may result in further refinements to &e incorporated
over the course of several Transition phase iterations The Transition phase also includes system
conversions and user training
)efinements and "ariations
)efinements of the >nified Process vary from each other in how they categori:e the
pro5ect disciplines or workflows The)ational >nified Process defines nine disciplines 4usinessModeling, )euirements, +nalysis and Design, 0mplementation,Test, Deployment, *onfiguration and
*hange Management, Pro5ect Management, and %nvironment The %nterprise >nified Process e'tends
)>P through the addition of eight AenterpriseA disciplines +gile refinements of >P such
as P/4asicand the +gile >nified Process simplify )>P &y reducing the num&er of disciplines
)efinements also vary in the emphasis placed on different pro5ect artifacts +gile refinements streamline
)>P &y simplifying wor6flows and reducing the num&er of e'pected artifacts
)efinements also vary in their specification of what happens after the Transition phase 0n the )ational>nified Process the Transition phase is typically followed &y a new 0nception phase 0n the %nterprise
>nified Process the Transition phase is followed &y a Production phase
The num&er of >nified Process refinements and variations is countless nified
Process invaria&ly incorporate their own modifications and e'tensions The following is a list of some of
the &etter 6nown refinements and variations
• +gile >nified Process (+>P$, a lightweight variation developed &y Scott ! +m&ler
• 4asic >nified Process (4>P$, a lightweight variation developed &y 04M and a precursor
to P
• %nterprise >nified Process (%>P$, an e'tension of the )ational >nified Process
• %ssential >nified Process (%ss>P$, a lightweight variation developed &y 0var Laco&son
• nified Process (P$, the %clipse Process ;ramewor6 software development process
• )ational >nified Process ()>P$, the 04M / )ational Software development process
12
http://en.wikipedia.org/wiki/Workflowshttp://en.wikipedia.org/wiki/Workflowshttp://en.wikipedia.org/wiki/Workflowshttp://en.wikipedia.org/wiki/Rational_Unified_Processhttp://en.wikipedia.org/wiki/Business_process_modelinghttp://en.wikipedia.org/wiki/Business_process_modelinghttp://en.wikipedia.org/wiki/Requirementhttp://en.wikipedia.org/wiki/Object-oriented_analysis_and_designhttp://en.wikipedia.org/wiki/Implementationhttp://en.wikipedia.org/wiki/Test_(assessment)http://en.wikipedia.org/wiki/Software_deploymenthttp://en.wikipedia.org/w/index.php?title=Configuration_and_Change_Management&action=edit&redlink=1http://en.wikipedia.org/w/index.php?title=Configuration_and_Change_Management&action=edit&redlink=1http://en.wikipedia.org/wiki/Project_Managementhttp://en.wikipedia.org/wiki/Environment_disciplinehttp://en.wikipedia.org/wiki/Enterprise_Unified_Processhttp://en.wikipedia.org/wiki/OpenUP/Basichttp://en.wikipedia.org/wiki/Agile_Unified_Processhttp://en.wikipedia.org/wiki/Artifact_(software_development)http://en.wikipedia.org/wiki/Enterprise_Unified_Processhttp://en.wikipedia.org/wiki/Enterprise_Unified_Processhttp://en.wikipedia.org/wiki/Agile_Unified_Processhttp://en.wikipedia.org/wiki/Scott_W._Amblerhttp://en.wikipedia.org/wiki/Basic_Unified_Processhttp://en.wikipedia.org/wiki/IBMhttp://en.wikipedia.org/wiki/OpenUPhttp://en.wikipedia.org/wiki/Enterprise_Unified_Processhttp://en.wikipedia.org/wiki/Essential_Unified_Processhttp://en.wikipedia.org/wiki/Ivar_Jacobsonhttp://en.wikipedia.org/wiki/Open_Unified_Processhttp://en.wikipedia.org/wiki/Rational_Unified_Processhttp://en.wikipedia.org/wiki/IBMhttp://en.wikipedia.org/wiki/Rational_Softwarehttp://en.wikipedia.org/wiki/Workflowshttp://en.wikipedia.org/wiki/Rational_Unified_Processhttp://en.wikipedia.org/wiki/Business_process_modelinghttp://en.wikipedia.org/wiki/Business_process_modelinghttp://en.wikipedia.org/wiki/Requirementhttp://en.wikipedia.org/wiki/Object-oriented_analysis_and_designhttp://en.wikipedia.org/wiki/Implementationhttp://en.wikipedia.org/wiki/Test_(assessment)http://en.wikipedia.org/wiki/Software_deploymenthttp://en.wikipedia.org/w/index.php?title=Configuration_and_Change_Management&action=edit&redlink=1http://en.wikipedia.org/w/index.php?title=Configuration_and_Change_Management&action=edit&redlink=1http://en.wikipedia.org/wiki/Project_Managementhttp://en.wikipedia.org/wiki/Environment_disciplinehttp://en.wikipedia.org/wiki/Enterprise_Unified_Processhttp://en.wikipedia.org/wiki/OpenUP/Basichttp://en.wikipedia.org/wiki/Agile_Unified_Processhttp://en.wikipedia.org/wiki/Artifact_(software_development)http://en.wikipedia.org/wiki/Enterprise_Unified_Processhttp://en.wikipedia.org/wiki/Enterprise_Unified_Processhttp://en.wikipedia.org/wiki/Agile_Unified_Processhttp://en.wikipedia.org/wiki/Scott_W._Amblerhttp://en.wikipedia.org/wiki/Basic_Unified_Processhttp://en.wikipedia.org/wiki/IBMhttp://en.wikipedia.org/wiki/OpenUPhttp://en.wikipedia.org/wiki/Enterprise_Unified_Processhttp://en.wikipedia.org/wiki/Essential_Unified_Processhttp://en.wikipedia.org/wiki/Ivar_Jacobsonhttp://en.wikipedia.org/wiki/Open_Unified_Processhttp://en.wikipedia.org/wiki/Rational_Unified_Processhttp://en.wikipedia.org/wiki/IBMhttp://en.wikipedia.org/wiki/Rational_Software
8/19/2019 spm notes 1-5%281%29
13/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
• nified Method (M$, the nified Process#System %ngineering ()>P#S%$, a version of )>P tailored &y )ational
Software for System %ngineering
1.0 4(ile Pro#esses
0n software development life cycle, there are two main considerations, one is to emphasi:e on
process and the other is the uality of the software and process itself +gile software processes is an
iterative and incremental &ased development, where reuirements are changea&le according to
customer needs 0t helps in adaptive planning, iterative development and time &o'ing 0t is a
theoretical framewor6 that promotes foreseen interactions throughout the development cycle There
are several SD@* models li6e spiral, waterfall, )+D which has their own advantages SD@* is a
framewor6 that descri&es the activities performed at each stage of a software development life
cycleThe software development activities such as planning, analysis, design, coding, testing andmaintenance which need to &e performed according to the demand of the customer 0t depends on
the various applications to choose the specific model 0n this paper, however, we will study the agile
processes and its methodologies +gile process is itself a software development process+gile
process is an iterative approach in which customer satisfaction is at highest priority as the customer
has direct involvement in evaluating the software
The agile process follows the software development life cycle which includes reuirements gathering,
analysis, design , coding , testing and delivers partially implemented software and waits for the
customer feed&ac6 0n the whole process , customer satisfaction is at highest priority with faster
development time
C)ara#teristi#s of a(ile ro7e#ts
+gile process reuires less planning and it divides the tas6s into small increments +gile process is
meant for short term pro5ects with an effort of team wor6 that follows the software development life
cycle Software development life cycle includes the following phases 1.Re&'ire!e"ts (at)eri"(3
+.4"al$sis3 ,.Desi("3 .Codi"( 3 /.Testi"(3 0.Mai"te"a"#e The involvement of software team
management with customers reduces the ris6s associated with the software This agile process is an
iterative process in which changes can &e made according to the customer satisfaction 0n agileprocess new features can &e added easily &y using multiple iterations
1. Iterative
The main o&5ective of agile software processes is satisfaction of customers, so it focuses on single
reuirement with multiple iterations
+. Mod'larit$
13
http://en.wikipedia.org/wiki/Oracle_Unified_Methodhttp://en.wikipedia.org/wiki/Oracle_Corporationhttp://en.wikipedia.org/wiki/Rational_Softwarehttp://en.wikipedia.org/wiki/Rational_Softwarehttp://en.wikipedia.org/wiki/System_Engineeringhttp://en.wikipedia.org/wiki/Oracle_Unified_Methodhttp://en.wikipedia.org/wiki/Oracle_Corporationhttp://en.wikipedia.org/wiki/Rational_Softwarehttp://en.wikipedia.org/wiki/Rational_Softwarehttp://en.wikipedia.org/wiki/System_Engineering
8/19/2019 spm notes 1-5%281%29
14/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
+gile process decomposes the complete system into managea&le pieces called modules Modularity
plays a ma5or role in software development processes
,. Ti!e 8o9i"(
+s agile process is iterative in nature, it reuires the time limits on each module with respective cycle
. Parsi!o"$
0n agile processes parsimony is reuired to mitigate ris6s and achieve the goals &y minimal num&er of
modules
/. I"#re!e"tal
+s the agile process is iterative in nature, it reuires the system to &e developed in increments, each
increment is independent of others, and at last all increments are integrated into complete system
0. 4dative
Due to the iterative nature of agile process new ris6s may occurs The adaptive characteristic of agile
process allows adapting the processes to attac6 the new ris6s and allows changes in the real timereuirements
:. Co"ver(e"t
+ll the ris6s associated with each increment are convergent in agile process &y using iterative and
incremental approach
;. Colla6orative
+s agile process is modular in nature, it needs a good communication among software development
teamDifferent modules need to &e integrated at the end of the software development process
8/19/2019 spm notes 1-5%281%29
15/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
,% Least do#'!e"tatio" The documentation in agile methodology is short and to the point though it
depends on the agile team enerally they don=t ma6e documentation on internal design of the
software The main things which should &e on the documentation are product features list, duration
for each iteration and date This &rief documentation saves time of development and deliver the
pro5ect in least possi&le time
% Red'#es ris5s of develo!e"t +s the incremented mini software is delivered to the customers
after every short development cycle and feed&ac6s are ta6en from the customers, it warns
developers a&out the upcoming pro&lems which may occur at the later stages of development 0t also
helps to discover errors uic6ly and they are fi'ed immediately
DIS4DV4NT4=ES
-$ *ustomer interaction is the 6ey factor of developing successful software +gile methodology is&ased on customer involvement &ecause the entire pro5ect is developed according to the
reuirements given &y the customers So if the customer representative is not clear a&out the product
features, the development process will go out of the trac6
.$ @ac6 of documentation Though the least documentation saves development time as an advantage
of agile method, on the other hand it is a &ig disadvantage for developer 9ere the internal design is
getting changed again and again depending on user reuirements after every iteration, so it is not
possi&le to maintain the detail documentation of design and implementation &ecause of pro5ect
deadline So &ecause of less availa&le information, it is very difficult for the new developers who 5oin
the development team at the later stage to understand the actual method followed to develop the
software
$ Time consuming and wastage of resources &ecause of constant change of reuirements 0f the
customers are not satisfied &y the partial software developed &y certain iteration and they change
their reuirements then that incremented part is of no use So it is the total wastage of time, effort and
resources reuired to develop that increment
1$ More helpful for management than developer The agile methodology helps management to ta6e
decisions a&out the software development, set goals for developers and fi' the deadline for them 4ut
it is very difficult for the &aseline developers to cope up with the ever changing environment and every
time changing the design, code &ased on 5ust in time reuirements
15
8/19/2019 spm notes 1-5%281%29
16/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
COMP4RISON OF 4=ILE PROCESS >IT? OT?ER SDLC MODELS
T48LE I. PRCOESS MODELS
Differe"t Pro#ess Models
Feat'res 4(ile Pro#ess Siral Model R4D Model
Defi"itio" 4(ile ro#ess is t)e
a6ilit$ to 6ot) #reate
a"d reso"d
to#)a"(i"(
re&'ire!e"ts of
software.
Siral !odel is t)e
software develo!e"t
!odel w)i#) fo#'ses
o" !a"a(i"( ris5s.
R4D !odel is @)i()
seed adatatio" of
li"ear se&'e"tial
!odel3 i" w)i#)
#o!o"e"t 6ased
#o"str'#tio" is 'sed.
4data6ilit$ $ $ "Testi"( P)ase U"it3 I"te(ratio" 3
S$ste! testi"(
U"it3 I"te(ratio" a"d
S$ste! testi"(
U"it
A'alit$ Fa#tors $ $ "
Ris5 4"al$sis " $ "
OffBt)eB Tools " " $
Fail're "or!all$ d'e to Code Code 4r#)ite#t're a"d
desi("
"owled(e Re&'ired Prod'#t a"d do!ai" Prod'#t a"d do!ai" Do!ai"
E"tr$ e9it Criteria " " $
Mo#5 ' $ $ "
E9te"da6ilit$ $ $ "
Pro7e#t
!a"a(e!e"t
i"volve!e"t
$ " $
?i()er Relia6ilit$ $ $ "
Ti!e 8o9i"( $ " $
16
8/19/2019 spm notes 1-5%281%29
17/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
1.: C)oosi"( t)e ri()t ro#ess
Software process consists of four fundamental activities
-Software specification where engineers or/and customers define what the product should do and how
should it operate
. Software development is designing and actual coding
Software validation is generally testing 0t is important to chec6 if the system is designed and
implemented correctly
1 Software evolution is modifying the system according to new needs of customer (s$
Different types of software need different development process
Software process model is a simplified description of a software process that presents one view of a
process +nd again, choice of a view depends on the system developing, sometimes it is useful to apply awor6flow model, sometimes, for e'ample E a role/action model
Most software process models are &ased on one of three general models or paradigms of software
development
- The waterfall approach 0n this case the development process and all activities are divided into
phases such as reuirement specification, software design, implementation, testing etc Development
goes phase#&y#phase
. 0terative development +n initial system is rapidly developed from very a&stract specifications
8/19/2019 spm notes 1-5%281%29
18/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
The process of ris6 analysis consists of four steps
- Ris5 ide"tifi#atio" Potential ris6s that might arise are identified These are dependent on the
environment in which the system is to &e used 0n safety#critical systems, the principal ris6s are ha:ards
that can lead to an accident %'perienced engineers, wor6ing with domain e'perts and professional safety
advisors, should identify system ris6s roup wor6ing techniues such as &rainstorming may &e used to
identify ris6s
. Ris5 a"al$sis a"d #lassifi#atio" The ris6s are considered separately Those that are potentially
serious and not implausi&le are selected for further analysis )is6s can &e categorised in three ways
a I"tolera6le The system must &e designed in such a way so that either the ris6 cannot arise or, if it
does arise, it will not result in an accident 0ntolera&le ris6s are those that threaten human life or the
financial sta&ility of a &usiness and which have a significant pro&a&ility of occurrence
& +s low as reasona&ly practical (4L4RP$ The system must &e designed so that the pro&a&ility of an
accident arising &ecause of the ha:ard is minimised, su&5ect to other considerations such as cost anddelivery +@+)P ris6s are those which have less serious conseuences or which have a low pro&a&ility of
occurrence
c 4##eta6le !hile the system designers should ta6e all possi&le steps to reduce the pro&a&ility of an
Naccepta&le= ha:ard arising, these should not increase costs, delivery time or other non#functional system
attri&utes
Ris5 de#o!ositio" %ach ris6 is analysed individually to discover potential root causes of that ris6
Different techniues for ris6 decomposition e'ist The one discussed in the &oo6 is ;ault#tree analysis,
where analyst puts ha:ard at the top and place different states which can lead to that ha:ard a&ove
States can &e lin6ed with Nor= and Nand= sym&ols )is6s that reuire a com&ination of root causes are
usually less pro&a&le than ris6s that can result from a single root cause
1 Ris5 red'#tio" assess!e"t Proposals for ways in which the identified ris6s may &e reduced or
eliminated are made Three possi&le strategies of ris6 deduction that can &e used are
a Ris5 avoida"#e Designing the system in such a way that ris6 or ha:ard cannot arise
& Ris5 dete#tio" a"d re!oval Designing the system in such a way that ris6s are detected and
neutralised &efore they result in an accident
c Da!a(e li!itatio" Designing the system in such a way that the conseuences of an accident are
minimised0n the -ICs and -IIs, as computer control &ecome widespread, the safety engineering community
developed standards for safety critical systems specification and development The process of safety
specification and assurance is part of an overall safety life cycle that is defined in an international
standard for safety management 0%* 3-2C (0%*, -IIC$
Security and safety reuirements have something in common7 however, there are some differences
&etween these types of reuirements
18
8/19/2019 spm notes 1-5%281%29
19/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
UNIT II
REAUIREMENT M4N4=EMENT
+.1 F'"#tio"al re&'ire!e"ts a"d A'alit$ attri6'tes
Fuality attri&utes, such as response time, accuracy,security, relia&ility, are properties that affect the
systemas a whole Most approaches deal with uality attri&utes separately from the functional
reuirements of a systemThis means that the integration is difficult to achieve and usually is
accomplished only at the later stages of thesoftware development process ;urthermore, current
approaches fail in dealing with the crosscutting nature ofsome of those attri&utes, ie it is difficult to
represent clearly how these attri&utes can affect severalreuirements simultaneously Since this
integration is not supported from reuirements to the implementation,some of the software engineering
principles, such as a&straction, locali:ation, modularisation, uniformity andreusa&ility, can &e
compromised !hat we propose is a model to identify and specify uality attri&utes that crosscut
reuirements including their systematic integration into the functional description at an early stage of the
software development process, ie at reuirements
4 !odel for earl$ &'alit$ attri6'tes
The process model we propose is >M@ compliant and is composed of three main activities identification,
specification and integration of reuirements The first activity consists of identifying all the reuirements
of asystem and select from those the uality attri&utes relevant to the application domain and
sta6eholders Thesecond activity is divided into two main parts (-$specifying functional reuirements
using a use case &ased approach7 (.$ descri&e uality attri&utes using special templates and identify
19
8/19/2019 spm notes 1-5%281%29
20/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
those that cut across (ie crosscutting$ functional reuirements The third activity proposes a set of
models to represent the integration of crosscutting uality attri&utes and functional reuirements ;igure -
depicts this model
20
8/19/2019 spm notes 1-5%281%29
21/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
To identify the crosscutting nature of some of the uality attri&utes we need to ta6e into account the
informationcontained in rows !here and )euirements 0f a uality attri&ute cuts across (ie is reuired
&y$ several reuirements and models, then it is crosscutting
The integration is accomplished &y “weaving” the uality attri&utes with the functional reuirements in
three different ways
(-$ Overla the uality attri&ute adds new &ehaviour to the functional reuirements it transverses 0n this
case, the uality attri&ute may &e reuired before those reuirements, or, it may &e reuired after them
(.$ Override the uality attri&ute superposes the functional reuirements it transverses 0n this case, its
&ehaviour su&stitutes the functional reuirements &ehavior
($ >ra the uality attri&ute “encapsulates” the reuirements it transverses 0n this case the &ehaviour
of the reuirements is wrapped &y the &ehaviour of the uality attri&ute !e weave uality attri&utes with
functionalreuirements &y using &oth standard diagrammatic representations (eg use case diagram,interaction diagrams$ and &y new diagrams
Ide"tif$ re&'ire!e"ts
)euirements of a system can &e classified into functional and non#functional (ie uality attri&utes$
;unctional reuirements are statements of services the system should provide, how the system should
react to particular inputs and how the system should &ehave in particular situations Different types of
methods are used to specify functional reuirements >se case driven approaches descri&e “the ways in
which a user uses a system” that is why use case diagram is often used for capturing functional
reuirements Fuality attri&utes define glo&al properties of a system >sually these are only dealt with in
the later stages of a software development process, such as design andimplementation
Ide"tif$ a#tors a"d 'se #ases.
;or the road pricing system, the actors we identified are
"ehicle owner is responsi&le for registering a vehicle7
• "ehicle driver comprehends the vehicle, the driver and the gi:mo installed on it7
• 4an6 represents the entity that holds the vehicle owner=s account7
•
System cloc6 represents the internal cloc6 of the system that monthly triggers the calculation of de&its
The following are the use cases reuired &y the actorslisted a&ove
• )egister vehicle is responsi&le for registering a vehicle and its owner, and communicate with the
&an6 to guarantee a good account7
• Pass single toll is responsi&le for dealing with tolls where vehicles pay a fi'ed amount 0t reads
thevehicle gi:mo and chec6s on whether it is a good one 0f the gi:mo is o6 the light is turned
21
8/19/2019 spm notes 1-5%281%29
22/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
green, andthe amount to &e paid is calculated and displayed 0f the gi:mo is not o6, the light is
turned yellow and aphoto is ta6en
• %nter motorway chec6s the gi:mo, turns on the light and registers an entrance 0f the gi:mo is
invalid a photo is ta6en and registered in the system
• %'it motorway chec6s the gi:mo and if the vehicle has an entrance, turns on the light
accordingly, calculates the amount to &e paid (as a function of the distance travelled$, displays it
and records this passage 0f the gi:mo is not o6, or if the vehicle did not enter in a green lane, the
light is turned yellow and a photo is ta6en
• Pay &ill sums up all passages for each vehicle, issues a de&it to &e sent to the &an6 and a copy
to the vehicle owner
Ide"tif$ &'alit$ attri6'tes.
Fuality attri&utes can &e assumptions, constraints or goals of sta6eholders 4y analysing the initial of set
reuirements, the potential uality attri&utes are identified ;or e'ample, if the owner of a vehicle has toindicate, during registration, his/her &an6 details so that automatic transfers can &e performed
automatically, then security is an issue that the system needs to address +nother fundamental uality
attri&ute is response time that is a issue when a vehicle passes a toll gate, or when a customer activates
his/her own gi:mo in an +TM the toll gate components have to react in time so that the driver can see the
light and the amount &eing displayed M@ models, such as use cases, seuence and class
diagrams The uality attri&utes are descri&ed in templates of the form presented in ;igure .
8'ild t)e 'se #ase dia(ra!.
The set of all use cases can &e represented in a use case diagram, where we can see the e'isting
relationships&etween use cases and the ones &etween use cases and actors ;igure shows the use
case diagram of the roadtraffic system
22
8/19/2019 spm notes 1-5%281%29
23/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
I"te(rate f'"#tio"al re&'ire!e"ts wit)#ross#'tti"( &'alit$ attri6'tes
0ntegration composes the uality attri&utes with the functional reuirements, to o&tain the whole system
!e use >M@ diagrams to show the integration The two e'amples given a&ove (for response time and
security$ fall into two of the categories already descri&ed overlap and wrapper !e could e'tend the >M@
diagrams to represent some uality attri&utes ;or e'ample, the seuence diagram shown in ;igure 1 can
&e e'tended to show how response time affects a scenario
+.+ Eli#itatio" te#)"i&'es
+ ma5or goal of )euirements %licitation is to avoid the confusions &etween sta6eholders and analysts
This will often involve putting significant sort into reuirements elicitation >nfortunately, )euirements
23
8/19/2019 spm notes 1-5%281%29
24/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
%ngineering is an immature discipline, perhaps not entirely unfairly characteri:ed as a &attlefield occupied
&y competing commercial methods, firing competing claims at each other, and leaving the consumers
weary and confused
The goal of this paper is to analy:e and compare of the different methods of the reuirements elicitation
process, which will &e useful to compare the different characteristics and the performance of the different
elicitation methods 9ence, all the reuirement elicitation techniues are very handy for e'tracting the
reuirements and different organi:ations, which can use different reuirement elicitation techniues
according to organi:ational culture and needs
+s reuirements elicitation is a process in which intensive interaction &etween sta6eholders and the
analysts, so for finding the interaction &etween sta6eholders and analysts will &e easy for improving the
uality of e'tracted reuirements 0t is important to distinguish different elicitation methods according tothe four methods of communication
- *onversational
. nderstanding
the method category helps engineers understand different elicitation methods and guides them to select
appropriate method for reuirements elicitation
Fo'r Met)ods of Co!!'"i#atio"
i. Conversational Methods
The conversational method provides a means of ver&al communication &etween sta6eholders and
+nalysts +s conversation is a natural way of communication and an effective mean of e'pressing needs
and ideas, and the conversational methods are used massively to understand the pro&lems and to elicit
generic product reuirements The *onversational Methods are also 6nown as ver&al methods, such as
0nterviews, Fuestionnaire, and 4rainstorming
a.I"terviews: + typical conversational method is interviews 0t is most commonly used method inreuirements elicitation +n 0nterview is generally conducted &y an e'perienced analyst, who has some
generic 6nowledge a&out the application domain as well 0n an interview, +nalyst discusses the desired
product with different sta6eholders and develops an understanding of their reuirements enerally
0nterviews are divided in two groups
- *losed 0nterview 0n this interview the reuirements, we have to prepare some predefined uestions
and try to get the answers for these uestions for the sta6eholder
24
8/19/2019 spm notes 1-5%281%29
25/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
.
8/19/2019 spm notes 1-5%281%29
26/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
Proto#ol a"al$sis 0n protocol analysis a sta6eholder is o&served when he is engaged in some tas6, and
concurrently spea6s out loud and e'plains his thought !ith the protocol analysis it is easy to identify
0nteraction pro&lems in e'isting systems and it gives &etter and closer understanding of !or6 conte't and
wor6 flow
;or
8/19/2019 spm notes 1-5%281%29
27/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
Do#'!e"tatio" st'dies: 0n this techniue different availa&le documents (eg
8/19/2019 spm notes 1-5%281%29
28/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
S#e"arios3 assive stor$6oards: 0t is an interaction session 0n this session a seuence of actions and
events descri&ed for e'ecuting some generic tas6 which the system is intended to accomplish !ith the
help of this techniue, clear reuirement related to procedure and data flow can &e achieved !ith this
techniue initial set of reuirement can &e prepared in lesser cost
Protot$i"(3 I"tera#tive stor$6oards: 0n this techniue, a concrete &ut partial system is discussed with
sta6eholders This concrete &ut partial system is e'pected to &e delivered at the end of pro5ect The
purpose of showing this system to sta6eholders is to elicit and validate functional reuirement The p
4D-R4D sessio": 0t stands for Loint +pplication Development/)apid +pplication Development and
emphasi:es user involvement through group sessions with un&iased facilitator L+D is conducted in the
same manner as &rainstorming, e'cept that the sta6eholders and the users are also allowed to participate
and discuss on the design of the proposed system The discussion with the sta6eholders and the userscontinues until the final reuirements are gathered
Co"te9t'al i"&'ir$* this techniue is a com&ination of open#ended interview, wor6place o&servation, and
prototyping This method used for interactive systems design where user interface design is critical
+ll four reuirement elicitation methods are commonly used &ut the selection of reuirement elicitation
method entirely depends on the needs and organi:ational structure Jo matter what development pro5ect
is, reuirements development nearly always ta6es place in the conte't of a human activity system, and
pro&lem owners are people 0t is essential for reuirements engineers to study how people perceive,
understand, and e'press the pro&lem domain, how they interact with the desired product, and how the
physical and cultural environments affect their actions
The conversational methods provide a direct contact channel &etween engineers and sta6eholders, and
the reuirements are mainly no tacit The o&servational methods provide an indirect channel &y o&serving
user=s interaction with his wor6 setting and conte't, and the reuirements fall into tacit 6nowledge The
analytic methods form one complementary indirect contact channel to e'tract reuirements proactively
The synthetic methods focus more on collective effort on clarifying the features of desired products, and
the communication channel is therefore a mi' of direct contact and indirect contact %ach type of techniues has trade#offs 0n reality, of course, the &oundary &etween different types of method is &lurred
4dva"ta(e a"d Disadva"ta(e of Re&'ire!e"t Eli#itatio"
+fter the discussion the different of the four group of reuirement elicitation method 0n order to
understand the each )euirement elicitation Methods and effective use them in the real case ,we have to
28
8/19/2019 spm notes 1-5%281%29
29/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
focus on the advantages and disadvantages of different reuirement elicitation methods *onversational,
8/19/2019 spm notes 1-5%281%29
30/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
$ *onversational or
8/19/2019 spm notes 1-5%281%29
31/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
4oth the system and software architectures are 6ey to reali:ing uality attri&ute reuirementsin the
implementation +lthough an architecture cannot guarantee that an implementation willmeet its uality
attri&ute goals, the wrong architecture will surely spell disaster +s an e'ample,consider security 0t is
difficult, may&e even impossi&le, to add effective security to a systemas an afterthought *omponents as
well as communication mechanisms and paths must &edesigned or selected early in the life cycle to
satisfy security reuirements The critical ualityattri&utes must &e well understood and articulated early in
the development of a system, so thearchitect can design an architecture that will satisfy them The F+!
is one way to discover,document, and prioriti:e a system=s uality attri&utes early in its life cycle
0t is important to point out that we do not aim at an a&solute measure of uality7 rather our purposeis to
identify scenarios from the point of view of a diverse group of sta6eholders (eg,architects, developers,
users, sponsors$ These scenarios can then &e used &y the system engineersto analy:e the system=s
architecture and identify concerns (eg, inadeuate performance,successful denial#of#service attac6s$
and possi&le mitigation strategies (eg, prototyping,modeling, simulation$
A4> Met)od
The F+! is a facilitated, early intervention method used to generate, prioriti:e, and refineuality attri&ute
scenarios &efore the software architecture is completed The F+! is focusedon system#level concerns
and specifically the role that software will play in the system TheF+! is dependent on the participation of
system sta6eholders?individuals on whom the systemhas significant impact, such as end users,
installers, administrators (of data&ase managementsystems BD4MSO, networ6s, help des6s, etc$, trainers,
architects, acuirers, system andsoftware engineers, and others The group of sta6eholders present
during any one F+! shouldnum&er at least 2 and no more than for a single wor6shop 0n preparation
31
8/19/2019 spm notes 1-5%281%29
32/168
8/19/2019 spm notes 1-5%281%29
33/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
representing the &usiness and/or mission concerns (typicallya manager or management representative$
spends a&out one hour presenting
the system=s &usiness/mission conte't
high#level functional reuirements, constraints, and uality attri&ute reuirements
During the presentation, the facilitators listen carefully and capture any relevant informationthat may shed
light on the uality attri&ute drivers The uality attri&utes that will &e refined inlater steps will &e derived
largely from the &usiness/mission needs presented in this step
Ste ,* 4r#)ite#t'ral Pla" Prese"tatio"
!hile a detailed system architecture might not e'ist, it is possi&le that high#level systemdescriptions,
conte't drawings, or other artifacts have &een created that descri&e some of thesystem=s technical
details +t this point in the wor6shop, a technical sta6eholder will presentthe system architectural plans as
they stand with respect to these early documents 0nformationin this presentation may include plans and strategies for how 6ey &usiness/mission reuirements will &e satisfied
6ey technical reuirements and constraints?such as mandated operating systems, hardware,
middleware, and standards?that will drive architectural decisions
presentation of e'isting conte't diagrams, high#level system diagrams, and other writtendescriptions
Ste * Ide"tifi#atio" of 4r#)ite#t'ral Drivers
During steps . and , the facilitators capture information regarding architectural drivers thatare 6ey to
reali:ing uality attri&ute goals in the system These drivers often include high#levelreuirements,
&usiness/mission concerns, goals and o&5ectives, and various uality attri&utes4efore underta6ing this
step, the facilitators should e'cuse the group for a -2#minute &rea6,during which they will caucus to
compare and consolidate notes ta6en during steps . and
!hen the sta6eholders reconvene, the facilitators will share their list of 6ey architectural driversand as6
the sta6eholders for clarifications, additions, deletions, and corrections The idea isto reach a consensus
on a distilled list of architectural drivers that include high#level reuirements,&usiness drivers, constraints,
and uality attri&utes The final list of architectural driverswill help focus the sta6eholders during scenario
&rainstorming to ensure that theseconcerns are represented &y the scenarios collected
Ste /* S#e"ario 8rai"stor!i"(
+fter the architectural drivers have &een identified, the facilitators initiate the &rainstormingprocess in
which sta6eholders generate scenarios The facilitators review the parts of a goodscenario (stimulus,
environment, and response$ and ensure that each scenario is well formedduring the wor6shop
33
8/19/2019 spm notes 1-5%281%29
34/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
%ach sta6eholder e'presses a scenario representing his or her concerns with respect to the systemin
round#ro&in fashion During a nominal F+!, at least two round#ro&in passes are madeso that each
sta6eholder can contri&ute at least two scenarios The facilitators ensure that atleast one representative
scenario e'ists for each architectural driver listed in Step 1Scenario generation is a 6ey step in the F+!
method and must &e carried out with care
!esuggest the following guidance to help F+! facilitators during this step
- ;acilitators should help sta6eholders create well#formed scenarios 0t is tempting forsta6eholders to
recite reuirements such as “The system shall produce reports for users”!hile this is an important
reuirement, facilitators need to ensure that the uality attri&uteaspects of this reuirement are e'plored
further ;or e'ample, the following scenario shedsmore light on the performance aspect of this
reuirement “ remote user re!uests a databasereport via the "eb during peak usage and receives the
report within five seconds.”Jote that the initial reuirement hasn=t &een lost, &ut the scenario further e'plores the performanceaspect of this reuirement ;acilitators should note that uality attri&ute names
&y themselves are not enough )ather than say “ the s#stem shall be modifiable$” the scenarioshould
descri&e what it means to &e modifia&le &y providing a specific e'ample of amodification to the system
vis#Q#vis a scenario
. The voca&ulary used to descri&e uality attri&utes varies widely 9eated de&ates oftenrevolve around
to which uality attri&ute a particular system property &elongs 0t doesn=tmatter what we call a particular
uality attri&ute, as long as there=s a scenario thatdescri&es what it means
;acilitators need to remem&er that there are three general types of scenarios and to ensurethat each
type is covered during the F+!
a use case scenarios # involving anticipated uses of the system
& growth scenarios # involving anticipated changes to the system
c e'ploratory scenarios # involving unanticipated stresses to the system that can includeuses and/or
changes
1 ;acilitators should refer to the list of architectural drivers generated in Step 1 from time totime during
scenario &rainstorming to ensure that representative scenarios e'ist for eachone
Ste 0* S#e"ario Co"solidatio" +fter the scenario &rainstorming, similar scenarios are consolidated when reasona&leTo do that,
facilitators as6 sta6eholders to identify those scenarios that are very similar in contentScenarios that are
similar are merged, as long as the people who proposed them agree andfeels that their scenarios will not
&e diluted in the process *onsolidation is an important step&ecause it helps to prevent a “dilution” of
votes during the prioriti:ation of scenarios (Step K$Such a dilution occurs when sta6eholders split their
votes &etween two very similar scenarios+s a result, neither scenario rises to importance and is therefore
34
8/19/2019 spm notes 1-5%281%29
35/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
never refined (Step C$ 9owever,if the two scenarios are similar enough to &e merged into one, the votes
might &e concentrated,and the merged scenario may then rise to the appropriate level of importance and
&erefined further;acilitators should ma6e every attempt to reach a ma5ority consensus with the
sta6eholders&efore merging scenarios Though sta6eholders may &e tempted to merge scenarios with
a&andon,they should not do so 0n actuality, very few scenarios are merged
Ste :* S#e"ario Prioritiatio"
Prioriti:ation of the scenarios is accomplished &y allocating each sta6eholder a num&er ofvotes eual to
R of the total num&er of scenarios generated after consolidation The actualnum&er of votes allocated
to sta6eholders is rounded to an even num&er of votes at the discretionof the facilitators ;or e'ample, if
scenarios were generated, each sta6eholder gets ', or I, votes rounded up to - "oting is done
in round#ro&in fashion, in two passes Sta6eholders can allocate any num&er oftheir votes to any
scenario or com&ination of scenarios The votes are counted, and the scenariosare prioriti:edaccordingly
Ste ;* S#e"ario Refi"e!e"t
+fter the prioriti:ation, depending on the amount of time remaining, the top four or five scenariosare
refined in more detail ;acilitators further ela&orate each one, documenting the following
;urther clarify the scenario &y clearly descri&ing the following si' things
- stimulus # the condition that affects the system
. response # the activity that results from the stimulus
source of stimulus # the entity that generated the stimulus
1 environment # the condition under which the stimulus occurred
2 artifact stimulated # the artifact that was stimulated
3 response measure # the measure &y which the system=s response will &e evaluated
Descri&e the &usiness/mission goals that are affected &y the scenario
Descri&e the relevant uality attri&utes associated with the scenario
+llow the sta6eholders to pose uestions and raise any issues regarding the scenario Suchuestions
should concentrate on the uality attri&ute aspects of the scenario and any concernsthat the sta6eholders
might have in achieving the response called for in the scenarioSee the e'ample template for scenariorefinement in +ppendi' + This step continues untiltime runs out or the highest priority scenarios have
&een refined Typically, time runs out first
A4> 8e"efits
The F+! provides a forum for a wide variety of sta6eholders to gather in one room at onetime very early
in the development process 0t is often the first time such a meeting ta6es placeand generally leads to the
35
8/19/2019 spm notes 1-5%281%29
36/168
8/19/2019 spm notes 1-5%281%29
37/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
in the appropriate view pac6et or overviewdocumentation Details that e'plain how to transition these
artifacts into architecturaldocumentation is the su&5ect of ongoing research0n addition to the more
immediate &enefits cited a&ove, the scenarios continue to provide &enefitsduring later phases of
development They provide input for analysis throughout the life ofthe system and can &e used to drive
test case development during implementation testing
+. 4"al$sis 3rioritiatio"3a"d trade off 4r#)ite#t're Ce"tri# Develo!e"t Met)od4CDM%
Lust as &lueprints in the &uilding construction industry guides the construction of a &uilding, the software
architecture serves a &lueprint that addresses technical concerns and programmatic issues of a pro5ect
+n architectural focus will
• help refine the functional reuirements, uality attri&ute reuirements, and constraints
• help set and maintain e'pectations in sta6eholders
• define the team structure
• aid in creating more accurate pro5ect estimates
• esta&lish the team voca&ulary
• help identify technical ris6 early
• guide the creation of a more realistic and accurate production schedule and assist in pro5ect
trac6ing and oversight
• provide an early vision of the solution/system
+ num&er of methods have &een created &y the Software %ngineering 0nstitute to help practitioners create
&etter architectures Some of these methods include Fuality +ttri&ute !or6shop (F+!$ ,+rchitecture
Tradeoff +nalysis Method (+T+M$ O, +ttri&ute Driven Design (+DD$ These methods have provided great
value to practitioners trying to &uild &etter architectures 9owever, these methods have two main
pro&lems ;irst, they are intervention oriented These methods were not designed with a particular
development philosophy (lifecycle or process$ in mind +s such, they do not fit neatly into e'isting
development models or processes without significant tailoring
@ittle guidance e'ists that descri&es how to tailor these methods to fit into an organi:ation=s developmentmodel To ma'imi:e their effectiveness, these methods should &e used together and this reuires
significant tailoring 0n order to tailor these methods, someone in an organi:ation has to 6now a great deal
a&out each of them in order to tease them apart, and reassem&le them into a cohesive, usa&le
development method/process This is a ris6y and difficult proposition in many organi:ations The second
pro&lem with these methods is that in their originally authored form they tend to &e heavy#weight and
e'pensive for the smaller teams, pro5ects, short deadlines, and iterative deliveries
8/19/2019 spm notes 1-5%281%29
38/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
hurdles has prevented many organi:ations in industry from em&racing these methods, and more
importantly, adopting the entire &ody of wor6
8/19/2019 spm notes 1-5%281%29
39/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
!hile +*DM emerged from small teams and pro5ects (1 to 3 team mem&ers, - to . year pro5ects$, it is
designed to scale up to meet the needs of larger teams and pro5ects as well 0n larger pro5ects, the +*DM
is used &y a core architecture team to create and refine the overall system architecture The output from
this +*DM cycle is an initial partitioning of the system (or system of systems$ into suelements (or
su&systems$ and their interactions Detailed architecting of the various elements is deferred to smaller
teams, each using +*DM to architect their part of the system (which may &e another system$ @ater
integration of the entire system is underta6en in production stages 3 and K The +*DM has &een evolved
over a five year period (since -III$ on small pro5ects and is now &eing further refined for use on larger
pro5ects in industry
39
8/19/2019 spm notes 1-5%281%29
40/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
4CDM Pre#o"ditio"s
+ precondition to &eginning step - of +*DM is to esta&lish the team roles for pro5ect The
recommended roles and responsi&ilities for +*DM are listed in the ta&le &elow
The +*DM also assumes that the functional reuirements and constraints e'ist &ut does not discuss
in detail how to get them, document them, and organi:e them This may seem somewhat naive &ut
this is intentional since reuirement gathering, documenting, and organi:ation varies widely even in
our small studio pro5ects !hile +*DM does not address the gathering of initial reuirements and
constraints, it will help refine them, clarify them, as the architecture is designed and matures The
relative completeness of the functional reuirements varies from pro5ect to pro5ect and may have to
&e discovered and refined as a conseuence of &uilding the system Some clients provide a
documented list of functional reuirements7 others 5ust &ring ideas to the team The initial gathering of
functional reuirements is assumed to have occurred prior to &eginning step - of +*DM The
reuirements engineer will coordinate the gathering and documenting of functional reuirements The
term “constraints” as applied in this conte't can &e confusing + “constraint” is an imposed design
decision or a design decision that the architect is not at li&erty to ma6e or change %'ample
constraints include &eing forced to use a particular operating system, use a particular commercial off#
the#shelf product, adhere to a particular standard, or &uild a system using a prescri&ed
implementation framewor6
+./ Re&'ire!e"ts do#'!e"tatio" a"d se#ifi#atio"
+ Software re&'ire!e"ts se#ifi#atio" (S)S$, a reuirements specification for a software system, is a
description of the &ehavior of a system to &e developed and may include a set of use cases that descri&e
40
http://en.wikipedia.org/wiki/Software_systemhttp://en.wikipedia.org/wiki/Software_systemhttp://en.wikipedia.org/wiki/Software_systemhttp://en.wikipedia.org/wiki/Use_casehttp://en.wikipedia.org/wiki/Use_casehttp://en.wikipedia.org/wiki/Software_systemhttp://en.wikipedia.org/wiki/Use_case
8/19/2019 spm notes 1-5%281%29
41/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
interactions the users will have with the software 0n addition it also contains non#functional reuirements
Jon#functional reuirements impose constraints on the design or implementation (such as performance
engineering reuirements, uality standards, or design constraints$
Software reuirements specification esta&lishes the &asis for agreement &etween customers and
contractors or suppliers (in mar6et#driven pro5ects, these roles may &e played &y the mar6eting and
development divisions$ on what the software product is to do as well as what it is not e'pected to do
Software reuirements specification permits a rigorous assessment of reuirements &efore design can
&egin and reduces later redesign 0t should also provide a realistic &asis for estimating product costs,
ris6s, and schedules
The software reuirements specification document enlists enough and necessary reuirements that are
reuired for the pro5ect developmentTo derive the reuirements we need to have clear and thorough
understanding of the products to &e developed or &eing developed This is achieved and refined with
detailed and continuous communications with the pro5ect team and customer till the completion of the
software
+.0 C)a"(e !a"a(e!e"t
=lo6aliatio" and the constant innovation of te#)"olo($ result in a constantly evolving &usiness
environment Phenomena such as social media and mo&ile adapta&ility have revolutioni:ed &usiness and
the effect of this is an ever increasing need for change, and therefore change management The growth in
technology also has a secondary effect of increasing the availa&ility and therefore accounta&ility of
6nowledge %asily accessi&le information has resulted in unprecedented scrutiny from stoc6holders and
the media and pressure on management
!ith the &usiness environment e'periencing so much change, organi:ations must then learn to &ecome
comforta&le with change as well Therefore, the a&ility to manage and adapt to organi:ational change is
an essential a&ility reuired in the wor6place today et, ma5or and rapid organi:ational change is
41
http://en.wikipedia.org/wiki/Non-functional_requirementshttp://en.wikipedia.org/wiki/Non-functional_requirementshttp://en.wikipedia.org/wiki/Performance_engineeringhttp://en.wikipedia.org/wiki/Performance_engineeringhttp://en.wikipedia.org/wiki/Performance_engineeringhttp://en.wikipedia.org/wiki/Quality_(business)http://en.wikipedia.org/wiki/Social_mediahttp://en.wikipedia.org/wiki/Non-functional_requirementshttp://en.wikipedia.org/wiki/Performance_engineeringhttp://en.wikipedia.org/wiki/Performance_engineeringhttp://en.wikipedia.org/wiki/Quality_(business)http://en.wikipedia.org/wiki/Social_media
8/19/2019 spm notes 1-5%281%29
42/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
profoundly difficult &ecause the structure, culture, and routines of organi:ations often reflect a persistent
and difficult#to#remove AimprintA of past periods, which are resistant to radical change even as the current
environment of the organi:ation changes rapidlyB-O
Due to the growth of technology, modern organi:ational change is largely motivated &y e'terior
innovations rather than internal moves !hen these developments occur, the organi:ations that adapt
uic6est create a competitive advantage for themselves, while the companies that refuse to change get
left &ehind This can result in drastic profit and/or mar6et share losses
8/19/2019 spm notes 1-5%281%29
43/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
+s a multi#disciplinary practice that has evolved as a result of scholarly research, organi:ational change
management should &egin with a systematic diagnosis of the current situation in order to determine &oth
the need for change and the capa&ility to change The o&5ectives, content, and process of change should
all &e specified as part of a *hange Management plan
*hange management processes should include creative mar6eting to ena&le communication &etween
changing audiences, as well as deep social understanding a&out leadership=s styles and group dynamics
+s a visi&le trac6 on transformation pro5ects,
8/19/2019 spm notes 1-5%281%29
44/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
• Personality !ide *hanges
+.: Tra#ea6ilit$ of re&'ire!e"ts
Tra#ea6ilit$ is the a&ility to verify the history, location, or application of an item &y means of documented
recorded identification
G (JP@$ the Jational 0nstitute of Standards and Technology (J0ST$ in
the >S+, the Physi6alisch#Technische4undesanstalt (PT4$ in ermany, and the 0stitutoJa:ionale di
)icercaMetrologica (0J)iM$ in 0taly +s defined &y J0ST, ATracea&ility of measurement reuires the
esta&lishment of an un&ro6en chain of comparisons to stated references each with a stated uncertaintyA
@ogistics
0n logistics, tracea&ility refers to the capa&ility for tracing goods along the distri&ution chain on
a &atch num&er or series num&er &asis Tracea&ility is an important aspect for e'ample in the automotive
industry, where it ma6es recalls possi&le, or in the food industry where it contri&utes to food safety
The international standards organi:ation %P*glo&al under S- has ratified the %P*glo&al
Jetwor6 standards (especially the %P* 0nformation Services %P*0S standard$ which codify the synta'
44
http://en.wikipedia.org/wiki/Measuring_instrumenthttp://en.wikipedia.org/wiki/Measurementhttp://en.wikipedia.org/wiki/Standard_(metrology)http://en.wikipedia.org/wiki/Calibrationhttp://en.wikipedia.org/wiki/Accuracy_and_precisionhttp://en.wikipedia.org/wiki/Accuracyhttp://en.wikipedia.org/wiki/Chain_of_custodyhttp://en.wikipedia.org/wiki/Calibrationhttp://en.wikipedia.org/wiki/National_Physical_Laboratory,_UKhttp://en.wikipedia.org/wiki/National_Institute_of_Standards_and_Technologyhttp://en.wikipedia.org/wiki/Physikalisch-Technische_Bundesanstalthttp://en.wikipedia.org/w/index.php?title=Istituto_Nazionale_di_Ricerca_Metrologica&action=edit&redlink=1http://en.wikipedia.org/w/index.php?title=Istituto_Nazionale_di_Ricerca_Metrologica&action=edit&redlink=1http://en.wikipedia.org/wiki/Logisticshttp://en.wikipedia.org/wiki/Batch_productionhttp://en.wikipedia.org/wiki/Food_safetyhttp://en.wikipedia.org/wiki/EPCglobalhttp://en.wikipedia.org/wiki/GS1http://en.wikipedia.org/wiki/EPCglobal_Networkhttp://en.wikipedia.org/wiki/EPCglobal_Networkhttp://en.wikipedia.org/wiki/EPCIShttp://en.wikipedia.org/wiki/Measuring_instrumenthttp://en.wikipedia.org/wiki/Measurementhttp://en.wikipedia.org/wiki/Standard_(metrology)http://en.wikipedia.org/wiki/Calibrationhttp://en.wikipedia.org/wiki/Accuracy_and_precisionhttp://en.wikipedia.org/wiki/Accuracyhttp://en.wikipedia.org/wiki/Chain_of_custodyhttp://en.wikipedia.org/wiki/Calibrationhttp://en.wikipedia.org/wiki/National_Physical_Laboratory,_UKhttp://en.wikipedia.org/wiki/National_Institute_of_Standards_and_Technologyhttp://en.wikipedia.org/wiki/Physikalisch-Technische_Bundesanstalthttp://en.wikipedia.org/w/index.php?title=Istituto_Nazionale_di_Ricerca_Metrologica&action=edit&redlink=1http://en.wikipedia.org/w/index.php?title=Istituto_Nazionale_di_Ricerca_Metrologica&action=edit&redlink=1http://en.wikipedia.org/wiki/Logisticshttp://en.wikipedia.org/wiki/Batch_productionhttp://en.wikipedia.org/wiki/Food_safetyhttp://en.wikipedia.org/wiki/EPCglobalhttp://en.wikipedia.org/wiki/GS1http://en.wikipedia.org/wiki/EPCglobal_Networkhttp://en.wikipedia.org/wiki/EPCglobal_Networkhttp://en.wikipedia.org/wiki/EPCIS
8/19/2019 spm notes 1-5%281%29
45/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
and semantics for supply chain events and the secure method for selectively sharing supply chain events
with trading partners These standards for tracea&ility have &een used in successful deployments in many
industries and there are now a wide range of products that are certified as &eing compati&le with these
standards
Materials
0n materials, tracea&ility refers to the capa&ility to associate a finished part with destructive test results
performed on material from the same ingot with the same heat treatment, or to associate a finished part
with results of a test performed on a sample from the same melt identified &y the uniue lot num&er of the
material Destructive tests typically include chemical composition and mechanical strength tests + heat
num&er is usually mar6ed on the part or raw material which identifies the ingot it came from, and a lot
num&er may identify the group of parts that e'perienced the same heat treatment (ie, were in the same
oven at the same time$ Material tracea&ility is important to the aerospace, nuclear, and process industry
&ecause they freuently ma6e use of high strength materials that loo6 identical to commercial low
strength versions 0n these industries, a part made of the wrong material is called Acounterfeit,A even if the
su&stitution was accidental
Supply chain
0n the supply chain, tracea&ility is more of an ethical or environmental issue %nvironmentally friendly
retailers may choose to ma6e information regarding their supply chain freely availa&le to customers,
illustrating the fact that the products they sell are manufactured in factories with safe wor6ing conditions,
&y wor6ers that earn a fair wage, using methods that do not damage the environment
Software development
0n software development, the term tracea&ility (or )euirements Tracea&ility$ refers to the a&ility to lin6
product reuirements &ac6 to sta6eholdersH rationales and forward to corresponding design artifacts,
code, and test cases Tracea&ility supports numerous software engineering activities such as
change impact analysis, compliance verification or trace&ac6 of code, regression test selection, and
reuirements validation 0t is usually accomplished in the form of a matri' created for the verification and
validation of the pro5ect >nfortunately the practice of constructing and maintaining a reuirements trace
matri' ()TM$ can &e very arduous and over time the traces tend to erode into an inaccurate state unless
45
http://en.wikipedia.org/w/index.php?title=Materials&action=edit&redlink=1http://en.wikipedia.org/wiki/Heat_numberhttp://en.wikipedia.org/wiki/Heat_numberhttp://en.wikipedia.org/wiki/Supply_chainhttp://en.wikipedia.org/wiki/Software_developmenthttp://en.wikipedia.org/wiki/Requirements_Traceabilityhttp://en.wikipedia.org/wiki/Test_casehttp://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Change_impact_analysishttp://en.wikipedia.org/wiki/Regression_testinghttp://en.wikipedia.org/wiki/Verification_and_Validationhttp://en.wikipedia.org/wiki/Verification_and_Validationhttp://en.wikipedia.org/wiki/Traceability_matrixhttp://en.wikipedia.org/wiki/Traceability_matrixhttp://en.wikipedia.org/w/index.php?title=Materials&action=edit&redlink=1http://en.wikipedia.org/wiki/Heat_numberhttp://en.wikipedia.org/wiki/Heat_numberhttp://en.wikipedia.org/wiki/Supply_chainhttp://en.wikipedia.org/wiki/Software_developmenthttp://en.wikipedia.org/wiki/Requirements_Traceabilityhttp://en.wikipedia.org/wiki/Test_casehttp://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Change_impact_analysishttp://en.wikipedia.org/wiki/Regression_testinghttp://en.wikipedia.org/wiki/Verification_and_Validationhttp://en.wikipedia.org/wiki/Verification_and_Validationhttp://en.wikipedia.org/wiki/Traceability_matrixhttp://en.wikipedia.org/wiki/Traceability_matrix
8/19/2019 spm notes 1-5%281%29
46/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
date/time stamped +lternate automated approaches for generating traces using information
retrieval methods have &een developed
0n transaction processing software, tracea&ility implies use of a uniue piece of data (eg, order date/time
or a seriali:ed seuence num&er$ which can &e traced through the entire software flow of all relevant
application programs Messages and files at any point in the system can then &e audited for correctness
and completeness, using the tracea&ility 6ey to find the particular transaction This is also sometimes
referred to as the transaction footprint
;ood processing
0n food processing (meat processing, fresh produce processing$, the term tracea&ility refers to therecording through means of &arcodes or );0D tags other trac6ing media, all movement of product and
steps within the production process
8/19/2019 spm notes 1-5%281%29
47/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
Mostly led out of %urope, and targeting countries where illegal logging has &een a 6ey pro&lem
(;@%T countries$, tim&er trac6ing is now part of daily &usiness for many enterprises and 5urisdictions
;ull tracea&ility offers advantages for multiple partners along the supply chain &eyond certification
systems, including
• Mechanism to comply with local and international policies and regulations
• )educing the ris6 of illegal or non#compliant material entering the supply chains
• Providing coordination &etween authorities and relevant &odies
• +llowing automatic reconciliation of &atches and volumes availa&le
•
8/19/2019 spm notes 1-5%281%29
48/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
advance, which could prevent the pro5ect from meeting one or more of its
o&5ectives
0ssue +n event or circumstance that has occurred with pro5ect impact that needs to
&e managed and resolved, with escalation if appropriate
Tas6 / +ction
0tem
!or6 pac6ages from the !or6 4rea6down Structure (!4S$ or wor6 resulting
from pro5ect meetings or conversations
Ris5 Ma"a(e!e"t 4roa#)
The pro5ect team will implement a continuous ris6 management process which entails two ma5or
processes E ris6 assessment and ris6 mitigation
)is6 assessment includes activities to identify ris6s, analy:e and prioriti:e )is6 mitigation includes
developing ris6 contingency and mitigation strategies, as well as monitoring the impact of the issue, actionitems, strategies and residual ris6s
Ris5 Tolera"#e
The company has a very low threshold for ris6s to
o The client e'perience
o The e'perience of users who directly support the client
o Jon#pu&lic information (JP0$
o Potential for fraud or loss related to insufficient control or security
Ris5 Ma"a(e!e"t Tas5s
)is6 Management activities are documented in the )is6 Management wor6&oo6 The wor6&oo6 is used
to identify, prioriti:e, analy:e, and plan a ris6 response
)is6 0dentification The process of determining which ris6s may affect the pro5ect and documenting their
characteristics
48
Communicati
Risk
Monitoring
and Control
Risk
Response
Planning
Risk Analysis
and
Prioritization
Risk
Identifcatio
n
8/19/2019 spm notes 1-5%281%29
49/168
CP7301 SOFTWARE PROCESS AND PROJECT MANAGEMENT
• Ris5 4ssess!e"t*The )is6 +ssessement and Mitigation ta& in the )is6 Management
wor6&oo6 has a set of uestions that need to &e answered that help determine the ris6 level
of the pro5ect %ach uestion has a potential rating of 9igh, Medium, or @ow in terms of
potential impact
• Ris5 Re(ister* This is located on the pro5ect=s SharePoint site where pro5ect specific ris6s
can &e entered +ll ris6s identified through any means should &e entered individually in the
)is6 )egister on SharePoint @i6e all company documentation, discretion should &e used in
documenting ris6 all statements should &e fact#&ased and conclusions should &e reviewed
&y management (and if appropriate, @egal$ )is6s should &e stated in a standard format, to
help the team stay focused on ris6s versus root causes and results *ause E )is6 E %ffect
o *ause specific situation that introduces ris6
o )is6 uncertain event that can impact the pro5ect
o %ffect potential conseuences of the ris6 occurring
%&le: shortage of skilled 'usiness nal#sts (cause) could result in man# missed
re!uirements (risk)$ leading to rework or customer dis