SOFTWARE PROCESSES MUHAMMAD RIZWAN Fall 2012

Objectives  To introduce software process models  To describe three generic process models and when they may be used  To describe outline of process models for requirements engineering, software development, testing and evolution  To explain the Rational Unified Process model  To introduce CASE technology to support software process activities

Topics covered  Software process models  Process iteration  Process activities  The Rational Unified Process  Computer-aided software engineering (CASE)

4 The phases of a software development cycle.  Analysis:  Specification  Design  Implementation  Testing  Delivery/Maintenance Software Life Cycle

5 Feasibility study – WHY? Cost benefit analysis (is it worth doing the project) Requirements analysis + specification: WHAT? What should the software do, produce a document. Design - How? How should the software do it. Architectural design (overall structures + organization of objects/modules, choice of data structures, etc. Coding/Implementation: Realize ! components. Code modules, products: software, Testing: Realize ! Test individual modules, test whether several modules work together, test system as a whole, document test results. Deliver and maintenance : Evolve! Software Life Cycle

6 Good Engineering Practice (Analysis - The Starting Point) A Legacy System: Does not provide any longer state-of the art technology, lack of functionality and user friendliness

Good Engineering Practice (More Analysis) What are the customer expectations? Frequently these might be unrealistic and not functional (see the wheels) 7

Good Engineering Practice (Specifications) Based on the analysis a more realistic and functional product is specified. First specification drawings are created. 8

9 Good Engineering Practice (Detailed Specifications) Interior and exterior are specified in more detail

Good Engineering Practice (Design) First 1: 4 design models are created 10

11 Good Engineering Practice (More Design) First 1:1 models are created, leading to a more realistic design of the new car.

12 Good Engineering Practice (More Design and first Testing) Prototypes are tested, re-designed and re-tested if necessary

13 Good Engineering Practice (Implementation) Product is product and final tests are conducted before product is shipped

Good Engineering Practice (Final Product) The final product is introduced: Meeting the customer requirements with respect to design and functionality. 14

15 Good Engineering Practice (Maintenance) The maintenance process for the new models are introduced:

Layered View of SE  Layered approach:  Process.  Methods.  Tools. Software Engineering a “quality” focus process model methods tools

The software process  A structured set of activities required to develop a software system  Specification – defining what the system should do;  Design and implementation – defining the organization of the system and implementing the system;  Validation – checking that it does what the customer wants;  Evolution – changing the system in response to changing customer needs.  A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective.

Software Process Models A software process model is a standardised format for  planning  organising, and  running a new development project. 18

Planning with Models SE projects usually live with a fixed financial budget. (An exception is maintainance?) Additionally, time-to-market places a strong time constraint. There will be other project constraints such as staff. 19

Project constraints money time Computing resources Examples of Project Constraints 20 staff programmersmanagers designers

Planning with Process Models Project planning is the art of scheduling the necessary activities, in time, space and across staff in order to optimise:  project risk [low] (see later)  profit [high]  customer satisfaction [high]  worker satisfaction [high]  long-term company goals 21

Generic software process models  The waterfall model  Separate and distinct phases of specification and development.  Incremental development  Specification, development and validation are interleaved. May be plan-driven or agile  Reuse-oriented software engineering  The system is assembled from existing components. May be plan-driven or agile.

The Waterfall Model 23

Advantages 1. Easy to understand and implement. 2. Widely used and known (in theory!) 3. Reinforces good habits: define-before- design, design-before-code 4. Identifies deliverables and milestones 5. Document driven, URD, SRD, … etc. Published documentation standards, e.g. PSS Works well on mature products and weak teams. 24

Disadvantages I 1. Idealised, doesn’t match reality well. 2. Doesn’t reflect iterative nature of exploratory development. 3. Unrealistic to expect accurate requirements so early in project 4. Software is delivered late in project, delays discovery of serious errors. 25

Disadvantages II 5. Difficult to integrate risk management 6. Difficult and expensive to make changes to documents, ”swimming upstream”. 7. Significant administrative overhead, costly for small teams and projects. 26

Incremental development  Objective is to work with customers and to evolve a final system from an initial outline specification. Should start with well-understood requirements and add new features as proposed by the customer.(Create different versions) Reduce cost Easy to get customer feedback Rapid delivery & deployment of software  Throw-away prototyping  Objective is to understand the system requirements. Should start with poorly understood requirements to clarify what is really needed.

28 Chapter 2 Software Processes Incremental 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. Incremental 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 increasingly used as component standards have emerged.  e.g. using databases, spread sheets, word proccessors, graphics software, web browsers, etc. Reuse-oriented development

Advantages  Fast, cheap solution  May give all the basic functionality  Well defined project, easy to run Disadvantages  Limited functionality  Licensing problems, freeware, shareware, etc.  License fees, maintainance fees, upgrade compatibility problems Reuse-oriented development

Spiral Model  Since end-user requirements are hard to obtain/define, it is natural to develop software in an experimental way: e.g. 1.Build some software 2.See if it meets customer requirements 3.If no goto 1 else stop.

Boehm’s spiral model  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. 34 Chapter 2 Software Processes

Boehm’s spiral model of the software process 35 Chapter 2 Software Processes

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.

Spiral Model Discussion  Pros 1. Realism: the model accurately reflects the iterative nature of software development on projects with unclear requirements 2. Comprehensive model decreases risk 3. Good project visibility.  Cons 1. Needs technical expertise in risk analysis to really work 2. Model is poorly understood by non-technical management, hence not so widely used 3. Complicated model, needs competent professional management. High administrative overhead. 37

Process activities  Software specification  Software design and implementation  Software validation  Software evolution  They are organized differently in different development processes. In the waterfall model, they are organized in sequence, whereas in incremental development they are inter-leaved. 38 Chapter 2 Software Processes

Software specification  The process of establishing what services are required and the constraints of the system’s operation and development.  Requirements engineering process  Feasibility study Is it technically and financially feasible to build the system?  Requirements elicitation and analysis What do the system stakeholders require or expect from the system?  Requirements specification Defining the requirements in detail  Requirements validation Checking the validity of the requirements 39 Chapter 2 Software Processes

The requirements engineering process

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 inter-leaved. 41 Chapter 2 Software Processes

Design process activities  Architectural design, where you identify the overall structure of the system, the principal components (sometimes called sub-systems or modules), their relationships and how they are distributed.  Interface design, where you define the interfaces between system components.  Component design, where you take each system component and design how it will operate.  Database design, where you design the system data structures and how these are to be represented in a database. 42 Chapter 2 Software Processes

The software design process

Structured methods  Systematic approaches to developing a software design.  The design is usually documented as a set of graphical models.  Possible models  Sequence model; (Use Case)  State transition model; (Submit, Assign)  Structural model;  Data-flow model.

Programming and debugging  Translating a design into a program and removing errors from that program.  Programming is a personal activity - there is no generic programming process.  Programmers carry out some program testing to discover faults in the program and remove these faults in the debugging process.

The debugging process

Software validation  Verification and validation (V & V) is intended to show that a system conforms to its specification and meets the requirements of the 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.  Testing is the most commonly used V & V activity. 47 Chapter 2 Software Processes

The testing process

Testing stages  Component or unit testing  Individual components are tested independently;  Components may be functions or objects or coherent groupings of these entities.  System testing  Testing of the system as a whole. Testing of emergent properties is particularly important.  Acceptance testing  Testing with customer data to check that the system meets the customer’s needs.

Testing phases

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 limit between development and evolution (maintenance) this is increasingly irrelevant as fewer and fewer systems are completely new.

System evolution

Key points  Software processes are the activities involved in producing a software system. Software process models are abstract representations of these processes.  General process models describe the organization of software processes. Examples of these general models include the ‘waterfall’ model, incremental development, and reuse- oriented development. 53 Chapter 2 Software Processes

Key points  Requirements engineering is the process of developing a software specification.  Design and implementation processes are concerned with transforming a requirements specification into an executable software system.  Software validation is the process of checking that the system conforms to its specification and that it meets the real needs of the users of the system.  Software evolution takes place when you change existing software systems to meet new requirements. The software must evolve to remain useful. 54 Chapter 2 Software Processes

The Rational Unified Process  A modern process model derived from the work on the UML and associated process.  Normally described from 3 perspectives  A dynamic perspective that shows phases over time;  A static perspective that shows process activities;  A practice perspective that suggests good practice.

RUP phase model

RUP phases  Inception  Establish the business case for the system.  Elaboration  Develop and understanding of the problem domain and the system architecture.  Construction  System design, programming and testing.  Transition  Deploy the system in its operating environment.

RUP good practice  Develop software iteratively  Manage requirements  Use component-based architectures  Visually model software  Verify software quality  Control changes to software

Computer-aided software engineering  Computer-aided software engineering (CASE) is software to support software development and evolution processes.  Activity automation  Graphical editors for system model development;  Data dictionary to manage design entities;  Graphical UI builder for user interface construction;  Debuggers to support program fault finding;  Automated translators to generate new versions of a program.

Case technology  Case technology has led to significant improvements in the software process. However, these are not the order of magnitude improvements that were once predicted  Software engineering requires creative thought - this is not readily automated;  Software engineering is a team activity and, for large projects, much time is spent in team interactions. CASE technology does not really support these.

CASE classification  Classification helps us understand the different types of CASE tools and their support for process activities.  Functional perspective  Tools are classified according to their specific function.  Process perspective  Tools are classified according to process activities that are supported.  Integration perspective  Tools are classified according to their organisation into integrated units.

Functional tool classification

Activity-based tool classification

Tools, workbenches, environments

Key points  Software processes are the activities involved in producing and evolving a software system.  Software process models are abstract representations of these processes.  General activities are specification, design and implementation, validation and evolution.  Generic process models describe the organisation of software processes. Examples include the waterfall model, evolutionary development and component-based software engineering.  Iterative process models describe the software process as a cycle of activities.

Key points  Requirements engineering is the process of developing a software specification.  Design and implementation processes transform the specification to an executable program.  Validation involves checking that the system meets to its specification and user needs.  Evolution is concerned with modifying the system after it is in use.  The Rational Unified Process is a generic process model that separates activities from phases.  CASE technology supports software process activities.