Green University of Bangladesh

Department of Computer Science and Engineering (CSE)

Semester: (Spring, Year: 2024), B.Sc. in CSE (Day)

Course Title: Software Enginerring

Course Code: CSE 313
Section: 221 D7
Students Details

Name ID
MD Mohibullah Ahmed Foysal 221902275

Submission Date: 26-06-2024

Course Teacher’s Name: MD Zahidul Islam

[For teachers use only: Don’t write anything inside this box]
 Lab Project Status

Marks: Signature:

Comments: Date:

Contents
1 Executive Summary/Synopsis 2

2 Introduction 3

3 Project Charter 3
3.1 Project Objectives . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2 Software Development Approach . . . . . . . . . . . . . . . . . 4
3.3 Software Requirement Specification . . . . . . . . . . . . . . . 4
3.4 Data Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . . 5
3.5 Project UML Diagrams . . . . . . . . . . . . . . . . . . . . . . 5

4 Findings 8
4.1 Work Breakdown Structure . . . . . . . . . . . . . . . . . . . 8
4.2 Project Cost Baseline . . . . . . . . . . . . . . . . . . . . . . . 8
4.3 Quality Management . . . . . . . . . . . . . . . . . . . . . . . 9
4.4 Quality policy . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.5 Quality Review . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.6 Test Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

5 Discussion 10
5.1 Risk Management . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2 Risk Management Plan . . . . . . . . . . . . . . . . . . . . . . 10

6 Conclusion 11

7 References 11

Abstract
The development process that a group uses to design software is
important for determining the success of a project. Although consider-
able research discusses processes best suited for large companies, this
paper presents a case study of software development by a small group
and considers the process taken towards the completion of a project.

1
 The collaborative undergraduate team project analyzed included the
design and development of a cell phone game using the programming
language Java 2 Micro Edition. Many development processes exist,
such as the waterfall model, the spiral model, the unified process, and
extreme programming. These were compared with the process the
team used. The analysis suggests the process was too detailed for a
small group environment. In this situation, it was found that less time
should have been spent on design. My research shows the need for a
simplified method usable by small groups that allows adaptation to
changes and takes advantage of the close communication environment
of the group.

1 Executive Summary/Synopsis
Case study technique was first presented into social science by Frederic Le
Play in 1829 as a handmaiden to indicators in his studies of family financial
plan. Case studies are studies of persons, actions, choices, stages, projects,
strategies and organizations are considered holistically by one or more ap-
proaches.

It is a research approach, an experimental analysis that scrutinizes an

occurrence within its real life perspective. Case study research can mean sin-
gle and various case studies can contain measureable substantiation, trusts
on several sources of substantiation, and paybacks from the previous develop-
ment of hypothetical propositions.

Software engineering (SE) is the application of a methodical, well-organized,

countable method to the strategy, development, procedure, and maintenance
of software, and the revision of these methods; that is, the application of
engineering to software.

• A Software Development Life Cycle (SDLC) is fundamentally a se-

quence of phases that offer a model for the development and lifecycle
management of software.

• SDLC in SE, information systems and SE is a process of generating or

modifying information systems, and the models and approaches that
people use to develop these systems.

• Software Project Management (SPM) is the talent and science of devel-

opment and leading software projects. It is a sub-discipline of project

2
 management in which software projects are intended, realized, super-
vised and organized.

2 Introduction
Case studies were first used in the Harvard Law School in 1871. Meanwhile
then, case studies have been a subject of much study and research about
their usefulness in teaching and learning. They have become a supported
and ubiquitous way of teaching about professional training in such fields as
commercial, law, and medicine. In its most simple form, it merely denotes
to a genuine illustration used to demonstrate a thought. More formerly,
and for the dedications of the Case Study Task, a case study encompasses
the application of understanding and abilities, by an individual orgroup, to
the identification and answer of a problem related with a realistic situation.

The Case Study Project (OTPS) focuses on developing case modules,

which are associated by being part of and derived from a single case, the
development of a single software product. Each case module relates to a
movement involved in the development of the product. In addition, each
case component is outlined as part of a product development description, us-
ing a scenario format, which involves characters and occurrences that might
be part of a real SPM (e.g., creation of a software project team, communi-
cation with upper management, customer and customer meetings, Creation
of Problem Identification, Project Charter, Scope Management, Time Man-
agement, Cost Management, Quality Management, Communication Manage-
ment, Risk Management., etc.).

3 Project Charter
3.1 Project Objectives
Develop an automated OTPS for Telecom Company helps site engineer to
manage the information about towers, sites and users effectively. OTPS
manages the various types of networks like GSM and CDMA. The different
mobile switching controls are allocating to different site engineers to maintain
the whole database. OTPS is replacing the existing in which information is
managing manually.

3
3.2 Software Development Approach
• Develop a survey in various telecom companies to determine the im-
portant features of OTPS.

• Review the documents of other similar systems relating to the OTPS.

• Develop online tower plotting system using Rapid Application Devel-

opment.

• Collecting the whole information about the towers and sites from Tele-
com Company.

3.3 Software Requirement Specification

Document Convention: : OTPS - Online Tower Plotting System etc.

• OTPS Features

• User Classes and Characteristics

• Assumptions and Dependencies

• System Features

– Search
– Tower Definition
– Distance Calculation

• External Interface Requirements

– User Interfaces
– Hardware Interfaces
– Software Interfaces
– Communications Interfaces

• Other Nonfunctional Requirements

– Performance Requirements
– Safety Requirements
– Security Requirements
– Software Quality Attributes

4
3.4 Data Flow Diagram
A data flow diagram (DFD) is a graphical demonstration of the ”flow” of data
through an information system, modelling its process features.

Figure 1: Context level DFD

3.5 Project UML Diagrams

UML (Unified Modelling Language) is a graphical language for envisaging,
specifying, creating and documenting the artifacts of OTPS. The UML gives
a standard way to write an OTPS’s blueprint, covering conceptual things,
such as business processes and OTPS functions as well as such as classes writ-
ten in a particular Programming Language, databases schema and reusable
software components.
Use Case Diagram: he use case diagram is essential modelling the
behaviour of the OTPS, subsystem or classes. The interaction among use
cases and actors is described in this diagram.
Class Diagram: A class diagram shows a collection of classes, inter-
faces,associations and their interactions. The class diagram of OTPS (Login)
is shown in Figure 5.

5
 Figure 2: First level DFD

Figure 3: Second level DFD

6
 Figure 4: Use Case Digram

Figure 5: Class Diagram

Activity Diagram: Activity diagrams are graphical representations of

workflows of stepwise activities and actions with sustenance for selection,
repetition and concurrency. Activity diagrams show the overall flow of con-
trol.The activity diagram of OTPS is shown in Figure 6.
Sequence Diagram: A sequence diagram is a kind of interaction di-
agram that shows how processes operate with one another and in what-
everdirection. A sequence diagram displaysitemcollaborationsorganized in
time order. It represents the objects and classes used in the scenario and
the sequence of messages exchanged between the objects needed to carry out
the functionality of the scenario. The sequence diagram of OTPS (Login) is
shown in Figure 7.

7
 Figure 6: Activity Digram

Figure 7: Sequence Diagram

4 Findings
4.1 Work Breakdown Structure
A work breakdown structure (WBS), in project management and systems
engineering, is a deliverable basedbreakdown of a project into minor compo-
nents. It describes and clusters a project’s isolated work elements in a way
that helps organize and define the total work scope of the project. The phase
based WBS is shown in, it explains all the phases of SDLC.

4.2 Project Cost Baseline

The project cost baseline is the foundation for the earned value record-
ingscheme. It is the financial plan for the projectedbudget of the project
spread over the time periods of the project.The project cost standard is the
portion of the project concerned with the quantity of money that the project
is forecast to charge and when that cash will be used.

8
4.3 Quality Management
The aim of Quality Management (QM) is to manage the quality of software
and of its development process. A quality product is one which meets its
requirements and satisfies the user. A quality culture is an organizational
environment where quality is viewed as everyone’s responsibility

4.4 Quality policy

We are committed to develop a high quality, technical and engineered soft-
ware product, which is efficiently adoptable by different multinational orga-
nizations whosoever, works in the telecom operator domain. This software
is used by the site engineer of telecom operator organization and provides
technical support to the engineer and assists him/her in facilitating their
work, which was quite tedious to be managed manually. Thus it provide
support to their job such that they can efficiently, precisely and confidently
configure and manage their respective sites and have a confidence their useful
and important information is secure and nobody as intruder can exploit and
corrupt the confidential information.

4.5 Quality Review

A process or meeting during which a software product is examined by project
workforces, administrators, consumers, customers, user senates, or other in-
terested parties for comment or approval. Different type of quality reviews
are describe.

4.6 Test Plan

The test plan for OTPS is described:

• Unit Testing: In order to test a single module, we will provide

the completeenvironment to test each module independentlylike Login,
Tower information, search, calculate distance and upload file

• Black Box Testing: The test cases are designed from an examination
of the input/output values only without considering code.

• White Box Testing: This strategy aims to design test cases so that
every statement in a coding part is executed at least once, to check the
error if exist.

9
5 Discussion
5.1 Risk Management
Risk management is the identification, valuation, and ranking of riskstrailed
by synchronized and inexpensive application of resources to reduce, observer,
and control the likelihood and influence of unsuccessfulactions or to maximize
the apprehension of occasions.

5.2 Risk Management Plan

Risk Management Plan is a manuscript that a project manager organizes to
foreknow risks, guesstimateinfluences, and describecomebacks to problems.
It also encompasses a risk assessment matrix. The risk management plan is
described in Table 1:

Risk Id Risk Name Category Probability Impact

R-101 RAD Process Project 35% 1
Model(uncontrolled
manner)
R-102 Schedule Esti- Project 40% 2
mate may less
R-103 Cost Estimate Project 40% 3
may be low
R-104 Team members Project 30% 2
lack of skill
R-105 Lack in hard- Project 40% 4
ware
R-106 Customer may Project 35% 2
feel uncom-
fortable with
excessive fea-
tures
R-107 Internet Con- Technical 50% 1
nection

Table 1: Risk Management Plan

10
6 Conclusion
The case teaching method has been used effectively in many professions (law,
medicine, and business) to teach about how to solve problems and make deci-
sions, while dealing with genuine circumstances, working with real-world re-
strictions, and engaging with both human and technical issues. Although the
use of the case module in teaching software engineering has been restricted,
the discipline is key candidate for such a procedure. The Case Study Project
described in this paper has the objective of building a framework for using
the case module for teaching software engineering. The goal of the OTPS
software system is to provide a single comprehensive and complete example of
the engineering of a software product. In addition, the project provides case
modules (mini case studies), which can be used to teach various software
engineering topics. Future work will consist of testing of the current case
study materials and ongoing development of the case study for subsequent
phases and distribute the complete project in different software engineers. It
is envisioned that the project will take about three years to complete.

7 References
• Merriam, Sharan B. Qualitative Research and Case Study Applications
in Education. Revised and Expanded from” Case Study Research in
Education.”.Jossey-Bass Publishers, 350 Sansome St, San Francisco,
CA 94104, 1998.
• Merriam, Sharan B. Case Study Research in Education. A Qualitative
Approach. Jossey-Bass Inc., Publishers, PO Box 44305, San Francisco,
CA 94144-4305, 1988.
• Stake, Robert E. ”The art of case study research.” (1995).
• Eisenhardt, Kathleen M. ”Building theories from case study research.”
Academy of management review (1989): 532-550.
• Gerring, John. Case study research: principles and practices. Cam-
bridge: Cambridge University Press, 2007.
• Feagin, Joe R., Anthony M. Orum, and Gideon Sjoberg. Case for the
case study. UNC Press Books, 1991.
• Boehm, Barry W. ”Software engineering economics.” Software Engi-
neering, IEEE Transactions on 1 (1984): 4-21.

11