Software Eng

BooksAn Integrated Approach to Software

Engineering By Pankaj JaloteSoftware Engineering By Roger S. PressmanSoftware Engineering By Ian SommerwilleSoftware Engineering By Nasib Singh GillSoftware Engineering By K.K. Aggarwal

SoftwareSoftware 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 toassure the quality of the software

Difference between s/w and ProgramA 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 ProgramA 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 softwareThere 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 ApplicationsSystem 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: Payroll, inventory etc.

Software ApplicationsEngineering 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 MythsSoftware is easy to changeTesting software can remove all the errorsReusing software increases safetySoftware can work right the first time.Software can be designed thoroughly enough

to avoid most integration problems.Software with more features is better

softwareAim is to develop working programs.

Software CrisisThe 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 expensiveLate, costly and UnreliableProblem of change and rework

Software EngineeringSoftware Engineering is a discipline whose

aim is the production of fault-free software that satisfies the user’s 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 EngineeringImprove the productivity of the developing processImprove the comprehension of the developed

software systemControlling and predicting the cost of software

developmentProducing what the customer wantsProducing software that satisfies specificationsProducing software systems with following

attributes :ReliabilityEfficiencyClarityExtensibility

Goals of Software EngineeringProducing the following products in addition

to programs :DocumentationRequirement DocumentsDevelopment Plans

Improve the quality of the software product at all levels.

Principles of Software EngineeringThese are the rules, which have to follow by software

development community ;Making quality as a primary.Give products to customers earlyDetermine the problem before writing the requirementsEvaluate design alternativesUse an appropriate process modelMinimize intellectual distancePut technique before toolsInspect codeGood management is more important than good

technologyTake responsibility

Essential Characteristics of well-engineered software productSoftware 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 well-engineered software productUsability : Software should have an appropriate user

interface and an adequate documentationOn 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 ProcessAccording 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 software at low cost.

Process ActivitiesSoftware 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 ProductsSoftware Process specifies a method of developing

softwareSoftware 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 ProcessOptimality : 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 ProcessSupport 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 ProcessEarly 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 introduced.

Characteristics of a software ProcessProcess 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 processesA. For client-server based conventional applications

(sales processing, payroll)B. For enterprise-level (ERP) projects based on

packages and customizationC. For web-based e-commerce typeD. For data-warehousing/decision-support type

The company may have many projects in each category

Software Process ModelA 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 ModelPrototypingIterative EnhancementSpiral 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 takenE.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

ReviewV&V

actions to be carried

out

(entry criteria) (exit criteria)

inputs

Project Control info

info for management

outputs

CONTROL

INPUT

Information to Management Process

OutputProcess Step

V&V

(entry criteria) (exit criteria)

Water Fall ModelThe 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.Once the programming is completed, the code is

integrated and testing done.

Water Fall ModelOn 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 output of the phase is consistent with the overall requirements of the system.

Deliverables in Waterfall ModelRequirements document (SRS : Software

Requirement Specifications)Project plan System design documentDetailed design documentTest plans and test reportsSource codeSoftware manuals (user manual, installation

manual)Review reports

Shortcomings of Waterfall ModelRequirements 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.

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

PrototypingPrototyping 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 end users and clients are given an opportunity to use the prototype and play with it.

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

Development approach is quick and dirty with focus on quick development rather than quality

Prototyping

Advantages of prototypeReduced 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 and specifications.

Disadvantages of prototypeInsufficient 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 prototype that is too complex

Iterative EnhancementIterative 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 EnhancementIn 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 far the project is at any given step from the final system.

Iterative EnhancementEach 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 control list is empty, at the time the final implementation of the system will be available.

Spiral ModelThis 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 ModelThe 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 DescriptionThe 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 objectives—namely performance, functionality, and ability to accommodate change.

Investigate implementation alternatives—namely design, reuse, procure, modify

Investigate constraints imposed on the alternatives—namely technology, cost, schedule, support, and risk. Once the system or product’s objectives, alternatives, and constraints are understood, Quadrant 2 (Evaluate alternatives, identify, and resolve risks) is performed.

Quadrant 2: Evaluate Alternatives, Identify, Resolve RisksEngineering 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, Next-Level ProductThe basic “waterfall” approach may be

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

Quadrant 4: Plan Next PhasesThe 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

Sofware Process 54

TimeboxingIterative is linear sequence of iterationsEach iteration is a mini waterfall – decide the

specs, then plan the iterationTime boxing – fix an iteration duration, then

determine the specsDivide iteration in a few equal stagesUse pipelining concepts to execute iterations

in parallel

Sofware Process 55

Time Boxed IterationsGeneral 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 56

Time boxed IterationThis itself very useful in many situationsHas predictable delivery timesOverall product release and marketing can be

better plannedMakes time a non-negotiable parameter and

helps focus attention on schedulePrevents requirements bloatingOverall dev time is still unchanged

Sofware Process 57

Timeboxing – Taking Time Boxed Iterations FurtherWhat if we have multiple iterations executing

in parallelCan reduce the average completion time by

exploiting parallelismFor parallel execution, can borrow pipelining

concepts from hardwareThis leads to Timeboxing Process Model

Sofware Process 58

Timeboxing Model – BasicsDevelopment is done iteratively in fixed

duration time boxesEach time box divided in fixed stagesEach stage performs a clearly defined

task that can be done independentlyEach stage approximately equal in

durationThere is a dedicated team for each stageWhen one stage team finishes, it hands

over the project to the next team

Sofware Process 59

TimeboxingWith this type of time boxes, can use

pipelining to reduce cycle timeLike hardware pipelining – view each

iteration as an instructionAs stages have dedicated teams,

simultaneous execution of different iterations is possible

Sofware Process 60

ExampleAn iteration with three stages – Analysis,

Build, DeployThese stages are appx equal in many situationsCan adjust durations by determining the

boudaries suitablyCan adjust duration by adjusting the team size

for each stageHave separate teams for A, B, and D

Sofware Process 61

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

executing it-2AT 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 62

Timeboxing Execution Software

Requirements Build Deploy

TB1

TB2

Requirements Build Deploy TB2



Sofware Process 63

Timeboxing executionFirst iteration finishes at time TSecond finishes at T+T/3; third at T+2 T/3,

and so onIn steady state, delivery every T/3 timeIf 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 64

Team SizeIn linear execution of iterations, the same

team performs all stagesIf each stage has a team of S, in linear

execution the team size is SIn 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 65

Team SizeMerely by increasing the team size we cannot

reduce cycle time - Brook’s lawTimeboxing allows structured way to add

manpower to reduce cycle timeNote that we cannot change the time of an

iteration – Brook’s law still holdsWork allocation different to allow larger team

to function properly

Sofware Process 66

Work Allocation of Teams

Requirements Team

RequirementsAnalysis for TB1




Build Team

Deployment Team

Build for TB1 Build for TB2 Build for TB3

Deployment for TB1Deployment for TB2

Build for TB4

Deployment for TB3

Requirements Team





Build Team

Deployment Team

Build for TB1 Build for TB2 Build for TB3

Deployment for TB1Deployment for TB2

Build for TB4

Deployment for TB3

Sofware Process 67

TimeboxingAdvantages: Shortened delivery times, other

adv of iterative, distr. executionDisadvantages: 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 68

waterfallStrength Weakness Types of

Projects

SimpleEasy to executeIntuitive and logicalEasy contractually

All or nothing – too riskyReq frozen earlyMay chose outdated hardware/techDisallows changesNo feedback from usersEncourages req bloating

Well understood problems, short duration projects, automation of existing manual systems

Sofware Process 69

PrototypingStrength Weakness Types of

Projects

Helps req elicitationReduces riskBetter and more stable final system

Front heavyPossibly higher cost and scheduleEncourages req bloatingDisallows later change

Systems with novice users; or areas with req uncertainity.Heavy reporting based systems can benefit from UI proto

Sofware Process 70

IterativeStrength Weakness Types of

Projects

Regular deliveries, leading to biz benefitCan accommodate changes naturallyAllows user feedbackAvoids req bloatingNaturally prioritizes reqAllows reasonable exit pointsReduces risks

Overhead of planning each iterationTotal cost may increaseSystem arch and design may sufferRework may increase

For businesses where time is imp; risk of long projects cannot be taken; req not known and evolve with time

Sofware Process 71

TimeboxingStrength Weakness Types of

Projects

All benefits of iterativePlanning for iterations somewhat easierVery short delivery times

PM becomes more complexTeam size is largerComplicated – lapses can lead to losses

Where very short delivery times are very importantWhere flexibility in grouping featuresArch is stable

Software Project managementProper 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 and monitoring and controlling the project.

Software management distinctionsThe product is intangibleThere are no standard software processes.Many software projects are 'one-off' projects.

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

Software RequirementsThe 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 complicated.

Software RequirementsRegardless 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 requirementUser 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

1. The software must provide a means of representing and1. accessing external files created by other tools.

1.1 The user should be provided with facilities to define the type of1.2 external files.1.2 Each external file type may have an associated tool which may be1.2 applied to the file.1.3 Each external file type may be represented as a specific icon on1.2 the user’s display.1.4 Facilities should be provided for the icon representing an1.2 external file type to be defined by the user.1.5 When a user selects an icon representing an external file, the1.2 effect of that selection is to apply the tool associated with the type of1.2 the external file to the file represented by the selected icon.

User requirement definition

System requirements specification

Client managersSystem end-usersClient engineersContractor managersSystem architects

System end-usersClient engineersSystem architectsSoftware developers

Client engineers (perhaps)System architectsSoftware developers

Userrequirements

Systemrequirements

Software designspecification

Functional and non-functional requirementsFunctional 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 requirementsThese are the constraints 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.

Non-functional classificationsProduct requirements

Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc.

Organisational requirementsRequirements which are a consequence of organisational

policies and procedures e.g. process standards used, implementation requirements, etc.

External requirementsRequirements which arise from factors which are external

to the system and its development process e.g. interoperability requirements, legislative requirements, etc.

Requirements Engineering ActivitiesRequirements 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 Specification Document.

Requirements Engineering ActivitiesRequirement 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 SpecificationThe 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 manner.

Need for SRSAn 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 SRSCorrect : 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 SRSConsistent : 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 SRSFunctionality : 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 SRSDesign constraints on an implementation :

There are a number of factors in the client’s 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 solutionspartitioning of SW into modules, choosing data

structuresProduct assurance plans

Quality Assurance procedures, Configuration Management procedures, Verification & Validation procedures

Uses of SRS DocumentProject 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.

Customers rely on it to know what product they can expect.

PrototypeA 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 requirements errors and omissions.

Uses of system prototypesRequirements 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 benefitsMisunderstandings between software users

and developers are exposedMissing services may be detected and

confusing services may be identifiedA working system is available early in the

processThe prototype may serve as a basis for

deriving a system specificationThe system can support user training and

system testing

Prototyping benefitsImproved system usabilityCloser match to the system neededImproved design qualityImproved maintainabilityReduced overall development effort

Establishprototypeobjectives

Defineprototype

functionality

Developprototype

Evaluateprototype

Prototypingplan

Outlinedefinition

Executableprototype

Evaluationreport

Prototyping in the software processEvolutionary 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 prototypingA 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

Evolutionaryprototyping

Throw-awayPrototyping

Deliveredsystem

Executable Prototype +System Specification

OutlineRequirements

Prototyping objectivesThe 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 prototypingMust 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

Build prototypesystem

Develop abstractspecification

Use prototypesystem

Deliversystem

Systemadequate?

YES

N

Evolutionary prototyping advantagesAccelerated delivery of the system

Rapid delivery and deployment are sometimes more important than functionality or long-term software maintainability

User engagement with the systemNot only is the system more likely to meet user

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

Evolutionary prototypingSpecification, design and implementation are

inter-twinedThe system is developed as a series of

increments that are delivered to the customerTechniques for rapid system development are

used, such as CASE tools and 4GLsUser interfaces are usually developed using a

GUI development toolkit

Evolutionary prototyping problemsManagement problems

Existing management processes assume a waterfall model of development

Specialist skills are required which may not be available in all development teams

Maintenance problemsContinual change tends to corrupt system

structure so long-term maintenance is expensive

Contractual problems

Throw-away prototypingUsed to reduce requirements riskThe 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

Outlinerequirements

Developprototype

Evaluateprototype

Specifysystem

Developsoftware

Validatesystem

Deliveredsoftwaresystem

Reusablecomponents

Prototype deliveryDevelopers may be pressured to deliver a

throw-away prototype as a final systemThis is not recommended

It may be impossible to tune the prototype to meet non-functional requirements

The prototype is inevitably undocumentedThe system structure will be degraded through

changes made during developmentNormal organisational quality standards may

not have been applied

Rapid prototyping techniquesVarious techniques may be used for rapid

developmentDynamic high-level language developmentDatabase programmingComponent 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 languagesLanguages which include powerful data

management facilitiesNeed 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 LanguagesJava

Object-oriented, interactive

LISP AI-based

Visual BasicHTML+Javascript, HTML+Java

Web browser as graphical display

Database programming languagesDomain 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 toolsetThe language + environment is sometimes

known as a fourth-generation language (4GL)Cost-effective for small- to medium-sized

business systems

DBprogramming

language

Interfacegenerator Spreadsheet

Reportgenerator

Database management system

Fourth-generation language

Component and application assemblyPrototypes 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 documentsFor some applications, a prototype can be

created by developing a compound documentThis 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

Word processor Spreadsheet Audio player

Text 1 Text 2 Text 3

Text 4 Text 5

Table 1

Table 2

Sound 1

Sound 2