The Federal Polytechnic, Bauchi

COM 324
Intro. To Software Engineering
1.1 Definitions
Software is considered to Engineering on the other
be a collection of hand, is all about
executable programming developing products,
code, associated libraries using well-defined,
and documentations . scientific principles and
Software, when made for methods.
a specific requirement is
called software product.
engineering as an IEEE defines software
engineering branch engineering as:
associated with the The application of a
development of software systematic, disciplined,
product using well- quantifiable approach to
defined scientific the development,
principles, methods and operation and
procedures. The outcome maintenance of software.
of software engineering is
an efficient and reliable
software product.
The need of software CHARACTERESTICS OF
engineering arises GOOD SOFTWARE
because of higher rate of
change in user
• Operational
requirements and
environment on which the
software is working. • Transitional
• Large software
• Scalability • Maintenance
• Cost
• Dynamic Nature
• Quality Management
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
1.2 Software Development
Life Cycle (SDLC)
A life cycle model a life cycle model maps
represents all the the different activities
activities required to performed on a
make a software software product from
product transit its inception to
through its life cycle retirement.
phases.
THE NEED FOR A SDLC
software life cycle
•Tram may need to models
select one & adhere to • Classical Waterfall
it Model
•Clear understanding • Iterative Waterfall
of what and when to Model
do • Prototyping Model
•It enhances division of • Evolutionary Model
labour • Spiral Model
•It makes the software
development
systematic
ITERATIVE WATERFALL MODEL
Prototype Model
EVOLUTIONARY MODEL
SPIRAL MODEL
 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.
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.
The iterative waterfall model is probably the most
widely used software development model evolved
so far.
 Comparison of different life-cycle
models
The prototyping model is suitable for projects for
which either the user requirements or the
underlying technical aspects are not well
understood.
The evolutionary approach is suitable for large
problems which can be decomposed into a set of
modules for incremental development and delivery.
The spiral model is called a meta model since it
encompasses all other life cycle models.
 Comparison of different life-cycle
models
The different software life cycle models can be
compared from the viewpoint of the customer.
Another important advantage of the
incremental model is that it reduces the
customer’s trauma of getting used to an entirely
new system.
2.1 REQUIREMENTS ANALYSIS
AND SPECIFICATION
Before we start to The important parts of
develop our software, SRS document are:
it becomes quite 1. Functional
essential for us to requirements of the
understand and system
document the exact 2. Non-functional
requirement of the requirements of the
customer. The person system, and
who does this is called 3. Goals of
system analyst. implementation
Functional requirements:-

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

Project 2.1.1
 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.

Project 2.1.2
 Goals of implementation
The goals of implementation section might
document issues such as revisions to the system
functionalities that may be required in the
future, new devices to be supported in the
future, reusability issues, etc. These are the
items which the developers might keep in their
mind during development so that the developed
system may meet some aspects that are not
required immediately.
Project 2.1.3
2.2 Identifying functional
requirements
Example: Consider the the function Search
case of the library Book (F1) takes the
system, where – author's name and
F1: Search Book function transforms it into book
Input: an author’s name details.
Output: details of the
author’s books and the
location of these books
in the library
Functional requirements actually describe a set
of high-level requirements, where each high-
level requirement takes some data from the user
and provides some data to the user as an
output. Also each high-level requirement might
consist of several other functions.
2.3 Documenting functional
requirements
Example: - Withdraw Cash from ATM
R1: withdraw cash
Description: The withdraw cash function first
determines the type of account that the user
has and the account number from which the
user wishes to withdraw cash. It checks the
balance to determine whether the requested
amount is available in the account. If enough
balance is available, it outputs the required
cash; otherwise it generates an error message.
R1.1 select withdraw amount option
Input: “withdraw amount” option
Output: user prompted to enter the account type
R1.2: select account type
Input: user option
Output: prompt to enter amount
R1.3: get required amount
Input: amount to be withdrawn in integer values greater
than 100 and less than 10,000 in multiples of 100.
Output: The requested cash and printed transaction
statement.
Processing: the amount is debited from the user’s
account if sufficient balance is available, otherwise an
error message displayed
Project 2.3.1
2.4 Properties of a good SRS
document
1. Concise.
2. Structured.
3. Black-box view.
4. Conceptual integrity.
5. Response to
undesired events.
6. Verifiable.
Problems without a SRS document
The important problems that an organization would face if it
does not develop a SRS document are as follows:
1. Without developing the SRS document, the system would
not be implemented according to customer needs.
2. Software developers would not know whether what they are
developing is what exactly required by the customer.
3. Without SRS document, it will be very much difficult for the
maintenance engineers to understand the functionality of
the system.
4. It will be very much difficult for user document writers to
write the users’ manuals properly without understanding the
SRS document.
 Problems with an unstructured
specification
1. It would be very much difficult to understand
that document.
2. It would be very much difficult to modify that
document.
3. Conceptual integrity in that document would
not be shown.
4. The SRS document might be unambiguous
and inconsistent.
 3.1 Decision Tree
A decision tree gives a Example: -
graphic view of the Consider Library
processing logic involved in Membership Automation
decision making and the Software (LMS) where it
corresponding actions should support the
taken. The edges of a following three options:
decision tree represent 1. New member
conditions and the leaf 2. Renewal
nodes represent the 3. Cancel membership
actions to be performed
depending on the outcome
of testing the condition
New member option-
Decision: When the 'new member' option is selected, the
software asks details about the member like the member's
name, address, phone number etc.
Action: If proper information is entered then a membership
record for the member is created and a bill is printed for the
annual membership charge plus the security deposit payable.
Renewal option-
Decision: If the 'renewal' option is chosen, the LMS asks for the
member's name and his membership number to check whether
he is a valid member or not.
Action: If the membership is valid then membership expiry date
is updated and the annual membership bill is printed, otherwise
an error message is displayed.
Cancel membership option-
Decision: If the 'cancel membership' option is selected, then the
software asks for member's name and his membership number.
Action: The membership is cancelled, a cheque for the balance
amount due to the member is printed and finally the
membership record is deleted from the database.
Decision Tree of LMS

Project 3.1.1
 4.1 Decision Table
A decision table is used to Example: -
represent the complex Consider Library
processing logic in a tabular or a Membership Automation
matrix form. The upper rows of
the table specify the variables or
Software (LMS) where it
conditions to be evaluated. The should support the
lower rows of the table specify following three options:
the actions to be taken when 1. New member
the corresponding conditions 2. Renewal
are satisfied. A column in a table 3. Cancel membership
is called a rule. A rule implies
that if a condition is true, then
the corresponding action is to
be executed.
Decision Table of LMS

Project 4.1.1
 SOFTWARE DESIGN
5.1
Software design is a process to Software Design Levels
transform user requirements Software design yields
into some suitable form, which three levels of results:
helps the programmer in
software coding and
1. Architectural Design
implementation. 2. High-level Design-
Modularization 3. Detailed Design
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.
Advantages of modularisation Concurrency
1. Smaller components are In software design, concurrency
easier to maintain is implemented by splitting the
2. Program can be divided software into multiple
based on functional aspects independent units of execution,
3. Desired level of abstraction like modules and executing
ca n be brought in the them in parallel. In other words,
program concurrency provides capability
4. Components with high to the software to execute more
cohesion can be re-used than one part of code in parallel
again. to each other.
5. Concurrent execution can be Cohesion
made possible Cohesion is a measure that
6. Desired from security aspect defines the degree of intra-
dependability within elements
of a module. The greater the
cohesion, the better is the
program design.
Types of Cohesion Coupling
Coupling is a measure that
1. Co-incidental cohesion defines the level of inter-
2. Logical cohesion dependability among modules
3. Temporal Cohesion of a program. It tells at what
4. Procedural cohesion level the modules interfere and
5. Communicational cohesion interact with each other. The
6. Sequential cohesion lower the coupling, the better
7. Functional cohesion the program
There are five levels of coupling, namely –
• Content coupling - When a module can directly access or modify or refer to the
content of another module, it is called content level coupling.

• Common coupling- When multiple modules have read and write access to some
global data, it is called common or global coupling.

• Control coupling- Two modules are called control-coupled if one of them decides
the function of the other module or changes its flow of execution.

• Stamp coupling- When multiple modules share common data structure and work
on different part of it, it is called stamp coupling.

• Data coupling- Data coupling is when two modules interact with each other by
means of passing data (as parameter). If a module passes data structure as
parameter, then the receiving module should use all its components.

Ideally, no coupling is considered to be the best.

 Design Verification
5.2
The output of software design It is then becomes necessary to
process is design verify the output before
documentation, pseudo codes, proceeding to the next phase.
detailed logic diagrams, process The early any mistake is
diagrams, and detailed detected, the better it is or it
description of all functional or might not be detected until
non-functional requirements. testing of the product. If the
The next phase, which is the outputs of design phase are in
implementation of software, formal notation form, then their
depends on all outputs associated tools for verification
mentioned above. should be used otherwise a
thorough design review can be
used for verification and
validation.
 Software Design Strategies
5.3
Software design is a process to Strategies
conceptualize the software 1. Structured Design
requirements into software 2. Function Oriented Design
implementation. Software 3. Object Oriented Design
design takes the user
requirements as challenges and
tries to find optimum solution.
There are multiple variants of
software design.
 Structured Design
5.3.1
Structured design is a
conceptualization of problem into
Cohesion - grouping of all
several well-organized elements functionally related elements.
of solution. It is basically
concerned with the solution Coupling - communication
design. Benefit of structured between different modules.
design is, it gives better
understanding of how the A good structured design has
problem is being solved. high cohesion and low coupling
Structured design is mostly based arrangements.
on ‘divide and conquer’ strategy
where a problem is broken into
several small problems and each
small problem is individually
solved until the whole problem is
solved.
 Function Oriented Design
5.3.2 Design Process
In function-oriented design, the 1. The whole system is seen
system is comprised of many as how data flows in the
smaller sub-systems known as system by means of data
functions. These functions are flow diagram.
capable of performing 2. DFD depicts how functions
significant task in the system. change the data and state of
The system is considered as top entire system.
view of all functions. 3. The entire system is
logically broken down into
smaller units known as
functions on the basis of
their operation in the
system.
4. Each function is then
described at large.
 Object Oriented Design
5.3.3 1. Objects - All entities involved in
Object oriented design works the solution design are known as
around the entities and their objects. For example, person,
banks, company and customers
characteristics instead of
are treated as objects. Every
functions involved in the entity has some attributes
software system. This design associated to it and has some
strategy focuses on entities and methods to perform on the
its characteristics. attributes.
2. Classes - A class is a generalized
description of an object. An object
is an instance of a class. Class
defines all the attributes, which an
object can have and methods,
which defines the functionality of
the object.
3. Encapsulation - In OOD, the attributes Design Process
(data variables) and methods (operation
on the data) are bundled together is
1. A solution design is created
called encapsulation. Encapsulation not from requirement or
only bundles important information of an previous used system and/or
object together, but also restricts access system sequence diagram.
of the data and methods from the outside
world. This is called information hiding.
4. Inheritance - OOD allows similar classes 2. Objects are identified and
to stack up in hierarchical manner where grouped into classes on
the lower or sub-classes can import, behalf of similarity in
implement and re-use allowed variables attribute characteristics.
and methods from their immediate super
classes. This property of OOD is known as
inheritance. This makes it easier to define 3. Class hierarchy and relation
specific class and to create generalized
classes from specific ones.
among them are defined.
5. Polymorphism - OOD languages provide a
mechanism where methods performing 4. Application framework is
similar tasks but vary in arguments, can defined.
be assigned same name. This is called
polymorphism, which allows a single
interface performing tasks for different
types. Depending upon how the function
is invoked, respective portion of the code
gets executed.
Project 5.3.3.1
 SOFTWARE ANALYSIS & DESIGN
6.1 TOOLS Let us see few analysis and
Software analysis and design design tools used by software
includes all activities, which designers :
help the transformation of 1. Data Flow Diagram
requirement specification into 2. Data Dictionary
implementation. The SRS 3. Context Diagram
document is good for human
consumption but not for the
computer system, there is need
to have it converted to a format
suitable for computer. That is
what this section intends to
address.
 Data Flow Diagram (DFD)
6.2 Types of DFD
Data flow diagram is a graphical Data Flow Diagrams are either
representation of data flow in an Logical or Physical.
information system. It is capable 1. Logical DFD – This type of
of depicting incoming data flow, DFD concentrates on the
outgoing data flow and stored system process and flow of
data. The DFD does not mention data in the system. For
anything about how data flows example in a Banking
through the system. software system, how data is
There is a prominent difference moved between different
between DFD and Flowchart. The entities.
flowchart depicts flow of control 2. Physical DFD - This type of
in program modules. DFDs depict DFD shows how the data flow
flow of data in the system at is actually implemented in
various levels. DFD does not the system. It is more specific
contain any control or branch and close to the
elements. implementation.
DFD Components
1. Entities - Entities are source and The main reason why the DFD
destination of information data. Entities
are represented by rectangles with their
technique is so popular is
respective names. probably because of the fact
2. Process - Activities and action taken on
that DFD is a very simple
the data are represented by Circle or formalism – it is simple to
Round-edged rectangles.
understand and use.
3. Data Storage - There are two variants of The data flow diagramming
data storage - it can either be represented
as a rectangle with absence of both technique also follows a very
smaller sides or as an open-sided simple set of intuitive concepts
rectangle with only one side missing.
and rules.
4. Data Flow - Movement of data is shown
by pointed arrows. Data movement is
shown from the base of arrow as its
source towards head of the arrow as
destination.

Project 6.2.1
 Data Dictionary
6.3 For example, a data dictionary
A data dictionary lists all data entry may represent that the
items appearing in the DFD data grossPay consists of the
model of a system. The data components regularPay and
items listed include all data overtimePay.
flows and the contents of all grossPay = regularPay +
data stores appearing on the overtimePay
DFDs in the DFD model of a
system.
A data dictionary lists the
purpose of all data items and
the definition of all composite
data items in terms of their
component data items.
 Symbols in Data Dictionary
• +: denotes composition of two data items, e.g. a+b
represents data a and b.
• [,,]: represents selection, i.e. any one of the data items
listed in the brackets can occur. For example, [a,b]
represents either a occurs or b occurs.
• (): the contents inside the bracket represent optional data
which may or may not appear. e.g. a+(b) represents either a
occurs or a+b occurs.
• {}: represents iterative data definition, e.g. {name}5
represents five name data. {name}* represents zero or
more instances of name data.
• =: represents equivalence, e.g. a=b+c means that a
represents b and c.
• /* */: Anything appearing within /* and */ is considered as
a comment
 Tic Tac Toe Game
Example Tic-Tac-Toe Computer Game
Tic-tac-toe is a computer game in which a human
player and the computer make alternative moves
on a 3×3 square. A move consists of marking
previously unmarked square. The player who first
places three consecutive marks along a straight line
on the square (i.e. along a row, column, or diagonal)
wins the game. As soon as either the human player
or the computer wins, a message congratulating the
winner should be displayed. If neither player
manages to get three consecutive marks along a
straight line, but all the squares on the board are
filled up, then the game is drawn. The computer
always tries to win a game.
Level 0

Level 1
 The Data Dictionary of the Tic Tac Toe Game

Data Dictionary for the DFD model in the above

example
• move: integer /*number between 1 and 9 */
• display: game+result
• game: board
• board: {integer}9
• result: [“computer won”, “human won”
“draw”]

Project 6.3.1
 Context Diagram
6.4
The context diagram is the most To develop the context diagram
abstract data flow of the system, it is required to
representation of a system. It analyze the SRS document to
represents the entire system as identify the different types of
a single bubble. This bubble is users who would be using the
labelled according to the main system and the kinds of data
function of the system. The they would be inputting to the
various external entities with system and the data they would
which the system interacts and be receiving the system. Here,
the data flow occurring the term “users of the system”
between the system and the also includes the external
external entities are also systems which supply data to or
represented. receive data from the system.
 Example: RMS Calculating Software

A software system called

RMS calculating software
would read three integral
numbers from the user in
the range of -1000 and
+1000 and then determine
the root mean square (rms)
of the three input numbers
and display it. In this
example, the context
diagram is simple to draw.
The system accepts three Context Diagram of the System
integers from the user and
returns the result to him.
Project 6.4.1
 STRUCTURED DESIGN
7.1
The aim of structured design is Structure Chart
to transform the results of the A structure chart represents the
structured analysis (i.e. a DFD software architecture, i.e. the
representation) into a structure various modules making up the
chart. Structured design system, the dependency (which
provides two strategies to guide module calls which other
transformation of a DFD into a modules), and the parameters
structure chart. that are passed among the
• Transform analysis different modules. Hence, the
• Transaction analysis structure chart representation
can be easily implemented using
some programming language.
 Structured Chart

The basic building blocks which are used to Structure Chart vs. Flow Chart
design structure charts are the following:
We are all familiar with the flow chart
representation of a program. Flow chart is a
• Rectangular boxes: Represents a module. convenient technique to represent the flow of
control in a program. A structure chart differs
• Module invocation arrows: Control is passed from a flow chart in three principal ways:
from on one module to another module in • It is usually difficult to identify the different
the direction of the connecting arrow. modules of the software from its flow chart
representation.
• Data flow arrows: Arrows are annotated • • Data interchange among different modules
with data name; named data passes from is not represented in a flow chart.
one module to another module in the • • Sequential ordering of tasks inherent in a
direction of the arrow. flow chart is suppressed in a structure chart.

• Library modules: Represented by a rectangle

with double edges.

• Selection: Represented by a diamond

symbol.

• Repetition: Represented by a loop around

the control flow arrow.
 Transform Analysis
7.2
Transform analysis identifies the Structure Chart
primary functional components A structure chart represents the
(modules) and the high level software architecture, i.e. the
inputs and outputs for these various modules making up the
components. The first step in system, the dependency (which
transform analysis is to divide module calls which other
the DFD into 3 types of parts: modules), and the parameters
• Input that are passed among the
• Logical processing different modules. Hence, the
• Output structure chart representation
can be easily implemented using
some programming language.
Structure Chart of the RMS problem

Project 7.2.1
 Transaction Analysis
7.3
A transaction allows the user to For each identified transaction,
perform some meaningful piece trace the input data to the
of work. Transaction analysis is output. All the traversed
useful while designing bubbles belong to the
transaction processing transaction. These bubbles
programs. In a transaction- should be mapped to the same
driven system, one of several module on the structure chart.
possible paths through the DFD In the structure chart, draw a
is traversed depending upon the root module and below this
input data item module draw each identified
transaction a module. Every
transaction carries a tag, which
identifies its type.
 OBJECT MODELLING USING UML
8.1
Unified Modelling Language
Model (UML)
A model captures aspects UML, as the name implies, is a
important for some application modelling language. It may be
while omitting (or abstracting) used to visualize, specify,
the rest. A model in the context construct, and document the
of software development can be artefacts of a software system. It
graphical, textual, provides a set of notations (e.g.
mathematical, or program code- rectangles, lines, ellipses, etc.)
based. Models are very useful in to create a visual model of the
documenting the design and system. Like any other language,
analysis results. UML has its own syntax
(symbols and sentence
formation rules) and semantics
(meanings of symbols and
sentences).
 USE CASE DIAGRAM
8.1.1
Use cases correspond to the
The use case model for any high-level functional
system consists of a set of “use requirements. The use cases
cases”. Intuitively, use cases partition the system behaviour
represent the different ways in into transactions, such that each
which a system can be used by transaction performs some
the users. useful action from the user’s
point of view. To complete each
transaction may involve either a
single message or multiple
message exchanges between
the user and the system to
complete.
Use Case Diagram for Tic Tac Toe
Game

Can you explain this system?

 Use Case Relationship

Includes
The includes relationship
in the older versions of
UML (prior to UML 1.1)
was known as the uses
relationship. The includes
relationship involves one
use case including the
behaviour of another use
case in its sequence of
events and actions.
Extends
The main idea behind the
extends relationship
among the use cases is
that it allows you to show
optional system behaviour.
An optional system
behaviour is extended only
under certain conditions.
The extends relationship is
normally used to capture
alternate paths or
scenarios.

Project 8.1.1.1
 CLASS DIAGRAMS
8.1.2
Classes
class diagram describes the The classes represent entities
static structure of a system. It with common features, i.e.
shows how a system is attributes and operations.
structured rather than how it Classes are represented as solid
behaves. The static structure of outline rectangles with
a system comprises of a number compartments.
of class diagrams and their Attributes
dependencies. The main An attribute is a named
constituents of a class diagram property of a class. It represents
are classes and their the kind of data that an object
relationships: generalization, might contain. Attributes are
aggregation, association, and listed with their names, and
various kinds of dependencies. may optionally contain
specification of their type, an
initial value, and constraints.
Operation Composition
Operation is the implementation of a Composition is a stricter form of
service that can be requested from aggregation, in which the parts are
any object of the class to affect existence-dependent on the whole.
behaviour. An object’s data or state This means that the life of the parts
can be changed by invoking an closely ties to the life of the whole.
operation of the object. A class may When the whole is created, the parts
have any number of operations or no are created and when the whole is
operation at all. destroyed, the parts are destroyed.
Aggregation Association
Aggregation is a special type of Associations are needed to enable
association where the involved objects to communicate with each
classes represent a whole-part other. An association describes a
relationship. The aggregate takes the connection between classes.
responsibility of forwarding
messages to the appropriate parts.
Can you explain the class?

Project 8.1.2.1
 INTERACTION DIAGRAMS
8.1.3
Sequence Diagram
Interaction diagrams are models A sequence diagram shows
that describe how group of interaction among objects as a
objects collaborate to realize two dimensional chart. The
some behaviour. chart is read from top to
Sequence Diagram bottom. The objects
Collaboration Diagram participating in the interaction
are shown at the top of the
chart as boxes attached to a
vertical dashed line. Inside the
box the name of the object is
written with a colon separating
it from the name of the class
and both the name of the object
and the class are underlined.
Project 8.1.3.1
 Collaboration Diagram

A collaboration diagram The behavioural aspect is

shows both structural and described by the set of
behavioural aspects messages exchanged among
explicitly. This is unlike a the different collaborators.
sequence diagram which The link between objects is
shows only the behavioural shown as a solid line and
aspects. The structural can be used to send
aspect of a collaboration messages between two
diagram consists of objects objects. The message is
and the links existing shown as a labelled arrow
between them. In this placed near the link.
diagram, an object is also
called a collaborator.
Project 8.1.3.2
 ACTIVITY AND STATE CHART
8.1.4 DIAGRAM
Activity Diagram
The activity diagram is possibly
one modelling element which
was not present in any of the
predecessors of UML.
The activity diagram focuses on
representing activities or chunks
of processing which may or may
not correspond to the methods
of classes. An activity is a state
with an internal action and one
or more outgoing transitions
which automatically follow the
termination of the internal
activity. Project 8.1.4.1
 State Diagram

STATE CHART DIAGRAM

A state chart diagram is
normally used to model
how the state of an object
changes in its lifetime.
State chart diagrams are
good at describing how
the behaviour of an object
changes across several use
case executions.

Project 8.1.4.2
 CODING
9.1
Contents of the headers
Coding- The objective of the preceding codes for different
coding phase is to transform the modules should have:
design of a system into code in a • Name of the module.
high level language and then to • Date on which the module
unit test this code. The was created.
programmers adhere to • Author’s name.
standard and well defined style • Modification history.
of coding which they call their • Synopsis of the module.
coding standard. • Different functions supported,
A coding standard lists several along with their input/output
rules to be followed during parameters.
coding, such as the way • Global variables
variables are to be named, the accessed/modified by the
way the code is to be laid out, module.
error return conventions, etc.
Code Review Code Walk Throughs
Code review for a model is carried
Code walk through is an informal
out after the module is successfully
compiled and the all the syntax code analysis technique. In this
errors have been eliminated. Code technique, after a module has been
reviews are extremely cost-effective coded, successfully compiled and all
strategies for reduction in coding syntax errors eliminated. A few
errors and to produce high quality members of the development team
code. are given the code few days before
Code Inspection the walk through meeting to read
In contrast to code walk through, the and understand code. Each member
aim of code inspection is to discover
selects some test cases and
some common types of errors
caused due to oversight and simulates execution of the code by
improper programming. In other hand (i.e. trace execution through
words, during code inspection the each statement and function
code is examined for the presence of execution). The main objectives of
certain kinds of errors, in contrast to the walk through are to discover the
the hand simulation of code algorithmic and logical errors in the
execution done in code walk code.
through.
Project 9.1.1
 Software Documentation
When various kinds of software
products are developed then not Different types of software
only the executable files and the documents can broadly be
source code are developed but classified into the following:
also various kinds of documents Internal documentation is the
such as users’ manual, software code comprehension features
requirements specification (SRS) provided as part of the source
documents, design documents, code itself. Internal
test documents, installation documentation is provided
manual, etc are also developed as through appropriate module
part of any software engineering headers and comments
process. embedded in the source code.
External documentation is
provided through various types of
supporting documents such as
users’ manual, software
requirements specification
document, design document, test
documents, etc.

Project 9.1.2
 TESTING
10.1
Verification Vs Validation
Testing a program consists of Verification is the process of
providing the program with a determining whether the output
set of test inputs (or test cases) of one phase of software
and observing if the program development conforms to that
behaves as expected. If the of its previous phase, whereas
program fails to behave as validation is the process of
expected, then the conditions determining whether a fully
under which failure occurs are developed system conforms to
noted for later debugging and its requirements specification.
correction.
Blackbox vs whitebox
Unit vs integration

Project 10.1.1
 SOFTWARE MAINTENANCE
11.1 Types of software maintenance
Software maintenance is There are basically three types of software
becoming an important activity maintenance. These are:
• Corrective: Corrective maintenance of a
of a large number of software software product is necessary to rectify the
organizations. This is no bugs observed while the system is in use.
surprise, given the rate of •Adaptive: A software product might need
maintenance when the customers need
hardware obsolescence, the the product to run on new platforms, on
immortality of a software new operating systems, or when they need
product per se, and the demand the product to interface with new
hardware or software.
of the user community to see •Perfective: A software product needs
the existing software products maintenance to support the new features
run on newer platforms, run in that users want it to support, to change
different functionalities of the system
newer environments, and/or according to customer demands, or to
with enhanced features. enhance the performance of the system.
 SOFTWARE RELIABILITY & QUALITY
12.1
Software Reliability Metrics
Software Reliability •Rate of occurrence of failure
Reliability of a software product (ROCOF)-
essentially denotes its •Mean Time To Failure (MTTF)
trustworthiness or •Mean Time To Repair (MTTR)
dependability. Alternatively, •Mean Time Between Failure
reliability of a software product (MTBR)
can also be defined as the •Probability of Failure on
probability of the product Demand (POFOD)
working “correctly” over a given •Availability
period of time.
• ROCOF measures the • Availability of a system
frequency of is a measure of how
occurrence of likely shall the system
unexpected behaviour be available for use over
(i.e. failures). a given period of time.
• MTTF is the average • MTBF = MTTF + MTTR
time between two • POFOD measures the
successive failures, likelihood of the system
observed over a large failing when a service
number of failures. request is made.
• MTTR measures the
average time it takes to
track errors causing the
failure and to fix them.
A possible classification of failures of software products into five different
types is as follows:

• Transient- Transient failures occur only for certain input values while
invoking a function of the system.

• Permanent- Permanent failures occur for all input values while invoking
a function of the system.

• Recoverable- When recoverable failures occur, the system recovers with

or without operator intervention.

• Unrecoverable- In unrecoverable failures, the system may need to be

restarted.

• Cosmetic- These classes of failures cause only minor irritations, and do

not lead to incorrect results. An example of a cosmetic failure is the case
where the mouse button has to be clicked twice instead of once to
invoke a given function through the graphical user interface.
 Software Quality
Traditionally, a quality Software Quality
product is defined in manifests in the form of:
terms of its fitness of
purpose. That is, a quality • Portability
product does exactly what • Portability
the users want it to do. • Reusability
For software products, • Reusability
fitness of purpose is
• Maintainability
usually interpreted in
terms of satisfaction of
the requirements laid
down in the SRS
document.
 COCOMO
13.1
COCOMO (Constructive Cost
Estimation Model) was
proposed by Boehm [1981].
According to Boehm, software
cost estimation should be done
through three stages: Basic
COCOMO, Intermediate
COCOMO, and Complete
COCOMO.
 Basic COCOMO Model
The basic COCOMO model gives an approximate estimate of
the project parameters. The basic COCOMO estimation model
is given by the following expressions:
• Effort = a1 х (KLOC)a2 PM
• Tdev = b1 x (Effort)b2 Months
Where
• • KLOC is the estimated size of the software product
expressed in Kilo Lines of Code,
• • a1, a2, b1, b2 are constants for each category of software
products,
• • Tdev is the estimated time to develop the software,
expressed in months,
• • Effort is the total effort required to develop the software
product, expressed in person months (PMs).
Assume that the size of an org organic type software
product has been estimated to be 32,000 lines of source
code. Assume that the average salary of software
engineers be NGN. 15,000/- per month. Determine the
effort required to develop the software product and the
nominal development time.
From the basic COCOMO estimation formula for organic
software:
• Effort = 2.4 х (32)1.05 = 91 PM
• Nominal development time = 2.5 х (91)0.38 = 14
months
• Cost required to develop the product = 14 х 15,000
• = NGN. 210,000/-
 Intermediate COCOMO Model
The basic COCOMO model assumes that effort and development
time are functions of the product size alone. However, a host of
other project parameters besides the product size affect the
effort required to develop the product as well as the
development time. Therefore, in order to obtain an accurate
estimation of the effort and project duration, the effect of all
relevant parameters must be taken into account. The
intermediate COCOMO model recognizes this fact and refines
the initial estimate obtained using the basic COCOMO
expressions by using a set of 15 cost drivers (multipliers) based
on various attributes of software development.
 Complete COCOMO Model
A major shortcoming of both the basic and intermediate
COCOMO models is that they consider a software product as a
single homogeneous entity. However, most large systems are
made up several smaller sub-systems. These sub-systems may
have widely different characteristics. For example, some sub-
systems may be considered as organic type, some semidetached,
and some embedded. Not only that the inherent development
complexity of the subsystems may be different, but also for some
subsystems the reliability requirements may be high, for some
the development team might have no previous experience of
similar development, and so on. The complete COCOMO model
considers these differences in characteristics of the subsystems
and estimates the effort and development time as the sum of
the estimates for the individual subsystems.
Abubakar Muhammad

faqeer4sure@gmail.com