PRACTICAL-1

Aim: Introduction to Software Engineering.

Software Engineering: Software Engineering is an engineering discipline that consists of
three key elements methods, tools and procedure that enables the manager to control the process
of software development and provide the developer with a foundation for building high quality
software in a productive manner .Software Engineering is an application of engineering to
software system implementation, operation and maintenance, which uses systematic approach,
methods, tools and procedure.
Application of engineering to software system implementation, operation and maintenance .It
uses systematic approach, methods, tools and procedure. Software Engineering is the study and
application of engineering to the design, development and maintenance of software.
The application of a systematic, disciplined, quantifiable approach to the development, operation
and maintenance of software. An engineering discipline that is concerned with all aspects of
software production .The establishment and use of sound engineering principles in order to
economically obtain software that is reliable and works efficiently on real machine Term
Software Engineering was first introduces in the first NATO conference 1968. The term was
defined as follows: The establishment and use of sound engineering principles in order to obtain
economically software that is reliable and works efficiently on real machines

History: The first commercial software was built as early as 1951, in England. The company
behind the software was J. Lyons Company. In the early days software building was
straightforward and uncontrolled. Still, even at 50s software could be relatively versatile.
When the first digital computers appeared in the early 1940s, the instructions to make them
operate were wired into the machine. Practitioners quickly realized that this design was not
flexible and came up with the "stored program architecture" or von Neumann architecture. Thus
the division between "hardware" and "software" began with abstraction being used to deal with
the complexity of computing.
When the first digital computers appeared in the early 1940s, the instructions to make them
operate were wired into the machine. Practitioners quickly realized that this design was not
flexible and came up with the "stored program architecture" or von Neumann architecture. Thus
the division between "hardware" and "software" began with abstraction being used to deal with
the complexity of computing.
In 1984, the Software Engineering Institute (SEI) was established as a federally funded research
and development center headquartered on the campus of Carnegie Mellon University in
Pittsburgh, Pennsylvania, United States. Watts Humphrey founded the SEI Software Process
Program, aimed at understanding and managing the software engineering process. His 1989

book, Managing the Software Process, asserts that the Software Development Process can and
should be controlled, measured, and improved. The Process Maturity Levels introduced would
become the Capability Maturity Model Integration for Development (CMMi-DEV), which has
defined how the US Government evaluates the abilities of a software development team.

Features of software engineering: The definition was very modern since it is still valid.
Software engineering is disciplined engineering work, offers means to build high-quality
efficient software at affordable prices, and offers task allocation and tools for all.

The emergence of software engineering: The task description and the requirements
frequently change even during the program design phase, and continue to change even after the
software system has long since been in use. The major problems encountered in development of
large software systems were:

correctness
efficiency
mastery of complexity
interface specification
reliability
documentation
maintainability
project organization

Phases of software engineering:

The analysis phase defines the requirements of the
system, independent of how these requirements will be
accomplished. This phase defines the problem that the
customer is trying to solve. The deliverable result at the
end of this phase is a requirement document. Ideally,
this document states in a clear and precise fashion what
is to be built. This analysis represents the ``what'' phase.
The requirement document tries to capture the
requirements from the customer's perspective by
defining goals and interactions at a level removed from
the implementation details. The analysis team develops
the requirement document, which talks about things and actions on things. This document should
also include states, events, typical scenarios of usage, and typical scenarios of usage

The Design Phase: In the design phase the architecture is established. This phase starts with
the requirement document delivered by the requirement phase and maps the requirements into
architecture. The architecture defines the components, their interfaces and behaviors. The

deliverable design document is the architecture. The design document describes a plan to
implement the requirements. This phase represents the ``how'' phase. Details on computer
programming languages and environments, machines, packages, application architecture,
distributed architecture layering, memory size, platform, algorithms, data structures, global type
definitions, interfaces, and many other engineering details are established. The design may
include the usage of existing components.

The Implementation Phase: In the implementation phase, the team builds the components
either from scratch or by composition . Given the architecture document from the design phase
and the requirement document from the analysis phase, the team should build exactly what has
been requested, though there is still room for innovation and flexibility. For example, a
component may be narrowly designed for this particular system, or the component may be made
more general to satisfy a reusability guideline. The architecture document should give guidance.
Sometimes, this guidance is found in the requirement document. The implementation phase deals
with issues of quality, performance, baselines, libraries, and debugging. The end deliverable is
the product itself.

The Testing Phase: Simply stated, quality is very important. Many companies have not
learned that quality is important and deliver more claimed functionality but at a lower quality
level. It is much easier to explain to a customer why there is a missing feature than to explain to
a customer why the product lacks quality. A customer satisfied with the quality of a product will
remain loyal and wait for new functionality in the next version The testing technique is from the
perspective of the system provider. Because it is nearly impossible to duplicate every possible
customer's environment and because systems are released with yet-to-be-discovered errors, the
customer plays an important, though reluctant, role in testing.

Introduction to SDLC: SDLC stands for Software development life cycle. It is a process
that describes how to develop, design and maintain the software project ensuring that all the
functional & user requirement, goals and objective are met. This methodology improves the
quality of the software project and over all process of software development.

The figure shows various stages of typical SDLC

Different Stages Of SDLC:

Requirement Gathering & Analysis phase: - 1st and important phase of SDLC for the
success of software. This phase includes communication between project stakeholders, end users
and project team, as requirements (both Functional & non functional) are being gathered from
clients.
This phase of SDLC includes:Functionally and financially feasibility analysis. Identify and capture requirements from
stakeholder through client interviews, surveys etc
Clearly defining and documenting requirements in SRS (software requirement specification
document) which consist of all the product requirements to be developed.
Creating prototypes of project, to show end user that how will project look like. Performed with
the help of tools like Azure etc.

Design Phase:- In design phase of SDLC, based on requirement captured in SRS, architecture
design is proposed for project and captured in design document. This phase of SDLC includes:Partition of requirements into hardware & software system.
Designing system architecture
Creating UML diagrams (Use cases, class diagram, sequence diagrams and Activity diagram)

Developments Phase: - This is the longest phase of SDLC as in this phase of SDLC actual
project is developed and build. This phase of SDLC includes:Actual code gets written.
Demonstration of work accomplished to Business analyst for future modification as per
requirement.
Unit testing is performed i.e. verification of code as per requirements.

Testing phase: The testing strategy is involved in almost all stages of SDLC. However this
phase of SDLC refers to the only testing of system where bugs/defect of the system are reported,
tracked and fixed. The system/project is migrated to a test environment and different type of
testing is performed like functional, integration, system and acceptance. This is performed until
the project reaches the quality standards as specified in SRS. This phase of SDLC includes:System is tested as a whole
Different type of testing to report & fix bugs.

Deploy & Maintenance phase: - In this phase of SDLC, once the system is tested, it is
ready to go live. The system may be first released for limited user, and tested in real business
environment for UAT (user acceptance testing).This phase of SDLC includes:System is ready to be delivered.
System is installed and put into use..
Correction of errors that were not caught before.

PRACTICAL-2
Aim: Introduction to Project and the feasibility study.
Introduction: In todays life software is become an integral part in almost all the applications
involving computer-based systems. This is the software project .In this project, we have to create
a website. Name of this website is Railway Reservation system .This website is basically
designed for providing online information regarding the Trains. In this project some basic
functions have to fulfill recommended by Administrator. Such functions include information
regarding the Trains, online registration or reservation of seat, time schedules, and all relevant
information available there, feedback information etc. provided on website.

Project planning objective

The objective of software project planning is to provide a framework that enables the manager to
make reasonable estimates of resources, cost and schedule .These estimates are made within a
limited time frame at the beginning of a software project and should be updated regularly as the
project progresses

Scope: The first activity on software project planning is the determine of software scope.
Function and performance allocated to software during system engineering should be assessed to
establish a project scope that is unambiguous and understandable at the management and
technical levels.

Following information is collected during estimating scope of this project:

This software project that is website of tutorial RRS is requested by Admin of this
website.
The developed project is used by many visitors who want to get information regarding
trains.
This project should be web-based project.
According to requirement, required changes should be possible to made.

Feasibility study: Once scope has been identified, it is reasonable to identify feasibility of the
project .Feasibility study acquires the information of economic, technical or operation
requirements of project. Putnam and Myers address this issue when they write:Not everything

imaginable is feasible ,not even in software, evanescent as it may appear to outsiders.On the
contrary software feasibility has four dimensions:
Technology-is a project technically feasible?
-is it within the state of the art?
Finance-is it financially feasible?
-can development be completed at a cost the software organization ,its client, or the
market?
Resources-Does the organization has the resources needed to succeed?

Information gathered during feasibility study:

Project is economically feasible as all cost estimation techniques are applied to guessing
the cost on project and customer is satisfied by it.
This software project needs software that is available in market easily. Systems required,
hardware required etc., everything is possible as required by customer.
This project is operationally possible to develop.

Resources: The development environment-hardware and software tolls-sits at the foundation

of the resources pyramid and provides the infrastructure to support the development effort.At a
higher level we encounter reusable software components-software building blocks that can
dramatically reduce development costs and accelerate delivery.
1. Human Resources: The planner begins by evaluating scope and selecting the skills
required to complete development. Both organization position(eg. manager, senior
software engineer)and specialty(eg. Telecommunications, database, client/server) are
specified .For relatively small projects a single individual may perform all software
engineering tasks.
As this is very small project so in this project two persons are efficient for developing
project and one for collecting information.
Reusable Resources: Component based software engineering emphasizes reusability that is
the creation and reuse of software building blocks.
In this projects all modules are created by the developer, some interacting media or
images are downloaded from internet.

People
Reusable software
Componets
Hardware/softwar
e tools
Figure 1: Resources Pyramid
TOOLS/TECHNOLOGIES: The project "Railway Reservation System" has been
prepared by using the following versions of software and hardware. Hence to use and modify the
package at any other installation the hardware and software requirements would be follows:
Minimum Software Requirement: The software requirements of project to develop are

Any Windows OS such as xp,7etc..

Application software to code website such as Notpad application ,PHP environment
Any Browser such as Internet Explorer, Firefox etc.
Database system such as MS Access, MYSQL.

Minimum Hardware Requirement: Hardware requirements used to develop this project are given
below .Here those requirements are mentioned that are under use by developer. These are basic
requirements. But as website is web based so this website can be visit from any environment where
internet possible. The hardware requirement of project to be develop are:

Processor i3
Minimum 2 Gb RAM
Hard Disk Space ( 200Gb )
Keyboard

PRACTICAL-3
Aim: To study the system requirement analysis and specification phase of project
development and develop SRS.
Requirement analysis:
A requirement analysis is the principle affected process in a feedbacks system that produces
description of the behavior and non-behavior feature of the system. It is the term used to describe
all tasks that go into the instigation, scooping and definition of a new or altered computer system.

Elements of Requirement:
Physical Environment: Means the target environment in which a system should have to
operate.
User: User means who will use the system.
Functionality: Functionality means what the proposed system will do and several modes
of operation.
Documentation: Documentation means how much documentation is required for the
proposed system.
Security: Security includes the different security issues of the proposed system.
In this phase following information is gathered:
As this project is web based software project. It runs on internet at any machine as
computer, mobile devices etc.
Users of this project will be those who want to travel in train and may be any web site
visitor.
Functionality of project will be described in SRS development.
Documentation is done with each phase completion.
Security is maintained by using different security mechanisms.

Software Requirement Specification

A SRS is a complete description of the behavior of the system to be developed. It includes a set
of use cases that describe all the interaction the users will have the software.

Important parts of SRS:

Functional Requirements: This part discusses the functionalities required from the
system. This software projectFis
i considered to perform a set of high level functionalities.
i1

o1

i2
i3

o2
o3

in

on
Figure 2: View of system performing a set of functions

Basic Functionalities of project:

1. You have to register yourself and then Enter the PNR for your booking to get the current
status. You will find it on the top left corner of the ticket. This information will be stored
on database of system.
2. Second function is to provide information regarding the timing schedules of train
between important stations. This information will be updated timely when changes have
to be done.
3. Seat availability information is also available through this website.
4. Fare enquiry can be done.

Non-Functional Requirements:- Non-functional requirements deal with the

characteristics of the system which cannot be expressed as functions such as the
maintainability of the system, portability of the system, usability of the system, etc.
Basic functionalities of project:
1. Accuracy of results: This project will be able to provide full accuracy. Each link of
web pages will be efficiently coded. There may be some issues of overload on server
if it leads to slow speed of page loading.
2. Human-computer interface: This website will provide simple interaction between the
website and visitor.
3. Constraints on the system: Each user visit will be catched by inbuilt implementation
as anyone visit website any time. It will be the wish of maintainer to upload
comments or feedback given by visitor.
Goals of implementation: In this, future requirements of project such as updation
needed and other facts completely possible to implement.

PRACTICAL-4
Aim:-Introduction to System Design.
Software design is both a process and a model. The design process is a sequence of steps that
enable the designer to describe all aspects of the software to be built. It is important to note
however, that the design process is not simply a cookbook. Creative skill, past experience, a
sense of what makes good software and an overall commitment to quality are critical success
factors for a competent design. The design model is the equivalent of an architects plans for a
house. It begins by representing the totality of the thing to be built (e.g., a three-dimensional
rendering of the house) and slowly renes the thing to provide guidance for constructing each
detail (e.g., the plumbing layout). Similarly, the design model that is created for soft- ware
provides a variety of different views of the computer software. Basic design principles enable the
software engineer to navigate the design process. During the design phase the design document
is produced, based on the customer requirements as documented in SRS document.

Design Concepts
The design concepts provide the software designer with a foundation from which more
sophisticated methods can be applied. A set of fundamental design concepts has evolved. They
are:

Abstraction:- Abstraction is the process or result of generalization by reducing the

information content of a concept or an observable phenomenon, typically in order to retain only
information which is relevant for a particular purpose.

Refinement:- It is the process of elaboration. A hierarchy is developed by decomposing

macroscopic statement of function in a step-wise fashion until programming language statements
are reached. In each step, one or several instructions of a given program are decomposed into
more detailed instructions. Abstraction and Refinement are complementary concepts.

Modularity:- Software architecture is divided into components called modules.

Software Architecture:- It refers to the overall structure of the software and the ways in
which that structure provides conceptual integrity for a system. Good software architecture will
yield a good return on investment with respect to the desired outcome of the project, e.g. in terms
of performance, quality, schedule and cost.

Control Hierarchy:- A program structure that represents the organization of a program

component and implies a hierarchy of control.

Structural Partitioning:- The program structure can be divided both horizontally and
vertically. Horizontal partitions define separate branches of modular hierarchy for each major
program function. Vertical partitioning suggests that control and work should be distributed top
down in the program structure.

Data Structure:- It is a representation of the logical relationship among individual elements

of data.

Software Procedure:- It focuses on the processing of each module individually.

Structure Analysis:
During Structure analysis, the major processing tasks of system are analyzed, and the data flow
among these processing tasks is represented graphically. During Structure analysis, the SRS
document is transformed into a DFD model.
The structure analysis technique is based on the following underlying principles:

Top-down decomposition approach.

Application of divide and conquer principle.
Graphical representation of analysis result using Data Flow Diagram.

Data Flow Diagram:

Data Flow Diagram (DFD) is graphical representation of flow of data/info. It is used to show
how data is moved between different processes. Data flow diagrams (also called data flow
graphs) are commonly used during problem analysis. Data flow diagrams (DFDs) are quite
general and are not limited to problem analysis for software requirements specification. They
were in use long before the software engineering discipline began. DFDs are very useful in
understanding a system and can be effectively used during analysis.
Primitive symbols used for constructing DFDs:

Function symbol: A function is represented using a circle. This symbol is called process
or a bubble.

Process
External entity symbol: It is represented by a rectangle.

External entity
Data flow symbol: A directed arc is used as data flow symbol.
Data store symbol: It is represented using parallel lines.

Output symbol: It is used when hard copy is produced.

Developing a DFD model of a system:

To develop the data flow model of a system, first the most abstract representation of the
problem is to be worked out. Subsequently, the lower level DFDs are developed.

Context Diagram: The Context level DFD is most abstract data flow of a system. It
represents the entire system as a single bubble. It is often referred to as Level 0 DFD, it is a
data flow diagram (DFD) of the scope of an organizational system that shows the system
boundaries, external entities that interact with the system and the major information flows
between the entities and the system; strictly there is however some distinction.
Context Diagram in software engineering and systems engineering is a diagram that
represents the actors outside a system that could interact with that system. This diagram is the
highest level view of a system. It is similar to a Block diagram.
The context diagram of our project Railway reservation system shows that how the data flow
is managed by the clerk of the railway and how passengers get all information about trains
and their fare.

T ic k e ts
Passenger

1
R a ilw a y
R e s e r v a t io n
S y s te m

R e s e r v a t io n
c h art

R e s e r v a t io n R e g is t e r

T ic k e t c o u n te r

A cce pta n ce o f fo rm
C o m pa rtm e n t

R a te T a b le

C o n te x t L e v e l

C a sh co u n te r

Level 1 DFD: The level 1 DFD usually contains between 3 to 7 bubbles. That is, the
system is represented as performing 3 to 7 functions. To develop the level 1 DFD, examine
the high-level functional requirements in the SRS document. If there are between 3 to 7 highlevel functions then each of these can be directly represented as a bubble in the level 1 DFD.
If there are more than 7 bubbles, then some of them have to be combined. If there are less
than 3 bubbles, then some of these have to be split.
In our website Railway reservation system, there are 3 high-level functions which define the
DFD level 1 represented as bubble. The 3 functions are process of verification seats,
preparing reports, cost and issuing tickets. The data is flowed among these three functions as
they perform different functions.

Passenger

C on du ctor

C heck

R e s e rvatio n
chart

T ic k e t
1 .1

1 .2

P roc ess o f
v e r if ic a t io n
s e a ts

P r e p a r in g
re p o r ts

A llo tm e n t
o f s e a ts

C o m pa rtm e n t

In q u ir y
R e s e r v a t io n
F ile

C ash

1 .3
C ost and
is s u in g o f
t ic k e t s

L evel 1
The function process of verification seat checks the passenger status and verifies their seats and
then stores the processed data into reservation file. The preparing report function prepares the
reservation chart and it is processed by the conductor of the railway. The function cost and issue
ticket, issues the ticket to passengers and maintain the cost.

PRACTICAL-5
Aim: Introduction to UML and its Diagrams.
UML:
The Unified Modeling Language (UML) is a general-purpose modeling language in the field
of software engineering. The basic level provides a set of graphic notation techniques to
create visual models of object-oriented software-intensive systems. Higher levels cover processoriented views of a system. UML was accepted by the Industrial Organization for
Standardization (ISO) as a standard for modeling software-intensive systems. It can be used with
all processes, throughout the software development life cycle, and across different
implementation technologies.[2]
The Unified Modeling Language (UML) offers a standard way to visualize a system's
architectural blueprints, including elements such as:
activities
actors
business processes
database schemas
(logical) components
programming language statements
reusable software components.

Uml Diagrams:
Class Diagram: The class diagram is the main building block of object oriented modeling. It
is used both for general conceptual modeling of the systematic of the application, and for
detailed modeling translating the models into programming code. Class diagrams can also be
used for data modeling. The classes in a class diagram represent both the main objects,
interactions in the application and the classes to be programmed.
In the diagram, classes are represented with boxes which contain three parts:
The top part contains the name of the class. It is printed in Bold, centered and the first
letter capitalized.

 The middle part contains the attributes of the class. They are left aligned and the first
letter is lower case.
The bottom part gives the methods or operations the class can take or undertake.
They are also left aligned and the first letter is lower case.
In the design of a system, a number of classes are identified and grouped together in a class
diagram which helps to determine the static relations between those objects. With detailed
modeling, the classes of the conceptual design are often split into a number of subclasses.

c le r k
+
+
+
+

id
a t t r ib u te
f o r m d e t a ils ( )
c a n c e lla t io n - f o r m ( )

* +uses

P a ssen ger
+
+
+
+
+
+
+
+
+

T r a in
+ tr a in N o .
+ T r a in n a m e

nam e
a d d re s s
age
gender
s e a r c h t r a in ( )
B o o k _ tic k e t( )
c a n c e l_ t ic k e t ( )
P a y c h a rg e ()
M o d if y _ f o r m ( )

R a ilw a y S y s te m

1 + id
+ a ttr ib u te
+ re sp o n se ()

P aym en t
+ account

T ic k e t
+
+
+
+
+
+
+

PN R N O .
S ta tu s
N o .o f p e r s o n s
C h a rg e ty p e
F a re _ a m t()
n e w _ tic k e t( )
d e le t e _ t ic k e t ( )
Class Diagram

Use case: A Use Case is typically defined with text which describes the scenario. You can enter
the text in the Description field within the Use Case definition. You can also choose to describe
the scenario in terms of its steps, using the Use Case Steps field within the Use Case definition.

Other properties are provided as a default for defining a Use Case, such as pre- and postconditions.

E n q u ir y tic k e t
a v a ila b ility

fill fo r m
r a ilw a y s ite

B o o k tic k e t

C u s to m e r
P ay am ount

C a n c e l tic k e t

Use case

Activity Diagram: Activity diagrams are graphical representations of workflows of stepwise

activities and action with support for choice, iteration and concurrency. In the Unified Modeling
Language, activity diagrams are intended to mode l both computational and organiz ational
processes (i.e. workflows). Activity diagrams show the overall flow of control.

Activity diagrams are constructed from a limited number of shapes, connected with arrows. The
most important shape types:

rounded rectangles representations;

diamonds represent decisions;
bars represent the start (split) or end (join) of concurrent activities;
a black circle represents the start (initial state) of the workflow;
an encircled black circle represents the end (final state).

Book
t ic k e t
F ill d e t a ils

S e a r c h t r a in
S u b m it d e t a ils

C h e c k t ic k e t
a v a ila b ilit y
M ake
paym ent

N o

Q u it
P r in t t ic k e t

B o o k t ic k e t

Yes

Activity Diagram

Sequence Diagram: A sequence diagram is an interaction diagram that shows how processes
operate with one another and in what order. It is a construct of a Message Sequence Chart. A
sequence diagram shows object interactions arranged in time sequence. It depicts the objects and
classes involved in the scenario and the sequence of messages exchanged between the objects
needed to carry out the functionality of the scenario. Sequence diagrams are typically associated
with use case realizations in the Logical View of the system under development. Sequence
diagrams are sometimes called event diagrams, event scenarios. A sequence diagram shows, as

parallel vertical lines (lifelines), different processes or objects that live simultaneously, and, as
horizontal arrows, the messages exchanged between them, in the order in which they occur. This
allows the specification of simple runtime scenarios in a graphical manner

P assen ger

R a ilw a y w e b s it e

c le r k

T ic k e t

1 :c a n c e lla tio n _ fo r m ()

2 :C a n c e l_ tic k e t()
3 :F ille d _ fo r m ()
4 :M o d ify _ fo r m ()
5 :C o n fir m ()

8 :c a lc u la te fin e a n d r e fu n d b a la n c e ()

6 :D e le te _ tic k e t()

7 :a d d to a v a ila b le ()

S e q u e n c e D ia g r a m

Sequence Diagram

Collaboration Diagram: The UML Collaboration diagram is used to model how objects
involved in a scenario interact, with each object instantiating a particular class in the system.
Objects are connected by links, each link representing an instance of an association between the
respective classes involved. The link shows messages sent between the objects, and the type of
message passed (synchronous, asynchronous, simple, balking, and timeout). Collaboration
diagrams offer a better view of a scenario than a Sequence diagram when the modeler is trying to
understand all of the effects on a given object and are therefore good for procedural design.
Objects: Objects are depicted on a Collaboration diagram as rectangles. The object name is
provided first, with the class name to the right; the two names are separated by a colon. You may
specify the multiple occurrence of an object by opening its definition dialog, selecting

its Symbol tab, and toggling on the multiple choices. You may also select the Multiple
Object tool from the toolbar.
Links: Messages passed between objects are specified within the Link drawn between objects.

9 : P a y _ c h a rg e s ()
3 : F o r m _ d e ta il( )
1

2 :S ta tu s ()

C le r k
4 : M o d if y _ d e ta il( )
6 : P r in t_ tic k e t( )
5 : F a re _ a m t()

T ic k e t

Collaboration Diagram

PRACTICAL-6

7 : n e w - tic k e t( )

P assenger

8 : T ic k e t_ n o .( )

R a ilw a y w e b s ite

Aim: Introduction to Coding and Unit testing.

Coding:
Coding is undertaken once design phase is complete and the design documents have been
successfully reviewed. The input to the coding phase is the design document produced at the end
of design phase. The objective of the coding phase is to transform the design of a system into
code in a high-level language, and then to unit test this code.
Coding conventions are only applicable to the human maintainers and peer reviewers of a
software project. Conventions may be formalized in a documented set of rules that an entire team
or company follows, or may be as informal as the habitual coding practices of an individual.
Coding conventions are not enforced by compilers. As a result, not following some or all of the
rules has no impact on the executable programs created from the source code.

Characteristics of coding:
Simplicity
Readability
Good documentation
Transportability

NAMING CONVENTIONS
Names of variables in mixed case, beginning with lowercase.
Function names and type names (classes, structs, enum, and typedef) in mixed case,
beginning with Uppercase.
Names of #defines, constants, and enum values in all uppercase, separated with
underscores.
Global variables start with g.
Class member variables start with m.
Avoid having too many parameters in functions: Functions that take too many parameters
often indicate poor code design and poor usage of data structures. If classes are used properly,
then there is no need to pass many parameters to member functions. Think of a class as a storage
place that stores data between function calls. In this way, its member functions should be able to
find inside the class most of the data they need. Too many parameters may also indicate
limited/poor usage of data structures.

Never use goto: This rule has been established long ago, when the structured programming
paradigm replaced the Spaghetti code style that was prominent in old programs. However, even
today there are programmers that still use it. It is extremely rare that using goto improves code
readability; therefore, its use should be completely avoided.
Code review is systematic examination (often known as peer review) of computer source code.
It is intended to find and fix mistakes overlooked in the initial development phase, improving
both the overall quality of software and the developers' skills. Reviews are done in various forms
such as pair programming, informal walkthroughs, and formal inspections.

Unit testing:
In computer programming, unit testing is a method by which individual units of source code, sets
of one or more computer program modules together with associated control data, usage
procedures, and operating procedures are tested to determine if they are fit for use. Intuitively,
one can view a unit as the smallest testable part of an application. Inprocedural programming, a
unit could be an entire module, but it is more commonly an individual function or procedure.
In object-oriented programming, a unit is often an entire interface, such as a class, but could be
an individual method. Unit tests are short code fragments created by programmers or
occasionally by white box testers during the development process.
Ideally, each test case is independent from the others. Substitutes such as method stubs, mock
objects, fakes, and test harnesses can be used to assist testing a module in isolation. Unit tests are
typically written and run by software developers to ensure that code meets its design and behaves
as intended.

OBJECTIVES OF SOFTWARE TESTING

The software testing is usually performed for the following objectives:SOFTWARE QUALITY IMPROVEMENT:- The computer and the software are mainly used
for complex and critical applications and a bug or fault in software causes severe losses. So a
great consideration is required for checking for quality of software.
VERIFICATION AND VALIDATION:Verification means to test that we are building the product in right way .i.e. are we using the
correct procedure for the development of software so that it can meet the user requirements.
Validation means to check whether we are building the right product or not.
SOFTWARE RELIABILTY ESTIMATION:- The objective is to discover the residual
designing errors before delivery to the customer. The failure data during process

PRACTICAL-7
Aim: introduction to integration and system testing.
Integration Testing:
Integration testing (sometimes called integration and testing, abbreviated I&T) is the phase
in software testing in which individual software modules are combined and tested as a group. It
occurs after unit testing and before validation testing. Integration testing takes as its
input modules that have been unit tested, groups them in larger aggregates, applies tests defined
in an integration test plan to those aggregates, and delivers as its output the integrated system
ready for system testing.
The purpose of integration testing is to verify functional, performance and
reliability requirements placed on major design items. These "design items", i.e. assemblages (or
groups of units), are exercised through their interfaces using black box testing, success and error
cases being simulated via appropriate parameter and data inputs. Simulated usage of shared data
areas and inter-process communication is tested and individual subsystems are exercised through
their input interface. Test cases are constructed to test whether all the components within
assemblages interact correctly, for example across procedure calls or process activations, and this
is done after testing individual modules, i.e. unit testing. The overall idea is a "building block"
approach, in which verified assemblages are added to a verified base which is then used to
support the integration testing of further assemblages.
Some different types of integration testing are:
Big bang
Top-down, and Bottom-up

Big bang: In this approach, all or most of the developed modules are coupled together to forms
a complete software system or major part of the system and then used for integration testing. The
Big Bang method is very effective for saving time in the integration testing process. However, if
the test cases and their results are not recorded properly, the entire integration process will be
more complicated and may prevent the testing team from achieving the goal of integration
testing.
A type of Big Bang Integration testing is called Usage Model testing. Usage Model Testing can
be used in both software and hardware integration testing. The basis behind this type of
integration testing is to run user-like workloads in integrated user-like environments. In doing the
testing in this manner, the environment is proofed, while the individual components are proofed
indirectly through their use. Usage Model testing takes an optimistic approach to testing, because

it expects to have few problems with the individual components. The strategy relies heavily on
the component developers to do the isolated unit testing for their product. The goal of the
strategy is to avoid redoing the testing done by the developers, and instead flesh-out problems
caused by the interaction of the components in the environment. For integration testing, Usage
Model testing can be more efficient and provides better test coverage than traditional focused
functional integration testing.

Top-down and Bottom-up

Bottom Up Testing is an approach to integrated testing where the lowest level components are
tested first, then used to facilitate the testing of higher level components. The process is repeated
until the component at the top of the hierarchy is tested.
All the bottom or low-level modules, procedures or functions are integrated and then tested.
After the integration testing of lower level integrated modules, the next level of modules will be
formed and can be used for integration testing. This approach is helpful only when all or most of
the modules of the same development level are ready. This method also helps to determine the
levels of software developed and makes it easier to report testing progress in the form of a
percentage.
Top Down Testing is an approach to integrated testing where the top integrated modules are
tested and the branch of the module is tested step by step until the end of the related module.

System testing:
System testing of software or hardware is testing conducted on a complete, integrated system to
evaluate the system's compliance with its specified requirements. System testing falls within the
scope of black box testing, and as such, should require no knowledge of the inner design of the
code or logic.
As a rule, system testing takes, as its input, all of the "integrated" software components that have
passed integration and also the software system itself integrated with any applicable hardware
system(s). The purpose of integration testing is to detect any inconsistencies between the
software units that are integrated together (called assemblages) or between any of
the assemblages and the hardware. System testing is a more limited type of testing; it seeks to
detect defects both within the "inter-assemblages" and also within the system as a whole.

Testing as a whole
System testing is performed on the entire system as a context of a functional Requirement
Specification and/or a System Requirement Specification (SRS). System testing tests not only
the design, but also the behavior and even the believed expectations of the customer.

Types of System Testing

Alpha testing
Beta testing
Acceptance testing
Alpha testing: It is the system testing performed by the development team.
Beta testing: It is the testing performed by the friendly set of customers.
Acceptance testing: this is the testing performed by the customer himself after the product
delivery to determine whether to accept the delivery product or to reject it.

PARCTICAL-8
Aim: Introduction to Software Maintenance.
Software maintenance:
In software engineering is the modification of a software product after delivery to correct faults,
to improve performance or other attributes. A common perception of maintenance is that it
merely involves fixing defects. However, one study indicated that the majority, over 80%, of the
maintenance effort is used for non-corrective actions. This perception is perpetuated by users
submitting problem reports that in reality are functionality enhancements to the system. More
recent studies put the bug-fixing proportion closer to 21%.
The key software maintenance issues are both managerial and technical. Key management issues
are: alignment with customer priorities, staffing, which organization does maintenance,
estimating costs. Key technical issues are: limited understanding, impact analysis, testing,
maintainability measurement.
Software maintenance is a very broad activity that includes error correction, enhancements of
capabilities, deletion of obsolete capabilities, and optimization. Because change is inevitable,
mechanisms must be developed for evaluation, controlling and making modifications.So any
work done to change the software after it is in operation is considered to be maintenance work.
The purpose is to preserve the value of software over the time. The value can be enhanced by
expanding the customer base, meeting additional requirements, becoming easier to use, more
efficient and employing newer technology. Maintenance may span for 20 years, whereas
development may be 1-2 years.

Types of Software maintenance:

Corrective: Corrective software maintenance involves developing and deploying solutions
to problems ("bugs") that arise during use of a software program. Computer users will
notice performance problems with software, such as error messages coming on the screen or
the program freezing or crashing, meaning corrective software maintenance is needed.
Often these fixes permanently solve the problem, but not always. Some fixes act as a
temporary solution while computer programmers work on a more permanent solution.

Perfective: No software program contains zero flaws or areas for improvement. Perfective
software maintenance involves computer programmers working to improve the way a
software program functions or how quickly it processes requests. Programmers may also
engage in perfective software maintenance to improve the software's menu layouts and

command interfaces. Sometimes programmers need to conduct perfective maintenance on

software because of outside influences, such as new government regulations that affect how
a business operates.

Adaptive:

The field of technology constantly changes through both hardware and

software developments. Adaptive software maintenance addresses these changes. A change
in a processor's speed, for example, will affect how the software performs on a single
computer. Software interacts with other software programs on a computer or network,
meaning changes in one program can require changes in other programs. A user will
eventually introduce new software to the computer or network, which can also affect how
other software already present operates.

Preventative:

When computer programmers engage in preventative software

maintenance they try to prevent problems with software programs before they occur.
Programmers seek to prevent corrective maintenance as much as possible, while also
anticipating adaptive maintenance needs before users experience problems. Computer
programmers test software, as automotive companies test the vehicles they make, to make
sure the software can handle high data loads and other stressful operations without
problems. Computer programmers also test the software with other programs users likely
will use on their computers, making sure compatibility issues do not arise.

Purpose: A process is a meaningful and partially-ordered set of activities that is carried out to
produce a valuable result.