Software Engineering 1 Module

CS-6209 Software Engineering 1
1
Week 1: The Scope of Software Engineering
Module 001: The Scope of Software Engineering
Course Learning Outcomes:

1. Understand what software engineering is and why it is important;
2. Understand that the development of different types of software Systems
may require different software engineering techniques;
3. Understand some ethical and professional issues that are important for
software engineers;
4. Understand the scope of Software Engineering
Introduction
The term software engineering is composed of two words, software and engineering.
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. Engineering on the other hand, is all about
developing products, using well-defined, scientific principles and methods. So, we can
define software engineering as an engineering branch associated with the development of
software product using well-defined scientific principles, methods and procedures.
The outcome of software engineering is an efficient and reliable software product. IEEE
defines software engineering as: The application of a systematic, disciplined, quantifiable
approach to the development, operation and maintenance of software. We can alternatively
view it as a systematic collection of past experience. The experience is arranged in the form
of methodologies and guidelines. A small program can be written without using software
engineering principles. But if one wants to develop a large software product, then software
engineering principles are absolutely necessary to achieve a good quality software cost
effectively. Without using software engineering principles it would be difficult to develop
large programs. In industry it is usually needed to develop large programs to accommodate
multiple functions. A problem with developing such large commercial programs is that the
complexity and difficulty levels of the programs increase exponentially with their sizes.
Software engineering helps to reduce this programming complexity. Software engineering
principles use two important techniques to reduce problem complexity: abstraction and
decomposition.
The principle of abstraction implies that a problem can be simplified by omitting irrelevant
details. In other words, the main purpose of abstraction is to consider only those aspects of
the problem that are relevant for certain purpose and suppress other aspects that are not
relevant for the given purpose. Once the simpler problem is solved, then the omitted details
can be taken into consideration to solve the next lower level abstraction, and so on.
Course Module
2
Abstraction is a powerful way of reducing the complexity of the problem. The other
approach to tackle problem complexity is DEPT OF CSE & IT VSSUT, Burla decomposition.
In this technique, a complex problem is divided into several smaller problems and then the
smaller problems are solved one by one. However, in this technique any random
decomposition of a problem into smaller parts will not help. The problem has to be
decomposed such that each component of the decomposed problem can be solved
independently and then the solution of the different components can be combined to get
the full solution.
A good decomposition of a problem should minimize interactions among various

components. If the different sub components are interrelated, then the different
components cannot be solved separately and the desired reduction in complexity will not
be realized.
Need of Software Engineering

The need of software engineering arises because of higher rate of change in user
requirements and environment on which the software is working.
 Large software - It is easier to build a wall than to a house or building, likewise,

as the size of software become large engineering has to step to give it a scientific
process.
 Scalability - If the software process were not based on scientific and engineering
concepts, it would be easier to re-create new software than to scale an existing
one.
 Cost- As hardware industry has shown its skills and huge manufacturing has
lower down the price of computer and electronic hardware. But the cost of
software remains high if proper process is not adapted.
 Dynamic Nature- The always growing and adapting nature of software hugely
depends upon the environment in which the user works. If the nature of
software is always changing, new enhancements need to be done in the existing
one. This is where software engineering plays a good role.
 Quality Management- Better process of software development provides better
and quality software product.
Characteristics of Good Software

A software product can be judged by what it offers and how well it can be used.
This software must satisfy on the following grounds:
 Operational
 Transitional
 Maintenance
This tells us how well software works in operations. It can be measured on:
3
 Budget
 Usability
 Efficiency
 Correctness
 Functionality
 Dependability
 Security
 Safety Transitional
This aspect is important when the software is moved from one platform to another
 Portability
 Interoperability
 Reusability
 Adaptability
 Maintenance
This aspect briefs about how well software has the capabilities to maintain itself in
the ever-changing environment:
 Modularity
 Maintainability
 Flexibility
 Scalability
In short, Software engineering is a branch of computer science, which uses well-

defined engineering concepts required to produce efficient, durable, scalable, in-
budget and on-time software products
Software engineering diversity

Software engineering is a systematic approach to the production of software
that takes into account practical cost, schedule, and dependability issues, as
well as the needs of software customers and producers. How this systematic
approach is actually implemented varies dramatically depending on the
organization developing the software, the type of software, and the people
involved in the development process. There are no universal software
engineering methods and techniques that are suit-able for all systems and all
companies. Rather, a diverse set of software engineering methods and tools
has evolved over the past 50 years.
Perhaps the most significant factor in determining which software engineering

methods and techniques are most important is the type of application that is
being developed. There are many different types of application including:
Course Module
4
1. Stand-alone applications. These are application systems that run on a

local computer, such as a PC. They include all necessary functionality
and do not need to be connected to a network. Examples of such
applications are office applications on a PC, CAD programs, photo
manipulation software, etc.
2. Interactive transaction-based applications. These are applications that

execute on a remote computer and that are accessed by users from their
own PCs or terminals. Obviously, these include web applications such as
e-commerce applications where you can interact with a remote system
to buy goods and services. This class of application also includes
business systems, where a business provides access to its systems
through a web browser or special-purpose client program and cloud-
based services, such as mail and photo sharing. Interactive applications
often incorporate a large data store that is accessed and updated in each
transaction.
3. Embedded control systems. These are software control systems that

control and manage hardware devices. Numerically, there are probably
more embedded systems than any other type of system. Examples of
embedded systems include the software in a mobile (cell) phone,
software that controls anti-lock braking in a car, and software in a
microwave oven to control the cooking process.
4. Batch processing systems. These are business systems that are designed
to process data in large batches. They process large numbers of
individual inputs to create corresponding outputs. Examples of batch
systems include periodic billing systems, such as phone billing systems,
and salary payment systems.
5. Entertainment system. These are systems that are primarily for personal
use and which are intended to entertain the user. Most of these systems
are games of one kind or another. The quality of the user interaction
offered is the most important distinguishing characteristic of
entertainment systems.
6. Systems for modeling and simulation. These are systems that are
developed by scientists and engineers to model physical processes or
situations, which include many, separate, interacting objects. These are
often computationally intensive and require high-performance parallel
systems for execution.
7. Data collection systems. These are systems that collect data from their
environment using a set of sensors and send that data to other systems
for processing. The software has to interact with sensors and often is
installed in a hostile environment such as inside an engine or in a
remote location.
5
8. Systems of systems. These are systems that are composed of a number of

other software systems. Some of these may be generic software
products, such as a spreadsheet program. Other systems in the assembly
may be specially written for that environment.
Of course, the boundaries between these system types are blurred. If you
develop a game for a mobile (cell) phone, you have to take into account the
same constraints (power, hardware interaction) as the developers of the phone
software. Batch processing systems are often used in conjunction with web-
based systems. For example, in a company, travel expense claims may be
submitted through a web application but processed in a batch application for
monthly payment.
You use different software engineering techniques for each type of system
because the software has quite different characteristics. For example, an
embedded control system in an automobile is safety-critical and is burned into
ROM when installed in the vehicle. It is therefore very expensive to change.
Such a system needs very extensive verification and validation so that the
chances of having to recall cars after sale to fix software problems are
minimized. User interaction is minimal (or perhaps nonexistent) so there is no
need to use a development process that relies on user interface prototyping.
For a web-based system, an approach based on iterative development and

delivery may be appropriate, with the system being composed of reusable
components. However, such an approach may be impractical for a system of
systems, where detailed specifications of the system interactions have to be
specified in advance so that each system can be separately developed.
Nevertheless, there are software engineering fundamentals that apply to all

types of software system:
1. They should be developed using a managed and understood

development process. The organization developing the software should
plan the development process and have clear ideas of what will be
produced and when it will be completed. Of course, different processes
are used for different types of software.
2. Dependability and performance are important for all types of systems.

Software should behave as expected, without failures and should be
available for use when it is required. It should be safe in its operation
and, as far as possible, should be secure against external attack. The
system should perform efficiently and should not waste resources.
Course Module
6
3. Understanding and managing the software specification and

requirements (what the software should do) are important. You have to
know what different customers and users of the system expect from it
and you have to manage their expectations so that a useful system can
be delivered within budget and to schedule.
4. You should make as effective use as possible of existing resources. This

means that, where appropriate, you should reuse software that has
already been developed rather than write new software.
These fundamental notions of process, dependability, requirements,

management, and reuse are important themes of this book. Different
methods reflect them in different ways but they underlie all professional
software development.
You should notice that these fundamentals do not cover implementation

and programming. I don’t cover specific programming techniques in this
book because these vary dramatically from one type of system to another.
For example, a scripting language such as Ruby is used for web-based
system programming but would be completely inappropriate for embedded
systems engineering.
Software engineering ethics

Like other engineering disciplines, software engineering is carried out within a
social and legal framework that limits the freedom of people working in that
area. As a software engineer, you must accept that your job involves wider
responsibilities than simply the application of technical skills. You must also
behave in an ethical and morally responsible way if you are to be respected as
a professional engineer.
It goes without saying that you should uphold normal standards of honesty
and integrity. You should not use your skills and abilities to behave in a
dishonest way or in a way that will bring disrepute to the software engineering
profession. However, there are areas where standards of acceptable behavior
are not bound by laws but by the more tenuous notion of professional
responsibility. Some of these are:
1. Confidentiality. You should normally respect the confidentiality of your

employers or clients irrespective of whether or not a formal
confidentiality agreement has been signed.
7
2. Competence. You should not misrepresent your level of competence.

You should not knowingly accept work that is outside your
competence.
3. Intellectual property rights. You should be aware of local laws governing

the use of intellectual property such as patents and copyright. You
should be careful to ensure that the intellectual property of employers
and clients is protected.
4. Computer misuse. You should not use your technical skills to misuse
other people’s computers. Computer misuse ranges from relatively
trivial (game playing on an employer’s machine, say) to extremely
serious (dissemination of viruses or other malware).
Software Engineering Code of Ethics and Professional Practice

ACM/IEEE-CS Joint Task Force on Software Engineering Ethics and Professional
Practices
PREAMBLE
The short version of the code summarizes aspirations at a high level of the
abstraction; the clauses that are included in the full version give examples
and details of how these aspirations change the way we act as software
engineering professionals. Without the aspirations, the details can become
legalistic and tedious; without the details, the aspirations can become high
sounding but empty; together, the aspirations and the details form a
cohesive code.
Software engineers shall commit themselves to making the analysis,

specification, design, development, testing and maintenance of software a
beneficial and respected profession. In accordance with their commitment
to the health, safety and welfare of the public, software engineers shall
adhere to the following Eight Principles:
PUBLIC — Software engineers shall act consistently with the public interest.
CLIENT AND EMPLOYER — Software engineers shall act in a manner that is in

the best interests of their client and employer consistent with the public
interest.
PRODUCT — Software engineers shall ensure that their products and

related modifications meet the highest professional standards possible.
Course Module
8
JUDGMENT — Software engineers shall maintain integrity and independence

in their professional judgment.
MANAGEMENT — Software engineering managers and leaders shall

subscribe to and promote an ethical approach to the management of
software development and maintenance.
PROFESSION — Software engineers shall advance the integrity and

reputation of the profession consistent with the public interest.
COLLEAGUES — Software engineers shall be fair to and supportive of

their colleagues.
SELF — Software engineers shall participate in lifelong learning regarding

the practice of their profession and shall promote an ethical approach to the
practice of the profession.
Professional societies and institutions have an important role to play in setting

ethical standards. Organizations such as the ACM, the IEEE (Institute of Electrical
and Electronic Engineers), and the British Computer Society publish a code of
professional conduct or code of ethics. Members of these organizations
undertake to follow that code when they sign up for membership. These codes of
conduct are generally concerned with fundamental ethical behavior.
Professional associations, notably the ACM and the IEEE, have cooperated to
produce a joint code of ethics and professional practice. This code exists in both a
short form, shown in Figure 1.3, and a longer form (Gotterbarn et al., 1999) that
adds detail and substance to the shorter version. The rationale behind this code
is summarized in the first two paragraphs of the longer form:
Computers have a central and growing role in commerce, industry, government,

medicine, education, entertainment and society at large. Software engineers are
those who contribute by direct participation or by teaching, to the analysis,
specification, design, development, certification, maintenance and testing of
software systems. Because of their roles in developing software systems, software
engineers have significant opportunities to do good or cause harm, to enable others
to do good or cause harm, or to influence others to do good or cause harm. To
ensure, as much as possible, that their efforts will be used for good, software
engineers must commit themselves to making software engineering a beneficial and
respected profession. In accordance with that commitment, software engineers
shall adhere to the following Code of Ethics and Professional Practice.
9
The Code contains eight Principles related to the behaviour of and decisions made
by professional software engineers, including practitioners, educators, managers,
supervisors and policy makers, as well as trainees and students of the profession.
The Principles identify the ethically responsible relationships in which individuals,
groups, and organizations participate and the primary obligations within these
relationships. The Clauses of each Principle are illustrations of some of the
obligations included in these relationships. These obligations are founded in the
software engineer’s humanity, in special care owed to people affected by the work
of software engineers, and the unique elements of the practice of software
engineering. The Code prescribes these as obligations of anyone claiming to be or
aspiring to be a software engineer.
In any situation where different people have different views and objectives you
are likely to be faced with ethical dilemmas. For example, if you disagree, in
principle, with the policies of more senior management in the company, how
should you react? Clearly, this depends on the particular individuals and the
nature of the dis-agreement. Is it best to argue a case for your position from
within the organization or to resign in principle? If you feel that there are
problems with a software project, when do you reveal these to management? If
you discuss these while they are just a suspicion, you may be overreacting to a
situation; if you leave it too late, it may be impossible to resolve the difficulties.
Such ethical dilemmas face all of us in our professional lives and, fortunately, in
most cases they are either relatively minor or can be resolved without too much
difficulty. Where they cannot be resolved, the engineer is faced with, perhaps,
another problem. The principled action may be to resign from their job but this
may well affect others such as their partner or their children.
A particularly difficult situation for professional engineers arises when their

employer acts in an unethical way. Say a company is responsible for developing a
safety-critical system and, because of time pressure, falsifies the safety validation
records. Is the engineer’s responsibility to maintain confidentiality or to alert the
customer or publicize, in some way, that the delivered system may be unsafe?
The problem here is that there are no absolutes when it comes to safety.
Although the system may not have been validated according to predefined
criteria, these criteria may be too strict. The system may actually operate safely
throughout its lifetime. It is also the case that, even when properly validated, the
system may fail and cause an accident. Early disclosure of problems may result in
damage to the employer and other employees; failure to disclose problems may
result in damage to others.
Course Module
10
You must make up your own mind in these matters. The appropriate ethical
position here depends entirely on the views of the individuals who are involved.
In this case, the potential for damage, the extent of the damage, and the people
affected by the damage should influence the decision. If the situation is very
dangerous, it may be justified to publicize it using the national press (say).
However, you should always try to resolve the situation while respecting the
rights of your employer.
Another ethical issue is participation in the development of military and nuclear

systems. Some people feel strongly about these issues and do not wish to
participate in any systems development associated with military systems. Others
will work on military systems but not on weapons systems. Yet others feel that
national security is an overriding principle and have no ethical objections to
working on weapons systems.
In this situation, it is important that both employers and employees should make
their views known to each other in advance. Where an organization is involved in
military or nuclear work, they should be able to specify that employees must be
willing to accept any work assignment. Equally, if an employee is taken on and
makes clear that they do not wish to work on such systems, employers should
not put pressure on them to do so at some later date.
The general area of ethics and professional responsibility is becoming more

important as software-intensive systems pervade every aspect of work and
everyday life. It can be considered from a philosophical standpoint where the
basic principles of ethics are considered and software engineering ethics are
discussed with reference to these basic principles. This is the approach taken by
Laudon (1995) and to a lesser extent by Huff and Martin (1995). Johnson’s text
on computer ethics (2001) also approaches the topic from a philosophical
perspective.
However, I find that this philosophical approach is too abstract and difficult to
relate to everyday experience. I prefer the more concrete approach embodied in
codes of conduct and practice. I think that ethics are best discussed in a software
engineering context and not as a subject in their own right. In this book,
therefore, I do not include abstract ethical discussions but, where appropriate,
include examples in the exercises that can be the starting point for a group
discussion on ethical issues.
11
References and Supplementary Materials

Books and Journals
1. SOFTWARE ENGINEERING, 9th Edition; Ian Sommerville
Online Supplementary Reading Materials

1. Fundamentals of Software Engineering;
https://www.academia.edu/2586877/Lecture_01_Fundamentals_of_Software_Engine
ering; October 14, 2019
2. Introduction to Software Engineering;

https://en.wikibooks.org/wiki/Introduction_to_Software_Engineering; October 14,
2019
Online Instructional Videos
Course Module
Week 001
The Scope of Software Engineering
Course Learning Objectives

• Understand what software engineering is and why it is important;
• Understand that the development of different types of software
Systems may require different software engineering techniques;
• Understand some ethical and professional issues that are important for
software engineers;
• Understand the scope of Software Engineering
What is “Software Engineering”?

A discipline whose aim is the production of software that
• meets the client’s needs
• fault-free
• delivered on time
• delivered within budget
• easy to modify
Why the need for Software Engineering?

• Software Crisis: Unacceptable low quality of software, exceeds
deadline and budget.
Successful,
Canceled, 23%
28%
*Completed with
Faults, 49%
*Completed late, over budget, and/or with features missing

The outcomes of 280,000 development projects completed in 2000
Horror Stories
• Patients died as a consequence of severe overdoses of radiation.
• US Treasury Department mailed incorrectly printed Social Security
Checks.
• Interest miscalculated on student loans resulting in higher monthly
payments.
• Mars Climate Orbiter spacecraft crashes into the surface of Mars
because of measurement conversion error.
Consequences of software failures range from inconvenience to death!

Ideal SE Life Cycle

Theoretical description of the steps that should be performed when
building a software product
• Requirements
• Analysis (specification)
-Draw up the Software Project Management Plan
• Design
-Architectural and Detailed Design
• Implementation
• Coding, Testing, Integration, Accepted by Clients
• Post-delivery maintenance
• Corrective, perfective (i.e. faster), adaptive (i.e. new hardware)
• Retirement
Classical vs. Modern Views of Maintenance

• Classical
-Development-then-Maintenance model
• Modern:
-Maintenance is performed at any time
• Projects take a long time and clients requirements change during process
• No longer from scratch - Reuse of existing products is widespread
Post-Delivery Maintenance
The real-time world is constantly changing
• Bad products are thrown away.

• Good products are repaired and enhanced
• SE Goal: Reduce post-delivery maintenance cost!
Post-delivery Development
maintenance 25%
75%
Average cost of percentages of development

and post-delivery maintenance between 1992
and 1998.
Find Faults Early!

• The cost of correcting a fault increase steeply from requirements to
post-delivery maintenance
• Involves: update documents, edit code, testing, integration …
• 60-70% of all faults detected are requirements, analysis or design
• SE Goal: Better requirements, specifications and designs

Importance of Continual Planning, Testing, Documentation

• After customer has signed off on the specifications, continue to
monitor and adjust plan.
• Software must be fault-free as possible at all times.
• At all times, documentation must be complete, correct and up-to-date.
• personnel overturn
• incomplete implementation
• inaccurate testing
• impossible to maintain
Why use Object-Oriented Paradigm

• Classical Structured Paradigm
• Focus on functions of system
• Object-Oriented
• Focus on objects
• Implementation details are local to the object
• Regression fault (inadvertent fault produced by seeming
unrelated change) is greatly reduced.
• Encapsulation: well-designed independent units
• Potential Reuse of objects reduces time and cost
Code of Ethics
Ethics – moral standards that help • Contribute to society and
guide your behavior, actions and human well being
choices • Avoid harm to others
The golden rule: Do unto others as • Be honest and trustworthy
you would have them do unto you • Honor property rights including
copyrights and patents
The slippery-slope rules: Be careful
starting down a path because one • Give proper credit for
you start you may not be able to stop intellectual property
• Access computing resources
Professional codes of conduct (ACM, only when authorized
IEEE)
• Respect privacy of others.
Questions
• When is it better to find faults? (requirements, post-delivery
maintenance)
• You are in charge of computerizing the extraction process in a silver
refinery. The cost of development has been estimated to be $370,000.
Approximately how much additional cost will be needed for post-
delivery maintenance?
1
Week 2: Software Engineering Principles
Module 002: Software Engineering Principles

1. Ability to identify, formulate, and solve complex engineering problems by
applying principles of engineering, science, and mathematics
2. Understand the importance of the stages in the software life cycle,
including a range of software development methodologies.
3. Understand the principles of Software Engineering
Introduction
Software engineering is concerned with all aspects of software production from the early
stages of system specification through to maintaining the system after it has been used.
As a discipline, software engineering has progressed very far in a very short period of time,
particularly when compared to classical engineering field (like civil or electrical
engineering). In the early days of computing, not more than 50 years ago, computerized
systems were quite small. Most of the programming was done by scientists trying to solve
specific, relatively small mathematical problems. Errors in those systems generally had
only “annoying” consequences to the mathematician who was trying to find “the answer.”
Today we often build monstrous systems, in terms of size and complexity.
Principles of Software Engineering

The need of software engineering arises because of higher rate of change in user
requirements and environment on which the software is working.
Separation of Concerns
When specifying the behavior of a data structure component, there are often two
concerns that need to be dealt with: basic functionality and support for data
integrity. A data structure component is often easier to use if these two concerns are
divided as much as possible into separate sets of client functions. It is certainly
helpful to clients if the client documentation treats the two concerns separately.
Modularity
The principle of modularity is a specialization of the principle of separation of
concerns. Following the principle of modularity implies separating software into
components according to functionality and responsibility. It describes a
responsibility-driven methodology for modularization in an object-oriented context.
Course Module
2
Abstraction
The principle of abstraction is another specialization of the principle of separation
of concerns. Following the principle of abstraction implies separating the behavior
of software components from their implementation. It requires learning to look at
software and software components from two points of view: what it does, and how
it does it.
Failure to separate behavior from implementation is a common cause of

unnecessary coupling. For example, it is common in recursive algorithms to
introduce extra parameters to make the recursion work. When this is done, the
recursion should be called through a non-recursive shell that provides the proper
initial values for the extra parameters. Otherwise, the caller must deal with a more
complex behavior that requires specifying the extra parameters. If the
implementation is later converted to a non-recursive algorithm, then the client code
will also need to be changed.
Anticipation of Change
Computer software is an automated solution to a problem. The problem arises in
some context or domain that is familiar to the users of the software. The domain
defines the types of data that the users need to work with and relationships
between the types of data.
Software developers, on the other hand, are familiar with a technology that deals
with data in an abstract way. They deal with structures and algorithms without
regard for the meaning or importance of the data that is involved. A software
developer can think in terms of graphs and graph algorithms without attaching
concrete meaning to vertices and edges.
Working out an automated solution to a problem is a learning experience for both

the software developers and their clients. Software developers are learning the
domain that the clients work in. They are also learning the values of the client: what
form of data presentation is most useful to the client, what kinds of data are crucial
and require special protective measures.
The clients are learning to see the range of possible solutions that software
technology can provide. They are also learning to evaluate the possible solutions
with regard to their effectiveness in meeting the client’s needs.
Cohesiveness has a positive effect on ease of change. Cohesive components are

easier to reuse when requirements change. If a component has several tasks rolled
up into one package, it is likely that it needs to be split up when changes are made.
3
Generality
The principle of generality is closely related to the principle of anticipation of
change. It is important in designing software that is free from unnatural
restrictions and limitations. One excellent example of an unnatural restriction or
limitation is the use of two digit year numbers, which has led to the "year 2000"
problem: software that will garble record keeping at the turn of the century.
Although the two-digit limitation appeared reasonable at the time, good software
frequently survives beyond its expected lifetime.
Incremental Development
An incremental software development process simplifies verification. If you develop
software by adding small increments of functionality, then, for verification, you only
need to deal with the added portion. If there are any errors detected, they are
already partly isolated so they are much easier to correct.
A carefully planned incremental development process can also ease the handling of
changes in requirements. To do this, the planning must identify use cases that are
most likely to be changed and put them towards the end of the development
process.
Consistency
The principle of consistency is a recognition of the fact that it is easier to do things
in a familiar context. For example, coding style is a consistent manner of laying out
code text. This serves two purposes. First, it makes reading the code easier. Second,
it allows programmers to automate part of the skills required in code entry, freeing
the programmer's mind to deal with more important issues.
Consistency serves two purposes in designing graphical user interfaces. First, a

consistent look and feel makes it easier for users to learn to use software. Once the
basic elements of dealing with an interface are learned, they do not have to be
relearned for a different software application. Second, a consistent user interface
promotes reuse of the interface components. Graphical user interface systems have
a collection of frames, panes, and other view components that support the common
look. They also have a collection of controllers for responding to user input,
supporting the common feel. Often, both look and feel are combined, as in pop-up
menus.
Is Software Development an Engineering Discipline?

Engineering involves the systematic application of scientific knowledge to the
solution of problems. The complexity of problems that are tackled today are not
Course Module
4
that different from those tackled by an electric engineer in creating a circuit or a

chemical engineer in devising a manufacturing process or a mechanical engineer
in the creation of a device.
The fact that there is also a hands-on approach of applying existing plans
(development in this case) is simply similar to the fact that in other fields,
somebody else executes those plans (e.g., the construction worker).
It is true that most developers also carry software engineering tasks, and that our
education is often not in programming but rather in software engineering. So we get
our hands dirty whereas a civil engineer would not.
Information System
An Information System (IS) is a system composed of people and computers that
processes or interprets information. The term is also sometimes used in more
restricted senses, referring only to the software used to run a computerized
database or a computer system only.
Information systems is an academic study of systems with a specific reference to

information and the complementary networks of hardware and software that
people and organizations use to collect, filter, process, create and also distribute
data. An emphasis is placed on an Information System having a definitive
Boundary, Users, Processors, Stores, Inputs, Outputs and the aforementioned
communication networks.
Any specific information system aims to support operations, management and

decision making. An information system is the information and communication
technology (ICT) that an organization uses, and also the way in which people
interact with this technology in support of business processes.
The 6 components that must come together to produce an information system are:
Hardware
The term hardware refers to machinery. This category includes the computer itself,
which is often referred to as the central processing unit (CPU), and all of its support
equipment. Among the support equipment are input and output devices, storage
devices and communication devices.
Software
5
The term software refers to computer programs and the manuals (if any) that
support them. Computer programs are machine-readable instructions that direct
the circuitry within the hardware parts of the system to function in ways that
produce useful information from data.
Data
Data are facts that are used by programs to produce useful information. Like
programs, data are generally stored in machine-readable form on disk or tape until
the computer needs them.
Procedures
Procedures are the policies that govern the operation of a computer system.
"Procedures are to people what software is to hardware" is a common analogy that
is used to illustrate the role of procedures in a system.
People
Every system needs people if it is to be useful. Often, the most over-looked element
of the system is the people when in fact it is probably the component that
influences the success or failure of information systems the most. This includes not
only the users, but those who operate and service the computers, those who
maintain the data, and those who support the network of computers.
Feedback
It is another component of the IS, that defines that an IS may be provided with a
feedback.
Data is the bridge between Hardware and People. This means that the data we
collect is only data, until we involve people. At that point, data will be information.
Course Module
6
Types of information system
The image above is a four level pyramid model of different types of information
systems based on the different levels of hierarchy in an organization.
The "classic" view of Information systems found in the textbooks in the 1980s was
of a pyramid of systems that reflected the hierarchy of the organization. Usually,
transaction processing systems is at the bottom of the pyramid, followed by
management information systems, decision support systems, and ending with
executive information systems at the top. Although the pyramid model remains
useful, since it was first formulated a number of new technologies have been
developed and new categories of information systems have emerged, some of
which no longer fit easily into the original pyramid model.
Some examples of such systems are:

 data warehouses
 enterprise resource planning enterprise systems
 expert systems search engines
 geographic information system
global information system
 office automation
A computer (-based) information system is essentially an IS using computer

technology to carry out some or all of its planned tasks. The basic components of
computer based information system are:
7
Hardware- these are the devices like the monitor, processor, printer and
keyboard, all of which work together to accept, process, show data and
information.
Software- are the programs that allow the hardware to process the data.
Databases- are the gathering of associated files or tables containing

related data.
Networks- are a connecting system that allows diverse computers to distribute

resources.
Procedures- are the commands for combining the components above to process
information and produce the preferred output.
The first four components (hardware, software, database, and network) make up
what is known as the information technology platform. Information technology
workers could use these components to create information systems that watch over
safety measures, risk and the management of data. These actions are known as
information technology services.
Information System Development

Information technology departments in larger organizations tend to strongly
influence the development, use, and application of information technology in the
organizations. A series of methodologies and processes can be used to develop and
use an information system. Many developers now use an engineering approach
such as the system development life cycle (SDLC), which is a systematic procedure of
developing an information system through stages that occur in sequence. An
information system can be developed in house (within the organization) or
outsourced. This can be accomplished by outsourcing certain components or the
entire system. A specific case is the geographical distribution of the development
team (offshoring, global information system).
Geographic information systems, land information systems, and disaster

information systems are examples of emerging information systems, but they
can be broadly considered as spatial information systems. System development
is done in stages which include:
 Problem recognition and specification

Course Module
8
 Information gathering
 Requirements specification for the new system
 System design
 System construction
 System implementation
 Review and maintenance
The academic discipline

The field of study called information systems encompasses a variety of topics
including systems analysis and design, computer networking, information security,
database management and decision support systems. Information management
deals with the practical and theoretical problems of collecting and analyzing
information in a business function area including business productivity tools,
applications programming and implementation, electronic commerce, digital media
production, data mining, and decision support. Communications and networking
deal with the telecommunication technologies. Information system bridges
business and computer science using the theoretical foundations of information
and computation to study various business models and related algorithmic
processes within a computer science discipline.
Computer information system(s) (CIS) is a field studying computers and

algorithmic processes, including their principles, their software and hardware
designs, their applications, and their impact on society, whereas IS emphasizes
functionality over design.
Several IS scholars have debated the nature and foundations of Information

Systems which has its roots in other reference disciplines such as Computer
Science, Engineering, Mathematics, Management Science, Cybernetics, and others.
Information systems can also be defined as a collection of hardware, software,
data, people and procedures that work together to produce quality information.
Information Systems have a number of different areas of work:

 IS strategy
 IS management
 IS development IS iteration
 IS organization
There is a wide variety of career paths in the information systems discipline.

"Workers with specialized technical knowledge and strong communications skills
will have the best prospects. Workers with management skills and an
understanding of business practices and principles will have excellent
9
opportunities, as companies are increasingly looking to technology to drive their

revenue."
Information technology is important in the operation of contemporary businesses

for it offers many employment opportunities. The information systems field
includes the people in organizations who design and build information systems, the
people who use those systems, and the people responsible for managing those
systems. The demand for traditional IT staff such as programmers, business
analysts, systems analysts, and designer is significant. Many well-paid jobs exist in
areas of Information technology. At the top of the list is the chief information officer
(CIO).
The CIO is the executive who is in charge of the IS function. In most organizations,
the CIO works with the chief executive officer (CEO), the chief financial officer
(CFO), and other senior executives. Therefore, he or she actively participates in the
organization's strategic planning process.
Information systems research

Information systems research is generally interdisciplinary, concerned with the
study of the effects of information systems on the behavior of individuals, groups,
and organizations.
Salvatore March and Gerald Smith proposed a framework for researching different
aspects of Information Technology including outputs of the research (research
outputs) and activities to carry out this research (research activities). They
identified research outputs as follows:
1. Constructs are concepts that form the vocabulary of a domain. They

constitute a conceptualization used to describe problems within the domain
and to specify their solutions.
2. A model is a set of propositions or statements expressing relationships

among constructs.
3. A method is a set of steps (an algorithm or guideline) used to perform a
task. Methods are based on a set of underlying constructs and a
representation (model) of the solution space.
4. An instantiation is the realization of an artifact in its environment.
Course Module
10
Furthermore, research activities include:

1. Building an artifact to perform a specific task.
2. Evaluating the artifact to determine if any progress has been achieved.
3. Given an artifact whose performance has been evaluated, it is important to

determine why and how the artifact worked or did not work within its
environment. Therefore, another research activity is the theorizing and
justifying of theories about IT artifacts.

Books and Journals

1. Principles of Software Engineering;
https://www.d.umn.edu/~gshute/softeng/principles.html; October 15, 2019
2. Seven Basic Principles of Software Engineering;

3. https://csse.usc.edu/TECHRPTS/1983/usccse83-500/usccse83-500.pdf; October 15,
2019

Week 002
Software Engineering Principles

• Ability to identify, formulate, and solve complex engineering problems
by applying principles of engineering, science, and mathematics
• Understand the importance of the stages in the software life cycle,
including a range of software development methodologies.
• Understand the principles of Software Engineering
Overview
• Software Engineering is based on a collection of fundamental principles

• These principles guide the development of all aspects of software
development
 Languages
 Methods
 Tools
 Process
 Project Management
How it All Relates
Tools
Methodologies
Methods
Techniques
Principles
We Will Cover
• Rigor and Formality
• Separation of Concerns
• Modularity
• Abstraction
• Anticipation of Change
• Generality (?)
• Incrementality
Rigor and Formality

• Software development is a creative process
• Creativity implies informality and chaos
• Rigor and formality seems to contradict creativity
• Not necessarily so
• Increase the confidence in the creative results
• Evident in
• Programming languages, design notations, requirements
specifications, process definitions
Separation of Concerns
• We cannot deal with all aspects of a problem simultaneously
• One way to conquer complexity
• Separate issues and tasks
• Separate functionality from efficiency
• Requirements specification from design
• Various types of separation
• In terms of time
• In terms of qualities
• In terms of views of an artifact
More on Separation
• By separating concerns we may miss out on optimizations
• True
• But, if we take a global view we may fail entirely!
• Separation of concerns allow separation of responsibilities
• Separation of managerial and technical issues
• Separation of requirements and design
Modularity
• A complex system must be broken down into smaller modules
• Three goals with modularity
• Decomposability
• Break the system down into understandable modules
• Divide and conquer
• Composability
• Construct a system from smaller pieces
• Reuse, ease of maintenance, OO frameworks
Modularity (continued)
• Ease of understanding
• The system will be changed; we must understand it
• Understand in pieces versus understanding the whole
Abstraction
• Identify the important aspects and ignore the details
• Must have different abstractions of the same reality
• Provide different views
• Examples of abstraction
• Design notations
• Project planning
• Etc.
• Two key concepts
• Information hiding and data encapsulation
Anticipation of Change
• Change is inevitable
• We might as well plan on it!
• This effects all aspects of Software Engineering

• Make sure all artifacts are easy to change
• Modularization and separation of concerns
• Make sure you can maintain many versions of all artifacts
• Configuration control
Anticipation of Change (continued)

• Plan for personnel turnover
• Plan for a rapidly changing market
• Plan for rapidly changing technology
Generality (??)
• In every problem, attempt to find a more general solution
• General problem is often easier to solve
• A generalized solution may be reusable
• If you are lucky, you may even be able to buy instead of build
• Attempt of the software industry to parallel hardware and

manufacturing
Incrementality
• Move towards the goal in increments
• Very difficult to have a “big bang” approach to anything
• Areas where we see incrementality

• Identify useful subsets of an application and deliver in increments
• Prototyping
• All software development adds functions a few at the time
• The whole development process; the spiral model
Concluding Remarks
• These fundamental principled guide all aspects of software development
• Remember
• Tools, methodologies, and techniques will evolve, the principles
remain the same
1
Week 3: Technical Development
Module 003: Technical Development

1. Identify the Life Cycle of a Software Development Project
2. Understand the Requirements Gathering
3. Understand the different types of testing in developing software
4. Know the components of developing a system
Introduction
Software development is a complicated process. It requires careful planning and execution
to meet the goals. Sometimes a developer must react quickly and aggressively to meet ever-
changing market demands. Maintaining software quality hinders fast-paced software
development, as many testing cycles are necessary to ensure quality products.
This chapter provides an introduction to the software development process. As you will
learn, there are many stages of any software development project. A commercial software
product is usually derived from market demands. Sales and marketing people have first-
hand knowledge of their customers’ requirements. Based upon these market requirements,
senior software developers create architecture for the products along with functional and
design specifications. Then the development process starts. After the initial development
phase, software testing begins, and many times it is done in parallel with the development
process. Documentation is also part of the development process because a product cannot
be brought to market without manuals. Once development and testing are done, the
software is released and the support cycle begins. This phase may include bug fixes and
new releases.
Life Cycle of a Software Development Project

Software development is a complicated process comprising many stages. Each stage
requires a lot of paperwork and documentation in addition to the development and
planning process. This is in contrast to the common thinking of newcomers to the
software industry who believe that software development is just “writing code.”
Each software development project has to go through at least the following stages:
 Requirement gathering
 Writing functional specifications
 Creating architecture and design documents
 Implementation and coding
 Testing and quality assurance
 Software release
 Documentation
Course Module
2
 Support and new features
Figure 3-1 shows a typical development process for a new product.
There may be many additional steps and stages depending upon the nature of the
software product. You may have to go through multiple cycles during the testing
phase as software testers find problems and bugs and developers fix them before a
software product is officially released. Let us go into some detail of these stages.
Requirement Gathering
Requirement gathering is usually the first part of any software product. This stage
starts when you are thinking about developing software. In this phase, you meet
customers or prospective customers, analyzing market requirements and features
that are in demand. You also find out if there is a real need in the market for the
software product you are trying to develop.
In this stage, marketing and sales people or people who have direct contact with the
customers do most of the work. These people talk to these customers and try to
understand what they need. A comprehensive understanding of the customers’
needs and writing down features of the proposed software product are the keys to
success in this phase. This phase is actually a base for the whole development effort.
If the base is not laid correctly, the product will not find a place in the market. If you
develop a very good software product which is not required in the market, it does
not matter how well you build it. You can find many stories about software products
that failed in the market because the customers did not require them. The marketing
people usually create a Marketing Requirement Document or MRD that contains
formal data representation of market data gathered.
Spend some time doing market research and analysis. Consider your competitors’
products (if any), a process called competitive analysis. List the features required by
the product. You should also think about the economics of software creation at this
point. Is there a market? Can I make money? Will the revenue justify the cost of
development?
Course Module
3
Figure 3-1 Typical processes for software development projects.
Writing Functional Specifications

Functional specifications may consist of one or more documents. Functional
specification documents show the behavior or functionality of a software product on
an abstract level. Assuming the product is a black box, the functional specifications
define its input/output behavior. Functional specifications are based upon the
product requirements documentation put forward by people who have contact with
the end user of the product or the customers.
Course Module
4
In larger products, functional specifications may consist of separate documents for

each feature of the product. For example, in a router product, you may have a
functional specification document for RIP (Routing Information Protocol), another
for security features, and so on.
Functional specifications are important because developers use them to create

design documents. The documentation people also use them when they create
manuals for end users. If different groups are working in different physical places,
functional specifications and architecture documents (discussed next) are also a
means to communicate among them. Keep in mind that sometimes during the
product development phase you may need to amend functional specifications
keeping in view new marketing requirements.
Creating Architecture and Design Documents

When you have all of the requirements collected and arranged, it is the turn of the
technical architecture team, consisting of highly qualified technical specialists, to
create the architecture of the product. The architecture defines different
components of the product and how they interact with each other. In many cases the
architecture also defines the technologies used to build the product. While creating
the architecture documents of the project, the team also needs to consider the
timelines of the project. This refers to the target date when the product is required
to be on the market. Many excellent products fail because they are either too early
or late to market. The marketing and sales people usually decide a suitable time
frame to bring the product to market. Based on the timeline, the architecture team
may drop some features of the product if it is not possible to bring the full-featured
product to market within the required time limits.
Once components of the product have been decided and their functionality defined,
inter-faces are designed for these components to work together. In most cases, no
component works in isolation; each one has to coordinate with other components of
the product. Interfaces are the rules and regulations that define how these
components will interact with each other. There may be major problems down the
road if these interfaces are not designed properly and in a detailed way. Different
people will work on different components of any large software development
project and if they don’t fully understand how a particular component will
communicate with others, integration becomes a major problem.
For some products, new hardware is also required to make use of technology
advancements. The architects of the product also need to consider this aspect of the
product.
Course Module
5
After defining architecture, software components and their interfaces, the next
phase of development is the creation of design documents. At the architecture level,
a component is defined as a black box that provides certain functionality. At the
design documents stage, you have to define what is in that black box. Senior
software developers usually create design documents and these documents define
individual software components to the level of functions and procedures. The design
document is the last document completed before development of the software
begins. These design documents are passed on to software developers and they start
coding. Architecture documents and MRDs typically need to stay in sync, as sales
and marketing will work from MRDs while engineering works from engineering
documents.
Implementation and Coding

The software developers take the design documents and development tools (editors,
compilers, debuggers etc.) and start writing software. This is usually the longest
phase in the product life cycle. Each developer has to write his/her own code and
collaborate with other developers to make sure that different components can
interoperate with each other. A revision control system such as CVS (Concurrent
Versions System) is needed in this phase. There are a few other open source
revision control systems as well as commercial options. The version control system
pro-vides a central repository to store individual files. A typical software project
may contain any-where from hundreds to thousands of files. In large and complex
projects, someone also needs to decide directory hierarchy so that files are stored in
appropriate locations. During the development cycle, multiple persons may modify
files. If everyone is not following the rules, this may easily break the whole
compilation and building process. For example, duplicate definitions of the same
variables may cause problems. Similarly, if included files are not written properly,
you can easily cause the creation of loops. Other problems pop up when multiple
files are included in a single file with conflicting definitions of variables and
functions.
Coding guidelines should also be defined by architects or senior software

developers. For example, if software is intended to be ported to some other platform
as well, it should be written on a standard like ANSI.
During the implementation process, developers must write enough comments

inside the code so that if anybody starts working on the code later on, he/she is able
to understand what has already been written. Writing good comments is very
important as all other documents, no matter how good they are, will be lost
Course Module
6
eventually. Ten years after the initial work, you may find only that information
which is present inside the code in the form of comments.
Development tools also play an important role in this phase of the project. Good
development tools save a lot of time for the developers, as well as saving money in
terms of improved productivity. The most important development tools for time
saving are editors and debuggers. A good editor helps a developer to write code
quickly. A good debugger helps make the written code operational in a short period
of time. Before starting the coding process, you should spend some time choosing
good development tools.
Review meetings during the development phase also prove helpful. Potential
problems are caught earlier in the development. These meeting are also helpful to
keep track of whether the product is on time or if more effort is needed complete it
in the required time frame. Sometimes you may also need to make some changes in
the design of some components because of new requirements from the marketing
and sales people. Review meetings are a great tool to convey these new
requirements. Again, architecture documents and MRDs are kept in sync with any
changes/problems encountered during development.
Testing
Testing is probably the most important phase for long-term support as well as for
the reputation of the company. If you don’t control the quality of the software, it will
not be able to compete with other products on the market. If software crashes at the
customer site, your customer loses productivity as well money and you lose
credibility. Sometimes these losses are huge. Unhappy customers will not buy your
other products and will not refer other customers to you. You can avoid this
situation by doing extensive testing. This testing is referred to as Quality Assurance,
or QA, in most of the software world.
Usually testing start as soon as the initial parts of the software is available. There
are multiple types of testing and these are explained in this section. Each of these
has its own importance.
Unit Testing
Unit testing is testing one part or one component of the product. The developer
usually does this when he/she has completed writing code for that part of the
product. This makes sure that the component is doing what it is intended to do. This
also saves a lot of time for software testers as well as developers by eliminating
Course Module
7
many cycles of software being passed back and forth between the developer and the
tester.
When a developer is confident that a particular part of the software is ready, he/she
can write test cases to test functionality of this part of the software. The component
is then forwarded to the software testing people who run test cases to make sure
that the unit is working properly.
Sanity Testing
Sanity testing is a very basic check to see if all software components compile with
each other without a problem. This is just to make sure that developers have not
defined conflicting or multiple functions or global variable definitions.
Regression or Stress Testing

Regression or stress testing is a process done in some projects to carry out a test for
a longer period of time. This type of testing is used to determine behavior of a
product when used continuously over a period of time. It can reveal some bugs in
software related to memory leak-age. In some cases developers allocate memory but
forget to release it. This problem is known as memory leakage. When a test is
conducted for many days or weeks, this problem results in allocation of all of the
available memory until no memory is left. This is the point where your soft-ware
starts showing abnormal behavior.
Another potential problem in long-term operation is counter overflow. This occurs
when you increment a counter but forget to decrement, it resulting in an overflow
when the product is used for longer periods.
The regression testing may be started as soon as some components are ready. This
testing process requires a very long period of time by its very nature. The process
should be continued as more components of the product are integrated. The
integration process and communication through interfaces may create new bugs in
the code.
Functional Testing
Functional testing is carried out to make sure that the software is doing exactly
what it is supposed to do. This type of testing is a must before any software is
released to customers. Functional testing is done by people whose primary job is
software testing, not the developers them-selves. In small software projects where a
company can’t afford dedicated testers, other developers may do functional testing
also. The key point to keep in mind is that the person who wrote a software
Course Module
8
component should not be the person who tested it. A developer will tend to test the
software the way he/she has written it. He/she may easily miss any problems in the
software.
The software testers need to prepare a testing plan for each component of the
software. A testing plan consists of test cases that are run on the software. The
software tester can prepare these test cases using functional specifications
documents. The tester may also get help from the developer to create test cases.
Each test case should include methodology used for testing and expected results.
In addition to test cases, the tester may also need to create a certain infrastructure
or environment to test the functionality of a piece of code. For example, you may
simulate a network to test routing algorithms that may be part of a routing product.
The next important job of the tester is to create a service request if an anomaly is
found. The tester should include as much information in the service request as
possible. Typical information included in reporting bugs includes:
 Test case description
 How the test was carried out
 Expected results
 Results obtained
 If a particular environment was created for testing, a description of that
environment
The service request should be forwarded to the developer so that the developer may
correct the problem. Many software packages are available in the market to track
bugs and fix problems in software. There are many web-based tools as well. For a
list of freely available open source projects, go to http://www.osdn.org or
http://www.sourceforge.net and search for “bug track”. OSDN (Open Source
Developers Network) hosts many open source software development projects. You
can find software packages that work with CVS also.
Software Releases
Before you start selling any software product, it is officially released. This means
that you create a state of the software in your repository, make sure that it has been
tested for functionality and freeze the code. A version number is assigned to release
software. After releasing the software, development may continue but it will not
make any change in the released software. The development is usually carried on in
a new branch and it may contain new features of the product. The released software
is updated only if a bug fixed version is released.
Course Module
9
Usually companies assign incremental version numbers following some scheme

when the next release of the software is sent to market. The change in version
number depends on whether the new software contains a major change to the
previous version or it contains bug fixes and enhancement to existing functionality.
Releases are also important because they are typically compiled versions of a
particular version of the code, and thus provide a stable set of binaries for testing.
Branches
In almost all serious software development projects, a revision or version control
system is used. This version control system keeps a record of changes in source
code files and is usually built in a tree-like structure. When software is released, the
state of each file that is part of the release should be recorded. Future developments
are made by creating branches to this state. Sometimes special branches may also be
created that are solely used for bug fixing.
Release Notes
Every software version contains release notes. These release notes are prepared by
people releasing the software version with the help of developers. Release notes
show what happened in this software version. Typically the information includes:
 Bug fixes
 New functionality
 Detail of new features added to the software
 Any bugs that are not yet fixed
 Future enhancements
If a user needs a change in the configuration process, it is also mentioned in the

release notes
Typically a user should be given enough information to understand the new release
enhancements and decide whether an upgrade is required or not.
Documentation
There are three broad categories of documentation related to software development
processes.
1. Technical documentation developed during the development process. This
includes architecture, functional and design documents.
Course Module
10
2. Technical documentation prepared for technical support staff. This includes

technical manuals that support staff use to provide customer support.
3. End-user manuals and guides. This is the documentation for the end user to
assist the user getting started with the product and using it.
All three types of documents are necessary for different aspects of product support.
Technical documents are necessary for future development, bug fixes, and adding
new features. Technical documentation for technical support staff contains
information that is too complicated for the end user to understand and use. The
support staff needs this information in addition to user manuals to better support
customers. Finally each product must contain user manuals.
Technical writers usually develop user manuals which are based on functional
specifications. In the timelines of most software development projects, functional
specifications are pre-pared before code development starts. So the technical
writers can start writing user manuals while developers are writing code. By the
time the product is ready, most of the work on user manuals has already been
completed.
Support and New Features
Your customers need support when you start selling a product. This is true
regardless of the size of the product, and even for products that are not software
related. Most common sup-port requests from customers are related to one of the
following:
 The customer needs help in installation and getting started.

 The customer finds a bug and you need to release a patch or update to the
whole product.
 The product does not fulfill customer requirements and a new feature is
required by the customer.
In addition to that, you may also want to add new features to the product for the
next release because competitor products have other features. Better support will
increase your customer loyalty and will create referral business for you.
You may adopt two strategies to add new features. You may provide an upgrade to
the cur-rent release as a patch, or wait until you have compiled and developed a list
of new features and make a new version. Both of these strategies are useful
depending how urgent the requirement for new features is.
Course Module
11
Components of a Development System

Like any other system, a development system is composed of many components that
work together to provide services to the developer for the software development
task. Depending upon the requirements of a project, different types of components
can be chosen. Many commercial companies also sell comprehensive development
tools. On Linux systems, all of the development tools are available and you can
choose some of these depending upon your level of expertise with these tools and
your requirements. Typically each development platform consists of the following
components:
 Hardware platform
 Operating system
 Editor
 Compilers and assemblers
 Debuggers
 Version control system
 Collaboration and bug tracking
Let us take a closer look on these components and what role they play in the
development cycle.
Hardware Platform
This is the tangible part of the development system. A hardware platform is the
choice of your hardware, PC or workstation, for the development system. You can
choose a particular hardware platform depending upon different factors as listed
below:
Course Module
12
Depending upon these factors, you may make a choice from the available hardware
plat-forms for development.
If hardware is part of the final product, selection of hardware platform also depends
upon customer/market requirement.
Operating System
Choice of a particular operating system may be made depending upon:
 Cost
 Availability of development tools
 Hardware platform
 Native or cross compiling
Some operating systems are cheaper than others. Linux is an excellent choice, as far
as cost is concerned. Linux is also a very good operating system as it has all of the
development tools available. Now you can install Linux on high-end workstations
from Sun Microsystems, HP, and IBM as well as commodity PC hardware available
everywhere. It provides stability and most of the people are familiar with
development tools. You can also use the operating system for cross-platform
development using GNU tools.
Editors
Editors play an important role in the development work. Easy-to-use and feature
rich editors, like Emacs, increase developers’ productivity. You should look at a few
things while selecting editors. These features include:
 Understanding syntax of language
 Collapsing of context
 Support of tags
 Opening multiple files
 Easy editing for generally used editing functions like cut, copy, paste, search,
replace and so on
 Multiple windows
 Support of user defined functions and macros
If you look at the open source community, you can find a lot of good editors
available to developers. The most commonly used editors are Jed, Emacs and
Xemacs. However, many other variants of these editors are also available. You can
also use X-Windows-based editors available on Linux platform. A lot of people also
edit in vi or vim, both of these have been very popular historically.
Course Module
13
Compilers and Assemblers

Compilers and assemblers are the core development tools because they convert
source code to executable form. Quality of compilers does affect the output code. For
example, some compilers can do much better code optimization compared to others.
If you are doing some cross-platform development, then your compiler should
support code generation for the target machine as well.
GNU compilers collection, more commonly called GCC, is a comprehensive set of
com-pilers for commonly used languages including the following:
 C
 C++
 Java
 Fortran
In addition to GCC, you can find a lot of other open source compilers available for
Linux.
GNU utilities set, also known as binutils, include GNU assembler and other utilities
that can be used for many tasks. GNU assembler is used whenever you compile a
program using GNU compiler.
Debuggers
Debuggers are the also an important part of all development systems. You can’t
write a program that is free of bugs. Debugging is a continuous part of software
development and you need good tools for this purpose. GNU debugger, more
commonly known as GDB, is a common debugger. Many other debuggers are also
built on this debugger. The GNU debugger and some other debuggers will be
introduced later in this book.
Version Control Systems

The revision control system is a must for any serious development effort where
multiple developers work on a software product. The most popular version control
system on Linux is known as Concurrent Versions System or CVS. CVS allows many
people to work on files at the same time and provides a central repository to store
files. Developers can check out files from this repository, make changes and check
the files back into the repository. CVS also works with editors like GNU Emacs.
Course Module
14
When multiple developers are modifying the same file at the same time, conflict may
occur between different changes made by multiple developers. When a conflict is
detected in the files being checked in, CVS provides a mechanism to merge the files
appropriately.
CVS can be used over secure links as well. This is required when developers are not
physically located at the same place. A server on the Internet can be used to provide
secure access to the central software repository.
There are other version control systems as well which are popular in the software
development community. Examples are Aegis, PRCS, RCS and SCCS.
E-mail and Collaboration

In any software development project, collaboration among developers, designers
and architects as well as marketing people is a must. The objective can be achieved
in many ways. Probably e-mail is the most efficient and cheapest way. Some
collaboration tools provide more functionality than just e-mailing.
X-Windows
X-Windows is much more than just a GUI interface on Linux, but for development
purposes, it provides a very good user interface. This is especially useful for editors
like Emacs.
Miscellaneous Tools
Many miscellaneous tools are also important during the development process. Some
of these tools are listed below:
 The make utility

 The ar program
 The ranlib utility
 The hexdump utility
Information about these tools is provided later in this book.
Selection Criteria for Hardware Platform

The development process needs computers, networks, storage, printing and other
hardware components. However the important hardware decision is the selection of
Course Module
15
PCs and workstations for developers. There is no hard and fast rule about how to
select a particular hardware platform. It depends upon the requirements of a
development project. Some factors that you may keep in mind are as follows:
 Cost of the hardware.

 Availability of desired operating system on the hardware. For example, you
can’t run HP-UX on PCs.
 Availability of development tools.
 Maintenance cost.
There may be other factors as well and you are the best person to judge what you
need. However, keep in mind that reliability of hardware is one major factor that
people usually over-look. If you buy cheap systems that decrease productivity of
developers, you lose a lot of money.
Selection Criteria for Software Development Tools

After selecting the hardware, software development tools are the next major initial
expense in terms of money and time to set these up. Selection of software
development tools depends upon the choice of hardware and operating system. In
many cases GNU tools are very well suited. Selection of development tools also has a
major effect on the productivity of the whole development team.
Managing Development Process

In large software development projects, management of the development process is
a big task and a dedicated person may be needed to take care of this aspect of the
project. A development manager usually acts as a binding and coordinating force
among different parties with conflict-ing interests. These parties include:
 Marketing and sales people who put forward requirements, change

requirements and come up with new requirements, usually when much of
the work is already done!
 Architecture and design people.
 Software developers who always think that they always have less amount of
time.
 Release management people.
 Software testers.
 Documentation writers.
Course Module
16
 Senior managers who often push to complete the project earlier than the
deadline.
Coordinating all of these parties is not an easy task. The manager has to convince
senior management that a new feature needs that much time for development. At
the same time he has to push developers to meet the deadlines. Some of the
important tasks of software management in a real-life project are as follows.
Creating Deadlines
The manager usually coordinates with the software developers to set reasonable
dead-lines for certain features. These deadlines must conform to the product
delivery time lines. The manager may have to arrange additional resources to
complete feature development in the allotted time.
Project management software can help a manager to set and meet deadlines and
track completion of different components.
Managing the Development Team
The manager has to keep track of how development among different parts of the
software is going on. If part of the product is behind schedule, she has to re-arrange
resources to get it back on track.. She may also need to hire new people to finish the
development of a particular component on schedule.
Resolving Dependencies
Usually software components are dependent on one another. If the development of
one component is lagging behind, it may affect development of other components.
The development manager needs to keep an eye on these dependencies and how
these may affect the over-all progress of the project. Well-known project
management methods are usually helpful for this task.

Books and Journals
Course Module
17

1. LDPS web site at http://www.freestandards.org/ldps/; October 15, 2019
2. CVS web site at http://www.gnu.org/software/cvs/; October 15, 2019
3. Aegis at web site http://aegis.sourceforge.net/index.html; October 15, 2019
4. PRCS at its web site http://prcs.sourceforge.net/; October 15, 2019
5. GNU Software at http://www.gnu.org; October 15, 2019
Course Module
Week 003
Technical Development

• Identify the Life Cycle of a Software Development Project
• Understand the Requirements Gathering
• Understand the different types of testing in developing software
• Know the components of developing a system
Life Cycle of a Software Development Project

Software development is a complicated process comprising many stages.
Each stage requires a lot of paperwork and documentation in addition to
the development and planning process.
This is in contrast to the common thinking of newcomers to the software

industry who believe that software development is just “writing code.”
Each software development project has to go through at least the

following stages:
• Requirement gathering
• Writing functional specifications
• Creating architecture and design documents
• Implementation and coding
• Testing and quality assurance
• Software release
• Documentation
• Support and new features
Requirements Gathering
Requirement gathering is usually the first part of any software product.
This stage starts when you are thinking about developing software. In this
phase, you meet customers or prospective customers, analyzing market
requirements and features that are in demand.
You also find out if there is a real need in the market for the software
product you are trying to develop.
What are requirements?

• A requirement is a statement about an intended product that specifies
what it should do or how it should perform.
• Goal: To make as specific, unambigous, and clear as possible.

What requirements should be gathered?

• Functional: What the product should do.
• Data requirements: Capture the type, volatility, size/amount,
persistence, accuracy and the amounts of the required data.
• Environmental requirements: a) context of use b) Social environment
(eg. Collaboration and coordination) c) how good is user support likely
to be d) what technologies will it run on
• User Requirements: Capture the characteristics of the intended user
group.
• Usability Requirement: Usability goals associated measures for a
particular product (More info on Chapter 6).
Data Gathering Techniques

• Questionnaires: Series of questions designed to elicit specific
information from us. The questions may require different kinds of
answers: some require a simple Yes/No, others ask us to choose from a
set of pre-supplied answers.
• Interviews: Interviews involve asking someone a set of questions.

Often interviews are face-to-face, but they don’t have to be (more on
next page).
Data Gathering Techniques (continued)

• Interviews:
• Forum for talking to people
• Structured, unstructured or semi-structured
• Props, e.g. sample scenarios of use,
prototypes, can be used in interviews
• Good for exploring issues
• But are time consuming and may be
infeasible to visit everyone
Task Classification
• Is the Task a set of sequential steps or is it a rapidly overlaying series of
sub-tasks?
• Does the task involve high information content : High information

content or low --- is it complex or simple to interpret visual displays.
• Is the task intended to be performed by a layman without much

training or by a practitioner skilled in the task domain?
Data Gathering Guidelines

• Focus on identifying the stakeholders
• Involve all the stakeholder groups
• Need more than on person from stakeholder group(s)
• Use a combination of data gathering techniques
For example: use observation to understand the context, interviews
to target specific user groups, questionnaires to reach a wider
population, and focus groups to build a consensus view
Coding
• Coding is undertaken once the design phase is complete and the
design documents have been successfully reviewed. In the coding
phase, every module identified and specified in the design document
is independently coded and unit tested.
• The input to the coding phase is the design document.
• During the coding phase, different modules identified in the design
document are coded according to the respective module
specifications.
Programming practice
• The primary goal of the coding phase is to translate the given design
into source code in a given programming language, so that the code
is simple easy to test and easy to understand and modify.
• So now we will discuss some concepts related to coding in a
language independent manner.
Information hiding
• Information hiding can reduce the coupling between modules and
make the system more maintainable.
• Information hiding is also an effective tool for managing the
complexity of developing software.
• Another form of information hiding is to let a module see only those
data items needed by it.
Internal documentation
• Internal documentation of the program is done by the use of
comments. All languages provide a means for writing comments
in program. Comments are textual statements that are meant for
the program reader and are not executed.
Coding Standards
• General coding standards pertain to how the developer writes code,
so here we will discuss some important standard regardless of the
programming language being used.
Indentation
• Proper and consistent indentation is important in producing easy to
read and maintainable programs. Indentation should be used to:
• Emphasize the body of a control statement such as a loop or a select
statement
• Emphasize the body of a conditional statement Emphasize a
new scope block
Inline Comments
• Inline comments explaining the functioning of the subroutine or key
aspects of the algorithm shall be frequently used.
Structured Programming
• Structured (or modular) programming techniques shall be used. GO
TO statements shall not be used as they lead to “spaghetti” code,
which is hard to read and maintain, except as outlined in the
FORTRAN Standards and Guidelines.
Source File
• The name of the source file or script shall represent its function. All of
the routines in a file shall have a common purpose.
Variable Names
• Variable shall have mnemonic or meaningful names that convey to a
casual observer, the intent of its use. Variables shall be initialized prior
to its first use.
Coding Guidelines
• General coding guidelines provide the programmer with a set of best
practices which can be used to make programs easier to read and
maintain.
• Most of the examples use the C language syntax but the guidelines
can be applied to all languages.
Line Length
• It is considered good practice to keep the lengths of source code lines
at or below 80 characters. Lines longer than this may not be
displayed properly on some terminals and tools. Some printers will
truncate lines longer than 80 columns.
Spacing
The proper use of spaces within a line of code can enhance readability.
Example:
Bad:
cost=price+(price*sales_tax);
fprintf(stdout ,“The total cost is %5.2f\n”,cost);
Better:
cost = price + ( price * sales_tax );
fprintf (stdout, “The total cost is %5.2f\n”, cost) ;
Wrapping Lines
When an expression will not fit on a single line, break it according to these following
principles:
• Break after a comma
Example:
Bad:
longName1 = longName2 * (longName3 + LongName4 –
longName5) + 4 * longName6 ;
Better:
longName1 = longName2 * (longName3 + LongName4 – LongName5)
+ 4 * longName6 ;
Variable Declarations
Variable declarations that span multiple lines should always be preceded
by a type.
Example: Acceptable:
int price , score ;
Acceptable:
int price ; int score ;
Not Acceptable:
int price , score ;
1
Week 4: Software Project Management
Module 004: Software Project Management

1. Understand the specific roles within a software organization as related to
project and process management
2. Understand the basic infrastructure competences (e.g., process modeling
and measurement)
3. Understanding the basic steps of project planning, project management,
quality assurance, and process management and their relationships
Introduction
Project management has been practiced since early civilization. Until the beginning of
twentieth century civil engineering projects were actually treated as projects and were
generally managed by creative architects and engineers. Project management as a
discipline was not accepted. It was in the 1950s that organizations started to systematically
apply project management tools and techniques to complex projects. As a discipline,
Project Management developed from several fields of application including construction,
engineering, and defense activity. Two forefathers of project management are commonly
known: Henry Gantt, called the father of planning and control techniques who is famous for
his use of the Gantt chart as a project management tool; and Henri Fayol for his creation of
the five management functions which form the foundation of the body of knowledge
associated with project and program management. The 1950s marked the beginning of the
modern Project Management era. Project management became recognized as a distinct
discipline arising from the management discipline.
What is a Project?
All of us have been involved in projects, whether they be our personal projects or in
business and industry. Examples of typical projects are for example:
Personal projects:
 obtaining an MCA degree
 writing a report
 planning a party
 planting a garden
Industrial projects:
Course Module
2
 Construction of a building
 Provide electricity to an industrial estate
 Building a bridge
 Designing a new airplane
Projects can be of any size and duration. They can be simple, like planning a party,
or complex like launching a space shuttle.
Project Definition:
A project can be defined in many ways :
A project is “a temporary endeavor undertaken to create a unique product, service,

or result.” Operations, on the other hand, is work done in organizations to sustain
the business. Projects are different from operations in that they end when their
objectives have been reached or the project has been terminated.
A project is temporary. A project’s duration might be just one week or it might go

on for years, but every project has an end date. You might not know that end date
when the project begins, but it’s there somewhere in the future. Projects are not the
same as ongoing operations, although the two have a great deal in common.
A project is an endeavor. Resources, such as people and equipment, need to do

work. The endeavor is undertaken by a team or an organization, and therefore
projects have a sense of being intentional, planned events. Successful projects do not
happen spontaneously; some amount of preparation and planning happens first.
Finally, every project creates a unique product or service. This is the deliverable for
the project and the reason, why that project was undertaken.
Project Attributes
Projects come in all shapes and sizes. The following attributes help us to define a
project further:
 A project has a unique purpose. Every project should have a well-defined

objective. For example, many people hire firms to design and build a new
house, but each house, like each person, is unique.
 A project is temporary. A project has a definite beginning and a definite end.

For a home construction project, owners usually have a date in mind when
they’d like to move into their new homes.
 A project is developed using progressive elaboration or in an iterative fashion.

Projects are often defined broadly when they begin, and as time passes, the
specific details of the project become clearer. For example, there are many
Course Module
3
decisions that must be made in planning and building a new house. It works
best to draft preliminary plans for owners to approve before more detailed
plans are developed.
 A project requires resources, often from various areas. Resources include

people, hardware, software, or other assets. Many different types of people,
skill sets, and resources are needed to build a home.
 A project should have a primary customer or sponsor. Most projects have

many interested parties or stakeholders, but someone must take the primary
role of sponsorship. The project sponsor usually provides the direction and
funding for the project.
 A project involves uncertainty. Because every project is unique, it is

sometimes difficult to define the project’s objectives clearly, estimate exactly
how long it will take to complete, or determine how much it will cost.
External factors also cause uncertainty, such as a supplier going out of
business or a project team member needing unplanned time off. This
uncertainty is one of the main reasons project management is so challenging.
Project Constraints
Like any human undertaking, projects need to be performed and delivered under
certain constraints. Traditionally, these constraints have been listed as scope, time,
and cost. These are also referred to as the Project Management Triangle, where each
side represents a constraint. One side of the triangle cannot be changed without
impacting the others. A further refinement of the constraints separates product
'quality' or 'performance' from scope, and turns quality into a fourth constraint.
The time constraint refers to the amount of time available to complete a project. The
cost constraint refers to the budgeted amount available for the project. The scope
constraint refers to what must be done to produce the project's end result. These
three constraints are often competing constraints: increased scope typically means
increased time and increased cost, a tight time constraint could mean increased
costs and reduced scope, and a tight budget could mean increased time and reduced
scope.
The discipline of project management is about providing the tools and techniques
that enable the project team (not just the project manager) to organize their work to
meet these constraints.
Another approach to project management is to consider the three constraints as

finance, time and human resources. If you need to finish a job in a shorter time, you
can allocate more people at the problem, which in turn will raise the cost of the
project, unless by doing this task quicker we will reduce costs elsewhere in the
project by an equal amount.
Course Module
4
Time:
For analytical purposes, the time required to produce a product or service is
estimated using several techniques. One method is to identify tasks needed to
produce the deliverables documented in a work breakdown structure or WBS. The
work effort for each task is estimated and those estimates are rolled up into the final
deliverable estimate.
The tasks are also prioritized, dependencies between tasks are identified, and this
information is documented in a project schedule. The dependencies between the
tasks can affect the length of the overall project (dependency constraint), as can the
availability of resources (resource constraint). Time is not considered as cost nor a
resource since the project manager cannot control the rate at which it is expended.
This makes it different from all other resources and cost categories.
Cost:
Cost to develop a project depends on several variables including: labor rates,
material rates, risk management, plant (buildings, machines, etc.), equipment, and
profit. When hiring an independent consultant for a project, cost will typically be
determined by the consultant's or firm's per diem rate multiplied by an estimated
quantity for completion.
Figure 4.1: The Project management Triangle
Scope:
Scope is requirement specified for the end result. The overall definition of what the
project is supposed to accomplish, and a specific description of what the end result
should be or accomplish can be said to be the scope of the project. A major
Course Module
5
component of scope is the quality of the final product. The amount of time put into
individual tasks determines the overall quality of the project. Some tasks may
require a given amount of time to complete adequately, but given more time could
be completed exceptionally. Over the course of a large project, quality can have a
significant impact on time and cost or vice versa.
Together, these three constraints viz. Scope, Schedule & Resources have given rise
to the phrase "On Time, On Spec, On Budget". In this case, the term "scope" is
substituted with "spec(ification)"
What is Project Management?

Project management is “the application of knowledge, skills, tools and techniques
to project activities to meet the project requirements.” The effectiveness of project
management is critical in assuring the success of any substantial activity. Areas of
responsibility for the person handling the project include planning, control and
implementation. A project should be initiated with a feasibility study, where a clear
definition of the goals and ultimate benefits need to be determined. Senior
managers' support for projects is important so as to ensure authority and direction
throughout the project's progress and, also to ensure that the goals of the
organization are effectively achieved in this process.
Knowledge, skills, goals and personalities are the factors that need to be considered
within project management. The project manager and his/her team should
collectively possess the necessary and requisite interpersonal and technical skills to
facilitate control over the various activities within the project.
The stages of implementation must be articulated at the project planning phase.

Disaggregating the stages at its early point assists in the successful development of
the project by providing a number of milestones that need to be accomplished for
completion. In addition to planning, the control of the evolving project is also a
prerequisite for its success. Control requires adequate monitoring and feedback
mechanisms by which senior management and project managers can compare
progress against initial projections at each stage of the project. Monitoring and
feedback also enables the project manager to anticipate problems and therefore
take pre-emptive and corrective measures for the benefit of the project.
Projects normally involve the introduction of a new system of some kind and, in
almost all cases, new methods and ways of doing things. This impacts the work of
others: the "users". User interaction is an important factor in the success of projects
and, indeed, the degree of user involvement can influence the extent of support for
the project or its implementation plan. A project manager is the one who is
responsible for establishing a communication in between the project team and the
user. Thus one of the most essential quality of the project manager is that of being a
good communicator, not just within the project team itself, but with the rest of the
organization and outside world as well.
Course Module
6
Features of projects:
Projects are often carried out by a team of people who have been assembled for that
specific purpose. The activities of this team may be co-ordinated by a project
manager.
Project teams may consist of people from different backgrounds and different parts
of the organization. In some cases project teams may consist of people from
different organizations.
Project teams may be inter-disciplinary groups and are likely to lie outside the
normal organization hierarchies.
The project team will be responsible for delivery of the project end product to some
sponsor within or outside the organization. The full benefit of any project will not
become available until the project has been completed.
Project Classification:
In recent years more and more activities have been tackled on a project basis.
Project teams and a project management approach have become common in most
organizations. The basic approaches to project management remain the same
regardless of the type of project being considered. You may find it useful to consider
projects in relation to a number of major classifications:
a) Engineering and construction

The projects are concerned with producing a clear physical output, such as
roads, bridges or buildings. The requirements of a project team are well defined
in terms of skills and background, as are the main procedures that have to be
undergone. Most of the problems which may confront the project team are likely
to have occurred before and therefore their solution may be based upon past
experiences.
b) Introduction of new systems

These projects would include computerization projects and the introduction of
new systems and procedures including financial systems. The nature and
constitution of a project team may vary with the subject of the project, as
different skills may be required and different end-users may be involved. Major
projects involving a systems analysis approach may incorporate clearly defined
procedures within an organization.
c) Responding to deadlines and change

An example of responding to a deadline is the preparation of an annual report by
a specified date. An increasing number of projects are concerned with designing
organizational or environmental changes, involving developing new products
and services.
Course Module
7
Project Management Tools and techniques:

Project planning is at the heart of project management. One can't manage and
control project activities if there is no plan. Without a plan, it is impossible to know
if the correct activities are underway, if the available resources are adequate or of
the project can be completed within the desired time. The plan becomes the
roadmap that the project team members use to guide them through the project
activities. Project management tools and techniques assist project managers and
their teams in carrying out work in all nine knowledge areas. For example, some
popular time-management tools and techniques include Gantt charts, project
network diagrams, and critical path analysis. Table 4.1 lists some commonly used
tools and techniques by knowledge area.
Course Module
8
Table 4.1: Project Management Tools and Techniques
Project Success Factors:

The successful design, development, and implementation of information technology
(IT) projects is a very difficult and complex process. However, although developing
IT projects can be difficult, the reality is that a relatively small number of factors
control the success or failure of every IT project, regardless of its size or complexity.
The problem is not that the factors are unknown; it is that they seldom form an
integral part of the IT development process.
Course Module
9
Some of the factors that influence projects and may help them succeed are
 Executive Support
 User involvement
 Experienced project managers
 Limited scope
 Clear basic requirements
 Formal methodology
 Reliable estimates
The Role of Project Manager

The project manager is the driving force in the management control loop. This
individual seldom participates directly in the activities that produce the end result,
but rather strives to maintain the progress and productive mutual interaction of
various parties in such a way that overall risk of failure is reduced.
A project manager is often a client representative and has to determine and

implement the exact needs of the client, based on knowledge of the firm he/she is
representing. The ability to adapt to the various internal procedures of the
contracting party, and to form close links with the nominated representatives, is
essential in ensuring that the key issues of cost, time, quality, and above all, client
satisfaction, can be realized.
In whatever field, a successful project manager must be able to envisage the entire
project from start to finish and to have the ability to ensure that this vision is
realized.
When they are appointed, project managers should be given terms of reference that
define their:
 Objectives;
 Responsibilities;
 Limits of authority.
Responsibilities of a Project Manager:

The objective of every project manager is to deliver the product on time, within
budget and with the required quality. Although the precise responsibilities of a
project manager will vary from company to company and from project to project,
they should always include planning and forecasting. Three additional areas of
management responsibility are:
 interpersonal responsibilities, which include:
- leading the project team;
- liaising with initiators, senior management and suppliers;
- Being the 'figurehead', i.e. setting the example to the project team and
representing the project on formal occasions.
Course Module
10
 informational responsibilities, which include:

- monitoring the performance of staff and the implementation of the
project plan;
- disseminating information about tasks to the project team;
- disseminating information about project status to initiators and
senior management;
- Acting as the spokesman for the project team.
 decisional responsibilities, which include:
- allocating resources according to the project plan, and adjusting those
allocations when circumstances dictate (i.e. the project manager has
responsibility for the budget);
- negotiating with the initiator about the optimum interpretation of
contractual obligations, with the company management for resources,
and with project staff about their tasks;
- Handling disturbances to the smooth progress of the project such as
equipment failures and personnel problems.
Project Life Cycle

The Project Life Cycle refers to a logical sequence of activities to accomplish
the project’s goals or objectives. Regardless of scope or complexity, any project
goes through a series of stages during its life. There is first an Initiation or Starting
phase, in which the outputs and critical success factors are defined, followed by a
Planning phase, characterized by breaking down the project into smaller
parts/tasks, an Execution phase, in which the project plan is executed, and lastly a
Closure or Exit phase, that marks the completion of the project. Project activities
must be grouped into phases because by doing so, the project manager and the core
team can efficiently plan and organize resources for each activity, and also
objectively measure achievement of goals and justify their decisions to move ahead,
correct, or terminate. It is of great importance to organize project phases into
industry-specific project cycles. Why? Not only because each industry sector
involves specific requirements, tasks, and procedures when it comes to projects, but
also because different have industry sectors had different needs for life cycle
management methodology. And paying close attention to such details is the
difference between doing things well and excelling as project managers.
Diverse project management tools and methodologies prevail in the different

project cycle phases. Let’s take a closer look at what’s important in each one of these
stages:
Project Initiation:
The initiation stage determines the nature and scope of the development. If this
stage is not performed well, it is unlikely that the project will be successful in
Course Module
11
meeting the business’s needs. The key project controls needed here are an
understanding of the business environment and making sure that all necessary
controls are incorporated into the project. Any deficiencies should be reported and a
recommendation should be made to fix them.
The initiation stage should include a plan that encompasses the following areas:
 Analyzing the business needs/requirements in measurable goals.
 Reviewing of the current operations.
 Conceptual design of the operation of the final product.
 Equipment and contracting requirements including an assessment
of long lead time items.
 Financial analysis of the costs and benefits including a budget.
 Stakeholder analysis, including users, and support personnel for
the project.
 Project charter including costs, tasks, deliverables, and schedule.
Figure 4.2: Project Life Cycle
Course Module
12
Planning & Design:

After the initiation stage, the system is designed. Occasionally, a small prototype of
the final product is built and tested. Testing is generally performed by a
combination of testers and end users, and can occur after the prototype is built or
concurrently. Controls should be in place that ensures that the final product will
meet the specifications of the project charter. The results of the design stage should
include a product design that:
 Satisfies the project sponsor (the person who is providing the

project budget), end user, and business requirements.
 Functions as it was intended.
 Can be produced within acceptable quality standards.
 Can be produced within time and budget constraints.
Execution & Controlling:

Monitoring and Controlling consists of those processes performed to observe
project execution so that potential problems can be identified in a timely manner
and corrective action can be taken, when necessary, to control the execution of the
project. The key benefit is that project performance is observed and measured
regularly to identify variances from the project management plan.
Monitoring and Controlling includes:

 Measuring the ongoing project activities (where we are);
 Monitoring the project variables (cost, effort, scope, etc.) against the project
management plan and the project performance baseline (where we should
be);
 Identify corrective actions to address issues and risks properly (How can we
get on track again);
 Influencing the factors that could circumvent integrated change control so
only approved changes are implemented
In multi-phase projects, the Monitoring and Controlling process also provides
feedback between project phases, in order to implement corrective or preventive
actions to bring the project into compliance with the project management plan.
Project Maintenance is an ongoing process, and it includes:

 Continuing support of end users
 Correction of errors
 Updates of the software over time
Course Module
13
In this stage, auditors should pay attention to how effectively and quickly user
problems are resolved.
Over the course of any IT project, the work scope may change. Change is normal and
expected part of the process. Changes can be the result of necessary design
modifications, differing site conditions, material availability, client-requested
changes, value engineering and impacts from third parties, to name a few. Beyond
executing the change in the field, the change normally needs to be documented to
show what was actually developed. This is referred to as Change Management.
Hence, the owner usually requires a final record to show all changes or, more
specifically, any change that modifies the tangible portions of the finished work. The
record is made on the contract documents – usually, but not necessarily limited to,
the design drawings. The end product of this effort is what the industry terms as-
built drawings, or more simply, “as built.”
When changes are introduced to the project, the viability of the project has to be re-
assessed. It is important not to lose sight of the initial goals and targets of the
projects. When the changes accumulate, the forecasted result may not justify the
original proposed investment in the project.
Closure:
Closing includes the formal acceptance of the project and the ending
thereof. Administrative activities include the archiving of the files and
documenting lessons learned.
This phase consists of:
 Project close: Finalize all activities across all of the process groups
to formally close the project or a project phase.
 Contract closure: Complete and settle each contract (including the
resolution of any open items) and close each contract applicable to
the project or project phase.
Sample Questions
1. Why is there a new or renewed interest in the field of project
management?
2. What is a project, and what are its main attributes? How is a project
different from what most people do in their day-to-day jobs? What
is the triple constraint?
3. What is project management? Briefly describe the project
management framework, providing examples of stakeholders,
knowledge areas, tools and techniques, and project success factors.
Course Module
14
4. Discuss the relationship between project, program, and portfolio

Management and their contribution to enterprise success.
5. What are the roles of the project, program, and portfolio
managers? What are suggested skills for project managers? What
additional skills do program and portfolio managers need?

Books and Journals
1. Information Technology Project Management: Kathy Schwalbe Thomson
Publication.
2. Information Technology Project Management providing measurable
organizational value Jack Marchewka Wiley India.
3. Applied software project management Stellman & Greene SPD.
4. Software Engineering Project Management by Richard Thayer, Edward Yourdon
WILEY INDIA.
Course Module
Week 004
Software Project Management

• Understand the specific roles within a software organization as related
to project and process management
• Understand the basic infrastructure competences (e.g., process
modeling and measurement)
• Understanding the basic steps of project planning, project
management, quality assurance, and process management and their
relationships
• To learn the techniques required to plan, organize, monitor and control
software projects
Lecture Outline
• What is a Project
• Details relevant to Project
• What is Project Management
• Details relevant to Project Management
• What is Software Project Management
• Details relevant to Software Project Management
What is a Project ?
• PMI definition
• It is a temporary endeavor (having specific start and completion
dates) undertaken to create a unique product or service
Elaborating the Definition …

• Temporary
• means that every project has a definite beginning and definite end
• End is reached when …
• project’s objectives have been achieved OR
• It is clear that objective will not be met. The project is
terminated in such a situation
• The term temporary does not apply to a project’s product or
service (which is a lasting result)
• Unique
• means that the product or service is different in some
distinguishing way from all similar products or services
Projects
• Projects may involve a single person or thousands
• Projects may be completed in hours, several months or years
• Examples of projects
• Developing a new product or service
• Designing a new vehicle
• Constructing a building
• Running a campaign for political office
• Implementing a new business procedure or process
• And so on …
What is Project Management ?
It is the discipline of
planning, organizing, and managing resources
to bring about the successful completion of
specific project goals and objectives
Project Management
• Following are related to Project Management
• Professional Organizations
 Project Management Institute (PMI) (pmi.org)
 Software Engineering Institute (SEI)
 IEEE Software Engineering Group
• Certifications
 PMI’s PMP (Project Management Professional)
• The “PMBOK” – PMI Body of Knowledge
• Tools
 MS Project
 Primavera Project Manager
Project Management
Project Management Skills
• Leadership
• Communications
• Problem Solving
• Negotiating
• Influencing the Organization
• Mentoring
• Process and technical expertise
Project Management
Project Manager Positions
• Project Administrator / Coordinator
• Assistant Project Manager
• Project Manager / Program Manager
• Executive Program Manager
• V.P. Program Development
Project Management Knowledge Areas

• PMI has suggested 9 Knowledge Areas
• Project Integration Management
• Project Scope Management
• Project Time Management
• Project Cost Management
• Project Quality Management
• Project Human Resource Management
• Project Communications Management
• Project Risk Management
• Project Procurement Management

Management
Project
Management
Software
Project
Management

• a sub-discipline of project management in which software projects are
planned, monitored and controlled
Project Planning
• Its purpose is to identify the
• scope of the project,
• estimate the work involved,
• and create a project schedule.
• Project planning begins with requirements that define the software to
be developed.
• The project plan is then developed to describe the tasks that will lead
to completion
Project Monitoring and Control

• The purpose
• To keep the team and management up to date on the project's
progress.
• If the project deviates from the plan, then the project manager can
take action to correct the problem.
• Project monitoring and control involves status meetings to gather
status from the team. When changes need to be made, change control
is used to keep the products up to date.
1
Week 6: Software Quality Management
Module 005: Software Quality Management

1. Understand the issue of Software Quality and the activities present in a
typical Quality Management process.
2. Understand the advantages of difficulties presented by the use of Quality
standards in Software Engineering
3. Understand the concepts of Software Quality Management
Introduction
Computers and software are ubiquitous. Mostly they are embedded and we don’t even
realize where and how we depend on software. We might accept it or not, but software is
governing our world and society and will continue further on. It is difficult to imagine our
world without software. There would be no running water, food supplies, business or
transportation would disrupt immediately, diseases would spread, and security would be
dramatically reduced – in short, our society would disintegrate rapidly. A key reason our
planet can bear over six billion people is software. Since software is so ubiquitous, we need
to stay in control. We have to make sure that the systems and their software run as we
intend – or better. Only if software has the right quality, we will stay in control and not
suddenly realize that things are going awfully wrong. Software quality management is the
discipline that ensures that the software we are using and depending upon is of right
quality. Only with solid understanding and discipline in software quality management, we
will effectively stay in control.
What exactly is software quality management? To address this question we first need to
define the term “quality”. Quality is the ability of a set of inherent characteristics of a
product, service, product component, or process to fulfill requirements of customers [1].
From a management and controlling perspective quality is the degree to which a set of
inherent characteristics fulfills requirements. Quality management is the sum of all planned
systematic activities and processes for creating, controlling and assuring quality [1]. Fig. 1
indicates how quality management relates to the typical product development. We have
used a V-type visualization of the development process to illustrate that different quality
control techniques are applied to each level of abstraction from requirements engineering
to implementation. Quality control questions are mentioned on the right side. They are
addressed by techniques such as reviews or testing. Quality assurance questions are
mentioned in the middle. They are addressed by audits or sample checks. Quality
improvement questions are mentioned on the left side. They are addressed by dedicated
improvement projects and continuous improvement activities.
Course Module
2
Quality Concepts
The long-term profitability of a company is heavily impacted by the quality
perceived by customers. Customers view achieving the right balance of reliability,
market window of a product and cost as having the greatest effect on their long-
term link to a company. This has been long articulated, and applies in different
economies and circumstances. Even in restricted competitive situations, such as a
market with few dominant players (e.g., the operating system market of today or the
database market of few years ago), the principle applies and has given rise to open
source development. With the competitor being often only a mouse-click away,
today quality has even higher relevance. This applies to Web sites as well as to
commodity goods with either embedded or dedicated software deliveries. And the
principle certainly applies to investment goods, where suppliers are evaluated by a
long list of different quality attributes.
Methodological approaches to guarantee quality products have led to international

guidelines (e.g., ISO 9001) and widely applied methods to assess the development
processes of software providers (e.g., SEI CMMI). In addition, most companies apply
certain techniques of criticality prediction that focus on identifying and reducing
release risk. Unfortunately, many efforts usually concentrate on testing and
reworking instead of proactive quality management.
Yet there is a problem with quality in the software industry. By quality we mean the
bigger picture, such as delivering according to commitments. While solutions
abound, knowing which solutions work is the big question. What are the most
fundamental underlying principles in successful projects? What can be done right
now? What actually is good or better? What is good enough – considering the
immense market pressure and competition across the globe?
A simple – yet difficult to digest and implement – answer to these questions is that
software quality management is not simply a task, but rather a habit. It must be
engrained in the company culture. It is something that is visible in the way people
are working, independent on their role. It certainly means that every single person
in the organization sees quality as her own business not that of a quality manager or
a testing team. A simple yet effective test to quickly identify the state of practice
with respect to quality management is to ask around what quality means for an
employee and how he delivers according to this meaning. You will identify that
many see it as a bulky and formal approach to be done to achieve necessary
certificates. Few exceptions exist, such as industries with safety and health impacts.
But even there, you will find different approaches to quality, depending on culture.
Those with carrot and stick will not achieve a true quality culture. Quality is a habit.
It is driven by objectives and not based on believes. It is primarily achieved when
each person in the organization knows and is aware on her own role to deliver
quality.
Quality management is the responsibility of the entire enterprise. It is

strategically defined, directed and operationally implemented on various
Course Module
3
organizational levels. Fig. 1 shows in a simplified organizational layout with four

tiers the respective responsibilities to successfully implement quality management.
Note that it is not a top-down approach where management sets unrealistic targets
that must be implemented on the project level. It is even more important that
continuous feedback is provided bottom-up so that decisions can be changed or
directions can be adjusted.
Fig. 1: Quality management within the organization
Quality is implemented along the product life-cycle. Fig. 2 shows some pivotal
quality-related activities mapped to the major life-cycle phases. Note that on the left
side strategic directions are set and a respective management system is
implemented. Towards the right side, quality related processes, such as test or
supplier audits are implemented. During evolution of the product with dedicated
services and customer feedback, the product is further optimized and the
management system is adapted where necessary.
It is important to understand that the management system is not specific to a

project, but drives a multitude of projects or even the entire organization. Scale
effects occur with having standardized processes that are systematically applied.
This not only allows moving people to different projects without long learning
curve but also assures proven quality at best possible efficiency. A key step along all
these phases is to recognize that all quality requirements can and should be
specified in quantitative terms. This does not mean “counting defects” as it would be
too late and reactive. It means quantifying quality attributes such as security,
portability, adaptability, maintainability, robustness, usability, reliability and
performance as an objective before the design of a product.
Course Module
4
Fig. 2: Quality management along the product life-cycle
A small example will illustrate this need. A software system might have strict
reliability constraints. Instead of simply stating that reliability should achieve less
than one failure per month in operation, which would be reactive, related quality
requirements should target underlying product and process needs to achieve such
reliability. During the strategy phase, the market or customer needs for reliability
need to be elicited. Is reliability important as an image or is it rather availability?
What is the perceived value of different failure rates? A next step is to determine
how these needs will be broken down to product features, components and
capabilities. Which architecture will deliver the desired reliability and what are
cost impacts? What component and supplier qualification criteria need to be
established and maintained throughout the product life-cycle? Then the underlying
quality processes need to be determined. This should not be done ad-hoc and for
each single project individually but by tailoring organizational processes, such as
product life-cycle, project reviews, or testing to the specific needs of the product.
What test coverage is necessary and how will it be achieved? Which test equipment
and infrastructure for interoperability of components needs to be applied? What
checklists should be used in preparing for reviews and releases? These processes
need to be carefully applied during development. Quality control will be applied by
each single engineer and quality assurance will be done systematically for selected
processes and work products. Finally the evolution phase of the product needs to
establish criteria for service request management and assuring the right quality
level of follow-on releases and potential defect corrections. A key question to
address across all these phases is how to balance quality needs with necessary effort
and availability of skilled people. Both relate to business, but that is at times
overlooked. We have seen companies that due to cost and time constraints would
Course Module
5
reduce requirements engineering or early reviews of specifications and later found

out that follow-on cost were higher than what was cut out. A key understanding to
achieving quality and therefore business performance has once been phrased by
Abraham Lincoln: “If someone gave me eight hours to chop down a tree, I would
spend six hours sharpening the axe.”
Process Maturity and Quality

The quality of a product or service is mostly determined by the processes and
people developing and delivering the product or service. Technology can be bought,
it can be created almost on the spot, and it can be introduced by having good
engineers. What matters to the quality of a product is how they are working and
how they introduce this new technology. Quality is not at a stand-still, it needs to be
continuously questioned and improved. With today’s low entry barriers to software
markets, one thing is sure: There is always a company or entrepreneur just
approaching your home turf and conquering your customers. To continuously
improve and thus stay ahead of competition, organizations need to change in a
deterministic and results-oriented way. They need to know and improve their
process maturity.
The concept of process maturity is not new. Many of the established quality models
in manufacturing use the same concept. This was summarized by Philip Crosby in
his bestselling book “Quality is Free” in 1979. He found from his broad experiences
as a senior manager in different industries that business success depends on quality.
With practical insight and many concrete case studies he could empirically link
process performance to quality. His credo was stated as: “Quality is measured by the
cost of quality which is the expense of nonconformance – the cost of doing things
wrong.”
First organizations must know where they are; they need to assess their processes.
The more detailed the results from such an assessment, the easier and more
straightforward it is to establish a solid improvement plan. That was the basic idea
with the “maturity path” concept proposed by Crosby in the 1970s. He distinguishes
five maturity stages, namely
 Stage 1: Uncertainty
 Stage 2: Awakening
 Stage 3: Enlightening
 Stage 4: Wisdom
 Stage 5: Certainty
Defects – Prediction, Detection, Correction and Prevention

To achieve the right quality level in developing a product it is necessary to understand
what it means not to have insufficient quality. Let us start with the concept of defects. A
Course Module
6
defect is defined as an imperfection or deficiency in a system or component where that

component does not meet its requirements or specifications which could yield a failure.
Causal relationship distinguishes the failure caused by a defect which itself is caused by
a human error during design of the product. Defects are not just information about
something wrong in a software system or about the progress in building up quality.
Defects are information about problems in the process that created this software. The
four questions to address are:
1. How many defects are there and have to be removed?

2. How can the critical and relevant defects be detected most efficiently?
3. How can the critical and relevant defects be removed most effectively and
efficiently?
4. How can the process be changed to avoid the defects from reoccurring?
These four questions relate to the four basic quality management techniques of
prediction, detection, correction and prevention. The first step is to identify how
many defects there are and which of those defects are critical to product performance.
The underlying techniques are statistical methods of defect estimation, reliability
prediction and criticality assessment. These defects have to be detected by quality
control activities, such as inspections, reviews, unit test, etc. Each of these techniques
has their strengths and weaknesses which explains why they ought to be combined to
be most efficient. It is of not much value to spend loads of people on test, when in-depth
requirements reviews would be much faster and cheaper. Once defects are detected and
identified, the third step is to remove them. This sounds easier than it actually is due to
the many ripple effects each correction has to a system. Regression tests and reviews of
corrections are absolutely necessary to assure that quality won’t degrade with changes.
A final step is to embark on preventing these defects from re-occurring. Often engineers
and their management state that this actually should be the first and most relevant step.
We agree, but experience tells that again and again, people stumble across defect
avoidance simply because their processes won’t support it. In order to effectively avoid
defects engineering processes must be defined, systematically applied and
quantitatively managed. This being in place, defect prevention is a very cost-effective
means to boost both customer satisfaction and business performance, as many high-
maturity organizations such as Motorola, Boeing or Wipro show.
Defect removal is not about assigning blame but about building better quality and
improving the processes to ensure quality. Reliability improvement always needs
measurements on effectiveness (i.e., percentage of removed defects for a given activity)
compared to efficiency (i.e., effort spent for detecting and removing a defect in the
respective activity). Such measurement asks for the number of residual defects at a
given point in time or within the development process.
But how is the number of defects in a piece of software or in a product estimated? We

will outline the approach we follow for up-front estimation of residual defects in any
software that may be merged from various sources with different degrees of stability.
We distinguish between upfront defect estimation which is static by nature as it looks
Course Module
7
only on the different components of the system and their inherent quality before the
start of validation activities, and reliability models which look more dynamically during
validation activities at residual defects and failure rates.
Only a few studies have been published that typically relate static defect estimation to
the number of already detected defects independently of the activity that resulted in
defects, or the famous error seeding which is well known but is rarely used due to the
belief of most software engineers that it is of no use to add errors to software when
there are still far too many defects in, and when it is known that defect detection costs
several person hours per defect.
Defects can be easily estimated based on the stability of the underlying software. All
software in a product can be separated into four parts according to its origin:
 Software that is new or changed. This is the standard case where software had
been designed especially for this project, either internally or from a supplier.
 Software reused but to be tested (i.e., reused from another project that was
never integrated and therefore still contains lots of defects; this includes ported
functionality). This holds for reused software with unclear quality status, such as
internal libraries.
 Software reused from another project that is in testing (almost) at the same
time. This software might be partially tested, and therefore the overlapping of
the two test phases of the parallel projects must be accounted for to estimate
remaining defects. This is a specific segment of software in product lines or any
other parallel usage of the same software without having hardened it so far for
field usage.
 Software completely reused from a stable product. This software is considered
stable and therefore it has a rather low number of defects. This holds especially
for commercial off the shelf software components and opens source software
which is used heavily.
The base of the calculation of new or changed software is the list of modules to be used
in the complete project (i.e., the description of the entire build with all its components).
A defect correction in one of these components typically results in a new version, while
a modification in functionality (in the context of the new project) results in a new
variant. Configuration management tools are used to distinguish the one from the other
while still maintaining a single source.
To statically estimate the number of residual defects in software at the time it is

delivered by the author (i.e., after the author has done all verification activities, she can
execute herself), we distinguish four different levels of stability of the software that are
treated independently
f = a × x + b × y + c × z + d × (w – x – y – z)
Course Module
8
with
 x: the number of new or changed KStmt designed and to be tested within this
project. This software was specifically designed for that respective project. All
other parts of the software are reused with varying stability.
 y: the number of KStmt that are reused but are unstable and not yet tested
(based on functionality that was designed in a previous project or release, but
was never externally delivered; this includes ported functionality from other
projects).
 z: the number of KStmt that are tested in parallel in another project. This
software is new or changed for the other project and is entirely reused in the
project under consideration.
 w: the number of KStmt in the total software – i.e., the size of this product in its
totality.
The factors a-d relate defects in software to size. They depend heavily on the
development environment, project size, maintainability degree and so on. Our
starting point for this initial estimation is actually driven by psychology. Any person
makes roughly one (non-editorial) defect in ten written lines of work. This applies
to code as well as a design document or e-mail, as was observed by the personal
software process (PSP) and many other sources [1,16,17]. The estimation of
remaining defects is language independent because defects are introduced per
thinking and editing activity of the programmer, i.e., visible by written statements.
This translates into 100 defects per KStmt. Half of these defects are found by careful
checking by the author which leaves some 50 defects per KStmt delivered at code
completion. Training, maturity and coding tools can further reduce the number
substantially. We found some 10-50 defects per KStmt depending on the maturity
level of the respective organization. This is based only on new or changed code, not
including any code that is reused or automatically generated.
Most of these original defects are detected by the author before the respective work
product is released. Depending on the underlying individual software process, 40–
80% of these defects are removed by the author immediately. We have
experienced in software that around 10–50 defects per KStmt remain. For the
following calculation we will assume that 30 defects/KStmt are remaining (which is
a common value [18]. Thus, the following factors can be used:
 defects per KStmt (depending on the engineering methods; should be based on

own data)
 b: 30 × 60% defects per KStmt, if defect detection before the start of testing is
60%
Course Module
9
 c: 30 × 60% × (overlapping degree) × 25% defects per KStmt (depending on

overlapping degree of resources)
 d: 30 × 0.1–1% defects per KStmt depending on the number of defects remaining
in a product at the time when it is reused
 The percentages are, of course, related to the specific defect detection
distribution in one’s own historical database (Fig. 3). A careful investigation of
stability of reused software is necessary to better substantiate the assumed
percentages.
5
0
%
6
5
%
Fig. 3: Typical benchmark effects of detecting defects earlier in the life-cycle
Since defects can never be entirely avoided, different quality control techniques are
used in combination for detecting defects during the product life-cycle. They are listed
in sequence when they are applied throughout the development phase, starting with
requirements and ending with system test:
 Requirements (specification) reviews

 Design (document) reviews
 Compile level checks with tools
 Static code analysis with automatic tools
 Manual code reviews and inspections with checklists based on typical defect
situations or critical areas in the software
 Enhanced reviews and testing of critical areas (in terms of complexity, former
Course Module
10
failures, expected defect density, individual change history, customer’s risk and
occurrence probability)
 Unit testing
 Focused testing by tracking the effort spent for analyses, reviews, and
inspections and separating according to requirements to find out areas not
sufficiently covered
 Systematic testing by using test coverage measurements (e.g., C0 and C1
coverage) and improvement
 Operational testing by dynamic execution already during integration testing
 Automatic regression testing of any redelivered code
 System testing by applying operational profiles and usage specifications.
We will further focus on several selected approaches that are applied for improved
defect detection before starting with integration and system test because those
techniques are most cost-effective.
Note that the starting point for effectively reducing defects and improving reliability is
to track all defects that are detected. Defects must be recorded for each defect
detection activity. Counting defects and deriving the reliability (that is failures over
time) is the most widely applied and accepted method used to determine software
quality. Counting defects during the complete project helps to estimate the duration of
distinct activities (e.g., unit testing or subsystem testing) and improves the underlying
processes. Failures reported during system testing or field application must be traced
back to their primary causes and specific defects in the design (e.g., design decisions or
lack of design reviews).
Quality improvement activities must be driven by a careful look into what they mean
for the bottom line of the overall product cost. It means to continuously investigate
what this best level of quality really means, both for the customers and for the
engineering teams who want to deliver it.
One does not build a sustainable customer relationship by delivering bad quality and
ruining his reputation just to achieve a specific delivery date. And it is useless to spend
an extra amount on improving quality to a level nobody wants to pay for. The optimum
seemingly is in between. It means to achieve the right level of quality and to deliver in
time. Most important yet is to know from the beginning of the project what is actually
relevant for the customer or market and set up the project accordingly. Objectives will
be met if they are driven from the beginning.
We look primarily at factors such as cost of non-quality to follow through this business
reasoning of quality improvements. For this purpose we measure all cost related to
error detection and removal (i.e., cost of non-quality) and normalize by the size of the
product (i.e., normalize defect costs). We take a conservative approach in only
considering those effects that appear inside our engineering activities, i.e., not
considering opportunistic effects or any penalties for delivering insufficient quality.
The most cost-effective techniques for defect detection are requirements reviews. For
Course Module
11
code reviews, inspections and unit test are most cost-effective techniques aside static
code analysis. Detecting defects in architecture and design documents has
considerable benefit from a cost perspective, because these defects are expensive to
correct at later stages. Assuming good quality specifications, major yields in terms of
reliability, however, can be attributed to better code, for the simple reason that there
are many more defects residing in code that were inserted during the coding activity.
We therefore provide more depth on techniques that help to improve the quality of
code, namely code reviews (i.e., code reviews and formal code inspections) and unit
test (which might include static and dynamic code analysis).
There are six possible paths of combining manual defect detection techniques in the
delivery of a piece of software from code complete until the start of integration test
(Fig. 4). The paths indicate the permutations of doing code reviews alone, performing
code inspections and applying unit test. Each path indicated by the arrows shows
which activities are performed on a piece of code. An arrow crossing a box means that
the activity is not applied. Defect detection effectiveness of a code inspection is much
higher than that of a code review. Unit test finds different types of defects than
reviews. However cost also varies depending on which technique is used, which
explains why these different permutations are used. In our experience code reviews is
the cheapest detection technique (with ca. 1-2 PH/defect), while manual unit test is
the most expensive (with ca. 1-5 PH/defect, depending on automation degree). Code
inspections lie somewhere in between. Although the best approach from a mere defect
detection perspective is to apply inspections and unit test, cost considerations and the
objective to reduce elapsed time and thus improve throughput suggest carefully
evaluating which path to follow in order to most efficiently and effectively detect and
remove defects
Entire set of modules
Code
integration test
Reviews
test
Unit
Formal
Code
Inspection
Fig. 4: Six possible paths for modules between end of coding and start of
integration test
Unit tests, however, combined with C0 coverage targets, have the highest effectiveness
for regression testing of existing functionality. Inspections, on the other hand, help in
detecting distinct defect classes that can only be found under real load (or even stress)
in the field.
Course Module
12
Defects are not distributed homogeneously through new or changed code. An analysis
of many projects revealed the applicability of the Pareto rule: 20-30% of the modules
are responsible for 70- 80% of the defects of the whole project. These critical
components need to be identified as early as possible, i.e., in the case of legacy systems
at start of detailed design, and for new software during coding. By concentrating on
these components the effectiveness of code inspections and unit testing is increased
and fewer defects have to be found during test phases. By concentrating on defect-
prone modules both effectiveness and efficiency are improved. Our main approach to
identify defect- prone software-modules is a criticality prediction taking into account
several criteria. One criterion is the analysis of module complexity based on
complexity measurements. Other criteria concern the number of new or changed code
in a module, and the number of field defects a module had in the preceding project.
Code inspections are first applied to heavily changed modules, in order to optimize
payback of the additional effort that has to be spent compared to the lower effort for
code reading. Formal code reviews are recommended even for very small changes
with a checking time shorter than two hours in order to profit from a good efficiency of
code reading. The effort for know-how transfer to another designer can be saved.
It is of great benefit for improved quality management to be able to predict early on in

the development process those components of a software system that are likely to
have a high defect rate or those requiring additional development effort. Criticality
prediction is based on selecting a distinct small share of modules that incorporate sets
of properties that would typically cause defects to be introduced during design more
often than in modules that do not possess such attributes. Criticality prediction is thus
a technique for risk analysis during the design process.
 Criticality prediction addresses typical questions often asked in software

engineering projects:
 How can I early identify the relatively small number of critical components that
make significant contribution to defects identified later in the life-cycle?
 Which modules should be redesigned because their maintainability is bad and
their overall criticality to the project’s success is high?
 Are there structural properties that can be measured early in the code to
predict quality attributes?
 If so, what is the benefit of introducing a measurement program that
investigates structural properties of software?
 Can I use the often heuristic design and test know-how on trouble identification
and risk assessment to build up a knowledge base to identify critical
components early in the development process?
Criticality prediction is a multifaceted approach taking into account several criteria.

Complexity is a key influence on quality and productivity. Having uncontrolled
Course Module
13
accidental complexity in the product will definitely decrease productivity (e.g., gold
plating, additional rework, more test effort) and quality (more defects). A key to
controlling accidental complexity from creeping into the project is the measurement
and analysis of complexity throughout in the life-cycle. Volume, structure, order or the
connections of different objects contribute to complexity. However, do they all account
for it equally? The clear answer is no, because different people with different skills
assign complexity subjectively, according to their experience in the area. Certainly
criticality must be predicted early in the life-cycle to effectively serve as a managerial
instrument for quality improvement, quality control effort estimation and resource
planning as soon as possible in a project. Tracing comparable complexity metrics for
different products throughout the life-cycle is advisable to find out when essential
complexity is over- ruled by accidental complexity. Care must be used that the
complexity metrics are comparable, that is they should measure the same factors of
complexity.
Having identified such overly critical modules, risk management must be applied. The
most critical and most complex, for instance, the top 5% of the analyzed modules are
candidates for a redesign. For cost reasons mitigation is not only achieved with
redesign. The top 20% should have a code inspection instead of the usual code
reading, and the top 80% should be at least entirely (C0 coverage of 100%) unit tested.
By concentrating on these components the effectiveness of code inspections and unit
test is increased and fewer defects have to be found during test phases. To achieve
feedback for improving predictions the approach is integrated into the development
process end-to-end (requirements, design, code, system test, deployment).
It must be emphasized that using criticality prediction techniques does not mean
attempting to detect all defects. Instead, they belong to the set of managerial
instruments that try to optimize resource allocation by focusing them on areas with
many defects that would affect the utility of the delivered product. The trade-off of
applying complexity-based predictive quality models is estimated based on
 limited resources are assigned to high-risk jobs or components

 impact analysis and risk assessment of changes is feasible based on affected or
changed complexity
 gray-box testing strategies are applied to identified high-risk components
 ewer customers reported failures
Our experiences show that, in accordance with other literature corrections of defects in
early phases is more efficient, because the designer is still familiar with the problem
and the correction delay during testing is reduced
The effect and business case for applying complexity-based criticality prediction to a
Course Module
14
new project can be summarized based on results from our own experience database
(taking a very conservative ratio of only 40% defects in critical components):
 20% of all modules in the project were predicted as most critical (after coding);
 These modules contained over 40% of all defects (up to release time). Knowing
from these and many other projects that
 60% of all defects can theoretically be detected until the end of unit test and
defect correction during unit test and code reading costs less than 10%
compared to defect correction during system test
It can be calculated that 24% of all defects can be detected early by investigating 20% of
all modules more intensively with 10% of effort compared to late defect correction
during test, therefore yielding a 20% total cost reduction for defect correction.
Additional costs for providing the statistical analysis are in the range of two person
days per project. Necessary tools are off the shelf and account for even less per project.

Books and Journals
Publication.
WILEY INDIA.
Course Module
Week 006
Software Quality Management

• Understand the issue of Software Quality and the activities present in a
typical Quality Management process.
• Understand the advantages of difficulties presented by the use of
Quality standards in Software Engineering
• Understand the concepts of Software Quality Management
Software Quality Management

• Concerned with ensuring the required level of quality is achieved in a
software product
• Involves the definition of appropriate quality standards and the
definition of procedures to ensure that these standards are followed
• Works best when a ‘quality culture’ is created where quality if seen as
everyone’s responsibility
Quality Definition
• Quality means that a product satisfies the demands of its
specifications
• It also means achieving a high level of customer satisfaction with the
product
• In software systems this is difficult
• customer quality requirements (e.g. efficiency or reliability) often
conflict with developer quality requirements (e.g. maintainability or
reusability)
• software specifications are often incomplete, inconsistent, or
ambiguous
Quality Management Activities

Quality assurance
• establishing organizational quality standards and procedures
Quality planning
• selecting and modifying applicable quality standards and
procedures for a particular project
Quality control
• ensuring quality standards and procedures are followed by
development team
Note: Quality management should be separated from project

management to ensure independence.
Quality Standards
• Key to effective quality management
• Product standards define the characteristics exhibited by all
components (e.g. programming style issues)
• Process standards describe how a software process is to be
implemented
• Should encapsulate best practices - this helps avoid repeating past
mistakes
• Provide continuity by giving new team members a means to
understand the organizational priorities
Process and Product Standards

Product Standards Process Standards
• Design review form • Design review guidelines
• Document naming • Document submission
standards procedures
• Function prototype format • Version release process
• Programming style • Project plan approval
standards procedure
• Project plan format • Change control process
• Change request form • Test data recording
procedures
Problems with Standards

• Sometimes viewed by software engineers as neither up-to-date or
relevant to the current project
• Can involve lots of bureaucratic form completion and submission
• Often not supported directly by software tools and this can mean lots
of manual work to maintain standards
Quality Standards Development

• Should involve practitioners in their development
• Engineers must understand the rationale behind each standard
• Standards must be reviewed and revised regularly to avoid
obsolescence and credibility problems with practitioners
• Detailed standards need tool support to eliminate the “too much
clerical work” excuse for not following the standards
Documentation Standards
• Documentation process standards
 describe how documents are to be developed, validated, and
maintained
• Document standards
 concerned with document content, structure, and appearance
• Document interchange standards
 specify how documents are to be stored and shared between
different documentation systems
Documentation process
Incorporate
Create Review Re-draft
review
initial draft draft document
comments
Stage 1:
Creation Approved document
Proofread Produce Check

text final draft final dr aft
Stage 2:
Polishing Approved document
Layout Review Produce Print

text layout print masters copies
Stage 3:
Pr oduction
Document Standards
• Document identification standards
 how documents are labeled
• Document structure standards
 organization of project documents
• Document presentation standards
 fonts, styles, logos, etc.
• Document update standards
 change control and version definition
Document Interchange Standards

• Allow documents produced on different computers, using different
tools to be exchanged among team members
• The lifetime of many word processing systems is often less than the
lifetime of the software being documented, document archival can be
tricky
• Document interchange standards like XML are beginning to emerge as
partial solutions to these problems
Process-Based Quality
• Product quality is influenced by the quality of its production process
• This relationship is easy the see in the manufacture of goods, it is more
complex for software production because
 the application of individual skills and experience is particularly
important in software development
 external factors (e.g. application novelty or need to accelerate
schedule) are more likely to impair quality
Process-Based Quality Activities
De velop Assess product

Define process
product quality
No Yes
Improve Quality Standar dize
process OK process
Process Quality Overview

• Determine the process standards to be used (e.g. review procedures,
configuration management, etc.)
• Monitor the development process to ensure standards are being
followed
• Report process findings to project manger and customerProcess-based
quality
Quality Plan
• Identifies the most significant quality attributes appropriate for the
product
• Defines the assessment process in detail for each quality attribute
• Indicates which organization standards should be applied and defines
new standards as necessary
Quality Plan Components

• Product introduction
• Product plans
• Process descriptions
• Quality goals
• Risks and risk management
Software Quality Attributes

• Safety • Modularity
• Security • Complexity
• Reliability • Portability
• Resilience • Usability
• Robustness • Accessibility
• Understandability • Reusability
• Testability • Efficiency
• Adaptability • Learnability
Quality Control
• Examines the software development process to ensure that all relevant
procedures and standards are being followed
• Two basic approaches
 quality reviews
 software measurement and assessment
Reviews
• Reviews are the principle means of validating both process and
product quality
• Basic procedure is to have a group of people examine a process
artifact to find potential problems
• Common software review types include
• defect inspection and removal (product)
• progress reviews (product and process)
• quality reviews (product and standards)
Quality Reviews
• Group of knowledgeable people examines a software component and
its documentation
• Code, design models, specifications, test plans, standards, etc. can be
subjected to review
• Once an artifact has been reviewed and ‘signed off’ by the reviewers,
management has given its approval to proceed to the next stage of
development
Quality Review Process

• Select a review team
• Arrange a time and place for the review
• Distribute documents to review
• Conduct the review
• Complete the review forms
• Decide whether to approve artifacts or have them reworked and review
them again
Review Purposes
• Quality function
• part of the general quality management process
• Project management function
• provide information to project managers
• Training and communication function
• product knowledge is shared among development team members
Quality Review Results

• Purpose is the discovery of system defects and inconsistencies
• Review comments need to be classified as
• no action (no changes to artifact are required)
• refer for repair (author needs to correct faults)
• reconsider overall design (problem identified impacts other design
components)
• Requirement and specification problems may require involvement of
client to resolve
Quality Review Results

• Purpose is the discovery of system defects and inconsistencies
• Review comments need to be classified as
• no action (no changes to artifact are required)
• refer for repair (author needs to correct faults)
• reconsider overall design (problem identified impacts other design
components)
• Requirement and specification problems may require involvement of
client to resolve
1
Week 7: Software Development Method
Module 006: Software Development Method

1. Understand the concepts of software processes and software process
models;
2. Have been introduced to three generic software process models and
when they might be used;
3. Know about the fundamental process activities of software requirements
engineering, software development, testing, and evolution;
4. Understand why processes should be organized to cope with changes in
the software requirements and design;
5. Understand how the Rational Unified Process integrates good software
engineering practice to create adaptable software processes.
Introduction
A software process is a set of related activities that leads to the production of a soft-
ware product. These activities may involve the development of software from
scratch in a standard programming language like Java or C. However, business
applications are not necessarily developed in this way. New business software is
now often developed by extending and modifying existing systems or by configuring
and integrating off-the-shelf software or system components.
There are many different software processes but all must include four activities that
are fundamental to software engineering:
 Software specification. The functionality of the software and constraints on
its operation must be defined.
 Software design and implementation. The software to meet the
specification must be produced.
 Software validation. The software must be validated to ensure that it does
what the customer wants.
 Software evolution. The software must evolve to meet changing customer
needs.
In some form, these activities are part of all software processes. In practice, of
course, they are complex activities in themselves and include sub-activities such as
requirements validation, architectural design, unit testing, etc. There are also
supporting process activities such as documentation and software configuration
management.
Course Module
2
When we describe and discuss processes, we usually talk about the activities in
these processes such as specifying a data model, designing a user interface, etc., and
the ordering of these activities. However, as well as activities, process descriptions
may also include:
1. Products, which are the outcomes of a process activity. For example, the out-
come of the activity of architectural design may be a model of the software
architecture.
2. Roles, which reflect the responsibilities of the people involved in the process.
Examples of roles are project manager, configuration manager, programmer,
etc.
3. Pre- and post-conditions, which are statements that are true before and after
a process activity has been enacted or a product produced. For example,
before architectural design begins, a pre-condition may be that all
requirements have been approved by the customer; after this activity is
finished, a post-condition might be that the UML models describing the
architecture have been reviewed.
Software processes are complex and, like all intellectual and creative processes, rely
on people making decisions and judgments. There is no ideal process and most
organizations have developed their own software development processes.
Processes have evolved to take advantage of the capabilities of the people in an
organization and the specific characteristics of the systems that are being
developed. For some systems, such as critical systems, a very structured
development process is required. For business systems, with rapidly changing
requirements, a less formal, flexible process is likely to be more effective.
Sometimes, software processes are categorized as either plan-driven or agile

processes. Plan-driven processes are processes where all of the process activities
are planned in advance and progress is measured against this plan. In agile
processes, which I discuss in Chapter 3, planning is incremental and it is easier to
change the process to reflect changing customer requirements. As Boehm and
Turner (2003) discuss, each approach is suitable for different types of software.
Generally, you need to find a balance between plan-driven and agile processes.
Although there is no ‘ideal’ software process, there is scope for improving the
software process in many organizations. Processes may include outdated
techniques or may not take advantage of the best practice in industrial software
engineering. Indeed, many organizations still do not take advantage of software
engineering methods in their software development.
Course Module
3
Software process models

Software process model is a simplified representation of a software process. Each
process model represents a process from a particular perspective, and thus provides
only partial information about that process. For example, a process activity model
shows the activities and their sequence but may not show the roles of the people
involved in these activities. In this section, I introduce a number of very general
process models (sometimes called ‘process paradigms’) and present these from an
architectural perspective. That is, we see the framework of the process but not the
details of specific activities.
These generic models are not definitive descriptions of software processes. Rather,
they are abstractions of the process that can be used to explain different approaches
to software development. You can think of them as process frameworks that may be
extended and adapted to create more specific software engineering processes.
The process models that I cover here are:

1. The waterfall model. This takes the fundamental process activities of
specification, development, validation, and evolution and represents them as
separate process phases such as requirements specification, software design,
implementation, testing, and so on.
2. Incremental development. This approach interleaves the activities of
specification, development, and validation. The system is developed as a
series of versions (increments), with each version adding functionality to the
previous version.
3. Reuse-oriented software engineering. This approach is based on the
existence of a significant number of reusable components. The system
development process focuses on integrating these components into a system
rather than developing them from scratch
These models are not mutually exclusive and are often used together, especially for
large systems development. For large systems, it makes sense to combine some of
the best features of the waterfall and the incremental development models. You
need to have information about the essential system requirements to design a soft-
ware architecture to support these requirements. You cannot develop this
incrementally. Sub-systems within a larger system may be developed using different
approaches. Parts of the system that are well understood can be specified and
developed using a waterfall-based process. Parts of the system which are difficult to
specify in advance, such as the user interface, should always be developed using an
incremental approach
Course Module
4
The waterfall model

The first published model of the software development process was derived from
more general system engineering processes (Royce, 1970). This model is illustrated
in Figure 6.1. Because of the cascade from one phase to another, this model is known
as the ‘waterfall model’ or software life cycle. The waterfall model is an example of a
plan-driven process—in principle, you must plan and schedule all of the process
activities before starting work on them.
Figure 6.1 The waterfall model
The principal stages of the waterfall model directly reflect the fundamental
development activities:
1. Requirements analysis and definition. The system’s services, constraints,
and goals are established by consultation with system users. They are then
defined in detail and serve as a system specification.
2. System and software design. The systems design process allocates the
requirements to either hardware or software systems by establishing an
overall system architecture. Software design involves identifying and
describing the fundamental software system abstractions and their
relationships.
3. Implementation and unit testing. During this stage, the software design is
realized as a set of programs or program units. Unit testing involves verifying
that each unit meets its specification.
4. Integration and system testing. The individual program units or programs
are integrated and tested as a complete system to ensure that the software
Course Module
5
requirements have been met. After testing, the software system is delivered
to the customer.
5. Operation and maintenance. Normally (although not necessarily), this is the
longest life cycle phase. The system is installed and put into practical use.
Maintenance involves correcting errors which were not discovered in earlier
stages of the life cycle, improving the implementation of system units and
enhancing the system’s services as new requirements are discovered.
In principle, the result of each phase is one or more documents that are approved
(‘signed off’). The following phase should not start until the previous phase has
finished. In practice, these stages overlap and feed information to each other. During
design, problems with requirements are identified. During coding, design problems
are found and so on. The software process is not a simple linear model but involves
feedback from one phase to another. Documents produced in each phase may then
have to be modified to reflect the changes made.
Because of the costs of producing and approving documents, iterations can be costly
and involve significant rework. Therefore, after a small number of iterations, it is
normal to freeze parts of the development, such as the specification, and to continue
with the later development stages. Problems are left for later resolution, ignored, or
programmed around. This premature freezing of requirements may mean that the
system won’t do what the user wants. It may also lead to badly structured systems
as design problems are circumvented by implementation tricks.
During the final life cycle phase (operation and maintenance) the software is put
into use. Errors and omissions in the original software requirements are discovered.
Program and design errors emerge and the need for new functionality is identified.
The system must therefore evolve to remain useful. Making these changes (software
maintenance) may involve repeating previous process stages.
Incremental development
Incremental development is based on the idea of developing an initial
implementation, exposing this to user comment and evolving it through several
versions until an adequate system has been developed (Figure 6.2). Specification,
development, and validation activities are interleaved rather than separate, with
rapid feedback across activities.
Course Module
6
Figure 6.2 Incremental development
Incremental software development, which is a fundamental part of agile

approaches, is better than a waterfall approach for most business, e-commerce, and
personal systems. Incremental development reflects the way that we solve
problems. We rarely work out a complete problem solution in advance but move
toward a solution in a series of steps, backtracking when we realize that we have
made a mistake. By developing the software incrementally, it is cheaper and easier
to make changes in the software as it is being developed.
Each increment or version of the system incorporates some of the functionality that
is needed by the customer. Generally, the early increments of the system include the
most important or most urgently required functionality. This means that the
customer can evaluate the system at a relatively early stage in the development to
see if it delivers what is required. If not, then only the current increment has to be
changed and, possibly, new functionality defined for later increments.
Incremental development has three important benefits, compared to the waterfall

model:
1. The cost of accommodating changing customer requirements is reduced. The

amount of analysis and documentation that has to be redone is much less
than is required with the waterfall model.
2. It is easier to get customer feedback on the development work that has been
done. Customers can comment on demonstrations of the software and see
Course Module
7
how much has been implemented. Customers find it difficult to judge

progress from software design documents.
3. More rapid delivery and deployment of useful software to the customer is
possible, even if all of the functionality has not been included. Customers are
able to use and gain value from the software earlier than is possible with a
waterfall process.
Incremental development in some form is now the most common approach for the
development of application systems. This approach can be either plan-driven, agile,
or, more usually, a mixture of these approaches. In a plan-driven approach, the
system increments are identified in advance; if an agile approach is adopted, the
early increments are identified but the development of later increments depends on
progress and customer priorities.
From a management perspective, the incremental approach has two problems:

1. The process is not visible. Managers need regular deliverables to measure
progress. If systems are developed quickly, it is not cost-effective to produce
documents that reflect every version of the system.
2. System structure tends to degrade as new increments are added. Unless time
and money is spent on refactoring to improve the software, regular change
tends to corrupt its structure. Incorporating further software changes
becomes increasingly difficult and costly.
The problems of incremental development become particularly acute for large,

complex, long-lifetime systems, where different teams develop different parts of the
system. Large systems need a stable framework or architecture and the
responsibilities of the different teams working on parts of the system need to be
clearly defined with respect to that architecture. This has to be planned in advance
rather than developed incrementally.
You can develop a system incrementally and expose it to customers for comment,
without actually delivering it and deploying it in the customer’s environment.
Incremental delivery and deployment means that the software is used in real,
operational processes. This is not always possible as experimenting with new
software can disrupt normal business processes.
Course Module
8
Reuse-oriented software engineering

In the majority of software projects, there is some software reuse. This often
happens informally when people working on the project know of designs or
codes that are similar to what is required. They look for these, modify them as
needed, and incorporate them into their system.
This informal reuse takes place irrespective of the development process that is
used. However, in the 21st century, software development processes that focus
on the reuse of existing software have become widely used. Reuse-oriented
approaches rely on a large base of reusable software components and an
integrating framework for the composition of these components. Sometimes,
these components are systems in their own right (COTS or commercial off-the-
shelf systems) that may provide specific functionality such as word processing or
a spreadsheet.
Figure 6.3 Reuse-oriented software engineering
A general process model for reuse-based development is shown in Figure 6.3.

Although the initial requirements specification stage and the validation stage are
comparable with other software processes, the intermediate stages in a reuse-
oriented process are different. These stages are:
1. Component analysis. Given the requirements specification, a search is

made for components to implement that specification. Usually, there is no
exact match and the components that may be used only provide some of
the functionality required.
2. Requirements modification. During this stage, the requirements are
analyzed using information about the components that have been
discovered. They are then modified to reflect the available components.
Where modifications are impossible, the component analysis activity may
be re-entered to search for alternative solutions.
3. System design with reuse. During this phase, the framework of the
system is designed or an existing framework is reused. The designers take
Course Module
9
into account the components that are reused and organize the framework
to cater for this. Some new software may have to be designed if reusable
components are not available.
4. Development and integration. Software that cannot be externally
procured is developed, and the components and COTS systems are
integrated to create the new system. System integration, in this model,
may be part of the development process rather than a separate activity.
There are three types of software component that may be used in a reuse-
oriented process:
1. Web services that are developed according to service standards and which
are available for remote invocation.
2. Collections of objects that are developed as a package to be integrated
with a component framework such as .NET or J2EE.
3. Stand-alone software systems that are configured for use in a particular
environment.
Reuse-oriented software engineering has the obvious advantage of reducing the

amount of software to be developed and so reducing cost and risks. It usually also
leads to faster delivery of the software. However, requirements compromises are
inevitable and this may lead to a system that does not meet the real needs of
users. Furthermore, some control over the system evolution is lost as new
versions of the reusable components are not under the control of the
organization using them.
Course Module
10

Books and Journals
Publication.
WILEY INDIA.
Course Module
Week 007
Software Development Method

• Understand the concepts of software processes and software process
models;
• Have been introduced to three generic software process models and
when they might be used;
• Know about the fundamental process activities of software
requirements engineering, software development, testing, and
evolution;
• Understand why processes should be organized to cope with changes
in the software requirements and design;
• Understand how the Rational Unified Process integrates good software
engineering practice to create adaptable software processes.
What are methodologies?

• Development methodologies add structure to the development process
• Ensure that no important step is missed
- “Oops, we forgot to test”
• Ensure that the customer’s input is gathered and applied
• Coordinate the interaction between developers and between
developers and the customer
Methodology Stages
• Requirements
- Determine the functional needs of the application
• Design
- Translate the requirements into a system specification
• Implementation
- Implement the design into a working application
Methodology Stages
• Testing
-Verify the correctness of the application
-Ensure that the application fulfills the requirements
• Maintenance
-Bug fixing and application updates
• Risk Analysis
-Is the application proceeding acceptable?
-Should the plug be pulled?
• Customer Verification
-Refinement of requirements, design, and implementation
Waterfall
* Note that the textbook uses different labels

Waterfall
• Sequence workflow from project inception to project deployment
• The classic model of development
• The project starts with customer communication to gather
requirements and ends with delivery of the application0
Waterfall Issues
• Real projects often break out of the linear progress of this model
• i.e. the design changes due to implementation problems

• If multiple developers are not tightly coupled, confusion can result
• Changes in previous phases can invalid considerable previous work
Waterfall Issues
• What happens when the customer does not specify the requirements
completely?
• Can the customer know all the requirements a priori?

• The requirements may change as the customer needs change
• The requirements may change once the customer sees the end result
Waterfall Issues
• Customer patience and forethought is required
• The customer does not see a prototype until the application is done
• What happens when a small misunderstanding in requirements
results in a major difference in the built application?
Towards Incremental Models
What happens when the customer kills the project at

delivery?
How much work is lost?
What can be done to mitigate the loss?

Towards Incremental Models
By keeping the customer in the loop, a project is less likely to be killed or overhauled
before delivery
The Incremental Model

• The incremental model is iteratively applying the waterfall model
• Each increment is a partial product, not a prototype
• It contains more functionality than the previous increment, but builds
on the previous increment
• i.e. for a word processor, increment 1 is the core infrastructure,
increment 2 is file management, increment 3 is basic editing, etc
• Increments progresses in parallel, with the product delivery of one
increment feeding into the design phase of the next


• This model provides the customer with early feedback, allowing
alterations of project to occur with limited impact
• Each increment is a functionally more complete version of the product
• Still requires extensive design and planning to order what features go
first
Assembly or RAD Model

• If a system can be decomposed into modular parts, those parts can be
independently developed
• By allowing simultaneous development, the product can be built faster
• Potentially, the built components can be reused in future projects
RAD Model
RAD Model
• Design must be more rigorous
• Coordinate the different sub-components
• If modularization is not possible, the application will fail
• More manpower
• More testing
• Performance tuning is more difficult
Towards Evolutionary Models

• Incremental models build up an application by a function at a time
• Evolutionary models build up an application through iterative complete
cycles. Each cycle is a rough-cut of the end application. These rough-cuts
are prototypes.
• Evolutionary systems are grown
• How many evolutions?
• What is “done”?
• Adding complexity
The Spiral Model

• The spiral model builds up successive prototypes
• Each iteration ends with a milestone prototype
• The prototype is used to determine what gaps remain
• The prototype is also used for risk analysis
The Spiral Model

• Each iteration has five stages
• Requirements
• Design
• Implementation
• Deployment
• Risk Analysis
• At the end of each milestone, a prototype is created
• At an arbitrary point, when the developers and customers agree, a
prototype is “blessed” as the shipping version
The Spiral Model

• What happens when the developer and customer bless an unready
prototype as the shipping version?
• Requirements may not be as complete
• The customer has opportunities to add detail “later”
• If no major changes are made, the process results in a longer
development time than the classic model
The Spiral Model

Extreme Programming
• Adding process to the spiral model
• Start with the customer and gather requirements
• Developers take each discrete requirement and estimate its time to
completion
Extreme Programming
• The developers decide how long it will take
• The customer gets to explicitly prioritize the requirements
• XP is “agile”, it will react well to change
• The process requires buy-in from the customer
• If the customer is not engaged, the process will not work
1
Week 8-9: Software Implementation and Documentation
Module 007: Software Implementation and

Documentation

1. Implement the Structured Programming in Software Coding and
Implementation
2. Understand the different Programming style and coding guidelines
3. Know the key issues that have to be considered when implementing
software, including software reuse and open-source development.
Software Implementation
In this chapter, we will study about programming methods, documentation and
challenges in software implementation.
In the process of coding, the lines of code keep multiplying, thus, size of the software
increases. Gradually, it becomes next to impossible to remember the flow of
program. If one forgets how software and its underlying programs, files, procedures
are constructed, it then becomes very difficult to share, debug, and modify the
program. The solution to this is structured programming. It encourages the
developer to use subroutines and loops instead of using simple jumps in the code,
thereby bringing clarity in the code and improving its efficiency Structured
programming also helps programmer to reduce coding time and organize code
properly.
Structured programming states how the program shall be coded. It uses three main
concepts:
1. Top-down analysis - A software is always made to perform some rational
work. This rational work is known as problem in the software parlance. Thus
it is very important that we understand how to solve the problem. Under top-
down analysis, the problem is broken down into small pieces where each one
has some significance. Each problem is individually solved and steps are
clearly stated about how to solve the problem.
2. Modular Programming - While programming, the code is broken down into

smaller group of instructions. These groups are known as modules,
subprograms, or subroutines. Modular programming based on the
understanding of top-down analysis. It discourages jumps using ‘goto’
Course Module
2
statements in the program, which often makes the program flow non-
traceable. Jumps are prohibited and modular format is encouraged in
structured programming.
3. Structured Coding - In reference with top-down analysis, structured coding

sub-divides the modules into further smaller units of code in the
Functional Programming
Functional programming is style of programming language, which uses the concepts
of mathematical functions. A function in mathematics should always produce the
same result on receiving the same argument. In procedural languages, the flow of
the program runs through procedures, i.e. the control of program is transferred to
the called procedure. While control flow is transferring from one procedure to
another, the program changes its state.
In procedural programming, it is possible for a procedure to produce different

results when it is called with the same argument, as the program itself can be in
different state while calling it. This is a property as well as a drawback of procedural
programming, in which the sequence or timing of the procedure execution becomes
important.
Functional programming provides means of computation as mathematical functions,

which produces results irrespective of program state. This makes it possible to
predict the behavior of the program.
Functional programming uses the following concepts:

First class and High-order functions - These functions have capability to accept
another function as argument or they return other functions as results.
 Pure functions - These functions do not include destructive updates, that is,
they do not affect any I/O or memory and if they are not in use, they can
easily be removed without hampering the rest of the program.
 Recursion - Recursion is a programming technique where a function calls
itself and repeats the program code in it unless some pre-defined condition
matches. Recursion is the way of creating loops in functional programming.
 Strict evaluation - It is a method of evaluating the expression passed to a
function as an argument. Functional programming has two types of
evaluation methods, strict (eager) or non-strict (lazy). Strict evaluation
always evaluates the expression before invoking the function. Non-strict
evaluation does not evaluate the expression unless it is needed.
Course Module
3
 λ-calculus - Most functional programming languages use λ-calculus as their

type systems. λ-expressions are executed by evaluating them as they occur.
Common Lisp, Scala, Haskell, Erlang, and F# are some examples of functional
programming languages.
Programming style
Programming style is set of coding rules followed by all the programmers to write
the code. When multiple programmers work on the same software project, they
frequently need to work with the program code written by some other developer.
This becomes tedious or at times impossible, if all developers do not follow some
standard programming style to code the program.
An appropriate programming style includes using function and variable names

relevant to the intended task, using well-placed indentation, commenting code for
the convenience of reader and overall presentation of code. This makes the program
code readable and understandable by all, which in turn makes debugging and error
solving easier. Also, proper coding style helps ease the documentation and updation.
Coding Guidelines
Practice of coding style varies with organizations, operating systems and language
of coding itself.
The following coding elements may be defined under coding guidelines of an

organization:
 Naming conventions - This section defines how to name functions,
variables, constants and global variables.
 Indenting - This is the space left at the beginning of line, usually 2-8
whitespace or single tab.
 Whitespace - It is generally omitted at the end of line.
 Operators - Defines the rules of writing mathematical, assignment and
logical operators. For example, assignment operator ‘=’ should have space
before and after it, as in “x = 2”.
 Control Structures - The rules of writing if-then-else, case-switch, while-
until and for control flow statements solely and in nested fashion.
 Line length and wrapping - Defines how many characters should be there
in one line, mostly a line is 80 characters long. Wrapping defines how a line
should be wrapped, if is too long.
 Functions - This defines how functions should be declared and invoked, with
and without parameters.
Course Module
4
 Variables - This mentions how variables of different data types are declared
and defined.
 Comments - This is one of the important coding components, as the
comments included in the code describe what the code actually does and all
other associated descriptions. This section also helps creating help
documentations for other developers.
Software Implementation Challenges

There are some challenges faced by the development team while implementing the
software. Some of them are mentioned below:
 Code-reuse - Programming interfaces of present-day languages are very

sophisticated and are equipped huge library functions. Still, to bring the cost
down of end product, the organization management prefers to re-use the
code, which was created earlier for some other software. There are huge
issues faced by programmers for compatibility checks and deciding how
much code to re-use.
 Version Management - Every time a new software is issued to the customer,
developers have to maintain version and configuration related
documentation. This documentation needs to be highly accurate and
available on time.
 Target-Host - The software program, which is being developed in the
organization, needs to be designed for host machines at the customers end.
But at times, it is impossible to design software that works on the target machines.
Software Documentation
Software documentation is an important part of software process. A well written
document provides a great tool and means of information repository necessary to
know about software process. Software documentation also provides information
about how to use the product.
A well-maintained documentation should involve the following documents:

 Requirement documentation - This documentation works as key tool for
software designer, developer, and the test team to carry out their respective
tasks. This document contains all the functional, non-functional and
behavioral description of the intended software.
Source of this document can be previously stored data about the software,
already running software at the client’s end, client’s interview,
Course Module
5
questionnaires, and research. Generally it is stored in the form of

spreadsheet or word processing document with the high-end software
management team.
This documentation works as foundation for the software to be developed

and is majorly used in verification and validation phases. Most test-cases are
built directly from requirement documentation.
 Software Design documentation - These documentations contain all the

necessary information, which are needed to build the software. It contains:
(a) High-level software architecture, (b) Software design details, (c) Data
flow diagrams, (d) Database design
These documents work as repository for developers to implement the

software. Though these documents do not give any details on how to code
the program, they give all necessary information that is required for coding
and implementation.
 Technical documentation - These documentations are maintained by the

developers and actual coders. These documents, as a whole, represent
information about the code. While writing the code, the programmers also
mention objective of the code, who wrote it, where will it be required, what it
does and how it does, what other resources the code uses, etc.
The technical documentation increases the understanding between various

programmers working on the same code. It enhances re-use capability of the
code. It makes debugging easy and traceable.
There are various automated tools available and some comes with the
programming language itself. For example java comes JavaDoc tool to
generate technical documentation of code.
 User documentation - This documentation is different from all the above

explained. All previous documentations are maintained to provide
information about the software and its development process. But user
documentation explains how the software product should work and how it
should be used to get the desired results.
Course Module
6
These documentations may include software installation procedures, how-to

guides, user-guides, uninstallation method and special references to get more
information like license updation etc.

Books and Journals

1. Software Design and Implementation;
https://courses.cs.washington.edu/courses/cse331/10sp/lectures/lectures.html;
November 4, 2019
Course Module
Week 008-9
Software Implementation and
Documentation

• Implement the Structured Programming in Software Coding and
Implementation
• Understand the different Programming style and coding guidelines
• Know the key issues that have to be considered when implementing
software, including software reuse and open-source development.
• Structured programing is the set of design and implementation
processes that yield well-structured programs.
• A disciplined approach to programming
• Top-down design
• Step-wise refinement using a restricted set* of program structures
* The set of program structures used in structured programming is:

• Sequence
• Choice
• Loop
Top-Down Design
• A program is divided into a main module and its related modules.
Each module is in turn divided into sub-modules until the resulting
modules are understood without further division.
Modular Programming
• While programming, the code is broken
down into smaller group of instructions.
These groups are known as modules,
subprograms, or subroutines.
• Modular programming based on the

understanding of top-down analysis. It
discourages jumps using ‘goto’ statements in
the program, which often makes the program
flow non-traceable. Jumps are prohibited and
modular format is encouraged in structured
programming.
Structured Coding
• Structured programming is
a programming paradigm aimed at
improving the clarity, quality, and
development time of a computer
program by making extensive use of the
structured control flow constructs of
selection (if/then/else) and repetition
(while and for), block structures,
and subroutines.
Documentation Requirements
• General requirements of all software documentation
• Should provide for communication among team
members
• Should act as an information repository to be used
by maintenance engineers
• Should provide enough information to
management to allow them to perform all program
management related activities
• Should describe to users how to operate and
administer the system
Documentation Requirements
• In all software projects some amount of
documentation should be created prior to any code
being written
• Design docs, etc.
• Documentation should continue after the code has
been completed
• User’s manuals, etc.
• The two main types of documentation created are

Process and Product documents
Process Documentation
• Used to record and track the development process
• Planning documentation
• Cost, Schedule, Funding tracking
• Schedules
• Standards
• Etc.
• This documentation is created to allow for successful

management of a software product
Process Documentation
• Has a relatively short lifespan
• Only important to internal development process

• Except in cases where the customer requires a view
into this data
• Some items, such as papers that describe design
decisions should be extracted and moved into the
product documentation category when they become
implemented
Product Documentation
• Describes the delivered product
• Must evolve with the development of the software

product
• Two main categories:
• System Documentation
• User Documentation
• System Documentation
• Describes how the system works, but not how to
operate it
• Examples:
 Requirements Spec
 Architectural Design
 Detailed Design
 Commented Source Code
- Including output such as JavaDoc
 Test Plans
- Including test cases
 V&V plan and results
 List of Known Bugs
• User Documentation has two main types
• End User
• System Administrator
• In some cases these are the same people

• The target audience must be well understood!
• There are five important areas that should be
documented for a formal release of a software
application
• These do not necessarily each have to have their
own document, but the topics should be covered
thoroughly
1. Functional Description of the Software
2. Installation Instructions
3. Introductory Manual
4. Reference Manual
5. System Administrator’s Guide
Document Quality
• Providing thorough and professional documentation is
important for any size product development team
• The problem is that many software professionals lack

the writing skills to create professional level
documents
Document Structure
• All documents for a given product should have a
similar structure
• A good reason for product standards
• The IEEE Standard for User Documentation lists such
a structure
• It is a superset of what most documents need
The authors “best practices” are:

1. Put a cover page on all documents
2. Divide documents into chapters with sections and
subsections
3. Add an index if there is lots of reference information
4. Add a glossary to define ambiguous terms
Standards
• Standards play an important role in the development,
maintenance and usefulness of documentation
• Standards can act as a basis for quality documentation
• But are not good enough on their own
• Usually define high level content and
organization
• There are three types of documentation standards ->
1.Process Standards
• Define the approach that is to be used when creating
the documentation
• Don’t actually define any of the content of the
documents
Draft
Peer Reviews
Revise Check
2. Product Standards
• Goal is to have all documents created for a specific
product attain a consistent structure and appearance
• Can be based on organizational or contractually
required standards
Four main types:

1. Documentation Identification Standards
2. Document Structure Standards
3. Document Presentation Standards
4. Document Update Standards
2. Product Standards
• One caveat:
• Documentation that will be viewed by end users

should be created in a way that is best consumed
and is most attractive to them
• Internal development documentation generally

does not meet this need
3. Interchange Standards
• Deals with the creation of documents in a format that
allows others to effectively use
• PDF may be good for end users who don’t need to
edit
• Word may be good for text editing
• Specialized CASE tools need to be considered
• This is usually not a problem within a single
organization, but when sharing data between
organizations it can occur
• This same problem is faced all the time during
software integration
Other Standards
• IEEE
• Has a published standard for user documentation
• Provides a structure and superset of content areas
• Many organizations probably won’t create
documents that completely match the standard
• Writing Style
• Ten “best practices” when writing are provided
• Author proposes that group edits of important
documents should occur in a similar fashion to
software walkthroughs
Online Documentation
• Either internal to the application or Web based
• Requires rethinking the presentation style since normal
“paper” documentation approaches do not carry over
well
• Should act as a supplement to paper documentation
• Biggest benefit of Web docs are that they are always
current
Document Preparation
• Covers the entire process of creating and formatting a
document for publication
• Author recommends using specialized (and separate)
tools for creating and preparing documents
• This is only important for user documentation
• It is often important to have a professional writer or

document publisher evaluate documents before
publication to ensure they look good and will carry over to
paper well
Document Storage
• Author Recommends (in 2001)
• File System to store the actual documents
• Database to store references to the files with metadata
to allow searching and referencing
• Today it is probably better to use a content management

systems
• CVS or Subversion
• Free and Open Source
• Easy to setup and maintain
1
Week 11: Software Testing
Module 008: Software Testing

1. Apply modern software testing processes in relation to software
development and project management.
2. Create test strategies and plans, design test cases, prioritize and execute
them.
3. Manage incidents and risks within a project.
4. Contribute to efficient delivery of software solutions and implement
improvements in the software development processes.
5. To gain expertise in designing, implementation and development of
computer based systems and IT processes.
Introduction
Software Testing is evaluation of the software against requirements gathered from
users and system specifications. Testing is conducted at the phase level in software
development life cycle or at module level in program code. Software testing
comprises of Validation and Verification.
Software Validation
Validation is process of examining whether or not the software satisfies the user
requirements. It is carried out at the end of the SDLC. If the software matches
requirements for which it was made, it is validated.
 Validation ensures the product under development is as per the user
requirements.
 Validation answers the question – "Are we developing the product which
attempts all that user needs from this software?".
 Validation emphasizes on user requirements.
Software Verification
Verification is the process of confirming if the software is meeting the business
requirements, and is developed adhering to the proper specifications and
methodologies.
 Verification ensures the product being developed is according to design
specifications.
 Verification answers the question– "Are we developing this product by firmly
following all design specifications ?"
 Verifications concentrates on the design and system specifications.
Course Module
2
Target of the test are –

 Errors - These are actual coding mistakes made by developers. In addition,
there is a difference in output of software and desired output, is considered
as an error.
 Fault - When error exists fault occurs. A fault, also known as a bug, is a result
of an error which can cause system to fail.
 Failure - failure is said to be the inability of the system to perform the
desired task. Failure occurs when fault exists in the system.
Manual Vs. Automated Testing

Testing can either be done manually or using an automated testing tool:
 Manual - This testing is performed without taking help of automated testing
tools. The software tester prepares test cases for different sections and levels
of the code, executes the tests and reports the result to the manager.
Manual testing is time and resource consuming. The tester needs to confirm
whether or not right test cases are used. Major portion of testing involves
manual testing.
 Automated This testing is a testing procedure done with aid of automated

testing tools. The limitations with manual testing can be overcome using
automated test tools.
A test needs to check if a webpage can be opened in Internet Explorer. This can be
easily done with manual testing. But to check if the web-server can take the load of 1
million users, it is quite impossible to test manually.
There are software and hardware tools which helps tester in conducting load
testing, stress testing, regression testing.
Testing Approaches
Tests can be conducted based on two approaches –
1. Functionality testing
2. Implementation testing
When functionality is being tested without taking the actual implementation in

concern it is known as black-box testing. The other side is known as white-box
testing where not only functionality is tested but the way it is implemented is also
analyzed.
Course Module
3
Exhaustive tests are the best-desired method for a perfect testing. Every single
possible value in the range of the input and output values is tested. It is not possible
to test each and every value in real world scenario if the range of values is large.
Black-box testing
It is carried out to test functionality of the program and also called ‘Behavioral’
testing. The tester in this case, has a set of input values and respective desired
results. On providing input, if the output matches with the desired results, the
program is tested ‘ok’, and problematic otherwise.
In this testing method, the design and structure of the code are not known to the
tester, and testing engineers and end users conduct this test on the software.
Black-box testing techniques:

 Equivalence class - The input is divided into similar classes. If one element
of a class passes the test, it is assumed that all the class is passed.
 Boundary values - The input is divided into higher and lower end values. If
these values pass the test, it is assumed that all values in between may pass
too.
 Cause-effect graphing - In both previous methods, only one input value at a
time is tested. Cause (input) – Effect (output) is a testing technique where
combinations of input values are tested in a systematic way.
 Pair-wise Testing - The behavior of software depends on multiple
parameters. In pairwise testing, the multiple parameters are tested pair-wise
for their different values.
 State-based testing - The system changes state on provision of input. These
systems are tested based on their states and input.
White-box testing
It is conducted to test program and its implementation, in order to improve code
efficiency or structure. It is also known as ‘Structural’ testing.
Course Module
4
In this testing method, the design and structure of the code are known to the tester.
Programmers of the code conduct this test on the code.
The below are some White-box testing techniques:

 Control-flow testing - The purpose of the control-flow testing to set up test
cases which covers all statements and branch conditions. The branch
conditions are tested for both being true and false, so that all statements can
be covered.
 Data-flow testing - This testing technique emphasis to cover all the data
variables included in the program. It tests where the variables were declared
and defined and where they were used or changed.
Testing Levels
Testing itself may be defined at various levels of SDLC. The testing process runs
parallel to software development. Before jumping on the next stage, a stage is tested,
validated and verified.
Testing separately is done just to make sure that there are no hidden bugs or issues
left in the software. Software is tested on various levels –
Unit Testing
While coding, the programmer performs some tests on that unit of program to know
if it is error free. Testing is performed under white-box testing approach. Unit
testing helps developers decide that individual units of the program are working as
per requirement and are error free.
Integration Testing
Even if the units of software are working fine individually, there is a need to find out
if the units if integrated together would also work without errors. For example,
argument passing and data updation etc.
Course Module
5
System Testing
The software is compiled as product and then it is tested as a whole. This can be
accomplished using one or more of the following tests:
 Functionality testing - Tests all functionalities of the software against the
requirement.
 Performance testing - This test proves how efficient the software is. It tests
the effectiveness and average time taken by the software to do desired task.
Performance testing is done by means of load testing and stress testing
where the software is put under high user and data load under various
environment conditions.
 Security & Portability - These tests are done when the software is meant to
work on various platforms and accessed by number of persons.
Acceptance Testing
When the software is ready to hand over to the customer it has to go through last
phase of testing where it is tested for user-interaction and response. This is
important because even if the software matches all user requirements and if user
does not like the way it appears or works, it may be rejected.
 Alpha testing - The team of developer themselves perform alpha testing by
using the system as if it is being used in work environment. They try to find
out how user would react to some action in software and how the system
should respond to inputs.
 Beta testing - After the software is tested internally, it is handed over to the
users to use it under their production environment only for testing purpose.
This is not as yet the delivered product. Developers expect that users at this
stage will bring minute problems, which were skipped to attend.
Regression Testing
Whenever a software product is updated with new code, feature or functionality, it
is tested thoroughly to detect if there is any negative impact of the added code. This
is known as regression testing.
Testing Documentation
Testing documents are prepared at different stages –
Before Testing
Testing starts with test cases generation. Following documents are needed for
reference –
 SRS document - Functional Requirements document
Course Module
6
 Test Policy document - This describes how far testing should take place
before releasing the product.
 Test Strategy document - This mentions detail aspects of test team,
responsibility matrix and rights/responsibility of test manager and test
engineer.
 Traceability Matrix document - This is SDLC document, which is related to
requirement gathering process. As new requirements come, they are added
to this matrix. These matrices help testers know the source of requirement.
They can be traced forward and backward.
While Being Tested

The following documents may be required while testing is started and is being done:
 Test Case document - This document contains list of tests required to be
conducted. It includes Unit test plan, Integration test plan, System test plan
and Acceptance test plan.
 Test description - This document is a detailed description of all test cases
and procedures to execute them.
 Test case report - This document contains test case report as a result of the
test.
 Test logs - This document contains test logs for every test case report.
After Testing
The following documents may be generated after testing :
 Test summary - This test summary is collective analysis of all test reports
and logs. It summarizes and concludes if the software is ready to be
launched. The software is released under version control system if it is ready
to launch.
Testing vs. Quality Control & Assurance and Audit

We need to understand that software testing is different from software quality
assurance, software quality control and software auditing.
 Software quality assurance - These are software development process
monitoring means, by which it is assured that all the measures are taken as
per the standards of organization. This monitoring is done to make sure that
proper software development methods were followed.
 Software quality control - This is a system to maintain the quality of
software product. It may include functional and non-functional aspects of
software product, which enhance the goodwill of the organization. This
system makes sure that the customer is receiving quality product for their
requirement and the product certified as ‘fit for use’.
Course Module
7
 Software audit - This is a review of procedure used by the organization to

develop the software. A team of auditors, independent of development team
examines the software process, procedure, requirements and other aspects
of SDLC. The purpose of software audit is to check that software and its
development process, both conform standards, rules and regulations.

Books and Journals

1. Software Testing Overview; https://www.w3schools.in/software-
testing/overview/; November 13, 2019
Course Module
Week 011
Software Testing

• Apply modern software testing processes in relation to software
development and project management.
• Create test strategies and plans, design test cases, prioritize and
execute them.
• Manage incidents and risks within a project.
• Contribute to efficient delivery of software solutions and implement
improvements in the software development processes.
• To gain expertise in designing, implementation and development of
computer based systems and IT processes.
Observations about Testing

• “Testing is the process of executing a program with the intention of
finding errors.” – Myers
• “Testing can show the presence of bugs but never their absence.” -
Dijkstra
Good Testing Practices

• A good test case is one that has a high probability of
detecting an undiscovered defect, not one that shows that
the program works correctly
• It is impossible to test your own program
• A necessary part of every test case is a description of the
expected result
• Avoid non-reproducible or on-the-fly testing
• Write test cases for valid as well as invalid input conditions.
• Thoroughly inspect the results of each test
Good Testing Practices (cont’d)

• As the number of detected defects in a piece of software
increases, the probability of the existence of more
undetected defects also increases
• Assign your best people to testing
• Ensure that testability is a key objective in your software
design
• Never alter the program to make testing easier
• Testing, like almost every other activity, must start with
objectives
Levels of Testing
• Unit Testing
• Integration Testing
• Validation Testing
 Regression Testing
 Alpha Testing
 Beta Testing
• Acceptance Testing
Unit Testing
• Algorithms and logic
• Data structures (global and local)
• Interfaces
• Independent paths
• Boundary conditions
• Error handling
Why Integration Testing Is Necessary

• One module can have an adverse effect on another
• Subfunctions, when combined, may not produce the desired
major function
• Individually acceptable imprecision in calculations may be
magnified to unacceptable levels
Why Integration Testing Is Necessary (cont’d)

• Interfacing errors not detected in unit testing may appear
• Timing problems (in real-time systems) are not detectable by
unit testing
• Resource contention problems are not detectable by unit
testing
Top-Down Integration
1. The main control module is used as a driver, and stubs are
substituted for all modules directly subordinate to the main
module.
2. Depending on the integration approach selected (depth or
breadth first), subordinate stubs are replaced by modules
one at a time.
Top-Down Integration (cont’d)

3. Tests are run as each individual module is integrated.
4. On the successful completion of a set of tests, another stub
is replaced with a real module
5. Regression testing is performed to ensure that errors have
not developed as result of integrating new modules
Problems with Top-Down Integration

• Many times, calculations are performed in the modules at the
bottom of the hierarchy
• Stubs typically do not pass data up to the higher modules
• Delaying testing until lower-level modules are ready usually
results in integrating many modules at the same time rather
than one at a time
• Developing stubs that can pass data up is almost as much
work as developing the actual module
Bottom-Up Integration
• Integration begins with the lowest-level modules, which are
combined into clusters, or builds, that perform a specific
software subfunction
• Drivers (control programs developed as stubs) are written to
coordinate test case input and output
• The cluster is tested
• Drivers are removed and clusters are combined moving
upward in the program structure
Problems with Bottom-Up Integration

• The whole program does not exist until the last module is
integrated
• Timing and resource contention problems are not found until
late in the process
Validation Testing
• Determine if the software meets all of the requirements
defined in the SRS
• Having written requirements is essential
• Regression testing is performed to determine if the software
still meets all of its requirements in light of changes and
modifications to the software
• Regression testing involves selectively repeating existing
validation tests, not developing new tests
Alpha and Beta Testing

• It’s best to provide customers with an outline of the things
that you would like them to focus on and specific test
scenarios for them to execute.
• Provide with customers who are actively involved with a
commitment to fix defects that they discover.
Acceptance Testing
• Similar to validation testing except that customers are
present or directly involved.
• Usually the tests are developed by the customer
Test Methods
• White box or glass box testing
• Black box testing
• Top-down and bottom-up for performing incremental
integration
• ALAC (Act-like-a-customer)
Test Types
• Functional tests
• Algorithmic tests
• Positive tests
• Negative tests
• Usability tests
• Boundary tests
• Startup/shutdown tests
• Platform tests
• Load/stress tests
Test Planning
• The Test Plan – defines the scope of the work to be
performed
• The Test Procedure – a container document that holds all of
the individual tests (test scripts) that are to be executed
• The Test Report – documents what occurred when the test
scripts were run
Test Plan
• Questions to be answered:
• How many tests are needed?
• How long will it take to develop those tests?
• How long will it take to execute those tests?
• Topics to be addressed:
• Test estimation
• Test development and informal validation
• Validation readiness review and formal validation
• Test completion criteria
Test Estimation
• Number of test cases required is based on:
• Testing all functions and features in the SRS
• Including an appropriate number of ALAC (Act Like A
Customer) tests including:
• Do it wrong
• Use wrong or illegal combination of inputs
• Don’t do enough
• Do nothing
• Do too much
• Achieving some test coverage goal
• Achieving a software reliability goal
Considerations in Test Estimation

• Test Complexity – It is better to have many small tests that a
few large ones.
• Different Platforms – Does testing need to be modified for
different platforms, operating systems, etc.
• Automated or Manual Tests – Will automated tests be
developed? Automated tests take more time to create but do
not require human intervention to run.
1
Week 12: Software Design Strategies
Module 009: Software Design Strategies

1. Assess the impact of a GUI in Software Design
2. Describe the Software structured Design
3. Identify the different design process of function oriented design
4. Discuss the Software User Interface Design
Introduction
Software design is a process to conceptualize the software requirements into
software implementation. Software design takes the user requirements as
challenges and tries to find optimum solution. While the software is being
conceptualized, a plan is chalked out to find the best possible design for
implementing the intended solution.
There are multiple variants of software design. Let us study them briefly:
Structured Design
Structured design is a conceptualization of problem into several well-organized
elements of solution. It is basically concerned with the solution design. Benefit of
structured design is, it gives better understanding of how the problem is being
solved. Structured design also makes it simpler for designer to concentrate on the
problem more accurately.
Structured design is mostly based on ‘divide and conquer’ strategy where a problem
is broken into several small problems and each small problem is individually solved
until the whole problem is solved.
The small pieces of problem are solved by means of solution modules. Structured
design emphasis that these modules be well organized in order to achieve precise
solution.
These modules are arranged in hierarchy. They communicate with each other. A
good structured design always follows some rules for communication among
multiple modules, namely –
 Cohesion - grouping of all functionally related elements.
 Coupling - communication between different modules.
Course Module
2
A good structured design has high cohesion and low coupling arrangements.
Function Oriented Design

In function-oriented design, the system comprises of many smaller sub-systems
known as functions. These functions are capable of performing significant task in
the system. The system is considered as top view of all functions.
Function oriented design inherits some properties of structured design where

divide and conquer methodology is used.
This design mechanism divides the whole system into smaller functions, which
provides means of abstraction by concealing the information and their operation.
These functional modules can share information among themselves by means of
information passing and using information available globally.
Another characteristic of functions is that when a program calls a function, the

function changes the state of the program, which sometimes is not acceptable by
other modules. Function oriented design works well where the system state does
not matter and program/functions work on input rather than on a state.
Design Process
 The whole system is seen as how data flows in the system by means of data
flow diagram.
 DFD depicts how functions change data and state of the entire system.
 The entire system is logically broken down into smaller units known as
functions on the basis of their operation in the system.
 Each function is then described at large.
Object Oriented Design

Object Oriented Design (OOD) works around the entities and their characteristics
instead of functions involved in the software system. This design strategies focuses
on entities and its characteristics. The whole concept of software solution revolves
around the engaged entities.
Let us see the important concepts of Object Oriented Design:

 Objects - All entities involved in the solution design are known as objects.
For example, person, banks, company, and customers are treated as objects.
Course Module
3
Every entity has some attributes associated to it and has some methods to
perform on the attributes.
 Classes - A class is a generalized description of an object. An object is an

instance of a class. Class defines all the attributes, which an object can have
and methods, which defines the functionality of the object.
In the solution design, attributes are stored as variables and functionalities

are defined by means of methods or procedures.
 Encapsulation - In OOD, the attributes (data variables) and methods

(operation on the data) are bundled together is called encapsulation.
Encapsulation not only bundles important information of an object together,
but also restricts access of the data and methods from the outside world. This
is called information hiding.
 Inheritance - OOD allows similar classes to stack up in hierarchical manner

where the lower or sub-classes can import, implement and re-use allowed
variables and methods from their immediate super classes. This property of
OOD is known as inheritance. This makes it easier to define specific class and
to create generalized classes from specific ones.
 Polymorphism - OOD languages provide a mechanism where methods

performing similar tasks but vary in arguments, can be assigned same name.
This is called polymorphism, which allows a single interface performing
tasks for different types. Depending upon how the function is invoked,
respective portion of the code gets executed.
Design Process
Software design process can be perceived as series of well-defined steps. Though it
varies according to design approach (function oriented or object oriented, yet It may
have the following steps involved:
 A solution design is created from requirement or previous used system
and/or system sequence diagram.
 Objects are identified and grouped into classes on behalf of similarity in
attribute characteristics.
 Class hierarchy and relation among them is defined.
 Application framework is defined.
Software Design Approaches

Here are two generic approaches for software designing:
Course Module
4
Top Down Design

We know that a system is composed of more than one sub-systems and it contains a
number of components. Further, these sub-systems and components may have their
own set of sub-systems and components, and creates hierarchical structure in the
system.
Top-down design takes the whole software system as one entity and then
decomposes it to achieve more than one sub-system or component based on some
characteristics. Each sub-system or component is then treated as a system and
decomposed further. This process keeps on running until the lowest level of system
in the top-down hierarchy is achieved.
Top-down design starts with a generalized model of system and keeps on defining
the more specific part of it. When all the components are composed the whole
system comes into existence.
Top-down design is more suitable when the software solution needs to be designed
from scratch and specific details are unknown.
Bottom-up Design
The bottom up design model starts with most specific and basic components. It
proceeds with composing higher level of components by using basic or lower level
components. It keeps creating higher level components until the desired system is
not evolved as one single component. With each higher level, the amount of
abstraction is increased.
Bottom-up strategy is more suitable when a system needs to be created from some
existing system, where the basic primitives can be used in the newer system.
Both, top-down and bottom-up approaches are not practical individually. Instead, a
good combination of both is used.
Software User Interface Design

User interface is the front-end application view to which user interacts in order to
use the software. User can manipulate and control the software as well as hardware
by means of user interface. Today, user interface is found at almost every place
where digital technology exists, right from computers, mobile phones, cars, music
players, airplanes, ships etc.
Course Module
5
User interface is part of software and is designed in such a way that it is expected to
provide the user insight of the software. UI provides fundamental platform for
human-computer interaction.
UI can be graphical, text-based, audio-video based, depending upon the underlying

hardware and software combination. UI can be hardware or software or a
combination of both.
The software becomes more popular if its user interface is:

 Attractive
 Simple to use
 Responsive in short time
 Clear to understand
 Consistent on all interfacing screens
UI is broadly divided into two categories:

 Command Line Interface
 Graphical User Interface
Command Line Interface (CLI)

CLI has been a great tool of interaction with computers until the video display
monitors came into existence. CLI is first choice of many technical users and
programmers. It is the minimum interface software can provide to its users.
CLI provides a command prompt, the place where the user types the command and
feeds to the system. The user needs to remember the syntax of command and its
use. Earlier CLI were not programmed to handle the user errors effectively.
A command is a text-based reference to set of instructions, which are expected to be

executed by the system. There are methods like macros, scripts that make it easy for
the user to operate.
CLI uses less amount of computer resource as compared to GUI.
Course Module
6
CLI Elements
A text-based command line interface can have the following elements:

 Command Prompt - It is text-based notifier that is mostly shows the context
in which the user is working. It is generated by the software system.
 Cursor - It is a small horizontal line or a vertical bar of the height of line, to

represent position of character while typing. Cursor is mostly found in
blinking state. It moves as the user writes or deletes something.
 Command - A command is an executable instruction. It may have one or

more parameters. Output on command execution is shown inline on the
screen. When output is produced, command prompt is displayed on the next
line.
Graphical User Interface

Graphical User Interface (GUI) provides the user graphical means to interact with
the system. GUI can be combination of both hardware and software. Using GUI, user
interprets the software.
Course Module
7
Typically, GUI is more resource consuming than that of CLI. With advancing
technology, the programmers and designers create complex GUI designs that work
with more efficiency, accuracy, and speed.
GUI Elements
GUI provides a set of components to interact with software or hardware.
Every graphical component provides a way to work with the system. A GUI system
has following elements such as:
Window - An area where contents of application are displayed. Contents in a

window can be displayed in the form of icons or lists, if the window represents file
structure. It is easier for a user to navigate in the file system in an exploring window.
Windows can be minimized, resized or maximized to the size of screen. They can be
moved anywhere on the screen. A window may contain another window of the same
application, called child window.
 Tabs - If an application allows executing multiple instances of itself, they
appear on the screen as separate windows. Tabbed Document Interface
has come up to open multiple documents in the same window. This interface
also helps in viewing preference panel in application. All modern web-
browsers use this feature.
Course Module
8
 Menu - Menu is an array of standard commands, grouped together and

placed at a visible place (usually top) inside the application window. The
menu can be programmed to appear or hide on mouse clicks.
 Icon - An icon is small picture representing an associated application. When

these icons are clicked or double clicked, the application window is opened.
Icon displays application and programs installed on a system in the form of
small pictures.
 Cursor - Interacting devices such as mouse, touch pad, digital pen are
represented in GUI as cursors. On screen cursor follows the instructions from
hardware in almost real-time. Cursors are also named pointers in GUI
systems. They are used to select menus, windows and other application
features.
Application specific GUI components

A GUI of an application contains one or more of the listed GUI elements:
 Application Window - Most application windows uses the constructs
supplied by operating systems but many use their own customer created
windows to contain the contents of application.
 Dialogue Box - It is a child window that contains message for the user and
request for some action to be taken. For Example: Application generate a
dialogue to get confirmation from user to delete a file.
 Text-Box - Provides an area for user to type and enter text-based data.
 Buttons - They imitate real life buttons and are used to submit inputs to the
software.
Course Module
9
 Radio-button - Displays available options for selection. Only one can be

selected among all offered.
 Check-box - Functions similar to list-box. When an option is selected, the box
is marked as checked. Multiple options represented by check boxes can be
selected.
 List-box - Provides list of available items for selection. More than one item
can be selected.
Other impressive GUI components are:

 Sliders
 Combo-box
 Data-grid
 Drop-down list
User Interface Design Activities

There are a number of activities performed for designing user interface. The process
of GUI design and implementation is alike SDLC. Any model can be used for GUI
implementation among Waterfall, Iterative or Spiral Model.
Course Module
10
A model used for GUI design and development should fulfill these GUI specific steps.
 GUI Requirement Gathering - The designers may like to have list of all
functional and non-functional requirements of GUI. This can be taken from
user and their existing software solution.
 User Analysis - The designer studies who is going to use the software GUI.
The target audience matters as the design details change according to the
knowledge and competency level of the user. If user is technical savvy,
advanced and complex GUI can be incorporated. For a novice user, more
information is included on how-to of software.
 Task Analysis - Designers have to analyze what task is to be done by the

software solution. Here in GUI, it does not matter how it will be done. Tasks
can be represented in hierarchical manner taking one major task and
dividing it further into smaller sub-tasks. Tasks provide goals for GUI
presentation. Flow of information among sub-tasks determines the flow of
GUI contents in the software.
 GUI Design and implementation - Designers after having information about

requirements, tasks and user environment, design the GUI and implements
into code and embed the GUI with working or dummy software in the
background. It is then self-tested by the developers.
Course Module
11
 Testing - GUI testing can be done in various ways. Organization can have in-
house inspection, direct involvement of users and release of beta version are
few of them. Testing may include usability, compatibility, user acceptance
etc.

Books and Journals

1. Strategies of Software Design; https://www.slideshare.net/Amitgehu/strategy-of-
software-design; November 15, 2019
2. Design Strategy and Software Design Effectiveness;
https://www.computer.org/csdl/magazine/so/2012/01/mso2012010051/13rR
UxZ0nZw; November 15, 2019
Course Module
Week 012
Software Design Strategies

• Assess the impact of a GUI in Software Design
• Describe the Software structured Design
• Identify the different design process of function oriented design
• Discuss the Software User Interface Design
SOFTWARE DESIGN PROCESS

Tackling Design Problems

 Any design problems must be tackled in three stages;
 Study and understand the problem
 Identify gross features of at least one possible solution
 Describe each abstraction used in the solution
Design Process
 Software designers do not arrive at a finished design immediately.
They develop design iteratively through number of different versions.
The starting point is informal design which is refined by adding
information to make it consistent and complete as shown in the figure
below:
Design Process
 A general model of design process
Architectural Design
 Identifying the sub-systems and establishing framework for sub-
system control and communication.
 Explained using the following architecture
Architecture Design
 Activities necessary for architectural designing;
 System Structuring
 Control modeling
 Modular decomposition
 The output of the architectural design process is an architectural
design document.
Architecture Design
 Client and Server are the subsystems that
are controlling the other modules.
 Other modules are the rectangles in white.
Ex, Network Prediction, Play, Chat Room,
Game Room etc.
SOFTWARE DESIGN METHODOLOGIES

Design Methodologies
 J. Christopher Jones, taken from classis work, Design Methods: Seeds
of Human Futures(Jones 1970.)
 ‘The fundamental problem is that designers are obliged to use current

information to predict a future state that will not come about unless
their predictions are correct. The final outcome of designing has to be
assumed before the means of achieving it can be explored: the
designers have to work backwards in time from an assumed effect
upon the world to the beginning of a chain of events that will bring the
effect about.’
 A more methodical approach to software design is proposed by
structured methods which are sets of notations and guidelines for
software design.
 Two major rules of this method
 Programs were to be broken into functions and subroutines
 There was only a single entry point and a single exit point for any
function or routine.
 Structured methods often support some or all of the following
models of a system:
 A data-flow model
 An Entity-relationship model
 A structural model
 An object-oriented model
 Rounded rectangles represents functions which transform inputs to
outputs.
The transformation name indicates its functions.

 Rectangles represents data stores.
 Circles represents user interactions with the system which provide

input and receive output.
 Arrows show the direction of the data flow.
Entity Relationship Notations

Entity Relationship Model

 Example for
Entity Relationship Model
Structural Model
 Example for structural model
SOFTWARE DESIGN STRATEGIES

Design Strategies
 Function Oriented
 Design is decomposed into set of interacting units where each
unit has clearly defined function
 Conceals the details of an algorithm in a function but system state
information is not hidden.
 The activities of this strategy;
 Data-flow design
 Structural decomposition
 Detailed design description
Design Strategies
 Object-oriented design
 Is based on the idea of information hiding.
 System is viewed as a set of interacting objects, with their own
private state.
 Dominant design strategy for new software systems.
 Objects communicate by calling on services offered by other
objects rather than sharing variables. This reduces the overall
system coupling.
 Message passing model allows objects to be implemented
as concurrent processes.
Design Strategies
 Kinds of concurrent object implementation
 Passive objects
 Active objects
1
Week 13: Software Maintenance
Module 010: Software Maintenance

1. Assess the impact of a change request to an existing product of medium
size.
2. Describe techniques, coding idioms and other mechanisms for
implementing designs that are more maintainable.
3. Refactor an existing software implementation to improve some aspect of
its design.
4. Identify the principal issues associated with software evolution and
explain their impact on the software lifecycle.'
5. Discuss the advantages and disadvantages of different types of software
reuse.
Introduction
Software maintenance is widely accepted part of SDLC now a days. It stands for all
the modifications and updations done after the delivery of software product. There
are number of reasons, why modifications are required, some of them are briefly
mentioned below:
 Market Conditions - Policies, which changes over the time, such as taxation
and newly introduced constraints like, how to maintain bookkeeping, may
trigger need for modification.
 Client Requirements - Over the time, customer may ask for new features or
functions in the software.
 Host Modifications - If any of the hardware and/or platform (such as
operating system) of the target host changes, software changes are needed to
keep adaptability.
 Organization Changes - If there is any business level change at client end,
such as reduction of organization strength, acquiring another company,
organization venturing into new business, need to modify in the original
software may arise.
Types of maintenance
In a software lifetime, type of maintenance may vary based on its nature. It may be
just a routine maintenance tasks as some bug discovered by some user or it may be
a large event in itself based on maintenance size or nature. Following are some
types of maintenance based on their characteristics:
Course Module
2
 Corrective Maintenance - This includes modifications and updations done

in order to correct or fix problems, which are either discovered by user or
concluded by user error reports.
 Adaptive Maintenance - This includes modifications and updations applied
to keep the software product up-to date and tuned to the ever changing
world of technology and business environment.
 Perfective Maintenance - This includes modifications and updates done in
order to keep the software usable over long period of time. It includes new
features, new user requirements for refining the software and improve its
reliability and performance.
 Preventive Maintenance - This includes modifications and updations to
prevent future problems of the software. It aims to attend problems, which
are not significant at this moment but may cause serious issues in future.
Cost of Maintenance
Reports suggest that the cost of maintenance is high. A study on estimating software
maintenance found that the cost of maintenance is as high as 67% of the cost of
entire software process cycle.
On an average, the cost of software maintenance is more than 50% of all SDLC
phases. There are various factors, which trigger maintenance cost go high, such as:
Course Module
3
Real-world factors affecting Maintenance Cost

 The standard age of any software is considered up to 10 to 15 years.
 Older softwares, which were meant to work on slow machines with less
memory and storage capacity cannot keep themselves challenging against
newly coming enhanced softwares on modern hardware.
 As technology advances, it becomes costly to maintain old software.
 Most maintenance engineers are newbie and use trial and error method to
rectify problem.
 Often, changes made can easily hurt the original structure of the software,
making it hard for any subsequent changes.
 Changes are often left undocumented which may cause more conflicts in
future.
Software-end factors affecting Maintenance Cost

 Structure of Software Program
 Programming Language
 Dependence on external environment
 Staff reliability and availability
Maintenance Activities
IEEE provides a framework for sequential maintenance process activities. It can be
used in iterative manner and can be extended so that customized items and
processes can be included.
Course Module
4
These activities go hand-in-hand with each of the following phase:

 Identification & Tracing - It involves activities pertaining to identification
of requirement of modification or maintenance. It is generated by user or
system may itself report via logs or error messages.Here, the maintenance
type is classified also.
 Analysis - The modification is analyzed for its impact on the system

including safety and security implications. If probable impact is severe,
alternative solution is looked for. A set of required modifications is then
materialized into requirement specifications. The cost of
modification/maintenance is analyzed and estimation is concluded.
 Design - New modules, which need to be replaced or modified, are designed

against requirement specifications set in the previous stage. Test cases are
created for validation and verification
 Implementation - The new modules are coded with the help of structured
design created in the design step.Every programmer is expected to do unit
testing in parallel.
 System Testing - Integration testing is done among newly created modules.

Integration testing is also carried out between new modules and the system.
Finally the system is tested as a whole, following regressive testing
procedures.
 Acceptance Testing - After testing the system internally, it is tested for

acceptance with the help of users. If at this state, user complaints some issues
they are addressed or noted to address in next iteration.
 Delivery - After acceptance test, the system is deployed all over the
organization either by small update package or fresh installation of the
system. The final testing takes place at client end after the software is
delivered.
Training facility is provided if required, in addition to the hard copy of user

manual.
 Maintenance management - Configuration management is an essential part

of system maintenance. It is aided with version control tools to control
versions, semi-version or patch management.
Course Module
5
Software Re-engineering
When we need to update the software to keep it to the current market, without
impacting its functionality, it is called software re-engineering. It is a thorough
process where the design of software is changed and programs are re-written.
Legacy software cannot keep tuning with the latest technology available in the
market. As the hardware become obsolete, updating of software becomes a
headache. Even if software grows old with time, its functionality does not.
For example, initially Unix was developed in assembly language. When language C
came into existence, Unix was re-engineered in C, because working in assembly
language was difficult.
Other than this, sometimes programmers notice that few parts of software need
more maintenance than others and they also need re-engineering.
Re-Engineering Process
 Decide what to re-engineer. Is it whole software or a part of it?
 Perform Reverse Engineering, in order to obtain specifications of existing
software.
 Restructure Program if required. For example, changing function-oriented
programs into object-oriented programs.
Course Module
6
 Re-structure data as required.

 Apply Forward engineering concepts in order to get re-engineered
software.
There are few important terms used in Software re-engineering
Reverse Engineering
It is a process to achieve system specification by thoroughly analyzing,
understanding the existing system. This process can be seen as reverse SDLC model,
i.e. we try to get higher abstraction level by analyzing lower abstraction levels.
An existing system is previously implemented design, about which we know

nothing. Designers then do reverse engineering by looking at the code and try to get
the design. With design in hand, they try to conclude the specifications. Thus, going
in reverse from code to system specification.
Program Restructuring
It is a process to re-structure and re-construct the existing software. It is all about
re-arranging the source code, either in same programming language or from one
programming language to a different one. Restructuring can have either source
code-restructuring and data-restructuring or both.
Re-structuring does not impact the functionality of the software but enhance
reliability and maintainability. Program components, which cause errors very
frequently can be changed, or updated with re-structuring.
The dependability of software on obsolete hardware platform can be removed via

re-structuring.
Forward Engineering
Forward engineering is a process of obtaining desired software from the
specifications in hand which were brought down by means of reverse engineering. It
assumes that there was some software engineering already done in the past.
Course Module
7
Forward engineering is same as software engineering process with only one

difference – it is carried out always after reverse engineering.
Component reusability
A component is a part of software program code, which executes an independent
task in the system. It can be a small module or sub-system itself.
Example
The login procedures used on the web can be considered as components, printing
system in software can be seen as a component of the software.
Components have high cohesion of functionality and lower rate of coupling, i.e. they
work independently and can perform tasks without depending on other modules.
In OOP, the objects are designed are very specific to their concern and have fewer
chances to be used in some other software.
In modular programming, the modules are coded to perform specific tasks which
can be used across number of other software programs.
There is a whole new vertical, which is based on re-use of software component, and
is known as Component Based Software Engineering (CBSE).
Course Module
8
Re-use can be done at various levels

 Application level - Where an entire application is used as sub-system of new
software.
 Component level - Where sub-system of an application is used.
 Modules level - Where functional modules are re-used.
Software components provide interfaces, which can be used to establish

communication among different components.
Reuse Process
Two kinds of method that can be adopted: either by keeping requirements same and
adjusting components or by keeping components same and modifying
requirements.
 Requirement Specification - The functional and non-functional

requirements are specified, which a software product must comply to, with
the help of existing system, user input or both.
 Design - This is also a standard SDLC process step, where requirements are
defined in terms of software parlance. Basic architecture of system as a
whole and its sub-systems are created.
 Specify Components - By studying the software design, the designers

segregate the entire system into smaller components or sub-systems. One
Course Module
9
complete software design turns into a collection of a huge set of components

working together.
 Search Suitable Components - The software component repository is

referred by designers to search for the matching component, on the basis of
functionality and intended software requirements..
 Incorporate Components - All matched components are packed together to

shape them as complete software.

Books and Journals

1. Software Maintenance and Evolution; https://uclouvain.be/en-cours-2019-
LINGI2252 ; November 13, 2019
2. CS302: Software Engineering; https://learn.saylor.org/course/CS302; November
13, 2019
Course Module
Week 013
Software Maintenance

• Assess the impact of a change request to an existing product of
medium size.
• Describe techniques, coding idioms and other mechanisms for
implementing designs that are more maintainable.
• Refactor an existing software implementation to improve some aspect
of its design.
• Identify the principal issues associated with software evolution and
explain their impact on the software lifecycle.'
• Discuss the advantages and disadvantages of different types of
software reuse.
Software Maintenance
Main issues:
 why maintenance is such an issue
 reverse engineering and its limitations
 how to organize maintenance
Relative distribution of software/hardware costs

100
Hardware
Development
Percent of total cost
60
Software
20
Maintenance
1955 1970 1985

Year
Point to ponder #1
Why does software maintenance cost so much?

Software Maintenance, definition

The process of modifying a software system or
component after delivery to correct faults, improve
performance or other attributes, or adapt to a
changed environment
Maintenance is thus concerned with:
• correcting errors found after the software has been delivered
• adapting the software to changing requirements, changing

environments, ...
Key to maintenance is in development

• Higher quality  less (corrective) maintenance
• Anticipating changes  less (adaptive and perfective) maintenance
• Better tuning to user needs  less (perfective) maintenance
• Less code  less maintenance

Kinds of maintenance activities

• corrective maintenance: correcting errors
• adaptive maintenance: adapting to changes in the environment (both

hardware and software)
• perfective maintenance: adapting to changing user requirements
• preventive maintenance: increasing the system’s maintainability

Distribution of maintenance activities
corrective 21%
perfective 50%
adaptive 25%
preventive 4%
Growth of maintenance problem

• 1975: ~75,000 people n maintenance (17%)
• 1990: 800,000 (47%)
• 2005: 2,500,000 (76%)
• 2015: ??
• (Numbers from Jones (2006))

Shift in type of maintenance over time
• Introductory stage: emphasis on user support
• Growth stage: emphasis on correcting faults
• Maturity: emphasis on enhancements
• Decline: emphasis on technology changes

Major causes of maintenance problems
• Unstructured code
• Insufficient domain knowledge
• Insufficient documentation
Reverse engineering
Reverse engineering
• Does not involve any adaptation of the system
• Akin to reconstruction of a blueprint
• Design recovery: result is at higher level of abstraction
• Redocumentation: result is at same level of abstraction

Restructuring
• Functionality does not change
• From one representation to another, at the same level of abstraction,

such as:
• From spaghetti code to structured code
• Refactoring after a design step in agile approaches
• Black box restructuring: add a wrapper
• With platform change: migration
Reengineering (renovation)
• Functionality does change
• Then reverse engineering step is followed by a forward

engineering step in which the changes are made
Refactoring in case of bad smells

• Long method
• Large class
• Primitive obsession
• Data clumps
• Switch statements
• Lazy class
• Duplicate code
• Feature envy
• Inappropriate intimacy
• …
Categories of bad smells
• Bloaters: something has grown too large

• Object-oriented abusers: OO not fully exploited
• Change preventers: hinder further evolution
• Dispensables: can be removed
• Encapsulators: deal with data communication
• Couplers: coupling too high
Program comprehension
• Role of programming plans, beacons
• As-needed strategy vs systematic strategy
• Use of outside knowledge (domain knowledge, naming

conventions, etc.)
Software maintenance tools

• Tools to ease perceptual processes (reformatters)
• Tools to gain insight in static structure
• Tools to gain insight in dynamic behavior
• Tools that inspect version history

Analyzing software evolution data

• Version-centered analysis: study differences between successive
versions
• History-centered analysis: study evolution from a certain

viewpoint (e.g. how often components are changed together)
Example version-centered analysis

Example history-centered analysis

Summary
• most of maintenance is (inevitable) evolution
• Maintenance problems:
• Unstructured code
• Insufficient knowledge about system and domain
• Insufficient documentation
• Bad image of maintenance department
• Lehman’s 3rd law: a system that is used, will change

1
Week 14: Software Engineering Best Practices
Module 011: Software Engineering Best

Practices

1. Function effectively in teams and adapt teaming strategies to improve
productivity;
2. Recognize human, security, social, and entrepreneur issues and
responsibilities relevant to engineering software and the digitalization of
services.
3. Integrate into a multi-cultural working environment with a practical
orientation and collaborate in professional networks;
4. Acknowledge life-long learning as a way to stay up to date in the
profession.
Introduction
Software is not immune to the failing economy. Many software companies will close,
and thousands of layoffs will occur as company’s contract and try to save money.
Historically, software costs have been a major component of corporate expense.

Software costs have also been difficult to control, and have been heavily impacted
by poor quality, marginal security, and other chronic problems.
Poor software engineering, which gave rise to seriously flawed economic models,
helped cause the recession. As the recession deepens, it is urgent that those
concerned with software engineering take a hard look at fundamental issues:
quality, security, measurement of results, and development best practices. This will
discuss the following topics that are critical during a major recession:
 Minimizing harm from layoffs and downsizing

 Optimizing software quality control
 Optimizing software security control
 Migration from custom development to certified reusable components
 Substituting legacy renovation for new development
 Measuring software economic value and risk
 Planning and estimating to reduce unplanned overruns
Course Module
2
What Are “Best Practices” and How Can They Be Evaluated?
A book entitled Software Engineering Best Practices should start by defining exactly
what is meant by the phrase “best practice” and then explain where the data came
from in order to include each practice in the set. A book on best practices should
also provide quantitative data that demonstrates the results of best practices.
Because practices vary by application size and type, evaluating them is difficult. For
example, the Agile methods are quite effective for projects below about 2,500
function points, but they lose effectiveness rap-idly above 10,000 function points.
Agile has not yet even been attempted for applications in the 100,000–function
point range and may even be harmful at that size.
To deal with this situation, an approximate scoring method has been developed that
includes both size and type. Methods are scored using a scale that runs from +10 to
–10 using the criteria shown in Table 11-1. Both the approximate impact on
productivity and the approximate impact on quality are included. The scoring
method can be applied to specific ranges such as 1000 function points or 10,000
function points. It can also be applied to specific types of software such as
information technology, web application, commercial software, military software,
and several others. The scoring method runs from a maximum of +10 to a minimum
of –10, as shown in Table 11-1.
The midpoint or “average” against which improvements are measured are

traditional methods such as waterfall development performed by organizations
either that don’t use the Software Engineering Institute’s Capability Maturity Model
or that are at level 1. This fairly primitive combination remains more or less the
most widely used development method even in 2009.
One important topic needs to be understood. Quality needs to be improved faster

and to a higher level than productivity in order for productivity to improve at all.
The reason for this is that finding and fixing bugs is overall the most expensive
activity in software development. Quality leads and productivity follows. Attempts
to improve productivity without improving quality first are ineffective.
For software engineering, a historically serious problem has been that measurement
practices are so poor that quantified results are scarce. There are many claims for
tools, languages, and methodologies that assert each should be viewed as a best
practice. But empirical data on their actual effectiveness in terms of quality or
productivity has been scarce.
Course Module
3
To be described as a best practice, a language, tool, or method needs to be

associated with soft-ware projects in the top 15 percent of the applications
measured and studied by the author and his colleagues. To be included in the set of
best practices, a specific method or tool has to demonstrate by using quantitative
data that it improves schedules, effort, costs, quality, customer satisfaction, or some
combination of these factors. Furthermore, enough data needs to exist to apply the
scoring method shown in Table 11-1.
This criterion brings up three important points:

Point 1: Software applications vary in size by many orders of magnitude. Methods
that might be ranked as best practices for small programs of 1000 functions point
may not be equally effective for large systems of 100,000 functions point. Therefore
the scoring method use size as a criterion for judging “best in class” status.
Course Module
4
Point 2: Software engineering is not a “one size fits all” kind of occupation. There
are many different forms of software, such as embedded applications, commercial
software packages, information technology projects, games, military applications,
outsourced applications, open source applications, and several others. These
various kinds of software applications do not necessarily use the same languages,
tools, or development methods. Therefore this will considers the approaches that
yield the best results for each type of software application.
Point 3: Tools, languages, and methods are not equally effective or important for all
activities. For example, a powerful programming language such as Objective C will
obviously have beneficial effects on coding speed and code quality. But which
programming language is used has no effect on requirements creep, user
documentation, or project management. Therefore the phrase “best practice” also
has to identify which specific activities are improved. This is complicated because
activities include development, deployment, and post-deployment maintenance and
enhancements. Indeed, for large applications, development can take up to five years,
installation can take up to one year, and usage can last as long as 25 years before the
application is finally retired. Over the course of more than 30 years, hundreds of
activities will occur.
The result of the preceding factors is that selecting a set of best practices for
software engineering is a fairly complicated undertaking. Each method, tool, or
language needs to be evaluated in terms of its effective-ness by size, by application
type, and by activity. The best practices in a variety of contexts:
 Best practices by size of the application

 Best practices by type of software (embedded, web, military, etc.)
 Best practices by activity (development, deployment, and maintenance)
In 2009, software engineering is not yet a true profession with state certification,
licensing, board examinations, formal specialties, and a solid body of empirical facts
about technologies and methods that have proven to be effective. There are, of
course, many international standards. Also, various kinds of certification are
possible on a voluntary basis. Currently, neither standards nor certification have
demonstrated much in the way of tangible improvements in software success rates.
This is not to say that certification or standards have no value, but rather that
proving their value by quantification of quality and productivity is a difficult task.
Several forms of test certification seem to result in higher levels of defect removal
efficiency than observed when uncertified testers work on similar applications.
Certified function-point counters have been shown experimentally to produce more
accurate results than uncertified counters when counting trial examples. However,
Course Module
5
much better data is needed to make a convincing case that would prove the value of
certification.
As to standards, the results are very ambiguous. No solid empiri-cal data indicates,
for example, that following ISO quality standards results in either lower levels of
potential defects or higher levels of defect removal efficiency. Some of the security
standards seem to show improvements in reduced numbers of security flaws, but
the data is sparse and unverified by controlled studies.
Multiple Paths for Software Development, Deployment, and Maintenance

One purpose is to illustrate a set of “paths” that can be followed from the very
beginning of a software project all the way through development and that lead to a
successful delivery. After delivery, the paths will continue to lead through many
years of maintenance and enhancements.
Because many paths are based on application size and type, a network of possible
paths exists. The key to successful software engineering is to find the specific path
that will yield the best results for a specific project. Some of the paths will include
Agile development, and some will include the Team Software Process (TSP). Some
paths will include the Rational Unified Process (RUP), and a few might even include
traditional water-fall development methods.
No matter which specific path is used, the destination must include fundamental
goals for the application to reach a successful conclusion:
 Project planning and estimating must be excellent and accurate.
 Quality control must be excellent.
 Change control must be excellent.
 Progress and cost tracking must be excellent.
 Measurement of results must be excellent and accurate.
Examples of typical development paths are shown in Figure 11-1. This figure
illustrates the development methods and quality practices used for three different
size ranges of software applications.
To interpret the paths illustrated by Figure 11-1, the Methods boxes near the top
indicate the methods that have the best success rates. For example, at fewer than
1000 function points, Agile has the most success. But for larger applications, the
Team Software Process (TSP) and Personal Software Process (PSP) have the
greatest success. However, all of the methods in the boxes have been used for
applications of the sizes shown, with reasonable success.
Course Module
6
Figure 11-1 Development practices by size of application
Moving down, the Defect Prevention and Defect Removal boxes show the best
combinations of reviews, inspections, and tests. As you can see, larger applications
require much more sophistication and many more kinds of defect removal than
small applications of fewer than 1000 function points.
Course Module
7
Paths for Software Deployment

Best practices are not limited to development. A major gap in the literature is that of
best practices for installing or deploying large applications. Readers who use only
personal computer software such as Windows Vista, Microsoft Office, Apple OS X,
Intuit Quicken, and the like may wonder why deployment even matters. For many
applications, installation via download, CD, or DVD may require only a few minutes.
In fact, for Software as a Service (SaaS) applications such as the Google word
processing and spreadsheet applications, downloads do not even occur. These
applications are run on the Google servers and are not in the users’ computers at all.
However, for large mainframe applications such as telephone switching systems,

large mainframe operating systems, and enterprise resource planning (ERP)
packages, deployment or installation can take a year or more. This is because the
applications are not just installed, but require substantial customization to match
local business and technical needs.
Also, training of the users of large applications is an important and time-consuming

activity that might take several courses and several weeks of class time. In addition,
substantial customized documentation may be created for users, maintenance
personnel, customer support personnel, and other ancillary users. Best practices for
installation of large applications are seldom covered in the literature, but they need
to be considered, too.
Not only are paths through software development important, but also paths for
delivery of software to customers, and then paths for maintenance and
enhancements during the active life of software applications. Figure 11-2 shows
typical installation paths for three very different situations: Software as a Service,
self-installed applications, and those requiring consultants and installation
specialists.
Software as a Service (SaaS) requires no installation. For self-installed applications,

either downloads from the Web or physical installation via CD or DVD are common
and usually accomplished with moderate ease. However, occasionally there can be
problems, such as the release of a Norton AntiVirus package that could not be
installed until the previous version was uninstalled. However, the previous version
was so convoluted that the normal Windows uninstall procedure could not remove
it. Eventually, Symantec had to provide a special uninstall tool (which should have
been done in the first place).
Course Module
8
Figure 11-2 Deployment practices by form of deployment
However, the really complex installation procedures are those associated with large
mainframe applications that need customization as well as installation. Some large
applications such as ERP packages are so complicated that sometimes it takes install
teams of 25 consultants and 25 in-house personnel a year to complete installation.
Because usage of these large applications spans dozens of different kinds of users in
various organizations (accounting, marketing, customer support, manufacturing,
etc.), a wide variety of custom user manuals and custom classes need to be created.
From the day large software packages are delivered until they are cut-over and
begin large-scale usage by all classes of users, as long as a year can go by. Make no
Course Module
9
mistake: installation, deployment, and training users of large software applications

is not a trivial undertaking.
Paths for Maintenance and Enhancements

Once software applications are installed and start being used, several kinds of
changes will occur over time:
All software applications have bugs or defects, and as these are found, they will need
to be repaired.
As businesses evolve, new features and new requirements will surface, so existing
applications must be updated to keep them current with user needs.
Government mandates or new laws such as changes in tax structures must be

implemented as they occur, sometimes on very short notice.
As software ages, structural decay always occurs, which may slow down
performance or cause an increase in bugs or defects. Therefore if the software
continues to have business value, it may be necessary to “renovate” legacy
applications. Renovation consists of topics such as restructuring or refactoring to
lower complexity, identification and removal of error-prone modules, and perhaps
adding features at the same time. Renovation is a special form of maintenance that
needs to be better covered in the literature.
After some years of usage, aging legacy applications may outlive their utility and
need replacement. However, redeveloping an existing application is not the same as
starting a brand-new application. Existing business rules can be extracted from the
code using data-mining techniques, since the original requirements and
specifications usually lag and are not kept current.
Therefore, this will attempt to show the optimal paths not only for development, but
also for deployment, maintenance, and enhancements. Figure 11-3 illustrates three
of the more common and important paths that are followed during the maintenance
period.
As can be seen from Figure 11-3, maintenance is not a “one size fits all” form of
modification. Unfortunately, the literature on software maintenance is very sparse
compared with the literature on software development. Defect repairs,
Course Module
10
enhancements, and renovations are very different kinds of activities and need
different skill sets and sometimes different tools.
Figure 11-3 Major forms of maintenance and enhancement
Course Module
11
Quantifying Software Development, Deployment, and Maintenance

This will include productivity benchmarks, quality benchmarks, and data on the
effectiveness of a number of tools, methodologies, and programming practices. It
will also include quantitative data on the costs of training and deployment of
methodologies. The data itself comes from several sources. The largest amount of
data comes from the author’s own studies with hundreds of clients between 1973
and 2009.
Other key sources of data include benchmarks gathered by Software Productivity

Research LLC (SPR) and data collected by the nonprofit International Software
Benchmarking Standards Group (ISBSG). In addition, selected data will be brought
in from other sources. Among these other sources are the David Consulting Group,
the Quality/ Productivity (Q/P) consulting group, and David Longstreet of
Longstreet consulting. Other information sources on best practices will include the
current literature on software engineering and various portals into the software
engineering domain such as the excellent portal provided by the Information
Technology Metrics and Productivity Institute (ITMPI) . Information from the
Software Engineering Institute (SEI) will also be included. Other professional
associations such as the Project Management Institute (PMI) and the American
Society for Quality (ASQ) will be cited, although they do not publish very much
quantitative data.
All of these sources provide benchmark data primarily using function points as
defined by the International Function Point Users Group (IFPUG). It uses IFPUG
function points for all quantitative data dealing with quality and productivity.
There are several other forms of function point, including COSMIC (Common
Software Measurement International Consortium) function points and Finnish
function points. While data in these alternative metrics will not be discussed at
length in this module, citations to sources of benchmark data will be included. Other
metrics such as use case points, story points, and goal-question metrics will be
mentioned and references provided.
(It is not possible to provide accurate benchmarks using either lines of code metrics
or cost per defect metrics. As will be illustrated later, both of these common metrics
violate the assumptions of standard economics, and both distort historical data so
that real trends are concealed rather than revealed.)
On the opposite end of the spectrum from best practices are worst practices. The
author has been an expert witness in a number of breach-of-contract lawsuits where
depositions and trial documents revealed the major failings that constitute worst
Course Module
12
practices. These will be discussed from time to time, to demonstrate the differences
between the best and worst practices.
In between the sets of best practices and worst practices are many methods and
practices that might be called neutral practices. These may provide some benefits for
certain kinds of applications, or they may be slightly harmful for others. But in
neither case does use of the method cause much variation in productivity or quality.
This will attempts to replace unsupported claims with empirical data derived from
careful measurement of results. When the software industry can measure
performance consistently and accurately, can estimate the results of projects with
good accuracy, can build large applications without excessive schedule and cost
overruns, and can achieve excellence in quality and customer satisfaction, then we
can call ourselves “software engineers” without that phrase being a misnomer. Until
our successes far outnumber our failures, software engineering really cannot be
considered to be a serious and legitimate engineering profession.
Yet another major weakness of software engineering is a widespread lack of

measurements. Many software projects measure neither productivity nor quality.
When measurements are attempted, many projects use metrics and measurement
approaches that have serious flaws. For example, the most common metric in the
software world for more than 50 years has been lines of code (LOC). LOC metrics
penalize high-level languages and can’t measure noncode activities at all. In the
author’s view, usage of lines of code for economic studies constitutes professional
malpractice.
Another flawed metric is that of cost per defect for measuring quality. This metric
actually penalizes quality and achieves its lowest values for the buggiest
applications. Cost per defect cannot be used to measure zero-defect applications.
Here, too, the author views cost per defect as professional malpractice if used for
economic study.
Mathematical problems with the cost per defect metric have led to the urban legend
that “it costs 100 times as much to fix a bug after delivery as during development.”
This claim is not based on time and motion studies, but is merely due to the fact that
cost per defect goes up as numbers of defects go down. Defect repairs before and
after deployment take about the same amount of time. Bug repairs at both times
range from 15 minutes to more than eight hours. Fixing a few subtle bugs can take
much longer, but they occur both before and after deployment.
Course Module
13
Neither lines of code nor cost per defect can be used for economic analysis or to
demonstrate software best practices. Therefore this will use function point metrics
for economic study and best-practice analysis. As mentioned, the specific form of
function point used is that defined by the International Function Point Users Group
(IFPUG).
There are other metrics in use such as COSMIC function points, use case points,
story points, web object points, Mark II function points, Finnish function points,
feature points, and perhaps 35 other function point variants. However, as of 2008,
only IFPUG function points have enough measured historical data to be useful for
economic and best-practice analysis on a global basis. Finnish function points have
sev-eral thousand projects, but most of these are from Finland where the work
practices are somewhat different from the United States. COSMIC function points
are used in many countries, but still lack substantial quantities of benchmark data as
of 2009 although this situation is improving.
This will offer some suggested conversion rules between other metrics and IFPUG
function points, but the actual data will be expressed in terms of IFPUG function
points using the 4.2 version of the counting rules.
IFPUG function point metrics are far from perfect, but they offer a number of
advantages for economic analysis and identification of best practices. Function
points match the assumptions of standard economics. They can measure
information technology, embedded applications, commercial software, and all other
types of software. IFPUG function points can be used to measure noncode activities
as well as to measure coding work. Function points can be used to measure defects
in requirements and design as well as to measure code defects. Function points can
handle every activity during both development and maintenance. In addition,
benchmark data from more than 20,000 projects is available using IFPUG function
points. No other metric is as stable and versatile as function point metrics.
One key fact should be obvious, but unfortunately it is not. To demonstrate high
quality levels, high productivity levels, and to identify best practices, it is necessary
to have accurate measurements in place. For more than 50 years, the software
engineering domain has utilized measurement practices and metrics that are
seriously flawed. An occupation that cannot measure its own performance with
accuracy is not qualified to be called an engineering discipline. Therefore another
purpose of this is to demonstrate how economic analysis can be applied to software
engineering projects. This will demonstrate methods for measuring productivity
and quality with high precision.
Course Module
14
Critical Topics in Software Engineering

As of 2009, several important points about software engineering have been proven
beyond a doubt. Successful software projects use state-of-the-art quality control
methods, change control methods, and project management methods. Without
excellence in quality control, there is almost no chance of a successful outcome.
Without excellence in change control, creeping requirements will lead to
unexpected delays and cost overruns. Without excellent project management,
estimates will be inac-curate, plans will be defective, and tracking will miss serious
problems that can cause either outright failure or significant overruns. Quality
control, change control, and project management are the three critical topics that
can lead to either success or failure.
A Preview of Software Development and Maintenance in 2049

Requirements analysis circa 2049 Design in 2049
Software development in 2049 User documentation circa 2049 Customer support in

2049 Maintenance and enhancement in 2049 Deployment and training in 2049
Software outsourcing in 2049
Technology selection and technology transfer in 2049 Software package evaluation

and acquisition in 2049 Enterprise architecture and portfolio analysis in 2049 Due
diligence in 2049
How Software Personnel Learn New Skills

Evaluation of software learning channels in descending order:
 Number 1: Web browsing
 Number 2: Webinars, podcasts, and e-learning
 Number 3: Electronic books (e-books)
 Number 4: In-house education
 Number 5: Self-study using CDs and DVDs
 Number 6: Commercial education
 Number 7: Vendor education
 Number 8: Live conferences
 Number 9: Wiki sites
 Number 10: Simulation web sites
 Number 11: Software journals
 Number 12: Self-study using books and training materials
 Number 13: On-the-job training
 Number 14: Mentoring
 Number 15: Professional books, monographs, and technical reports
Course Module
15
 Number 16: Undergraduate university education

 Number 17: Graduate university education
Team Organization and Specialization

 Large teams and small teams
 Finding optimal organization structures
 Matrix versus hierarchical organizations Using project offices
 Specialists and generalists Pair programming
 Use of Scrum sessions for local development
 Communications for distributed development
 In-house development, outsource development, or both

Books and Journals

1. Best Practices in Software Development;
https://www.cs.utexas.edu/~mitra/csSummer2014/cs312/lectures/bestPractice
s.html; November 16, 2019
2. Best Practice Software Engineering; http://best-practice-software-
engineering.ifs.tuwien.ac.at/; November 16, 2019
Course Module
Week 014
Software Engineering Best Practices

• Function effectively in teams and adapt teaming strategies to improve
productivity;
• Recognize human, security, social, and entrepreneur issues and
responsibilities relevant to engineering software and the digitalization
of services.
• Integrate into a multi-cultural working environment with a practical
orientation and collaborate in professional networks;
• Acknowledge life-long learning as a way to stay up to date in the
profession.
Fundamental Terms / Concepts

• Science and Engineering
 Discover
 Relationships that exist but are not found
 Formulas; chemical composition, d=r*t; calories in fats,
carbohydrates, proteins; experimentation;
 Astrophysics – origins of the universe
 Build
 Apply principles of science and mathematics to real needs,
commodities, structures, products, etc.
• Software Engineering; Software Development
Fundamental Terms / Concepts

• Software Engineering; Software Development
• Job positions:
 Software developer
 Programmer
 Software engineer
 Analyst / Programmer
 Senior … what have you…
What is Software Engineering?

• The process of solving customers’ problems by the systematic
development and evolution of large, high-quality software systems
within cost, time and other constraints
• Note:
• Process, systematic (not ad hoc), evolutionary…
• Constraints: high quality, cost, time, meets user requirements
What Happens in Practice

Sequential activities: (Traditional ‘Waterfall’ Process)
Requirements Design Code Integration Test
100% Integration
Begins
Development Progress
Risk inadequately addressed

Process not receptive to Change Late Design
Problems not really ‘seen’ Breakage
(% coded)
until near delivery date!

Until then, ‘all is well…’
Big Bang approach – full delivery
Long development cycles…
Little user involvement, etc. etc… Original
Target Date
Project Schedule
Symptoms of Software Development Problems

• Inaccurate understanding of end-user needs
• Inability to deal with changing requirements
• Modules that don’t fit together (integration)
• Software that’s hard to maintain or extend (brittle)
• Late discovery of serious project flaws (integration)
• Poor software quality (architecture, risks unanticipated…)
• Process not responsive to Change (Gantt Charts…)
• Unacceptable software performance
• Team members in each other’s way, unable to reconstruct who
changed what, when, where, why (software architecture, …
• …and we could go on and on…
Best Practices of Software Engineering
Develop Iteratively
Use
Manage Model Verify
Component Visually
Requirements Architectures Quality
Control Changes
Know these!
Practice 1: Develop Software Iteratively

• Until recently, developed under assumption - most requirements can
be identified up front.
• The research deconstructing this myth includes work by Capers Jones.

(See next slide) In this very large study of 6,700 projects, creeping
requirements — those not anticipated near the start—are a very
significant fact of software development life, ranging from around 25%
on average projects up to 50% on larger ones.
Interestingly,
• An initial design will likely be flawed with respect to its key
requirements. Requirements rarely fully known up front!
• Late-phase discovery of design defects results in costly over-runs
and/or project cancellation
• Oftentimes requirements change – even during implementation!
• While large projects are more prone to cost overruns, medium-

size/small projects are vulnerable to cancellation.
• The key reasons continue to be
• poor project planning and management,
• shortage of technical and project management expertise,
• lack of technology infrastructure,
• disinterested senior management, and
• inappropriate project teams.”
Waterfall Delays Risks

Walker Royce, 1995
R Requirements
I Design
S Code
Waterfall risk
K Integration
System
Test
T I M E
Iterative Development
Iteration 1 Iteration 2 Iteration 3

• Earliest iterations address greatest risks

• Each iteration produces an executable release
• Each iteration includes integration, test, and assessment!
• Objective Milestones: short-term focus; short term successes!
Accelerate Risk Reduction Walker Royce, 1995
I Risk reduction
S
Waterfall risk
K Iterative
Iteration Iteration Iteration Iteration Iteration

T I M E
• Earliest iterations address greatest risks

• Each iteration produces an executable release
• Each iteration includes integration, test, and assessment!
• Objective Milestones: short-term focus; short term successes!
Iterative Development Characteristics
• Critical risks are resolved before making large investments

• Initial iterations enable early user feedback
 Easy to resolve problems early.
 Encourages user feedback in meaningful ways
• Testing and integration are continuous – assures successful
integration (parts all fit)
 Continuous testing.
Iterative Development Characteristics
• Objective milestones provide short-term focus

• Progress measured by assessing implementations
• Partial implementations can be deployed
 Waterfall method – no delivery
 Incremental development? May be some great values in
delivering key parts of application. Critical components
delivered first?
• No big-bang approach!
UP Lifecycle Graph – Showing Iterations
In an iteration,
you may walk
C through all
O
N
disciplines
T
E
N
T
S
T
R
U
C
T
U
R
E
20
Problems Addressed by Iterative Development
Root Causes Solutions

 Insufficient requirements Enables and encourages user
feedback
 Ambiguous
communications Serious misunderstandings evident
early in the life cycle
 Brittle architectures
 Overwhelming complexity Development focuses on critical
 Subjective assessment issues – break it down!
 Undetected inconsistencies Objective assessment thru testing
 Poor testing and assessment
 Waterfall development
Inconsistencies detected early
 Uncontrolled change
 Insufficient automation
Testing starts earlier – continuous!
Risks identified and addressed early
- via planned iterations!
Iterations Are Time-boxed
• Work is undertaken within an iteration.

• The iteration plan defines the artifacts to be delivered, roles
and activities.
• An iteration is clearly measurable.
• Iterations are risk-driven
• Iterations are planned.
• Iterations are assessed!
• Generally, initial iterations (in Construction) based on high risk
and core functionalities!
The Iteration Plan Defines….

The deliverables for
that iteration. artifacts
The to do list for the

team members
Summary
• Much more about iteration and iteration planning later in the

course…
• You will see some of these again – and, more importantly, use
this information in your own iteration planning.

Software Engineering 1 Module

Uploaded by

Copyright:

Available Formats

Software Engineering 1 Module

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Engineering 1 Module

Uploaded by

Copyright:

Available Formats

CS-6209 Software Engineering 1

Module 001: The Scope of Software Engineering

Course Learning Outcomes:

A good decomposition of a problem should minimize interactions among various

Need of Software Engineering

 Large software - It is easier to build a wall than to a house or building, likewise,

Characteristics of Good Software

In short, Software engineering is a branch of computer science, which uses well-

Software engineering diversity

Perhaps the most significant factor in determining which software engineering

1. Stand-alone applications. These are application systems that run on a

2. Interactive transaction-based applications. These are applications that

3. Embedded control systems. These are software control systems that

8. Systems of systems. These are systems that are composed of a number of

For a web-based system, an approach based on iterative development and

Nevertheless, there are software engineering fundamentals that apply to all

1. They should be developed using a managed and understood

2. Dependability and performance are important for all types of systems.

3. Understanding and managing the software specification and

4. You should make as effective use as possible of existing resources. This

These fundamental notions of process, dependability, requirements,

You should notice that these fundamentals do not cover implementation

Software engineering ethics

1. Confidentiality. You should normally respect the confidentiality of your

2. Competence. You should not misrepresent your level of competence.

3. Intellectual property rights. You should be aware of local laws governing

Software Engineering Code of Ethics and Professional Practice

Software engineers shall commit themselves to making the analysis,

CLIENT AND EMPLOYER — Software engineers shall act in a manner that is in

PRODUCT — Software engineers shall ensure that their products and

JUDGMENT — Software engineers shall maintain integrity and independence

MANAGEMENT — Software engineering managers and leaders shall

PROFESSION — Software engineers shall advance the integrity and

COLLEAGUES — Software engineers shall be fair to and supportive of

SELF — Software engineers shall participate in lifelong learning regarding

Professional societies and institutions have an important role to play in setting

Computers have a central and growing role in commerce, industry, government,

A particularly difficult situation for professional engineers arises when their

Another ethical issue is participation in the development of military and nuclear

The general area of ethics and professional responsibility is becoming more

References and Supplementary Materials

Online Supplementary Reading Materials

2. Introduction to Software Engineering;

Online Instructional Videos

Course Learning Objectives

What is “Software Engineering”?

Why the need for Software Engineering?

*Completed late, over budget, and/or with features missing

Consequences of software failures range from inconvenience to death!

Ideal SE Life Cycle

Classical vs. Modern Views of Maintenance

• Bad products are thrown away.

Average cost of percentages of development

Find Faults Early!

• SE Goal: Better requirements, specifications and designs

Importance of Continual Planning, Testing, Documentation

Why use Object-Oriented Paradigm

Module 002: Software Engineering Principles

Course Learning Outcomes:

Principles of Software Engineering