Greening the Philippine Manufacturing Industry Roadmap Dr. Bernd Gutterer GIZ ProGED 8.6.2015
Tempus Software Project Management SE603 Unit 1: SPM Basics Vasa Case Study Egypt, 8.6.2015.
-
Upload
oswald-day -
Category
Documents
-
view
221 -
download
0
Transcript of Tempus Software Project Management SE603 Unit 1: SPM Basics Vasa Case Study Egypt, 8.6.2015.
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.