Spm Lecture1 2

8/3/2019 Spm Lecture1 2

1/14

1

G64SPMSoftware Project Management

Dr. Ender [email protected]

Office: C41

School of Computer Science

G64SPM - Dr. Ender zcan -Introduction 2

Background

Module Activities:2 hours per week

AssessmentOne hour written examination (50%)

A coursework (50%)

Module web page can be reached from: http://cs.nott.ac.uk/~exo/teaching


2/14

2


Summary of Content

This course considers the activities which arerequired, and the tools which are available, tomanage commercial software development projects.

Systems analysis is presented as a way of gatheringand structuring information such that the requiredspecification corresponds closely to the users'requirements.

Systems design is then presented as a technique fortransforming the specification to a form in which itcan be implemented.

Case studies will be used to illustrate many of thetools and techniques introduced.


Educational Aims

This module aims to give students anunderstanding of the tools and techniques

which may be used to manage softwaredevelopment projects and designcommercial software


3/14

3


Resources An introduction to management science : quantitative

approaches to decision making / David R. Anderson,Dennis J. Sweeney, Thomas A. Williams.

Systems analysis and design / Kenneth E. Kendall, JulieE. Kendall.

Applied Software Project Management / AndrewStellman, JenniferGreene

NOT REQUIRED FOR THIS MODULE

Lecture notes can be reached from: http://cs.nott.ac.uk/~exo/teaching

Acknowledgement: Lecture notes of Ben Moss and UweAickelin are used while preparing the slides.


Examinable Material

Lecture Notes Whats written on the slides

Lecture Content Whats said Whats written on the whiteboard

Lecture Exercises Questions: At the end of each lectures notes Answers: Said or written at the start of the following

lecture


4/14

4

Introduction


Content

Basic terminology Who needs/builds software?

Sofware engineering

Sofware project management

Project failures Success criteria for projects

The role of SPM in improving (Why to study SPM?)

How to avoid failure


5/14

5


Who needs software?

Most software is built in organizations for people withspecific needs.

A stakeholder is a anyone who has an interest (or stake)in the software being completed

A user is someone who will need to use the software toperform tasks.

Sometimes stakeholders will be users; but often the

stakeholder will not use the software. For example, a senior manager (like a CEO or CTO in a

company) will usually have a stake in the software that is built(since it affects the bottom line), even if she wont ever use it.


Who builds software?

Business analystsor requirements analystswhotalk to users and stakeholders, plan the behaviorof software and write software requirements

Designers and architectswho plan the technicalsolution

Programmerswho write the code

Testerswho verify that the software meets itsrequirements and behaves as expected


6/14

6


Systems development life cycle


Is software engineering

A manageable task? Programming is a

highly creative

process, with anenormous space offlexibility

Really engineering?

Generalized Engineering Activity

Formulation of a task

Analysis of a task

Design, searching for alternativesolutions

Design, selection of the mostappropriate solution

Specification of the appropriatesolution


7/14

7


Software Project Management

It is about large-scale, long-term softwaredevelopment projects

The project manager plans and guides thesoftware project The project manager is responsible for identifying the

users and stakeholders and determining their needs The project manager coordinates the team, ensuring

that each task has an appropriate software engineerassigned and that each engineer has sufficientknowledge to perform it

To do this well, the project manager must be familiarwith every aspect of software engineering anddecision making concepts

Why to study SPM?


8/14

8


Strict Success Criteria forSoftware Projects

A software project can be consideredsuccessful if:The software is delivered on schedule

.

Development costs were within budget

.The software meets the needs of users (in

scope and quality)


Loose Success Criteria forSoftware Projects

A software project can be consideredsuccessful if:

The software is delivered around schedule(perhaps with a reasonable delay)

Development costs were within budgetwithout exceeding an expected deviation

The software meets the basic (most of the)needs of users (in scope and quality)


9/14

9


Software Hall ofShame

http://www.spectrum.ieee.org/sep05/1685/failt1

Quotations(Mike Ward, Gordian Enterprises Associate)

31% of application development projects are cancelled,53% cost 189 percent over their original estimates, andonly one third of projects are completed on time and onbudget

Stephen Lynn (Projects at Work) Nov 2006

By 2010, 40 per cent of existing enterprise architectureprogrammes will be stopped due to poor execution

Gartner

The firm failed to ensure that adequate projectmanagement procedures were in place

Financial Services Authority January 2007G64SPM - Dr. Ender zcan -

Introduction 18


10/14

10


Why do projects fail so often?

Among the most common factors:

Unrealistic or unarticulated project goals

Inaccurate estimates of needed resources

Badly defined system requirements

Poor reporting of the project's status

Unmanaged risks

Poor communication among customers, developers, and users

Use of immature technology

Inability to handle the project's complexity

Sloppy development practices

Stakeholder politics

Commercial pressures

By Robert N. Charette at http://www.spectrum.ieee.org/sep05/1685

Poor project management

Why do projects fail so often?



11/14

11


What is the use of SPM then?

Learning from the mistakes Standish report (http://www.standishgroup.com) 1994

31% of projects were failed

16% of the projects are considered to be successful

Standish report 2003: 15% of projects were failed

34% of the projects are considered to be successful Good SPM practices makes a difference


How can we make sure that ourprojects succeed? Make sure all decisions are based on openly

shared information Its important to create a culture of transparency,

where everyone who needs information knows whereto find it and is comfortable looking at it. All project documents, schedules, estimates, plans

and other work products should be shared with theentire team, managers, stakeholders, users andanyone else in the organization who wants them.

Major decisions that are made about the projectshould be well-supported and explained.


12/14

12


How can we make sure that ourprojects succeed?

Dont second-guess your team membersexpertiseManagers need to trust team members.Just because a manager has responsibility for

a projects success, it doesnt mean that hesmore qualified to make decisions than the

team members. If you dont have a good reason to veto an

idea, dont.



Introduce software quality from the verybeginning of the projectReview everything, test everything.Use reviews to find defects but dont expect

the review to be perfect.Use reviews to gain a real commitment from

the team. Its always faster in the long run to hold a

review than it is to skip it.


13/14

13



Dont impose an artificial hierarchy on theproject team All software engineers were created equal.

A manager should not assume that programming ismore difficult or technical than design, testing orrequirements engineering.

Managers should definitely not assume that theprogrammer is always right, or the tester is alwaysraising false alarms.


How can we make sure that ourprojects succeed? Remember that the fastest way through the

project is to use good engineering practices Managers and teams often want to cut important

tasks especially estimation, reviews, requirementsgathering and testing. If it were faster to build the software without these

practices, we would never use them. Every one of these practices is about saving time and

increasing quality by planning well and finding defectsearly. Cutting them out will cost time and reducequality.


14/14

14


Software Project Management Issues

Tackling business and managementproblemsDecision making, models

Planning

Scheduling

Team work (communication)

Spm Lecture1 2

Documents

Transcript of Spm Lecture1 2