5 Unit
5 Unit
SOFTWARE ENGINEERING
CONTENTS
July 2013
Krishna Kanta Handiqui State Open University
No part of this publication which is material protected by this copyright notice may be produced or
transmitted or utilized or stored in any form or by any means now known or hereinafter invented,
electronic, digital or mechanical, including photocopying, scanning, recording or by any information
storage or retrieval system, without prior written permission from the KKHSOU.
Printed and published by Registrar on behalf of the Krishna Kanta Handiqui State Open University.
While going through a unit, you will notice some boxes along-side, which have been included
to help you know some of the difficult, unseen terms. Some ACTIVITY (s) have been included to help
you apply your own thoughts. Again, we have included some relevant concepts in LET US KNOW
along with the text. And, at the end of each section, you will get CHECK YOUR PROGRESS questions.
These have been designed to self-check your progress of study. It will be better if you solve the given
problems in these boxes immediately, after you finish reading the section in which these questions
occur and then match your answers with ANSWERS TO CHECK YOUR PROGRESS given at the
end of each unit.
MASTER OF COMPUTER APPLICATIONS
Software Engineering
DETAILED SYLLABUS
UNIT STRUCTURE
1.2 Introduction
1.8 SDLC
1.2 INTRODUCTION
Software Engineering is an engineering discipline which is used to solve larger and more
complex problem in cost-effective and efficient ways. It is mainly related with software system
implementation, operation and maintenance etc. Software engineering uses systematic
approaches, methods, tools and procedure to solve a problem.
In this unit we will introduce you a brief description of software components, software
characteristics, different software attributes, software processes and also the phases of a
software development life cycle (starting from software requirement specification to design,
testing, implementation and maintenance phase) and different software development life cycle
models.
A software component is an independent software unit that can be composed with other
components to create a software system.
Component characteristics:
Independent: A component should be independent
Composable: It means that all the external instruction must take place through publicly
defined interfaces.
Deployable: A component has to be self-contained and must be able to operate as a
stand-alone entity.
Fundamental Principle of component:
Independent Software development:
Large software system are necessarily assembled from components develop by
different people.
To facilitate independent development, it is essential to decouple developers and
users of components.
Reusability:
Some parts of a large system will necessarily be special-purpose software, it is
essential to design and assemble pre-existing components in developing new
components.
Software quality:
A component or system needs to be shown to have desired behavior, either
through logical reasoning or testing.
CBSE Waterfall
Find Requirement analysis
Select
Design
Adapt Implementation
Test Test
Deploy Replace
Replace Maintenance
Correctness Usability
Usability Portability
Integrity Transferability
Efficiency
Reliability
Security
Safety
Revision
Maintainability Extensibility
Testability Scalability
Fig.1.1:Flexibility
Software Quality Triangle
Modularity
These are functionality based factors and related to 'exterior quality' of software. Various
Operational Characteristics of software are:
a) Correctness: The software which we are making should meet all the specifications
stated by the customer.
b) Usability: The amount of efforts or time required to learn how to use the software should
be less. This makes the software user-friendly even for IT-illiterate people.
c) Integrity: Just like medicines have side-effects, in the same way software may have a
side-effect i.e. it may affect the working of another application. But quality software
should not have side effects.
d) Reliability: The software product should not have any defects. Not only this, it shouldn't
fail while execution.
e) Efficiency: This characteristic relates to the way software uses the available resources.
The software should make effective use of the storage space and execute command as
per desired timing requirements.
f) Security: With the increase in security threats nowadays, this factor is gaining
importance. The software shouldn't have ill effects on data / hardware. Proper measures
should be taken to keep data secure from external threats.
g) Safety: The software should not be hazardous to the environment/life.
1. PROBLEM OF COMPATIBILITY
2. PROBLEM OF PORTABILITY
3. PROBLEM OF DOCUMENTATION
4. PROBLEM OF PIRACY OF SOFTWARE
5. PROBLEM IN COORDINATION TO WORK WITH OTHER PEOPLE
6. PROBLEM THAT ARISE DURING ACTUAL RUN TIME IN THE ORGANIZATION
7. PROBLEM OF MAINTENANCE IN PROPER MANNER.
Like all engineering discipline, software engineering has also three major attributes:
Cost
Schedule
Quality
The cost of developing a system is the cost of the resources used for system. Which in the
case of software is determined by the manpower cost, as development is largely labor-intensive.
Hence, the cost of a software project is often measured in terms of person-month spent in a
project.
Person-month: In software engineering Person-month is a measure of work effort. It can be
converted into dollar amount by multiplying it with average dollar cost.
Calculation:
If a project will take 2 months to finish with 3 people working full time on it, the project requires
2*3=6 person-month effort.
If an employee worked 20 days on a project, his contribution to the project is 1*20/30 = 0.6666
person-month. (Note that month is considered 30 days in such calculations.)
Schedule is also an important factor in software projects. Business trends are dictating
that the time to market of a product should be reduced; i.e. the cycle time from concept to
delivery should be small. For software this means that it needs to be developed faster.
The other major attribute of any production discipline is quality. Today, quality is the
main thing. So, clearly developing high quality Software is another fundamental goal of software
engineering. However the concept of quality in the context of software needs further discussion.
We use the international standard on software product quality as the basis of our discussion
here. According to the quality model adopted by this standard, software quality comprise of six
main attributes as shown in the fig 1.2-
Software
Quality
Functionality: The Capability to provide functions which meet stated and implied needs
when the software is used.
Reliability: The capability to maintain a specified level of performance.
Usability: The capability to be understood, learned, and used.
Efficiency: The capability to provide appropriate performance relative to the amount of
resources used.
Maintainability: The capability to be modified for the purpose of making corrections,
improvements etc.
Portability: The capability of the software to be work properly in different environment
without applying any action.
Software Design
Coding
Software testing
Software
maintenance
Now the question is why we need life cycle model? Why it is necessary for a
development team to use a suitable life cycle model?
The primary advantages of using a life cycle model are that it encourages development
of software in a systematic and disciplined manner. When software is developed by a single
programmer he has the freedom to decide the exact steps through which he will develop the
program. However, when a software is developed by a team, it is necessary to have a precise
understanding among the team members that when to do what. Otherwise, it may lead to chaos
and project failure. Suppose, a software development problem is divided into several parts and
the parts are assigned to the different team members. Then suppose the team members are
allowed to the freedom to develop the parts assigned to them in whatever way they like. It is
Possible that one member must start writing the code for his part, another might decide to
prepare the test document first, and some other engineer might begin with the design phase of
the parts assign to him. This allowed to be one of perfect reason for project failure.
Now we discuss four different types life cycle model. Different life cycle models are:-
Waterfall Model
Prototype model
Evolutionary Development Model
Spiral Model
Requirement
Analysis and
specification
Design
Integration and
system testing
Maintenance
The feasibility study activity involve the analysis of problem and collection of all relevant
information relating to the product such as
The different data items which would be input to the system
The processing required to be carried out on these data.
The output data required to be produced by the system as well as various constraints on
the behavior of system.
Requirement analysis and specification: This phase is the next phase of feasibility study
phase. The main aim of this phase is to understand the exact requirements of the customer and
to document them properly. This phase consists of two distinct activities, namely requirement
gathering and analysis, and requirement specification.
Once an application is in the testing stage, it is very difficult to go back and change
something that was not well-thought out in the concept stage.
No working software is produced until late during the life cycle.
High amounts of risk and uncertainty.
Not a good model for complex and object-oriented projects.
Poor model for long and ongoing projects.
Not suitable for the projects where requirements are at a moderate to high risk of
changing.
Requirement
Analysis
Code
Test
Requirement
Analysis
However, in the prototyping model of development the requirement analysis and specification
phase becomes redundant as the working prototype approved by the customer and the next
phases are design, coding and testing as shown in the Fig1.5.
Prototype model should be used when the desired system needs to have a lot of
interaction with the end users.
Typically, online systems, web interfaces have a very high amount of interaction with
end users, are best suited for Prototype model. It might take a while for a system to be
built that allows ease of use and needs minimal training for the end user.
Prototyping ensures that the end users constantly work with the system and provide a
feedback which is incorporated in the prototype to result in a useable system. They are
excellent for designing good human computer interface systems.
Each successive version of product is fully functioning software capable of performing more
useful work than previous one. The following two fig describe the evolutionary model:
B C
A B
A
A
Maintenance
Generates working software quickly and early during the software life cycle.
More flexible less costly to change scope and requirements.
Easier to test and debug during a smaller iteration.
Customer can respond to each built.
Lowers initial delivery cost.
Easier to manage risk because risky pieces are identified and handled during itd
iteration.
Disadvantages of Incremental model:
The spiral model is similar to the incremental model, with more emphasis placed on risk
analysis. The spiral model has four phases: Planning, Risk Analysis, Engineering and
Evaluation. A software project repeatedly passes through these phases in iterations (called
Spirals in this model). The baseline spiral, starting in the planning phase, requirements is
Gathered and risk is assessed. Each subsequent spiral builds on the baseline
spiral. Requirements are gathered during the planning phase. In the risk analysis phase, a
process is undertaken to identify risk and alternate solutions. A prototype is produced at the
end
of the risk analysis phase.
Software is produced in the engineering
phase, along with testing at the end of the
phase. The evaluation phase allows the
customer to evaluate the output of the
project to date before the project continues
to the next spiral.
The spiral model is called Meta
model because it subsumes all the
discussed models. For example a single
loop spiral model can be viewed as
waterfall model. The spiral model uses a
prototyping approach by first building a
prototype before embarking on the actual
product development effort. Also the spiral
model can be considered as supporting the
evolutionary model-the iteration along the spiral can be considered as evolutionary levels
through which the complete system is built. The spiral model uses prototyping as risk reduction
mechanism and also systematic step-wise approach of waterfall model.
Advantages of Spiral model:
High amount of risk analysis hence, avoidance of Risk is enhanced.
Good for large and mission-critical projects.
Strong approval and documentation control.
Additional Functionality can be added at a later date.
Software is produced early in the software life cycle.
Disadvantages of Spiral model:
Can be a costly model to use.
Risk analysis requires highly specific expertise.
Projects success is highly dependent on the risk analysis phase.
Doesnt work well for smaller projects.
When to use Spiral model:
When costs and risk evaluation is important
For medium to high-risk projects
Long-term project commitment unwise because of potential changes to economic
priorities
Users are unsure of their needs
Requirements are complex
New product line
Significant changes are expected (research and exploration
Software engineering is the discipline that aims to provide methods and procedures for
systematically developing industrial strength software. Software engineering uses
systematic approaches, methods, tools and procedure to solve a problem.
Software components are independent software unit that can be composed with other
components to create a full software system.
Like all engineering discipline, software engineering has also three major attributes:
Cost, Schedule and Quality.
A software life cycle is the series of identifiable stages that a software product
undergoes during its lifetime. The first stage in the life cycle of any software product is
usually the feasibility study stage. Commonly, the subsequent stages are Requirement
analysis and Specification, Software Design, Coding, Software testing, Software
maintenance.
Name of different life cycle models are Waterfall Model, Prototype model, Evolutionary,
Development Model, Spiral Model.
1. Transition
2.Work Effort
3.Software Failure
4.Attribute
5.c)Dependability
6. A. Feasibly study
7. C. Software requirement specification
8. C. Prototyping model
9. C .Technology, finance, time, recourses
10.B. Spiral
1.11 FURTHER READINGS
MODEL QUESTIONS
1. What do you mean by Software Engineering? Why we need software engineering
techniques?
2. What do you mean by software components? How CBSE is different from traditional
software engineering?
3. Define the characteristics of good software?
4. Explain the term software crisis?
5. What do you mean by the term person-month? Explain the software quality model?
6. Why we need SDLC model?
7. What are the different life cycle models? Explain Waterfall model? Write down the
advantages and disadvantages of waterfall model?
8. Explain the prototyping model with their advantages and disadvantages?
9. Explain the spiral model of software engineering with their advantages? Why it is called
Meta model?
10. Write down the concept of evolutionary Development model?
11. Explain Iterative Enhancement Model of software development?
12. Compare all the life cycle models with their advantage and disadvantages?
******
UNIT- 2 SOFTWARE REQUIREMENT SPECIFICATIONS (SRS)
UNIT STRUCTURE
2.1 Learning Objectives
2.2 Introduction
2.3 Requirement Engineering Process
2.3.1 Elicitation
2.3.2 Analysis
2.3.3 Documentation
2.3.4 Review and Management of User Needs
2.4 Feasibility Study
2.5 Information Modeling
2.6 Data Flow Diagrams
2.7 Entity Relationship Diagrams
2.8 Decision Tables
2.9 SRS Document
2.10 IEEE Standards for SRS
2.11 Software Quality Assurance (SQA)
2.11.1 Verification and Validation
2.11.2 SQA Plans
2.12 ISO 9000 Models
2.13 SEI-CMM Model
2.14Let Us Sum Up
2.15Further Readings
2.16 Answers To Check Your Progress
2.17 Possible Questions
The figure below illustrates the process of determining the requirements for a system:
Requirements engineering describes what to do and not the how to do of a software system.
The problem statement that is prepared by the customer is the input to the requirement
engineering and the output of this process is a system requirement specification, also termed as
Requirement Definition and description (RDD). This RDD then forms the basis for designing the
software solutions.
Requirements can be categorized based on their priority and functionality. Based on priority
they are of three types.
2.3.1 Elicitation
Elicitation is the first activity that takes place and continues through the requirement engineering
lifecycle. The purpose is to gain knowledge that is relevant to the problem. The analyst should
have a sound knowledge of the problem domain. Otherwise it may happen that some important
parameters of the problem were not considered and thereby the software will not provide the
best solution to the users problem. This is a communication process between the analyst and
the users of the existing system.
There are various information gathering tools in elicitation and each of the tool has a different
function depending on the type of the information that is needed. Some of the tools are
1. Review of Literature, Procedures and Forms
2. On-site observation
3. Interviews and Questionnaires.
About 90 - 95% elicitation should be completed in the initiation stage while the remaining 5% is
completed in the developing stage.
The procedures, manuals and forms are some of the useful sources of information for the
analyst. These describe the formats and functions of the present working system. Forms are
widely used for capturing and providing information. The main objective of using this tool in
elicitation is to find out how the forms are used in dealing with the information in the system.
The main disadvantage of this search is time. Up-to-date manuals save much of the
requirements-gathering time but unfortunately, in many cases, either they do not exist or are
out-of-date.
On-site observation
Natural or Contrived: A natural observation takes place in the employees work place
while a contrived observation takes place in a place such as a laboratory.
Obtrusive or Unobtrusive: An observation where the respondent knows that he is being
observed is an obtrusive observation, whereas if the observation takes place in a
contrived way such as behind a one-way mirror, is an unobtrusive observation.
Direct or Indirect: When the analyst actually observes the system at work is a direct
observation whereas indirect is that in which cameras or video recorders are used to
capture the information.
Structured or Unstructured: In structured the observer studies and records a specific
action in the system. Unstructured methods place the observer in a situation to observe
whatever might be pertinent at the time.
The main problem with this technique is that intruding into the users area might result in adverse
reaction by the staff.
An interview is a direct face-to-face attempt in which questions are asked by a person called the
interviewer to a person being interviewed to gather information about the system or the problem
area of the system. It is a conversation in which the roles of the interviewer and the respondent
change continually. The art of interviewing is mostly developed through experience. In this
method, they can directly obtain the information from the domain expert by asking them how
they do their job.
The success of an interview is dependent on the questions asked and the ability of the expert to
articulate and willing to share the knowledge. The information has to be easily expressed by the
expert, which is often difficult when tasks that are frequently performed often become
automatic. Indirect methods are then used to obtain the information that otherwise cannot be
expressed directly.
Another tool used is the questionnaire. It consists of a series of questions to which the
individuals responds. It is self administered and is much economical than interview. A
questionnaire can be given to a large number of the system users at the same time. Questions
in a questionnaire can be open-ended or closed ended.
2.3.2 ANALYSIS
The next step after elicitation is requirement analysis. After gathering the requirements in the
elicitation stage, each of them is then analyzed to get a clear picture of the exact customer
requirements and also the product to be developed. This is done by checking the validity,
consistency and feasibility of the gathered requirements. The validity checks and confirms its
relevance to goals and objectives, consistency confirms that the requirements does not conflict
with the other requirements and then feasibility ensures that the inputs and the required
technology support is available for the project development.
In Domain understanding, the analyst must properly understand the domain for which a system
has to be developed. After that the requirements of the stakeholders of the organization must be
gathered. The requirements should be organized accordingly in classification. There are again
chances for requirements conflict in the organization as different stakeholders have different
types of requirements. Basically there are three types of requirements that the analyst needs to
identify and resolve in conflict resolution. They are ambiguity, inconsistency and
incompleteness. Anomaly is an ambiguity in the requirement. If there is anomalous requirement,
then several interpretation of that requirement is possible which may lead to finally an incorrect
system. Requirements can be incomplete if some of them has been overlooked by the stake
holders. The analyst can suggest those requirements to the users for their consideration and
approval to incorporate those in the requirements lists. Conflict resolution requires effort and
experience of the analyst to detect them.
In prioritization, the requirements are to be given priority based on their importance. Finally in
the requirements checking, the requirements are checked to discover if they are complete,
consistent and in accordance with what is actually wanted from the system.
2.3.3 DOCUMENTATION
After gathering the required information needed to develop the new system and analyzing each
of them by removing the anomalies, inconsistencies and incompleteness, the analyst organizes
the requirements in a proper format in the form of an SRS (Software Requirement Specification)
document. The SRS document usually contains all the users requirements. It also serves as a
contract document between the customer and the developer.
In case the system proposal is accepted by the management after the review of the users
requirements, the next step is to examine the feasibility of the system. A feasibility study is
carried out to identify, describe and evaluate the candidate systems and select the best system
that meets performance requirements. A proper feasibility study will show the strengths and
deficits before the project is planned or budgeted for. By doing the research beforehand,
companies can save money and resources in the long run by avoiding projects that are not
feasible.
It is basically the test of the proposed system in the light of its workability, meeting users
requirements, effective use of resources and of course, the cost effectiveness. These are
categorized as economic, technical and operational feasibility.
Economic feasibility: This is more commonly known as the cost/benefit analysis. The benefits
and savings that are expected from the candidate system is determined and then compared
with the cost. If benefits outweigh costs, then the decision is made to design and implement the
system.
Technical feasibility: The technical requirements of the proposed project are considered in
technical feasibility. It studies whether the problem can be solved using existing technology and
available resources. The technical requirements of the proposed system are compared to the
technical capability of the organization. The systems project is considered technically feasible if
the internal technical capability is sufficient to support the project requirements. The analyst
must also find out to whether the existing resources can be upgraded to fulfill the request under
consideration.
Operational feasibility: It examines the users and the managements acceptance and support
for the new system. It is also known as behavioral feasibility because it measures the behavior
of the users. If the users do not accept the new technology or system then it will definitely fail to
serve the purpose of developing the software product. One of the common method of obtaining
user acceptance and support is through user involvement by communicating, educating and
involving them. Thus the introduction of a candidate system requires effort to educate and train
the staff on new ways of conducting business.
2.5 INFORMATION MODELING
An information model is used to describe the flow of information in a system. The sources and
destination of the information flow in an organization can be understood with the help of
information modeling. In Information flow Model (IFM), the medium of the flow may be
documents or emails and its contents may be text, images or diagrams. The IFM is a high-level
model which shows only the main flows and the internal information are assumed to be present.
A business process can be modeled, for example, to describe the progression of an order from
the entry of the order by the customer to the final invoicing. This would describe the order
process and not the specific orders that has been placed by the customer.
The Data Flow Diagrams (abbreviated as DFD) was introduced by De Marco and Gane and
Sarson and it is an important tool of structured analysis. The Data Flow Diagram is also known
as the Bubble chart. It is a graphical representation of the flow of data through the system. It
identifies the major transformations that later in system design will become the programs.
A DFD models a system by using external entities from which data flows to a process. The
process then transforms the data and creates output data flows which go to other processes or
other external entities or some data stores. The stored data may also flow as input to some
processes. The advantage of DFD is that it provides an overview of what data the system would
process, what transformations are done on the data, which data are stored and where the
results flow. In other words, a DFD describes what data flow rather than how they are
processed. The DFD is simple to understand by both programmers and non-programmers. It
specifies only what processes are performed and not how they are performed.
There are different types of symbols that are used to construct a DFD. They are listed below
along with the meanings.
1. Process symbol: A process is represented using a circle. It transforms the input data into
output data.
2. External entity: A square defines an external entity. They are the source or destination of
the system data.
3. Data store symbol: A data store symbol is represented by open-ended rectangle. They
are the temporary repositories of data. It is a logical file.
4. Data flow symbol: A directed arc or arrow is used as a data flow symbol. The data flow
represents the movement of data from one component to another.
There are some rules how to draw a DFD. They are as follows:
Symbol Meaning
Entity
Weak entity
Relationship
Attribute
Key Attribute
Multivalued Attribute
Composite attribute
Derived attribute
An example of an ER diagram of a company which keeps information about its employees, the
projects it has in hand, the parts used in the project, the supplier who supplies the projects and
the warehouses where the parts are stored is given in the figure below.
Require
The entities in the above figure are Employee, Project, Parts, Supplier and Warehouses.
Attached to each of the entities are its attributes and the relationships among them.
There may be several types of attributes in an ER model simple versus composite, single-
valued versus multivalued and stored versus derived attribute.
Simple versus Composite attribute: Those attributes that can be further divided into subparts are
called composite attribute. For example, the address attribute can be divided into House
Number, Street, City, State, District and Pincode. Attributes that are not divisible are called
Simple or Atomic attributes.
Single-valued versus Multivalued attribute: Those attributes that have a single value for a
particular entity are called Single-valued attribute. For example, the age of a person is a single
valued attribute. In some cases, an attribute can have a set of values for the same entity. For
example, the attribute CollegeDegree for a person may be different for different persons. A
person may have 0, 1 or more number of degrees.
Stored versus Derived attribute: Sometimes two (or more) attribute values may be related. For
example, the DateOfBirth and Age attributes of a person are related. The age of a person can
be determined from his DateOfBirth and the current date. Hence, the Age attribute is called a
derived attribute and the DateOfBirth attribute is called a stored attribute.
An entity type is a collection of entities that have the same attributes. Each entity type is
described by its name and attributes. The collection of all entities of a particular entity type at an
instance is called an entity set. An entity type EMPLOYEE with its attributes is shown below:
Entity Set :
(E1, Aashish Bora, 26)
(E2, Binod Das, 35)
(E3, Rahul Purkayastha, 28)
(E4, Snigdha Kapoor, 30)
.
.
.
An entity type usually has an attribute with a distinct value for each individual entity in the entity
set. Such type of attributes are called key attribute. They are used to uniquely identify each
entity. For example, in the above case, the entity type EMPLOYEE has the attribute Emp_id as
the key attribute because it can uniquely identify each of the entities in the set.
2.8 DECISION TABLES
A decision table is a two-dimensional matrix with one row for each possible action and one
row for each relevant condition and one column for each combination of condition states.
They are useful when there are different sets of conditions and a number of combinations
of actions that can take place. To represent and analyze complex logical relationships, the
decision tables are used.
A decision table consists of two parts stub and entry. The stub part is divided into an
upper quadrant called condition stub and a lower quadrant called action stub. The entry
part is also divided into a upper and a lower quadrant namely condition entry and action
entry. These four elements are shown in the figure below:
Condition
Action
1. Introduction
1.4. References
1.5. Overview
2. Overall description
2.4. Constraints
3. Specific Requirements
4. Supporting information
4.2 Appendixes
The specific requirements cover the functional, non-functional and the interface requirements.
The aim of Software Quality Assurance (SQA) is to develop high quality software product.
A good quality product does exactly what the users want it to do. Software Quality Assurance is
a set of activities that defines how software quality can be achieved and how the development
organization knows that the software has the required level of quality. If the quality in the
software development process is high then the errors are reduced in the developed product.
SQA includes the process of assuring that standards and procedures are established and are
followed throughout the software acquisition life cycle.
The main task of quality assurance is to define or select standards. There are two types of
standards that may be established as part of the quality assurance process:
1. Product standard: These apply to the software product being developed. It includes
standard of the document, the documentation and the coding standard.
2. Process standard: These define the processes that should be followed during the
software development process.
Verification determines whether the output of one phase of software development confirms to
that of its previous phase. The validation process, on the other hand, determines whether the
fully developed system confirms to its requirements specification. The ultimate goal of these
processes is to establish the confidence that the system is fit for the purpose.
There are some steps how to develop and implement an SQA plan.
The guidelines for maintaining a quality system is specified in the ISO 9000 standard. These
standards define the quality systems or models applicable to design, development, production,
installation and servicing, final inspection and test. As all endeavors do not encompass all of
these business aspects, three standards were developed covering different combinations of
these disciplines. Guidelines were also issued to assist the industries in choosing the correct
standard. The aims of such standards are to assure consistency in the quality of products and
services combined with continual improvement in customer satisfaction and error rates.
These three standards are ISO 9001, ISO 9001 and ISO 9003.
ISO 9001: This is the most general of the above standards. It applies to organizations
concerned with the quality process in organizations engaged in design, development,
production and servicing of goods. ISO 9001 requires the development of quality
manual and documented procedures which define the organization and operation of the
quality system.
ISO 9002: This standard applies to those organizations which are involved in production,
installation and servicing. It is the model for quality systems that include production but
do not include design. For example, manufacturing industries such as car and steel who
buy the design from external sources and are only involved in its production. Thus the
ISO 9002 is not applicable to software development organizations.
ISO 9003: This standard applies to those organizations which are involved only in
installation and testing of the products.
The Capability Maturity Model (CMM) was developed by the SEI. It was developed to assist the
US Department of Defence (US DoD) in purchasing software. This model helped the
organizations to improve the quality of the software they developed and thus the adoption of the
SEI CMM model helped the organizations to gain competitive advantage.
The Capability Maturity Model is a reference model for apprising the software process maturity
into different levels. The SEI CMM has 5 levels of organizational maturity that determine
effectiveness in delivering quality software.
Level 1: Initial
At this level almost no software development processes are defined and followed. Software
engineers follow their own processes of development and so this level is characterized by
chaos, periodic panics, and heroic efforts required by individuals to successfully complete the
projects.
Level 2: Repeatable
At this level, the basic management practices like software project cost tracking and scheduling
are established. The size and cost estimation techniques such as function point analysis,
COCOMO etc are used. The success story of the development of a product can be repeated for
the others.
Level 3: Defined
At this level, standard software development and maintenance processes are defined and also
documented. Organization-wide understanding of the roles and responsibilities exist. Periodic
training programs are used to ensure understanding and compliance.
Level 4: Managed
Software metrics is used in this level. Tools like fishbone diagrams, Pareto charts etc are used
to measure product and process quality. Project performance is evaluated in this level.
Level 5: Optimizing
The focus is on continuous process improvement. This is achieved by analyzing the quantitative
feedback from the process measurements and it can also be achieved from new and innovative
ideas and technologies.
2.14Let Us Sum Up
1. Requirements Engineering is the process of establishing the services that the customer
requires from the system and the constraints under which it is to be developed and
operated.
2. It describes what to do and not the how to do of a software system.
3. The requirements are of two different types - Functional Requirements and Non-
functional Requirement
4. The steps in requirement engineering are Elicitation, Analysis, Documentation, Review
and requirements management.
5. Elicitation is the first activity that takes place and continues through the requirement
engineering lifecycle.
6. Some information gathering tools in elicitation are Review of Literature, Procedures and
Forms, On-site observation and Interviews and Questionnaires.
7. In the analysis phase, each of the requirement is analyzed to understand the exact
customer requirements and also the software product to be developed.
8. In the documentation, the analyst organizes the requirements in a proper format in the
form of an SRS (Software Requirement Specification) document. The SRS document
usually contains all the users requirements.
9. A requirement review is a manual process of evaluation or examination of the
requirements documents. It involves people from both the client and contractor
organization so as to check the documents for anomalies and omissions.
10. Requirements review can be informal or formal.
11. A feasibility study is carried out to identify, describe and evaluate the candidate systems
and select the best system that meets performance requirements.
12. Feasibility study can be categorized as economic, technical and operational feasibility.
13. An information model is used to describe the flow of information in a system.
14. The DFD is a graphical representation of the flow of data through the system. It identifies
the major transformations that later in system design will become the programs.
15. An entity-relationship (ER) model is a detailed, logical representation of the data for an
organization. It describes the data as entities, attributes and relationships.
16. There may be different types of attributes in an ER model : simple versus composite,
single-valued versus multivalued and stored versus derived attribute.
17. An entity type usually has an attribute with a distinct value for each individual entity in
the entity set. Such type of attributes are called key attribute.
18. A decision table is a two-dimensional matrix with one row for each possible action and
one row for each relevant condition and one column for each combination of condition
states.
19. The Software Requirements Specification (SRS) document includes both the user
requirements and a detailed specification of the system requirements. It enlists all the
necessary requirements that are required for the project development.
20. The aim of Software Quality Assurance (SQA) is to develop high quality software
product.
21. The main task of quality assurance is to define or select standards.
22. Verification determines whether the output of one phase of software development
confirms to that of its previous phase. The validation process, on the other hand,
determines whether the fully developed system confirms to its requirements
specification.
23. A Software Quality Assurance (SQA) plan consists of those procedures, techniques and
tools used to ensure that a product meets the requirements specified in software
requirements specification.
24. The ISO 9000 is the set of standards that can be used in the development of a quality
management system (QMS) in the organizations. The ISO 9000 standards establish a
standard framework for a Quality System.
25. The Capability Maturity Model is a reference model for apprising the software process
maturity into different levels. The SEI CMM has 5 levels of organizational maturity that
determine effectiveness in delivering quality software.
1. Systems Analysis and Design, 2nd Edition, Elias M Awad, Galgotia Publication
A.1. True
2. False
3. True
4. False
5. True
6. True
7. False
8. False
9. True
10. False
11. False
12. True
1. a. SRS Document
d. Validation
e. SQA Plan
f. ISO 9000
h. ISO 9002
j. 5 levels
UNIT STRUCTURE
3.2 INTRODUCTION
Data
Parameters Control
Information
or
Flag Data
Module
B
3.6 COUPLING
Edit Edit
vendor vendor
record record
Vendor name
Vendor ID vendor vendor
record vendor record
Vendor address
EOF ID EOF
tax status
date
Retrieve Retrieve
vendor vendor
record record
Floating data occurs when one module produces data that are not
needed by the calling module; but are required by another module elsewhere
in the system. This should be avoided. The details are passed through the
system until they finally reach the function that requires them. Redesigning
to establish loose coupling, along with the creation of more cohesive modules
will avoid this difficulty.
3.7 COHESION
1. Functional
Yes
Can the module be
considered to be doing
2. Sequential
one problem-related Yes
funtion?
Is sequence
important?
No
No 3. Communicational
Data
Neither
6. Logical
Yes
Are the
activities in
the same
general No
category? 7. Coincidental
UNIT STRUCTURE
1
Software Testing Unit 4
4.2 INTRODUCTION
After going through the previous units of this course, we learnt
many concepts involved with the subject of Software Engineering.
The various components that were associated with the process of
Software Engineering have already been discussed at length. Also
in the previous unit, we came to know about some basic concepts
of the Software design process like architectural design, low-level
designs, Pseudo codes, flow charts, coupling and cohesion
measures etc. Apart from that, few other topics relating to software
measurement and metrics that enable us to gain insight by
providing a mechanism for objective evaluation were also
discussed at length.
In this unit, we get introduced to the concept of Software
testing which is a very important phase in the process of any kind
of software development process in order to ensure the successful
production of a fully functional and error-free final product.
Software testing is a critical element of software quality assurance
and represents the ultimate review of specification, design, and
code generation. The increasing visibility of software as a system
element and the attendant "costs" associated with a software
failure are motivating forces for well-planned, thorough testing. In
this unit we discuss software testing fundamentals and techniques
for software test case design. Software testing fundamentals
define the overriding objectives for software testing.
2
Software Testing Unit 4
3
Software Testing Unit 4
4
Software Testing Unit 4
5
Software Testing Unit 4
6
Software Testing Unit 4
7
Software Testing Unit 4
8
Software Testing Unit 4
9
Software Testing Unit 4
This is the final stage in the testing process before the system is
accepted for operational use. The system is tested with data
supplied by the system customer rather than with simulated test
data. Acceptance testing may reveal errors and omissions in the
system requirements definition, because the real data exercise the
system in different ways from the test data. Acceptance testing
may also reveal requirements problems where the systems
facilities do not really meet the users needs or the system
performance is unacceptable.
It is virtually impossible for a software developer to foresee how
the customer will really use a program. Instructions for use may be
misinterpreted; strange combinations of data may be regularly
used; output that seemed clear to the tester may be unintelligible
10
Software Testing Unit 4
11
Software Testing Unit 4
12
Software Testing Unit 4
13
Software Testing Unit 4
feeding them input and examining the output, and internal program
structure is rarely considered. Functional Testing also called Black-
box testing, focuses on the functional requirements of the software.
That is, black-box testing enables the software engineer to derive
sets of input conditions that will fully exercise all functional
requirements for a program. Black-box testing is not an alternative
to white-box techniques. Rather, it is a complementary approach
that is likely to uncover a different class of errors than white-box
methods.
Black-box testing attempts to find errors in the following categories:
1. incorrect or missing functions
2. interface errors
3. errors in data structures or external data base access
4. behavior or performance errors
5. initialization and termination errors.
Unlike white-box testing, which is performed early in the testing
process, black-box testing tends to be applied during later stages
of testing. Because black-box testing purposely disregards control
structure, attention is focused on the information domain. Tests are
designed to answer the following questions:
How is functional validity tested?
How is system behavior and performance tested?
What classes of input will make good test cases?
Is the system particularly sensitive to certain input values?
How are the boundaries of a data class isolated?
What data rates and data volume can the system tolerate?
What effect will specific combinations of data have on
system operation?
14
Software Testing Unit 4
15
Software Testing Unit 4
16
Software Testing Unit 4
3. Code inspections
Software review
A Software review can be defined as a filter for the software
engineering process. The purpose of any review is to discover
errors in the analysis, design, and coding, testing and
implementation phases of the software development cycle. The
other purpose of a review is to see whether procedures are applied
uniformly and in a manageable manner.
Objectives of reviews
Review objectives are used:
To ensure that the software elements conform to their
specifications.
To ensure that the development of the software element is
being done as per plan, standards, and guidelines
applicable for the project.
To ensure that the changes to the software elements are
properly implemented and affect only those system areas
identified by the change specification.
Types of Reviews
Reviews are of two types:
17
Software Testing Unit 4
Results of FTR
Meeting decisions
1. Whether to accept the product/work without any
modifications.
2. Accept the product/work with certain changes.
3. Reject the product/work due to errors.
Review summary report
1. What are reviewed?
2. Who reviewed it?
3. Findings of the review.
4. Conclusion.
18
Software Testing Unit 4
19
Software Testing Unit 4
20
Software Testing Unit 4
21
Software Testing Unit 4
Drivers and Stubs are software that must be written but that
is not delivered with the final software product.
1.
(a) Verification
(b) unit test.
(c) path errors.
(d) Boundary testing.
(e) overhead.
(f) simple, low.
(g) simplified, cohesion
(h) program structure, interfacing
(i) control, decision
22
Software Testing Unit 4
2.
(a) errors, omissions
(b) Acceptance
(c) alpha
(d) beta
(e) Regression
(f) Capture/playback
(g) regression test
(h) internal structures
(i) functions
(j) functional
3.
(a) test cases
(b) coverage criteria
(c) Static, execution path
(d) faults
(e) Static, semantic
(f) analysis, design, coding, testing, implementation.
(g) software quality assurance
(h) code walk through
(i) organization, goals
(j) code inspection
23
Software Testing Unit 4
24
Software Maintenance and Software Project ManagementUnit5
UNIT STRUCTURE
1
Software Maintenance and Software Project ManagementUnit5
5.2 INTRODUCTION
In the previous units, we learnt about the testing process of any
software. This gave us an introduction to the various software
testing methods depending upon the software type and nature that
are used to perform valid tests and analysis in order to produce a
high quality and error-free software product.
2
Software Maintenance and Software Project ManagementUnit5
3
Software Maintenance and Software Project ManagementUnit5
4
Software Maintenance and Software Project ManagementUnit5
5
Software Maintenance and Software Project ManagementUnit5
6
Software Maintenance and Software Project ManagementUnit5
Preventive maintenance
Computer software deteriorates due to change, and because of
this, preventive maintenance must be conducted to enable the
software to serve the needs of its end users. In essence,
preventive maintenance makes changes to computer programs so
that they can be more easily corrected, adapted, and enhanced.
Corrective maintenance
Corrective maintenance includes all the changes made to remove
actual faults in the software, and it can be called a reactive
modification of a software product performed after delivery to
correct discovered faults. Corrective maintenance changes the
software to correct defects. Corrective maintenance is universally
used to refer to maintenance for fault repair.
Perfective maintenance
Perfective maintenance refers to changes that originate from user
requests; examples include inserting, deleting, extending, and
modifying functions, rewriting documentation, improving
performances, or improving ease of use. Perfective maintenance
sometimes means perfecting the software by implementing new
requirements; in other cases it means maintaining the functionality
of the system but improving its structure and its performance. As
software is used, the customer/user will recognize additional
functions that will provide benefit. Perfective maintenance extends
the software beyond its original functional requirements.
7
Software Maintenance and Software Project ManagementUnit5
8
Software Maintenance and Software Project ManagementUnit5
9
Software Maintenance and Software Project ManagementUnit5
10
Software Maintenance and Software Project ManagementUnit5
11
Software Maintenance and Software Project ManagementUnit5
The term reverse engineering has its origins in the hardware world.
A company disassembles a competitive hardware product in an
effort to understand its competitor's design and manufacturing
"secrets." These secrets could be easily understood if the
competitor's design and manufacturing specifications were
obtained. But these documents are proprietary and unavailable to
the company doing the reverse engineering. In essence,
successful reverse engineering derives one or more design and
manufacturing specifications for a product by examining actual
specimens of the product.
Reverse engineering for software is quite similar. In most cases,
however, the program to be reverse engineered is not a
competitor's. Rather, it is the company's own work (often done
many years earlier). The "secrets" to be understood are obscure
because no specification was ever developed. Therefore, reverse
engineering for software is the process of analyzing a program in
12
Software Maintenance and Software Project ManagementUnit5
13
Software Maintenance and Software Project ManagementUnit5
14
Software Maintenance and Software Project ManagementUnit5
15
Software Maintenance and Software Project ManagementUnit5
16
Software Maintenance and Software Project ManagementUnit5
17
Software Maintenance and Software Project ManagementUnit5
18
Software Maintenance and Software Project ManagementUnit5
19
Software Maintenance and Software Project ManagementUnit5
20
Software Maintenance and Software Project ManagementUnit5
21
Software Maintenance and Software Project ManagementUnit5
Upper CASE: Upper CASE tools mainly focus on the analysis and
design phases of software development. They include tools for
analysis modeling, reports and forms generation.
Lower CASE: Lower CASE tools support implementation of
system development. They include tools for coding, configuration
management, etc.
Integrated CASE Tools: Integrated CASE tools help in providing
linkages between the lower and upper CASE tools. Thus creating a
cohesive environment for software development where
programming by lower CASE tools may automatically be
generated for the design that has been developed in an upper
CASE tool.
Need of CASE Tools
The software development process is expensive and as the
projects become more complex in nature, the project
implementations become more demanding and expensive. The
CASE tools provide the integrated homogenous environment for
the development of complex projects. They allow creating a shared
repository of information that can be utilized to minimize the
software development time. The CASE tools also provide the
environment for monitoring and controlling projects such that team
leaders are able to manage the complex projects.
22
Software Maintenance and Software Project ManagementUnit5
23
Software Maintenance and Software Project ManagementUnit5
Table 5.1
Estimating Size
Estimating the size of the software to be developed is the very first
step to make an effective estimation of the project. Customer
requirements and system specifications form a baseline for
estimating the size of software. At a later stage of the project,
system design documents can provide additional details for
estimating the overall size of the software.
The ways to estimate project size can be through past data
from an earlier developed system. This is called estimation
by analogy.
The other way of estimation is through product
feature/functionality. The system is divided into several
subsystems depending on functionality, and the size of
each subsystem is calculated.
24
Software Maintenance and Software Project ManagementUnit5
Estimating Effort
Once the size of software is estimated, the next step is to estimate
the effort based on the size. The estimation of effort can be made
from the organizational specifics of the software-development life-
cycle. The development of any application software system is more
than just the coding of the system. Depending on deliverable
requirements, the estimation of effort for a project will vary.
Efforts are estimated in the number of person-months.
The best way to estimate effort is based on the
organizations own historical data of development
processes. Organizations follow a similar development life-
cycle when developing various applications.
If the project is of a different nature, which requires the
organization to adopt a different strategy for development,
then different models based on algorithmic approaches can
be devised to estimate the required effort.
Estimating Schedules
The next step in the estimation process is estimating the project
schedule from the effort estimated. The schedule for a project will
generally depend on human resources involved in a process.
Efforts in person-months are translated to calendar months.
Schedule estimation in calendar months can be calculated using
the following model:
Schedule in calendar months = 3.0 * (person-months)1/3
The parameter 3.0 is variable, used depending on the situation that
works best for the organization.
Estimating Cost
Cost estimation is the next step for projects. The cost of a project
is derived not only from the estimates of effort and size but from
other parameters, such as hardware, travel expenses,
telecommunication costs, training costs, etc. Figure 5.12 depicts
the cost-estimation process.
25
Software Maintenance and Software Project ManagementUnit5
26
Software Maintenance and Software Project ManagementUnit5
27
Software Maintenance and Software Project ManagementUnit5
Basic COCOMO
Software Project ab bb cb db
Intermediate COCOMO
Product attributes
Required software reliability
Size of application database
28
Software Maintenance and Software Project ManagementUnit5
Software Project ai bi
Detailed COCOMO
29
Software Maintenance and Software Project ManagementUnit5
30
Software Maintenance and Software Project ManagementUnit5
Management of Risks
Risk management plays an important role in ensuring that the
software product is error-free. Firstly, risk management takes care
that the risk is avoided, and if it is not avoidable, then the risk is
detected, controlled and finally recovered.
31
Software Maintenance and Software Project ManagementUnit5
From Figure 5.15, it is clear that the first phase is to avoid risk by
anticipating and using tools from previous project histories. In the
case where there is no risk, the risk manager stops. In the case of
risk, detection is done using various risk analysis techniques and
further prioritizing risks. In the next phase, risk is controlled by
pending risks, resolving risks, and in the worst case lowering the
priority. Lastly, risk recovery is done fully, partially, or an alternate
solution is found.
1. Risk Avoidance
a) Risk Anticipation: Various risk anticipation rules are
listed according to standards from previous projects,
experience, and also as mentioned by the project
manager.
b) Risk Tools: Risk tools are used to test whether the
software is risk-free. The tools have a built-in
database of available risk areas and can be
updated depending upon the type of project.
2. Risk Detection
The risk-detection algorithm detects a risk and it can
be categorically stated as:
a) Risk Analysis: In this phase, the risk is analyzed
with various hardware and software parameters as
probabilistic occurrence (pr), weight factor (wf),
(hardware resources, lines of code, people), and
risk exposure (pr * wf).
32
Software Maintenance and Software Project ManagementUnit5
33
Software Maintenance and Software Project ManagementUnit5
Sources of Risks
There are two major sources of risks:
1. Generic Risks: Generic risks are the risks common to all
software projects. For example, requirement
misunderstanding, allowing insufficient time for testing,
losing key personnel, etc.
2. Project-Specific Risks: A vendor may be promising to
deliver particular software by a particular date, but is unable
to do it.
Types of Risks
There are three types of risks:
1. Product Risks: These are the risks that affect the quality
or performance of the software being developed. This
originates from conditions, such as unstable requirement
specifications, not being able to meet the design
specifications affecting software performance, and
uncertain test specifications. In view of the software product
risks, there is a risk of losing the business and facing
strained customer relations. For example, CASE tools
under performance.
2. Business Risks: These risks affect the organization
developing or procuring the software. For example,
technology changes and product competition. The top five
business risks are:
Building an excellent product or system that no one
really wants (market risks).
34
Software Maintenance and Software Project ManagementUnit5
35
Software Maintenance and Software Project ManagementUnit5
36
Software Maintenance and Software Project ManagementUnit5
37
Software Maintenance and Software Project ManagementUnit5
1.
(a) requirements
(b) maintenance
(c) reliability, structure
(d) Corrective
(e) technical, managerial
2.
(a) Reengineering
(b) Reverse engineering
(c) unstructured, restructured
(d) Version management systems
(e) Configuration, versions
3.
(a) CASE
(b) analysis, design
(c) estimating
(d) requirements, specifications
(e) human
(f) COCOMO
(g) scientific, game theory, decision theory, probability
theory, utility theory
(h) maximum, priority
(i) Product Risks
(j) Project
38
Software Maintenance and Software Project ManagementUnit5
39