Software Engineering

Practical-1

Aim: Study the complete Software Development Life Cycle (SDLC) and analyse
various activities conducted as apart of various phases. For each SDLC phase,
identify the objectives and summaries outcomes.

➔ Software Development is the development of software for distinct purposes. For

software development, there is a specific programming language like Java, Python,
C/C++, etc. The entire process of software development isn’t as simple as its
definition, it’s a complicated process. Accordingly, it requires an efficient approach
from the developer in the form of the Software Development Life Cycle (SDLC).

➔ SDLC specifies the task to be performed at various stages by a software

engineer/developer. It ensures that the end product is able to meet the customer’s
expectations and fits in the overall budget.

➔ Hence, it’s vital for a software developer to have prior knowledge of this software
development process.

1
 Software Engineering

These 6 stages are discussed below :

Stage-1: Planning And Requirement Analysis:

➔ Planning is the crucial step in everything and so as in software development. In

this same stage, requirement analysis is also performed by the developers of the
organisation.

➔ This is obtained from the inputs from the customers, sales department/market
surveys.

➔ The information from this analysis forms the building block of a basic project. The
quality proof of the project is a result of planning. Thus, in this stage, the basic
project is designed with all the available information.

Stage-2: Defining Requirements:

➔ In this stage, all the requirements for the target software are specified. These
requirements get approval from the customers, market analysts, and
stakeholders.

➔ This is fulfilled by utilising SRS (Software Requirement Specification). This is a

sort of document that specifies all those things that need to be defined and
created during the entire project cycle.

Stage-3: Designing Architecture:

➔ SRS is a reference for software designers to come out with the best architecture
for the software. Hence, with the requirements defined in SRS, multiple designs
for the product architecture are present in the Design Document Specification
(DDS).

➔ This DDS is assessed by market analysts and stakeholders. After evaluating all
the possible factors, the most practical and logical design is chosen for the
development.

2
 Software Engineering

Stage-4: Developing the project

➔ In this phase of SDLC, the actual development begins, and the programming is
built. The implementation of design begins concerning writing code.

➔ Developers have to follow the coding guidelines described by their management

and programming tools like compilers, interpreters, debuggers, etc. are used to
develop and implement the code.

Stage-5: Testing

➔ After the code is generated, it is tested against the requirements to make sure that
the products are solving the needs addressed and gathered during the
requirements stage.

➔ During this stage, unit testing, integration testing, system testing, acceptance
testing are done.

Stage-6: Deployment

➔ Once the software is certified, and no bugs or errors are stated, then it is
deployed.

➔ Then based on the assessment, the software may be released as it is or with

suggested enhancement in the object segment.

➔ After the software is deployed, then its maintenance begins.

Stage-7: Maintenance

➔ Once when the client starts using the developed systems, then the real issues
come up and requirements to be solved from time to time.

➔ This procedure where the care is taken for the developed product is known as
maintenance.

3
 Software Engineering

Practical-2

Aim: To perform the system analysis: Requirement analysis, SRS.

→ Software requirement analysis simply means complete study, analysing,

describing software requirements so that requirements that are genuine and
needed can be fulfilled to solve problem. There are several activities involved
in analysing Software requirements.

• What is Software Requirements Specification (SRS)?

→ A software requirements specification (SRS) is a document that captures

complete description about how the system is expected to perform. It is usually
signed off at the end of requirements engineering phase.

➢ Qualities of SRS:

• Correct
• Unambiguous
• Complete
• Consistent
• Ranked for importance and/or stability
• Verifiable
• Modifiable
• Traceable

4
 Software Engineering

Requirements fall into two types:

1. Functional requirements
2. Non – Functional requirements

1. Functional requirements
→ Any requirement which specifies what the system Should do.

→ A functional requirement will describe a particular behaviour of function the

system when certain conditions are met.
for example: “Send email when a new customer signs up” or “Open a
new account”.

2. Non-Functional requirements
→ Any requirement which specifies how the system performs a certain function.

→ A non-functional requirement will describe how a system should behave and

what limits there are on its functionality.

Characteristics of good Software Design

→ SRS should be accurate, complete, efficient, and of high quality, so that it does
not affect the entire project plan.

→ An SRS is said to be of high quality when the developer and user easily
understand the prepared document.

➢ Characteristics of a Good SRS:

• Correct: Correctly implement all the functionalities of the system.

• Understandability: Unless a design solution is easily understandable,

It would be difficult to implement and maintain it.

• Maintainability: Easy to change.

• Complete: SRS is complete when the requirements clearly define what

the software is required to do.

• Ranked for Importance/Stability: All requirements are not equally

hence requirement is identified to make difference
among other requirements.

5
 Software Engineering

• Modifiable: The requirements of the user can change.

• Traceable: SRS is traceable when the source of each requirement is clear

and facilitates the reference of each requirement in future.

• Verifiable: SRS is verifiable when the specified requirements can be

verified cost-effective process to check whether the final
software meets those requirements.

• Consistent: SRS is consistent when the subsets of individual

requirements defined do not conflict with each other.

Problems Without SRS

→ Without developing the SRS document, the system would not be properly
implemented according to customer needs.

→ Without SRS, it will be very difficult for the maintenance engineers to

understand the functionality of the system.

6
 Software Engineering

Practical-3

Aim: To perform the function-oriented diagram: DFD and Structured chart.

• Function Oriented design
→ Function Oriented design is a method to software design where the model is
decomposed into a set of interacting units or modules where each unit or
module has a clearly defined function. Thus, the system is designed from a
functional viewpoint.

• DFD (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.

→ Data Flow diagrams are very popular because they help us to visualize the
major steps and data involved in software-system processes.

→ In Software engineering DFD (data flow diagram) can be drawn to represent the
system of different levels of abstraction.

Notation Symbol

External entities

Process

Data store

7
 Software Engineering

Data flow

→ Higher-level DFDs are partitioned into low levels-hacking more information and
functional elements. Levels in DFD are numbered 0, 1, 2 or beyond.

→ Here, we will see mainly 3 levels in the data flow diagram:

1) 0-level DFD
2) 1-level DFD
3) 2-level DFD

1) 0-level DFD

• It is also known as a context diagram. It’s designed to be an abstraction view,

showing the system as a single process with its relationship to external entities.

• It represents the entire system as a single bubble with input and output data
indicated by incoming/outgoing arrows.

Cancellation Up/Down Train Info

Reservation Reserve/Cancel Info Admin

Passenger Railway
Ticket Info
Reservatio Passenger Info
n

2) 1-level DFD

→ In 1-level DFD the context diagram is decomposed into multiple

bubbles/processes.

→ In this level, we highlight the main functions of the system and breakdown the
high-level process of 0-level DFD into subprocesses.

8
 Software Engineering

3) 2-level DFD

→ 2-level DFD goes one step deeper into parts of 1-level DFD. It can be used to
plan or record the specific/necessary detail about the system’s functioning.

9
 Software Engineering

Structure Charts

→ Structure Charts represent hierarchical structure of modules. It breaks down

the entire system into lowest functional modules, describe functions and sub-
functions of each module of a system to a greater detail.

→ Structure Chart partitions the system into black boxes (functionality of the
system is known to the users but inner details are unknown). Inputs are given
to the black boxes and appropriate outputs are generated.

• Symbols used in construction of structured chart

1. Module
It represents the process or task of the system. It is of three types.

a. Control Module
A control module branches to more than one sub module.

b. Sub Module
Sub Module is a module which is the part (Child) of another module.
c. Library Module
Library Module are reusable and invokable from any module.

10
 Software Engineering

2. Conditional Call
→ It represents that control module can select any of the sub module on the basis
of some condition.

3. Loop (Repetitive call of module)

→ It represents the repetitive execution of module by the sub module.
A curved arrow represents loop in the module.

→ All the sub modules cover by the loop repeat execution of module.

11
 Software Engineering

4. Data Flow
→ It represents the flow of data between the modules. It is represented by directed
arrow with empty circle at the end.

5. Control Flow
→ It represents the flow of control between the modules. It is represented by
directed arrow with filled circle at the end.

6. Physical Storage

→ Physical Storage is that where all the information is to be stored .

12
 Software Engineering

Example: Structure chart for an Email server

13
 Software Engineering

Practical-4

Aim: To perform the user’s view analysis: Use case diagram for railway
reservation system.

Manage Users and Full application Book Tickets

Manage Booking Search Vacant Seat

Manage Booking Collect Payment

Login and Logout from System

Logout from s

Update My profile

Change Account Password

Manage Payment Book Tickets

Manage Ticket Make Payments

Manage Train Schedule Search Trains

14
 Software Engineering

Practical-5

Aim: To draw the structural view diagram: Class diagram for library
management system.

15
 Software Engineering

Practical-6
Aim: To draw the behavioural view diagram: Activity diagram for flight control
system.

Login to the flight control System

Check user level and permission

16
 Software Engineering

Practical-8

Aim: To study cost estimation and preparation of timeline chart.

• What is cost estimation?

→ Cost estimation in project management is the process of forecasting the cost

and other resources needed to complete a project within a defined scope. Cost
estimation accounts for each element required for the project and calculates a
total amount that determines a project’s budget.

→ If a project cost management system such as a software tool is used, and it

encompasses all the units of project controls, it would not be possible to ignore
the execution changes after the budget is baselined from the estimate data.

→ Cost estimation is used to predict the quantity, cost and price of the resources
required by the scope of a project. A project might be any process that is started
to perform work activities and/or create assets.

→ Cost estimation is needed to provide decision-makers with the means to make

investment decisions, choose between alternatives and to set up the budget
during the front end of projects.

→ For this, estimates made by vendors and contractors need to be validated by

clients as well. In later phases of the project, the budget estimate is used as a
baseline to assess the performance of a project.

→ Related to this principle, it is always challenging to collect and read the huge
amount of cost data, which doesn’t help with the decision making. Analysing
and visualizing the cost data opens the doors to making the data useful and
meaningful.

17
 Software Engineering

→ The dashboards of a project control software system are the data-driven

graphical representations of a project; dashboards can provide decision-
makers with a quick overview of a project’s progress and turn the data into
decision points.

→ A cost estimate is more than a list of costs. It also includes a detailed Basis of
Estimate (BOE) report that describes the assumptions, inclusions, exclusions,
accuracy and other aspects that are needed to interpret the total project cost.
Otherwise, it would be a meaningless number.

→ The BOE is required to communicate the estimate to the various parties

involved in the decision making but is also handy during closeout when the
performance of the project is compared with other projects.

→ Cost estimation, however, is easier said than done. An accurate estimation

method can be the difference between a successful plan and a failed one.

→ Make sure to set up the estimate in a structured way to allow for an easy
transition into project cost estimating software, which will help you make more
solid and accurate estimates in the long run.

18
 Software Engineering

Project Timeline
Analysis Conent entry Maintenance

Proposal Designing Testing

Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec

Research Implements Deployment

Planning Coding Go-live

Practical-11

Aim: Generate a test suite using the white box testing strategies.

19