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.

Stage-4: Developing the project

2
 Software Engineering

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

Practical-2

3
 Software Engineering

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

Requirements fall into two types:

4
 Software Engineering

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.

 Modifiable: The requirements of the user can change.

5
 Software Engineering

 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

Data flow

7
 Software Engineering

 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

Passenger Reservation Railway Reserve/Cancel Info Admin

Reservatio
n
Ticket Info Passenger Info

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

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

Practical-11

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

19