SE - Lab Manual

A Laboratory Manual for
SOFTWARE ENGINEERING
(3150711)
B.E. Semester V
(Department of Computer Engineering)
Directorate of Technical Education, Gandhinagar,

Gujarat.
Government Engineering College, Bhavnagar

Institute Vision and Mission
Vision:
To transform the students into good human beings, employable engineering graduates and
continuous learners by inculcating human values and imparting excellence in technical
education.
Mission:
To impart education to rural and urban students, so as to earn respect from the society and
thereby improving the living standards of their families and become asset for the industry
and society. To foster a learning environment with technology integration and individual
attention, so that the students imbibe quality technical knowledge, skill-development and
character building
Department of Computer Engineering Vision and Mission

Vision:
To achieve excellence for providing value based education in computer science and
Information Technology through innovation, team work and ethical practices.
Mission:
To attain excellence in teaching-learning process by providing better infrastructure facilities.

To collaborate with IT industry to bridge the knowledge gap between academics and industry
needs.
To impart value based IT education for building cutting edge and innovative IT applications.
Program Education Objectives:
Have careers in industry, research & academics focusing on the application of the
information technologies and take leadership positions in the industry and also initiate
businesses offering innovative solutions.
Capable of adapting to new technologies and constantly upgrade their skills with an attitude
towards lifelong learning.
Act conscientiously about the potentials and the responsibilities of the computing profession
in the context of science, technology, society and humanity.
Program Specific Outcomes:
An ability to design solutions by simulating computer engineering problems in absence of
real time environment.
An ability to learn and use of open source tools in the areas like operating systems, computer
programming, computer networks and database management.
An ability to face competitive examinations for higher education and PSUs.

Certificate
This is to certify that Mr./Ms. ___________________________________

Enrollment No. __________________________ of B.E. Semester _____
Computer Engineering of this Institute (GTU College Code: 021) has satisfactorily
completed the Practical / Tutorial work for the subject Software Engineering
(3150711) 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 practical 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 practical 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.
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.
Define the Problem statement of Software development,
and after identifying the requirements based on the
1. √ √
requirement engineering tasks, prepare the Software
Requirement Specification (SRS) document.
Prepare the Software Project Management Plan (SPMP),
including the following:
2. √ √
• Estimation of Size, Cost, Duration, Effort
• Prepare the Schedule, Milestones using the Gantt chart
Prepare the following components of the Data Flow Model:
3. • Data Dictionary √ √
• Data Flow Diagram Structure Chart
Prepare the user’s view analysis: Describe different
4. scenarios and Draw Use case diagrams using UML √ √
Prepare the structural view: Draw the Class diagram and

5. √ √
object diagram.
Prepare the behavioral view: Draw a Sequence diagram
6. √ √
and a Collaboration diagram.
Prepare the behavioral view: Draw a State-chart diagram
7. √ √
and Activity diagram.
Prepare the implementation view: Draw the Component
8. √ √
and Deployment diagram.
9. Prepare the quality management plan. √ √
To perform various testing using the testing tool unit
10. √ √
testing, integration testing design test cases.
Case Study: Study of Open-source tools in DevOps for
Infrastructure Automation, Configuration Management,
11 √
Deployment Automation, Performance Management, and
Log Management. Monitoring
Index
(Progressive Assessment Sheet)
Sr. Objective(s) of Experiment Page Date of Date of AssessSign. of Remarks

No. No. perform submiss ment Teacher
ance ion Marks with date
1 Define the Problem statement of Software
development and after identifying the
requirements based on the requirement
engineering tasks prepare the Software
Requirement Specification (SRS) document.
2 Prepare the Software Project Management Plan
(SPMP) including following:
• Estimation of Size, Cost, Duration, Effort
• Prepare the Schedule, Milestones using
Gantt chart
3 Prepare the following components of Data Flow
Model:
• Data Dictionary
• Data Flow Diagram Structure Chart
4 Prepare the user’s view analysis: Describe
different scenarios and Draw Use case diagrams
using UML
5 Prepare the structural view: Draw Class diagram
and object diagram using UML.
6 Prepare the behavioral view: Draw Sequence
diagram and Collaboration diagram using UML.
7 Prepare the behavioral view: Draw State-chart
diagram and Activity diagram using UML.
8 Prepare the implementation view: Draw
Component and Deployment diagram using UML.
9. Prepare the quality management plan.
10. To perform various testing using the testing tool

unit testing, integration testing design test cases.
11. Case Study: Study of Open-source tools in
DevOps for Infrastructure Automation,
Configuration Management, Deployment
Automation, Performance Management, Log
Management. Monitoring
Total
GUJARAT TECHNOLOGICAL UNIVERSITY, AHMEDABAD,
COURSE CURRICULUM
COURSE TITLE: Software Engineering
(Code: 3150711)
Degree Program in which this course is offered Semester in which offered
Computer Engineering 5th Semester
1. RATIONALE
• To study Software Development Life Cycle, Development models and Agile Software
development.
• To study fundamental concepts in software testing, including software testing objectives,
process, criteria, strategies, and methods.
• To discuss various software testing issues and solutions in software unit test; integration,
regression, and system testing.
• To learn the process of improving the quality of software work products.
• To gain the techniques and skills on how to use modern software testing tools to support
software testing projects.
• To expose Software Process Improvement and Reengineering
2. COMPETENCY
• The course content should be taught and analyze with the aim to develop different types of
skills so that students are able to acquire following competency:
• Software engineering models to development of the complex engineering software based on the
software development life cycle.
3. COURSE OUTCOMES
After learning the course, the students should be able to:

1. Prepare SRS (Software Requirement Specification) document and SPMP (Software Project
Management Plan) document.
2. Apply the concept of Functional Oriented and Object-Oriented Approach for Software Design.
3. Recognize how to ensure the quality of software product, different quality standards and
software review techniques.
4. Apply various testing techniques and test plan in.
5. Able to understand modern Agile Development.
4. TEACHING AND EXAMINATION SCHEME
5. SUGGESTED LEARNING RESOURCES

A. LIST OF BOOKS
1. Roger S.Pressman, Software Engineering- A practitioner’s Approach, McGraw-Hill International

Editions
2. Ian Sommerville, Software engineering, Pearson education Asia
3. Pankaj Jalote, Software Engineering – A Precise Approach Wiley
4. Behhforoz & Frederick Hudson, Software Engineering Fundamentals, OXFORD
5. Rajib Mall, Fundamentals of software Engineering, Prentice Hall of India.
6. Deepak Gaikwad, Viral Thakkar, DevOps Tools from Practitioner’s ViewPoint, Wiley
7. Merlin Dorfman (Editor), Richard H. Thayer (Editor), Software Engineering
8. Robert C. "Uncle Bob" Martin, Clean Architecture: A Craftsman's Guide to Software Structure and
Design
B. LIST OF SOFTWARE / LEARNING WEBSITES

• www.onesmartclick.com/engsineering/software-engineering.html
• www.sei.cmu.edus
• https://www.edx.org/school/uc-berkeleyx
• https://devops.com/most-popular-open-source-devops-tools/
• https://www.guru99.com/devops-tutorial.html
Industry Relevant Skills
The following industry relevant competencies are expected to be developed in the student by
undertaking the practical work of this laboratory.
1. Apply knowledge of Software engineering to solve real world problems

2. Understand, analyze, design, implement and Deployment of project/product
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 complete curriculum of the course.
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
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
s/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 make a team of
maximum 3 students’ group.
3. For making the group, students must take care that the all the students of group must be from
same batch.
4. After establishing the team, every team will have to identify the problem area / definition for
performing the laboratory work.
5. Every team has to approve their problem definition to respective faculty member within 15 days
of the beginning of the semester.
6. Once the problem definition is approved by the faculty member, every team has to perform all
the practical based on their respective problem definition.
Practical – 1
AIM: Define the Problem statement of Software development and after identifying the requirements
based on the requirement engineering tasks prepare the Software Requirement Specification (SRS)
document.
• Objectives: Too learn how to define the problem statement for software development and how to
identify the requirements while performing requirements engineering tasks and to learn what are
the contents of SRS and how to write the contents in SRS.
• Theory:
o The process off collecting the software requirement from the client then understand,
evaluate and document it is called as requirement engineering.
o Requirement engineering constructs a bridge for design and construction.
Figure: Requirements Engineering Process
oduction of the requirements stage of the software development process is Software

o The production
Requirements Specifications (SRS) (also called a requirements document).
document This report lays a
foundation for software engineering activities and is constructing when entire requirements
re are
elicited and analyzed. SRS is a formal report, which acts as a representation of software that
enables the customers to review whether it (SRS) is according to their requirements. Also, it
comprises user requirements for a system as well as detailed specifications of the system
requirements.
o The SRS is a specification for a specific software product, program, or set of applications that
perform particular functions in a specific environment. It serves several goals depending on who
is writing it. First, the SRS could be written by the client of a system. Second, the SRS could be
written by a developer of the system. The two methods create entirely various situations and
establish different purposes for the document altogether. The first case, SRS, is used to define the
needs and expectation of the users. The second case, SRS, is written for various purposes and
serves as a contract document between customer and developer.
Characteristics of good SRS

1. Correctness
2. Completeness
3. Consistency
4. Unambiguousness
5. Ranking for importance and stability
6. Modifiability
7. Verifiability
8. Traceability
9. Design Independence
10. Testability
11. Understandable by the customer
12. The right level of abstraction
The following are the features of a good SRS document:
1. Correctness: User review is used to provide the accuracy of requirements stated in the
SRS. SRS is said to be perfect if it covers all the needs that are truly expected from the
system.
2. Completeness: The SRS is complete if, and only if, it includes the following elements:
(1). All essential requirements, whether relating to functionality, performance, design,

constraints, attributes, or external interfaces.
(2). Definition of their responses of the software to all realizable classes of input data
in all available categories of situations.
(3). Full labels and references to all figures, tables, and diagrams in the SRS and
definitions of all terms and units of measure.
3. Consistency: The SRS is consistent if, and only if, no subset of individual requirements
described in its conflict. There are three types of possible conflict in the SRS:
(1). The specified characteristics of real-world objects may conflicts. For example,
(a) The format of an output report may be described in one requirement as tabular but in
another as textual.
(b) One condition may state that all lights shall be green while another states that all
lights shall be blue.
(2). There may be a reasonable or temporal conflict between the two specified actions.
For example,
(a) One requirement may determine that the program will add two inputs, and another
determine that the program will multiply them.
(b) One condition may state that "A" must always follow "B," while other requires that
"A and B" co-occurs.
(3). Two or more requirements may define the same real-world object but use different
terms for that object. For example, a program's request for user input may be called a
"prompt" in one requirement's and a "cue" in another. The use of standard terminology
and descriptions promotes consistency.
4. Unambiguousness: SRS is unambiguous when every fixed requirement has only one
interpretation. This suggests that each element is uniquely interpreted. In case there is a
method used with multiple definitions, the requirements report should determine the
implications in the SRS so that it is clear and simple to understand.
5. Ranking for importance and stability: The SRS is ranked for importance and stability
if each requirement in it has an identifier to indicate either the significance or stability of
that particular requirement.
Typically, all requirements are not equally important. Some prerequisites may be
essential, especially for life-critical applications, while others may be desirable. Each
element should be identified to make these differences clear and explicit. Another way to
rank requirements is to distinguish classes of items as essential, conditional, and optional.
6. Modifiability: SRS should be made as modifiable as likely and should be capable of

quickly obtain changes to the system to some extent. Modifications should be perfectly
indexed and cross-referenced.
7. Verifiability: SRS is correct when the specified requirements can be verified with a cost-
effective system to check whether the final software meets those requirements. The
requirements are verified with the help of reviews.
8. Traceability: The SRS is traceable if the origin of each of the requirements is clear and if
it facilitates the referencing of each condition in future development or enhancement
documentation.
There are two types of Traceability:
1. Backward Traceability: This depends upon each requirement explicitly referencing

its source in earlier documents.
2. Forward Traceability: This depends upon each element in the SRS having a unique
name or reference number.
The forward traceability of the SRS is especially crucial when the software product enters
the operation and maintenance phase. As code and design document is modified, it is
necessary to be able to ascertain the complete set of requirements that may be concerned
by those modifications.
9. Design Independence: There should be an option to select from multiple design

alternatives for the final system. More specifically, the SRS should not contain any
implementation details.
10. Testability: An SRS should be written in such a method that it is simple to generate test
cases and test plans from the report.
11. Understandable by the customer: An end user may be an expert in his/her explicit
domain but might not be trained in computer science. Hence, the purpose of formal
notations and symbols should be avoided too as much extent as possible. The language
should be kept simple and clear.
12. The right level of abstraction: If the SRS is written for the requirements stage, the
details should be explained explicitly. Whereas, for a feasibility study, fewer analysis can
be used. Hence, the level of abstraction modifies according to the objective of the SRS.
Properties of a good SRS document
The essential properties of a good SRS document are the following:
Concise: The SRS report should be concise and at the same time, unambiguous, consistent, and
complete. Verbose and irrelevant descriptions decrease readability and also increase error
possibilities.
Structured: It should be well-structured. A well-structured document is simple to understand

and modify. In practice, the SRS document undergoes several revisions to cope up with the user
requirements. Often, user requirements evolve over a period of time. Therefore, to make the
modifications to the SRS document easy, it is vital to make the report well-structured.
Black-box view: It should only define what the system should do and refrain from stating how to
do these. This means that the SRS document should define the external behavior of the system
and not discuss the implementation issues. The SRS report should view the system to be
developed as a black box and should define the externally visible behavior of the system. For this
reason, the SRS report is also known as the black-box specification of a system.
Conceptual integrity: It should show conceptual integrity so that the reader can merely
understand it. Response to undesired events: It should characterize acceptable responses to
unwanted events. These are called system responses to exceptional conditions.
Verifiable: All requirements of the system, as documented in the SRS document, should be
correct. This means that it should be possible to decide whether or not requirements have been
met in an implementation.
• Background / Preparation:
Requirement engineering consists of seven different tasks as follows:
1. Inception
• Inception is a task where the requirement engineering asks a set of questions to establish
a software process.
• In this task, it understands the problem and evaluates with the proper solution.
• It collaborates with the relationship between the customer and the developer.
• The developer and customer decide the overall scope and the nature of the question
2. Elicitation
Elicitation means to find the requirements from anybody.

The requirements are difficult because the following problems occur in elicitation.
Problem of scope: The customer gives the unnecessary technical detail rather than
clarity of the overall system objective.
Problem of understanding: Poor understanding between the customer and the developer
regarding various aspect of the project like capability, limitation of the computing
environment.
Problem of volatility: In this problem, the requirements change from time to time and it
is difficult while developing the project
3. Elaboration
In this task, the information taken from user during inception and elaboration and are
expanded and refined in elaboration.
Its main task is developing pure model of software using functions, feature and
constraints of a software.
4. Negotiation
In negotiation task, a software engineer decides the how will the project be achieved
with limited business resources.
To create rough guesses of development and access the impact of the requirements on the
project cost and delivery time.
5. Specification
In this task, the requirement engineer constructs a final work product.
The work product is in the form of software requirement specification.
In this task, formalize the requirement of the proposed software such as informative,
functional and behavioral.
The requirements are formalize in both graphical and textual formats.
6. Validation
The work product is built as an output of the requirement engineering and that is accessed
for the quality through a validation step.
The formal technical reviews from the software engineer, customer and other
stakeholders helps for the primary requirements validation mechanism.
7. Requirement management
It is a set of activities that help the project team to identify, control and track the
requirements and changes can be made to the requirements at any time of the ongoing
project.
These tasks start with the identification and assign a unique identifier to each of the
requirements.
After finalizing the requirement traceability table is developed.
The examples of traceability table are the features, sources, dependencies, subsystems
and interface of the requirement.
• In order to form a good SRS, here you will see some points which can be used and should be
considered to form a structure of good SRS. These are as follows :
1. Introduction
(i) Purpose of this document
(ii) Scope of this document
(iii) Overview
2. General description
3. Functional Requirements
4. Interface Requirements
5. Performance Requirements
6. Design Constraints
7. Non-Functional Attributes
8. Preliminary Schedule and Budget
9. Appendices
• Tools / Material Needed:

o Hardware:
o Software:
• Procedure:
o Every team has to identify the requirements of their projects and arrange as per the
requirement engineering document.
• Steps:
o Every team has to follow the given format as described in the below example.
o Example 1: Withdraw Cash from ATM
R.1: withdraw cash
Description: The withdraw cash function first determines the type of account that the user
has and the account number from which the user wishes to withdraw cash. It
checks the balance to determine whether the requested amount is available in
the account. If enough balance is available, it outputs the required cash,
otherwise it generates an error message.
R.1.1: Select withdraw amount option
Input: “withdraw amount” option
Output: user prompted to enter the account type
R.1.2: Select account type
Input: user option
Output: prompt to enter amount
R.1.3: Get required amount

Input: amount to be withdrawn in integer values greater than 100 and less than
10,000 in multiples of 100.
Output: The requested cash and printed transaction statement.
Processing: The amount is debited from the user’s account if sufficient balance is
available, otherwise an error message displayed.
o Example 2: Search Book Availability in Library

R.1: Search Book
Description: Once the user selects the search option, he would be asked to enter the
keywords. The system would search the book in the book list based on the
keywords entered. After making the search, the system should output the
details of all books whose title or author name match any of the keywords
entered. The book details to be displayed include: title, author name, publisher
name, year of publication, ISBN number, catalog number, and the location in
the library.
R.1.1: Select search option
Input: “Search” option
Output: User prompted to enter the keywords
R.1.2: Search and display
Input: Keywords
Output: Details of all books whose title or author name matches any of the keywords
entered by the user. The details displayed would include: title of the book,
author name, ISBN number, catalog number, year of publication, number of
copies available, and the location in the library.
Processing: Search the book list based on the keywords
R.2: Renew book
Description: When the “renew” option is selected, the user is asked to enter his
membership number and password. After password validation, the list of the
books borrowed by him are displayed. The user can renew any of his
borrowed books by indication them. A requested book cannot be renewed if it
is reserved by another user. In this case, an error message would be displayed.
R.2.1: Select renew option
State: The user has logged in and the main menu has been displayed
Input: “Renew” option selection
Output: Prompt message to the user to enter his membership number and password
R.2.2: Login
State: The renew option has been selected
Input: Membership number and password
Output: List of the books borrowed by the user is displayed, and user is prompted to
select the books to be renewed, if the password is valid. If the password is
invalid, the user is asked to reenter the password.
Processing: Password validation search the books issued to the user form the borrower’s
list and display
Next R.2.3 if password is valid and R.2.2 if password is invalid
function:
R.2.3: Renew selected books
Input: User choice for books to be renewed out of the books borrowed by him.
Output: Confirmation of the books successfully renewed and apology message for the
books that could not be renewed.
Processing: Check if anyone has reserved any of the requested books. Renew the books
selected by the use in the borrower’s list, if no one has reserved those books.
Software Requirement Specification (SRS) Format as name suggests, is complete
specification and description of requirements of software that needs to be fulfilled for successful
development of software system. These requirements can be functional as well as non-functional
depending upon type of requirement. The interaction between different customers and contractor
is done because its necessary to fully understand needs of customers.
Depending upon information gathered after interaction, SRS is developed which describes
requirements of software that may include changes and modifications that is needed to be done
to increase quality of product and to satisfy customer’s demand.
1. Introduction :
• (i) Purpose of this Document –

o At first, main aim of why this document is necessary and what’s purpose of
document is explained and described.
• (ii) Scope of this document –
o In this, overall working and main objective of document and what value it will
provide to customer is described and explained. It also includes a description
of development cost and time required.
• (iii) Overview –
o In this, description of product is explained. It’s simply summary or overall
review of product.
2. General description :
In this, general functions of product which includes objective of user, a user
characteristic, features, benefits, about why its importance is mentioned. It also
describes features of user community.
3. Functional Requirements:
In this, possible outcome of software system which includes effects due to
operation of program is fully explained. All functional requirements which
may include calculations, data processing, etc. are placed in a ranked order.
4. Interface Requirements :
In this, software interfaces which mean how software program communicates
with each other or users either in form of any language, code, or message are fully
described or explained. Examples can be shared memory, data streams, etc.
5. Performance Requirements:
In this, how a software system performs desired functions under specific
condition is explained. It also explains required time, required memory, maximum
error rate, etc.
6. Design Constraints:
In this, constraints which simply mean limitation or restriction are specified and
explained for design team. Examples may include use of a particular algorithm,
hardware and software limitations, etc.
7. Non-Functional Attributes:
In this, non-functional attributes are explained that are required by software
system for better performance. An example may include Security, Portability,
Reliability, Reusability, Application compatibility, Data integrity, Scalability
capacity, etc.
8. Preliminary Schedule and Budget:
In this, initial version and budget of project plan are explained which include
overall time duration required and overall cost required for development of
project.
9. Appendices:
In this, additional information like references from where information is gathered,
definitions of some specific terms, acronyms, abbreviations, etc. are given and
explained.
Quiz:
1. Which are properties of good SRS?

2. What is functional and non-functional requirement?
3. Which are different requirement engineering tasks?
Suggested Reference:
1. Lecture on "System Analysis and Design", NPTEL

2. When Telepathy Won’t Do: Requirements Engineering Key Practices
3. Requirements Analysis: Process of requirements gathering and requirement definition
4. IEEE Recommended Practice for Software Requirements Specifications
5. Requirements Trace-ability and Use Cases
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:
Practical – 2
AIM: Prepare the Software Project Management Plan (SPMP) including following: 1) Estimation of
Size, Cost, Duration, Effort 2) Prepare the Schedule, Milestones using Gantt chart
• Objectives:
1. To perform Estimation of Size, Cost, Duration, Effort
2. To Prepare the Schedule, Milestones
• 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:
Estimating the following attributes of the project:

Project size: What will be problem complexity in terms of the effort and time required to develop
the product?
Cost: How much is it going to cost to develop the project?
Duration: How long is it going to take to complete development?
Effort: How much effort would be required?
The effectiveness of the subsequent planning activities is based on the accuracy of these estimations.
• Scheduling manpower and other resources.

• Staff organization and staffing plans.
• Risk identification, analysis, and abatement planning
• Miscellaneous plans such as quality assurance plan, configuration management plan, etc.
Organization of SPMP Document
Introduction (Objectives, Major Functions, Performance Issues, Management and Technical Constraints)
Project Estimates (Historical Data, Estimation Techniques, Effort, Cost, and Project Duration Estimates)
Project Resources Plan(People, Hardware and Software, Special Resources)
Schedules (Work Breakdown Structure, Task Network, Gantt Chart Representation, PERT Chart
Representation)
Risk Management Plan (Risk Analysis, Risk Identification, Risk Estimation, Abatement Procedures)
Project Tracking and Control Plan
Miscellaneous Plans(Process Tailoring, Quality Assurance)
Function Points
STEP 1: measure size in terms of the amount of functionality in a system. Function points are computed
by first calculating an unadjusted function point count (UFC).
Counts are made for the following categories
External inputs–those items provided by the user that describe distinct application-oriented data (such as
file names and menu selections)
External outputs–those items provided to the user that generate distinct application-oriented data (such
as reports and messages, rather than the individual components of these)
External inquiries–interactive inputs requiring a response
External files–machine-readable interfaces to other systems
Internal files–logical master files in the system
STEP 2: Multiply each number by a weight factor, according to complexity (simple, average or
complex) of the parameter, associated with that number. The value is given by a table:
STEP 3: Calculate the total UFP(Unadjusted Function Points)
STEP 4: Calculate the total TCF(Technical Complexity Factor) by giving a value between 0 and 5
according to the importance of the following points(next slide):
Technical Complexity Factors:
1.Data Communication 2.Distributed Data Processing 3.Performance Criteria 4.Heavily Utilized
Hardware 5.High Transaction Rates 6.Online Data Entry 7.Online Updating 8.End-user Efficiency
9.Complex Computations 10.Reusability 11.Ease of Installation 12.Ease of Operation 13.Portability
14.Maintainability
STEP 5: Sum the resulting numbers to obtain DI(degree of influence)
STEP 6: TCF(Technical Complexity Factor) by given by the formula

–TCF=0.65+0.01*DI
STEP 6: Function Points are by given by the formula
–FP=UFP*TCF
The Constructive Cost Model (COCOMO) is the most widely used software estimation model.
The COCOMO model predicts the effort and duration of a project based on inputs relating to the size
of the resulting systems and a number of "cost drives" that affect productivity.
The most important factors contributing to a project's duration and cost is the Development Mode.
Organic Mode: The project is developed in a familiar, stable environment, and the product is similar to
previously developed products. The product is relatively small, and requires little innovation.
Semidetached Mode: The project's characteristics are intermediate between Organic and Embedded.
Embedded Mode: The project is characterized by tight, inflexible constraints and interface
requirements. An embedded mode project will require a great deal of innovation.
Example:
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.
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.
Gantt charts are mainly used to allocate resources to activities. The resources allocated to
activities include staff, hardware, and software. Gantt charts (named after its developer Henry
Gantt) are useful for resource planning. A Gantt 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. In the Gantt charts used for software project management, each bar consists of a white
part and a shaded part. The shaded part of the bar shows the length of time each task is estimated
to take. The white part shows the slack time, that is, the latest time by which a task must be
finished.
Quiz:
1) Explain project scheduling process. Explain Gantt Chart in detail.

2) A project size of 300 KLOC is to be developed. Software development team has beginner
experience on similar type of projects. The project schedule is not very tight. Calculate the
Effort, development time, average staff size, and productivity of the project.
3) Explain Software metrics used for software cost estimation
I. COCOMO
II. Halstead complexity measures
III. COCOMO (Constructive Cost Model), Seminar on Software Cost Estimation WS 2002 / 2003,
presented by Nancy Merlo – Schett
IV. The Halstead metrics
V. Software Engineering, National Program on Technology Enhanced Learning
VI. Halstead Metrics, Verifysoft Technology

implementation implementation implementation implementation implementation
as asked as asked as asked as asked as asked
Development of Development of Development of

the Solution the Solution the Solution
Concept Clarity Concept Clarity

& understanding & understanding
Correct answer to
all questions
Practical – 3
AIM: Prepare the following components of Data Flow Model: Data Dictionary, Data Flow Diagram
and Structure Chart
Objectives:
1. To learn how to prepare data dictionary.

2. To learn how to draw data flow diagrams.
3. To convert a DFD into structure chart.
Theory:
o A Data Flow Diagram (DFD) is a traditional visual representation of the information

flows within a system. A neat and clear DFD can depict the right amount of the system
requirement graphically. It can be manual, automated, or a combination of both.
o It shows how data enters and leaves the system, what changes the information, and where
data is stored.
o The objective of a DFD is to show the scope and boundaries of a system as a whole. It
may be used as a communication tool between a system analyst and any person who
plays a part in the order that acts as a starting point for redesigning a system. The DFD is
also called as a data flow graph or bubble chart.
o The following observations about DFDs are essential:
All names should be unique. This makes it easier to refer to elements in the DFD.
Remember that DFD is not a flow chart. Arrows is a flow chart that represents the
order of events; arrows in DFD represents flowing data. A DFD does not involve
any order of events.
Suppress logical decisions. If we ever have the urge to draw a diamond-shaped
box in a DFD, suppress that urge! A diamond-shaped box is used in flow charts to
represents decision points with multiple exists paths of which the only one is
taken. This implies an ordering of events, which makes no sense in a DFD.
Do not become bogged down with details. Defer error conditions and error
handling until the end of the analysis.
o Standard symbols for DFDs are derived from the electric circuit diagram analysis and are
shown in fig:
Term Notation Remarks
Name of the external entity is written inside the

External entity
rectangle
Process Name of the process is written inside the circle
A left-right open rectangle is denoted as data store;

Data store
name of the data store is written inside the shape
Data flow is represented by a directed arc with its data

Data flow
name
Explanation of Symbols used in DFD
• Process: Processes are represented by circle. The name of the process is written into the circle.
The name of the process is usually given in such a way that represents the functionality of the
process. More detailed functionalities can be shown in the next Level if it is required. 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.
.
Levels in Data Flow Diagrams (DFD)
The DFD may be used to perform a system or software at any level of abstraction. Infact,
DFDs may be partitioned into levels that represent increasing information flow and
functional detail. Levels in DFD are numbered 0, 1, 2 or beyond. Here, we will see
primarily three levels in the data flow diagram, which are: 0-level DFD, 1-level DFD,
and 2-level DFD.
0-level DFDM
It is also known as fundamental system model, or context diagram represents the entire
software requirement as a single bubble with input and output data denoted by incoming
and outgoing arrows. Then the system is decomposed and described as a DFD with
multiple bubbles. Parts of the system represented by each of these bubbles are then
decomposed and documented as more and more detailed DFDs. This process may be
repeated at as many levels as necessary until the program at hand is well understood. It is
essential to preserve the number of inputs and outputs between levels, this concept is
called leveling by DeMacro. Thus, if bubble "A" has two inputs x1 and x2 and one output
y, then the expanded DFD, that represents "A" should have exactly two external inputs
and one external output as shown in fig:
The Level-0 DFD, also called context diagram of the result management system is shown
in fig. As the bubbles are decomposed into less and less abstract bubbles, the
corresponding data flow may also be needed to be decomposed.
1-level DFD
In 1-level DFD, a context diagram is decomposed into multiple bubbles/processes. In this

level, we highlight the main objectives of the system and breakdown the high-level
process of 0-level DFD into sub processes.
2-Level DFD
2-level DFD goes one process deeper into parts of 1-level DFD. It can be used to project
or record the specific/necessary detail about the system's functioning.

o Hardware:
o Software:
• Procedure / Steps:
o Example: ATM System
The data flow diagram is a hierarchy of diagram consist of:
• Context Diagram (conceptually level zero)

• The Level-1 DFD
• And possible Level-2 DFD and further levels of functional decomposition depending
on the complexity of your system.
Context DFD
The figure below shows a context Data Flow Diagram that is drawn for an Android supermarket
app. It contains a process (shape) that represents the system to model, in this case, the "ATM
System". It also shows the participants who will interact with the system, called the external
entities. In this example, there is only one external entity, which is the User. In between the
process and the external entity, there is a uni-directional connector, which indicates the existence
of information exchange between user and the ATM System, and the information flow is bi-
directional.
Context DFD is the entrance of a data flow model. It contains one and only one process and does
not show any data store, which makes the diagram simple.
Level 1 DFD
The figure below shows the level 1 DFD, which is the decomposition (i.e. break down) of
the ATM System process that is shown in the context DFD. Read through the diagram
and then we will introduce some of the key concepts based on this diagram.
Quiz:
1) Draw the Data Flow Diagram for Hotel Management System.

2) What is DFD? Give advantage and disadvantages of DFD.
3) Types and Components of Data Flow Diagram (DFD)
1) NPTEL course material - System Analysis and Design

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.



Correct answer to
all questions
Practical – 4
AIM: Prepare the user’s view analysis: Describe different scenarios and Draw Use case
diagrams using UML
• 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.
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.
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;
A description of the states when the scenario finishes.

o Hardware:
o Software:
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
o Example: ATM System
1. Identification of use cases.

2. Identification of actors.
3. Sample input:
1. Actor: User
2. Use case: Login
• Withdrawal Use Case :

A withdrawal transaction asks the customer to choose a type of account to withdraw from
(e.g. checking) from a menu of possible accounts, and to choose a dollar amount from a menu of
possible amounts. The system verifies that it has sufficient money on hand to satisfy the request
before sending the transaction to the bank. (If not, the customer is informed and asked to enter a
different amount.) If the transaction is approved by the bank, the appropriate amount of cash is
dispensed by the machine before it issues a receipt. A withdrawal transaction can be cancelled by
the customer pressing the Cancel key any time prior to choosing the dollar amount.
• Deposit Use Case :
A deposit transaction asks the customer to choose a type of account to deposit to (e.g.
checking) from a menu of possible accounts, and to type in a dollar amount on the keyboard. The
transaction is initially sent to the bank to verify that the ATM can accept a deposit from this
customer to this account. If the transaction is approved, the machine accepts an envelope from
the customer containing cash and/or checks before it issues a receipt. Once the envelope has been
received, a second message is sent to the bank, to confirm that the bank can credit the customer‟
account – contingent on manual verification of the deposit envelope contents by an operator
later.
A deposit transaction can be cancelled by the customer pressing the Cancel key any time
prior to inserting the envelope containing the deposit. The transaction is automatically cancelled
if the customer fails to insert the envelope containing the deposit within a reasonable period of
time after being asked to do so.
• Transfer UseCase:
A transfer transaction asks the customer to choose a type of account to transfer from (e.g.
checking) from a menu of possible accounts, to choose a different account to transfer to, and to
type in a dollar amount on the keyboard. No further action is required once the transaction is
approved by the bank before printing the receipt.
A transfer transaction can be cancelled by the customer pressing the Cancel key any time
prior to entering a dollar amount.
• Inquiry Use Case :
An inquiry transaction asks the customer to choose a type of account to inquire about
from a menu of possible accounts. No further action is required once the transaction is approved
by the bank before printing the receipt. An inquiry transaction can be cancelled by the customer
pressing the Cancel key any time prior to choosing the account to inquire about.
• Validate User usecase:
This usecase is for validate the user i.e check the pin number, when the bank reports that
the customer‟s transaction is disapproved due to an invalid PIN. The customer is required to re-
enter the PIN and the original request is sent to the bank again. If the bank now approves the
transaction, or disapproves it for some other reason, the original use case is continued; otherwise
the process of re-entering the PIN is repeated. Once the PIN is successfully re-entered.
If the customer fails three times to enter the correct PIN, the card is permanently retained,
a screen is displayed informing the customer of this and suggesting he/she contact the bank, and
the entire customer session is aborted.
Quiz:
1. What is use case diagram? Draw use case for library management system.
2. List relationship used in use case.
3. What Tests Can Help Find Useful Use Cases?
1) Use Case Diagrams.

2) Unified Modeling Language, Superstructure, V2.1.2.
3) "Functional Requirements and Use Cases", Ruth Malan and Dana Bredemeyer, Bredemeyer
Consulting.
4) "A Use Case Template: draft for discussion", Derek Coleman, Hewlett-Packard Software
Initiative X. J. Zheng, X. Liu, & S. Liu. (2010). Use Case and Non-functional Scenario
Template-Based Approach to Identify Aspects. Computer Engineering and Applications
ICCEA 2010 Second International Conference on (Vol. 2, pp. 89-93).

Problem Problem Problem Problem

analysis analysis analysis analysis


Correct answer
to all questions
Practical – 5
AIM: Prepare the structural view: Draw Class diagram and object diagram.
• Objectives: to learn about UML class diagram and object diagram components.
• Theory:
o Class diagram:
The class diagram depicts a static view of an application. It represents the types of
objects residing in the system and the relationships between them. A class
consists of its objects, and also it may inherit from other classes. A class diagram
is used to visualize, describe, document various different aspects of the system,
and also construct executable software code.
It shows the attributes, classes, functions, and relationships to give an overview of
the software system. It constitutes class names, attributes, and functions in a
separate compartment that helps in software development. Since it is a collection
of classes, interfaces, associations, collaborations, and constraints, it is termed as
a structural diagram.
o Purpose of Class Diagrams

The main purpose of class diagrams is to build a static view of an application. It is the
only diagram that is widely used for construction, and it can be mapped with object-
oriented languages. It is one of the most popular UML diagrams. Following are the
purpose of class diagrams given below:
1. It analyses and designs a static view of an application.
2. It describes the major responsibilities of a system.
3. It is a base for component and deployment diagrams.
4. It incorporates forward and reverse engineering.
o Benefits of Class Diagrams
1. It can represent the object model for complex systems.
2. It reduces the maintenance time by providing an overview of how an application
is structured before coding.
3. It provides a general schematic of an application for better understanding.
4. It represents a detailed chart by highlighting the desired code, which is to be
programmed.
5. It is helpful for the stakeholders and the developers.
Vital components of a Class Diagram
The class diagram is made up of three sections:
1. Upper Section: The upper section encompasses the name of the class. A class is a
representation of similar objects that shares the same relationships, attributes,
operations, and semantics. Some of the following rules that should be taken into
account while representing a class are given below:
1. Capitalize the initial letter of the class name.
2. Place the class name in the center of the upper section.
3. A class name must be written in bold format.
4. The name of the abstract class should be written in italics format.
2. Middle Section: The middle section constitutes the attributes, which describe the
quality of the class. The attributes have the following characteristics:
1. The attributes are written along with its visibility factors, which are public
(+), private (-), protected (#), and package (~).
2. The accessibility of an attribute class is illustrated by the visibility factors.
3. A meaningful name should be assigned to the attribute, which will explain
its usage inside the class.
3. Lower Section: The lower section contains methods or operations. The methods
are represented in the form of a list, where each method is written in a single line.
It demonstrates how a class interacts with data.
o Object diagram:
o Object diagrams are dependent on the class diagram as they are derived from the class
diagram. It represents an instance of a class diagram. The objects help in portraying a
static view of an object-oriented system at a specific instant.
o Both the object and class diagram are similar to some extent; the only difference is
that the class diagram provides an abstract view of a system. It helps in visualizing a
particular functionality of a system.
Notation of an Object Diagram
o Purpose of Object Diagram
The object diagram holds the same purpose as that of a class diagram. The class diagram
provides an abstract view which comprises of classes and their relationships, whereas the
object diagram represents an instance at a particular point of time.
The object diagram is actually similar to the concrete (actual) system behavior. The main
purpose is to depict a static view of a system.
How to draw a Class Diagram?
The class diagram is used most widely to construct software applications. It not only
represents a static view of the system but also all the major aspects of an application. A
collection of class diagrams as a whole represents a system.
Some key points that are needed to keep in mind while drawing a class diagram are given
below:
1. To describe a complete aspect of the system, it is suggested to give a meaningful name to

the class diagram.
2. The objects and their relationships should be acknowledged in advance.
3. The attributes and methods (responsibilities) of each class must be known.
4. A minimum number of desired properties should be specified as more number of the
unwanted property will lead to a complex diagram.
5. Notes can be used as and when required by the developer to describe the aspects of a
diagram.
6. The diagrams should be redrawn and reworked as many times to make it correct before
producing its final version.
o How to draw an Object Diagram?
1. All the objects present in the system should be examined before start drawing the object
diagram.
2. Before creating the object diagram, the relation between the objects must be
acknowledged.
3. The association relationship among the entities must be cleared already.
4. To represent the functionality of an object, a proper meaningful name should be assigned.
5. The objects are to be examined to understand its functionality.

o Hardware
o Software
o Example of sales order system
o Example of Object Diagram

Quiz:
1) How to create domain model?

2) When to Use: Class Diagrams.
3) Define Object diagram.
1) Domain Analysis.
2) Domain Analysis Using Textual Analysis Approach
3) Domain model
4) Business Modeling – The Domain Model
5) I. Y. Song, K. Yano, J. Trujillo, and S. Luján-Mora. "A Taxonomic Class Modeling Methodology for
Object-Oriented Analysis", In Information Modeling Methods and Methodologies, Advanced Topics in
Databases Series, Ed. (J Krostige, T. Halpin, K. Siau), Idea Group Publishing, 2004, pp. 216-240.



Correct answer to
all questions
Practical – 6
AIM: Prepare the behavioral view: Draw Sequence diagram and Collaboration diagram.
• Objectives: To explore and use various UML components of sequence diagram and
collaboration diagram
• Theory:
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.
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.
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.
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.
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.
o Collaboration diagram:
The collaboration diagram is used to show the relationship between the objects in
a system. Both the sequence and the collaboration diagrams represent the same
information but differently. Instead of showing the flow of messages, it depicts the
architecture of the object residing in the system as it is based on object-oriented
programming. An object consists of several features. Multiple objects present in the
system are connected to each other. The collaboration diagram, which is also known as a
communication diagram, is used to portray the object's architecture in the system.
Notations of a Collaboration Diagram
Following are the components of a component diagram that are enlisted below:
1.Objects: The representation of an object is done by an object symbol with its name and
class underlined, separated by a colon.
In the collaboration diagram, objects are utilized in the following ways:
o The object is represented by specifying their name and class.
o It is not mandatory for every class to appear.
o A class may constitute more than one object.
o In the collaboration diagram, firstly, the object is created, and then its class is specified.
o To differentiate one object from another object, it is necessary to name them.
2.Actors: In the collaboration diagram, the actor plays the main role as it invokes the
interaction. Each actor has its respective role and name. In this, one actor initiates the
use case.
3.Links: The link is an instance of association, which associates the objects and actors. It
portrays a relationship between the objects through which the messages are sent. It is
represented by a solid line. The link helps an object to connect with or navigate to
another object, such that the message flows are attached to links.
4. Messages: It is a communication between objects which carries information and
includes a sequence number, so that the activity may take place. It is represented by a
labeled arrow, which is placed near a link. The messages are sent from the sender to the
receiver, and the direction must be navigable in that particular direction. The receiver
must understand the message.
o How to Draw a Sequence Diagram
A sequence diagram represents the scenario or flow of events in one single use case.
The message flow of the sequence diagram is based on the narrative of the particular
use case.
Then, before you start drawing the sequence diagram or decide what interactions should
be included in it, you need to draw the use case diagram and ready a comprehensive
description of what the particular use case does.
From the above use case diagram example of ‘Create New Online Library Account’, we
will focus on the use case named ‘Create New User Account’ to draw our sequence
diagram example.
Before drawing the sequence diagram, it’s necessary to identify the objects
obje or actors that
would be involved in creating a new user account. These would be;
• Librarian
• Online Library Management system
• User credentials database
• Email system
Once you identify the objects, it is th

then
en important to write a detailed description on what
the use case does. From this description, you can easily figure out the interactions (that
should go in the sequence diagram) that would occur between the objects above, once the
use case is executed.
Here
re are the steps that occur in the use case named ‘Create New Library User Account’.
• The librarian request the system to create a new online library account
• The librarian then selects the library user account type
• The librarian enters the user’s details
• Thee user’s details are checked using the user Credentials Database
• The new library user account is created
• A summary of the of the new account’s details are then emailed to the user
From each of these steps, you can easily specify what messages should be exchanged
exc
between the objects in the sequence diagram. Once it’s clear, you can go ahead and start
drawing the sequence diagram.
The sequence diagram below shows how the objects in the online library management
system interact with each other to perform the ffunction
unction ‘Create New Library User
Account’.

o Hardware:
o Software:
o Sequence Diagram Example: Hotel System
Sequence Diagram is an interaction diagram that details how operations are carried out --
what messages are sent and when. Sequence diagrams are organized according to time. The
time progresses as you go down the page. The objects involved in the operation are listed
from left to right according to when they take part in the message sequence.
Below is a sequence diagram for making a hotel reservation. The object initiating the
sequence of messages is a Reservation window.
Note That: Class and object diagrams are static model views. Interaction diagrams are
dynamic. They describe how objects collaborate.
o Steps for creating a Collaboration Diagram
o Determine the behavior for which the realization and implementation are specified.
o Discover the structural elements that are class roles, objects, and subsystems for
performing the functionality of collaboration.
o Choose the context of an interaction: system, subsystem, use case, and operation.
o Think through alternative situations that may be involved.
o Implementation of a collaboration diagram at an instance level, if needed.
o A specification level diagram may be made in the instance level sequence diagram for
summarizing alternative situations.
Example of a Collaboration Diagram
Quiz:
1) Difference between Sequence diagram and Collaboration diagram.

2) In a sequence diagram, what does a box depict? What does a dashed line depict? What does a
arrow between boxes depict?
3) What does a X over a lifeline indicate?
1) Booch, G. et al. The Unified Modeling Language User Guide. Chapters 15, 18, 27. Addison-
Wesley.
2) Jacobson, I. et al. Object-Oriented Software Engineering: A Use-Case Driven Approach.
Addison-Wesley.
3) Fowler, M. UML Distilled: A Brief Guide to the Standard Object Modelling Language.
Chapter 5. Addison Wesley.



Correct answer to
all questions
Practical – 7
AIM: Prepare the behavioral view: Draw State-chart diagram and Activity diagram.
• Objectives:
To explore various components of UML state-chart diagram and use them.

To explore various elements of activity diagram and use them.
• Theory:
o State Machine Diagram:
The state machine diagram is also called the Statechart or State Transition diagram, which
shows the order of states underwent by an object within the system. It captures the software
system's behavior. It models the behavior of a class, a subsystem, a package, and a complete
system.
It tends out to be an efficient way of modeling the interactions and collaborations in the
external entities and the system. It models event-based systems to handle the state of an
object. It also defines several distinct states of a component within the system. Each
object/component has a specific state.
Following are the types of a state machine diagram that are given below:
• Behavioral state machine

o The behavioral state machine diagram records the behavior of an object within the
system. It depicts an implementation of a particular entity. It models the behavior of the
system.
• Protocol state machine
It captures the behavior of the protocol. The protocol state machine depicts the change in
the state of the protocol and parallel changes within the system. But it does not portray
the implementation of a particular component.
o Notation of a State Machine Diagram
Following are the notations of a state machine diagram enlisted below:
1. Initial state: It defines the initial state (beginning) of a system, and it is represented by a
black filled circle.
2. Final state: It represents the final state (end) of a system. It is denoted by a filled circle
present within a circle.
3. Decision box: It is of diamond shape that represents the decisions to be made on the basis
of an evaluated guard.
4. Transition: A change of control from one state to another due to the occurrence of some
event is termed as a transition. It is represented by an arrow labeled with an event due to
which the change has ensued.
5. State box: It depicts the conditions or circumstances of a particular object of a class at a
specific point of time. A rectangle with round corners is used to represent the state box.
o Types of State
The UML consist of three states:
1. Simple state: It does not constitute any substructure.

2. Composite state: It consists of nested states (substates), such that it does not
contain more than one initial state and one final state. It can be nested to any
level.
3. Submachine state: The submachine state is semantically identical to the
composite state, but it can be reused.
When to use an Activity Diagram?
An activity diagram can be used to portray business processes and workflows. Also, it used for
modeling business as well as the software. An activity diagram is utilized for the followings:
1.To graphically model the workflow in an easier and understandable way.

2.To model the execution flow among several activities.
3.To model comprehensive information of a function or an algorithm employed within the
system.
4.To model the business process and its workflow.
5.To envision the dynamic aspect of a system.
6.To generate the top-level flowcharts for representing the workflow of an application.
7.To represent a high-level view of a distributed or an object-oriented system.

o Hardware:
o Software:
o How to Draw a State Machine Diagram?
The state machine diagram is used to portray various states underwent by an object. The change
in one state to another is due to the occurrence of some event. All of the possible states of a
particular component must be identified before drawing a state machine diagram.
The primary focus of the state machine diagram is to depict the states of a system. These states
are essential while drawing a state transition diagram. The objects, states, and events due to
which the state transition occurs must be acknowledged before the implementation of a state
machine diagram.
Following are the steps that are to be incorporated while drawing a state machine diagram:
1. A unique and understandable name should be assigned to the state transition that describes
the behavior of the system.
2. Out of multiple objects, only the essential objects are implemented.
3. A proper name should be given to the events and the transitions.
o Example of a State Machine Diagram
An example of a top-level state machine diagram showing Bank Automated Teller Machine
(ATM) is given below.
Initially, the ATM is turned off. After the power supply is turned on, the ATM starts
performing the startup action and enters into the Self Test state. If the test fails, the ATM
will enter into the Out Of Service state, or it will undergo a triggerless transition to the
Idle state. This is the state where the customer waits for the interaction.
Whenever the customer inserts the bank or credit card in the ATM's card reader, the ATM
state changes from Idle to Serving Customer, the entry action readCard is performed after
entering into Serving Customer state. Since the customer can cancel the transaction at any
instant, so the transition from Serving Customer state back to the Idle state could be
triggered by cancel event.
Here the Serving Customer is a composite state with sequential substates that are Customer
Authentication, Selecting Transaction, and Transaction.
Customer Authentication and Transaction are the composite states itself is displayed by a
hidden decomposition indication icon. After the transaction is finished, the Serving
Customer encompasses a triggerless transition back to the Idle state. On leaving the state, it
undergoes the exit action ejectCard that discharges the customer card.
o Activity Diagram:
o In UML, the activity diagram is used to demonstrate the flow of control within the system
rather than the implementation. It models the concurrent and sequential activities.
o The activity diagram helps in envisioning the workflow from one activity to another. It put
emphasis on the condition of flow and the order in which it occurs. The flow can be
sequential, branched, or concurrent, and to deal with such kinds of flows, the activity
diagram has come up with a fork, join, etc.
o It is also termed as an object-oriented flowchart. It encompasses activities composed of a set
of actions or operations that are applied to model the behavioral diagram.
o Components of an Activity Diagram
Following are the component of an activity diagram:
o Activities
o The categorization of behavior into one or more actions is termed as an activity. In other
words, it can be said that an activity is a network of nodes that are connected by edges. The
edges depict the flow of execution. It may contain action nodes, control nodes, or object
nodes.
o The control flow of activity is represented by control nodes and object nodes that illustrates
the objects used within an activity. The activities are initiated at the initial node and are
terminated at the final node.
o Activity partition /swimlane
The swimlane is used to cluster all the related activities in one column or one row. It can be
either vertical or horizontal. It used to add modularity to the activity diagram. It is not
necessary to incorporate swimlane in the activity diagram. But it is used to add more
transparency to the activity diagram.
o Forks
Forks and join nodes generate the concurrent flow inside the activity. A fork node consists of
one inward edge and several outward edges. It is the same as that of various decision
parameters. Whenever a data is received at an inward edge, it gets copied and split crossways
various outward edges. It split a single inward flow into multiple parallel flows.
o Join Nodes
Join nodes are the opposite of fork nodes. A Logical AND operation is performed on all of
the inward edges as it synchronizes the flow of input across one single output (outward)
edge.
o Pins
o It is a small rectangle, which is attached to the action rectangle. It clears out all the messy and
complicated thing to manage the execution flow of activities. It is an object node that
precisely represents one input to or output from the action.
o Notation of an Activity diagram
Activity diagram constitutes following notations:
Initial State: It depicts the initial stage or beginning of the set of actions.
Final State: It is the stage where all the control flows and object flows end.
Decision Box: It makes sure that the control flow or object flow will follow only one path.
Action Box: It represents the set of actions that are to be performed.
How to draw an Activity Diagram?
An activity diagram is a flowchart of activities, as it represents the workflow among

various activities. They are identical to the flowcharts, but they themself are not exactly the
flowchart. In other words, it can be said that an activity diagram is an enhancement of the
flowchart, which encompasses several unique skills.
Since it incorporates swimlanes, branching, parallel flows, join nodes, control nodes, and
forks, it supports exception handling. A system must be explored as a whole before drawing
an activity diagram to provide a clearer view of the user. All of the activities are explored
after they are properly analyzed for finding out the constraints applied to the activities. Each
and every activity, condition, and association must be recognized.
After gathering all the essential information, an abstract or a prototype is built, which is
then transformed into the actual diagram.
Following are the rules that are to be followed for drawing an activity diagram:
1. A meaningful name should be given to each and every activity.
2. Identify all of the constraints.
3. Acknowledge the activity associations.
Example of an Activity Diagram

An example of an activity diagram showing th thee business flow activity of order processing is
given below.
Here the input parameter is the Requested order, and once the order is accepted, all of the
required information is then filled, payment is also accepted, and then the order is shipped. It
permitss order shipment before an invoice is sent or payment is completed.
Quiz:
1) Contrast Branches and Forks?

2) What are the initial and final states of an Activity diagram represented by?
3) What differentiates one state of a software component from another?
4) What is the source of a transition that begins at the border of a composite state?
1) UML 2 State Machine Diagrams

Diagrams.
2) Modeling Behavior with UML Interactions and State charts
3) UML 2 State Machine Diagramming Guidelines
4) State chart Diagr
Diagram
5) PlantUML (Open
(Open-Source
Source tool in Java to draw UML Diagram)




questions
Practical – 8
AIM: Prepare the implementation view: Draw Component diagram and Deployment diagram.
• Objectives: to explore and use various elements UML component diagram and deployment
diagram.
• Theory:
o A component diagram is used to break down a large object-oriented system into the
smaller components, so as to make them more manageable. It models the physical view
of a system such as executables, files, libraries, etc. that resides within the node.
o It visualizes the relationships as well as the organization between the components present
in the system. It helps in forming an executable system. A component is a single unit of
the system, which is replaceable and executable. The implementation details of a
component are hidden, and it necessitates an interface to execute a function. It is like a
black box whose behavior is explained by the provided and required interfaces.
o Purpose of a Component Diagram
Since it is a special kind of a UML diagram, it holds distinct purposes. It describes all the
individual components that are used to make the functionalities, but not the
functionalities of the system. It visualizes the physical components inside the system. The
components can be a library, packages, files, etc.
The component diagram also describes the static view of a system, which includes the
organization of components at a particular instant. The collection of component diagrams
represents a whole system.
The main purpose of the component diagram are enlisted below:
1. It envisions each component of a system.

2. It constructs the executable by incorporating forward and reverse engineering.
3. It depicts the relationships and organization of components.
o Notation of a Component Diagram
a) A component
b) A node
o When to use a Component Diagram?
It represents various physical components of a system at runtime. It is helpful in

visualizing the structure and the organization of a system. It describes how individual
components can together form a single system. Following are some reasons, which tells
when to use component diagram:
1. To divide a single system into multiple components according to the functionality.

2. To represent the component organization of the system.

o Hardware:
o Software:
o How to Draw a Component Diagram?
The component diagram is helpful in representing the physical aspects of a
system, which are files, executables, libraries, etc. The main purpose of a
component diagram is different from that of other diagrams. It is utilized in the
implementation phase of any application.
Once the system is designed employing different UML diagrams, and the artifacts
are prepared, the component diagram is used to get an idea of implementation. It
playss an essential role in implementing applications efficiently.
Following are some artifacts that are needed to be identified before drawing a
component diagram:
1. What files are used inside the system?

2. What is the application of relevant libraries and artifacts?
artifac
3. What is the relationship between the artifacts?
Following are some points that are needed to be kept in mind after the artifacts are
identified:
1. Using a meaningful name to ascertain the component for which the

diagram is about to be drawn.
2. Before pro
producing
ducing the required tools, a mental layout is to be made.
3. To clarify the important points, notes can be incorporated.
o Example of a Component Diagram

o A component diagram for an online shopping system is given below:
o The deployment diagram visualizes the pphysical

hysical hardware on which the software will be
deployed. It portrays the static deployment view of a system. It involves the nodes and
their relationships.
o It ascertains how software is deployed on the hardware. It maps the software architecture
created in design to the physical system architecture, where the software will be executed
as a node. Since it involves many nodes, the relationship is shown by utilizing
communication paths.
o Purpose of Deployment Diagram
The main purpose of the deployment diagram is to represent how software is
installed on the hardware component. It depicts in what manner a software
interacts with hardware to perform its execution.
Both the deployment diagram and the component diagram are closely interrelated
to each other as they focus on software and hardware components. The
component diagram represents the components of a system, whereas the
deployment diagram describes how they are actually deployed on the hardware.
o The deployment diagram does not focus on the logical components of the system, but it
put its attention on the hardware topology.
o Following are the purposes of deployment diagram enlisted below:
• To envision the hardware topology of the system.
• To represent the hardware components on which the software components are
installed.
• To describe the processing of nodes at the runtime.
o Symbol and notation of Deployment diagram

o The deployment diagram consist of the following notations:
1. A component
2. An artifact
3. An interface
4. A node
o How to draw a Deployment Diagram?
The deployment diagram portrays the deployment view of the system. It helps in
visualizing the topological view of a system. It incorporates nodes, which are
physical hardware. The nodes are used to execute the artifacts. The instances of
artifacts can be deployed on the instances of nodes.
Since it plays a critical role during the administrative process, it involves the
following parameters:
1. High performance
2. Scalability
3. Maintainability
4. Portability
5. Easily understandable
One of the essential elements of the deployment diagram is the nodes and artifacts. So
it is necessary to identify all of the nodes and the relationship between them. It
becomes easier to develop a deployment diagram if all of the nodes, artifacts, and
their relationship is already known.
o Example of a Deployment diagram
A deployment diagram for the Apple iTunes application is given below.
The iTunes setup can be downloaded from the iTunes website, and also it can be installed
on the home computer. Once the installation and the registration are done, iTunes
application can easily interconnect with the Apple iTunes store. Users can purchase and
download music, video, TV serials, etc. and cache it in the media library.
Devices like Apple iPod Touch and Apple iPhone can update its own media library from
the computer with iTunes with the help of USB or simply by downloading media directly
from the Apple iTunes store using wireless protocols, for example; Wi-Fi, 3G, or EDGE.
Quiz:
1) Component diagram and Deployment diagram.
2) Draw component diagram to show the run time dependency between a java class file ,
the java.exe runtime program and the java classes in .zip file.
1) Introduction to the Diagrams of UML 2.X




questions
Practical – 9
AIM: Prepare the quality management plan.
• Objectives: To explore the contents which is required to create quality management plan
• Theory:
Quality Management Plan Content
• Overview of Quality Management Plan

• Purpose
• Overview of Plan, Do, Check, Act
• Customer Quality Objectives
• Identify Customer Quality Objectives
• Identify Quality Threshold for each Quality Objective
• Quality Control Plans
• Address each major deliverable
• Identify Independent Technical Review Team(s)
• Quality Assurance
• Organizational Quality System Requirements (Organizational Quality Management Plan)
• Project-specific requirements
• Other Project Specific Information as required
Plan
• Identify the customers Quality Objectives. Help customers express quality expectations in
objective, quantitative terms.
• Identify professional standards including legal, environmental, economic, code, life safety
and health.
• Balance needs and expectations of customers and stakeholders with cost, schedule, and
professional standards. Evaluate the costs and benefits of selected quality objectives and the
processes to be used to achieve objectives.
• Develop an effective plan and processes, including quality assurance and quality control
procedures, to achieve objectives. Consider risk/hazard factors and complexity of the project
and adapt processes to provide the requisite level of quality. Document in the risk
management plan any project variations from the local QMP requirements.
• Develop performance measure thresholds to ensure agreement on the definition of success
relative to Quality Objectives.
• Ensure customer endorsement of all quality objectives included in the Quality Management
Plan.
Do
• Do the work according to the approved PMP and standard operating procedures.
• Project execution is a dynamic process. The PDT must communicate, meet on a regular
basis, and adapt to changing conditions. The Quality Management Plan and PMP may
require modification to ensure that project objectives are met.
Check
• Perform independent technical review, management oversight, and verification to ensure that
quality objectives are met consistent with District Quality Management Plans.
• Check performance against the PMP and Customer Quality Objectives performance
measures thresholds to verify that performance will accomplish Quality Objectives and to
verify sufficiency of the plan. Share findings with all project stakeholders to facilitate
continuous improvement.
Act
• If performance measures thresholds are exceeded, take specific corrective actions to fix the
systemic cause of any non-conformance, deficiency, or other unwanted effect.
• Document quality improvements that could include appropriate revisions to the quality
management plan, alteration of quality assurance and control procedures, and adjustments to
resource allocations.
Quiz:
1. Compare Cohesion and coupling with suitable example.
2. Different between software quality assurance vs software quality control.
1) Rajib Mall, Fundamentals of software Engineering, Prentice Hall of India.
2) Pankaj Jalote, Software Engineering – A Precise Approach Wiley





questions
Practical – 10
AIM: To perform various testing using the testing tool unit testing, integration testing design test cases.
• 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 concentrate 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.
• 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.

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
aintain 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 ttool ool 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.
o It is best for test
est 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

o Hardware:
o Software:
o RTH iss another webweb-based open-source tool, and it stands for the Requirement and
testing hub.. It is used to manage the requirements, test results, and also have bug
tracking facilities. This tool follows a structured approach to extend the visibility of the
testing
ting process with the help of a common repository for test cases, test result,
requirements, and test plans.
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 ca
case
se is to achieve the efficiency of the
application.
As we know, the actual result is written after the test case execution, and most of the
time, it would be same as the expected result. But if the test step will fail, it will be
different. So, the actual result field can be skipped, and in the Comments section, we can
write about the bugs.
And also, the Input field can be removed, and this information can be added to the
Description field.
The above template we discuss above is not the standard one because it can be different
for each company and also with each application, which is based on the test engineer and
the test lead. But, for testing one application, all the test engineers should follow a usual
template, which is formulated.
The test case should be written in simple language so that a new test engineer can also
understand and execute the same.
In the above sample template, the header contains the following:

Step number
It is also essential because if step number 20 is failing, we can document the bug report
and hence prioritize working and also decide if it’s a critical bug.
Test case type
It can be functional, integration or system test cases or positive or negative or positive
and negative test cases.
Release
One release can contain many versions of the release.
Pre-condition
These are the necessary conditions that need to be satisfied by every test engineer before
starting the test execution process. Or it is the data configuration or the data setup that
needs to be created for the testing.
For example: In an application, we are writing test cases to add users, edit users, and
delete users. The per-condition will be seen if user A is added before editing it and
removing it.
Test data
These are the values or the input we need to create as per the per-condition.
For example, Username, Password, and account number of the users.
The test lead may be given the test data like username or password to test the application,
or the test engineer may themself generate the username and password.
o Test Cases – Login Page

o Following is the possible list of functional and non-functional test cases for a
login page:
o Functional Test Cases:

Type- Negative/
Sr. No. Functional Test Cases
Positive Test Case
Verify if a user will be able to login with a valid username and valid
1 Positive
password.
Verify if a user cannot login with a valid username and an invalid
2 Negative
password.
Verify the login page for both, when the field is blank and Submit button is
3 Negative
clicked.
4 Verify the ‘Forgot Password’ functionality. Positive
5 Verify the messages for invalid login. Positive
6 Verify the ‘Remember Me’ functionality. Positive
Verify if the data in password field is either visible as asterisk or bullet
7 Positive
signs.
Verify if a user is able to login with a new password only after he/she has
8 Positive
changed the password.
Verify if the login page allows to log in simultaneously with different
9 Positive
credentials in a different browser.
Verify if the ‘Enter’ key of the keyboard is working correctly on the login
10 Positive
page.
Other Test Cases
Performance &
11 Verify the time taken to log in with a valid username and password.
Positive Testing
12 Verify if the font, text color, and color coding of the Login page is as per UI Testing &
Type- Negative/
Sr. No. Functional Test Cases
Positive Test Case
the standard. Positive Testing
13 Verify if there is a ‘Cancel’ button available to erase the entered text. Usability Testing
Browser
14 Verify the login page and all its controls in different browsers Compatibility &
Positive Testing.
o Non-functional Security Test Cases:

Type- Negative/
Sr. No. Security test cases
Positive Test Case
Verify if a user cannot enter the characters more than the specified range in
1 Negative
each field (Username and Password).
Verify if a user cannot enter the characters more than the specified range in
2 Positive
each field (Username and Password).
Verify the login page by pressing ‘Back button’ of the browser. It should
3 Negative
not allow you to enter into the system once you log out.
4 Verify the timeout functionality of the login session. Positive
Verify if a user should not be allowed to log in with different credentials
5 Negative
from the same browser at the same time.
Verify if a user should be able to login with the same credentials in
6 Positive
different browsers at the same time.
7 Verify the Login page against SQL injection attack. Negative
8 Verify the implementation of SSL certificate. Positive
Showing 1 to 8 of 8 entries
We can take an Example of Gmail Login page. Here is the image of it.
Test Cases for Gmail Login page
Sr.
Test Scenarios
No.
1 Enter the valid email address & click next. Verify if the user gets an option to enter the password.
Don’t enter an email address or phone number & just click the Next button. Verify if the user
2
will get the correct message or if the blank field will get highlighted.
Enter the invalid email address & click the Next button. Verify if the user will get the correct
3
message.
Enter an invalid phone number & click the Next button. Verify if the user will get the correct
4
message.
5 Verify if a user can log in with a valid email address and password.
6 Verify if a user can log in with a valid phone number and password.
7 Verify if a user cannot log in with a valid phone number and an invalid password.
8 Verify if a user cannot log in with a valid email address and a wrong password.
9 Verify the ‘Forgot email’ functionality.
10 Verify the ‘Forgot password’ functionality.
Test Scenarios for the Sign-up page

1) Verify the messages for each mandatory field.
2) Verify if the user cannot proceed without filling all the mandatory fields.
3) Verify the age of the user when the DOB is selected.
4) Verify if the numbers and special characters are not allowed in the First and Last name.
5) Verify if a user can sign-up successfully with all the mandatory details.
6) Verify if a user can log in with the valid details.
7) Verify if the Password and Confirm Password fields are accepting similar strings only.
8) Verify if the Password field will prompt you for the weak passwords.
9) Verify if duplicate email address will not get assigned.
10) Verify that hints are provided for each field on the form, for the ease of use.
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? What are the different black box testing techniques?
1 Software Testing: A Craftsman's Approach, by Paul C. Jorgensen, Third Edition

2 Software Engineering by Rajib Mall, PHI 2014



Correct answer to
all questions
Practical – 11
AIM: Case Study: Study of Op
Open-source
source tools in DevOps for Infrastructure Automation,
Configuration Management, Deployment Automation, Performance Management, Log
Management. Monitoring
• Objectives: to explore various case studies where DevOps is applied.
• Theory:
DevOps is the combination

ation 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,
Sometime
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
se 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 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.
Micro services
The micro services 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). Micro services are built around business capabilities; each service
is scoped to a single purpose. You can use different frameworks or programming languages to
write micro services and deploy them independently, as a single service, or as a group of
services.
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 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.
1 Deepak Gaikwad, Viral Thakkar, DevOps Tools from Practitioner’s ViewPoint, Wiley.
2 The DevOps Handbook - Gene Kim et. al.





questions

SE - Lab Manual

Uploaded by

Copyright:

Available Formats

SE - Lab Manual

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SE - Lab Manual

Uploaded by

Copyright:

Available Formats

A Laboratory Manual for

Directorate of Technical Education, Gandhinagar,

Government Engineering College, Bhavnagar

continuous learners by inculcating human values and imparting excellence in technical

Department of Computer Engineering Vision and Mission

Information Technology through innovation, team work and ethical practices.

To attain excellence in teaching-learning process by providing better infrastructure facilities.

Program Education Objectives:

businesses offering innovative solutions.

towards lifelong learning.

in the context of science, technology, society and humanity.

Program Specific Outcomes:

An ability to design solutions by simulating computer engineering problems in absence of

real time environment.

programming, computer networks and database management.

An ability to face competitive examinations for higher education and PSUs.

This is to certify that Mr./Ms. ___________________________________

Name and Sign of Faculty member

Head of the Department

Course Outcomes (COs):

Prepare the structural view: Draw the Class diagram and

Sr. Objective(s) of Experiment Page Date of Date of AssessSign. of Remarks

10. To perform various testing using the testing tool

Degree Program in which this course is offered Semester in which offered

Computer Engineering 5th Semester

After learning the course, the students should be able to:

4. TEACHING AND EXAMINATION SCHEME

5. SUGGESTED LEARNING RESOURCES

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

B. LIST OF SOFTWARE / LEARNING WEBSITES

1. Apply knowledge of Software engineering to solve real world problems

Guidelines for Faculty members

Instructions for Students

Figure: Requirements Engineering Process

oduction of the requirements stage of the software development process is Software

Characteristics of good SRS

The following are the features of a good SRS document:

(1). All essential requirements, whether relating to functionality, performance, design,

6. Modifiability: SRS should be made as modifiable as likely and should be capable of

There are two types of Traceability:

1. Backward Traceability: This depends upon each requirement explicitly referencing

9. Design Independence: There should be an option to select from multiple design

Properties of a good SRS document

The essential properties of a good SRS document are the following:

Structured: It should be well-structured. A well-structured document is simple to understand

Requirement engineering consists of seven different tasks as follows:

Elicitation means to find the requirements from anybody.

In this task, the requirement engineer constructs a final work product.

The work product is in the form of software requirement specification.

The requirements are formalize in both graphical and textual formats.

After finalizing the requirement traceability table is developed.

• Tools / Material Needed:

R.1.3: Get required amount

o Example 2: Search Book Availability in Library

• (i) Purpose of this Document –

1. Which are properties of good SRS?

1. Lecture on "System Analysis and Design", NPTEL

Marks Complete Complete Complete Complete Complete

Problem analysis Problem analysis Problem analysis Problem analysis