Unit-1

Definitions: software engineering:

IEEE defines software engineering as:

(1) The application of a systematic, disciplined, quantifiable approach to the
development, operation and maintenance of software; that is, the application of
engineering to software.
(2) The study of approaches as in the above statement.
Fritz Bauer, a German computer scientist, defines software engineering as:
Software engineering is the establishment and use of sound engineering
principles in order to obtain economically software that is reliable and work
efficiently on real machines.

Sofware myths:
Myth 1 : Testing is Too Expensive
Reality : There is a saying, pay less for testing during software development or pay
more for maintenance or correction later. Early testing saves both time and cost in
many aspects, however reducing the cost without testing may result in improper design
of a software application rendering the product useless.
Myth 2 : Testing is Time-Consuming
Reality : During the SDLC phases, testing is never a time-consuming process.
However diagnosing and fixing the errors identified during proper testing is a time-
consuming but productive activity.
Myth 3 : Only Fully Developed Products are Tested
Reality : No doubt, testing depends on the source code but reviewing requirements
and developing test cases is independent from the developed code. However iterative
or incremental approach as a development life cycle model may reduce the
dependency of testing on the fully developed software.
Myth 4 : Complete Testing is Possible
Reality : It becomes an issue when a client or tester thinks that complete testing is
possible. It is possible that all paths have been tested by the team but occurrence of
complete testing is never possible. There might be some scenarios that are never
executed by the test team or the client during the software development life cycle and
may be executed once the project has been deployed.
 Myth 5 : A Tested Software is Bug-Free

Reality : This is a very common myth that the clients, project managers, and the
management team believes in. No one can claim with absolute certainty that a
software application is 100% bug-free even if a tester with superb testing skills has
tested the application.

Myth 6 : Missed Defects are due to Testers

Reality : It is not a correct approach to blame testers for bugs that remain in the
application even after testing has been performed. This myth relates to Time, Cost, and
Requirements changing Constraints. However the test strategy may also result in bugs
being missed by the testing team.
Myth 7 : Testers are Responsible for Quality of Product
Reality : It is a very common misinterpretation that only testers or the testing team
should be responsible for product quality. Testers responsibilities include the
identification of bugs to the stakeholders and then it is their decision whether they will
fix the bug or release the software. Releasing the software at the time puts more
pressure on the testers, as they will be blamed for any error.
Myth 8 : Test Automation should be used wherever possible to Reduce Time
Reality : Yes, it is true that Test Automation reduces the testing time, but it is not
possible to start test automation at any time during software development. Test
automaton should be started when the software has been manually tested and is stable
to some extent. Moreover, test automation can never be used if requirements keep
changing.
Myth 9 : Anyone can Test a Software Application
Reality : People outside the IT industry think and even believe that anyone can test a
software and testing is not a creative job. However testers know very well that this is a
myth. Thinking alternative scenarios, try to crash a software with the intent to explore
potential bugs is not possible for the person who developed it.
Myth 10 : A Tester's only Task is to Find Bugs
Reality : Finding bugs in a software is the task of the testers, but at the same time,
they are domain experts of the particular software. Developers are only responsible for
the specific component or area that is assigned to them but testers understand the
overall workings of the software, what the dependencies are, and the impacts of one
module on another module
 Software Process Model:
Waterfall Model
Waterfall model is the simplest model of software development paradigm. It says the
all the phases of SDLC will function one after another in linear manner. That is, when
the first phase is finished then only the second phase will start and so on.

This model assumes that everything is carried out and taken place perfectly as planned
in the previous stage and there is no need to think about the past issues that may arise
in the next phase. This model does not work smoothly if there are some issues left at
the previous step. The sequential nature of model does not allow us go back and undo
or redo our actions.
This model is best suited when developers already have designed and developed
similar software in the past and are aware of all its domains.
 Iterative Model
This model leads the software development process in iterations. It projects the
process of development in cyclic manner repeating every step after every cycle of
SDLC process.

The software is first developed on very small scale and all the steps are followed
which are taken into consideration. Then, on every next iteration, more features and
modules are designed, coded, tested and added to the software. Every cycle produces a
software, which is complete in itself and has more features and capabilities than that of
the previous one.
After each iteration, the management team can do work on risk management and
prepare for the next iteration. Because a cycle includes small portion of whole
software process, it is easier to manage the development process but it consumes more
resources.
 Spiral Model
Spiral model is a combination of both, iterative model and one of the SDLC model. It
can be seen as if you choose one SDLC model and combine it with cyclic process
(iterative model).

This model considers risk, which often goes un-noticed by most other models. The
model starts with determining objectives and constraints of the software at the start of
one iteration. Next phase is of prototyping the software. This includes risk analysis.
Then one standard SDLC model is used to build the software. In the fourth phase of
the plan of next iteration is prepared.
 V model
The major drawback of waterfall model is we move to the next stage only when the
previous one is finished and there was no chance to go back if something is found
wrong in later stages. V-Model provides means of testing of software at each stage in
reverse manner.

At every stage, test plans and test cases are created to verify and validate the product
according to the requirement of that stage. For example, in requirement gathering
stage the test team prepares all the test cases in correspondence to the requirements.
Later, when the product is developed and is ready for testing, test cases of this stage
verify the software against its validity towards requirements at this stage
This makes both verification and validation go in parallel. This model is also known as
verification and validation model.
 Big Bang Model
This model is the simplest model in its form. It requires little planning, lots of
programming and lots of funds. This model is conceptualized around the big bang of
universe. As scientists say that after big bang lots of galaxies, planets and stars evolved
just as an event. Likewise, if we put together lots of programming and funds, you may
achieve the best software product.

For this model, very small amount of planning is required. It does not follow any
process, or at times the customer is not sure about the requirements and future needs.
So the input requirements are arbitrary.
This model is not suitable for large software projects but good one for learning and
experimenting.
Process activities:
Real software processes are inter-leaved sequences of technical,
collaborative and managerial activities with the overall goal of specifying,
designing, implementing and testing a software system.
The four basic process activities of specification, development, validation
and evolution are organized differently in different development processes.
In the waterfall model, they are organized in sequence, whereas in
incremental development they are inter-leaved.
Software specification
 The process of establishing what services are required and the constraints
on the systems operation and development.
Requirements engineering process
Feasibility study
Is it technically and financially feasible to build the system?
Requirements elicitation and analysis
What do the system stakeholders require or expect from the
system?
Requirements specification
Defining the requirements in detail
Requirements validation
Checking the validity of the requirements
The requirements engineering process

CASE Tools
CASE stands for Computer Aided Software Engineering. It means, development and
maintenance of software projects with help of various automated software tools.
 CASE Tools
CASE tools are set of software application programs, which are used to automate
SDLC activities. CASE tools are used by software project managers, analysts and
engineers to develop software system.
There are number of CASE tools available to simplify various stages of Software
Development Life Cycle such as Analysis tools, Design tools, Project management
tools, Database Management tools, Documentation tools are to name a few.
Use of CASE tools accelerates the development of project to produce desired result
and helps to uncover flaws before moving ahead with next stage in software
development.
Components of CASE Tools
CASE tools can be broadly divided into the following parts based on their use at a
particular SDLC stage:
Central Repository - CASE tools require a central repository, which can
serve as a source of common, integrated and consistent information. Central
repository is a central place of storage where product specifications,
requirement documents, related reports and diagrams, other useful
information regarding management is stored. Central repository also serves as
data dictionary.

Upper Case Tools - Upper CASE tools are used in planning, analysis and
design stages of SDLC.
Lower Case Tools - Lower CASE tools are used in implementation, testing
and maintenance.
Integrated Case Tools - Integrated CASE tools are helpful in all the stages of
SDLC, from Requirement gathering to Testing and documentation.
CASE tools can be grouped together if they have similar functionality, process
activities and capability of getting integrated with other tools.
Scope of Case Tools
The scope of CASE tools goes throughout the SDLC.
Case Tools Types
Now we briefly go through various CASE tools
Diagram tools
These tools are used to represent system components, data and control flow among
various software components and system structure in a graphical form. For example,
Flow Chart Maker tool for creating state-of-the-art flowcharts.
Process Modeling Tools
Process modeling is method to create software process model, which is used to
develop the software. Process modeling tools help the managers to choose a process
model or modify it as per the requirement of software product. For example, EPF
Composer
Project Management Tools
These tools are used for project planning, cost and effort estimation, project
scheduling and resource planning. Managers have to strictly comply project execution
with every mentioned step in software project management. Project management tools
help in storing and sharing project information in real-time throughout the
organization. For example, Creative Pro Office, Trac Project, Basecamp.
Documentation Tools
Documentation in a software project starts prior to the software process, goes
throughout all phases of SDLC and after the completion of the project.
Documentation tools generate documents for technical users and end users. Technical
users are mostly in-house professionals of the development team who refer to system
manual, reference manual, training manual, installation manuals etc. The end user
documents describe the functioning and how-to of the system such as user manual. For
example, Doxygen, DrExplain, Adobe RoboHelp for documentation.
Analysis Tools
These tools help to gather requirements, automatically check for any inconsistency,
inaccuracy in the diagrams, data redundancies or erroneous omissions. For example,
Accept 360, Accompa, CaseComplete for requirement analysis, Visible Analyst for
total analysis.
Design Tools
These tools help software designers to design the block structure of the software,
which may further be broken down in smaller modules using refinement techniques.
These tools provides detailing of each module and interconnections among modules.
For example, Animated Software Design

Configuration Management Tools

An instance of software is released under one version. Configuration Management
tools deal with

Version and revision management

Baseline configuration management

Change control management

CASE tools help in this by automatic tracking, version management and release
management. For example, Fossil, Git, Accu REV.
Change Control Tools
These tools are considered as a part of configuration management tools. They deal
with changes made to the software after its baseline is fixed or when the software is
first released. CASE tools automate change tracking, file management, code
management and more. It also helps in enforcing change policy of the organization.
Programming Tools
These tools consist of programming environments like IDE (Integrated Development
Environment), in-built modules library and simulation tools. These tools provide
comprehensive aid in building software product and include features for simulation
and testing. For example, Cscope to search code in C, Eclipse.
Prototyping Tools
Software prototype is simulated version of the intended software product. Prototype
provides initial look and feel of the product and simulates few aspect of actual product.
Prototyping CASE tools essentially come with graphical libraries. They can create
hardware independent user interfaces and design. These tools help us to build rapid
prototypes based on existing information. In addition, they provide simulation of
software prototype. For example, Serena prototype composer, Mockup Builder.
Web Development Tools
These tools assist in designing web pages with all allied elements like forms, text,
script, graphic and so on. Web tools also provide live preview of what is being
developed and how will it look after completion. For example, Fontello, Adobe Edge
Inspect, Foundation 3, Brackets.
Quality Assurance Tools
Quality assurance in a software organization is monitoring the engineering process
and methods adopted to develop the software product in order to ensure
conformance of quality as per organization standards. QA tools consist of
configuration and change control tools and software testing tools. For example,
SoapTest, AppsWatch, JMeter.
Maintenance Tools
Software maintenance includes modifications in the software product after it is
delivered. Automatic logging and error reporting techniques, automatic error ticket
generation and root cause Analysis are few CASE tools, which help software
organization in maintenance phase of SDLC. For example, Bugzilla for defect
tracking, HP Quality Center.

Software Project
A Software Project is the complete procedure of software development from
requirement gathering to testing and maintenance, carried out according to the
execution methodologies, in a specified period of time to achieve intended software
product.
Need of software project management
Software is said to be an intangible product. Software development is a kind of all new
stream in world business and theres very little experience in building software
products. Most software products are tailor made to fit clients requirements. The most
important is that the underlying technology changes and advances so frequently and
rapidly that experience of one product may not be applied to the other one. All such
business and environmental constraints bring risk in software development hence it is
essential to manage software projects efficiently.
The image above shows triple constraints for software projects. It is an essential part
of software organization to deliver quality product, keeping the cost within clients
budget constrain and deliver the project as per scheduled. There are several factors,
both internal and external, which may impact this triple constrain triangle. Any of
three factor can severely impact the other two.
Therefore, software project management is essential to incorporate user requirements
along with budget and time constraints.
Software Project Manager
A software project manager is a person who undertakes the responsibility of executing
the software project. Software project manager is thoroughly aware of all the phases of
SDLC that the software would go through. Project manager may never directly involve
in producing the end product but he controls and manages the activities involved in
production.
A project manager closely monitors the development process, prepares and executes
various plans, arranges necessary and adequate resources, maintains communication
among all team members in order to address issues of cost, budget, resources, time,
quality and customer satisfaction.
Let us see few responsibilities that a project manager shoulders -
Managing People

Act as project leader

Lesion with stakeholders

Managing human resources

Setting up reporting hierarchy etc.

Managing Project
 Defining and setting up project scope

Managing project management activities

Monitoring progress and performance

Risk analysis at every phase

Take necessary step to avoid or come out of problems

Act as project spokesperson

Software Project Management

Management Activities
Software project management comprises of a number of activities, which contains
planning of project, deciding scope of software product, estimation of cost in various
terms, scheduling of tasks and events, and resource management. Project management
activities may include:

Project Planning

Scope Management

Project Estimation
Project Planning
Software project planning is task, which is performed before the production of
software actually starts. It is there for the software production but involves no concrete
activity that has any direction connection with software production; rather it is a set of
multiple processes, which facilitates software production. Project planning may
include the following:
Scope Management
It defines the scope of project; this includes all the activities, process need to be done
in order to make a deliverable software product. Scope management is essential
because it creates boundaries of the project by clearly defining what would be done in
the project and what would not be done. This makes project to contain limited and
quantifiable tasks, which can easily be documented and in turn avoids cost and time
overrun.
During Project Scope management, it is necessary to -
 Define the scope

Decide its verification and control

Divide the project into various smaller parts for ease of management.

Verify the scope

Control the scope by incorporating changes to the scope

Project Estimation
For an effective management accurate estimation of various measures is a must. With
correct estimation managers can manage and control the project more efficiently and
effectively.
Project estimation may involve the following:

Software size estimation

Software size may be estimated either in terms of KLOC (Kilo Line of Code) or
by calculating number of function points in the software. Lines of code depend
upon coding practices and Function points vary according to the user or software
requirement.

Effort estimation
The managers estimate efforts in terms of personnel requirement and man-hour
required to produce the software. For effort estimation software size should be
known. This can either be derived by managers experience, organizations
historical data or software size can be converted into efforts by using some
standard formulae.

Time estimation
Once size and efforts are estimated, the time required to produce the software
can be estimated. Efforts required is segregated into sub categories as per the
requirement specifications and interdependency of various components of
software. Software tasks are divided into smaller tasks, activities or events by
Work Breakthrough Structure (WBS). The tasks are scheduled on day-to-day
basis or in calendar months.
The sum of time required to complete all tasks in hours or days is the total time
invested to complete the project.

Cost estimation
 This might be considered as the most difficult of all because it depends on more
elements than any of the previous ones. For estimating project cost, it is required
to consider -

o Size of software

o Software quality

o Hardware

o Additional software or tools, licenses etc.

o Skilled personnel with task-specific skills

o Travel involved

o Communication

o Training and support

Project Scheduling
Project Scheduling in a project refers to roadmap of all activities to be done with
specified order and within time slot allotted to each activity. Project managers tend to
tend to define various tasks, and project milestones and them arrange them keeping
various factors in mind. They look for tasks lie in critical path in the schedule, which
are necessary to complete in specific manner (because of task interdependency) and
strictly within the time allocated. Arrangement of tasks which lies out of critical path
are less likely to impact over all schedule of the project.
For scheduling a project, it is necessary to -

Break down the project tasks into smaller, manageable form

Find out various tasks and correlate them

Estimate time frame required for each task

Divide time into work-units

Assign adequate number of work-units for each task

Calculate total time required for the project from start to finish
 Risk Management Process
There are following activities involved in risk management process:

Identification - Make note of all possible risks, which may occur in the
project.

Categorize - Categorize known risks into high, medium and low risk
intensity as per their possible impact on the project.

Manage - Analyze the probability of occurrence of risks at various phases.

Make plan to avoid or face risks. Attempt to minimize their side-effects.

Monitor - Closely monitor the potential risks and their early symptoms.
Also monitor the effects of steps taken to mitigate or avoid them.

Project Execution & Monitoring

In this phase, the tasks described in project plans are executed according to their
schedules.
Execution needs monitoring in order to check whether everything is going according
to the plan. Monitoring is observing to check the probability of risk and taking
measures to address the risk or report the status of various tasks.
These measures include -

Activity Monitoring - All activities scheduled within some task can be

monitored on day-to-day basis. When all activities in a task are completed, it
is considered as complete.

Status Reports - The reports contain status of activities and tasks

completed within a given time frame, generally a week. Status can be marked
as finished, pending or work-in-progress etc.

Milestones Checklist - Every project is divided into multiple phases

where major tasks are performed (milestones) based on the phases of SDLC.
This milestone checklist is prepared once every few weeks and reports the
status of milestones.

Project Management Tools

The risk and uncertainty rises multifold with respect to the size of the project, even
when the project is developed according to set methodologies.
There are tools available, which aid for effective project management. A few are
described -
Gantt Chart
Gantt charts was devised by Henry Gantt (1917). It represents project schedule with
respect to time periods. It is a horizontal bar chart with bars representing activities and
time scheduled for the project activities.

PERT Chart
PERT (Program Evaluation & Review Technique) chart is a tool that depicts project as
network diagram. It is capable of graphically representing main events of project in
both parallel and consecutive way. Events, which occur one after another, show
dependency of the later event over the previous one.

Events are shown as numbered nodes. They are connected by labeled arrows depicting
sequence of tasks in the project.
Resource Histogram
This is a graphical tool that contains bar or chart representing number of resources
(usually skilled staff) required over time for a project event (or phase). Resource
Histogram is an effective tool for staff planning and coordination.
 Critical Path Analysis
This tools is useful in recognizing interdependent tasks in the project. It also helps to
find out the shortest path or critical path to complete the project successfully. Like
PERT diagram, each event is allotted a specific time frame. This tool shows
dependency of event assuming an event can proceed to next only if the previous one is
completed.
The events are arranged according to their earliest possible start time. Path between
start and end node is critical path which cannot be further reduced and all events
require to be executed in same order.
Project Planning:
The key to a successful project is in the planning. Creating a project plan is the
first thing you should do when undertaking any kind of project.

Often project planning is ignored in favour of getting on with the work.

However, many people fail to realise the value of a project plan in saving time,
money and many problems.
This article looks at a simple, practical approach to project planning. On
completion of this guide, you should have a sound project planning approach
that you can use for future projects.

Step 1: Project Goals

A project is successful when the needs of the stakeholders have been met. A
stakeholder is anybody directly, or indirectly impacted by the project.

As a first step, it is important to identify the stakeholders in your project. It is

not always easy to identify the stakeholders of a project, particularly those
impacted indirectly. Examples of stakeholders are:

The project sponsor.

The customer who receives the deliverables.

The users of the project outputs.

The project manager and project team.

Once you understand who the stakeholders are, the next step is to find out their
needs. The best way to do this is by conducting stakeholder interviews. Take
time during the interviews to draw out the true needs that create real benefits.
Often stakeholders will talk about needs that aren't relevant and don't deliver
benefits. These can be recorded and set as a low priority.

The next step, once you have conducted all the interviews, and have a
comprehensive list of needs is to prioritise them. From the prioritised list, create
a set of goals that can be easily measured. A technique for doing this is to review
them against the SMART principle. This way it will be easy to know when a
goal has been achieved.

Once you have established a clear set of goals, they should be recorded in the
project plan. It can be useful to also include the needs and expectations of your
stakeholders.

This is the most difficult part of the planning process completed. It's time to
move on and look at the project deliverables.

Step 2: Project Deliverables

Using the goals you have defined in step 1, create a list of things the project
needs to deliver in order to meet those goals. Specify when and how each item
must be delivered.

Add the deliverables to the project plan with an estimated delivery date. More
accurate delivery dates will be established during the scheduling phase, which is
next.

Step 3: Project Schedule

Create a list of tasks that need to be carried out for each deliverable identified in
step 2. For each task identify the following:

The amount of effort (hours or days) required to complete the task.

The resource who will carryout the task.

Once you have established the amount of effort for each task, you can workout
the effort required for each deliverable, and an accurate delivery date. Update
your deliverables section with the more accurate delivery dates.

At this point in the planning, you could choose to use a software package such
as Microsoft Project to create your project schedule. Alternatively, use one of
the many free templates available. Input all of the deliverables, tasks, durations
and the resources who will complete each task.

A common problem discovered at this point, is when a project has an imposed

delivery deadline from the sponsor that is not realistic based on your estimates.
If you discover this is the case, you must contact the sponsor immediately. The
options you have in this situation are:

Renegotiate the deadline (project delay).

Employ additional resources (increased cost).

Reduce the scope of the project (less delivered).

Use the project schedule to justify pursuing one of these options.

Step 4: Supporting Plans

This section deals with plans you should create as part of the planning process.
These can be included directly in the plan.

Human Resource Plan

Identify by name, the individuals and organisations with a leading role in the
project. For each, describe their roles and responsibilities on the project.

Next, describe the number and type of people needed to carryout the project. For
each resource detail start dates, estimated duration and the method you will use
for obtaining them.

Create a single sheet containing this information.

Communications Plan

Create a document showing who needs to be kept informed about the project
and how they will receive the information. The most common mechanism is a
weekly or monthly progress report, describing how the project is performing,
milestones achieved and work planned for the next period.

Risk Management Plan

Risk management is an important part of project management. Although often

overlooked, it is important to identify as many risks to your project as possible,
and be prepared if something bad happens.

Here are some examples of common project risks:

Time and cost estimates too optimistic.

Customer review and feedback cycle too slow.

Unexpected budget cuts.

Unclear roles and responsibilities.

Stakeholder input is not sought, or their needs are not properly understood.

Stakeholders changing requirements after the project has started.

Stakeholders adding new requirements after the project has started.

Poor communication resulting in misunderstandings, quality problems and

rework.

Lack of resource commitment.

Risks can be tracked using a simple risk log. Add each risk you have identified
to your risk log; write down what you will do in the event it occurs, and what
you will do to prevent it from occurring. Review your risk log on a regular
basis, adding new risks as they occur during the life of the project. Remember,
when risks are ignored they don't go away.
 Unit-2
Requirement Engineering
The process to gather the software requirements from client, analyze and document
them is known as requirement engineering.
The goal of requirement engineering is to develop and maintain sophisticated and
descriptive System Requirements Specification document.
Requirement Engineering Process
It is a four step process, which includes

Feasibility Study

Requirement Gathering

Software Requirement Specification

Software Requirement Validation

Let us see the process briefly -
Feasibility study
When the client approaches the organization for getting the desired product developed,
it comes up with rough idea about what all functions the software must perform and
which all features are expected from the software.
Referencing to this information, the analysts does a detailed study about whether the
desired system and its functionality are feasible to develop.
This feasibility study is focused towards goal of the organization. This study analyzes
whether the software product can be practically materialized in terms of
implementation, contribution of project to organization, cost constraints and as per
values and objectives of the organization. It explores technical aspects of the project
and product such as usability, maintainability, productivity and integration ability.
The output of this phase should be a feasibility study report that should contain
adequate comments and recommendations for management about whether or not the
project should be undertaken.
Requirement Gathering
If the feasibility report is positive towards undertaking the project, next phase starts
with gathering requirements from the user. Analysts and engineers communicate with
the client and end-users to know their ideas on what the software should provide and
which features they want the software to include.
 Software Requirement Specification
SRS is a document created by system analyst after the requirements are collected from
various stakeholders.
SRS defines how the intended software will interact with hardware, external
interfaces, speed of operation, response time of system, portability of software across
various platforms, maintainability, speed of recovery after crashing, Security, Quality,
Limitations etc.
The requirements received from client are written in natural language. It is the
responsibility of system analyst to document the requirements in technical language so
that they can be comprehended and useful by the software development team.
SRS should come up with following features:

User Requirements are expressed in natural language.

Technical requirements are expressed in structured language, which is used

inside the organization.

Design description should be written in Pseudo code.

Format of Forms and GUI screen prints.

Conditional and mathematical notations for DFDs etc.

Software Requirement Validation
After requirement specifications are developed, the requirements mentioned in this
document are validated. User might ask for illegal, impractical solution or experts may
interpret the requirements incorrectly. This results in huge increase in cost if not
nipped in the bud. Requirements can be checked against following conditions -

If they can be practically implemented

If they are valid and as per functionality and domain of software

If there are any ambiguities

If they are complete

If they can be demonstrated

Requirement Elicitation Process

Requirement elicitation process can be depicted using the folloiwng diagram:
 Requirements gathering - The developers discuss with the client and end
users and know their expectations from the software.

Organizing Requirements - The developers prioritize and arrange the

requirements in order of importance, urgency and convenience.
Negotiation & discussion - If requirements are ambiguous or there are some
conflicts in requirements of various stakeholders, if they are, it is then
negotiated and discussed with stakeholders. Requirements may then be
prioritized and reasonably compromised.
The requirements come from various stakeholders. To remove the ambiguity and
conflicts, they are discussed for clarity and correctness. Unrealistic requirements
are compromised reasonably.

Documentation - All formal & informal, functional and non-functional

requirements are documented and made available for next phase processing.

Software Requirements
We should try to understand what sort of requirements may arise in the requirement
elicitation phase and what kinds of requirements are expected from the software
system.
Broadly software requirements should be categorized in two categories:
Functional Requirements
Requirements, which are related to functional aspect of software fall into this category.
They define functions and functionality within and from the software system.
EXAMPLES -

Search option given to user to search from various invoices.

User should be able to mail any report to management.

Users can be divided into groups and groups can be given separate rights.
 Should comply business rules and administrative functions.

Software is developed keeping downward compatibility intact.

Non-Functional Requirements
Requirements, which are not related to functional aspect of software, fall into this
category. They are implicit or expected characteristics of software, which users make
assumption of.
Non-functional requirements include -

Security

Logging

Storage

Configuration

Performance

Cost

Interoperability

Flexibility

Disaster recovery

Accessibility
Requirements are categorized logically as

Must Have : Software cannot be said operational without them.

Should have : Enhancing the functionality of software.

Could have : Software can still properly function with these requirements.

Wish list : These requirements do not map to any objectives of software.

While developing software, Must have must be implemented, Should have is a
matter of debate with stakeholders and negation, whereas could have and wish list
can be kept for software updates.
User Interface requirements (User requirements)
UI is an important part of any software or hardware or hybrid system. A software is
widely accepted if it is -

easy to operate

quick in response

effectively handling operational errors

providing simple yet consistent user interface

User acceptance majorly depends upon how user can use the software. UI is the only
way for users to perceive the system. A well performing software system must also be
equipped with attractive, clear, consistent and responsive user interface. Otherwise the
functionalities of software system can not be used in convenient way. A system is said
be good if it provides means to use it efficiently. User interface requirements are
briefly mentioned below -

Content presentation

Easy Navigation

Simple interface

Responsive

Consistent UI elements

Feedback mechanism

Default settings

Purposeful layout

Strategical use of color and texture.

Provide help information

User centric approach

Group based view settings.

Software System Analyst

System analyst in an IT organization is a person, who analyzes the requirement of
proposed system and ensures that requirements are conceived and documented
properly & correctly. Role of an analyst starts during Software Analysis Phase of
SDLC. It is the responsibility of analyst to make sure that the developed software
meets the requirements of the client.
System Analysts have the following responsibilities:

Analyzing and understanding requirements of intended software

Understanding how the project will contribute in the organization

objectives

Identify sources of requirement

Validation of requirement

Develop and implement requirement management plan

Documentation of business, technical, process and product requirements

Coordination with clients to prioritize requirements and remove and

ambiguity

Finalizing acceptance criteria with client and other stakeholders

Software Metrics and Measures

Software Measures can be understood as a process of quantifying and symbolizing
various attributes and aspects of software.
Software Metrics provide measures for various aspects of software process and
software product.
Software measures are fundamental requirement of software engineering. They not
only help to control the software development process but also aid to keep quality of
ultimate product excellent.
According to Tom DeMarco, a (Software Engineer), You cannot control what you
cannot measure. By his saying, it is very clear how important software measures are.
Let us see some software metrics:
Size Metrics - LOC (Lines of Code), mostly calculated in thousands of
delivered source code lines, denoted as KLOC.
 Function Point Count is measure of the functionality provided by the software.
Function Point count defines the size of functional aspect of software.

Complexity Metrics - McCabes Cyclomatic complexity quantifies the

upper bound of the number of independent paths in a program, which is
perceived as complexity of the program or its modules. It is represented in
terms of graph theory concepts by using control flow graph.
Quality Metrics - Defects, their types and causes, consequence, intensity of
severity and their implications define the quality of product.
The number of defects found in development process and number of defects
reported by the client after the product is installed or delivered at client-end,
define quality of product.

Process Metrics - In various phases of SDLC, the methods and tools used,
the company standards and the performance of development are software
process metrics.

Resource Metrics - Effort, time and various resources used, represents

metrics for resource measurement.

COCOMO Model
Introduction to the COCOMO Model
The most fundamental calculation in the COCOMO model is the use of the
Effort Equation to estimate the number of Person-Months required to develop a
project. Most of the other COCOMO results, including the estimates for
Requirements and Maintenance, are derived from this quantity.
Overview of COCOMO

The COCOMO cost estimation model is used by thousands of software project

managers, and is based on a study of hundreds of software projects. Unlike other
cost estimation models, COCOMO is an open model, so all of the details are
published, including:

The underlying cost estimation equations

Every assumption made in the model (e.g. "the project will enjoy good
management")

Every definition (e.g. the precise definition of the Product Design phase of
a project)

The costs included in an estimate are explicitly stated (e.g. project

managers are included, secretaries aren't)

Because COCOMO is well defined, and because it doesn't rely upon proprietary
estimation algorithms, Costar offers these advantages to its users:

COCOMO estimates are more objective and repeatable than estimates

made by methods relying on proprietary models

COCOMO can be calibrated to reflect your software development

environment, and to produce more accurate estimates

Costar is a faithful implementation of the COCOMO model that is easy to use

on small projects, and yet powerful enough to plan and control large projects.

Typically, you'll start with only a rough description of the software system that
you'll be developing, and you'll use Costar to give you early estimates about the
proper schedule and staffing levels. As you refine your knowledge of the
problem, and as you design more of the system, you can use Costar to produce
more and more refined estimates.

Costar allows you to define a software structure to meet your needs. Your initial
estimate might be made on the basis of a system containing 3,000 lines of code.
Your second estimate might be more refined so that you now understand that
your system will consist of two subsystems (and you'll have a more accurate
idea about how many lines of code will be in each of the subsystems). Your next
estimate will continue the process -- you can use Costar to define the
components of each subsystem. Costar permits you to continue this process until
you arrive at the level of detail that suits your needs.
COCOMO II Effort Equation
The COCOMO II model makes its estimates of required effort (measured in
Person-Months PM) based primarily on your estimate of the software
project's size (as measured in thousands of SLOC, KSLOC)):

Effort = 2.94 * EAF * (KSLOC)E

Where
EAF Is the Effort Adjustment Factor derived from the Cost Drivers
E Is an exponent derived from the five Scale Drivers

As an example, a project with all Nominal Cost Drivers and Scale Drivers
would have an EAF of 1.00 and exponent, E, of 1.0997. Assuming that the
project is projected to consist of 8,000 source lines of code, COCOMO II
estimates that 28.9 Person-Months of effort is required to complete it:

Effort = 2.94 * (1.0) * (8)1.0997 = 28.9 Person-Months

COCOMO II Schedule Equation

The COCOMO II schedule equation predicts the number of months required to
complete your software project. The duration of a project is based on the effort
predicted by the effort equation:

Duration = 3.67 * (Effort)SE

Where
Effort Is the effort from the COCOMO II effort equation
SE Is the schedule equation exponent derived from the five Scale Drivers

Continuing the example, and substituting the exponent of 0.3179 that is

calculated from the scale drivers, yields an estimate of just over a year, and an
average staffing of between 3 and 4 people:

Duration = 3.67 * (42.3)0.3179 = 12.1 months

Average staffing = (42.3 Person-Months) / (12.1 Months) = 3.5 people

Unit-3
Design Strategies:
Software design is a process to conceptualize the software requirements into software
implementation. Software design takes the user requirements as challenges and tries to
find optimum solution. While the software is being conceptualized, a plan is chalked
out to find the best possible design for implementing the intended solution.
There are multiple variants of software design. Let us study them briefly:
Structured Design
Structured design is a conceptualization of problem into several well-organized
elements of solution. It is basically concerned with the solution design. Benefit of
structured design is, it gives better understanding of how the problem is being solved.
Structured design also makes it simpler for designer to concentrate on the problem
more accurately.
Structured design is mostly based on divide and conquer strategy where a problem is
broken into several small problems and each small problem is individually solved until
the whole problem is solved.
The small pieces of problem are solved by means of solution modules. Structured
design emphasis that these modules be well organized in order to achieve precise
solution.
These modules are arranged in hierarchy. They communicate with each other. A good
structured design always follows some rules for communication among multiple
modules, namely -
Cohesion - grouping of all functionally related elements.
Coupling - communication between different modules.
A good structured design has high cohesion and low coupling arrangements.
Function Oriented Design
In function-oriented design, the system is comprised of many smaller sub-systems
known as functions. These functions are capable of performing significant task in the
system. The system is considered as top view of all functions.
Function oriented design inherits some properties of structured design where divide
and conquer methodology is used.
This design mechanism divides the whole system into smaller functions, which
provides means of abstraction by concealing the information and their operation..
These functional modules can share information among themselves by means of
information passing and using information available globally.
Another characteristic of functions is that when a program calls a function, the
function changes the state of the program, which sometimes is not acceptable by other
modules. Function oriented design works well where the system state does not matter
and program/functions work on input rather than on a state.
Design Process

The whole system is seen as how data flows in the system by means of
data flow diagram.

DFD depicts how functions changes data and state of entire system.

The entire system is logically broken down into smaller units known as
functions on the basis of their operation in the system.

Each function is then described at large.

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

Objects - All entities involved in the solution design are known as objects.
For example, person, banks, company and customers are treated as objects.
Every entity has some attributes associated to it and has some methods to
perform on the attributes.
Classes - A class is a generalized description of an object. An object is an
instance of a class. Class defines all the attributes, which an object can have
and methods, which defines the functionality of the object.
In the solution design, attributes are stored as variables and functionalities are
defined by means of methods or procedures.

Encapsulation - In OOD, the attributes (data variables) and methods

(operation on the data) are bundled together is called encapsulation.
Encapsulation not only bundles important information of an object together,
but also restricts access of the data and methods from the outside world. This
is called information hiding.

Inheritance - OOD allows similar classes to stack up in hierarchical

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

Polymorphism - OOD languages provide a mechanism where methods

performing similar tasks but vary in arguments, can be assigned same name.
This is called polymorphism, which allows a single interface performing tasks
for different types. Depending upon how the function is invoked, respective
portion of the code gets executed.
Design Process
Software design process can be perceived as series of well-defined steps. Though it
varies according to design approach (function oriented or object oriented, yet It may
have the following steps involved:

A solution design is created from requirement or previous used system

and/or system sequence diagram.

Objects are identified and grouped into classes on behalf of similarity in

attribute characteristics.

Class hierarchy and relation among them is defined.

Application framework is defined.

Software Design Approaches

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

Interface Design

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

Attractive

Simple to use

Responsive in short time

Clear to understand

Consistent on all interfacing screens

UI is broadly divided into two categories:

Command Line Interface

Graphical User Interface

Command Line Interface (CLI)
CLI has been a great tool of interaction with computers until the video display
monitors came into existence. CLI is first choice of many technical users and
programmers. CLI is minimum interface a software can provide to its users.
CLI provides a command prompt, the place where the user types the command and
feeds to the system. The user needs to remember the syntax of command and its use.
Earlier CLI were not programmed to handle the user errors effectively.
A command is a text-based reference to set of instructions, which are expected to be
executed by the system. There are methods like macros, scripts that make it easy for
the user to operate.
CLI uses less amount of computer resource as compared to GUI.
CLI Elements

A text-based command line interface can have the following elements:

Command Prompt - It is text-based notifier that is mostly shows the context
in which the user is working. It is generated by the software system.
 Cursor - It is a small horizontal line or a vertical bar of the height of line, to
represent position of character while typing. Cursor is mostly found in
blinking state. It moves as the user writes or deletes something.
Command - A command is an executable instruction. It may have one or
more parameters. Output on command execution is shown inline on the
screen. When output is produced, command prompt is displayed on the next
line.
Graphical User Interface
Graphical User Interface provides the user graphical means to interact with the system.
GUI can be combination of both hardware and software. Using GUI, user interprets
the software.
Typically, GUI is more resource consuming than that of CLI. With advancing
technology, the programmers and designers create complex GUI designs that work
with more efficiency, accuracy and speed.
GUI Elements
GUI provides a set of components to interact with software or hardware.
Every graphical component provides a way to work with the system. A GUI system
has following elements such as:

Window - An area where contents of application are displayed. Contents in a

window can be displayed in the form of icons or lists, if the window
represents file structure. It is easier for a user to navigate in the file system in
an exploring window. Windows can be minimized, resized or maximized to
the size of screen. They can be moved anywhere on the screen. A window
may contain another window of the same application, called child window.
 Tabs - If an application allows executing multiple instances of itself, they
appear on the screen as separate windows. Tabbed Document Interface has
come up to open multiple documents in the same window. This interface also
helps in viewing preference panel in application. All modern web-browsers
use this feature.
Menu - Menu is an array of standard commands, grouped together and placed
at a visible place (usually top) inside the application window. The menu can
be programmed to appear or hide on mouse clicks.
Icon - An icon is small picture representing an associated application. When
these icons are clicked or double clicked, the application window is opened.
Icon displays application and programs installed on a system in the form of
small pictures.
Cursor - Interacting devices such as mouse, touch pad, digital pen are
represented in GUI as cursors. On screen cursor follows the instructions from
hardware in almost real-time. Cursors are also named pointers in GUI
systems. They are used to select menus, windows and other application
features.
Application specific GUI components
A GUI of an application contains one or more of the listed GUI elements:
Application Window - Most application windows uses the constructs
supplied by operating systems but many use their own customer created
windows to contain the contents of application.
Dialogue Box - It is a child window that contains message for the user and
request for some action to be taken. For Example: Application generate a
dialogue to get confirmation from user to delete a file.

Text-Box - Provides an area for user to type and enter text-based data.
 Buttons - They imitate real life buttons and are used to submit inputs to the
software.

Radio-button - Displays available options for selection. Only one can be

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

Other impressive GUI components are:

Sliders

Combo-box

Data-grid

Drop-down list
User Interface Design Activities
There are a number of activities performed for designing user interface. The process of
GUI design and implementation is alike SDLC. Any model can be used for GUI
implementation among Waterfall, Iterative or Spiral Model.
A model used for GUI design and development should fulfill these GUI specific steps.
 GUI Requirement Gathering - The designers may like to have list of all
functional and non-functional requirements of GUI. This can be taken from
user and their existing software solution.
User Analysis - The designer studies who is going to use the software GUI.
The target audience matters as the design details change according to the
knowledge and competency level of the user. If user is technical savvy,
advanced and complex GUI can be incorporated. For a novice user, more
information is included on how-to of software.
Task Analysis - Designers have to analyze what task is to be done by the
software solution. Here in GUI, it does not matter how it will be done. Tasks
can be represented in hierarchical manner taking one major task and dividing
it further into smaller sub-tasks. Tasks provide goals for GUI presentation.
Flow of information among sub-tasks determines the flow of GUI contents in
the software.
GUI Design & implementation - Designers after having information about
requirements, tasks and user environment, design the GUI and implements
into code and embed the GUI with working or dummy software in the
background. It is then self-tested by the developers.
Testing - GUI testing can be done in various ways. Organization can have in-
house inspection, direct involvement of users and release of beta version are
few of them. Testing may include usability, compatibility, user acceptance etc.

Software Design Levels

Software design is the first step in SDLC (Software Design Life Cycle), which moves
the concentration from problem domain to solution domain. It tries to specify how to
fulfill the requirements mentioned in SRS.
Software design yields three levels of results:

Architectural Design - The architectural design is the highest abstract

version of the system. It identifies the software as a system with many
components interacting with each other. At this level, the designers get the
idea of proposed solution domain.

High-level Design- The high-level design breaks the single entity-

multiple component concept of architectural design into less-abstracted view
of sub-systems and modules and depicts their interaction with each other.
High-level design focuses on how the system along with all of its components
can be implemented in forms of modules. It recognizes modular structure of
each sub-system and their relation and interaction among each other.

Detailed Design- Detailed design deals with the implementation part of

what is seen as a system and its sub-systems in the previous two designs. It is
more detailed towards modules and their implementations. It defines logical
structure of each module and their interfaces to communicate with other
modules.

Modularization

Modularization is a technique to divide a software system into multiple discrete and

independent modules, which are expected to be capable of carrying out task(s)
independently. These modules may work as basic constructs for the entire software.
Designers tend to design modules such that they can be executed and/or compiled
separately and independently.
Modular design unintentionally follows the rules of divide and conquer problem-
solving strategy this is because there are many other benefits attached with the
modular design of a software.
Advantage of modularization:

Smaller components are easier to maintain

 Program can be divided based on functional aspects

Desired level of abstraction can be brought in the program

Components with high cohesion can be re-used again

Concurrent execution can be made possible

Desired from security aspect

Concurrency
Back in time, all software are meant to be executed sequentially. By sequential
execution we mean that the coded instruction will be executed one after another
implying only one portion of program being activated at any given time. Say, a
software has multiple modules, then only one of all the modules can be found active at
any time of execution.
In software design, concurrency is implemented by splitting the software into multiple
independent units of execution, like modules and executing them in parallel. In other
words, concurrency provides capability to the software to execute more than one part
of code in parallel to each other.
It is necessary for the programmers and designers to recognize those modules, which
can be made parallel execution.
Example
The spell check feature in word processor is a module of software, which runs along
side the word processor itself.
Coupling and Cohesion
When a software program is modularized, its tasks are divided into several modules
based on some characteristics. As we know, modules are set of instructions put
together in order to achieve some tasks. They are though, considered as single entity
but may refer to each other to work together. There are measures by which the quality
of a design of modules and their interaction among them can be measured. These
measures are called coupling and cohesion.
Cohesion
Cohesion is a measure that defines the degree of intra-dependability within elements
of a module. The greater the cohesion, the better is the program design.
There are seven types of cohesion, namely

Co-incidental cohesion - It is unplanned and random cohesion, which

might be the result of breaking the program into smaller modules for the sake
of modularization. Because it is unplanned, it may serve confusion to the
programmers and is generally not-accepted.

Logical cohesion - When logically categorized elements are put together

into a module, it is called logical cohesion.

Temporal Cohesion - When elements of module are organized such that

they are processed at a similar point in time, it is called temporal cohesion.

Procedural cohesion - When elements of module are grouped together,

which are executed sequentially in order to perform a task, it is called
procedural cohesion.

Communicational cohesion - When elements of module are grouped

together, which are executed sequentially and work on same data
(information), it is called communicational cohesion.

Sequential cohesion - When elements of module are grouped because the

output of one element serves as input to another and so on, it is called
sequential cohesion.

Functional cohesion - It is considered to be the highest degree of

cohesion, and it is highly expected. Elements of module in functional
cohesion are grouped because they all contribute to a single well-defined
function. It can also be reused.

Coupling
Coupling is a measure that defines the level of inter-dependability among modules of a
program. It tells at what level the modules interfere and interact with each other. The
lower the coupling, the better the program.
There are five levels of coupling, namely -

Content coupling - When a module can directly access or modify or refer

to the content of another module, it is called content level coupling.
 Common coupling- When multiple modules have read and write access to
some global data, it is called common or global coupling.

Control coupling- Two modules are called control-coupled if one of them

decides the function of the other module or changes its flow of execution.

Stamp coupling- When multiple modules share common data structure

and work on different part of it, it is called stamp coupling.

Data coupling- Data coupling is when two modules interact with each
other by means of passing data (as parameter). If a module passes data
structure as parameter, then the receiving module should use all its
components.
Ideally, no coupling is considered to be the best.
Design Verification
The output of software design process is design documentation, pseudo codes, detailed
logic diagrams, process diagrams, and detailed description of all functional or non-
functional requirements.
The next phase, which is the implementation of software, depends on all outputs
mentioned above.
It is then becomes necessary to verify the output before proceeding to the next phase.
The early any mistake is detected, the better it is or it might not be detected until
testing of the product. If the outputs of design phase are in formal notation form, then
their associated tools for verification should be used otherwise a thorough design
review can be used for verification and validation.
By structured verification approach, reviewers can detect defects that might be caused
by overlooking some conditions. A good design review is important for good software
design, accuracy and quality.

Software reuse
Software reuse principles
Hardware reuse
use the same tool more than once, producing the same product more than
once, etc.
Hammer a nail
Hammer a nail again
Hammer a nail again and again

Software reuse: dont reinvent the wheel use the same knowledge more than
once
Hammer a nail
Hammer a nut

Why Reuse?

Save the cost, Reduce the effort Software costs huge when it was created, but
costs almost nothing to copy or redistribute One should focus on more creative
tasks

Reduce bugs
Use proven legacy software rather than write it completely from scratch

The goal of software reuse is to reduce the cost

of software production by replacing creation with recycling.

Improve Software Reusability

Build for reuse
Identify units of reusable knowledge
Store the reusable knowledge into a knowledge
base
Build with reuse
Search the reusable knowledge
Modify the reusable knowledge to fit new situations
Combine the reusable knowledge with your Project

Classic software reuse examples

High-level programming languages (e.g., Java, SQL)
Library of generic (parameterized) components (e.g. Math library)
Parser-generators and application generators (e.g. YACC, JavaCC, ANTLR,
automake, Eclipse)
Menu/table driven mechanism for specifying parameters (e.g. GUI widgets)
Application frameworks (e.g. Smalltalk, Motif, Swing/SWT)
Aspects: Pointcuts and advices (e.g. AspectJ etc.)
Internationalization/Localization (i18n/ l10n) (e.g. tag transformations)
Document generations (e.g. Javadoc/XDoclet, DocBook, LaTeX, CSS, RSS,
XSLT)
Components-off-the-shelf (COTS) through middleware (e.g., OLE/ActiveX,
CORBA,
 Web Services)
Plugin-ins, Skins, Themes, Macros, Extensions (e.g. Eclipse, Word, WinAmp,
Mozilla
Firefox etc.)
Domain engineering and application generation (e.g. SAP)
Domain-specific languages (DSL) and transformation systems (e.g. Draco,
TXL)
4-G languages (e.g. SQL, Wizards, templates, MIL/ADL, etc.)

Software Testing is evaluation of the software against requirements gathered from

users and system specifications. Testing is conducted at the phase level in software
development life cycle or at module level in program code. Software testing comprises
of Validation and Verification.
Software Validation
Validation is process of examining whether or not the software satisfies the user
requirements. It is carried out at the end of the SDLC. If the software matches
requirements for which it was made, it is validated.

Validation ensures the product under development is as per the user

requirements.

Validation answers the question "Are we developing the product which

attempts all that user needs from this software ?".

Validation emphasizes on user requirements.

Software Verification
Verification is the process of confirming if the software is meeting the business
requirements, and is developed adhering to the proper specifications and
methodologies.

Verification ensures the product being developed is according to design

specifications.

Verification answers the question "Are we developing this product by

firmly following all design specifications ?"

Verifications concentrates on the design and system specifications.

Target of the test are -
 Errors - These are actual coding mistakes made by developers. In addition,
there is a difference in output of software and desired output, is considered as
an error.
Fault - When error exists fault occurs. A fault, also known as a bug, is a result
of an error which can cause system to fail.
Failure - failure is said to be the inability of the system to perform the desired
task. Failure occurs when fault exists in the system.
Manual Vs Automated Testing
Testing can either be done manually or using an automated testing tool:
Manual - This testing is performed without taking help of automated testing
tools. The software tester prepares test cases for different sections and levels
of the code, executes the tests and reports the result to the manager.
Manual testing is time and resource consuming. The tester needs to confirm
whether or not right test cases are used. Major portion of testing involves manual
testing.
Automated This testing is a testing procedure done with aid of automated
testing tools. The limitations with manual testing can be overcome using
automated test tools.
A test needs to check if a webpage can be opened in Internet Explorer. This can be
easily done with manual testing. But to check if the web-server can take the load of 1
million users, it is quite impossible to test manually.
There are software and hardware tools which helps tester in conducting load testing,
stress testing, regression testing.
Testing Approaches
Tests can be conducted based on two approaches

Functionality testing

Implementation testing
When functionality is being tested without taking the actual implementation in concern
it is known as black-box testing. The other side is known as white-box testing where
not only functionality is tested but the way it is implemented is also analyzed.
Exhaustive tests are the best-desired method for a perfect testing. Every single possible
value in the range of the input and output values is tested. It is not possible to test each
and every value in real world scenario if the range of values is large.
 Black-box testing
It is carried out to test functionality of the program. It is also called Behavioral
testing. The tester in this case, has a set of input values and respective desired results.
On providing input, if the output matches with the desired results, the program is
tested ok, and problematic otherwise.

In this testing method, the design and structure of the code are not known to the tester,
and testing engineers and end users conduct this test on the software.
Black-box testing techniques:
Equivalence class - The input is divided into similar classes. If one element
of a class passes the test, it is assumed that all the class is passed.
Boundary values - The input is divided into higher and lower end values. If
these values pass the test, it is assumed that all values in between may pass
too.
Cause-effect graphing - In both previous methods, only one input value at a
time is tested. Cause (input) Effect (output) is a testing technique where
combinations of input values are tested in a systematic way.
Pair-wise Testing - The behavior of software depends on multiple
parameters. In pairwise testing, the multiple parameters are tested pair-wise
for their different values.
State-based testing - The system changes state on provision of input. These
systems are tested based on their states and input.
White-box testing
It is conducted to test program and its implementation, in order to improve code
efficiency or structure. It is also known as Structural testing.
In this testing method, the design and structure of the code are known to the tester.
Programmers of the code conduct this test on the code.
The below are some White-box testing techniques:
Control-flow testing - The purpose of the control-flow testing to set up test
cases which covers all statements and branch conditions. The branch
conditions are tested for both being true and false, so that all statements can
be covered.
Data-flow testing - This testing technique emphasis to cover all the data
variables included in the program. It tests where the variables were declared
and defined and where they were used or changed.
Testing Levels
Testing itself may be defined at various levels of SDLC. The testing process runs
parallel to software development. Before jumping on the next stage, a stage is tested,
validated and verified.
Testing separately is done just to make sure that there are no hidden bugs or issues left
in the software. Software is tested on various levels -
Unit Testing
While coding, the programmer performs some tests on that unit of program to know if
it is error free. Testing is performed under white-box testing approach. Unit testing
helps developers decide that individual units of the program are working as per
requirement and are error free.
Integration Testing
Even if the units of software are working fine individually, there is a need to find out if
the units if integrated together would also work without errors. For example, argument
passing and data updation etc.
System Testing
The software is compiled as product and then it is tested as a whole. This can be
accomplished using one or more of the following tests:
Functionality testing - Tests all functionalities of the software against the
requirement.
Performance testing - This test proves how efficient the software is. It tests
the effectiveness and average time taken by the software to do desired task.
Performance testing is done by means of load testing and stress testing where
the software is put under high user and data load under various environment
conditions.
 Security & Portability - These tests are done when the software is meant to
work on various platforms and accessed by number of persons.
Acceptance Testing
When the software is ready to hand over to the customer it has to go through last phase
of testing where it is tested for user-interaction and response. This is important because
even if the software matches all user requirements and if user does not like the way it
appears or works, it may be rejected.
Alpha testing - The team of developer themselves perform alpha testing by
using the system as if it is being used in work environment. They try to find
out how user would react to some action in software and how the system
should respond to inputs.
Beta testing - After the software is tested internally, it is handed over to the
users to use it under their production environment only for testing purpose.
This is not as yet the delivered product. Developers expect that users at this
stage will bring minute problems, which were skipped to attend.
Regression Testing
Whenever a software product is updated with new code, feature or functionality, it is
tested thoroughly to detect if there is any negative impact of the added code. This is
known as regression testing.
Testing Documentation
Testing documents are prepared at different stages -
Before Testing
Testing starts with test cases generation. Following documents are needed for
reference
SRS document - Functional Requirements document

Test Policy document - This describes how far testing should take place
before releasing the product.
Test Strategy document - This mentions detail aspects of test team,
responsibility matrix and rights/responsibility of test manager and test
engineer.
Traceability Matrix document - This is SDLC document, which is related to
requirement gathering process. As new requirements come, they are added to
this matrix. These matrices help testers know the source of requirement. They
can be traced forward and backward.
 While Being Tested
The following documents may be required while testing is started and is being done:
Test Case document - This document contains list of tests required to be
conducted. It includes Unit test plan, Integration test plan, System test plan
and Acceptance test plan.
Test description - This document is a detailed description of all test cases and
procedures to execute them.
Test case report - This document contains test case report as a result of the
test.
Test logs - This document contains test logs for every test case report.

After Testing
The following documents may be generated after testing :
Test summary - This test summary is collective analysis of all test reports
and logs. It summarizes and concludes if the software is ready to be launched.
The software is released under version control system if it is ready to launch.
Testing vs. Quality Control, Quality Assurance and Audit
We need to understand that software testing is different from software quality
assurance, software quality control and software auditing.
Software quality assurance - These are software development process
monitoring means, by which it is assured that all the measures are taken as
per the standards of organization. This monitoring is done to make sure that
proper software development methods were followed.
Software quality control - This is a system to maintain the quality of
software product. It may include functional and non-functional aspects of
software product, which enhance the goodwill of the organization. This
system makes sure that the customer is receiving quality product for their
requirement and the product certified as fit for use.
Software audit - This is a review of procedure used by the organization to
develop the software. A team of auditors, independent of development team
examines the software process, procedure, requirements and other aspects of
 SDLC. The purpose of software audit is to check that software and its
development process, both conform standards, rules and regulations.

Softawre Reliablity:
First definition
Software reliability is defined as the probability of failure-free
operation of a software system for a specified time in a specified
environment.
Key elements of the above definition
Probability of failure-free operation
Length of time of failure-free operation
A given execution environment
Example
The probability that a PC in a store is up and running for
eight hours without crash is 0.99.
Second definition
Failure intensity is a measure of the reliability of a software system
operating in a given environment.
Example: An air traffic control system fails once in two years.

Reliability is a broad concept.
It is applied whenever we expect something to behave in a certain
way.
Reliability is one of the metrics that are used to measure quality.
It is a user-oriented quality factor relating to system operation.
Intuitively, if the users of a system rarely experience failure, the
system is considered to be more reliable than one that fails more
often.
A system without faults is considered to be highly reliable.
Constructing a correct system is a difficult task.
Even an incorrect system may be considered to be reliable if the
frequency of failure is acceptable.
Key concepts in discussing reliability:
Fault
Failure
 Time
Three kinds of time intervals: MTTR, MTTF, MTBF

Failure
A failure is said to occur if the observable outcome of a program
execution is different from the expected outcome.
Fault
The adjudged cause of failure is called a fault.
Example: A failure may be cause by a defective block of code.
Time
Time is a key concept in the formulation of reliability. If the time gap
between two successive failures is short, we say that the system is
less reliable.
Two forms of time are considered.
Execution time ()
Calendar time (t)
MTTF: Mean Time To Failure
MTTR: Mean Time To Repair
MTBF: Mean Time Between Failures (= MTTF + MTTR)
 Two ways to measure reliability
Counting failures in periodic intervals
Observer the trend of cumulative failure count - ().
Failure intensity
Observe the trend of number of failures per unit time ().
()
This denotes the total number of failures observed until execution
time from the beginning of system execution.
()
This denotes the number of failures observed per unit time after
time units of executing the system from the beginning. This is also
called the failure intensity at time .
Relationship between () and ()
() = d()/d

Defect Testing:
The goal of defect testing is to discover defects in programs
A successful defect test is a test which causes a program to behave in an
anomalous way
Tests show the presence not the absence of defects
To discover faults or defects in the software where its behaviour is
incorrect or not in conformance with its specification;
A successful test is a test that makes the system perform incorrectly and so
exposes a defect in the system.
 Tes t Tes t Tes t Tes t
cas es data res ults reports

Des ign tes t Prepare tes t Run program Compare re s ults

cas es data with tes t da
ta to tes t cas es

Software safety:

Diagram
Software has been built into more and more products and systems over the years
and has taken on more and more of the functionality of those systems. The
question is: how dependable is the functionality provided by software? The
traditional approach to verification of functionality - try it out and see if it works
- is of limited value in the case of software which can be much more complex
than hardware.

Software safety has evolved to be a parallel effort to the development of the

software itself. The System Safety engineer is involved in each step of the
software development process identifying which functions are critical to the safe
functioning of the greater system and tracing those functions down into the
software modules which support them.
 Unit-4
Software maintenance is widely accepted part of SDLC now a days. It stands for all
the modifications and updations done after the delivery of software product. There are
number of reasons, why modifications are required, some of them are briefly
mentioned below:
Market Conditions - Policies, which changes over the time, such as taxation
and newly introduced constraints like, how to maintain bookkeeping, may
trigger need for modification.
Client Requirements - Over the time, customer may ask for new features or
functions in the software.
Host Modifications - If any of the hardware and/or platform (such as
operating system) of the target host changes, software changes are needed to
keep adaptability.
Organization Changes - If there is any business level change at client end,
such as reduction of organization strength, acquiring another company,
organization venturing into new business, need to modify in the original
software may arise.
Types of maintenance
In a software lifetime, type of maintenance may vary based on its nature. It may be
just a routine maintenance tasks as some bug discovered by some user or it may be a
large event in itself based on maintenance size or nature. Following are some types of
maintenance based on their characteristics:
Corrective Maintenance - This includes modifications and updations done in
order to correct or fix problems, which are either discovered by user or
concluded by user error reports.
Adaptive Maintenance - This includes modifications and updations applied
to keep the software product up-to date and tuned to the ever changing world
of technology and business environment.
Perfective Maintenance - This includes modifications and updates done in
order to keep the software usable over long period of time. It includes new
features, new user requirements for refining the software and improve its
reliability and performance.
Preventive Maintenance - This includes modifications and updations to
prevent future problems of the software. It aims to attend problems, which are
not significant at this moment but may cause serious issues in future.
 Cost of Maintenance
Reports suggest that the cost of maintenance is high. A study on estimating software
maintenance found that the cost of maintenance is as high as 67% of the cost of entire
software process cycle.

On an average, the cost of software maintenance is more than 50% of all SDLC
phases. There are various factors, which trigger maintenance cost go high, such as:
Real-world factors affecting Maintenance Cost

The standard age of any software is considered up to 10 to 15 years.

Older softwares, which were meant to work on slow machines with less
memory and storage capacity cannot keep themselves challenging against
newly coming enhanced softwares on modern hardware.

As technology advances, it becomes costly to maintain old software.

Most maintenance engineers are newbie and use trial and error method to
rectify problem.

Often, changes made can easily hurt the original structure of the software,
making it hard for any subsequent changes.

Changes are often left undocumented which may cause more conflicts in
future.
Software-end factors affecting Maintenance Cost

Structure of Software Program

 Programming Language

Dependence on external environment

Staff reliability and availability

Maintenance Activities
IEEE provides a framework for sequential maintenance process activities. It can be
used in iterative manner and can be extended so that customized items and processes
can be included.

These activities go hand-in-hand with each of the following phase:

Identification & Tracing - It involves activities pertaining to identification of
requirement of modification or maintenance. It is generated by user or system
may itself report via logs or error messages.Here, the maintenance type is
classified also.
Analysis - The modification is analyzed for its impact on the system
including safety and security implications. If probable impact is severe,
alternative solution is looked for. A set of required modifications is then
materialized into requirement specifications. The cost of
modification/maintenance is analyzed and estimation is concluded.
Design - New modules, which need to be replaced or modified, are designed
against requirement specifications set in the previous stage. Test cases are
created for validation and verification.
 Implementation - The new modules are coded with the help of structured
design created in the design step.Every programmer is expected to do unit
testing in parallel.
System Testing - Integration testing is done among newly created modules.
Integration testing is also carried out between new modules and the system.
Finally the system is tested as a whole, following regressive testing
procedures.
Acceptance Testing - After testing the system internally, it is tested for
acceptance with the help of users. If at this state, user complaints some issues
they are addressed or noted to address in next iteration.
Delivery - After acceptance test, the system is deployed all over the
organization either by small update package or fresh installation of the
system. The final testing takes place at client end after the software is
delivered.
Training facility is provided if required, in addition to the hard copy of user
manual.
Maintenance management - Configuration management is an essential part
of system maintenance. It is aided with version control tools to control
versions, semi-version or patch management.

Software Re-engineering
When we need to update the software to keep it to the current market, without
impacting its functionality, it is called software re-engineering. It is a thorough process
where the design of software is changed and programs are re-written.
Legacy software cannot keep tuning with the latest technology available in the market.
As the hardware become obsolete, updating of software becomes a headache. Even if
software grows old with time, its functionality does not.
For example, initially Unix was developed in assembly language. When language C
came into existence, Unix was re-engineered in C, because working in assembly
language was difficult.
Other than this, sometimes programmers notice that few parts of software need more
maintenance than others and they also need re-engineering.
 Re-Engineering Process

Decide what to re-engineer. Is it whole software or a part of it?

Perform Reverse Engineering, in order to obtain specifications of existing

software.

Restructure Program if required. For example, changing function-

oriented programs into object-oriented programs.

Re-structure data as required.

Apply Forward engineering concepts in order to get re-engineered

software.
There are few important terms used in Software re-engineering
Reverse Engineering
It is a process to achieve system specification by thoroughly analyzing, understanding
the existing system. This process can be seen as reverse SDLC model, i.e. we try to get
higher abstraction level by analyzing lower abstraction levels.
An existing system is previously implemented design, about which we know nothing.
Designers then do reverse engineering by looking at the code and try to get the design.
With design in hand, they try to conclude the specifications. Thus, going in reverse
from code to system specification.

Program Restructuring
It is a process to re-structure and re-construct the existing software. It is all about re-
arranging the source code, either in same programming language or from one
programming language to a different one. Restructuring can have either source code-
restructuring and data-restructuring or both.
Re-structuring does not impact the functionality of the software but enhance reliability
and maintainability. Program components, which cause errors very frequently can be
changed, or updated with re-structuring.
The dependability of software on obsolete hardware platform can be removed via re-
structuring.
Forward Engineering
Forward engineering is a process of obtaining desired software from the specifications
in hand which were brought down by means of reverse engineering. It assumes that
there was some software engineering already done in the past.
Forward engineering is same as software engineering process with only one difference
it is carried out always after reverse engineering.

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

Modules level - Where functional modules are re-used.

Software components provide interfaces, which can be used to establish
communication among different components.
Reuse Process
Two kinds of method can be adopted: either by keeping requirements same and
adjusting components or by keeping components same and modifying requirements.

Requirement Specification - The functional and non-functional requirements

are specified, which a software product must comply to, with the help of
existing system, user input or both.
Design - This is also a standard SDLC process step, where requirements are
defined in terms of software parlance. Basic architecture of system as a whole
and its sub-systems are created.
Specify Components - By studying the software design, the designers
segregate the entire system into smaller components or sub-systems. One
 complete software design turns into a collection of a huge set of components
working together.
Search Suitable Components - The software component repository is
referred by designers to search for the matching component, on the basis of
functionality and intended software requirements..
Incorporate Components - All matched components are packed together to
shape them as complete software.
Software Configuration Management (SCM)
Definition
Software configuration management (SCM) is a software engineering discipline
consisting of standard processes and techniques often used by organizations to
manage the changes introduced to its software products. SCM helps in
identifying individual elements and configurations, tracking changes, and
version selection, control, and base lining.

SCM is also known as software control management. SCM aims to control

changes introduced to large complex software systems through reliable version
selection and version control.

The SCM (Software Configuration Management) system has the following

advantages:

Reduced redundant work.

Effective management of simultaneous updates.

Avoids configuration-related problems.

Facilitates team coordination.

Helps in building management; managing tools used in builds.

Defect tracking: It ensures that every defect has traceability back to its
source.

SDLC Activities
 Software Development Life Cycle, SDLC for short, is a well-defined,
structured sequence of stages in software engineering to develop the intended
software product.

SDLC provides a series of steps to be followed to design and develop a software

product efficiently. SDLC framework includes the following steps:

Communication
This is the first step where the user initiates the request for a desired software product.
He contacts the service provider and tries to negotiate the terms. He submits his
request to the service providing organization in writing.
Requirement Gathering
This step onwards the software development team works to carry on the project. The
team holds discussions with various stakeholders from problem domain and tries to
bring out as much information as possible on their requirements. The requirements are
contemplated and segregated into user requirements, system requirements and
functional requirements. The requirements are collected using a number of practices as
given -

studying the existing or obsolete system and software,

conducting interviews of users and developers,

referring to the database or

collecting answers from the questionnaires.

Feasibility Study
After requirement gathering, the team comes up with a rough plan of software process.
At this step the team analyzes if a software can be made to fulfill all requirements of
the user and if there is any possibility of software being no more useful. It is found
out, if the project is financially, practically and technologically feasible for the
organization to take up. There are many algorithms available, which help the
developers to conclude the feasibility of a software project.
System Analysis
At this step the developers decide a roadmap of their plan and try to bring up the best
software model suitable for the project. System analysis includes Understanding of
software product limitations, learning system related problems or changes to be done
in existing systems beforehand, identifying and addressing the impact of project on
organization and personnel etc. The project team analyzes the scope of the project and
plans the schedule and resources accordingly.
Software Design
Next step is to bring down whole knowledge of requirements and analysis on the desk
and design the software product. The inputs from users and information gathered in
requirement gathering phase are the inputs of this step. The output of this step comes
in the form of two designs; logical design and physical design. Engineers produce
meta-data and data dictionaries, logical diagrams, data-flow diagrams and in some
cases pseudo codes.
Coding
This step is also known as programming phase. The implementation of software
design starts in terms of writing program code in the suitable programming language
and developing error-free executable programs efficiently.
Testing
An estimate says that 50% of whole software development process should be tested.
Errors may ruin the software from critical level to its own removal. Software testing is
done while coding by the developers and thorough testing is conducted by testing
experts at various levels of code such as module testing, program testing, product
testing, in-house testing and testing the product at users end. Early discovery of errors
and their remedy is the key to reliable software.
Integration
Software may need to be integrated with the libraries, databases and other program(s).
This stage of SDLC is involved in the integration of software with outer world entities.
Implementation
This means installing the software on user machines. At times, software needs post-
installation configurations at user end. Software is tested for portability and
adaptability and integration related issues are solved during implementation.
Operation and Maintenance
This phase confirms the software operation in terms of more efficiency and less errors.
If required, the users are trained on, or aided with the documentation on how to
operate the software and how to keep the software operational. The software is
maintained timely by updating the code according to the changes taking place in user
end environment or technology. This phase may face challenges from hidden bugs and
real-world unidentified problems.
Disposition
As time elapses, the software may decline on the performance front. It may go
completely obsolete or may need intense upgradation. Hence a pressing need to
eliminate a major portion of the system arises. This phase includes archiving data and
required software components, closing down the system, planning disposition activity
and terminating system at appropriate end-of-system time.
Software Evolution
The process of developing a software product using software engineering principles
and methods is referred to as software evolution. This includes the initial
development of software and its maintenance and updates, till desired software
product is developed, which satisfies the expected requirements.

Evolution starts from the requirement gathering process. After which developers create
a prototype of the intended software and show it to the users to get their feedback at
the early stage of software product development. The users suggest changes, on which
several consecutive updates and maintenance keep on changing too. This process
changes to the original software, till the desired software is accomplished.
Even after the user has desired software in hand, the advancing technology and the
changing requirements force the software product to change accordingly. Re-creating
software from scratch and to go one-on-one with requirement is not feasible. The only
feasible and economical solution is to update the existing software so that it matches
the latest requirements.

Software documentation is written text that accompanies computer software. It

either explains how it operates or how to use it, or may mean different things to
people in different roles.

Documentation is an important part of software engineering. Types of

documentation include:

1. Requirements - Statements that identify attributes, capabilities,

characteristics, or qualities of a system. This is the foundation for what
shall be or has been implemented.

2. Architecture/Design - Overview of software. Includes relations to an

environment and construction principles to be used in design of software
components.

3. Technical - Documentation of code, algorithms, interfaces, and APIs.

4. End user - Manuals for the end-user, system administrators and support
staff.

5. Marketing - How to market the product and analysis of the market

demand.

Software Quality Assurance (SQA)

Definition
Software quality assurance (SQA) is a process that ensures that developed
software meets and complies with defined or standardized quality
specifications. SQA is an ongoing process within the software
development life cycle (SDLC) that routinely checks the developed
software to ensure it meets desired quality measures.

Goal: to achieve high-quality software product

Quality definition:

Conformance to explicitly stated functional and performance

 requirements, explicitly documented development standards,

and implicit characteristics that expected of al professional

developed software.

Three import points for quality measurement:

- Use requirements as the foundation

- Use specified standards as the criteria

- Considering implicit requirements

About quality assurance:

- The first formal quality assurance and control function was

introduced at Bell Labs in 1916 in the manufacturing world.

- During the 1950s and 1960s, the programmers controls their product
quality.

- During the 1970s, quality assurance standards were introduced first in

military contract software development.

- In 1987, the extending definition is given in [SCH87].

Software Quality Assurance Activities

Application of Technical Methods (Employing proper methods and tools

for developing software)

Conduct of Formal Technical Review (FTR)

Testing of Software

Enforcement of Standards (Customer imposed standards or management

imposed standards)

Control of Change (Assess the need for change, document the change)
 Measurement (Software Metrics to measure the quality, quantifiable)

Records Keeping and Recording (Documentation, reviewed, change

control etc. i.e. benefits of docs).

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