A Laboratory Manual for

SOFTWARE ENGINEERING
(3161605)

B.E. Semester 6 (Information Technology)

Directorate of Technical Education, Gandhinagar,

Gujarat.
 Government Engineering College, Bhavnagar

Certificate

This is to certify that Mr./Ms.

Enrollment No.
of B.E. Semester _ Information
Technology of this Institute (GTU Code: ) has satisfactorily completed
the Practical / Tutorial work for the subject Software Engineering (3161605)
for the academic year 2023-24.

Place:

Date:

Name and Sign of Faculty member

Head of the Department

 Preface

The main motto of any laboratory/practical/field work is to enhance required skills and create ability
amongst students to solve real-time problems by developing relevant competencies in the
psychomotor domain. By keeping this in view, GTU has designed a competency-focused outcome-
based curriculum for engineering degree programs where sufficient weightage is given to practical
work. It shows the importance of enhancement of skills amongst the students, and it pays attention to
utilizing every second of time allotted for practicals amongst students, instructors, and faculty
members to achieve relevant outcomes by performing the experiments rather than merely study-type
experiments. It is a must for the effective implementation of a competency-focused outcome-based
curriculum that every practical is keenly designed to serve as a tool to develop and enhance relevant
competency required by the various industry among every student. These psychomotor skills are very
difficult to develop through traditional chalk-and-board content delivery methods in the classroom.
Accordingly, this lab manual is designed to focus on industry-defined relevant outcomes rather than
the old practice of conducting practicals to prove concepts and theories.

By using this lab manual, students can go through the relevant theory and procedure in advance before
the actual performance, which creates interest, and students can have a basic idea prior to the
performance. This, in turn, enhances pre-determined outcomes amongst students. Each experiment in
this manual begins with competency, industry-relevant skills, course outcomes as well as practical
outcomes (objectives). The students will also achieve safety and necessary precautions to be taken
while performing practical.

This manual also provides guidelines to faculty members to facilitate student-centric lab activities
through each experiment by arranging and managing necessary resources in order that the students
follow the procedures with required safety and necessary precautions to achieve the outcomes. It also
gives an idea of how students will be assessed by providing rubrics.

Software Engineering is an application of a systematic, defined, and measurable approach that begins
with requirement specification and progresses with planning, modeling, and testing, and concludes
with deployment. It is a layered paradigm that comprises processes, methods, and tools with the
bedrock of quality focus. The Software Engineering approach's main purpose is committed to
developing the software products within the stipulated time and budget with more quality. Quality
product motivates firmness, commodity, and delight.

Utmost care has been taken while preparing this lab manual; however ,there is always a chance of
improvement. Therefore, we welcome constructive suggestions for improvement and removal of
errors, if any.
Soft
Software Engineering (3161605)

Practical – Course Outcome matrix

Course Outcomes (COs):

CO-1: Prepare SRS (Software Requirement Specification) document and SPMP (Software Project
Management Plan) document.
CO-2: Apply the concept of Functional Oriented and Object-Oriented Approaches for Software
Design. CO-3. Recognize how to ensure the quality of software products, different quality standards,
and software review techniques.
CO-4. Apply various testing techniques and test plans in.
CO-5. Able to understand modern Agile Development
Sr.
Objective(s) of Experiment CO1 CO2 CO3 CO4 CO5
No.
Study of various type of Software Process models with
comparison and find out which process model will be
1. √
appropriate for your selected Project.

Discuss the Project Management: Project Planning and

2. √ √
Project Scheduling about your Project.
Prepare the Software Requirement Specification (SRS)
3. √ √
document for selected project.
4. Draw the Data Flow Diagram for your selected Project. √ √

Draw the Entity-Relationship Diagram for your selected

5. √ √
Project
Draw Usecase Diagram for your selected Project.
6. √ √
Solve the problem by applying basic COCOMO model.
7. √ √

8. Modeling UML Class Diagrams and Sequence diagrams √ √

Design the various test cases to perform the testing of the
9. √ √
system and also perform the various type of testing.
Study of any two Open source tools in DevOps for
Infrastructure Automation, Configuration Management
10. √
Deployment Automation, Performance Management, Log
Management Monitoring.
Soft
Software Engineering (3161605)

Industry Relevant Skills

The following industry relevant competency is expected to be developed in the student by

undertaking the practical work of this laboratory.

1. Apply knowledge of Process Models for the development of software.

2. Understand the concept of Software requirement Specification (SRS) document for project
development.

Guidelines for Faculty members

1. Teacher should provide the guideline with demonstration of practical to the students with
all features.
2. Teacher shall explain basic concepts/theory related to the experiment to the students before
starting of each practical
3. Involve all the students in performance of each experiment.
4. Teacher is expected to share the skills and competencies to be developed in the students
and ensure that the respective skills and competencies are developed in the students after
the completion of the experimentation.
5. Teachers should give opportunity to students for hands-on experience after the
demonstration.
6. Teacher may provide additional knowledge and skills to the students even though not
covered in the manual but are expected from the students by concerned industry.
7. Give practical assignment and assess the performance of students based on task assigned to
check whether it is as per the instructions or not.
8. Teacher is expected to refer complete curriculum of the course and follow the guidelines
for implementation.

Instructions for Students

1. Students are expected to carefully listen to all the theory classes delivered by the faculty
members and understand the COs, content of the course, teaching and examination scheme, skill
set to be developed etc.
2. Students shall organize the work in the group and make record of all observations.
3. Students shall develop maintenance skill as expected by industries.
4. Student shall attempt to develop related hand-on skills and build confidence.
5. Student shall develop the habits of evolving more ideas, innovations, skills etc. apart from those
Soft
Software Engineering (3161605)

included in scope of manual.

6. Student shall refer technical magazines and data books.
7. Student should develop a habit of submitting the experimentation work as per the schedule and
she/he should be well prepared for the same.

General Guidelines for Software Engineering Laboratory Work

1. Student has to perform all the practical as described in the practical list.

2. For performing the practical list, student can able to work individually or work in a team as per
subject teacher guidelines.
3. After establishing the team, every team will have to identify the problem area / definition for
performing the laboratory work.
4. Every team has to approve their problem definition to respective faculty member within 15 days
of the beginning of the semester.
5. Once the problem definition is approved by the faculty member, every team has to perform all
the practical based on their respective problem definition.
Soft
Software Engineering (3161605)

Index
(Progressive Assessment
Sheet)

Sr. Objective(s) of Experiment Page Date of Date of Assessmen Sign. of Remar

No. No. perform submiss t Teacher ks
ance ion Marks with date
1 Study of various type of Software Process
models with comparison and find out which
process model will be appropriate for your
selected Project.
2 Discuss the Project Management: Project
Planning and Project Scheduling about your
Project.
3 Prepare the Software Requirement
Specification (SRS) document for selected
project.
4 Draw the Data Flow Diagram for your selected
Project.
5 Draw the Entity-Relationship Diagram for your
selected Project
6 Draw Usecase Diagram for your selected
Project.
7 Solve the problem by applying basic
COCOMO model.
8 Modeling UML Class Diagrams and
Sequence diagrams
9. Design the various test cases to perform the
testing of the system and also perform the
various type of testing.
10. Study of any two Open source tools in
DevOps for Infrastructure Automation,
Configuration Management ,Deployment
Automation, Performance Management, Log
Management Monitoring.
Total
Soft
Software Engineering (3161605)

Practical – 1
AIM: Study of various type of Software Process models with comparison and find out which process
model will be appropriate for your selected Project.

Objectives: To learn different process models and identify suitable model for the project development.

 Theory:
A software process is defined as a collection of work activities, actions, and tasks that are
performed when some work product is to be created.

List of Different Process Models

1. Waterfall Model :
1. Requirement Gathering and
Analysis: In this initial phase, all the
necessary requirements for the
system are identified and documented
in a specification requirement
document.
2. Design: Building upon the requirements
gathered, this phase
Involves creating a detailed system
design. This design specifies the
hardware and system requirements
and defines the overall system
architecture. Figure 1:Waterfall Model
3. Implementation: Based on the system design, the actual system is developed in small units
or programs. Each unit is developed and tested individually in a process known as Unit Testing.
4. Testing: Once all the individual units are developed and tested, they are integrated into a complete
system. The integrated system is then tested thoroughly for any faults or failures.
5. Deployment of the System: After successful testing, the product is deployed in the customer
environment or released into the market.
6. Maintenance: As the system is used in the client environment, issues may arise. To address these,
patches are released. Additionally, new versions of the product may be released to enhance its features.
Maintenance ensures that these changes are delivered to the customer environment.
 Soft
Software Engineering (3161605)
2. V model :

 Verification: This phase

includes a static analysis method,
such as a review which is conducted
without executing the code. It
evaluates the product development
process to determine if specified
requirements are met.
 Validation: This phase involves a
dynamic analysis method, including
functional and non-functional
testing, which is performed by
executing the code. Validation
classifies the software after the
development process to ascertain if
it meets customer expectations and
Figure 2:V Model
requirements.
 The V-Model incorporates
Verification phases on one side and Validation phases on the other side. The Verification and
Validation processes are connected by the coding phase in a V-shape, hence its name. Here are the
various phases of the Verification Phase in the V-model:

1. Business Requirement Analysis: This initial step involves understanding the product requirements from
the customer's perspective. It requires detailed communication to grasp the customer's expectations and
exact requirements.
2. System Design: In this stage, system engineers analyze and interpret the business aspects of the
proposed system by studying the user requirements document.
3. Architecture Design: The architecture design phase involves selecting a baseline architecture that
comprehensively addresses all requirements. This typically includes a list of modules, brief functionality
of each module, interface relationships, dependencies, database tables, architecture diagrams, technology
details, etc. Integration testing is also carried out in this phase.
4. Module Design: During this phase, the system is broken down into small modules. Detailed designs of
these modules are specified, which is known as Low-Level Design.
5. Coding Phase: After the design phase, the coding phase begins. Based on the requirements, a suitable
programming language is chosen. Coding is done following specific guidelines and standards. Before
checking in the repository, the final build is optimized for better performance. The code also undergoes
many code reviews to ensure its performance.

There are the various phases of Validation Phase of V-model:

1. Unit Testing: In the V-Model, Unit Test Plans (UTPs) are developed during the module design phase.
These UTPs are executed to eliminate errors at code level or unit level. A unit is the smallest entity
which can independently exist, e.g., a program module. Unit testing verifies that the smallest entity
can function correctly when isolated from the rest of the codes/ units.
2. Integration Testing: Integration Test Plans are developed during the Architectural Design Phase.
These tests verify that groups created and tested independently can coexist and communicate among
themselves.
Soft
Software Engineering (3161605)
3. System Testing: System Tests Plans are developed during System Design Phase. Unlike Unit and
Integration Test Plans, System Tests Plans are composed by the client’s business team. System Test
ensures that expectations from an application developer are met.
4. Acceptance Testing: Acceptance testing is related to the business requirement analysis part. It
includes testing the software product in user atmosphere. Acceptance tests reveal the compatibility
problems with the different systems, which is available within the user atmosphere. It conjointly
discovers the non-functional problems like load and performance defects within the real user
atmosphere.

3. Incremental model :
The Incremental Model of software development
Progress through several phases:
1. Requirement Analysis: In this initial phase,
the product analysis experts identify the
requirements. The requirement analysis
team understands the system's functional
requirements, which plays a crucial
role in developing software under the
incremental model.
Figure 3:Incremental Model

2. Design & Development: This phase completes the design of the system functionality and the
development of the method. The incremental model uses the design and development phase when
developing new functionality.

3. Testing: The testing phase in the incremental model checks the performance of each existing function and
any additional functionality. Various methods are used to test the behavior of each task.

4. Implementation: The implementation phase enables the coding phase of the development system. It
involves the final coding designed in the design and development phase and tests the functionality from
the testing phase. After this phase, the product's working functionality is enhanced and upgraded to the
final system product.

The Incremental Model is used in the following scenarios:

• When requirements are complex: Breaking them down into smaller chunks makes them easier to handle.
• For lengthy development schedules: Incremental development allows for regular releases, keeping
stakeholders engaged.
• With less experienced teams: It allows for learning and improvement over successive iterations.
• When quick product releases are required: Incremental development enables rapid, iterative
improvements.
• For prioritized requirements: Allows development of high-priority features first, ensuring essential
functionality is delivered early.

4. RAD model.
Soft
Software Engineering (3161605)

Figure 4: RAD Model

The various phases of RAD are as follows:

1. Business Modelling: This phase defines the flow of information among business functions. It answers
questions like what data drives the business process, who generates it, where does it go, who processes it,
and so on.
2. Data Modelling: The data collected from business modeling is refined into a set of data objects (entities)
needed to support the business. Attributes (characteristics of each entity) are identified, and the
relationships between these data objects (entities) are defined.
3. Process Modelling: Information objects defined in the data modeling phase are transformed to achieve
the data flow necessary to implement a business function. Processing descriptions are created for adding,
modifying, deleting, or retrieving a data object.
4. Application Generation: This phase involves using automated tools to facilitate the construction of the
software.
5. Testing & Turnover: Many of the programming components have already been tested since RAD
emphasizes reuse. This reduces overall testing time. However, the new parts must be tested, and all
interfaces must be fully exercised.

5. Agile model :

Phases of Agile Model:

Soft
Software Engineering (3161605)
1. Requirements gathering: In this phase, the requirements are defined. It involves explaining business
opportunities and planning the time and effort needed to build the project. Based on this information,
technical and economic feasibility can be evaluated.
2. Designing: Once the project is identified, stakeholders work together to define requirements. User flow
diagrams or high-level UML diagrams can be used to illustrate the workflow of new features and how
they will integrate with the existing system.
3. Construction/ iteration: After the requirements are defined, the work begins. Designers and developers
start working on the project, aiming to deploy a working product. The product undergoes various stages
of improvement, including the inclusion of simple, minimal functionality.
4. Testing: In this phase, the Quality Assurance team examines the product's performance and looks for
bugs.
5. Deployment: In this phase, the team issues a product for the user's work environment.
6. Feedback: After releasing the product, the last step is feedback. In this, the team receives feedback about
the product and works through the feedback.

Agile Testing Methods:

1. Scrum
2. Crystal
3. Dynamic Software Development Method (DSDM)
4. Feature Driven Development (FDD)
5. Lean Software Development
6. eXtreme Programming (XP)

When to use the Agile Model?

• When frequent changes are required.
• When a highly qualified and experienced team is available.
• When a customer is ready to have a meeting with a software team all the time.
• When project size is small.

6. Iterative model :

Figure 6:Iterative Model

The various phases of Iterative model are as follows:

Soft
Software Engineering (3161605)
1. Requirement gathering & analysis: In this phase, requirements are gathered from customers and
analyzed by an analyst to ensure they can be fulfilled within budget. Once this is done, the software team
moves on to the next phase.
2. Design: During the design phase, the team creates the software using various diagrams such as Data
Flow diagrams, activity diagrams, class diagrams, and state transition diagrams.
3. Implementation: In the implementation phase, the requirements are translated into code and transformed
into computer programs, which form the software.
4. Testing: After the coding phase is completed, software testing begins using different methods such as
white box, black box, and grey box testing.
5. Deployment: Once all the phases are completed, the software is deployed to its working environment.
6. Review: After the software is deployed, a review phase is conducted to check the behavior and validity
of the product. If any errors are found, the process starts again from the requirement gathering phase.
7. Maintenance: In the maintenance phase, after deployment of the software in the working environment
there may be some bugs, some errors or new updates are required. Maintenance involves debugging and
new addition options.

7. Spiral model :

Figure 7:Spiral Model

Each cycle in the spiral is divided into four parts:

1. Objective setting: Each cycle in the spiral starts with the identification of purpose for that cycle, the
various alternatives that are possible for achieving the targets, and the constraints that exists.
2. Risk Assessment and reduction: The next phase in the cycle is to calculate these various alternatives
based on the goals and constraints. The focus of evaluation in this stage is located on the risk
perception for the project.
3. Development and validation: The next phase is to develop strategies that resolve uncertainties and
risks. This process may include activities such as benchmarking, simulation, and prototyping.
4. Planning: Finally, the next step is planned. The project is reviewed, and a choice made whether to
continue with a further period of the spiral. If it is determined to keep, plans are drawn up for the next
step of the project.
 Soft
Software Engineering (3161605)
• The development phase depends on the remaining risks. For example, if performance or user-interface
risks are treated more essential than the program development risks, the next phase may be an
evolutionary development that includes developing a more detailed prototype for solving the risks.
• The risk-driven feature of the spiral model allows it to accommodate any mixture of a specification-
oriented, prototype-oriented, simulation-oriented, or another type of approach. An essential element of
the model is that each period of the spiral is completed by a review that includes all the products
developed during that cycle, including plans for the next cycle. The spiral model works for development
as well as enhancement projects.

8. Prototype model :

The prototype model requires that before carrying out the development of actual software, a working
prototype of the system should be built. A prototype is a toy implementation of the system. A
prototype usually turns out to be a very crude version of the actual system, possible exhibiting limited
functional capabilities, low reliability, and inefficient performance as compared to actual software. In
many instances, the client only has a general view of what is expected from the software product. In
such a scenario where there is an absence of detailed information regarding the input to the system,
the processing needs, and the output requirement, the prototyping model may be employed.

Steps of Prototype Model

 Requirement Gathering and Analyst

 Quick Decision
 Build a Prototype
 Assessment or User Evaluation
 Prototype Refinement
 Engineer Product

Q1) Write the reasons to justify which life cycle model you going use to develop a software in your
 Soft
Software Engineering (3161605)
project?

 For our project named 3-level password authentication, we used incremental model.
 Here are reasons for using incremental model:
1)Requirement evolution: Since security requirement can evolve, an iterative model allows for
refinement and adaption as the project progresses each iteration can address new security concerns or
requirement that emerge during development.
2)Risk management: With sensitive authentication systems, risk management is crucial. The iterative
model allows for early identification and mitigation of risks though multiple cycles of development and
testing, reducing the likelihood of security vulnerabilities.
3)Feedback Loop: An iterative approach facilities continuous feedback from stakeholders and end users
ensuring that the authentication systems meets their needs effectively. This is important for refining the
authentication mechanism at each level.
4)Testing and validation: Security testing is paramount in authentication systems. Iterative development
allows for frequent testing and validation of security features ensuring that each level of authentication is
robust and effective.

Q2) Give reasons for all other life cycle models not to select those life cycle models. Justify with valid
reasons.

 Waterfall Model: The waterfall model is not ideal for this project because it follows a linear, sequential
approach where each phase must be completed before moving to the next. Given the complexity of
authentication systems and the likelihood of evolving requirements, the rigid structure of the waterfall
model makes it difficult to accommodate changes or incorporate feedback effectively.
 Spiral Model: While the spiral model emphasizes risk management and allows for iterative development,
it may not be the best fit for this project due to its emphasis on addressing high-risk areas early in the
development process. While security is a significant concern, the 3-level password authentication project
may require more frequent iterations and testing cycles than the spiral model typically allows.
 V-Model (Verification and Validation Model): The V-Model is a testing-centric approach that aligns
testing activities with development phases. However, it may not be suitable for this project because it
does not inherently support the iterative refinement of security features or accommodate evolving
requirements throughout the development lifecycle. Additionally, it may not provide sufficient flexibility
to address unforeseen security vulnerabilities or changes in authentication protocols.
 Agile Model: While Agile methodologies promote flexibility, collaboration, and customer involvement,
they may not be the best fit for a project with strict security requirements like a 3-level password
authentication system. Agile projects typically prioritize delivering working software in short iterations,
which may not align well with the meticulous planning and rigorous testing needed for robust
authentication mechanisms. Additionally, Agile's emphasis on adaptability may not provide enough
structure for managing the inherent risks and complexities of security-sensitive projects.
 In summary, while each life cycle model has its strengths, the unique requirements and challenges of
developing a 3-level password authentication project necessitate an approach that prioritizes iterative
refinement, rigorous testing, and adaptability to evolving security concerns, making the iterative or
incremental model the most suitable choice.

Quiz:

1. Compare waterfall model and incremental model.

Soft
Software Engineering (3161605)

 Waterfall Model:

a)Sequential Approach: The waterfall model follows a linear and sequential approach to software
development. Each phase must be completed before moving on to the next one.
b)Phases: It typically consists of sequential phases such as requirements gathering, design,
implementation, testing, deployment, and maintenance.
c)Minimal Flexibility: Once a phase is completed, it's challenging to go back and make changes without
affecting subsequent phases, which can lead to rigidity in accommodating changes.
d)Documentation Heavy: Each phase requires extensive documentation, making it suitable for projects
where requirements are well-defined and unlikely to change significantly.
e)Late Feedback: Feedback from stakeholders or end-users typically occurs late in the process, often at
the testing or deployment phase.
f)Example: Traditional engineering projects like building construction often follow a waterfall model.

 Incremental Model:

a)Iterative Approach: The incremental model follows an iterative approach where the software is
developed, tested, and delivered in incremental chunks or increments.
b)Phases: It involves breaking down the project into small, manageable modules or increments. Each
increment goes through the phases of requirements, design, implementation, and testing.
c)Flexibility: The incremental model offers more flexibility as changes can be accommodated at the
beginning of each increment, allowing for a more adaptive development process.
d)Early Feedback: Stakeholders can provide feedback early in the development process as increments are
delivered incrementally, allowing for continuous improvement.
e)Less Documentation: Documentation is typically lighter compared to the waterfall model as it focuses
more on delivering working increments rather than extensive documentation.
f)Example: Agile methodologies like Scrum and Extreme Programming (XP) follow incremental
approaches.

2. State weather the following statements are true or false. Justify your answer.
a) Software development organizations which follow the iterative waterfall model for
product development provide maximum customer satisfaction.
 False.
 Software development organizations that follow the iterative waterfall model for product
development do not necessarily provide maximum customer satisfaction. The iterative waterfall
model, although it incorporates some iterative elements, is still fundamentally sequential and rigid.
It lacks the continuous customer involvement and adaptability to change that are characteristic of
Agile methodologies like Scrum or Kanban. Maximum customer satisfaction often comes from
approaches that allow for frequent feedback, flexibility, and early delivery of valuable features,
which are hallmarks of Agile methodologies rather than the iterative waterfall model.

b) The loops for spiral model are fixed.

 False.
 The loops in the Spiral Model are not fixed. The Spiral Model is a risk-driven software development
process model that emphasizes iterative development and incorporates elements of both waterfall and
 Soft
Software Engineering (3161605)
iterative models. It consists of several cycles or loops, with each loop representing a phase of the
software development process. The number of loops and the activities within each loop can vary based
on project requirements, risk assessment, and feedback from previous iterations. The Spiral Model
allows for flexibility in tailoring the development process to the specific needs of the project, so the
loops are not fixed but rather adaptable based on the project's evolving requirements

Suggested Reference:

1. Ian Sommerville, Software engineering, Pearson education Asia

2. Roger S.Pressman, Software Engineering- A practitioner‟s Approach, McGraw-Hill International Editions

References used by the students:

Rubric wise marks obtained:

Rubrics 1 2 3 4 5 Total

Marks Complete Complete Complete Complete Complete

implementation as implementation as implementation as implementation as implementation as
asked asked asked asked asked

Problem analysis Problem analysis Problem analysis Problem analysis

Development of the Development of the Development of the

Solution Solution Solution

Concept Clarity & Concept Clarity &

understanding understanding

Correct answer to all

questions

Signature of Faculty:
Soft
Software Engineering (3161605)

Practical – 2
AIM: Discuss the Project Management: Project Planning and Project Scheduling about your Project.

Objectives:

1. To represent the plan to deliver the project scope over time.

Theory:
Once a project is found to be feasible, software project managers undertake project planning. Project
planning is undertaken and completed even before any development activity starts. Project planning
consists of the following essential activities:
Project-task scheduling is an important project planning activity. It involves deciding which
tasks would be taken up when. In order to schedule the project activities, a software project manager
needs to do the following:

1. Identify all the tasks needed to complete the project.

2. Break down large tasks into small activities.
3. Determine the dependency among different activities.
4. Establish the most likely estimates for the time durations necessary to complete the activities.
5. Allocate resources to activities.
6. Plan the starting and ending dates for various activities.
7. Determine the critical path.

A critical path is the chain of activities that determines the duration of the project. The first step in
scheduling a software project involves identifying all the tasks necessary to complete the project. A
good knowledge of the intricacies of the project and the development process helps the managers to
effectively identify the important tasks of the project. Next, the large tasks are broken down into a
logical set of small activities which would be assigned to different engineers. The work breakdown
structure formalism helps the manager to breakdown the tasks systematically after the project manager
has broken down the tasks and created the work breakdown structure, he has to find the dependency
among the activities.

Dependency among the different activities determines the order in which the different activities would
be carried out. If an activity A requires the results of another activity B, then activity A must be
scheduled after activity B. In general, the task dependencies define a partial ordering among tasks, i.e.
each tasks may precede a subset of other tasks, but some tasks might not have any precedence ordering
defined between them (called concurrent task). The dependency among the activities is represented in
the form of an activity network. Once the activity network representation has been worked out,
resources are allocated to each activity.
Soft
Software Engineering (3161605)

1. Identify all the tasks needed to complete the project.

To complete a project on 3-level password authentication, you would typically need to complete the following
tasks:

● Define Requirements: Clearly outline the specifications and requirements for the authentication system,
including the three levels of authentication.

● Design System Architecture: Create a high-level design of the authentication system, including how the three
levels of authentication will be implemented.

● Implement Authentication Logic: Develop the code for the three levels of authentication, including password
validation, storage, and comparison.

● User Interface Design: Design the user interface for entering and managing passwords at each level of
authentication.

● Database Design: Set up a database to store user information and passwords securely.

● Implement Security Measures: Implement security measures to protect the authentication system from common
threats like brute force attacks and password guessing.

● Testing: Test the authentication system thoroughly to ensure that it works as expected and is secure.

● Documentation: Create documentation for the authentication system, including user guides and technical
documentation for developers.

● Deployment: Deploy the authentication system to a production environment, ensuring that it is accessible and
secure.

● Maintenance: Regularly update and maintain the authentication system to address security vulnerabilities and
improve performance.
 Soft
Software Engineering (3161605)

2.Break down large tasks into small activities

The large tasks for implementing a 3-level password authentication system can be broken down into several key
components:

Overall System Design:

Define the overall architecture of the authentication system, including the three levels of authentication.
Specify how users will interact with the system at each level.

Database Design and Implementation:

Design the database schema to store user information and passwords.
Implement the database to securely store and manage user data.

Password Encryption and Storage:

Develop a method to securely hash and store passwords for each level of authentication.
Ensure that passwords are stored in a way that is resistant to common attacks, such as brute-force or dictionary
attacks.

Authentication Logic:
Implement the logic for verifying passwords at each level of authentication.
Develop mechanisms for handling password resets and recovery.

User Interface Design:

Design user interfaces for users to enter and manage their passwords at each level of authentication.
Ensure that the interfaces are intuitive and easy to use.

Security Measures:
Implement security measures to protect against common threats, such as password guessing or eavesdropping.
Use encryption and secure communication protocols to protect passwords in transit.

Testing and Quality Assurance:

Develop test cases to ensure that the authentication system functions correctly and securely.
Conduct thorough testing to identify and fix any issues before deployment.

Documentation:
Create documentation for users and administrators on how to use and manage the authentication system.
Document the system architecture and design decisions for future reference.

Deployment and Integration:

Deploy the authentication system to a production environment.
Integrate the authentication system with other systems and applications as needed.

Monitoring and Maintenance:

Monitor the authentication system for security vulnerabilities and performance issues.
Perform regular maintenance and updates to ensure the system remains secure and functional.
These tasks represent the major components of implementing a 3-level password authentication system, and
breaking them down into smaller, manageable tasks can help ensure a successful implementation.
 Soft
Software Engineering (3161605)

These are some large tasks we need for 3 level password authentication.

 We can break down these tasks in small parts like.

1. Define Requirements: Identify and document the specific needs and constraints for the authentication system,
including the criteria for each level of authentication and acceptable password policies.

2. Design System Architecture: Create a high-level design of the authentication system, outlining the components,
interactions, and data models for user information and password storage.

3. Implement Authentication Logic: Develop the code for validating passwords at each level, storing passwords
securely, and comparing passwords for authentication.

4. User Interface Design: Design user interfaces for each level of authentication, including login screens and
password management interfaces, focusing on usability and clarity.

5. Database Design: Design the database schema for storing user information and passwords securely, implementing
encryption and access controls.

6. Implement Security Measures: Implement measures to protect the authentication system from common threats,
such as brute force attacks, using secure password hashing algorithms and secure transmission protocols.

7. Testing: Develop and execute test cases to ensure the authentication system functions correctly and securely,
including unit tests, integration tests, and security tests.

8. Documentation: Create user guides and technical documentation for developers, detailing how to use and
integrate with the authentication system.

9. Deployment: Prepare the authentication system for deployment to a production environment, ensuring it is secure
and accessible.

10. Maintenance: Regularly update and maintain the authentication system to address security vulnerabilities and
improve performance, providing ongoing support for users and developers.
 Soft
Software Engineering (3161605)

3. Determine the most likely dependency among different activities.

Here's a general overview of the dependencies among the activities for implementing a 3-level password
authentication system:

Overall System Design: This activity is foundational and should be completed before any other activities. It
will inform the design and implementation of other components.

Database Design and Implementation: This activity can be done in parallel with the overall system
design, but it depends on the overall system architecture.

Password Encryption and Storage: This activity depends on the database design and implementation, as it
involves storing passwords securely in the database.

Authentication Logic: This activity depends on the overall system design and the password encryption and
storage mechanism.

User Interface Design: This activity can be done concurrently with other activities but may require input
from the overall system design and authentication logic.

Security Measures: This activity is intertwined with other activities and should be considered throughout the
project.

Testing and Quality Assurance: This activity depends on the completion of the authentication logic and user
interface design.

Documentation: This activity can be done concurrently with other activities but may require finalization after
the completion of the system implementation.

Deployment and Integration: This activity depends on the completion of all other activities and is typically
one of the final steps in the project.

Monitoring and Maintenance: This activity is ongoing and should be considered throughout the project
lifecycle.
Soft
Software Engineering (3161605)

4. Establish the most likely estimates for the time durations necessary to complete the activities.

Estimating the time durations for each activity is important for creating a realistic project schedule. Here are some
rough estimates for the time durations of each activity in implementing a 3-level password authentication
system:

Overall System Design: 1-2 weeks

This activity involves defining the system architecture, which includes determining the three levels of authentication
and how they will be implemented.

Database Design and Implementation: 2-4 weeks

Designing the database schema and implementing it can be time-consuming, especially ensuring the security of
password storage.

Password Encryption and Storage: 1-2 weeks

Implementing the encryption and storage mechanism for passwords should be relatively straightforward but requires
attention to security details.

Authentication Logic: 2-3 weeks

Developing the logic for password verification and management at each level may require careful planning and
implementation.

User Interface Design: 1-2 weeks

Designing user interfaces for password entry and management should be completed in parallel with other activities
but may require revisions based on system design changes.

Security Measures: Ongoing

Implementing security measures should be an ongoing concern throughout the project, but specific tasks related to
security can be estimated at 1-2 weeks.

Testing and Quality Assurance: 1-2 weeks

Testing the authentication system thoroughly to ensure it functions correctly and securely is crucial and should be
allocated sufficient time.

Documentation: 1 week
Creating documentation for users and administrators should be relatively quick but may require updates based on
system changes.

Deployment and Integration: 1-2 weeks

Deploying the authentication system to a production environment and integrating it with other systems can be
complex and should be carefully planned.

Monitoring and Maintenance: Ongoing

Monitoring and maintaining the authentication system should be an ongoing activity, with specific tasks estimated
at 1-2 weeks initially and then ongoing as part of regular operations.

These estimates are rough and can vary based on the complexity of the authentication system, the team's expertise,
and other factors. It's important to review and adjust these estimates as the project progresses to ensure the
schedule remains realistic.
Soft
Software Engineering (3161605)

5. allocate resources to activities.

Allocating resources to activities involves assigning the necessary personnel, tools, and materials
to each task to ensure they are completed efficiently. Here's how you might allocate
resources to the activities for implementing a 3-level password authentication system:

Overall System Design:

Personnel: System architect, security expert
Tools: Design software (e.g., UML tools)
Materials: None

Database Design and Implementation:

Personnel: Database architect, database developers
Tools: Database design software (e.g., ERD tools), database management system
Materials: None

Password Encryption and Storage:

Personnel: Security expert, software developers
Tools: Encryption libraries (e.g., bcrypt, Argon2)
Materials: None

Authentication Logic:
Personnel: Software developers
Tools: Programming languages and libraries
Materials: None

User Interface Design:

Personnel: UI/UX designer, graphic designer
Tools: Design software (e.g., Adobe XD, Sketch)
Materials: None

Security Measures:
Personnel: Security expert, software developers
Tools: Security tools (e.g., vulnerability scanners)
Materials: None

Testing and Quality Assurance:

Personnel: QA engineers, software testers
Tools: Testing frameworks (e.g., Selenium, JUnit)
Materials: Test environments

Documentation:
Personnel: Technical writers
Tools: Documentation tools (e.g., Microsoft Word, Confluence)
Soft
Software Engineering (3161605)
Materials: None

Deployment and Integration:

Personnel: DevOps engineers, system administrators
Tools: Deployment tools (e.g., Docker, Kubernetes)
Materials: Server infrastructure

Monitoring and Maintenance:

Personnel: System administrators, security experts
Tools: Monitoring tools (e.g., Prometheus, ELK stack)
Materials: None

Allocate resources based on the expertise required for each task and ensure that team members
have the necessary tools and materials to complete their work effectively. Adjust resource
allocations as needed throughout the project to address any changing requirements or
priorities.
Soft
Software Engineering (3161605)

6. plan the starting and ending dates for various activities

Planning the starting and ending dates for each activity involves creating a timeline that accounts for
dependencies, resource availability, and overall project goals. Here's a sample timeline for the
activities involved in implementing a 3-level password authentication system:

Overall System Design:

Start Date: Week 1
End Date: Week 2
Database Design and Implementation:
Start Date: Week 1
End Date: Week 4
Password Encryption and Storage:
Start Date: Week 3
End Date: Week 4
Authentication Logic:
Start Date: Week 3
End Date: Week 5
User Interface Design:
Start Date: Week 2
End Date: Week 3
Security Measures:
Start Date: Week 1
End Date: Ongoing
Testing and Quality Assurance:
Start Date: Week 5
End Date: Week 6
Documentation:
Start Date: Week 6
End Date: Week 7
Deployment and Integration:
Start Date: Week 7
End Date: Week 8
Monitoring and Maintenance:
Start Date: Week 8
End Date: Ongoing

This timeline assumes a sequential workflow with some activities overlapping where possible. However, it's
important to note that some activities, such as security measures and monitoring, are ongoing and should be
considered throughout the project lifecycle. Adjust the timeline as needed based on the specific requirements
and constraints of your project.
Soft
Software Engineering (3161605)

7. determine the critical path.

The critical path is the longest path through the project, determining the shortest time in which the project can
be completed. It's crucial because any delay in tasks along the critical path will directly impact the
project's overall timeline.
To determine the critical path for implementing a 3-level password authentication system, we need to identify
the sequence of activities that will take the longest to complete. Here's a simplified example based on
the previously outlined activities and their estimated durations:

Overall System Design (2 weeks)

Database Design and Implementation (4 weeks)
Password Encryption and Storage (2 weeks)
Authentication Logic (3 weeks)
User Interface Design (2 weeks)
Security Measures (2 weeks)
Testing and Quality Assurance (2 weeks)
Documentation (1 week)
Deployment and Integration (2 weeks)
Monitoring and Maintenance (ongoing)

the critical path would include activities 1, 2, 4, 7, 9, and 10, as these are the longest sequential activities.
Any delay in these tasks would directly impact the project's overall timeline. It's important to manage these
critical path activities carefully to ensure the project stays on track.
Soft
Software Engineering (3161605)

Resource allocation is typically done using a Gantt chart. After resource allocation is done, a PERT
chart representation is developed. The PERT chart representation is suitable for program monitoring and
control. For task scheduling, the project manager needs to decompose the project tasks into a set of
activities. The time frame when each activity is to be performed is to be determined. The end of each
activity is called milestone. The project manager tracks the progress of a project by monitoring the
timely completion of the milestones. If he observes that the milestones start getting delayed, then he has
to carefully control the activities, so that the overall deadline can still be met.

A Gantt chart(Time line chart) is a special type of bar chart where each bar represents an activity. The
bars are drawn along a time line. The length of each bar is proportional to the duration of time planned
for the corresponding activity. Gantt charts are used in software project management are actually an
enhanced version of the standard Gantt charts.
 Soft
Software Engineering (3161605)

Quiz:

a) Explain project scheduling process.

The project scheduling process for implementing a 3-level password authentication system involves
creating a timeline that outlines when each task will start and end, considering dependencies, resource
availability, and project goals. Here's a step-by-step guide to the project scheduling process:
Define Activities: List all the activities required to implement the 3-level password authentication
system. These activities should include designing the system, developing authentication logic, creating
user interfaces, testing, documentation, deployment, and maintenance.
Sequence Activities: Determine the order in which the activities need to be completed. Some
activities can be done in parallel, while others may have dependencies that require one activity to be
completed before another can start.
Estimate Durations: Estimate the time it will take to complete each activity. Use historical data, expert
judgment, and other relevant information to come up with realistic estimates.
Develop a Schedule: Create a timeline that shows when each activity will start and end. Use tools like
Gantt charts or project management software to visualize the schedule.
Allocate Resources: Assign the necessary personnel, tools, and materials to each activity. Ensure that
resources are available when needed to avoid delays.
Identify the Critical Path: Determine the critical path, which is the longest sequence of activities that
determines the shortest possible duration for the project. Focus on managing tasks along the critical
path to avoid delays.
Monitor and Control: Continuously monitor the progress of the project and make adjustments as
needed. Keep stakeholders informed of any changes to the schedule.
Review and Update: Regularly review the project schedule and update it as necessary to reflect
changes in scope, resources, or other factors.

b) Explain Software metrics used for software cost estimation

Software metrics are used to quantify various aspects of the software development process, including
size, complexity, and quality. They play a crucial role in software cost estimation by providing a basis
for estimating the effort, time, and resources required to complete a project. Here are some software
metrics that can be used for estimating the cost of implementing a 3-level password authentication
system:
Lines of Code (LOC): LOC is a simple metric that measures the size of the codebase. It can be used to
estimate the effort required for development and maintenance based on historical data.
Function Points (FP): FP is a measure of the functionality provided by a software system. It considers
inputs, outputs, queries, files, and interfaces to estimate the size of the software and can be used to
estimate development effort.
Cyclomatic Complexity: Cyclomatic complexity measures the complexity of a software system by
counting the number of independent paths through the code. It can be used to estimate the testing
effort required for the authentication system.
 Soft
Software Engineering (3161605)
Code Quality Metrics: Metrics such as code coverage, code duplication, and code smells can be used
to assess the quality of the codebase. Better code quality generally leads to lower maintenance costs.
Effort Estimation: Effort estimation metrics, such as person-months or person-hours required to
complete a task, can be used to estimate the overall effort for developing the authentication system.
Schedule Estimation: Metrics such as project duration and milestone completion dates can be used
to estimate the schedule for developing and deploying the authentication system.
Defect Density: Defect density measures the number of defects found per unit of code. It can be used
to estimate the cost of fixing defects during development and maintenance.

Suggested Reference:

1. Ian Sommerville, Software engineering, Pearson education Asia

2. Roger S.Pressman, Software Engineering- A practitioner‟s Approach, McGraw-Hill
International Editions
References used by the students:

Rubric wise marks obtained:

Rubrics 1 2 3 4 5 Total

Marks Complete Complete Complete Complete Complete

implementation implementation implementation implementation implementation
as asked as asked as asked as asked as asked

Problem analysis Problem analysis Problem analysis Problem analysis

Development of Development of Development of

the Solution the Solution the Solution

Concept Clarity Concept Clarity

& understanding & understanding

Correct answer to
all questions

Signature of Faculty:
Soft
Software Engineering (3161605)

Practical – 3
AIM: Prepare the Software Requirement Specification (SRS) document for selected project.

Objectives:

1. Learn how to provide a detailed overview of our software product, its parameters and goals.

2. Describes the project's target audience and its user interface, hardware and software requirements.

Theory:

A software requirements specification (SRS) is a document that is created when a detailed description of
all aspects of the software to be built must be specified before the project is to commence. It is important
to note that a formal SRS is not always written. In fact, there are many instances in which effort
expended on an SRS might be better spent in other software engineering activities. However, when
software is to be developed by a third party, when a lack of specification would create severe business
issues, or when a system is extremely complex or business critical, an SRS may be justified.

IEEE Template for SRS

Soft
Software Engineering (3161605)

Software Requirements Specification

For <Project>
Version 1.0 approved

Prepared by <author>

<organization>

<date created>
Soft
Software Engineering (3161605)

Table of Contents
Table of Contents 11
Revision History 12
1. Introduction 13
1.1 Purpose 13
1.2 Document Conventions 13
1.3 Intended Audience and Reading SuggestionsError! Bookmark not defined.
1.4 Product Scope 13
1.5 References 13
2. Overall Description 13
2.1 Product Perspective 13
2.2 Product Functions 13
2.3 User Classes and Characteristics 13
2.4 Operating Environment 13
2.5 Design and Implementation Constraints 14
2.6 User Documentation 14
2.7 Assumptions and Dependencies 14
3. External Interface Requirements 14
3.1 User Interfaces 14
3.2 Hardware Interfaces 14
3.3 Software Interfaces 14
3.4 Communications Interfaces 14
4. System Features 15
4.1 System Feature 1 15
4.2 System Feature 2 (and so on) 15
5. Other Nonfunctional Requirements 15
5.1 Performance Requirements 15
5.2 Safety Requirements 15
5.3 Security Requirements 16
5.4 Software Quality Attributes 16
5.5 Business Rules 16
6. Other Requirements 16
Appendix A: Glossary16
Appendix B: Analysis Models 16
Appendix C: To Be Determined List 16

Revision History
Name Date Reason For Changes Version
 Soft
Software Engineering (3161605)

Introduction
Purpose
This software requirement specification (SRS) document describes the functional and non
functional
description of the “Graphical Password Authentication System “ release version 1.0. The working
and objectives is briefly summarized followed by detailed description of the system’s scope, vision,
use case, features and other related requirement issues. In the project’s later phases, such as
system design, database design, implementation and testing, this document should be referred as
functional model of the system for release 1.0.
Document Conventions
In this SRS for the “3-level password authentication system”, we have adhered to the following conventions:

Fonts: We have used ‘Arial’ for the main text, ‘Courier New’ for code snippets, and ‘Times New Roman’ for
headers.

Highlighting: Important terms and concepts are highlighted in bold. Code or technical terms are presented in
monospace.

Requirement Priorities: Each requirement statement has its own priority. Higher-level requirement priorities
are not assumed to be inherited by detailed requirements.

Requirement Identification: Each requirement is uniquely identified with a number for easy reference.

Terminology: All terms are defined in a glossary at the end of the document. Blockchain and barcode-related
terms are used consistently throughout the document.

These conventions ensure clarity and consistency throughout the document.

Product Scope

References
1. Roger S. Pressman, “Software Engineering: A Practitioner’s Approach”, 7th Edition, McGrawHill,
Singapore,2022.
2. Bin B. Zhu, Jeff Yan, Guanbo Bao, Maowei Yang, and Ning Xu, “Captcha as Graphical
Password-A new Security Primitive Based on Hard AI Problems”, IEEETRANSACTIONS ON
FORENSIC AND SECURITY, VOL. 9, NO. 6, JUNE 2014
3. [IEEE Standard 181-1988]:The standard followed by the current SRS
Overall Description
Product Perspective
In this project, main aim is to enhance security of user login using 3-level of password authentication.
Enhanced security measures will be taken to improve the security of the files uploaded using the same
technology.
Product Functions
In this project, we are using function such as:
 Graphical password generation
 Authentication
 Uploading and Downloading file with integrated security
Soft
Software Engineering (3161605)
 For 3 different times in different ways validating the user
User Classes and Characteristics
Generally the users are classified into two:
 Administrator
 Users
Admin is responsible for the maintenance of the software and he will see for the security measures for the
system. He should be given the authority to add and delete users.
Users can use the system to upload or download their files or documents.
Operating Environment
Hardware Requirements:
 Processor: Pentium G or above.
 RAM: Minimum 1 GB.
 Standard Keyboard and Mouse.

Software Requirements:
 Operating System: Windows 7 and above.
 Java jdk1.7.0
 Eclipse
 Tomcat 5.0/6.X
 MySQL Serve

Design and Implementation Constraints

Input Design: This involve:
 Input to the front end of the system is designed to be the 3 types of different passwords
such as, 1)User ID and Password
2)Graphical password
3)Image password
User Documentation
In this software, we prepare an about page so that the user can read it and can execute the
software properly. It can be seen at top of the Menu page labelled ‘About’. This page will
helps the users to work the software.
Assumptions and Dependencies
There are many dependencies and assumptions associated with the software. They are:
 Every user is expected to have a valid user id and 3 types of passwords
 The size of the files uploaded should not exceed the limit
External Interface Requirements
User Interfaces
The interface between user and the system include many provisions from where they can access the whole system.
It contains the option list to move one form to another as well as searches form that is as follows:
 Login/sing up page
 Generate graphical password page
 File Management Page
Hardware Interfaces
1. Keypad: The keypad serves as the input device for users to enter their passwords. It usually consists of a
matrix of buttons, each representing a numeric digit or an alphanumeric character.
2. Display: A display is used to provide feedback to the user, such as prompts for entering passwords, error
messages, or confirmation messages upon successful authentication. This could be an LCD display, LED
Soft
Software Engineering (3161605)
matrix, or another type of visual output.
3. Microcontroller: The microcontroller acts as the brain of the system, managing the input from the keypad,
controlling the display, and implementing the authentication logic. It processes the user input, compares it with
stored passwords, and determines whether access should be granted.
4. Storage: There needs to be a method for storing the passwords securely. This could involve onboard memory
within the microcontroller, external EEPROM (Electrically Erasable Programmable Read-Only Memory), or
other secure storage mechanisms.
5. Interfaces: Depending on the specific requirements of the application, the hardware interface may include
additional components or interfaces. For example, if the system is part of a larger networked environment, it
may include Ethernet, Wi-Fi, or Bluetooth interfaces for communication with other devices or systems.
6. Power Supply: A reliable power supply is essential to ensure continuous operation of the authentication
system. This could be provided by batteries, AC power adapters, or other power sources depending on the
deployment environment.
7. Enclosure: Depending on the deployment environment and security considerations, the hardware interface
may be enclosed within a protective housing to prevent tampering or unauthorized access to internal
components.
8. Indicators: LEDs or other indicators may be included to provide visual feedback to users, such as indicating
when the system is ready to accept input, when input is being processed, or when authentication is successful
or unsuccessful.
9. Reset/Override Mechanism: In case of emergency or system malfunction, there should be a way to reset the
system or override the authentication process. This could be a physical button or switch accessible only to
authorized personnel.

Software Interfaces
1. User Interface (UI):
 The user interface allows users to interact with the authentication system. This could be a
graphical user interface (GUI) for desktop or web applications, or a command-line interface
(CLI) for terminal-based systems.
 The UI provides prompts for users to input their passwords and displays feedback such as
authentication success or failure messages.
2. Application Programming Interface (API):
 The API defines the methods and data structures used for communication between different
software components within the authentication system.
 It allows other software applications or systems to interact with the authentication system
programmatically. For example, an API might be used to integrate the authentication system
with a web application or a mobile app.
3. Database Interface:
 The database interface is used to interact with the storage mechanism where user credentials
(passwords) are stored.
 This interface typically involves CRUD (Create, Read, Update, Delete) operations for managing
user accounts and passwords within the database.
4. Security Protocol Interfaces:
 These interfaces define the protocols used for securing communication between different
components of the authentication system.
 For example, if the system communicates over a network, it might use protocols such as
HTTPS (HTTP Secure) or TLS (Transport Layer Security) to encrypt data transmitted between
the client and server.
5. External System Interfaces:
 Soft
Software Engineering (3161605)

If the authentication system needs to integrate with other external systems or services, it may
require interfaces to communicate with those systems.
 These interfaces could involve APIs provided by external services or custom integration
protocols specific to the requirements of the integration.
6. Logging and Monitoring Interfaces:
 The authentication system may include interfaces for logging authentication events and
monitoring system health and performance.
 These interfaces could allow administrators to view logs of authentication attempts, analyze
system usage patterns, and detect potential security incidents.
7. Configuration Interfaces:
 Configuration interfaces allow administrators to customize the behavior of the authentication
system according to their requirements.
 This might involve setting parameters such as password complexity rules, account lockout
policies, and audit logging settings.
8. Error Handling Interfaces:
 Interfaces for handling errors gracefully and providing informative error messages to users and
administrators are essential for usability and troubleshooting.
 These interfaces ensure that users receive clear feedback in case of authentication failures or
other errors encountered during system operation

Communications Interfaces
1. Client-Server Communication:
 If the authentication system operates in a client-server architecture, communication between
clients (e.g., user interfaces) and the authentication server is crucial. This communication
typically occurs over a network, and protocols like HTTP, HTTPS, or custom TCP/IP protocols
may be used.
 Clients send authentication requests to the server, which processes them and responds with
the outcome of the authentication attempt.
2. Database Communication:
 Communication with the database where user credentials are stored is essential. This involves
database query protocols such as SQL (Structured Query Language) for relational databases
or NoSQL query languages for non-relational databases.
 The authentication system communicates with the database to perform operations such as user
authentication, account creation, password updates, and retrieval of user information.
3. API Communication:
 If the authentication system exposes an API for integration with other systems, communication
with these external systems occurs through API calls.
 APIs may use RESTful principles over HTTP/HTTPS or other RPC (Remote Procedure Call)
mechanisms such as SOAP (Simple Object Access Protocol) or GraphQL.
 These interfaces allow external systems to interact programmatically with the authentication
system for tasks such as user authentication, account management, and retrieval of
authentication logs.
4. Security Protocols:
 Communication between components of the authentication system, as well as with external
systems, must be secured to prevent unauthorized access or interception of sensitive data.
Soft
Software Engineering (3161605)
 This involves the use of security protocols such as SSL/TLS for encryption and HTTPS for
secure web communication.
 Additionally, mechanisms such as digital signatures and message authentication codes may be
used to ensure data integrity and authenticity.
5. Error Handling and Feedback:
 Communication interfaces should include mechanisms for providing feedback to users and
administrators in case of errors or exceptions.
 This might involve sending error codes or messages along with responses to authentication
requests, API calls, or database queries.
 Clear and informative error messages help users understand and resolve authentication issues
efficiently.
6. Logging and Monitoring:
 Communication interfaces for logging and monitoring systems allow the authentication system
to record events, errors, and performance metrics.
 Logs may be stored locally or sent to external logging systems using protocols like Syslog,
SNMP (Simple Network Management Protocol), or custom logging APIs.
System Features
<This template illustrates organizing the functional requirements for the product by system features, the
major services provided by the product. You may prefer to organize this section by use case, mode of
operation, user class, object class, functional hierarchy, or combinations of these, whatever makes the
most logical sense for your product.>
System Feature 1
Feature Name: User Authentication
4.1.1 Description and Priority: This feature involves the process of authenticating users attempting
to access the system. It is of High priority as it is fundamental to the security and functionality of the
authentication system.
4.1.2 Stimulus/Response Sequences:
User enters username and password.
System verifies credentials.
If credentials are correct, the system grants access.
If credentials are incorrect, the system denies access and prompts the user to try again or reset
their password.
4.1.3 Functional Requirements:
REQ-1: The system shall provide a login interface where users can input their username and
password.
REQ-2: Upon receiving user credentials, the system shall verify them against the stored credentials
in the database.
REQ-3: If the provided credentials match those stored in the database, the system shall grant
access to the user.
REQ-4: If the provided credentials do not match those stored in the database, the system shall deny
access and display an error message.
REQ-5: The system shall provide functionality for users to reset their password in case they forget
it.
Soft
Software Engineering (3161605)
REQ-6: Password reset requests shall be authenticated through a secondary verification method,
such as email verification or security questions.
REQ-7: The system shall enforce password complexity requirements, such as minimum length, use
of special characters, and avoidance of common passwords.
REQ-8: The system shall securely store user passwords using encryption techniques to prevent
unauthorized access to sensitive information.

System Feature 2
Feature Name: Audit Logging
4.1.1Description and Priority: This feature involves logging all authentication-related events and
activities for auditing and accountability purposes. It is of High priority as it directly impacts the
system's ability to track and monitor user access for security and compliance reasons.

4.1.2Stimulus/Response Sequences:
User attempts to log in or perform authentication-related actions.
System verifies user credentials.
If authentication is successful, the system logs the event as a successful login.
If authentication fails, the system logs the event as a failed login attempt.
System administrators access audit logs for monitoring and analysis purposes.
Functional Requirements:
REQ-1: The system shall maintain comprehensive audit logs of all authentication-related events,
including successful logins, failed login attempts, password reset requests, and account lockouts.
REQ-2: Each audit log entry shall include relevant details such as the timestamp of the event, the
user's username or identifier, the outcome of the authentication attempt, and any additional
contextual information.
REQ-3: Audit logs shall be stored securely to prevent unauthorized access or tampering, following
industry best practices for data protection and integrity.
REQ-4: The system shall provide functionality for system administrators to search, filter, and view
audit logs based on specified criteria, such as time range, user ID, or event type.
REQ-5: Audit logs shall be exportable in common formats (e.g., CSV, JSON) for further analysis or
integration with external systems.
REQ-6: The system shall enforce access controls to restrict access to audit logs, allowing only
authorized personnel to view or modify log data.
REQ-7: Audit log entries shall be retained for a configurable period, in compliance with regulatory
requirements or organizational policies regarding data retention.
REQ-8: In case of any errors or issues related to audit logging, the system shall generate alerts or
notifications to administrators for prompt resolution.
REQ-9: The system shall periodically review audit log settings and configurations to ensure they
remain aligned with security policies and regulatory compliance requirements.

Other Nonfunctional Requirements

Performance Requirements
The performance of the system lies in the way it is handled. Every user must be given proper
guidance regarding how to use the system. The other factor which affects the performance is
the absence of any of the suggested requirements
Safety Requirements
To ensure the safety of the system, perform regular monitoring of the system so as to trace the proper working of
the system. An administrator should be there to ensure the safety of the system. He has to be
trained to handle extreme error cases.
 Soft
Software Engineering (3161605)

Security Requirements
Any unauthorized user should be prevented from accessing the system.
Software Quality Attributes
1) Planned approach towards working: - The working in the system will be well planned and
organized. The image will be stored properly and
will help in implementing the secrecy.
2) Accuracy: -The level of accuracy in the proposed system will be higher. All operation would be
done.
3) Reliability: -The reliability of the proposed system will be high due to the above stated reasons.
The reason for the increased reliability of the system is that now there would be proper storage of
information.
4) No Redundancy: - In the proposed system utmost care would be that no information is repeated
anywhere, in storage or otherwise. This would assure economic use of storage space and consistency in the data
stored.
5) Immediate storage of information: -In manual system there are many problems to store the largest amount
of information.
6) Easy to Operate: - The system should be easy to operate and should be such that it can be
developed within a short period of time and fit in the limited budget of the user.
Business Rules
This Graphical password authentication system is having priority role in keeping the secrecy ofuser.
It helps in storing important files or documents in a manner nobody can directly access. Thus the
project is having a big scope and space in today’s society.

Other Requirements
The registration of new users require the following personal details:
 Name
 Email
 Contact No.
 Gender
 Mobile No.
 Date of birth

Appendix A: Glossary
 SRS: Software Requirement Specification

 GUI: Graphical User Interface

 ADMIN: Administrator

 FREQ: Functional Requirement

 NRFEQ: Non functional requirements

Soft
Software Engineering (3161605)
Appendix B: Analysis Models
<Optionally, include any pertinent analysis models, such as data flow diagrams, class diagrams, state-
transition diagrams, or entity-relationship diagrams.>

Appendix C: To Be Determined List

<Collect a numbered list of the TBD (to be determined) references that remain in the SRS so they
can be tracked to closure.>
Soft
Software Engineering (3161605)

Quiz:

1. Which are properties of good SRS?

2. What is functional and non-functional requirement?

Suggested Reference:

1. Ian Sommerville, Software engineering, Pearson education Asia

2. Roger S.Pressman, Software Engineering- A practitioner‟s Approach, McGraw-Hill
International Editions

References used by the students:

Rubric wise marks obtained:

Rubrics 1 2 3 4 5 Total

Marks Complete Complete Complete Complete Complete

implementation implementation implementation implementation implementation
as asked as asked as asked as asked as asked

Problem analysis Problem analysis Problem analysis Problem analysis

Development of Development of Development of

the Solution the Solution the Solution

Concept Clarity Concept Clarity

& understanding & understanding

Correct answer to
all questions

Signature of Faculty:
Soft
Software Engineering (3161605)

Practical – 4
AIM: Draw the Data Flow Diagram for your selected Project.

 Objectives:
To learn flow oriented model through data flow diagrams.

 Theory:
The DFD takes an input-process-output view of a system. That is, data objects flow into the
software, are transformed by processing elements, and resultant data objects flow out of the
software. The data flow diagram enables you to develop models of the information domain and
functional domain.
Term Notation Remarks

External
Name of the external entity is written inside the rectangle
entity

Process Name of the process is written inside the circle

A left-right open rectangle is denoted as data store; name of the data

Data store
store is written inside the shape

Data flow Data flow is represented by a directed arc with its data name
Soft
Software Engineering (3161605)

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. Usually it
is better to keep the number of processes less than 7. 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 is
written 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.

.
 Background / Preparation:

Levels of DFD

DFD uses hierarchy to maintain transparency thus multilevel DFD‟s can be created. Levels of DFD
are as follows:

 0-level DFD: The primary external entities (boxes) produce information for use by the system
and consume information generated by the system
 1-level DFD: It represents the main functions of the system and how they interact with
each other.
 2-level DFD: It represents the processes within each function of the system and how they
interact with each other.

 Tools / Material Needed:

o Hardware:
o Software:
Soft
Software Engineering (3161605)

Quiz:

1. In a data flow diagram, does an arrow represent a flow of control or something else?

2. What is “information flow continuity” and how is it applied as a data flow diagram
is refined?
3. What are the advantages of DFD?

Suggested Reference:

1. Roger S. Pressman, Software Engineering- A practitioner‟s Approach, McGraw-Hill

International Editions

2. Rajib Mall, Fundamentals of software Engineering, Prentice Hall of India.

References used by the students:

Rubric wise marks obtained:

Rubrics 1 2 3 4 5 Total

Marks Complete Complete Complete Complete Complete

implementation as implementation as implementation as implementation as implementation as
asked asked asked asked asked

Problem analysis Problem analysis Problem analysis Problem analysis

Development of the Development of the Development of the

Solution Solution Solution

Concept Clarity & Concept Clarity &

understanding understanding

Correct answer to
all questions

Signature of the Faculty

Soft
Software Engineering (3161605)

Practical – 5
AIM: Draw the Entity-Relationship Diagram for your selected Project.

 Objectives:
1. Identify entity sets, their attributes, and various relationships
2. Represent the data model through ER diagram

 Theory:
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.

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.
Soft
Software Engineering (3161605)

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
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, including
zero, 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.
Soft
Software Engineering (3161605)

Quiz:

1. what is weak entityset?

2. what is mapping cardinality?

References used by the students:

Soft
Software Engineering (3161605)

Rubric wise marks obtained:

Rubrics 1 2 3 4 5 Total

Marks Complete Complete Complete Complete Complete

implementation implementation implementation implementation implementation
as asked as asked as asked as asked as asked

Problem analysis Problem analysis Problem analysis Problem analysis

Development of Development of Development of

the Solution the Solution the Solution

Concept Clarity Concept Clarity

& understanding & understanding

Correct answer to
all questions

Signature of Faculty:
Soft
Software Engineering (3161605)

Practical – 6
AIM: Draw Usecase Diagram for your selected Project .

 Objectives:
1. To write different scenarios of the system‟s execution.
2. To explore various UML use case diagram components to draw USECASE diagram.

 Theory:
o A use case diagram is used to represent the dynamic behavior of a system. It encapsulates
the system's functionality by incorporating use cases, actors, and their relationships. It
models the tasks, services, and functions required by a system/subsystem of an
application. It depicts the high-level functionality of a system and also tells how the user
handles a system.
o Purpose of Use Case Diagrams
 The main purpose of a use case diagram is to portray the dynamic aspect of a
system. It accumulates the system's requirement, which includes both internal as
well as external influences. It invokes persons, use cases, and several things that
invoke the actors and elements accountable for the implementation of use case
diagrams. It represents how an entity from the external environment can interact
with a part of the system.
Following are the purposes of a use case diagram given below:
1. It gathers the system's needs.
2. It depicts the external view of the system.
3. It recognizes the internal as well as external factors that influence the system.
4. It represents the interaction between the actors.
o In a use-case diagram, an actor is a user of the system (i.e. Something external to the
system; can be human or non-human) acting in a particular role.
o A use-case is a task which the actor needs to perform with the help of the system,
e.g., find details of a book or print a copy of a receipt in a bookshop.
o We can draw a box (with a label) around a set of use cases to denote the system
boundary, as on the previous slide (“library system”).

Inheritance can be used between actors to show that all use cases of one actor are
available to the other:
If several use cases include, as part of their functionality, another use case, we have a
special way to show this in a use-case diagram with an <<include>> relation.
Soft
Software Engineering (3161605)

If a use-case has two or more significantly different outcomes, we can show this by
extending the use case to a main use case and one or more subsidiary cases.

 Background / Preparation:
How to draw a Use Case diagram?
It is essential to analyze the whole system before starting with drawing a use case diagram, and
then the system's functionalities are found. And once every single functionality is identified, they
are then transformed into the use cases to be used in the use case diagram.
After that, we will enlist the actors that will interact with the system. The actors are the person or
a thing that invokes the functionality of a system. It may be a system or a private entity, such that
it requires an entity to be pertinent to the functionalities of the system to which it is going to
interact.
Once both the actors and use cases are enlisted, the relation between the actor and use case/
system is inspected. It identifies the no of times an actor communicates with the system.
Basically, an actor can interact multiple times with a use case or system at a particular instance
of time.
Following are some rules that must be followed while drawing a use case diagram:
1. A pertinent and meaningful name should be assigned to the actor or a use case of a
system.
2. The communication of an actor with a use case must be defined in an understandable
way.
3. Specified notations to be used as and when required.
4. The most significant interactions should be represented among the multiple no of
interactions between the use case and actors.
The purposes of use case diagrams can be as follows:

 Used to gather requirements of a system.

 Used to get an outside view of a system.
 Identify external and internal factors influencing the system.
 Show the interacting among the requirements are actors.
Scenarios
• Scenarios are real-life examples of how a system can be used.
• They should include
– A description of the starting situation;
– A description of the normal flow of events;
– A description of what can go wrong;
– Information about other concurrent activities;
Soft
Software Engineering (3161605)

A description of the state when the scenario finishes.

 Tools / Material Needed:
o Hardware:
o Software:

 Procedure / Steps:
o Developing Use Cases:
o Step One – Define the set of actors that will be involved in the story
 Actors are people, devices, or other systems that use the system or product within
the context of the function and behavior that is to be described
 Actors are anything that communicate with the system or product and that are
external to the system itself
o Step Two – Develop use cases, where each one answers a set of questions

Quiz:

1. What are the four main components of a use case diagram?

2. List relationship used in use case.
3. What Tests Can Help Find Useful Use Cases?

Suggested Reference:

1. Roger S. Pressman, Software Engineering- A practitioner‟s Approach, McGraw-Hill

International Editions
2. Booch, G. et al. The Unified Modeling Language User Guide. Chapters 15, 18, 27.
Addison-Wesley.
3. Jacobson, I. et al. Object-Oriented Software Engineering: A Use-Case Driven Approach.
Addison-Wesley.
4. Fowler, M. UML Distilled: A Brief Guide to the Standard Object Modelling Language.
Chapter 5. Addison Wesley.
Soft
Software Engineering (3161605)

References used by the students:

Rubric wise marks obtained:

Rubrics 1 2 3 4 5 Total

Marks Complete Complete Complete Complete Complete

implementation implementation implementation implementation implementation
as asked as asked as asked as asked as asked

Problem analysis Problem analysis Problem analysis Problem analysis

Development of Development of Development of

the Solution the Solution the Solution

Concept Clarity Concept Clarity

& understanding & understanding

Correct answer to
all questions

Signature of Faculty:
Soft
Software Engineering (3161605)

Practical – 7
AIM: Solve the problem by applying basic COCOMO model.

 Objectives:
1. Categorize projects using COCOMO, and estimate effort and development time required
for a project.

 Theory

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 interested to 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 project parameters
that are estimated include:

Project size: What would be the size of the code written say, in number of lines, files,
modules?
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

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.
Soft
Software Engineering (3161605)

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

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 PM
Tdev = 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 in
person months (PMs)
 Tdev denotes the estimated time required to develop the software (expressed in
months)
The value of the constants a, b, c are given below:

Software project a b c
Organic 2.4 1.05 0.38
Semi-detached 3.0 1.12 0.35
Embedded 3.6 1.20 0.32

Quiz:

1. Assume that the size of an organic type software product has been estimated to be 32,000 lines of
source code. Assume that the average salary of software engineers be Rs. 15,000/- per month. Determine
the effort required to develop the software product and the nominal development time.

Suggested Reference:

1) Roger S. Pressman, Software Engineering- A practitioner‟s Approach, McGraw-Hill

International Editions
Soft
Software Engineering (3161605)

References used by the students:

Rubric wise marks obtained:

Rubrics 1 2 3 4 5 Total

Marks Complete Complete Complete Complete Complete

implementation as implementation as implementation as implementation as implementation as
asked asked asked asked asked

Problem analysis Problem analysis Problem analysis Problem analysis

Development of the Development of the Development of the

Solution Solution Solution

Concept Clarity & Concept Clarity &

understanding understanding

Correct answer to all

questions

Signature of Faculty:
Soft
Software Engineering (3161605)

Practical – 8
AIM: Modeling UML Class Diagrams and Sequence diagrams.

Objectives:

1. Graphically represent a class, and associations among different classes

2. Identify the logical sequence of activities undergoing in a system, and represent them pictorially

 Theory:
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 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.
Soft
Software Engineering (3161605)

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

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.
Soft
Software Engineering (3161605)

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.

Aggregation
It is a special form of association which describes a part-whole[i] relationship between a pair of
classes. It 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
Soft
Software Engineering (3161605)

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

 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:

o Sequence diagram:

The sequence diagram represents the flow of messages in the system and is also
termed as an event diagram. It helps in envisioning several dynamic scenarios. It
portrays the communication between any two lifelines as a time-ordered sequence
of events, such that these lifelines took part at the run time. In UML, the lifeline is
represented by a vertical bar, whereas the message flow is represented by a
vertical dotted line that extends across the bottom of the page. It incorporates the
iterations as well as branching.
o Purpose of a Sequence Diagram

1. To model high-level interaction among active objects within a system.

2. To model interaction among objects inside a collaboration realizing a use case.
3. It either models generic interactions or some certain instances of interaction.
Soft
Software Engineering (3161605)

o Notations of a Sequence Diagram

Lifeline

An individual participant in the sequence diagram is represented by a lifeline. It is

positioned at the top of the diagram.

Actor

A role played by an entity that interacts with the subject is called as an actor. It is out of
the scope of the system. It represents the role, which involves human users and external
hardware or subjects. An actor may or may not represent a physical entity, but it purely
depicts the role of an entity. Several distinct roles can be played by an actor or vice versa.

Activation

It is represented by a thin rectangle on the lifeline. It describes that time period in which
an operation is performed by an element, such that the top and the bottom of the rectangle
is associated with the initiation and the completion time, each respectively.
Soft
Software Engineering (3161605)

Messages

The messages depict the interaction between the objects and are represented by arrows.
They are in the sequential order on the lifeline. The core of the sequence diagram is
formed by messages and lifelines.

Following are types of messages enlisted below:

 Call Message: It defines a particular communication between the lifelines of an

interaction, which represents that the target lifeline has invoked an operation.

Return Message: It defines a particular communication between the lifelines of

interaction that represent the flow of information from the receiver of the corresponding
caller message.

Self Message: It describes a communication, particularly between the lifelines of an

interaction that represents a message of the same lifeline, has been invoked.
Soft
Software Engineering (3161605)

Recursive Message: A self message sent for recursive purpose is called a recursive
message. In other words, it can be said that the recursive message is a special case of the
self message as it represents the recursive calls.

Create Message: It describes a communication, particularly between the lifelines of an

interaction describing that the target (lifeline) has been instantiated.

Destroy Message: It describes a communication, particularly between the lifelines of an

interaction that depicts a request to destroy the lifecycle of the target.
Soft
Software Engineering (3161605)

Duration Message: It describes a communication particularly between the lifelines of an

interaction, which portrays the time passage of the message while modeling a system.

Quiz:

1) In a sequence diagram, what does a box depict? What does a dashed line depict? What does a
arrow between boxes depict?
2) What does a X over a lifeline indicate?

Suggested Reference:

1) Rajib Mall, Fundamentals of software Engineering, Prentice Hall of India.

2) Pankaj Jalote, Software Engineering – A Precise Approach Wiley

References used by the students:

Rubric wise marks obtained:

Rubrics 1 2 3 4 5 Total

Marks Complete Complete Complete Complete Complete

implementation as implementation as implementation as implementation as implementation as
asked asked asked asked asked

Problem analysis Problem analysis Problem analysis Problem analysis

Development of the Development of the Development of the

Solution Solution Solution

Concept Clarity & Concept Clarity &

understanding understanding

Correct answer to all

questions

Signature of Faculty:
Soft
Software Engineering (3161605)

Practical – 9
AIM: Design the various test cases to perform the testing of the system and also perform the
various type of testing
Objectives: To explore and learn about different testing techniques and use them.

 Theory:
o Software Testing is evaluation of the software against requirements gathered from users
and system specifications. Testing is conducted at the phase level in software
development life cycle or at module level in program code. Software testing comprises of
Validation and Verification.

o Software Validation
 Validation is process of examining whether or not the software satisfies the user
requirements. It is carried out at the end of the SDLC. If the software matches
requirements for which it was made, it is validated.

o Validation ensures the product under development is as per the user

requirements.
o Validation answers the question – "Are we developing the product which
attempts all that user needs from this software ?".
o Validation emphasizes on user requirements.
o Software Verification
 Verification is the process of confirming if the software is meeting the business
requirements, and is developed adhering to the proper specifications and
methodologies.

 Verification ensures the product being developed is according to design

specifications.
 Verification answers the question– "Are we developing this product by firmly
following all design specifications ?"
 Verifications concentrates on the design and system specifications.

o Target of the test are -

 Errors - These are actual coding mistakes made by developers. In addition, there is a
difference in output of software and desired output, is considered as an error.
Soft
Software Engineering (3161605)

 Fault - When error exists fault occurs. A fault, also known as a bug, is a result of an
error which can cause system to fail.
 Failure - failure is said to be the inability of the system to perform the desired task.
Failure occurs when fault exists in the system.

o Testing Levels
 Testing itself may be defined at various levels of SDLC. The testing process
runs parallel to software development. Before jumping on the next stage, a
stage is tested, validated and verified.
 Testing separately is done just to make sure that there are no hidden bugs or
issues left in the software. Software is tested on various levels -
o Unit Testing

While coding, the programmer performs some tests on that unit of program to
know if it is error free. Testing is performed under white-box testing approach. Unit
testing helps developers decide that individual units of the program are working as
per requirement and are error free.

o Integration Testing

Even if the units of software are working fine individually, there is a need to find
out if the units if integrated together would also work without errors. For example,
argument passing and data updation etc.

o System Testing
The software is compiled as product and then it is tested as a whole.

 Background / Preparation:
o Test management tool
o Test management tools are used to keep track of all the testing activity, fast data
analysis, manage manual and automation test cases, various environments, and
plan and maintain manual testing as well.
o Test management tools are used to keep track of all the testing activity, fast data analysis,
manage manual and automation test cases, various environments, and plan and maintain
manual testing as well.
o The test management tool is connected with the automation software. These types of
tools had various strategies for testing and multiple sets of features. Some of the test
management tools had capabilities to design the test case with the help of requirements.
Soft
Software Engineering (3161605)

o It is best for test managing, scheduling, defect logging, tracking, and analysis.
o Some of the most commonly used test management tools are as follows:
o Quality center
o RTH
o Testpad
o Test Monitor
o PractiTest

 Tools / Material Needed:

o Hardware:
o Software:

o Test Cases:
 The test case is defined as a group of conditions under which a tester determines
whether a software application is working as per the customer's requirements or
not. Test case designing includes preconditions, case name, input conditions, and
expected result. A test case is a first level action and derived from test scenarios.

o Test case template

o The primary purpose of writing a test case is to achieve the efficiency of the
application.

Test Test Test Steps Expected Actual Pass/Fail

case Scenario Results Results
ID

1
2

Example
Test Test Test Steps Expected Actual Pass/Fail
Case Scenario Results Results
ID

TU01 Check 1. Go to User As Pass

Customer should Expected
site http://demo.guru99.c
Login with Login into
om
application
Soft
Software Engineering (3161605)

valid Data 2. Enter UserId

3. Enter Password
4. Click Submit

TU02 Check 1. Go to User As Pass

Customer should not Expected
site http://demo.guru99.c
Login with Login into
om
invalid Data application
2. Enter UserId
3. Enter Password
4. Click Submit

Quiz:

1 What elements of the WebApp can be “unit tested”? What types of tests must be conducted only
after the WebApp elements are integrated?
2 What is white box testing? What are the different coverage based testing strategies.
3 What is black box testing?

Suggested Reference:
1 Software Testing: A Craftsman's Approach, by Paul C. Jorgensen, Third Edition
2 Software Engineering by Rajib Mall, PHI 2014

References used by the students:

Soft
Software Engineering (3161605)

Rubric wise marks obtained:

Rubrics 1 2 3 4 5 Total

Marks Complete Complete Complete Complete Complete

implementation as implementation as implementation as implementation as implementation as
asked asked asked asked asked

Problem analysis Problem analysis Problem analysis Problem analysis

Development of the Development of the Development of the

Solution Solution Solution

Concept Clarity & Concept Clarity &

understanding understanding

Correct answer to
all questions

Signature of Faculty:
Soft
Software Engineering (3161605)

Practical – 10
AIM: Study of Open-source tools in DevOps for Infrastructure Automation, Configuration
Management, Deployment Automation, Performance Management, Log Management. Monitoring

 Objectives: to learn how DevOps tools works.

 Theory:

DevOps is the combination of cultural philosophies, practices, and tools that increases an organization‟s
ability to deliver applications and services at high velocity: evolving and improving products at a faster
pace than organizations using traditional software development and infrastructure management
processes. This speed enables organizations to better serve their customers and compete more effectively
in the market.

How DevOps Works

Under a DevOps model, development and operations teams are no longer “siloed.” Sometimes, these
two teams are merged into a single team where the engineers work across the entire application
lifecycle, from development and test to deployment to operations, and develop a range of skills not
limited to a single function.

In some DevOps models, quality assurance and security teams may also become more tightly integrated
with development and operations and throughout the application lifecycle. When security is the focus of
everyone on a DevOps team, this is sometimes referred to as DevSecOps.

These teams use practices to automate processes that historically have been manual and slow. They use
a technology stack and tooling which help them operate and evolve applications quickly and reliably.
These tools also help engineers independently accomplish tasks (for example, deploying code or
Soft
Software Engineering (3161605)

provisioning infrastructure) that normally would have required help from other teams, and this further
increases a team‟s velocity.

Why DevOps Matters

Software and the Internet have transformed the world and its industries, from shopping to entertainment
to banking. Software no longer merely supports a business; rather it becomes an integral component of
every part of a business. Companies interact with their customers through software delivered as online
services or applications and on all sorts of devices. They also use software to increase operational
efficiencies by transforming every part of the value chain, such as logistics, communications, and
operations. In a similar way that physical goods companies transformed how they design, build, and
deliver products using industrial automation throughout the 20th century, companies in today‟s world
must transform how they build and deliver software.

DevOps Practices

Continuous Integration
Continuous integration is a software development practice where developers regularly merge their code
changes into a central repository, after which automated builds and tests are run. The key goals of
continuous integration are to find and address bugs quicker, improve software quality, and reduce the
time it takes to validate and release new software updates.

Continuous Delivery
Continuous delivery is a software development practice where code changes are automatically built,
tested, and prepared for a release to production. It expands upon continuous integration by deploying all
code changes to a testing environment and/or a production environment after the build stage. When
continuous delivery is implemented properly, developers will always have a deployment-ready build
artifact that has passed through a standardized test process.

Microservices
The microservices architecture is a design approach to build a single application as a set of small
services. Each service runs in its own process and communicates with other services through a well-
defined interface using a lightweight mechanism, typically an HTTP-based application programming
interface (API). Microservices are built around business capabilities; each service is scoped to a single
purpose. You can use different frameworks or programming languages to write microservices and
deploy them independently, as a single service, or as a group of services.
Soft
Software Engineering (3161605)

Infrastructure as Code
Infrastructure as code is a practice in which infrastructure is provisioned and managed using code and
software development techniques, such as version control and continuous integration. The cloud‟s API-
driven model enables developers and system administrators to interact with infrastructure
programmatically, and at scale, instead of needing to manually set up and configure resources. Thus,
engineers can interface with infrastructure using code-based tools and treat infrastructure in a manner
similar to how they treat application code. Because they are defined by code, infrastructure and servers
can quickly be deployed using standardized patterns, updated with the latest patches and versions, or
duplicated in repeatable ways.

Configuration Management
Developers and system administrators use code to automate operating system and host configuration,
operational tasks, and more. The use of code makes configuration changes repeatable and standardized.
It frees developers and systems administrators from manually configuring operating systems, system
applications, or server software.

Policy as Code
With infrastructure and its configuration codified with the cloud, organizations can monitor and enforce
compliance dynamically and at scale. Infrastructure that is described by code can thus be tracked,
validated, and reconfigured in an automated way. This makes it easier for organizations to govern
changes over resources and ensure that security measures are properly enforced in a distributed manner
(e.g. information security or compliance with PCI-DSS or HIPAA). This allows teams within an
organization to move at higher velocity since non-compliant resources can be automatically flagged for
further investigation or even automatically brought back into compliance.

Monitoring and Logging

Organizations monitor metrics and logs to see how application and infrastructure performance impacts
the experience of their product‟s end user. By capturing, categorizing, and then analyzing data and logs
generated by applications and infrastructure, organizations understand how changes or updates impact
users, shedding insights into the root causes of problems or unexpected changes. Active monitoring
becomes increasingly important as services must be available 24/7 and as application and infrastructure
update frequency increases. Creating alerts or performing real-time analysis of this data also helps
organizations more proactively monitor their services.

Communication and Collaboration

Increased communication and collaboration in an organization is one of the key cultural aspects of
DevOps. The use of DevOps tooling and automation of the software delivery process establishes
collaboration by physically bringing together the workflows and responsibilities of development and
operations. Building on top of that, these teams set strong cultural norms around information sharing and
facilitating communication through the use of chat applications, issue or project tracking systems, and
Soft
Software Engineering (3161605)

wikis. This helps speed up communication across developers, operations, and even other teams like
marketing or sales, allowing all parts of the organization to align more closely on goals and projects.

DevOps Tools
The DevOps model relies on effective tooling to help teams rapidly and reliably deploy and innovate for
their customers. These tools automate manual tasks, help teams manage complex environments at scale,
and keep engineers in control of the high velocity that is enabled by DevOps. AWS provides services
that are designed for DevOps and that are built first for use with the AWS cloud. These services help
you use the DevOps practices described above.

+Quiz:
1 What are the challenges with DevOps implementation?
2 What is DevOps? How it works? What are the DevOps principles & best practices?
3 Explain 7Cs of DevOps lifecycle.

Suggested Reference:

1 Deepak Gaikwad, Viral Thakkar, DevOps Tools from Practitioner‟s ViewPoint, Wiley.
2 The DevOps Handbook - Gene Kim et. al.
References used by the students:

Rubric wise marks obtained:

Rubrics 1 2 3 4 5 Total

Marks Complete Complete Complete Complete Complete

implementation as implementation as implementation as implementation as implementation as
asked asked asked asked asked

Problem analysis Problem analysis Problem analysis Problem analysis

Development of the Development of the Development of the

Solution Solution Solution

Concept Clarity & Concept Clarity &

understanding understanding

Correct answer to all

questions

Signature of Faculty: