Books

An Integrated Approach to Software

Engineering By Pankaj Jalote Software Engineering By Roger S. Pressman Software Engineering By Ian Sommerwille Software Engineering By Nasib Singh Gill Software Engineering By K.K. Aggarwal

Software
Software is Computer programs, procedures

and possibly associated documentation and data pertaining to the operation of a computer system. The IEEE definition of software lists the following four components of software:
Computer Program Procedures Documentation Data necessary for operating the software system

All four components are needed in order to assure the quality of the software

Difference between s/w and Program

A program is generally complete in itself and

is generally used only by the author of the program. There is usually little documentation or other aids to help people use the program. Because the author is the user, the presence of :bugs is not a major concern. Such programs are not designed with such issues as portability, reliability and usability in mind

Difference between s/w and Program

A software, on the other hand, is used largely by

people other than the developers of the system. The user may be from different background, so a proper user interface is provided. There is sufficient documentation to help these diverse users use the system. Programs are thoroughly tested before operational use. Because the product may be used in variety of environments, portability is a key issue. Much more effort and resources are required for a software product.

Types of software
There are two types of Software Products : Generic Products : These are stand-alone

systems which are produced by the development organizations and sold on the open market to any customer who is able to buy them. Example: Database, word processor, drawing package. Bespoke (or customized products) : These soft wares are specially developed according to the customer requirements. Example : system written to support a particular business process, air traffic control system

Software Applications
System Software : System software is a

collection of programs written to service other programs. Example : operating system, compiler, editor, drivers etc. Real-Time Software : Programs that monitor/analyze/control real world events as they occur are called real-time softwares. A real-time system must respond within strict time constraints. Business Software : Applications in this area restructure existing data in a way that facilitates business operations or management decision making. Example:

Software Applications
Engineering and Scientific Software :

Engineering and scientific software has been characterized by number crunching algorithm. Example : Computer-aided design, system simulation, astronomy etc. Embedded Software : Embedded software resides in read-only memory and is used to control products and systems for the consumer and industrial markets. Example : microwave oven etc.

Software Myths
Software is easy to change Testing software can remove all the errors Reusing software increases safety Software can work right the first time. Software can be designed thoroughly enough

to avoid most integration problems. Software with more features is better software Aim is to develop working programs.

Software Crisis
The problems associated with software

development are characterized as software crisis. In other words, the software crisis is characterized by an inability to develop software on time, on budget and within requirements. Software Problems :
Software is expensive Late, costly and Unreliable Problem of change and rework

Software Engineering
Software Engineering is a discipline whose

aim is the production of fault-free software that satisfies the users needs and that is delivered on time and within budget. Software Engineering is the systematic development, operation, maintenance and retirement of the software. IEEE Definition : Software Engineering is the application of a systematic, disciplined and quantifiable approach to the development, operation and maintenance of software.

Goals of Software Engineering

Improve the productivity of the developing

process Improve the comprehension of the developed software system Controlling and predicting the cost of software development Producing what the customer wants Producing software that satisfies specifications Producing software systems with following attributes :
Reliability

Goals of Software Engineering

Producing the following products in addition

to programs :
Documentation Requirement Documents Development Plans

Improve the quality of the software product at

all levels.

Principles of Software Engineering

These are the rules, which have to follow by software

development community ; Making quality as a primary. Give products to customers early Determine the problem before writing the requirements Evaluate design alternatives Use an appropriate process model Minimize intellectual distance Put technique before tools Inspect code Good management is more important than good technology

Essential Characteristics of wellengineered software product

Software engineering is not just about producing

software products but involves producing software product in a cost-effective manner. Efficiency : Software should not make wasteful use of system resources such as memory and processor cycles. Maintainability : It should be possible to evolve software to meet the changing requirements of the customers. Dependability : It is the ability of the software that should not cause any physical or economic damage in the event of the system failure.

Essential Characteristics of wellengineered software product

Usability : Software should have an appropriate

user interface and an adequate documentation On time : Software should be developed well in time. Within budget : The software development costs should not overrun and it should be within budgetary limits. Functionality : The software system should exhibit proper functionality. Adaptability : The software system should have the ability of getting adopted to a reasonable extent with the changing requirement

Software Process
According to Webster, the process means a

particular method of doing something, generally involving a number of steps or operation. Software process refers to the method of developing software. Definition : A software process is a set of activities, together with ordering constraints among them, such that if the activities are performed properly and in accordance with the ordering constraints, the desired result is produced. The desired result is high-quality

Process Activities
Software specification : The functionality of

the software and constraints on its operation must be defined. Software development : The software to meet the specification must be produced. Software validation : The software must be validated to ensure that it does what the customer wants. Software evolution : The software must evolve to meet changing customer needs. Different software processes organize these activities in different ways are described at different levels of details.

Process, Project and Products

Software Process specifies a method of developing

software Software Project is a development project in which software process is used. Software Products are the outcome of a software project. A software process specifies the abstract set of activities that should be performed to go from user needs to final product. The actual act of executing the activities for some specific user needs is a software project. And all the outputs that are produced while the activities are being executed are the products.

Software processes

Project 1

Project i

Project n

Product 1 Product 2 Product m

Characteristics of a software Process

Optimality : Optimality means that the process

should be able to produce high-quality software at low cost. Scalability : Scalability means that it should also be applicable for large software projects. Predictability : Predictability of a process determines how accurately the outcome of following a process in a project can be predicted before the project is completed.
A predictable process is said to be under statistical

control. A process is under statistical control if following the same process produces similar results.

Characteristics of a software Process

Support Testability and Maintainability : The

goal of the process should not be to reduce the effort of design and coding, but to reduce the cost of testing and maintenance because testing and maintenance require more effort as compared to coding.

Characteristics of a software Process

Early Defect Removal and Defect Prevention :

Software process should attempt to detect errors that occur in a phase during that phase itself and should not wait until testing to detect errors. The greater the delay in detecting an error after it occurs, the more expensive it is to correct it. An error that occurs during the requirements phase, if corrected during acceptance testing, can cost up to 100 times more than correcting the error during the requirement phase itself. Even better is to provide support for defect prevention. This requires that the process of performing the activities should be such that fewer defects are

Characteristics of a software Process

Process Improvement : Having process

improvement as a basic goal of the software process implies that the software process used is such that it supports its improvement. This requires that there be means for evaluating the existing process and understanding the weakness in the process. Only when support for these activities is available can process improvement be undertaken.

Multiple processes
A large software development company may

have multiple development processes

A. For client-server based conventional applications

(sales processing, payroll) B. For enterprise-level (ERP) projects based on packages and customization C. For web-based e-commerce type D. For data-warehousing/decision-support type

The company may have many projects in

each category

Software Process Model

A Development process model specifies some

activities that, according to the model, should be performed and the order in which they should be performed. The 4 basic software process models are used :
Waterfall Model Prototyping Iterative Enhancement Spiral Model

Process step
A production process is a sequence of steps. Each step performs a well-defined activity leading

toward the satisfaction of the project goal, with the output of one step forming the input of the next one. Step must be executed as per project plan that gives duration, effort, resources, constraints, etc. It must produce information for management so that corrective actions can be taken E.g., adding more resources A step ends in a review (V&V) Verification: check consistency of outputs with inputs (of the step) Validation: check consistency with user needs

CONTROL (entry criteria) actions to be carried inputs out Process V&V INPUT Step (entry criteria)

Information to (exit criteria) Management Process Review V&V

outputs Output

Project Control info

(exit criteria) info for management

Water Fall Model

The Waterfall life model was introduced by Winston

Royce in 1970. The simplest process model is waterfall model, which states that the phases are organized in a linear order. In a typical model, a project begins with feasibility analysis. On successfully demonstrating the feasibility of a project, the requirements analysis and project planning begins. The design starts after the requirements analysis is complete, and coding begins after the design is complete.

Water Fall Model

On successful completion of testing, the system is

installed. After this, the regular operation and maintenance of the system takes place. Linear ordering of activities has some important consequences. First, to clearly identify the end of a phase and the beginning of the next, some certification mechanism has to be employed at the end of each phase. This is usually done by some verification and validation means that will ensure that the output of a phase is consistent with its input and that the

Deliverables in Waterfall Model

Requirements document (SRS : Software

Requirement Specifications) Project plan System design document Detailed design document Test plans and test reports Source code Software manuals (user manual, installation manual) Review reports

Shortcomings of Waterfall Model

Requirements may not be clearly known,

especially for applications not having existing (manual) counterpart. Requirements change with time during project life cycle itself The hardware technology will become obsolete Considered documentation-heavy: so much documentation may not be required for all types of projects.

Prototyping
A prototype is a working model that is functionally

equivalent to a component of the product. The basic idea in prototyping is that instead of freezing the requirements before any design or coding can proceed, a throwaway prototype is built to help understand the requirements. Development of the prototype undergoes design, coding and testing but each of these phases is not done very thoroughly. By using this prototype, the client can get an actual feel of the system. This results in more stable requirements that change less frequently.

Prototyping
Prototyping is an attractive idea for

complicated and large systems for which there is no manual process or existing system to help determine the requirements. A development process using throwaway prototyping proceeds as follows. The development of the prototype typically starts when the preliminary version of the requirements specification document has been developed. After the prototype has been developed, the

Prototyping
Based on the feedback, the prototype is

modified to incorporate some of the suggested changes that can be done easily and then the users and clients are again allowed to use the system. This cycle repeats until, in the judgment of the prototypers and analysts, the benefit from further changing the system outweighed by the cost and time involved in making the changes. Only those features are included in the prototype that will have a valuable return from the user experience.

Prototyping

Advantages of prototype
Reduced time and costs: Prototyping can

improve the quality of requirements and specifications provided to developers. Because changes cost exponentially more to implement as they are detected later in development, the early determination of what the user really wants can result in faster and less expensive software. Improved and increased user involvement: Prototyping requires user involvement and allows them to see and interact with a prototype allowing them to provide better and more complete feedback

Disadvantages of prototype
Insufficient analysis: The focus on a limited prototype

can distract developers from properly analyzing the complete project. User confusion of prototype and finished system: Users can begin to think that a prototype, intended to be thrown away, is actually a final system that merely needs to be finished or polished. Developer attachment to prototype: Developers can also become attached to prototypes they have spent a great deal of effort producing; this can lead to problems like attempting to convert a limited prototype into a final system. Excessive development time of the prototype: A key property to prototyping is the fact that it is supposed to be done quickly. If the developers lose sight of this fact, they very well may try to develop a

Iterative Enhancement
Iterative Enhancement tries to combine the

benefits of both prototyping and the waterfall model. The basic idea is that the software should be developed in increments, where each increment adds some functional capability to the system until the full system is implemented. An advantage of this approach is that it can result in better testing, since testing each increment is likely to be easier than testing entire system like in the waterfall model. Furthermore, as in prototyping, the increments provides feedback to the client which is useful for determining the final requirements of the system.

Iterative Enhancement
In the first step of iterative enhancement

model, a simple initial implementation is done for a subset of the overall problem. This subset is the one that contains some of the key aspects of the problem which are easy to understand and implement, and which forms a useful and usable system. A project control list is created which contains, in an order, all the tasks that must be performed to obtain the final implementation. This project control list gives an idea of how

Iterative Enhancement
Each step consists of removing the next step

from the list. Designing the implementation for the selected task, coding and testing the implementation, and performing an analysis of the partial system obtained after this step and updating the list as a result of the analysis. These three phases are called the design phase, implementation phase and analysis phase. The process is iterated until the project

Spiral Model
This is a recent model that has been proposed by

Boehm. As the name suggests, the activities in this model can be organized like a spiral. The spiral has many cycles. The radial dimension represents the cumulative cost incurred in accomplishing the steps dome so far and the angular dimension represents the progress made in completing each cycle of the spiral. Each cycle in the spiral begins with the identification of objectives for that cycle and the different alternatives are possible for achieving the objectives and the imposed constraints.

Spiral Model
The next step in the spiral life cycle model is

to evaluate these different alternatives based on the objectives and constraints. This will also involve identifying uncertainties and risks involved. The next step is to develop strategies that resolve the uncertainties and risks. This step may involve activities such as benchmarking, simulation and prototyping. Next, the software is developed by keeping in mind the risks. Finally the next stage is planned.

Spiral Model Description

The development spiral consists of four

quadrants Quadrant 1: Determine objectives, alternatives, and constraints. Quadrant 2: Evaluate alternatives, identify, resolve risks. Quadrant 3: Develop, verify, next-level product. Quadrant 4: Plan next phases.

Quadrant 1: Determine Objectives, Alternatives, and Constraints

Activities performed in this quadrant include: Establish an understanding of the system or product objectivesnamely performance, functionality, and ability to accommodate change. Investigate implementation alternatives namely design, reuse, procure, modify Investigate constraints imposed on the alternativesnamely technology, cost, schedule, support, and risk. Once the system or products objectives, alternatives, and constraints are understood, Quadrant 2 (Evaluate alternatives,

Quadrant 2: Evaluate Alternatives, Identify, Resolve Risks

Engineering activities performed in this

quadrant select an alternative approach that best satisfies technical, technology, cost, schedule, support, and risk constraints. The focus here is on risk mitigation. Each alternative is investigated and prototyped to reduce the risk associated with the development decisions.

Quadrant 3: Develop, Verify, NextLevel Product

The basic waterfall approach may be

employedmeaning concept of operations, design, development, integration, and test of the next system or product iteration.

Quadrant 4: Plan Next Phases

The spiral development model has one

characteristic that is common to all models the need for advanced technical planning and multidisciplinary reviews at critical staging or control points

Timeboxing
Iterative is linear sequence of iterations Each iteration is a mini waterfall decide the

specs, then plan the iteration Time boxing fix an iteration duration, then determine the specs Divide iteration in a few equal stages Use pipelining concepts to execute iterations in parallel

Sofware Process

54

Time Boxed Iterations

General iterative development fix the

functionality for each iteration, then plan and execute it In time boxed iterations fix the duration of iteration and adjust the functionality to fit it Completion time is fixed, the functionality to be delivered is flexible

Sofware Process

55

Time boxed Iteration

This itself very useful in many situations Has predictable delivery times Overall product release and marketing can be

better planned Makes time a non-negotiable parameter and helps focus attention on schedule Prevents requirements bloating Overall dev time is still unchanged

Sofware Process

56

Timeboxing Taking Time Boxed Iterations Further

What if we have multiple iterations executing

in parallel Can reduce the average completion time by exploiting parallelism For parallel execution, can borrow pipelining concepts from hardware This leads to Timeboxing Process Model

Sofware Process

57

Timeboxing Model Basics

Development is done iteratively in fixed

duration time boxes Each time box divided in fixed stages Each stage performs a clearly defined task that can be done independently Each stage approximately equal in duration There is a dedicated team for each stage When one stage team finishes, it hands over the project to the next team
Sofware Process 58

Timeboxing
With this type of time boxes, can use

pipelining to reduce cycle time Like hardware pipelining view each iteration as an instruction As stages have dedicated teams, simultaneous execution of different iterations is possible

Sofware Process

59

Example
An iteration with three stages Analysis,

Build, Deploy

These stages are appx equal in many situations Can adjust durations by determining the

boudaries suitably Can adjust duration by adjusting the team size for each stage

Have separate teams for A, B, and D

Sofware Process

60

Pipelined Execution
AT starts executing it-1 AT finishes, hands over it-1 to BT, starts

executing it-2 AT finishes it-2, hands over to BT; BT finishes it-1, hands over to DT; AT starts it-3, BT starts it-2 (and DT, it-1)

Sofware Process

61

Timeboxing Execution
Software TB 1 Requirements Build Deploy

TB 1

Requirements

Build

Deploy

TB 1 TB 1

Requirements

Build Requirements

Deploy Build Deploy

Sofware Process

62

Timeboxing execution
First iteration finishes at time T Second finishes at T+T/3; third at T+2 T/3,

and so on In steady state, delivery every T/3 time If T is 3 weeks, first delivery after 3 wks, 2nd after 4 wks, 3rd after 5 wks, In linear execution, delivery times will be 3 wks, 6 wks, 9 wks,

Sofware Process

63

Team Size
In linear execution of iterations, the same

team performs all stages If each stage has a team of S, in linear execution the team size is S In pipelined execution, the team size is three times (one for each stage) I.e. the total team size in timeboxing is larger; and this reduces cycle time

Sofware Process

64

Team Size
Merely by increasing the team size we cannot

reduce cycle time - Brooks law Timeboxing allows structured way to add manpower to reduce cycle time Note that we cannot change the time of an iteration Brooks law still holds Work allocation different to allow larger team to function properly

Sofware Process

65

Work Allocation of Teams

R e q u ir e m e nRtse q u ir e m e n tsR e q u ir e m e n t sR e q u ir e m e n t sR e q u ir e m e n ts A n a ly s is fo r TA n a ly s is f o r TA n a ly s is fo r TA n a ly s is f o r T B 1 B 1 B 1 B 1 Team B u ild T e a m D e p lo y m e n t Team
B u ild f o r1T B B u ild fo r1T B B u ild f o r1T B B u ild f o r1T B

D e p lo y m e n t 1 re T B y m e n t 1 re T Bo y m e n t 1 r T B fo p lo D fD p l o fo

Sofware Process

66

Timeboxing
Advantages: Shortened delivery times, other

adv of iterative, distr. execution Disadvantages: Larger teams, proj mgmt is harder, high synchronization needed, CM is harder Applicability: When short delivery times v. imp.; architecture is stable; flexibility in feature grouping

Sofware Process

67

waterfall
Strength Simple Easy to execute Intuitive and logical Easy contractually Weakness All or nothing too risky Req frozen early May chose outdated hardware/tech Disallows changes No feedback from users Encourages req bloating Types of Projects Well understood problems, short duration projects, automation of existing manual systems

Sofware Process

68

Prototyping
Strength Weakness Types of Projects Systems with novice users; or areas with req uncertainity. Heavy reporting based systems can benefit from UI proto Helps req elicitation Front heavy Reduces risk Possibly higher cost Better and more stableand schedule final system Encourages req bloating Disallows later change

Sofware Process

69

Iterative
Strength Regular deliveries, leading to biz benefit Can accommodate changes naturally Allows user feedback Avoids req bloating Naturally prioritizes req Allows reasonable exit points Reduces risks Weakness Overhead of planning each iteration Total cost may increase System arch and design may suffer Rework may increase Types of Projects For businesses where time is imp; risk of long projects cannot be taken; req not known and evolve with time

Sofware Process

70

Timeboxing
Strength Weakness Types of Projects Where very short delivery times are very important Where flexibility in grouping features Arch is stable All benefits of iterative PM becomes more Planning for iterations complex somewhat easier Team size is larger Very short delivery Complicated lapses times can lead to losses

Sofware Process

71

Software Project management

Proper management is an integral part of software

development. A large software development project involves many people working for a long period of time. We have seen that a development process typically partition the problem of developing software into a set of phases. To meet the cost, quality and schedule objectives, resources have to be properly allocated to each activity for the project, and progress of different activities has to be monitored and corrective actions taken, if needed. All these activities are part of the project management process. The focus of the management process is on issues like planning a project, estimating resources and schedule

Software management distinctions

The product is intangible There are no standard software processes. Many software projects are 'one-off' projects.

Management activities
Proposal writing. Project planning and scheduling. Project costing. Project monitoring and reviews. Personnel selection and evaluation. Report writing and presentations.

Software Requirements
The description of the services and constraint

s are the requirements for the system and the process of finding out, analyzing, documenting and checking these services and constraints is called requirement engineering. Note that in software requirements we are dealing with the requirements of the proposed system, that is, the capability that the system, which is yet to be developed, should have. It is because we are dealing with specifying a system that does not exist in any form, that the problem of requirements becomes

Software Requirements
Regardless of how the requirements phase

proceeds, it ultimately ends with the software Requirement Specification (SRS). SRS is a document that completely describes what the proposed system should do without describing how to do.

Types of requirement
User requirements
Statements in natural language (NL) 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

U ser requir ent definition em 1 T softw must pr vide a m eans of . he are o representing and 1 accessing xternal files eated by other tools . e cr . Syst em requir m ents specification e 11The user should beovided with facilities to define the type of . pr 11 . external files . 11 Each xternal file type m a ve an associa tool which my be . e y ha ted a 11 . applied to the file . 11Each xternal file type m a r presented as a specific icon on . e y be e 11the user displa . s y . 11F . acilities should beovided or the icon epresenting an pr f r 11 . external file type to be defined b user y the . 11When a user selects an icon r . epresenting an xternal file e , the 11effect of that selection is to apply the tool associated with the type of . 11the external file to the file represented by the selected icon. .

U ser requir m ents e

Client m ana gers System end-users Client eng i neers Contractor m ana gers System ar chitects

System requir m ents e

System end-users Client eng i neers System ar chitects Software dev elopers

Software design specifica tion

Client eng i neers (perha ps) System ar chitects Software dev elopers

Functional and non-functional requirements

Functional requirements
These are the statements of services the system should

provide, how the system should react to particular inputs and how the system should behave in particular situations. In some cases, the functional requirements may also explicitly state what the system should not do.

Non-functional requirements
These are the constraints on the services or functions

offered by the system such as timing constraints, constraints on the development process, standards, etc.

Domain requirements
Requirements that come from the application domain of

the system and that reflect characteristics of that domain.

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.

Requirements Engineering Activities

Requirements Elicitation : Requirements

elicitation is the activity during which software requirements are discovered, articulated and revealed from stakeholders. Requirement Analysis : Requirement Analysis is the activity during which the requirements gathered during elicitation are analyzed for conflicts, ambiguity, inconsistencies or missing requirements. Requirement Specification : Requirement specification is the activity during which requirements are recorded in one or more forms, usually is a Software Requirement

Requirements Engineering Activities

Requirement validation : Requirement

validation is the activity during which the requirements are checked for omitted, extra, ambiguous and inconsistent requirements. Requirement management : Requirement Management involves establishing and maintaining an agreement with the customer on the requirements for the software project.

Software Requirement Specification

The SRS is a document that completely

describes what the proposed software should do without describing how the software will do it. It can be a written document, a graphical model, a formal mathematical model, a prototype or any combination of these. Some suggest that a standard template should be developed and used for a system specification, arguing that this leads to requirements that are presented in a consistent and therefore more understandable

Need for SRS

An SRS establishes the basis for agreement

between the client and the supplier on what the software product will do. An SRS provides a reference for validation for the final product A high quality SRS is a prerequisite to high quality software. A high-quality SRS reduces the development cost.

Characteristics of SRS
Correct : A SRS is correct if every requirement

included in the SRS represents something required in the final system. Complete : An SRS is complete if everything the software supposed to do is specified in the SRS. Unambiguous : An SRS is unambiguous if and only if every requirement stated has one and only one interpretation. Verifiable : A requirement is variable if there exist some cost effective process that can check whether the final software meets that requirements.

Characteristics of SRS
Consistent : An SRS is consistent if there is no

requirement that conflict with another. Modifiable : An SRS is modifiable if its structure and style are such that any necessary changes can be made easily while preserving completeness and consistency.

Components of an SRS
Functionality : Functional requirements

specify which output should be produced from the given inputs. Performance : All the requirements relating to the performance characteristics of the system must be clearly specified.
2 types of performance requirements : Static requirements are those that do not

impose constraint on the execution characteristics of the system. Dynamic requirements specify constraints on the execution behavior of the system.

Components of an SRS
Design constraints on an implementation :

There are a number of factors in the clients environment that may restrict the choices of a designer. Such factors include standards that must be followed.
Standard Compliance : Standards may include

the report format and accounting procedures. Hardware Limitations : The software nay have to operate on some existing hardware, thus imposing restrictions on the design. Reliability and fault tolerance : Requirements about system behavior in the face of certain kinds of faults is specified.

External interfaces

What is not included in an SRS ?

Project requirements cost, delivery schedules, staffing, reporting procedures Design solutions
partitioning of SW into modules, choosing data

structures

Product assurance plans Quality Assurance procedures, Configuration Management procedures, Verification & Validation procedures

Uses of SRS Document

Project managers base their plans and

estimates of schedule, effort and resources on it. Development team needs it to develop product. The testing group needs it to generate test plans based on the described external behavior. The maintenance and product support staff need it to understand what the software product is supposed to do. The publications group writes documentation, manuals etc from it.

Prototype
A prototype is an initial version of a software

system which is used to demonstrate concepts, try out design options and generally to find out more about the problem and its possible solution. Rapid development of the prototype is essential so that costs are controlled and users can experiment with the prototype early in the software process. Prototyping can be used as a risk analysis and reduction technique. A significant risk in software development is

Uses of system prototypes

Requirements elicitation : Users can

experiment with a prototype to see how the system supports their work Requirements validation : The prototype can reveal errors and omissions in the requirements Experiments have shown that prototyping reduces the number of problems with the requirements specifications. Furthermore, the overall development costs may be lower if a prototype is developed.

Prototyping benefits
Misunderstandings between software users

and developers are exposed Missing services may be detected and confusing services may be identified A working system is available early in the process The prototype may serve as a basis for deriving a system specification The system can support user training and system testing

Prototyping benefits
Improved system usability Closer match to the system needed Improved design quality Improved maintainability Reduced overall development effort

Establish prototype objectives

Define prototype functionality

Develop prototype

Evaluate prototype

Prototyping plan

Outline definition

Executable prototype

Evaluation report

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

Evolutionary prototyping Outline Requirements Throw-away Prototyping

Delivered system

Executable Prototype + System Specification

Prototyping objectives
The objective of evolutionary prototyping is to

deliver a working system to end-users. The development starts with those requirements which are best understood. The objective of throw-away prototyping is to validate or derive the system requirements. The prototyping process starts with those requirements which are poorly understood

Evolutionary prototyping
Must be used for systems where the

specification cannot be developed in advance e.g. AI systems and user interface systems Based on techniques which allow rapid system iterations Verification is impossible as there is no specification. Validation means demonstrating the adequacy of the system

Develop abstract specification

Build prototype system

Use prototype system

N Deliver system YES System adequate?

Evolutionary prototyping advantages

Accelerated delivery of the system Rapid delivery and deployment are sometimes more important than functionality or long-term software maintainability User engagement with the system
Not only is the system more likely to meet user

requirements, they are more likely to commit to the use of the system

Evolutionary prototyping
Specification, design and implementation are

inter-twined The system is developed as a series of increments that are delivered to the customer Techniques for rapid system development are used, such as CASE tools and 4GLs User interfaces are usually developed using a GUI development toolkit

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

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 as some system characteristics may have been left out

Outline requirements Reusable components

Develop prototype

Evaluate prototype

Specify system

Develop software

Validate system

Delivered software system

Prototype delivery
Developers may be pressured to deliver a

throw-away prototype as a final system This is not recommended

It may be impossible to tune the prototype to

meet non-functional requirements The prototype is inevitably undocumented The system structure will be degraded through changes made during development Normal organisational quality standards may not have been applied

Rapid prototyping techniques

Various techniques may be used for rapid

development
Dynamic high-level language development Database programming Component and application assembly

These are not exclusive techniques - they are

often used together Visual programming is an inherent part of most prototype development systems

Dynamic high-level languages

Languages which include powerful data

management facilities Need a large run-time support system. Not normally used for large system development. (Less of a problem nowadays) Some languages offer excellent UI development facilities

Prototyping Languages
Java
Object-oriented, interactive

LISP
AI-based

Visual Basic HTML+Javascript, HTML+Java

Web browser as graphical display

Database programming languages

Domain specific languages for business

systems based around a database management system Normally include a database query language, a screen generator, a report generator and a spreadsheet. May be integrated with a CASE toolset The language + environment is sometimes known as a fourth-generation language (4GL) Cost-effective for small- to medium-sized

Interface generator DB programming language

Spreadsheet Report generator

Database management system

Fourth-gener ation language

Component and application assembly

Prototypes can be created quickly from a set

of reusable components plus some mechanism to glue these component together The composition mechanism must include control facilities and a mechanism for component communication The system specification must take into account the availability and functionality of existing components

Compound documents
For some applications, a prototype can be

created by developing a compound document This is a document with active elements (such as a spreadsheet) that allow user computations Each active element has an associated application which is invoked when that element is selected The document itself is the integrator for the different applications

Compound document Text 1 Table 1 Text 1 Text 1 Sound 1

Table 1

Text 1

Sound 1

Text 1

Word processor

Spreadsheet

Audio player