Course Title: Software Engineering

Lecture: 01 & 02
Course Code: CSE-3505

Topic
Introduction

Instructor: Ahmed Shan-A-Alahi, Lecturer, CSE, IIUC

Software

Software is not only a computer program, but it consists of all associated documentation and
configuration data that is needed to make these programs operate correctly.

Software System

Programs Configuration Files System documentaition

User documentaion

 Programs: Codes which actually form the core of the software. These codes determine
the actions of the software based on varying inputs.

 Configuration files: Configuration files are used to set up these programs.

 System documentation: It explains how the software is built. This is aimed at

developers and advanced users.

 User documentation: It explains how to use the software- aimed at general users.

Fundamentals types of Software product

There are two fundamental types of sofware product:

 Generic products

 These are stand-alone systems that are marketed and sold to any customer who
wishes to buy them.

Page 1 of 62
 Examples – PC software such as graphics programs, project management tools;
CAD software; software for specific markets such as appointments systems for
dentists.

 Customized products

 Software that is commissioned (authorization to carry out particular task or duty)

by a specific customer to meet their own needs.

 Examples – embedded control systems (software in a mobile (cell) phone,

software that controls anti-lock braking in a car, software in a microwave oven to
control the cooking process), air traffic control software, traffic monitoring
systems.

Nature of software engineering

The various engineering disciplines are distinguished by the type of product and/or the type of
constituents that form the raw material for the product. Software engineering is characterized by
its primary product, which is software - programs that direct a computer to perform some task. In
software engineering, there is a well developed science, computer science, that covers, among
other things, concepts of programming languages, algorithms, data structures, and important
aspects of hardware systems and systems software. Many of the subject areas of computer
science deal with software products. Because of this, the boundary between computer science
and software engineering is difficult to define. In particular, the values of software engineering
are an important element of computer science. [https://www.d.umn.edu/~gshute/softeng/nature.html]

Some Problems of Software Engineering/ Key challenges facing software engineering

Software engineering in the 21st century faces some of the following challenges:

1. There is no single domain of knowledge that covers the behavior of all software products.
Software engineering does not have a single body of theory that tells us how to specify and
measure the behavior of its products. Computer science deals with the components of software
and some of the tools and techniques involved in its construction, but does not and cannot deal
with all of the kinds of behavior exhibited by software. [https://www.d.umn.edu/~gshute/softeng/nature.html]

2. The values (important and worthwhile) of software engineering are driven by customers who
have an unlimited range of needs. A classification of the wide range of values is a virtually
impossible task. Even where there are common values, they vary considerably in importance. A
value that is unimportant in one software product may be crucial in another. For these reasons,
the ethical and value-oriented side of software engineering takes on a more prominent role.
[https://www.d.umn.edu/~gshute/softeng/nature.html]

Page 2 of 62
3. Increasingly, systems are required to operate as distributed systems across networks that
include different types of computer and mobile devices. As well as running on general-purpose
computers, software may also have to execute on mobile phones. You often have to integrate
new software with older legacy systems (Systems that have been developed using older and
obsolete technology) written in different programming languages. The challenge here is to
develop techniques for building dependable software that is flexible enough to cope with this
heterogeneity (diversity).

4. Business and society are changing incredibly quickly as emerging economies develop and new
technologies become available. They need to be able to change their existing software and to
rapidly develop new software. Many traditional software engineering techniques are time
consuming and delivery of new systems often takes longer than planned. They need to evolve so
that the time required for software to deliver value to its customers is reduced.

5. As software is intertwined (to be connected so as to be difficult to separate) with all aspects of

our lives, it is essential that we can trust that software. This is especially true for remote software
systems accessed through a web page or web service interface. We have to make sure that
malicious users cannot attack our software and that information security is maintained.

Engineering vs. Software Engineering

Engineers make things work (Find out a solution within limitations). They apply theories,
methods, and tools where these are appropriate. However, they use them selectively and always
try to discover solutions to problems even when there are no applicable theories and methods.
Engineers also recognize that they must work to organizational and financial constraints so they
look for solutions within these constraints.

Software engineering is not just concerned with the technical processes of software development.
It also includes activities such as software project management and the development of tools,
methods, and theories to support software production .In other words, it is an engineering
discipline concerned with all aspects of software production. In short, we can say, software
engineering is a systematic way (software process- specification, development, validation and
evaluation) of designing software.

State of the art of software engineering

‘State of the art’ technology means the ‘latest’ technology. State of the art of software
engineering means the latest methods/techniques of software engineering. Current research in
software engineering is progressing on two levels. Some researchers, sometimes called
‘practitioners’ work toward developing techniques for immediate application, while others,
called theoreticians search for underlying principles and theories on which somebody is able to
construct his application. We can read papers from different journals like journal of systems and

Page 3 of 62
software, software and system modeling etc to know more on State of the art in software
engineering.

Characteristics of good software

The specific set of attributes that we might expect from a software system obviously depends on
its application. Therefore, a banking system must be secure, an interactive game must be
responsive, a telephone switching system must be reliable, and so on. These can be generalized
into the set of attributes shown in the following table, which are the essential characteristics of a
professional software system.

Product Description
characteristic

Maintainability Software should be written in such a way so that it can evolve to meet the changing needs
of customers. This is a critical attribute because software change is an inevitable
requirement of a changing business environment.

Dependability and Software dependability includes a range of characteristics including reliability, security
security and safety. Dependable software should not cause physical or economic damage in the
event of system failure. Malicious users should not be able to access or damage the
system.

Efficiency Software should not make wasteful use of system resources such as memory and
processor cycles. Efficiency therefore includes responsiveness, processing time, memory
utilisation, etc.

Acceptability Software must be acceptable to the type of users for which it is designed. This means that
it must be understandable, usable and compatible with other systems that they use.

Page 4 of 62
Course Title: Software Engineering

Lecture: 03, 04 & 05

Course Code: CSE-3505

Topic
Introduction

Instructor: Ahmed Shan-A-Alahi, Lecturer, CSE, IIUC

Software process

A software process is a set of related activities that leads to the production of a software product.
These activities may involve the development of software from scratch in a standard
programming language like Java or C.

There are many different software processes but all must include four activities that are
fundamental to software engineering:

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

2. Software design and implementation: The software to meet the specification must be
produced.

3. Software validation: The software must be validated to ensure that it does what the customer
wants.

4. Software evolution: The software must evolve to meet changing customer needs

Software process model

A software process model is a simplified representationof a software process. Each process

model represents a process from a particular perspective, and thus provides only partial
information about that process. For example,a process activity model shows the activities and
their sequence but may not showthe roles of the people involved in these activities.

Most software process models are based on one of three general moels or paraigms of sofware
development:

1. The waterfall model: This takes the fundamental process activities of specification,
development, validation, and evolution and represents them as separate process phases such as
requirements specification, software design, implementation, testing, and so on. After each stage

Page 5 of 62
is defined it is’signed-off’, and development goes on to the following stage. This model is
illustrated in figure below. Because of the cascade from one phase to another, this model is
knownas the ‘waterfall model’ or software life cycle. Moreover, this model is an example of a
plan-driven process—in principle, you must plan and schedule all of the process activities before
starting work on them.

Waterfall model

2. Incremental or iterative development: This approach interleaves the activities of

specification, development, and validation. The system is developed as a series of versions
(increments), with each version adding functionality to the previous version. In other words, an
initial system is rapidly developed from very abstact specifications. This then refined with
customer input to produe a system that staisfies customer’s needs. The system may then be
delivered.

Inremental or iterative development

Page 6 of 62
3. Reuse-oriented or component-based software engineering: This approach is based on the
existence of a significant number of reusable components. The system development process
focuses on integrating these components into a system rather than developing them from scratch.

Reuse-oriented or component-based software engineering

Costs of software engineering

Roughly 60% of software costs are development costs; 40% are testing costs. For long-lifetime
software systems, such as command and control systems that may be used for 10 years or more,
evolution costs often exceed development costs. In fact, there is no simple answer what are the
costs of software engineering as the distribution costs across the different activities in the
software process depends on the process used and the type of software that is being developed.
For example, real-time software ususally requires more extensive validation and testing than
web-based systems. However, each of the different generic approaches to software development
a different profile o cost distribution across the software process activities. If we assume that
the total cost of developing a complex software system is 100 cost units then figure below
illustrates how these are spent on different process activities.

Waterfall model

Incremental or iterative development

Reuse-oriented or component-based software engineering

Page 7 of 62
Development and evolution costs for long-lifetime software systems

Software engineering methods

A software engineering method is a structured approach to software development whose aim is

to facilitate the production of highquality software in a cost effective way. Methods such as
Structred Analysis (DeMacro,1978) and JSD (Jackson,1983) were first developed in 1970s. these
method attempted to identify the basic functional components of a system; function –oriented
methods are still used. In the 1980 and 1990s, these funtion-oriente method were supplemented
by object-oriented (OO) methods such as those proposed by Booch (Booch; 1994) and
Rambaugh (Rambaugh,etal.,1991). These different approaches have now been integrated into a
single unified approach built around the Unified Modeling Language (UML) ( Booch, et al.,
1999; Rambaugh, et al., 1999a; Rambaugh, et al., 1999b). There is no ideal method, and
different methods have different areas where they are applicable. For example, object-oriented
methods are often appropiate for interactive systems but not for systems with stringent (rigorous)
real-time requirements.

Methods Components

All methods are based on the idea of developing models o a system that may be represented
graphically and using these models as a system speciication or design. Methods include a
number of different components as illustrated in the figure below:

Figure: Methods Components

Page 8 of 62
Professional and ethical responsibility of a software engineer

Like other engineering disciplines, software engineering is carried out within a social and legal
framework that limits the freedom of people working in that area. As a software engineer, you
must accept that your job involves wider responsibilities than simply the application of technical
skills. You must also behave in an ethical and morally responsible way if you are to be respected
as a professional engineer.

It goes without saying that you should uphold normal standards of honesty and integrity. You
should not use your skills and abilities to behave in a dishonest way or in a way that will bring
disrepute to the software engineering profession. However, there are areas where standards of
acceptable behavior are not bound by laws but by the more tenuous notion of professional
responsibility. Some of these are:

1. Confidentiality: You should normally respect the confidentiality of your employ-ers or clients
irrespective of whether or not a formal confidentiality agreement has been signed.

2. Competence You should not misrepresent your level of competence. You should not
knowingly accept work that is outside your competence.

3. Intellectual property rights: You should be aware of local laws governing the use of
intellectual property such as patents and copyright. You should be careful to ensure that the
intellectual property of employers and clients is protected.

4. Computer misuse: You should not use your technical skills to misuse other people’s
computers. Computer misuse ranges from relatively trivial (game playing on an employer’s
machine, say) to extremely serious(dissemination of viruses or other malware).

ACM/IEEE-CS Joint Task Force on Software Engineering Ethics and Professional

Practices:

In accordance with their commitment to the health, safety and welfare of thepublic, software
engineers shall adhere to the following Eight Principles:

1. PUBLIC — Software engineers shall act consistently with the public interest.

2. CLIENT AND EMPLOYER — Software engineers shall act in a manner that is in the best
interests of their client and employer consistent with the public interest.

3. PRODUCT — Software engineers shall ensure that their products and related modifications
meet the highest professional standards possible.

4. JUDGMENT — Software engineers shall maintain integrity and independence in their

professional judgment.

Page 9 of 62
5. MANAGEMENT — Software engineering managers and leaders shall subscribe to and
promote an ethical approach to the management of software development and maintenance.

6. PROFESSION — Software engineers shall advance theintegrity and reputation of the

profession consistent with the public interest.

7. COLLEAGUES — Software engineers shall be fair to and supportive of their colleagues.

8. SELF — Software engineers shall participate in lifelong learning regarding the practice of
their profession and shall promote an ethical approach to the practice of the profession.

Page 10 of 62
Course Title: Software Engineering

Lecture: 06, 07 & 08

Course Code: CSE-3505

Topic
Software Process
Instructor: Ahmed Shan-A-Alahi, Lecturer, CSE, IIUC

Liner sequential model

 Linear Sequential Process Model suggest a systematic, sequential approach to software

development that begins at the system level and progress through various steps.

 Linear Sequential Process Model provides a template into which methods for analysis, design,
coding, testing and maintenance can be placed.

 It remains a widely used procedural model for software engineering.

 In this model, each step is completed and then another step is started. Therefore, there is no
way to back into previous step.

 Considered as ideal process model.

Figure: Linear sequential model

Page 11 of 62
Waterfall model

 The linear Process Model shown earlier requires that each process stage is correct and
complete before the next stage is started

 In practice, it is likely that a later stage may find errors introduced in an earlier stage

 The Waterfall Process Model adds a backward path so that problems in a later stage may be
addressed by revisiting an earlier stage

Figure: Waterfall model

The principal stages of the waterfall model directly reflect the fundamental development
activities:

1. Requirements analysis and definition: The system’s services, constraints, and goals are
established by consultation with system users. They are then defined in detail and serve as a
system specification.

2. System and software design: The systems design process allocates the requirements to either
hardware or software systems by establishing an overall system architecture. Software design
involves identifying and describing the fundamen-tal software system abstractions and their
relationships.

3. Implementation and unit testing: During this stage, the software design is realized as a set of
programs or program units. Unit testing involves verifying that

Page 12 of 62
each unit meets its specification.

4. Integration and system testing The individual program units or programs are integrated and
tested as a complete system to ensure that the software requirements have been met. After
testing, the software system is delivered to the customer.

5. Operation and maintenance Normally (although not necessarily), this is the longest life
cycle phase. The system is installed and put into practical use. Maintenance involves correcting
errors which were not discovered in earlier stages of the life cycle, improving the
implementation of system units and enhancing the system’s services as new requirementsare
discovered.

Proper use case of Waterfall model

The waterfall model should only be used when requirements are well understood and unlikely to
change radically during system development.

Linear/Sequential/Waterfall model- advantages and disadvantages

Advantage:

1. Documentation is produced after each stage and

2. It fits other engineering models [For example making a building/structure].

3. Well understood milestones.

Disadvantages:

1. Inflexible partitioning of project into distinct stages.

2.Commitments must be made in early stages, makes it difficult to respond to changing customer
needs.

3. Not suitable for complex projects.

Comparison between Linear Sequential vs. Waterfall model

Linear Sequential Process Model:

 Each phase of the linear sequential process model has a well-defined starting and ending
point.

 All requirements are gathered before the project work is started.

Page 13 of 62
 Later stages may find errors introduced in an earlier stage.

 This process cannot ensure that the each stage is complete and error free.

Waterfall Model:

 Each stage of this model is connected with the previous stage by a backward path.

 Often the full requirements only become known/ are realized, when user has the software.

 Problems in a later stage may be addressed by revisiting an earlier stage by the backward
path.

Prototyping

Here, a prototype software is made first and based on it final product is developed. A prototype
is a model or a program which is not based on strict planning, but is an early approximation of
the final product or software system. A prototype acts as a sample to test the process. From this
sample we learn and try to build a better final product. This prototype may or may not be
completely different from the final software.

Figure: Prototyping process model

Use case of Prototype model

This type of System Development Method is employed when it is very difficult to obtain exact
requirements from the customer (unlike waterfall model, where requirements are clear). While
making the model, user keeps giving feedbacks from time to time and based on it, a prototype is
made. Completely built sample model is shown to user and based on his feedback, the SRS
(System Requirements Specifications) document is prepared. After completion of this, a more
accurate SRS is prepared, and now development work can start using Waterfall Model.

Page 14 of 62
Advantages of prototype model:

1) When prototype is shown to the user, he gets a proper clarity and 'feel' of the functionality of
the software and he can suggest changes and modifications.

2) This type of approach of developing the software is used for non-IT-literate people. They
usually are not good at specifying their requirements, nor can tell properly about what they
expect from the software.

3) When client is not confident about the developer's capabilities, he asks for a small prototype to
be built. Based on this model, he judges capabilities of developer.

4) Sometimes it helps to demonstrate the concept to prospective investors to get funding for
project.

Disadvantages of Prototyping Model:

1) Prototyping is usually done at the cost of the developer. So it should be done using minimal
resources. It can be done using Rapid Application Development (RAD) tools. Please note
sometimes the start-up cost of building the development team, focused on making prototype, is
high.

2) Once we get proper requirements from client after showing prototype model, it may be of no
use. That is why sometimes we refer to the prototype as "Throw-away" prototype.

3) It is a slow process.

4) Too much involvement of client is not always preferred by the developer.

Classification of prototyping model:

Prototyping model could be of two types:

1. Rapid or throwaway prototype model:

Used for
 data-oriented applications

Page 15 of 62
 applications with considerable emphasis on the user interface

 systems where there is a high degree of user interaction

Benefits
- Requirements become clear as customers actually ‘use’ the system

 Misunderstandings are clarified

 Missing functions can be identified
 Poor interfaces can be refined
 Missing requirements can be identified

- Working system is produced

 although limited in functionality and performance

- Prototype becomes the specification

Problems
- The prototype will have features that have been deliberately left out

 May not be able to prototype all features

- System characteristics like performance and reliability will not be addressed

- The prototype will not be used in precisely the same way as the real system.

 For example, it may be slower so users will adjust in different ways

Page 16 of 62
2. Evolutionary prototype model: If you’ve built a prototype, there is some temptation to try
and evolve this into the software you deliver. In general, this is not a good idea since, 1) Certain
issues have been ignored 2) Further development may lead to a poorly structured system 3) It is
difficult to maintain. However, for certain types of system, particularly those where it is difficult
or impossible to develop a specification. For example, certain AI systems. A prototype that
evolves into the final system is called Evolutionary Prototyping or Exploratory Programming.

Incremental development:
o In an incremental model, customers identify in outline, the services to be provided by the
system. They identify which of the services are most important and which are least important
for them. A number of delivery increments are then defined, with each increment providing a
sub-set of the system functionality.

o Once the system increments are specified, the requirements for the services to be delivered in
the first increment are defined in detail and that increment is developed.

o Once an increment is completed and delivered, customers can put that into service. They can
then determine their requirements for later increments.

Page 17 of 62
A better representation of Incremental model

Advantages of incremental model

 Customers do not have to wait until the entire system is delivered before they can gain value
from it.

 Customers can use early increment as prototypes and gain experience that informs their
requirements for later system increments.

 There is a lower risk of overall project failure.

 As the highest priority services are delivered first and later increments are integrate with them,
it is inevitable that the most important services receive the most testing.

Disadvantages of incremental model

 Increments should be relatively small.

 It can be hard to map customer’s requirements onto increments of the right size.

 It can be hard to identify common facilities required by all increments.

Page 18 of 62
Spiral development

In this model, software process is represented as a spiral, each loop in the spiral represents a
phase of the software process. Thus, the innermost loop might be considered with system
feasibility, the next loop requirements definition, next loop system design and so on.

Each loop in the spiral is split into four sectors:

Objective setting: Specific objective, constraints on the process and the product are identified,
detail management plan is drawn up.

Risk assessment and reduction: For each of the identified project risks, a detailed analysis is
carried out. Steps are taken to reduce the risk.

Development and Validation: After risk evaluation, a development model for the system is
chosen. For example, if user interface risks are dominant, an appropriate development model
might be evolutionary prototyping.

Planning: The project is reviewed and a decision is made whether to continue with a further
loop of the spiral. If so, plans are drawn for next phase of project.

The main difference between the spiral and other software process models is the explicit
recognition of risk in the spiral model. Informally, something that can go wrong. For example, if
the intention is to use a new programming language, a risk is that available compilers are
unreliable.

Spiral model advantages

Page 19 of 62
 It is suitable for high risk projects, where business needs may be unstable.

 A highly customized product can be developed using this.

 Requirements can be captured more accurately.

Spiral model disadvantages

 Cost involved in this model is usually high.

 Due to various customizations allowed from the client, using the same prototype in other
projects, in future, is difficult.

 Large number of intermediate stages require excessive documentation.

Advanced Software development lifecycle

Page 20 of 62
Course Title: Software Engineering

Lecture: 09
Course Code: CSE-3505

Topic
Software Requirement
Instructor: Ahmed Shan-A-Alahi, Lecturer, CSE, IIUC

Requirement definition

The requirements for a system are the descriptions of what the system should do—the services
that it provides and the constraints on its operation. These requirements reflect the needs of
customers for a system that help solve some problem such as controlling a device, placing an
order, or finding information. Moreover, the process of finding out, analyzing, documenting and
checking these services and constraints is called requirements engineering (RE).

The term ‘requirement’ is not used consistently in the software industry. In some cases, a
requirement is simply a high-level, abstract statement of a service that a system should provide or
a constraint on a system. At the other extreme, it is a detailed formal definition of a system
function. Davis (1993) explains why these differences exist:

If a company wishes to let a contract for a large software development project, it must define its
needs in a sufficiently abstract way that a solution is not pre-defined. The requirements must be
written so that several contractors can bid for the contract, offering, perhaps, different ways of
meeting the client organization’s needs. Once a contract has been awarded, the contractor must
write a system definition for the client in more detail so that the client understands and can
validate what the software will do. Both of these documents may be called the requirements
document for the system.

Some of the problems that arise during the requirements engineering process are a result of
failing to make a clear separation between these different levels of description. We can
distinguish between them by using the term ‘user requirements’ to mean the high-level abstract
requirements and ‘system requirements’ to mean the detailed description of what the system
should do. User requirements and system requirements may be defined as follows:

User Requirement: These are statements in natural language plus diagrams, of what services is
expected from the software and which are the constraints under which it must operate. For
example, it is used during tender call for a software project. It should be specified in natural and
easy language.

System Requirement: Set’s out the system functions, services and operations in detail. The
system requirement document should be precise. It should define exactly what is to be
implemented. For example, it is used once your company wins the tender; you can go the
drawing board and sketch detail of requirements.

Page 21 of 62
Software system requirements are often classified as functional requirements or non-functional
requirements:

Functional Requirements: These are 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. In short, we can say these requirements concerned with detail functional behavior
of every component of the software. Example: For a university library system called LIBSYS,
used by faculty and students to order books, following are functional requirements:

 The time and order for a book should be logged.

 Every order shall have a unique order ID.

 If there are abnormally high numbers of orders from a user, it should check out for spam.

Non-functional requirements: This are requirements that are not directly concerned with
specific functions of the system, rather relate to emergent system properties such as reliability,
response time, etc. It may also define constraints such as abilities of I/O devices (for example,
the software should work on Fedora).

In reality, the distinction between different types of requirement is not as clear-cut as these
simple definitions suggest. A user requirement concerned with security, such as a statement
limiting access to authorized users, may appear to be a non-functional requirement. However,
when developed in more detail, this requirement may generate other requirements that are clearly
functional, such as the need to include user authentication facilities in the system.

Non-functional requirement types

Non-functional requirements arise through user needs, because of budget constraints,

organizational policies, the need for interoperability with other software or hardware systems, or
external factors such as safety regulations or privacy legislation. Figure below is a classification
of non-functional requirements. We can see from this diagram that the non-functional
requirements may come from required characteristics of the software (product requirements), the
organization developing the software (organizational requirements), or from external sources:

1. Product requirements: These requirements specify or constrain the behavior of the software.
Examples include performance requirements on how fast the system must execute and how much
memory it requires, reliability requirements that set out the acceptable failure rate, portability for
example an app should work on Android 2.2 and 2.3, security requirements, and usability
requirements.

Page 22 of 62
Figure: Types of non-functional requirements

2. Organizational requirements: These requirements are broad system requirements derived

from policies and procedures in the customer’s and developer’s organization. Examples include
operational process requirements that define how the system will be used, development process
requirements that specify the programming language, the development environment or process
standards to be used, and environmental requirements that specify the operating environment of
the system.

3. External requirements: This broad heading covers all requirements that are derived from
factors external to the system and its development process. These may include regulatory
requirements that set out what must be done for the system to be approved for use by a regulator,
such as a central bank; legislative requirements that must be followed to ensure that the system
operates within the law; and ethical requirements that ensure that the system will be acceptable
to its users and the general public. Moreover, it also defines how the system interacts with other
software, for example, how Google API (Application Programming Interface) is used in the
software.

Page 23 of 62
Requirements imprecision

Imprecision in the requirements specification is the cause of many software engineering

problems. It is natural for a system developer to interpret an ambiguous requirement in a way
that simplifies its implementation. Often, however, this is not what the customer wants. New
requirements have to be established and changes made to the system. Of course, this delays
system delivery and increases costs.

For example, one of the functional requirements of a university library system ‘LIBSYS’ is to
provide appropriate viewers for the user to read documents in the document store. The library
system can deliver documents in a range of formats; the requirement is that viewers for all of
these formats should be available. However, the requirement is worded ambiguously; it does not
make clear that viewers for each document format should be provided. A developer under
schedule pressure might simply provide a text viewer and claim that the requirement had been
made.

Page 24 of 62
Course Title: Software Engineering

Lecture: 10
Course Code: CSE-3505

Topic
Requirement Engineering Process
Instructor: Ahmed Shan-A-Alahi, Lecturer, CSE, IIUC

Requirement Engineering Process

The goal of the requirements engineering process is to create and maintain a system requirements
documents and the processes used for requirement engineering vary widely depending on the
application domain, the people involved and the organisation developing the requirements.
However, the overall process includes four high-level requirements engineering sub-process.
These are concern with assessing whether the system is useful to the business (feasibility study),
discovering requirements (elicitation and analysis), converting these requirements into some
standard form (specification), and checking that the requirements actually define the system that
the customer wants (validation). Figure below illustrates the relationship between these
activities. It also shows the documents produced at each stage of the requirement engineering
process.

Figure: The requirements engineering process

Page 25 of 62
Spiral model of requirements engineering process

An alternative perspective of the requirements engineering process is illustrated below. This

presents the process as a three-stage activity where the activities are organized as an iterative
process around a spiral, with the output being a system requirements document. The amount of
time and effort devoted to each activity in each iteration depends on the stage of the overall
process and the type of system being developed. Early in the process, most effort will be spent
on understanding high-level business and non-functional requirements, and the user requirements
for the system. Later in the process, in the outer rings of the spiral, more effort will be devoted to
eliciting and understanding the detailed system requirements.

Figure: Spiral model of requirement engineering process

Page 26 of 62
Feasibility Study

A feasibility study decides whether or not the proposed system is worthwhile. It is a short,
focused study that should take place early in the RE process. It should answer three key
questions: a) does the system contribute to the overall objectives of the organization? b) can the
system be implemented within schedule and budget using current technology? and c) can the
system be integrated with other systems that are used?

Feasibility study implementation

Carrying out a feasibility study involves information assessment, information collection and
report writing. The information assessment phase identifies the information that is required to
answer the three questions set out above. Once the information has been identified, we should
talk with information sources to discover the answers to these questions. Some examples of
possible questions that may be put are:

1. How would the organisation cope if this system were not implemented?

2. What are the problems with current process and how would a new system help alleviate these
problems?

3. What direct contribution will the system make to the business objectives and requirements?

4. Can information be transferred to and from other systems?

5. Does the system require technology that has not previously been used in the organisation?

6. What must supported by the system and what need not be supported?

In a feasibility study, we may consult information sources such as the managers of the
departments where the system will be used, software engineers who are familiar with the type of
system that is proposed, technology experts and end-users of the system. Normally, we should
try to complete a feasibility study in two or three weeks.

Once we have the information, we write the feasibility study report. We should make a
recommendation about whether or not the system development should continue. In the report, we
may propose changes to the scope, budget and schedule of the system and suggest further high-
level requirements for the system.

Requirements elicitation and analysis

The next stage of the requirements engineering process is requirements elicitation or

requirements discovery and analysis. In this activity, software engineers work with customers

Page 27 of 62
and system end-users to find out about the application domain, what services the system should
provide, the required performance of the system, hardware constrains, and so on.

Requirements elicitation and analysis may involve a variety of people in an organisation. The
term stakeholder is used to refer to any person or group who will be affected by the system,
directly or indirectly. For example end-users, managers, engineers involved in maintenance, domain
experts, trade union, representatives etc. these are called stakeholders.

Stakeholders

Stakeholders interact with the system by receiving services from it & by providing data &
controlling signal to the system.

Stakeholders can be categories as:

- Primary stakeholder is one who will be the end user of the proposed system and therefore, will
receive the services/ functions provided by the system and will interact with the system interface

- Secondary stakeholder on the other hand, is one who required information from the system, but
is not necessarily going to use the system directly.

- Ternary stakeholder users will be benefited from the system in an implicit way.

Eliciting and understanding requirements from system stakeholders is a difficult process for
several reasons:

1. Stakeholders often don’t know what they want from a computer system except in the most
general terms; they may find it difficult to articulate what they want the system to do; they may
make unrealistic demands because they don’t know what is and isn’t feasible.

2. Stakeholders in a system naturally express requirements in their own terms and with implicit
knowledge of their own work. Requirements engineers, without experience in the customer’s
domain, may not understand these requirements.

3. Different stakeholders have different requirements and they may express these in different
ways. Requirements engineers have to discover all potential sources of requirements and
discover commonalities and conflict.

4. Political factors may influence the requirements of a system. Managers may demand specific
system requirements because these will allow them to increase their influence in the
organization.

5. The economic and business environment in which the analysis takes place is dynamic. It
inevitably changes during the analysis process. The importance of particular requirements may

Page 28 of 62
change. New requirements may emerge from new stakeholders who were not originally
consulted.

Page 29 of 62
Course Title: Software Engineering

Lecture: 11
Course Code: CSE-3505

Topic
Requirement Engineering Process
Instructor: Ahmed Shan-A-Alahi, Lecturer, CSE, IIUC

A very general process model of the elicitation an analysis process is shown figure below. Each
organization will has its own version of this general model, depending on local factors such as
expertise of the staff, the type of system being developed and the standards used. Again, we can
think of these activities within a spiral so that the activities are interleaved as the process
proceeds from the inner to the outer rings of the spiral.

Requirements Requirements
classification and prioritization and
organisation negotiation

Requirements Requirements
discovery documentation

Figure: The requirements elicitation and analysis process

Page 30 of 62
Process activities

The process activities are:

1. Requirements discovery: This is the process of interacting with stakeholders of the system to
discover their requirements. Domain requirements from stakeholders and documentation are also
discovered during this activity.

2. Requirements classification and organization: This activity takes the unstructured

collection of requirements, groups related requirements, and organizes them into coherent
clusters. The most common way of grouping requirements is to use a model of the system
architecture to identify sub-systems and to associate requirements with each sub-system. In
practice, requirements engineering and architectural design cannot be completely separate
activities.

3. Requirements prioritization and negotiation: Inevitably, when multiple stake-holders are

involved, requirements will conflict. This activity is concerned with prioritizing requirements
and finding and resolving requirements conflicts through negotiation. Usually, stakeholders have
to meet to resolve differences and agree on compromise requirements.

4. Requirements specification or documentation: The requirements are documented and input

into the next round of the spiral.

Requirements discovery

Requirements discovery (sometime called requirements elicitation) is the process of gathering

information about the required system and existing systems, and distilling the user and system
requirements from this information. Sources of information during the requirements discovery
phase include documentation, system stakeholders, and specifications of similar systems. We
interact with stakeholders through inter-views and observation and you may use scenarios and
prototypes to help stakeholders understand what the system will be like.

Mental healthcare patient information system stakeholders

Stakeholders range from end-users of a system through managers to external stake-holders such
as regulators, who certify the acceptability of the system. For example, system stakeholders for
the mental healthcare patient information system include:

1. Patients whose information is recorded in the system.

2. Doctors who are responsible for assessing and treating patients.

Page 31 of 62
3. Nurses who coordinate the consultations with doctors and administer some treatments.

4. Medical receptionists who manage patients’ appointments.

5. IT staff who are responsible for installing and maintaining the system.

6. A medical ethics manager who must ensure that the system meets current ethical guidelines
for patient care.

7. Healthcare managers who obtain management information from the system.

8. Medical records staff who are responsible for ensuring that system information can be
maintained and preserved, and that record keeping procedures have been properly implemented.

Another Example

System stakeholders for a bank ATM includes:

• Bank customers

• Representatives of other banks

• Bank managers

• Counter staff

• Database administrators

• Security managers

• Marketing department

• Hardware and software maintenance engineers

• Banking regulators

Page 32 of 62
Course Title: Software Engineering

Lecture: 12
Course Code: CSE-3505

Topic
Requirement Engineering Process
Instructor: Ahmed Shan-A-Alahi, Lecturer, CSE, IIUC

A viewpoint is way of collecting and organizing a set of requirements from a group of

stakeholders who have something in common. Each viewpoint therefore includes a set of system
requirements. Viewpoints might come from end-users, managers, etc. They help identify the
people who can provide information about their requirements and structure the requirements for
analysis. Viewpoints can be used as a way of classifying different types of stakeholder and other
sources of requirements. This multi-perspective analysis is important as there is no single correct
way to analyse system requirements.

There are three generic types of viewpoint:

1. Interactor viewpoints that represent people or other systems that interact directly with the
system. In the bank ATM system, examples of interactor viewpoints are the bank’s customers
and the bank’s account database.

2. Indirect viewpoints that represent stakeholders who do not use the system themselves but who
influence the requirements in some way. In the bank ATM system, examples of indirect
viewpoints are the management of the bank and the bank security staff.

3. Domain viewpoints that represent domain characteristics and constraints that influence the
system requirements. In the bank ATM system, an example of a domain viewpoint would be the
standards that have been developed for inter-bank communications.

Viewpoint identification

The initial identification of viewpoints that are relevant to a system can sometimes be difficult.
To help with this process, you should try to identify viewpoints of different types:

 Providers of services to the system and receivers of system services.

 Systems that should interface directly with the system being specified.

 Regulations and standards that apply to the system.

 The sources of system business and non-functional requirements.

Page 33 of 62
 Engineering viewpoints reflecting the requirements of people who have to develop,
manage and maintain the system.

 Marketing and external affairs viewpoints that generate requirements on the product
features expected by customers and how the system should reflect the external image of
the organisation.

LIBSYS viewpoint hierarchy

All VPs

Indirect Interactor Domain

Library Article Library UI Classification

Finance Users
manager providers staff standards system

System
Students Staff External Cataloguers
managers

Interviewing

Formal or informal interviews with system stakeholders are part of most requirements
engineering processes. In these interviews, the requirements engineering team puts questions to
stakeholders about the system that they currently use and the system to be developed.
Requirements are derived from the answers to these questions.

Page 34 of 62
Interviews may be of two types:

1. Closed interviews, where the stakeholder answers a predefined set of questions.

2. Open interviews, in which there is no pre-defined agenda. The requirements engineering team
explores a range of issues with system stakeholders and hence develop a better understanding of
their needs.

Scenarios

People usually find it easier to relate to real-life examples rather than abstract descriptions. They
can understand and criticize a scenario of how they might interact with a software system.
Requirements engineers can use the information gained from this discussion to formulate the
actual system requirements.

At its most general, a scenario may include:

1. A description of what the system and users expects when the scenario starts.

2. A description of the normal flow of events in the scenario.

3. A description of what can go wrong and how this is handled.

4. Information about other activities that might be going on at the same time.

5. A description of the system state when the scenario finishes.

Example:

Scenario-based elicitation involves working with stakeholders to identify scenarios and to

capture details to be included in these scenarios. Scenarios may be written as text, supplemented
by diagrams, screen shots, etc. Alternatively, a more structured approach such as event scenarios
or use cases may be used.

As an example of a simple text scenario, we can consider how the MHC-PMS (Mental Health
Care-Patient Management System) may be used to enter data for a new patient (Figure
below).When a new patient attends a clinic, a new record is created by a medical receptionist and
personal information(name, age, etc.) is added to it. A nurse then interviews the patient and
collects medical history. The patient then has an initial consultation with a doctor who makes a
diagnosis and, if appropriate, recommends a course of treatment. The scenario shows what
happens when medical history is collected.

Page 35 of 62
Figure: Scenario for collecting medical history in MHC-PMS

Page 36 of 62
Course Title: Software Engineering

Lecture: 13 & 14
Course Code: CSE-3505

Topic
Requirement Engineering Process
Instructor: Ahmed Shan-A-Alahi, Lecturer, CSE, IIUC

Use- cases

Use-cases are a scenario-based requirements discovery technique which identifies the actors
involved in an interaction and names the type of interaction. This is then supplemented by
additional information describing the interaction with the system. The additional information
may be a textual description or one or more graphical models such as sequence or state diagrams.

Use- case notation

Figure below illustrates the essentials of the use-case notation. Actors in the process are
represented as stick figures, and each class of interaction is represented as a named ellipse.

Figure: A simple use-case for article printing

The set of use-cases represents all of the possible interactions to be represented in the system
requirements. Figure below develops the LIBSYS example and shows other use-cases in that
environment.

Page 37 of 62
Figure: Use cases for the library system

Use-cases identify the individual interactions with the system. They can be documented with text
or linked to graphical models that develop the scenario in more detail. Sequence diagrams are
often used to add information to a use-case. These sequence diagrams show the actors involved
in the interaction, the objects they interact with and the operations associated with these objects.
As an illustration of this figure below shows the interactions involved in using LIBSYS for
downloading and printing article. In this figure there are four objects of classes-Article, Form,
Workspace and Printer-involved in this interaction. The sequence of actions is from top to
bottom, and the labels on the arrows between the actors and objects indicate the names of
operations. Essentially, a user request for an article triggers a request for a copyright form. Once
the user has completed the form, the article is downloaded and sent to the printer. Once printing
is completed, the article is deleted from the LIBSYS workspace.

Page 38 of 62
Figure: System interaction for article printing

Social and organisational factors and Ethnography

Software systems do not exist in isolation. They are used in a social and organizational context
and software system requirements maybe derived or constrained by that context. Satisfying these
social and organizational requirements is often critical for the success of the system. One reason
why many software systems are delivered but never used is that their requirements do not take
proper account of how the social and organizational context affects the practical operation of the
system. In short we can say-

• Software systems are used in a social and organisational context. This can influence or even
dominate the system requirements.

Page 39 of 62
• Social and organisational factors are not a single viewpoint but are influences on all
viewpoints.

• Good analysts must be sensitive to these factors but currently no systematic way to tackle their
analysis.

Ethnography is an observational technique that can be used to understand operational processes

and help derive support requirements for these processes. An analyst immerses himself or herself
in the working environment where the system will be used. The day-to-day work is observed and
notes made of the actual tasks in which participants are involved. The value of ethnography is
that it helps discover implicit system requirements that reflect the actual ways that people work,
rather than the formal processes defined by the organization. Briefly we can say in ethnography-

• A social scientist spends a considerable time observing and analysing how people actually
work.

• People do not have to explain or articulate their work.

• Social and organisational factors of importance may be observed.

• Ethnographic studies have shown that work is usually richer and more complex than
suggested by simple system models.

Requirements validation

Requirements validation is the process of checking that requirements actually define the system
that the customer really wants. It overlaps with analysis as it is concerned with finding problems
with the requirements. Requirements validation is important because errors in a requirements
document can lead to extensive rework costs when these problems are discovered during
development or after the system is in service.

The cost of fixing a requirements problem by making a system change is usually much greater
than repairing design or coding errors. The reason for this is that a change to the requirements
usually means that the system design and implementation must also be changed. Furthermore the
system must then be retested.

Requirements checking

During the requirements validation process, different types of checks should be carried out on
the requirements in the requirements document. These checks include:

1. Validity checks: A user may think that a system is needed to perform certain functions.
However, further thought and analysis may identify additional or different functions that are

Page 40 of 62
required. Systems have diverse stakeholders with different needs and any set of requirements is
inevitably a compromise across the stake-holder community.

2. Consistency checks: Requirements in the document should not conflict. That is, there should
not be contradictory constraints or different descriptions of the same system function.

3. Completeness checks: The requirements document should include requirements that define
all functions and the constraints intended by the system user.

4. Realism checks: Using knowledge of existing technology, the requirements should be

checked to ensure that they can actually be implemented. These checks should also take account
of the budget and schedule for the system development.

5. Verifiability: To reduce the potential for dispute between customer and contractor, system
requirements should always be written so that they are verifiable. This means that you should be
able to write a set of tests that can demonstrate that the delivered system meets each specified
requirement.

Requirements validation techniques

There are a number of requirements validation techniques that can be used individually or in
conjunction with one another:

1. Requirements reviews: The requirements are analyzed systematically by a team of reviewers

who check for errors and inconsistencies.

2. Prototyping: In this approach to validation, an executable model of the system in question is

demonstrated to end-users and customers. They can experiment with this model to see if it meets
their real needs.

3. Test-case generation: Requirements should be testable. If the tests for the requirements are
devised as part of the validation process, this often reveals requirements problems. If a test is
difficult or impossible to design, this usually means that the requirements will be difficult to
implement and should be reconsidered. Developing tests from the user requirements before any
code is written is an integral part of extreme programming.

Page 41 of 62
Course Title: Software Engineering

Lecture: 15
Course Code: CSE-3505

Topic
Software Design
Instructor: Ahmed Shan-A-Alahi, Lecturer, CSE, IIUC

The Context of Software Design

The goal of software design is to specify how the system is going to be implemented. This results
in design specifications (which we’ll refer to as designs) that can be presented in a number of
ways

- Natural language

- Formal Descriptions

- Semi-formal graphical approaches

The design is used by the programmer to implement the software.

Definition

Design is a meaningful engineering representation of software that is to be built. It can be treated

to a customer’s requirements and at the same time assessed for quality against a set of predefined
criteria for ‘good’ design.

What does a Software Design Specify?

Typically a Software Design will specify

1. The architecture of the system: The set of components that make up the program.

2. The interface design: The way in which the components interact.

3. The component design: The responsibilities that are allocated to the components.

4. Data structure design: The data structure used in the program are designed in detail and
specified.

5. Algorithm design: The algorithms that allow the components to fulfill their responsibilities
must be identified.

Page 42 of 62
A general model of software design process

A Simple Design Process

Overall Design sets the structure or shape of the software. It

identifies the set of modules.

Detailed Design defines the processing that is carried out in the

modules.

Data Structure Design chooses the data structures to be used.

Structure Charts

Structure charts are used to represent the design of software at the Overall Design level. A
Structure Chart shows software divided into a set of modules. Structure Charts are usually used
as part of a Functional Design Strategy, called Structured Design, where the requirements
specification has been developed using a method called Structured Analysis (which uses a

Page 43 of 62
notation called Data Flow Diagrams). We’ve not had time to cover Structured Analysis, so we’ll
simply use Structure Charts as a way of representing and reasoning about modular designs.

Structure Chart Notation Modules

Page 44 of 62
Module

A module is a software component or part of a program that contains one or more functions. One
or more independently developed modules make up a program. An enterprise-level software
application may contain several different modules, and each module serves unique and separate
business operations. Modules allow the designer to focus on smaller parts of the system
independently from the other modules. This is of course a standard problem solving techniques
of splitting a problem down into a set of more manageable problems (Divide and Conquer
strategy). We break the design down into a set of modules for more manageable levels of
complexity. Ideally these subtasks will be independent, so that when we think about one module
we will not have to think about any others. In practice, the modules will not always be totally
independent. Modules will communicate with other modules. For example, if a module
corresponds to a C function, the functions will need to call one another. However, good
modularization uses forms of communication that maximize the independence between the
modules and thus simplify the problem.

Module Size

A module should contain between 10 and 100 statements. Larger than 100 is difficult to correct
which gives problems with maintenance and smaller than 10 the overhead of calling the module
outweighs its advantage which gives problems with efficiency. Some studies show that the
‘ideal’ size is somewhere around 30-50 lines.

Page 45 of 62
fan-in and fan-out

The fan-in of a subordinate module is the number of super ordinate modules that call it. Module
1 below has a fan-in of 4(Figure A). Fan-in should be maximized but not at any cost. High fan-in
means that replicated code is minimized. This is desirable from a maintenance perspective. The
fan-out of a module is the number of subordinate modules that a super ordinate module calls.
The Module 1 has a fan-out of 2 (Figure B). The fan-out of a module should be less than 8. If the
fan-out exceeds 8 the module is complex which will cause problems from a maintenance
perspective.

Module 2 Module 3 Module 4 Module 5

Module 1

Figure A: fan-in

Module 1

Module 2 Module 3

Figure B: fan-out

Page 46 of 62
Coupling and Cohesion

Coupling and cohesion are two concepts found in object oriented languages. Coupling measures
how much each of the program modules are dependent on the other program modules. Cohesion
measures how strongly each of the functions are related within a module.

Actually, cohesion is the qualitative measure (the strength) of the degree of common purpose of
a module. There are a number of different types of cohesion and they are classifies on an ordinal
scale:

- Coincidental cohesion BAD

- Logical cohesion

- Temporal Cohesion

- Procedural cohesion

- Communication cohesion

- Sequential cohesion

- Functional cohesion GOOD

1. Coincidental Cohesion: Components are grouped into a module in a haphazard way. The
responsibilities of the components bear no relation to each other.

Page 47 of 62
2. Logical Cohesion: Components perform tasks that are logically related.

3. Temporal Cohesion: The components are independent but are invoked at the same time in the
life of a program.

4. Procedural Cohesion: The module consists of a number of components that have to be

executed in a particular order.

5. Communication Cohesion: The components of the module operate the same external data.

6. Sequential Cohesion: The module consists of a sequence of components where the output of
one is the input for the next component.

7. Functional Cohesion: All the components in the module contribute to the one single
functional goal of the module.

Good (strong) Cohesion is where all elements of a module contribute to the satisfaction of a single
functional goal. The module does one ‘thing’ and all statements contribute to doing the one ‘thing’.

Poor (weak) Cohesion is where the module tries to satisfy more than one functional goal or implements
parts of a functional goal. The module tries to do parts of many things.

Difference between Coupling and Cohesion

Even though coupling and cohesion deal with the quality of a module in software engineering,
they are entirely different concepts. Some basic difference between coupling and cohesion are:

Coupling Cohesion
1. Coupling is the indication of the relationships 1. Cohesion is the indication of the relationship
between modules. within module.
2.Coupling shows the 2.Cohesion shows the module’s
relative independence among the modules. relative functional strength.
3. Coupling is a degree to which a component 3. Cohesion is a degree (quality) to which a
module is connected to the other modules. component / module focuses on the single thing.
4. Coupling is Inter -Module Concept. 4. Cohesion is Intra – Module Concept.

Page 48 of 62
Course Title: Software Engineering

Lecture: 16
Course Code: CSE-3505

Topic
Validation and Verification
Instructor: Ahmed Shan-A-Alahi, Lecturer, CSE, IIUC

Validation and Verification

The terms Verification and Validation are commonly used in software engineering to mean two
different types of analysis. The usual definitions are:

Verification: Are we building the system right?

Validation: Are we building the right system?

In other words, verification is concerned with whether the system is well-engineered, error-free,
and so on. Verification will help to determine whether the software is of high quality, but it will
not ensure that the system is useful while validation is concerned with checking that the system
will meet the customer’s actual needs. Both activities often referred to as V&V.

The distinction between these two terms can be summarized as follows:

Criteria Verification Validation

Definition The process of evaluating work-products (not The process of evaluating
the actual final product) of a development software during or at the end
phase to determine whether they meet the of the development process to
specified requirements for that phase. determine whether it satisfies
specified business
requirements.
Objective To ensure that the product is being built To ensure that the product
according to the requirements and design actually meets the user’s
specifications. In other words, to ensure that needs, and that the
work products meet their specified specifications were correct in
requirements. the first place. In other words,
to demonstrate that the
product fulfills its intended
use when placed in its
intended environment.
Question Are we building the product right? Are we building
the right product?
Evaluation Plans, Requirement Specifications, Design The actual product/software.
Items Specifications, Code, Test Cases
Activities • Reviews  Testing
• Walkthroughs
• Inspections
Page 49 of 62
Testing

 Testing is a crucial part of software quality assurance.

 In industry it is not unusual for testing to occupy between 30% to 49% of the project budget.
 For safety critical software testing may occupy a cost of 3 to 5 times as much as the rest of the
software engineering activities.

Testing Objectives

 Testing is a process of executing a program with the intent of finding errors.

 A good test case is one that has a high probability of finding an as-yet undiscovered error.
 A successful test is one that uncovers an as-yet undiscovered error.
 Testing cannot show the absence of defects, it can only show that software errors are present.

Types of testing

There are two basic types of testing

Black-box testing

Black-box testing (also known as functional testing) treats software under test as a black-box
without knowing its internals. Tests are using software interfaces and trying to ensure that they
work as expected. As long as functionality of interfaces remains unchanged, tests should pass
even if internals are changed. Tester is aware of what the program should do but does not have
the knowledge of how it does it. Black-box testing is most commonly used type of testing in
traditional organizations that have testers as a separate department, especially when they are not
proficient in coding and have difficulties to understand the code. It provides external
perspective of the software under test.

Some of the advantages of black-box testing are:

1. Efficient for large segments of code.

2. Code access is not required.
3. Separation between user’s and developer’s perspectives.

Page 50 of 62
Some of the disadvantages of black-box testing are:

1. Limited coverage since only a fraction of test scenarios is performed.

2. Inefficient testing due to tester’s luck of knowledge about software internals.
3. Blind coverage since tester has limited knowledge about the application.

White-box testing
White-box testing (also known as clear box testing, glass box testing, transparent box testing,
and structural testing) looks inside the software that is being tested and uses that knowledge as
part of the testing process White-box testing requires internal knowledge of the system and
programming skills. It provides internal perspective of the software under test.

Some of the advantages of white-box testing are:

1. Efficient in finding errors and problems.

2. Required knowledge of internals of the software under test is beneficial for thorough
testing.
3. Allows finding hidden errors.
4. Programmers introspection.
5. Helps optimizing the code.
6. Due to required internal knowledge of the software, maximum coverage is obtained.

Some of the disadvantages of white-box testing are:

1. Might not find unimplemented or missing features.

2. Requires high level knowledge of internals of the software under test.
3. Requires code access.

Testing Documentation

There are two aspects to test documentation

The Test Plan- This can start to be developed at the analysis stage and can further refined
during design and implementation

The Test Log- This is a log that records the tests applied and the results of each test. For a
module this may look the table on the following page

Page 51 of 62
Test Log (for classify)

Condition Expected Result Actual Result Remarks

a=3, b=3, c=4 True True Pass
a=10, b=2, c=7 False True Problem bad return from
order
a=-7, b=3, c=6 False False Pass

Testing with Customers

The developers of software will not always foresee exactly how the customer will use their
software. Therefore testing with the customer is important. When the software is a custom
product for one specific product a series of Acceptance Tests are undertaken where the customer
determine whether his/her requirements are satisfied ranges from a ‘test-drive’ to systematic
testing procedure. Where software is to be used with many customers, the developer must test
with a representative sample. Most developers use alpha and beta testing-

Alpha Test

-Customer is taken developer’s site and asked to use the software with developer watching and
recording problems any errors

Beta Test

- Number of customers use the software on their own sites

- Developer is not present

- Customer records problems

Top down and bottom up approach of software testing

Top down Testing: In this approach testing is conducted from main module to sub module. if
the sub module is not developed a temporary program called STUB is used for simulate the sub
module.

Advantages:
-Advantageous if major flaws occur toward the top of the program.
-Once the I/O functions are added, representation of test cases is easier.
-Early skeletal Program allows demonstrations and boosts morale.

Disadvantages:
- Stub modules must be produced.
- Stub Modules are often more complicated than they first appear to be.
- Before the I/O functions are added, representation of test cases in stubs can be difficult.

Page 52 of 62
- Test conditions may be impossible, or very difficult, to create.
- Observation of test output is more difficult.
- Allows one to think that design and testing can be overlapped.
- Induces one to defer completion of the testing of certain modules.

Bottom up testing: In this approach testing is conducted from sub module to main module, if
the main module is not developed a temporary program called DRIVERS is used to simulate the
main module.

Advantages:
- Advantageous if major flaws occur toward the bottom of the program.
- Test conditions are easier to create.
- Observation of test results is easier.

Disadvantages:
- Driver Modules must be produced.
- The program as an entity does not exist until the last module is added

The basic differences between top down and bottom up approach of software testing are:

No. Top down approach Bottom up approach

1. Top down testing conducted from Bottom up testing conducted from sub module to
main module to sub module. main module.
2. If sub module is not developed a If main module is not developed a temporary
temporary program called Stub is used program called Driver is used to simulate the
to simulate the sub module. main module.
3. Top down testing good if major flaws Bottom up testing good if major flaws occur
occur toward the top of the program. toward the bottom of the program.
4. In this test condition difficult to create. In this test condition easy to create.
5. Observation of test output is more Observation of test output is easier.
difficult.

Page 53 of 62
Figure: Creating stubs and drivers to do integration tests for C

Page 54 of 62
Course Title: Software Engineering

Lecture: 17
Course Code: CSE-3505

Topic
Software maintenance and documentation
Instructor: Ahmed Shan-A-Alahi, Lecturer, CSE, IIUC

Software maintenance in software engineering is the modification of a software product after

delivery to correct faults, to improve performance or other attributes.

A common perception of maintenance is that it merely involves fixing defects. However, one
study indicated that over 80% of maintenance effort is used for non-corrective actions.

Software maintenance activities categorize into four classes:

Adaptive – modifying the system to cope with changes in the software environment. For
example, the operating system may change or the hardware platforms may change. Suppose if
we wrote a program 10 years ago for PCs, we may have gone through DOS, Windows 3.1 and
Windows 95, Windows 98, Windows NT versions. In this activity functionality of the software
does not radically change. Surveys shows that about 18% of maintenance is adaptive.

Perfective – implementing new or changed user requirements which concern functional or non-
functional enhancements to the software. For example, generally customers’ requirements will
change with time and some software programs have lifetime of greater than 10 or 15 years so
new functional and non-functional requirements will emerge as time goes by. Surveys shows that
about 65% of maintenance is perfective.

Corrective – diagnosing and fixing errors, possibly ones found by users. This may be coding
errors which are relatively cheap to fix, design errors which are more expensive as several
modules may need to be rewritten, analysis errors which are most expensive because the
program may require significant redesign. Surveys shows that about 17% of maintenance is
corrective.

Preventive – increasing software maintainability or reliability to prevent problems in the future.

For example this involves redesign, rewriting and documentation of the code after the program
has been delivered and altered due to maintenance activities. The idea is that preventative
maintenance can improve the code’s structure and design making subsequent maintenance easier.
It tries to prevent degradation in the structure of the code.

Page 55 of 62
Factors that affect Maintenance Costs

1. Good Software Engineering

-Independent modules that exhibit information hiding (loosely coupled and strongly cohesive)
allow modules to be changed without affecting other modules.

- Good Programming Style (meaningful variable names and comments, style corresponding to
house standards) leads to readable code.

- Good test and validation if this is carried out properly there will be fewer errors in the
program and corrective maintenance costs will be reduced.

- Quality of Documentation: Well-documented programs are cheaper to maintain than those

with poor or non-existent documentation.

- Good configuration management technique.

- Use of modern programming languages.

2. Understanding how the software is to be used by the customer is important

- This is referred to as the application domain.

- If the application domain is well understood the system’s requirements should be good, hence
perfective maintenance will be minimized.

- If the application domain, is not so well understood, requirements will be less precise and
perfective maintenance may be higher.

3. If the person who wrote the code is responsible for its maintenance, cost will be reduced.

4. The older the program, the more its structure degrades, the more expensive it is to maintain.

5. If the external environment of the program is stable, the program will require less
maintenance.

6. If the program is designed for a particular hardware platform, and that does not change during
the lifetime of the system, costs will be reduced.

Software documentation

Documentation is the technical manual, user manual or other instructional manual that facilitate
the use of a software product or services. Documentation includes source code, instructional
items, error code where ever required. It may exists in any formats like PDF, Word or CDs.
Documentation play an important role in software engineering. Suppose that in C lab you are

Page 56 of 62
given another student’s project and asked to fix some faults and add a significant new function .
In this case, software documentation is necessary because the source code alone not sufficient
here.

Importance of Software Documentation

1. Clarify our business goals, requirements and activities: With a proper documentation, we
can share the business goals and requirement with your managers and team mates so that they
have a clear vision and goals and the activity they perform will be more towards the success.

2. Design and Specify our product: This comes in Architectural/Design documents and it gives
you complete overview of how our products look like.

3. Everything is clearly explained: When we make End User documentation of the product of
software, we have to explain each and everything about its working. It describes each feature of
the program, and assists the user in realizing these features.

4. Anybody can work on other's code: If we are a developer, it is not sufficient to write good
codes only but you also need to take cares about the documentation part, which can be helpful to
other developers while working in a team.

5. Helpful in proper communication: A good software documentation is helpful in proper

communication. The written procedure helps us to make interaction within several departments.

Page 57 of 62
Course Title: Software Engineering

Lecture: 18
Course Code: CSE-3505

Topic
Software management
Instructor: Ahmed Shan-A-Alahi, Lecturer, CSE, IIUC

Software cost estimation technique

 Algorithmic cost: A model is developed using historical cost information that relates
some software metric to the project cost.

 Expert judgment: Several experts on the proposed software development techniques and
the application domain are consulted, they each estimate the project cost.

 Estimation by analogy: This technique is applicable when other projects in the same
application domain have been completed. The cost of a new project is estimated by
analogy with this completed projects.

 Parkinson’s Law: Parkinson’s Law states that work expends to fill the time available. The
cost is determined by available resources rather than by objective assessment.

 Pricing to win: The software cost is estimated to be whatever the customer has available
to spend on the project. The estimated project depends on the customer’s budget and not
on the software functionality.

The COCOMO Model

The Constructive Cost Model (COCOMO) is an algorithmic software cost estimation model
developed by Barry Boehm. The model uses a basic regression formula, with parameters that are
derived from historical project data and current project characteristics.

Reasons for choosing cocomo model:

1. It is well documented, available in the public domain and supported by the public domain and
commercial tools.

2. It has been widely used and evaluated in a range of organizations.

3. It has a long pedigree (background) from its first instantiation in 1989, through a refinement
tailored (gear) to ada software development.

Page 58 of 62
Software Attributes
 We can measure the internal attributes of
software
- Things like number of lines of code, the
readability of the software manual, the number
of faults observed in testing, the fan in of the
modules, etc
 What is important is how the internal attributes
relate to the external attributes
- The characteristics of the actual product
 These are the ilities, such as Maintainability, Reliability,
Portability, Usability, etc

Relationship Between Internal

and External Attributes
Internal Attributes
External Attributes
Number of
Maintainability procedure parameters

Cyclometric
Reliability complexity

Number of lines of code

Portability
Number of
error message
Usability
Length of
user manual

Page 59 of 62
Information Fan In/ Fan Out
 Fan In & Fan Out does not consider the
data passes to the module
- So class_ord appears less complex
than order
 It’s rather more complex
 Information Fan In & Fan Out considers
the parameters passed
Fan in information = 3
Fan out information = 2
Complexity = 5
Order

Page 60 of 62
Henry and Kafura’s Metric
 This uses the following formula
- For module m, the complexity C is:
- C = length (m) x (fan_in(m) + fan_out(m))2
- where
 length (m) is the length of the module as lines of
code or as Cyclometric Complexity
 fan_in and fan_out are computed as the
information metric
 When applied at design time before code
is developed, length must be an estimate

Card and Glass’s Systems

Complexity
 Structural Complexity S of module m is given by
- S(m) = fan_out(m)2
 where fan_out is the standard fan out rather than the
information fan out
 Data Complexity D of module m is given by
- D(m) = v(m).(fan_out(m)+1)
- where v(m) is the number of input and output variables
passed to and from the module m
 System Complexity C for module m is
- C(m) = S(m) + D(m)

Page 61 of 62
Exercise:

***The fan in and fan out of module X is 3 and 4 respectively. The complexity of the system is
2000. The number of lines in module X is 200, i.e LOC of module X is LOC(X) =200.Calculate
the structural complexity of module X using card and glass’s system complexity. Using
combined Henry Kafura’s approach and Card glass’s approach calculate the data complexity of
module X.

*** Suppose the fan out of a module is: 5, the cumulative number of variables passed to and
from the module is: 9, the complexity of the module is: 35. Use Card and Glass’s Systems
Complexity method in order to find out the structural complexity of the module.

Page 62 of 62