Software Engineering Project Management

1. Software Engineering
(CSI 321)
Project Management
1

2. What is a Project?
 Project : A planned undertaking of related
activities to reach an objective that has a
beginning and an end.
2

3. What is Project Management?
• Project management is a controlled process of initiating,
planning, executing, and closing down a project.
• Project management involves the planning, monitoring, and
control of the people, process, and events that occur as
software evolves from a preliminary concept to full
operational deployment.
• Software project management is an umbrella activity within
software engineering.
– It begins before any technical activity is initiated and
continues throughout the modeling, construction, and
deployment of computer software.
3

4. What is Project Management?
• Managing the accomplishments of a software
development project according to a specific project
plan, in order that a project is completed on time,
and within its budget , and meets its design
objectives.
• Project management activity encompasses
measurement and metrics, estimation and
scheduling, risk analysis, tracking , and control.
4

5. Why Project Management is important?
• Developing computer software is a complex undertaking,
particularly if it involves many people working over a
relatively long time. That’s why software projects need to be
managed.
• Software project management is an essential part of software
engineering and may be the most important aspect of
software development.
• Effective Project Management helps ensure system
development projects –
– Meet customer expectations
– Delivered within budget and time constraints
5

6. The Management Spectrum
 Effective software project management focuses
on the four P’s:
1) People – Organized, motivated, coordinated
2) Product – Requirements well-understood
3) Process – Appropriate for people & product
4) Project – Must be organized in a manner that
enables the software team to succeed.
6

7. People: The Stakeholders
1) Senior managers/Business managers –defines business
issues that often have significant influence on the project
2) Project(technical) managers –must plan, motivate, organize,
control practitioners who do software work
3) Practitioners –deliver the technical skills that are necessary
to develop a product
4) Customers –specify the requirements for the software to be
engineered
5) End-users –interact with the software once it is released for
production use
7

8. Characteristics of Team Leader/Project Manager
 A model of leadership: The MOI model
• Motivation - Ability to encourage technical people to
produce to their best ability.
• Organization – Ability to mold existing processes that will
enable initial concept to be translated into a final product.
• Innovation- Ability to encourage people to create and feel
creative.
• Successful project leaders apply a problem solving management style. A
software project manager should concentrate on understanding the
problem to be solved, managing the flow of ideas, and at the same time,
letting everyone on the team know that quality counts & that it will not be
compromised.
8

9. Characteristics of Team Leader/Project Manager
 An effective project manager emphasizes four key
traits:
1) Problem solving
2) Managerial identity
3) Achievement
4) Influence and team building
9

10. Software Teams
10
How to lead?
How to organize?
How to create good ideas?How to motivate?
How to collaborate?

11. Software Teams
 What factors should be considered when the structure of a
software team is chosen?
– 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
11

12. “Organizational Paradigms” for Software Teams
 Software engineers can be organized in a number of different
team structures:
• 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.
12
…suggested by Constantine [CON93]

13. Avoid “Team Toxicity”
 Why do many software teams suffer from “Team Toxicity”? // What are
the five factors that foster a potentially toxic team environment?
1) A frenzied work atmosphere in which team members waste energy and
lose focus on the objectives of the work to be performed.
2) High frustration (caused by personal, business, or technological factors )
that causes friction among team members.
3) A “Fragmented or poorly coordinated” software process or a poorly
defined or improperly chosen process model that becomes a roadblock to
accomplishment.
4) Unclear definition of roles on the software team (resulting in a lack of
accountability and resultant finger-pointing).
5) “Continuous and repeated exposure to failure” that leads to a loss of
confidence and a lowering of morale.
13

14. Agile Software Development
 The characteristics of Agile Software Development
– Adaptable and incremental software process
– Encourages customer satisfaction
– Incremental delivery of software
– Small, highly motivated project teams
– Informal methods
– Overall development simplicity
14

15. Agile Teams
• An agile team is a self-organizing team that has
autonomy to plan and make technical decisions.
• 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.
• Stresses individual (team member) competency
coupled with group collaborations as critical success
factors for the team.
15

16. Agile Teams
• Team is “self-organizing”
– A small, highly motivated, and adaptive team
structure
– Uses elements of Constantine’s random, open,
and synchronous paradigms
– Significant autonomy
16

17. Team Coordination & Communication
 Formal, impersonal approaches
– SE documents and work products, project milestones, schedules,
change request documents, error tracking reports
 Formal interpersonal approaches
– review meetings, inspections
 Informal interpersonal approaches
– group meetings for information dissemination and problem solving
 Electronic communication
– e-mail, video conferencing
 Interpersonal network
– Informal discussions with team members and those outside the
project who may have experience or insight that can assist team
members
17

18. The Product
 The Product(Software) scope: Software project scope must be
unambigguous and understanable at the management and
technical level. Scope is defined by answering the following
questions –
• Context: How does the s/w to be built fit into a larger system or
business context? What are constraints?
• Information objectives: What customer-visible data objects are
produced as output? What data objects are required for input?
• Function: What functions does the s/w perform to transform input
data into output?
• Performance: Are there any special performance characteristics to
be addressed?
18

19. The Product
 Problem decomposition
• Also called partitioning or problem elaboration
• Sits at the core of software requirements analysis
• Applied in two major areas
i. Functionality that must be delivered
ii. The process used to deliver it
• To develop a reasonable project plan, you must decompose
the problem.
– List of functions/use-cases
– User stories(for agile work)
19

20. The Process
• Common Process Framework Activities:
– Communication
– Planning
– Modeling
– Construction
– Deployment
• Work tasks may vary but the common process framework
activities are invariant. The framework activities that
characterizes the software process are applicable to all
software projects. The problem is to select the process model
that is appropriate for the software to be engineered by the
project team.
20

21. The Process
• The project manager must decide which process
model is most appropriate for –
– customers
– developers
– characteristics of the product
– project development environment
21

22. Customer Communication Activity
 Customer Communication Activities for a small and
relatively simple project:
– Develop list of communication issues
– Meet with customer to address clarification issues
– Jointly develop a statement of scope (Statement of Work)
– Review statement of scope/work (SoW) with all concerned
– Modify SoW as required
22

23. Customer Communication Activity
 Customer Communication Activities for a large and relatively
complex project:
– Review customer request
– Plan and schedule formal meeting with customer (regular)
– Conduct research to specify the proposed solution and existing
approaches
– Prepare working doc and agenda for the formal meeting
– Conduct the meeting
– Jointly develop mini-scope
– Review SoW with all concerned
– Modify SoW doc as required
23

24. The Project
 What are signs that a software project is in jeopardy?
– 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.
24

25. Common-Sense Approach to Manage
Software Projects
• Start on the right foot : Accomplished by working hard (very hard) to
understand the problem that is to be solved and then setting realistic
objectives and expectations.
• Maintain momentum: 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 : Progress is tracked as work products are produced and
approved as part of a QA activity.
• Make smart decisions: “keep it simple.”
• Conduct a postmortem analysis: Establish a consistent mechanism for
extracting lessons learned for each project.
25

26. The W5
HH Principle
 How to define key project characteristics?
==> Barry Boehm’s W5
HH Principle
• Why is the system being developed?
• What will be done?
• When will it be done?
• Who is responsible for a function?
• Where are they organizationally located?
• How will the job be done technically & managerially?
• How much of each resource is needed?
26

27. Critical Software Practices
• Formal risk management
• Empirical cost and schedule estimation
• Metric-based project management
• Earned value tracking
• Defect tracking against quality targets
• People-aware program management
27