Вы находитесь на странице: 1из 51

SOFTWARE ENGINEERING @ COGNIZANT

LESSON 1: WHAT IS SOFTWARE ENGG?

At the end of this session, you will be able to:

 Understand software engineering as an engineering discipline

 Understand the importance of framework in Software Engineering

Before you delve deeper into software engineering, you must first understand what software is.
Software or a software product is set of computer programs performing specific process and the
documentation associated with the computer programs (3). Software products can be developed
for defined market of customers. An example would be an accounting package, applicable across
industries. On the other hand, software products can also be customized and developed for one
particular customer. An example would be a customer banking system for a specific bank.

Engineering is a science. Software Engineering involves art, craft, and science. It is an amalgam
of artistry, craftsmanship, and scientific thought (4). You will now move on to the development
of software product. In most engineering disciplines, specifications are the first step in the
development of a product. Consider the case of house construction. One starts with
specifications, goes on to design, and finally building and finishing the product. Similarly in
software development, one starts with product requirements, followed by architectural details,
and then proceeds to building, that is, developing the code. It is then followed by reviewing and
installing the product. (5)

Coding and development is one of the major activities in Software Engineering. But software
engineering goes much beyond coding. It consists of various activities to encompass all aspects
of software production, such as requirements, specifications, design, coding, testing, integration,
documentation, deployment, and maintenance. Coding would occupy as little as 5 percent of the
total work involved in a Software Engineering Project. Although artistic and scientific in its
scope, it has to adhere to several time-tested processes pertaining to the different aspects.

1
Now that you know the processes involved in software development, take a look at the number
of people involved. They are spread across the managerial, technical, and end user cadre. And
like any other industry, software is linked to peripheral issues, such as business, Contractual,
Legal, and Environmental. Hence, remember, Software is "Not Just Some Pretty Code".

As mentioned, the process of creating software is more than coding -- involving people,
processes, and time-tested activities. Developing software involves opportunity of individual
expression, but it needs to be brilliance encapsulated in a framework. Small programs can be
written in an ad hoc manner by a single bright individual. However, complex software solutions
are seldom developed by armchair programmers. For complicated systems to be successfully
built, one has to be innovative and good while sticking to rules, methods, processes, and
teamwork.

2
Software development can be compared to art. Imagine building the Sistine Chapel alone and
without a blueprint. The best works of art require discipline, teamwork and planning. Art
requires blue print and team work.

In this session, you have learned that:

 Software engineering is the art, craft, and science of building large, important software
systems. It is an amalgam of artistry, craftsmanship, and scientific thought

 While being a major aspect, software engineering goes much beyond coding

 Software engineering is akin to art, which cannot succeed without a blueprint and
teamwork

=====================================================================
===

LESSON 2: SOFTWARE PROJECT STAGES

Consider this scenario (10). Doing things using a development methodology, and in a step by
step manner, ensures successful product, regardless of which industry the product belongs to.

At the end of this session, you will be able to:

 Explain the concept of a Software Development Lifecycle (SDLC)

 Describe the various stages in a Software Application Development Project, and

 Identify the Elements of a Software Application Development Stage

Software Engineering is not just Code Construction. Each Software Application that is created
follows a well defined set of activities, and has a well defined Life Cycle from initiation to the
retirement of the Software Application. Similar to a car manufacture, a software application
development project has well defined stages that are implemented in a predefined fashion to
create the software application.

The Various Stages in a Software Development Life Cycle are Requirement, analysis, design,
coding, testing, Implementation, and Maintenance/Post Implementation. In the next few pages,
you will learn about each of these stages in detail (12, 13).

In the Software Requirements Stage, the required functionality or behavior of the software is
identified by the Software Engineer. These Requirements are documented in the Software
3
Requirements Specifications Document. The Analysis and Design stage, translates requirements
into a representation of the software that can be assessed for quality before coding begins. In this
stage, typical documents that get created are the functional specifications document, design
documents, and the program specifications. In the coding stage, the executable that can be read
by the computer is created. Individual modules of programs are assembled together to create the
final executable of the software application.

Once Code has been generated, program testing begins during the Testing stage. Testing process
focuses on the logical internals of the software, ensuring all statements have been checked for
correctness. It also focuses on the functional externals, that is, conducting tests to uncover errors
and ensure that defined input will produce actual results that agree with the actual results. At the
implementation stage, after all tests have shown that the completed software works as intended,
it is deployed in its production environment. Implementation is a planned activity and steps
pertaining to it are documented as part of the Roll-Out Plan. A series of checks and reviews are
conducted in this stage to ensure that all components of the completed software have been
installed correctly. Software undergoes change after it has been deployed and delivered to the
customer. Change will occur because errors may be encountered, or because the software needs
to be adapted to meet changes in its external or operating environment, or because the customer
requires functional or performance enhancements. These are issues that are resolved during the
Maintenance or Post Implementation stage.

You will now learn about the basic building block of any stage. Basic building blocks of a Stage
are Tasks. Activities explain how a task needs to be performed. See what each of them signifies.
In the next few pages, you will learn in detail about elements of any software development stage.

You will now learn about the various elements of a stage. The Entry Criteria provides inputs
which can be documents or tasks. It is then followed by the Task or list of activities that are
implemented to complete the process. The Verification consists of reviews and approvals that
confirms adequacy of the activities done during the Task period. The stage ends with an Exit
criteria which consists of work products or documents that may serve as an Entry Criteria for the
next Stage.

4
Here is an example that describes the Elements of the Requirements Stage. The Entry Criteria
for Requirements Stage is the Business Need. For example, the client requires a system that will
automate the process of banking according to his needs. Tasks of the Stage would include
activities like requirement capture, requirement analysis, and requirements documentation. Work
Products created in this stage could be completed requirements gathering checklists and
Software Requirements Specifications. As part of Verification the completed SRS document will
be reviewed by the Project Manager and approved by the Client Representative. Signed off SRS
will be Exit Criteria for this stage, which would become the Entry Criteria for the next Stage,
Analysis and Design.

In this session, you have learned that:

 The SDLC is a sequence of steps that organizes the development of a software product
 The various stages in the SDLC are Requirement, Analysis, Design, Coding, Testing,
Implementation, and Maintenance or Post implementation
 The building blocks of any stage are Activities and Tasks.

 The elements of a stage include Entry criteria, Task, Verification, and Exit criteria.

=====================================================================
===LESSON 3: REQUIREMENT DEVELOPMENT AND MANAGEMENT

What is needed is what is often stated in the requirement specifications. What is wanted is not
what is often stated but is inherent to business and so it is called implied requirements.
Collecting the requirements is very difficult.

5
Software requirement is a necessary feature or an environment needed in the software.(17)

6
7
8
9
10
11
LESSON 4: SOFTWARE ANALYSIS AND DESIGN

At the end of this session, you will be able to:

 Explain the concept of software analysis

 Explain the concept of software design

 Describe the types of analysis and design techniques

In the analysis and design stage of software development, the focus gradually shifts from "What
to build" to "How to build". Over the next few pages, you will learn about the analysis and
design stage in detail.

You must be aware that the Requirement Specifications Document acts as the exit criteria of the
Requirement Stage. This same document is the entry criteria for the Analysis Stage. Functional
Specifications Document is the exit criteria for the Analysis Stage and in turn the entry criteria
12
for the Design Stage. In the Design Stage, the Detailed Design Document is the most important
document that gets created and is used as the basis of Code Construction in the Code
Construction Stage.

Analysis and Design are one of the foremost stages in software development cycle. (23, 24)

Analysis is the software engineering task that bridges the gap between the software requirements
stage and software design. The objective of software analysis is to state precisely what the
system will do to provide a solution to the client's need at a functional level. This is captured in
the Functional Specification Document.

Design creates a detailed Design Document that acts as the "blue-print" for the developers or the
team that will construct the code to create the system. The typical elements of software design
include Program Architectural Design, Data Design, Interface Design, and Component Design.

To understand each element of Software Design, here is an example of a Travel Booking System
called the SmartBook System. This is to be used by the Travel Agents to book Airline Tickets or
Railway Tickets.

This is the overall Architecture Design for the SmartBook System. It defines the relationship
between the structural elements of the Software Application being built. Architecture for the
system needs to be built as part of Software Analysis and Design Stage. The Data Design
specifies the data structures needed to implement the solution. It includes the Database or File
System Space Requirements. It also includes Table or Layout details, such as Table or Record
name, Column or Field names and description,Type of Column or Field the length, Default
values, Edit or validation conditions associated to a Column or Field, and Details of all Keys or
Indexes of a Table or Record. These are the interface designs which describe how the software
communicates within itself, with the systems that interoperate with it and the Humans who use
it. Interface Design for the system needs to be built as part of Software Analysis and Design
13
Stage. The Component level design transforms the structural elements of software into
procedural description of the Software Component. It includes Program specifications, that is,
the Functions or Algorithms that define the procedural design. (25, 27)

Here is a case study to understand the concept of software analysis and design better. Mercury
Travels is a premier Travel Agency of the country. Mercury wants to automate its business
processes. Requirement Analysis reveals that the specific requirement of Mercury is to create an
Air or Rail Ticket Booking System for the Travel Agents. Other business processes will not be
included in the current automation initiative. (Refer page 8 and 9).

To begin with, the software requirement specifications document is put in place. The business
need is the basis for creation of the software requirement specification document. This activity is
completed in the Requirements Stage of an Application Development Project.

Each of the Requirements is then decomposed further to create the Software Functional
Specifications. The Functional Specifications express the system to be built in a language that
designers of the system understand. The problem presented by the Requirements is analyzed
using Analysis Models. Creation of the Analysis Models and the Functional Specifications often
take place simultaneously. (31)

Here, you can see an Analysis Model that is used to express the problem. Such a diagram is
called a Data Flow Diagram, in which each bubble indicates the activity taking place. The box
on the other hand, is used to denote an external source or sink of information. The parallel bars
denote data store or file while an arc is used to denote the flow of components among the other 3
components. Note that SRS 01.1 has been expressed using processes 2a and 2b. (32)

14
The bubble 1 which denotes the activity, "Determine form of travel" has been factored further to
a lower level of D F D. (33)

The Analysis Models form the basis of the Program Specifications which is an essential
component of the Design Document. (34)

In addition to Program Specifications the Design Document includes other details like Data
Design and Program Architecture Design.

Data design involves the overall data model design for the application. Program hierarchy and
program-level interfaces are addressed in the program architecture design.

Look closely at the examples here. There are two ways you can visualize the building or
construction of a house. Builder may appoint a bricklayer to create the walls and carpenter to
create windows, fit windows into the walls etc and slowly create the house. Alternatively, the
builder may fit the standard models of doors, windows, roofs, walls, and rooms available in the
market to create the house. This is how most buildings get built now. (37)

There are two approaches to creating the Design Specifications in a project. One is the
Structured Analysis and Design Technique that can be traced to the 1970s. The other is a newer
concept called the Object Oriented approach which as a concept was developed from 1990s. (38)

SSAD makes a heavy use of functional decomposition. System behavior takes a secondary role
here. Like in the case of building a house brick by brick.(39)

The object-oriented technique on the other hand focuses on the system behavior. In the recent
years OOAD technique has become very popular with software engineers. Objects represent a
sample expected system behavior and they are called upon to function as a whole. Re-usable and

15
common objects help in achieving greater modularity and are manageable from the project
management perspective. (40)

In this session, you have learned that:

 In analysis and design the focus is on "HOW to Build" a solution and not on "WHAT to
Build"

 Analysis is the software engineering stage that bridges the gap between the software
requirements stage and software design stage

 Functional Analysis Document is the most important document that is created in this
phase

 In the software design stage, detailed design document is the most important document
that is created

 This acts as a "blue-print" to be used by the eventual implementers of the system

 The elements of software design are Program architectural design, Data design, Interface
design, Component design.

 There are two ways in which software engineers visualize "HOW to build" a solution
during analysis and design stage, namely, Structured Analysis and Design (SSAD)
technique and object-oriented technique
=====================================================================
===

LESSON 5: CODE CONSTRUCTION-V1

Your builder has taken your house requirements and has given you the building plan and the
prototype of your house. So in your mind, you have the picture of your dream house ready. What
do you think is the activity that the builder has to engage in now? Yes. You guessed it right. The
builder will need to construct the house now.

At the end of this session, you will be able to:

 Explain what code construction is and in which part of the software development
lifecycle code is constructed

 Illustrate the process of code construction

 Describe good programming practices


You will now learn how code is constructed. Design provides the basis for code construction. A
unit test helps a developer to consider what needs to be done as requirements are nailed down
firmly by tests. There is a rhythm to developing software unit tests. First, you create one test to
define some small aspect of the problem at hand. Then, you create the simplest code that will
make that test pass. Then, you create a second test. Now, you add to the code you just created to
make this new test pass, but do not write any more code until you have created a third test. You
continue until there is nothing left to test. The next page holds an activity for you. You have to

16
connect the numbers in a series beginning with number one. For example, click number two to
connect number one and number two. (42)

Now, you know that any unstructured piece of work is difficult to understand and comprehend
and that code is no exception. You should remember that even though completed code is an
important deliverable that is given to the customer, software engineering is not just coding.
Coding (shifting of focus from “what to build” to “how to build” a solution) is a stage within the
software development life cycle. The subsequent page explains the coding process in detail.
Design documents and unit test cases that are updated with test cases are important inputs for the
coding stage. Code construction using language-specific coding standards, peer review of code,
and updating code based on review comments are major tasks in this phase. Peer-reviewed code
is the output of the coding stage. (43)

This page delves into details of the tasks and activities of the coding stage. It must be noted here
that peer review of code is a very important task in the code construction stage. (44)

Before we move forward, let us take a look at the benefits of peer review. (45)

Here you will see what happens if you do not use proper coding standards. (48)

A coding standards document tells developers how they must write their code. Instead of each
developer coding in their own preferred style, they will write all code to the standards outlined in
the document. This makes sure that a large project is coded in a consistent style, that is, parts are
not written differently by different programmers. Not only does this solution make the code
easier to understand, it also ensures that any developer who looks at the code will know what to
expect throughout the entire application. (49)

This section outlines concepts that are generic in nature and applicable to most software tools
and platforms. Platform-specific conventions and guidelines are covered under the relevant
17
company standard. The relevant language-specific standard must be referred to when
constructing code in a specific language.

CODE LAYOUT AND PRESENTATION ASPECTS:

It is necessary to have a good coding layout structure. Good coding structure improves the
readability and maintainability of code. A good layout brings out the logical program structure
through appropriate use of blank lines, spaces, and indentation. Let us take the example of an
essay written by two young students of class five. Student A has used a clean paper with the
necessary punctuation marks, spaces, paragraph settings, used uniform fonts, and cases. This is
much easier to read than the one written by Student B, which has not been written neatly and
clearly. These were the basic tenets of sentence construction that we had learned when we were
in school. This is true even when you write your first program.

This page deals with the good practices on code layout and programming. Code layout deals
with the structure of the code and the way it is laid out. It affects readability and ease of
modification of code. (51) Here are the guidelines to be followed for maintaining presentation

18
aspects of code when fixing a bug.

This page outlines the concepts pertaining to sentence construction that are generic in nature and
applicable to most software tools and platforms. Platform-specific conventions and guidelines
are covered under the relevant company standard.

19
Code-level readability is not about using comments only. The main contributor to code-level
readability is not comments, but good programming style. Check the first example of code
provided. This reflects bad programming style. Check the second example. Even though this
code does not use any comment, it is much more readable. It takes us toward the goal of "self-
documenting code". (54)

When commenting a source code, always use comments judiciously so that we can ensure our
code is readable and clear. (55)

Use of headers in a program will not add to its functionality. It is of immense help during
maintenance of a program. (56)

Naming conventions for a language should be as per the recommended convention documented
in the coding checklist. The benefits of adhering to naming conventions is that somebody going
through the program can get an idea about the purpose of various entities from their names, thus
enhancing program readability. Conventions bring about uniformity in the way program entities
like variables, symbolic constants, procedures, and functions are named. Teams can develop
their specific naming conventions for identification of programs. (57)

In this page, you will learn about the declarations standards in a piece of code:

• A program consists of two basic entities, data and instructions. Data elements or
structures should be declared and initialized before (executable) instructions.

• All header files and libraries used in the program (whether standard or user defined)
should be declared.

• All global variables need to be declared and the number of global declarations used
should be minimized so as to reduce coupling between modules.

• All unique or complex variables or data structures should be described through


appropriate comments, clarifying the reason for such complexity.

• Functions and their parameters should be declared taking care to ensure that no type
mismatches occur during runtime between the calling and called module or function or
procedure.

• When using arrays, remember it is cumbersome to handle arrays having more than three
dimensions. Such arrays should be avoided.(59)
You will now learn what defensive programming is. As a programmer, you should be able to
envisage areas in your programs that can initiate errors in the behavior of the software
application. Hence, appropriate methods should be used to prevent the occurrence of errors. (60)

Continuing with defensive programming ensures that your program is secure and prevents
unauthorized access. (61)

Expectations change and hence requirements change, and so it is but natural that programs have
to be modified in order to suit the new specifications. This means that the program should be
flexible enough to be modified with little or no effort. This page identifies some practices that
help in creating modifiable or flexible programs. (62)
20
ON-SCREEN ERROR AND HELP MESSAGES:

Now, you will learn the importance of On-Screen Error and Help Messages. In this example, the
customer inserts his debit card in the ATM machine. But the machine does not accept the card
and ejects it immediately, without showing any error message. This makes the customer
frustrated. The next page provides some good practices that should be followed in case of text-
based error and help messages. Design of the On-Screen Error and Help Messages have a strong
bearing on user-friendliness. This page puts forward some of the guidelines that could be
followed by the developer.

Before we conclude, remember the following points whenever you are constructing any code.
(66)

In this session, you have learned that:

 Coding is a stage within the software development lifecycle.

 The inputs for the code construction include design document and the unit test cases
document.
 The process of code construction involves using design document and coding standards
to create code, aligning code to the unit test cases, and peer reviewing code before
delivery.

 It is a good programming practice to follow some platform-specific conventions and


guidelines that have been documented. This will help the developer to write legible
codes.

21
=====================================================================
===

LESSON 6: TESTING

Testing is an activity that is used to discover errors and correct them, so that we are able to
create a defect-free product for our customer. Let us take the example of a house. The client had
specified requirements of the house she wants. The tester tested the house to find out if all
requirements of the client had been met after delivery. The tester created the test execution
details document, which detailed the scenarios or test cases. The tester also created the results of
the test execution, which are referred to as the test log. (67)

At the end of this session, you will be able to:

 Learn about the testing stage and its process in software development

 Explain the various types of testing

 Study the important test case design methods


Testing is an important stage which follows the Coding stage in the software development life
cycle. The objective of testing is to evaluate if we have created the system correctly. During the
earlier stages, the focus was to check what is being built but in testing when we have the end
product ready, our focus shifts to validate whether the product that has been built has been built
correctly or not. Hence, the focus shifts from building the product right to building the right
product.

Now, an attempt to define software testing is made. Testing is a systematic activity where
records of test execution need to be maintained. (68)

Testing is the process of executing a program with the specific intent of finding an error. Success
of a test is determined by the number of errors it has uncovered. Tests can be conducted by the
developer or by an independent testing team. What one should remember is that the role of a
good tester is to show the presence of the defects or errors of that software.

This page explains the major activities and tasks of the testing stage. Creation of the test strategy
is the first step. It is based on the Requirements Document, the Functional Specifications
Document, and the Design Document. The test strategy describes the overall plan and approach
to be taken for testing, the deliverables, and the process for test reporting. The next step is to
create the test cases, containing the individual scenarios, which would be tested with their
expected outcomes. Test cases are executed by the tester and results of the tests are documented
in the test log. The defects of testing are recorded in defect-tracking tools such as the internal
tool Prolite or the external tool called Test Director, depending on the requirement of a project.
The owner of the application being tested then updates the application, closes the defects, and
updates Prolite with the defect status in the tools. Re-testing may be conducted to verify closure
of defects.

22
In this page, you will know the people who are responsible for testing a software application:

• Software testing can be conducted by the developers of the system or an independent


testing group who are part of the organization that has built the system.

• Software testing can also be conducted by the client or the ultimate users of the system.

• The team responsible for the different types of testing needs to be decided upon during
the planning stage.
Here, you will learn about the various stages in testing: Software testing is usually performed at
different levels of abstraction of the application along the software development process by the
builders of the system. There are three testing stages: Unit testing, integration testing, and system
testing. The objective and the abstraction levels of the application to which these tests are
performed are different. Unit tests are performed on the smallest individual units of the
application, the integration tests on a group of modules and their interfaces while the system
tests are for the entire system and the interfacing external systems. In this illustration, you can
see where the three major types of testing fit into the software development life cycle.

There is one more stage in testing that is done by the end user of the system. This is referred to
as the user acceptance test. This is to verify the functionality of the system from the end user's
perspective. Here we can see where the user acceptance testing fits into the software
development life cycle. (72)

You will now learn about each of the testing stages in detail. First you will know about unit
testing. In this page, we see a small child building a doll house. She checks each building block
to ensure that it is in line with the design of the doll house as she creates them. Similarly, unit
testing concentrates on each unit or component of the software as implemented in the code and
23
checks that it is in line with the program specification and the detailed design. The primary focus
of unit testing is to validate the logic, the structure, and the flows of the concerned program. It is
often performed by the software developer.

Moving on to integration testing, you see that the builders of the doll house now begin to put the
individually tested blocks of the house together, that is, they integrate the unit tested units. The
primary intent is to uncover errors associated with interfaces when the unit-tested components
are integrated as a module. The next page talks about system testing. (73)

After the doll house has been completed, it is checked fully by the builders of house to ensure
that it is complete and ready for habitation. Additionally, builders check if the house is secure
and can withstand rain or thunder or lightning and other environmental factors, so that it can
easily be placed in its intended environment. System testing in software checks the performance
and functionality of the complete system after all unit tested units have been integrated as per the
build plan. It also evaluates functionality with interfacing systems. Non functional requirements
like speed and reliability are also verified during system testing. (74)

Finally, looking at the acceptance testing, you see that the doll house has been placed in a
children's park. The acceptance test verifies whether the system created is in conformance with
user requirements when placed in its 'real' environment. Acceptance tests are often conducted by
the client or by the end users. Developers are not often involved in this type of testing activity.

Now, you will learn about an important concept of testing called regression testing. Regression
testing will be done to ensure that the actions taken to rectify the defect have not produced any
unexpected effects. Regression testing should be done at all levels of testing, such as unit,
integration, system, and acceptance testing. The following page gives you an example that will
help you learn the concept of regression testing. (75)

As seen in the previous example of a client stating her requirement for her house, it was
observed by the tester that the location of the door was incorrect and a defect ID was allocated to
it. When correcting this defect, the constructors may remove the door and move it to the rear
side. In this process, other sections of the building may get damaged. So when correcting the
defect of incorrect door location, care must be taken to ensure that unintended defects like cracks
in the walls are not introduced in the building. Regression testing takes care of such unexpected
issues that occur as a result of fixing defects.

This page explains what the focus is for each type of testing:

 Unit testing uses code and detailed design as an input to check correctness of individual
units.

 Integration testing uses the system design and the functional specification document as
an input.

 System testing uses the overall functionality of the system as given in the functional
specifications and software requirements. It also evaluates the non- functional
requirements.

24
 Acceptance testing is the test conducted periodically by client representatives to check if
client requirements have been met adequately.
 Regression testing, on the other hand, retests the tested sections of the software to ensure
no unintended error has been introduced.(76)
Here is another very important concept of software testing, that is, the test case. Test cases are
scenarios that are executed by the testers on the completed application to determine if the
application meets a specific requirement. One or more test cases may be required to determine if
a requirement is satisfied.

A good test case is one that uncovers errors in a complete manner with minimum time and effort.
Considering the earlier example of the completed house, the analysis, 'check if the color of
chimney is red' is a test case. If for the same example, when the test case is written as 'check if
the door does not open with a wrong key', becomes a negative test case. Hence, we learn that a
test case is a statement specifying an input, an action, or an event and expects a specific response
after execution. (78)

This page explains the two approaches to test case design.

The white box approach which is based on the internal workings of the system and black box or
behavioral approach which deals with the external functionality of the application or its part
being tested irrespective of the internal details. The following pages will give more details on
these two types of approaches.

The white box approach is used to create test cases to check if 'all gears mesh', that is, to check if
the internal operations are performed according to specifications. This tests all the logical paths
within the unit being tested and verifies if these are functioning as required in the design.

25
Black box test case design approach does not consider the internal workings of the application. It
focuses on the functional requirements alone, and it is designed to verify if the inputs are given
correctly the output generated is also correct. It should be noted that black box testing and white
box testing are not alternative approaches to test case design. On the other hand, they
complement each other.

Here are the activities performed in the testing stage for the SMARTBOOK System. The test
scenarios or test cases are logged and tracked in a tool with the detailed information about the
test case execution. Individual program units are tested as part of unit testing and the results are
logged in the tool. Subsequently, each functional module is considered and integration tested for
its functioning and logic. All interface-related tests between program units are covered under
integration testing. The system testing follows where all the functional modules are taken
together and the application is tested as a whole incorporating the interfacing issues between the
functional modules. Finally, User Acceptance Testing is conducted by the users of the system
and the resulting errors are corrected prior to staging the system into production. (81)

This page explains the salient points you should remember about testing. Test execution activity
starts after code has been constructed with unit testing of individual modules. This will be
26
followed by integration testing and system testing. However, it should be noted that test planning
activity occurs much earlier in the software development life cycle. In fact, user acceptance test
plans and cases are prepared along with the requirements document. To improve the quality of
the code being delivered, it is a good practice to 'Test before you code'. The model shown is also
called the V-Model where each stage is associated with the corresponding review and a specific
test case is prepared for testing at a later stage.

In this session, you have learned that:

 Testing is an important stage within the software development life cycle.

 The objective of a good test is to show the presence of errors and not the absence of
them.
 A good tester should attempt to break the system to uncover undiscovered errors.

 The stages important in testing are unit testing, which targets a single module, integration
testing targeting a group of modules, system testing that targets the whole system, and
acceptance testing targeting the overall system and conducted by users.

 There are two important approaches that are used to design test cases, namely, the black
box approach focuses on the functional requirements of the software, and the white box
approach focuses on internal workings of the software.
=====================================================================
===
LESSON 7: IMPLEMENTATION AND POST IMPLEMENTATION

27
At the end of this session, you will be able to:

 Explain what software implementation and post implementation are

 Illustrate the activities involved in the implementation and post implementation stages

First, you will learn about the implementation stage in software development. In this example,
you see a statue of a jockey being built. This statue is created in the sculpture workshop. It is
being built as per the requirements provided by Company 123.Company 123 wants the statue to
be installed in a park that they own. The installation team of the sculptures transfers the statue to
its intended environment. They prepare the site for installation of the statue. After the site is
ready, workers install the statue in the park for public viewing. We can see here that there is a
communication activity associated with the unveiling of the new statue.

Similarly, in case of software application development, after the software is constructed and
tested, it needs to be installed or implemented in its working environment for the intended users
to make use of it.

After the system is tested completely, it is delivered to the onsite team. The onsite team
implements the tested application in the client environment. Software implementation or the
deployment stage starts after user acceptance testing is completed. It involves all the activities
needed to make the software operational for its users. Here, the focus is to verify that the
software or the product that has been delivered is meeting the need, that is, whether the product
has been rightly built. Shifting of focus from “have we built the right product” to “have we
installed the right product correctly”

The main activities in the implementation stage are planning and defining the process for rollout,
to deploy the new application, train users on the new system after the rollout has been
implemented, and communicate the details of deployment to relevant people. (83)

Now you will learn about the post implementation stage in software development. After the
statue has been installed, as you saw in the earlier illustration, any complication can arise.

A part of the statue may get damaged and may need to be mended. In that case a complaint is
lodged with the sculpture company. Stakeholders of Company123, who own the statue, may
want a new feature to be added, or one of the stakeholders may want to change an existing
feature of the statue they had purchased. Thus, the activities involved in the post-implementation
stage are support necessary to sustain, modify, and improve a deployed system.

Similarly, in software application development, after a software has been implemented in its
intended environment, support may be needed because of the discovery of a bug or defect; the
need for enhancing the existing functionality of the software, or the need to change the existing
features or functionality of the software application.

Post implementation activity may be the regular warranty support. This includes providing the
support necessary to sustain, modify, and improve the operational software of a deployed system
to meet user requirements. Shifting of focus from “have we installed the right product” to “does
the product function correctly”. Post Implementation is the final stage in an application
development project. This page gives you some details on the post implementation stage.
28
A process document describing the post-implementation process guides the activities performed
in the post-implementation phase, which generally consists of the warranty period as per the
contract signed by the client. It also includes helpdesk support, fixing the bugs, and planning for
release of the reworked application and all other activities pertaining to the overall support of the
system in action.

Here is an illustration of the activities performed in the post implementation stage of an


application development project. The requests given by the users are first classified as bugs or
production support tasks and subsequently logged in a tool like e-tracker, for tracking followed
by analysis for resolution of the request. The resolution is then implemented and delivered to the
client for implementation. Production support issues are similarly analyzed and fixed in the
application prior to their closure. (85)

Application maintenance projects have a well-defined life cycle consisting of stages like
Requirements, Knowledge Transition, and Steady Stage. If the post-implementation activities are
continued over a sustained period, the project is converted to an application maintenance project
and the contract is revised accordingly. (86)

In this session, you have learned that:

 Software implementation or deployment is an activity that makes a software application


available for use

 A new application is deployed as per the roll-out plan

 Post-implementation is a support activity required to sustain, modify, and improve a


deployed system

 This stage generally refers to the two to six month warranty contract that may be signed
with the client

 The main activities in the implementation stage are, to roll out or deploy the new
application, and train users on the new system

29
 Post-implementation activities are implemented as per the post-implementation process
document
 The process tool used to manage post implementation activities is e-tracker.

=====================================================================
===

LESSON 8: THE MAINTANENCE MODEL (APPLICATION VALUE MANAGEMENT)

Software maintenance is the process of enhancing and optimizing deployed software as well as
remedying defects in the software. Here is an example of a constructed house. Due to wear and
tear, the delivered house would require continuous maintenance. This would include any of the
following:

 Quickfixes, such as repairing faulty electricity or plumbing appliances.

 Additional requirements to be added with the changing needs, such as adding an extra
floor to the house.

 Major repairs, which also require in-depth analysis and designing of the solution prior to
its execution, such as relaying the air-conditioning for the entire house.
At the end of this session, you will be able to:

 Learn about the fundamentals of software maintenance

 Study the different stages and activities of the maintenance process

 Know the service-level agreements and their relevance

 Identify the key issues in software maintenance

 Learn about the tool, eTracker

When in operation, defects are uncovered, operating environments change, and new user
requirements surface. Software maintenance is defined as the totality of activities required to
provide cost-effective support to software. This includes modification of a software product after
delivery to correct faults or defects, adapt the product to a modified environment, and
incorporate additional features in the application to cater to the new requirements.

Software maintenance can be categorized as:

Corrective maintenance: Is a reactive modification of a software product performed after


delivery to correct discovered problems and it is also termed as bugfix.

Adaptive maintenance: Is the modification performed on a software product after delivery to


keep a software product usable in a changed or changing environment. It is also termed as
enhancement.

Perfective maintenance: Is the modification of a software product after delivery to improve


performance or maintainability. It is also called performance tuning.
30
Preventive maintenance: Is the modification of a software product after delivery to detect and
correct latent faults in the software product before they become effective faults. This is also
termed as bugfix.

Here is an example of a house built earlier and which requires maintenance at a future point in
time. The maintenance person has to initially plan as to how the contract of maintenance would
be executed and which areas would be in the scope of the maintenance. He might exclude the
electrical maintenance from the contract and he would decide on the team that would be
responsible for maintenance and other business issues. After the contract is signed, the architect
responsible for the maintenance studies the building plan in detail, including the plumbing
layout. Then, the architect passes on the details to the maintenance team. This stage is for
developing an understanding of the existing building. Now, based on the request of the customer
the house is maintained over a period of time. As discussed earlier, the maintenance can be of
the nature of quick fixes or minor repairs, such as electrical or plumbing repairs, a major change,
such as repainting the house and incorporation of additional requirements, such as designing the
plumbing system or incorporation of air-conditioning in the house.

When the software is in operation, defects are uncovered, operating environments change, and
new user requirements surface. The principal stages of an application maintenance project
consist of planning, knowledge transition, and finally the steady state maintenance activities.
(89)

You have seen what an application maintenance process involves. Now, you will know about the
model followed by the application maintenance process. The application maintenance model
consists of planning, knowledge transition, and service steady state. The planning phase
primarily involves understanding the need of the customer in terms of what is expected from the
maintenance team. This involves a detailed discussion with the client to identify the
requirements and finalizing the contract. The activities in this stage are: Business planning at the
organizational level: This includes proposal development, estimating for resources and cost, and
defining the escalation mechanism. Maintenance planning at transition level: This includes scope
definition and the execution process adaptation. And finally knowledge transfer planning, which
involves defining the entire methodology to be adopted during the knowledge transfer phase and
a detailed schedule of the KT phase. (91)

For maintaining the existing application developed by another vendor, the maintenance team
needs to understand the functionalities and the technical details of the system. Hence, a
knowledge transition phase is required prior to the commencement of the maintenance activities.
The knowledge transition phase primarily consists of obtaining:

The knowledge about the application, considered for maintenance, from the client. Guided
support under the supervision of the client, and finally a plan defined for transitioning the
obtained knowledge to the team for future support. Initially, the application identified for
31
maintenance has to be thoroughly studied by the K T team. This includes a detailed
understanding about the business processes that the application caters to and the functions served
by the application. This also includes understanding of the technical details about the
application, the environment in which the application is operating along with the details of
interaction with the interfacing systems. Finally, the application inventory is collected by the K
T team for providing support in future. After obtaining an understanding of the entire
maintenance scenario, the K T team performs the support activities under the supervision of the
client's team. This helps in getting familiar with the support activities and also in defining a
detailed plan for transitioning the knowledge obtained and subsequently transferring the
knowledge obtained about the system to the entire maintenance team primarily at the offshore
centre. The infrastructure required to perform the support is also built during the stage and a
knowledge repository containing the details of the maintenance project is also built to capture
the entire information, learning, and mistakes committed during the execution of the project.
This helps in easy transitioning of resources down the project timelines. (92,93)

The steady state support involves resolving the service requests sent by the client, optimizing the
processes continuously over time. This involves measuring and analyzing the metrics to identify
the weaknesses in the process as well as the application being maintained and defining the
corrective measures to eradicate the weaknesses. Finally, offering the client value additions
identified and obtained over the maintenance period. This includes proactive root-cause analysis
of the recurring problems and the necessary measures for improvement. SLA-based
measurement also helps in tracking the performance strictly on a defined interval at every level.
(94)

The steady state requests can be classified based on the type of request or the level of support
and the size of the request. The requests can be of the following types:

FIRST LEVEL-Production support, SECOND LEVEL-Bugfix and THIRD LEVEL-


Enhancements

Similarly the bugfix and the enhancements are further classified into Minor, Major, and Super
major, based on their size.

Software maintenance sustains the software product throughout its operational life cycle.
Modification requests are logged and tracked, the impact of proposed changes is determined,
code and other software artifacts are modified, testing is conducted, and a new version of the
software product is released. It also includes training and daily support through: helpdesks that
are provided to users, or any documentation regarding the application. The enhancement bugfix
request, popularly called the EBR, primarily consists of the enhancement or bug description,
technical details, the proposed resolution for incorporating the request, and the results of testing
done after the change.

32
The set of activities performed for software maintenance in the steady state can be sequentially
classified into:

Modification request, Classification and Identification, Analysis, Design, Implementation of the


change in the necessary places, System Testing, Acceptance Testing, and Delivery.

Based on the size, type, and complexity of the request, one or more of these phases are
integrated or eliminated from the execution cycle.

The workflow shown here actually illustrates the functioning of the onsite and offshore team in a
typical maintenance scenario, describing the activities performed for the various levels and type
of support.

33
Here is a description of different measurement areas and the areas where improvement can be
identified over a period of time. (99)

Here, you will know the term service-level agreement and will see its importance in the
maintenance projects. A service-level agreement is a contractual service commitment that
describes the minimum performance criteria a provider promises to meet while delivering a
service. This is usually in measurable terms. It typically also sets out the remedial action and any
penalties that will take effect if performance falls below the promised standard. It is an essential
component of the legal contract between a service consumer and the provider. (100)

Finally, looking into the value additions offered to the client includes implementing an S L A-
based management, which keeps a constant eye on the health of the project and gives a measure
of the performances. This subsequently leads to the improvement in the areas of productivity,
schedule, and finally the cost involved. The root-cause analysis done at intervals helps in
identifying the pain areas of the application and hence focuses on correcting them.

34
You will now learn about some key issues and challenges faced during application maintenance.
The key issues that should be adeptly dealt with for maintaining the software effectively can be
classified as:

• Technical issues, which includes limited understanding, extent of testing possible, and
the maintainability or is it maintenance of code.

• Management issues that include staffing and process-related issues.

• Cost estimation that adapts the right methodology as parametric or judgmental.

• Measures with respect to Analysis, Changeability, Stability, and the Testability of the
software.
Here is an overview of eTracker. eTracker is a tool used for managing the maintenance projects
in Cognizant. It is a request management tool where individual requests can be planned and
tracked to closure. It also has features like automated metrics management, defect management,
and risk management. The tool represents the information stored in the form of various types of
reports and charts.

In this session, you have learned that:

 The maintenance process fundamentally includes correction of defects, adaptation to


modified environment, and incorporation of additional requirements. They are termed as
production support, enhancements, or bug fixes

 Maintenance can be categorized into proactive, reactive, correction, and enhancement.


The combination of these categories result in what are termed as Preventive
Maintenance, Perfective Maintenance, Corrective Maintenance, and Adaptive
Maintenance

 The three primary stages of maintenance include Planning for transition, Knowledge
transition, and Steady state

 The classification of requests is based on a combination of their size and type

 A service-level agreement is a contractual service commitment that describes the


minimum performance criteria a provider promises to meet while delivering a service.
This is usually in measurable terms

 The key issues that should be adeptly dealt with for maintaining the software effectively
can be classified as:
a) Technical issues, which include limited understanding, extent of testing possible, and
the maintainability of code
b) Management issues that include staffing and process-related issues
c) Cost Estimation that adapts the right methodology as parametric or judgmental
d) Measures with respect to Analysis, Changeability, Stability and the Testability of the
software
eTracker is used for tracking requests for a maintenance project
35
=====================================================================
===
LESSON 9: UMBRELLA ACTIVITIES

Any standard software process model would primarily consist of two types of activities: A set of
framework activities, which are always applicable, regardless of the project type, and a set of
umbrella activities, which are the non SDLC activities that span across the entire software
development life cycle.

At the end of this session, you will be able to:

 Define umbrella activities in a software life cycle

 Explain the usage and importance of the following umbrella activities:

a) Traceability Matrix-its definition, usage, and relevance in the SDLC

b) Peer Reviews, Forms of reviews, Planning and execution of peer reviews

Umbrella activities span all the stages of the SDLC. They are not specific to any particular life
cycle stage.

The umbrella activities in a software development life cycle process include the following:

1. Software Project Management


2. Formal Technical Reviews
3. Software Quality Assurance
4. Software Configuration Management
5. Re-usability Management
6. Risk Management
7. Measurement and Metrics
8. Document Preparation and Production
The following pages would focus on the requirement traceability matrix and formal technical
reviews.

Managing traceability is required to ensure the requirements are carried through properly to
design, development, and delivery. The following animation will show the pitfalls of poor
traceability.

Now, let us try to understand the concept of traceability and its importance in software
development. For example, in an organization, the activities are departmentalized on the basis of
the functionality to be served and employees are allocated to each department. A requirement
traceability can be defined as a method for tracing each requirement from its point of origin,
through each development phase and work product, to the delivered product. Thus, it helps in
indicating, for each work product, the requirements this work product satisfies.
36
When there is absence of traceability: The product gets compromised since the development
cannot be prioritized based on the order of criticality of the component, ultimately leading to
missed functionality in the delivered software. Project management is compromised due to the
lack of visibility of the components of the application being developed and their interconnections
causing a major hindrance to continuous planning. Testing is compromised as the coverage is not
verified at every stage of the life cycle. It becomes difficult to demonstrate that the product is
ready. Finally, maintenance becomes difficult as identification and analysis of the impacted
work products and requirements becomes tedious. This ultimately increases the complexity
during testing.

Some benefits are that its availability ensures correct implementation of requirements as
traceability gives a clear visibility of the interactions among the components within the system.
The forward and backward visibility into the system actually helps in estimating the tasks and
activities of the project with greater accuracy through a detailed impact analysis for the changes.
This leads to effective project management and planning. Since traceability provides a highly
visual view of the interrelationships between the various components, it can be used to identify
the requirements that have not been covered and hence analyze the gaps between them.
Traceability gives a complete idea about the dependencies and relationships of and between
components. For any change in requirement that is requested by the customer, it facilitates
impact analysis and simplifies the maintenance activities. Finally, traceability also helps to
ensure that all the work is against current requirements and that the requirements are completely
satisfied. (103)

The roles and responsibilities with respect to the traceability matrix are explained in this page.
Project manager ensures all required information is provided as needed, reviews the traceability
matrix for completeness. Requirement analyst updates requirements traceability matrix as
needed, support analysis as needed. Designer provides mapping of requirements to design
products. Developer provides mapping of requirements to development products. Tester
provides mapping of requirements to test products.

37
This page details the concept of Peer Review in software projects and identifies the importance
and need of Peer Reviews. In software development, Peer Review refers to a type of Software
Review in which a work product (any software deliverable, design, or document) is examined by
its author and/or one or more colleagues of the author, in order to evaluate its technical content
and quality. Management representatives should not be involved in conducting a peer review
except when included because of specific technical expertise, or when the work product under
review is a management-level document. Managers participating in a peer review should not be
line managers of any other participants in the review. (106)

Peer Review has to be planned at the start of the project where the PM or PL identifies the
artifacts to be reviewed and the Peer Reviewers. The Review schedule of the individual items to
be reviewed along with associated reviewer needs to be planned by the PL during the project
execution. The Peer Review needs to be conducted by the assigned Reviewers. The Review
comments need to be logged in a Review tool such as eTracker or Prolite. The developer needs
to incorporate the review comments.

In this session, you have learned that:

 Umbrella activities span all the stages of the SDLC

 The concept of umbrella activities focuses on Requirement Traceability Matrix

 Requirement traceability matrix is needed to be maintained by projects to ensure that the


requirements are adequately addressed

 Not maintaining a requirement traceability matrix results in problems including


unsatisfied requirements, problems during delivery and maintenance

 Software Peer Review needs to be planned, performed, and logged.

38
=====================================================================
===

LESSON 10: CONFIGURATION MANAGEMENT

Here, we are presenting the scenario on the day version 3.0 of Far Flung Personnel Planner to be
released.

We see here that the current problem that the far flung company was facing could be reverted if
they could roll back to the earlier release. They are unable to identify the changes incorporated in
the previous version and check whether all the changes suggested have been incorporated in the
latest version. There is no formal communication about the status of the changes either. (109)

At the end of this session, you will be able to:

 Learn what software configuration management is

 Study the important terminologies used in software configuration management

 Explain the tasks involved in software configuration management


FIRST LAW OF SYSTEM ENGINEERING:

Change management is a life cycle activity, not just a maintenance activity.

Change is inevitable and it can occur at any stage of software development.

Here, we will illustrate a few basic reasons why we encounter change in software application
development. If the business need is not clear to the customers, then the way it is communicated
often doesn't address the actual need which, at a later point of time, might result in a change.
Secondly, if there is a change in the operating environment in which the system functions.
Thirdly, a change might result from the errors committed due to other reasons during
requirement gathering, design, and the testing phase of the life cycle.

Since you now know the fact that change is inevitable in software application development, the
next basic question that arises is how are we going to manage these changes? To manage
changes in software application development, we use the discipline of software configuration
management, which operates throughout the life cycle of an application development.

Here is an illustration of configuration management. Configuration management is a discipline


that involves a set of activities that need to be performed to manage and control the changes that
arise during the software development life cycle. The discipline of configuration management is
applied across the life cycle of the project. SCM is that aspect of project management that
focuses exclusively on systematically controlling the changes that occur during the project by
using a defined process. SCM is a support activity that makes technical and managerial activities
more effective with the basic objectives of delivery of high-quality software product to the
client. It involves identifying and documenting the physical and functional characteristics and
managing the security and protection of a software artifact.

39
Now, here is an illustration of the basic questions a configuration management system helps us
to answer about any document or code that is created or used in software development or
maintenance. Typical questions that any SCM process should address are:

• What are the artifacts to be developed within the life cycle?


• What is the status of an item?
• How do I identify a work product uniquely, every time I make a change and how do I
record its effect on other items?
• How do I inform everyone else of the changes I have made to an existing document or
code?

Now it is essential to get familiarized with some of the commonly used terminologies in
configuration management and understand their significance in detail. Software Configurable
Item or an S C I, Baseline, Version Control, and Access Control. You will learn about these
terminologies in the following pages.
The most important concept of software configuration management is a software configurable
item or SCI. Software configurable items are the basic building blocks of any software product.
Changes to the software configurable items need to be managed in order to control change of the
software product. Here is an example of a house that relates to an SCI. The building plan, the
floor design, the doors, windows, and chimney of the completed house can be identified to be the
configurable items of a house. In case of a software application requirements document, the
design document, code, test strategy document, and the delivered application itself can be
considered to be examples of SCI.

A baseline is a specification or product that has been formally reviewed and agreed upon.
Examples of baselines are reviewed design document, approved project plans, and accepted
product. Baselines are well-defined points in the evolution of a software application. Hence, the
baselining criteria and the person responsible for meeting the criteria need to be defined prior to
planning configuration management. (111)

Using version control of a configurable item, we are able to identify multiple instances of the
same configurable item, uniquely. Assume that we have completed building a house using the
Base-lined project plan: House_Project_Plan_Version_1.0, and Base-lined Floor Design
Document: House_Floor_Design_Version_1.0. Now, there is a need to change the pattern of
windows of the house.

To change the window pattern of the house, we would need to re-plan the project and recreate
the floor design. The version number of the initial project plan is incremented by 1.0 and the new
plan is named: House_Project_Plan_Version_2.0. The floor design is also updated and the
version number of the initial floor plan is incremented by 1.0 and the new floor design is named:
House_Floor_Design_Version_2.0. Based on the new baselined configurable items
House_Project_Plan_Version_2.0 and House_Floor_Design_Version_2.0, an updated version of
the house is created. The following page will give you details on Access control.

Access control is used to maintain integrity of configurable items. Not all associates working in
a software company are allowed to access the documents pertaining to a particular project. Only
core members of a project are allowed to gain access to documents of a project. Again, within
the project, different user groups are defined and access rights are defined for each user group.
40
Separate work areas are defined for each team and access is controlled within each work area.
(112,113)

The first task for initiating the discipline of software configuration management, referred to as
SCM, is to create the configuration management plan. The next step is to form the SCM team as
per the roles identified in the SCM plan. The third step is to set up a library or project repository
structure as per the SCM plan. Along with this task, access rights of each team member to each
repository are also defined and implemented. Changes implemented in all items are then
implemented as per the methodology documented in the SCM plan. The status of items changed
is maintained by the SCM coordinator. All activities of SCM are subject to configuration audits
conducted by the quality reviewer.

The software configuration management plan documents the processes and methodologies that
will be used to manage change in the project. It also identifies the roles of the team members
who will be responsible for implementing change control in a project. (115)

The SCM plan identifies the names of the SCM team and the roles of each member, that is, the
names of the reviewers, approvers, SCM coordinator, and other team members who will be
responsible for implementing a change. (116)

Libraries or repositories are areas where a project stores and maintains the documents and
executables. This page illustrates the repository structure for version controlled items. The
development area contains all items documents that are in development while review or test area
contains items that are ready for testing. The baseline area contains all the approved items that

41
are ready for project use and deliverable to the next step or stage. Old items that are no longer in
use are stored in the archival area.

Here you will see how user access rights are defined for each of the area or repository and how
read or write access is controlled in a project. To maintain integrity of the work products, access
rights to each of the folders is defined.

A software project has both version controlled and non version controlled items. All the items
that will undergo changes throughout the life cycle are version controlled and called documents,
such as design document, code etc., There are many other items, which reflect the status at the
given point of time and that individual item will not undergo changes. Only a new instance will
be created. These are typically non-version controlled and called as records. Examples are Status
reports, review records.

This naming conventions of configurable items have been described here. The qualifier can be a
project or a module or a sub project name or any combination of them identified as appropriate
to a project.

42
To manage changes in a software configuration item, it is necessary to identify the multiple
instances of a configurable item uniquely. We use the concept of a naming convention and a
version number to identify a configurable item. After a configurable item is baselined, a version
number is given to the configurable item, generally starting at 1.0. As already described earlier, a
baselined configurable item is either reviewed or approved based on the criteria set for
baselining the item.

Here you can see how non-configurable items like quality records are named. The example is
that of a review sheet for a design document. In this case, a qualifier can be a project or a module
or a sub project name or any combination of them identified as appropriate to a project.

43
The naming convention of other non configurable items like status reports is illustrated here. In
this case, the qualifier can be a project or a module or a sub project name or any combination of
them identified as appropriate to a project.

Change control is a procedural activity that ensures quality and consistency as changes are made
to configurable items. Change control is the means by which changes are accepted into a project
in a controlled manner without causing great instability. Manages the process for initiating and
making changes to baselined software configurable items.

Status Accounting keeps track of changes made to Configurable Items and its current status by
maintaining a history and a continuous status over the period of time. The status can be WIP,
baselined, under review, or change etc. This helps in identifying the list of changes required, the
changes incorporated, and the changes pending. (125)

The quality reviewer or SCM coordinator of the project audits all activities pertaining to
configuration management. There are two types of audit that a quality reviewer performs,
functional configuration audit and physical configuration audit. Functional configuration audit
verifies that the system satisfies the specifications and this is typically verified by auditing the
traceability matrix. The traceability matrix traces each requirement through the design, code, and
test case, whereas the physical configuration audit verifies the typical SCM question of the status
accounting of all SCIs.

44
In this page, you will learn about the modes of configuration management. SCM can be either
tool-based or manual or a combination of the two. Manual management essentially involves
configuring a folder structure in a file server with controlled access rights for various areas.
Tool-based management covers automatic version control mechanism for both source code and
documents, and access control. Since the process is automatic, the chances of committing
manual errors are eliminated. Examples of SCM tools are: VSS, Clearcase, CVS, etc. SCM can
be performed as a combination of these two mechanisms.

Currently, VSS from Microsoft is most widely used across projects. We will learn the various
features of configuration management by using VSS as the source control tool. VSS allows
automatic version management eliminating the version naming conventions. Instead, it keeps a
history of the previous versions of the same file through frequent check-ins or check-outs. Apart
from that, the details of the check-ins and check-outs can be stored by labeling each version of

45
an item. The labeling can also be used for automatic build management of the software at
defined intervals by improving the tool using add-ins to VSS. VSS allows multiple degrees of
folder level access control mechanisms to a group or at individual level. Parallel development is
also possible through the usage of branching and merging of the main chain.

Here are the SCM best practices that are followed at Cognizant:

1. Addressing workflow and the responsibility for change


2. Conditions for initiating CRs (Eg- Rec Change, UI Stds Change, delay in sign-offs)

3. Highlighting and planning for controlling dependencies affecting the critical path or SLA
4. Handling signoff delays
5. Handling scope and responsibility change apart from the requirement change
6. A defined branching and merging strategy
7. Defining and enforcing the frequency of check-ins of development code
8. Addressing tagging or labeling frequency or nomenclature for the builds
SCM practices and other details followed at Cognizant can be accessed from Cognizant's quality
management system-the Qview. The demo will help you to reach out for necessary
documentation regarding the SCM practice at Cognizant. (129)

In this session, you have learned that:

 Software configuration management is a discipline used to manage and control change


across the project software development life cycle

 The terminologies used in SCM are:

 Software Configurable Item, These are the components of a product that are to be
controlled for managing change in a product. They are identified using naming
conventions and version numbering

 Baseline, Is the formally agreed upon project plan

 Version Control, Identifies multiple instances of the same configurable item, uniquely

 Access Control, Is used to maintain integrity of configurable items


 The software configuration management plan documents the processes and
methodologies that will be used to manage change in the project. It also identifies the
roles of the team members who will be responsible for implementing change control in a
project.

 The SCM plan includes Names of the SCM team members, Roles of each SCM team
member, Name and location of project libraries, User access right for project libraries,
Names of configurable items, Names of non version controlled items, Process for change
control, and Process for status accounting.

46
=====================================================================
===

LESSON 11: DEFECT MANAGEMENT

“Some maladies at their beginning are easy to cure but difficult to recognize. In course of time,
when they have not been at first recognized and treated, they become easy to recognize and
difficult to cure” (Niccolo Machiavelli). This necessitates defect prevention and defect detection
to be a part of the defect management process. This is true for software projects as much as
medical science.

At the end of this session, you will be able to:

 Study the defect-tracking mechanism and


 Learn about the defect prevention and causal analysis

A defect can be defined as a flaw in a system or system component that causes the system or
component to fail in performing its required function. A defect can be of two types: Process
defect and Product defect.
Prolite or eTracker needs to be used for tracking, reporting, and resolution purposes. Here, you
can see the diagram of the workflow for internal defect.

You will now learn what defect reporting involves. Defects are reported using Prolite, eTracker,
or other defect tracking tools. A defect report must include: Defect Id, Test case reference,
Defect description, Defect priority and severity, Tester name, and Test date and time. After the
defect is assigned to a developer and fixed, the final report will include the Defect fixer's name,
Date and time, and Defect fix verification. In the next page, you can see how defects are
classified.

Defects are classified in terms of severity. Severity is indicative of how severe the defect is. This
can be very high or critical, high, medium, or low. Priority is an indicator of how soon the defect
needs to be fixed and this can be high, medium, or low.

Now, you will learn how defects can be prevented. Every project prepares a defect-prevention
plan. Using the plan, the common/special causes of defects are sought, identified, prioritized and
systematically eliminated. Defect-prevention tasks include: analyzing defects encountered in the
past and taking specific actions to prevent the occurrence of the same in future.

This diagram depicts the defect-prevention flow. The causal analysis meetings are planned in the
defect-prevention plan. You will learn more about causal analysis in the next few pages.

47
48
Causal analysis primarily focuses on: fixing problems as they occur(before they happen), finding
what, in the process, has permitted the defect to occur, and finding what needs to be corrected to
prevent it from occurring again.

The outcome of the causal analysis meeting:

• Determines the root causes and special/common causes.

• Proposes action plans and draws up implementation plans.


Root causes for defects may occur during:

o Coding and testing stage because of lack of programming skills, insufficient adherence to
standards, lack of environment knowledge, lack of testing skills, and oversight of design
requirements.
o Implementation due to: Lack of implementation skills, and lack of availability of the
proper environment.
The responsibilities involved in managing a defect begin with:

 Creating a team to coordinate defect-prevention activities for the organization. This team
is either part of SQAG or its activities are closely coordinated with that group.

 Building a team to coordinate defect-prevention activities for the software project. This
team is closely tied to the team responsible for developing and maintaining the projects
with defined process. SEPG is such a team.

49
Here are the roles and responsibilities for defect management in a project:

 Follow defect-prevention checklist from database

 Adopt DP activities suggested in the kick-off meeting

 Collect defect data

 Conduct causal analysis

 Identify the special or common root causes for defects

 Identify action proposals for each root cause

 Identify the action proposals for preventing the special or common defects

 Review causal analysis and select action proposals to be addressed

 Implement the action items and track them to closure

 Review the success or failure of the past action items

 Entering the data in the repository

 Conduct phase-wise review of defect-prevention activities


Some of the defect prevention (statistical) techniques commonly used are Root-cause analysis,
Defect metrics analysis, and Defect prediction.(133)

In this session, you have learned that:

 A defect can be defined as a flaw in a system or system component that causes the
system or component to fail in performing its required function

 A defect can be of two types, namely, process defect and product defect

 Every project prepares a defect-prevention plan. Using the plan, the common causes of
defects are identified and eliminated

 The causal analysis meetings are planned in the defect prevention plan.

 The causal analysis focus on fixing problems as they occur, finding what, in the process,
has permitted the defect to occur, and finding what needs to be corrected to prevent it
from occurring again

 The outcome of the causal analysis meeting: Determines the root causes and common
causes, and proposes action plans and draws up implementation plans

50
*****************************************************************************
****

51