csc450 software engineering 1 devon m. simmonds university of north carolina, wilmington...
TRANSCRIPT
CSC450CSC450CSC450
Software Engineering
1
Devon M. SimmondsUniversity of North Carolina, Wilmington
Introduction to Software Project Management
CSC450CSC450Outline2
Introduction to Software project management Project management activities
Teams Project management process
Scoping Estimation Scheduling Risk analysis
Project planning template Project management problems
3
A project is a sequence of unique, complex, and connected activities having one goal or purpose and that must be completed by a specific time, within budget, and according to specifications.
What is a Project?
4
• Project management is a set of principles and tools for– Defining– Planning– Executing– Controlling . . . and – Completing a PROJECT
What is Project Management?
CSC450CSC450Software Project Management
5
Software project management is the organization and management of project resources to create or evolve software within specified, budgetary, time and scoping constraints. A software project is a set of activities
that use resources to realize specified software development objectives.
CSC450CSC450Project Management Activities
6
Planning Description of tasks to be done Estimating resources
People, time, hardware, software, money, etc. Acquiring resources Assemble project teams Assigning tasks & organizing work Allocating resources Assessing and mitigating risks (i.e., Risk Management) Controlling project execution Tracking and Reporting progress Analyzing results Forecasting future trends in the project Quality Management
7
• Organize your approach• Generate a credible schedule• Track progress and control your project• Identify where to focus your efforts • Identify problems early – before they are crises• Saves you TIME….MONEY
If you fail to plan, you PLAN TO FAIL
Why is Project Management Important?
CSC450CSC450The 4 P’s of Software Project Management
8
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
CSC450CSC450People
9
People Capability Maturity Model To assess organizations ability to attract,
develop, motivate, organize, retain people. PCMM key practice areas
Staffing, communication and coordination, work environment, performance management, training, compensation, career development, team development, etc.
CSC450CSC450People: Who needs software?
10
Most software is built in organizations for people with specific needs.
A stakeholder is a anyone who has an interest (or stake) in the software being completed Senior managers, project managers, practitioners,
customers, end users.
A user is someone who will need to use the software to perform tasks.
Stakeholders may or may not be users For example, a senior manager (like a CEO or CTO in
a company) will usually have a stake in the software that is built (since it affects the bottom line), even if she won’t ever use it.
CSC450CSC450Stakeholders
11
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.
Who/What will be the concern of senior managers?Customers = End-users?
CSC450CSC450People: Who builds software?
12
Software is typically built by a team of software engineers, which includes: Business analysts or requirements analysts
who talk to users and stakeholders, plan the behavior of software and write software requirements
Designers and architects who plan the technical solution
Programmers who write the code Testers who verify that the software meets its
requirements and behaves as expected
CSC450CSC450Software Teams
13
How to lead?
How to organize?
How to motivate?
How to collaborate?
How to create good ideas?
CSC450CSC450Team Leadership
14
The MOI Model [Weinberg] Motivation. The ability to encourage 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.
CSC450CSC450Traits of an effective project manager
15
Problem solving Must be able to diagnose technical and managerial issues Must be able to realize a solution the coordinating personal skills with skills of the
team Must be flexible enough to change directions when initial attempts at realizing
solution are fruitless
Managerial identity Must take charge of project Must have the confidence to take control when necessary Must allow competent persons to follow their own initiatives
Achievement Must reward initiative and accomplishment
Influence and team building Must be able to “read” people Must be able to understand verbal and non-verbal signals Must remain under control in high-stress situations
CSC450CSC450
Organizational Paradigms
16
closed paradigm—structures a team along a traditional hierarchy of authority E.g. chief programmer team
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 Democratic teams
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
CSC450CSC450Agile Teams
17
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 random, open, and synchronous
paradigms Significant autonomy
CSC450CSC450
Software Teams
18
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 How well people know each other
Factors to be considered
CSC450CSC450
The Product
19
Software Scope- an estimation dilemma Context Information objectives Function and perfrmance
Problem Decomposition
CSC450CSC450
Scope Develop Launch Etc.
The Project
Management Process
20
21 Five Phases of Project Management
Scoping the Project
Adapted from Weiss, J.W., and Wysocki, R.K. 1992. 5-Phase Project Management: A Practical Planning and Implementation Guide. Reading, MA: Addison Wesley.
Developing the Plan
Scoping the Project
Launching thePlan
Monitoring &Controlling
Closing Out the Project
Scoping the Project
Scoping the Project
22 Scoping The Project
Define the Project Objectives
State the Problem/Opportunity
Establish the Project Goal
Identify theSuccess Criteria
List Assumptions,Risks, Obstacles
Adapted from Weiss, J.W., and Wysocki, R.K. 1992. 5-Phase Project Management:
A Practical Planning and Implementation Guide. Reading, MA: Addison Wesley.
Scoping the Project
Scoping the Project
Scoping the Project
Scoping the Project
CSC450CSC450
Scoping Document Content
23
What is to be done Why it is to be done The value it provides if it is done
CSC450CSC450
24
Project Scoping FormProject Name Project
ManagerTeam Members
Problem / Opportunity (Why do this project?):
Project Goal:
Objectives (Specific, Measurable, Assignable, Realistic, Time-Based (SMART)), Duration? Cost?
Success Criteria (Outcomes):
Assumptions, Risks, Obstacles:
CSC450CSC450Scoping
25
Problem/Opportunity A statement of fact that everyone in the organization will
accept as true Should communicate why the project should be accomplished
Goal Defines the final deliverable and outcome States in clear terms what is to be accomplished Is a reference point for questions about scope
and purpose of the project “SMART” objectives
CSC450CSC450
Scope Develop Launch Etc.
Developing the Project
Plan: Estimation &
Scheduling
26
27 Five Phases of Project Management
Scoping the Project
Adapted from Weiss, J.W., and Wysocki, R.K. 1992. 5-Phase Project Management: A Practical Planning and Implementation Guide. Reading, MA: Addison Wesley.
Developing the Project Plan
Scoping the Project
Launching thePlan
Monitoring &Controlling
Closing Out the Project
28 Developing The Plan
Construct/AnalyzeProject Schedule
Prepare theProject Proposal
Identify ProjectTasks (WBS)
Estimate Task Duration
Estimate Resource Requirements
CSC450CSC450Estimates and Project Schedule
29
Estimates and project schedule: A work breakdown structure (WBS) is defined.
A list of tasks needed to develop the software. An estimate of the effort required for each
task in the WBS. A project schedule is created by assigning
resources and determining the calendar time required for each task.
CSC450CSC450Resource List
30
The project plan should contain a list of all persons and resources that will be used on the project. A resource is any hardware, software, etc. that
is necessary for the project The resource list should:
Give resource a name Give a brief description of resource List resource availability Specify cost (if applicable)
31
Planning the Project:Work Breakdown Structure (WBS)
• A WBS is the functional decomposition of a system
• Breaks the project into chunks of work at a level of detail that meets planning and scheduling needs
32 WBS Example: Grocery Store
Prepare at home (level 1 task)Create Grocery List (level 2 task)
check pantry for needed items (level 3 task)check refrigerator for needed itemscheck items in refrigerator for expiration date
Determine method of payment
Transport to storeSelect method of transportation, e.g., carSelect route Drive to storePark
Prepare at storeSelect method of holding groceries
Plan for gathering groceries etc.
CSC450CSC450Work Breakdown Structure
33
Software Project
System Engineering Analysis Design Testing
ArchitecturalDesign
DetailedDesign
ProceduralDesign
DatabaseDesign
UserInterfaceDesign
…
AlgorithmDesign
Test CaseDesign
DetermineWork
Patterns
DesignInterface
DesignReview
……
DefineOperationalSignatures
DefinePre/post
Conditions
CSC450CSC450Work Breakdown Structure
34
From an internet source
CSC450CSC450Reality Check
35
Planning is an ongoing activity throughout the life of a project.
36
Scheduling• Similarity to other activities• Historical data• Expert advice
37
Resource Activity• Identify all the resources required
for each activity• Estimate the duration of each
activity
38
Dependencies• Linkage between and among activities/tasks• Dependencies create the backbone of the
project network
39
Dependencies• Finish to start
• Predecessor Task: A
• Successor Task: B
• Arrow head indicates dependency relationship: Task B cannot begin until Task A is complete
A B
40
Gantt Chart• Visual scheduling tool• Graphical representation of information in WBS• Show dependencies between tasks, personnel,
and other resources allocations• Track progress towards completion
Developed by Engineer, Henry L. Gant, 1917.
Henry Laurence Gantt (1861-1919)
41
Building a Gantt Chart• List all tasks and milestones from the WBS
along the vertical axis• List time frame along the horizontal axis
Activity 1
Activity 2
Milestone
Time Frame: day 1 day 2 day3
42
Building a Gantt Chart
• Activities: Create box the length of each activity time duration– E.g., activity one is scheduled from day1-day3
• Milestones: Create a diamond on the day the milestone is scheduled to be completed
Activity 1
Activity 2
Milestone
Time Frame: day 1 day 2 day3
43
Building a Gantt Chart• Dependencies: Show dependencies between activities with
arrows– E.g., activity 2 cannot start until activity 1 is complete
Activity 1
Activity 2
Milestone
Time Frame: day 1 day 2 day3… day 23
44
45
Gantt Chart – Example
Estimated time to complete a task
Task
s
Bars indicate time requirement
Arrows indicate task dependencies: Predecessor task Successor task
46
Responsibility Matrix• Creates accountability by assigning each task to a
personTask Joe Mary Renee
Activity 1 x
Activity 2 x
Activity 3 x
CSC450CSC450Scheduling: Critical Path Method (CPM)
47
CPM developed in 1956/57 by Kelly & Walker for DuPont
Goal Shut down chemical plants for
maintenance, restart plants when maintenance was completed.
CSC450CSC450Scheduling: Critical Path Method (CPM)
48
CPM models the activities and events of a project as a network.
Activities are depicted as nodes on the network Events that signify the beginning or ending of activities
are depicted as arcs or lines between nodes
CSC450CSC450Scheduling: Critical Path Method (CPM)
49
Steps in CPM Project Planning Determine the sequence of activities. Draw a network diagram. Estimate the completion time for each activity. Identify the critical path (longest path through the network) Update the CPM diagram as the project progresses.
CSC450CSC450Program Evaluation and Review Technique (PERT)
50
Steps in PERT Project Planning Determine the sequence of activities. Draw a network diagram. Estimate the completion time for each activity. Identify the critical path (longest path through the network) Update the PERT diagram as the project progresses.
CSC450CSC450
1: Which tasks are on the critical path? 2: What is the slack time for tasks C, D and G? 3: Task C is delayed by one day. What impact
would this have on the completion date of the project? Why?
4: Task A will be delayed by 2 days because some equipment has arrived late. If the project manager wants to finish the project on time he will need to shorten the duration of one or more of the tasks. How can he achieve this?
5: The project manager reduces the durations of tasks D and F by one day each. How will this affect the finishing date of the project?
51
CSC450CSC450
1: Which tasks are on the critical path?
52
ANSWER: A,B,D,F,I
Possible paths:
A,B,C,E,I = 2+3+1+4+3 = 13 days
A,B,D,F,I = 2+3+3+3+3 = 14 days
A,G,H,I = 2+2+5+3 = 12 days
CSC450CSC450
2: What is the slack time for tasks C, D and G?
53
Path C,E = 5 days, Path D,F = 6 days
Path B,C,E = 8 days. Path B, D, F = 9 daysPath G, H = 7 days.
Difference (slack) = 1 day for tasks C or E compared to D,F
So G & H have 2 days’ slack between them. B,C or E have 1 day’s slack. B,D,F have no slack.
TASKS C and D…
TASK G…
CSC450CSC450
54
3: Task C starts one day late. What impact would this have on the completion date of the project? Why?
No impact, because task C has one day’s slack (as discovered in previous question!)
CSC450CSC450
55
4: Task A will be delayed by 2 days because some equipment has arrived late. If the project manager still wants to finish the project within the original time frame, he will need to shorten the time for one or more of the tasks. What steps can he take to reduce the number of days allocated to a task?The answer has NOTHING to do with the chart! Just say how jobs can be finished more quickly, e.g. bringing in extra workers from slack tasks, working longer hours, working weekend, streamlining work practices, automating tasks etc.
CSC450CSC450
56
5: The project manager decides to reduce the time needed for tasks D and F by one day each. How effective will this reduction be in achieving his aim of maintaining the original finish time for the project?
It is only partially effective. Reducing tasks D and F by one day each means the path A,B,D,F,I is now 12 days long. However, path A,B,C,E,I is still 13 days so it becomes the longest path, and therefore becomes the new critical path.
The project is now 13 days long instead of 14, a saving of only one day.
CSC450CSC450Software Project Plan
57
The project plan defines the work that will be done and who will do it. A list of all resources that will be needed for the product
and their availability A work breakdown structure that describes tasks A set of estimates for the tasks A project schedule that identifies when tasks will be
done A list of persons/teams and other resources allocated to
tasks A risk plan that identifies risks and how they will be
handled Project monitoring and control mechanisms Etc.
The preliminary Software Project Plan will have all the available information
CSC450CSC450
Scope Develop Launch Etc.
Project Management
Problems
58
CSC450CSC450Project Management Problems
59
• What does it take to realize a successful project?
CSC450CSC450Lack of Leadership
60
It takes more than a talented and motivated team to make a successful project.
Lack of leadership manifests itself in the team members suffering from: Tunnel vision Over-reliance on gut instincts Repeated false starts in the project
CSC450CSC450The Mid-Course Correction
61
A change in project priorities throws the team into disarray
This usually comes from a lack of understanding of the scope of the project
When the engineers don’t understand the users’ and stakeholders’ needs, they build the wrong software And they might not find out that there’s a
problem until after the work is done!
CSC450CSC450The Detached Engineering Team
62
There is an artificial wall between the people who build the software and those who need it. The business people feel like the
engineers are moving too slowly and don’t care about their needs
The engineers feel like they’re always shooting at a moving target because business people don’t know what they want
CSC450CSC450Solution: Fixing Planning Problems
63
Lack of Leadership, the Mid-Course Correction and the Detached Engineering Team are project planning problems Use a project plan/vision and scope
document to define the needs of the users and stakeholders
Use a project plan to specify how those needs will be met
Use risk planning to keep the plan realistic
CSC450CSC450Solution: Fixing Planning Problems
64
Conflict resolution Arbitration Confrontation + care Negotiation Coordination device Separation Rules
CSC450CSC450Padded Estimates Generate Distrust
65
Programmers add extra time to their estimates They may do this because of
unknowns Often they have been late in the
past, and “know” that they will need extra time
Project managers and senior managers figure this out, and …..
CSC450CSC450Self-Fulfilling Prophecy
66
A project manager under pressure imposes a deadline, and creates unrealistic estimates that meet it The team works nights and weekends to
meet the deadline The project manager feels vindicated The team eventually gets frustrated and
disillusioned
CSC450CSC450Solution: Fixing Estimation Problems
67
Padded estimates and the self-fulfilling prophecy are estimation problems Adopting a repeatable estimation process can
help fix them By writing down assumptions, the team can
handle risks without padding their time – and even avoid the risks altogether
It reduces padding and increases honesty through transparency, by letting the team correct each other in an open meeting
CSC450CSC450Working Backwards From a Deadline
68
Project managers approach a non-negotiable deadline for a project by working backwards They shorten the tasks in the schedule or
cutting them entirely until everything fits When the schedule gets tight, any non-
programming activities are cut and the software is released before it’s finished
CSC450CSC450Misunderstood Predecessors
69
The project manager does not take the time to understand how tasks depend on each other
Problems are discovered partway through the project. One task can’t be started because it depends
on another Delays cascade through the project,
getting increasingly worse Some programmers are stuck waiting with
nothing to do, while others work overtime
CSC450CSC450Solution: Fixing Scheduling Problems
70
Working backwards from a deadline and misunderstood predecessors are symptoms of underlying scheduling problems They can be avoided by adopting good
planning and estimation practices and creating a project schedule
Schedule techniques like critical path analysis can help spot problems early on
CSC450CSC450Problems Are Found Too Late
71
There are preventable defects in the software that aren’t caught until late in the project The team may misunderstand a need - its
not discovered until delivery Requirements may be missed or incorrect The design may be difficult to use or fail to
take all of the features into account
CSC450CSC450Big, Useless Meetings
72
A project manager who has previously been burned by problems that were found too late is determined to avoid falling into the same trap He calls a big meeting with everyone who
could possibly have input The meeting drags on for hours, without
making any real progress Eventually, everyone gives up and goes back
to the way they did things before
CSC450CSC450The Indispensable “Hero”
73
One “critical” person is seen as the clear top designer/programmer, etc. and all important work is sent through him He may have a unique skill or experience He is always working long hours – and
causing bottlenecks
CSC450CSC450Solution: Fixing Review Problems
74
Problems that are found too late, big useless meetings, and the indispensable “hero” are problems which can be solved with reviews Reviews can catch defects early, when they are
cheaper to fix A review meeting only includes the people
necessary for the work to be done Reviews – especially code reviews – can help
the “hero” spread his expertise and knowledge
CSC450CSC450
Scope Develop Launch Etc.
Risk Analysis
75
CSC450CSC450Scoping: Risk Analysis
76
Identify factors that might affect the outcome or completion of the project
Used to alert management to factors that may interfere with project work
Types of assumptions and risks Technological Environmental Interpersonal Cultural Political
76
CSC450CSC450
77
Project Risks
What can go wrong?What is the likelihood?What will the damage be?What can we do about it?
CSC450CSC450
78
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
CSC450CSC450
79
Proactive Risk Management
Formal risk analysis is performed Organization corrects the root causes
of risk TQM concepts and statistical SQA Examining risk sources that lie beyond
the bounds of the software Developing the skill to manage change
CSC450CSC450
80
Seven Principles
1. Maintain a global perspective—view software risks within the context of system and the business problem
2. Take a forward-looking view—think about the risks that may arise in the future; establish contingency plans
3. Encourage open communication—if someone states a potential risk, don’t discount it.
4. Integrate—a consideration of risk must be integrated into the software process
5. 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.
6. 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.
7. Encourage teamwork—the talents, skills and knowledge of all stakeholder should be pooled
CSC450CSC450
81
RISK
Risk Management Paradigm
control
identify
analyze
plan
track
CSC450CSC450
82
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.
CSC450CSC450
83
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?
CSC450CSC450
84
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?
CSC450CSC450
85
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.
CSC450CSC450
86
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.
CSC450CSC450
87
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.
CSC450CSC450
88
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.
CSC450CSC450
89
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
CSC450CSC450
90
Building a Risk Table
Category Probability Impact RMMM
RiskMitigationMonitoring
& Management
Risk Priority
CSC450CSC450
91
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
CSC450CSC450
92
Risk Due to Product Size
• estimated size of the product in LOC or FP?
• estimated size of product in number of programs, files, transactions?
• percentage deviation in size of product from average for previous products?
• size of database created or used by the product?
• number of users of the product?
• number of projected changes to the requirements for the product? before delivery? after delivery?
• amount of reused software?
Attributes that affect risk:
CSC450CSC450
93
Risk Due to Business Impact
• affect of this product on company revenue?
• visibility of this product by senior management?
• reasonableness of delivery deadline?
• number of customers who will use this product
• interoperability constraints
• sophistication of end users?
• amount and quality of product documentation that must be produced and delivered to the customer?
• governmental constraints
• costs associated with late delivery?
• costs associated with a defective product?
Attributes that affect risk:
CSC450CSC450
94
Risks Due to the Customer
• Have you worked with the customer in the past?
• Does the customer have a solid idea of requirements?
• Has the customer agreed to spend time with you?
• Is the customer willing to participate in reviews?
• Is the customer technically sophisticated?
• Is the customer willing to let your people do their job—that is, will the customer resist looking over your shoulder during technically detailed work?
• Does the customer understand the software engineering process?
Questions that must be answered:
CSC450CSC450
95
Risks Due to Process Maturity
• Have you established a common process framework?
• Is it followed by project teams?• Do you have management support for software engineering
• Do you have a proactive approach to SQA? • Do you conduct formal technical reviews?
• Are CASE tools used for analysis, design and testing?
• Are the tools integrated with one another?
• Have document formats been established?
Questions that must be answered:
CSC450CSC450
96
Technology Risks
• Is the technology new to your organization?• Are new algorithms, I/O technology required? • Is new or unproven hardware involved?
• Does the application interface with new software?
• Is a specialized user interface required?
• Is the application radically different?• Are you using new software engineering methods?
• Are you using unconventional software development methods, such as formal methods, AI-based approaches,
artificial neural networks?
• Are there significant performance constraints?
• Is there doubt the functionality requested is "do-able?"
Questions that must be answered:
CSC450CSC450
97
Staff/People Risks
• Are the best people available?• Does staff have the right skills?• Are enough people available?• Are staff committed for entire duration?• Will some people work part time? • Do staff have the right expectations?• Have staff received necessary training?• Will turnover among staff be low?
Questions that must be answered:
CSC450CSC450
98
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 7-1-96
Recording Risk Information
CSC450CSC450Risk Plan
99
A risk plan is a list of all risks that threaten the project, along with a plan to mitigate some or all of those risks. The project manager selects team members to
participate in a risk planning session: The team members brainstorm potential risks The probability and impact of each risk is estimated A risk plan is constructed
CSC450CSC450Risk Plan Example
100
101
Project Scoping FormProject Name Project
ManagerTeam Members
Problem / Opportunity (Why do this project?):
Project Goal:
Objectives (Specific, Measurable, Assignable, Realistic, Time-Based (SMART)), Duration? Cost?
Success Criteria (Outcomes):
Assumptions, Risks, Obstacles:
Summary of Risk Analysis
CSC450CSC450
Scope Develop Launch Etc.
Summary
102
CSC450CSC450The Project
103
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.
CSC450CSC450Common-Sense Approach to Projects
104
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.
CSC450CSC450
To Get to the Essence of a Project105
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
CSC450CSC450Critical Practices106
Formal risk management Empirical cost and schedule
estimation Metrics-based project
management Defect tracking against quality
targets People aware project
management
CSC450CSC450Summary107
In this class we discussed: Software project management Project management activities Teams Project management problems Risk management
CSC450CSC450Summary108 What’s coming next class?
______________________Devon M. Simmonds
Computer Science Department
University of North Carolina Wilmington
_____________________________________________________________
Qu es ti ons?