PRACTICAL FILE

ON
SOFTWARE ENGINEERING

Bachelor of Business Administration

(BATCH: 2019-2022)

Submitted to: Submitted By: Controller of

Examination Name:Praveen
MDU, Rohtak Registration No:191150111
Under the Supervision of Roll No. :
Mrs.Jyoti thakur

INSTITUTE OF MANAGEMENT & TECHNOLOGY

[Approved By AICTE, and affiliated to M.D.U, ROHTAK]
TIGAON ROAD, NEAR SAI DHAM, FARIDABAD -121002
 PRACTICAL 1
Objective:- Study the complete Software Development Life Cycle (SDLC) and analyse various activities
conducted as a part of various phases. For each SDLC phase, identify the objective and summaries
outcomes.

Result:
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.

A typical Software Development Life Cycle consists of the following 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 risks associated with the project is
also done in the planning stage. The outcome of the technical feasibility study is to define the various
technical approaches that can be followed to implement the project successfully with minimum risks.
Outcome of this stage is a requirement specification.

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.

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

Then based on the feedback, the product may be released as it is or with suggested enhancements in the
targeting market segment. After the product is released in the market, its maintenance is done for the
existing customer base.

PRACTICAL 2
Objective: Prepare a SRS document in line with the IEEE recommended standards.

Description:

An SRS is basically an organization's understanding (in writing) of a customer or potential client's system
requirements and dependencies at a particular point in time (usually) prior to any actual design or
development work. It's a two-way insurance policy that assures that both the client and the organization
understand the other's requirements from that perspective at a given point in time.
The SRS document itself states in precise and explicit language those functions and capabilities a software
system (i.e., a software application, an eCommerce Web site, and so on) must provide, as well as states any
required constraints by which the system must abide. The SRS also functions as a blueprint for completing a
project with as little cost growth as possible. The SRS is often referred to as the "parent" document because
all subsequent project management documents, such as design specifications, statements of work, software
architecture specifications, testing and validation plans, and documentation plans, are related to it.

It's important to note that an SRS contains functional and nonfunctional requirements only; it doesn't offer
design suggestions, possible solutions to technology or business issues, or any other information other than
what the development team understands the customer's system requirements to be.

A well-designed, well-written SRS accomplishes four major goals:

It provides feedback to the customer. An SRS is the customer's assurance that the development
organization understands the issues or problems to be solved and the software behavior necessary to
address those problems. Therefore, the SRS should be written in natural language (versus a formal
language, explained later in this article), in an unambiguous manner that may also include charts,
tables, data flow diagrams, decision tables, and so on.
 It decomposes the problem into component parts. The simple act of writing down software
requirements in a well-designed format organizes information, places borders around the problem,
solidifies ideas, and helps break down the problem into its component parts in an orderly fashion.

It serves as an input to the design specification. As mentioned previously, the SRS serves as the
parent document to subsequent documents, such as the software design specification and statement
of work. Therefore, the SRS must contain sufficient detail in the functional system requirements so
that a design solution can be devised.

It serves as a product validation check. The SRS also serves as the parent document for testing and
validation strategies that will be applied to the requirements for verification.

SRSs are typically developed during the first stages of "Requirements Development," which is the initial
product development phase in which information is gathered about what requirements are needed--and not.
This information-gathering stage can include onsite visits, questionnaires, surveys, interviews, and perhaps a
return-on-investment (ROI) analysis or needs analysis of the customer or client's current business
environment. The actual specification, then, is written after the requirements have been gathered and
analyzed.

SRS should address the following

The basic issues that the SRS shall address are the following:

● Functionality. What is the software supposed to do?

●
● External interfaces. How does the software interact with people, the system’s hardware, other
hardware, and other software?
●
● Performance. What is the speed, availability, response time, recovery time of various software
functions, etc.?
●
● Attributes. What are the portability, correctness, maintainability, security, etc. considerations?
●
● Design constraints imposed on an implementation. Are there any required standards in effect,
implementation language, policies for database integrity, resource limits, operating
environment(s) etc.

Characterstics of good SRS

An SRS should be

a) Correct
b) Unambiguous
c) Complete
d) Consistent
e) Ranked for importance and/or stability
f) Verifiable
g) Modifiable
h) Traceable
● Correct - This is like motherhood and apple pie. Of course you want the
specification to be correct. No one writes a specification that they know is
incorrect. We like to say - "Correct and Ever Correcting." The discipline is keeping
the specification up to date when you find things that are not correct.
● Unambiguous - An SRS is unambiguous if, and only if, every requirement stated
therein has only one interpretation. Again, easier said than done. Spending time on
this area prior to releasing the SRS can be a waste of time. But as you find
ambiguities - fix them.
● Complete - A simple judge of this is that is should be all that is needed by the
software designers to create the software.
● Consistent - The SRS should be consistent within itself and consistent to its
reference documents. If you call an input "Start and Stop" in one place, don't call it
"Start/Stop" in another.
● Ranked for Importance - Very often a new system has requirements that are
really marketing wish lists. Some may not be achievable. It is useful provide this
information in the SRS.
● Verifiable - Don't put in requirements like - "It should provide the user a fast
response." Another of my favorites is - "The system should never crash." Instead,
provide a quantitative requirement like: "Every key stroke should provide a user
response within 100 milliseconds."
● Modifiable - Having the same requirement in more than one place may not be
wrong - but tends to make the document not maintainable.
● Traceable - Often, this is not important in a non-politicized environment.
However, in most organizations, it is sometimes useful to connect the requirements
in the SRS to a higher level document. Why do we need this requirement?

PRACTICAL 3