Software Engineering

Software Engineering

- Software engineering is concerned with software systems, which are built by teams
rather than individual programmers, uses engineering principles in the development
of these systems, and is made up of both technical and non-technical aspects.

Well Engineered Software

- If the system does what the user wants, it is well-engineered.

- This means that producing products in the most cost-effective way.
- It is important about cost considerations when attempting to define well-engineered
software including development cost and maintenance cost.
- There are 5 attributes that any well-engineered software system should possess
regardless of functionality.

1. The software should be maintainable.

2. The software should be reliable.
3. The software should be efficient.
4. The software should offer an appropriate user interface.
5. The software should be cost-effective.

The Software Process

There are 4 fundamental process activities which are common to all software process:

(1) Software specification - The functionality of the software and constraints on its
operation must be defined.

(2) Software development - The software to meet the specification must be produced.

(3) Software validation - The software must be validated to ensure that it does
what the user wants.

(4) Software evolution - The software must evolve to meet changing customer
needs.

There are a number of different models or paradigms of software development :

(1) Waterfall Approach (Life-cycle model)

(2) Exploratory Programming
(3) Prototyping
(4) Formal Transformation
(5) System assembly from reusable components

1
(1) Waterfall Approach (Life-cycle Model)

The stages of waterfall model are as follows:

1. Requirement analysis and definition

2. System and software design
3. Implementation and unit testing
4. System testing
5. Operation and maintenance

(1) Requirement analysis and definition

- The system’s services, constraints, and goals are established by consultation with
system users and define them in an understandable manner.

(2) System and Software design

- The requirements are partitioned to either hardware or software systems. This

process is termed system design.
- Software design is the process or representing the functions of each software system
to be readily transformed one or more computer programs.

(3) Implementation and unit testing

- During this stage, the software design is realized as a set of programs or program
units that are written in some executable programming language.
- Unit testing involves verifying that each unit meets its specification.

(4) System testing

- The individual program unit or programs are integrated and tested as a complete
system to ensure that the software requirements have been met.
- The activities of verification and validation (V & V activities) pervade the earlier
lifecycle stages.
- Verification checks, if the product which is under-construction , meets the
requirement definition.
- Validation checks, if the product functions are what the customer really wants.
- After testing, the software system is delivered to the customer.

(5 ) Operation and maintenance

- During the final lifecycle phase, information is fed back to all previous development
phases.
- This final phase is an operational phase where the software is put into use.
- During this use, errors and omissions in the original software requirements are
discovered, program and design errors come to light and the need for new software
functionality is identified.
- This software modification activity is called ‘software maintenance’.
- The development stages overlap and feed information to each other.
- Thus the software development process is not a simple linear model and it may
involve a sequence of iterations of the development activities.
2
 Requirement

Design

Implementation

Testing

Maintenance

Figure – Interaction in the WATERFALL Model

(2) Exploratory Programming

- Based on the idea of developing an initial implementation, exposing this to user

comments and refining this through many stages until an adequate system has been
developed.
- Most appropriate for systems where it is very difficult to establish a detail system
specification.
- Mostly used for the development of Artificial Intelligence systems, which attempt to
some human capabilities.
- The key is to use techniques which allow very rapid system iterations so that
suggested changes may be incorporated and demonstrated as quickly as possible.
- This implies the use of a very high level programming language (LISP, PROLOG) for
software development, use of powerful hardware system, and integrated software
tools to support the system developer.
- EP has been little used in the development of large long time systems by 2 reasons:

(1) Existing software management structures are set up to deal with a software
process model which results in regular deliverables. In EP, it is not cost-
effective to produce a great deal of system documentation as the system is
subject to regular change.

(2) EP tends to result in systems whose structure is not well-defined. The reason
for this is that continual change corrupts the initial software structure. This
means that maintenance of such system is difficult and costly in large systems
where the system maintainers may not be the original developers.

- Another potential problem is that most users of this approach have been highly
qualified and skilled.

3
 Develop Outline Build Software Use Software
Specification System System

No

System
adequate

Yes

Deliver Software
System

Figure - Exploratory Programming Model

Software Evolution

- Large software systems exist in an environment which is subject to constant change

and which may not be completely understood by the implementers of the software.
- As the environment changes or become more fully understood, the software system
must either adapt to these changes or become less useful until it must be discarded.
- This process of change is termed software evolution and there are 5 laws of this
evolution.

(1) Continuing changing

- A program that is used in a real-world environment must be change or become less

useful in that environment.

(2 )Increasing complexity

- As an evolving program changes, its structure become complex unless active effort
are made to avoid this phenomenon.

(3) Program evolution

- Program evolution is a self-regulating process and measurement of system attributes

such as size, time between releases, number of reported errors, etc., to reveal
significant trends and in-variances.

(4) Conservation of organizational stability

- Over the lifetime of a program, the rate of development of that program is

approximately constant and independent of the resources devoted to system
development.

4
(5) Conservation of familiarity

- Over the lifetime of a system, the incremental system change in each release is
approximately constant.

Software Reliability

- The most important characteristic of computer software is that it should be reliable.

- Reliability takes precedence over efficiency for the following reasons:

1. Equipment is becoming steadily cheaper and faster.

2. Unreliable software may be avoided by users and irrespective of how efficient it
is, it will become worthless.
3. The cost of system failure is very much greater than the cost of system itself.
There are more and more safety-critical systems coming into use where the human
costs of a system failure are unacceptable. (E.g. – aircraft navigation system)
4. An efficient system may be considerable success because most execution time is
spent in small section of a program. A reliable system is more difficult to improve
as unreliability tends to be distributed throughout the entire system.
5. Inefficiency is predictable as programs take a long time to execute. Unreliability
is much worse. Unreliable software can have hidden errors which can violate the
system and user data without warning and the result of an error might not be
discovered until much later.
6. Unreliable system can result in information being lost and violate the system.
Data is expensive and may be worth much more than the computer system. So,
more effort and money is expended in duplicating valuable data.

A requirement definition - is a statement in a natural language of what user services the

system is expected to provide. This should be expressed in
understandable way by non-specialist staff to both client and
management and potential users.

A requirement specification - is a statement in a more formal notation which sets out the
system services in more detail. This document (also called a
functional specification) should be precise to be a contract
between the system procurer and software developer and it is
reasonable to assume some understanding of the software
engineering process on the part of the procurer.

A software specification - is an abstract description of the software design which is

intended to serve as a basis for the design and implementation
(design specification) of the software. There should be a clear relationship between
this document and the requirement specification, and it is
principally used by software designers rather than users or
management.

5
The software requirement document

- The software requirement document is a critical document produces during the

software lifecycle.
- It may serve as the basis of a contract between system procurer and the system
contractor.
- It should set out what the system should do without specifying how it should be done.
- The requirement document should be complete and consistent..
- Everything the system should be specified and no requirements should conflict with
any other.
- It must be accepted that errors and omissions will exist in the document and it must
be structured in such a way that it is enable to change.

There are requirements that a software requirement document should satisfy :

1. It should only specify external system behavior

2. It should specify constraints on the implementation
3. It should be easy to change
4. It should serve as a reference tool for system maintainers
5. It should record forethought about lifecycle of the system
6. It should characterize acceptable responses to undesired events.

The requirement definition might have the following structure :

Introduction

- the need for the system

- its functions
- how the system fits into the overall business objectives of the organization

The system model

- showing the relationships between the system components and the system and its
environment graphically.

Functional requirements

- the services provided for the user

- cross-references to a more detailed specification

Non-functional requirements

- the constraints under which software must operate

Hardware

- special hardware
- its interfaces

6
Database requirements

- logical organization of the data used by the system

- its interrelationships

Maintenance information

- hardware evolution
- changing user needs

Glossary

- define the technical terms used in the document

Index

- a normal alphabetic index

- an index per chapter
- an index of functions and so on.

System Model

- A system model represents a description of the real-world entities, which are to be

represented in the software system.
- There are 2 distinct approaches that can be used for the system modeling.

1. A functional approach – models the system as a set of interacting functions and is

typified by the data flow diagram.
2. Object-oriented approach – models the system as a set of interacting objectives where
the operations allowed on each object are encapsulated with the object itself.

Viewpoint Analysis

- When formulating a system model, an engineer must realize that the sources of
information about that system do not normally think about in a top-down manner.
- There are different ways of looking at the system to contribute to make system
understanding.
- A viewpoint is any angle from which a system might be considered, so possible
viewpoints might be human users, sensors associated with the system, or other
computer systems connected to the system being analyzed.

E.g. – Automated Teller Machines (ATM), there are 3 major viewpoints to be considered.

1. The customer using the facilities of the machine.

2. The auto-teller hardware providing input to and displaying output from the system.
3. The bank database system on which customer accounts are maintained.

7
 - Within each viewpoint, there may be sub-viewpoints.
- There are 3 rules to perform a viewpoint analysis :

1. Each viewpoint should be responsible for some information processing.

2. Viewpoints should not overlap. That is , functions should not span viewpoints and
each function should be performed in a single viewpoint.
3. The source and destination of all system information must be an identified viewpoint.

V0
Auto-Teller System

V01 V02 V03

Customer Auto-Teller Account DB

V011 V012
Home bank user Foreign bank user

Figure – A viewpoint diagram for an auto-teller system

(3) Prototyping

- Prototyping is a process that enables the developer to create a model of the software
to be built.
- The model can take one of the three forms:

1. “a paper prototype” - that depicts human-machine interaction in a form that

enables the user to understand how such interaction will occur.

2. “a working prototype” - that implements some subset of the function required to

the desired software.

3. “an existing program” – that performs part or all of the functions desired but has
other features to be improved upon in the new development effort.

- Prototyping begins with requirement gathering.

- Developer and customer meet and define the overall objectives for the software,
identify whatever requirements are known, and outline areas where further definition
is mandatory.
- “A quick design” then occurs which focuses on a representation of these aspects of
the software visible to the user (e.g. – input approaches and output formats).
- The quick design leads to the construction of a prototype.
- The prototype is evaluated by the customer and is used to refine requirements for the
software to be developed.

8
 - A process of iteration occurs as the prototype is “tuned” to satisfy the needs of the
customer and also enabling the developer to understand better what needs to be done.
- The prototype serves as a mechanism for identifying software requirements.
- If a working prototype is built, the developer attempts to use existing program
fragments to be able to generate quickly.
- The prototype can serve as “the first system”.
- It is then to be discarded and the actual software engineer toward quality and
maintainability.
Requirement
gathering

Quick design

Built
prototype

Evaluate & refine

requirements

Engineer
products
Benefits of using a prototype

1. Misunderstanding between software developers and users may be identified as the

system functions are demonstrated.
2. Missing user services may be detected.
3. Difficult-to-use or confusing user services may be identified and refined.
4. Software development staff may find incomplete and/or inconsistent requirements as
the prototype is developed.
5. A working system is available very quickly to demonstrate the feasibility and
usefulness of the application to management.
6. The prototype serves as a basic for writing the specification for a production quality
system.

Other uses

(1) User training - A prototype system can be used for training users before the final
system has been delivered.

(2) System testing - Prototypes can run “back to back test”. This reduces the need for tedious
manual checking of test runs. The same test cases are submitted to both
the prototype and the system under test. If both systems give the same
result, the test case has not detected a fault. If the results are different,
the tester should look in more detail at the reasons for the difference.

- one way to view prototyping is as a technique of risk reduction that prototyping reduces
the number of problems with the requirements specification and the overall development
cost may be lower if a prototype is developed.

9
(4) Formal Transformation

- This approach is based on producing a formal mathematical system specification and

transforming this specification, using mathematical methods, to a program.
- These transformations are ‘correctness preserving’ that the developed program meets
its specification.

Requirement Formal Formal Integrating &

definition specification transformation System testing

Mathematical Notation

Figure – Formal system development

(5) System assembly from reusable components

- This technique assumes that part of the system already exists.

- The system development process focuses on integrating these parts rather than
developing them from scratch.

Requirement Component Requirement System design

specification analysis modification with reuse

Development System
& integration validation

Figure - Reuse-oriented development

10