Chapter 1 Introduction to Software Project Management

Learning outcomes:
Describe SoftwareManagement functions (C1) Explain the management activity (C2) Discuss the responsibility of software project managers (A2)

Chapter 1: Introduction to Software Project management

Topics covered Software project Management functions and activities Software management structures

Chapter 1: Introduction to Software Project management

What is Software?

What is Software engineering?

Chapter 1: Introduction to Software Project management 3

What is Software?

Software is: (1) instructions (computer programs) that when executed provide desired features, function, and performance; (2) data structures that enable the programs to adequately manipulate information and (3) documentation that describes the operation and use of the programs.

Chapter 1: Introduction to Software Project management 4

What is Software?

Software is developed or engineered, it is not manufactured in the classical sense.

Software doesn't "wear out." Although the industry is moving toward componentbased construction, most software continues to be custom-built.

Chapter 1: Introduction to Software Project management 5

Software Engineering Some realities:

a concerted effort should be made to understand the problem before a software solution is developed design becomes a pivotal activity software should exhibit high quality software should be maintainable

The seminal definition:

[Software engineering is] the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines.

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGrawHill 2009). Slides copyright 2009 by Roger Pressman.

Software Engineering The IEEE definition:

Software Engineering: (1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1).

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

What is a Project?

A project is a temporary endeavor undertaken to create a unique product, service, or result [Project
Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK Guide), 4th edition]
Chapter 1: Introduction to Software Project management 8

What is a Project management?

What is Software Project Management?

Chapter 1: Introduction to Software Project management

Software project management Concerned with activities involved in ensuring that software is delivered on time and on schedule and in accordance with the requirements of the organisations developing and procuring the software.

Project management is needed because software development is always subject to budget and schedule constraints that are set by the organisation developing the software.

Chapter 1: Introduction to Software Project management

10

Success criteria Deliver the software to the customer at the agreed time.

Keep overall costs within budget.

Deliver software that meets the customers expectations. Maintain a happy and well-functioning development team.

Chapter 1: Introduction to Software Project management

11

Software management distinctions The product is intangible.

Software cannot be seen or touched. Software project managers cannot see progress by simply looking at the artefact that is being constructed.

Many software projects are 'one-off' projects.

Large software projects are usually different in some ways from previous projects. Even managers who have lots of previous experience may find it difficult to anticipate problems.

Software processes are variable and organization specific.

We still cannot reliably predict when a particular software process is likely to lead to development problems.
Chapter 1: Introduction to Software Project management 12

Management activities Project planning

Project managers are responsible for planning, estimating and scheduling project development and assigning people to tasks.

Reporting
Project managers are usually responsible for reporting on the progress of a project to customers and to the managers of the company developing the software.

Risk management
Project managers assess the risks that may affect a project, monitor these risks and take action when problems arise.

Chapter 1: Introduction to Software Project management

13

Management activities People management

Project managers have to choose people for their team and establish ways of working that leads to effective team performance

Proposal writing
The first stage in a software project may involve writing a proposal to win a contract to carry out an item of work. The proposal describes the objectives of the project and how it will be carried out.

Chapter 1: Introduction to Software Project management

14

The Management Spectrum - The Four Ps 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

15

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

PEOPLE - Stakeholders
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.
These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides

16

PEOPLE- Software Teams

How to lead?
How to organize? How to collaborate?

How to motivate?

How to create good ideas?

17

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

Team Leader The MOI Model

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. 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.

18

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides

Software Teams
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
These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

19

Software Team- Organizational Paradigms

closed paradigmstructures a team along a traditional hierarchy of authority (work well when producing software that is quite similar to past efforts) random paradigmstructures a team loosely and depends on individual initiative of the team members (when innovation is required) open paradigmattempts 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 (for complex problem- work is performed collaboratively, heavy communication & consensus-based decision making) synchronous paradigmrelies on the natural compartmentalization of a problem and organizes team members to work on pieces of the problem with little active communication among themselves suggested by Constantine [Con93]
20 These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

Avoid Team Toxicity

A frenzied work atmosphere in which team members waste energy and lose focus on the objectives of the work to be performed.

High frustration caused by personal, business, or technological factors that cause friction among team members.
Fragmented or poorly coordinated procedures or a poorly defined or improperly chosen process model that becomes a roadblock to accomplishment. Unclear definition of roles resulting in a lack of accountability and resultant finger-pointing. Continuous and repeated exposure to failure that leads to a loss of confidence and a lowering of morale.

21

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

Agile Teams
Encourages customer satisfaction and early incremental delivery software, small highly motivated project teams, informal methods, minimal software engineering work products, and overall development simplicity 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 Constantines random, open, and synchronous paradigms

Significant autonomy
These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

22

Team Coordination & Communication

Formal, impersonal approaches include software engineering documents and work products (including source code), technical memos, project milestones, schedules, and project control tools change requests and related documentation, error tracking reports, and repository data
Formal, interpersonal procedures focus on quality assurance activities applied to software engineering work products. These include status review meetings and design and code inspections. Informal, interpersonal procedures include group meetings for information dissemination and problem solving and collocation of requirements and development staff. Electronic communication encompasses electronic mail, electronic bulletin boards, and by extension, video-based conferencing systems. Interpersonal networking includes informal discussions with team members and those outside the project who may have experience or insight that can assist team members.
These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides

23

People management factors Consistency

Team members should all be treated in a comparable way without favourites or discrimination.

Respect
Different team members have different skills and these differences should be respected.

Inclusion
Involve all team members and make sure that peoples views are considered.

Honesty
You should always be honest about what is going well and what is going badly in a project.
Chapter 1: Introduction to Software Project management 24

Managing people People are an organisations most important assets. The tasks of a manager are essentially people-oriented. Poor people management is an important contributor to project failure.

Chapter 1: Introduction to Software Project management

25

The Product Scope Scope

Context. How does the software to be built fit into a larger system, product, or business context and 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? 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 levels.
These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 26

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 defined

27

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides

The Process Once a process framework has been established

Consider project characteristics Determine the degree of rigor required Define a task set for each software engineering activity
Task set = Software engineering tasks Work products Quality assurance points Milestones

28

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides

Melding the Problem and the Process

29

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

The Project
Projects get into trouble when
Software people dont understand their customers 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.

30

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides

Common-Sense Approach to Projects

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 teams 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.
31 These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides

To Get to the Essence of a Project

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 [Boe96]
32 These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill 2009). Slides

Key points
Good project management is essential if software engineering projects are to be developed on schedule and within budget. Software management is distinct from other engineering management. Software is intangible. Projects may be novel or innovative with no body of experience to guide their management. Software processes are not as mature as traditional engineering processes. Effective software project management focuses on the 4 Ps: People, Product, Process and Project. Software project manager plays a major role in software project management activities

Chapter 1: Introduction to Software Project management

33

References Sommerville, I. (2011). Software Engineering,9th edition, Pearson Education Inc. Pressman, R.S. (2009).Software Engineering: A Practitioners Approach, 7th edition, McGraw-Hill.

Chapter 1: Introduction to Software Project management

34