Software Project Management Lecture 1 Introduction to Software Project Management

Overview Software engineering Software project management Formal methods Software Project Management

Software Crisis Faulty software Delay in completion time Over budgeted Difficult to maintain software Mention that we have less than 60 years of software development history Software Project Management

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). Software Project Management

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 Software Project Management

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 Software Project Management

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] Software Project Management

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] Software Project Management

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 Emphasis the difference between large software and small softwar 2. Describe a bit more details about quality software 3. The importance of constraints on resources – time, staff, etc 4. Mention the importance of formal methods Software Project Management

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 Software Project Management

Phases of Software Development Requirements analysis and specification Design Coding Testing Installation Maintenance Briefly explain what is meant by each phase 2. Point out that such a classifications of phases is not unique 3. Though these phases are listed sequentially, they are overlapping and iterative Software Project Management

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 Software Project Management

Characteristics of software Simple and elegant mathematical representation Logic intensive Cannot have partial completion Design costs are relatively expensive Software Project Management

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 Software Project Management

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 Software Project Management

Major processes in developing a software system Feasibility study Project planning Project execution Software Project Management

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 Software Project Management

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 Software Project Management

What is management? Management involves the following activities: Planning Staffing Innovating Directing Monitoring Liaising …? Some more activities are given in the recommended textbook Software Project Management

What is software project management? Understand the characteristics of software products Understand what is meant by a project Understand what is meant by management Teacher reminds the students that these three issues were covered in the previous slides. Software Project Management

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 Software Project Management

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 This is in fact a list of the topics to be covered in the course For each topic, briefly explain: (a) what is the objective (b) what is the content Software Project Management

Major issues of software project management to be covered (cont’d) Software project configuration management Software project team management Software Project Management

Main problems encountered with requirements and specifications Ambiguous Incomplete Inconsistent Teachers should give examples to illustrate these problems Software Project Management

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

Formal Methods Mathematically based techniques Providing a precise and concise language Supporting formality Supporting abstraction Supporting logical reasoning May support automation Teachers need to emphasis that a full automation is not normally supported Teachers also need to emphasis that formal methods are not only applicable for requirements and specifications. Software Project Management

Example: traffic light control Simple 4-way crossroads Traffic lights control each entry Roads run North-South and East-West N Software Project Management

Light == red | redamber | green | amber, 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, Software Project Management

if ns(j) isin {amber, redamber} \/ ew(j) isin {amber, redamber} 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) Software Project Management

Critical properties Safety: Liveness: 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)) Software Project Management

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. Software Project Management

local junction : Junction := mk_Junction(red, red, 0) in [change] 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)) Software Project Management

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. Software Project Management

What are formal methods for? Clarify and fix requirements Support early analysis: Static analysis Testing Model checking Proof Provide a basis for implementation Software Project Management

Specification languages The traffic light example was written in RAISE There are many formal methods, some general purpose, some specialised Software Project Management

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

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 Software Project Management

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. Software Project Management

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