Management CSEB233 Fundamentals of Software Engineering B Computer Science SE Hons Objectives Discuss the importance of Software Project Management SPM Explain the four Ps of effective project management People Product Process Project ID: 617101
Download Presentation The PPT/PDF document "Software Project" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
Software Project Management
CSEB233: Fundamentals of Software Engineering
B. Computer Science (SE) (Hons.)Slide2
Objectives
Discuss the importance of Software Project Management (SPM)Explain the four P’s of effective project management: People, Product, Process, Project
Explain the W5HH Principle and critical practices for performance-based managementSlide3
Software Project Management
Importance of SPMSlide4
Importance of SPM
Building computer software is complex, particularly if it involves many people working over a relatively long timeThat is why software projects need to be managedSlide5
Software Project Management
Four P’s of Effective SPMSlide6
The Management Spectrum
Effective SPM focuses on four P’s:People T
he 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 realitySlide7
Four P’s: People
People must be organized to perform software work effectivelyThe “people factor” is so important that the Software Engineering Institute has developed People Capability Maturity Model (People-CMM).
The maturity model defines key practice areas like staffing, communication and coordination, work environment, training, career development, team/culture development and others.
Organizations that have a higher levels of People-CMM have a higher likelihood of implementing effective software project management practiceSlide8
Four P’s: People
Stakeholders
Defined as “individuals or organizations who stand to gain or lose from the success or failure of a system”
(
Nuseibeh
& Easterbrook, 2000)
By definition, stakeholders are those who are impacted by, or have an impact on the project, e.g.:
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 workSlide9
Four P’s: People
Stakeholders
By definition, stakeholders are those who are impacted by, or have an impact on the project, e.g.:
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 useSlide10
Four P’s: People
Team Leaders
To be effective, the project team must be organized in a way that maximizes each person’s skills and attributes, which is the job of the team leader
What do we look for when choosing a team leader?
Based on MOI model of leadership by Weinberg (1986):
Motivation, Organization, Ideas or Innovation
Based on four traits of effective project manager by Edgemon (1995):
Problem Solving, Managerial Identity, Achievement, Influence and Team BuildingSlide11
Four P’s: People
Team Leaders
The MOI Model of Leadership:
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
T
he ability to encourage people to create and feel creative even when they must work within bounds established for a particular software product or applicationSlide12
Four P’s: People
Team Leaders
Four traits of effective project manager
Problem solving
Can diagnose relevant technical and organizational issues, systematically structure a solution or motivate others to develop the solution, apply lesson learned from past projects to new situation and many others
Managerial identity
A good manager must take charge of the projectSlide13
Four P’s: People
Team Leaders
Four traits of effective project manager
Achievement
Reward initiative and accomplishment to optimize the team productivity
Influence and team building
Able to ‘read’ people, understand verbal and nonverbal signal and react to the needs of the people sending the signalsSlide14
How to lead?
How to organize?
How to motivate?
How to collaborate?
How to create good ideas?
Four P’s: People
Software TeamSlide15
Four P’s: People
Software Team
The following factors must be considered when selecting a software project team structure:
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 Slide16
Four P’s: People
Agile Team
Agile teams are formed for agile software development
Agile philosophy encourages
customer satisfaction and early incremental delivery of software
small highly motivated project teams
informal methods
minimal software engineering work products, and
overall development simplicitySlide17
Four P’s: People
Agile Team
The distribution of skills must be appropriate to the problem
Mavericks (individualist) may have to be excluded from the team, if team cohesiveness is to be maintained.
Agile teams are self-organizingSlide18
Four P’s: People
Issues
Software projects get into trouble because of:
Scale
The scale of many development efforts is large, leading to complexity, confusion, and significant difficulties in coordinating team members
Uncertainty
Resulting in a continuing stream of changes
Interoperability
New software must communicate with existing software and conform to predefined constraints imposed by the system or productSlide19
Four P’s: People
Issues
Software projects get into trouble because of:
Formal and informal communication among team members and between multiple teams must be established
Formal communication – writing, structured meetings, and other non-interactive and impersonal communication channel.
Informal communication – more personal, members share ideas on ad hoc basisSlide20
Four P’s: Product
Before project can be planned:Establish product objectives and scopeCommunication with the customer and other stakeholders must occur so that product scope and requirements are understood
Identify technical and management constraints
Consider alternative solutions
Enable the managers and practitioners to select a “best” approach, given the constraints imposed by delivery deadlines, budgetary restrictions, personnel availability and other factorsSlide21
Four P’s: Product
Scope
Scope is defined by answering the following questions:
Context
How does the software to be built fit into a larger system, product, or business context?
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?Slide22
Four P’s: Product
Scope
Scope is defined by answering the following questions:
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 levelsSlide23
Four P’s: Product
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 definedSlide24
Four P’s: Process
Once a process framework has been establishedConsider project characteristics
Determine the degree of rigor required
Define a
task set
for each software engineering activity
Software engineering tasks
Work products
Quality assurance points
MilestonesSlide25
Four P’s: Process
Melding Product and ProcessSlide26
Four P’s: Process
Melding Product and Process
In the figure shown in previous slide:
The job of the project manager (and other team members) are to:
estimate resource requirements for each matrix cell
start and end dates for the tasks associated with each cell
work products to be produced as a consequence of each taskSlide27
Four P’s: Process
Project Decomposition
Factors that you need to look at when choosing the process model:
The customers who have requested the product and the people who will do the work
The characteristics of the product itself
The project environment in which the software team worksSlide28
Four P’s: Process
Project Decomposition
Example of type of project and suitable approach:
A relatively small project that is similar to past efforts - linear sequential approach might be suitable
The deadline is so tight that full functionality cannot reasonably be delivered – incremental approach might be suitable Slide29
Four P’s: Project
The project must be planned by estimating effort and calendar time to accomplish work tasksSome of the required activities:
defining work products
establishing quality checkpoints, and
identifying mechanisms to monitor and control work defined by the planSlide30
Four P’s: 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]Slide31
Four P’s: Project
Projects get into trouble when …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 learnedSlide32
Four P’s: Project
Common-Sense Approach to Projects
How does a manager act to avoid the problems?
Start on the right footing
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 waySlide33
Four P’s: Project
Common-Sense Approach to Projects
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 projectSlide34
Software Project Management
The W5HH Principle & Critical PracticesSlide35
The W5HH Principle
A series of questions that lead to a definition of key project characteristics and the resultant project plan
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?
(Boehm, 1996)Slide36
Critical Practices
Example of practices that is important in software project management:Metrics-based project management
Measures of specific attributes of the process, project, and product are used to compute software metrics.
These metrics can be analyzed to provide indicators that guide management and technical actions.
Empirical cost and schedule estimation
Estimate how much money, effort, resources (people, hardware, software), risks, and time that will take to build a systemSlide37
Critical Practices
Defect tracking against quality targetRequires that quality targets be set and that tracked defects be analyzed against those targets.
Involve activities such as:
recording defects in a database
following a documented process to analyze, resolve, and remove them
tracking the process
measuring defects against quality targets; and
reporting metrics on the process to program managementSlide38
Critical Practices
Example of quality measures with examples of target values, are as follows:
Number of defects (a measure of reliability): less than 1 defect per function point
Cyclomatic
Complexity (McCabe's): less than 10 for all modules
Operator errors: Less than 5 per day
Time to restore: less than 1 hour
Timing: less than 1 second response time
Fault tolerance: at least 80% of failures circumvented
Reference:
https://goldpractice.thedacs.com/practices/gp_28.phpSlide39
Critical Practices
Earned value trackingQuantitative technique for assessing progress as the software team progresses through the work tasks allocated to the project schedule
People aware management
Management of people that involve in projectSlide40
Summary
The importance of Software Project ManagementThe four P’s of effective project management: People, Product, Process, ProjectThe W5HH Principle and critical practices for performance-based managementSlide41
Copyright © 2013 M Mahmoud
THE END