LIST OF PRACTICAL

S.No. Name of experiments Date Signature

1 Study of Waterfall Model

2 Study of RAD Model in details

3 Study of Spiral Model

4 Study of Testing Technique

5 Study of Data Flow Diagram

6 Study of Software Requirement Specification

7 Study of UML

8 Study of Software Quality Assurance

 EXPERIMENT: -1
AIM :- Study of Waterfall Model

Waterfall model or linear sequential model or classic life cycle model: -

Sometimes called the classic life cycle or the waterfall model, the linear sequential model suggests a
systematic, sequential approach to software development that begins at the system level and
progresses through analysis, design, coding, testing, and maintenance. It is the oldest software
paradigm.

The waterfall model continues to be used in industrial design applications. It's often cited as the first
software development methodology. The model is also used more generally as a high-level project
management methodology for complicated, multifaceted projects.

Software requirements analysis: The requirements gathering process is focused specifically on

software. To understand the nature of the program(s) to be built, the software engineer ("analyst")
must understand the information domain for the software, as well as required function, behavior,
performance, and interface. Requirements for both the system and the software are documented and
reviewed with the customer.

Design: Software design is actually a multi-step process that focuses on four distinct attributes of a
program: data structure, software architecture, interface representations, and procedural (algorithmic)
detail. The design process translates requirements into a representation of the software that can be
assessed for quality before coding begins. Like requirements, the design is documented and becomes
part of the software configuration.

Coding: The design must be translated into a machine-readable form. The code generation step
performs this task. If design is performed in a detailed manner, code generation can be accomplished
mechanistically.

Testing: Once code has been generated, program testing begins. The testing process focuses on the
logical internals of the software, ensuring that all statements have been tested, and on the functional
externals; that is, conducting tests to uncover errors and ensure that defined input will produce actual
results that agree with required results.

Maintenance: Software will undoubtedly undergo change after it is delivered to the customer (a
possible exception is embedded software). Change will occur because errors have been encountered,
because the software must be adapted to accommodate changes in its external environment (e.g., a
change required

because of a new operating system or peripheral device), or because the customer requires functional
or performance enhancements. Software support/maintenance reapplies each of the preceding phases
to an existing program rather than a new one.

Advantages of waterfall model: -

• This model is simple and easy to understand and use.

• Waterfall model works well for smaller projects where requirements are very well understood.
• Each phase proceeds sequentially.
• Documentation is produced at every stage of the software's development. This makes
understanding the product designing procedure, simpler.
• After every major stage of software coding, testing is done to check the correct running of the
code.
• help us to control schedules and budgets.

Disadvantages of waterfall model: -

• Not a good model for complex and object-oriented projects.

• Poor model for long and ongoing projects.
• Not suitable for the projects where requirements are at a moderate to high risk of changing.
• High amounts of risk and uncertainty.
• Customer can see working model of the project only at the end. after reviewing of the working
model if the customer gets dissatisfied then it causes serious problem.
• You cannot go back a step if the design phase has gone wrong, things can get very complicated
in the implementation phase.
When to Use The Waterfall Model?
1. The waterfall model is most commonly used in software engineering and product development,
less often in other projects and industries.

2. Employ the waterfall model only if your project meets the following criteria:

3. All the requirements are known, clear, and fixed

4. There are no ambiguous requirements

5. The project is short and simple

6. The development environment is stable

7. Resources are adequately trained and available

8. The necessary tools and techniques used are stable, and not dynamic
 EXPERIMENT :- 2
AIM :- Study of RAD Model in details
RAPID APPLICATION MODEL:
Rapid application development (RAD) is a software development methodology that uses minimal
planning in favor of rapid prototyping. A prototype is a working model that is functionally equivalent to a
component of the product. In RAD model, the functional modules are developed in parallel as
prototypes and are integrated to make the complete product for faster product delivery.

Since there is no detailed pre-planning, it makes it easier to incorporate the changes within the
development process. RAD projects follow iterative and incremental model and have small teams
comprising of developers, domain experts, customer representatives and other IT resources working
progressively on their component or prototype. The most important aspect for this model to be
successful is to make sure that the prototypes developed are reusable.

Rapid application development (RAD) is an incremental software development process model that
emphasizes an extremely short development cycle. The RAD model is a "high-speed" adaptation of the
linear sequential model in which rapid development is achieved by using component-based
construction. If requirements are well understood and project scope is constrained, the RAD process
enables a development team to create a "fully functional system" within very short time periods (e.g.,
60 to 90 days). Used primarily for information systems applications, the RAD approach encompasses the
following phases:

Business modeling: The information flow among business functions is modeled in a way that answers
the following questions: What information drives the business process? What information is generated?
Who generates it? Where does the information go? Who processes it?

Data modeling: The information flow defined as part of the business modeling phase is refined into a
set of data objects that are needed to support the business. The characteristics (called attributes) of
each object are identified and the relationships between these objects defined.

Process modeling: The data objects defined in the data modeling phase are transformed to achieve
the information flow necessary to implement a business function. Processing descriptions are created
for adding, modifying, deleting, or retrieving a data object.

Application generation: RAD assumes the use of fourth generation techniques. Rather than creating
software using conventional third generation programming languages the RAD process works to reuse
existing program components (when possible) or create reusable components (when necessary). In all
cases, automated tools are used to facilitate construction of the software.

Testing and turnover: Since the RAD process emphasizes reuse, many of the program components
have already been tested. This reduces overall testing time. However, new components must be tested .
Advantages of the RAD model:
• Reduced development time.
• Increases re usability of components.
• Quick initial reviews occurs.
• Encourages customer feedback.
• Integration from very beginning solves a lot of integration issues.

Disadvantages of RAD model:

• Depends on strong team and individual performances for identifying business requirements.
• Only system that can be modularized can be built using RAD.
• Requires highly skilled developers/designers.
• High dependency on modeling skills
• Inapplicable to cheaper projects as cost of modeling and automated code generation is very
high.

When to use RAD model:

• RAD should be used when there is a need to create a system that can be modularized in 2-3
months of time.
• It should be used if there's high availability of designers for modeling and the budget is high
enough to afford their cost along with the cost of automated code generating tools.
• RAD SDLC model should be chosen only if resources with high business knowledge are available
and there is a need to produce the system in a short span of time (2-3 months).
 EXPERIMENT :- 3
AIM :- Study of Spiral Model

SPIRAL MODEL:
The spiral model, is an evolutionary software process model that couples the iterative nature of
prototyping with the controlled and systematic aspects of the linear sequential model. It provides the
potential for rapid development of incremental versions of the software. Using the spiral model,
software is developed in a series of incremental releases. During early iterations, the incremental
release might be a paper model or prototype. During later iterations, increasingly more complete
versions of the engineered system are produced.

A spiral model is divided into a number of framework activities, also called task Region Project entry
point axis is defined this axis represents starting point for different types of project. Every framework
activities represent one section of the spiral path. As the development process starts, the software team
performs activities that are indirect by a path around the spiral model in a clockwise direction. It begins
at the center of spiral model. Typically, there are between three and six task regions. In blow Figure
depicts a spiral model that contains six task regions:

Customer communication-tasks required to establish effective communication between developer

and customer.

Planning-tasks required to define resources, time lines, and other project related Information.

Risk analysis-tasks required to assess both technical and management risk

Engineering-tasks required to build one or more representations of the application.

Construction and release-tasks required to construct, test, install, and provide user support(e.g..
documentation and training).

Customer evaluation-tasks required to obtain customer feedback based on evaluation of the software
representations created during the engineering stage and implemented during the installation.
Advantages of Spiral model: -

• Good for large and mission-critical projects.

• Strong approval and documentation control.
• Additional Functionality can be added at a later date.
• Software is produced early in the software life cycle.

Disadvantages of Spiral model: -

• Can be a costly model to use.

• Risk analysis requires highly specific expertise.
• Project's success is highly dependent on the risk analysis phase.
• Doesn't work well for smaller projects.

When to use Spiral model:

• For medium to high-risk projects.

• When costs and risk evaluation is important.
• Long-term project commitment unwise because of potential changes to economic priorities.
• Users are unsure of their needs.
• Requirements are complex.
• New product line.
• Significant changes are expected (research and exploration).
 EXPERIMENT :- 4
AIM :- Study of Testing Technique

TEST TECHNIQUES:
There are various testing techniques are available in which internal structure/ design /implementation
of the item being tested. There are different methods that can be used for software testing.

• Black box testing

• White box testing
• Integration testing
• Unit testing
• System testing

BLACK BOX TESTING:

Black box testing is also called as behavioral testing. Black-box testing is a method of software testing
that examines the functionality of an application based on the specifications. It is also known as
Specifications based testing. Independent Testing Team usually performs this type of testing during the
software testing life cycle. This method of test can be applied to each and every level of software testing
such as unit, integration, system and acceptance testing.

Black box testing uncovers following types of errors:

• Incorrect or missing functions

• Interface errors
• Errors in data structures
• Performance errors
• Initialization or termination errors

There are different techniques involved in Black Box testing.

• Equivalence partitioning Boundary Value Analysis.

• Cause-Effect Graphing.
• Error-Guessing.
 Advantages Disadvantages
• Well suited and efficient for large code • Limited coverage, since only a selected number
segments. of test scenarios is actually performed.
• Code access is not required. • Inefficient testing, due to the fact that the
• Clearly separates user's perspective from tester only has limited knowledge about an
the developer's perspective through visibly application.
defined roles. • Blind coverage, since the tester cannot target
• Large numbers of moderately skilled testers specific code segments or error-prone areas.
can test the application with no knowledge • The test cases are difficult to design.
of implementation, programming language,
or operating systems.

WHITE BOX TESTING:

White-box testing is the detailed investigation of internal logic and structure of the code. White-box
testing is also called glass testing or open-box testing. In order to perform white-box testing on an
application, a tester needs to know the internal workings of the code. The tester needs to have a look
inside the source code and find out which unit/chunk of the code is behaving inappropriately.

White box testing techniques includes:

• Statement Coverage -This technique is aimed at exercising all programming statements with
minimal tests.
• Branch Coverage - This technique is running a series of tests to ensure that all branches are
tested at least once.
• Path Coverage - This technique corresponds to testing all possible paths which means that
each statement and branch is covered.

Advantages Disadvantages
• As the tester has knowledge of the source • Due to the fact that a skilled tester is
code, it becomes very easy to find out needed to perform white-box testing,
which type of data can help in testing the the costs are increased.
application effectively. • Sometimes it is impossible to look into
• It helps in optimizing the code. every nook and corner to find out
• Extra lines of code can be removed which hidden errors that may create problems,
can bring in hidden defects. as many paths will go untested.
• Due to the tester's knowledge about the • It is difficult to maintain white-box
code, maximum coverage is attained testing, as it requires specialized tools
during test scenario writing. like code analyzers and debugging tools.
UNIT TESTING:
nook and corner to find out hidden errors that may create problems, as many paths will go untested.

It is difficult to maintain white-box testing, as it requires specialized tools like code analyzers and
debugging tools.

Unit testing, a testing technique using which individual modules are tested to determine if there are any
issues by the developer himself. It is concerned with functional correctness of the standalone modules.

The main aim is to isolate each unit of the system to identify, analyze and fix the defects.

Advantages:-

• Reduces Defects in the newly developed features or reduces bugs when changing the existing
functionality.
• Reduces Cost of Testing as defects are captured in very early phase.
• Improves design and allows better refactoring of code.
• Unit Tests, when integrated with build gives the quality of the build as well.

• Black Box Testing - Using which the user interface, input and output are tested.
• White Box Testing - used to test each one of those functions behavior is tested.
• Gray Box Testing - Used to execute tests, risks and assessment methods.
 EXPERIMENT :- 5
AIM :- Study of Data Flow Diagram

DFD is the abbreviation for Data Flow Diagram. The flow of data of a system or a process is represented
by DFD. It also gives insight into the inputs and outputs of each entity and the process itself. DFD does
not have control flow and no loops or decision rules are present. Specific operations depending on the
type of data can be explained by a flowchart. It is a graphical tool, useful for communicating with users,
managers and other personnel. it is useful for analyzing existing as well as proposed system.

It provides an overview of
• What data is system processes.
• What transformation are performed.
• What data are stored.
• What results are produced, etc.
Characteristics of DFD :-
• DFDs are commonly used during problem analysis.
• DFDs are quite general and are not limited to problem analysis for software requirements
specification.
• DFDs are very useful in understanding a system and can be effectively used during analysis.
• It views a system as a function that transforms the inputs into desired outputs.
Rules for creating DFD
• The name of the entity should be easy and understandable without any extra assistance(like
comments).
• The processes should be numbered or put in ordered list to be referred easily.
• The DFD should maintain consistency across all the DFD levels.
• A single DFD can have a maximum of nine processes and a minimum of three processes.
Symbols Used in DFD

• Square Box: A square box defines source or destination of the system. It is also called entity. It is
represented by rectangle.

• Arrow or Line: An arrow identifies the data flow i.e. it gives information to the data that is in motion.

• Circle or bubble chart: It represents as a process that gives us information. It is also called processing
box.

• Open Rectangle: An open rectangle is a data store. In this data is store either temporary or
permanently.
Levels of DFD

DFD uses hierarchy to maintain transparency thus multilevel DFD's can be created. Levels of DFD are as
follows:

• 0-level DFD: It represents the entire system as a single bubble and provides an overall picture of the
system.

• 1-level DFD: It represents the main functions of the system and how they interact with each other.

• 2-level DFD: It represents the processes within each function of the system and how they interact with
each other.

• 3-level DFD: It represents the data flow within each process and how the data is transformed and
stored.
Advantages of DFD

• It helps us to understand the functioning and the limits of a system.

• It is a graphical representation which is very easy to understand as it helps visualize contents.

• Data Flow Diagram represent detailed and well explained diagram of system components.

• It is used as the part of system documentation file.

• Data Flow Diagrams can be understood by both technical or nontechnical person because they are
very easy to understand.
Disadvantages of DFD

• At times DFD can confuse the programmers regarding the system.

• Data Flow Diagram takes long time to be generated, and many times due to this reasons analysts are
denied permission to work on it.
 EXPERIMENT :- 6
AIM :- Study of Software Requirement Specification

Software Requirement Specification (SRS) Format as the name suggests, is a complete specification and
description of requirements of the software that need to be fulfilled for the successful development of
the software system. These requirements can be functional as well as non-functional depending upon
the type of requirement. The interaction between different customers and contractors is done because
it is necessary to fully understand the needs of customers.

Introduction

• Purpose of this Document - At first, main aim of why this document is necessary and what's
purpose of document is explained and described.
• Scope of this document - In this, overall working and main objective of document and what
value it will provide to customer is described and explained. It also includes a description of
development cost and time required.
• Overview - In this, description of product is explained. It's simply summary or overall review of
product.

General description

In this, general functions of product which includes objective of user, a user characteristic, features,
benefits, about why its importance is mentioned. It also describes features of user community.

Functional Requirements

In this, possible outcome of software system which includes effects due to operation of program is fully
explained. All functional requirements which may include calculations, data processing, etc. are placed
in a ranked order. Functional requirements specify the expected behavior of the system-which outputs
should be produced from the given inputs. They describe the relationship between the input and output
of the system. For each functional requirement, detailed description all the data inputs and their source,
the units of measure, and the range of valid inputs must be specified.

Interface Requirements

In this, software interfaces which mean how software program communicates with each other or users
either in form of any language, code, or message are fully described and explained. Examples can be
shared memory, data streams, etc.

Performance Requirements

In this, how a software system performs desired functions under specific condition is explained. It also
explains required time, required memory, maximum error rate, etc. The performance requirements part
of an SRS specifies the performance constraints on the software system. All the requirements relating to
the performance characteristics of the system must be clearly specified. There are two types of
performance requirements: static and dynamic. Static requirements are those that do not impose
constraint on the execution characteristics of the system. Dynamic characteristics of the system.
Dynamic requirements specify constraints the execution behaviour of the system.
Design Constraints

In this, constraints which simply means limitation or restriction are specified and explained for design
team. Examples may include use of a particular algorithm, hardware and software limitations, etc. There
are a number of factors in the client's environment that may restrict the choices of a designer leading to
design constraints such factors include standards that must be followed resource limits, operating
environment, reliability and security requirements and policies that may have an impact on the design
of the system. An SRS should identify and specify all such constraints.

Non-Functional Attributes

In this, non-functional attributes are explained that are required by software system for better
performance. An example may include Security, Portability, Reliability, Reusability, Application
compatibility, Data integrity, Scalability capacity, etc.

Preliminary Schedule and Budget

In this, initial version and budget of project plan are explained which include overall time duration
required and overall cost required for development of project.

Appendices

In this, additional information like references from where information is gathered, definitions of some
specific terms, acronyms, abbreviations, etc. are given and explained.

Uses of SRS document

• Development team require it for developing product according to the need.

• Test plans are generated by testing group based on the describe external behaviour.

• Maintenance and support staff need it to understand what the software product is supposed to do.

• Project manager base their plans and estimates of schedule, effort and resources on it.

• customer rely on it to know that product they can expect.

• As a contract between developer and customer.

• in documentation purpose.
 EXPERIMENT :- 7

AIM :- Study of UML

Unified Modeling Language (UML):-

UML, as the name implies, is a modeling language. It may be used to visualize, specify, construct, and
document the artifacts of a software system. It provides a set of notations (e.g. rectangles, lines,
ellipses, etc.) to create a visual model of the system. Like any other language, UML has its own syntax
(symbols and sentence formation rules) and semantics (meanings of symbols and sentences). Also, we
should clearly understand that UML is not a system design or development methodology, but can be
used to document object-oriented and analysis results obtained using some methodology.

UML Diagrams:

UML can be used to construct nine different types of diagrams to capture five different views of a
system. Just as a building can be modeled from several views (or perspectives) such as ventilation
perspective, electrical perspective, lighting perspective, heating perspective, etc.; the different UML
diagrams provide different perspectives of the software system to be developed and facilitate a
comprehensive understanding of the system. Such models can be refined to get the actual
implementation of the system.

The UML diagrams can capture the following five views of a system:
• User's view
• Structural view
• Behavioral view
• Implementation view
• Environmental view

User's view: This view defines the functionalities (facilities) made available by the system to its users.
The users' view captures the external user's view of the system in terms of the functionalities offered by
the system. The user's view is a black-box view of the system where the internal structure, the dynamic
behavior of different system components, the implementation etc. are not visible.

Structural view: The structural view defines the kinds of objects (classes) important to the
understanding of the working of a system and to its implementation. It also captures the relationships
among the classes (objects). The structural model is also called the static model, since the structure of a
system does not change with time.

Behavioral view: The behavioral view captures how objects interact with each other to realize the
system behavior. The system behavior captures the time-dependent (dynamic) behavior of the system.

Implementation view: This view captures the important components of the system and their
dependencies. Environmental view: This view models how the different components are implemented
on different pieces of hardware.

UML Diagram Types:

There are several types of UML diagrams:

• User model view represent through:

Use-case Diagram: Shows actors, use-cases, and the relationships between them.
• Structural model view represents through

Class Diagram: Shows relationships between classes and pertinent information about classes
themselves.

Object Diagram: Shows a configuration of objects at an instant in time.

• Behavioral model view represents through

Interaction Diagrams: Show an interaction between groups of collaborating objects.

Two types: Collaboration diagram and sequence diagram

Package Diagrams: Shows system structure at the library/package level.

State Diagram: Describes behavior of instances of a class in terms of states, stimuli, and transitions.

Activity Diagram: Very similar to a flowchart- shows actions and decision points, but with the ability to
accommodate concurrency.

• Environment model view represent through

Deployment Diagram: Shows configuration of hardware and software in a distributed system.

• Implementation model view represent through

Component Diagram: It shows code modules of a system. This code module includes application
program, ActiveX control, Java beans and back end databases. It representing interfaces and
dependencies among software architect.
 EXPERIMENT :- 8
AIM :- Study of Software Quality Assurance

SOFTWARE QUALITY ASSURANCE (SQA):

Software Quality:

In the context of software engineering, software quality measures how well software is designed
(quality of design), and how well the software conforms to that design (quality of conformance).

Quality Control:

Quality control (QC) is a procedure or set of procedures intended to ensure that a manufactured
product or performed service adheres to a defined set of quality criteria or meets the requirements of
the client or customer.

Quality Assurance:

It is planned and systematic pattern of activities necessary to provide a high degree of confidence in the
quality of a product. It provides quality assessment of the quality control activities and determines the
validity of the data or procedures for determining quality.

SQA Activities to Assure the Software Quality

The Software Quality Assurance of the software is analyzed and ensured by performing a series of
activities. The activities are performed as step by step process and the result analysis is reported for the
final evaluation process. The activities are performed as step by step process and the result analysis is
reported for the final evaluation process.

A Quality Management Plan is prepared

• 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).