St.

PETER'S COLLEGE OF ENGINEERING AND TECHNOLOGY

AVADI, CHENNAI - 600 054.

DEPARTMENT OF COMPUTER SCIENCE AND

ENGINEERING

CP4212 – SOFTWARE ENGINEERING LABORATORY

Record Note Book

NAME :

REG. NO. :

PROGRAMME: M.E (CSE)

BRANCH : COMPUTER SCIENCE AND ENGINEERING

YEAR /SEM : I / II
2021-22 EVEN SEMESTER
 ST. PETER'S COLLEGE OF ENGINEERING AND TECHNOLOGY
AVADI, CHENNAI - 600 054.

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

Bonafide Certificate

NAME:

YEAR: SEMESTER: BRANCH: .

REGISTER NO:

Certified that this is a bonafide record of work done by the above student in the CP4212 –
SOFTWARE ENGINEERING LABORATORY during the academic year 2021 – 2022.

Faculty-in-Charge Head of the Department

Submitted for the practical Examination held on …14/10/2022... at St. PETER'S

COLLEGE OF ENGINEERING AND TECHNOLOGY.

Internal Examiner External Examiner

 ST PETER’S COLLEGE OF ENGINEERING AND TECHNOLOGY,
AVADI, CHENNAI

VISION

To emerge as an Institution of Excellence by providing High Quality Education in Engineering,

Technology and Management to contribute for the economic as well as societal growth of our
Nation.

MISSION

 To impart strong fundamental and Value-Based Academic knowledge in various

Engineering, Technology and Management disciplines to nurture creativity.
 To promote innovative Research and Development activities by collaborating with
Industries, R&D organizations and other statutory bodies.
 To provide conducive learning environment and training so as to empower the students
with dynamic skill development for employability.
 To foster Entrepreneurial spirit amongst the students for making a positive impact on
remarkable community development.
 DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

VISION

To empower our students to take part in progressive socio– economic conditioned nation
building process by creating diligent, adept and responsible Computer Science Engineers.

MISSION

1. To provide Quality Engineering Education through cutting edge technologies in Computer

Science and Engineering.
2. To provide conducive learning milieu to comprehend nitty-gritty of computing process,
edify the students to become successful professional lifelong learners.
3. To establish Industry-Institution liaison to make the students to cater the needs of Industry.
4. To promote projects and activities in the promising areas of Engineering and Technology.
 PROGRAMME EDUCATIONAL OBJECTIVES(PEOs)

PEO I:

To enable graduates to pursue higher education and research, or have a successful career in
industries associated with Computer Science and Engineering, or as entrepreneurs.

PEO II:

To ensure that graduates will have the ability and attitude to adapt to emerging technological
changes.

PROGRAMME SPECIFIC OUTCOMES(PSOs)

Computer Science and Engineering Graduates will be able to

PSO I:

Analyze, design and develop computing solutions by applying foundational concepts of

computer science and engineering.

PSO II:

Apply software engineering principles and practices for developing quality software for
scientific and business applications.

PSO III:

Achieve confidence to become Entrepreneurs and face the challenging working environment.
 ST PETER’S COLLEGE OF ENGINEERING AND TECHNOLOGY
AVADI, CHENNAI
DEPARTMENT OF CSE
PROGRAM OUTCOMES (POs)
Engineering Graduates will be able to:
1. Engineering knowledge: Apply the knowledge of mathematics, science, engineering
fundamentals, and an engineering specialization to the solution of complex engineering
problems.

2. Problem analysis: Identify, formulate, review research literature, and analyze complex
engineering problems reaching substantiated conclusions using first principles of
mathematics, natural sciences, and engineering sciences.

3. Design/development of solutions: Design solutions for complex engineering problems

and design system components or processes that meet the specified needs with
appropriate consideration for the public health and safety, and the cultural, societal, and
environmental considerations.

4. Conduct investigations of complex problems: Use research-based knowledge and

research methods including design of experiments, analysis and interpretation of data,
and synthesis of the information to provide valid conclusions.

5. Modern tool usage: Create, select, and apply appropriate techniques, resources, and
modern engineering and IT tools including prediction and modeling to complex
engineering activities with an understanding of the limitations.

6. The engineer and society: Apply reasoning informed by the contextual knowledge to
assess societal, health, safety, legal and cultural issues and the consequent
responsibilities relevant to the professional engineering practice.

7. Environment and sustainability: Understand the impact of the professional

engineering solutions in societal and environmental contexts, and demonstrate the
knowledge of, and need for sustainable development.

8. Ethics: Apply ethical principles and commit to professional ethics and responsibilities
and norms of the engineering practice.

9. Individual and team work: Function effectively as an individual, and as a member or

leader in diverse teams, and in multidisciplinary settings.

10. Communication: Communicate effectively on complex engineering activities with the

engineering community and with society at large, such as, being able to comprehend and
write effective reports and design documentation, make effective presentations, and give
and receive clear instructions.

11. Project management and finance: Demonstrate knowledge and understanding of the
engineering and management principles and apply these to one’s own work, as a member
and leader in a team, to manage projects and in multidisciplinary environments.

12. Life-long learning: Recognize the need for, and have the preparation and ability to
engage in independent and life-long learning in the broadest context of technological
change.
 INDEX
PAGE
NO. DATE NAME OF THE PROGRAM SIGNATURE
NO.
 Experiment No 1

Write problem statement to define the project title with bounded scope of the project.
I Practical Significance

A properly defined and managed scope leads to delivering a quality product, in agreed cost and within
specified schedules to the stake-holders. Whilst there is a clear understanding of the need to achieve project
success, surprisingly little is published on significance of scope on project success. This study discusses that scope
should be properly defined and controlled and what can be the major factors behind mismanagement of scope and
how it can be overcome.

II Relevant Program Outcomes

All POs are listed.

III Relevant Course Outcomes

Identify the project needs, objectives and goals of the Project.

IV Practical Learning Outcomes

Define the project title with bounded scope of the project.

V Practical Skills

Learn how to write Scope of the project.

VI Relevant Affective domain related Outcomes

a) Identify the project needs

b) Project Scope description
c) Identify constraints
d) Identify necessary changes

VII Minimum Theoretical Background

Project scope is the part of project planning that involves determining and documenting a list of
specificproject goals, deliverables, features, functions, tasks, deadlines, and ultimately costs. In other words, it is
what needs to be achieved and the work that must be done to deliver a project. It is important to pin down the
scope early in a project’s life cycle as it can greatly impact the schedule or cost (or both) of the project down the
track.
VIII Resources required

Sr No Instrument Specification Quantity Remarks

Any Desktop PC
1 Computer System with attached 10 No. Whichever is available
HardDisk

IX Procedure

1. Identify the project needs

2. Confirm the objectives and goals of the Project
3. Project Scope description
4. Expectations and acceptance
5. Identify constraints
6. Identify necessary changes
X Precautions

1. Change the requirement carefully.

2. Save changes if required under the guidance of teacher.
XI Description

A project scope is the first step in setting your project goals and objectives.

Project Scope Step 1:

1. Identify the project needs

When you are clearly able to identify the needs of a project, you are more likely to set a soundbenchmark from
the beginning.
Understanding the ‘what and why’ of a project will enable you to set specific goals and objectives. It also sets the
groundwork for what tasks are to follow and how they are to be performed.

Project Scope Step 2:

2. Confirm the objectives and goals of the Project

The basis of the project scope should entail your goals and objectives to be one that follows a SMART guideline.
That is, to be Specific, Measurable and Achievable. It should also be Realistic and completed within a specific
Timeframe.
Specific–This involves stating accurately what the project wants to achieve. That is, what, why and how these will be
done. Clarity will reduce the chances of ambiguities and misunderstandings.
Measurable –Are your goals and objectives able to provide feedback and be accountable for?
Achievable –Can your project’s goals and objectives be achieved, given the resources on hand?
Realistic –Are the goals and objectives easy to deliver, especially if you face problems or complications. Will
these reduce the overall quality of the project’s outcome and cause running over budget and not meeting the set
deadlines.
Time Frame –Can your project goals and objectives be met within the allocated time frame? Is it a key criterion to
meet these deadlines?

Project Scope Step 3:

3. Project Scope description

You as a leader, need to be clear about the features and functioning required for your product or service. For
example, you are building a website. You need a list that provides how you will build your website, the type of
branding required and so on. In other words, what certain qualities will increase achieving your project’s success.

Project Scope Step 4:

4. Expectations and acceptance

Successful projects are ones that take into account the satisfaction of the end-user. Whether they meet the end-
users expectations and accept the product, service or process. The end-users could be your customers or your
internal team.
For customers, this includes pricing, value, and quality of products/services as well as availability, delivery and
return policies. For employees, this includes the effectiveness and efficiency of new operational processes.
Ultimately, your project scope is one that should be attuned to giving better outcomes to whoever your end users
may be.

Project Scope Step 5:

5. Identify constraints
There are always roadblocks to achieving what you were set out to do. When being aware of possible limitations
along the way, it can help you minimize problems that may delay or constrain your ability to achieve your project’s
outcome.
These can be caused by dynamic environmental conditions (internal and external), technological glitches and/or
lack of resources. Communicating such problems with your team early on and taking steps to overcome these
hurdles will reduce delays in project completion and keep spending within budget. Whether these are based
on assumptions or uncertainty, analyzing their impact throughout the projects timeline further reduces the risk of
failure.

Project Scope Step 6:

6. Identify necessary changes

It is always best to avoid reworking the scope of your project, as it means investing in more time, money and
resources. However, at times these changes are inevitable and necessary.Limit changes by taking on the
perspectives of customers, stakeholders, and employees involved in the project. This minimizes disagreements
later on.
 Experiment No 2
Select relevant process model to define activities and related tasks set for the assigned project.

I Practical Significance

A software process model is a simplified representation of a software process. Each model represents a process
from a specific perspective. Some methodologies are sometimes known as software development life cycle (SDLC)
methodologies, though this term could also be used more generally to refer to any methodology.

II Relevant Program Outcomes

All POs are listed.

III Relevant Course Outcomes

Understand the Software Life Cycle.

IV Practical Learning Outcomes

Describes the sequence of phases for the entire lifetime of a product.

V Practical Skills

Learn Selection criteria for software Process Model.

VI Relevant Affective domain related Outcomes

a) Development of the product

b) Planning and organizing the project
c) Tracking and running the project

VII Minimum Theoretical Background

A software process model is a simplified representation of a software process. Each model represents a
process from a specific perspective. These generic models are abstractions of the process that can be used to
explain different approaches to the software development. A software process model represents the order in
which the activities of software development will be undertaken. It describes the sequence in which the phases of
the software lifecycle will be performed.

The software development models are the various processes or methodologies that are being selected
for the development of the project depending on the project’s aims and goals. There are many development life
cycle models that have been developed in order to achieve different required objectives. The models specify the
various stages of the process and the order in which they are carried out. The selection of model has very high
impact on the testing that is carried out. It will define the
what, where and when of our planned testing, influence regression testing and largely determines which test
techniques to use.

VIII Resources required

Sr No Instrument Specification Quantity Remarks

Any Desktop PC
1 Computer System with attached 10 No. Whichever is available
HardDisk

IX Procedure

1. Learn the about Software Process Models.

2. Assess the needs of Stakeholders
3. Define activities and related tasks set for the project.
4. Define the selection criteria or arguments that use to select Software Process Models.
5. Decide which criteria fit for software Process Model.
X Precautions

1. Change the requirement carefully.

2. Save changes if required under the guidance of teacher.
XI Description

Choosing right model for developing of the software product or application is very important. Based on the
model the development and testing processes are carried out. Different companies based on the software
application or product, they select the type of development model whichever suits to their application. But these
days in market the ‘Agile Methodology‘ is the most used model.

Waterfall Model

It’s useful when the requirements are clear, or following a very structured process as in critical systems
which needs a detailed, precise, and accurate documents describes the system to be produced.

Not good when requirements are ambiguous, and doesn’t support frequent interaction with the
customers for feedback and proposing changes. It’s not suitable for large projects that might take long time to
be developed and delivered.

Prototype Model

This is very useful when requirements aren’t clear, and the interactions with the customer and
experimenting an initial version of the software results in high satisfaction and a clearance of what to be
implemented.
 It’s downsides are, good tools need to be acquired for quick development (like coding) in order to
complete a prototype. In addition, the costs for for training the development team on prototyping may be
high.

Incremental & Iterative Model

They’re suited for large projects, less expensive to the change of requirements as they support customer
interactions with each increment. Initial versions of the software are produced early, which facilitates
customer evaluation and feedback.

They don’t fit into small projects, or projects that waterfall are best suited for; A structured process with a
detailed, and accurate description of the system.

Spiral Model

It’s good for high risky or large projects where the requirements are ambiguous. The risks might be due to
cost, schedule, performance, user interfaces, etc.

Risk analysis requires highly specific expertise, and project’s success is highly dependent on the risk
analysis phase. It doesn’t work well for smaller projects.

Agile Model

It suits small-medium size project, with rapidly changes in the requirements as customer is involved
during each phase.

Very limited planning is required to get started with the project. It helps the company in saving time and
money (as result of customer physical interaction in each phase). The daily meetings make it possible to
measure productivity.

Difficult to scale up to large projects where documentation is essential. A highly skilled team is also needed. If
team members aren’t committed, the project will either never complete or fail. And there’s always a limitation
in time, like in increments, meetings, etc.
 Experiment No 3
Gather application specific requirements for assimilate into RE (Requirement Engineering)
model.

I Practical Significance

Requirement Engineering is the process of defining, documenting and maintaining the requirements. It is a
process of gathering and defining service provided by the system.. It is a common role in systems engineering and
software engineering.

II Relevant Program Outcomes

All POs are listed.

III Relevant Course Outcomes

Apply the principles of software engineering for the given problem.

IV Practical Learning Outcomes

Choose the relevant ‘Requirements Engineering’ steps in the given problem.

V Practical Skills
Learn Requirements Engineering for software Process Model.

VI Relevant Affective domain related Outcomes

a) Functionalities of the product

b) Planning and organizing the project
c) Tracking and running the project

VII Minimum Theoretical Background

The process to gather the software requirements from client, analyze and document them is known as requirement
engineering.The goal of requirement engineering is to develop and maintain sophisticatedand descriptive ‘System
Requirements Specification’ document.

It is a four step process, which includes –

Feasibility Study

Requirement Gathering

Software Requirement SpecificationSoftware

Requirement Validation
VIII Resources required

Sr No Instrument Specification Quantity Remarks

Any Desktop PC
1 Computer System with attached 10 No. Whichever is available
HardDisk

IX Procedure

Step 1: Develop Requirements.

Step 2: Write and Document Requirements.Step

3: Check Completeness.

Step 4: Analyze, Refine, and Decompose Requirements.Step 5:

Validate Requirements.

Step 6: Manage Requirements.

X Precautions

1. Change the requirement carefully.

2. Save changes if required under the guidance of teacher.
XI Description

Requirement Gathering

If the feasibility report is positive towards undertaking the project, next phase starts with gathering requirements
from the user. Analysts and engineers communicate with the client and end-users to knowtheir ideas on what the
software should provide and which features they want the software to include.

Requirements Development fits into Step One of the Systems Engineering Process: Requirements Analysis. There
are six (6) basic requirements development steps and really don’t change depending on which model is used. All
models are similar in their approach; they just depict them differently graphically.

Below is a list of the basic six (6) steps of requirements development. Step 1:

Develop Requirements

The first step is to gather, analyze and develop requirements from the Concept of Operations (CONOPS ),
stakeholder needs, objectives and other external requirement. Once requirements are documented, they are
prioritized, de-conflicted, and validated with the stakeholders.
Step 2: Write and Document Requirements

The second step focuses on writing down the functional and performance requirements into the appropriate
requirements documents; Initial Capabilities Document (ICD), Capability Development Document (CDD), and
Capability Production Document (CPD). Requirements must be documented in order to establish a requirements
baseline to start building a system and manage any changes. Requirements can be developed using the Capability
Development Tracking and Manager (CDTM) tool for DoD programs.

Step 3: Check Completeness

The third step is to check that a complete set of requirements have been developed and documented that defines
all system functions that are needed to satisfy the stakeholder needs with their associated performance,
environmental, and other non-functional requirements. Requirement Tracing is a big tool in this step.

Step 4: Analyze, Refine, and Decompose Requirements

Requirements Analysis is the first major step in the Systems Engineering Process. This step examines each
requirement to see if it meets the characteristics of a good requirement. Each requirement is then decomposed
into a more refined set of requirements that are allocated to sub-systems and documentedin the Weapons System
Specification (WSS). Newly derived requirements are expected to emerge from this process, which continues until
all requirements are defined and analyzed.

Step 5: Validate Requirements

In step five each requirement must be verified and validated to ensure that these are the correct requirements.
This ensures that the requirements meet the overall objective of the system and all stakeholder needs.

Step 6: Manage Requirements

In step six the requirements have been accepted and a baseline is established by the stakeholders. Any changes to
the requirements are controlled using a Configuration Management process.

Next System Engineering Step: Functional Analysis and Allocation

Functional Analysis and Allocation is a top-down process of translating system level requirements which were just
developed into detailed functional and performance design criteria. The result of the process is a defined
architecture with allocated system requirements that are traceable to each system function.

Classification of requirements

Business requirements. These include high-level statements of goals, objectives, and needs.

Stakeholder requirements. The needs of discrete stakeholder groups are also specified to define what they expect
from a particular solution.
Solution requirements. Solution requirements describe the characteristics that a product must have tomeet the
needs of the stakeholders and the business itself.

Nonfunctional requirements describe the general characteristics of a system. They are also known as
quality attributes.

Functional requirements describe how a product must behave, what its features and functions.

Transition requirements. An additional group of requirements defines what is needed from anorganization
to successfully move from its current state to its desired state with the new product.

The Non-functional, Functional requirements for Hospital Patient Information Management System.

Functional Requirements

 Registration

SRS001 Add patients

The HPIMS shall allow front-desk staff to add new patients to the system.
SRS002 Assign ID
The HPIMS shall allow front-desk staff to give each patient a ID and add it to the patient’s record. This IDshall be used
by the patient throughout his/her stay in hospital.

 Check Out

SRS003 Delete Patient ID

The administrative staff in the ward shall be allowed to delete the ID of the patient from the systemwhen the
patient checks out.
SRS004 Add to beds-available list
The administrative staff in the ward shall be allowed to put the beds just evacuated in beds-available list.

 Report Generation

SRS005 Patient information

The HPIMS shall generate reports on patients about the following information: patient’s PHN, patient’sname, ward
name, bed number and the doctor’s name which was assigned.
SRS006 Bed Aavailability
The HPIMS shall generate reports on bed availability about the following information: ward name, bednumber,
occupied/unoccupied.
Database

SRS007 Patient Mandatory Information

Each patient shall have the following mandatory information: first name, last name, phone number,personal
health number, address, postal code, city, country, patient identification number.
SRS008 Update Patient Information
The HPIMS shall allow the user to update any of the patient’s information as described in SRS007.

Non-Functional Requirements

 Security

SRS012 Patient Identification

The system requires the patient to identify himself /herself using PHN

SRS013 Logon ID

Any user who uses the system shall have a Logon ID and Password.

SRS014 Modification

Any modification (insert, delete, update) for the Database shall be synchronized and done only by theadministrator in
the ward.

SRS015 Front Desk staff Rights

Front Desk staff shall be able to view all information in HPIMS, add new patients to HPIMS but shall not be able to
modify any information in it.

SRS016 Administrators' Rights

Administrators shall be able to view and modify all information in HPIMS.

 Performance Requirements

SRS017 Response Time

The system shall give responses in 1 second after checking the patient’s information.

SRS018 Capacity

The System must support 1000 people at a time.

SRS019 User-interface

The user-interface screen shall respond within 5 seconds.

SRS020 Conformity
The systems must conform to the Microsoft Accessibility guidelines

 Maintainability

SRS021 Back Up

The system shall provide the capability to back-up the Data

SRS022 Errors

The system shall keep a log of all the errors.

 Reliability

SRS023 Availability

The system shall be available all the time

 Experiment No 4
Prepare broad SRS (Software Requirements Software) for the above selected project.

I Practical Significance

A software requirements specification (SRS) is a document that captures complete description about how the
system is expected to perform. It is usually signed off at the end of requirements engineering phase. A good SRS
defines the how Software System will interact with all internal modules, hardware, communication with other
programs and human user interactions with wide range of real life scenarios.

II Relevant Program Outcomes

All POs are listed.

III Relevant Course Outcomes

Prepare software requirement specifications of project.

IV Practical Learning Outcomes

Detailed description of all aspects of the software to be built.

V Practical Skills

Learn software requirement specification document consistent of all necessary requirements required for project
development.

VI Relevant Affective domain related Outcomes

a) Consistent requirements
b) Verification of expected result
c) Testing environment
d) Security and Performance criteria
e) Deletion of irrelevant requirements
f) Freeze requirements

VII Minimum Theoretical Background

A software requirements specification (SRS) is a detailed description of a software system to be

developed with its functional and non-functional requirements. The SRS is developed based the agreement
between customer and contractors. It may include the use cases of how user is going to interact with software
system. The software requirement specification document consistent of all necessary requirements required for
project development. To develop the software system we should have clear understanding of Software system. To
achieve this we need to continuous communication with customers to gather all requirements.
 A good SRS defines the how Software System will interact with all internal modules, hardware,
communication with other programs and human user interactions with wide range of real li fe scenarios. Using the
Softwarerequirements specification (SRS) document on QA lead, managers creates test plan. It is very important
that testers must be cleared with every detail specified in this document in order to avoid faults in test cases and its
expected results.

VIII Resources required

Sr No Instrument Specification Quantity Remarks

Any Desktop PC
1 Computer System with attached 10 No. Whichever is available
HardDisk

IX Procedure

1. If your organization does not have a standard Software Requirements Specifications document
template, create one now
2. Meet with the subject matter experts/clients to gather the requirements.
3. Define the functions of the software.
4. Create use cases for the major sub-processes. For example, if you're designing an order entry
system, use cases would consist of creating a new order, modifying an existing order and a
customer order search.
5. Define the user interface.
6. Define any other interfaces such as hardware interfaces or other software system interfaces.
7. Define the process flow.
8. Determine any specific business rules.
9. Define the performance specification.
10. Create any diagrams needed to illustrate the process flowor elaborate on key requirements.
11. Compile the SRS document and have all necessary parties review or sign i t.
X Precautions

1. Change the requirement carefully.

2. Save changes if required under the guidance of teacher.

XI Description

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

1. Introduction
1.1. Purpose
1.2. Document Conventions
1.3. Intended Audience and Reading Suggestions
1.4. Project Scope
1.5. References
2. Overall Description
2.1 Product Perspective
2.2 Product Features
2.3 User Classes and Characteristics
2.4 Operating Environment
2.5 Design and Implementation Constraints
2.6 User Documentation
2.7 Assumptions and Dependencies
3. System Features
3.1 System Feature 1
3.2 System Feature 2 (and so on)
4. External Interface Requirements
4.1 User Interfaces
4.2 Hardware Interfaces
4.3 Software Interfaces
4.4 Communications Interfaces
5. Other Nonfunctional Requirements
5.1. Performance Requirements
5.2. Safety Requirements
5.3. Security Requirements
5.4. Software Quality Attributes
6. Other Requirements
Appendix A: Glossary
Appendix B: Analysis Models
Appendix C: Issues List
 Experiment No 5
Prepare the use-case and draw the use-case diagram using Software Modelling Tool.

I Practical Significance

A use case diagram is a dynamic or behavior diagram in UML. Use case diagrams model the functionality
of a system using actors and use cases. Use cases are a set of actions, services, and functions that the system
needs to perform.

II Relevant Program Outcomes

All POs are listed.

III Relevant Course Outcomes

Prepare use case diagram of project.

IV Practical Learning Outcomes

Detailed description of all aspects of the project to be built.

V Practical Skills
Learn use case diagrams: discovering actors and discovering use cases.

VI Minimum Theoretical Background

Use case diagrams are used to gather the requirements of a system including internal and external influences.
These requirements are mostly design requirements. Hence, when a system is analyzed to gather its
functionalities, use cases are prepared and actors are identified.

When the initial task is complete, use case diagrams are modelled to present the outside view. In brief,

the purposes of use case diagrams can be said to be as follows −

 Used to gather the requirements of a system.

 Used to get an outside view of a system.

 Identify the external and internal factors influencing the system.

 Show the interaction among the requirements are actors.

VII Resources required

Sr No Instrument Specification Quantity Remarks

Any Desktop PC
1 Computer System with attached 10 No. Whichever is available
HardDisk
2 Any UML Software - 1 No. -

VIII Procedure

1. Select Diagram > New from the application toolbar.

2. In the New Diagram window, select Use Case Diagram.
3. Click Next.
4. Enter the diagram name and description. The Location field enables you to select a model to
store the diagram.
5. Click OK.

IX Precautions

1. Change the requirement carefully.

2. Save changes if required under the guidance of teacher.

X Description

Use case diagrams are used to gather a usage requirement of a system. Depending on yourrequirement you can
use that data in different ways. Beloware few ways to use them.

To identify functions and how roles interact with them – The primary purpose of use case diagrams.

For a high-level view of the system – Especially useful when presenting to managers or stakeholders. You can
highlight the roles that interact with the system and the functionality provided by the system without going deep
into inner workings of the system.

To identify internal and external factors – This might sound simple but in large complex projects a
system can be identified as an external role in another use case.

Notations used in use case diagram are:

1. 1. Use case:

Use case is the description of set of sequences of actions. It is graphically represented as an ellipse andlabeled with
the name of the use case. Use case represents an action performed by a system.
Notation:
2. Actor:

An actor represents a coherent set of roles that users of use case can play while interacting with usecases. An actor
represents a role that a human, hardware device or another system plays when it communicates with the system.
It is represented with the following notation.
Notation:

3. Association:

An association is a connection between an actor and use case. It indicates that both are communicatingwith each
other. Association is represented with a solid line.
Notation:

4. Generalization:

Generalization is used to show the relationship between two use cases. In this relationship the child usecase
inherits the behavior and meaning of parent use case. It is represented with the solid line with a large hollow
triangle as an arrowhead. Arrow head indicates direction of generalization.
Notation:

5. Include Relationship:

An include relationship is the directed relationship between two use cases. Including a use case requiresforceful
execution of included use case.
Notation/example:
6. Extend Relationship:

It is a directed relationship between two use cases that specifies extra actions in a system. Extendrelationship
specifies optional behavior for extending use case.
Notation/example:
 Experiment No 6
Develop the activity diagram to represent flow from one activity to another for software
development.

I Practical Significance

An activity diagram is a special kind of a state chart diagram that shows the flow from activity to
activity within the system. Activity diagram addresses the dynamic view of a system.

II Relevant Program Outcomes

All POs are listed.

III Relevant Course Outcomes

Prepare activity diagram of project.

IV Practical Learning Outcomes

Detailed description of all aspects of the project to be built.

V Practical Skills
Deeper understanding of UML activity diagrams.

VI Minimum Theoretical Background

Use case diagrams are used to gather the requirements of a system including internal and external
influences. These requirements are mostly design requirements. Hence, when a system is analyzed to gather its
functionalities, use cases are prepared and actors are identified.

When the initial task is complete, use case diagrams are modelled to present the outside view. In brief,

the purposes of use case diagrams can be said to be as follows −

 Used to gather the requirements of a system.

 Used to get an outside view of a system.

 Identify the external and internal factors influencing the system.

 Show the interaction among the requirements are actors.

VII Resources required

Sr No Instrument Specification Quantity Remarks

Any Desktop PC
1 Computer System with attached 10 No. Whichever is available
HardDisk
2 Any UML Software - 1 No. -

VIII Procedure

1. Select Diagram > New from the application toolbar.

2. In the New Diagram window, select activity Diagram.
3. Click Next.
4. Enter the diagram name and description. The Location field enables you to select a model to
store the diagram.
5. Click OK.

IX Precautions

1. Change the requirement carefully.

2. Save changes if required under the guidance of teacher.

X Description

Activity diagrams illustrate the dynamic nature of a system by modeling the flow of control from activity to
activity. An activity represents an operation on some class in the system that results in a change in the state of the
system. Typically, activity diagrams are used to model workflow or business processes and internal operation.
Action states cannot be decomposed. Action states are atomic, meaning that events may occur, but the
work of an action state is not interrupted. The work of an action state as a special case of an activity case of an
activity state that cannot be further decomposed.
Notations used in activity diagram:
Fig: Activity diagram for Library Management System
 Experiment No 7
Develop data designs using DFDs (data flow diagram), Decision tables and E-R (entity –
relationship) diagram.

I Practical Significance

Data flow diagram is graphical representation of flow of data in an information system. It is capable of
depicting incoming data flow, outgoing data flow and stored data. The DFD does not mention anything about how
data flows through the system.

There is a prominent difference between DFD and Flowchart. The flowchart depicts flow of control in
program modules. DFDs depict flow of data in the system at various levels. DFD does not contain any control or
branch elements.

II Relevant Program Outcomes

All POs are listed.

III Relevant Course Outcomes

Prepare Data flow diagram, Decision tables and E-R (entity –relationship) of project.

IV Practical Learning Outcomes

Detailed description of all aspects of the project to be built.

V Practical Skills
Deeper understanding of System modeling:

 Data model: entity-relationship diagram (ERD).

 Functional model: data flow diagram (DFD).
 Decision Table.

VI Minimum Theoretical Background

A data flow diagram shows the way information flows through a process or system. It includes data inputs
and outputs, data stores, and the various sub processes the data moves through. DFDs are built using standardized
symbols and notation to describe various entities and their relationships.

Decision tables are very much helpful in test design technique – it helps testers to search the effects of
combinations of different inputs and other software states that must correctly implement business rules. A
decision table is basically an outstanding technique used in both testing and requirements management.
 An Entity Relationship (ER) Diagram is a type of flowchart that illustrates how “entities” such as people, objects
or concepts relate to each other within a system.

VII Resources required

Sr No Instrument Specification Quantity Remarks

Any Desktop PC
1 Computer System with attached 10 No. Whichever is available
HardDisk
2 Any UML Software - 1 No. -

VIII Procedure

1. Select Diagram > New from the application toolbar.

2. In the New Diagram window, select Data Flow Diagram.
3. Click Next.
4. Enter the diagram name and description. The Location field enables you to select a model to
store the diagram.
5. Click OK.

IX Precautions

1. Change the requirement carefully.

2. Save changes if required under the guidance of teacher.

X Description

Data Flow Diagrams are either Logical or Physical.

 Logical DFD - This type of DFD concentrates on the system process, and flow of data in the
system.For example in a Banking software system, how data is moved between different
entities.
 Physical DFD - This type of DFD shows how the data flow is actually implemented in the system.
It is more specific and close to the implementation.
DFD Components
DFD can represent Source, destination, storage and flow of data using the following set of components
-
  Entities - Entities are source and destination of information data. Entities are represented by a
rectangles with their respective names.
 Process - Activities and action taken on the data are represented by Circle or Round-edged
rectangles.
 Data Storage - There are two variants of data storage - it can either be represented as a
rectangle with absence of both smaller sides or as an open-sided rectangle with onlyone side
missing.
 Data Flow - Movement of data is shown by pointed arrows. Data movement is shown from the
base of arrow as its source towards head of the arrow as destination.
Levels of DFD

 Level 0 - Highest abstraction level DFD is known as Level 0 DFD, which depicts the entire
information system as one diagram concealing all the underlying details. Level 0 DFDs are also
known as context level DFDs.

 Level 1 - The Level 0 DFD is broken down into more specific, Level 1 DFD. Level 1 DFD depicts
basic modules in the system and flow of data among various modules. Level 1 DFD also
mentions basic processes and sources of information.
  Level 2 - At this level, DFD shows how data flows inside the modules mentioned in Level 1.

Higher level DFDs can be transformed into more specific lower level DFDs with deeper level of understanding
unless the desired level of specification is achieved.

Decision Tables
A Decision table represents conditions and the respective actions to be taken to address them, in a structured
tabular format.

It is a powerful tool to debug and prevent errors. It helps group similar information into a single tableand then by
combining tables it delivers easy and convenient decision-making.

Creating Decision Table

To create the decision table, the developer must follow basic four steps:

 Identify all possible conditions to be addressed

 Determine actions for all identified conditions
 Create Maximum possible rules
 Define action for each rule
Decision Tables should be verified by end-users and can lately be simplified by eliminating duplicate rules and
actions.

 Example 1: How to make Decision Table for Login Screen

 Let's create a decision table for a login screen.
 The condition is simple if the user provides correct username and password the user will be
redirected to the homepage. If any of the input is wrong, an error message will be displayed.

 Conditions  Rule 1  Rule 2  Rule 3  Rule 4

 Username (T/F)  F  T  F  T

 Password (T/F)  F  F  T  T

 Output (E/H)  E  E  E  H

 Legend:

 T – Correct username/password
 F – Wrong username/password
 E – Error message is displayed
 H – Home screen is displayed
Interpretation:

Case 1 – Username and password both were wrong. The user is shown an error message.

Case 2 – Username was correct, but the password was wrong. The user is shown an error message. Case 3 –

Username was wrong, but the password was correct. The user is shown an error message. Case 4 –

Username and password both were correct, and the user navigated to homepage

While converting this to test case, can create 2 scenarios ,

Enter correct username and correct password and click on login, and the expected result will be the user should be
navigated to homepage

And one from the below scenario

  Enter wrong username and wrong password and click on login, and the expected result will be
the user should get an error message
 Enter correct username and wrong password and click on login, and the expected result will be
the user should get an error message
 Enter wrong username and correct password and click on login, and the expected result will be
the user should get an error message

Entity-Relationship Model
Entity-Relationship model is a type of database model based on the notion of real world entities and relationship
among them. We can map real world scenario onto ER database model. ER Model creates a set of entities with
their attributes, a set of constraints and relation among them.

ER Model is best used for the conceptual design of database. ER Model can be represented as follows :

 Entity - An entity in ER Model is a real world being, which has some properties called attributes.
Every attribute is defined by its corresponding set of values, called domain.

For example, Consider a school database. Here, a student is an entity. Student has various attributes like
name, id, age and class etc.

 Relationship - The logical association among entities is called relationship. Relationships are
mapped with entities in various ways. Mapping cardinalities define the number of associations
between two entities.

Mapping cardinalities:

o one to one
o one to many
o many to one
o many to many
 Experiment No 8

Draw class diagram, Sequence diagram, Collaboration diagram, State Transition diagram
for the assigned project.

I Practical Significance

Class diagram describes the attributes and operations of a class and also the constraints imposed on the system.
Sequence diagrams describe how and in what order the objects in a system function. Collaboration diagrams are
used to describe the structural organization of the objects taking part in the interaction. In state transition
diagram we represent that what actions are leads to change the state of the object.

II Relevant Program Outcomes

All POs are listed.

III Relevant Course Outcomes

Prepare class diagram, Sequence diagram, Collaboration diagram, State Transition diagram ofproject.

IV Practical Learning Outcomes

Detailed description of all aspects of the project to be built.

V Practical Skills
Deeper understanding of System modeling: class diagram, Sequence diagram, Collaboration diagram,State
Transition diagram.

VI Minimum Theoretical Background

Behavioral diagrams basically capture the dynamic aspect of a system. Dynamic aspect can befurther
described as the changing/moving parts of a system.

UML has the following five types of behavioral diagrams −Use case

diagram

Sequence diagram

Collaboration diagramState

chart diagram Activity

diagram
VII Resources required

Sr No Instrument Specification Quantity Remarks

Any Desktop PC
1 Computer System with attached 10 No. Whichever is available
HardDisk
2 Any UML Software - 1 No. -

VIII Procedure

1. Select Diagram > New from the application toolbar.

2. In the New Diagram window, select the Diagram.
3. Click Next.
4. Enter the diagram name and description. The Location field enables you to select a model to
store the diagram.
5. Click OK.

IX Precautions

1. Change the requirement carefully.

2. Save changes if required under the guidance of teacher.

X Description

Class diagrams describe the static structure of a system or how it is structured rather than how it behaves.
These diagrams contain the following element with their symbol.
1) Class– It represents entity with common characteristics or features. These features can include
attributes, operations and associations.
The symbol used to denote class is rectangle with three compartments.
First contains the name of the class, second contains the attributes of the class and third contains the
operations of that class.
Notation:
2) Association – It represents relationships that relate to two or more other classes where the
relationships have common characteristics.
The symbol used to denote association is solid line.
Notation:

3) Multiplicity -Multiplicity in an association specifies how many objects participate in a relationship.

Multiplicity decides the number of related objects. Multiplicity is generally explained as “one” or“many,”
but in general it is a subset of the non-negative integers.
Indicator and Meaning
0..1 Zero or one
1 One only
0..* Zero or more
1..* One or more
n Only n (where n > 1)
0..n Zero to n (where n > 1)
1..n One to n where n > 1)
Notation:
4) Association Class: An association class is an attribute of an association. It is also
a class.
Notation:

5) Generalization: It is a relationship between a class (superclass) and its derived classes (subclasses).

Notation:

6) Qualified association: It uses the special attribute qualifier which reduces the effective multiplicity of
an association.
Notation:
 Fig: Class Diagram for Hotel Management System

Notations used to draw sequence diagram.

1) Object: Class roles describe the way an object will behave in context. Use the UML object
symbol to illustrate class roles, but don't list object attributes.

2) Activation or Execution Occurrence: Activation boxes represent the time an object needs to
complete a task. When an object is busy executing a process or waiting for a reply message, use
a thin gray rectangle placed vertically on its lifeline.
3) Messages: Messages are arrows that represent communication between objects. Use half-
arrowed lines to represent asynchronous messages. Asynchronous messages are sent f rom an
object that will not wait for a response from the receiver before continuing its tasks.

4) Lifelines: Lifelines are vertical dashed lines that indicate the object's presence over time.

5) Destroying Objects: Objects can be terminated early using an arrow labeled "<< destroy >>"
that points to an X. This object is removed from memory. When that object's lifeline ends, you
can place an X at the end of its lifeline to denote a destruction occurrence.
6) Loops: A repetition or loop within a sequence diagram is depicted as a rectangle. Place the
condition for exiting the loop at the bottom left corner in square brackets [ ].
 Fig: sequence diagram for hotel management system

A collaboration Diagram is an interaction diagram which emphasizes the structural organization of the objects that
send and receive messages.

Collaboration Diagram Notations:

Objects are model elements that represent instances of a class or of classes.

Multi-object represents a set of lifeline instances.

Association role is optional and suppressible.

Delegation is like inheritance done manually through object composition.

Link to self is used to link the bjects that fulfill more than one role.

Constraint is an extension mechanism that enables you to refine the semantics of a UML modelelement.

Fig : Collaboration diagram for Online Hospital ManagementState

Transition diagram
Statechart diagrams are used to model the states and also the events operating on the system.
When implementing a system, it is very important to clarify different states of an object
during its life time and Statechart diagrams are used for this purpose. When these states andevents are
identified, they are used to model it and these models are used during the implementation of the system.
Notations :
State defines current condition of an event or activity. State diagram is often used to describestate
changes triggered by events.

Start state symbol signals the first step of a process.

End state symbol stands for the result of a process.

Transition takes operation from one state to another and represents the response to a particular event. A
single transition comes out of each state or activity, connecting it to the nextstate or activity.

Decision were introduced in UML to support conditionals in activities.

History refers to the development of object-oriented methods and notation.

Constraint is an extension mechanism that enables you to refine the semantics of a UML modelelement.

Note contains comments or textual information.

Fig: State Diagram for online reservation system
 Experiment No 9
Write test cases to validate requirements of assigned project from SRS document.

I Practical Significance

A test case is a specification of the inputs, execution conditions, testing procedure, and expected results
that define a single test to be executed to achieve a particular software testing objective, such as to exercise a
particular program path or to verify compliance with a specific requirement.

II Relevant Program Outcomes

All POs are listed.

III Relevant Course Outcomes

Study SRS document and designing test cases.

IV Practical Learning Outcomes

Detailed description of all aspects of the project to be built with test case design.

V Practical Skills
Deeper understanding of System Requirement Specification of a software system, test cases formulationstrategy.

VI Minimum Theoretical Background

A Test Case is defined as a set of actions executed to verify a particular feature or functionality of the
software application. A test case is an indispensable component of the Software Testing LifeCycle that helps
validate the AUT (Application Under Test).

Test scenarios are rather vague and cover a wide range of possibilities. Testing is all about being very
specific.

VII Resources required

Sr No Instrument Specification Quantity Remarks

Any Desktop PC
1 Computer System with attached 10 No. Whichever is available
HardDisk
2 Any UML Software - 1 No. -
VIII Procedure

1. Detailed study of the System under test

2. Written in simple language
3. Use Test case template

IX Precautions

1. Change the requirement carefully.

2. Save changes if required under the guidance of teacher.

X Description

Test case template

It looks like:

i) Test Case ID: This field is defined by what type of system we are testing. Standard rules are as follows:
 If we are making test case for a general application which doesn’t belong to any specific module then
ID would start as TC001.
 If we are making test cases for a module specific system then ID would start from MC001.
 If test case has more than one expected result then we make it as version number wise. E.g. TC001.1,
TC001.2 etc. All these test cases are sub part of TC001.

ii) Test Case Name: This filed can contain

 Name of the feature you are testing
 Requirement number from the specifications
 Name of a particular Button or input box
 Requirement name as classified in client’s document
The main advantage of maintaining this field is, if a requirement gets changed in future then we can easily estimate
how many test cases that change will affect and we change/remove the corresponding test cases accordingly.

iii) Description: This field has the summary what respective test case is going to do. It explains what
attribute is under test and under what condition. E.g. If a text box is under provigil onlinetest, which
allows only number and alphabets then description can be written as “Random special characters (@, #,
%,$,^,*) are entered”, if we want to test a negative scenario.

iv) Pre-Conditions: when the system needs to be in a particular base state for the function to be tested,
these pre conditions should be defined clearly.
Pre-conditions could be:
 A certain page that a user needs to be on
 A certain data that should be in the system
 A certain action to be performed before “execution steps” can be executed on that particular
system.
Pre-conditions should be satisfied before the test case execution starts.

v) Execution steps: These are the steps to be performed on the system under test to get the desired
results. Steps must be defined clearly and must be accurate. They are written and executed number
wise.

vi) Expected Results: These are the desired outcomes from the execution steps performed. Expected
results should be clearly defined for each step. It specifies what the specification or client expects from
that particular action.

vii) Actual result: This field has the actual outcomes after the execution steps were performed on the
system under test. If the results match with the expected ones then we can just write “As expected”,
otherwise we need to mentioned the exact result observed.

viii) Status: This field can have following values based on the actual result we got, they are:

 “Passed” – The expected and actual results match

 “Failed”- The actual result and expected result do not match
 “Not tested”- The test case has not been executed
 “Not Applicable”-The test case does not apply to the feature any more since the requirement
changed or modified
 “Cannot be tested” – This may be because precondition is not met. There could be a defect in one of
the steps leading up to the function under test.

ix) Comments: This column is for additional information. So for e.g. if status is set to “cannot be tested”
then tester can give the reason in this column.

Fig: sample test case to login form of Twitter social site.

 Experiment No 10
Identify risks involved in the project and prepare RMMM (Risk Management, Mitigation and
Monitoring) plan.

I Practical Significance

A risk management strategy can be defined as a software project plan or the risk
management steps. It can be organized into a separate Risk Mitigation, Monitoring and
Management Plan. The RMMM plan documents all work performed as part of risk analysis and are
used by the project manager as part of the overall project plan. Risk Management involves to assess
risks that are likely to affect performance and quality of project.

II Relevant Program Outcomes

All POs are listed.

III Relevant Course Outcomes

Prepare RMMM (Risk Management, Mitigation and Monitoring) plan diagram of project.

IV Practical Learning Outcomes

Detailed descriptions of all aspects of the project to be understand.

V Practical Skills
Deeper understanding of risk mitigation, monitoring and management plan is to identify as manypotential

risks as possible.

VI Minimum Theoretical Background

Risk always involves two characteristics:

Uncertainty - The risk may or may not happen. There are no 100% probable risks.Loss - If

a risk becomes a reality, unwanted consequences or losses will occur.

• The goal of the risk mitigation, monitoring and management plan is to identify as many potential risks
as possible. The project will then be analyzed to determine any project-specific risks.

• When all risks have been identified, they will then be evaluated to determine their probability of
occurrence. Plans will then be made to avoid each risk, to track each risk to determine if it is more or
less likely to occur, and to plan for those risks should they occur.

• It is the organization’s responsibility to perform risk mitigation, monitoring, and management in order
to produce a quality product.
• The quicker the risks can be identified and avoided, the smaller the chances of having to face that
particular risk’s consequence. The fewer consequences suffered as a result of good RMMM plan, the
better the product and the smoother the development process.

VII Resources required

Sr No Instrument Specification Quantity Remarks

Any Desktop PC
1 Computer System with attached 10 No. Whichever is available
HardDisk
2 Any UML Software - 1 No. -

VIII Procedure

To assist the project team in developing a strategy for dealing with risk. An effective
strategy must consider three issues: risk avoidance, risk monitoring, and risk management and
contingency planning. If a software team adopts a proactive approach to risk, avoidance is always
the best strategy. This is achieved by developing a plan for risk mitigation.

Risk mitigation:

To mitigate this risk, you would develop a strategy for reducing turnover. Among the possible steps tobe taken
are:

• Meet with current staff to determine causes for turnover (e.g., poor working conditions, low pay, and
competitive job market).

• Mitigate those causes that are under your control before the project starts.

• Once the project commences, assume turnover will occur and develop techniques to ensure continuity
when people leave.

• Organize project teams so that information about each development activity is widely dispersed.

• Define work product standards and establish mechanisms to be sure that all models and documents
are developed in a timely manner.

• Conduct peer reviews of all work (so that more than one person is ―up to speed ).

• Assign a backup staff member for every critical technologist.

Risk avoidance:

When a lose-lose strategy is likely, the team can opt to eliminate the risk is an example of a riskavoidance strategy
is the team opting not to develop a product or a particularly risky feature.
Risk protection:

The organization can buy insurance to cover any financial loss should the risk become a reality.
Alternately, a team can employ fault tolerance strategies, such as parallel processors, to provide reliability
insurance.

Risk planning and risk mitigation actions often come with an associated cost. The team must do a
cost/benefit analysis to decide whether the benefits accrued by the risk management steps outweigh the costs
associated with implementing them. This calculation can involve the calculation of risk leverage.

Risk Leverage = (risk exposure before reduction – risk exposure after

reduction)/cost of risk reduction.

If risk leverage value, rl, is ≤1, clearly the benefit of applying risk reduction is not worth its cost. If rl is
only slightly > 1, still the benefit is very questionable, because these computations are based on probabilistic
estimates and not on actual data. Therefore, rl is usually multiplied by a risk discount factor ρ< 1. If ρ rl > 1, then
the benefit of applying risk reduction is considered worth its cost. If the discounted leveraged valued is not high
enough to justify the action, the team should look for other, less costly or more effective, reduction techniques.

RISK MONITORING:

As the project proceeds, risk-monitoring activities commence. The project manager

monitors factors that may provide an indication of whether the risk is becoming more or less likely.
In the case of high staff turnover, the general attitude of team members based on project
pressures, the degree to which the team has jelled, interpersonal relationships among team
members, potential problems with compensation and benefits, and the availability of jobs within
the company and outside it are all monitored.

RISK MANAGEMENT:

In addition to monitoring these factors, a project manager should monitor the effectiveness
of risk mitigation steps. Risk management and contingency planning assumes that mitigation efforts
have failed and that the risk has become a reality. Risk management and contingency planning
assumes that mitigation efforts have failed and that the risk has become a reality. It is important to
note that risk mitigation, monitoring, and management (RMMM) steps incur additional project cost.
For example, spending the time to back-up every critical technologist costs money. Part of risk
management, therefore, is to evaluate when the benefits accrued by the RMMM steps are
outweighed by the costs associated with implementing them.

IX Precautions

1. Change the requirement carefully.

2. Save changes if required under the guidance of teacher.
X Description

The RMMM plan documents all work performed as part of risk analysis and is used by the
project manager as part of the overall project plan. Some software teams do not develop a
formal RMMM document. Rather, each risk is documented individually using a risk
information sheet (RIS). RIS is maintained using a database system, so that creation and
information entry, priority ordering, searches, and other analysis may be accomplished
easily. Once RMMM has been documented and the project has begun, risk mitigation and
monitoring steps commence.
 Experiment No 11
Evaluate size of the project using Function point metric for the assigned project.

I Practical Significance

Function points are one of the most widely used measures of software size. The basis of
function points is that the "functionality” of the system that is; what the system performs, is the
measure of the system size. In function points, the system functionally is calculated in terms of the
number of function it implements, the number of inputs, the number of output etc.

II Relevant Program Outcomes

All POs are listed.

III Relevant Course Outcomes

Calculate the size of the project using Function point metric for the assigned project.

IV Practical Learning Outcomes

Detailed descriptions of all aspects of the project to be understand.

V Practical Skills
Deeper understanding of various measures is used in project size estimation.

VI Minimum Theoretical Background

The initial design criteria for function points were to provide a mechanism that both software developers and
users could utilize to define functional requirements. It was determined that the best way to gain an
understanding of the users' needs was to approach their problem from the perspective of how they view the
results an automated system produces. Therefore, one of the primary goals of Function Point Analysis is to
evaluate a system's capabilities from a user's point of view. To achieve this goal, the analysis is based upon the
various ways users interact with computerized systems. From a user's perspective a system assists them in doing
their job by providing five basic functions.
Two of these address the data requirements of an end user and are referred to as Data Functions. The
remaining three addresses the user's need to access data and are referred to as Transactional Functions.

The Five Components of Function Points

Data Functions

 Internal Logical Files

 External Interface Files
 Transactional Functions

 External Inputs
 External Outputs
 External Inquiries

Internal Logical Files - The first data function allows users to utilize data they are responsible for maintaining.
For example, a pilot may enter navigational data through a display in the cockpit prior to departure. The data is
stored in a file for use and can be modified during the mission. Therefore the pilot is responsible for maintaining
the file that contains the navigational information. Logical groupings of data in a system, maintained by an end
user, are referred to as Internal Logical Files (ILF).

External Interface Files - The second Data Function a system provides an end user is also related to logical
groupings of data. In this case the user is not responsible for maintaining the data. The data resides in another
system and is maintained by another user or system. The user of the system being counted requires this data for
reference purposes only. For example, it may be necessary for a pilot to reference position data from a satellite or
ground-based facility during flight. The pilot does not have the responsibility for updating data at these sites but
must reference it during the flight. Groupings of data from another system that are used only for reference
purposes are defined as External Interface Files (EIF).

The remaining functions address the user's capability to access the data contained in ILFs and EIFs. This capability
includes maintaining, inquiring and outputting of data. These are referred to as Transactional Functions.

External Input - The first Transactional Function allows a user to maintain Internal Logical Files (ILFs) through the
ability to add, change and delete the data. For example, a pilot can add, change and delete navigational
information prior to and during the mission.

In this case the pilot is utilizing a transaction referred to as an External Input (EI). An External Input gives the user
the capability to maintain the data in ILF's through adding, changing and deleting its contents.

External Output - The next Transactional Function gives the user the ability to produce outputs. For example a
pilot has the ability to separately display ground speed, true air speed and calibrated air speed. The results
displayed are derived using data that is maintained and data that is referenced. In function point terminology the
resulting display is called an External Output (EO).

External Inquiries - The final capability provided to users through a computerized system addresses the
requirement to select and display specific data from files. To accomplish this a user inputs selection information
that is used to retrieve data that meets the specific criteria. In this situation there is no manipulation of the data. It
is a direct retrieval of information contained on the files. For example if a pilot displays terrain clearance data that
was previously set, the resulting output is the direct retrieval of stored information. These transactions are referred
to as External Inquiries (EQ).
FPs of an application is found out by counting the number and types of functions used in theapplications.
Various functions used in an application can be put under five types as shown in Table.

Types of FP Attributes

VII Resources required

Sr No Instrument Specification Quantity Remarks

Any Desktop PC
1 Computer System with attached 10 No. Whichever is available
HardDisk

VIII Procedure

In Function Point Analysis method, the number and type of functions supported by the softwareare
utilized to find FPC(function point count). The steps in function point analysis are:

1. Count the number of functions of each proposed type.

2. Compute the Unadjusted Function Points(UFP).
3. Find Total Degree of Influence(TDI).
4. Compute Value Adjustment Factor(VAF).
5. Find the Function Point Count(FPC).

IX Precautions

1. Change the requirement carefully.

2. Save changes if required under the guidance of teacher.
X Description

The functional complexities are multiplied with the corresponding weights against each function and thevalues are added
up to determine the UFP (Unadjusted Function Point) of the subsystem.

Fig: Computing FPs

The weighing factor will be simple, average or complex for a measurement parameter type. The

Function Point (FP) is thus calculated with the following formula

FP = Count-total * [0.65 + 0.01 * S(Fi ) ]

where Count-total is obtained from the above Table.

and

S(Fi ) is the sum of all 14 questionnaires and show the complexity adjustment value/ factor-CAF (where iranges
from 1 to 14). Usually, a student is provided with the value of S (Fi ).

Also note that S (Fi ) ranges from 0 to 70,

i.e., 0 <= S (Fi) <=70.

Based on the FP measure of software many other metrics can be computed:

(a) Cost per function = cost/ productivity

(b) Cost=$/FP.

(c) Quality=Number of Faults/FP

(d) Documentation=Pages of documentation/FP

(e) Productivity = FP/PM (effort is measured in person-months).

 Experiment No 12

Estimate cost of the project using COCOMO (Constructive Cost Model) / COCOMO II approach for theassigned project.

I Practical Significance

COCOMO (Constructive Cost Model) is a regression model based on LOC, i.e number of Lines
of Code. It is a procedural cost estimate model for software projects and often used as a process of
reliably predicting the various parameters associated with making a project such as size, effort, cost,
time and quality. It was proposed by Barry Boehm in 1970 and is based on the study of 63 projects,
which make it one of the best-documented models.

According to Boehm, software cost estimation should be done through three stages: Basic
COCOMO, Intermediate COCOMO, and Complete COCOMO. Each of the models initially estimates
efforts based on the total estimated KLOC.

II Relevant Program Outcomes

All POs are listed.

III Relevant Course Outcomes

Calculate the size of the project using COCOMO approach for the assigned project.

IV Practical Learning Outcomes

Detailed descriptions of all aspects of the project to be understand.

V Practical Skills
Deeper understanding of various measures is used in project size estimation.

VI Minimum Theoretical Background

There are also different "flavors" of COCOMO in use for business estimates. For example, in a model known as
"detailed COCOMO," a step-by-step process includes attention to planning and requirements, system design, detail
design, module code and testing, integration and testing, and estimation. In general, COCOMO provides a helpful
framework to try to determine the cost and scope of a software project.
 The key parameters which define the quality of any software products, which are also anoutcome of the
Cocomo are primarily Effort & Schedule:

Effort: Amount of labor that will be required to complete a task. It is measured in person-months units.

Schedule: Simply means the amount of time required for the completion of the job, which is, of course,
proportional to the effort put. It is measured in the units of time such as weeks, months.

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

The concept of organic, semidetached, and embedded systems are described below.

Organic: A development project is said to be of organic type, if The project deals with developing a well
understood application The development team is small. The team members have prior experience in working with
similar types of projects.

Semidetached: A development project can be categorized as semidetached type, if The team consists of some
experienced as well as inexperienced staff Team members may have some experience on the type of system to be
developed.

Embedded: Embedded type of development project are those, which Aims to develop a software strongly related
to machine hardware Team size is usually large.

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

VII Resources required

Sr No Instrument Specification Quantity Remarks

Any Desktop PC
1 Computer System with attached 10 No. Whichever is available
HardDisk
http://csse.usc.edu/tools/cocomoii.php or
http://csse.usc.edu/csse/research/COCOMOII/cocomo2000.0/CII2000.exe use for COCOMO II -
Constructive Cost Model.

VIII Procedure

a. Read the exercise enclosed scenario. This scenario describes the software product you are
estimating, your work setting and much of the pertinent information required for
establishing the model parameters.

b. You should initially set the parameters based solely on the information provided in the
scenario. In cases where the scenario description provides no direct information regarding a
particular factor, you should assume that the nominal setting is appropriate. However, after
you have completed the exercise described below, you are encouraged to adjust other
factors based on your experience or curiosity. You will then be in a position to observe their
impact on effort and schedule.

IX Precautions

1. Change the requirement carefully.

2. Save changes if required under the guidance of teacher.

X Description

Estimation of Effort: Calculations –

Basic Model –

E = a * (KLOC)b

D= c*(E)d

P=E/D

Where,

E- Effort applied in person-months

D – Development time in duration-in-month
P- Total number of persons required to accomplish the project
KLOC ... kilo lines of code
a, b, c, d depend on the project type
The above formula is used for the cost estimation of for the basic COCOMO model, and also is used in the
subsequent models. The constant values a and b for the Basic Model for the different categories of system:

Intermediate Model –
The effort calculation:

E = a * (KLOC)b * EAF (person-months)D=

c*(E)d

P=E/D

Where,

E- Effort applied in person-months

D – Development time in duration-in-month (use c and d coefficient from basic model)P- Total

number of persons required to accomplish the project

KLOC ... kilo lines of code

a, b, c, d depend on the project type

Detailed Model –

Detailed COCOMO incorporates all characteristics of the intermediate version with an assessment of thecost
driver’s impact on each step of the software engineering process.

The Four phases of detailed COCOMO are:

1. Requirements Planning and Product Design

2. Detailed design
3. Code and unit test
4. Integration and test

Effort(E) = ab * (KLOC)b (inb Person-months)

DevelopmentTime(D) = cb * (E) d (in month) Average

b

staff size(SS) = E/D (in Person) Productivity(P) = KLOC / E

(in KLOC/Person-month)
 Experiment No 13
Use CPM (critical path method)/PERT (Programme evaluation and review technique) forscheduling the
assigned project.

I Practical Significance

PERT (Program Evaluation and Review Technique) and CPM (Critical Path Method) are two closely - related
operations research techniques that use networks to coordinate activities, develop schedules, and monitor
progress of projects. PERT and CPM were developed independently in the 1950s. While the original versions
differed in some important ways, the two techniques had much in common. Over time, the techniques have
merged and, for the most part, the names are used interchangeably or combined in a single acronym,
PERT/CPM.

II Relevant Program Outcomes

All POs are listed.

III Relevant Course Outcomes

Develop Time-line chart and project table using PERT or CPM project scheduling methods.

IV Practical Learning Outcomes

Detailed description of all aspects of the project to be built.

V Practical Skills

Deeper understanding of PERT or CPM project scheduling methods.

VI Minimum Theoretical Background

The program evaluation review technique (PERT) and critical path method (CPM) are tools useful in
planning, scheduling, and managing complex projects. PERT/CPM (sometimes referred to as network analysis)
provides a focus around which managers and project planners can brainstorm. It is useful for evaluating the
performance of individuals and teams. The key concept in CPM/PERT is that a small set of activities, which make up
the longest path through the activity network, control the entire project.Ifthese critical activities can be identified
and assigned to the responsible persons, management resources can be optimally used by concentrating on the
few activities that determine the fate of the entire project. Noncritical activities can be replanned or rescheduled,
and resources for them can be reallocatedflexibly, without affecting the whole project.

There are many variations of CPM/PERT which have been useful in planning costs and scheduling
manpower and machine time. CPM/PERT can answer the following important questions:

1) How long will the entire project take? What are the risks involved?
 2) Which are the critical activities or tasks in the project which could delay everything if they are
not completed on time?

3) Is the project on schedule, behind schedule, or ahead of schedule?

4) If the project must be finished earlier than planned, what is the best way to do this at the least
cost?

VII Resources required

Sr No Instrument Specification Quantity Remarks

Any Desktop PC
1 Computer System with attached 10 No. Whichever is available
HardDisk

VIII Procedure

Six steps of PERT and CPM:

1. Define the project and prepare WBS

2. Develop relationships

3. Draw the network connecting all activities

4. Assign time and cost estimated

5. Compute the longest time path through the network = critical path

6. Use network to help plan, schedule, monitor, and control the project

IX Precautions

1. Change the requirement carefully.

2. Save changes if required under the guidance of teacher.

X Description

PERT-CPM Method

• Task interdependency represents the dependency relationship or the

sequence of tasks between a pair of activities.

• An activity network diagram (AND) that shows the task interdependency in the project.
• The activity network diagram is designed using

– Project Evaluation and Review Technique (PERT)

– Critical Path Method (CPM).

• PERT is a network-based representation of tasks or activities to

determine the task interdependency.

• It represents the precedence or parallel relationships among the tasks in a project.

• A PERT diagram has the following construction rules:

• Each task or activity is represented as a node in boxes.

• Arrow shows the dependencies between tasks or activities.

• There is a start node, which has only an outgoing arrow, and an end
node, which has only incoming arrows.

• An arrow pointing to a node comes from its predecessor activity,

which must be completed before a task can begin.

• Arrows pointing out of a task box go to its successor tasks, which

cannot start until at least this task is complete.

• For example, T1 is the predecessor of T2 in the following diagram. T2

cannot start until T1 is completed.

• Based upon the details of WBS and the sequence of activities, an activity
network diagram is drawn which shows the sequence of serial and parallel
activities in the project.

• There is no cycle in the activity network diagram.

• The expected completion time in days is shown inside the nodes, along with
the activities.
• The duration of the project is equal to the longest path from the start to the
finish node of the network.

• A path in the network diagram is one of the routes following the arcs from the
start to the finish node.

• The length of a path is the sum of the expected estimated durations of the
activities on the path.

• The duration of the project must be at least the length of the longest path.

• Thus, the estimated project duration equals the length of the longest path
through the project network.

• This longest path is called the critical path.

• For larger projects, it may be helpful to determine the following values for each activity:

• Earliest Start time (TES): It is the earliest time an activity may begin after
allowing the preceding activities to finish. Earliest start time (TES) = max
(TEF of immediate predecessors).

• Earliest Finish time (TEF): It is the earliest time an activity may finishafter
allowing the preceding activities to finish. Earliest finish time (TEF) = TES
+ Activity duration.

• TES and TEF are calculated in the forward pass through the network diagram.
• Sometimes activities take longer than the expected time duration that
may delay project completion.

• So, to determine how much late an activity can start or finish

without delaying project completion as:

• Latest Start time (TLS): It is the latest time an activity may begin
without delaying project completion. Latest start time (TLS) = TLF -
Activity duration.

• Latest Finish time (TLF): It is the latest time an activity may finish
without delaying project completion. Latest finish time = TLF = min (TLS
of immediate successors).

• Slack time (TS): The slack time for an activity is the difference
between its latest finish time and its earliest finish time. Slack time
(TS) = TLF – TEF = TLS – TES.

• The backward pass through the network diagram is made starting with
the final activities and moving backward in time toward the initial
activities to calculate TLS and TLF.
• There are some activities having no slack and other activities have slack time. The
critical path then is the path through the network in which none of the activities
have slack.

• Each activity with zero slack is on the critical path through the project network
such that any delay along this path will delay project completion.

• The critical path is shown in Figure with dark arrows in the network diagram.

• The critical path is:

Start node > Architectural design > Database design > Output design > Finish
node

• Advantage:

• PERT is useful to determine the expected project completion time, the

probability of completion before a specified date, and the start and end
dates.

• It helps to find the critical path activities that directly influence the completion
time.

• Limitation:

• The time estimates for activities are somewhat subjective and depend on
judgment.

• If there is little experience in performing an activity, the time is fixed

only by an educated guess.
 Experiment No 14
Use Timeline charts/Gantt charts to track progress of the assigned project.

I Practical Significance

Gantt charts are widely used in business to describe and monitor all kinds of projects according to the rules of
project management. Different Gantt applications have different features and capabilities.

II Relevant Program Outcomes

All POs are listed.

III Relevant Course Outcomes

Prepare Gantt charts for tracking the utilization of the resources in the project.

IV Practical Learning Outcomes

Detailed description of all aspects of the project to be built.

V Practical Skills

Learn Gantt charts to track the progress of the entire project which is required for project development.

VI Relevant Affective domain related Outcomes

a) Follow precautionary measures.

b) Demonstrate working as a team member.
c) Follow ethical practices.

VII Minimum Theoretical Background

A Gantt chart is a bar graph of a project’s tasks. A typical Gantt chart has the name of individual tasks or group of
tasks in the project on the Y-axis. The X-axis has a timeline divided into days or weeks. Colorbars indicate when a
task is expected to start. Different colors indicate how much of an activity has been completed and how much
remains unfinished.

The ability to grasp the overall status of a project and its tasks at once is the key advantage in using a Gantt chart
tool. Therefore, upper management or the sponsors of the project can make informed decisions just by looking at
the Gantt chart tool.

The software-based Gantt charts are able to show the task dependencies in a project schedule. Thishelpsto identify
and maintain the critical path of a project schedule. Gantt chart tools can be used as the single entity for managing
small projects. For small projects, no other documentation may be required; but for large projects, the Gantt chart
tool should be supported by other means of documentation.
 For large projects, the information displayed in Gantt charts may not be sufficient for decision making.

Fig: A simple Gantt chart with multiple activities and their respective dependencies

VIII Resources required

Sr No Instrument Specification Quantity Remarks

Any Desktop PC
1 Computer System with attached 10 No. Whichever is available
HardDisk

Gantt Chart
2 1 No.
Template
IX Procedure

1. Develop a Work Breakdown Structure

2. Assign Tasks

3. Evaluate Task Dependencies

4. Share & Evaluate the Plan with Your Team

X Precautions

1. Change the requirement carefully.

2. Save changes if required under the guidance of teacher.

XI Description

A Gantt chart can be very useful in planning and carrying out a project. There are a number of ways to create a
Gantt chart: from pen and paper or whiteboard to very complex software programs.

Step 1: Develop a Work Breakdown Structure

What is a Work Breakdown Structure (WBS)? It is a process by which a project is planned by breaking it into easily
definable and understandable goals, milestones and tasks. Listing the major componentsfirst is the first step in
developing a WBS. This can be done by in a word processor, spreadsheet, or using a Gantt chart program.

A key element in the WBS is to plan for intended outcomes, rather than planning actions. That is, understand what
the goals of the project are, define key milestones, and then start the processofbreaking those pieces down into
tasks. If there are fixed dates that need to be met, make sure those are shown in the Gantt chart. This way, as the
topics are broken into tasks, it will become clear upfront whether more resources will need to be added to meet
these deadlines.

After the major topics are determined, the process of breaking these into tasks is next. Dependingonthe
complexity of each task, the project planner may find it necessary to continue breaking these items into sub-tasks
until they are very specific.

For many project planners, a visual model of the WBS is easier to work with than the "laundry list"dictated by the
Gantt chart format. A mind map is ideal for this because it lets you easily see the work breakdown. A good Gantt
chart software program, such as SmartDraw, will allow you to work in Gantt chart or mind map view, with
relational data that automatically updates both views when changes are made in either one.

It is estimated that more than 90% of projects are late. The primary reason for this is that they weren't properly
planned with a well-thought-out work breakdown structure. The more detailed the breakdown, the easier it is to
plan, organize and schedule a project accurately.
Step 2: Assign Tasks
One of the most critical pieces in how to build a Gantt chart is the distribution of work. There are several things to
consider.

 Who is most qualified to complete this task?

 What is their availability vis-à-vis their currently scheduled workload?
 What is a reasonable expectation of their time needed to complete the task(s)?
 Will additional people or resources be necessary to get these tasks completed on time?

Step 3: Evaluate Task Dependencies

One of the benefits of creating a Gantt chart for project planning is that it makes it easier to see dependencies.
This is a situation where one task is dependent upon the completion or outcome of another. For example, a
webmaster can't build a web page unless the copywriter and illustrator have finished their tasks. Identifying these
dependent relationships is critical, as delays in theprimarystepswill almost certainly ripple throughout the entire
project. Automated software will allow you to add dependencies as you create your Gantt chart. If you're doing
this by hand or using a less sophisticated program, you'll need to remember to do this crucial step manually.
Step 4: Share & Evaluate the Plan with Your Team
When the Gantt chart is complete, distribute it to team members for review and feedback. It's important that each
member of the project buys off on the plan upfront. This helps to ensure that the planisaccurate and reasonable. It's
much easier to allow for contingencies, plan additional resources, or even proposea revised schedule at this stage,
rather than at a critical juncture later.