Tempus

Software Project Management SE603

Unit 1: SPM BasicsVasa Case Study

Egypt, 8.6.2015

2

Course Content

• Software Project Management Basics • Project Planning• Software Development Life Cycle Models• Project Activities • Effort Estimation• Risk Management• Software Configuration Management

3

Vasa Case Study

• Project began in January 1625 •Ordered by Sweden’s King Gustav II•Made by Hybertsson, the master

shipwright.• 4 ships: 135 ft x 2 + 108 ft x 2

4

Vasa Case Study

• Sep, 10 ships were lost•Nov, 108 to be 120 ft to carry 32 24-

pnd cannons•………………………..

5

Vasa Case Study

•On 10 August 1628, the Vasa sailed about 1,300 meters. • Then, with a light gust of wind, it

started to swing and sank.• 53 lives were lost.• After a formal hearing, it was not

determined why the ship sank, and no one was blamed.

6

Vasa Case Study

• Vasa is a show case of how a project can fail despite having all the factors and reasons that should contribute to its success because of poor management.

8

1- Schedule Pressures

•Fred Brooks, “ More software projects have

failed (“gone awry”) for lack of adequate calendar time than for all other reasons combined.”

9

1- Schedule Pressures

• Truly pressing needs

• Perceived needs that are not truly pressing

• Changing of requirements without adjusting schedule or resources

• Unrealistic schedules imposed on projects by outside forces

• Lack of realistic estimates based on objective data

11

2- Changing Needs

• Reasons for change to requirements include• competitive forces (as in the case of Vasa), • user needs that evolve over time, • changes in platform and target technologies, • and new insights gained during a project.

13

4- No documented project plan

•We did it many times before !!• Planning was seen as unnecessary use of

time and resource• Evolving a baselined project plan for an

initially small project is much easier than trying to construct a project plan later

14

4- No documented project plan

• At minimum have• Work breakdown structure• Allocation of requirements to WBS• A schedule• Allocation of resources to tasks• Deliverables of each task • Plans for acquisition and subcontracting• Risk management plan• Hierarchy (statement of authorities / respon.)

16

5- Excessive innovation

• Software projects are always innovative to some extent • because replicating existing software, unlike

replicating physical artifacts, is a trivial process.

17

5- Excessive innovation

• To control excessive innovation in software projects:• Baseline control of working documents (for

instance, requirements, project plans, design documents, test plans, and source code)• Impact analysis of proposed changes• Continuous risk management

19

10- Unethical Behavior

• The role of engineering is providing systems and products that enhance human life.• Making Sweden more secure• Bring glory to the country

• When it became obvious the ship was not seaworthy, those with authority to stop the launch did not do so.• Can u think of SW failure that was the same??

20

10- Unethical Behavior

• 1.03. Approve software only if they have a well-founded belief that it is safe, meets specifications, passes appropriate tests, and does not diminish quality of life, diminish privacy or harm the environment. The ultimate effect of the work should be to the public good. (IEEE/ACM SOFTWARE ENGINEERING

CODE OF ETHICS AND PROFESSIONAL PRACTICE)

Tempus

Thank you for your attention.