1 / 39

Software Project Management

Software Project Management. Lecture 1 Introduction to Software Project Management. Overview. Software engineering Software project management Formal methods. Software Crisis. Faulty software Delay in completion time Over budgeted Difficult to maintain software. Some UK projects.

shiro
Télécharger la présentation

Software Project Management

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software Project Management Lecture 1 Introduction to Software Project Management

  2. Overview • Software engineering • Software project management • Formal methods

  3. Software Crisis • Faulty software • Delay in completion time • Overbudgeted • Difficult to maintain software

  4. Some UK projects • Home Office asylum seeker Casework system: £80m; abandoned 2001 (Siemens). • Pathway UK benefits identity card system: abandoned 1999 with £1bn losses (ICLFujitsu). • Datacentre for UK cabinet office: £85m, cancelled in 2004 (ITNET). • MRC Laboratory of Molecular Biology, FAMIS purchasing system: £55m; ‘operating failure’ (LogicaGMC). • UK e-University: £62m; abandoned 2004 (Sun, though only £20m of the full figure).

  5. American experience • 25% of development projects are abandoned • probability of cancellation rises to 50% for largest developments • average project overshoots schedule by 50% • 75% of systems are regarded as ‘operating failures’ U.S. Bureau of Labor Statistics, 1997

  6. Some important facts • Relative cost of the software in a system is growing • Increase in demand for software • Increase in size and complexity of software • Increase in performance of hardware

  7. Software Engineering An initial, loose definition: “the establishment and use of sound engineering principles in order to obtain, economically, software that is reliable and works efficiently on real machines” [Bauer, 1969]

  8. A more useful definition “The application of scientific and engineering efforts to 1. transform an operational need into a system through the use of an iterative process of definition, analysis, design, test, and validation; 2. ensure the compatibility of all interfaces […]; 3. integrate reliability, maintainability, disposability, […] to meet cost, schedule, and technical performance objectives.” [Blanchard, 1998]

  9. Software Engineering • Aimed at large software • Systematic and well-defined techniques, methodologies and tools • To design, code, test and maintain quality software • Within a resource constrained environment

  10. Large Software • Developed by more than one person • Effective communications are important – standards, documentation, etc • Management issues • Techniques and methodologies are useful only if automated systems can be built upon them

  11. Phases of Software Development • Requirements analysis and specification • Design • Coding • Testing • Installation • Maintenance

  12. Some important observations • Maintenance is the most expensive phase and coding is the least expensive phase • The earlier the detection of faults, the less expensive the correction of faults

  13. Characteristics of software • Simple and elegant mathematical representation • Logic intensive • Cannot have partial completion • Design costs are relatively expensive

  14. What is a project? • Key characteristics of a project: • A planned activity • Specific objectives or products • Work to be carried out in several phases • Limited resources • Deadline • Large and complex

  15. Major differences between software products and hardware products • Progress of software development is not obviously visible • Modifications of software products are more easy and flexible • Software products are usually more complex than the hardware products in terms of development or construction cost

  16. Major processes in developing a software system • Feasibility study • Project planning • Project execution

  17. Feasibility Study • Analyze the general requirements, costs and the functionalities and services provided by the system to be developed • Aimed to determine whether a system should be developed or not • Can be viewed as a project itself

  18. Important factors in planning a software project • To know the nature of the system to be developed • A management information system or a control system • To know clearly the objectives and products of the project • How to evaluate the objectives and products after the completion of the project

  19. What is management? • Management involves the following activities: • Planning • Staffing • Innovating • Directing • Monitoring • Liaising • …?

  20. What is software project management? • Understand the characteristics of software products • Understand what is meant by a project • Understand what is meant by management

  21. Common problems with software projects • Lack of quality standards and measures • Lack of measurable milestones • Difficult to make the progress visible • Poor communications • Poor documentation • Frequent changes of requirements • Over budget and late delivery of software

  22. Major issues of software project management to be covered • Software development models • Software size and cost estimation • Software project planning • Software risk management • Resource allocation • Standards: ISO 9000 and CMM • Performance tracking and reporting

  23. Major issues of software project management to be covered (cont’d) • Software project configuration management • Software project team management

  24. Main problems encountered with requirements and specifications • Ambiguous • Incomplete • Inconsistent

  25. Main problems encountered with requirements and specifications (cont’d) • To overcome these problems via • Formality – achieving precision • Abstraction – concentrating on essential parts

  26. Formal Methods • Mathematically based techniques • Providing a precise and concise language • Supporting formality • Supporting abstraction • Supporting logical reasoning • May support automation

  27. Example: traffic light control • Simple 4-way crossroads • Traffic lights control each entry • Roads run North-South and East-West N

  28. type Light == red | redamber | green | amber, Junction :: ns : Light ew : Light timer : Nat value nextLight : Light → Light nextLight(l) is case l of red → redamber, redamber → green, green → amber, amber → red end,

  29. limit : Junction → Nat limit(j) is if ns(j) isin {amber, redamber} \/ ew(j) isin {amber, redamber} then 1 else 4 end, next : Junction → Junction next(j) is if limit(j) ≤ timer(j) then mk_Junction(nextLight(ns(j)), nextLight(ew(j)), 0) else mk_Junction(ns(j), ew(j), timer(j) + 1) end, safe : Junction → Bool safe(j) is ~ (ns(j) = green /\ ew(j) =green)

  30. Critical properties • Safety: • Not both green at the same time: G(safe(junction)) i.e. Globally (in all states), the junction is safe • Liveness: • In each direction, lights will eventually go green: G(F(ns(junction) = green)) i.e. Globally, in the Future, North-South is green /\ G(F(ew(junction) = green))

  31. Is the junction safe and live? • Safe? – depends on what state it starts in • Live? – yes We can model check the specification to prove these.

  32. transition_system [T] local junction : Junction := mk_Junction(red, red, 0) in [change] true ==> junction' = next(junction) end ltl_assertion [safe] T |- G(safe(junction)), [live_ns] T |- G(F(ns(junction) = green)), [live_ew] T |- G(F(ew(junction) = green))

  33. Counterexample for 'safe': ======================== Step 0: junction = mk_Junction(red, red, 0) ------------------------ Step 1: junction = mk_Junction(red, red, 1) ... Step 4: junction = mk_Junction(red, red, 4) ------------------------ Step 5: junction = mk_Junction(redamber, redamber, 0) ... Step 7: junction = mk_Junction(green, green, 0) Summary: The assertion 'safe' is invalid. The assertion 'live_ns' is valid. The assertion 'live_ew' located at is valid.

  34. What are formal methods for? • Clarify and fix requirements • Support early analysis: • Static analysis • Testing • Model checking • Proof • Provide a basis for implementation

  35. Specification languages • The traffic light example was written in RAISE • There are many formal methods, some general purpose, some specialised

  36. A good slogan • You may not be able to avoid making mistakes … • But you must find them before they cost too much!

  37. Modelling • Modern software engineering is based on making models • A formal model (eg in RAISE) supports more analysis than in informal one (eg in UML) • Increasingly, implementations will be derived from models: programmers will be obsolete

  38. References • Hughes, B., and Cotterell, M. (1999) Software Project Management, McGraw Hill • Dean, C.N., and Hinchey, M.G. (1996) Teaching and Learning Formal Methods, Academic Press • Sommerville, I. (2001) Software Engineering, Pearson Education.

  39. References • RAISE: http://www.iist.unu.edu/raise • Dines Bjørner (2006) Software Engineering, Springer

More Related