1. Tempus Software Project Management SE603 Unit 1: SPM Basics Vasa Case Study Egypt, 8.6.2015

2. 2 Course Content Software Project Management Basics Project Planning Software Development Life Cycle Models Project Activities Effort Estimation Risk Management Software Configuration Management

3. 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. 4 Vasa Case Study Sep, 10 ships were lost Nov, 108 to be 120 ft to carry 32 24- pnd cannons ………………………..

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

22. Tempus Thank you for your attention.