Prepared by Zubair Ahmed -1–

Prepare by

Zubair Ahmed

S O FT WA R E E N G I N E E R I N G

S O F T WA R E :
S O F T WA R E = Programs + Documentation required to develop, operate and
maintain programs.

Documentation is an essential component of software because it is not

possible to understand different aspects of large programs without documentation. And in the
words of Goethe:

“What we do not understand we do not possess.”

Most programmers regard documentation a necessary evil. But this idea is not
correct. In large systems the effort required to write documentation is often as great as that
required to develop programs.

S O F T WA R E E NG I N E E R I N G :
Prepared by Zubair Ahmed -2–

Software Engineering is an engineering discipline concerned with the

practical problems of developing large software systems. Efficient and economical
development of large software systems is perhaps the central problem of Software
Engineering. A large software system incorporates a variety of human interests and activities
and its development is beyond the capabilities of a single individual. Such a system needs an
organised group of specialised people to design, implement, test and maintain it. After coming
into operation large systems tend to have long lives because their development is very large
expensive and it is not economical to replace them by a new system. Instead they are modified
to fix bugs, to increase efficiency and to cope with the changing requirements. The
modifications and extensions tend to deteriorate the original structure of the system and may
introduce new errors. In the words of Arango et al:

“Over its life time a system is disected, modified and sewn back together
until its form is beyond recognition. Horror stories of these software Frankenstein are well
known to the practitioners.“

Software systems are the most intricate and complex of man’s handiwork
whose complexity increases with size much more than linearly.

A large system is developed by many people perhaps at different sites,

therefore, its development is not merely a programming problem but it also a management
problem.

The term “Software Engineering” was introduced in late 1960’s at a

conference held to discuss what was then called “Software Crisis”. This crisis resulted directly
from the introduction of the “Third Generation” hardware. This hardware was very powerful
as compared to their “Second Generation” counterparts and their power made development of
unrealisable applications a feasible proposition. The implementation of these applications
required large systems to be built. Early experiences in building large software systems showed
that existing methods of Software Development were not good enough. The techniques
applicable to small systems could not be scaled up. Major projects were sometimes years late,
cost much more than originally estimated, were unreliable, difficult to maintain and performed
poorly. Hardware costs were decreasing while the software costs were increasing. New
techniques and methods
Prepared by Zubair Ahmed -3–

were needed to control the complexity inherent in large software systems.

Now, even in 1990’s the software Crisis is not resolved. Although there have been real
improvements in Software Engineering methods and techniques, in tools for the software
development and in skills of development staff, the demand for the software is increasing faster
than the improvements:

We needed:

Better technology.

Better education and training of software engineers.

Software Engineers should be professionals who use theory from other

disciplines and apply this in a cost-effective way to solve difficult problems.

W E L L E N G I N E E RE D S O F T WA R E :
A well engineered software:

Should be maintainable; i.e. it should be designed and documented in such a

way that it could be modified/enhanced without undue cost.

Should be reliable; i.e. it should perform according to the expectations of the

users and should not fail very often.

Should be efficient; i.e. it should not make a wasteful use of resources such as
memory & CPU.

Should offer an appropriate user interface; if a software system has not a

good user interface it cannot be used to get maximum out of it. It should be noted that it is the
interface through which are accessed the facilities provided by a software system.

THE SOFTWARE PROCESS (LIFE CYCLE)

The identification of the software development as an engineering discipline
led to the need of a “Software Development Model” or “Software Life Cycle”. The detailed
model is still the topic of research but it is now clear that a number of general models or
paradigms of software development can be identified. Some of these models are:
Prepared by Zubair Ahmed -4–

THE WAT E R - FA L L A P P R OA C H : This approach views the software life

cycle as made up of a number of stages such as: requirements specification, software design,
implementation and so on. After the completion of one stage the development proceeds to the
next stage.

E X PLO R AT O RY P R O G R AM M I N G : This approach involves developing

a working system as quickly as possible and then modifying that system until it works in an
adequate way. This is used in the development of AI systems where the users can not formulate
a detailed requirement specification and where adequacy rather than correctness in the aim of
designers.

P R O T O T Y P I N G : This approach is similar to exploratory programming in

that first phase involves the quick development of a program for user’s experiment. But here the
objective is to establish the system requirements. This is developed from an outline
specification. The users experiment with the prototype to refine and improve the specification.
This is followed by the re-implementation of the software to produce a production quantity
system.

F O RM A L T R A N S F O R M AT I O N : This approach involves developing a

formal specification of the system and transforming this specification to a program using
correctness - preserving transformations. Each transformation is sufficiently close to the
previous description that effort of verifying the transformation is not excessive. It can then be
guaranteed that the developed program is the true implementation of the specification.

S Y S T EM A SS E M BLY FR O M R E - U S A B L E C O M P O N E N T S : This
approach involves developing software system from the existing components. Thus the system
development process becomes one of the assembly rather than creation.

The first three of these approaches are all being used for practical system
development. Some systems have been built using formal transformation but this is still an
untried approach. The re-use-oriented model is still not commercially viable because of the lack
of reusable component libraries.

THE WATERFALL MODELS OF THE LIFE CYCLE

Prepared by Zubair Ahmed -5–

This model is illustrated in the figure below. Because of the cascade from one
stage to other this model is called waterfall model. This is also called “Classic Life-Cycle”.
This model is the oldest and widely used one.

Requirements
Analysis and
Definition

R E Q USystem N T S A N ALY S I S
I R E M E and A N D D E F I N I T I O N : The system’s
Software Design
services, constraints and goals are established by consultation with the system users. They are
then defined in a manner which is understandable by the users and the development staff.
Implementation
and Unit Testing

Integration and
System Testing

Operation and
Fig. The Waterfall Model of Software Development Maintenance
Prepared by Zubair Ahmed -6–

S Y S T EM AND S O F T WA R E D E S I G N : The system design process

partitions the requirements either to hardware or to software systems and establishes an overall
systems structure. The software design involves representing the software system functions in
such a way that may be transformed to one or more executable programs.

Software design is a multistep process that focuses on four attributes of a

program. These are:

Software architecture

Interface

Data structure

Procedural details

Design process translates requirements into representation of the software.

Like requirements, design is also documented and it becomes apart of software configuration.

I M P L EM E N TAT I O N AND U N I T T E S T I N G : In this stage the software

design is realised as a set of working programs or program units. The unit-testing means
verifying each unit that meets its specifications and it is verified that the defined input produces
the desired results.

I N T EG R AT I O N AND S Y S T EM T E S T I N G : The individual program

units or programs are integrated and tested as a whole system to ensure that software
requirements are met. After testing the system is delivered to the customer.

O P E R AT I O N & M A I N T E N A NC E : Normally (not necessarily) this is

the longest phase of the life cycle. The system is installed and put into practical use.
Maintenance involves correcting errors, which were not detected in earlier stages of the life
cycle, improving the implementation of the system units and enhancing the system’s services as
new requirements are discovered.
Prepared by Zubair Ahmed -7–

It is useful for the management if all the stages are distinct. In practice the
stages overlap and feed information to each other. For example, during design problems with
requirements are identified, during coding design problems are found and so on.

Thus the software development process is not a simple linear model but
involves a sequence of iteration of the development activities. But this model makes it difficult
for the management to

Requirements
Analysis and
Definition

System and
Software Design

Implementation
and Unit Testing

Integration and
System Testing

Operation and
Maintenance

Fig. Iteration in the Waterfall Model

Prepared by Zubair Ahmed -8–

identify definite checkpoints. Thus tendency is to freeze a part of

development after a small number of iterations and to continue with the next development stage.
Problems are, either left for later resolution, ignored or programmed around. This premature
freezing of requirements may mean that the system will not do what the user wants. It may lead
to badly structured systems as the design problems are circumvented by the implementation
tricks. The testing of the system when it is complete is the ultimate validation phase. At this
stage the system developer must convince the system buyer that the system meets the
requirements. However, the verification and validation should be part of earlier life cycle stages.
During verification and validation, the information is fed back to the earlier stages. According to
Boehm (1981)

Verification: Are we building the product right?

Validation: Are we building the right product?

During the final phase of life cycle (Operation and Maintenance), the
information is fed back to the previous development phases. In this phase the software is used,
errors and omissions in the requirements phase are discovered, program and design errors come
to light and the need for new functionality is identified. Modifications become necessary for the
software to be useful.

Making these changes is usually called Software Maintenance. Maintenance

may involve changes is requirements, design & coding and may need further systems testing.
The development process or a part of it is repeated as modifications are made.

An aim of software engineering is to reduce overall software costs so the cost

distribution across the software process must be known. Unfortunately for anything apart from
the conventional waterfall model, the development costs are not broken down. Even for systems
developed using a conventional approach costs vary dramatically depending upon the
application, development organization & development costs. Sometimes the cost information is
commercially sensitive. If available, only a few organizations are ready to publish the costs. It
is very difficult to obtain an overall picture of development costs for the Software Industry.

Following are the figures given by Boehm (1975) for different systems:
Prepared by Zubair Ahmed -9–

S Y S T EM T Y P E P H A S E C O S T S (%)
Req / Design Implementation Testing

Command & control Systems 46 20 34

Space-born Systems 34 20 46

Operating Systems 33 17 50

Scientific Systems44 26 30

Business systems 44 28 28

Fig. Life cycle cost distribution.

It is clear that software development costs are more at the beginning & at the
end. Thus the software development costs an be reduced by:

More effective requirements assessment & design.

More effective verification & validation.

These requirements have promoted other approaches to software development

where the emphasis is on:

Requirements: (Prototyping Model) &

Validation: (Formed Transformation Model)

N O T E : The costs of the systems developed by using exploratory

programming are not covered by these figures.

Above figure does not give any information about the maintenance costs.
Again there is an immense variation from system to system. For most large, long life systems
maintenance costs usually exceed the development costs by a factor of 2 to 4. But these may be
greater. The waterfall model is not considered an adequate model because:

It does not recognise the role of iteration in the software process.

It implies that specifications should be frozen at an early stage This leads to

software systems whose functionality does not match the one required by the users.
Prepared by Zubair Ahmed - 10 –

Exploratory Programming Model & Prototyping Model try to resolve

these difficulties.

What are major problems with “Waterfall Model” / ”Classic Life

Cycle”?
Ans. 1. Real projects rarely follow the linear flow of this model. Iteration
always occurs and creates problems in the application of this model.

This model expects that the requirements be stated explicitly in the beginning.
But this is not possible for the customers.

Customer must have patience. The working programs become available only
at the end of the project. A major mistake, if undetected, can be disastrous.

But in spite of its weaknesses this model is batter than other models.

EXPLORATORY PROGRAMMING

This is based on the idea of developing an initial implementation, exposing it

to the user and refining this through many stages until an adequate system has been developed.
This method is suitable to develop systems for which it is difficult (or impossible) to establish
systems specifications at the earlier stages, such as AI systems.

Use Software
Develop System
Outline Spec.

Build Software N Yes Deliver the

o Is
System System
Adequate
Prepared by Zubair Ahmed - 11 –

This method requires rapid development of the system & rapid incorporation
of the modifications. To accomplish thus:

A very high-level programming language such as LISP or PROLOG is

required.

Powerful dedicated hardware is required.

Integrated set of tools for the development of software is required.

Its main difference from the other approaches is in the verification &
validation:

Without a specification verification is impossible because for this purpose the

program is composed of its specifications.

The notion of correctness is replaced by the notion of adequacy.

It has been mostly used to develop AI systems & has been little used in the
development of large, long life systems because :

It is not economical to produce a great deal of documentation as the system

goes on changing regularly.

This results in a system whose structure is not well defined and if there is any
it gets deteriorated. Thus the maintenance costs are high (particular when the system maintainers
are different from the system developers).

The skills of the developing team can not be used effectively.

These difficulties do not mean that exploratory programming should be

rejected. There are some systems, which can not be developed by setting out specifications &
then constructing the

systems according to specifications. In such cases it is the only reasonable

development technique.

One possible approach might be to develop a prototype using exploratory

programming and use this as a basis for a system developed in a more structured way.
Prepared by Zubair Ahmed - 12 –

Explain why programs, which are developed using an exploratory

programming approach, are likely to be difficult to maintain?

What is difference between verification and validation? Illustrate

your answer with examples of each of these activities.

MANAGEMENT PROCESS MODELS

Software engineering is also concerned with the management problems of a
team developing a software. A model of the software life cycle is acceptable only if it does not
result in an unmanageable process. The management cannot assess the progress by looking at the
work, therefore the management relies on a model which makes the process visible by means of
documents. This has led to a “Deliverable Oriented Model”. In this model again, a process is
decomposed into stages and at the completion of each stage a document is produced, reviewed
and accepted. The output of one stage acts as input for other. “The waterfall model is one of the
deliverable models”. Fig shows one possible way of splitting it into stages and the deliverables,
which should be produced at each stage.

ACTIVITY OUTPUT DOCUMENT

Req. Analysis Feasibility Study, Outline Requirements

Req. Definition Requirements Spec

System Spec. Functional Spec., Acceptance Test Spec.

Architectural Design Draft User Manual, Design Spec., System Spec.

Interface Design Interface Spec., Integration Test Spec.

Coding Program.

Unit Testing Unit Test Report.

Model Testing Model Test Report.

Integration Testing Integration Test Report.

System Testing System Test Report.

Acceptance Testing Final system.

The problems with the document-based models are:

Prepared by Zubair Ahmed - 13 –

Management requires documents at regular intervals. Timings of the

management requirements may not coincide with activity completion.

The need to approve documents constrains the process iteration.

The notion that output of one stage acts as input for the other implies that
process is linear. But in actual practice at any point a software engineer considers the earlier and
future stages. A design, which is difficult to implement, is not desired even if it meets the
requirements.

A lot of time is spent on documents, which tends to make the system

expensive.

Time required to review the document is significant and a phase starts before
the documents of the previous phase are complete.

Certain problems simply cannot be tackled by creating a detailed

specification, then design then an implementation & so on. In some projects the blind use of this
model has resulted in high prices.

The waterfall model has been adopted as a general standard by many

government agencies (software procures). It can not be simply rejected, inspite of these
difficulties. Some improved model for management which satisfies the requirements of the
procurers & is based on the different generic models. The best alternation is “RISK BASED” on
“SPIRAL MODE”. This is illustrated in fig. Its key characteristic is the assessment of
management risk items at regular stages andRisk
initiation
Analysis of actions to counteract these risks.
Before each cycle a risk analysis is initiated and at the end of each cycle a review procedure
Risk Analysis
whether to move on to the next cycle of the spiral. Operational
Prototype

Risk Analysis Prototype3

Prototype2
Risk
Analysis
Review Prototype1
Request Plan, Simulation, models,
Life Cycle Plan Concept of benchmarks
Operations
S/W
Requirements Detailed
Development Plan Requirements Design
Validation Product
Design
Integration Design
& Test Plan & Verification Implementation
& unit testing
Plan next phase Integration test
Acceptance test
Operation Service
Prepared by Zubair Ahmed - 14 –

Risk cannot be defined precisely. A good way to think of the risk in a model
is simply something, which can go wrong. For example, if the intention is to use a new
programming language a risk is that no suitable compiler is available.

Risks are consequences of inadequate information and are resolved by

initiating some actions to discover information, which reduces the uncertainty. In above example,
the risk would be resolved by a market survey to find which compilers were available. If no
suitable system were available the decision would have to be changed.

A cycle of the spiral begins by elaborating objectives such as performance

functionality. Alternative ways of achieving these objectives are then enumerated. Each
alternative is then assessed against each objective. This results in the identification of the
sources of the project risk. The next step is to evaluate these risks by activities such as more
detailed analysis, prototyping simulation etc.
Prepared by Zubair Ahmed - 15 –

After risk evaluation a development model is chosen. If user interface risks

are dominant then appropriate model is prototyping & if safety risks are dominant then formal
transformation model is appropriate. Waterfall model is most appropriate if the identified risk is
the subsystem integration.

It is not mandatory to adopt a single model for whole of the life cycle of the
system. Spiral model encompasses other process models. Prototyping may be used in one cycle
to resolve the requirements risk and this may be followed by a conventional waterfall model.
Formal transformation can be used for the critical parts of the system and reuse oriented model
can be used during the implementation of the user interface.

The originator of this model, (Boehm) suggests that a form be filled in for
each round of the spiral. To illustrate this a form for the development of “Reusable Components
Catalogue” is shown in the following figure.
Prepared by Zubair Ahmed - 16 –

ObjectivesProcure software components catalogueConstraintsWithin a

yearMust support existing componentsTotal cost less than Rs.3mAlternativesBuy existing
information softwareBuy a database and develop catalogue using query languageDevelop special
purpose catalogueRisksMay be impossible to procure within constraintsCommission consultant
report on existing information retrieval systemsRelax time constraintResultsInformation retrieval
systems are inflexibleIdentified requirements cannot be metPrototypes developed using DBMS
may be enhanced to complete the systemSpecial purpose catalogue development is
expensive.PlansDevelop catalogue using existing DBMS by enhancing prototype & user
interfaceCommitmentFund further 12 months developmentThe risk assessment for the catalogue
can then be developed in more details, user interface requirements. As it is clear that risk driven
approach can accommodate other models such as evolutionary prototyping. By identifying and
assessing the risks most appropriate models can be used. Indeed different models can be used for
the development of the different parts of the same system.

E X E RC I S E :

An education board intends to computerise its examination system. The

system holds all details of registered students including personal information, courses taken and
examination marks achieved. The alternative approaches to be adopted are:

Buy a DBMS and develop an in-house system based on this database.

Buy a system from another board and tailor it to local requirements.

Join a consortium of other boards, establish a common set of requirements and

contract software house to develop a single system for all of the boards in the consortium.

Identify two possible risks in each of these strategies and suggest techniques
for risk resolution which would help in deciding which approach to adopt.

What is the distinction between verification & validation. Illustrate your

answer by an example.
Prepared by Zubair Ahmed - 17 –

FUNCTIONAL A ND NON FUNCTIONAL REQUIREMENTS

FUNCTIONAL REQUIREMENTS:

Requirements describe a system’s behaviour. These are the services which the
system is expected to provide to the user. The user is not interested in how these services are
implemented so the software engineer should avoid the implementation details in the description
of these requirements.

NON - FUNCTIONAL REQUIREMENTS:

These set out the constraints under which the system must operate and the
standards, which must be met by the system, e.g. a non-functional constraint might be “input
should be expressible using ASCII character set”. Actually, a non-functional constraint imposes a
restriction, which limits our choice of constructing a solution. A standard, which must be met by
the system, might be “the maximum system response time for any user command should be less
than 2 seconds”.

C HARACTERISTIC S OF R EQUIREMENTS :

The requirements describe not only the flow of

information to and from the system and

transformation of data by the system but also the

constraints under which the system must operate.

Thus the requirements can serve three purposes:
They allow the developers to explain their
understanding of how the customer wants the system to
work.
Prepared by Zubair Ahmed - 18 –

They tell the designers what functionality and the characteristics the resultant
system is to have.

They tell the test team what to demonstrate to convince the customer that the
system being delivered is indeed what was ordered. In particular, the standards set out must be
quantifiable measures.

As the requirements are used both by the customer and the system developer,

it is necessary to validate the requirements. The validation process checks for

seven criteria:

Are the requirements correct? The requirements should be

reviewed by the customer and software engineer to check that theSy are stated without errors.

Are the requirements consistent? No one requirement

should conflict any other.

Are the requirements complete? This means that all

services required by the user are specified. If the requirements description contains all the things
desired by the user then it is said to be “externally complete”. A description is internally
complete if there are no undefined references within the requirements.

Are the requirements realistic? Can the goals set by the

user be possibly achieved? (e.g. It is impossible to have the same response time for local and
remote users).

Do the requirement describe what is needed by

the customer? “What the user needs often differs from what he thinks he needs”.

Are the requirements verifiable? Can tests be

written so that one can demonstrate that requirements have been met?”.

Are the requirements traceable? Can each system function be

traced to a set of requirements that mandate it? Is it easy to find a set of requirements, which
deal with a specific aspect of the system?
Prepared by Zubair Ahmed - 19 –

In practice, for large software systems it is practically impossible to have

completeness and consistency in the initial version of the requirements-document. It must be
correct after having the feedback from later stages.

H OW TO W RITE R EQUIREMENTS
D EFINITION :
It is a normal practice to express the requirements-definition using a mixture
of natural language, tables and diagrams. In spite of the developments in the specification
techniques the first version of the requirements-definition is in a natural language (English or
customer’s language). However, it has become clear that there are several problems with using
natural language. These include:

Ambiguity; different parties interpret the same terms differently.

Requirements are not easily separated according to the system elements with
which they deal. It is sometimes difficult to trace back from a system characteristic to the
requirement that define or affect it.

A natural language requirements-definition should be complemented by a

requirements specification in a structured language. Comments should be included in this
specification for the non-technical people. The definition should concentrate on concepts and
refer the reader to the specification for more detailed information. The definition concentrates
on describing the facility required and justifying why it is required. This rationale is critical if
the requirements document is to be properly understood and is to be an effective system
description for software developers. Without a rationale some facilities appear arbitrary and the
developer may not understand their importance.

It is easy to criticise a requirements definition but much more difficult to write

such a document. The writer has a mental model of what is required and has formed a variety of
informal relationships within the model. The natural tendency is to express these relationships as
these are discovered so that information is not accidentally omitted. The first version is
inevitably unstructured.
Prepared by Zubair Ahmed - 20 –

The most useful approach is to invent a standard format and to ensure that the
definition adheres to that format. The descriptive paragraphs might be followed by a rational and
a reference to more detailed specification.

A X I O M AT I C D E F I N I T I O N :

The system is expressed in terms of axioms. The basic system properties are
specified and the behaviour of the system generates new properties from them. The new
properties are called theorems. This method demands that axioms are complete and consistent
otherwise the resulting theorems will not express truths about the system. This method is well
suited to the requirements definition of the expert systems.

Axiomatic definition is often used in specifying abstract data types. The

system is described as a set of objects and a set of operations on those objects. The axioms
specify the relationship between the objects and operations.

R E Q U I R E M E N T S S P E C I F I C AT I O N :

Requirements specification is the technical counterpart of the requirements

definition. In this case the contents of requirements definition are restated in technical terms
appropriate for the system design. Requirements specification also forms the basis of contract
between the procurer

and developer. Requirements specification is also called “ functional

specification”. Many of the problems of software engineering are difficulties with the
requirements specification.

The cost of errors in stating requirements may be very high, particularly if

these are not detected until the implementation of the system. The cost of implementing a
requirements change, whether it is due to error or inconsistency can be up to one hundred times
of fixing a bug in implementation.

METHODS FOR W R I T I N G R E Q U I R E M E N T S S P E C I F I C AT I O N S
S T R U C T U R E D L A N G U A G E S P E C I F I C AT I O N :

Many notations have been developed which use natural language in

controlled way using a standard form for requirements specification.
Prepared by Zubair Ahmed - 21 –

A form-based approach to requirements specification may be structured

around the objects manipulated by the system, the functions performed by the system or the
events processed by the system. But functionally oriented specifications are probably the most
common. An example of such specification for a part of ATM system is shown in the fig.

Function: Check-card-validity

Description: This operation must ensure that the card input by a user has
been issued by the subscribing bank, is in date, contains appropriate account information and
includes the details of date and amount of previous cash withdrawal.

Inputs: Bank-identifier, Account-number, Expiry date, Last transaction

date, and Last transaction.

Source: Input data is read from the card magnetic stripe.

Outputs: Card-status = (OK, Invalid)

Destination: Auto Teller. The card status is passed to another part of the
software.

Requires: Bank-list, Account-format, and Today’s-date.

Pre-condition: Card has been inserted and data has been read.

Post-condition: Bank-identifier is in the bank-list, Account No. matches the

account format and expiry date >= Today’s date

and last transaction date <= Today’s date

and card-status = OK

AND (if any of these tests fails then) Card-status = Invalid

Side effects: None.

This specification uses pre and post conditions to specify the actions of the function. It uses a
number of names (Bank-list, Account-format etc.) which must be defined elsewhere in the
specification. This does not include any sequencing information - the tests may be carried out in
any order.
Prepared by Zubair Ahmed - 22 –

This method eliminates some of the problems of natural language specification; i.e. specification
is structured but the ambiguity is still there. The other approaches eliminate this problem at the
expense of readability.

A formal mathematical specification can be defined from the structured forms.

(I) PROTOTYPING:

Q: What is a Prototype? Why do we need a Prototype?

Ans: The prototype is all or part of the system that looks like the system under consideration
but does not have the complete functionality of the real system. In this case sections of
the proposed system are built quickly to determine the necessity, desirability or feasibility
of the requirements.

We need a Prototype to validate the requirements. Sometimes the customer is not certain
what he exactly need. Sometimes customer is certain of what he need but we are not
certain whether the requirements are realistic or not. The potential user may have
difficulty in imagining how the system would work.

Q: How does a Software prototype differ from a Hardware prototype?

Ans: Actually objectives are different. In the case of hardware prototype the objective is to
validate the design. First the electronic design is realised and tested by using off the shelf
components, which are then replaced by expensive production quality IC’s after the
satisfactory performance of the prototype. While in case of software prototype the
objective is to validate/refine the requirements.

Q: What are the benefits of developing the prototype?

Prepared by Zubair Ahmed - 23 –

Ans: Misunderstandings between the user and the system developers are identified.

 Missing user services may be detected.

 Confusing user services may be identified and refined.

 Development staff may find incompleteness inconsistencies in requirements.

 A working system is available quickly, which can be used to demonstrate its usefulness
to the management.

 Prototype reduces the risk of errors in the requirements, which can be expensive.

 It serves as a basis for writing the final version of the requirements specifications.

It can also has two other uses:

 As it is similar to the actual system, it can be used for staff training (who would
operate the system).

 It can be used to run back to back tests with the actual system.

It is an important technique for requirements-validation. A prototype software system may be

developed from outline specification. Users experiment with the prototype to refine and improve
the specification.

Experiments have shown that prototyping reduces the number of problems with requirement
specifications. Overall development costs may be lower if a prototype is developed.

The potential user may have difficulties in imagining how does the system work. Having only
requirement specification in hand the user may have difficulties in imagining how does the
system would work. One way to counter this difficulty is to develop a system prototype and to

allow the user to experiment with it. In this way user can discover errors and omission in the
requirements.

S TA G E S IN THE P R O T O T Y P E D E V ELO P M E N T :
There are four stages in the prototype development:

1. E S TA BL I S H PROTOTYPE OBJECTIVES: i.e. why we are developing the prototype?

 User interface
Prepared by Zubair Ahmed - 24 –

 Develop requirements

 Demonstrate feasibility

2. S E L EC T F U N C T I O N S : i.e. what to be included in prototype and also decide which non-

functional requirements must be prototyped. Error handling management may be left out a
prototype for a subset of function is developed.

3. D E V ELO P PROTOTYPE:

4. E VALUAT E THE PROTOTYPE SYSTEM: User must be given enough training and time
to become comfortable with the system. He should experiment with it and feedback.

Q: How does the prototype development effect the overall cost of a product?
Ans: A common argument against prototyping is that its cost is an unacceptably large fraction
of the total system costs. It may be more economic to modify a finished system to meet
the unperceived needs that to provide the user with the opportunity to refine and
understand his needs. It has been observed that prototype development reduces the overall
cost of a product because:

 Errors and omissions are detected earlier

 Effective prototyping increases software quality and gives developers a competitive

edge over competitors.

 “Build it cheap and fix it latter” philosophy has failed in case of U.K and U.S
automobile industry while Japanese succeeded due to Prototyping.

P R O T O T Y P I N G T EC H N I Q U E S :
The main objective is the rapid development of a working system (prototype). This minimises
the prototype costs (software staff salaries) and enables early feedback. There are four methods
for Prototype Development:

 Executable specification languages

 Very high level languages

Prepared by Zubair Ahmed - 25 –

 Fourth generation languages

 Composition of reusable compounds

E X EC U TA B L E S P E C I F IC AT I O N S L A N G UAG E : A formal specification is a mathematical

system model, which may be executable. The cost of producing a specification from the
prototype is negligible. The code of the prototype is system specification. But this is not
understandable by the users and there is a need to derive descriptive specification from it. There
is still a need to derive descriptive specification from its mathematical equation. The prototype
development may not be rapid. Formal specification requires a detailed system analysis and
much time may be devoted to the detailed modelling of the system. The executable system is also
slow and inefficient. Functional languages like ML (Meta-Language - Edinburgh), Z, CDL
(Computer Description language - designed specially for specifications), Larch family of
languages & Miranda are used.
A functional language relies on expressing the system as a mathematical function. Functional
languages are very high level languages. They allow a very concise expression of the problem.
Because of their mathematical basis a function program can be viewed as a formal system
specification. However the execution of functional programs on sequential Hardware is slow.
Functional languages are most suitable for writing executable specifications. Functional
languages are executed sequentially and their execution is very slow.

V ERY H I G H L E V E L L A NG UA G E S (F I F T H G E N E R AT I O N L A N G UA G E S ):

These languages have inherent dynamic data structures and high level features like
Backtracking. These include LISP (LISt Processing - based on list structures), Prolog (PROcess
LOGic - based on logic) APL (A Programming Language - based of vectors) and SETL (SET
language - based on sets). These languages require huge runtime environment and thus are not
suitable for large programs, systems. These are suitable for prototypes or small programs.

Lisp and Smalltalk have better environment

Most of these languages are based on a single paradigm (concept), e.g. LISP handles functions
and lists only; Pascal is imperative language; and Prolog is used for facts and logical systems.
LISP and SmallTalk have better environment.
Prepared by Zubair Ahmed - 26 –

Thus, a wide spectrum language like GIST is required, which describes a system as a finite state
model. A wide spectrum language may include objects, logic programming and imperative
constructs. GIST forces us to see the system as a set of “states and actions”. So we can write
specifications in this language. Its commercial derivative REFINE is also available which is
perhaps the wide spectrum language. It is a non-deterministic language in which the user writes
the executable specification. This specification is refined by the user to produce an automated
prototype. The specifications written in GIST or REFINE can be processed to generate programs
in LISP.

An alternative approach is to use mixed language programming for prototype development. Its
disadvantage is communication framework.

F O U RT H G E NE R AT I O N L A NG UA G E S :

COMPOSITION FR O M R EU S A B L E C O M P O N E N T S :
Prototypes can rapidly be created from the reusable components, provided their libraries
are available. Best example of this approach is the Shell programming language available in
several variants under UNIX. It provides facilities for combining commands, which operate on
strings and files: e.g. grip, sat, find. Shell programs are advanced forms of DOS Batch files.
Reusable components can only be used if it was kept in mind before their programming.

Prototyping using the shell is limited because the granularity of software components is
relatively coarse.

Base around database relies on Software reuse where the routines to access database and
generate reports commercial data processing, small, rewrite rather than structuring code of the
prototype, cost affective system specification.

SYSTEM DESIGN

Q: What is a design?
Ans: It is desired to build a new system due to any of the following reasons:

1. There is no existing system

2. The system is not working properly.

Prepared by Zubair Ahmed - 27 –

To find a solution to this problem, we use some creative process. The output of this process is a
description of the solution to our problem. This is called system design. There can be more
than one solution to a problem. Design is a creative process. It cannot be learned from book.
Design must be practiced and learnt by experience and study of existing systems.

In system design the functions to be performed by the system are partitioned into Software
Functions and Hardware Functions. Until recently, these decisions were not difficult to make
because only standard hardware with known functionality could be used. As it is now possible to
fabricate special purpose chips at reasonable costs, the borderline between hardware and
software components is blurring. It is becoming increasingly cost effective to delay decisions
about which functions should be implemented in hardware and which functions should be
implemented in software. This implies that system architecture must be made up of stand-alone
components, which can be implemented in either Hardware or Software. This is the aim of the
designer who wants to build a maintainable system. From now onward we shall concentrate on
the software design.

A general model of a software design is a directed graph where the nodes represent the entities
in the design such as processes, functions or types and links represent relations between these
design entities. The target of a design process is the creation of such a graph where there are no
inconsistencies and the relationships are legal ones.

It is not usual for Software designers to arrive at a finished design graph immediately. The design
process appears to be a process of adding formality as the design progresses with constant
backtracking to correct, earlier, less formal design.

A general form of Informal Informal More Formal Finished

design, which usually Idea Design Design Design
emerges from such a
design process, is The Design Process
Prepared by Zubair Ahmed - 28 –

hierarchical with cross-links at lower levels. These links appear because of the fact that design
components created earlier are reused later.

Q: What is practiced?

Ans: In many organizations Software design is largely an ad hoc process. Given a set of
requirements, usually in a natural language, an informal design is prepared. Coding then
starts and the design is modified as the system is implemented. By the time the system is
implemented the design has changed so much that its original design document is totally
inadequate description of the system.

Q: What is meant by a good design?

1. Should it allow efficient code to be produced?

2. Should it allow small, compact code to be produced?

3. Should it be the most maintainable design?

Ans: We adopt the later criterion as the criterion of goodness. A maintainable design implies
that cost of system changes should be minimized. This is possible only if the design is
understandable and effects of the changes are local. Let us now investigate the
characteristics of a good design.

1. M O D U L A R I T Y :
Modularity implies decomposition of large system into modules so that each of them can
be implemented independently. A module usually realizes a single and simple function of
the system. It therefore encapsulates data types related to that function & operations on
the data types. In this way changes related to this data type and the corresponding
operations are localized in this module. Each module is provided with a well-defined

interface for communication with the other modules. The interface to the whole system is
structured from these interacting module interfaces. Modularity directly supports
modifiability, reliability and readability.

2. A B S T R AC T I O N :
Prepared by Zubair Ahmed - 29 –

An abstract data type is defined as a set of objects capable only of a certain kind of
behavior which corresponds to a finite set of allowable operations on object of that
type. Its implementation details are hidden. The user is provided with certain operations
and only needs to know what the operations are supposed to do and not how they do it.

3. C O H E S I O N :
It refers to the internal glue with which a module is constructed. A module is highly
cohesive if all elements within the module are directed toward and essential for
performing the same function. The following levels of cohesion (in order of increasing
strength) have been identified.

a) C O I N C I D E N TA L C O H E S I O N : The parts of a module are not related but are just

bundled together.

b) L O G IC A L A SS O C I AT I O N : Components which perform similar functions are

grouped together; e.g. a module may read all kinds of inputs (from floppy disk, tape,
HD) regardless of where the input is coming from and how it will be used.

c) T EM P O R A L C O H E S I O N : The components which are activated at a single time

such as start up or shut down.

d) P R OC E D U R A L C O HE S I O N : The elements in a unit make up a single cohesion

sequence.

e) C O M M U N I C AT I O N A L C O H E S I O N : All the elements that operate on the same

input data or produce the same output.

f) SEQUENTIAL COHESION: The output of one element in the unit serves as

(becomes) input for another element.

g) F U N C T I O N A L C O HE S I O N : Each part of the unit is necessary for the execution

of a single function.

4. C O U P L I N G :
It is an indication of the strength of interconnections between the program units. It is
measure of how program units depend on each other. Two modules are highly coupled if
there is a great deal of dependence between them.
Prepared by Zubair Ahmed - 30 –

DESIGN ACTIVITIES

A design process consists of a number of stages. These are called design activities. Output of
each design activity is a specification. This specification may be abstract, formal specification,
which is produced to clarify the requirements, or it may be a specification of how part of the
system is to be realized. As the design process continues more and more details is added t the
specification. The design activities and design descriptions (specifications) produced as results of
these activities are illustrated in figure below.

Requirements
Specification

The Design Activities

Architectural Abstract Interface Component DataStructure Algorithm

Design Specification Design Design Design Design

System Software Interface Component DataStructure Algorithm

Architecture Specification Specification Specification Specification Specification
Design Products
Design Activities & Design Products

Figure suggests that stages of the design process are sequential. In practice some design activities
go in parallel. However the activities shown are essential in the design of large software systems:

1. A RC H I T EC T U R AL D E S I G N : The subsystems constituting the system and their

relationships are identified and documented.

2. A B S T R AC T S P E C I F IC AT I O N : An abstract specification of the services to be provided

by each subsystem and the constraints under which it must operate is produced.

3. I N T E R FA C E D E S I G N : Interface of each subsystem with other subsystems is designed

and documented. This specification allows the subsystem to be used without knowledge of its
implementation.

4. C O M P O N E N T D E S I G N : The services provided by a subsystem are partitioned across

components in that subsystem.
Prepared by Zubair Ahmed - 31 –

5. D ATA S T R U C T U R E D E S I G N : Datastructures to be used in the implementation of a

subsystem/component are designed in detail and specified.

6. ALGORITHM DESIGN: Algorithms used to provide services are designed and

specified.

This process is repeated for each subsystem until the components identified can be mapped
directly into programming language components such as packages, procedures or functions.

D E S I G N D E SC R I P T I O N
A design acts as:

 a basis for implementation

 a communication medium between designers

 a communication medium for maintainers

It must be possible to view the design at a number of different levels of abstraction.

There are three notations, which are widely used for the documentation of design:

1. G R A P H I C A L N O TAT I O N S : It gives a overall picture of the system by displaying

components and their relationships.

2. P R OG R A M D E S C R I P T I O N L A N G UAG E S (PDL’S): These use control and

structuring constructs based on programming language constructs. These also allow
comments. These allow the intention of the designer to be expressed.

3. I N F O R M A L T E XT : A lot of information associated with a design can not be expressed

formally. Information about design rationales and non-functional considerations must be
expressed using natural language text.

Generally, all of these notations should be used in describing a system design: Architecture and
logical data design should be described by graphical notation. Design rationale is described
using natural languages (comments) text. The interface design, datastructure design and
Algorithm design are best described using a PDL.
Prepared by Zubair Ahmed - 32 –

A P P R OAC H E S TO S Y S T EM D E S I G N
It is useful to separate a design into component parts called modules. A design module is a
functional entity with a well-defined set of inputs and outputs. Thus each module can be viewed
as a component of the whole system just as each room is a component of a house. A module is
well defined if all the inputs are transformed to generate outputs.

A design is then determination of modules and inter-modular interfaces that satisfy a set of
requirements. These modules can be developed in two ways:

 By beginning with a high level view and dividing the system into modules (decomposition).

 By beginning with data and objects and building modules from them. (This is called
composition).

D EC O M P O S I T I O N (Function-Based Design): We begin by writing high level description of

inputs their transformation and outputs. Then we refine and redefine top level into more detailed
modules - the first level of decomposition. This process continues to 2nd … levels of
decomposition until atomic components have been identified where each module performs
operations on exactly one major datastructure. This function-based design is also called Top-
Down Design.

Top Level

First Level of
decomposition

2nd Level of
decompositio
Prepared by Zubair Ahmed - 33 –

C O M P O S I T I O N (Object-Oriented Design): We compose the system from object modules. An

object module defines a data object and provides operations to handle that object. The object
module can be visualized as a box containing data and related operations. The data cannot be
accessed directly; instead the operations provided are used to access the object.

Object-type
Modules

Object Modules

Data Types

Then we define object-type module or object class to describe a type of data. The result of
building up from data and data types is also a set of modules. Object Oriented design is also
called bottom up design.

Ex: What is common and what is different in function-based design and Object Oriented
design.