Professional Documents
Culture Documents
BRANCH: MCA
SEM:5th
SESSION: 2014-15
Evaluation scheme:
Subject
Code
MCA513
Name of
Subject
Software
Engineering
Periods
L T P
3 1 0
Evaluation Scheme
CT TA TOTAL ESE
30 20
50
100
Subject
Total
150
Credit
4
INDEX
Unit-1
Introduction to Software Engineering
1.1
1.2
1.3
1.4
1.5
1.6
Unit-2
Software Requirement Specifications (SRS)
2.1 Software Requirements
2.2 Requirement Engineering Process
2.1.1
2.1.2
2.1.3
2.1.4
Feasibility Study
Elicitation
Analysis
Documentation,
2.1.4.1 SRS Document
2.1.5 Requirement validation
2.3 Software Quality
Unit-3
Software Design
3.1 Software Design
3.2 Software Design principles
3.3 Architectural design
3.4 Coupling and Cohesion Measures
3.5 Function Oriented Design
3.6 Object Oriented Design, Top Down and Bottom-Up Design
2
Unit-4
Software Testing and Maintenance
4.1 Software Testing
4.2 Levels of Testing:
4.2.1 Unit Testing
4.2.2 Integration Testing
4.2.3 Acceptance Testing
4.3 Top-Down and Bottom-Up Testing
4.4 Functional Testing (Black Box Testing)
4.5 Structural Testing (White Box Testing)
4.6 Mutation Testing
4.7 Performance testing
4.8 Coding
4.8.1 Coding Standards
4.8.2 Coding Guidelines
Unit-5
Software Maintenance and project management
5.1Software Maintenance
5.2 Software RE-Engineering
5.3 Software Reverse engineering
5.4 Software Configuration management (CM)
5.4.1 Functions of SCM
5.4.2 SCM Terminology
5.4.3 SCM Activities
5.5 CASE (Computer aided software engineering)
5.6 Constructive cost model (COCOMO)
5.7 Putnam Resource Model
5.8 Software Risk
2)
3)
4)
5)
Software is not manufactured, but it is developed through the life cycle concept.
Reusability of components
Software is flexible and can be amended to meet new requirements
Cost of its change at if not carried out initially is very high at later stage .
Software
1.Large
3. Single developer
3.Team of developers
4.Well-designed interface
6. Ad hoc development.
6.Systematic development
Software Engineering
Software Programming
1. Single developer
1.Teams of
multiple roles
developers
1. Toy applications
2.Complex systems
2. Short lifespan
3.Indefinite lifespan
4.Numerous stakeholders
with
5.System families
10
11
1. The new system requirements are defined in as much detail as possible. This
usually involves interviewing a number of users representing all the departments or
aspects of the existing system.
2. A preliminary design is created for the new system.
12
3. A first prototype of the new system is constructed from the preliminary design.
This is usually a scaled-down system, and represents an approximation of the
characteristics of the final product.
4. The users thoroughly evaluate the first prototype, noting its strengths and
weaknesses, what needs to be added, and what should to be removed. The
developer collects and analyzes the remarks from the users.
5. The first prototype is modified, based on the comments supplied by the users, and a
second prototype of the new system is constructed.
6. The second prototype is evaluated in the same manner as was the first prototype.
7. The preceding steps are iterated as many times as necessary, until the users are
satisfied that the prototype represents the final product desired.
8. The final system is constructed, based on the final prototype.
9. The final system is thoroughly evaluated and tested. Routine maintenance is carried
out on a continuing basis to prevent large-scale failures and to minimize downtime.
Customers could believe its the working system. Developer could take shortcuts and
only fill the prototype instead of redesigning it. Customers may think that the system is
almost done, and only few fixes are needed
Advantage of Prototype model
Suitable for large systems for which there is no manual process to define there
requirements.
User training to use the system.
User services determination.
System training.
Quality of software is good.
Requirements are not freezed.
Disadvantage of Prototype model
It is difficult to find all the requirements of the software initially.
It is very difficult to predict how the system will work after development.
1.6.4 Evolutionary Process Model
In EP model development engineering effort is made first to establish correct, precise
requirement definitions and system scope, as agreed by all the users across the
organization. This is achieved through application of iterative processes to evolve a system
most suited to the given circumstances.
The process is iterative as the software engineer goes through a repetitive process
of requirement until all users and stakeholders are satisfied. This model differs from the
iterative enhancement model in the sense that this does not require a useable product at
the end of each cycle. In evolutionary development, requirements are implemented by
category rather than by priority.
Main characteristics:
The phases of the software construction are interleaved
Feedback from the user is used throughout the entire process
The software product is refined through many versions
Types of evolutionary development:
Exploratory development
Throw-away prototyping
13
Concurrent
activities
Specification
Outline
description
Development
Validation
Initial
version
Intermedia te
versions
Final
version
Advantages:
Disadvantages:
14
Progressively more complete version of the software gets built with each iteration
around the spiral
Spiral model
15
Advantage of RAD
Dramatic time savings the systems development effort
Can save time, money and human effort
Tighter fit between user requirements and system specifications
Works especially well where speed of development is important
Disadvantage of RAD
More speed and lower cost may lead to lower overall system quality
Danger of misalignment of system developed via RAD with the business due to
missing information
May have inconsistent internal designs within and across systems
Possible violation of programming standards related to inconsistent naming
conventions and inconsistent documentation
16
Functional requirements: - describe what the software has to do. They are often
called product features. It depends on the type of software, expected users and the
type of system where the software is used.
Non Functional requirements: - are mostly quality requirements. That stipulate
how well the software does, what it has to do.These define system properties and
constraints e.g. reliability, response time and storage requirements. Constraints are
I/O device capability, system representations, etc.
User requirements:- Statements in natural language plus diagrams of the services
the system provides and its operational constraints.
System requirements: - A structured document setting out detailed descriptions of
the systems functions, services and operational constraints. Defines what should
be implemented so may be part of a contract between client and contractor.
17
Requirements engineering processes:- The processes used for RE vary widely depending
on the application domain, the people involved and the organisation developing the
requirements. However, there are a number of generic activities common to all processes
Requirements elicitation
Requirements analysis
Requirements documentation
Requirements review
Crucial process steps of Requirement
Problem
Engineering
Statem ent or
feasibility study
Requirem ent
Elicitation
Requirem ent
Engineering
Requirem ent
analysis
Requirem ent
docum entation
Requirem ent
Review
SRS
19
20
This causes a communication gap between the parties involved in the development
project. A basic purpose of software requirements specification is to bridge this
communication gap.
Characteristics of good SRS document:- Some of the identified desirable qualities of the
SRS documents are the followingConcise- The SRS document should be concise and at the same time unambiguous,
consistent, and complete. An SRS is unambiguous if and only if every requirement stated
has one and only one interpretation.
Structured- The SRS document should be well-structured. A well-structured document is
easy to understand and modify. In practice, the SRS document undergoes several revisions
to cope with the customer requirements.
Black-box view- It should only specify what the system should do and refrain from stating
how to do. This means that the SRS document should specify the external behaviour of the
system and not discuss the implementation issues.
Conceptual integrity- The SRS document should exhibit conceptual integrity so that the
reader can easily understand the contents.
Verifiable- All requirements of the system as documented in the SRs document should be
verifiable. This means that it should be possible to determine whether or not requirements
have been met in an implementation.
2.1.5 Requirements Validation
Requirement Validation is used for checking the document: Completeness & consistency
Conformance to standards
Requirements conflicts
Technical errors
Ambiguous requirements
21
22
23
These five factors are related to operational performance, convenience, ease of usage and
its correctness. These factors play a very significant role in building customers
satisfaction.
ii. Product Revision
The factors which are required for testing & maintenance are combined and are given
below:
Maintainability
Flexibility
Testability
These factors pertain to the testing & maintainability of software. They give us idea about
ease of maintenance, flexibility and testing effort. Hence, they are combined under the
umbrella of product revision.
iii. Product Transition
We may have to transfer a product from one platform to an other platform or from one
technology to another technology. The factors related to such a transfer are combined and
given below:
Portability
Reusability
Interoperability
24
Design
Test
Deployment
IV&V
Safety
Reliability
Metrics
Risk Management
25
Continued surveillance
CMM
26
ISO certification
is awarded by an
international standard body and can be
quoted as an official document
Deals primarily for manufacturing
industry and provisioning of services
SEI CMM
Internal use
CMM
was developed specially for
Software industry
and therefore
addresses software issues
It aims at level 3 of CMM
Goes beyond Quality Assurance and lead
to TQM
Has Customer Focus as primary aim and Provide a list of Key Process Areas to
follows procedural controls
proceed from lower CMM level to
higher level to provide gradual Quality
improvements
27
28
or related functions . Cohesion is strong if al parts are needed for the functioning of other
parts (e..Important design objective is to maximize module cohesion and minimize module
coupling.
Coupling
It is the measure of the degree of interdependence between modules. Coupling is highly
between components if they depend heavily on one another, (e.g., there is a lot of
communication between them).
Decomposition and modularization
Decomposition and modularization large software in to small independent once, usually
with the goal of placing different functionality or responsibility in different component
Design Complexity
Complexity is another design criteria used in the process of decomposition and refinement.
A module should be simple enough to be regarded as a single unit for purposes of
verification and modification
a measure of complexity for a given module is proportional to the number of other
modules calling this module (termed as fan-in), and the number of modules called by the
given module (termed as fan-out).
Top-down approach (is also known as step-wise design) is essentially the breaking down
of a system to gain insight into its compositional sub-systems. In a top-down approach an
overview of the system is formulated, specifying but not detailing any first-level
subsystems. Each subsystem is then refined in yet greater detail, sometimes in many
additional subsystem levels, until the entire specification is reduced to base elements. A
top-down model is often specified with the assistance of "black boxes", these make it
easier to manipulate. However, black boxes may fail to elucidate elementary mechanisms
or be detailed enough to realistically validate the model.
Bottom-up approach is the piecing together of systems to give rise to grander systems,
thus making the original systems sub-systems of the emergent system. In a bottom-up
approach the individual base elements of the system are first specified in great detail.
These elements are then linked together to form larger subsystems, which then in turn are
linked, sometimes in many levels, until a complete top-level system is formed. This
strategy often resembles a "seed" model, whereby the beginnings are small but eventually
grow in complexity and completeness. However, "organic strategies" may result in a tangle
of elements and subsystems, developed in isolation and subject to local optimization as
opposed to meeting a global purpose. Mechanisms or be detailed enough to realistically
validate the model.
3.3 Architectural design
Architectural design represents the structure of data and program components that
are required to build a computer-based system.
It considers the architectural style that the system will take, the structure and
properties of the components that constitute the system, and the interrelationships
that occur among all architectural components of a system.
Architectural design begins with data design and then proceeds to the derivation of
one or more representations of the architectural structure of the system.
30
Alternative architectural styles or patterns are analyzed to derive the structure that
is best suited to customer requirements and quality attributes.
Once an alternative has been selected, the architecture is elaborated using an
architectural design method.
Layered architectures
Data-centered architectures: - A data store (e.g., a file or database) resides at the center
of this architecture and is accessed frequently by other components that update, add, delete,
or otherwise modify data within the store. Client software accesses a central repository. In
some cases the data repository is passive. That is, client software accesses the data
independent of any changes to the data or the actions of other client software. A variation
on this approach transforms the repository into a blackboard that sends notifications to
client software when data of interest to the client change.
31
32
4.Procedural cohesion: is the form of cohesion obtained when software components are
grouped in a module to perform a series of functions following a certain procedure
specified by the application requirements
5. Temporal cohesion: Module exhibits temporal cohesion when it contains tasks that are
related by the fact that all tasks must be executed in the same time-span. Examples are
functions required to be activated for a particular input event, or during the same state of
operation
6.Logical cohesion: refers to modules designed using functions who are logically related,
such as input/output functions, communication type functions (such as send and receive),
7.Coincidental cohesion: Coincidental cohesion exists in modules that contain
instructions that have little or no relationship to one another.
3.5 Function oriented design
Function Oriented design is an approach to software design where the design is
decomposed into a set of interacting units where each unit has a clearly defined function.
Thus, system is designed from a functional view point.
Design Notations of function oriented design
Design notations are largely meant to be used during the process of design and are used to
represent design or design decisions. For a function oriented design, the design can be
represented graphically or mathematically by the following:
Data flow diagrams
Data Dictionaries
Structure Charts: - function-oriented design, the design can be represented
graphically by structure charts. Structure of a program is made up of the modules of
that program together with the interconnections between modules. structure chart of
a program is a graphic representation of its structure. In a structure chart a module
is represented by a box with the module name written in the box. An arrow from
module A to module B represents that module A invokes module B. B is called the
subordinate of A, and A is called the superordinate of B.
be used in both the preliminary and detailed design phases. Using pseudocode, the
designer describes system characteristics using short, concise, English language
phrases that are structured by key words such as It-Then-Else, While-Do, and End.
Example:COUNT=0
STOCK=STOCK+QUANTITY
OR
READ THE DATA FROM SOURCE
WRITETHE DATA TO DESTINATION
34
Categories of Metrics
i. Product metrics: describe the characteristics of the product such as size,
complexity, design features, performance, efficiency, reliability, portability,
etc.
ii. Process metrics: describe the effectiveness and quality of the processes that
produce the software product. Examples are:
effort required in the process
time to produce the product
effectiveness of defect removal during development
number of defects found during testing
maturity of the process
iii. Project metrics: describe the project characteristics and execution.
Examples are: number of software developers
staffing pattern over the life cycle of the software
cost and schedule
productivity
3.7.1 Halsteads Software science
Halstead has proposed metrics for length and volume of a program based of the
number of operation and operands.
Tokens are classified as either operators or operands all software science measures
are function of the count of these tokens
Any symbol or keyboard in a program that specify an algorithmic action is
considered an operator ,while a symbol used to represent the data is considered an
operand.
Variable, constants and even labels are operands
Operators consists of arithmetic symbols such as +,-,/,*and command names such as
while ,for, printf, special character such as :=,braces, parentheses etc.
In a program we define following measurable quantities
N = N1+N2
N : program length
where
N1 : total occurrences of operators
N2 : total occurrences of operands
Volume
The unit of measurement of volume is the common unit for size bits. It is the actual
size of a program if uniform binary encoding for the vocabulary is used.
V= N* log2
Program Level
The value of L ranges between zero and one, with L=1 representing a program
written at the highest possible level (i.e., with minimum size) and v is the potential
volume
35
L=V*/V
Estimated program Length
= 1log2 2+ 2log2 2
3.7.2 Function points Analysis
Alan Albrecht while working for IBM, recognized the problem in size measurement
in the 1970s, and developed a technique (which he called Function Point Analysis),
which appeared to be a solution to the size measurement problem.
It measure functionality from user point of view i.e on the basis of what the user
request and receive in return.
Therefore it deals with the functionality being delivered , and not with LOC, source
code, files etc.
Measuring size in this way has the advantage that size measure is independent of the
technology used to deliver the function
Advantages
Users point of view: what user requests & receives from the system
Independent of tech.,lang,tool,methods
36
37
38
Test data
Inputs which have been devised to test the system
Test cases
Inputs to test the system and the predicted outputs from these inputs if the system operates
according to its specification
4.2 Levels of Testing
There are 3 levels of testing:
i. Unit Testing
ii. Integration Testing
iii. System Testing
4.2.1 Unit testing is undertaken after a module has been coded and successfully reviewed.
Unit testing (or module testing) is the testing of different units (or modules) of a
system in isolation.
In order to test a single module, a complete environment is needed to provide all
that is necessary for execution of the module. That is, besides the module under test
itself, the following steps are needed in order to be able to test the module.
39
40
Test in g
s eq uen ce
Level 1
Level 1
Lev el 2
Level 2
. ..
Le vel 2
Level 2
Le vel 2
s tu bs
Le vel 3
s tu bs
Bottom-up testing
each subsystem is tested separately and then the full system is tested
Primary purpose of testing each subsystem is to test the interfaces among various
modules making up the subsystem. Both control and data interfaces are tested
Integrate individual components in levels until the complete system is created
T e st
d ri v e r s
Lev el N
T e st
d ri v e r s
L e ve l N
Le ve l N 1
Le vel N
Lev el N 1
Lev el N
Lev el N
T e s t in g
s eq u e n c e
Lev el N 1
41
For example, programmers may improperly use < instead of <=, or conversely <=
for <. Boundary value analysis leads to selection of test cases at the boundaries of
the different equivalence classes.
Suppose we have an input variable x with a range from 1-100 the boundary values
are 1,2,99 and 100.
Hence both the input x and y are bounded by two interval [a,b] and [c,d] respectively. for
input x, we may design test cases with value a and b, just above a and also just below b, for
42
input y, we may have values c and d ,design just above c and just below d. These test cases
will have more chance to detect an error
The basic idea of boundary value analysis is to use input values at their minimum,
just minimum, a nominal value, just below their their maximum and at their
maximum
Thus for a program of n variable ,boundary value analysis yields 4n+1 test cases.
2. Equivalence Class Partitioning
In this approach, the domain of input values to a program is partitioned into a finite
number of equivalence classes, so that if the program works correctly for a value
then it will work correctly for all the other values in that class.
This partitioning is done such that the behavior of the program is similar for every
input data belonging to the same equivalence class.
The main idea behind defining the equivalence classes is that testing the code with
any one value belonging to an equivalence class is as good as testing the software
with any other value belonging to that equivalence class.
Equivalence classes for a software can be designed by examining the input data and
output data.
The following are some general guidelines for designing the quivalence classes
Two steps are required to implementing this method:
1. The equivalence classes are identified by taking each input condition and partitioning it
into valid and invalid classes. For example, if an input condition specifies a range of values
from 1 to 999, we identify one valid equivalence class [1<item<999]; and two invalid
equivalence classes [item<1] and [item>999].
2. Generate the test cases using the equivalence classes identified in the previous step. This
is performed by writing test cases covering all the valid equivalence classes. Then a test
case is written for each invalid equivalence class so that no test contains more than one
invalid class.
43
2. The semantic content of the specification is analyzed and transformed into a Boolean
graph linking the causes & effects.
3. The graph is converted in to decision
4. The columns in the decision table are converted into test cases.
Basic cause effect graph symbols
44
45
corresponding to node j.Flow graph can easily be generated from the code of any
problem
Example
46
47
Method 1: Given a control flow graph G of a program, the cyclomatic complexity V(G)
can be computed as:
V(G) = E N + 2(P)
where N is the number of nodes of the control flow graph and E is the number of edges in
the control flow graph.
Method 2: An alternative way of computing the cyclomatic complexity of a program from
an inspection of its control flow graph is as follows:
V(G) = Total number of bounded areas + 1
In the programs control flow graph G, any region enclosed by nodes and edges can be
called as a bounded area
Method 3:The cyclomatic complexity of a program can also be easily computed by
computing the number of decision statements of the program.
If N is the number of decision statement of a program, then the McCabes metric is
equal to N+1.
Difference between functional and structural testing
Black-box testing
Functional Testing also called
Specification based Testing.
48
data are capable of detecting the change between the original program and the
mutated program
A major disadvantage of the mutation-based testing approach is that it is
computationally very expensive, since a large number of possible mutants can be
generated
Mutation testing should be used in conjunction of some testing tool which would run
all the test cases automatically
4.7 Performance testing
Performance testing is carried out to check whether the system needs the
nonfunctional requirements identified in the SRS document.
There are several types of performance testing. Among of them nine types are
discussed below.
The types of performance testing to be carried out on a system depend on the
different non-functional requirements of the system documented in the SRS
document.
All performance tests can be considered as black-box tests.
Stress testing
Volume testing
Configuration testing
Compatibility testing
Regression testing
Recovery testing
Maintenance testing
Documentation testing
Usability testing
4.8 Coding
Coding is undertaken once the design phase is complete and the design document
have been successfully reviewed
In the coding phase every module identified and specified in the design document
is independently coded and unit tested
Good software development organizations normally require their programmers to
adhere to some well-defined and standard style of coding called coding standards.
Most software development organizations formulate their own coding standards
that suit them most, and require their engineers to follow these standards
rigorously.
Good software development organizations usually develop their own coding standards and
guidelines depending on what best suits their organization and the type of products they
develop.
representative coding standards
representative coding Guidelines
4.8.1 Coding Standards
49
50
51
52
53
54
55
Benefits of CASE
Cost saving through all development phases. CASE put the effort reduction
between 30% to 40%
Use of CASE tool leads to considerable improvement to quality
CASE tools help to produces high quality and consistent documents
Use of CASE environment has an impact on style of working of a company, and
makes it conscious of structured and orderly approach
CASE Environment
Consistency &
Completeness analysis
Documentation
Generation
Structured analysis
facility
Coding support
activity
Central
Reposi
tory
Transfer facility in
Different format
Project magt
facility
prototyping
Configuration mant
facilities
Structured digram
facility
56
Organic Mode
developed in a familiar, stable environment,
similar to the previously developed projects
relatively small and requires little innovation
Semidetached Mode
intermediate between Organic and Embedded
Embedded Mode
tight, inflexible constraints and interface requirements
The product requires great innovation
5.7 Putnam Resource Model
Putnam studied the problem of staffing of software projects and found that the software
development has characteristics very similar to other R & D projects studied by Norden
and that the Rayleigh-Norden curve can be used to relate the number of delivered lines of
code to the effort and the time required to develop the project. It analyzing a large number
of army projects, Putnam derived the following expression:
57
Schedule Risk
Operational risk
Technical risk
Risk management is the identification, assessment, and prioritization of risks followed by
coordinated and economical application of resources to minimize, monitor, and control the
probability and/or impact of unfortunate events.
Risk Management Process, describes the steps you need to take to identify, monitor and
control risk. Within the Risk Process, a risk is defined as any future event that may prevent
you to meet your team goals. A Risk Process allows you to identify each risk, quantify the
impact and take action now to prevent it from occurring and reduce the impact should it
eventuate.
This Risk Process helps you:
Identify critical and non-critical risks
Document each risk in depth by completing Risk Forms
Log all risks and notify management of their severity
Take action to reduce the likelihood of risks occurring
Reduce the impact on your business, should risk eventuate
58
59