PRACTICAL JOURNAL OF SOFTWARE ENGINEERING

AND AGILE

BE: III Year

Department of Computer Science and Information Technology

Name : Varun Yeolekar

Branch : CI-3 VI semester

Section : 03

Roll No. : 0827CI211200

Session : JAN-JUNE 2024

Department of Computer Science and Information Technology

AITR, Indore.
 ACROPOLIS INSTITUTE OF TECHNOLOGY & RESEARCH, INDORE

Department of Computer Science Engineering

Certificate

This is to certify that the experimental work entered in this journal as per
the BE II year syllabus prescribed by the RGPV was done by Mr. Varun

Yeolekar BE III year VI semester CI in the Software Engineering and Agile

Laboratory of this institute during the academic year 2022- 2023.

Signature of Faculty

Prof. Nisha Rathi

 Acropolis Institute of Technology and Research, Indore

Department of Computer Science and Information Technology

CSIT Vision

To develop competent professionals to become a valuable source for industry, nation

and humanity by adapting industry inspired practices.

CSIT Mission

1. To strengthen industry collaboration for maximizing career opportunities ,

professional and entrepreneurship skills .
2. To improve employment marketability, positive attitude , communication skills
and learning agility.
3. To Facilitate value-based research and innovation for broadening knowledge,
skills and intellectual abilities
 Acropolis Institute of Technology and Research, Indore
Department of Computer Science and Information Technology
Course Objective:
The subject/course objectives support the program objectives and outcomes. This subject will help students
to learn and understand the concept of
601.CEO1 This course introduces the concepts and methods required for the construction of large
software intensive systems.

601.CEO2 The course aims are to develop a broad understanding of the discipline of software

engineering and management of software systems.

Course Outcome:
Upon completion of this subject / course the student will be able to:
Bloom’s level of Course Outcomes
learning

C601.1 Knowledge, Apply project management concepts and techniques to an IT project.

understand
Apply , Analyze
C601.2 Knowledge, Identify issues that could lead to IT project success or failure.
understand
Apply , Analyze
C601.3 Knowledge, . Explain project management in terms of the software development
understand process.
Apply

C601.4 Knowledge, Describe the responsibilities of IT project managers.

understand

C601.5 Knowledge, Apply project management concepts through working in a group as team
understand leader or active team member on an IT project.
Apply
 Acropolis Institute of Technology and Research, Indore
Department of Computer Science and Information Technology

GENERAL INSTRUCTIONS FOR LABORATORY CLASSES

DO’S
❖ Without Prior permission do not enter into the Laboratory.
❖ While entering into the LAB students should wear their ID cards.
❖ The Students should come with proper uniform.
❖ Students should sign in the LOGIN REGISTER before entering into the
laboratory.
❖ Students should come with observation and record note book to the laboratory.
❖ Students should maintain silence inside the laboratory.
❖ After completing the laboratory exercise, make sure to shutdown the system
properly

DONT’S

❖ Students bringing the bags inside the laboratory.

❖ Students using the computers in an improper way.
❖ Students scribbling on the desk and mishandling the chairs.
❖ Students using mobile phones inside the laboratory.
❖ Students making noise inside the laboratory.
 Acropolis Institute of Technology and Research, Indore
Department of Computer Science and Information Technology
Syllabus

I Course Contents: UNIT I: Introduction, Software- problem and prospects Software

development process: Software life cycle models, Open source software
development, the unified process, documentation, configuration management,
Safety, risk assessment.
II UNIT II: Measures, Metrics and Indicators, Metrics in the Process and Project
Domains, Software Measurement, Metrics of Software Quality, S/W reliability,
Software estimation techniques, loc and FP estimation. Empirical models like
COCOMO, project tracking and scheduling, reverse engineering

III . UNIT III: Software requirements and specification: feasibility study,

Informal/formal specifications, pre/post conditions, algebraic specification and
requirement analysis models, Specification design tools. Software design and
implementation: Software design objectives, design Like, Top-Down, bottom-up,
team etc. techniques, User interface design, modularity Functional decomposition
Data flow design, Data structure design, Object-oriented design, Design patterns
implementation strategies.

IV UNIT IV: Coding standard and guidelines, programming style, code sharing, code
review, software components, rapid prototyping, specialization, construction, class
extensions, intelligent software agents, reuse performance improvement, debugging.
Software Testing Strategies: Verification and Validation, Strategic Issues, test plan,
white box, black-box testing, unit and integration testing, system testing test case
design and acceptance testing, maintenance activities.

V UNIT V: Agile Vs Traditional SDLC Models, Phases of Agile Model, Principles of

Agile model, Agile Model - Pros and Cons, , When to use the Agile Model? , Agile
Testing Methods, Scrum, Product Backlog, Scrum Practices, Process flow of Scrum
Methodologies, extreme Programming (XP), Phases of eXtreme programming,
Crystal Methodologies, Dynamic Software Development Method (DSDM), Feature
Driven Development (FDD), Lean Software Development, KANBAN, Agile metrics.
 cropolis Institute of Technology and Research, Indore
Department of Computer Science and Information Technology

University List of Experiments

1. Identifying the requirements from problem statements.

2. Modeling UML use case diagram & capturing use case scenarios.

3. E-R modeling from the problem statements.

4. Activity & state chart modeling.

5. Modeling UML class diagram & collaboration diagrams/sequence diagrams.

6. Identifying domain classes from the problem statements.

7. Modeling DFD.

8. Designing test suite.

9. Estimation of test coverage metrics & structural complexity.

10. Estimation of project metrics.

 Acropolis Institute of Technology and Research, Indore
Department of Computer Science and Information Technology
HARDWARE REQUIREMENTS:

Processors - 2.0 GHz or Higher

RAM - 256 MB or Higher
Hard Disk - 20 GB or Higher

SOFTWARE REQUIREMENTS

Operating System: Windows 7/8/10

Rational Rose

Teaching and Examination Scheme

Maximum Marks Allotted Hours/Week Credits
Theory Practical
Subject Code

L T P
Quiz, Assignment
Subject

Mid Sem. Test

Name

Assignment
Lab work
End Sem.

End Sem.

sessional

Marks
Total

Software 70 20 10 30 20 150 2 1 2 4
CSIT-
Engineering &
601
Agile
 Acropolis Institute of Technology and Research, Indore
Department of Computer Science and Information Technology
RATIONALE:

Software engineering is the process of designing, developing, testing, and maintaining software. It is a
systematic and disciplined approach to software development that aims to create high-quality, reliable,
and maintainable software. Software engineering includes a variety of techniques, tools, and
methodologies, including requirements analysis, design, testing, and maintenance.

There are several advantages to using a systematic and disciplined approach to software
development, such as:

Improved quality: By following established software engineering principles and techniques, software
can be developed with fewer bugs and higher reliability.

Increased productivity: Using modern tools and methodologies can streamline the development
process, allowing developers to be more productive and complete projects faster.

Better maintainability: Software that is designed and developed using sound software engineering
practices is easier to maintain and update over time.

Reduced costs: By identifying and addressing potential problems early in the development process,
software engineering can help to reduce the cost of fixing bugs and adding new features later on.

Increased customer satisfaction: By involving customers in the development process and developing
software that meets their needs, software engineering can help to increase customer satisfaction.

Better team collaboration: By using Agile methodologies and continuous integration, software
engineering allows for better collaboration among development teams.

Better scalability: By designing software with scalability in mind, software engineering can help to
ensure that software can handle an increasing number of users and transactions.

Better Security: By following the software development life cycle (SDLC) and performing security
testing, software engineering can help to prevent security breaches and protect sensitive data.

Acropolis Institute of Technology and Research, Indore

Department of Computer Science and Information Technology
 Lab Plan

Software Engineering and Agile

S. Name of Experiment Report/Diagram
No.
1 Problem Selection and writing problem statement using 5 Problem Statement
W’s Worksheet
2 Feasibility Study
• Economic Feasibility
• Technical Feasibility Feasibility Report

• Operational Feasibility And Gantt Chart

• Scheduled Feasibility
Legal Feasibility
3 Identifying the requirements from problem statements. Requirement Gathering
Functional and Non Functional Requirements
4 Estimation of project metrics Estimation Reports

5 Modeling UML use case diagram & capturing use case Use Case Diagram
scenarios.
6 E-R modeling from the problem statements ER Diagram

7 Activity & state chart modeling. Activity Diagram

8 Sequence diagrams.
Sequence Diagram

9 Modeling DFD. Data-Flow Diagram

10 Designing test suite. Test Cases

11 User Stories and Acceptance Criteria User Stories and

Acceptance Criteria

Varun Yeolekar 0827CI211200

Software Engineering and Agile Lab Practical 1

 EXPERIMENT NO. 1

Identifying the Problem and write Problem Statements

Problem Statement
A problem statement in software development gives a developer the ability to understand clearly the issue
and then architect a solution. Put simply, a problem statement clearly defines - in a concise but comprehensive
way - a key business problem that needs to be solved.

In software development, the problem statement says, “What has to be done” for a project to succeed - to meet
the needs of its stakeholders who are external to the development. When you do not have a well- thought
problem statement, you risk building a product that solves the wrong problem.

The problem statement is a tool for the stakeholders and developers to communicate in concise, plain
language, about what tasks are being paid for, and what must be accomplished conceptually for the project
to be a success. The problem statement forces all parties involved (including the development team’s leaders),
to reach an agreement about what they are doing.

There are different methods for building a problem statement, but the most popular is breaking down the
problem statement creating into the 5 W's.

1. What: Begin with a clear, brief statement of the problem. In one to three sentences, explain exactly what
the issue is and how the problem affects the company.

2. Where: Explain what sector of your business the problem is affecting and whether it has triggered related
problems.

3. Who: Name the stakeholders whose goals are impeded by the specific issue at hand.

4. When: Lay out the timeframe during which the problem has existed.

5. Why: Articulate why this extant problem matters, and why it prevents the company from moving forward
toward its goals. This item can include everything from financial costs to damaged morale to literal physical
objects blocking a path.
6. Proposed solution (optional): While the problem statement should spend more time identifying the
factors surrounding the issue and making a case for taking it seriously, it may be appropriate to provide
potential solutions as well. Consider whether it would be more helpful to list proposed solutions or simply
provide questions for the team to think about during brainstorming sessions.

Experiment Specific Instructions:

Create a Problem Statement report based on 5 W’s

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2024
 Problem Statement Worksheet
Name: Varun Yeolekar

Roll No. 0827CI211200

Problem Statement:
Implementing electronic voting (e-voting) systems introduces challenges such as ensuring security, protecting
voter privacy, mitigating cyber threats, and providing equal access.

Meaning Key Questions Answers

WHO (Who has the This problem impacts various stakeholders, including voters, election
problem) authorities, technology developers, cybersecurity experts, policymakers,
legislators, and the general public.

WHAT (What is the The problem involves challenges associated with implementing electronic
Problem) voting (e-voting) systems, such as ensuring security, protecting voter privacy,
mitigating cyber threats, and providing equal access.

WHY Why is it It is important to address the e-voting challenges to uphold the integrity of the
important for democratic process, maintain public trust, and ensure fair and accurate
the customers election outcomes. Failure to address these issues could lead to compromised
to elections and erode confidence in the electoral system.
address?

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2024
WHERE (When and The problem occurs in the implementation and operation of e-voting systems
Where Does the during elections. The impact is felt wherever electronic voting is adopted. The
Problem occur) problem needs to be addressed in a timely manner, especially before
WHEN upcoming elections.
The problem has become prominent with the increasing adoption of e-voting
systems. It needs to be addressed promptly to prevent potential issues in
future elections.

HOW The problem of implementing electronic voting (e-voting) systems can be

solved by collaborating on transparent and secure development, ensuring
user-friendly interfaces, implementing strong identity verification, protecting
voter privacy, employing robust cybersecurity measures, raising public
awareness, and establishing a supportive legislative framework.

What are the key Key Issues:

issues you are trying • Security: Ensuring the integrity and security of e-voting systems to prevent
to manipulation, fraud, and unauthorized access.
address?? • Privacy: Safeguarding voter privacy by implementing measures to protect
Why is it important? sensitive information and voting choices.
• Cyber Threats: Mitigating the risk of cyber threats, such as hacking and
malware, to maintain the trustworthiness of the electoral process.
• Equal Access: Providing equal access to all eligible voters, irrespective of
technological proficiency, disabilities, or geographical location.
• Democracy Integrity: Addressing these issues is crucial for maintaining the
integrity of the democratic process and ensuring that election outcomes
accurately reflect the will of the people.
• Public Trust: By addressing these key issues, trust in the electoral system is
preserved, fostering confidence among voters in the fairness and accuracy of
elections.
• Security and Privacy: Protecting the security and privacy of voters is a
fundamental requirement to uphold democratic principles and respect
individual rights.
• Inclusivity: Ensuring equal access promotes inclusivity, allowing all eligible
citizens to participate in the electoral process, regardless of their background
or circumstances.

Software Engineering and

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2024
 EXPERIMENT NO
.Feasibility Study

Feasibility Study in Software Engineering is a study to evaluate feasibility of proposed project or

system. Feasibility study is one of stage among important four stages of Software Project Management
Process. As name suggests feasibility study is the feasibility analysis or it is a measure of the software
product in terms of how much beneficial product development will be for the organization in a practical
point of view. Feasibility study is carried out based on many purposes to analyze whether software product
will be right in terms of development, implantation, contribution of project to the organization etc.

Types of Feasibility Study :

The feasibility study mainly concentrates on below five mentioned areas. Among these Economic
Feasibility Study is most important part of the feasibility analysis and Legal Feasibility Study is less
considered feasibility analysis.

1. Technical Feasibility –
In Technical Feasibility current resources both hardware software along with required
technology are analyzed/assessed to develop project. This technical feasibility study gives report
whether there exists correct required resources and technologies which will be used for project
development. Along with this, feasibility study also analyzes technical skills and capabilities of
technical team, existing technology can be used or not, maintenance and up-gradation is easy or
not for chosen technology etc.

2. Operational Feasibility –
In Operational Feasibility degree of providing service to requirements is analyzed along with
how much easy product will be to operate and maintenance after deployment. Along with this
other operational scopes are determining usability of product, Determining suggested solution by
software development team is acceptable or not etc.

3. Economic Feasibility –
In Economic Feasibility study cost and benefit of the project is analyzed. Means under this
feasibility study a detail analysis is carried out what will be cost of the project for development
which includes all required cost for final development like hardware and software resource

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2024
 required, design and development cost and operational cost and so on. After that it is analyzed
whether project will be beneficial in terms of finance for organization or not.
4. Legal Feasibility –
In Legal Feasibility study project is analyzed in legality point of view. This includes analyzing
barriers of legal implementation of project, data protection acts or social media laws, project
certificate, license, copyright etc. Overall it can be said that Legal Feasibility Study is study to
know if proposed project conform legal and ethical requirements.

5. Schedule Feasibility –
In Schedule Feasibility Study mainly timelines/deadlines is analyzed for proposed project which
includes how many times teams will take to complete final project which has a great impact on
the organization as purpose of project may fail if it can’t be completed on time.

Aim of feasibility study :

• The overall objective of the organization are covered and contributed by the system or not.

• The implementation of the system be done using current technology or not.

• can the system be integrated with the other system which are already exist

Need of Feasibility Study:

Feasibility study is so important stage of Software Project Management Process as after completionof
feasibility study it gives a conclusion of whether to go ahead with proposed project as it is practically
feasible or to stop proposed project here as it is not right/feasible to develop or to think/analyze about
proposed project again.
Along with this Feasibility study helps in identifying risk factors involved in developing and deploying
system and planning for risk analysis also narrows the business alternatives and enhance success rate
analyzing different parameters associated with proposed project development.

Experiment Specific Instructions

Create Feasibility for the problem selected in experiment no.1

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2024
E-Voting System

Technical Feasibility
1)Development Environment: JavaScript-based environment for consistency with React.js and Node.js.

2)Front-End: React.js for an efficient, user-friendly interface.

3)Back-End: Node.js with Express.js for a secure, efficient server.

Hardware Requirement

• Any processor with a minimum of dual cores

• 8 GB RAM
• 556 GB SSD

Software Requirement

• WINDOWS 10
• VS STUDIO CODE
• MySQL Command line Prompt

s.no Team member Technical Expertise

1 Team member 1 frontend
2 Team member 2 backend
3 Team member 3 designer

Remarks The system will be technically feasible because:

1)Proven Technologies: The system will use proven technologies like React.js for front-end
development and Node.js with Express.js for back-end development.

2)Scalability: The chosen technologies and architecture allow the system to scale to handle a
large number of simultaneous users, which is crucial for an e-voting system.
CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2024
Operational Feasibility
Easy for the end user

• Friendly Interface: The system will be designed with a simple and intuitive interface,
making it easy for users of all ages and technical abilities to cast their votes.
• Accessibility: The system will be accessible from various devices (desktop, laptop, tablet,
smartphone) and will be designed to be compatible with assistive technologies for users
with disabilities.
• Clear Instructions: The system will provide clear instructions to guide users through the
voting process.
Economic Feasibility

Cost Investigation

Staff
Particulars Number of persons Cost
Developer 6 35000
Testing 5 20000
Analyst 4 12000
Trainer 3 10000
Supervisor 4 23000
Marketing 5 25000
Risk Managers 4 30000

Total 155000

Constant Cost

Particulars cost
Domain 8000
Servers 40000
CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2024
 Hosting 4000

System Phases

System Analysis cost

Requirement Analysis
Design
Coding 20000
Testing 10000
debugging 5000
Legal Feasibility

1)Legal Considerations:

• Compliance: Ensure adherence to national and regional election laws. This includes voter eligibility,
registration, and voting procedures.
• Privacy: Protect voters’ privacy by complying with data protection laws.
• Transparency: Comply with laws that mandate transparency in the electoral process.
• Verification: Implement mechanisms for verifying voter identity while maintaining anonymity.

2)Technical Measures:

• Cybersecurity: Safeguard against cyber threats to prevent unauthorized access or tampering.

• Accessibility: Design an accessible system for all eligible voters, including those with disabilities.
• Auditability: Create an auditable system with verifiable records.
• Algorithmic Integrity: Ensure the use of secure, copyrighted algorithms.

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2024
 EXPERIMENT NO. 3

Identifying the Requirements from Problem Statements

Introduction

Requirements identification is the first step of any software development project. Until the requirements of
a client have been clearly identified, and verified, no other task (design, coding, testing) could begin. Usually
business analysts having domain knowledge on the subject matter discuss with clients and decide what
features are to be implemented.

In this experiment we will learn how to identify functional and non-functional requirements from a given
problem statement. Functional and non-functional requirements are the primary components of a Software
Requirements Specification.

Objectives

After completing this experiment you will be able to:

• Identify ambiguities, inconsistencies and incompleteness from a requirements specification

• Identify and state functional requirements
• Identify and state non-functional requirements

Requirements

Somerville defines "requirement" as a specification of what should be implemented. Requirements specify

how the target system should behave. It specifies what to do, but not how to do. Requirements engineering
refers to the process of understanding what a customer expects from the system to be developed, and to
document them in a standard and easily readable and understandable format. This documentation will serve
as reference for the subsequent design, implementation and verification of the system.

It is necessary and important that before we start planning, design and implementation of the software system
for our client, we are clear about its requirements. If we don't have a clear vision of what is to be developed
and what all features are expected, there would be serious problems and customer dissatisfactionas well.

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2024
Characteristics of Requirements

Requirements gathered for any new system to be developed should exhibit the following three properties:

Unambiguity: There should not be any ambiguity what a system to be developed should do. For example,
consider you are developing a web application for your client. The client requires that enough number of
people should be able to access the application simultaneously. What's the "enough number of people"? That
could mean 10 to you, but, perhaps, 100 to the client. There's an ambiguity.

Consistency: To illustrate this, consider the automation of a nuclear plant. Suppose one of the clients say that
it the radiation level inside the plant exceeds R1, all reactors should be shut down. However, another person
from the client side suggests that the threshold radiation level should be R2. Thus, there is an inconsistency
between the two end users regarding what they consider as threshold level of radiation.

Completeness: A particular requirement for a system should specify what the system should do and also what
it should not. For example, consider a software to be developed for ATM. If a customer enters an amount
greater than the maximum permissible withdrawal amount, the ATM should display an error message, and
it should not dispense any cash.

Categorization of Requirements

Based on the target audience or subject matter, requirements can be classified into different types, as stated
below:

• User requirements: They are written in natural language so that both customers can verify
theirrequirements have been correctly identified
• System requirements: They are written involving technical terms and/or specifications, and are
meantfor the development or testing teams

Requirements can be classified into two groups based on what they describe:

• Functional requirements (FRs): These describe the functionality of a system -- how a system
shouldreact to a particular set of inputs and what should be the corresponding output.
• Non-functional requirements (NFRs): They are not directly related what functionalities are
expectedfrom the system. However, NFRs could typically define how the system should behave
under certain

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2024
 situations. For example, a NFR could say that the system should work with 128MB RAM. Under such
condition, a NFR could be more critical than a FR.

Non-functional requirements could be further classified as:

• Product requirements: For example, a specification that the web application should use only
plainHTML, and no frames
• Performance requirements: For example, the system should remain available 24x7
• Organizational requirements: The development process should comply to SEI CMM level 4

Functional Requirements

Identifying Functional Requirements

Given a problem statement, the functional requirements could be identified by focusing on the following
points:

Identify the high level functional requirements simply from the conceptual understanding of the problem.
For example, a Library Management System, apart from anything else, should be able to issue and return
books.

Identify the cases where an end user gets some meaningful work done by using the system. For example, in
a digital library a user might use the "Search Book" functionality to obtain information about the books of
his interest.

If we consider the system as a black box, there would be some inputs to it, and some output in return. This
black box defines the functionalities of the system. For example, to search for a book, user gives title of the
book as input and gets the book details and location as the output.

Any high level requirement identified could have different sub-requirements. For example, "Issue Book"
module could behave differently for different class of users, or for a particular user who has issued the book
thrice consecutively.

Preparing Software Requirements Specifications

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2024
 Once all possible FRs and non-FRs have been identified, which are complete, consistent, and non-
ambiguous, the Software Requirements Specification (SRS) is to be prepared. The SRS is prepared by the
service provider, and verified by its client. This document serves as a legal agreement between the client and
the service provider. Once the concerned system has been developed and deployed, and a proposed feature
was not found to be present in the system, the client can point this out from the SRS. Also, if after delivery,
the client says a new feature is required, which was not mentioned in the SRS, the service provider can again
point to the SRS. The scope of the current experiment, however, doesn't cover writing a SRS.

Experiment Specific Instructions

• From the given problem statement of experiment 1, try to figure out if there's any inconsistency
withthe requirement specification
• Also, try to determine what are the functional and non-functional requirements
Bibliography

1. Requirements Engineering: A Good Practice Guide, Ian Sommerville, Pete Sawyer, Wiley India Pvt Ltd,
2009
2. Fundamentals of Software Engineering, Rajib Mall, Prentice-Hall of India, 3rd Edition, 2009
Webliography
i. Lecture on "System Analysis and Design", NPTEL
ii. When Telepathy Won’t Do: Requirements Engineering Key Practices
iii. Requirements Analysis: Process of requirements gathering and requirement definition
iv. IEEE Recommended Practice for Software Requirements Specifications
v. Requirements Trace-ability and Use Cases

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2023
 Functional and Non-Functional Requirements

Functional Requirements:

• Mobility: Voters can cast their ballot from any were .

• Convenience: The system allows voters to cast votes quickly and in one session.
• User-Interface: Easy-to-use interface without disadvantaging any candidate.
• Transparency: Voters have a general understanding of the voting process.
• Flexibility: Supports various ballot question formats, including open-ended questions.
• Accuracy: Records and counts all votes correctly.
• Eligibility: Only authorized and registered voters can vote.
• Uniqueness: Ensures no voter votes more than once.
• Auditability: Verifiable that all votes are correctly accounted for.
• Voter Confirmation: Voters can confirm and modify their vote before submission.
• Provisional Ballots: Allows voting with provisional ballots if registration issues arise.
• Documentation and Assurance: Well-documented design, implementation, and testing procedures

Non-Functional Requirements:

• Security: Robust identification and authentication process.

• Reliability: Consistent operation during peak usage.
• Scalability: Can handle a large number of voters simultaneously.
• Performance: Fast response times even under heavy load.
• Maintainability: Easy to update and maintain without system downtime.
• Usability: Intuitive for all user groups regardless of technical skill.

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2023
 EXPERIMENT NO. 4

Estimation of Project Metrics

Introduction

After gathering the entire requirements specific to software project usually we need to think about different
solution strategy for the project. Expert business analysts are analyzing their benefits and as well as their
shortcomings by means of cost, time and resources require developing it.

In this experiment, we will learn how to estimate cost, effort and duration for a software project, and then
select one solution approach which will be found suitable to fulfill the organizational goal.

Objectives
After completing this experiment you will be able to:
• Categorize projects using COCOMO, and estimate effort and development time required for
aproject

• Estimate the program complexity and effort required to recreate it using Halstead's metrics

Project Estimation Techniques

A software project is not just about writing a few hundred lines of source code to achieve a particular
objective. The scope of a software project is comparatively quite large, and such a project could take several
years to complete. However, the phrase "quite large" could only give some (possibly vague) qualitative
information. As in any other science and engineering discipline, one would be interestedto measure
how complex a project is. One of the major activities of the project planning phase, therefore, is to estimate
various project parameters in order to take proper decisions. Some important projectparameters that are
estimated include:
• Project size: What would be the size of the code written say, in number of lines, files,
modules?
CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2023
• Cost: How much would it cost to develop a software? A software may be just pieces of
code,but one has to pay to the managers, developers, and other project personnel.

• Duration: How long would it be before the software is delivered to the clients?

Effort: How much effort from the team members would be required to create the software?

In this experiment we will focus on two methods for estimating project metrics: COCOMO and Halstead's
method.

COCOMO
COCOMO (Constructive Cost Model) was proposed by Boehm. According to him, there could be three
categories of software projects: organic, semidetached, and embedded. The classification is done
considering the characteristics of the software, the development team and environment. These product
classes typically correspond to application, utility and system programs, respectively. Data processing
programs could be considered as application programs. Compilers, linkers, are examples of utility programs.
Operating systems, real-time system programs are examples of system programs. One could easily
apprehend that it would take much more time and effort to develop an OS than an attendance management
system.
The concept of organic, semidetached, and embedded systems are described below.

• Organic: A development project is said to be of organic type, if

• The project deals with developing a well understood application

• The development team is small

• The team members have prior experience in working with similar types of projects

Semidetached: A development project can be categorized as semidetached type, if

• The team consists of some experienced as well as inexperienced staff

• Team members may have some experience on the type of system to be developed

Embedded: Embedded type of development project are those, which

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2023
 • Aims to develop a software strongly related to machine hardware

• Team size is usually large

Boehm suggested that estimation of project parameters should be done through three stages: Basic
COCOMO, Intermediate COCOMO, and Complete COCOMO.
Basic COCOMO Model

Tdev denotes the estimated time required to develop the software The basic COCOMO model helps to
obtain a rough estimate of the project parameters. It estimates effort and time required for development in
the following way:
Effort = a * (KDSI)b PMTdev = 2.5 * (Effort)c Months where

• KDSI is the estimated size of the software expressed in Kilo Delivered Source
Instructions
• a, b, c are constants determined by the category of software project
• Effort denotes the total effort required for the software development, expressed
inperson months (PMs) (expressed in months)
The value of the constants a, b, c are given below:

Software project

Organic 2.4 1.05 0.38

Semi-detached 3.0 1.12 0.35

Embedded 3.6 1.20 0.32

Intermediate COCOMO Model

The basic COCOMO model considers that effort and development time depends only on the size of the
software. However, in real life there are many other project parameters that influence the development
process. The intermediate COCOMO take those other factors into consideration by defining a set of 15 cost
drivers (multipliers) as shown in the table below [i]. Thus, any project that makes use of modern
CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2023
programming practices would have lower estimates in terms of effort and cost. Each of the 15 such attributes
can be rated on a six-point scale ranging from "very low" to "extra high" in their relative order of
importance. Each attribute has an effort multiplier fixed as per the rating. The product of effort multipliers
of all the 15 attributes gives the Effort Adjustment Factor (EAF).

Cost drivers for INtermediat COCOMO

e
(Source: http://en.wikipedia.org/wiki/COCOMO)

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2023
 Complete COCOMO Model

Both the basic and intermediate COCOMO models consider a software to be a single homogeneous entity
-- an assumption, which is rarely true. In fact, many real life applications are made up of several smaller
sub-systems. (One might not even develop all the sub-systems -- just use the available services). The
complete COCOMO model takes these factors into account to provide a far more accurate estimate of
project metrics.

To illustrate this, consider a very popular distributed application: the ticket booking system of the Indian
Railways. There are computerized ticket counters in most of the railway stations of our country. Tickets can
be booked / cancelled from any such counter. Reservations for future tickets, cancellation of reserved tickets
could also be performed. On a high level, the ticket booking system has three main components:

• Database
• Graphical User Interface (GUI)
• Networking facilities
Among these, development of the GUI is considered as an organic project type; the database module could
be considered as a semi-detached software. The networking module can be considered as anembedded
software. To obtain a realistic cost, one should estimate the costs for each component separately, and then
add it up.
Advantages of COCOMO

COCOMO is a simple model, and should help one to understand the concept of project metrics estimation.

Drawbacks of COCOMO

COCOMO uses KDSI, which is not a proper measure of a program's size. Indeed, estimating the size of a
software is a difficult task, and any slight miscalculation could cause a large deviation in subsequent project
estimates. Moreover, COCOMO was proposed in 1981 keeping the waterfall model of project life cycle in
mind [2]. It fails to address other popular approaches like prototype, incremental, spiral, agile models.
Moreover, in present day a software project may not necessarily consist of coding of every bit of
functionality. Rather, existing software components are often used and glued together towards the
development of a new software. COCOMO is not suitable in such cases.

Experiment Specific Instructions

From the given problem statement of experiment 1 and requirements foiled try to figure out the cost
CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2023
 estimation and submit the report

Bibliography

1. Fundamentals of Software Engineering, Rajib Mall, Prentice-Hall of India, 3rd Edition, 2009
2. Software Engineering, Ian Sommerville, Addison Wesley Longman, 9th Edition, March 2010

Webliography

1. COCOMO
2. COCOMO (Constructive Cost Model), Seminar on Software Cost Estimation WS 2002 /
2003,presented by Nancy Merlo – Schett
3. Software Engineering, National Program on Technology Enhanced Learning

cost estimation

1)Staff Costs:

Developer: 6 persons * $35,000 = $210,000

Testing: 5 persons * $20,000 = $100,000

Analyst: 4 persons * $12,000 = $48,000

Trainer: 3 persons * $10,000 = $30,000

Supervisor: 4 persons * $23,000 = $92,000

Marketing: 5 persons * $25,000 = $125,000

Risk Managers: 4 persons * $30,000 = $120,000

Total Staff Cost: $725,000

2)Constant Costs:

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2023
Domain: $8,000

Servers: $40,000

Hosting: $4,000

Total Constant Costs: $52,000

3)System Phases:

Coding: $20,000

Testing: $10,000

Debugging: $5,000

Total System Phases Costs: $35,000

4)Total Operational Costs:

Total Staff Cost + Total Constant Costs + Total System Phases Costs

= $725,000 + $52,000 + $35,000

= $812,000

5)Legal Feasibility:

The legal feasibility involves ensuring compliance with national and regional election laws, data protection laws,
transparency mandates, cybersecurity measures, accessibility requirements, auditability, and algorithmic integrity.
These considerations may not directly contribute to cost estimation but are critical for the project's success.

6)Total Cost Estimation:

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2023
Considering only the operational costs provided, the total cost estimation for the project is $812,000.

Conclusion- The e-voting system project has been carefully analyzed in terms of technical, operational,
economic, and legal feasibility. Here's a summary of the conclusions drawn from the cost estimation and
feasibility analysis.

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2023
 EXPERIMENT NO. 5

Modeling UML Use Case Diagrams and Capturing Use Case Scenarios

Introduction

Use case diagram is a platform that can provide a common understanding for the end-users, developers and
the domain experts. It is used to capture the basic functionality i.e. use cases, and the users of those
available functionality, i.e. actors, from a given problem statement.
In this experiment, we will learn how use cases and actors can be captured and how different use cases are
related in a system.

Objectives

After completing this experiment you will be able to:

• How to identify different actors and use cases from a given problem statement
• How to associate use cases with different types of relationships
• How to draw a use-case diagram
Use case diagrams
Use case diagrams belong to the category of behavioural diagram of UML diagrams. Use case diagrams aim
to present a graphical overview of the functionality provided by the system. It consists of a set of actions
(referred to as use cases) that the concerned system can perform, one or more actors, and dependencies
among them.

Actor

An actor can be defined as an object or set of objects, external to the system, which interacts with the
system to get some meaningful work done. Actors could be human, devices, or even other systems.
For example, consider the case where a customer withdraws cash from an ATM. Here, customer is a human
actor.

Actors can be classified as below :

Primary actor: They are principal users of the system, who fulfill their goal by availing someservice from the
system. For example, a customer uses an ATM to withdraw cash when he needs it. A customer is the primary actor
here.

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2023
 • Supporting actor: They render some kind of service to the system. "Bank representatives",
who replenishes the stock of cash, is such an example. It may be noted that replenishing stock of cash in
anATM is not the prime functionality of an ATM.

In a use case diagram primary actors are usually drawn on the top left side of the diagram.

Use Case

A use case is simply functionality provided by a system.

Continuing with the example of the ATM, withdraw cash is a functionality that the ATM provides.
Therefore, this is a use case. Other possible use cases includes, check balance, change PIN, and so on.

Use cases include both successful and unsuccessful scenarios of user interactions with the system. For
example, authentication of a customer by the ATM would fail if he enters wrong PIN. In such case, an error
message is displayed on the screen of the ATM.

Subject
Subject is simply the system under consideration. Use cases apply to a subject. For example, an ATM is a
subject, having multiple use cases, and multiple actors interact with it. However, one should be careful of
external systems interacting with the subject as actors.
Graphical Representation

An actor is represented by a stick figure and name of the actor is written below it. A use case is depicted by
an ellipse and name of the use case is written inside it. The subject is shown by drawing a rectangle. Label
for the system could be put inside it. Use cases are drawn inside the rectangle, and actors are drawn outside
the rectangle, as shown in figure – 01

Figure - 01: A use case diagram for a book store

Association between Actors and Use Cases

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2023
A use case is triggered by an actor. Actors and use cases are connected through binary associations
indicating that the two communicates through message passing.

An actor must be associated with at least one use case. Similarly, a given use case must be associated with
at least one actor. Association among the actors are usually not shown. However, one can depict the class
hierarchy among actors.

Use Case Relationships

Three types of relationships exist among use cases:

• Include relationship
• Extend relationship
• Use case generalization
Include Relationship
Include relationships are used to depict common behaviour that are shared by multiple use cases. This could
be considered analogous to writing functions in a program in order to avoid repetition of writing the same
code. Such a function would be called from different points within the program.

Example

For example, consider an email application. A user can send a new mail, reply to an email he has received,
or forward an email. However, in each of these three cases, the user must be logged in to perform those
actions. Thus, we could have a login use case, which is included by compose mail, reply, and forward
email use cases. The relationship is shown in figure - 02.

Figure - 02: Include relationship between use cases

Notation

Include relationship is depicted by a dashed arrow with a «include» stereotype from the including use case
to the included use case.

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2023
Extend Relationship

Use case extensions are used used to depict any variation to an existing use case. They are used to the
specify the changes required when any assumption made by the existing use case becomes false [iv, v].

Example

Let's consider an online bookstore. The system allows an authenticated user to buy selected book(s). While
the order is being placed, the system also allows to specify any special shipping instructions [vii], for
example, call the customer before delivery. This Shipping Instructions step is optional, and not a part of the
main Place Order use case. Figure - 03 depicts such relationship.

Figure - 03: Extend relationship between use cases

Notation

Extend relationship is depicted by a dashed arrow with a «extend» stereotype from the extending use case to
the extended use case.

Generalization Relationship

Generalization relationship is used to represent the inheritance between use cases. A derived use case
specializes some functionality it has already inherited from the base use case.

Example

To illustrate this, consider a graphical application that allows users to draw polygons. We could have a use
case draw polygon. Now, rectangle is a particular instance of polygon having four sides at right angles to
each other. So, the use case draw rectangle inherits the properties of the use case draw polygon and
overrides it's drawing method. This is an example of generalization relationship. Similarly, a generalization
relationship exists between draw rectangle and draw square use cases. The relationship has been illustrated
in figure - 04.
CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2023
Figure - 04: Generalization relationship among use cases

Notation

Generalization relationship is depicted by a solid arrow from the specialized (derived) use case to the more
generalized (base) use case.
Identifying Actors
Given a problem statement, the actors could be identified by asking the following questions :
• Who gets most of the benefits from the system? (The answer would lead to the identification of
theprimary actor)
• Who keeps the system working? (This will help to identify a list of potential users)
• What other software / hardware does the system interact with?
• Any interface (interaction) between the concerned system and any other system?
Identifying Use cases

Once the primary and secondary actors have been identified, we have to find out their goals i.e. what are the
functionality they can obtain from the system. Any use case name should start with a verb like, "Check
balance".

Guidelines for drawing Use Case diagrams

Following general guidelines could be kept in mind while trying to draw a use case diagram :
• Determine the system boundary
• Ensure that individual actors have well-defined purpose
• Use cases identified should let some meaningful work done by the actors
• Associate the actors and use cases -- there shouldn't be any actor or use case floating without
anyconnection
• Use include relationship to encapsulate common behaviour among use cases , if any

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2023
 Experiment Specific Instructions

Draw the Use Case diagram for the Problem statement you framed in Practical 1.
Bibliography

1. Object-Oriented Modeling and Design with UML, Michael Blaha, James Rumbaugh, Prentice-Hall of
India, 2nd Edition
2. Object-Oriented Analysis and Design using UML, Mahesh P. Matha, Prentice-Hall of India,
Webliography

1. Use Case Diagrams

2. Use case diagram -- Wikipedia
3. Unified Modeling Language, Superstructure, V2.1.2
4. "Functional Requirements and Use Cases", Ruth Malan and Dana Bredemeyer,
BredemeyerConsulting
5. "A Use Case Template: draft for discussion", Derek Coleman, Hewlett-Packard Software Initiative
6. X. J. Zheng, X. Liu, & S. Liu. (2010). Use Case and Non-functional Scenario Template-Based
Approach to Identify Aspects. Computer Engineering and Applications ICCEA 2010 Second
International Conference on (Vol. 2, pp. 89-93)
7. Extend relationships
8. Requirements Trace-ability and Use Cases
9. UML Use Case Diagrams: Tips and FAQ

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2023
 Use Case diagram

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2023
 EXPERIMENT NO. 6

E-R Modeling from the Problem Statements

Developing databases is a very important task to develop a system. Before going to form exact database tables
and establishing relationships between them, we conceptually or logically can model our database using ER
diagrams.
In this experiment we will learn how to find the entities, its attributes and how the relationships between the
entities can be established for a system.
Objectives
After completing this experiment you will be able to:
• identify entity sets, their attributes, and various relationships
• Represent the data model through ER diagram

Entity Relationship Model

Entity-Relationship model is used to represent a logical design of a database to be created. In ER model, real
world objects (or concepts) are abstracted as entities, and different possible associations among them are
modeled as relationships.
For example, student and school -- they are two entities. Students study in school. So, these two entities are
associated with a relationship "Studies in".
As another example, consider a system where some job runs every night, which updates the database. Here,
job and database could be two entities. They are associated with the relationship "Updates".
Entity Set and Relationship Set
An entity set is a collection of all similar entities. For example, "Student" is an entity set that abstracts all
students. Ram, John are specific entities belonging to this set. Similarly, a "Relationship" set is a set of similar
relationships.
Attributes of Entity

Attributes are the characteristics describing any entity belonging to an entity set. Any entity in a set can be
described by zero or more attributes.
For example, any student has got a name, age, an address. At any given time a student can study only at one
school. In the school he would have a roll number, and of course a grade in which he studies. These data are
the attributes of the entity set Student.
CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2023
Keys

One or more attribute(s) of an entity set can be used to define the following keys:
• Super key: One or more attributes, which when taken together, helps to uniquely identify an entity in
an entity set. For example, a school can have any number of students. However, if we know grade and roll
number, then we can uniquely identify a student in that school.
• Candidate key: It is a minimal subset of a super key. In other words, a super key might
contain extraneous attributes, which do not help in identifying an object uniquely. When such attributes are
removed, the key formed so is called a candidate key.
• Primary key: A database might have more than one candidate key. Any candidate key chosen
for a particular implementation of the database is called a primary key.
• Prime attribute: Any attribute taking part in a super key
Weak Entity
An entity set is said to be weak if it is dependent upon another entity set. A weak entity can't be uniquely
identified only by it's attributes. In other words, it doesn't have a super key.
For example, consider a company that allows employees to have travel allowance for their immediate family.
So, here we have two entity sets: employee and family, related by "Can claim for". However, family doesn't
have a super key. Existence of a family is entirely dependent on the concerned employee. So, it is meaningful
only with reference to employee.

Entity Generalization and Specialization

Once we have identified the entity sets, we might find some similarities among them. For example, multiple
person interacts with a banking system. Most of them are customers, and rest employees or other service
providers. Here, customers, employees are persons, but with certain specializations. Or in other way, person is
the generalized form of customer and employee entity sets.
ER model uses the "ISA" hierarchy to depict specialization (and thus, generalization).
Mapping Cardinalities
One of the main tasks of ER modeling is to associate different entity sets. Let's consider two entity sets E1 and
E2 associated by a relationship set R. Based on the number of entities in E1 and E2 are associated with, we
can have the following four type of mappings:
• One to one: An entity in E1 is related to at most a single entity in E2, and vice versa

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2023
• One to many: An entity in E1 could be related to zero or more entities in E2. Any entity in E2 could be
related to at most a single entity in E1.
• Many to one: Zero or more number of entities in E1 could be associated to a single entity in
E2.However, an entity in E2 could be related to at most one entity in E1.
• Many to many: Any number of entities could be related to any number of entities in E2,
includingzero, and vice versa.
ER Diagram

From a given problem statement we identify the possible entity sets, their attributes, and relationships among
different entity sets. Once we have these information, we represent them pictorially, called an entity-
relationship (ER) diagram.
Graphical Notations for ER Diagram

Term Notation Remarks

Name of the set is written

Entity set
inside the rectangle

Name of the attribute is

Attribute
writteninside the ellipse

Roll is the primary

Entity with attributes
key;denoted with an
underline

Weak entity set

Name of the relationship is

Relationship set
written inside the diamond

Related enity sets

A person can own zero or

Relationshi
more cars but no two persons
p
can own the same car
cardinality

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2023
 Term Notation Remarks

Relationship
wit
hweak entity set

Importance of ER modeling
Figure - 01 shows the different steps involved in implementation of a (relational) database.

Figure - 01: Steps to implement a RDBMS

Given a problem statement, the first step is to identify the entities, attributes and relationships. We represent
them using an ER diagram. Using this ER diagram, table structures are created, along with required constraints.
Finally, these tables are normalized in order to remove redundancy and maintain data integrity. Thus, to have
data stored efficiently, the ER diagram is to be drawn as much detailed and accurate as possible.
Experiment Specific Instructions
Draw ER diagrams for the Problem statement you framed in experiment No. 1.

Bibliography
1. Database System Concepts, Henry F. Korth , Abraham Silberschatz, McGraw Hills, 5th Edition

Webliography
Entity-relationship modelling
Entity Relationship Modelling - 2

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2023
CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2023
 EXPERIMENT NO. 7

Activity Modeling

Capturing the dynamic view of a system is very important for a developer to develop the logic for a system.
State chart diagrams and activity diagrams are two popular UML diagram to visualize the dynamic behavior
of an information system.
In this experiment, we will learn about the different components of activity diagram and state chart diagram
and how these can be used to represent the dynamic nature of an information system.
Objectives
After completing this experiment you will be able to:
• Identify the distinct states a system have
• Identify the events causing transitions from one state to another
• Represent the above information pictorially using simple states
• Identify activities representing basic units of work, and represent their flow
State chart Diagrams
In case of Object Oriented Analysis and Design, a system is often abstracted by one or more classes with
some well defined behaviour and states. A statechart diagram is a pictorial representation of such a system,
with all it's states, and different events that lead transition from one state to another.
To illustrate this, consider a computer. Some possible states that it could have are: running, shutdown,
hibernate. A transition from running state to shutdown state occur when user presses the "Power off" switch,
or clicks on the "Shut down" button as displayed by the OS. Here, clicking on the shutdown button, or pressing
the power off switch act as external events causing the transition.
Statechart diagrams are normally drawn to model the behaviour of a complex system. For simple systems this
is optional.
Building Blocks of a Statechart Diagram
State

A state is any "distinct" stage that an object (system) passes through in it's lifetime. An object remains in a
given state for finite time until "something" happens, which makes it to move to another state. All such states
CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2023
can be broadly categorized into following three types:
• Initial: The state in which an object remain when created
• Final: The state from which an object do not move to any other state [optional]
• Intermediate: Any state, which is neither initial, nor final
As shown in figure-01, an initial state is represented by a circle filled with black. An intermediate state is
depicted by a rectangle with rounded corners. A final state is represented by a unfilled circle with an inner
black-filled circle.

Figure-01: Representation of initial, intermediate, and final states of a statechart diagram

Intermediate states usually have two compartments, separated by a horizontal line, called the
namecompartment and internal transitions compartment [iv]. They are described below:

• Name compartment: Contains the name of the state, which is a short, simple, descriptive string
• Internal transitions compartment: Contains a list of internal activities performed as long as the system is
inthis state
The internal activities are indicated using the following syntax: action-label / action-expression. Action
labels could be any condition indicator. There are, however, four special action labels:
• Entry: Indicates activity performed when the system enter this state
• Exit: Indicates activity performed when the system exits this state
• Do: indicate any activity that is performed while the system remain in this state or until the
actionexpression results in a completed computation
• Include: Indicates invocation of a sub-machine
Any other action label identifies the event (internal transition) as a result of which the corresponding action
is triggered. Internal transition is almost similar to self transition, except that the former doesn't result in
execution of entry and exit actions. That is, system doesn't exit or re-enter that state. Figure-02 shows the
syntax for representing a typical (intermediate) state

Figure-02: A typical state in a statechart diagram

States could again be either simple or composite (a state congaing other states). Here, however, we will deal
only with simple states.
CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2023
 Transition : Transition is movement from one state to another state in response to an external stimulus (or
any internal event). A transition is represented by a solid arrow from the current state to the next state. It is
labeled by: event [guard-condition]/[action-expression], where

• Event is the what is causing the concerned transition (mandatory) -- Written in past tense [iii]
• Guard-condition is (are) precondition(s), which must be true for the transition to happen [optional]
• Action-expression indicate action(s) to be performed as a result of the transition [optional]
It may be noted that if a transition is triggered with one or more guard-condition(s), which evaluate to false,
the system will continue to stay in the present state. Also, not all transitions do result in a state change. For
example, if a queue is full, any further attempt to append will fail until the delete method is invoked at least
once. Thus, state of the queue doesn't change in this duration.
Action

Actions represents behaviour of the system. While the system is performing any action for the current event,
it doesn't accept or process any new event. The order in which different actions are executed, is given
below:
1. Exit actions of the present state
2. Actions specified for the transition
3. Entry actions of the next state
Figure-03 shows a typical statechart diagram with all it's syntaxes.

Figure-03: A statechart diagram showing transition from state A to B

Guidelines for drawing Statechart Diagrams

Following steps could be followed, as suggested in [i] to draw a statechart diagram:

• For the system to developed, identify the distinct states that it passes through
• Identify the events (and any precondition) that cause the state transitions. Often these would be
themethods of a class as identified in a class diagram.
• Identify what activities are performed while the system remains in a given state
Activity Diagrams
Activity diagrams fall under the category of behavioral diagrams in Unified Modeling Language. It is a high
level diagram used to visually represent the flow of control in a system. It has similarities with traditional
CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2023
 flow charts. However, it is more powerful than a simple flow chart since it can represent various other concepts
like concurrent activities, their joining, and so on [vii, viii].
Activity diagrams, however, cannot depict the message passing among related objects. As such, it can't be
directly translated into code. These kind of diagrams are suitable for confirming the logic to be implemented

with the business users. These diagrams are typically used when the business logic is complex. In
simplescenarios it can be avoided entirely
Components of an Activity Diagram
Below we describe the building blocks of an activity diagram.
Activity
An activity denotes a particular action taken in the logical flow of control. This could simply be invocation
of a mathematical function, alter an object's properties and so on [x]. An activity is represented with a rounded
rectangle, as shown in table-01. A label inside the rectangle identifies the corresponding activity.
There are two special type of activity nodes: initial and final. They are represented with a filled circle, and a
filled in circle with a border respectively (table-01). Initial node represents the starting point of a flow in an
activity diagram. There could be multiple initial nodes, which means that invoking that particular activity
diagram would initiate multiple flows.
A final node represents the end point of all activities. Like an initial node, there could be multiple final nodes.
Any transition reaching a final node would stop all activities.
Flow

A flow (also termed as edge, or transition) is represented with a directed arrow. This is used to depict transfer
of control from one activity to another, or to other types of components, as we will see below. A flow is often
accompanied with a label, called the guard condition, indicating the necessary condition for the transition to
happen. The syntax to depict it is [guard condition].
Decision
A decision node, represented with a diamond, is a point where a single flow enters and two or more flows
leave. The control flow can follow only one of the outgoing paths. The outgoing edges often have guard
conditions indicating true-false or if-then-else conditions. However, they can be omitted in obvious cases.
The input edge could also have guard conditions. Alternately, a note can be attached to the decision node
indicating the condition to be tested.
Merge
This is represented with a diamond shape, with two or more flows entering, and a single flow leaving out. A

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2023
merge node represents the point where at least a single control should reach before further processing could
continue.
Fork
Fork is a point where parallel activities begin. For example, when a student has been registered with a college,
he can in parallel apply for student ID card and library card. A fork is graphically depicted with a black bar,
with a single flow entering and multiple flows leaving out.
Join

A join is depicted with a black bar, with multiple input flows, but a single output flow. Physically it
represents the synchronization of all concurrent activities. Unlike a merge, in case of a join all of the
incoming controls must be completed before any further progress could be made. For example, a sales order
is closed only when the customer has receive the product, and the sales company has received it's payment.
Note
UML allows attaching a note to different components of a diagram to present some textual information. The
information could simply be a comment or may be some constraint. A note can be attached to a decision point,
for example, to indicate the branching criteria.
Partition
Different components of an activity diagram can be logically grouped into different areas, called partitions
or swimlanes. They often correspond to different units of an organization or different actors. The drawing
area can be partitioned into multiple compartments using vertical (or horizontal) parallel lines. Partitions in
an activity diagram are not mandatory.
The following table shows commonly used components with a typical activity diagram.

Graphica
Componen
t l
Notation

Activity Fork

Flow

Decision Join

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2023
 Merge Note

Table-01: Typical components used in an activity diagram

Apart from the above stated components, there are few other components as well (representing events,
sending of signals, nested activity diagrams), which won't be discussed here. The reader is suggested to go
through [x] for further knowledge.
A Simple Example

Figure-04 shows a simple activity diagram with two activities. The figure depicts two stages of a form
submission. At first a form is filled up with relevant and correct information. Once it is verified that there is
no error in the form, it is then submitted. The two other symbols shown in the figure are the initial node (dark
filled circle), and final node (outer hollow circle with inner filled circle). It may be noted that there

could be zero or more final node(s) in an activity diagram [ix].

Figure-04: A simple activity diagram.
Guidelines for drawing an Activity Diagram
The following general guidelines could be followed to pictorially represent a complex logic.
• Identify tiny pieces of work being performed by the system
• Identify the next logical activity that should be performed
• Think about all those conditions that should be made, and all those constraints that should be
satisfied,before one can move to the next activity
• Put non-trivial guard conditions on the edges to avoid confusion
Experiment Specific Instructions

Draw Activity diagrams for the Problem statement you framed in Experiment 1.
Webliography

1. UML 2 State Machine Diagrams

2. Modeling Behavior with UML Interactions and Statecharts
CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2023
 3. UML 2 State Machine Diagramming Guidelines
4. Statechart Diagram
PlantUML (Open-Source tool in Java to draw UML Diagram)

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2023
 Activity diagram

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2024
 EXPERIMENT NO. 8

Modeling UML Class Diagrams and Sequence diagrams

Introduction
Classes are the structural units in object oriented system design approach, so it is essential to know all the
relationships that exist between the classes, in a system. All objects in a system are also interacting to each
other by means of passing messages from one object to another. Sequence diagram shows these interactions
with time ordering of the messages.
In this Experiment, we will learn about the representation of class diagram and sequence diagram. We also
learn about different relationships that exist among the classes, in a system.
From the experiment of sequence diagram, we will learn about different types of messages passing in
between the objects and time ordering of those messages, in a system.

Objectives
After completing this experiment you will be able to:
• Graphically represent a class, and associations among different classes
• Identify the logical sequence of activities undergoing in a system, and represent them
pictorially
Structural and Behavioral aspects
Developing a software system in object oriented approach is very much dependent on understanding the
problem. Some aspects and the respective models are used to describe problems and in context of those
aspects the respective models give a clear idea regarding the problem to a designer. For developer,
structural and behavioral aspects are two key aspects to see through a problem to design a solution for the
same.
Class diagram

It is a graphical representation for describing a system in context of its static construction[1].

Elements in class diagram
Class diagram contains the system classes with its data members, operations and relationships between
classes.
Class
A set of objects containing similar data members and member functions is described by a class. In UML

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2024
 syntax, class is identified by solid outline rectangle with three compartments which contain
• Class name

A class is uniquely identified in a system by its name. A textual string [2]is taken as class name. It lies in
the first compartment in class rectangle.
• Attributes
Property shared by all instances of a class. It lies in the second compartment in class rectangle.
• Operations

An execution of an action can be performed for any object of a class. It lies in the last compartment in class
rectangle.

Example

To build a structural model for an Educational Organization, ‘Course’ can be treated as a class which contains
attributes ‘courseName’ & ‘courseID’ with the operations ‘addCourse()’ & ‘removeCourse()’ allowed to be
performed for any object to that class.

Figure-01:

• Generalization/Specialization
It describes how one class is derived from another class. Derived class inherits the properties of its parent
class.

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2024
 Example

Geometric_Shapes is the class that describes how many sides a particular shape has. Triangle, Quadrilateral
and Pentagon are the classes that inherit the property of the Geometric_Shapes class. So the relations among
these classes are generalization. Now Equilateral_Triangle, Isosceles_Triangle and Scalene_Triangle, all
these three classes inherit the properties of Triangle class as each one of them has three sides. So, these are
specialization of Triangle class.
Relationships
Existing relationships in a system describe legitimate connections between the classes in that system.
Association
It is an instance level relationship[i] that allows exchanging messages among the objects of both ends of
association. A simple straight line connecting two class boxes represent an association. We can give a
name to association and also at the both end we may indicate role names and multiplicity of the adjacent
classes. Association may be uni-directional.
Example In structure model for a system of an organization an employee (instance of ‘Employee’ class) is
always assigned to a particular department (instance of ‘Department’ class) and the association can be shown
by a line connecting the respective classes.

Figure-03:

Aggregation
It is a special form of association which describes a part-whole[i] relationship between a pair of classes. It

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2024
means, in a relationship, when a class holds some instances of related class, then that relationship can be
designed as an aggregation.
Example:For a supermarket in a city, each branch runs some of the departments they have. So, the relation
among the classes ‘Branch’ and ‘Department’ can be designed as an aggregation. In UML, it can be shown
as in the fig. below

Composition [i]
It is a strong from of aggregation which describes that whole is completely owns its part. Life cycle of the
part depends on the whole.
Example
Let consider a shopping mall has several branches in different locations in a city. The existence of branches
completely depends on the shopping mall as if it is not exist any branch of it will no longer exists in the city.
This relation can be described as composition and can be shown as below

Figure-05:
Multiplicity
It describes how many numbers of instances of one class is related to the number of instances of another
class in an association.
Notation for different types of multiplicity:

Figure-06:

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2024
 Example

One vehicle may have two or more wheels

Figure-07:

Sequence diagram

It represents the behavioral aspects of a system[1]. Sequence diagram shows the interactions between the
objects[1] by means of passing messages from one object to another with respect to time[2] in a system.
Elements in sequence diagram
Sequence diagram contains the objects of a system and their life-line bar and the messages passing between
them.
Object
Objects appear at the top portion of sequence diagram[1]. Object is shown in a rectangle box. Name of object
precedes a colon ‘:’ and the class name, from which the object is instantiated. The whole string is underlined
and appears in a rectangle box. Also, we may use only class name or only instance name.
Objects which are created at the time of execution of use case and are involved in message passing , are
appear in diagram, at the point of their creation[1].
Life-line bar
A down-ward vertical line from object-box is shown as the life-line of the object. A rectangle bar on life-
line indicates that it is active at that point of time[1].
Messages

Messages are shown as an arrow from the life-line of sender object to the life-line of receiver object and
labeled with the message name. Chronological order of the messages passing throughout the objects’ life-
line show the sequence in which they occur[1] . There may exist some different types of messages :
• Synchronous messages:Receiver start processing the message after receiving it and sender
needs to wait until it is made[iii]. A straight arrow with close and fill arrow-head from sender life-line bar
to receiver end, represent a synchronous message[iii].
• Asynchronous messages:For asynchronous message sender needs not to wait for the receiver
toprocess the message[iv]. A function call that creates thread can be represented as an asynchronous
message in sequence diagram[iv]. A straight arrow with open arrow-head from sender life-line bar to
receiver end, represent an asynchronous message[iii].
CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2024
• Return message:For a function call when we need to return a value to the object, from which
it was called, then we use return message. But, it is optional, and we are using it when we are going to
model our system in much detail. A dashed arrow with open arrow-head from sender life-line bar to
receiver end, represent that message.
• Response message:One object can send a message to self[iv]. We use this message when we
need to show the interaction between the same object.

Figure-08

Figure 1: Sequence diagram for "Issue Book"

Figure 2 shows the order of steps involved in the process of purchasing of a new book. In this case also,
"PurchaseManager" is a part of LIS, which manages all books that are being purchased. The activation bars
indicate the different instances when a particular object is active in their corresponding life cycles.

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2024
Figure 2: Sequence diagram for "Purchase Books"

Experiment Specific Instructions

Draw Sequence diagrams for the Problem statement you framed in Experiment no. 1.

Bibliography
Fundamentals of Software Engineering, Rajib Mall, Prentice-Hall of India, 3rd Edition, 2009
THE UNIFIED MODELING LANGUAGE USER GUIDE, GRADY BOOCH, JAMES RUMBAUGH,
IVAR JACOBSON, ADDISON-WESLEY, Low Priced Edition, 2000

Webliography

1. Class diagram
2. UML Tutorial: Part 1 -- Class Diagrams
3. Synchronous messages The UML
4. Asynchronous message , UML sequence diagram

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2024
 Sequence Diagram

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2024
 EXPERIMENT NO. 9

Modeling Data Flow Diagrams

Introduction
Information Systems (IS) help in managing and updating the vast business-related information. Before
designing such an IS, it is helpful to identify the various stakeholders, and the information that they would
be exchanging with the system. An IS, however, is a large software comprised of several modules, which, in
turn, share the process the available data. These data are often stored in databases for further references. A
Data Flow Diagram (DFD) is used to pictorially represent the functionalities of the ISs by focusing on the
sources and destinations of the data flowing in the system.
Objectives
After completing this experiment you will be able to:
• Identify external entities and functionalities of any system
• Identify the flow of data across the system
• Represent the flow with Data Flow Diagrams
Data Flow Diagram
DFD provides the functional overview of a system. The graphical representation easily overcomes any gap
between ’user and system analyst’ and ‘analyst and system designer’ in understanding a system. Starting
from an overview of the system it explores detailed design of a system through a hierarchy. DFD shows the
external entities from which data flows into the process and also the other flows of data within a system. It
also includes the transformations of data flow by the process and the data stores to read or write a data.
Graphical notations for Data Flow Diagram

Term Notation Remarks Ter Notation Remarks

m
Name of the A left-right open
Externa external entity is Data rectangle is denoted as
lentity written inside the stor data store; name of the
rectangle e data store is written
inside the shape

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2024
 Name of the Data flow is represented
Data
Process process is written by a directed arc with its
flow
inside the circle data name

Explanation of Symbols used in DFD

• Process: Processes are represented by circle. The name of the process is written into the circle.
The name of the process is usually given in such a way that represents the functionality of the process.
More detailed functionalities can be shown in the next Level if it is required. If we see that the number of
processes becomes more than 7 then we should combine some the processes to a single one to reduce the
number of processes and further decompose it to the next level .
• External entity: External entities are only appear in context diagram. External entities are
represented by a rectangle and the name of the external entity is written into the shape. These send data
to be processed and again receive the processed data.
• Data store: Data stares are represented by a left-right open rectangle. Name of the data store
iswritten in between two horizontal lines of the open rectangle. Data stores are used as repositories from
which data can be flown in or flown out to or from a process.
• Data flow: Data flows are shown as a directed edge between two components of a Data Flow
Diagram. Data can flow from external entity to process, data store to process, in between two processes
and vice-versa.
Context diagram and leveling DFD
We start with a broad overview of a system represented in level 0 diagram. It is known as context diagram
of the system. The entire system is shown as single process and also the interactions of external entities
with the system are represented in context diagram.
Further we split the process in next levels into several numbers of processes to represent the detailed
functionalities performed by the system. Data stores may appear in higher level DFDs.
Numbering of processes : If process ‘p’ in context diagram is split into 3 processes ‘p1’, ‘p2’and ‘p3’ in
next level then these are labeled as 0.1, 0.2 and 0.3 in level 1 respectively. Let the process ‘p3’ is again
split into three processes ‘p31’, ‘p32’ and ‘p33’ in level 2, so, these are labeled as 0.3.1, 0.3.2 and 0.3.3
respectively and so on.
Balancing DFD: The data that flow into the process and the data that flow out to the process need to be
CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2024
 match when the process is split into in the next level. This is known as balancing a DFD.
Note :

1. External entities only appear in context diagram[2] i.e, only at level 0.

2. Keep number of processes at each level less than 7[i].
3. Data flow is not possible in between two external entities and in between two data stores[i].

4. Data cannot flow from an External entity to a data store and vice-versa[i].

Figure 1: Context-level DFD for Library Information System

Comparing figures 1 and 2 one might observe that the information flow in and out of LIS has been preserved.

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2024
 We observe in figure 2 that the sub-processes themselves exchange information among themselves. These
information flows would be, in turn, preserved if we decompose the system into a level2 DFD.
Finally, in order to eliminate intersecting lines and make the DFD complex, the Member external entity has
been duplicated in figure 2. This is indicated by a * mark near the right-bottom corner of the entity box.

Figure 2: Level 1 DFD for Library Information System

Experiment Specific Instructions
Draw DFD Diagram for the Problem statement you framed in Practical 1.
Bibliography
Software Engineering, Ian Sommerville, Addison Wesley Longman, 9th Edition, March 2010

1. Fundamentals of Software Engineering, Rajib Mall, Prentice-Hall of India, 3rd Edition, 2009

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2024
 Webliography

• NPTEL course material - System Analysis and Design

• Software Engineering Virtual Lab - Simulation
• Software Engineering Virtual Lab - Case Study

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2024
 Data flow
diagram

Df 0

Df 1

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2024
 EXPERIMENT NO 10

Designing Test Suites

Development of a new software, like any other product, remains incomplete until it subjected to exhaustive
tests. The primary objective of testing is not to verify that all desired features have been implemented correctly.
However, it also includes verification of the software behavior in case of "bad inputs".
In this experiment we discuss in brief about different types of testing, and provide mechanisms to have hands-
on experience on unit testing.

Objectives
After completing this experiment you will be able to:
• Learn about different techniques of testing a software
• Design unit test cases to verify the functionality and locate bugs, if any

Software Testing
Testing software is an important part of the development life cycle of a software. It is an expensive activity.
Hence, appropriate testing methods are necessary for ensuring the reliability of a program. According to the
ANSI/IEEE 1059 standard, the definition of testing is the process of analyzing a software item, to detect the
differences between existing and required conditions i.e. defects/errors/bugs and to evaluate the features of the
software item.
The purpose of testing is to verify and validate a software and to find the defects present in a software. The
purpose of finding those problems is to get them fixed.
• Verification is the checking or we can say the testing of software for consistency and conformance
byevaluating the results against pre-specified requirements.
• Validation looks at the systems correctness, i.e. the process of checking that what has been specified
iswhat the user actually wanted.
• Defect is a variance between the expected and actual result. The defect’s ultimate source may be traced
to afault introduced in the specification, design, or development (coding) phases.
CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2024
Testing Frameworks
Following are the different testing frameworks:

Following are the different testing frameworks:

• jUnit - for Java unit test

• Selenium - is a suite of tools for automating web applications for software testing purposes, plugin for
Firefox
• HP QC - is the HP Web-based test management tool. It familiarizes with the process of defining
releases, specifying requirements, planning tests, executing tests, tracking defects, alerting on changes, and
analyzing results. It also shows how to customize project
• IBM Rational - Rational software has a solution to support business sector for designing, implementing
and testing software

Need for Software Testing

There are many reasons for why we should test software, such as:
• Software testing identifies the software faults. The removal of faults helps reduce the number of
systemfailures. Reducing failures improves the reliability and the quality of the systems.
• Software testing can also improves the other system qualities such as maintainability, usability, and
testability.
• In order to meet the condition that the last few years of the 20th century systems had to be shown to be
freefrom the ‘millennium bug’.
• In order to meet the different legal requirements.
• In order to meet industry specific standards such as the Aerospace, Missile and Railway Signaling
standards.

Test Cases and Test Suite

A test case describes an input descriptions and an expected output descriptions. Input are of two types:
preconditions (circumstances that hold prior to test case execution) and the actual inputs that are identified by
CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2024
 some testing methods. The set of test cases is called a test suite. We may have a test suite of all possible test
cases.

Types of Software Testing

Testing is done in every stage of software development life cycle, but the testing done at each level of software
development is different in nature and has different objectives. There are different types of testing, such as stress testing,
volume testing, configuration testing, compatibility testing, recovery testing,

maintenance testing, documentation testing, and usability testing. Software testing are mainlyof following
types
1. Unit Testing
2. Integration Testing
3. System Testing

Unit Testing : Unit testing is done at the lowest level. It tests the basic unit of software, that is the smallest
testable piece of software. The individual component or unit of a program are tested in unit testing. Unit testing
are of two types.
• Black box testing: This is also known as functional testing , where the test cases are designed based
on input output values only. There are many types of Black Box Testing but following are the prominent ones.
- Equivalence class partitioning: In this approach, the domain of input values to a program is divided into a
set of equivalence classes. e.g. Consider a software program that computes whether an integer number
iseven or not that is in the range of 0 to 10. Determine the equivalence class test suite. There are three
equivalence classes for this program. - The set of negative integer - The integers in the range 0 to 10 - The
integer larger than 10
- Boundary value analysis: In this approach, while designing the test cases, the values at boundaries of
different equivalence classes are taken into consideration. e.g. In the above given example as in equivalence
class partitioning, a boundary values based test suite is { 0, -1, 10, 11 }

• White box testing: It is also known as structural testing. In this testing, test cases are designed on the basis
of examination of the code. This testing is performed based on the knowledge of how the system is
implemented. It includes analyzing data flow, control flow, information flow, coding practices, exception
and error handling within the system, to test the intended and unintended software behavior. White box
testing can be performed to validate whether code implementation follows intended design, to validate
CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2024
implemented security functionality, and to uncover exploitable vulnerabilities.This testing requires access to
the source code. Though white box testing can be performed any time in the life cycle after the code is
developed, but it is a good practice to perform white box testing during the unit testing phase.

Integration Testing
Integration testing is performed when two or more tested units are combined into a larger structure. The main
objective of this testing is to check whether the different modules of a program interface with each other
properly or not. This testing is mainly of two types:
• Top-down approach

• Bottom-up approach
In bottom-up approach, each subsystem is tested separately and then the full system is tested. But the top-
down integration testing starts with the main routine and one or two subordinate routines in the system. After
the top-level ‘skeleton’ has been tested, the immediately subroutines of the ‘skeleton’ are combined with it and
tested.

System Testing

System testing tends to affirm the end-to-end quality of the entire system. System testing is often based on
the functional / requirement specification of the system. Non-functional quality attributes, such as reliability,
security, and maintainability are also checked. There are three types of system testing
• Alpha testing is done by the developers who develop the software. This testing is also done by the client or
an outsider with the presence of developer or we can say tester.
• Beta testing is done by very few number of end users before the delivery, where the change requests are
fixed, if the user gives any feedback or reports any type of defect.
• User Acceptance testing is also another level of the system testing process where the system is tested for
acceptability. This test evaluates the system's compliance with the client requirements and assess whether
itis acceptable for software delivery
An error correction may introduce new errors. Therefore, after every round of error-fixing, another testing is
carried out, i.e. called regression testing. Regression testing does not belong to either unit testing, integration
testing, or system testing, instead, it is a separate dimension to these three forms of testing.

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2024
Regression Testing

The purpose of regression testing is to ensure that bug fixes and new functionality introduced in a software
do not adversely affect the unmodified parts of the program [2]. Regression testing is an important activity at
both testing and maintenance phases. When a piece of software is modified, it is necessary to ensure that the
quality of the software is preserved. To this end, regression testing is to retest the software using the test cases
selected from the original test suite.

Experiment Specific Instructions

Draw Test Cases for the Problem statement you framed in Practical 1.
Bibliography

1. Fundamentals of Software Engineering, Rajib Mall, Prentice-Hall of India, 3rd Edition, 2009
2. Software Engineering: A Practioner's Approach, Roger S. Pressman, McGraw Hills, 7thEdition,
2009
Webliography

1. Standards for software test documentation

2. JUnit frameworks
3. Selenium frameworks
4. HP Quality Center Tutorial
5. IBM Rational Software information Center
6. Developing Test Plans

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2024
 Test
Case ID Description Expected Outcome Pass/Fail
Verify voter can cast ballot Voter should be able to access the system from any location
TC_001 from anywhere and cast their vote successfully. Pass
Check if the system allows Voter should be able to cast their vote without any delays or
TC_002 quick voting in one session interruptions and complete the voting process in one session. Pass
The system interface should be intuitive and easy to navigate,
Test user-interface for ease of ensuring that no candidate is disadvantaged due to
TC_003 use complexity. Pass
Ensure voters have a general Voters should be provided with clear instructions and
understanding of the voting explanations at each step of the voting process to ensure
TC_004 process transparency and understanding. Pass
The system should allow for different types of questions,
Verify system supports various including open-ended questions, to provide flexibility in
TC_005 ballot question formats ballot design. Pass
Test system's ability to record All votes cast by voters should be accurately recorded and
TC_006 and count votes accurately counted without errors or discrepancies. Pass
Check eligibility verification Only authorized and registered voters should be allowed to
TC_007 process cast their votes. Pass
Ensure system prevents The system should prevent a voter from casting more than
TC_008 multiple voting one vote to maintain the uniqueness of each vote. Pass
The system should generate verifiable records of all votes
Verify auditability of the cast, ensuring that they are correctly accounted for and
TC_009 system auditable. Pass
Test voter confirmation and Voters should be able to review and modify their votes before
TC_010 modification process final submission to ensure accuracy and prevent errors. Pass
If registration issues arise, the system should allow voters to
Test provisional ballots cast provisional ballots, ensuring that no eligible voter is
TC_011 functionality disenfranchised. Pass
The design, implementation, and testing procedures of the
Verify documentation and system should be well-documented to ensure transparency
TC_012 assurance procedures and reliability. Pass
The system should have robust security measures in place to
Test robust identification and accurately identify and authenticate voters, ensuring the
TC_013 authentication process security and integrity of the voting process. Pass
The system should maintain consistent operation even during
Check consistent operation peak voting periods, ensuring reliability and availability to all
TC_014 during peak usage voters. Pass
The system should be able to handle a large number of voters
Test scalability under heavy simultaneously without degradation in performance, ensuring
TC_015 load scalability. Pass

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2024
 Test
Case ID Description Expected Outcome Pass/Fail
The system should provide fast response times even under
Verify fast response times heavy voting load to prevent delays and ensure a smooth
TC_016 under heavy load voting experience. Pass
The system should be easy to update and maintain without
Test system's ease of update requiring system downtime, ensuring minimal disruption to
TC_017 and maintenance voting operations. Pass
The system should be intuitive and easy to use for all user
Ensure usability for all user groups, regardless of their technical skill level, ensuring Pass
TC_018 groups usability and inclusivity.

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2024
 EXPERIMENT NO. 11

Identifying User Stories and Acceptance Criteria

Introduction

In the Software Development industry, the word ‘Requirement’ defines what our goal is, what the customers
exactly need, and what will make our company increase its business.

Be it a product company that makes software products or a service company that offers services in various
software fields, the prime base for all of them is the requirement, and success is defined by how well the
requirements are met.

The term ‘requirement’ has different names in different project methodologies.

In Waterfall, it is referred to as ‘Requirement/Specification Document’, in Agile or SCRUM it is referred to

as ‘Epic’, ‘User Story’.

Under Waterfall model, the Requirement documents are huge docs of 200 or more pages as the whole
product is implemented in one phase. But this is not the case with Agile/SCRUM because in these
methodologies the requirements are given for small functionalities or features as the product is prepared in a
step by step manner.

A user story is a requirement for any functionality or feature which is written down in one or two lines and
max up to 5 lines. A user story is usually the simplest possible requirement and is about one and only one
functionality (or one feature).

While user stories aim at describing what exactly the user wants the system to do, the goal of acceptance
criteria is to explain the conditions that a specific user story must satisfy

The Product Owner is responsible for creating User Stories. Generally, the Product Owner creates those, but
sometime they are developed by the Scrum team in consultation with the Product Owner. the Collaboration
in Scrum team favours the Product Owner involving the team in writing User Stories.

User Story format

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2024
The format of the User Story is as follows:
As a <user role/customer,

I want to < goal to be accomplished>so

that I can <reason of the goal>.

Example 1:

As a WhatsApp user,
I want a camera icon in the chat write box to capture and send pictures
so that I can click and share my pictures simultaneously with all my friends.
At a project level
As a Marketing Director,
I need to improve customer
serviceSo that we retain our
customers.
At a detailed
levelAs an
Investor,
I need to see a summary of my investment
accounts,So that I can decide where to focus my
attention

An acceptance criterion is a set of accepted conditions or business rules which the functionality or feature
should satisfy and meet, in order to be accepted by the Product Owner/Stakeholders.

This is a very important part of user story completion and it should be studied by the Product Owner and
Business Analyst very meticulously because missing a single criterion can cost a lot. This is a simple
numbered or bulleted list.

Format

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2024
 “Given some precondition
when I do some action
then I expect the result”.

User Story:
As a WhatsApp user,
I want a camera icon in the chat write box to capture and send pictures
so that I can click and share my pictures simultaneously with all my friends.

Acceptance Criteria:

Let’s consider that I’m chatting with a friend and I should be able to capture a

picture. When I click on a picture, I should be able to add a caption to the image

before sending it.

If there is some problem with starting my phone camera, an error message like ‘Camera
could notbe started’. etc., should be shown accordingly.

Experiment Specific Instructions

Create User stories and acceptance criteria for the problem selected in Experiment No.1

CSIT Department Software Engineering and Agile Lab Manual Session Jan-June 2024
 Software Engineering and Agile Lab Manual
User Stories and Acceptance Criteria

1. User Authentication

User Story: As a registered voter, I want to authenticate securely to access the voting system.

Acceptance Criteria:

Enter valid credentials (e.g., username/password or biometric data).

Verify successful login with correct credentials.

Ensure login fails with incorrect credentials.

Test system behavior for locked accounts or multiple failed login attempts.

2. Vote Casting

User Story: As a voter, I want to cast my vote efficiently and accurately.

Acceptance Criteria:

Display eligible ballot options based on voter's authentication.

Allow voter to select and confirm vote choices.

Ensure only one vote per voter is recorded.

Test system response when attempting to vote multiple times.

3. Transparency and Confirmation

User Story: As a voter, I want transparency in the voting process and the ability to confirm my vote before
submission.

Acceptance Criteria:

Display clear instructions and voting process steps.

Show selected vote choices for confirmation before final submission.

Allow voter to modify choices before confirming.

Ensure submitted votes are accurately recorded and cannot be altered.

4.Security and Eligibility

CSIT Department Faculty: Prof. Nisha Rathi Session Jan-June 2024
 Software Engineering and Agile Lab Manual
User Story: As a voter, I want assurance that my vote is secure and that only eligible voters can participate.

Acceptance Criteria:

Validate voter eligibility based on registration status.

Encrypt sensitive data (e.g., authentication credentials, vote choices).

Test against unauthorized access attempts and account manipulation.

5. System Performance and Scalability

User Story: As a voter during peak election hours, I want the voting system to perform reliably and efficiently.

Acceptance Criteria:

Conduct load testing to simulate concurrent user activity.

Measure system response times under varying loads.

Ensure the system remains stable and responsive during peak usage periods.

6. Maintainability and Documentation

User Story: As a system administrator, I want the voting system to be maintainable and well-documented for
future updates and enhancements.

Acceptance Criteria:

Document system architecture, components, and dependencies.

Include clear instructions for system deployment and configuration.

Test system update procedures and version control mechanisms.

CSIT Department Faculty: Prof. Nisha Rathi Session Jan-June 2024