UNIT 1 – SOFTWARE ENGINEERING

CHAPTER 1 – INTRODUCTION TO SOFTWARE ENGINEERING

1.1 Basic definitions

1.1.1 Software?

↔ Definition1:

Software can be defined as “set of instructions” or “computer programs”

↔ Definition 2:
(IEEE) defines software as collection of programs, procedures, rules, and associated documentation and
data.

There are two fundamental types of software product:

1. Generic products
↔ Produced by software development organization and sold on the open market to any customer
who is able to by them.
↔ The organization that develops the software controls the software specification

Example: software for PCs such as databases, word processors, drawing packages and management tools

2. Customised (bespoke) products

↔ Developed for a particular customer, a software contractor develops the software especially for
that customer.
↔ The specification is usually developed and controlled by the organization that is buying the
software
↔ The software developers must work to that specification

Examples:

Control systems for electronic devices, systems written to support a particular business process such as INILAK
library management information system, air traffic control system

1.1.2 Software engineering

Definition 1:

↔ Software engineering is an engineering discipline that is concerned with all aspects of software
production from the early stages of system specification to maintaining the system after it has gone into
use.
  Engineering discipline: Engineering is about planning - Describing the problem, analyzing the
problem, searching for solutions, deciding on an appropriate solution, specifying the solution
 An engineer has to build solutions to problems which are
Correct, reliable, cheap, safe, adaptable, cost effective and fast

 Engineers apply selectively theories, methods and tools where these are
appropriate
 All aspects of software production: It means that Software engineering is not just concerned with the
technical processes of software development but also with activities
such as software project management and with the development of tools, methods and theories to
support software production.

Definition 2:

↔ Software engineering is the technological and managerial discipline concerned with systematic
production and maintenance of software products that are developed and modified on time and within
cost estimates.

1.2 Difference between software engineering and other engineering disciplines

 Software engineering vs. computer science

Computer science is concerned with the theories and methods that underlie computers and software systems,
whereas software engineering is concerned with the practical problems of producing software. But some
knowledge of computer science is essential for software engineers in the same way that some knowledge of
physics is essential for electrical engineers.

 System engineering vs. software engineering

System engineering is concerned with all aspects of computer-based systems development including hardware,
software and process engineering. Software engineering is part of this process

1.3 The need for software engineering

When a new application or embedded system is to be built, many voices must be heard. And it sometimes
seems that each of them has a slightly different idea of what software features and functions should be
delivered.

 Effort should be made to understand the problem before a software solution is developed

The complexity of new computer-based systems and products demands careful attention to the interaction of all
system elements.
  Design becomes a pivotal activity

Individuals, businesses, and governments increasingly rely on software for strategic and tactical decision
making as well as day-to-day operations and control. If the software fails, people and major enterprises can
experience anything from minor inconvenience to catastrophic failures.

 Software should exhibit high quality

The users of software might grow in number as its time-in-use increase, demands for adaptation and
enhancement also grow.

 Software should be maintainable

These simple realities lead to one conclusion: software in all of its forms and across all of its application
domains should be engineered. That leads to the need of software engineering.
CHAPITER 2 – SOFTWARE DEVELOPMENT LIFE CYCLE

2.1 Introduction

For a system development project to be successful, the people developing the system must have a detailed plan
to follow. One of the key, fundamental concepts in information system development is the systems
development life cycle (SDLC).

Definition:

Software Development Life Cycle, SDLC for short, is a well-defined, structured sequence of stages in software
engineering to develop the intended software product.

During the life of an information system, it is first conceived as an idea; then it is designed, built, and
deployed during a development project; and finally it is put into production and used to support the business.

2.2 SDLC phases and objectives

↔ The development of a new information system requires several different, but related, activities.
↔ They are the elements that provide the framework for managing the project
↔ These activities are grouped into SDLC phases.
2.3 Activities in each phase of SDLC

 Activities undertaken during Planning phase:

Project planning is the initial phase of the SDLC, whose objective is to identify the scope of the new system and
plan the project.

Five activities in project planning:

 Define the problem

 Produce the project schedule

 Confirm project feasibility

 Staff the project

 Launch the project

The main activity in project planning is conducting the 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 behaviour 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.

 Activities undertaken during requirements analysis and specification phase:

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 (is the core activity for discovery and understanding).
  Define system requirements.
 Build prototypes for more discovery of requirements
 Prioritize requirements.
 Generate and evaluate alternatives.
 Review recommendations with management
 Requirements specifications
↔ 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.
↔ After all ambiguities, inconsistencies, and incompleteness have been resolved and all the requirements
properly understood through Requirements analysis, the requirements specification activity can start.
During this activity, the user requirements are systematically organized into a Software Requirements
Specification (SRS) document.

2.3.1 Requirements gathering techniques

The analysts obtain information about the problem domain by:

1. Observing the users as they do their work;

2. Interviewing and asking questions of the users
3. Reading existing documents about procedures, business rules, and job responsibilities; and
4. Reviewing existing automated systems.

The analysts should also consult other interested parties such as; middle management, senior executives, and at
times even external customers

 System analyst:

A system analyst is a business professional who uses analysis and design techniques to solve business problems
using information technology.

 Activities undertaken during design phase:

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.
Major activities during the design phase:

 Design and integrate the network.

 Design the application architecture.

 Design the user interfaces.

 Design the system interfaces.

 Design and integrate the database.

 Prototype for design details.

Two distinctly different approaches in design are available:

1. The traditional design approach (also known as structured design) and

2. The object-oriented design approach
1. 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.
2. 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.

Activities undertaken during implementation phase:

The purpose of the implementation phase of software development is to translate the software design into
source code.

↔ The activities of the SDLC during which the new system is programmed and installed.
↔ 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

Five major activities make up the implementation phase:

 Construct software components.

 Verify and test.

 Install the system.

 Train users and document the system.

 Activities undertaken during maintenance:

↔ This phase confirms the software operation in terms of more efficiency and less errors.
↔ If required, the users are trained on, or aided with the documentation on how to operate the software and
how to keep the software operational.
↔ The software is maintained timely by updating the code according to the changes taking place in user
end environment or technology.

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.

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.
2.4 SDLC models

↔ 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.
↔ Different life cycle models may map the basic development activities to phases in different ways.
↔ 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.

For example, the design phase might consist of the structured analysis activity followed by the structured design
activity.

2.5 The need for software life cycle model

The development team must identify a suitable life cycle model for the particular project and then adhere to it.
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.

↔ Without using of a particular life cycle model the development of a software product would not be in a
systematic and disciplined manner.
↔ Without software life cycle models it becomes difficult for software project managers to monitor the
progress of the project.

2.6 Predictive vs. Adaptive approaches to the SDLC models

SDLC models are classified based on these two approaches.

 A predictive approach:

An SDLC approach that assumes the development project can be planned and organized in advance and
that the new information system can be developed according to the plan.

↔ Predictive SDLCs are useful for building systems that are well understood and defined.

 An adaptive approach:

An SDLC approach that is more flexible, assuming that the project cannot be planned out completely in
advance but must be modified as it progresses
2.7 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:

o Classical Waterfall model

o Spiral model
o Iterative model
o Prototyping model
o Incremental model

Classical waterfall model

↔ It is the most predictive model

↔ Waterfall model is the simplest model of software development life cycle models.
↔ This model assumes that the various phases of a project can be carried out and completed entirely
sequentially.
↔ That is, when the first phase is finished then only the second phase will start and so on.
↔ Example: A detailed plan is first developed, then the requirements are thoroughly specified, then the
system is designed down to the last algorithm, then it is programmed, tested, and installed.

Classical waterfall model divides the life cycle into the following phases:

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.
↔ 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.

2.7 Phase-entry and phase-exit criteria of each phase

 At the starting of the feasibility study, project managers or team leaders try to understand what the actual
problem is by visiting the client side. At the end of that phase they pick the best solution and determine
whether the solution is feasible financially and technically.
 At the starting of requirements analysis and specification phase the required data is collected. After that
requirement specification is carried out. Finally, SRS document is produced.
 At the starting of design phase, context diagram and different levels of DFDs are produced according to
the SRS document. At the end of this phase module structure (structure chart) is produced.
 During the coding phase each module (independently compilation unit) of the design is coded. Then
each module is tested independently as a stand-alone unit and debugged separately. After this each
module is documented individually. The end product of the implementation phase is a set of program
modules that have been tested individually but not tested together.
 After the implementation phase, different modules which have been tested individually are integrated in
a planned manner. After all the modules have been successfully integrated and tested, system testing is
carried out.
 Software maintenance denotes any changes made to a software product after it has been delivered to the
customer. Maintenance is inevitable for almost any kind of product. However, most products need
maintenance due to the wear and tear caused by use.

2.7 Methodologies, models, tools, and techniques

Introduction

Systems analysts have a variety of aids to help them complete activities and tasks in the SDLC.

Among them are methodologies, models, tools, and techniques.

2.7.1 Methodologies

↔ System development methodology

Comprehensive guidelines to follow for completing every activity in the systems development life cycle,
including specific models, tools, and techniques.
↔ Some methodologies are home-grown, developed by systems professionals in the company based on
their experience. Some methodologies are purchased from consulting firms or other vendors.
↔ Some methodologies (whether home-grown or purchased) contain written documentation
↔ The documentation defines everything the developers might need to produce at any point in the project,
including how documentation should look and what reports to management should contain.
↔ The methodology used by the organization determines how prescriptive or adaptive the approach to a
system development project should be.

2.7.2 Models

Model

↔ A representation of an important aspect of the real world

↔ Models used in system development include representations of inputs, outputs, processes, data, objects,
object interactions, locations, networks, and devices, among other things.
↔ Most of the models are graphical models, which are drawn representations that employ agreed-upon
symbols and conventions.
↔ These are often called diagrams and charts.

Example of some models of system component

 Flowchart
 Data flow diagram (DFD)
 Entity-relationship diagram (ERD)
 Structure chart
 Use case diagram
 Class diagram
 Sequence diagram

Some models used to manage the development process

 Gantt chart
 Organizational hierarchy chart
 Financial analysis models – NPV, ROI
2.7.3 Tools

↔ A tool in the context of system development is software support that helps create models or other
components required in the project.

Some tools used in system development:

 Project management application (e.g. Microsoft project)

 Drawing/graphics application (EDRAW, SMARTDRAW)
 Word processor/text editor (MS WORLD, NOTEPAD)
 Visual modelling tool
 Integrated development environment (IDE)
 Database management application (MS ACCESS, SQL)
 Reverse-engineering tool
 Code generator tool

2.7.4 Techniques

↔ A technique in system development is a collection of guidelines that help an analyst complete a system
development activity or task.
↔ A technique often includes step-by-step instructions for creating a model, or it might include more
general advice for collecting information from system users.

Some techniques used in system development:

 Strategic planning techniques

 Project management techniques
 User interviewing techniques
 Data-modelling techniques
 Relational database design techniques
 Structured analysis and design techniques
 Structured programming technique
 Software-testing techniques
 Object-oriented analysis and design techniques
CHAPTER 3 – REQUIREMENT ANALYSIS AND SPECIFICATION

3.1 Introduction

↔ The requirements for a system are the descriptions of the services provided by the system and its
operational constraints.
↔ These requirements reflect the needs of customers for a system that helps solve some problem such as
controlling a device, placing an order or finding information.

The process of finding out, analysing, documenting and checking these services and constraints is called
requirements engineering (RE).

3.2 The need for requirement analysis

↔ If a company wishes to let a contract for a large software development project, it must define its needs in
a sufficiently abstract way.
↔ The requirements must be written so that several contractors can bid for the contract, offering, perhaps,
different ways of meeting the client organisation’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. [Davis, 1993]

3.3 Role of a system analyst

↔ The analyst starts requirements gathering and analysis activity by collecting all information from the
customer which could be used to develop the requirements of the system.
↔ He then analyzes the collected information to obtain a clear and thorough understanding of the product
to be developed, with a view to removing all ambiguities and inconsistencies from the initial customer
perception of the problem.

The following basic questions pertaining to the project should be clearly understood by the analyst in order to
obtain a good grasp of the problem:

 What is the problem? [Problem statement]

 Why is it important to solve the problem? [The objectives]
 What are the possible solutions to the problem? [Feasibility study ]
 What exactly are the data input to the system and what exactly are the data output by the system?
[The scope of the system]
  What are the likely complexities that might arise while solving the problem? [Analysis of the
system]
 If there are external software or hardware with which the developed software has to interface,
then what exactly would the data interchange formats with the external system be? [Analysis &
Design of the system]
↔ After the analyst has understood the exact customer requirements, he proceeds to identify and resolve
the various requirements problems [implementation of the system].
↔ The most important requirements problems that the analyst has to identify and eliminate are the
problems of anomalies, inconsistencies, and incompleteness.
↔ When the analyst detects any inconsistencies, anomalies or incompleteness in the gathered requirements,
he resolves them by carrying out further discussions with the end users and the customers.

3.4 Types of requirements

Requirements can be distinguished as follows:

 User requirements - To mean the high-level abstract requirements and

 System requirements - To mean the detailed description of what the system should do.
 Software requirements - A detailed software description which can serve as a basis for a design
or implementation. Written for developers

User requirements and system requirements may be defined in more detail:

 User requirement:

Are statements, in a natural language plus diagrams, of what services the system is expected to provide and the
constraints under which it must operate.

 System requirements:

Set out the system’s functions, services and operational constraints in detail. The system requirements document
(sometimes called a functional specification) should be precise. It should define exactly what is to be
implemented. It may be part of the contract between the system buyer and the software developers.

↔ Different levels of system specification are useful because they communicate information about the
system to different types of readers.
↔ You need to write requirements at different levels of detail because different types
of readers use them in different ways.
3.5 Types of readers for the user and system requirements

 The readers of the user requirements are not usually concerned with how the system will be
implemented.

 The readers of the system requirements need to know more precisely what the system will do because
they are concerned with how it will support the business processes or because they are involved in the

system implementation.

3.6 Functional and non-functional requirements

Software system requirements are often classified as functional requirements or non-functional requirements

3.6.1 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.
↔ The system is considered to perform a set of high-level functions { fi}.
↔ Each function fi of the system can be considered as a transformation of a set of input data (ii) to the
corresponding set of output data (oi).
↔ The user can get some meaningful piece of work done using a high-level function.

The functional view of the system is shown below:

View of a system performing a set of functions

3.6.2 Non-functional requirements:

↔ Non-functional requirements deal with the characteristics of the system which cannot be expressed
as functions - such as the maintainability of the system, portability of the system, usability of the
system, etc.
↔ Non-functional requirements may include:
# reliability issues,
# Accuracy of results,
# Human - computer interface issues,
# Constraints on the system implementation, etc

Types of non-functional requirements

3.7 Properties of a good SRS document

1. Completeness - Means that all services required by the user should be defined.
2. Consistency - Means that requirements should not have contradictory definitions.
3. Structure - It should be well-structured.
 A well-structured document is easy to understand and modify. In practice, the SRS document
undergoes several revisions to cope up with the customer requirements. Often, the customer
requirements evolve over a period of time. Therefore, in order to make the modifications to the
SRS document easy, it is important to make the document well-structured
4. Black-box view - It should only specify what the system should do and refrain from stating how to do
these.
 This means that the SRS document should specify the external behaviour of the system and not
discuss the implementation issues. The SRS document should view the system to be developed
 as black box, and should specify the externally visible behaviour of the system. For this reason,
the SRS document is also called the black-box specification of a system.
5. Conceptual integrity - It should show conceptual integrity so that the reader can easily understand it.
6. Verifiable - This means that it should be possible to determine whether or not requirements have been
met in an implementation.
CHAPTER 4 – SOFTWARE DESIGN

3.1 Introduction

Software design deals with transforming the customer requirements, as described in the SRS document, into a
form (a set of documents) that is suitable for implementation in a programming language.

3.2 Design activities

Design activities can be broadly classified into two important parts:

 Preliminary (or high-level) design and

 Detailed design.

High-level design: - High-level design means identification of different modules and the control relationships
among them and the definition of the interfaces among these modules. The outcome of high-level design is
called the program structure or software architecture.

Detailed design: - During detailed design, the data structure and the algorithms of the different modules are
designed.

3.3 Characteristics of a good software design

Most researchers and software engineers agree on a few desirable characteristics that every good software
design for general application must possess.

The characteristics are listed below:

1. Correctness: A good design should correctly implement all the functionalities identified in the SRS
document.
2. Understand ability: A good design is easily understandable.
3. Efficiency: It should be efficient.
4. Maintainability: It should be easily amenable to change

3.4 Design approaches to system development

↔ Sometimes it seems every company that develops information systems has its own methodology
↔ Sometimes different development groups within the same company use different methodologies, and
each person in the company might have his own way of developing systems.
↔ Every development group uses models, tools, and techniques that make up an overall system
development methodology
However, all system developers should be familiar with two very general approaches to system development,
because they form the basis of virtually all methodologies:

1. The traditional approach (structured system development) and

2. The object-oriented approach.

3.4.1. Structured System Development

This approach uses three techniques:

1. Structured analysis,
2. Structured design, and
3. Structured programming

Sometimes these techniques are collectively referred to as the structured analysis and design technique (SADT).

1. Structured analysis

↔ Structured analysis is used to carry out the top-down decomposition of a set of high-level functions
depicted in the problem description and to represent them graphically.
↔ During structured analysis, functional decomposition of the system is achieved. That is, each function
that the system performs is analyzed and hierarchically decomposed into more detailed functions.

Structured analysis technique is based on the following essential underlying principles:

 Top-down decomposition approach.

 Divide and conquer principle. Each function is decomposed independently.
 Graphical representation of the analysis results using Data Flow Diagrams (DFDs)
 Data Flow Diagram (DFD)

The DFD is a hierarchical graphical model of a system that shows the different processing activities or
functions that the system performs and the data interchange among these functions. Each function is considered
as a processing station (or process) that consumes some input data and produces some output data. The system
is represented in terms of the input data to the system, various processing carried out on these data, and the
output data generated by the system.
  Data Flow Diagram symbols

An example of a DFD showing the process Look up item availability

 DFD level of abstraction

Level of abstraction breaks the system into a hierarchical set of increasingly more detailed models

Data flow diagrams can show either higher-level or lower-level views of the system.

The high-level processes on one DFD can be decomposed into separate lower-level, detailed DFDs.

Processes on the detailed DFDs can also be decomposed into additional diagrams to provide multiple levels of
abstraction.

Context Diagram

A context diagram is a DFD that describes the most abstract view of a system. All external agents and all data
flows into and out of the system are shown in one diagram, with the entire system represented as one process.
 ↔ The context diagram does not usually show data stores because all of the system’s data stores are
considered to be within the system scope (that is, part of the internal implementation of the process that
represents the system).
↔ However, data stores may be shown when they are shared by the system being modeled and another
system or in the later abstraction levels as shown in the graphics below.

Real world example of simple university course registration system

External agents:

1. Academic department,
2. Student, and
3. Faculty member
↔ The topmost DFD in the figure below is a context diagram for a simple university course registration
system that interacts with three external agents: Academic department, Student, and Faculty member.
↔ Academic departments supply information on offered courses, students request enrollment in offered
courses, and faculty members receive class lists when the registration period is complete.
2. Structured design

↔ As information systems continued to become increasingly complex through the 1970s, each system
involved many different functions.
↔ Each function performed by the system might be made up of dozens of separate programs.

The structured design is technique developed to provide some guidelines for deciding what the set of programs
should be, what each program should accomplish, and how the programs should be organized into a hierarchy.

Structured chart

A graphical model showing the hierarchy of program modules produced by the structured design technique

Some principles of structured design

There are two main principles of structured design:

Program modules should be designed:

 1. Loosely coupled

Loosely coupled means each module is as independent of the other modules as possible, which allows each
module to be designed and later modified without interfering with the performance of the other modules.

2. Highly cohesive

Highly cohesive means each module accomplishes one clear task. That way, it is easier to understand what
each module does and to ensure that if changes to the module are required, none will accidentally affect
other modules.

↔ With structured programming, quality is defined in terms of how easily the design can be understood
and modified later when the need arises.
↔ Structured design assumes the designer knows what the system needs to do i.e. what the main system
functions are, what the required data are, and what the needed outputs are.

Other design works:

 File and database design

 User-interface design

Object-oriented design

↔ In the object-oriented design approach, the system is viewed as collection of objects (i.e. entities). The
state is decentralized among the objects and each object manages its own state information.

For example, in a Library Automation Software, each library member may be a separate object with its own
data and functions to operate on these data. In fact, the functions defined for one object cannot refer or change
data of other objects. Objects have their own internal data which define their state. Similar objects constitute a
class. In other words, each object is a member of some class. Classes may inherit features from super class.
Conceptually, objects communicate by message passing
CHAPTER 5 – IMPLEMENTATION

4.1 Structured Programming

The structured programming technique, developed in the 1960s, was the first attempt to provide guidelines to
improve the quality of computer programs.

Structured programming uses two concepts:

1. Basic principles of structured programming:

A structured program is program or module that has one beginning and one ending, and each step in the
program execution consists of one of three programming constructs.

The rules of structured programming:

1. One beginning
2. One ending and

Three programming constructs

1. Sequence of program statements

2. Decision where one set of statements or another set of statements executes
3. Repetition of a set of statements

The figure below shows an example of a structured programming using three constructs

2. Top-down programming

↔ Divides more complex programs into a hierarchy of program modules

↔ The programmer writes each program module using the rules of structured programming.
 ↔ One module at the top of the hierarchy controls program execution by “calling” lower-level modules as
required.

4.2 Object-oriented programming (OOP)

OOP consists of writing statements in a programming language to define what each type of object does each
type of object does, including the messages that the objects send to each other

4.3 Testing

↔ Errors may ruin the software from critical level to its own removal.
Software testing is done while coding by the developers and thorough testing is conducted by testing
experts at various levels of code such as module testing, program testing, product testing, in-house
testing, and testing the product at user’s end.
↔ Early discovery of errors and their remedy is the key to reliable software.

4.4 Integration

Software may need to be integrated with the libraries, databases, and other program(s).

This stage of SDLC is involved in the integration of software with outer world entities.