3-cha
-
Upload
rahulmhatre26 -
Category
Documents
-
view
217 -
download
0
Transcript of 3-cha
-
8/7/2019 3-cha
1/26
Chapter 3 -- R. A. Volz -- Assistance - DavidMar
Project Management Concepts
Why is project management important? Cost
o Dod already spending $30 billion annually onsoftware in late 80so The US spent $150 billiono $225 billion worldwide
Projects frequently fail or have severe difficultieso New FAA air traffic control systemo They dont meet specificationso They take much longer than expected
-
8/7/2019 3-cha
2/26
Chapter 3 -- R. A. Volz -- Assistance - DavidMar
Why Do Major EngineeringUndertakings Often Fail?
Large projects often fail for two principalreasons:
Communication: Inadequate communicationleads to project failure
Coordination: Lack of communication implies
that the team can not coordinate. Thus eachgroup moves in an independent direction and theproject will grind to a halt.
-
8/7/2019 3-cha
3/26
Chapter 3 -- R. A. Volz -- Assistance - DavidMar
Why Do Major EngineeringUndertakings Often Fail?
Large projects often fail for two principalreasons:
Communication: Inadequate communicationleads to project failure
Coordination: Lack of communication implies
that the team can not coordinate. Thus eachgroup moves in an independent direction and theproject will grind to a halt.
-
8/7/2019 3-cha
4/26
Chapter 3 -- R. A. Volz -- Assistance - DavidMar
The Spectrum of ManagementConcerns
Effective Software managementencompasses three main areas:
The People The product
The process
o
The project
-
8/7/2019 3-cha
5/26
Chapter 3 -- R. A. Volz -- Assistance - DavidMar
People
The Players -- It is important to recognizethe different categories of people involvedin a large software project.
Senior Managers - who define business issues. Project (technical) Managers - who plan,
motivate, organize and control the practitioners Practitioners - who deliver the technical skill
that are necessary to engineer the project Customers - who specify the requirements
End users - who interact with the software onceit is released.
-
8/7/2019 3-cha
6/26
Chapter 3 -- R. A. Volz -- Assistance - DavidMar
Team Leadership -- A Critical Item
The Problem The best programmers often make poor team
leaders.
Different skills are required. Technical leadership model Motivation - The ability to encourage technical
people to produce to their best ability.
Organization - The ability to mold existingprocesses that will enable the initial concept tobe translated into reality.
Ideas and Innovation - The ability to invite
creativeness even within a set of restrictions.
-
8/7/2019 3-cha
7/26
Chapter 3 -- R. A. Volz -- Assistance - DavidMar
Key characteristics EffectiveProject Manager
The Problem solving ability
Achievement
Managerial identity
Influence and team building
-
8/7/2019 3-cha
8/26
Chapter 3 -- R. A. Volz -- Assistance - DavidMar
Team Organizational Models
Marilyn Mantei model: Democratic decentralized (DD). -- Does not have a
defined leader. Task Coordinators are appointed to
assure that a particular job is to be executed. Theseare later replaced by other Task Coordinators asnew tasks arise.
Controlled decentralized (CD) -- Has a definedleader who coordinates tasks, and secondary
leaders who carry out subtasks. Problem solving isdone by the group, implementation is done bysubgroups.
Controlled Centralized (CC) - Top-level problemsolving and team coordination managed by the teamleader. The communication between the leader and
members is vertical.
-
8/7/2019 3-cha
9/26
-
8/7/2019 3-cha
10/26
Chapter 3 -- R. A. Volz -- Assistance - DavidMar
Impact of Project Characteristics
-
8/7/2019 3-cha
11/26
Chapter 3 -- R. A. Volz -- Assistance - DavidMar
Other Underlying OrganizationalFactors
Matrix model The organization has divisions organized by
skills, e.g., engineering, safety and mission
assurance (SMA), human factors, etc. Projects rent people from the divisions, as
needed. Issues
Who evaluates person for raises? Independence of reporting for safety & quality
issues? Who is boss?
-
8/7/2019 3-cha
12/26
Chapter 3 -- R. A. Volz -- Assistance - DavidMar
Other Underlying OrganizationalParadigms
Constantine model
Closed Paradigm
Random Paradigm
Open Paradigm
Synchronous Paradigm
-
8/7/2019 3-cha
13/26
Chapter 3 -- R. A. Volz -- Assistance - DavidMar
How Do We Communicate?
Informally - Good phone/electronicservice, a clear definition of group
interdependencies and good relationshipshelp encourage communication
Meetings - Regular project meetings help
alleviate minor misunderstandings
Workbook - a formal project workbookmust be started from the beginning.
-
8/7/2019 3-cha
14/26
Chapter 3 -- R. A. Volz -- Assistance - DavidMar
Project Coordination techniques
Formal, impersonal approaches - softwareengineering documents and deliverables,
technical memos, project milestones, schedulesand control tools Formal interpersonal procedures - quality
assurance activities - reviews and design andcode inspections
Informal, interpersonal procedures - groupmeetings
Electronic communication - Email, bulletinboards, web sites, extension and video
conferences
-
8/7/2019 3-cha
15/26
Chapter 3 -- R. A. Volz -- Assistance - DavidMar
A Study on the Impact ofCoordination Techniques
-
8/7/2019 3-cha
16/26
Chapter 3 -- R. A. Volz -- Assistance - DavidMar
The Problem
Must first determine project scope. Context - How does this software to be built fit
into the larger system? What constraints are
imposed as a result of this? Information objectives - What customer-visible
objects are produced from the software? Whatdata objects are necessary for input?
F
unction and performance - What functions oractions does the software perform to transform theoutput?
The stability, or lack thereof, of the projectrequirements is a major factor in project
management.
-
8/7/2019 3-cha
17/26
Chapter 3 -- R. A. Volz -- Assistance - DavidMar
The Problem Decomposition
Partitioning of problem.
Functional Partition functionallyindependent area
Process that will deliver the functionality
D
ivide and conquer strategy
-
8/7/2019 3-cha
18/26
Chapter 3 -- R. A. Volz -- Assistance - DavidMar
The Process Select a software engineering model according
to
Environment in which team works
characteristics of product
People Customers , developers and users.
-
8/7/2019 3-cha
19/26
Chapter 3 -- R. A. Volz -- Assistance - DavidMar
Melding the Product and The Process
Task framework. Activities
Customer communication- Req. elicitation
Planning -- determine resources, time line & other inf
Risk analysis -- assess technical and managementrisks Engineering -- build one or more representationsof the product.
Construction and release -- construct, test, installand provide user support.
Customer evaluation -- obtain feedback onproduct
-
8/7/2019 3-cha
20/26
Chapter 3 -- R. A. Volz -- Assistance - DavidMar
Common Process FrameworkActivities
-
8/7/2019 3-cha
21/26
Chapter 3 -- R. A. Volz -- Assistance - DavidMar
Process Decomposition
Typical activitieso Review the customer request.o Plan and schedule a formal, facilitated meeting with
the customer.o
Conduct research to define proposed solutions &existing solutions.o Prepare a working document and meeting
agenda.o Conduct meeting with customer.o Jointly develop mini-specs for the product which
reflect data, function, behavioral features of s/wo Review each mini-spec for correctness, lack of
ambiguity.oAssemble the mini-specs into a scoping document.
-
8/7/2019 3-cha
22/26
Chapter 3 -- R. A. Volz -- Assistance - DavidMar
Problems in project management
Typical problemso S/w people dont understand customer needs.o Poorly defined product scope.o Changes managed poorly.o Selected technology changes.o Business needs change.o Unrealistic deadlines.o Users are resistant.o Sponsorship lost.o Team lacks people with appropriate skills.o Managers avoid best practices and lessons
learned.
-
8/7/2019 3-cha
23/26
Chapter 3 -- R. A. Volz -- Assistance - DavidMar
approach
Doo Start on right foot.Work hard to understand problem
and set realistic goals & expectations , build rightteam with autonomy , authority and technology .
o
Maintain momentum do not let your project toshut down after good start.o Track progress monitor progress with work
products and quality assurance activities.o Make smart decisions Decide correctly for use of
components , risk management , priority of worketc..
o Conduct Postmortem analysis Extract lessonsfrom each project and apply them in new projects ,
use customer, developer feedbacks for this.
-
8/7/2019 3-cha
24/26
Chapter 3 -- R. A. Volz -- Assistance - DavidMar
The Boehms W5HH principle
Why is system being developed ?
What will be done ? And
By when ?
Who is responsible for a function ?
Where are they organizationally located?
How will the job be done ? ( Technically or managerially)
How much of each resource is needed?
-
8/7/2019 3-cha
25/26
Chapter 3 -- R. A. Volz -- Assistance - DavidMar
Critical Practices
Formal risk management ( document risks thatcan turn into problems)
Empirical cost and scheduleestimation(estimation of size and methods toestimate)
Metric based project management (any metric tool
that indicates the evolving problems) Earned value tracking (collection monthly earnedvalue , how you compute these.)
Defect tracking against quality targets(Account
for number of defects ) Peo le aware ro ram mana ement avera e
-
8/7/2019 3-cha
26/26
Chapter 3 -- R. A. Volz -- Assistance - DavidMar
Summary
Software project management is an umbrellaactivity that continues throughout the life cycle ofthe system.
Software management includes people, theproblem, and the process.
The most critical element in all software systemprojects is the people. The team can have an
number of structures that effect the way work isaccomplished. However, complete, consistent problem
definition and an effective process are also
essential ingredients.