Midterm Overview

1. Midterm Overview • Software process models • Software Specification • Requirements • Requirements Engineering Processes • System Models • Prototyping

2. The software process • A structured set of activities required to develop a software system. Five components: • Specification • Design • Implementation • Validation • Evolution • A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective

3. Generic software process models • The waterfall model • Separate and distinct phases of specification and development • Evolutionary development • Specification and development are interleaved • Formal systems development • A mathematical system model is formally transformed to an implementation • Reuse-based development • The system is assembled from existing components

4. Waterfall model

5. Waterfall model problems • Inflexible partitioning of the project into distinct stages • This makes it difficult to respond to changing customer requirements • Therefore, this model is only appropriate when the requirements are well-understood

6. Evolutionary development

7. 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

8. Formal systems development • Based on the transformation of a mathematical specification through different representations to an executable program • Transformations are ‘correctness-preserving’ so it is straightforward to show that the program conforms to its specification • Embodied in the ‘Cleanroom’ approach to software development

9. Formal transformations

10. Formal systems development • Problems • Need for specialised skills and training to apply the technique • Difficult to formally specify some aspects of the system such as the user interface • Applicability • Critical systems especially those where a safety or security case must be made before the system is put into operation

11. Reuse-oriented development • 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 • This approach is becoming more important but still limited experience with it

12. Process iteration • System requirements always evolve in the course of a project so process iteration where earlier stages are reworked is always part of the process for large systems • Iteration can be applied to any of the generic process models • Two (related) approaches • Incremental development • Spiral development

13. Incremental development • 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 • Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve

14. Incremental development

15. 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

16. 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

17. Spiral model of the software process

18. 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

19. Software specificationRequirements Engineering • The process of establishing what services are required and the constraints on the system’s operation and development • Requirements engineering process • Feasibility study (“Can we do it on time and effectively?”) • Requirements elicitation and analysis (“What does it need to do?”) • Requirements specification (Write it all down.) • Requirements validation (“Does it all make sense?”)

20. Software design and implementation • The process of converting the system specification into an executable system • Software design • Design a software structure that realises the specification • Implementation • Translate this structure into an executable program • The activities of design and implementation are closely related and may be interleaved

21. Software validation • Verification and validation is intended to show that a system conforms to its specification and meets the requirements of the system customer • Involves checking and review processes and system testing • System testing involves executing the system with test cases that are derived from the specification of the real data to be processed by the system

22. The testing process

23. Testing stages • Unit testing • Individual components are tested • Module testing • Related collections of dependent components are tested • Sub-system testing • Modules are integrated into sub-systems and tested. The focus here should be on interface testing • System testing • Testing of the system as a whole. Testing of emergent properties • Acceptance testing • Testing with customer data to check that it is acceptable

24. Software evolution • Software is inherently flexible and can change. • As requirements change through changing business circumstances, the software that supports the business must also evolve and change • Although there has been a demarcation between development and evolution (maintenance) this is increasingly irrelevant as fewer and fewer systems are completely new

25. Midterm Overview • Software process models • Software Specification • Requirements • Requirements Engineering Processes • System Models • Prototyping

26. Requirements • What is a requirement? • Functional and non-functional requirements • User requirements • System requirements • The software requirements document

27. Types of requirements - Depth • User requirements • Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers • System requirements • A structured document setting out detailed descriptions of the system services. Written as a contract between client and contractor • Software specification • A detailed software description which can serve as a basis for a design or implementation. Written for developers

28. Types of Requirements - Nature • Functional requirementsStatements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. • Non-functional requirementsConstraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. • Domain requirementsRequirements that come from the application domain of the system and that reflect characteristics of that domain. May be functional or non-functional

29. Non-functional classifications • Product requirements • Requirements which specify that the delivered product must behave in a particular way, e.g. execution speed, reliability, etc. • Organisational requirements • Requirements which are a consequence of organisational policies and procedures, e.g. process standards used, implementation requirements, etc. • External requirements • Requirements which arise from factors which are external to the system and its development process, e.g. interoperability requirements, legislative requirements, etc.

30. Completeness and consistency • In principle requirements should be both complete and consistent • Complete • They should include descriptions of all facilities required • Consistent • There should be no conflicts or contradictions in the descriptions of the system facilities • In practice, it is impossible to produce a complete and consistent requirements document

31. Goals and requirements • Non-functional requirements may be very difficult to state precisely and imprecise requirements may be difficult to verify. • Goal • A general intention of the user such as ease of use • Verifiable non-functional requirement • A statement using some measure that can be objectively tested • Goals are helpful to developers as they convey the intentions of the system users

32. Midterm Overview • Software process models • Software Specification • Requirements • Requirements Engineering Processes • System Models • Prototyping

33. Requirements engineering process • Feasibility study(“Can we do it on time and effectively?”) • Requirements elicitation and analysis(“What does it need to do?”) • Requirements specification(Write it all down.) • Requirements validation(“Does it all make sense?”)

34. Feasibility study • Based on information assessment (what is required), information collection and report writing • Questions for people in the organisation • What if the system wasn’t implemented? • What are current process problems? • How will the proposed system help? • What will be the integration problems? • Is new technology needed? What skills? • What facilities must be supported by the proposed system?

35. Elicitation and analysis • Sometimes called requirements elicitation or requirements discovery • Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system’s operational constraints • May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders

36. Elicitation and analysis Problems • Stakeholders don’t know what they really want • Stakeholders express requirements in their own terms • Different stakeholders may have conflicting requirements • Organisational and political factors may influence the system requirements • The requirements change during the analysis process. New stakeholders may emerge and the business environment change

37. Elicitation and AnalysisProcess activities • Domain understanding • Requirements collection • Classification • Conflict resolution • Prioritisation • Requirements checking

38. Midterm Overview • Software process models • Software Specification • Requirements • Requirements Engineering Processes • System Models • Prototyping

39. System models • System modelling helps the analyst to understand the functionality of the system and models are used to communicate with customers • Different models present the system from different perspectives • External perspective showing the system’s context or environment • Behavioural perspective showing the behaviour of the system • Structural perspective showing the system or data architecture

40. System modelsContext models • Context models are used to illustrate the boundaries of a system • Social and organisational concerns may affect the decision on where to position system boundaries

41. System ModelsModel types • Architectural model showing principal sub-systems • Data processing model showing how the data is processed at different stages • Composition model (a.k.a. entity-relationship-attribute model) showing how entities are composed of other entities • Classification model showing how entities have common characteristics • Stimulus/response model showing the system’s reaction to events

42. System ModelsModel languages • Entity-relationship-attribute • State-chart • Semantic data model • Object model • UML (Unified Modeling Language)

43. Midterm Overview • Software process models • Software Specification • Requirements • Requirements Engineering Processes • System Models • Prototyping

44. Prototyping in the software process • Evolutionary prototyping • An approach to system development where an initial prototype is produced and refined through a number of stages to the final system • Throw-away prototyping • A prototype which is usually a practical implementation of the system is produced to help discover requirements problems and then discarded. The system is then developed using some other development process

45. Approaches to prototyping

46. Throw-away prototyping • Used to reduce requirements risk • The prototype is developed from an initial specification, delivered for experiment then discarded • The throw-away prototype should not be considered as a final system • Some system characteristics may have been left out • There is no specification for long-term maintenance • The system will be poorly structured and difficult to maintain

47. Evolutionary prototyping • Specification, design and implementation are inter-twined • The system is developed as a series of increments that are delivered to the customer • User interfaces are usually developed using a GUI development toolkit

48. Evolutionary prototyping problems • Management problems • Existing management processes assume a waterfall model of development • Specialist skills are required which may not be available in all development teams • Maintenance problems • Continual change tends to corrupt system structure so long-term maintenance is expensive • Contractual problems

49. Prototypes as specificationsProblems • Some parts of the requirements (e.g. safety-critical functions) may be impossible to prototype and so don’t appear in the specification • An implementation has no legal standing as a contract • Non-functional requirements cannot be adequately tested in a system prototype

50. Incremental development • Intended to combine some of the advantages of prototyping but with a more manageable process and better system structure • System is developed and delivered in increments after establishing an overall architecture • Requirements and specifications for each increment may be developed • Users may experiment with delivered increments while others are being developed. therefore, these serve as a form of prototype system