Software Engineering

1. Software Engineering The Software Process

2. Why Software Engineering? • Can you approach building software as building a bridge? Why? Why not? • How is software engineering like other engineering disciplines?

3. Software Process A structured set of activities required to develop a software system. Fundamental Assumption: Good processes lead to good software Good processes reduce risk

4. Risk Management What can go wrong in a software project? How can the risk be reduced?

5. The software process • Many different software processes but all involve: • Specification: defining what the system should do; • Design and implementation: defining the organization of the system and implementing it • Validation – checking that it does what the customer wants; • Evolution – changing the system in response to changing customer needs.

6. Software Process Models A software process model is an abstract representation of a process. • The waterfall model • Separate and distinct phases of specification and development (product focused) • Evolutionary development • Specification, development and validation are interleaved e.g. XP (Beck), increment driven • Component-based software engineering • The system is assembled from existing components. • Spiral (Boehm) • driven by risk analysis and mitigation

7. Use of the Models in Practice

8. The Waterfall Model Requirements Definition System and Software design Programming and Unit Testing Integration and System Testing Operation and Maintenance

9. perceived need requirements design code test integrate Waterfall Modelmaterial adapted from Steve Easterbrook • View of development: • A process of stepwise refinement • High-level management view • Problems: • Static view of requirements (ignores volatility) • Lack of user involvement once spec is written • Unrealistic separation of spec from design • Doesn’t accomodate prototyping, reuse

10. Problem Case Study • Publisher of books want to develop a product that will carry out all the accounting functions of the company and provide online information to the head office staff regarding orders and inventory • Terminals are required for 15 accounting clerks, 32 order clerks, and 15 managers need access to the data. The publisher will pay 30000 and wants the complete product in 4 weeks • What do you tell him?

11. The Waterfall Model Requirements Definition System and Software design Programming and Unit Testing Integration and System Testing Operation and Maintenance

12. [1] Requirements Analysis and Definition • Result from an analysis or discovery process • The system's services, constraints and goals are established by consultation with system users. They are then defined in a manner that is understandable by both users and development staff. This phase can be divided into: •  Feasibility study (often carried out separately) •  Requirements analysis •  Requirements definition •  Requirements specification

13. Terminology • A requirement is a technical objective which is imposed upon the software, i.e., anything that might affect the kind of software that is produced • A requirement may be imposed by • the customer • the developer • the operating environment • The requirement must be documented • Requirements fall into two broad categories • functional • non-functional

14. Functional Requirements • Functional requirements are concerned with what the software must do • capabilities, services, or operations • Functional requirements are not concerned with how the software does things, i.e., they must be free of design considerations

15. Non-Functional Requirements • Non-functional requirements place restrictions on the range of acceptable solutions • Non-functional requirements cover a broad range of issues • interface constraints • performance constraints • operating constraints • life-cycle constraints • economic constraints • political constraints • manufacturing

16. Case Study: Sensor Display • Consider a small system that displays the status of several sensors (e.g., pressure, temperature, rate of change, etc.) on a limited-size screen • What are some of its functional requirements? • What are some of its non-functional requirements?

17. The Waterfall Model Requirements Definition System and Software design Programming and Unit Testing Integration and System Testing Operation and Maintenance

18. [2] System and Software Design System design: Partition the requirements to hardware or software systems. Establishes an overall system architecture Software design: Represent the software system functions in a form that can be transformed into one or more executable programs  Unified Modeling Language (UML)

19. Case study Children hospital • Care for children in the Alexandria city and some Arab countries • The average length of stay of inpatients is 3.6 days • All patients are accompanied by a parent for the entire duration of their stay at hospital

20. The Waterfall Model Requirements Definition System and Software design Programming and Unit Testing Integration and System Testing Operation and Maintenance

21. [3] Programming and Unit Testing The software design is realized as a set of programs or program units. (Written specifically, acquired from elsewhere, or modified.) Individual components are tested against specifications.

22. [4] Integration and System Testing The individual program units are:  integrated and tested as a complete system  tested against the requirements as specified  delivered to the client

23. [5] Operation and Maintenance  Operation: The system is put into practical use.  Maintenance: Errors and problems are identified and fixed.  Evolution: The system evolves over time as requirements change, to add new functions or adapt the technical environment.  Phase out: The system is withdrawn from service.

24. Discussion of the Waterfall Model Advantages:  Process visibility  Dependence on individuals  Quality control  Cost control

25. The Classical Software Lifecycle The classical software lifecycle models the software development as a step-by-step “waterfall” between the various development phases. Requirements Collection Analysis Design Implementation Testing Maintenance • The waterfall model is unrealistic for many reasons: • requirements must be frozen too early in the life-cycle • requirements are validated too late

26. Problems with the Waterfall Lifecycle • “Real projects rarely follow the sequential flow that the model proposes. Iteration always occurs and creates problems in the application of the paradigm” • “It is often difficult for the customer to state all requirements explicitly. The classic life cycle requires this and has difficulty accommodating the natural uncertainty that exists at the beginning of many projects.” • Each stage in the process reveals new understanding of the previous stages, that requires the earlier stages to be revised.

27. design design design design code code code code test test test test integrate integrate integrate integrate O&M O&M O&M O&M Release 1 Incremental development (each release adds more functionality) Requirements release 2 release 3 release 4 version 1 reqts reqts design design code code test test integrate integrate O&M O&M lessons learnt version 2 lessons learnt Evolutionary development (each version incorporates new requirements) version 3 reqts design code test integrate Phased Modelsmaterial adapted from Steve Easterbrook

28. Incremental Development Plan to incrementally develop (i.e., prototype) the system. • If possible, always have a running version of the system, even if most functionality is yet to be implemented. • Integrate new functionality as soon as possible. • Validate incremental versions against user requirements.

29. The Unified Process Inception Elaboration Construction Transition Requirements Analysis Design Implementation Test Iter. Iter. Iter. Iter. #1 #2 ... ... ... ... ... ... #n-1 #n How do you plan the number of iterations? How do you decide on completion?

30. Incremental development

31. Incremental delivery • Rather than deliver the system as a single delivery, the development and delivery is broken down into increments with each increment delivering part of the required functionality. • User requirements are prioritised and the highest priority requirements are included in early increments. • It is easier to get customer feedback on the development work that has been done.

32. Incremental development advantages • Customer value can be delivered with each increment so system functionality is available earlier. • Early increments act as a prototype to help elicit requirements for later increments. • Lower risk of overall project failure. • The highest priority system services tend to receive the most testing. • The cost of accommodating changing customer requirements is reduced.

33. Iterative Development In practice, development is always iterative, and all activities progress in parallel. Requirements Testing based on requirements Collection Testing Maintenance through iteration Analysis Testing throughout implementation Validation through prototyping If the waterfall model is pure fiction, why is it still the dominant software process? Implementation Design Design through refactoring

34. Iterative Refinement Requirements Evaluation Implementation (prototype) Design

35. Evolutionary Process Model

36. Requirements Design Design Coding Coding Test Test Deployment Deployment Requirements Requirements Design Coding Test Deployment Evolutionary Version 1 Version 1 Feedback Version 1 New versions implement new and evolving requirements (Some call it iterative)

37. Evolutionary development • Problems • Lack of process visibility; • Systems are often poorly structured; • Special skills (e.g. in languages for rapid prototyping) may be required. • Applicability • For small or medium-size interactive systems; • For parts of large systems (e.g. the user interface); • For short-lifetime systems.

38. Build and Fix Model • Advantage • Appropriate for small programs written by one person • Disadvantage • Understandability and maintainability decrease rapidly with increasing program size • Totally unsatisfactory • Need a life-cycle model • “Game plan” • Phases • Milestones

39. Spiral development • Process is represented as a spiral rather than as a sequence of activities with backtracking. • Each loop in the spiral represents a phase in the process. • No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required. • Risks are explicitly assessed and resolved throughout the process.

40. Determine goals, alternatives, constraints Evaluate alternatives and risks constraints4 risk analysis4 constraints3 risk analysis3 Constr- aints2 alternatives4 risk analysis2 alternatives3 Altern- atives2 alternatives constraints risk analysis1 budget4 budget3 budget2 budget1 prototype1 prototype2 prototype3 prototype4 concept of operation software requirements detailed design requirements, lifecycle plan software design development plan validated requirements code integration and test plan validated, verified design unit test Plan Develop and test system test acceptance test implementation plan Spiral Modelmaterial adapted from Steve Easterbrook

41. Boehm’s Spiral Lifecycle Planning = determination Risk Analysis = Analysis of of objectives, alternatives alternatives and identification/ and constraints resolution of risks Risk = something that will delay project or initial requirements increase its cost go, no-go decision completion first prototype alpha demo Engineering = Customer Evaluation = Development of the Assessment of the next level product evolving system results of engineering

42. Spiral model sectors • Objective setting • Specific objectives for the phase are identified. • Risk assessment and reduction • Risks are assessed and activities put in place to reduce the key risks. • Development and validation • A development model for the system is chosen which can be any of the generic models. • Planning • The project is reviewed and the next phase of the spiral is planned.

43. Spiral Model Advantages • Focuses attention on reuse options. • Focuses attention on early error elimination. • Puts quality objectives up front. • Integrates development and maintenance. • Provides a framework for hardware/software development.

44. Prototyping Modelmaterial adapted from Steve Easterbrook • Prototyping is used for: • Understanding the requirements for the user interface • Examining feasibility of a proposed design approach • Exploring system performance issues • Problems • Users treat the prototype as the solution • A prototype is only a partial specification

45. system requirements system integration Level of abstraction software requirements acceptance test preliminary design software integration “test and integrate” “analyze and design” detailed design component test code and debug unit test time V Modelmaterial adapted from Steve Easterbrook

46. Collect User stories code Planning game Each cycle:approx 2 weeks Release integrate test Write test cases Agile Model (XP)material adapted from Steve Easterbrook

47. ATM system

48. Reuse-oriented software engineering • Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems. • Process stages • Component analysis; • Requirements modification; • System design with reuse; • Development and integration. • Reuse is now the standard approach for building many types of business system

49. Types of software component • Web services that are developed according to service standards and which are available for remote invocation. • Collections of objects that are developed as a package to be integrated with a component framework such as .NET or J2EE. • Stand-alone software systems (COTS) that are configured for use in a particular environment.

50. System design • The design is usually documented as a set of graphical models. • Possible models • Object model; • Sequence model; • State transition model; • Structural model; • Data-flow model.