Software Engineering: Engineering approach to develop software.

The early programmers used an exploratory (also called build and fix) style. In
this style, normally a `dirty' program is quickly developed. The different
imperfections that are subsequently noticed are fixed.
Drawback: Can successfully be used for very small programs only.

Besides the exponential growth of effort, cost, and time with problem size:
a) It results in unmaintainable code.
b) It becomes very difficult to use it in a team development environment.

Item:
An item is any set of related information. Each item normally occupies one place in
memory. When you are able to relate several different items together (chunking):
The information that should normally occupy several places can be stored using only
one place in the memory. e.g.,
110010101001 = octal form of 6251 ((110)(010)(101)(001))
You have managed to create chunks of three items each.

Principles Deployed by Software Engineering to Overcome Human

1) Abstraction: Simplify a problem by omitting unnecessary details. Focus attention
on only one aspect of the problem and ignore irrelevant details. e.g., A map is an
abstract representation of a country.

2) Decomposition: Decompose a problem into many small independent parts.

– The small parts are then taken up one by one and solved separately.
– The idea is that each small part would be easy to grasp and can be easily solved.
– The full problem is solved when all the parts are solved.

Software products:
– Fail to meet user requirements.
– Frequently crash.
– Expensive.
– Difficult to alter, debug, and enhance.
– Often delivered late.
– Use resources non-optimally.

Programs | Software Products

--------------------------------------------------------------------------
● Usually small in size | ● Large
● Author himself is sole user | ● Large number of users
● Single developer | ● Team of developers
● Lacks proper user interface | ● Well-designed interface
● Lacks proper documentation | ● Well documented & user-manual prepared
● Ad hoc development | ● Systematic development

Requirements Analysis and Specification: Consists of two distinct activities.

● Requirements Analysis: Requirements Gathering and Analysis
● Specification

The person who undertakes requirements analysis and specification: Systems analyst
– Collects data pertaining to the product
– Analyses collected data to understand what exactly needs to be done.
– Writes the Software Requirements Specification (SRS) document.

Requirements Gathering Activities

1. Studying the existing documentation
2. Interview
3. Task analysis
4. Scenario analysis
5. Form analysis

Inconsistent Requirement: Some part of the requirement contradicts with some other
part.
● Example in Chemistry Lab: One customer says turn off heater and open water shower
when temperature > 100 C
Another customer says turn off heater and turn ON cooler when temperature > 100 C

Incomplete Requirement: Some requirements have been omitted possibly due to

oversight.
Example: The analyst has not recorded when temperature falls below 90 C
● heater should be turned ON
● water shower turned OFF.

SRS: Advantages:
– Statement of user needs
– Contract document
– Reference document
– Definition for implementation

The SRS document is known as black-box specification.

– The system is considered as a black box whose internal details are not known.
– Only its visible external (i.e. input/output) behavior is documented.

Properties:
● It should be concise and at the same time should not be ambiguous(should not have
multiple meanings)
● It should specify what the system must do and not say how to do it.
● Easy to change i.e. it should be well-structured.
● consistent
● complete
● It should be traceable (which part of the specification corresponds to which part
of the design, code, etc and vice versa.)
● It should be verifiable

Software life cycle: Series of identifiable stages that a software product

undergoes during its life time.
● Feasibility study: determine whether developing the product is financially
worthwhile and technically feasible.
● Requirements analysis and specification: understand the exact requirements of the
customer and document them properly.
● Design: In technical terms, during design phase, software architecture is derived
from the SRS document.
Two design approaches:

– traditional approach: Consists of two activities:

a) Structured analysis: ● Identify all the functions to be performed.
● Identify data flow among the functions.
● Decompose each function recursively into sub-functions and identify data
flow among the subfunctions as well.
● Carried out using Data flow diagrams (DFDs).

b) Structured design: ● High-level design:

– decompose the system into modules,
– represent invocation relationships among the modules.

● Detailed design: different modules designed in greater

detail (data structures and algorithms for each module are designed)
– object oriented approach: First identify various objects (real world entities)
occurring in the problem and then identify the relationships among the objects.
● OOD has several advantages:
– lower development effort,
– lower development time,
– better maintainability.

● Coding + ● Testing : implementation phase (aka coding and unit testing phase)
translates software design into
source code.

● Maintenance: – requires much more effort than the effort to develop the product
itself.
– development effort to maintenance effort is typically 40:60.

● Corrective maintenance: Correct errors which were not discovered during the
product development phases.
● Perfective maintenance: Improve implementation of the system ; enhance
functionalities of the system.
● Adaptive maintenance: Port software to a new environment, e.g. to a new computer
or to a new operating system.

Life Cycle Model:

– defines entry and exit criteria for every phase.
– A phase is considered to be complete only when all its exit criteria are
satisfied.

Classical Waterfall Model:

Feasibility Study, Req. Analysis, Design, Coding, Testing, Maintenance.

Iterative Waterfall Model:

● Errors should be detected in the same phase in which they are introduced.
● The principle of detecting errors as close to its point of introduction as
possible is known as phase containment of errors.
● It is by far the most widely used model (Almost every other model is derived from
it)

Prototyping Model:
● Before starting actual development, a working prototype of the system should
first be built.
● A prototype is a toy implementation of a system:
– limited functional capabilities,
– low reliability,
– inefficient performance.

Evolutionary Model: aka successive versions model; The system is broken down into
several modules which can be incrementally implemented and delivered.
Advantages:
● Users get a chance to experiment with a partially developed system:
● Helps finding exact user requirements
● Core modules get tested thoroughly

Disadvantages:
● Often, difficult to subdivide problems into functional units which can be
incrementally implemented
and delivered.
Spiral Model:
● Each loop of the spiral represents a phase of the software process:
– the innermost loop might be concerned with system feasibility,
– the next loop with system requirements definition,
– the next one with system design, and so on.
● There are no fixed phases in this model, the phases shown in the figure are just
examples.
● Each loop in the spiral is split into four sectors (quadrants) - Determine
Objectives, Resolve Risks, Develop Next Level of Product, Customer Evaluation of
Prototype

Spiral Model as a meta model: Subsumes all discussed models.

– a single loop spiral represents waterfall model.
– uses an evolutionary approach: iterations through the spiral are evolutionary
levels.
– enables understanding and reacting to risks during each iteration along the
spiral.
– uses:
● prototyping as a risk reduction mechanism
● retains the step-wise approach of the waterfall model.

Decision trees:
– Edges of a decision tree represent conditions
– Leaf nodes represent actions to be performed.
- A decision tree gives a graphic view of: Logic involved in decision making ;
Corresponding actions taken.

Decision Table:
● A decision table shows Processing logic and corresponding actions in a tabular
form
● Upper rows of the table specify: The variables or conditions to be evaluated
● Lower rows specify: The actions to be taken when the corresponding conditions are
satisfied.

Modularity: Modularity is a fundamental attributes of any good design.

Decomposition of a problem cleanly into modules: Modules are almost independent of
each other; Divide and conquer principle.

Layered Design: Neat arrangement of modules in a hierarchy means: Low fan-out;

Control abstraction

Cohesion: It is a measure of functional strength of a module. A cohesive module

performs a single task or function.

Coincidental Cohesion:
● The module performs a set of tasks Which relate to each other very loosely, if at
all.
● The module contains a random collection of functions.
● Functions have been put in the module out of pure coincidence without any thought
or design.

Logical Cohesion:
● All elements of the module perform similar operations: e.g. error handling, data
input, data output, etc.
● An example: A set of print functions to generate an output report arranged into a
single module.

Temporal Cohesion:
● The module contains tasks that are related by the fact that All the tasks must be
executed in the same time span.
● Example: The set of functions responsible for initialization; start-up, shut-down
of some process, etc.

Procedural Cohesion:
● The set of functions of the module:
– All part of a procedure (algorithm)
– Certain sequence of steps have to be carried out in a certain order for achieving
an objective,
● e.g. the algorithm for decoding a message.

Communicational Cohesion:
● All functions of the module: Reference or update the same data structure,
● Example: The set of functions defined on an array or a stack.

Sequential Cohesion:
● Elements of a module form different parts of a sequence,
– Output from one element of the sequence is input to the next.
– Example: sort -> search -> display

Functional Cohesion:
● Different elements of a module cooperate:
– To achieve a single function,
– e.g. managing an employee's pay-roll.
● When a module displays functional cohesion, We can describe the function using a
single sentence.

Coupling: A measure of the degree of the interdependence or interaction between the

two modules.

Data coupling:
● Two modules are data coupled,
– If they communicate via a parameter: an elementary data item; e.g an integer, a
float, a character, etc.
– The data item should be problem related and Not used for control purpose.

Stamp Coupling:
● Two modules are stamp coupled – If they communicate via a composite data item
such as a record in PASCAL or a structure in C.

Control Coupling:
● Data from one module is used to direct the Order of instruction execution in
another.
● Example: A flag set in one module and tested in another module.

Common Coupling:
● Two modules are common coupled, If they share some global data.

Content Coupling:
● Content coupling exists between two modules: If they share code- e.g, branching
from one module into another module.
● The degree of coupling increases from data coupling to content coupling.

DFD: It is a hierarchical graphical model.

– Shows the different functions (or processes) of the system
– Data interchange among the processes.
– Uses limited types of symbols.
– Simple set of rules
– Easy to understand
Synchronous Operation: If two bubbles are directly connected by a data flow arrow,
They are synchronous.
Asynchronous Operation: If two bubbles are connected via a data store, They are not
synchronous.

Context Diagram: A context diagram shows:

–Data input to the system,
–Output data generated by the system,
–External entities.

Context diagram captures:

– Various entities external to the system and interacting with it.
– Data flow occurring between the system and the external entities.

The context diagram is also called as the level 0 DFD.

Level 1 DFD: Examine the SRS document

– Represent each high-level function as a bubble.
– Represent data input to every high-level function.
– Represent data output from every high-level function.

Data Dictionary: A DFD is always accompanied by a data dictionary. A data

dictionary lists all data items appearing in a DFD:
– Definition of all composite data items in terms of their component data items.
– All data names along with the purpose of the data items.
For example, a data dictionary entry may be: – grossPay = regularPay+overtimePay

Data Definition:
● +: denotes composition of data items, e.g – a+b represents data a and b.
● [,,,]: represents selection,– i.e. any one of the data items listed inside the
square bracket can occur.For example, [a,b] represents either a occurs or b
occurs.
● ( ): contents inside the bracket represent optional data which may or may not
appear. a+(b) represents either a 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 * * is considered as comment.