Name: - Darshil Ghatalia

Enrollment number:-221133116008
Subject:-software engineering
Class:-TB6

1|Page
 INDEX

Page No.
Sr. Fro T Dat Mark Signatur
No Experiment m o e s e
.
1. Study the complete Software
Development Life Cycle (SDLC)
and analyze various activities 3 6
conducted as a part of various
phases.
Develop Requirement
2. Specification for a 7 11
given problem

3. Case Study on Rational Rose

Tool.
Prepare Data dictionary
4. for given system.
Prepare Use Case Diagram
5. for given system.
Prepare all the levels of DFD
6. diagram for given system.
Prepare ER diagram on
7. given system.
Develop Activity diagram
8. for given system.
9. Calculate FP based Estimation
and LOC based Estimation for
any project.
10. Consider the any code
segment:
1. Guarantees that all
independent execution path is
exercised at least once;
2.Calculate the Cyclomatic
complexity for given code

2|Page
 Practical-1

 TITLE: Study the complete Software Development

Life Cycle (SDLC) and analyze various activities
conducted as a part of various phases.

 Defination:-
 Software Development Life Cycle (SDLC) is a process
used by the software industry to design, develop and
test high quality softwares. The SDLC aims to produce
a high-quality software that meets or exceeds customer
expectations, reaches completion within times and cost
estimates.

What is SDLC?
SDLC is a process followed for a software project, within a software
organization. It consists of a detailed plan describing how to develop,
maintain, replace and alter or enhance specific software. The life cycle
defines a methodology for improving the quality of software and the
overall development process.

The following figure is a graphical representation of the various stages

of a typical SDLC.

o Diagram

3|Page
  Explanation of all the stages:

Stage 1: Planning and Requirement Analysis

Requirement analysis is the most important and fundamental stage in
SDLC. It is performed by the senior members of the team with inputs
from the customer, the sales department, market surveys and domain
experts in the industry. This information is then used to plan the basic
project approach and to conduct product feasibility study in the
economical, operational and technical areas.

Planning for the quality assurance requirements and identification of

the risk.

4|Page
Stage 2: Defining Requirements
Once the requirement analysis is done the next step is to clearly define
and document the product requirements and get them approved from
the customer or the market analysts. This is done through an SRS
(Software Requirement Specification) document which consists of all the
product requirements to be designed and developed during the project
life cycle.
Stage 3: Designing the Product Architecture
SRS is the reference for product architects to come out with the best
architecture for the product to be developed. Based on the
requirements specified in SRS, usually more than one design approach
for the product architecture is proposed and documented in a DDS -
Design Document Specification.

This DDS is reviewed by all the important stakeholders and based on

various parameters as risk assessment, product robustness, design
modularity, budget and time constraints, the best design approach is
selected for the product.

A design approach clearly defines all the architectural modules of the

product along with its communication and data flow representation
with the external and third party modules (if any). The internal design
of all the modules of the proposed architecture should be clearly
defined with the minutest of the details in DDS.

Stage 4: Building or Developing the Product

In this stage of SDLC the actual development starts and the product is
built. The programming code is generated as per DDS during this
stage. If the design is performed in a detailed and organized manner,
code generation can be accomplished without much hassle.

Developers must follow the coding guidelines defined by their

organization and programming tools like compilers, interpreters,
debuggers, etc. are used to generate the code. Different high level
programming languages such as C, C++, Pascal, Java and PHP are
used for coding. The programming language is chosen with respect to
the type of software being developed.

5|Page
 Stage 5: Testing the Product
This stage is usually a subset of all the stages as in the modern SDLC
models, the testing activities are mostly involved in all the stages of
SDLC. However, this stage refers to the testing only stage of the
product where product defects are reported, tracked, fixed and
retested, until the product reaches the quality standards defined in the
SRS.

Stage 6: Deployment in the Market and

Maintenance
Once the product is tested and ready to be deployed it is released
formally in the appropriate market. Sometimes product deployment
happens in stages as per the business strategy of that organization.
The product may first be released in a limited segment and tested in
the real business environment (UAT- User acceptance testing).

 SDLC MODELS:-

I. Waterfall Model
II. Iterative Model
III. Spiral Model
IV. V-Model
V. Big Bang Model

6|Page
 Practical-2

 TITLE: Develop Requirement Specification for a

given problem Objectives.
 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.

 Overview:-
The production of the requirements stage of the software development process
is Software Requirements Specifications (SRS) (also called a requirements
document). This report lays a foundation for software engineering activities and
is constructing when entire requirements are elicited and analyzed.

 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.

7|Page
  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.
 Design 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.
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,

8|Page
  Explanation:-

1. Correctness: User review is used to provide the accuracy of

requirements stated in the SRS. SRS is said to be perfect if it covers all the
needs that are truly expected from the system.

2. Completeness: The SRS is complete if, and only if, it includes the following
elements:

(1). All essential requirements, whether relating to functionality, performance,

design, constraints, attributes, or external interfaces.

(2). Definition of their responses of the software to all realizable classes of input
data in all available categories of situations.

9|Page
3. Consistency: The SRS is consistent if, and only if, no subset of individual
requirements described in its conflict. There are three types of possible conflict in
the SRS:

(1). The specified characteristics of real-world objects may conflicts. For example,

(a) The format of an output report may be described in one requirement as

tabular but in another as textual.

(b) One condition may state that all lights shall be green while another states that
all lights shall be blue.

4. Unambiguousness: SRS is unambiguous when every fixed requirement has only one
interpretation. This suggests that each element is uniquely interpreted. In case there is a
method used with multiple definitions, the requirements report should determine the
implications in the SRS so that it is clear and simple to understand.

5. Ranking for importance and stability: The SRS is ranked for importance and stability if
each requirement in it has an identifier to indicate either the significance or stability of that particular
requirement.

Typically, all requirements are not equally important. Some prerequisites may be essential,
especially for life-critical applications, while others may be desirable. Each element should be
identified to make these differences clear and explicit. Another way to rank requirements is to
distinguish classes of items as essential, conditional, and optional.

6. Modifiability: SRS should be made as modifiable as likely and should be capable of

quickly obtain changes to the system to some extent. Modifications should be perfectly
indexed and cross-referenced.

7. Verifiability: SRS is correct when the specified requirements can be verified with a cost-
effective system to check whether the final software meets those requirements. The
requirements are verified with the help of reviews.

8. Traceability: The SRS is traceable if the origin of each of the requirements is clear and if
it facilitates the referencing of each condition in future development or enhancement
documentation.

9. Design Independence: There should be an option to select from multiple design

alternatives for the final system. More specifically, the SRS should not contain any
implementation details.

10 | P a g e
10. Testability: An SRS should be written in such a method that it is simple to generate test
cases and test plans from the report.

11. Understandable by the customer: An end user may be an expert in his/her explicit
domain but might not be trained in computer science. Hence, the purpose of formal
notations and symbols should be avoided too as much extent as possible. The language
should be kept simple and clear.

12. The right level of abstraction: If the SRS is written for the requirements stage, the
details should be explained explicitly. Whereas, for a feasibility study, fewer analysis can be
used. Hence, the level of abstraction modifies according to the objective of the SRS.

 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.

 Conclusion
Software development requires a well-structured Software Requirement
Specification (SRS). It helps stakeholders communicate, provides a roadmap for
development teams, guides testers in creating effective test plans, guides
maintenance and support employees, informs project management decisions, and
sets customer expectations

11 | P a g e