MODULE 2 SYLLABUS

Programming Style Guides and Coding Standards; Literate programming and

Softwaredocumentation; Documentation generators, Javadoc, phpDocumentor.

Version control systems basic concepts; Concept of Distributed version control

system and Git;Setting up Git; Core operations in Git version control system using
command line interface (CLI):Clone a repository; View history; Modifying files;
Branching; Push changes, Clone operation, add,commit, log, diff
commands,conflict resolution. Pushing changes to the master; Using Git in
IDEsand UI based tools.

Software Quality: Understanding and ensuring requirements specification quality,

design quality,quality in software development, conformance quality.

1
[PART 1] Programming Style Guides andCoding
Standards

• A programming style guide is an opinionated guide of programming conventions, style,and best

practices for a team or project.
• A team following a style guide helps everyone write code in a consistent way,and consistent
code is easier to read and faster to update.
• Consistent code is easier to read and understand making it faster to add new features.

Widely accepted style guides that you should consider to start with:
•Google’s Style Guides
•JavaScript Standard Style
•GitHub’s Ruby Style Guide
•Python Foundation’s Style Guide
•Airbnb’s JavaScript Style Guide
•Angular’s Style Guide

• Implementing one of these generally accepted style guides is a good start to helping your team
write code consistently.
• Make your style guide easy to reference.
• Style guide acts as a basic code blueprint for your team during all parts of the software
development lifecycle.
• To keep relevant, it should be often discussed. Such as during a developers onboarding, when
writing code, when writing tests, and during code review.

Literature Programming
• It is a methodology that combines a programming language with a documentation language,
thereby making programs more robust, more portable, more easily maintained, and arguably
more fun to write than programs that are written only in a high-level language.
• The main idea is to treat a program as a piece of literature, addressed to human beings rather
than to a computer.
• The program is also viewed as a hypertext document, rather like the World Wide Web.

2
Software documentation
• Software documentation is a part of any software. Appropriate details and description need to
be in the documented to achieve the following goals:
• Resolve issue encountered by the developer during the development process
• Help end-user to understand the product
• Assist customers and the support team to find the information.

Javadoc
• JavaDoc tool is a document generator tool in Java programming language for generating
standard documentation in HTML format.
• It generates API documentation.
• Before using JavaDoc tool, you must +include JavaDoc comments /**………………..*/
providing information about classes, methods, and constructors, etc.
• For creating a good and understandable document API for any java file you must write better
comments for every class, method, constructor.
• The JavaDoc comments is different from the normal comments because of the extra asterisk at
the beginning of the comment. It may contain the HTML tags as well.
// Single-Line Comment
/* Multiple-Line comment */
/** JavaDoc comment */
• By writing a number of comments, it does not affect the performance of the Java program as all
the comments are removed at compile time.

Generation of JavaDoc
To create a JavaDoc you do not need to compile the java file. To create the Java documentation
API, you need to write Javadoc followed by file name.
javadoc file_name or javadoc package_name
After successful execution of the above command, a number of HTML files will be created,
open the file named index to see all the information about classes.

(Table)

phpDocumentor
3
• phpDocumentor is an application that is capable of analyzing your PHP source code and
DocBlock comments to generate a complete set of API Documentation.phpDocumentor v3
(Stable)
• v3 is the latest stable release.
• The easiest way to run phpDocumentor is by running the following command:$ phpdoc run -d
<SOURCE_DIRECTORY> -t
<TARGET_DIRECTORY>

Coding Standards and Guidelines

Good software development organizations want their programmers to
maintain to some well-defined and standard style of coding called coding
standards. They usually make their own coding standards and guidelines
depending on what suits their organization best and based on the types of
software they develop. It is very important for the programmers to maintain
the coding standards otherwise the code will be rejected during code review.
Purpose of Having Coding Standards:
• A coding standard gives a uniform appearance to the codes written
by different engineers.
• It improves readability, and maintainability of the code and it reduces
complexity also.
• It helps in code reuse and helps to detect error easily.
• It promotes sound programming practices and increases efficiency of the
programmers.

S ome of the coding standards are given below:

• Limited use of globals:
These rules tell about which types of data that can be declared global
and the data that can’t be.
• Standard headers for different modules:
For better understanding and maintenance of the code, the header of different
modules should follow some standard format and information. The header
format must contain below things that is being used in various companies:
• Name of the module
• Date of module creation
• Author of the module
• Modification history
4
 • Synopsis of the module about what the module does
• Different functions supported in the module along with their input output
parameters
• Global variables accessed or modified by the module

• Naming conventions for local variables, global variables, constants and

functions:
Some of the naming conventions are given below:
• Meaningful and understandable variables name helps anyone to
understand the reason of using it.
• Local variables should be named using camel case lettering starting
with small letter (e.g. localData) whereas Global variables names
should start with a capital letter
(e.g. GlobalData). Constant names should be formed using
capital letters only (e.g. CONSDATA).
• It is better to avoid the use of digits in variable names.
• The names of the function should be written in camel case starting with
small letters.
• The name of the function must describe the reason of using the
function clearly and briefly.

• Indentation:
Proper indentation is very important to increase the readability of the code. For
making the

code readable, programmers should use White spaces properly. Some

of the spacing conventions are given below:
• There must be a space after giving a comma between two function
arguments.
• Each nested block should be properly indented and spaced.
• Proper Indentation should be there at the beginning and at the end of
each block in the program.
• All braces should start from a new line and the code following the end of
braces also start from a new line.
• Error return values and exception handling conventions:
All functions that encountering an error condition should either return a 0 or
1 for simplifying the debugging.

5
 On the other hand, Coding guidelines give some general suggestions
regarding the coding style that to be followed for the betterment of
understandability and readability of the code. Some of the coding
guidelines are given below :
• Avoid using a coding style that is too difficult to understand:
Code should be easily understandable. The complex code makes
maintenance and debugging difficult and expensive.

• Avoid using an identifier for multiple purposes:

Each variable should be given a descriptive and meaningful name indicating
the reason behind using it. This is not possible if an identifier is used for
multiple purposes and thus it can lead to confusion to the reader. Moreover, it
leads to more difficulty during future enhancements.
• Code should be well documented:
The code should be properly commented for understanding easily. Comments
regarding the statements increase the understandability of the code.
• Length of functions should not be very large:
Lengthy functions are very difficult to understand. That’s why functions
should be small enough to carry out small work and lengthy functions
should be broken into small ones for completing small tasks.
• Try not to use GOTO statement:
GOTO statement makes the program unstructured, thus it reduces the
understandability of the program and also debugging becomes difficult.

A dvantages of Coding Guidelines:

• Coding guidelines increase the efficiency of the software and reduces the
development time.
• Coding guidelines help in detecting errors in the early phases, so it helps
to reduce the extra cost incurred by the software project.
• If coding guidelines are maintained properly, then the software
code increases readability and understandability thus it reduces
the complexity of the code.
• It reduces the hidden cost for developing the software.

6
[PART2]GitVersionControlSystem
A version control system is a software that tracks changes to a file or set of
files over time so that you can recall specific versions later. It also allows you
to work together with other programmers.

The version control system is a collection of software tools that help a team to
manage changes in a source code. It uses a special kind of database to keep
track of every modification to the code.

Developers can compare earlier versions of the code with an older version to
fix the mistakes.

Benefits of the Version Control System

The Version Control System is very helpful and beneficial in software

development; developing software without using version control is unsafe. It
provides backups for uncertainty. Version control systems offer a speedy
interface to developers. It also allows software teams to preserve efficiency
and agility according to the team scales to include more developers.

Some key benefits of having a version control system are as follows.

• Complete change history of the file

• Simultaneously working
• Branching and merging
• Traceability

Types of Version Control System

• Localized version Control System

7
 • Centralized version control systems
• Distributed version control systems

Localized Version Control Systems

The localized version control method is a common approach because of its

simplicity. But this approach leads to a higher chance of error. In this
approach, you may forget which directory you're in and accidentally write to
the wrong file or copy over files you don't want to.

To deal with this issue, programmers developed local VCSs that had a
simple database. Such databases kept all the changes to files under revision
control. A local version control system keeps local copies of the files.

The major drawback of Local VCS is that it has a single point of failure.

Centralized Version Control System

The developers needed to collaborate with other developers on other systems.

The localized version control system failed in this case. To deal with this
problem, Centralized Version Control Systems were developed.

8
These systems have a single server that contains the versioned files, and some
clients to check out files from a central place.

Centralized version control systems have many benefits, especially over local
VCSs.

• Everyone on the system has information about the work what

others are doing on the project.
• Administrators have control over other developers.
• It is easier to deal with a centralized version control system than a
localized version control system.
• A local version control system facilitates with a server software
component which stores and manages the different versions of the
files.

It also has the same drawback as in local version control system that it also
has a single point of failure.

Distributed Version Control System

Centralized Version Control System uses a central server to store all the
database and team collaboration. But due to single point failure, which
9
means the failure of the central server, developers do not prefer it. Next, the
Distributed Version Control System is developed.

In a Distributed Version Control System (such as Git, Mercurial, Bazaar or

Darcs), the user has a local copy of a repository. So, the clients don't just
check out the latest snapshot of the files even they can fully mirror the
repository. The local repository contains all the files and metadata present in
the main repository.

DVCS allows automatic management branching and merging. It speeds up of

most operations except pushing and pulling. DVCS enhances the ability to
work offline and does not rely on a single location for backups. If any server
stops and other systems were collaborating via it, then any of the client
repositories could be restored by that server. Every checkout is a full backup
of all the data.

These systems do not necessarily depend on a central server to store

all the versions of a project file.

10
Difference between Centralized Version Control System and
Distributed Version Control System

Centralized Version Control Systems are systems that use client/server

architecture. In a centralized Version Control System, one or more client
systems are directly connected to a central server. Contrarily the
Distributed Version Control Systems are systems that use peer-to-peer
architecture.

There are many benefits and drawbacks of using both the version control
systems. Let's have a look at some significant differences between
Centralized and Distributed version control system.

Centralized Version Control System Distributed Version Control System

In CVCS, The repository is placed at one In DVCS, Every user has a local copy of
place and delivers information to many the repository in place of the central

clients. repository on the server-side.

11
It is based on the client-server approach. It is based on the client-server approach.

It is the most straightforward system It is flexible and has emerged with the
based on the concept of the central concept that everyone has their
repository. repository.

In DVCS, every user can check out the

In CVCS, the server provides the latest
code to all the clients across the globe. snapshot of the code, and they can fully
mirror the central repository.

CVCS is easy to administrate and has DVCS is fast comparing to CVCS as you
additional control over users and access don't have to interact with the central
by its server from one place. server for every command.

The popular tools of CVCS are SVN The popular tools of DVCS are Git and
(Subversion) and CVS. Mercurial.

CVCS is easy to understand for DVCS has some complex process for
beginners. beginners.

if any server fails and other systems were

If the server fails, No system can access
data from another system. collaborating via it, that server can
restore any of the client repositories

Git Basics

Git is the most popular and widely used version control system today.
Originally developed as an open source project in 2005 by the creator of the
Linux operating system, it is a matured and actively maintained environment.
A huge number of developers rely upon Git version controlling to develop
several types of commercial and non-commercial projects. Git-based
developers are well thought of and considered as valuable resources.

12
Git stores and thinks about information much differently than these other
systems, even though the user interface is fairly similar, and understanding
those differences will help prevent us from becoming confused while using it.

Git thinks of its data more like a set of snapshots of a miniature file system.
Every time you commit, or save the state of your project in Git, it basically
takes a picture of what all your files look like at that moment and stores a
reference to that snapshot. To be efficient, if files have not changed, Git doesn’t
store the file again, just a link to the previous identical file it has already stored.
Git thinks about its data more like a stream of snapshots.

What are the advantages of Git?

• Performance

Git performs very strongly and reliably when compared to other version control
systems. New code changes can be easily committed, version branches can be
effortlessly compared and merged, and code can also be optimized to perform
better. Algorithms used in developing Git take the full advantage of the deep
knowledge stored within, with regards to the attributes used to create real
source code file trees, how files are modified over time and what kind of file
access

13
patterns are used to recall code files as and when needed by developers. Git
primarily focuses upon the file content itself rather than file names while
determining the storage and file version history. Object formats of Git
repository files use several combinations of delta encoding and compression
techniques to store metadata objects and directory contents.

• Security

Git is designed specially to maintain the integrity of source code. File contents
as well as the relationship between file and directories, tags, commits, versions
etc. are secured cryptographically using an algorithm called SHA1 which
protects the code and change history against accidental as well as malicious
damage. You can be sure to have an authentic content history for your source
code with Git.

• Flexibility

A key design objective of Git is the kind of flexibility it offers to support

several kinds of nonlinear development workflows and its efficiency in
handling both small scale and large scale projects as well as protocols. It is
uniquely designed to support tagging and branching operations and store each
and every activity carried out by the user as an integral part of “change” history.
Not all VCSs support this feature.

• Wide acceptance

Git offers the type of performance, functionality, security, and flexibility that
most developers and teams need to develop their projects. When compared to

14
other VCS Git is the most widely accepted system owing to its universally
accepted usability and performance standards.

• Quality open source project

Git is a widely supported open source project with over ten years of operational
history. People maintaining the project are very well matured and possess a
long- term vision to meet the long-term needs of users by releasing staged
upgrades at regular intervals of time to improve functionality as well as
usability. Quality of open source software made available on Git is heavily
scrutinized a countless number of times and businesses today depend heavily
on Git code quality.

Why use Git in your organization?

If your business depends heavily upon it and software processes, or you’re a

software development entity, Git radically changes the way how your team will
create and deliver work to you. Various processes including designing,
development, product management, marketing, customer support can be easily
handled and maintained using Git in your organization.

• Feature Branch Workflow

15
Git has powerful branching capabilities. To start work, developers have to first
create a unique branch. Each branch functions in an isolated environment while
changes are carried out in the codebase. This ensures that the master branch
always

supports production-quality code. Therefore, besides being more reliable it’s

also much easier to edit code in a Git branch rather than editing it directly using
an external editor.

• Distributed Development

Since Git is a distributed VCS it offers a local repository to each developer with
its own history of commits. Therefore, you don’t require a network connection
to create commits, inspect previous file versions, or check differences between

16
two or more commits. Also, it’s much easier to scale the team. With Git, users
can be easily added or removed as and when required. Other team members
can continue working using their local repositories and are not dependent upon
whether a new branch is added or an older one closed.

• Pull Requests

A developer calls a pull request to ask another developer to merge one of

his/her branches into the other’s repository. Besides making it a lot easier for
project leaders to monitor and track code changes, “pulling” also facilitates
other developers to discuss their work before integrating the code with the
codebase. Moreover, if a developer can’t continue work owing to some hard
technical problem, he/she can initiate a pull request to seek help from the rest
of the team.

• Community

17
Git is very popular, widely used, and accepted as a standard version control
system by the vast majority within the developer’s community. It’s much easier
to leverage 3rd-party libraries and encourage other developers to fork your
open source code using Git. The sheer number of Git users make it easy to
resolve issues and seek outside help using online forums.

The Three States

Git has three main states that your files can reside in: committed, modified, and
staged. Committed means that the data is safely stored in your local database.
Modified means that you have changed the file but have not committed it to
your database yet. Staged means that you have marked a modified file in its
current version to go into your next commit snapshot. This leads us to the three
main sections of a Git project: the Git directory, the working directory, and the
staging area.

18
The Git directory is where Git stores the metadata and object database for our
project. This is the most important part of Git, and it is what is copied when we
clone a repository from another computer. The working directory is a single
checkout of one version of the project. These files are pulled out of the
compressed database in the Git directory and placed on disk for you to use or
modify. The staging area is a file, generally contained in your Git directory,
that stores information about what will go into your next commit. It’s
sometimes referred to as the “index”, but it’s also common to refer to it as the
staging area

The basic Git workflow

• We modify files in our working directory.

• We stage the files, adding snapshots of them to your staging area.

• We do a commit, which takes the files as they are in the staging area and
stores that snapshot permanently to our Git directory.

19
If a particular version of a file is in the Git directory, it’s considered committed.
If it has been modified and was added to the staging area, it is staged. And if it
was changed since it was checked out but has not been staged, it is modified.

Setting up of GIT

Get a github
account. Download
and install git.

Set up git with your user name and email.

• Open a terminal/shell and type:

• $ git config --global user.name "Your name here"
• $ git config --global user.email "[email protected]"

It comes with a tool called git config that lets us get and set configuration
variables that control all aspects of how Git looks and operates. These variables
can be stored in three different places:

• [path]/etc/gitconfig file: Contains values applied to every user on the

system and all their repositories. If you pass the option --system to git
config, it reads and writes from this file specifically. Because this is a
system configuration file, you would need administrative or super user
privilege to make changes to it.
• ~/.gitconfig or ~/.config/git/config file: Values specific personally to
you, the user. You can make Git read and write to this file specifically
by passing the --global option, and this affects all of the repositories you
work with on your system.
• config file in the Git directory (that is, .git/config) of whatever
repository you’re currently using: Specific to that single repository.

20
 You can force Git to read from and write to this file with the --local
option, but that is in fact the default. Unsurprisingly, you need to be
located somewhere in a Git repository for this option to work properly.

Each level overrides values in the previous level, so values in .git/config trump
those in [path]/etc/gitconfig.

On Windows systems, Git looks for the .gitconfig file in the $HOME directory
(C:\Users\$USER for most people). It also still looks for [path]/etc/gitconfig,
although it’s relative to the MSys root, which is wherever you decide to install
Git on your Windows system when you run the installer. If you are using
version 2.x or later of Git for Windows, there is also a system-level config file
at C:\Documents and Settings\All Users\Application Data\Git\config on
Windows

XP, and in C:\ProgramData\Git\config on Windows Vista and newer. This

config file can only be changed by git config -f <file> as an admin.

You can view all of your settings and where they are coming from using:

$ git config --list --show-origin

Our Identity

The first thing we should do when we install Git is to set your user name and
email address. This is important because every Git commit uses this
information, and it’s immutably baked into the commits you start creating:

$ git config --global user.name "John Doe"

$ git config --global user.email [email protected]

21
Again, we need to do this only once if you pass the --global option, because
then Git will always use that information for anything you do on that system.
If you want to override this with a different name or email address for specific
projects, you can run the command without the --global option when you’re in
that project.

Many of the GUI tools will help us do this when you first run them.

Checking Your Settings

Getting Help

These commands are good ,we can access them anywhere, even offline.

Your default branch name

By default Git will create a branch called master when you create a new
repository with git init. From Git version 2.28 onwards, you can set a different
name for the initial branch.

22
To set main as the default branch name do:

$ git config --global init.defaultBranch main

if you don’t need the full-blown manpage help, but just need a quick refresher
on the available options for a Git command, you can ask for the more concise
“help” output with the -h option, as in:

$ git add -h
usage: git add [<options>] [--] <pathspec>...

-n, --dry-run dry run

-v, --verbose be verbose

-i, --interactive interactive picking

-p, --patch select hunks interactively
-e, --edit edit current diff and apply
-f, --force allow adding otherwise ignored files
-u, --update update tracked files
--renormalize renormalize EOL of tracked files (implies -u)
-N, --intent-to-add record only the fact that the path will be added later
-A, --all add changes from all tracked and untracked files
--ignore-removal ignore paths removed in the working tree (same as --no-
all)
--refresh don't add, only refresh the index
--ignore-errors just skip files which cannot be added because of errors
--ignore-missing check if - even missing - files are ignored in dry run
--chmod (+|-)x override the executable bit of the listed files
23
Getting a Git Repository

You typically obtain a Git repository in one of two ways:

• You can take a local directory that is currently not under version
control, and turn it into a Git repository, or
• You can clone an existing Git repository from elsewhere.

In either case, you end up with a Git repository on your local machine, ready
for work.

Initializing a Repository in an Existing Directory

If you have a project directory that is currently not under version control and
you want to start controlling it with Git, you first need to go to that project’s
directory

for Linux:

$ cd

/home/user/my_projec

t for macOS:

$ cd

/Users/user/my_projec

t for Windows:

24
$ cd

C:/Users/user/my_projec

t and type:
$ git init

This creates a new subdirectory named .git that contains all of your necessary
repository files — a Git repository skeleton .Nothing in your project is tracked
yet.

Cloning an Existing Repository

To get a copy of an existing Git repository — for example, a project you’d

like to contribute to — the command needed is git clone

Git receives a full copy of nearly all data that the server has. Every version of
every file for the history of the project is pulled down by default when you run
git clone. In fact, if your server disk gets corrupted, you can often use nearly
any of

the clones on any client to set the server back to the state it was in when it was
cloned.

clone a repository with git clone <url>.

For example, if you want to clone the Git linkable library called libgit2, you
can do so like this:

$ git clone https://github.com/libgit2/libgit2

25
That creates a directory named libgit2, initializes a .git directory inside it, pulls
down all the data for that repository, and checks out a working copy of the
latest version. If you go into the new libgit2 directory that was just created,
you’ll see the project files in there, ready to be worked on or used.

If you want to clone the repository into a directory named something other than
libgit2, you can specify the new directory name as an additional argument:

$ git clone https://github.com/libgit2/libgit2 mylibgit

That command does the same thing as the previous one, but the target directory
is called mylibgit.

Git has a number of different transfer protocols you can use.

The previous example uses the https:// protocol, but you may also see git:// or
user@server:path/to/repo.git, which uses the SSH transfer protocol.

Recording Changes to the Repository

Each file in our working directory can be in one of two states: tracked or
untracked.

Tracked files are files that were in the last snapshot; they can be
unmodified, modified, or staged. - tracked files are files that Git knows
about.

Untracked files are everything else — any files in our working directory that
were not in our last snapshot and are not in our staging area. When you first

26
clone a repository, all of your files will be tracked and unmodified because
Git just
checked them out and you haven’t edited anything.

As you edit files, Git sees them as modified, because you’ve changed them
since your last commit. As you work, you selectively stage these modified
files and then commit all those staged changes, and the cycle repeats.

27
[PART 3] SOFTWARE QUALITY
What IS QUALITY?
• To say that a certain product is a quality product implies that the product is of good
quality
• On the other hand, people certainly use the term bad quality to express their
dissatisfaction with the products or services they use
• Therefore, the adjective good is implicitly attached to the word quality in the minds of
most people
• Thus, the word quality connotes good quality to most people, including technical
professionals
Before attempting a more elaborate definition of quality, let us consider the various
connotations the word invokes, as it means different things in different sections of society:
1) For a customer or end user of a product, quality connotes defect-free functioning, reliability,
ease of use
2) For a producer of goods, quality connotes conformance of the product to specifications
3) For a provider of services, quality connotes meeting deadlines and delivery of service that
conforms to customer specifications and standards
4) For government bodies, quality connotes safety and protection of consumers from fraud
5) For an industry association or standards body, quality connotes safeguarding the industry’s
reputation, protecting the industry from fraud

• The International Organization for Standardization (ISO 9000, second edition, 2000)
defines quality as the degree to which a set of inherent characteristics fulfills
requirements
• Quality can be used with such adjectives as poor, good, or excellent
• This definition contains three key terms: requirements, characteristics, and degree
• Requirements can be stated by a customer as product specifications
• Characteristics refers to the capability of the deliverable
• The word degree implies that quality is a continuum, beginning with zero and moving
toward, perhaps, infinity
• Quality is an attribute of a product or service provided to consumers that conforms the
best of the available specifications for that product or service
• It includes making those specifications available to the end user of the product or
service

28
 • The specifications that form the basis of the product or service provided may have been
defined by a government body, an industry association, or a standards body
• Where such a definition is not available, the provider may define the specifications
• The result of a product or service that meets the above definition of quality is that the
customer is able to effectively use the product for the length of its life or enjoy the
service fully
• This result further mandates that the provider is responsible for providing any support
that is required by the customer
• Any product or service that meets the requirements of this definition is rated a “quality
product/service”
• Any product or service that does not meet the requirements of this definition is rated
“poor quality”
• Reliability of a product is its capability

FOUR DIMENSIONS OF QUALITY

Quality has four dimensions

• Specification quality
• Design quality
• Development (software construction) quality
• Conformance quality
o Specifications are the starting point in the journey of providing a product or service,
followed by design and then development
o Conformance quality is ensuring how well that quality is built into the deliverable at
every stage

1 SPECIFICATION QUALITY
• Specification quality refers to how well the specifications are defined for the product or
service being provided

29
 • Specifications have no predecessor activity, and all other activities succeed
specifications
• Thus, if the specifications are weak, design will be weak, resulting in the development
and manufacture of an incorrect product, and the effort spent on ensuring that quality
is built in will have been wasted
Specifications normally should include the following six aspect:
1) Functionality aspects : Specify what functions are to be achieved by the product or service
2) Capacity aspects : Specify the load the product can carry (such as 250 passengers on a plane
or 100 concurrent users for a Web application)
3) Intended use aspects : Specify the need or needs the product or service satisfies
4) Reliability aspects : Specify how long the product can be enjoyed before it needs
maintenance
5) Safety aspects : Specify the threshold levels for ensuring safety to persons and property from
use of the product or service
6) Security aspects : Specify any threats for which the product or service needs to be prepared

Ensuring Quality in Specifications

• In the software industry, specifications are referred to as user requirements
• The following are possible scenarios for obtaining user requirements:
1) A business analyst conducts a feasibility study, writes up a report, and draws up the
user requirements. The analyst:
a) Meets with all the end users and notes their requirements and concerns
b) Meets with the function heads and notes their requirements and concerns
c) Meets with management personnel and notes their requirements and concerns
d) Consolidates the requirements and presents them to select end users, function
heads, and management personnel and receives their feedback, if any
e) Implements the feedback and finalizes specifications
2) A ready set of user requirements is presented as part of a request for proposal
3) A request for proposal points to a similar product and requests replication with
client-specific customization
• Regardless of the scenario, once the specifications are ready, quality assurance steps in
• The role of quality assurance in this area is to ensure that the specifications are
exhaustive and cover all areas
• Including functionality, capacity, reliability, safety, security, intended use, etc
• The tools for building quality into specifications are as follows:

30
 o Process documentation - Details the methodology for gathering, developing,
analyzing, and finalizing the specifications
o Standards and guidelines, formats, and templates - Specify the minimum set of
specifications that needs to be built in
o Checklists - Help analysts to ensure comprehensiveness of the specifications

2 DESIGN QUALITY
➢ Design quality refers to how well the product or service to be delivered is designed
➢ The objectives for design are to fulfill the specifications defined for the product or
service being provided
➢ Design determines the shape and strengths of the product or service
➢ Therefore, if the design is weak, the product or service will fail, even if the
specifications are very well defined
➢ Design can be split into two phases: conceptual design and engineering
➢ Conceptual design selects the approach to a solution from the multiple approaches
available
➢ Engineering uses the approach selected and works out the details to realize the solution
➢ Conceptual design is the creative part of the process, and engineering is the details
part
➢ In terms of software, conceptual design refers to software architecture, navigation,
number of tiers, approaches to flexibility, portability, maintainability, and so on
➢ Engineering design refers to database design, program specifications, screen design,
report design, etc.
➢ Software design normally contains the following elements:
1. Functionality design
2. Software architecture
3. Navigation
4. Database design
5. Development platform
6. Deployment platform
7. User interface design
8. Report design
9. Security
10. Fault tolerance
11. Capacity
12. Reliability
13. Maintainability
14. Efficiency and concurrence
15. Coupling and cohesion
16. Program specifications

31
 17. Test design
➢ It is normal to conduct a brainstorming session at the beginning of a software design
project, to select one optimum design alternative and to decide on the overall design
aspects
➢ Such as the number of tiers, technology platform, software coupling and cohesion, etc.
➢ A brainstorming session helps designers arrive at the best possible solution for the
project at hand
➢ Normally, software design is a two-step process

Ensuring Quality in Design

➢ Normally, software design is a two-step process:
o Conceptual design - Referred to as high-level design, functional design
specification, software requirements specification, and software architecture
design
o Engineering design - Referred to as low-level design, detailed design
specification, software design description, and software program design
➢ The tools for building quality into design include the following:
o Process documentation - Details the methodology for design alternatives to be
considered, criteria for selecting the alternative for the project, and finalizing the
conceptual design
o Standards and guidelines, formats, and templates - Specify the possible
software architectures along with their attendant advantages and disadvantages
and so on
o Checklists - Help designers to ensure that design is carried out comprehensively
and appropriately

2 DEVELOPMENT(Software Construction) QUALITY

The following activities form part of developing software:
➢ Create the database and table structures
➢ Develop dynamically linked libraries for common routines Develop screens
➢ Develop reports
➢ Develop unit test plans
➢ Develop associated process routines for all other aspects, such as security, efficiency,
fault tolerance, etc.
❖ Good-quality construction is achieved by adhering to the coding guidelines of the
programming language being used
❖ Normally there is a separate coding guideline for every programming language used in an
organization

32
❖ Coding guidelines contain naming conventions, code formatting that help developers write
reliable and defect-free code
❖ Of course, it is very important to have qualified people trained in software development
❖ Construction follows software design, and it should always conform to the design document
❖ In this way, good quality in construction can be achieved

Ensuring Quality In Development(Software Construction)

➢ Quality is built in by adhering to the organizational standards for code quality as well as
the coding guidelines for the development language being used
➢ Uncontrolled changes can wreak havoc with code quality
➢ Therefore, change management and configuration management assume importance for
ensuring code quality
➢ There are two techniques to ensure that quality is built into a product:
o Reviews (walkthroughs)
o Testing

2 CONFORMANCE QUALITY
➢ Conformance quality deals with how well an organization ensures that quality is built
into a product through the above three dimensions
➢ It is one thing to do a quality job
➢ But it is quite another to unearth any defects lurking in the work product and ensure
that a good-quality product is indeed built
➢ Essentially, conformance quality examines how well quality control is carried out in the
organization

Ensuring conformance Quality

➢ Ensuring that conformance quality is at desirable levels in the organization is achieved
through :
❖ Audits
❖ Quality measurements
❖ Metrics
❖ Benchmarking
➢ Defect removal efficiency of verification and validation activities, defect injection rate,
and defect density are all used for this purpose
➢ Audits also are conducted to ensure that projects conform to various applicable
standards for building quality into all activities, including specifications and design
➢ In addition, organizational data is benchmarked against industry benchmarks, and
corrective or preventive actions are taken to ensure that organizational conformance is
indeed on a par with the industry

33
 ➢ Conformance quality is built in through process definition and continuous improvement
for all software development activities as well as quality assurance

----------------------------------------------------------------------------------------------------------------------------------------

34