Lab Manual of Software Engineering Complete
Lab Manual of Software Engineering Complete
Of
Software Engineering
1|Page
Software Engineering Course Code: CSC601
Program Objectives
PSO1 Professional & Problem-Solving Skills: The ability to understand and analyse the problem
and develop algorithms & programs for the same, with efficient design and varying
complexity using lifelong learning and principles of computer engineering in the fields of
multimedia, web design, data management & analytics, networking &security, machine
learning & artificial intelligence etc. To apply standard practices and strategies in software
& hardware project development using open-source programming environments to deliver
a quality product for business success.
PSO2 Successful Career and Entrepreneurship: Ability to acquire logical thinking capability
and problem solving skill in computer engineering as well as diverse fields to achieve better
overall prospects of the employment or to be a successful entrepreneur and work as an
individual and as well as in a team to achieve solution within the budget and to communicate
effectively with the engineering community and the society and also to have a zest for higher
studies.
2|Page
Software Engineering Course Code: CSC601
Course Objectives
The main objective of the course is to introduce to the students about the product that is to be
engineered and the processes that provides a framework for the engineering methodologies
and practices.
1. To provide the knowledge of software engineering discipline.
2. To apply analysis, design and testing principles to software project development.
3. To demonstrate and evaluate real time projects with respect to software engineering
principles.
Course Outcomes
3|Page
Software Engineering Course Code: CSC601
INDEX
Sr. No. Name of Experiment Page No.
Prepare detailed statement (SRS) of problem for the selected / allotted 6-9
mini project and identify
1
suitable process model for the same with justification.
4|Page
Software Engineering Course Code: CSC601
5|Page
Software Engineering Course Code: CSC601
Experiment No. 1
6|Page
Software Engineering Course Code: CSC601
Experiment No. 1
Aim: To learn Software Requirement Specification (SRS) and design the documentation for
given project.
SRS Format:
The general format of SRS consists of:
i. Functional Requirements Definition
➢Functional requirements are a subset of the overall system requirement.
➢It measures the documentation and the inputs for the various requirements
In thesystem.
➢Starting from the specification and the data base schema, on how the
System should bedesigned.
<Project Name>
Software Requirements
Specification
<Version>
<Date>
<Your Name>
1.0.
Introduction
1.1 Purpose
7|Page
Software Engineering Course Code: CSC601
Term Definition
1.4 References
1.5 Overview
2.0. Overall
Description
2.4 Constraints
3.0. Specific
Requirements
Report
Generation:
Database:
3.4 Diagrams: Use – Case, UML as per the requirement of the project.
Problem Statement: Design a SRS for any one of the systems and develop the documentation
as given in the SRS template (Any other system that student can take)
8|Page
Software Engineering Course Code: CSC601
9|Page
Software Engineering Course Code: CSC601
Experiment No. 2
10 | P a g e
Software Engineering Course Code: CSC601
Experiment No. 2
Aim: To study RMMM RISK MANAGEMENT
Theory:
What is it?
• Analysis and management are a serious of steps that helps a software team to understand
and manage uncertainty.
• Many problems can plague a software project.
• A risk is a potential problem ‐ it might happen, it might not. But, regardless of the
outcomes, it’s a really good idea to identify it assess its probability of occurrence, estimate its
impact, and establish a contingency plan should the problem actually occur.
Why is it important?
Be prepared software is a difficult under taking. Lots of things can go wrong, and frankly,
many often do. It’s for this reason that being prepared‐ understanding the risk and taking
proactive measures to avoid or manage them‐is a key element of good software project
management [1]
A risk management strategy can be defined as a software project plan or the risk management
steps. It can be organized into a separate Risk Mitigation, Monitoring and Management Plan.
The RMMM plan documents all work performed as part of risk analysis and is used by the
project manager as part of the overall project plan.
Teams do not develop a formal RMMM document. Rather, each risk is documented
individually using a risk information sheet. In most cases, the RIS is maintained using a
database system, so that creation and information entry, priority ordering, searches, and other
analysis may be accomplished easily.
Once RMMM has been documented and the project has begun, risk mitigation and
monitoring steps commence. As we have already discussed, risk mitigation is a problem
avoidance activity. Risk monitoring is a project tracking activity with three primary
objectives:
(1) To assess whether predicted risks occur.
(2) To ensure that risk aversion steps defined for the risk are being properly applied; and
(3) To collect information that can be used for future risk analysis.
Effective strategy must consider three issues:
Risk avoidance
Risk monitoring
Risk management and contingency planning. Proactive approach to risk – avoidance
strategy. Develop risk mitigation plan. Develop a strategy to mitigate this risk for
11 | P a g e
Software Engineering Course Code: CSC601
reducing turnover. Meet with current staff to determine causes for turnover. Mitigate
those causes that are under our control before the project starts.
Organize project teams so that information about each development activity is widely
dispersed.
Define documentation standards and establish mechanisms to be sure that documents
are developed in a timely manner. Project manager monitors for likelihood of risk,
Project manager should monitor the effectiveness of risk mitigation steps. Risk
management and contingency planning assumes that mitigation efforts have failed and
that the risk has become a reality. RMMM steps incur additional project cost.
THE RMMM PLAN
Risk Mitigation, Monitoring and Management Plan (RMMM) – documents all work
performed as part of risk analysis and is used by the project manager as part of the overall
project plan. RIS is maintained using a database system, so that creation and information
entry, priority ordering, searches, and other analysis may be accomplished easily. Risk
monitoring is a project tracking activity
Three primary objectives:
assess whether predicted risks do, in fact, occur
ensure that risk aversion steps defined for the risk are being properly applied
collect information that can be used for future risk analysis.[2]
REFRENCES
http://cmstest.srmuniv.ac.in/sites/default/files/files/Risk%20Management.pdf
http://www.ques10.com/p/24877/explain-rmmm-also-explain-rmmm-plan/
Pre Lab Questions:
1. What are the steps in developing a software?
2. What are the steps involved in developing a SRS?
12 | P a g e
Software Engineering Course Code: CSC601
Experiment No. 3
13 | P a g e
Software Engineering Course Code: CSC601
Theory: Microsoft Project is a project management software product, developed and sold
by Microsoft. It is designed to assist a project manager in developing a plan,
assigning resources to tasks, tracking progress, managing the budget, and analysing workloads.
Microsoft Project was the company's third Microsoft Windows-based application, and within
a couple of years of its introduction it became the dominant PC-based project management
software.[1]
It is part of the Microsoft Office family but has never been included in any of the Office suites.
It is available currently in two editions, Standard and Professional. Microsoft
Project's proprietary file format is .mpp.
14 | P a g e
Software Engineering Course Code: CSC601
Screenshots:
Task View
15 | P a g e
Software Engineering Course Code: CSC601
Gantt Chart
Network Chart
16 | P a g e
Software Engineering Course Code: CSC601
Resource Sheet
Project Overview
Work Overview
17 | P a g e
Software Engineering Course Code: CSC601
Cost Overview
18 | P a g e
Software Engineering Course Code: CSC601
19 | P a g e
Software Engineering Course Code: CSC601
Experiment No. 4
20 | P a g e
Software Engineering Course Code: CSC601
Aim: Identify the scenarios & develop UML Use-case for the given scenarios:
1. Airport Check-in and Security Screening
2. Restaurant Management
3. Ticket Booking System
4. Bank ATM
5. Library Management System
6. Online Shopping
7. Credit Card Processing
8. Hospital Management System
Theory:
A use case diagram at its simplest is a representation of a user's interaction with the system
that shows the relationship between the user and the different use cases in which the user is
involved. A use case diagram can identify the different types of users of a system and the
different use cases and will often be accompanied by other types of diagrams as well. The use
cases are represented by either circles or ellipses.
The purpose of the use case diagrams is simply to provide the high level view of the system
and convey the requirements in laypeople's terms for the stakeholders. Additional diagrams
and documentation can be used to provide a complete functional and technical view of the
system.
Screenshots:
21 | P a g e
Software Engineering Course Code: CSC601
Resturant Management
22 | P a g e
Software Engineering Course Code: CSC601
Bank ATM
23 | P a g e
Software Engineering Course Code: CSC601
24 | P a g e
Software Engineering Course Code: CSC601
Conclusion: Thus the UML Use-case Diagrams haven been developed for the given scenarios.
25 | P a g e
Software Engineering Course Code: CSC601
Experiment No. 5
26 | P a g e
Software Engineering Course Code: CSC601
Aim: Identify the scenarios & develop UML Class Diagrams for the given scenarios:
1. Airport Check-in and Security Screening
2. Restaurant Management
3. Ticket Booking System
4. Bank ATM
5. Library Management System
6. Online Shopping
7. Credit Card Processing
8. Hospital Management System
Theory:
In software engineering, a class diagram in the Unified Modeling Language (UML) is a type
of static structure diagram that describes the structure of a system by showing the
system's classes, their attributes, operations (or methods), and the relationships among objects.
The class diagram is the main building block of object-oriented modeling. It is used for
general conceptual modeling of the structure of the application, and for detailed modeling
translating the models into programming code. Class diagrams can also be used for data
modelling. The classes in a class diagram represent both the main elements, interactions in the
application, and the classes to be programmed.
In the diagram, classes are represented with boxes that contain three compartments:
The top compartment contains the name of the class. It is printed in bold and centered, and
the first letter is capitalized.
The middle compartment contains the attributes of the class. They are left-aligned and the
first letter is lowercase.
The bottom compartment contains the operations the class can execute. They are also left-
aligned and the first letter is lowercase.
In the design of a system, a number of classes are identified and grouped together in a class
diagram that helps to determine the static relations between them. With detailed modelling, the
classes of the conceptual design are often split into a number of subclasses.
27 | P a g e
Software Engineering Course Code: CSC601
Screenshots:
Airport Check-in and Security Screening
Resturant Management
28 | P a g e
Software Engineering Course Code: CSC601
Bank ATM
29 | P a g e
Software Engineering Course Code: CSC601
30 | P a g e
Software Engineering Course Code: CSC601
31 | P a g e
Software Engineering Course Code: CSC601
Experiment No. 6
32 | P a g e
Software Engineering Course Code: CSC601
Aim: Identify the scenarios & develop UML Sequence Diagrams for the given scenarios:
1. Airport Check-in and Security Screening
2. Restaurant Management
3. Ticket Booking System
4. Bank ATM
5. Library Management System
6. Online Shopping
7. Credit Card Processing
8. Hospital Management System
Theory:
A sequence diagram shows object interactions arranged in time sequence. It depicts the objects
and classes involved in the scenario and the sequence of messages exchanged between the
objects needed to carry out the functionality of the scenario. Sequence diagrams are typically
associated with use case realizations in the Logical View of the system under development.
Sequence diagrams are sometimes called event diagrams or event scenarios.
A sequence diagram shows, as parallel vertical lines (lifelines), different processes or objects
that live simultaneously, and, as horizontal arrows, the messages exchanged between them, in
the order in which they occur. This allows the specification of simple runtime scenarios in a
graphical manner.
Screenshots:
Airport Check-in and Security Screening
33 | P a g e
Software Engineering Course Code: CSC601
Resturant Management
34 | P a g e
Software Engineering Course Code: CSC601
Bank ATM
35 | P a g e
Software Engineering Course Code: CSC601
36 | P a g e
Software Engineering Course Code: CSC601
Conclusion: Thus the UML Sequence Diagrams haven been developed for the given scenarios.
37 | P a g e
Software Engineering Course Code: CSC601
Experiment No. 7
38 | P a g e
Software Engineering Course Code: CSC601
Aim: Identify the scenarios & develop UML Activity Diagrams for the given scenarios:
1. Airport Check-in and Security Screening
2. Restaurant Management
3. Ticket Booking System
4. Bank ATM
5. Library Management System
6. Online Shopping
7. Credit Card Processing
8. Hospital Management System
Theory:
Activity diagrams are graphical representations of workflows of stepwise activities and
actions with support for choice, iteration and concurrency. In the Unified Modelling Language,
activity diagrams are intended to model both computational and organizational processes (i.e.,
workflows), as well as the data flows intersecting with the related activities. Although activity
diagrams primarily show the overall flow of control, they can also include elements showing
the flow of data between activities through one or more data stores.
Activity diagrams are constructed from a limited number of shapes, connected with
arrows. The most important shape types:
39 | P a g e
Software Engineering Course Code: CSC601
Screenshots:
Airport Check-in and Security Screening
Resturant Management
40 | P a g e
Software Engineering Course Code: CSC601
Bank ATM
41 | P a g e
Software Engineering Course Code: CSC601
42 | P a g e
Software Engineering Course Code: CSC601
43 | P a g e
Software Engineering Course Code: CSC601
Conclusion: Thus the UML Activity Diagrams haven been developed for the given scenarios.
44 | P a g e
Software Engineering Course Code: CSC601
Experiment No. 8
45 | P a g e
Software Engineering Course Code: CSC601
Product attributes
Required software reliability extent
Size of application database
Complexity of the product
Hardware attributes
Run-time performance constraints
Memory constraints
Volatility of the virtual machine environment
Required turnabout time
Personnel attributes
Analyst capability
Software engineering capability
Applications experience
Virtual machine experience
Programming language experience
46 | P a g e
Software Engineering Course Code: CSC601
Project attributes
Use of software tools
Application of software engineering methods
Required development schedule
Each of the 15 attributes receives a rating on a six-point scale that ranges from "very low" to
"extra high" (in importance or value). An effort multiplier from the table below applies to the
rating. The product of all effort multipliers results in an effort adjustment factor (EAF).
Typical values for EAF range from 0.9 to 1.4.
The Development time D calculation uses E in the same way as in the Basic COCOMO.
47 | P a g e
Software Engineering Course Code: CSC601
48 | P a g e
Software Engineering Course Code: CSC601
Experiment No. 9
49 | P a g e
Software Engineering Course Code: CSC601
Theory: A test case is a specification of the inputs, execution conditions, testing procedure,
and expected results that define a single test to be executed to achieve a particular software
testing objective, such as to exercise a particular program path or to verify compliance with a
specific requirement.[1] Test cases underlie testing that is methodical rather than haphazard. A
battery of test cases can be built to produce the desired coverage of the software being tested.
Formally defined test cases allow the same tests to be run repeatedly against successive
versions of the software, allowing for effective and consistent regression testing.
test case ID
test case description
test step or order of execution number
related requirement(s)
50 | P a g e
Software Engineering Course Code: CSC601
depth
test category
author
check boxes for whether the test can be or has been automated
pass/fail
remarks
Larger test cases may also contain prerequisite states or steps, and descriptions.
A written test case should also contain a place for the actual result.
These steps can be stored in a word processor document, spreadsheet, database or other
common repository.
In a database system, you may also be able to see past test results and who generated the results
and the system configuration used to generate those results. These past results would usually
be stored in a separate table.
Test suites often also contain
Test summary
Configuration
Besides a description of the functionality to be tested, and the preparation required to ensure
that the test can be conducted, the most time consuming part in the test case is creating the tests
and modifying them when the system changes.
Under special circumstances, there could be a need to run the test, produce results, and then a
team of experts would evaluate if the results can be considered as a pass. This happens often
on new products' performance number determination. The first test is taken as the base line for
subsequent test / product release cycles.
Acceptance tests, which use a variation of a written test case, are commonly performed by a
group of end-users or clients of the system to ensure the developed system meets the
requirements specified or the contract. User acceptance tests are differentiated by the inclusion
of happy path or positive test cases to the almost complete exclusion of negative test cases.
Topics: Write a test case on:
1. Pen
2. Login Page
3. Lift
4. Gmail
5. ATM
6. Android Phone
7. Bottle
Pre Lab Questions:
1. What is Software Testing?
2. Why is testing of software important?
Post Lab Questions:
51 | P a g e
Software Engineering Course Code: CSC601
52 | P a g e
Software Engineering Course Code: CSC601
Experiment No. 10
53 | P a g e
Software Engineering Course Code: CSC601
What is Bugzilla?
Features:
Requirements:
Currently supported database systems are MySQL, PostgreSQL, Oracle, and SQLite. Bugzilla
is usually installed on Linux using the Apache HTTP Server, but any web server that
supports CGI such as Lighttpd, Hiawatha, Cherokee can be used. Bugzilla's installation
process is command line driven and runs through a series of stages where system requirements
and software capabilities are checked.
History of Bugzilla:
54 | P a g e
Software Engineering Course Code: CSC601
Bugzilla 2.0 was the result of that port to Perl, and the first version was released to the
public via anonymous CVS.
Bugzilla 3.0 was released on May 10, 2007 and brought refreshed UI, XML-
RPC interface, custom fields and resolutions, mod_perl support, shared saved searches,
and improved UTF-8 support, along with other changes.
Bugzilla 4.0 was released on February 15, 2011 and Bugzilla 5.0 was released in July
2015.
Improve communication
Increase product quality
Improve customer satisfaction
Ensure accountability
Increase productivity
Bugzilla can adapt to multiple situations
The software isn't designed to diagnose or repair developed applications; however, users can
categorize, track and detail debugging procedures -- and other similar actions. This can be done
in both the predevelopment and post-development stages of the application. Additionally,
collaboration and reporting features simplify defect tracking, reduce deployment delays and
prevent app downtime.
The Bugzilla issue tracking system contains an interactive tracking spreadsheet that allows
users to submit new bug reports or other data that requires tracking or updating. The
spreadsheets provide options for basic information such as title, summary, description, status,
severity and resolution, but they also allow for more detailed input such as product, component,
version, operating system and keywords. Users can also use the Bugzilla tool to assign a bug
submission so they are notified of future changes to the report -- like when a resolution to the
bug is found.
Another useful feature of the Bugzilla software is automatic duplicate detection. If users
attempt to file a duplicate bug in the system, the software automatically checks for similar
existing bugs based off of the previously submitted summary details. If a duplicate bug is
detected, Bugzilla will then notify users and allow them to add themselves to the notification
list for future updates on the bug.
Other notable features offered in the Bugzilla tool include its advanced data reporting tools that
allow users to create custom tables and charts based on bug data, roles-based access modes,
advanced search functions and the ability to create or modify bugs by email. A detailed list of
the tool's features can be seen on the Bugzilla website.
References:
https://en.wikipedia.org/wiki/Bugzilla
https://www.bugzilla.org/
https://searchsoftwarequality.techtarget.com/feature/Track-project-changes-using-the-
Bugzilla-bug-tracking-tool
55 | P a g e
Software Engineering Course Code: CSC601
56 | P a g e