F28SD2 Software Design L01. Overview of Software Processes

1. F28SD2 Software DesignL01.Overview of Software Processes Monica Farrow monica@macs.hw.ac.uk Modified by Lu Fan L.Fan@hw.ac.uk December 2009

2. Introduction to the module Andrew Ireland (Wed) Lu Fan (Tue) Intro to Software Processes Architectural Design UML – Use Case & Activity Function-oriented Design UML – State Machine Object-oriented Design UML – Class & Interaction Component-based Design Design Patterns Verification & Validation Week 6&7 Feasibility Studies Testing & Analysis (IS) (CS) Revision & looking ahead

3. Software engineering • Not very long ago in the history… • The 1940s – modern computers appeared • The 1950s – programming languages appeared • The 1960s – software crisis! • As a result of “chaotic software development process” • Projects ran over-time/budget • Software was inefficient/not able to meet requirements/never delivered • Codes were unmanageable/difficult to maintain • Software engineering: • Firstly proposed in 1968, NATO Software Engineering Conference • Cost-effective development of high-quality software systems

4. Software engineering • Frederick Phillips Brooks, Jr. • “The Mythical Man-Month” • Essays on software engineering, published in 1975 • Many important ideas, including: • Adding manpower to a late software project makes it later • The second-system effect • Advocacy of prototyping • “No Silver Bullet” • Essence and accidents of software engineering, published in 1986 • Many important arguments, including: • Essential complexity – caused by the problem to be solved – cannot be removed • Accidental complexity – problems that we create on our own – can be fixed • Much of the accidental complexity has already been cleaned up – no silver bullet

5. The software process • A structured set of activities required to develop a software system –Sommerville • Specification Design Validation Evolution • A framework for the tasks that are required to build high-quality software –Pressman • A process defines who is doing what, when and how to reach a certain goal –Jacobson, Booch, Rumbaugh • Several models for such processes, e.g. waterfall, spiral, agile and extreme programming • A.k.a. software lifecycle models, software development methodologies…

6. Waterfall process model • A sequential software development process • Create a team, follow a well-documented process with fixed milestones • Described by Winston Royce in 1970. • Collect & document all of the system requirements • Produce a set of design documents • Write code that implements the pieces specified in the design • Integrate all of the pieces and test to make sure the system satisfies the requirements • Package the system & ship to the customer

7. Project costs Requirements Specification • For conventional projects, typically: • 2% of budget is spent on requirements • 4% on specification • 1% on planning • 6% on design • 20% on implementation • and 67% on maintenanceincluding correction of defects Planning Design Implementation Maintenance

8. Waterfall criticisms • Projects are seldom so clear-cut and linear • It’s usually late in the project before a working version is available for user to test and criticise. • Misunderstandings are not discovered until nearly complete and the problems are expensive to fix. • The earlier an issue is identified, the smaller the cost – errors detected in testing phase may be 50 times more costly to fix than if they were detected during requirements or design phases. • Most require some iteration • Waterfall is often modified with arrows back to any stage to show this.

9. Waterfall model with iterations Requirements capture • Iterative processes • Incremental delivery • Spiral development • Rapid application development System and software design Implementation and unit testing Integration and system testing Rework the earlier stages Operation and maintenance

10. Incremental delivery • Descriptions: • The development & delivery is broken down into increments, each delivering part of the required functionality. • User requirements are prioritised & the highest priority requirements are included in early increments. • Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve. • Advantages: • System functionality is available earlier – accelerated delivery • Early increments help elicit requirements for later increments • The highest priority system services tend to receive the most testing • Lower risk of overall project failure

11. Incremental delivery • Problems • ManagementProgress can be hard to judge & problems hard to find, because there is no documentation to demonstrate what has been done. • ContractualThe normal contract may include a specification; without a specification, different forms of contract have to be used. • ValidationWithout a specification, what is the system being tested against? • MaintenanceContinual change tends to corrupt software structure, making it more expensive to change & evolve to meet new requirements.

12. Spiral development • The spiral model • Analyze a little, design a little, code a little • Defined by Barry Boehm in 1988

13. Spiral development • Descriptions: • Incremental development, delivery, iteration, evaluation & feedback. • The project moves continually from planning of the next increment, to risk assessment, through implementation and evaluation. • PM can terminate project at any point, while ensuring that the user gains some benefit from each increment. • Focuses on prototyping and formalises an evolutionary approach to software development. • Requires an explicit risk analysis during each cycle. • User involvement throughout the development process. • Validation and prioritisation of requirements. • Tends to work best for small projects.

14. Software prototyping • A prototype • simulates some of the features of the eventual program • may be completely different from the eventual implementation • Advantages • enables software engineers to understand the problem domain and the user requirements • allows users to provide better & more complete feedbacks • Types • Throwaway prototyping – the model will eventually be discarded • Evolutionary prototyping – constantly refine a functional model • Incremental prototyping – merge several prototypes in an overall design

15. Rapid Application Development (RAD) • RAD was Initiated in the 1990s for projects with a rapidly changing business environment, where to arrive at a stable, consistent set of system requirements is often impossible. • In these cases, a waterfall model of development is impractical. An approach to development based on iterative specification and delivery is the only way to deliver software quickly. • Characteristics: • Concurrent specification, design & implementation • Minimal planning, specification & documentation • End users evaluate each increment & make proposals for later increments

16. Agile methods • Dissatisfaction with the overheads involved in design methods led to the creation of ‘agile’ methods • Agile manifesto www.agilemanifesto.org • Individuals and interactions rather than processes and tools • Software development rather than exhaustive documentation • Working with the customer rather than contract negotiation • Openness to change rather than following inflexible plans • Agile methods are probably best suited to small/medium-sized business systems or PC products.

17. Agile methods • Principles: • Individuals & interactions • In the development world, people are more valuable than computer tools • Face-to-face conversation is the most efficient form of communication • Working software • Deliver software often (weekly) • Working software is the primary measure of progress • Customer collaboration • Customer needs come first • Feedback from customer rather than planning • Responding to change • Even late changes in requirements are welcomed

18. Extreme Programming (XP) • One of the best known agile methods • Ground rules: • Small team (2 to 12) • Continuous access to customers – needs an “on-site customer” • OO design and code – Smalltalk, Java • Change management system – code and tests • The system is always “working” (growing functionality over time) • Development cycle – 4 to 12 months (new release every 2-3 months, internal iterations every two weeks) • Not for life-critical systems (heart monitor, nuclear power plant, avionics systems, etc.)

19. Extreme Programming (XP) • Principles: • Planning • Do project planning via “user stories” – interview the customer • Start each day with a “stand-up meeting” – choose task & partner for the day • Designing • Keep the design simple – use the simplest thing that could work • Code refactor as needed • Coding • Pair programming – all code is reviewed as it is written • Code unit tests first – test-driven development • Testing • Unit tests for all code • Acceptance tests for each user story

20. Agile vs. XP • Agile is a generalisation of XP, featuring • Small team sizes • Short development iterations – release at regular intervals • Continuous testing, e.g. daily regression tests • Collecting customer requirements using scenarios • Informal modeling techniques, e.g. CRC cards, simple drawings • Adaptive planning based on reprioritisation by the customers • XP is a radical agile method, requiring • On-site customer & planning by user stories • Pair programming • General-purpose developer • Unit tests for everything • Existing processes can be adapted to be more “agile”

21. Key points so far • Software processes are the activities involved in producing and evolving a software system. • specification, design, implementation, validation and evolution. • Waterfall model describes the software development as a sequential process. • Iterative models describe the software development as a cycle of activities. • RAD, including Agile & XP, have concurrent specification, design and implementation. • There is no ideal process model • Largest software vendors, e.g. Microsoft & IBM, still primarily rely on traditional waterfall methodologies with some degree of spiraling.

22. Information systems lifecycle • Software lifecycle models • concentrate on design & implementation of a software system • lack an overall picture of the organisation and its business processes • Information systems lifecycle models extend software lifecycle models by adding • Feasibility study • Review during maintenance • System is an open one • Operation feeds back to design

23. Information Systems Development LifecycleDavid Avison & Hanifa Shah 1997 Problems with existing system New business opportunities IS planning Managerial directive Feasibility study Feasibility study report Systems investigation User requirements Project plans Resource requirements Staff assignment Methods and tools Current system data flow System requirements Systems analysis Systems design New system data flow System specification Training and test plans Implementation Programs Procedures Documentation New system in operation Review and maintenance Evaluation report New problem statement?

24. Next • Andrew on Wednesdays • No tutorial on this Friday • 3 Tuesday lectures on UML • Use cases & activity diagrams • State machine diagrams • Class & interaction diagrams