ﴀ These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e...

These slides are designed to accompany Software Engineering: A Practitioner’يحs Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

1

Project Management Risk Analysis and Management

Lecture 2 SD3043


2

Outline

• Project Management Concepts

• Project Planning

• Risk Analysis and Management


3

Management Activities

• Proposal writing

• Project planning and scheduling

• Project costing

• Project monitoring and evaluation

• Report writing and presentation


4

The Four P’s

• People — the most important element of a successful project

• Product — the software to be built

• Process — the set of framework activities and software engineering tasks to get the job done

• Project — all work required to make the product a reality


5

Stakeholders• Senior managers who define the business issues that often

have significant influence on the project.• Project (technical) managers who must plan, motivate,

organize, and control the practitioners who do software work.

• Practitioners who deliver the technical skills that are necessary to engineer a product or application.

• Customers who specify the requirements for the software to be engineered and other stakeholders who have a peripheral interest in the outcome.

• End-users who interact with the software once it is released for production use.


6

Software TeamsHow to lead?

How to organize?

How to motivate?

How to collaborate?

How to create good ideas?


7

Team Leader• The MOI Model

– Motivation. The ability to encourage (by “push or pull”) technical people to produce to their best ability.

– Organization. The ability to mold existing processes (or invent new ones) that will enable the initial concept to be translated into a final product.

– Ideas or innovation. The ability to encourage people to create and feel creative even when they must work within bounds established for a particular software product or application.


8

Software Teams

• the difficulty of the problem to be solved

• the size of the resultant program(s) in lines of code or function points

• the time that the team will stay together (team lifetime)

• the degree to which the problem can be modularized

• the required quality and reliability of the system to be built

• the rigidity of the delivery date

• the degree of sociability (communication) required for the project

The following factors must be considered when selecting a software project team structure ...


9

• closed paradigm—structures a team along a traditional hierarchy of authority

• random paradigm—structures a team loosely and depends on individual initiative of the team members

• open paradigm—attempts to structure a team in a manner that achieves some of the controls associated with the closed paradigm but also much of the innovation that occurs when using the random paradigm

• synchronous paradigm—relies on the natural compartmentalization of a problem and organizes team members to work on pieces of the problem with little active communication among themselves

Organizational Paradigms

suggested by Constantine [Con93]


10

Avoid Team “Toxicity”• A frenzied work atmosphere in which team members waste

energy and lose focus on the objectives of the work to be performed.

• High frustration caused by personal, business, or technological factors that cause friction among team members.

• “Fragmented or poorly coordinated procedures” or a poorly defined or improperly chosen process model that becomes a roadblock to accomplishment.

• Unclear definition of roles resulting in a lack of accountability and resultant finger-pointing.

• “Continuous and repeated exposure to failure” that leads to a loss of confidence and a lowering of morale.


11

Agile Teams

• Team members must have trust in one another. • The distribution of skills must be appropriate to

the problem. • Mavericks may have to be excluded from the

team, if team cohesiveness is to be maintained.• Team is “self-organizing”

– An adaptive team structure– Uses elements of Constantine’s random, open, and

synchronous paradigms– Significant autonomy


12

Team Coordination & Communication

• Formal, impersonal approaches include software engineering documents and work products (including source code), technical memos, project milestones, schedules, and project control tools, change requests and related documentation, error tracking reports, and repository data.

• Formal, interpersonal procedures focus on quality assurance activities applied to software engineering work products. These include status review meetings and design and code inspections.

• Informal, interpersonal procedures include group meetings for information dissemination and problem solving and “collocation of requirements and development staff.”

• Electronic communication encompasses electronic mail, electronic bulletin boards, and by extension, video-based conferencing systems.

• Interpersonal networking includes informal discussions with team members and those outside the project who may have experience or insight that can assist team members.


13

The Product Scope• Scope

• Context. How does the software to be built fit into a larger system, product, or business context and what constraints are imposed as a result of the context?

• Information objectives. What customer-visible data objects are produced as output from the software? What data objects are required for input?

• Function and performance. What function does the software perform to transform input data into output? Are any special performance characteristics to be addressed?

• Software project scope must be unambiguous and understandable at the management and technical levels.


14

Problem Decomposition

• Sometimes called partitioning or problem elaboration

• Once scope is defined …– It is decomposed into constituent functions– It is decomposed into user-visible data objects

or– It is decomposed into a set of problem

classes• Decomposition process continues until all

functions or problem classes have been defined


15

The Process

• Once a process framework has been established– Consider project characteristics– Determine the degree of rigor required– Define a task set for each software engineering

activity• Task set =

– Software engineering tasks– Work products– Quality assurance points– Milestones


16

Melding the Problem and the Process


17

The Project

• Projects get into trouble when …

– Software people don’t understand their customer’s needs.– The product scope is poorly defined.– Changes are managed poorly.– The chosen technology changes.– Business needs change [or are ill-defined]. – Deadlines are unrealistic.– Users are resistant.– Sponsorship is lost [or was never properly obtained].– The project team lacks people with appropriate skills.– Managers [and practitioners] avoid best practices and lessons

learned.


18

Common-Sense Approach to Projects

• Start on the right foot. This is accomplished by working hard (very hard) to understand the problem that is to be solved and then setting realistic objectives and expectations.

• Maintain momentum. The project manager must provide incentives to keep turnover of personnel to an absolute minimum, the team should emphasize quality in every task it performs, and senior management should do everything possible to stay out of the team’s way.

• Track progress. For a software project, progress is tracked as work products (e.g., models, source code, sets of test cases) are produced and approved (using formal technical reviews) as part of a quality assurance activity.

• Make smart decisions. In essence, the decisions of the project manager and the software team should be to “keep it simple.”

• Conduct a postmortem analysis. Establish a consistent mechanism for extracting lessons learned for each project.


19

To Get to the Essence of a Project

• Why is the system being developed?• What will be done? • When will it be accomplished?• Who is responsible?• Where are they organizationally located?• How will the job be done technically and

managerially?• How much of each resource (e.g., people,

software, tools, database) will be needed?Barry Boehm [Boe96]


20

Critical Practices

• Formal risk management – what are the top ten risks for the project? For each of these risks, what is the chance that the risk will transition into a problem and what is the impact if it does.

• Empirical cost and schedule estimation – Current estimated size of the application software.

• Metrics-based project management – have measures to give an early indication of evolving problems.

• Earned value tracking – reporting monthly earned value metrics computed from an activity network of tasks for the entire effort to the next delivery.

• Defect tracking against quality targets – report the number of defects

• People aware project management – average turnover


21

Software Project PlanningThe overall goal of project planning is to The overall goal of project planning is to

establish a pragmatic strategy for establish a pragmatic strategy for controlling, tracking, and monitoring a controlling, tracking, and monitoring a complex technical project.complex technical project.

Why?Why?

So the end result gets done on time, with So the end result gets done on time, with

quality!quality!


22

Project Planning Task Set-I

• Establish project scope• Determine feasibility

• Analyze risks

• Define required resources– Determine require human resources– Define reusable software resources– Identify environmental resources


23

Project Planning Task Set-II

• Estimate cost and effort– Decompose the problem– Develop two or more estimates using size, function points,

process tasks or use-cases– Reconcile the estimates

• Develop a project schedule– Scheduling will be considered later

• Establish a meaningful task set• Define a task network• Use scheduling tools to develop a timeline chart• Define schedule tracking mechanisms


24

Estimation

• Estimation of resources, cost, and schedule for a software engineering effort requires – experience– access to good historical information (metrics)– the courage to commit to quantitative predictions

when qualitative information is all that exists• Estimation carries inherent risk and this risk leads to

uncertainty


25

Write it Down!

SoftwareSoftwareProjectProject

PlanPlan

Project ScopeProject ScopeEstimatesEstimatesRisksRisksScheduleScheduleControl strategyControl strategy


26

Software risks

• Project risks – budgetary, schedule, personnel, resource, customer; complexity, size, degree of uncertainty.

• Technical risks – threat to quality and timeliness of the software to be produced: e.g. technical obsolescence, “leading edge”, problem harder than thought.

• Business risks: building a system nobody wants, product does not fit anymore business strategy; product not understood by sales force; losing support form senior management; losing budgetary or personnel commitment.


27

Reactive Risk Management• project team reacts to risks when they

occur• mitigation—plan for additional resources

in anticipation of fire fighting• fix on failure—resource are found and

applied when the risk strikes• crisis management—failure does not

respond to applied resources and project is in jeopardy


28

Proactive Risk Management• formal risk analysis is performed

(identification, impact, strategy to avoid risk, contingency plans)

• organization corrects the root causes of risk– examining risk sources that lie beyond the

bounds of the software– developing the skill to manage change


29

Seven Principles• Maintain a global perspective—view software risks within the context

of system and the business problem • Take a forward-looking view—think about the risks that may arise in

the future; establish contingency plans • Encourage open communication—if someone states a potential risk,

don’t discount it. • Integrate—a consideration of risk must be integrated into the software

process• Emphasize a continuous process—the team must be vigilant

throughout the software process, modifying identified risks as more information is known and adding new ones as better insight is achieved.

• Develop a shared product vision—if all stakeholders share the same vision of the software, it likely that better risk identification and assessment will occur.

• Encourage teamwork—the talents, skills and knowledge of all stakeholder should be pooled


30

RISK

Risk Management Paradigm

controlcontrol

identifyidentify

analyzeanalyze

planplan

tracktrack


31

Risk Identification• Product size—risks associated with the overall size of the software to be

built or modified.• Business impact—risks associated with constraints imposed by

management or the marketplace.• Customer characteristics—risks associated with the sophistication of the

customer and the developer's ability to communicate with the customer in a timely manner.

• Process definition—risks associated with the degree to which the software process has been defined and is followed by the development organization.

• Development environment—risks associated with the availability and quality of the tools to be used to build the product.

• Technology to be built—risks associated with the complexity of the system to be built and the "newness" of the technology that is packaged by the system.

• Staff size and experience—risks associated with the overall technical and project experience of the software engineers who will do the work.


32

Risk Due to Product Size

• • estimated size of the product in LOC (lines of code) or estimated size of the product in LOC (lines of code) or

estimated size of product in number of programs, estimated size of product in number of programs, user inputs, user outputs, user inquiries, number user inputs, user outputs, user inquiries, number of files.of files.

FP (function FP (function points)-points)-

• • percentage deviation in size of product from percentage deviation in size of product from average for previous products?average for previous products?

• • size of database created or used by the product?size of database created or used by the product?

• • number of users of the product?number of users of the product?

• • number of projected changes to the requirements number of projected changes to the requirements for the product? before delivery? after delivery?for the product? before delivery? after delivery?

• • amount of reused software?amount of reused software?

Attributes that affect risk:


33

Risk Due to Business Impact

• • affect of this product on company revenue?affect of this product on company revenue?

• • visibility of this product by senior management?visibility of this product by senior management?

• • reasonableness of delivery deadline?reasonableness of delivery deadline?

• • number of customers who will use this product number of customers who will use this product

• • interoperability constraintsinteroperability constraints

• • sophistication of end users?sophistication of end users?

• • amount and quality of product documentation that amount and quality of product documentation that must be produced and delivered to the customer?must be produced and delivered to the customer?

• • governmental constraintsgovernmental constraints

• • costs associated with late delivery?costs associated with late delivery?

• • costs associated with a defective product?costs associated with a defective product?

Attributes that affect risk:


34

Risks Due to the Customer

• • Have you worked with the customer in the past?Have you worked with the customer in the past?

• • Does the customer have a solid idea of requirements?Does the customer have a solid idea of requirements?

• • Has the customer agreed to spend time with you? Has the customer agreed to spend time with you?

• • Is the customer willing to participate in reviews?Is the customer willing to participate in reviews?

• • Is the customer technically sophisticated?Is the customer technically sophisticated?

• • Is the customer willing to let your people do their Is the customer willing to let your people do their job—that is, will the customer resist looking over your job—that is, will the customer resist looking over your

shoulder during technically detailed work?shoulder during technically detailed work?

• • Does the customer understand the software Does the customer understand the software

engineering process?engineering process?

Questions that must be answered:


35

Risks Due to Process Maturity

• • Have you established a common process framework? Have you established a common process framework?

• • Is it followed by project teams?Is it followed by project teams?

• • Do you have management support for Do you have management support for software engineering software engineering

• • Do you have a proactive approach to SQA? Do you have a proactive approach to SQA?

• • Do you conduct formal technical reviews?Do you conduct formal technical reviews?

• • Are CASE tools used for analysis, design and Are CASE tools used for analysis, design and testing?testing?

• • Are the tools integrated with one another?Are the tools integrated with one another?

• • Have document formats been established?Have document formats been established?



36

Technology Risks

• • Is the technology new to your organization?Is the technology new to your organization?

• • Are new algorithms, I/O technology required?Are new algorithms, I/O technology required? • • Is new or unproven hardware involved?Is new or unproven hardware involved?

• • Does the application interface with new software?Does the application interface with new software?

• • Is a specialized user interface required? Is a specialized user interface required?

• • Is the application radically different?Is the application radically different?

• • Are you using new software engineering methods?Are you using new software engineering methods?

• • Are you using unconventional software development Are you using unconventional software development methods, such as formal methods, AI-based approaches, methods, such as formal methods, AI-based approaches, artificial neural networks?artificial neural networks?

• • Are there significant performance constraints?Are there significant performance constraints?

• • Is there doubt the functionality requested is "do-able?"Is there doubt the functionality requested is "do-able?"



37

Staff/People Risks

• • Are the best people available?Are the best people available?• • Does staff have the right skills?Does staff have the right skills?• • Are enough people available?Are enough people available?• • Are staff committed for entire duration?Are staff committed for entire duration?• • Will some people work part time? Will some people work part time?

• • Do staff have the right expectations?Do staff have the right expectations?• • Have staff received necessary training?Have staff received necessary training?

• • Will turnover among staff be low?Will turnover among staff be low?



38

Assessing Project Risk-I• Have top software and customer managers formally

committed to support the project?• Are end-users enthusiastically committed to the project

and the system/product to be built?• Are requirements fully understood by the software

engineering team and their customers?• Have customers been involved fully in the definition of

requirements?• Do end-users have realistic expectations?


39

Assessing Project Risk-II

• Is project scope stable?• Does the software engineering team have the

right mix of skills?• Are project requirements stable?• Does the project team have experience with the

technology to be implemented?• Is the number of people on the project team

adequate to do the job?• Do all customer/user constituencies agree on

the importance of the project and on the requirements for the system/product to be built?


40

Risk Components• performance risk—the degree of uncertainty that the

product will meet its requirements and be fit for its intended use.

• cost risk—the degree of uncertainty that the project budget will be maintained.

• support risk—the degree of uncertainty that the resultant software will be easy to correct, adapt, and enhance.

• schedule risk—the degree of uncertainty that the project schedule will be maintained and that the product will be delivered on time.

• The impact of each risk component is divided into four impact categories: negligible, marginal, critical and catastrophic.


41

Risk Projection• Risk projection, also called risk estimation, attempts to

rate each risk in two ways– the likelihood or probability that the risk is real – the consequences of the problems associated with the

risk, should it occur. • The are four risk projection steps:

– establish a scale that reflects the perceived likelihood of a risk

– delineate the consequences of the risk– estimate the impact of the risk on the project and the

product,– note the overall accuracy of the risk projection so that

there will be no misunderstandings.


42

Building a Risk Table

RiskRisk ProbabilityProbability ImpactImpact RMMMRMMM

RiskRiskMitigationMitigationMonitoringMonitoring

& & ManagementManagement


43

Building the Risk Table• Estimate the probability of occurrence• Estimate the impact on the project on a scale of 1

to 5, where– 1 = low impact on project success– 5 = catastrophic impact on project success

• sort the table by probability and impact• Cut-off line – implies only risks above the line will

be given attention


44

Risk Exposure (Impact)

The overall risk exposure, RE, is determined using the following relationship [Hal98]:

RE = P x C

where P is the probability of occurrence for a risk, and C is the cost to the project should the risk occur.


45

Risk Exposure Example

• Risk identification. Only 70 percent of the software components scheduled for reuse will, in fact, be integrated into the application. The remaining functionality will have to be custom developed.

• Risk probability. 80% (likely).• Risk impact. 60 reusable software components were planned. If

only 70 percent can be used, 18 components would have to be developed from scratch (in addition to other custom software that has been scheduled for development). Since the average component is 100 LOC and local data indicate that the software engineering cost for each LOC is $14.00, the overall cost (impact) to develop the components would be 18 x 100 x 14 = $25,200.

• Risk exposure. RE = 0.80 x 25,200 ~ $20,200.


46

• mitigation—how can we avoid the risk?• monitoring—what factors can we track

that will enable us to determine if the risk is becoming more or less likely?

• management—what contingency plans do we have if the risk becomes a reality?

Risk Mitigation, Monitoring,and Management


47

Example• Risk – staff turnover

• Risk avoidance– Meet with current staff to determine causes for turnover– Act to mitigate those causes that are under out of control before the project starts– Once project commences assume turnover will occur and develop techniques to ensure

continuity when people leave– Organise project teams so that information about each development activity is widely

dispersed– Define documentation standards and establish mechanisms to be sure that documents are

developed in a timely manner• Risk monitoring

– General attitude of team members based on project pressures– Interpersonal relationships – Potential problems with compensation and beliefs– The availability of jobs within the company and outside it

• Risk management and contingency planning– Those individuals who are leaving are asked to stop all work and spend their last weeks in

knowledge transfer


48

Project: Embedded software for XYZ systemRisk type: schedule riskPriority (1 low ... 5 critical): 4Risk factor: Project completion will depend on tests which require hardware component under development. Hardware component delivery may be delayedProbability: 60 %Impact: Project completion will be delayed for each day that hardware is unavailable for use in software testingMonitoring approach: Scheduled milestone reviews with hardware groupContingency plan: Modification of testing strategy to accommodate delay using software simulationEstimated resources: 6 additional person months beginning in July

Recording Risk Information


49

Summary

• Project Management

• Project Planning

• Risk Management

ﴀ These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e...

Documents

Transcript of ﴀ These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e...