Department of Mathematics and Computer Science

Faculty of Science
Borno State University, Maiduguri

CSC403: Software Engineering

Course Content

Software engineering concepts and principle; design, development and testing of software
systems. Introduction to software lifecycle. Requirement, design and testing. Review of
principles of object orientation. OO analysis using UML. Frameworks and APIs. Introduction
to client-server architecture. Analysis, design and programming of team project including
user interface consideration.

Course Content

Software crisis. Goals, Scope and Principles of Software Engineering; Software Process,
Software process models: Waterfall model, V-model, Prototyping, Incremental model, Spiral
model. Agile Software Development methodology: Extreme Programming (XP). Software
Design: Architectural design, Component design, Design patterns, Object Oriented analysis
and design. UML Notations: use case, sequence diagram, and class diagrams. Software
Reliability; Verification and Validation, Software testing; Black-box testing, White-box
testing. Software Maintenance, Introduction to software project management.

Introduction to Software Engineering

The term software engineering is composed of two words, software and engineering.

Software is more than just a program code. A program is an executable code, which serves
some computational purpose. Software is considered to be a collection of executable
programming code, associated libraries and documentations. Software, when made for a
specific requirement is called software product.

Engineering on the other hand, is all about developing products, using well-defined, scientific
principles and methods.

So, we can define software engineering as an engineering branch associated with the
development of software product using well-defined scientific principles, methods and
procedures. The outcome of software engineering is an efficient and reliable software
product.

IEEE defines software engineering as: The application of a systematic, disciplined,

quantifiable approach to the development, operation and maintenance of software.
We can alternatively view it as a systematic collection of past experience. The experience is
arranged in the form of methodologies and guidelines. A small program can be written
without using software engineering principles. But if one wants to develop a large software
product, then software engineering principles are absolutely necessary to achieve a good
quality software cost effectively.

Without using software engineering principles it would be difficult to develop large

programs. In industry it is usually needed to develop large programs to accommodate
multiple functions. A problem with developing such large commercial programs is that the
complexity and difficulty levels of the programs increase exponentially with their sizes.
Software engineering helps to reduce this programming complexity. Software engineering
principles use two important techniques to reduce problem complexity: abstraction and
decomposition. The principle of abstraction implies that a problem can be simplified by
omitting irrelevant details. In other words, the main purpose of abstraction is to consider only
those aspects of the problem that are relevant for certain purpose and suppress other aspects
that are not relevant for the given purpose. Once the simpler problem is solved, then the
omitted details can be taken into consideration to solve the next lower level abstraction, and
so on. Abstraction is a powerful way of reducing the complexity of the problem. The other
approach to tackle problem complexity is decomposition. In this technique, a complex
problem is divided into several smaller problems and then the smaller problems are solved
one by one. However, in this technique any random decomposition of a problem into smaller
parts will not help. The problem has to be decomposed such that each component of the
decomposed problem can be solved independently and then the solution of the different
components can be combined to get the full solution. A good decomposition of a problem
should minimize interactions among various components. If the different subcomponents are
interrelated, then the different components cannot be solved separately and the desired
reduction in complexity will not be realized.

NEED OF SOFTWARE ENGINEERING

The need of software engineering arises because of higher rate of change in user requirements
and environment on which the software is working.

 Large software - It is easier to build a wall than to a house or building, likewise, as the
size of software become large engineering has to step to give it a scientific process.
 Scalability- If the software process were not based on scientific and engineering
concepts, it would be easier to re-create new software than to scale an existing one.
 Cost- As hardware industry has shown its skills and huge manufacturing has lower
down the price of computer and electronic hardware. But the cost of software remains
high if proper process is not adapted.
 Dynamic Nature- The always growing and adapting nature of software hugely
depends upon the environment in which the user works. If the nature of software is
always changing, new enhancements need to be done in the existing one. This is
where software engineering plays a good role.
 Quality Management- Better process of software development provides better and
quality software product.
CHARACTERESTICS OF GOOD SOFTWARE

A software product can be judged by what it offers and how well it can be used. This
software must satisfy on the following grounds:

 Operational
 Transitional
 Maintenance

Well-engineered and crafted software is expected to have the following characteristics:

Operational

This tells us how well software works in operations. It can be measured on:

 Budget
 Usability
 Efficiency
 Correctness
 Functionality
 Dependability
 Security
 Safety

Transitional

This aspect is important when the software is moved from one platform to another:
 Portability
 Interoperability
 Reusability
 Adaptability

Maintenance
This aspect briefs about how well a software has the capabilities to maintain itself in the ever
changing environment:

 Modularity
 Maintainability
 Flexibility
 Scalability
In short, Software engineering is a branch of computer science, which uses well-defined
engineering concepts required to produce efficient, durable, scalable, in-budget and on-time
software products.

SOFTWARE DEVELOPMENT LIFE CYCLE

LIFE CYCLE MODEL

A software life cycle model (also called process model) is a descriptive and diagrammatic
representation of the software life cycle. A life cycle model represents all the activities
required to make a software product transit through its life cycle phases. It also captures the
order in which these activities are to be undertaken. In other words, a life cycle model maps
the different activities performed on a software product from its inception to retirement.
Different life cycle models may map the basic development activities to phases in different
ways. Thus, no matter which life cycle model is followed, the basic activities are included in
all life cycle models though the activities may be carried out in different orders in different
life cycle models. During any life cycle phase, more than one activity may also be carried
out.

THE NEED FOR A SOFTWARE LIFE CYCLE MODEL

The development team must identify a suitable life cycle model for the particular project and
then adhere to it. Without using of a particular life cycle model the development of a software
product would not be in a systematic and disciplined manner.

When a software product is being developed by a team there must be a clear understanding
among team members about when and what to do. Otherwise it would lead to chaos and
project failure.

This problem can be illustrated by using an example. Assuming a software development

problem is divided into several parts and the parts are assigned to the team members. From
then on, suppose the team members are allowed the freedom to develop the parts assigned to
them in whatever way they like. It is possible that one member might start writing the code
for his part, another might decide to prepare the test documents first, and some other engineer
might begin with the design phase of the parts assigned to him. This would be one of the
perfect recipes for project failure.

A software life cycle model defines entry and exit criteria for every phase. A phase can start
only if its phase-entry criteria have been satisfied. So without software life cycle model the
entry and exit criteria for a phase cannot be recognized. Without software life cycle models it
becomes difficult for software project managers to monitor the progress of the project.

Different software life cycle models

Many life cycle models have been proposed so far. Each of them has some advantages as
well as some disadvantages. A few important and commonly used life cycle models are as
follows:

 Classical Waterfall Model

 Iterative Waterfall Model
 Prototyping Model
 Evolutionary Model
 Spiral Model.

1. CLASSICAL WATERFALL MODEL

The classical waterfall model is intuitively the most obvious way to develop software.
Though the classical waterfall model is elegant and intuitively obvious, it is not a practical
model in the sense that it cannot be used in actual software development projects. Thus, this
model can be considered to be a theoretical way of developing software. But all other life
cycle models are essentially derived from the classical waterfall model. So, in order to be
able to appreciate other life cycle models it is necessary to learn the classical waterfall model.
Classical waterfall model divides the life cycle into the following phases as shown in Figure
1:

Figure 1: Classical Waterfall Model

Feasibility study - The main aim of feasibility study is to determine whether it would be
financially and technically feasible to develop the product.

 At first project managers or team leaders try to have a rough understanding of what is
required to be done by visiting the client side. They study different input data to the
system and output data to be produced by the system. They study what kind of processing
is needed to be done on these data and they look at the various constraints on the behavior
of the system.
 After they have an overall understanding of the problem they investigate the different
solutions that are possible. Then they examine each of the solutions in terms of what kind
of resources required, what would be the cost of development and what would be the
development time for each solution.
 Based on this analysis they pick the best solution and determine whether the solution is
feasible financially and technically. They check whether the customer budget would meet
the cost of the product and whether they have sufficient technical expertise in the area of
development.

Requirements analysis and specification: - The aim of the requirements analysis and
specification phase is to understand the exact requirements of the customer and to document
them properly. This phase consists of two distinct activities, namely

 Requirements gathering and analysis

 Requirements specification

The goal of the requirements gathering activity is to collect all relevant information from the
customer regarding the product to be developed. This is done to clearly understand the
customer requirements so that incompleteness and inconsistencies are removed. The
requirements analysis activity is begun by collecting all relevant data regarding the product to
be developed from the users of the product and from the customer through interviews and
discussions. For example, to perform the requirements analysis of a business accounting
software required by an organization, the analyst might interview all the accountants of the
organization to ascertain their requirements. The data collected from such a group of users
usually contain several contradictions and ambiguities, since each user typically has only a
partial and incomplete view of the system. Therefore it is necessary to identify all ambiguities
and contradictions in the requirements and resolve them through further discussions with the
customer. After all ambiguities, inconsistencies, and incompleteness have been resolved and
all the requirements properly understood, the requirements specification activity can start.
During this activity, the user requirements are systematically organized into a Software
Requirements Specification (SRS) document. The customer requirements identified during
the requirements gathering and analysis activity are organized into a SRS document. The
important components of this document are functional requirements, the nonfunctional
requirements, and the goals of implementation.

Design: - The goal of the design phase is to transform the requirements specified in the SRS
document into a structure that is suitable for implementation in some programming language.
In technical terms, during the design phase the software architecture is derived from the SRS
document. Two distinctly different approaches are available: the traditional design approach
and the object-oriented design approach.

 Traditional design approach -Traditional design consists of two different activities; first
a structured analysis of the requirements specification is carried out where the detailed
structure of the problem is examined. This is followed by a structured design activity.
During structured design, the results of structured analysis are transformed into the
software design.
 Object-oriented design approach -In this technique, various objects that occur in the
problem domain and the solution domain are first identified, and the different relationships
that exist among these objects are identified. The object structure is further refined to
obtain the detailed design.

Coding and unit testing:- The purpose of the coding phase (sometimes called the
implementation phase) of software development is to translate the software design into source
code. Each component of the design is implemented as a program module. The end-product
of this phase is a set of program modules that have been individually tested. During this
phase, each module is unit tested to determine the correct working of all the individual
modules. It involves testing each module in isolation as this is the most efficient way to
debug the errors identified at this stage.

Integration and system testing: - Integration of different modules is undertaken once they
have been coded and unit tested. During the integration and system testing phase, the
modules are integrated in a planned manner. The different modules making up a software
product are almost never integrated in one shot. Integration is normally carried out
incrementally over a number of steps. During each integration step, the partially integrated
system is tested and a set of previously planned modules are added to it. Finally, when all the
modules have been successfully integrated and tested, system testing is carried out. The goal
of system testing is to ensure that the developed system conforms to its requirements laid out
in the SRS document. System testing usually consists of three different kinds of testing
activities:
 α – testing: It is the system testing performed by the development team.
 β –testing: It is the system testing performed by a friendly set of customers.
 Acceptance testing: It is the system testing performed by the customer himself after the
product delivery to determine whether to accept or reject the delivered product.

System testing is normally carried out in a planned manner according to the system test plan
document. The system test plan identifies all testing-related activities that must be performed,

System testing is normally carried out in a planned manner according to the system test plan
document. The system test plan identifies all testing-related activities that must be performed,
specifies the schedule of testing, and allocates resources. It also lists all the test cases and the
expected outputs for each test case.

Maintenance: -Maintenance of a typical software product requires much more than the effort
necessary to develop the product itself. Many studies carried out in the past confirm this and
indicate that the relative effort of development of a typical software product to its
maintenance effort is roughly in the 40:60 ratios. Maintenance involves performing any one
or more of the following three kinds of activities:

 Correcting errors that were not discovered during the product development phase. This is
called corrective maintenance.
 Improving the implementation of the system, and enhancing the functionalities of the
system according to the customer’s requirements. This is called perfective maintenance.
 Porting the software to work in a new environment. For example, porting may be required
to get the software to work on a new computer platform or with a new operating system.
This is called adaptive maintenance.

Shortcomings of the classical waterfall model

The classical waterfall model is an idealistic one since it assumes that no development error
is ever committed by the engineers during any of the life cycle phases. However, in practical
development environments, the engineers do commit a large number of errors in almost every
phase of the life cycle. The source of the defects can be many: oversight, wrong assumptions,
use of inappropriate technology, communication gap among the project engineers, etc. These
defects usually get detected much later in the life cycle. For example, a design defect might
go unnoticed till we reach the coding or testing phase. Once a defect is detected, the
engineers need to go back to the phase where the defect had occurred and redo some of the
work done during that phase and the subsequent phases to correct the defect and its effect on
the later phases. Therefore, in any practical software development work, it is not possible to
strictly follow the classical waterfall model.

ITERATIVE WATERFALL MODEL

To overcome the major shortcomings of the classical waterfall model, we come up with the
iterative waterfall model.
Here, we provide feedback paths for error correction as & when detected later in a phase.
Though errors are inevitable, but it is desirable to detect them in the same phase in which
they occur. If so, this can reduce the effort to correct the bug.

Figure 2: Iterative Waterfall Model

The advantage of this model is that there is a working model of the system at a very early
stage of development which makes it easier to find functional or design flaws. Finding issues
at an early stage of development enables to take corrective measures in a limited budget.

The disadvantage with this SDLC model is that it is applicable only to large and bulky
software development projects. This is because it is hard to break a small software system
into further small serviceable increments/modules.

PROTOTYPING MODEL

Prototype

A prototype is a toy implementation of the system. A prototype usually exhibits limited

functional capabilities, low reliability, and inefficient performance compared to the actual
software. A prototype is usually built using several shortcuts. The shortcuts might involve
using inefficient, inaccurate, or dummy functions. The shortcut implementation of a function,
for example, may produce the desired results by using a table look-up instead of performing
the actual computations. A prototype usually turns out to be a very crude version of the actual
system.

Need for a prototype in software development

There are several uses of a prototype. An important purpose is to illustrate the input data
formats, messages, reports, and the interactive dialogues to the customer. This is a valuable
mechanism for gaining better understanding of the customer’s needs:

 how the screens might look like

 how the user interface would behave
 how the system would produce outputs

Another reason for developing a prototype is that it is impossible to get the perfect product in
the first attempt. Many researchers and engineers advocate that if you want to develop a good
product you must plan to throw away the first version. The experience gained in developing
the prototype can be used to develop the final product. A prototyping model can be used
when technical solutions are unclear to the development team. A developed prototype can
help engineers to critically examine the technical issues associated with the product
development. Often, major design decisions depend on issues like the response time of a
hardware controller, or the efficiency of a sorting algorithm, etc. In such circumstances, a
prototype may be the best or the only way to resolve the technical issues.

A prototype of the actual product is preferred in situations such as:

 User requirements are not complete

 Technical issues are not clear

Figure 3: Prototype Model

EVOLUTIONARY MODEL

It is also called successive versions model or incremental model. At first, a simple working
model is built. Subsequently it undergoes functional improvements & we keep on adding new
functions till the desired system is built.

Applications:

 Large projects where you can easily find modules for incremental implementation.
Often used when the customer wants to start using the core features rather than
waiting for the full software.
 Also used in object oriented software development because the system can be easily
portioned into units in terms of objects.

Advantages:

 User gets a chance to experiment partially developed system

 Reduce the error because the core modules get tested thoroughly.

Disadvantages:

 It is difficult to divide the problem into several versions that would be acceptable to
the customer which can be incrementally implemented and delivered.
 Figure 4: Evolutionary Model

SPIRAL MODEL

The Spiral model of software development is shown in Figure 4. The diagrammatic

representation of this model appears like a spiral with many loops. The exact number of loops
in the spiral is not fixed. Each loop of the spiral represents a phase of the software process.
For example, the innermost loop might be concerned with feasibility study, the next loop with
requirements specification, the next one with design, and so on. Each phase in this model is
split into four sectors (or quadrants) as shown in Figure 4. The following activities are carried
out during each phase of a spiral model.

Figure 4: Spiral Model

First quadrant (Objective Setting)

• During the first quadrant, it is needed to identify the objectives of the phase. • Examine the
risks associated with these objectives.
• Examine the risks associated with these objectives.

Second Quadrant (Risk Assessment and Reduction)

• A detailed analysis is carried out for each identified project risk.
• Steps are taken to reduce the risks. For example, if there is a risk that the requirements are
inappropriate, a prototype system may be developed.
Third Quadrant (Development and Validation)

• Develop and validate the next level of the product after resolving the identified risks.

Fourth Quadrant (Review and Planning)

• Review the results achieved so far with the customer and plan the next iteration around the
spiral.
• Progressively more complete version of the software gets built with each iteration around
the spiral.

Circumstances to use spiral model

The spiral model is called a meta model since it encompasses all other life cycle models. Risk
handling is inherently built into this model. The spiral model is suitable for development of
technically challenging software products that are prone to several kinds of risks. However,
this model is much more complex than the other models – this is probably a factor deterring
its use in ordinary projects.

Comparison of different life-cycle models

The classical waterfall model can be considered as the basic model and all other life cycle
models as embellishments of this model. However, the classical waterfall model cannot be
used in practical development projects, since this model supports no mechanism to handle the
errors committed during any of the phases.

This problem is overcome in the iterative waterfall model. The iterative waterfall model is
probably the most widely used software development model evolved so far. This model is
simple to understand and use. However this model is suitable only for well-understood
problems; it is not suitable for very large projects and for projects that are subject to many
risks.

The prototyping model is suitable for projects for which either the user requirements or the
underlying technical aspects are not well understood. This model is especially popular for
development of the user-interface part of the projects.

The evolutionary approach is suitable for large problems which can be decomposed into a set
of modules for incremental development and delivery. This model is also widely used for
object oriented development projects. Of course, this model can only be used if the
incremental delivery of the system is acceptable to the customer.

The spiral model is called a meta model since it encompasses all other life cycle models. Risk
handling is inherently built into this model. The spiral model is suitable for development of
technically challenging software products that are prone to several kinds of risks. However,
this model is much more complex than the other models – this is probably a factor deterring
its use in ordinary projects.
The different software life cycle models can be compared from the viewpoint of the
customer. Initially, customer confidence in the development team is usually high irrespective
of the development model followed. During the lengthy development process, customer
confidence normally drops off, as no working product is immediately visible. Developers
answer customer queries using technical slang, and delays are announced. This gives rise to
customer resentment. On the other hand, an evolutionary approach lets the customer
experiment with a working product much earlier than the monolithic approaches. Another
important advantage of the incremental model is that it reduces the customer’s trauma of
getting used to an entirely new system. The gradual introduction of the product via
incremental phases provides time to the customer to adjust to the new product. Also, from the
customer’s financial viewpoint, incremental development does not require a large upfront
capital outlay. The customer can order the incremental versions as and when he can afford
them.

SOFTWARE DESIGN

Software design is a process to transform user requirements into some suitable form, which
helps the programmer in software coding and implementation.

For assessing user requirements, an SRS (Software Requirement Specification) document is

created whereas for coding and implementation, there is a need of more specific and detailed
requirements in software terms. The output of this process can directly be used into
implementation in programming languages.

Software design is the first step in SDLC (Software Design Life Cycle), which moves the
concentration from problem domain to solution domain. It tries to specify how to fulfill the
requirements mentioned in SRS.

Software Design Levels

Software design yields three levels of results:

 Architectural Design - The architectural design is the highest abstract version of the
system. It identifies the software as a system with many components interacting with
each other. At this level, the designers get the idea of proposed solution domain.
 High-level Design- The high-level design breaks the ‘single entity-multiple
component’ concept of architectural design into less-abstracted view of sub-systems
and modules and depicts their interaction with each other. High-level design focuses
on how the system along with all of its components can be implemented in forms of
modules. It recognizes modular structure of each sub-system and their relation and
interaction among each other.
 Detailed Design- Detailed design deals with the implementation part of what is seen
as a system and its sub-systems in the previous two designs. It is more detailed
towards modules and their implementations. It defines logical structure of each
module and their interfaces to communicate with other modules.

Modularization
Modularization is a technique to divide a software system into multiple discrete and
independent modules, which are expected to be capable of carrying out task(s) independently.
These modules may work as basic constructs for the entire software. Designers tend to design
modules such that they can be executed and/or compiled separately and independently.

Modular design unintentionally follows the rules of ‘divide and conquer’ problem-solving
strategy this is because there are many other benefits attached with the modular design of a
software.

Advantage of modularization:

 Smaller components are easier to maintain

 Program can be divided based on functional aspects
 Desired level of abstraction can be brought in the program
 Components with high cohesion can be re-used again.
 Concurrent execution can be made possible.
 Desired from security aspect

Concurrency

Back in time, all software were meant to be executed sequentially. By sequential execution
we mean that the coded instruction will be executed one after another implying only one
portion of program being activated at any given time. Say, a software has multiple modules,
then only one of all the modules can be found active at any time of execution.

In software design, concurrency is implemented by splitting the software into multiple

independent units of execution, like modules and executing them in parallel. In other words,
concurrency provides capability to the software to execute more than one part of code in
parallel to each other.

It is necessary for the programmers and designers to recognize those modules, which can be
made parallel execution.

Example; The spell check feature in word processor is a module of software, which runs
alongside the word processor itself.

Coupling and Cohesion

When a software program is modularized, its tasks are divided into several modules based on
some characteristics. As we know, modules are set of instructions put together in order to
achieve some tasks. They are though, considered as single entity but may refer to each other
to work together. There are measures by which the quality of a design of modules and their
interaction among them can be measured. These measures are called coupling and cohesion.

Cohesion

Cohesion is a measure that defines the degree of intra-dependability within elements of a

module. The greater the cohesion, the better is the program design.