2. Project Management Concepts
(Source: Pressman, R. Software Engineering: A Practitioner’s Approach. McGraw-Hill, 2005)
• What are the key concepts that lead to effective SPM?
• How can we measure progress in software projects?
• How can estimate cost and resource requirements for a
software Project, so that we make an effective Project plan?
• How can we ensure the quality of a software Project?
• Pressman discusses those topics in Chapters 3 to 9
3. Project management
3
• “Project management involves the planning,
monitoring, and control of the people, process and
events that occur as software grows from
preliminary concept to operational
implementation.” – Pressman, 2000
• For most projects, important goals are:
▫ Deliver the software to the customer at the agreed time.
▫ Keep overall costs within budget.
▫ Deliver software that meets the customer’s expectations.
▫ Maintain a happy and well-functioning development team.
4. Chapter 3
Project Management Concepts
Effective SPM focuses on 3 P’s:
- The People
- The Problem
- The Process
(Source: Pressman, R. Software Engineering: A Practitioner’s Approach. McGraw-Hill, 2005)
Bla..bla..b
bla.
People
Problems
Start
divide-and-solve
Process
Finish
PROJECT PRODUCT
6. 6
People must be organized to perform
software work effectively.
A process must be selected that is
appropriate for the people and the
product.
The project must be planned by
estimating effort and calendar time to
accomplish work tasks.
Effective SPM focuses on 3 P’s:
7. PEOPLE
• Software engineering work is heavily dependent
on HUMAN FACTOR/WORK.
• In 1988, the engineering vice presidents of three
major technology companies were asked about
the most important contributor to a successful
software project.
8. • VP1: It’s not the tools we use, but it’s the people.
• VP2: It is having smart people. Very little else
matters in my opinion. The most important thing
you do for a Project is selecting the staff.
• VP3: The only rule I have in management is to
ensure I have really good people . Then, I provide
an environment in which good people can work.
• So, Who are the ‘Players’ who participate in the
software development process?
Their answers were as follows:
9. Participants
• 1. Senior Managers: define the business issues. Coordinate
the interface between the business and the software
professionals.
• 2. Project Managers: Plan, motivate, organize and control
people who do technical aspects of work – the practitioners.
Practitioners: Convey necessary technical skills to engineer
product
– A software engineer manages day-to-day activities,
planning, monitoring, and controlling technical tasks.
• 4. Customers & Stakeholders: specify the requirements and
scope for software project.
• 5. End Users: use the software once it is delivered.
10. 10
The People: Team Leaders
• Project Management: is a people-intensive activity.
• So, practitioners often fail to be good team leaders; they just don’t have
the right skills.
• Weinberg’s MOI model->abilities to look for a team leader
▫ Motivation
Ability to encourage technical people to work to the best of their
abilities (push or pull)
▫ Organization
Ability to adapt existing processes, or invent new ones, to enable the
concept to be turned into a product
▫ Ideas/Innovation
Ability to encourage people to create, and to feel creative, within the
bounds of the particular product
11. Problem Solving Experience
• Team leaders should use a problem-solving
management style (acc. to the Weinberg’s model )
– Concentrate on understanding the problem
to be solved
– Manage the flow of ideas
– Team leader must let everyone know
(by words and. by actions) that quality is
important – lead by example!
11
12. 12
Another view of what makes a good
team leader:
• A good Project Manager (PM) is responsible for:
– Problem solving
• Decide which technical and organizational issues are most
important
• Create a systematic solution to the problem – or motivate others to
do so
• Apply lessons from past projects to new ones
• Remain flexible enough to change direction if initial proposed
solution doesn’t work
– Managerial Identity
• Should be ConfidentConfidence to take control of project when
necessary, but also to let good technical people use their initiative
(encourage them to apply their initiative)
– Achievement
• Reward initiative and accomplishment of team members
• Demonstrate that controlled risk-taking will not be punished
– Influence and Team building
• Be able to “read” people – understand both verbal and non-verbal
signals from team members, and react to their needs
(acc. to the Edgemon’s model )
13. 13
The People: The Software Team
• There are many team structures for SW development.
• We shall assume that there are n people in the team.
• OPTION 1:
– n individuals are assigned to m different functional tasks, n<m (5 people, 10 tasks)
– little combined work is done by them.
– Coordination of individuals is the responsibility of the SW manager.
– The manager may be dealing with other projects at the same time (Many-project responsibility).
• OPTION 2:
– n individuals are assigned to m different functional tasks (i.e. 10 people, 5 tasks).
– One person in the team may be appointed as a Team Leader
– But, m<n, so relaxed/informal TEAMs are established.
– Coordination among the TEAMs is the responsibility of the SW Manager.
• OPTION 3 (Team-Oriented):
– n individuals are assigned to t teams. (10 people, 5 teams).
– Each team is assigned one or more functional tasks
– Each team has a specific structure.
– Coordination is controlled by both the team leader and a SW Manager.
14. 14
The People: The Software Team
• Most people think that OPTION 3, that is, a formal team organization is most
PRODUCTIVE!
• The BEST team structure depends on:
– The management style of the organization
– The # of people who will participate in Teams and their skill levels,
– The difficulty of the overall project.
16. Mantei(81):team structures
• SW teams can be organized into number of
different team structures
• appropriate team structure depends on
type of problem task
• 3 generic team organizations
17. 17
The People: The Software Team
(continued)
Mantei suggests three types of organizational paradigms for software development
teams:
1)Democratic Decentralized (DD)
– No permanent leader.
– task coordinators appointed for short time and then replaced
– decisions made by group consensus (
taken joint decisions)
– horizontal communication (no hierarchy)
2)Controlled Decentralized (CD)
– There is a defined leader who coordinates tasks
– There are secondary leaders who responsible for subtasks
– Group problem solving- Implementation of solution is partitioned
among subgroups by the Team Leader (group problem solving)
– Horizontal communication among subgroups
– Vertical communication along control hierarchy
18. 18
The People: The Software Team
(continued)
3) Controlled Centralized (CC)
– There is a defined leader.
– The leader manages top level problem solving and internal team
coordination.
– Vertical communication between leader and team members.
Table 3.1 P.63 in text - summarizes impact of project characteristics on team
structure (Mantei 81)
19. D model has more sociability (girişken)!
CC/CD has fewer
defect than DD
DD is best for low
Modularity bcz higher
communication in team
DD is best for Long Team
Life: bcz, high team morale,
live together,job satisfaction
CC/CD is best subgrouping
20. Project structures
• Since centralized model completes tasks faster - better at
handling simple problems.
• Decentralized model - generates more and better solutions
so better at more difficult problems.
• Controlled Decentralized (CD) team or CC (Controlled
Centralized) team
• DD structure is the best for Difficult Problems.
• Very large projects are best addressed by CC and CD
teams. Bcz, subgrouping helps to reduce the amount of
communication that must be conducted.
20
21. Project structures
• DD teams bring about higher moral and job satisfaction. So,
DD is suitable for a long time group work.
• Bcz, in DD teams, a high amount of communication is needed.
So the DD team structure is best for problems with relatively
low modularity (low size of project).
• When high modularity (high size of project) is possible (and
people can do their own parts alone), the CC and CD structure
should be preferred.
• CC and CD type teams have been found to Produce Fewer
Defects than DD type teams.
• Decentralized teams generally require more time to
complete a project.
• Also, they are better when high socaibility (friendliness) is
required.
21
22. 22
The Montei also described the seven important
project factors when organizing a team:
– The difficulty of the problem to be solved.
– The size of the resultant program(s) in source lines of code / LOC.
– The time that the team will stay together.
– The degree to which the problem can be modularized.
– The required quality and reliability of the system to be built.
– The inflexibility of the delivery date.
– The degree of sociability (communication) required for the
project.
25. 1.Closed Paradigm: (Similar to CC)
• Tradional/team work based always on standard
tasks
• Works well especially if teams are working on
projects that are similar to the ones completed in the
past (previous completed projects).
• There is a strict hierarchy of authority.
• Can not be innovative (bringing in new ideas,
processes, new innovations.)
26. 2.Random Paradigm
• The team is inaccurately (loosely) structured,
depends on individual initiative of the team
members.
• These type of teams will be successful when
innovation or a technological advance is required
(for example, developing software for a new
machine).
• When routine projects (similar projects) are
considered or performed, this organization may
cause problems.
27. 3. Open Paradigm:
• A combination of the Open = Closed + Random
paradigms.
• There is strict hierarchy of authority like in the Closed
paradigm, can also be innovative like the Random
paradigm.
• Work is performed collaboratively, and there is a lot of
communication, decision making is based on the
consensus of the team.
• Suitable for solving complex problems.
• Not as efficient as other paradigms.
28. 4. Synchronous Paradigm:
• Suitable for problems that can be divided easily into
sub problems.
• Team members are organized to work on sub
problems with little communication.
29. Senior Eng.
(Chief
Programmer)
Backup
Eng.
Technical Staff
2-7 People
Helps the senior
Eng. (can replace
him/her if needed)
Plans,
Coordinates,
reviews all
activities
Systems analysis
Software
development
Software
Librarian
Figure. Earliest software team organization model.
Chief programmer team (Harlas Hills, Baker) similar to CC.
30. 1.The chief programmer may be served:
– by one or more specialists (i.e. Database designer, telecom, expert,...),
– by support staff (i.e. Secretaries, technical writers)
– a software librarian.
2.The software librarian serves many teams.
– His/she maintains and controls source listings, data, backups and
documentation.
– Also collects software productivity parameters of technical staff and
assists teams in research, evaluation and document preparation.
*Good teams should have same «Team Spirit».
31. Coordination & Communication in SW Projects
• There are many reasons that SW projects run into problems:
– The problem to solve is too large, complex or confusing, so the team
members cannot be coordinated property.
– There is a lot of uncertainty in the early stages of the problem definition
and this results in many changes in requirements.
– Modern SW Eng. requires interoperability: a new SW must communicate
with existing modules properly and satisfy the predefined constraints.
• So, a SE team must found effective methods for coordinating the
team members.
• Formal and informal communication mechanisms within teams,
and between teams must be established properly.
– For Formal Communication: write reports, organize meetings.
– For Informal Communication: mostly something personal, team members
share ideas, ask for help of others, interact with one another daily.
32. Kraul and Streeter’s Collection of
Project Coordination Techniques
A) Formal, impersonal approaches:
– Source code, SE documents (e.g., systems
requirements), technical memorandums, project
milestones, projects schedules, project control tools,
requests for change, error tracking reports.
B) Formal, interpersonal procedures: Quality
assurance activities applied to SE products.
– Status review meetings, design meetings, code reviews.
32
33. C) Informal, Interpersonal Procedures:
– group meetings to inform all team members,
– group meetings for problem solving.
D) Electronic Communication:
– E-mail, bulletin/discussion boards, shared websites, video
conferencing.
E) Interpersonal Network:
– Informal discussions with those outside the company, who
(e.g., software consultants, e.g. ASELSAN) have experience
and insight that can help team members working on the
Project
35. II. The Problem
• A SW Project manager has a difficult task at the beginning
of a new project.
– There’s no much information about project,
– but some quantitative estimates (like how much time will be
needed, how many programmers are needed) and
– a project organization plan is required.
• A detailed analysis of software requirements will provide
this information eventually.
• But this study takes a lot of time (weeks or months).
• The requirements may be changing during the projects,
which make things worse.
• So, what to do at the beginning of the project?
36. Define Software Scope
• First activity is to determine the software scope by the
project manager.
• This can be done by answering the following questions:
1. How does the SW to be developed fit into a larger system?
(context) What constraints are compulsory?
2. What customer-visible objects are to be produced? What data
objects are required for input? (Information Objectives)
3. What function will the software perform to transform input data
to outputs? (Any special performance characteristics?) (Function
and Performance)
37. • Project scope must be understandable, and unmistakable
for the project manager.
• A statement of project scope must be bounded, so
quantitative data (e.g., no. of simultaneous users, max.
allowable response time) are stated explicitly.
• Constraints and/or limitations are noted. (e.g., if the product
is thought to be cheap, memory size may be restricted, etc.)
• Algorithms to be used are well understood and properly
described.
