Software Engineering

1. Software Engineering Chapter Two Software Process • Learning Outcomes • Appreciate the need for a defined software process • Be able to describe in detail the main software process models • Be able to compare software process models and choose between them • Know about alternative approaches – agile and reengineering

2. The software process • Structured set of activities required e.g. Specification, Design, Validation, Evolution • Activities vary depending on the organisation and the type of system being developed • Must be explicitly modelled if it is to be managed • Process Characteristics • Understandability • Visibility • Supportability • Acceptability • Reliability • Maintainability • Rapidity

3. Generic vs Software engineering process • Generic – building any product • Specification - set out requirements and constraints • Design - Produce a paper model of the system • Manufacture - build the system • Test - check the system meets the required specifications • Install - deliver system to customer and ensure it is operational • Maintain - repair faults in the system as they are discovered • Software • Normally, specifications are incomplete / anomalous • Very blurred distinction between specification, design and manufacture • No physical realisation of the system for testing • Software does not wear out - maintenance does not mean component replacement

4. Software process models • Waterfall model • Separate and distinct phases of specification and development • Prototyping Models • Incremental Models • Specification and development are interleaved • The Spiral model • Agile Methods • Formal transformation • A mathematical system model is formally transformed to an implementation • Reuse-based development • The system is assembled from existing components

5. Waterfall model

6. Prototyping Model • Prototyping is used: 2 types • Evolutionary prototyping • Objective is to work with customers and to evolve a final system from an initial outline specification. Should start with well-understood requirements • Throw-away prototyping • Objective is to understand the system requirements. Starts with poorly understood requirements • Requirements are difficult to capture accurately! • Prototype - a working model of part or all of the final system • Use of high-level languages to create working programs quickly. Modern 4GLs are very suitable • Prototype may be inefficient/ not as robust as final system/ less functionality

7. Requirements Gathering Design Design Implementation Implementation Testing Testing Maintenance

8. Problems with Prototyping • Documentation may get neglected • Effort in building a prototype may be wasted • Difficult to plan and manage • Advantages • Faster than the waterfall model • High level of user involvement from start • Technical or other problems discovered early - risk reduced

9. Evolutionary Strategies • main purpose of software process model is “to give risk-reducing structure” [Ould, 1990]. • growing recognition that in many cases software should be developed in an evolutionary fashion [e.g. McConnell, 1993] • e.g. Microsoft Visual C++ is shipped every 4 months • Strategies • Evolutionary Prototyping • Incremental (Staged) Delivery • Design-to-Schedule • Evolutionary Delivery Ould, M.A., Strategies for Software Engineering: The Management of Risk and Quality, John Wiley, NY, 1990. McConnell, S., Rapid Development: Taming Wild Software Schedules, Microsoft Press, Redmond, WA, 1996

10. Evolutionary Prototyping • Build prototype and evolve software from it • Prototype typically the user interface, but may be any high-risk area of the system. • Evolutionary prototyping especially useful • when requirements are changing rapidly • when the customer is reluctant to commit to a set of requirements • when there is a lack of understanding of what is required [ • when the developer is unsure of which technical solution to use.

11. Problems with Evolutionary Prototyping • Difficult to plan as amount of effort is uncertain • Documentation may be neglected • Could degenerate into “Build and Fix” with poorly structured code • Languages which are good for prototyping not always best for final product • Advantages • Effort of prototype is not wasted • Faster than the waterfall model • High level of user involvement from start • Technical or other problems discovered early - risk reduced

12. Incremental (staged) Delivery Differs from Evolutionary Prototyping in that requirements are fully known at the start

13. Mechanism • requirements gathered in initial stages • overall architectural design is determined • requirements met in successive stages of the project • users get part of the functionality delivered at an early stage (As in evolutionary prototyping) • Problems • Needs careful planning - stages have interdependencies • If not planned well - extra effort in interfacing stages • Users may tire of constant changes • funding may be difficult to obtain for a succession of changes

14. Design-to-Schedule Note: Variation onIncremental Model n Stages prioritised lower prioritylast. Thus if deadline or budget is reached before product finishedlowest priority stagescan be omitted.

15. Each stage is VALUABLE! Incremental and Iterative Delivery • (Tom Gilb, 1988 – he called it “evolutionary”/ “evo”) Architecture at each stage Must be OPEN = easyto change and add to Gilb, T., Principles of Software Engineering Management, Addison-Wesley, 1988

16. CHANGE Initial course New Objectives Revised course Incremental and Iterative Delivery Initial Objectives

17. Agile Methods • http://agilemanifesto.org/ and http://www.martinfowler.com/articles/newMethodology.html Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Candidates: XP (Extreme Programming), Cockburn's Crystal Family, Open Source, Highsmith's Adaptive Software Development, Scrum, Feature Driven Development, DSDM (Dynamic System Development Method)

18. What is Extreme Programming • Things we know from Software Engineering: Pair Programming Unit and functional tests Refactorin g Simplest Design that works Use of a metaphor Continuous Integration The Planning Game

19. What is XP? • A lightweight, efficient, low-risk, flexible,predictable, scientific and fun way to develop software (Kent Beck) • ‘lightweight’ being replaced by the term ‘agile’ • 4 Values • Communication • Unit testing, pair programming, task estimation done with > 1 person • Simplicity • XP coach asks “What is the simplest thing that could possibly work?” • Feedback • Each task feeds back to the instigator, early deliverables • Courage • E.g. Throwing code away, refactoring, trying out new ideas

20. XP – Overview of the 12 Practices • The Planning Game • Business People: Scope, Priority, Composition of releases, Dates of releases • Technical People: Estimates, Consequences of choices, Process, Detailed Scheduling • Small Releases • Sensible but reduce cycle as much as possible • Metaphor • Similar to ‘architecture ‘ but for non-technical too e.g see system as contracts and customers • Simple Design • Runs all the tests, No duplicated logic, all the required bits, fewest classes and methods

21. Collective Ownership • Everyone owns and can improve the code • Continuous Integration • Code integrated and tested after a few hours-1 day • Run the tests until they work • 40 hour week • max • On site customer • (real) customer sits with team • Coding Standards • Same indentation, layout etc • Least amount of work possible

22. Testing • Tests are written before the code • Test run (automated) frequently (after all changes) • Customers provide acceptance tests • Pair Programming • One person has keyboard, other checks and suggests • Refactoring • XP teams improve the software throughout development process

23. Software Reengineering • What? - Re-structuring or re-writing part or all of a legacy system without changing its functionality • When? • When some but not all sub-systems of a larger system require frequent maintenance • When hardware or software support becomes obsolete • How? • The system may be re-structured and re-documented to make it easier to maintain • Why • Reduced risk • New software development carries high risk. • Reduced cost • The cost of re-engineering is often significantly less than the costs of developing new software

24. Automated program conversionAutomated program restructuringManual Program and Data RestructuringRestructuring plus Architectural Changes cost Forward engineering and re-engineering

25. Reverse engineering • Analysing software to gain an understanding of its design and specification • May be part of a re-engineering process or to re-specify a system for re-implementation • Builds a program data base and generates information from this • Program understanding tools (browsers, cross-reference generators, etc.) may be used in this process • Why? • Original code may have been written under limitations which no longer apply e.g. memory needs, performance etc • Maintenance tends to corrupt the structure of a program. It becomes harder and harder to understand • The program may be automatically restructured to remove unconditional branches or complex conditional statements

26. Software Engineering Chapter Two Software Process • Learning Outcomes • Appreciate the need for a defined software process • Be able to describe in detail the main software process models • Be able to compare software process models and choose between them • Know about alternative approaches – agile and reengineering