JOSEPH AYO BABALOLA UNIVERSITY

Computer Science Department

Course Module

for

SEN 201

Introduction to Software Engineering

INTRODUCTION

Software Engineering is a first semester course. It is a two credit degree course

available to all students offering Computer Science. The course will enable you
to develop the skills necessary for you to develop, operate and maintain
software. They are no compulsory pre-requisites to it, although it is good to
have a basic knowledge of operating computer.

This course guide tells you briefly what the course about, what course
materials you will be using and how you can work with these materials. The
course will prepare you for challenges you will meet in the field of software
engineering.

COURSE AIM AND OBJECTIVES

The aim of the course is simple. The course aims to provide you with an
understanding of Software Engineering; it also aims to provide you with
solutions to problem in software as a whole.

Below are the comprehensive objectives of the course as a whole. By meeting

these objectives, you should have achieved the aims of the course as a whole.
In addition to the aims above, this course sets to achieve some objectives.
Thus, after going through the course, you be able to:

• Explain the basic concepts of software and software engineering

• Explain what software system is

• Give an overview of software design, development and testing.

• Explain software development life cycle model.

• Explain the software processes.

• Explain software requirements and specifications.

• Explain software project management.

• Explain Software evolution.

• Explain Software Quality and Testing

• Explain Software Quality Assurance

• Explain Software verification and Validation

 CHAPTER 1
BASIC CONCEPT OF SOFTWARE ENGINEERING
The Computer system has two major components namely hardware and
software. The hardware component is physical (can be touched or held). The
non-physical part of the computer system is the software. As the voice of man
is non-physical yet it so important for the complete performance of man, so is
the software.

WHAT IS SOFTWARE?

Software is more than just a program code. A program is an executable code,

which serves some computational purpose. Software is considered to be a
collection of executable programming code, associated libraries and
documentations. Software, when made for a specific requirement is called
software product. Software products may be generic (that is, developed to be
sold to a range of different customers) OR custom (that is, developed for a single
customer according to their specification).

SOFTWARE CHARACTERISTICS

To gain an understanding of SW, it is important to examine the characteristics

of software that make it different from other things that human being built.
When hardware is built, the human creative Process (analysis, design,
construction, testing) is ultimately translated into a physical form. Software is
a logical rather than a physical system element. Therefore, software has
characteristics that differ considerably from those of hardware:

 Operational: - This tells how good software works on operations

like budget, usability, efficiency, correctness, functionality,
dependability, security and safety.
 Transitional: - Transitional is important when an application is
shifted from one platform to another. So, portability, reusability
and adaptability come in this area.
 Maintenance: - This specifies how good software works in the
changing environment. Modularity, maintainability, flexibility
and scalability come in maintenance part.
 Software is developed or engineered; Software is developed or
engineered; it is not manufactured in the classical sense.
Although some similarities exist between software development
and hardware manufacture, the two activities are fundamentally
different.
 Software doesn't "wear out": The hardware exhibits relatively
 high failure rates early in its life (these failures are often
attributable to design or manufacturing defects); defects are
corrected and the failure rate drops to a steady-state level (Ideally,
quite low) for some period of time. As time passes, however, the
failure rate rises again as hardware components suffer from the
cumulative effects of dust, vibration, abuse, temperature
extremes, and many other environmental maladies.
 Most software is custom-built, rather than being assembled from
existing components.

TYPES OF SOFTWARE
Software can be categorized into three major types namely system software,
programming software and application software.
1. System software helps to run the computer hardware and the entire
computer system. It includes the following:
• Device drivers
• Operating systems
• Servers
• Utilities
The function of systems software is to assist the applications programmer from
the details of the particular computer complex being used, including such
peripheral devices as communications, printers, readers, displays and
keyboards, and also to partition the computer's resources such as memory and
processor time in a safe and stable manner.
2. Programming software offers tools to assist a programmer in writing
programs, and software using different programming languages in a
more convenient way. The tools include:
• Compilers
• debuggers
• Interpreters
• Linkers
• Text editors
3. Application software is a class of software which the user of computer
needs to accomplish one or more definite tasks. The common
applications include the following:
• Industrial automation and molecular modeling software
• Business software and Word processing
• Computer games and photo-editing
• Quantum chemistry and solid state physics software
• Telecommunications (i.e., the internet and everything that flows on it)
• Databases and Spreadsheet
• Educational, medical and military software
• Decision making software etc.

SOFTWARE APPLICATIONS
Software may be applied in any situation for which a pre-specified set of
procedural steps (i.e., an algorithm) has been defined (notable exceptions to
this rule are expert system software and neural network software). For
example, many business applications use highly structured input data (a
database) and produce formatted “reports”. Software that controls an
automated machine (e.g., a numerical control) accepts discrete data items with
limited structure and produces individual machine commands in rapid
succession. Notable Software Applications are listed below:
Artificial Intelligence (AI) software
 AI software is made to think like human beings and therefore it is useful
in solving complex problems automatically.
 Game playing, speech recognition, understanding natural language.
Computer vision, expert systems, robotics are some applications of AI
software.
Embedded software
 Embedded software is a type of software that is built into hardware
systems.
 Controllers, real-time operating systems, communication protocols are
some examples of embedded software.
Engineering /Scientific software
 Engineering problems and quantitative analysis are carried out using
automated tools.
 Scientific software is typically used to solve mathematical functions and
calculations.
 Computer-aided design and computer-aided manufacturing software
(CAD/CAM), Electronic design automation (EDA), Embedded System
Software (ESS), statistical process control software (SPCS), civil
engineering and architectural software, math calculation software,
modeling and simulation software, etc.., are the examples of engineering
scientific software.
Web software
 Web applications are based on client server architecture, where the client
requests information and the server stores and retrieves information
from the web software.
 Examples include HTML 5.0, JSP, ASP, PHP etc.
Product-Line software
 Product-line software is a set of software intensive systems that share a
common, managed set of features to satisfy the specific needs of a
particular market segment or mission.
 Some common applications are multimedia, database software, word
processing software, etc.
Legacy Programs/ Legacy Software: Today, a growing population of legacy
programs is forcing many companies to pursue software reengineering
strategies. The term legacy programs are a euphemism for older, often poorly
designed and documented software that is business critical and must be
supported over many years. Some legacy systems have relatively solid program
architecture, but individual CHAPTERs were coded in a way that makes them
difficult to understand, test, and maintain. In such cases, the code within the
suspect CHAPTERs can be restructured.

WHAT IS SOFTWARE ENGINEERING?

Software engineering is the application of a systematic, disciplined, quantifiable
approach to the development, operation, and maintenance of software, and the
study of these approaches. In other words, it is the application of engineering
to software. It is an engineering, technological, and managerial discipline that
provides a systematic approach to the development, operation, and
maintenance of software.

SUB-DISCIPLINES OF SOFTWARE ENGINEERING

Software engineering can be divided into ten sub-disciplines. They are as
follows:
• Software requirements: The elicitation, analysis, specification, and
validation of requirements for software.
• Software design: Software Design consists of the steps a programmer
should do before they start coding the program in a specific language. It is
usually done with Computer-Aided Software Engineering (CASE) tools and use
standards for the format, such as the Unified Modeling Language (UML).
• Software development: It is construction of software through the use of
programming languages.
• Software testing: Software Testing is an empirical investigation
conducted to provide stakeholders with information about the quality of the
product or service under test.
• Software maintenance: This deals with enhancements of Software
systems to solve the problems they may have after being used for a long time
after they are first completed.
• Software configuration management: is the task of tracking and
controlling changes in the software. Configuration management practices
include revision control and the establishment of baselines.
• Software engineering management: The management of software systems
borrows heavily from project management.
• Software development process: A software development process is a
structure imposed on the development of a software product. There are several
models for such processes, each describing approaches to a variety of tasks or
activities that take place during the process.
• Software engineering tools, (CASE which stands for Computer Aided
Software Engineering) CASE tools are a class of software that automates many
of the activities involved in various life cycle phases.
• Software quality: The totality of functionality and features of a software
product that bear on its ability to satisfy stated or implied needs.

SOFTWARE ENGINEERING GOALS AND PRINCIPLES

The software engineering goals include:
• Maintainability: Changes to software without increasing the complexity
of the original system design should be possible.
• Reliability: The software should be able to prevent failure in design and
construction as well as recover from failure in operation. In other words, the
software should perform its intended function with the required precision at all
times.
• Efficiency: The software system should use the resources that are
available in an optimal manner.
• Understand ability: The software should accurately model the view the
reader has of the real world. Since code in a large, long-lived software system is
usually read more times than it is written, it should be easy to read at the
expense of being easy to write, and not the other way around.

The software engineering Principles include:

Sound engineering principles must be applied throughout development, from
the design phase to final fielding of the system in order to attain a software
system that satisfies the above goals. These include:
• Abstraction: The purpose of abstraction is to bring out essential
properties while omitting inessential detail. The software should be organized
as a ladder of abstraction in which each level of abstraction is built from lower
levels. The code is sufficiently conceptual so the user need not have a great
deal of technical background in the subject. The reader should be able to easily
follow the logical path of each of the various CHAPTERs. The decomposition of
the code should be clear.
• Information Hiding: The code should include no needless detail.
Elements that do not affect other segment of the system are inaccessible to the
user, so that only the intended operations can be performed. There are no
"undocumented features".
• Modularity: The code is purposefully structured. Components of a given
CHAPTER are logically or functionally dependent.
• Localization: The breakdown and decomposition of the code is rational.
Logically related computational units are collected together in CHAPTERs.
• Uniformity: The notation and use of comments, specific keywords and
formatting is consistent and free from unnecessary differences in other parts of
the code.
• Completeness: Nothing is deliberately missing from any CHAPTER. All
important or relevant components are present both in the CHAPTERs and in
the overall system as appropriate.
• Confirm ability: The CHAPTERs of the program can be tested
individually with adequate rigor. This gives rise to a more readily alterable
system, and enables the reusability of tested components.

In-Text Question
1. What do you understand by the term “Software Engineering”?
2. Discuss the basic Software Engineering Principles?
 CHAPTER TWO
SOFTWARE ENGINEERING DEVELOPMENT

Overview of Software Engineering

In the 1968, software engineering originated from the NATO Software

Engineering Conference. It came at the time of software crisis. The field of
software engineering has since then been growing gradually as a study
dedicated to creating qualified software. In spite of being around for a long
time, it is a relatively young field compared to other fields of engineering.
Though some people are still confused whether software engineering is actually
engineering because software is more of invisible course. Although it is
disputed what impact it has had on actual software development over the last
more than 40 years, the field's future looks bright according to Money
Magazine and [Link] who rated "software engineering" as the best job in
America in 2006.

The early computers had their software wired with the hardware thereby
making them to be inflexible because the software could not easily be upgraded
from one machine to another. This problem necessitated the development.
Programming languages started to appear in the 1950s and this was also
another major step in abstraction. Major languages such as FORTRAN, ALGOL,
and COBOL were released in the late 1950s to deal with scientific, algorithmic,
and business problems respectively. E.W. Dijkstra wrote his seminal paper,
"Go To Statement Considered Harmful", in 1968 and David Parnas introduced
the key concept of modularity and information hiding in 1972 to help
programmers deal with the ever increasing complexity of software systems. A
software system for managing the hardware called an operating system was
also introduced, most notably by Unix in 1969. In 1967, the Simula language
introduced the object-oriented programming paradigm.

The technological advancement in software has always been driven by the ever
changing manufacturing of various types of computer hardware. The more the
new technologies upgrades, from vacuum tube to transistor, and to
microprocessor were emerging, the more the necessity to upgrade and even
write new software. In the mid-1980s software experts had a consensus for
centralized construction of software with the use of software development Life
Cycle from system analysis. This period gave birth to object-oriented
programming languages. Open-source software started to appear in the early
90s in the form of Linux and other software introducing the "bazaar" or
decentralized style of constructing software. Then the Internet and World Wide
Web hit in the mid-90s changing the engineering of software once again.
Distributed Systems gained sway as a way to design systems and the Java
programming language was introduced as another step in abstraction having
its own virtual machine. Programmers collaborated and wrote the Agile
Manifesto that favored more light weight processes to create cheaper and
timelier software.

The birth of internet played a major role in software engineering. With its
arrival, information could be gotten from the World Wide Web speedily.
Programmers could handle illustrations, maps, photographs, and other images,
plus simple animation, at a very fast rate.

It became easier to display and retrieve information as a result of the usage of

browser on the HTML language. The widespread of network connections
brought in computer viruses and worms on MS Windows computers. These
new technologies brought in a lot good innovations such as e-mailing, web-
based searching, e-education to mention a few. As a result, many software
systems had to be re-designed for international searching. It was also required
to translate the information flow in multiple foreign languages. Many software
systems were designed for multi-language usage, based on design concepts
from human translators.

Year 2000-present era witnessed increasing demand for software in many

smaller organizations. There was also the need for inexpensive software
solutions and this led to the growth of simpler, faster methodologies that
developed running software, from requirements to deployment. There was a
change from rapid-prototyping to entire lightweight methodologies. For
example, Extreme Programming (XP), tried to simplify many areas of software
engineering, including requirements gathering and reliability testing for the
growing, vast number of small software systems.

Today, Software Engineering as a profession is now being defined as a field of

human experts in boundary and content. Software Engineering is rated as one
of the best job in developed economies in terms of growth, pay, and flexibility
and so on.

SOFTWARE ENGINEER
A software engineer is an individual who applies the principles of software
engineering to the design, development, testing, and evaluation of the software
and systems in order to meet with client‘s requirements. He/she fully designs
software, tests, debugs and maintains it. Software engineer needs knowledge of
varieties of computer programming languages and applications; to enable him
cope with the varieties of works before him. In view of this, he can sometimes
be referred to as a computer programmer.
The functions of a software engineer include:
• Analyses information to determine, recommend, and plan computer
specifications and layouts, and peripheral equipment modifications.
• Analyses user needs and software requirements to determine feasibility
of design within time and cost constraints.
• Coordinates software system installation and monitor equipment
functioning to ensure specifications are met.
• Designs, develops and modifies software systems, using scientific
analysis and mathematical models to predict and measure outcome and
consequences of design.
• Determines system performance standards.
• Develops and direct software system testing and validation procedures,
programming, and documentation.
• Modifies existing software to correct errors; allow it to acclimatize to new
hardware, or to improve its performance.
• Obtains and evaluates information on factors such as reporting formats
required, costs, and security needs to determine hardware configuration.
• Stores, retrieves, and manipulates data for analysis of system
capabilities and requirements.

EVOLUTION OF SOFTWARE ENGINEERING

There are a number of areas where the evolution of software engineering is
notable:
• Professionalism: The early 1980s witnessed software engineering
becoming a full-fledged profession like computer science and other engineering
fields.
• Impact of women: In the early days of computer development (1940s,
1950s, and 1960s,), the men were found in the hardware sector because of the
mental demand of handling heavy duty equipment which was too strenuous for
women. The writing of software was delegated to the women. Some of the
women who were into many programming jobs at this time include Grace
Hopper and Jamie Fenton. Today, many fewer women work in software
engineering than in other professions, this reason for this is yet to be
ascertained.
• Processes: Processes have become a great part of software engineering
and re praised for their ability to improve software and sharply condemned for
their potential to narrow programmers.
• Cost of hardware: The relative cost of software versus hardware has
changed substantially over the last 50 years. When mainframes were costly
and needed large support staffs, the few organizations purchasing them also
had enough to fund big, high-priced custom software engineering projects.
Computers can now be said to be much more available and much more
powerful, which has a lot of effects on software. The larger market can sustain
large projects to create commercial packages, as the practice of companies
such as Microsoft. The inexpensive machines permit each programmer to have
a terminal capable of fairly rapid compilation. The programs under
consideration can use techniques such as garbage collection, which make them
easier and faster for the programmer to write. Conversely, many fewer
organizations are concerned in employing programmers for large custom
software projects, instead using commercial packages as much as possible.

The Pioneering Era

The most key development was that new computers were emerging almost
every year or two, making existing ones outdated. Programmers had to rewrite
all their programs to run on these new computers. They did not have
computers on their desks and had to go to the "computer room" or ―computer
laboratory‖. Jobs were run by booking for machine time or by operational staff.
Jobs were run by inserting punched cards for input into the computer‘s card
reader and waiting for results to come back on the printer.

The field was so new that the idea of management using schedule was absent.
Guessing the completion time of project predictions was almost unfeasible
Computer hardware was application-based. Scientific and business tasks
needed different machines. High level languages like FORTRAN, COBOL, and
ALGOL were developed to take care of the need to frequently translate old
software to meet the needs of new machines. Systems software was given out
for free by the vendors since it must to be installed in the computer before it is
sold. Custom software was sold by a few companies but no sale of packaged
software. Organization such as like IBM's scientific user group SHARE gave out
software free and as a result reuse was order of the day. Academia did not yet
teach the principles of computer science. Modular programming and data
abstraction were already being used in programming.

1945 to 1965: The origins

The term software engineering came into existence in the late 1950s and early
1960s. Programmers have always known about civil, electrical, and computer
engineering but found it difficult to marry engineering with software.

In 1968 and 1969, two conferences on software engineering were sponsored by

the NATO Science Committee. This gave the field its initial boost. It was widely
believed that these conferences marked the official start of the profession of
software engineering.

1965 to 1985: The software crisis

Software engineering was prompted by the software crisis of the 1960s, 1970s,
and 1980s. It was the crisis that identified many of the problems of software
development. This era was also characterized by: run over budget and
schedule, property damage and loss of life caused by poor project management.
Initially the software crisis was defined in terms of productivity, but advanced
to emphasize quality.
• Cost and Budget Overruns: The OS/360 operating system was a classic
example. It was a decade-long project from the 1960s and eventually produced
one of the most complex software systems at the time.
• Property Damage: Software defects can result in property damage. Poor
software security allows hackers to steal identities, costing time, money, and
reputations.
• Life and Death: Software defects can kill. Some embedded systems used
in radiotherapy machines failed so disastrously that they administered
poisonous doses of radiation to patients. The most famous of these failures is
the Therac 25 incident.

1985 to 1989: No silver bullet

For years, solving the software crisis was the primary concern for researchers
and companies producing software tools. Apparently, they proclaim every new
technology and practice from the 1970s to the 1990s as a silver bullet to solve
the software crisis. Tools, discipline, formal methods, process, and
professionalism were published as silver bullets:
• Tools: Particularly underline tools include: Structured programming,
object- oriented programming, CASE tools, Ada, Java, documentation,
standards, and Unified Modeling Language were touted as silver bullets.
• Discipline: Some pundits argued that the software crisis was due to the
lack of discipline of programmers.
• Formal methods: Some believed that if formal engineering methodologies
would be applied to software development, then production of software would
become as predictable an industry as other branches of engineering. They
advocated proving all programs correct.
• Process: Many advocated the use of defined processes and methodologies
like the Capability Maturity Model.
• Professionalism: This led to work on a code of ethics, licenses, and
professionalism.

Fred Brooks (1986), No Silver Bullet article, argued that no individual

technology or practice would ever make a 10-fold improvement in productivity
within 10 years.

Debate about silver bullets continued over the following decade. Supporter for
Ada, components, and processes continued arguing for years that their favorite
technology would be a silver bullet. Skeptics disagreed. Eventually, almost
everyone accepted that no silver bullet would ever be found. Yet, claims about
silver bullets arise now and again, even today.

” No silver bullet” means different things to different people; some take” no

silver bullet” to mean that software engineering failed. The pursuit for a single
key to success never worked. All known technologies and practices have only
made incremental improvements to productivity and quality. Yet, there are no
silver bullets for any other profession, either. Others interpret no silver bullet
as evidence that software engineering has finally matured and recognized that
projects succeed due to hard work.

However, it could also be pointed out that there are, in fact, a series of silver
bullets today, including lightweight methodologies, spreadsheet calculators,
customized browsers, in-site search engines, database report generators,
integrated design-test coding-editors with memory/differences/undo, and
specialty shops that generate niche software, such as information websites, at
a fraction of the cost of totally customized website development. Nevertheless,
the field of software engineering looks as if it is too difficult and different for a
single "silver bullet" to improve most issues, and each issue accounts for only a
small portion of all software problems.
1990 to 1999: Importance of the Internet
The birth of internet played a major role in software engineering. With its
arrival, information could be gotten from the World Wide Web speedily.
Programmers could handle illustrations, maps, photographs, and other images,
plus simple animation, at a very fast rate.

It became easier to display and retrieve information as a result of the usage of

browser on the HTML language. The widespread of network connections
brought in computer viruses and worms on MS Windows computers. These
new technologies brought in a lot good innovations such as e-mailing, web-
based searching, e-education to mention a few. As a result, many software
systems had to be re-designed for international searching. It was also required
to translate the information flow in multiple foreign languages. Many software
systems were designed for multi-language usage, based on design concepts
from human translators.

2000 to Present: Lightweight Methodologies

This era witnessed increasing demand for software in many smaller
organizations. There was also the need for inexpensive software solutions and
this led to the growth of simpler, faster methodologies that developed running
software, from requirements to deployment. There was a change from rapid-
prototyping to entire lightweight methodologies. For example, Extreme
Programming (XP), tried to simplify many areas of software engineering,
including requirements gathering and reliability testing for the growing, vast
number of small software systems.

What is it today?
Software Engineering as a profession is now being defined as a field of human
experts in boundary and content. Software Engineering is rated as one of the
best job in developed economies in terms of growth, pay, and flexibility and so
on.

In-Text Question
1. Discuss the historical development of software engineering?
2. State four (4) functions of a Software Engineering?
 CHAPTER THREE
SOFTWARE ENGINEERING METHODOLOGIES
A software engineering methodology is a set of procedures followed from the
beginning to the completion of the development process. The most popular
software methodologies are:
• Exploratory methodology
• Structure-oriented methodology
• Data-structure-oriented methodology
• Object oriented Methodology
• Component-based development methodology

Exploratory Methodology:
 Exploratory style uses unstructured programming or design heuristics
for program writing, where the focus is given on global data items.
 Unstructured languages ,such as assembly or low-level languages,
BASIC, etc., consists of a sequence of commands or statements ,such as
labels, GOTO ,etc.,
 State-oriented models, such as flow charts, finite state machines (for
example, DFAs, NFAs, PDAs,),Turing machines, etc., are used for the
design of algorithms

STRUCTURE ORIENTED METHODOLOGY

 Structured methodology focuses on procedural approach, which,
concentrates on developing functions or procedures.
 It uses the features of the unstructured programming and provides
certain improvements.
 It has three basic elements, namely,
Sequence: The order in which instructions are executed is the sequence of
programming.
Selection: If else condition statements and other forms of selection from the
second element. It is because of selection that programs react to choices.
Iteration: The use of loops and other forms of repetitive sets of instructions
forms the last building block of procedural programming.
 Structure oriented methodology uses a variety of notations, such as data
flow diagrams (DFD),data dictionary ,control flow graphs(CFG),entity
relationship(ER)diagrams ,etc., to design the solutions to the problem.
 Structured –oriented approach is preferred in scripts and embedded
systems with small memory requirements and high speed.
DATA-STRUCTURE-ORIENTED METHODOLOGY
 Data-structure-oriented methodology concentrates more on designing
data structures rather than on procedures and control.
 Jackson structured design (JSD) methodology developed by Michael
Jackson in 1970 is a famous Data-structure-oriented methodology that
expresses how functionality fits in with the real world.
 It describes the real world in terms of entities, actions, and ordering of
actions.
 JSD-Based development proceeds in two stages: firstly, specifications
that determines “what”, and secondly, implementation that determines
“How”.
 JSD is a useful methodology for concurrent software, real time software,
micro code, and for parallel computers.

OBJECT-ORIENTED-METHODOLOGY
 Object oriented methodology emphasizes the use of data rather than
functions.
 Object oriented methodology has three important concepts: Modularity,
Abstraction and Encapsulation.
 Object oriented analysis (OOA) and Object oriented design (OOD)
Techniques are used in Object oriented methodology.
 OOA is used to understand the requirements by identifying the objects
and classes, their relations to other classes, their attributes, and the
inheritance relations ship among them
 OOD creates object models and maps the real world situation into the
software structure.

COMPONENT-BASED DEVELOPMENT METHODOLOGY (CBD)

 Component-based development (CBD) becomes significant methodology
for communication among different stake holders and for large-scale
reuse.
 CBD is a system analysis and design methodology that has evolved from
the Object oriented methodology.
 CBD employs are architectural elements, such as user interface layer:
business layer that includes process components business domain
components and the business infrastructure components and technical
infrastructure components and technical infrastructure layer

SOFTWARE ENGINEERING CHALLENGES

We will briefly discuss some software engineering challenges:
(1) PROBLEM UNDERSTANDING
 There are several issues involved in problem understanding.
 Usually customers are from different backgrounds and they do not have a
clear understanding of their problems and requirements.
 Also, the customers don’t have technical knowledge, especially those who
are living in remote areas.
 Similarly, software Engineers do not have the knowledge of all
application domains and detailed requirements of the problems and the
expectations of the customer.
 The lack of communication among software engineers and customers
causes problems for the software engineers in clearly understanding the
customer needs.
 Sometimes the customers do not have the sufficient time to explain their
problems to development organization
(2) QUALITY AND PRODUCTIVITY
 Quality products provide customer satisfaction.
 A good quality products implements features that are required by the
customer.
 Systematic software engineering practices produce products that have
certain quality attributes, such as reliability, usability, efficiency,
maintainability, portability and functionality.
 Production of software is measured in terms of KLOC per person month
(PM). Software companies focus on improving the productivity of the
software, i.e., increasing the number of KLOC per PM.
 Higher productivity means that cycle time can be reduced with the low
cost of the product.
 But the productivity and the quality of the software depend on several
factors, such as programmer’s ability, type of technology, level of
experience, nature of the projects and their complexity, available time,
development and maintenance approach, stability of requirements,
managerial skills, required resources, etc.
(3) CYCLE TIME AND COST
 Software companies put efforts to reduce the cycle time of product
delivery and minimize the product cost.
 The cost of the software product is generally the cost of the software,
hardware and manpower resources.
 It is calculated on the basis of the number of the person engaged in a
project and for how much time. The cost of the product also depends on
the project size and nature.
  There are some other factors that can affect the time to market and cost,
such as level of technology, application experience, and the availability of
the required resource.
 Higher the cycle time higher the product cost.
 The cost is finally converted into a dollar amount for standard
representation.
(4) RELIABILITY
 Verification and the validation techniques are used to ensure the
reliability ratio in the product.
 Defect Detection and the prevention is the prerequisite to high reliability
in the product.
 Software becomes unreliable due to logical errors present in the
programs of the software.
 Project complexity is the major issue cause of software unreliability.
 Due to unreliable software more than hundred failures were reported in a
day at a single air traffic control location in 1989; 22 fatal crashes of the
fly-by-wire UH-60 helicopter took place; patients were given the fatal
doses by malfunctioning hospital computers. Therefore Software
engineers spend more than 75% of time on development in keeping the
computer and software up to date.
(5) CHANGE AND MAINTENANCE:
 Change and maintenance in software come when the software is
delivered and deployed at the customer site.
 They occur if there is any change in the business operations, errors in
the software, addition of some new features.
 Due to repeated maintenance and change, software deteriorates its
operational life and quality.
 Thus to accommodate increasing requirements and stream line the
modern technology, software is needed to be reengineered on to a
modern platform.
(6) USABILITY AND REUSABILITY
 Usability means the ease of use of a product in terms of efficiency,
effectiveness, and customer satisfaction.
 Reuse of the existing software components and their development has
become an institutional business in the modern software business
scenario.
 The analysis of domain knowledge, development of reusable library, and
integration of reusable of components in software development are some
important issues in reuse based development.
  Reusability increases reliability because reusable components are well
tested before integrating them into software development.
(7) REPEATABILITY AND PROCESS MATURITY
 Repeatability maintains the consistency of product quality and
productivity.
 Repeatability can help to plan project schedule, its deadlines for product
delivery, manage configuration, and identify locations of bug
occurrences.
 Repeatability promotes process maturity.
 A maturity software process produces quality products and improves
software productivity.
 There are several standards, such as CMM, ISO and Six sigma, which
emphasize process maturity and guidelines.

In-Text Question
1. Discuss briefly, some of the Software Engineering Challenges?
2. Expatiate on Software Engineering Methodologies?
 CHAPTER FOUR
SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC)
Software development is the set of activities that results in software products.
Software development may include research, new development, modification,
reuse, re-engineering, maintenance, or any other activities that result in
software products. Particularly the first phase in the software development
process may involve many departments, including marketing, engineering,
research and development and general management. The term software
development may also refer to computer programming, the process of writing
and maintaining the source code.

There are several different approaches to software development. While some

take a more structured, engineering-based approach, others may take a more
incremental approach, where software evolves as it is developed piece-by-piece.
These stages are collectively referred to as the software development lifecycle
(SDLC).

The Software Development Lifecycle is a systematic process for building

software that ensures the quality and correctness of the software built. SDLC
process aims to produce high- quality software which meets customer
expectations. The software development should be complete in the pre-defined
time frame and cost. It consists of a detailed plan describing how to develop,
maintain and replace specific software. Software life cycle models describe
phases of the software cycle and the order in which those phases are executed.
Each phase produces deliverables required by the next phase in the life cycle. A
typical Software Development Life Cycle (SDLC) consists of the following
phases:
1. Requirement gathering
2. System Analysis
3. Design
4. Development /Implementation or coding
5. Testing
6. Deployment
7. Maintenance

1. Requirement gathering:
 Requirement gathering and analysis is the most important phase in
software development lifecycle. Business Analyst collects the requirement
from the Customer/Client as per the client’s business needs and documents
the requirements in the Business Requirement Specification.
 This phase is the main focus of the project managers and stake holders.
Meetings with managers, stake holders and users are held in order to
determine the requirements like; who is going to use the system? How
will they use the system? What data should be input into the system?
What data should be output by the system?
2. Analysis Phase:
 Once the requirement gathering and analysis is done the next step is to
define and document the product requirements and get them approved
by the customer. This is done through SRS (Software Requirement
Specification) document.
 SRS consists of all the product requirements to be designed and
developed during the project life cycle.
 Key people involved in this phase are Project Manager, Business Analysis
and senior members of the Team.
 The outcome of this phase is Software Requirement Specification.
3. Design Phase:
 In this third phase the system and software design is prepared from the
requirement specifications which were studied in the first phase.
 System Design helps in specifying hardware and system requirements
and also helps in defining overall system architecture.
  There are two kinds of design documents developed in this phase:
 High-Level Design (HLD): It gives the architecture of the software product
to be developed and is done by architects and senior developers. It gives
brief description and name of each CHAPTER. It also defines interface
relationship and dependencies between CHAPTERs, database tables
identified along with their key elements
 Low-Level Design (LLD): It is done by senior developers. It describes how
each and every feature in the product should work and how every
component should work. Here, only the design will be there and not the
code. It defines the functional logic of the CHAPTERs, database tables
design with size and type, complete detail of the interface. Addresses all
types of dependency issues and listing of error messages.
4. Coding/Implementation Phase:
 In this phase, developers start builds the entire system by writing code
using the chosen programming language.
 Here, tasks are divided into units or CHAPTERs and assigned to the
various developers. It is the longest phase of the Software Development
Life Cycle process.
 In this phase, Developer needs to follow certain predefined coding
guidelines. They also need to use programming tools like compiler,
interpreters, debugger to generate and implement the code.
 The outcome from this phase is Source Code Document (SCD) and the
developed product.
5. Testing Phase:
 After the code is developed it is tested against the requirements to make
sure that the product is actually solving the needs addressed and
gathered during the requirements phase.
 They either test the software manually or using automated testing tools
depends on process defined in STLC (Software Testing Life Cycle) and
ensures that each and every component of the software works fine. The
development team fixes the bug and sends back to QA for a re-test. This
process continues until the software is bug-free, stable, and working
according to the business needs of that system.
6. Deployment:
After successful testing the product is delivered/deployed to the customer for
their use. As soon as the product is given to the customers they will first do the
beta testing. If any changes are required or if any bugs are caught, then they
will report it to the engineering team. Once those changes are made or the bugs
are fixed then the final deployment will happen.
7. Maintenance:
Software maintenance is a vast activity which includes optimization, error
correction, and deletion of discarded features and enhancement of existing
features. Since these changes are necessary, a mechanism must be created for
estimation, controlling and making modifications. The essential part of
software maintenance requires preparation of an accurate plan during the
development cycle. Typically, maintenance takes up about 40-80% of the
project cost, usually closer to the higher pole. Hence, a focus on maintenance
definitely helps keep costs down.

SOFTWARE MYTHS

Software myths—erroneous beliefs about software and the process that is used
to build it— can be traced to the earliest days of computing. Myths have a
number of attributes that make them insidious.

Managers with software responsibility, like managers in most disciplines, are

often under pressure to maintain budgets, keep schedules from slipping, and
improve quality. Like a drowning person who grasps at a straw, a software
manager often grasps at belief in a software myth, if that belief will lessen the
pressure (even temporarily).

Myth: We already have a book that’s full of standards and procedures for
building software. Won’t that provide my people with everything they
need to know?

Reality: The book of standards may very well exist, but is it used? Are software
practitioners aware of its existence? Does it reflect modern software
engineering practice? Is it complete? Is it adaptable? Is it streamlined to
improve time-to-delivery while still maintaining a focus on quality? In many
cases, the answer to all of these questions is “no.”

Myth: If we get behind schedule, we can add more programmers and catch
up (sometimes called the “Mongolian horde” concept).

Reality: Software development is not a mechanistic process like

manufacturing. In the words of Brooks [Bro95]: “adding people to a late
software project makes it later.” At first, this statement may seem counter
intuitive. However, as new people are added, people who were working must
spend time educating the newcomers, thereby reducing the amount of time
spent on productive development effort. People can be added but only in a
planned and well-coordinated manner.

Myth: If I decide to outsource the software project to a third party, I can

just relax and let that firm build it.

Reality: If an organization does not understand how to manage and control

software projects internally, it will invariably struggle when it outsources
software projects.

Customer myths.
A customer who requests computer software may be a person at the next desk,
a technical group down the hall, the marketing/sales department, or an
outside company that has requested software under contract. In many cases,
the customer believes myths about software because software managers and
practitioners do little to correct misinformation. Myths lead to false
expectations (by the customer) and, ultimately, dissatisfaction with the
developer.

Myth: A general statement of objectives is sufficient to begin writing

programs—we can fill in the details later.

Reality: Although a comprehensive and stable statement of requirements is

not always possible, an ambiguous “statement of objectives” is a recipe for
disaster. Unambiguous requirements (usually derived iteratively) are developed
only through effective and continuous communication between customer and
developer.

Myth: Software requirements continually change, but change can be easily

accommodated because software is flexible.

Reality: It is true that software requirements change, but the impact of change
varies with the time at which it is introduced. When requirements changes are
requested early (before design or code has been started), the cost impact is
relatively small. However, as time passes, the cost impact grows rapidly—
resources have been committed, a design framework has been established, and
change can cause upheaval that requires additional resources and major
design modification.
Practitioner’s myths
Myths that are still believed by software practitioners have been fostered by
over 50 years of programming culture. During the early days, programming
was viewed as an art form. Old ways and attitudes die hard.

Myth: Once we write the program and get it to work, our job is done.

Reality: Someone once said that “the sooner you begin ‘writing code,’ the
longer it’ll take you to get done.” Industry data indicate that between 60 and 80
percent of all effort expended on software will be expended after it is delivered
to the customer for the first time.

Myth: Until I get the program “running” I have no way of assessing its
quality.

Reality: One of the most effective software quality assurance mechanisms can
be applied from the inception of a project—the technical review. Software
reviews (described in Chapter 15) are a “quality filter” that have been found to
be more effective than testing for finding certain classes of software defects.

Myth: The only deliverable work product for a successful project is the
working program.

Reality: A working program is only one part of a software configuration that

includes many elements. A variety of work products (e.g., models, documents,
plans) provide a foundation for successful engineering and, more important,
guidance for software support.

Myth: Software engineering will make us creates voluminous and

unnecessary documentation and will invariably slow us down.

Reality: Software engineering is not about creating documents. It is about

creating a quality product. Better quality leads to reduced rework. And reduced
rework results in faster delivery times.

In-Text Question
1. What is software life cycle model?
2. Mention three myths and realities of software?
 CHAPTER FIVE
SOFTWARE REQUIREMENTS AND SPECIFICATION
Business requirements are gathered in this phase. This phase is the main
center of attention of the project managers and stake holders. Meetings with
managers, stake holders and users are held in order to determine the
requirements. The general questions that require answers during a
requirements gathering phase are: Who is going to use the system? How will
they use the system? What data should be input into the system?
What data should be output by the system? A list of functionality that the
system should provide, which describes functions the system should perform,
business logic that processes data, what data is stored and used by the
system, and how the user interface should work is produced at this point. The
requirements development phase may have been preceded by a feasibility
study, or a conceptual analysis phase of the project. The requirements phase
may be divided into requirements elicitation (gathering the requirements from
stakeholders), analysis (checking for consistency and completeness),
specification (documenting the requirements) and validation (making sure the
specified requirements are correct)

In systems engineering, a requirement can be a description of what a system

must do, referred to as a Functional Requirement. This type of requirement
specifies something that the delivered system must be able to do. Another type
of requirement specifies something about the system itself, and how well it
performs its functions. Such requirements are often called Non-functional
requirements, or 'performance requirements' or 'quality of service
requirements.' Examples of such requirements include usability, availability,
reliability, supportability, testability, maintainability, and (if defined in a way
that's verifiably measurable and unambiguous) ease-of-use.

Types of Requirements
Requirements are categorized as:
• Functional requirements which describe the functionality that the
system is to execute; for example, formatting some text or modulating a signal.
• Non-functional requirements which are the ones that acts to constrain
the solution. Nonfunctional requirements are sometimes known as quality
requirements or Constraint requirements No matter how the problem is solved
the constraint requirements must be adhered to.

It is important to note that functional requirements can be directly

implemented in software. The non-functional requirements are controlled by
other aspects of the system. For example, in a computer system reliability is
related to hardware failure rates, performance controlled by CPU and memory.
Non-functional requirements can in some cases be broken into functional
requirements for software. For example, a system level non-functional safety
requirement can be decomposed into one or more functional requirements. In
addition, a non-functional requirement may be converted into a process
requirement when the requirement is not easily measurable. For example, a
system level maintainability requirement may be decomposed into restrictions
on software constructs or limits on lines or code.

Requirements analysis
Requirements analysis in systems engineering and software engineering,
consist of those activities that go into determining the needs or conditions to
meet for a new or altered product, taking account of the possibly conflicting
requirements of the various stakeholders, such as beneficiaries or users.

Requirements analysis is critical to the success of a development project.

Requirements must be actionable, measurable, testable, related to identified
business needs or opportunities, and defined to a level of detail sufficient for
system design.

The Need for Requirements Analysis

Studies reveal that insufficient attention to Software Requirements Analysis at
the beginning of a project is the major reason for critically weak projects that
often do not fulfill basic tasks for which they were designed. Software
companies are now spending time and resources on effective and streamlined
Software Requirements Analysis Processes as a condition to successful projects
that support the customer‘s business goals and meet the project‘s requirement
specifications.

Requirements Analysis Process: Requirements Elicitation, Analysis and

Specification
Requirements Analysis is the process of understanding the client needs and
expectations from a proposed system or application. It is a well-defined stage in
the Software Development Life Cycle model. Requirements are a description of
how a system should behave, in other words, a description of system properties
or attributes. Considering the numerous levels of dealings between users,
business processes and devices in worldwide corporations today, there are
immediate and composite requirements from a single application, from
different levels within an organization and outside it.
The Software Requirements Analysis Process involves the complex task of
eliciting and documenting the requirements of all customers, modeling and
analyzing these requirements and documenting them as a foundation for
system design. This job (requirements analysis process) is dedicated to a
specialized Requirements Analyst. The Requirements Analysis function may
also come under the scope of Project Manager, Program Manager or Business
Analyst, depending on the organizational hierarchy.

Steps in the Requirements Analysis Process

1. Fix system boundaries: This is initial step and helps in identifying how
the new application fit in into the business processes, how it fits into the
larger picture as well as its capacity and limitations.
2. Identify the customer: This focuses on identifying who the users or
customers of an application that is, to say know the group or groups of
people who will be directly or indirectly impacted by the new application.
This allows the Requirements Analyst to know in advance where he has
to look for answers.
3. Requirements elicitation: Here information is gathered from the
multiple stakeholders identified. The Requirements Analyst brings out
from each of these groups what their requirements from the application
are and what they expect the application to achieve. Taking into account
the multiple stakeholders involved, the list of requirements gathered in
this manner could go into pages. The level of detail of the requirements
list depends on the number and size of user groups, the degree of
complexity of business processes and the size of the application.

Problems faced in Requirements Elicitation

• Ambiguous understanding of processes
• Inconsistency within a single process by multiple users
• Insufficient input from stakeholders
• Conflicting stakeholder interests
• Changes in requirements after project has begun

Tools used in Requirements Elicitation

Tools used in Requirements Elicitation include stakeholder interviews and
focus group studies. Other methods like flowcharting of business processes
and the use of existing documentation like user manuals, organizational
charts, process models and systems or process specifications, on-site analysis,
interviews with end-users, market research and competitor analysis are also
used widely in Requirements Elicitation.

There are of course, modern tools that are better equipped to handle the
complex and multilayered process of Requirements Elicitation. Some of the
current Requirements Elicitation tools in use are:
• Prototypes
• Use cases
• Data flow diagrams
• Transition process diagrams
• User interfaces

4. Requirements Analysis: The moment all stakeholder requirements have

been gathered, a structured analysis of these can be done after modeling the
requirements. Some of the Software Requirements Analysis techniques used
are requirements animation, automated reasoning, knowledge- based
critiquing, consistency checking, analogical and case-based reasoning.

5. Requirements Specification: After requirements have been elicited,

modeled and analyzed, they should be documented in clear, definite terms. A
written requirements document is crucial and as such its circulation should be
among all stakeholders including the client, user-groups, the development and
testing teams. It has been observed that a well-designed, clearly documented
Requirements Specification is vital and serves as a:
• Base for validating the stated requirements and resolving stakeholder
conflicts, if any
• Contract between the client and development team
• Basis for systems design for the development team
• Bench-mark for project managers for planning project development
lifecycle and goals
• Source for formulating test plans for QA and testing teams
• Resource for requirements management and requirements tracing
• Basis for evolving requirements over the project life span

Software requirements specification involves scoping the requirements so that

it meets the customer‘s vision. It is the result of teamwork between the end-
user who is usually not a technical expert, and a Technical/Systems Analyst,
who is expected to approach the situation in technical terms. The software
requirements specification is a document that lists out stakeholders needs and
communicates these to the technical community that will design and build the
system. It is really a challenge to communicate a well-written requirements
specification, to both these groups and all the sub-groups within. To overcome
this, Requirements Specifications may be documented separately as:
• User Requirements - written in clear, precise language with plain text
and use cases, for the benefit of the customer and end-user
• System Requirements - expressed as a programming or mathematical
model, meant to address the Application Development Team and QA and
Testing Team.

Requirements Specification serves as a starting point for software, hardware

and database design. It describes the function (Functional and Non-Functional
specifications) of the system, performance of the system and the operational
and user-interface constraints that will govern system development.

SPECIFICATION PRINCIPLES
 Separate functionality from implementation
 Develop a model of the desired behavior of a system that encompasses
data and functional response of a system to various stimuli from the
environment
 Establish the context in which software operates by specifying the
manner in which other systems components interact with software
 Define the environment in which the system operates and indicate how
“a highly intertwined collection of agents react to stimuli in the
environment (changes to objects) produced by those agents”
 Create a cognitive model rather than a design or implementation model.
The cognitive model describes a system as perceived by its user
community
 Recognize that “the specifications must be tolerant of incompleteness
and augmentable.” A specification is always a model-an abstraction-of
some real situation that is normally quite complex. Hence, it will be
incomplete and will exist at many level of detail
 Establish the content and structure of a specification in a way that will
enable it to be amenable to change

Representation
 Representation format and content should be relevant to the problem
 Information contained within the specification should be nested
 Diagrams and other notational forms should be restricted in number and
consistent in use
 Representations should be revisable
The software requirements specification
 Is produced at the culmination of analysis task.
 The function and performance allocated to software as part of system
engineering are refined by establishing a complete information
description, a detailed functional description, a representation of system
behavior, an indication of performance requirements and design
constraints, appropriate validation criteria, and other information
pertinent to requirements.

Format of software requirements specification:

 Introduction
 Information description
 Functional description
 Behavioral description
 Validation criteria
 Bibliography and appendix

Specification Review
• A review of the Software Requirements Specification is conducted by both
the software developer and the customer.
• Because the specification forms the foundation of the development
phase, extreme care should be taken into conducting the review.
• Once the review is complete, the Software Requirements Specification is
“signed- off” by both the customer and developer.
The specification becomes a “contract” for software development

In-Text Question
1. What is Software Specification?
2. Outline steps in the Requirements Analysis Process?
 CHAPTER SIX
SOFTWARE PROCESS
A structured set of activities required to develop a software system is called a
software process. It is a set of ordered activities carried out to produce a
software product. Each activity has well-defined objective, task, and outcome.
An activity is a specified task performed to achieve the process objectives. A
software project is an entity, with defined start and end, in which a software
process is being used. Software project is a cross functional entity which is
developed through a series of projects using the required resource. Thus,
process, project, product are interrelated to each other for the development of
software. There are many different software processes but all involve:
 Specification – defining what the system should do;
 Design and implementation – defining the organization of the system and
implementing the system;
 Validation – checking that it does what the customer wants;
 Evolution – changing the system in response to changing customer
needs.

ELEMENTS OF SOFTWARE PROCESS

A software process comprises various essential elements. These elements are
discussed as follows:
(1) ARTIFACTS:
 Artifacts are tangible work products produced during the development of
software.
 Examples of artifacts include software architecture, project plan, etc.
(2) ACTIVITY:
 Activity specifies the task to be carried out implicitly or explicitly each
activity uses some procedures, rules, policies and guidelines to produce
required artifacts.
 Examples for Activity include analysis, design, tracking and monitoring
etc.
(3) CONSTRAINTS:
 Constraints refer to the criteria or condition that must be met or
processed by a software product.
 Examples include, a machine allows five users to login at a time, permits
seven transaction per nanoseconds etc.
(4) PEOPLE:
 People are persons or stakeholders who are directly or indirectly in the
process.
  Stakeholders play important role in achieving project goals, software
tester quality checker etc.
 Examples of stakeholders include software engineers, system analyst,
project managers, designers, Architects, Release Managers etc.
(5) TOOLS AND TECHNOLOGY:
 Tools and technology provides technical supports to the methods are
techniques to be used for performing the activities.
 Examples include FORTRAN is suitable for scientific problems, CASE
tools support in software development.
(6) METHOD OR TECHNIQUE:
 Methods or techniques specify the way to perform an activity using tools
and technology to accomplish the activity.
 It Provides detail mechanism to carry out an activity.
 Examples include object oriented analysis (OOA), binary search etc.
(7) RELATIONSHIP:
 Relationship specifies the link among various activities or entities.
 Examples include, maintenance followed by implementation, debugging
is required after error detection etc.
(8) ORGANIZATIONAL STRUCTURE:
 Organizational structure specifies the team of people that should be
coordinated and managed during software development.
 Examples include, the project leader monitors the work flow of various
activities which are assigned to the software engineers.

CHARACTERISTICS OF A SOFTWARE PROCESS:

There are certain common characteristics of a software process, which are
discussed below:
(1) UNDERSTANDABILITY: The process specification must be easy to
understand, easy to learn, and easy to apply.
(2) EFFECTIVENESS: Effectiveness of a product depend s on certain
performance indicators, such as programmer’s, skills, fund availability, quality
of work products, etc.
(3) PREDICTABILITY: It is about forecasting the outcomes before the
completion of a process. It is the basis through which the cost, quality and
resource requirements are specified in a project.
(4) MAINTAINABILITY: It is the flexibility to maintain software through
change requirements, defect detection and correction, adopting it in new
operating environments. Maintainability is a life-long process. It is one of the
primary objectives of a process to reduce the maintenance task in software.
Reduction in maintenance definitely reduces a project cost.
(5) RELIABILITY: It refers to the capability of performing the intended tasks.
Unreliability of a process causes product failures and unreliable process waste
time and money.
(6) CHANGEABILITY: It is the acceptability of changes done in software.
(7) MONITORING AND TRACKING: Monitoring and tracking a process in a
project can help to determine predictability and productivity. It helps to
monitor and track the progress of the project based up on past experiences of
the process.
(8) RAPIDITY: Rapidity is the speed of a process to produce the products
under specifications for its timely completion.

PROCESS CLASSIFICATION: Software processes may be classified as

(1) Product development process
(2) Project management process
(3) Change management process
(4) Process improvements and
(5) Quality management process.

PRODUCT DEVELOPMENT PROCESS

 Product development processes focus mainly on producing software
products.
 These processes involve various techniques, tools and technologies for
developing software.
 Such processes include various activities like conceptualization,
designing, coding, testing, and implementation of new or existing system.
 These are certain work products of these activities, such as software
requirement specifications (SRS), design models, source codes, test
reports and documentation.
 The most widely used software development process models are the
waterfall model, prototyping model, spiral model, agile model, RUP, and
so on.
 Customer feedback, reusability, co-ordination, communication and
documentation are some factors that help to decide the application of
development process models
PROJECT MANAGEMENT PROCESS
 Project management processes concentrate on planning and managing
projects in order to achieve the project objectives.
 The goal of these processes is to carry out the development activities with
in time, budget and resources.
  Initiating, Planning, coordinating, controlling, executing, and terminating
are the main activities of a general project management process.
 The project manager is the key person for handling all the above
activities in an organization.
 The project manager designs teams, allocate the tasks and monitors the
progress of the project team members so that the project could be
completed on time and within budget.

PROCESS IMPROVEMENT PROCESS

 The ultimate goal of improvement in a process is to enable the
organization to produce more quality products.
 Sometimes, it becomes very difficult to apply an improved software
process to achieve the specified results due to short delivery span,
insufficient knowledge of the process and context, insufficient managerial
support, and many other factors.
 There exists various process improvement process model, such as
CMMI,QIP, continuous quality improvement (CQI), total quality
management (TQM), six sigma, band so on.

CONFIGURATION OR CHANGE MANAGEMENT PROCESS:

 Changes may occur in projects, processes, and products as these entities
are evolutionary in nature.
 Changes may arise due to either change in the customer requirements or
discrepancies in the work products or procedures from the developer’s
side.
 Thus, identifying, evaluating, and finally implementing changes is the
main function of software configuration management (SCM) process.
configuration management includes various activities for performing
changes , such as identification of configuration items, devising
mechanisms for performing changes, controlling changes, and tracking
the status of those changes

QUALITY MANAGEMENT PROCESS:

 A quality management process provides metrics, feedback, and
guidelines for the assurance of product quality.
 Software quality organization gives information and expertise to
development and management process for quality production.
 The main activities of software quality groups are verification and
validation, acceptance testing, measurement and metrics, process
consulting, and so on.
 ISO 9000 is a framework that provides certain guidelines for the quality
system.

In-Text Question
1. Mention some characteristics of a Software Process?
2. List four factors involved in all software process?
 CHAPTER SEVEN
SOFTWARE PROCESS MODEL
A software process model is an abstract representation of a process. It presents
a description of a process from some particular perspective. When we describe
and discuss processes, we usually think about the activities in these processes
such as specifying a data model, designing a user interface, etc. and the
ordering of these activities. There are different models available.

Water fall Model (Linear-Sequential Life Cycle Model)

 The Waterfall Model was first Process Model to be introduced. It is very
simple to understand and use. In a Waterfall model, each phase must be
completed before the next phase can begin and there is no overlapping in
the phases.
 Waterfall model is the earliest SDLC approach that was used for software
development.
 In “The Waterfall” approach, the whole process of software development
is divided into separate phases.
 The outcome of one phase acts as the input for the next phase
sequentially.
 This means that any phase in the development process begins only if the
previous phase is complete.
 At the end of each phase, a review takes place to determine if the project
is on the right path and whether or not to continue or discard the
project.
1. Communication: The major task performed is requirement gathering
which helps in finding out the exact need of the customer. Once all
the needs of the customer are gathered the next step is planning.
2. Planning: Major activities like planning for schedule, keeping tracks
on the processes and the estimation related to the project are done.
Planning is even used to find the types of risks involved throughout
the projects. Planning describes how technical tasks are going to take
place and what resources are needed and how to use them.
3. Modeling: This is one the important phases of the architecture of the
system is designed in this phase. Analysis is carried out and
depending on the analysis a software model is designed. Different
models for developing software are created depending on the
requirements gathered in the first phase and the planning done in the
second phase.
4. Construction: The actual coding of the software is done in this phase.
This coding is done on the basis of the model designed in the
modeling phase. So in this phase software is actually developed and
tested.
5. Deployment: In this last phase the product is actually rolled out or
delivered & installed at customer’s end and support is given if
required. A feedback is taken from the customer to ensure the quality
of the product.

Advantages of waterfall model

1. This model is simple and easy to understand and use.
2. It is easy to manage due to the rigidity of the model – each phase has
specific deliverables and a review process.
3. In this model phases are processed and completed one at a time. Phases
do not overlap.
4. Waterfall model works well for smaller projects where requirements are
very well understood.

Disadvantages of waterfall model

1. 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.
2. No working software is produced until late during the life cycle.
3. High amounts of risk and uncertainty.
4. Not a good model for complex and object-oriented projects.
5. Poor model for long and ongoing projects.
6. Not suitable for the projects where requirements are at a moderate to
high risk of changing.

When to use the waterfall model

• This model is used only when the requirements are very well known,
clear and fixed.
• Product definition is stable.
• Technology is understood.
• There are no ambiguous requirements
• Ample resources with required expertise are available freely
• The project is short.

Prototyping Model:
Prototype: Prototype is an early approximation of a final system/product or
Prototype is a working model of software with some limited functionality.

The Software Prototyping refers to building software application prototypes

which displays the functionality of the product under development, but may
not actually hold the exact logic of the original software.

1. The basic idea in Prototype model is that instead of freezing the

requirements before a design or coding can proceed, a throwaway prototype
is built to understand the requirements. This prototype is developed based
on the currently known requirements.
2. 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.
3. 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.
4. The first prototype is modified, based on the comments supplied by the
users, and a second prototype of the new system is constructed.
5. The second prototype is evaluated in the same manner as was the first
prototype.
6. The process of refining the prototype is repeated till all the requirements
of users are met.
7. When the users are satisfied with the developed prototype then the
system is developed on the basis of final prototype and it is thoroughly
evaluated and tested.
Advantages of Prototyping Model
 In the development process of this model users are actively involved.
 The development process is the best platform to understand the
system by the user.
 Earlier error detection takes place in this model.
 It gives quick user feedback for better solutions.
 It identifies the missing functionality easily. It also identifies the
confusing or difficult functions.

Disadvantages of Prototyping Model

 The client involvement is more and it is not always considered by the
developer.
 It is a slow process because it takes more time for development.
 Many changes can disturb the rhythm of the development team.
 It is a throw away prototype when the users are confused with it.

When to use Prototype model:

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

RAD model:
 RAD model is Rapid Application Development model. It is a type of
incremental model.
 In RAD model the components or functions are developed in parallel
as if they were mini projects
 The developments are time boxed, delivered and then assembled into
a working prototype.
 This can quickly give the customer something to see and use and to
provide feedback regarding the delivery and their requirements.

The phases in the rapid application development (RAD) model are:

• Business modeling: The information flow is identified between various
business functions.
• Data modeling: Information gathered from business modeling is used to
define data objects that are needed for the business.
• Process modeling: Data objects defined in data modeling are converted to
achieve the business information flow to achieve some specific business
objective. Descriptions are identified and created for CRUD of data objects.
• Application generation: Automated tools are used to convert process
models into code and the actual system.
• Testing and turnover: Test new components and all the interfaces.

Advantages of the RAD model:

• Reduced development time.
• Increases reusability of components
• Quick initial reviews occur
• Encourages customer feedback
• Integration from very beginning solves a lot of integration issues.

Disadvantages of RAD model:

• Depends on strong team and individual performances for identifying
business requirements.
• Only system that can be modularized can be built using RAD
• Requires highly skilled developers/designers.
• High dependency on modeling skills
• Inapplicable to cheaper projects as cost of modeling and automated code
generation are very high.

When to use RAD model

• RAD should be used when there is a need to create a system that can be
modularized in 2-3 months of time.
• It should be used if there’s high availability of designers for modeling and
the budget is high enough to afford their cost along with the cost of automated
code generating tools.
• RAD SDLC model should be chosen only if resources with high business
knowledge are available and there is a need to produce the system in a short
span of time (2-3 months).

Incremental Process model:

 The incremental model combines the elements of waterfall model and
they are applied in an iterative fashion.
 The first increment in this model is generally a core product.
 Multiple development cycles take place. Cycles are divided up into
smaller, more easily managed CHAPTERs. Each CHAPTER passes
through the requirements, design, implementation and testing phases.
 Each increment builds the product and submits it to the customer for
any suggested modifications.
 The next increment implements on the customer's suggestions and add
additional requirements in the previous increment.
 This process is repeated until the product is finished. For example, the
word-processing software is developed using the incremental model.

Advantages of incremental model

• This model is flexible because the cost of development is low and
initial product delivery is faster.
• It is easier to test and debug during the smaller iteration.
• The working software generates quickly and early during the
software life cycle.
• The customers can respond to its functionalities after every
increment.

Disadvantages of the incremental model

• The cost of the final product may cross the cost estimate initially.
• This model requires a very clear and complete planning.
• The planning of design is required before the whole system is
broken into small increments.
• The demands of customer for the additional functionalities after
every increment causes problem during the system architecture.

Spiral Model: The spiral model was first mentioned by Barry Boehm in
his 1986 paper. 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 continually goes through these phases in iterations which are
called spirals. In the baseline spiral requirements are 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 carried out to discover risk and alternate
solutions. A prototype is produced at the end of the risk analysis phase.

Software is produced in the engineering phase, alongside with testing at

the end of the phase. The evaluation phase provides the customer with
opportunity to evaluate the output of the project to date before the
project continues to the next spiral. In the spiral model, the angular
component denotes progress, and the radius of the spiral denotes cost.

When to use Spiral Methodology?

 When project is large
 When releases are required to be frequent.
  When risk and costs evaluation is important
 For medium to high-risk projects
 When requirements are unclear and complex
 When changes may require at any time

Merits
• High amount of risk analysis
• Good for large and mission-critical projects.
• Software is produced early in the software life cycle.
• Development is fast and features are added in a systematic way.

Demerits
• Can be a costly model to use.
• Risk analysis requires highly specific expertise.
• Project‘s success is highly dependent on the risk analysis phase.
• Doesn‘t work well for smaller projects.

Win-Win Spiral Methodology: The win-win spiral approach is very similar to

the spiral model in that it is simply an extension of the spiral model. In the
win-win model approach, everyone discusses things together to figure out what
should go into the new version of the software. The Win-Win spiral software
engineering methodology expands the Boehm-Spiral methodology by adding a
priority setting step, the Win-Win process, at the beginning of each spiral cycle
and by introducing intermediate goals, called anchor points that help establish
the completion of one cycle around the spiral and provide decision milestones
before the software project proceeds. The Win-Win Spiral Model uses Theory W
(win-win) to develop software and system requirements, and architectural
solutions, as win conditions negotiated among a project's stakeholders (user,
customer, developer, maintainer, interface, etc.). Boehm’s WINWIN spiral model
defines a set of negotiation activities at the beginning of each pass around the
spiral. Rather than a single customer communication activity, the following
activities are defined:
1. Identification of the system or subsystem’s key “stakeholders.”
2. Determination of the stakeholders’ “win conditions.”
3. Negotiation of the stakeholders’ win conditions to reconcile them into a
set of win-win conditions for all concerned (including the software project
team). Successful completion of these initial steps achieves a win-win result,
which becomes the key criterion for proceeding to software and system
definition.
Advantages:
1 high amount of risk analysis hence, avoidance of risk is enhanced
2 good for large and mission critical projects 3 strong approval and
documentation control

Disadvantages:
1 can be a costly model to use
2 risk analysis requires highly specific expertise
3 projects success is highly depend on the risk analysis phase.

In-Text Question
1. Differentiate between Spiral model and V-shaped Model?
2. Mention two merits and demerits of prototype model?
 CHAPTER EIGHT
SOFTWARE DESIGN
A software design is a meaningful engineering representation of some software
product that is to be built. A design can be traced to the customer's
requirements and can be assessed for quality against predefined criteria. The
activities carried out during the design phase (called as design process)
transform the SRS document into the design document. In the software
engineering context, design focuses on four major areas of concern: data,
architecture, interfaces and components.

The design process is very important. As a laborer, for example one would not
attempt to build a house without an approved blueprint so as not to risk the
structural integrity and customer satisfaction. In the same way, the approach
to building software products is no unlike. The emphasis in design is on
quality. It is pertinent to note that, this is the only phase in which the
customer‘s requirements can be precisely translated into a finished software
product or system. As such, software design serves as the foundation for all
software engineering steps that follow regardless of which process model is
being employed.

During the design process the software specifications are changed into design
models that express the details of the data structures, system architecture,
interface, and components. Each design product is re-examined for quality
before moving to the next phase of software development. At the end of the
design process a design specification document is produced. This document is
composed of the design models that describe the data, architecture, interfaces
and components. The design process starts using the SRS document and
completes with the production of the design document. The design document
produced at the end of the design phase should be implementable using a
Programming language in the subsequent (coding) phase.
Design Specification Models
Data design – created by changing the analysis information model (data
dictionary and ERD) into data structures needed to implement the software.
Part of the data design may occur in combination with the design of software
architecture. More detailed data design occurs as each software component is
designed.

Architectural design - defines the relationships among the major structural

elements of the software, the ―design patterns‖ that can be used to attain the
requirements that have been defined for the system, and the constraint that
affect the way in which the architectural patterns can be applied. It is derived
from the system specification, the analysis model, and the subsystem
interactions defined in the analysis model (DFD).

Interface design - explains how the software elements communicate with each
other, with other systems, and with human users. Much of the necessary
information required is provided by the e data flow and control flow diagrams.

Component-level design – It converts the structural elements defined by the

software architecture into procedural descriptions of software components
using information acquired from the process specification (PSPEC), control
specification (CSPEC), and state transition diagram (STD).

Design Guidelines

In order to assess the quality of a design (representation) the yardstick for a

good design should be established. Such a design should:
 exhibit good architectural structure
 be modular
 contain distinct representations of data, architecture, interfaces, and
components (CHAPTERs)
 lead to data structures that are appropriate for the objects to be
implemented and be drawn from recognizable design patterns
 lead to components that exhibit independent functional characteristics
 lead to interfaces that reduce the complexity of connections between
CHAPTERs and with the external environment
 be derived using a reputable method that is driven by information
obtained during software requirements analysis
These criteria are not acquired by chance. The software design process
promotes good design through the application of fundamental design
principles, systematic methodology and through review.

Design Principles

Software design can be seen as both a process and a model. The design process
is a series of steps that allow the designer to describe all aspects of the
software to be built. However, it is not merely a recipe book; for a competent
and successful design, the designer must use creative skill, past experience, a
sense of what makes ―good‖ software, and have a commitment to quality.

The set of principles which has been established to help the software engineer in
directing the design process are:

The design process should not suffer from tunnel vision – Alternative
approaches should be considered by a good designer. Designer should judge
each approach based on the requirements of the problem, the resources
available to do the job and any other constraints.

The design should be traceable to the analysis model – because a single

element of the design model often traces to multiple requirements, it is
necessary to have a means of tracking how the requirements have been
satisfied by the model

The design should not reinvent the wheel – Systems are constructed using a
suite of design patterns, many of which may have likely been encountered
before. These patterns should always be chosen as an alternative to
reinvention. Design time should be spent in expressing truly fresh ideas and
incorporating those patterns that already exist.

The design should reduce intellectual distance between the software and the
problem as it exists in the real world – This means that, the structure of the
software design should imitate the structure of the problem domain.

The design should show uniformity and integration – a design is uniform if it

appears that one person developed the whole thing. Rules of style and format
should be defined for a design team before design work begins. A design is
integrated if care is taken in defining interfaces between design components.
The design should be structured to degrade gently, even with bad data, events,
or operating conditions are encountered – Well-designed software should never
―bomb‖. It should be designed to accommodate unusual circumstances, and if
it must terminate processing, do so in a graceful manner.

The design should be reviewed to minimize conceptual (semantic) errors – there

is sometimes the tendency to focus on minute details when the design is
reviewed, missing the forest for the trees. The designer team should ensure
that major conceptual elements of the design have been addressed before
worrying about the syntax if the design model.

Design is not coding, coding is not design – Even when detailed designs are
created for program components, the level of abstraction of the design model is
higher than source code. The only design decisions made of the coding level
address the small implementation details that enable the procedural design to
be coded.

The design should be structured to accommodate change

The design should be assessed for quality as it is being created
With proper application of design principles, the design displays both external
and internal quality factors. External quality factors are those factors that can
readily be observed by the user, (e.g. speed, reliability, correctness, usability).
Internal quality factors have to do with technical quality more so the quality of
the design itself. To achieve internal quality factors the designer must
understand basic design concepts.

Fundamental Software Design Concepts

Over the past four decades, a set of fundamental software design concepts has
evolved, each providing the software designer with a foundation from which
more sophisticated design methods can be applied. Each concept assists the
software engineer to answer the following questions:

 What criteria can be used to partition software into individual

components?
 How is function or data structure detail separated from a conceptual
representation of software?
 Are there uniform criteria that define the technical quality of a software
design?
The fundamental design concepts are:
1. Abstraction - allows designers to focus on solving a problem without
being concerned about irrelevant lower level details (procedural
abstraction - named sequence of events, data abstraction - named
collection of data objects)
2. Refinement - process of elaboration where the designer provides
successively more detail for each design component
3. Modularity - the degree to which software can be understood by
examining its components independently of one another
4. Software architecture - overall structure of the software components and
the ways in which that structure provides conceptual integrity for a
system
5. Control hierarchy or program structure - represents the CHAPTER
organization and implies a control hierarchy, but does not represent the
procedural aspects of the software (e.g. event sequences)
6. Structural partitioning - horizontal partitioning defines three partitions
(input, data transformations, and output); vertical partitioning (factoring)
distributes control in a top-down manner (control decisions in top level
CHAPTERs and processing work in the lower level CHAPTERs).
7. Data structure - representation of the logical relationship among
individual data elements (requires at least as much attention as
algorithm design)
8. Software procedure - precise specification of processing (event sequences,
decision points, repetitive operations, data organization/structure)
9. Information hiding - information (data and procedure) contained within a
CHAPTER is inaccessible to CHAPTERs that have no need for such
information

In-Text Question
1. Explain five fundamental design concepts?
2. Mention four design principles?
 CHAPTER NINE
SOFTWARE PROJECT MANAGEMENT
Software Project management involves planning, monitoring and control of
people, process and event that occurs as software evolves from preliminary
concept to fully operational deployment. The Software Project management
Spectrum focuses on the four P’s:
1. People
2. Product
3. Process
4. Project

Reasons for the failure of software project

1. Software people don’t understand their customer’s needs.
2. The product scope is poorly defined.
3. Changes are managed poorly.
4. The chosen technology changes.
5. Business needs change.
6. Deadlines are unrealistic.
7. Users are resistant.
8. Sponsorship is lost.
9. The project team lacks people with appropriate skills.
10. Managers [and practitioners] avoid best practices and lessons learned.

Software Project Planning

Project planning is the process of identifying and planning the activities
required to build a software product. Planning will improve a project’s outcome;
it requires you to make an initial commitment. Effective planning is needed to
resolve problems upstream [early in the project] at low cost, rather than
downstream [late in the project] at high cost. Planning is one of the most
important management activities and is an ongoing effort throughout the life of
the project.

Project Planning Objectives

• The objective of software project planning is to provide a framework that
enables the Manager to make reasonable estimates of:
1. Estimation of resources
2. Estimation of cost
3. Estimation of schedule
These estimates are made within a limited time frame at the beginning of a
software project and should be updated regularly as the project progresses.
• In addition, estimates should attempt to define best case and worst-case
scenarios so that project outcomes can be bounded.
• The overall goal of project planning is to establish a pragmatic strategy
for controlling, tracking and monitoring a complex technical project.
• The purpose of the project planning is to ensure that the end result is
completed on time, within budget and exhibits quality.

Task Set for Project Planning

1. Establish Project Scope.
2. Determine Feasibility.
3. Analyze risks
4. Define required resources.
a. Determine required human resources.
b. Define reusable software resources.
c. Identify environmental resources.
5. Estimate cost and effort.
a. Decompose the problem.
b. Develop two or more estimates using size, function points, process
tasks, or use cases.
c. Reconcile the estimates.
6. Develop a project schedule
a. Establish a meaningful task set.
b. Define a task network.
c. Use scheduling tools to develop a time-line chart.
d. Define schedule tracking mechanisms.

PROJECT ESTIMATION
Project Estimation is the process of estimating the cost, time, resources and
effort required to build a software product. The accuracy of a software project
estimate is predicated on
1. The degree to which the planner has properly estimated the size (e.g.,
KLOC) of the product to be built
2. The ability to translate the size estimate into human effort, calendar
time, and money
3. The degree to which the project plan reflects the abilities of the software
team
4. The stability of both the product requirements and the environment that
supports the software engineering effort

Project Estimation is done through the following steps:

 a. Decompose the problem.
b. Develop two or more estimates using size, function points, process
tasks, or use cases.
c. Reconcile the estimates.

Project Estimation can be performed in the following ways:

 Delay estimation until late in the project (we should be able to achieve
100% accurate estimates after the project is complete)
 Base estimates on similar projects that have already been completed
 Use relatively simple decomposition techniques to generate project cost
and effort estimates
 Use one or more empirical estimation models for software cost and effort
estimation.

SOFTWARE RISKS

• Risk Analysis and management are activities that help a software team to
understand uncertainty.
• Risk exhibits two characteristics:
1. Uncertainty: The occurrence of risk is uncertain that is risk may or may
not occur.
2. Loss: If the risk becomes a reality, unwanted consequences or losses will
occur.

Note: When risks are analyzed, it is important to quantify the level of

uncertainty and the degree of loss associated with each risk.

Different categories of risks are:

1. Project risks:
• They threaten the project plan.
• That is, if project risks become real, it is likely that the project schedule
will slip and that costs will increase.
• Project risks identify potential budgetary, schedule, personnel (staffing
and organization), resource, stakeholder, and requirements problems and their
impact on a software project.

2. Technical risks:
 They threaten the quality and timeliness of the software to be produced.
  If a technical risk becomes a reality, implementation may become
difficult or impossible.
 Technical risks identify potential design, implementation, interface,
verification, and Maintenance problems.

3. Business risks: They threaten the viability of the software to be built and
often jeopardize the project or the Product. Candidates for the top five business
risks are
a. Market risk: building an excellent product or system that no one really
wants
b. Strategic risk: building a product that no longer fits into the overall
business strategy for the company
c. Sales risk: building a product that the sales force doesn’t understand
how to sell.
d. Management risk: losing the support of senior management due to a
change in focus or a change in people.
e. Budget risks: losing budgetary or personnel commitment.

4. Known risks are those that can be uncovered after careful evaluation of the
project plan, the business and technical environment in which the project is
being developed, and other reliable information sources (e.g., unrealistic
delivery date, lack of documented requirements or software scope, poor
development environment).

5. Predictable risks are extrapolated from past project experience (e.g., staff
turnover, poor communication with the customer, dilution of staff effort as
ongoing maintenance requests are serviced).

6. Unpredictable risks are the joker in the deck. They can and do occur, but
they are extremely difficult to identify in advance.
 Risk Management: Fundamental Steps
In-Text Question
1. Explain five software risks?
2. Differentiate between project planning and project estimation?
 CHAPTER TEN
CODING AND TESTING
CODING
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. The purpose of requiring all engineers of an
organization to adhere to a standard style of coding is the following:
• A coding standard gives a uniform appearance to the codes written by
different engineers.
• It enhances code understanding.
• It encourages good programming practices.
A coding standard lists several rules to be followed during coding, such as the
way variables are to be named, the way the code is to be laid out, error return
conventions, etc.

Coding standards and guidelines

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. The following are some representative coding
standards.
1. Rules for limiting the use of global: These rules list what types of data can
be declared global and what cannot.
2. Contents of the headers preceding codes for different CHAPTERs: The
information contained in the headers of different CHAPTERs should be
standard for an organization. The exact format in which the header information
is organized in the header can also be specified. The following are some
standard header data:
• Name of the CHAPTER.
• Date on which the CHAPTER was created.
• Author’s name.
• Modification history.
• Synopsis of the CHAPTER.
• Different functions supported, along with their input/output parameters.
• Global variables accessed/modified by the CHAPTER
3. Naming conventions for global variables, local variables, and constant
identifiers: A possible naming convention can be that global variable names
always start with a capital letter, local variable names are made of small
letters, and constant names are always capital letters
4. Error return conventions and exception handling mechanisms: The way
error conditions are reported by different functions in a program are handled
should be standard within an organization. For example, different functions
while encountering an error condition should either return a 0 or 1 consistently
5. Do not use a coding style that is too clever or too difficult to understand:
Code should be easy to understand. Many inexperienced engineers actually
take pride in writing cryptic and incomprehensible code. Clever coding can
obscure meaning of the code and hamper understanding. It also makes
maintenance difficult.
6. Avoid obscure side effects: The side effects of a function call include
modification of parameters passed by reference, modification of global
variables, and I/O operations. An obscure side effect is one that is not obvious
from a casual examination of the code. Obscure side effects make it difficult to
understand a piece of code. For example, if a global variable is changed
obscurely in a called CHAPTER or some file I/O is performed which is difficult
to infer from the function’s name and header information, it becomes difficult
for anybody trying to understand the code.
7. Do not use an identifier for multiple purposes: Programmers often use the
same identifier to denote several temporary entities. For example, some
programmers use a temporary loop variable for computing and a storing the
final result.
• Each variable should be given a descriptive name indicating its purpose.
This is not possible if an identifier is used for multiple purposes. Use of a
variable for multiple purposes can lead to confusion and make it difficult for
somebody trying to read and understand the code.
• Use of variables for multiple purposes usually makes future
enhancements more difficult.

8. The code should be well-documented: As a rule of thumb, there must be

at least one comment line on the average for every three-source line.
9. The length of any function should not exceed 10 source lines: A function
that is very lengthy is usually very difficult to understand as it probably carries
out many different functions. For the same reason, lengthy functions are likely
to have disproportionately larger number of bugs.
10. Do not use goto statements: Use of goto statements makes a program
unstructured and makes it very difficult to understand.

Code review
• Code review for a model is carried out after the CHAPTER is successfully
compiled and the all the syntax errors have been eliminated.
• Code reviews are extremely cost-effective strategies for reduction in
coding errors and to produce high quality code. Normally, two types of reviews
are carried out on the code of a CHAPTER.

These two types’ code review techniques are code inspection and code walk
through.
Code Walk Throughs
• Code walk through is an informal code analysis technique. In this
technique, after a CHAPTER has been coded, successfully compiled and all
syntax errors eliminated.
• A few members of the development team are given the code few days
before the walk through meeting to read and understand code.
• Each member selects some test cases and simulates execution of the
code by hand (i.e. trace execution through each statement and function
execution).
• The main objectives of the walk through are to discover the algorithmic
and logical errors in the code. The members note down their findings to discuss
these in a walk through meeting where the coder of the CHAPTER is present.
• Even though a code walks through is an informal analysis technique,
several guidelines have evolved over the years for making this naïve but useful
analysis technique more effective.

Some of these guidelines are the following:

• The team performing code walk through should not be either too big or
too small. Ideally, it should consist of between three to seven members.
• Discussion should focus on discovery of errors and not on how to fix the
discovered errors.
• In order to foster cooperation and to avoid the feeling among engineers
that they are being evaluated in the code walk through meeting, managers
should not attend the walk through meetings.

Code Inspection
• In contrast to code walk through, the aim of code inspection is to
discover some common types of errors caused due to oversight and improper
programming. In other words, during code inspection the code is examined for
the presence of certain kinds of errors, in contrast to the hand simulation of
code execution done in code walk throughs.
• For instance, consider the classical error of writing a procedure that
modifies a formal parameter while the calling routine calls that procedure with
a constant actual parameter. It is more likely that such an error will be
discovered by looking for these kinds of mistakes in the code, rather than by
simply hand simulating execution of the procedure.
• In addition to the commonly made errors, adherence to coding standards
is also checked during code inspection. Good software development companies
collect statistics regarding different types of errors commonly committed by
their engineers and identify the type of errors most frequently committed. Such
a list of commonly committed errors can be used during code inspection to look
out for possible errors.
Following is a list of some classical programming errors which can be checked
during code inspection:
1. Use of uninitialized variables.
2. Jumps into loops.
3. Nonterminating loops.
4. Incompatible assignments.
5. Array indices out of bounds.
6. Improper storage allocation and de-allocation
7. Mismatches between actual and formal parameter in procedure calls.
8. Use of incorrect logical operators or incorrect precedence among
operators.
9. Improper modification of loop variables.
10. Comparison of equally of floating point variables, etc.

SOFTWARE TESTING
Software testing is an empirical examination carried out to provide
stakeholders with information about the quality of the product or service under
test. Software Testing in addition provides an objective, independent view of the
software to allow the business to value and comprehend the risks associated
with implementation of the software.

Software Testing can also be viewed as the process of validating and verifying
that a software program/application/product (1) meets the business and
technical requirements that guided its design and development; (2) works as
expected; and (3) can be implemented with the same characteristics. It is
important to note that depending on the testing method used, software testing
can be applied at any time in the development process, though most of the test
effort occurs after the requirements have been defined and the coding process
has been completed.

Testing can never totally detect all the defects within software. Instead, it
provides a comparison that put side by side the state and behavior of the
product against the instrument someone applies to recognize a problem. These
instruments may include specifications, contracts, comparable products, past
versions of the same product, inferences about intended or expected purpose,
user or customer expectations, relevant standards, applicable laws, or other
criteria.

Every software product has a target audience. For instance, the audience for
video game software is completely different from banking software. Software
testing therefore is the process of attempting to make this assessment whether
the software product will be satisfactory to its end users, its target audience, its
purchasers, and other stakeholders.

Brief History of software testing

In 1979, Glenford J. Myers introduced the separation of debugging from
testing, illustrated the desire of the software engineering community to
separate fundamental development activities, such as debugging, from that of
verification. 1988, Dave Gelperin and William C. Hetzel classified the phases
and goals in software testing in the following stages:

• Until 1956 - Debugging oriented.

• 1957–1978 - Demonstration oriented.
• 1983–1987 - Evaluation oriented.
• 1988–2000 - Prevention oriented.

Testing methods
Traditionally, software testing methods are divided into black box testing, white
box testing and Grey Box Testing. A test engineer used these approaches to
describe his opinion when designing test cases.

1. Black box testing

Black box testing considers the software as a "black box" in the sense that
there is no knowledge of internal implementation. Black box testing methods
include: equivalence partitioning, boundary value analysis, all-pairs testing,
fuzz testing, model-based testing, traceability matrix, exploratory testing and
specification-based testing.

[Link] Specification-based testing: Specification-based testing intends to test

the functionality of software based on the applicable requirements.
Consequently, the tester inputs data into, and only sees the output from, the
test object. This level of testing usually needs thorough test cases to be
supplied to the tester, who can then verify that for a given input, the output
value, either "is" or "is not" the same as the expected value specified in the test
case.
Specification-based testing though necessary, but it is insufficient to guard
against certain risks.
Merits and Demerits: The black box testing has the advantage of "an
unaffiliated opinion in the sense that there is no "bonds" with the code and the
perception of the tester is very simple. He believes a code must have bugs and
he goes for it. But, on the other hand, black box testing has the disadvantage
of blind exploring because the tester doesn't know how the software being
tested was actually constructed. As a result, there are situations when (1) a
tester writes many test cases to check something that could have been tested
by only one test case, and/or (2) some parts of the back-end are not tested at
all.

2. White box testing

In a White box testing the tester has the privilege to the internal data
structures and algorithms including the code that implement these.

Types of white box testing

White box testing is of different types namely:
• API testing (application programming interface) - Testing of the
application using Public and Private APIs.
• Code coverage - creating tests to satisfy some criteria of code coverage
(e.g., the test designer can create tests to cause all statements in the program
to be executed at least once)
• Fault injection methods
• Mutation testing methods
• Static testing - White box testing includes all static testing

3. Grey Box Testing

Grey box testing requires gaining access to internal data structures and
algorithms for purposes of designing the test cases, but testing at the user, or
black-box level. Manipulating input data and formatting output cannot be
regarded as grey box, because the input and output are clearly outside of the
"black-box" that we are calling the system under test. This difference is
important especially when conducting integration testing between two
CHAPTERs of code written by two different developers, where only the
interfaces are exposed for test. However, changing a data repository can be
seen as grey box, because the use would not ordinarily be able to change the
data outside of the system under test. Grey box testing may also include
reverse engineering to ascertain boundary values or error messages.

Integration Testing
Integration testing is any type of software testing that seeks to reveal clash of
individual software CHAPTERs to each other. Such integration flaws can result,
when the new CHAPTERs are developed in separate branches, and then
integrated into the main project.

Regression Testing
Regression testing is any type of software testing that attempts to reveal
software regressions. Regression of the nature can occurs at any time software
functionality, that was previously working correctly, stops working as
anticipated. Usually, regressions occur as an unplanned result of program
changes, when the newly developed part of the software collides with the
previously existing. Methods of regression testing include re- running
previously run tests and finding out whether previously repaired faults have re-
appeared. The extent of testing depends on the phase in the release process
and the risk of the added features.

Acceptance testing
One of two things below can be regarded as Acceptance testing:
1. A smoke test which is used as an acceptance test prior to introducing a
new build to the main testing process, i.e. before integration or regression.
2. Acceptance testing performed by the customer, usually in their lab
environment on their own HW, is known as user acceptance testing (UAT).

Non Functional Software Testing

The following methods are used to test non-functional aspects of software:
• Performance testing confirms to see if the software can deal with large
quantities of data or users. This is generally referred to as software scalability.
This activity of Non Functional Software Testing is often referred to as
Endurance Testing.
• Stability testing checks to see if the software can continuously function
well in or above an acceptable period. This activity of Non Functional Software
Testing is oftentimes referred to as load (or endurance) testing.
• Usability testing is used to check if the user interface is easy to use and
understand.
• Security testing is essential for software that processes confidential data
to prevent system intrusion by hackers.
• Internationalization and localization is needed to test these aspects of
software, for which a pseudo localization method can be used.

Destructive testing
Destructive testing attempts to cause the software or a sub-system to fail, in
order to test its robustness.

Testing process
Testing process can take two forms: Usually the testing can be performed by an
independent group of testers after the functionality is developed before it is
sent to the customer. Another practice is to start software testing at the same
time the project starts and it continues until the project finishes. The first
practice always results in the testing phase being used as project buffer to
compensate for project delays, thereby compromising the time devoted to
testing.

Testing can be done on the following levels:

• Unit testing tests the minimal software component, or CHAPTER. Each
unit (basic component) of the software is tested to verify that the detailed
design for the unit has been correctly implemented. In an object-oriented
environment, this is usually at the class level, and the minimal unit tests
include the constructors and destructors.
• Integration testing exposes defects in the interfaces and interaction
between integrated components (CHAPTERs). Progressively larger groups of
tested software components corresponding to elements of the architectural
design are integrated and tested until the software works as a system.
• System testing tests a completely integrated system to verify that it meets
its requirements.
• System integration testing verifies that a system is integrated to any
external or third party systems defined in the system requirements.

Before shipping the final version of software, alpha and beta testing are often
done additionally:
• Alpha testing is simulated or actual operational testing by potential
users/customers or an independent test team at the developers' site. Alpha
testing is often employed for off-the-shelf software as a form of internal
acceptance testing, before the software goes to beta testing.
• Beta testing comes after alpha testing. Versions of the software, known
as beta versions, are released to a limited audience outside of the programming
team. The software is released to groups of people so that further testing can
ensure the product has few faults or bugs. Sometimes, beta versions are made
available to the open public to increase the feedback field to a maximal number
of future users.

Finally, acceptance testing can be conducted by the end-user, customer, or

client to validate whether or not to accept the product. Acceptance testing may
be performed as part of the hand-off process between any two phases of
development.

Benchmarks may be employed during regression testing to ensure that the

performance of the newly modified software will be at least as acceptable as the
earlier version or, in the case of code optimization, that some real improvement
has been achieved.

TESTING TOOLS
Program testing and fault detection can be aided significantly by testing tools
and debuggers. Testing/debug tools include features such as:
• Program monitors, permitting full or partial monitoring of program code
including:
a. Instruction Set Simulator, permitting complete instruction level
monitoring and trace facilities
b. Program animation, permitting step-by-step execution and conditional
breakpoint at source level or in machine code
c. Code coverage reports
• Formatted dump or Symbolic debugging, tools allowing inspection of
program variables on error or at chosen points
• Automated functional GUI testing tools are used to repeat system-level
tests through the GUI
• Benchmarks, allowing run-time performance comparisons to be made
• Performance analysis (or profiling tools) that can help to highlight hot
spots and resource usage

IN-TEXT QUESTIONS
1. Discuss the various testing methods?
2. Differentiate between the black box and white box testing?
 CHAPTER ELEVEN
SOFTWARE QUALITY ASSURANCE (SQA)
There is need to ensure that the software development and control processes
described in the project's Management Plan are correctly carried out and that
the project's procedures and standards are followed hence the need for
Software Quality Assurance cannot be underestimated.

CONCEPTS AND DEFINITIONS

Software Quality Assurance (SQA) is defined as a planned and systematic
approach to the evaluation of the quality of and adherence to software product
standards, processes, and procedures. SQA includes the process of assuring
that standards and procedures are established and are followed throughout the
software acquisition life cycle. Compliance with agreed-upon standards and
procedures is evaluated through process monitoring, product evaluation, and
audits. Software development and control processes should include quality
assurance approval points, where an SQA evaluation of the product may be
done in relation to the applicable standards.

STANDARDS AND PROCEDURES

Establishing standards and procedures for software development is critical,
since these provide the structure from which the software evolves. Standards
are the established yardsticks to which the software products are compared.
Procedures are the established criteria to which the development and control
processes are compared.
Standards and procedures establish the prescribed methods for developing
software; the SQA role is to ensure their existence and adequacy. Proper
documentation of standards and procedures is necessary since the SQA
activities of process monitoring, product evaluation and auditing rely upon
clear definitions to measure project compliance.

Types of standards include:

• Documentation Standards specify form and content for planning,
control, and product documentation and provide consistency throughout a
project.
• Design Standards specify the form and content of the design product.
They provide rules and methods for translating the software requirements into
the software design and for representing it in the design documentation.
• Code Standards specify the language in which the code is to be written
and define any restrictions on use of language features. They define legal
language structures, style conventions, rules for data structures and
interfaces, and internal code documentation.

Procedures are explicit steps to be followed in carrying out a process. All

processes should have documented procedures. Examples of processes for
which procedures are needed are configuration management, non-conformance
reporting and corrective action, testing, and formal inspections.

If developed according to the NASA DID, the Management Plan describes the
software development control processes, such as configuration management,
for which there have to be procedures, and contains a list of the product
standards. Standards are to be documented according to the Standards and
Guidelines DID in the Product Specification. The planning activities required to
assure that both products and processes comply with designated standards
and procedures are described in the QA portion of the Management Plan.

SOFTWARE QUALITY ASSURANCE ACTIVITIES

Product evaluation and process monitoring are the SQA activities that assure
the software development and control processes described in the project's
Management Plan are correctly carried out and that the project's procedures
and standards are followed. Products are monitored for conformance to
standards and processes are monitored for conformance to procedures. Audits
are a key technique used to perform product evaluation and process
monitoring. Review of the Management Plan should ensure that appropriate
SQA approval points are built into these processes.

Product evaluation is an SQA activity that assures standards are being

followed. Ideally, the first products monitored by SQA should be the project's
standards and procedures. SQA assures that clear and achievable standards
exist and then evaluates compliance of the software product to the established
standards. Product evaluation assures that the software product reflects the
requirements of the applicable standard(s) as identified in the Management
Plan.

Process monitoring is an SQA activity that ensures that appropriate steps to

carry out the process are being followed. SQA monitors processes by comparing
the actual steps carried out with those in the documented procedures. The
Assurance section of the Management Plan specifies the methods to be used by
the SQA process monitoring activity.
A fundamental SQA technique is the audit, which looks at a process and/or a
product in depth, comparing them to established procedures and standards.
Audits are used to review management, technical, and assurance processes to
provide an indication of the quality and status of the software product.

The purpose of an SQA audit is to assure that proper control procedures are
being followed, that required documentation is maintained, and that the
developer's status reports accurately reflect the status of the activity. The SQA
product is an audit report to management consisting of findings and
recommendations to bring the development into conformance with standards
and/or procedures.

COMPATIBILITY TESTING
Software testing comes in different types. Compatibility testing is one of the
several types of software testing which can be carried out on a system that is
develop based on certain yardsticks and which has to perform definite
functionality in an already existing setup/environment. Many things are
decided n compatibility of a system/application being developed with, for
example, other systems/applications, OS, Network. They include the use of the
system/application in that environment, demand of the system/application etc.
On many occasions, the reason while users prefer not to go for an
application/system cannot be unconnected with it non-compatibility of such
application/system with any other system/application, network, hardware or
OS they are already using. This explains the reason why the efforts of
developers may appear to be in vain. Compatibility testing can also be used to
certify compatibility of the system/application/website built with various other
objects such as other web browsers, hardware platforms, users, operating
systems etc. It helps to find out how well a system performs in a particular
environment such as hardware, network; operating system etc. Compatibility
testing can be performed manually or with automation tools.

COMPATIBILITY TESTING COMPUTING ENVIRONMENT

Computing environment that will require compatibly testing may include some
or all of the below mentioned elements:

• Computing capacity of Hardware Platform (IBM 360, HP 9000, etc.)..

• Bandwidth handling capacity of networking hardware
• Compatibility of peripherals (Printer, DVD drive, etc.)
• Operating systems (MVS, UNIX, Windows, etc.)
• Database (Oracle, Sybase, DB2, etc.)
• Other System Software (Web server, networking/ messaging tool, etc.)
• Browser compatibility (Firefox, Netscape, Internet Explorer, Safari, etc.)
Browser compatibility testing which can also be referred to as user
experience testing requires that the web applications are tested on different
web browsers, to ensure the following:
• Users have the same visual experience irrespective of the browsers
through which they view the web application.
• In terms of functionality, the application must behave and respond the
same way across different browsers.

Compatibility between versions: This has to do with testing of the

performance of system/application in connection with its own
predecessor/successor versions. This is sometimes referred to as backward
and forward compatibility. For example, Windows 98 was developed with
backward compatibility for Windows 95.

Software Compatibility testing: This is the evaluation of the performance of

system/application in connection with other software. For example: Software
compatibility with operating tools for network, web servers, messaging tools
etc.

Operating System compatibility testing: This is the evaluation of the

performance of system/application in connection with the underlying operating
system on which it will be used.

Databases compatibility testing: Many applications/systems operate on

databases. Database compatibility testing is used to evaluate an
application/system‘s performance in connection to the database it will interact
with.

Usefulness of Compatibility Testing

Compatibility testing can help developers understand the yardsticks that their
system/application needs to reach and fulfil, so as to get acceptance by
intended users who are already using some OS, network, software and
hardware etc. It also helps the users to find out which system will better fit in
the existing setup they are using.

Certification testing falls within the range of Compatibility testing. Product

Vendors do run the complete suite of testing on the newer computing
environment to get their application certified for a specific Operating Systems
or Databases.
IN-TEXT QUESTIONS
1. What is Software Quality Assurance?
2. Explain the concept of standards and procedures.