1. MADALINA CROITORU croitoru@lirmm.fr Software Engineering week 1 Madalina Croitoru IUT Montpellier

2. MADALINA CROITORU croitoru@lirmm.fr Software crisis Survey of outcomes from Standish Group 280,000 development projects 1.Successful 2.Cancelled 3.Late, over budget, incomplete

3. MADALINA CROITORU croitoru@lirmm.fr Goals of software engineering Satisfy user requirements High reliability Low maintenance costs Deliver on time Low production cost High performance Ease of reuse

4. MADALINA CROITORU croitoru@lirmm.fr Software process models Determine the order of the stages of software development. Establish the transition criteria to proceed from one stage to the next. What shall we do next? How long should we take?

5. MADALINA CROITORU croitoru@lirmm.fr Code and fix

6. MADALINA CROITORU croitoru@lirmm.fr Code and fix difficulties After many changes the code becomes badly constructed and expensive to maintain. Design phase needed. Poor match to users’ needs. Requirements phase needed. Poor preparation for testing and modification. Test phase and evolution phase.

7. MADALINA CROITORU croitoru@lirmm.fr

8. MADALINA CROITORU croitoru@lirmm.fr Why is software development not ideal Fallibility of software professions Change of clients requirements while the software is being developed Need for maintenance

9. MADALINA CROITORU croitoru@lirmm.fr Public transport Fare machine that takes dollar bills Sensor scans bill, image recognition decides if genuine –If any piece of paper works, company loses $$ –If valid bills are rejected, customers annoyed Response time < 1sec Accuracy 98% in image recognition The last two are in conflict. Why?

10. MADALINA CROITORU croitoru@lirmm.fr Example 1.First version implemented 2.Test showed that the real-time constraint was not achieved. The reason was using “double” instead of “float”. The programmer changed the code. 3.Before completing the work in 2, tests showed that even with this change the real time constraint would still not be made. New image recognition algorithm may do it. 4.Company wishes to get the accuracy up to 99.9% to market the product. 5.Sensors become obsolete

11. MADALINA CROITORU croitoru@lirmm.fr

12. MADALINA CROITORU croitoru@lirmm.fr Iterative and incremental development Moving targets (customer driven, hardware) Iteration Increment Identification of work flows –Requirements, analysis, design, implement, test Unified process

13. MADALINA CROITORU croitoru@lirmm.fr Waterfall life cycle model The seminal paper for this model appeared in 1970 and was reprinted in 1987 (Royce 1987)

14. MADALINA CROITORU croitoru@lirmm.fr

15. MADALINA CROITORU croitoru@lirmm.fr Waterfall (plan driven) Based on project milestones. Each “signed off” before going onto the next Reinforced by documentation; very important in large projects Gives discipline Works well if requirements are fixed No iteration

16. MADALINA CROITORU croitoru@lirmm.fr Waterfall model Requirement analysis and definition System and software design Implementation and unit testing System testing

17. MADALINA CROITORU croitoru@lirmm.fr Requirement analysis, definition and specification Requirement analysis: Long consultation with the customer to find out what they want Requirement definition: stating what the user wants so that is understandable both by user and developers Requirement specification: formal document (sometimes acts as a contract)

18. MADALINA CROITORU croitoru@lirmm.fr Design Requirements divided into two: –Software –Hardware Software design means representing the function of every unit in such way that it can be transformed directly into software

19. MADALINA CROITORU croitoru@lirmm.fr Implementation Unit design transformed into software Individual units are then tested to make sure they satisfy their specification

20. MADALINA CROITORU croitoru@lirmm.fr Testing Individual units are integrated gradually Tested for compatibility and functionality System is deployed System is maintained

21. MADALINA CROITORU croitoru@lirmm.fr Criticism of waterfall The milestones did not fit in with an increasing number of project situations (Boehm 1996) Royce in the 1970 paper pointed out the shortcomings, and suggested prototyping and “do it twice”. However, he rather erroneously has been attributed with a very rigid process.

22. MADALINA CROITORU croitoru@lirmm.fr Boehm 1996 A prototype is worth 100,000 words. Written specifications are not effective. Gold plating. Fixed requirements encourage elaborate additions that may not be needed. Inflexible point solutions. These are optimised about the original solution. (Both waterfall and evolutionary) Need to manage risk. (Both waterfall and evolutionary)

23. MADALINA CROITORU croitoru@lirmm.fr Current challenges

24. MADALINA CROITORU croitoru@lirmm.fr Current challenges Most commercial systems are now networked Software systems must integrate with different software systems developed by OTHER ORGANISATIONS using: –Different hardware –Different software

25. MADALINA CROITORU croitoru@lirmm.fr Other challenges Hardware evolves FASTER than software Some programs are obsolete but perform critical business tasks Modifications meant software logic became corrupted Original developers have moved on