software eng
TRANSCRIPT
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
Requirements Build Deploy TB3
Requirements Build Deploy TB4
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
RequirementsAnalysis for TB3
RequirementsAnalysis for TB2
RequirementsAnalysis for TB4
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
RequirementsAnalysis for TB1
RequirementsAnalysis for TB3
RequirementsAnalysis for TB2
RequirementsAnalysis for TB4
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