FSD Lab Manual

PARUL POLYTECHNIC INSTITUTE
COMPUTER ENGINEERING
SUB CODE: 3340703 SUB NAME: FUNDAMENTALS OF SOFTWARE DESIGNING
PRACTICAL: 1
AIM: IDENTIFY THE DEVELOPMENT MODEL FOR SOFTWARE WITH

PROPER EXPLANATION.
WATERFALL MODEL:
The Waterfall Model was first Process Model to be introduced. It is also referred to as a
linear-sequential life cycle model. It is very simple to understand and use. In a waterfall
model, each phase must be completed before the next phase can begin and there is no
overlapping in the phases.
The waterfall Model illustrates the software development process in a linear sequential
flow; hence it is also referred to as a linear-sequential life cycle model. This means that
any phase in the development process begins only if the previous phase is complete. In
waterfall model phases do not overlap.
Classical Model design:-
Waterfall approach was first SDLC Model to be used widely in Software

Engineering to ensure success of the project. In "The Waterfall" approach, the whole
Lab Manual, REV No. 0.0 Page No: 1

process of software development is divided into separate phases. In Waterfall model,
typically, the outcome of one phase acts as the input for the next phase sequentially.
Following is a diagrammatic representation of different phases of waterfall model.
The sequential phases in Waterfall model are:
Requirement Gathering and analysis: All possible requirements of the system to be

developed are captured in this phase and documented in a requirement specification doc.
 System Design: The requirement specifications from first phase are studied in
this phase and system design is prepared. System Design helps in specifying
hardware and system requirements and also helps in defining overall system
architecture.
 Implementation: With inputs from system design, the system is first developed
in small programs called units, which are integrated in the next phase. Each unit is
developed and tested for its functionality which is referred to as Unit Testing.
 Integration and Testing: All the units developed in the implementation phase are
integrated into a system after testing of each unit. Post integration the entire
system is tested for any faults and failures.
 Deployment of system: Once the functional and non functional testing is done,
the product is deployed in the customer environment or released into the market.
 Maintenance: There are some issues which come up in the client environment.
To fix those issues patches are released. Also to enhance the product some better
versions are released. Maintenance is done to deliver these changes in the
customer environment.
All these phases are cascaded to each other in which progress is seen as flowing steadily
downwards (like a waterfall) through the phases. The next phase is started only after the
defined set of goals are achieved for previous phase and it is signed off, so the name
"Waterfall Model". In this model phases do not overlap.
Waterfall Model Application :

Every software developed is different and requires a suitable SDLC approach to be
followed based on the internal and external factors. Some situations where the use of
Waterfall model is most appropriate are:
 Requirements are very well documented, clear and fixed.

 Product definition is stable.
 Technology is understood and is not dynamic.

 There are no ambiguous requirements.
 Ample resources with required expertise are available to support the product.
 The project is short.
Advantage:
The advantage of waterfall development is that it allows for departmentalization and
control. A schedule can be set with deadlines for each stage of development and a product
can proceed through the development process model phases one by one.
Development moves from concept, through design, implementation, testing, installation,

troubleshooting, and ends up at operation and maintenance. Each phase of development
proceeds in strict order.
Disadvantage :
The disadvantage of waterfall development is that it does not allow for much reflection or
revision. Once an application is in the testing stage, it is very difficult to go back and
change something that was not well-documented or thought upon in the concept stage.
Iterative Model design:-

Iterative process starts with a simple implementation of a subset of the software
requirements and iteratively enhances the evolving versions until the full system is
implemented. At each iteration, design modifications are made and new functional
capabilities are added. The basic idea behind this method is to develop a system through
repeated cycles (iterative) and in smaller portions at a time (incremental).
Following is the pictorial representation of Iterative and Incremental model:

Iterative and Incremental development is a combination of both iterative design or

iterative method and incremental build model for development. "During software
development, more than one iteration of the software development cycle may be in
progress at the same time." and "This process may be described as an "evolutionary
acquisition" or "incremental build" approach."
In incremental model the whole requirement is divided into various builds. During each
iteration, the development module goes through the requirements, design, implementation
and testing phases. Each subsequent release of the module adds function to the previous
release. The process continues till the complete system is ready as per the requirement.
The key to successful use of an iterative software development lifecycle is rigorous

validation of requirements, and verification & testing of each version of the software
against those requirements within each cycle of the model. As the software evolves
through successive cycles, tests have to be repeated and extended to verify each version
of the software.
Iterative Model Application

Like other SDLC models, Iterative and incremental development has some specific
applications in the software industry. This model is most often used in the following
scenarios:
 Requirements of the complete system are clearly defined and understood.

 Major requirements must be defined; however, some functionalities or requested
enhancements may evolve with time.
 There is a time to the market constraint.

 A new technology is being used and is being learnt by the development team
while working on the project.
 Resources with needed skill set are not available and are planned to be used on
contract basis for specific iterations.
 There are some high risk features and goals which may change in the future.
Iterative Model Pros and Cons

The advantage of this model is that there is a working model of the system at a very early
stage of development which makes it easier to find functional or design flaws. Finding
issues at an early stage of development enables to take corrective measures in a limited
budget.
The disadvantage with this SDLC model is that it is applicable only to large and bulky
software development projects. This is because it is hard to break a small software system
into further small serviceable increments/modules.
SPIRAL MODEL:
The spiral model has four phases. A software project repeatedly passes through these
phases in iterations called Spirals.
 Identification:
This phase starts with gathering the business requirements in the baseline spiral.
In the subsequent spirals as the product matures, identification of system
requirements, subsystem requirements and unit requirements are all done in this
phase.
This also includes understanding the system requirements by continuous
communication between the customer and the system analyst. At the end of the spiral
the product is deployed in the identified market.
 Design:
Design phase starts with the conceptual design in the baseline spiral and involves
architectural design, logical design of modules, physical product design and final
design in the subsequent spirals.
 Construct or Build:

Construct phase refers to production of the actual software product at every spiral.
In the baseline spiral when the product is just thought of and the design is being
developed a POC (Proof of Concept) is developed in this phase to get customer
feedback.
Then in the subsequent spirals with higher clarity on requirements and design
details a working model of the software called build is produced with a version
number. These builds are sent to customer for feedback.
 Evaluation and Risk Analysis:
Risk Analysis includes identifying, estimating, and monitoring technical
feasibility and management risks, such as schedule slippage and cost overrun. After
testing the build, at the end of first iteration, the customer evaluates the software and
provides feedback.
Following is a diagrammatic representation of spiral model listing the activities in each

phase:
Based on the customer evaluation, software development process enters into the next
iteration and subsequently follows the linear approach to implement the feedback

suggested by the customer. The process of iterations along the spiral continues throughout
the life of the software.
Spiral Model Application

 When costs there is a budget constraint and risk evaluation is important.
 For medium to high-risk projects.
 Long-term project commitment because of potential changes to economic
priorities as the requirements change with time.
 Customer is not sure of their requirements which is usually the case.
 Requirements are complex and need evaluation to get clarity.
 New product line which should be released in phases to get enough customer
feedback.
 Significant changes are expected in the product during the development cycle.
Advantage:
 Changing requirements can be accommodated.
 Allows for extensive use of prototypes
 Requirements can be captured more accurately.
 Users see the system early.
 Development can be divided into smaller parts and more risky parts can be
developed earlier which helps better risk management.
Disadvantage:
 Management is more complex.
 End of project may not be known early.
 Not suitable for small or low risk projects and could be expensive for small
projects.
 Process is complex
 Spiral may go indefinitely.
 Large number of intermediate stages requires excessive documentation.

PRACTICAL: 2
AIM: GATHER REQUIREMNT FOR SOFTWARE.
There are basically two types of software requirements - Functional and Non-
Functional. As the name implies, Functional requirements describe the functionality of
the product. They describe exactly what tasks the software must perform. Functional
requirements define the scope of the system, the product boundaries, and its connections
to adjacent systems. Functional requirements also define the business rules. Business
rules are the rules that the system must conform to, based on the individual business. This
includes defining the data that must be tracked. The business rules are the most important
type of functional requirements and most of your requirements will be of this type.
Non-Functional requirements describe the look and feel of the system. This includes the
visual properties of the system, its usability, and the performance requirements - how big,
how fast, etc. Non-Functional requirements also include the product's intended operating
environment and any maintainability, portability and security issues. Non-Functional
requirements also include cultural and political issues as well as legal requirements that
the software must conform to.

It's important to point out that various sources, such as books and web sites, describe the
different types of software requirements using other categories, often with contradictory
terminology. The important part, however, is not which category the requirements fall
into, but that all the requirements in the business process have been identified and
documented.
So, now that we know what types of information we should be collecting, let's take a look
at the characteristics of good requirements. Good requirements have the following
attributes. They are:
 Complete - they very thoroughly describe the criteria

 Correct - they are accurate and true
 Feasible - they can be accomplished and individual requirements do not
contradict each other.
 Necessary - they are truly needed for the system to function properly and they
are really what the client wants.
 Prioritized - in the case that not all parts of the system can be implemented at
the same time, it's important to be able to distinguish "absolutely necessary"
from "nice to have".
 Unambiguous - they are clear and cannot be misinterpreted
 Verifiable - once implemented, it can be confirmed that the system has met
the requirement through observation and testing
Looking at the above list, it's obvious that quality and accuracy are extremely important.
One way to assure quality is to create a single checkpoint that each requirement must
pass through. Thus, a single person or a group of people must eventually individually
approve every requirement no matter where it originated. Having a single quality
checkpoint is especially important in large or complex projects. In addition, it's vital to
make sure that the requirements are not too general, and that they are comprehensive and
completely clear. Keep in mind that the person collecting the requirements might not
always be the same person who will be writing the actual code.
So, where and how do we find out about the requirements for a system? The best places
are from:
 Domain Experts - people who are very knowledgeable and work in the area
of the system that is being built
 Users - people who will actually be the ones using the system once it's built

 Existing processes and programs - both manual processes and existing
programs
 Find out the limitations of existing systems and software
 Find out where the users' time is spent
 Find out what they like and don't like
 Sit down with the users WHILE they are performing their tasks. Be sure to
ask questions to get a clear idea of what they are doing.
 Review similar software programs - if there is a similar or competing
program, this can be a great resource
It's important that you set up meetings with these people and interview them in order to
extract the information. This, of course, is not always an easy task, depending on the
people involved and how well they can communicate about what they do and how they
do it. More information about dealing with the customer while collecting requirements
can be found in the "Customers vs. Code" column in this issue of Component Developer
Magazine.

PRACTICAL: 3
AIM: PREPARE SRS DOCUMENT FOR SYSTEM.
SRS FOR ONLINE SHOPPING:
1. Introduction:
1.1 Purpose:
This document is meant to delineate the features of OSS, so as to serve as a guide to the
developers on one hand and a software validation document for the prospective client on
the other. The Online Shopping System (OSS) for furniture shop web application is
intended to provide complete solutions for vendors as well as customers through a single
get way using the internet. It will enable vendors to setup online shops, customer to
browse through the shop and purchase them online without having to visit the shop
physically. The administration module will enable a system administrator to approve and
reject requests for new shops and maintain various lists of shop category.
1.2 Scope:
This system allows the customer’s to maintain their cart for add or remove the product
over the internet.
1.3 Definitions:
OSS- Online shopping System (for furniture shop)

SRS- Software Requirement Specification
GUI- Graphical User Interface
Stockholder- The person who will participate in system
Ex. Customer, Administrator, Visitor etc.
1.3.1 Overview:

This system provides an easy to solution customer’s to buy the product without go to the
shop and also shop owner to sale the product.
1.4 Additional Information:

The system work on internet server, so it will operated by any end user for the buying
purpose.
2. General Description:
The Online Shopping system (OSS) application enables vendors to set up online shops,
customers to browse through the shops, and a system administrator to approve and reject
requests for new shops and maintain lists of shop categories. Also the developer is
designing an online shopping site to manage the items in the shop and also help
Customers purchase them online without having to visit the shop physically.The online
shopping system will use the internet as the sole method for selling goods to its
consumers.
3. Functional Requirement:
This section provides requirement overview of the system. Various functional modules
that can be implemented by the system will be –
3.1 Description:
3.1.1 Registration:
If customer wants to buy the product then he/she must be registered, unregistered user
can’t go to the shopping cart.
3.1.2 Login:
Customer logins to the system by entering valid user id and password for the shopping.
3.1.3 Changes to Cart:
Changes to cart means the customer after login or registration can make order or cancel
order of the product from the shopping cart.
3.1.4 Payment:
For customer there are many type of secure billing will be prepaid as debit or credit card,
post paid as after shipping, check or bank draft. The security will provide by the third
party like Pay-Pal etc.
3.1.5 Logout:
After the payment or surf the product the customer will logged out.

3.1.6 Report Generation:
After all transaction the system can generate the portable document file (.pdf) and then
sent one copy to the customer’s Email-address and another one for the system data base
to calculate the monthly transaction .
3.2 Technical Issues:

This system will work on client-server architecture. It will require an internet server and
which will be able to run PHP application. The system should support some commonly
used browser such as IE etc.
4. Interface Requirement:
4.1 Various interfaces for the product could be-

1. Login Page
2. Registration Form
3. There will be a screen displaying information about product that the shop
having.
4. If the customers select the buy button then another screen of shopping cart will
be opened.
5. After all transaction the system makes the selling report as portable document
file (.pdf) and sent to the customer E-mail address.
4.2 Hardware Interface:
The System must run over the internet, all the hardware shall require to connect internet
will be hardware interface for the system. As for e.g. Modem, WAN – LAN, Ethernet
Cross-Cable.
4.3 Software Interface:
The system is on server so it requires the any scripting language like PHP, VBScript
etc.The system require Data Base also for the store the any transaction of the system like
MYSQL etc. system also require DNS(domain name space) for the naming on the
internet. At the last user need web browser for interact with the system.
5. Performance Requirement:
There is no performance requirement in this system because the server request and
response is depended on the end user internet connection.
6. Design Constrain:
The system shall be built using a standard web page development tool that conforms to
Microsoft’s GUI standards like HTML, XML etc.

7. Other non Functional requirement:
7.1 Security:
The system use SSL (secured socket layer) in all transactions that include any
confidential customer information. The system must automatically log out all customers
after a period of inactivity. The system should not leave any cookies on the customer’s
computer containing the user’s password. The system’s back-end servers shall only be
accessible to authenticated administrators. Sensitive data will be encrypted before being
sent over insecure connections like the internet.
7.2 Reliability:
The system provides storage of all databases on redundant computers with automatic
switchover.
The reliability of the overall program depends on the reliability of the separate
components. The main pillar of reliability of the system is the backup of the database
which is continuously maintained and updated to reflect the most recent changes.
Thus the overall stability of the system depends on the stability of container and its
underlying operating system.
7.3 Availability:
The system should be available at all times, meaning the user can access it using a web
browser, only restricted by the down time of the server on which the system runs. In case
of a of a hardware failure or database corruption, a replacement page will be shown. Also
in case of a hardware failure or database corruption, backups of the database should be
retrieved from the server and saved by the administrator. Then the service will be
restarted. It means 24 X 7 availability.
7.4 Maintainability:
A commercial database is used for maintaining the database and the application server
takes care of the site. In case of a failure, a re-initialization of the program will be done.
Also the software design is being done with modularity in mind so that maintainability
can be done efficiently.
7.5 Portability:
The application is HTML and scripting language based. So The end-user part is fully
portable and any system using any web browser should be able to use the features of the
system, including any hardware platform that is available or will be available in the
future.
An end-user is use this system on any OS; either it is Windows or Linux.
The system shall run on PC, Laptops, and PDA etc.
8. Operational Scenario:
The customer wants to buy item. The system shows all product categories to customer. If
customer select item then they listed in shopping cart for buying.

The payment will made with credit card or bank check. If customer wants to cancel the
order before shipping then he or she can cancel it.
Customer can see the buying report on account detail.
PRACTICAL: 4
AIM: DESIGN ACTIVITY DIAGRAM FOR SYSTEM.
Activity diagram for Library Management System.
What is ACTIVITY diagram?
Typically used for business process modeling, activity diagrams are also useful for
system modeling. In its basic form, an activity diagram is a simple and intuitive
illustration of what happens in a workflow, what activities can be done in parallel, and
whether there are alternative paths through the workflow.
Activity diagrams as defined in the Unified Modeling Language (UML) are derived from
various techniques to visually illustrate workflows.
In the Rational Unified Process, we talk about how you can use activity diagrams to
visualize the workflow of a business use case. A complete workflow description will have
a basic flow, and one or several alternative flows. This workflow has a structure that we
can define textually, using informal if, if-then-else, or does-until statements of various
kinds. For a simple workflow with a simple structure, such textual definitions may be
quite sufficient, but in the case of more complex structures, activity diagrams help to
clarify and make more apparent what the workflow is.
Historically, activity diagramming techniques have mostly been used in the business
process modeling domain, but this practical will also briefly discuss how you can use it in
the system modeling domain.
The purpose of this practical is to show how you can use activity diagrams within the
Rational Unified Process for business modeling as well as system modeling. Activity
diagrams are often mentioned almost as a synonym to business modeling.
Diagram Notations:

Activity diagrams are constructed from a limited number of shapes, connected with
arrows. The most important shape types:
 Actions: rounded rectangles represent activities
 Decision Node:
The diamond below represents a conditional branch point or decision node. A
decision node has one input and two or more outputs:
Each output has a condition attached to it, which is written in brackets. If a condition
is met, the flow proceeds along the appropriate output. An ‘else’ output can be
defined along which the flow can proceed if no other condition is met.
 Edge (Control Flow):

Edges, represented by arrows, connect the individual components of activity diagrams
and illustrate the control flow of the activity:
Arrows run from the start towards the end and represent the order in which activities
happen .Within the control flow an incoming arrow starts a single step of an activity;
after the step is completed the flow continues along the outgoing arrow. A name can
be attached to an edge (close to the arrow).
 Merge Node:
The diamond below has several inputs and only one output:

Its purpose is the merging of flows. The inputs are not synchronized; if a flow reaches
such a node it precedes at the output without waiting for the arrival of other flows.
 Initial Node:
The initial node is the starting point of an activity. An activity can have more than one
initial node; in this case several flows start at the beginning of an activity:
 An encircled black circle represents the end (final state).

Exit



PRACTICAL: 5
AIM: DESIGN USE-CASE DIAGRAM FOR SYSTEM.
Use case diagram for Library Management System.
A use case diagram at its simplest is a representation of a user's interaction with the
system and depicting the specifications of a use case. A use case diagram can portray the
different types of users of a system and the various ways that they interact with the
system. This type of diagram is typically used in conjunction with the textual use case
and will often be accompanied by other types of diagrams as well.
An Actor models a type of role played by an entity that interacts with the subject (e.g., by
exchanging signals and data), but which is external to the subject.
Diagram Notations:
The actors that the system you are describing interacts with, the system itself, the use
cases, or services, that the system knows how to perform, and the lines that represent
relationships between these elements.
Actor:
An actor can be defined as some internal or external entity that interacts with the system.
Actor is used in a use case diagram to describe the internal or external entities.
"Actors may represent roles played by human users, external hardware, or other subjects.
Note that an actor does not necessarily represent a specific physical entity but merely a
particular facet (i.e., “role”) of some entity that is relevant to the specification of its
associated use cases. Thus, a single physical instance may play the role of several
different actors and, conversely, a given actor may be played by multiple different
instances."

Use case is represented as an eclipse with a name inside it. It may contain additional
responsibilities.
Use case is used to capture high level functionalities of a system.
LIBRARY MANAGEMENT SYSTEM:
Library management software is that software which used to do library housekeeping

activities and other work like accessioning, cataloguing, indexing, issue book, return
book, calculate fine etc.
USECASE DIAGRAM:

PRACTICAL: 6

AIM: DESIGN DATA DICTIONARY OF SYSTEM.
The terms data dictionary and data repository indicate a more general software utility
than a catalogue. A catalogue is closely coupled with the DBMS software. It provides the
information stored in it to the user and the DBA, but it is mainly accessed by the various
software modules of the DBMS itself, such as DDL and DML compilers, the query
optimizer, the transaction processor, report generators, and the constraint enforcer. On the
other hand, a data dictionary is a data structure that stores metadata, i.e., (structured) data
about data. The software package for a stand-alone data dictionary or data repository may
interact with the software modules of the DBMS, but it is mainly used by the designers,
users and administrators of a computer system for information resource management.
These systems maintain information on system hardware and software configuration,
documentation, application and users as well as other information relevant to system
administration.
If a data dictionary system is used only by the designers, users, and administrators and
not by the DBMS Software, it is called a passive data dictionary. Otherwise, it is called
an active data dictionary or data dictionary. When a passive data dictionary is updated, it
is done so manually and independently from any changes to a DBMS (database)
structure. With an active data dictionary, the dictionary is updated first and changes occur
in the DBMS automatically as a result.
Database users and application developers can benefit from an authoritative data
dictionary document that catalogs the organization, contents, and conventions of one or
more databases. This typically includes the names and descriptions of various tables
(records or Entities) and their contents (fields) plus additional details, like the type and
length of each data element. Another important piece of information that a data dictionary
can provide is the relationship between Tables. This is sometimes referred to in Entity-
Relationship diagrams, or if using Set descriptors, identifying which Sets database Tables
participate in.
In an active data dictionary constraints may be placed upon the underlying data. For
instance, a Range may be imposed on the value of numeric data in a data element (field),
or a Record in a Table may be FORCED to participate in a set relationship with another
Record-Type. Additionally, a distributed DBMS may have certain location specifics
described within its active data dictionary (e.g. where Tables are physically located).
The data dictionary consists of record types (tables) created in the database by systems
generated command files, tailored for each supported back-end DBMS. Command files
contain SQL Statements for CREATE TABLE, CREATE UNIQUE INDEX, ALTER
TABLE (for referential integrity), etc., using the specific statement required by that type
of database. There is no universal standard as to the level of detail in such a document
Example Data dictionary

(Taken from the CDC Manual: Indicators and methods for cross sectional surveys of
vitamin and mineral status of populations)
A Data Dictionary is a document that describes the basic organization of a database.

Typically a data dictionary will contain a list of variables in the database as well as the
assigned variable names and a description of each type of variable (e.g. character,
numeric, dates). The data dictionary should also include the values accepted for each
variable and any helpful comment such as important exclusions and skip patterns. The
data dictionary is used primarily for data analysis.
Variable Variable name Variable type Variable Width Values/notes

Participant ID ID Numeric 3 001-900
number
Cluster number CLUSTER Numeric 2 1-30
Age in months AGE Numeric 2.1 6.0-59.9
Date of birth DOB dd/mm/yyyy 1-31/1-
12/1900-2011
Sex SEX Numeric 1 1 = male 2 =
female
Date of survey SURVEY dd/mm/yyyy 15/06/2004 –
20/08/2004
Hemoglobin HB Numeric 2.1 4.0 – 18.0
Urinary iodine UI Numeric 4.1 0.0 – 1000.0
Iodine levels in IODINE Numeric 2 0,7, 15, 30
salt based on
rapid test kit
PRACTICAL: 7

AIM: PREPARE E-R DIAGRAM OF SYSTEM.
What are Entity Relationship Diagrams?
Entity Relationship Diagrams (ERDs) illustrate the logical structure of databases.
An ER Diagram
Entity Relationship Diagram Notations
Entity
An entity is an object or concept about which you want to store information.
Learn how to edit text on an entity.
Weak Entity

A weak entity is an entity that must defined by a foreign key relationship with another
entity as it cannot be uniquely identified by its own attributes alone.
Learn how to edit text on this object.
Key attribute
A key attribute is the unique, distinguishing characteristic of the entity. For example, an
employee's social security number might be the employee's key attribute.
Multivalued attribute
A multivalued attribute can have more than one value. For example, an employee entity
can have multiple skill values.
Derived attribute
A derived attribute is based on another attribute. For example, an employee's monthly
salary is based on the employee's annual salary.
Relationships
Relationships illustrate how two entities share information in the database structure.
Learn how to draw relationships:

First, connect the two entities, then drop the relationship notation on the line.

Cardinality
Cardinality specifies how many instances of an entity relate to one instance of another
entity.
Ordinality is also closely linked to cardinality. While cardinality specifies the occurrences
of a relationship, ordinality describes the relationship as either mandatory or optional. In
other words, cardinality specifies the maximum number of relationships and ordinality
specifies the absolute minimum number of relationships.
Recursive relationship
In some cases, entities can be self-linked. For example, employees can supervise other
employees.
E-R DIAGRAM FOR EXAM DATABASE:

PRACTICAL: 8
AIM: PREPARE DFD DIAGRAM OF SYSTEM.

Process Notations:
Process
A process transforms incoming data flow into outgoing data flow.
Yourdon and Coad Process Notations
Gane and Sarson Process Notation
Data store Notations
Data Store
Data stores are repositories of data in the system. They are sometimes also referred to as
files.
Yourdon and Coad Datastore Notations

Gane and Sarson Datastore Notations
Dataflow Notations
Dataflow
Data flows are pipelines through which packets of information flow. Label the arrows
with the name of the data that moves through it.
External Entity Notations
External Entity
External entities are objects outside the system, with which the system communicates.
External entities are sources and destinations of the system's inputs and outputs.

Data Flow Diagram Layers

Draw data flow diagrams in several nested layers. A single process node on a high level
diagram can be expanded to show a more detailed data flow diagram. Draw the context
diagram first, followed by various layers of data flow diagrams.
The nesting of data flow layers

DFD FOR HOSPITAL MANAGEMENT SYSTEM
[LEVEL 0]
[DFD FOR HOSPITAL MANAGEMENT SYSTEM]
LEVEL 1 ADMINISTROTOR

LEVEL 1 USER



DFD FOR ONLINE SHOPPING SYSTEM.


PRACTICAL: 9
AIM: DRAW GANTT CHART FOR THE GIVEN PROJECT.
A Gantt chart, commonly used in project management, is one of the most popular and
useful ways of showing activities (tasks or events) displayed against time. On the left of
the chart is a list of the activities and along the top is a suitable time scale. Each activity
is represented by a bar; the position and length of the bar reflects the start date, duration
and end date of the activity. This allows you to see at a glance:
 What the various activities are

 When each activity begins and ends
 How long each activity is scheduled to last
 Where activities overlap with other activities, and by how much
 The start and end date of the whole project.
To summarize, a Gantt chart shows you what has to be done (the activities) and when (the
schedule).
A simple Gantt chart

PRACTICAL: 10
AIM: PREPARE SUITABLE TEST CASE FOR SYSTEM TESTING.
A test case is a documentation which specifies input values, expected output and the
preconditions for executing the test.
IEEE Standard 610 (1990) defines test case as follows:
A set of test inputs, execution conditions, and expected results developed for a particular
objective, such as to exercise a particular program path or to verify compliance with a
specific requirement. A sequence of one or more subtests executed as a sequence because
the outcome and/or final state of one subtest is the input and/or initial state of the next.
The word ‘test’ is used to include subtests, tests proper, and test suites.
Objectives behind writing and executing the test cases:
Below mentioned are some of the objectives behind running the test cases.
1. Find the defects in software products

2. Verify that the software meets the end user requirements
3. Improve software quality
4. Minimize the maintenance and software support costs
5. Avoid post deployment risks
6. Compliance with processes
7. Help management to make software delivery decisions
TYPES OF TEST LEVEL:
What is Validation?
Validation represents dynamic testing techniques.
Validation ensures that the software operates as planned in the requirements phase by
executing it, running predefined test cases and measuring the output with expected
results.

Validation answers the question “Did we build the software fit for purpose and does it
provides the solution to the problem”.
Validation is concerned with evaluating the software, component or system to determine

it meets end user requirements.
Some important validation techniques are as follows:

Acceptance Testing
System Testing
Integration Testing
Unit Testing
Acceptance Testing:
Acceptance testing is performed after system testing is done and all or most of the major
defects have been fixed. The goal of acceptance testing is to establish confidence in the
delivered software/system that it meets the end user/customers requirements and is fit for
use Acceptance testing is done by user/customer and some of the project stakeholders.
Acceptance testing is done in production kind of environment.
For Commercial off the shelf (COTS) software’s that are meant for the mass market
testing needs to be done by the potential users, there are two types of acceptance testing
for COTS software’s.
Alpha Testing
Alpha testing is mostly applicable for software’s developed for mass market i.e.
Commercial off the shelf (COTS), feedback is needed from potential users. Alpha testing
is conducted at developers site, potential users, members or developers organization are
invited to use the system and report defects.
Beta Testing
Beta testing is also known as field testing, it is done by potential or existing

users/customers at an external site without developers involvement, this test is done to
determine that the software satisfies the end users/customers’ needs. This testing is done
to acquire feedback from the market.
System Testing
Testing the behavior of the whole software/system as defined in software requirements

specification (SRS) is known as system testing, its main focus is to verify that the
customer requirements are fulfilled.

System testing is done after integration testing is complete. System testing should test
functional and non functional requirements of the software.
Following types of testing should be considered during system testing cycle. The test
types followed in system testing differ from organization to organization however this list
covers some of the main testing types which need to be covered in system testing.
Sanity Testing
Usability Testing
Stress Testing
Load Testing
Performance Testing
Regression Testing
Maintenance Testing
Security Testing
Accessibility Testing
Integration Testing
In integration testing the individual tested units are grouped as one and the interface
between them is tested. Integration testing identifies the problems that occur when the
individual units are combined i.e. it detects the problem in interface of the two units.
Integration testing is done after unit testing.
There are mainly three approaches to do integration testing.
Top-down Approach
Top down approach tests the integration from top to bottom, it follows the architectural
structure.
Example: Integration can start with GUI and the missing components will be substituted
by stubs and integration will go on.
Bottom-up approach
In bottom up approach testing takes place from the bottom of the control flow, the higher
level components are substituted with drivers
Big bang approach

In big bang approach most or all of the developed modules are coupled together to form a
complete system and then used for integration testing.
Unit Testing
Unit is the smallest testable part of the software system. Unit testing is done to verify that
the lowest independent entities in any software are working fine. The smallest testable

part is isolated from the remainder code and tested to determine whether it works
correctly.
Why is Unit Testing Important?

Suppose you have two units and you do not want to test the units individually but as an
integrated system to save your time.
Once the system is integrated and you found error in an integrated system it becomes
difficult to differentiate that the error occurred in which unit so unit testing is mandatory
before integrating the units.
When developer is coding the software it may happen that the dependent modules are not
completed for testing, in such cases developers use stubs and drivers to simulate the
called (stub) and caller (driver) units. Unit testing requires stubs and drivers, stubs
simulate the called unit and driver simulates the calling unit.
Let’s explain STUBS and DRIVERS in detail.
STUBS:
Assume you have 3 modules, Module A, Module B and module C. Module A is ready and
we need to test it, but module A calls functions from Module B and C which are not
ready, so developer will write a dummy module which simulates B and C and returns
values to module A. This dummy module code is known as stub.
DRIVERS:
Now suppose you have modules B and C ready but module A which calls functions from
module B and C is not ready so developer will write a dummy piece of code for module A
which will return values to module B and C. This dummy piece of code is known as
driver.
Functional Testing:
Functional testing is also known as component testing.

It tests the functioning of the system or software i.e. What the software does. The
functions of the software are described in the functional specification document or
requirements specification document. Functional testing considers the specified behavior
of the software.
Non Functional Testing
Non functional testing tests the characteristics of the software like how fast the response
is, or what time does the software takes to perform any operation.
Some examples of Non-Functional Testing are:
1. Performance Testing
2. Load Testing
3. Stress Testing

4. Usability Testing
5. Reliability Testing
Non functionality testing focuses on the software’s performance i.e. How well it works.
Static Testing
Static testing is the form of software testing where you do not execute the code being
examined. This technique could be called non-execution technique. It is primarily syntax
checking of the code or manually reviewing the code, requirements documents, design
documents etc. to find errors.
From the black box testing point of view, static testing involves reviewing requirements
and specifications. This is done with an eye toward completeness or appropriateness for
the task at hand. This is the verification portion of Verification and Validation.
The fundamental objective of static testing technique is to improve the quality of the
software products by finding errors in early stages of software development life cycle.
Following are the main Static Testing techniques used:

1. Informal Reviews
2. Walkthrough
3. Technical Reviews
4. Inspection
5. Static Code Analysis
Dynamic Testing
Dynamic Testing is used to test the software by executing it. Dynamic Testing is also
known as Dynamic Analysis, this technique is used to test the dynamic behavior of the
code. In dynamic testing the software should be compiled and executed, this analyses the
variable quantities like memory usage, CPU usage, response time and overall
performance of the software.
Dynamic testing involves working with the software, input values are given and output
values are checked with the expected output. Dynamic testing is the Validation part of
Verification and Validation.
Some of the Dynamic Testing Techniques are given below:
Unit Testing
Integration Testing
System Testing
Acceptance Testing

Black Box Testing
Black box testing tests functional and non-functional characteristics of the software
without referring to the internal code of the software.
Black Box testing doesn’t requires knowledge of internal code/structure of the

system/software. It uses external descriptions of the software like SRS(Software
Requirements Specification), Software Design Documents to derive the test cases.
Black box Test Design Techniques
Typically Black box Test Design Techniques include:

Equivalence Partitioning
Boundary Value Analysis
State Transition Testing
Use case Testing
Decision Table Testing
White Box Testing
White Box testing tests the structure of the software or software component. It checks
what going on inside the software.
Also Know as clear box Testing, glass box testing or structural testing. Requires
knowledge of internal code structure and good programming skills. It tests paths within a
unit and also flow between units during integration of units.
White Box Test Design Techniques
Typically White box Test Design Techniques include:

1. Line Coverage or Statement Coverage
2. Decision Coverage
3. Condition Coverage
4. Multiple Condition Decision Coverage
5. Multiple Condition Coverage
Regression Testing
Regression Testing is done to find out the defects that arise due to code changes made in
existing code like functional enhancements or configuration changes.
The main intent behind regression testing is to ensure that any code changes made for
software enhancements or configuration changes has not introduced any new defects in
the software.

Anytime the changes are made to the existing working code, a suite of test cases is
executed to ensure that the new changes have not introduced any bugs in the software.
It is necessary to have a regression test suite and execute that suite after every new
version of software is available. Regression test suite is the ideal candidate for
automation because it needs to be executed after every new version.
Load Testing
Load testing tests the software or component with increasing load, number of concurrent
users or transactions is increased and the behavior of the system is examined and checked
what load can be handled by the software.
The main objective of load testing is to determine the response time of the software for
critical transactions and make sure that they are within the specified limit. It is a type of
performance testing. Load Testing is non-functional testing.
Stress Testing
Stress testing tests the software with a focus to check that the software does not crashes if
the hardware resources (like memory, CPU, Disk Space) are not sufficient.
Stress testing puts the hardware resources under extensive levels of stress in order to
ensure that software is stable in a normal environment.
In stress testing we load the software with large number of concurrent users/processes
which cannot be handled by the systems hardware resources. Stress Testing is a type of
performance testing and it is a non-functional testing.
Performance Testing
Performance Testing is done to determine the software characteristics like response time,
throughput or MIPS (Millions of instructions per second) at which the system/software
operates.
Performance Testing is done by generating some activity on the system/software; this is

done by the performance test tools available. The tools are used to create different user
profiles and inject different kind of activities on server which replicates the end-user
environments.
The purpose of doing performance testing is to ensure that the software meets the
specified performance criteria, and figure out which part of the software is causing the
software performance go down.
Performance Testing Tools should have the following characteristics:

It should generate load on the system which is tested
It should measure the server response time
It should measure the throughput
Security Testing
Security Testing tests the ability of the system/software to prevent unauthorized access to
the resources and data. Security Testing needs to cover the six basic security concepts:
confidentiality, integrity, authentication, authorization, availability and non-repudiation.
Confidentiality
A security measure which protects against the disclosure of information to parties other
than the intended recipient that is by no means the only way of ensuring the security.
Integrity
A measure intended to allow the receiver to determine that the information which it is
providing is correct. Integrity schemes often use some of the same underlying
technologies as confidentiality schemes, but they usually involve adding additional
information to a communication to form the basis of an algorithmic check rather than the
encoding all of the communication.
Authentication
The process of establishing the identity of the user. Authentication can take many forms
including but not limited to: passwords, biometrics, radio frequency identification, etc.
Authorization
The process of determining that a requester is allowed to receive a service or perform an
operation. Access control is an example of authorization.
Availability
Assuring information and communications services will be ready for use when expected.
Information must be kept available to authorized persons when they need it.
Non-repudiation
A measure intended to prevent the later denial that an action happened, or a
communication that took place etc.In communication terms this often involves the
interchange of authentication information combined with some form of provable time
stamp.
What is Verification?
Verification represents static testing techniques.
Verification ensures that the software documents comply with the organizations
standards, it is static analysis technique.
Verification answers the question “Is the Software build according to the specifications”.

Important Verification techniques are as follows:

Feasibility reviews
Requirements reviews
Technical Reviews
Walk through
Inspections
Formal reviews
Informal reviews
Peer reviews
Static Code Analysis

FSD Lab Manual

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

FSD Lab Manual

Загружено:

Авторское право:

Доступные форматы

PARUL POLYTECHNIC INSTITUTE

AIM: IDENTIFY THE DEVELOPMENT MODEL FOR SOFTWARE WITH

Classical Model design:-

Waterfall approach was first SDLC Model to be used widely in Software

Lab Manual, REV No. 0.0 Page No: 1

Following is a diagrammatic representation of different phases of waterfall model.

The sequential phases in Waterfall model are:

Requirement Gathering and analysis: All possible requirements of the system to be

Waterfall Model Application :

 Requirements are very well documented, clear and fixed.

 Technology is understood and is not dynamic.

Lab Manual, REV No. 0.0 Page No: 2

 The project is short.

Development moves from concept, through design, implementation, testing, installation,

Iterative Model design:-

Following is the pictorial representation of Iterative and Incremental model:

Lab Manual, REV No. 0.0 Page No: 3

Iterative and Incremental development is a combination of both iterative design or

The key to successful use of an iterative software development lifecycle is rigorous

Iterative Model Application

 Requirements of the complete system are clearly defined and understood.

 There is a time to the market constraint.

Lab Manual, REV No. 0.0 Page No: 4

Iterative Model Pros and Cons

Lab Manual, REV No. 0.0 Page No: 5

Following is a diagrammatic representation of spiral model listing the activities in each

Lab Manual, REV No. 0.0 Page No: 6

Spiral Model Application

 Large number of intermediate stages requires excessive documentation.

Lab Manual, REV No. 0.0 Page No: 7

AIM: GATHER REQUIREMNT FOR SOFTWARE.

Lab Manual, REV No. 0.0 Page No: 8

 Complete - they very thoroughly describe the criteria

Lab Manual, REV No. 0.0 Page No: 9

Lab Manual, REV No. 0.0 Page No: 10

AIM: PREPARE SRS DOCUMENT FOR SYSTEM.

SRS FOR ONLINE SHOPPING:

OSS- Online shopping System (for furniture shop)

Lab Manual, REV No. 0.0 Page No: 11

1.4 Additional Information:

3.1.3 Changes to Cart:

Lab Manual, REV No. 0.0 Page No: 12

3.1.6 Report Generation:

3.2 Technical Issues:

4.1 Various interfaces for the product could be-

4.2 Hardware Interface:

4.3 Software Interface:

Lab Manual, REV No. 0.0 Page No: 13

7. Other non Functional requirement:

Lab Manual, REV No. 0.0 Page No: 14

AIM: DESIGN ACTIVITY DIAGRAM FOR SYSTEM.

Activity diagram for Library Management System.

What is ACTIVITY diagram?

Lab Manual, REV No. 0.0 Page No: 15

 Actions: rounded rectangles represent activities

 Edge (Control Flow):

Lab Manual, REV No. 0.0 Page No: 16

 An encircled black circle represents the end (final state).

Lab Manual, REV No. 0.0 Page No: 17

Lab Manual, REV No. 0.0 Page No: 18

Lab Manual, REV No. 0.0 Page No: 19

Lab Manual, REV No. 0.0 Page No: 20