0% found this document useful (0 votes)

22 views50 pages

Manual 21-22

The document describes two traditional software development process models: 1) The waterfall model consists of sequential stages of requirements, analysis, design, testing, implementation, and maintenance. Each stage must be completed before moving to the next. It allows for extensive documentation but does not accommodate changes well. 2) The spiral model is iterative with four stages - planning, objectives, risk analysis, and development - repeated until completion. It evaluates risks to guide decisions and builds prototypes in each iteration to fix errors and enhance requirements early. This allows changes and reduces costs compared to the waterfall model.

Uploaded by

nonijop950

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

22 views50 pages

Manual 21-22

Uploaded by

nonijop950

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 50

AY 2021-22 Software Engineering Sem V

Mahatma Education Society’s

Pillai HOC College of Engineering and Technology, Rasayani

Department of Computer Engineering
Practical List
__________________________________________________________________________________
Subject: Software Engineering Semester: V

Sr. No. Name of the Experiment Page No.

1 Application of at least two traditional process models. 2

2 Application of the Agile process models. 6

3 Preparation of software requirement specification (SRS) document in IEEE 12

format.
4 Structured data flow analysis. 16

5 Use of metrics to estimate the cost. 20

6 Scheduling & tracking of the project 26

7 Write test cases for black box testing. 32

8 Write test cases for white box testing. 36

9 Preparation of Risk Mitigation, Monitoring and Management Plan (RMMM). 40

10 Version controlling of the project. 44

H/W Requirements RAM 512 MB, Printer, Cartridges

S/W Requirements Rational Rose, Argouml, Visual Paradigm

Rahul Kapse PHCET 1

AY 2021-22 Software Engineering Sem V

EXPERIMENT NO:1
Name of the Student: -__________________________________________________
Roll No.____________

Date of Practical Performed: -___________ Staff Signature with Date

& Marks

Aim: Application of at least two traditional process model

Objectives:

1. 1 To provide the knowledge of software engineering discipline.

2. 2 To apply analysis, design and testing principles to software project development.
3. 3 To demonstrate and evaluate real world software projects.

Outcome:

1. Identify requirements & assess the process models.

2. 2 Plan, schedule and track the progress of the projects.
3. 3 Design the software projects.
4. 4 Do the testing of software projects.
5. 5 Identify risks, manage the change to assure quality in software projects.

Background: The software engineer is a key person analyzing the business, identifying
opportunities for improvement, and designing information systems to implement these ideas. It
is important to understand and develop through practice the skills needed to successfully design
and implement new software systems.

Introduction: · In this lab you will practice the software development life cycle (project
management, requirements engineering, systems modeling, software design, prototyping, and
testing) using CASE tools within a team work environment.

Tools Used in the Lab: Software Engineering lab is one of the most challenging of all labs.
Developing a complete software application requires from each of you a good level of
know-how of various tools.

Theory:

Traditional systems development existed prior to agile systems development. These

methodologies include waterfall method, V-model, Rational Unified Process, these

Rahul Kapse PHCET 2

AY 2021-22 Software Engineering Sem V

methodologies are based on the systems development principles that have served as a foundation
for the creation of the systems development to date which can be either sequential or iterative.
Sequential approach means that the methodology is made up of a series of steps/stages that
follow each other sequentially. The steps are dependent on each. The emphasis of the traditional
development approach is to create ample documentation which serves as a means for
communication and traceability of the design. Documentation also plays a vital role in sharing
knowledge and keeping tacit knowledge within the organisation. There are a variety of
traditional systems development methodologies that can be adopted within the organisation.
They include waterfall, Spiral, V-Model, Rational Unified Process (RUP) and Rapid Application
Development, Prototype Model, Concurrent Model. The traditional methodology is the most
commonly used approach by organisations whereby software development activities are
completed sequentially.

The traditional methodologies are briefly explained below.

Waterfall Model: The waterfall model (also referred to as systems development life cycle) is the
most popular of the traditional models. This model was originally proposed by Winston W.
Royce in 1970 to define a potential software engineering practice. It is made up of various stages
and has distinct goals for each stage of software development. It consists of six stages including
requirement gathering, analysis, design, testing, implementation, and maintenance.

Fig1. Waterfall Model

Each stage within the waterfall model flows downward into each other. Each stage has to be
completed prior to the next stage could commence. One of the strengths of the waterfall model is
the extensive documentation of requirements which is good for communication among the
systems development team. However, the waterfall model does not allow changes to be made to
the previously completed stage.
As a result, the system will have to be implemented with missing/faulty requirements or mistakes
committed in any stage of system development. Fixing such mistakes is not easy but costly and it
also leads to late delivery of the requested system. The user requirements keep on changing
throughout the system development because the client does not usually know what they exactly
want. To fix mistakes or gaps encountered in the business requirements specification, change
requests are often logged but can only be attended to once the system has been implemented.

Rahul Kapse PHCET 3

AY 2021-22 Software Engineering Sem V

Spiral Model: The spiral model was introduced by Barry W. Boehm in 1988. It was introduced
to solve the limitations encountered in the waterfall model. Boehm created the spiral model with
the intention of introducing iterative software development.
This model combines the features of the prototyping and the waterfall model.The spiral
model consists of four stages starting with the planning, objectives, risk analysis and
development. The model arranges all the activities in the form of a spiral. All the stages are
continuously repeated for a certain period of time until the completion of the requested system.
The emphasis of the spiral model is to evaluate risks, which are used as a source for decision
making to further develop the system. In each cycle, problems that are encountered are resolved.
The next iteration occurs until the system completes and meets the user requirements. A
prototype is built for every iteration.

Due to the iterative pattern of the spiral development,feedback given on each stage makes it
possible to fix errors at early stages, enhance requirements and get rid of risks identified.
Problems encountered in every iteration are resolved quicker and possible risks are removed at
earlier stages of systems development. This approach makes it possible for the organisations to
save costs since it is cheaper to identify problems and risk in the early stages of the systems
development. This model also makes it possible to enhance or make changes to the requirements
until the acceptable system is delivered to the users.
The spiral development starts smaller and grows bigger depending on the number of
iterations. However, lots of activities occur parallel and make it difficult to manage the systems
development and rework is likely to occur since requirements are not fully specified prior to
systems development. Due to the fact that requirements are not fully specified when the
development starts, additional work may be required.

Rahul Kapse PHCET 4

AY 2021-22 Software Engineering Sem V

The main reason for not specifying all requirements at once is because users do not
normally know exactly what they want until the system is delivered to them. Another setback of
the spiral model is that it works better for big projects than small ones.

Conclusion:
---------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------
---------------------------------------------

Questions:

1. Write Problem definition of case study allotted to you?

Rahul Kapse PHCET 5

AY 2021-22 Software Engineering Sem V

EXPERIMENT NO:2
Name of the Student: -__________________________________________________
Roll No.____________

Date of Practical Performed: -___________ Staff Signature with Date

& Marks
Aim: Application of the Agile process models.

Theory:

Agile methodology is the most significant approach to project management which is effectively
used in the process of software development. This agile approach has been majorly introduced in
the field of software development to overcome difficulties with earlier waterfall and traditional
software development models and to make processes more flexible and effective.agile
development methodology, requirements and solutions evolve through proper collaboration
between cross-functional teams and the product owner. This unique software development
process ensures teams to deliver value faster with quality and predictability and handles changes
effectively.

What are the principles of Agile Methodology?

Rahul Kapse PHCET 6

AY 2021-22 Software Engineering Sem V

Types of Agile Methodologies :

1. Agile Scrum Methodology
2. Scaled Agile Framework (SAFe)
3. Lean Software Development
4. Kanban
5. Extreme Programming (XP)
6. Crystal Methodology
7. Dynamic Systems Development Method (DSDM)
8. Feature Driven Development (FDD)

1. Agile Scrum Methodology: Scrum is an Agile framework that is used to implement the ideas
behind Agile software development. It is the most popular Agile framework used in companies.
Created by Jeff Sutherland and Ken Schwaber (who were also part of the 13 individuals who
cemented the Agile Manifesto), it comprises five values: commitment, courage, focus, openness,
and respect. Its goal is to develop, deliver, and sustain complex products through collaboration,
accountability, and iterative progress.

What distinguishes Scrum from other Agile methodologies are the roles, events, and artifacts that
it is made up of, with which it operates. Here’s what they are:

Scrum team roles

● Product owner: Product expert who represents the stakeholders, and is the voice of the
customer.
● Development team: Group of professionals who deliver the product (developers,
programmers, designers).
● Scrum master: Organized servant-leader who ensures the understanding and execution of
Scrum is followed.

Rahul Kapse PHCET 7

AY 2021-22 Software Engineering Sem V

Scrum events
● Sprint: Iterative timeboxes where a goal is accomplished. Time frame does not exceed
one calendar month and is consistent throughout the development process.
● Sprint planning: Where the entire Scrum team gets together—at the beginning of every
Sprint—to plan the upcoming sprint.
● Daily Scrum: 15 minute time boxed meeting held at the same time, every day of the
Sprint, where the previous day’s achievements are discussed, as well as the expectations
for the following one.
● Sprint review: An informal meeting held at the end of every Sprint where the Scrum team
present their Increment to the stakeholders, and discuss feedback.
● Sprint retrospective: A meeting where the Scrum team reflects on the proceedings of the
previous Sprint and establishes improvements for the next Sprint.

Scrum Artifacts
● Product backlog: Managed by the Product Owner, it’s where all the requirements needed
for a viable product are listed in order of priority. Includes features, functions,
requirements, enhancements, and fixes that authorize any changes to be made to the
product in future releases.
● Sprint backlog: A list of the tasks and requirements that need to be accomplished during
the next Sprint. Sometimes accompanied by a Scrum task board, which is used to
visualize the progress of the tasks in the current Sprint, and any changes that are made in
a ‘To Do, Doing, and Done’ format.

2. Kanban: Kanban is a lean method to manage and improve work across human systems. This
approach aims to manage work by balancing demands with available capacity, and by improving
the handling of system-level bottlenecks.
Work items are visualized to give participants a view of progress and process, from start to
finish—usually via a Kanban board. Work is pulled as capacity permits, rather than work being
pushed into the process when requested.
In knowledge work and in software development, the aim is to provide a visual process
management system which aids decision-making about what, when, and how much to produce.
The underlying Kanban method originated in lean manufacturing,[1] which was inspired by the
Toyota Production System.
A Kanban board is one of the tools that can be used to implement Kanban to manage work at a
personal or organizational level.
Kanban boards visually depict work at various stages of a process using cards to represent work
items and columns to represent each stage of the process. Cards are moved from left to right to
show progress and to help coordinate teams performing the work. A Kanban board may be
divided into horizontal "swimlanes" representing different kinds of work or different teams

Rahul Kapse PHCET 8

AY 2021-22 Software Engineering Sem V

performing the work. Simple boards have columns for "waiting", "in progress" and "completed"
or "to-do", "doing", and "done". Complex Kanban boards can be created that subdivide "in
progress" work into multiple columns to visualise the flow of work across a whole value stream
map

A Kanban board in software development

Applications: Kanban can be used to organize many areas of an organization and can be
designed accordingly. The simplest kanban board consists of three columns: "to-do", "doing" and
"done", though some additional detail such as WiP limits are needed to fully support the Kanban
Method. Business functions that use kanban boards include:
● Kanban board for software development team. A popular example of a Kanban board
for agile or lean software development consists of: Backlog, Ready, Coding, Testing,
Approval, and Done columns. It is also a common practice to name columns in a
different way, for example: Next, In Development, Done, Customer Acceptance,
Live.

Rahul Kapse PHCET 9

AY 2021-22 Software Engineering Sem V

● Kanban for marketing teams

● Kanban for HR teams[7]
● Personal task management or "Personal Kanban"
● Kanban for Accounting teams. Usually consistent of such columns - New items,
Ready for distribution, In progress, and Completed.

Questions:

1. List out Agile Principles?

---------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------
---------------------------------------------
2. List out Agile software development methods and write applications of any two
methodologies .
---------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------

Rahul Kapse PHCET 10

AY 2021-22 Software Engineering Sem V

3. Compare Scrum and Kanban methodologies.

---------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------

Rahul Kapse PHCET 11

AY 2021-22 Software Engineering Sem V

EXPERIMENT NO:3
Name of the Student: -__________________________________________________
Roll No.____________

Date of Practical Performed: -___________ Staff Signature with Date

& Marks

Aim: Preparation of software requirement specification (SRS) document in IEEE format.

Background
A requirement is a statement of a behaviour or attribute that a system must possess for the
system to be acceptable to a stakeholder. Software Requirement Specification (SRS) is a
document that describes the requirements of a computer system from the user's point of view.

An SRS document specifies:

● The required behavior of a system in terms of: input data, required processing, output
data, operational scenarios and interfaces.
● The attributes of a system include: performance, security, maintainability, reliability,
availability, safety requirements and design constraints.
● Requirements management is a systematic approach to eliciting, organizing and
documenting the requirements of a system. It is a process that establishes and maintains
agreement between the customer and the project team on the changing requirements of a
system.
● Requirements management is important because, by organizing and tracking the
requirements and managing the requirement changes, you improve the chances of
completing the project on time and under budget. Poor change management is a key
cause of project failure.
● Requirements Engineering Process Requirements engineering process consists of four
phases:
○ Requirements elicitation: getting the customers to state exactly what the
requirements are.

○ Requirements analysis: making qualitative judgments and checking for

consistency and feasibility of requirements.
○ Requirements validation: demonstrating that the requirements define the system
that the customer really wants.
○ Requirements management: the process of managing changing requirements
during the requirements engineering process and system development, and
identifying missing and extra requirements.

Writing Requirements

Rahul Kapse PHCET 12

AY 2021-22 Software Engineering Sem V

Requirements always need to be correct, unambiguous, complete, consistent, and testable.

Recommendations When Writing Requirements

● Never assume: others do now know what you have in mind. Use meaningful words;
avoid words like: process, manage, perform, handle, and support.
● State requirements not features
● Feature: general, tested only for existence.
● Requirement: specific, testable, measurable.
● Avoid:
○ Conjunctions: ask yourself whether the requirement should be split into two
requirements.
○ Conditionals: if, else, but, except, although. Possibilities: may, might, probably,
usually.

Writing Specifications:

Specification is a description of operations and attributes of a system. It can be a

document, set of documents, a database of design information, a prototype, diagrams or any
combination of these things. Specifications are different from requirements: specifications are
sufficiently complete not only what stakeholders say they want; usually, they have no conflicts;
they describe the system as it will be built and resolve any conflicting requirements.

Creating specifications is important. However, you may not create specifications if:

● You are using a very incremental development process (small changes).

● You are building research or proof of concept projects.
● You rebuild very small projects.
● It is not cheaper or faster than building the product.

Software Requirement Specification (SRS)

Remember that there is no “Perfect SRS”.

However, SRS should be:

● Correct: each requirement represents something required by the target system.

● Unambiguous: every requirement in SRS has only one interpretation
● Complete: everything the target system should do is included in SRS (nosections are
marked TBD-to be determined).
● Verifiable: there exists some finite process with which a person/machine can check that
the actual as-built software product meets the requirements.
● Understandable by customers.

Rahul Kapse PHCET 13

AY 2021-22 Software Engineering Sem V

● Modifiable: changes can be made easily, completely and consistently.

● Design independent: doesn©t imply specific software architecture or algorithm.

● Concise: shorter is better.

● Organized: requirements in SRS are easy to locate; related requirements are together.
● Traceable: each requirement is able to be referenced for later use (by the using paragraph
numbers, one requirement in each paragraph, or by using convention for indication
requirement.

IEEE Template for SRS

1. Purpose
1. Definitions
2. Background
3. System overview
4. References
2. Overall description
1. Product perspective
1. System Interfaces
2. User interfaces
3. Hardware interfaces
4. Software interfaces
5. Communication Interfaces
6. Memory constraints
2. Design constraints
1. Operations
2. Site adaptation requirements
3. Product functions
4. User characteristics
5. Constraints, assumptions and dependencies
3. Specific requirements
1. External interface requirements
2. Performance requirements
3. Logical database requirement
4. Software system attributes
1. Reliability
2. Availability
3. Security
4. Maintainability
5. Portability
5. Functional requirements
1. Functional partitioning
2. Functional description
3. Control description
6. Environment characteristics

Rahul Kapse PHCET 14

AY 2021-22 Software Engineering Sem V

1. Hardware
2. Peripherals
3. Users
7. Other

Conclusion:
………………………………………………………………………………………………………
………………………………………………………………………………………………………
………………………………………………………………………………………………………
………………………………………………………………………………………………………
………………………………………………………………………………………………………
………………………………………………………………………

Questions:

1. What characteristics of good SRS?

2. What are the functional requirements of your project? Give an example.

3. What are non-functional requirements of your project? Give an example.

Rahul Kapse PHCET 15

AY 2021-22 Software Engineering Sem V

EXPERIMENT NO:4
Name of the Student: -__________________________________________________
Roll No.____________

Date of Practical Performed: -___________ Staff Signature with Date

& Marks

Aim:Structured data flow analysis.

Background:
Structured Analysis is a development method that allows the analyst to understand the system
and its activities in a logical way.
It is a systematic approach, which uses graphical tools that analyze and refine the objectives of
an existing system and develop a new system specification which can be easily understandable
by the user.
It has following attributes −
● It is a graphic which specifies the presentation of the application.
● It divides the processes so that it gives a clear picture of system flow.
● It is logical rather than physical i.e The elements of a system do not depend on the vendor
or hardware.
● It is an approach that works from high-level overviews to lower-level details.

Modeling:

Modeling consists of building an abstraction of reality. These abstractions are

simplifications because they ignore irrelevant details and they only represent the relevant details
(what is relevant or irrelevant depends on the purpose of the model).

Why Model Software?

Software is getting larger, not smaller; for example, Windows XP has more than 40
million lines of code. A single programmer cannot manage this amount of code in its entirety.
Code is often not directly understandable by developers who did not participate in the
development; thus, we need simpler representations for complex systems (modeling is a means
for dealing with complexity).
A wide variety of models have been in use within various engineering disciplines for a long time.
In software engineering a number of modeling methods are also available.

Analysis Model Aims

Rahul Kapse PHCET 16

AY 2021-22 Software Engineering Sem V

● To describe what the customer requires.

● To establish a basis for the creation of a software design.
● To define a set of requirements that can be validated once the software is built.

The Elements of the Analysis Model

The generic analysis model consists of:
● An entity-relationship diagram (data model).
● A data flow diagram (functional model).
● A state transition diagram (behavioral model).
Entity Relationship Diagram
An entity relationship diagram (ERD) is one means of representing the objects
and their relationships in the data model for a software product.

Entity Relationship diagram notation:

To create an ERD you need to:

● Define “objects” by underlining all nouns in the written statement of scope

Producers/consumers of data, places where data are stored, and “composite” data items.
● Define “operations” by double underlining all active verbs: processes relevant to the
application and data transformations.
● Consider other “services” that will be required by the objects.
● Then you need to define the relationship which indicates “connectedness”: a "fact" that
must be "remembered" by the system and cannot be or is not computed or derived
mechanically.

Rahul Kapse PHCET 17

AY 2021-22 Software Engineering Sem V

Data Flow Diagram:

A data flow data diagram is one means of representing the functional model of a software
product. DFDs do not represent program logic like flowcharts do.

Data flow diagram notation:

To create a DFD you need to:

● Review ERD to isolate data objects and grammatical parse to determine operations.
● Determine external entities (producers and consumers of data).
● Create a level 0 DFD “Context Diagram” (one single process).
● Balance the flow to maintain data flow continuity.
● Develop a level 1 DFD; use a 1:5 (approx.) expansion ratio.

Data Flow Diagram Guidelines:

● All icons must be labeled with meaningful names.
● Always show external entities at level 0.
● Always label data flow arrows.
● Do not represent procedural logic.
● Each bubble is refined until it does just one thing.

Conclusion:
………………………………………………………………………………………………………
………………………………………………………………………………………………………
………………………………………………………………………………………

Rahul Kapse PHCET 18

AY 2021-22 Software Engineering Sem V

Questions:

1.Define DFD?

………………………………………………………………………………………………………
………………………………………………………………………………………………………
………………………………………………………………………………………

2.What is the use of Data stores?

3.How many levels are there in DFD?.

4. Draw DFD of the case study allotted to you ?

Rahul Kapse PHCET 19

AY 2021-22 Software Engineering Sem V

EXPERIMENT NO:5
Name of the Student: -__________________________________________________
Roll No.____________

Date of Practical Performed: -___________ Staff Signature with Date

& Marks

Aim: Use of metrics to estimate the cost.

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

Theory: The scope of a software project is comparatively quite large, and such a project could
take several years to complete. However, the phrase "quite large" could only give some (possibly
vague) qualitative information. As in any other science and engineering discipline, one would be
interested to measure how complex a project is. One of the major activities of the project
planning phase, therefore, is to estimate various project parameters in order to make proper
decisions. Some important project parameters that are estimated include:

Project size: What would be the size of the code written say, in number of lines, files, modules?
Cost: How much would it cost to develop a software? A software may be just pieces of code, but
one has to pay to the managers, developers, and other project personnel.
Duration: How long would it be before the software is delivered to the clients?
Effort: How much effort from the team members would be required to create the software?
In this experiment we will focus on two methods for estimating project metrics: COCOMO

COCOMO (Constructive Cost Model): was proposed by Boehm. According to him, there could
be three categories of software projects: organic, semi-detached, 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.

Rahul Kapse PHCET 20

AY 2021-22 Software Engineering Sem V

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, semi-detached, 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
● Semi-detached: A development project can be categorized as semi-detached type, if
○ The team consists of some experienced as well as inexperienced staff
○ Team members may have some experience on the type of system to be developed
● Embedded: Embedded type of development project are those, which
○ Aims to develop a software strongly related to machine hardware
○ Team size is usually large

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

Basic COCOMO Model

The basic COCOMO model helps to obtain a rough estimate of the project parameters. It
estimates effort and time required for development in the following way:

Effort = a * (KDSI)b PM
Tdev = 2.5 * (Effort)c Months

where.
● KDSI is the estimated size of the software expressed in Kilo Delivered Source
Instructions
● a, b, c are constants determined by the category of software project
● Effort denotes the total effort required for the software development, expressed in person
months (PMs).
● Tdev denotes the estimated time required to develop the software (expressed in months)

● The value of the constants a, b, c are given below:

Rahul Kapse PHCET 21

AY 2021-22 Software Engineering Sem V

Software project a b c

Organic 2.4 1.05 0.38

Semi-detached 3.0 1.12 0.35

Embedded 3.6 1.20 0.32

Intermediate COCOMO Model

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

Cost drivers for INtermediate COCOMO (Source: http://en.wikipedia.org/wiki/COCOMO)

Cost Drivers Ratings

Very Low Nomin High Very Extra

Low al High High

Product attributes

Required software reliability 0.75 0.88 1.00 1.15 1.40

Size of application database 0.94 1.00 1.08 1.16

Complexity of the product 0.70 0.85 1.00 1.15 1.30 1.65

Hardware attributes

Run-time performance constraints 1.00 1.11 1.30 1.66

Memory constraints 1.00 1.06 1.21 1.56

Volatility of the virtual machine 0.87 1.00 1.15 1.30

Rahul Kapse PHCET 22

AY 2021-22 Software Engineering Sem V

environment

Required turnabout time 0.87 1.00 1.07 1.15

Personnel attributes

Analyst capability 1.46 1.19 1.00 0.86 0.71

Applications experience 1.29 1.13 1.00 0.91 0.82

Software engineer capability 1.42 1.17 1.00 0.86 0.70

Virtual machine experience 1.21 1.10 1.00 0.90

Programming language experience 1.14 1.07 1.00 0.95

Project attributes

Application of software engineering 1.24 1.10 1.00 0.91 0.82

methods

Use of software tools 1.24 1.10 1.00 0.91 0.83

Required development schedule 1.23 1.08 1.00 1.04 1.10

EAF is used to refine the estimates obtained by basic COCOMO as follows:

Effort|corrected = Effort * EAF

Tdev|corrected = 2.5 * (Effort| corrected) c

Complete COCOMO Model:

Both the basic and intermediate COCOMO models consider a software to be a single
homogeneous entity -- an assumption, which is rarely true. In fact, many real life applications are
made up of several smaller sub-systems. (One might not even develop all the subsystems -- just
use the available services). The complete COCOMO model takes these factors into account to
provide a far more accurate estimate of project metrics.
To illustrate this, consider a very popular distributed application: the ticket booking
system of the Indian Railways. There are computerized ticket counters in most of the railway
stations of our country. Tickets can be booked / cancelled from any such counter. Reservations
for future tickets, cancellation of reserved tickets could also be performed. On a high level, the
ticket booking system has three main components:

Rahul Kapse PHCET 23

AY 2021-22 Software Engineering Sem V

· Database
· Graphical User Interface (GUI)
· Networking facilities
Among these, development of the GUI is considered as an organic project type; the database
module could be considered as a semi-detached software. The networking module can be
considered as an embedded software. To obtain a realistic cost, one should estimate the costs for
each component separately, and then add it up.
Advantages of COCOMO:
COCOMO is a simple model, and should help one to understand the concept of project metrics
estimation.
Drawbacks of COCOMO:
COCOMO uses KDSI, which is not a proper measure of a program's size. Indeed, estimating the
size of a software is a difficult task, and any slight miscalculation could cause a large deviation
in subsequent project estimates. Moreover, COCOMO was proposed in 1981 keeping the
waterfall model of project life cycle in mind. It fails to address other popular approaches like
prototype, incremental, spiral, agile models. Moreover, in the present day a software project may
not necessarily consist of coding every bit of functionality. Rather, existing software components
are often used and glued together towards the development of a new software. COCOMO is not
suitable in such cases. COCOMO II was proposed later in 2000 to address these issues.

Questions:

1. List out the types of COCOMO Models

Rahul Kapse PHCET 24

AY 2021-22 Software Engineering Sem V

2. Explain FP Estimation Method

3. Explain LOC Estimation Method.

Rahul Kapse PHCET 25

AY 2021-22 Software Engineering Sem V

EXPERIMENT NO:6
Name of the Student: -__________________________________________________
Roll No.____________

Date of Practical Performed: -___________ Staff Signature with Date

& Marks

Aim : Scheduling & tracking of the project

Theory:
Can you imagine starting a long car trip to an unfamiliar destination without a map or
navigation system? You're pretty sure you have to make some turns here and there, but you have
no idea when or where, or how long it will take to get there. You may arrive eventually, but you
run the risk of getting lost, and feeling frustrated, along the way.
Essentially, driving without any idea of how you're going to get there is the same as
working on a project without a schedule. No matter the size or scope of your project, the
schedule is a key part of project management. The schedule tells you when each activity should
be done, what has already been completed, and the sequence in which things need to be finished.
Luckily, drivers have fairly accurate tools they can use.
Scheduling, on the other hand, is not an exact process. It's part estimation , part
prediction, and part "educated guessing." Because of the uncertainty involved, the schedule is
reviewed regularly, and it is often revised while the project is in progress. It continues to develop
as the project moves forward, changes arise, risks come and go, and new risks are identified. The
schedule essentially transforms the project from a vision to a time-based plan.

Schedules also help you do the following:

● They provide a basis for you to monitor and control project activities.
● They help you determine how best to allocate resources so you can achieve the project
goal.
● They help you assess how time delays will impact the project.
● You can figure out where excess resources are available to allocate to other projects.
● They provide a basis to help you track project progress.
● With that in mind, what's the best way of building an accurate and effective schedule for
your next project?
● Project managers have a variety of tools to develop a project schedule – from the
relatively simple process of action planning for small projects, to use of Gantt Charts and
Network Analysis for large projects . Here, we outline the key tools you will need for
schedule development.
Schedule Inputs:

Rahul Kapse PHCET 26

AY 2021-22 Software Engineering Sem V

You need several types of inputs to create a project schedule:

○ Personal and project calendars – Understanding working days, shifts, and resource
availability is critical to completing a project schedule.
○ Description of project scope – From this, you can determine key start and end
dates, major assumptions behind the plan, and key constraints and restrictions.
You can also include stakeholder expectations, which will often determine project
milestones.
○ Project risks – You need to understand these to make sure there's enough extra
time to deal with identified risks – and with unidentified risks (risks are identified
with thorough Risk Analysis).
○ Lists of activities and resource requirements – Again, it's important to determine
if there are other constraints to consider when developing the schedule.
Understanding the resource capabilities and experience you have available – as
well as company holidays and staff vacations – will affect the schedule.
○ A project manager should be aware of deadlines and resource availability issues
that may make the schedule less flexible.
Scheduling Tools
Here are some tools and techniques for combining these inputs to develop the schedule:
Schedule Network Analysis – This is a graphic representation of the project's activities, the time
it takes to complete them, and the sequence in which they must be done. Project management
software is typically used to create these analyses – Gantt charts and PERT Charts are common
formats.

Critical Path Analysis – This is the process of looking at all of the activities that must be
completed, and calculating the "best line" – or critical path – to take so that you'll complete the
project in the minimum amount of time. The method calculates the earliest and latest possible
start and finish times for project activities, and it estimates the dependencies among them to
create a schedule of critical activities and dates. Learn more about Critical Path Analysis.

Schedule Compression – This tool helps shorten the total duration of a project by decreasing the
time allotted for certain activities. It's done so that you can meet time constraints, and still keep
the original scope of the project.

You can use two methods here:

Crashing – This is where you assign more resources to an activity, thus decreasing the time it
takes to complete it. This is based on the assumption that the time you save will offset the added
resource costs.

Rahul Kapse PHCET 27

AY 2021-22 Software Engineering Sem V

Fast-Tracking – This involves rearranging activities to allow more parallel work. This means
that things you would normally do one after another are now done at the same time. However, do
bear in mind that this approach increases the risk that you'll miss things, or fail to address
changes.

Use of Project Stages:

One of the biggest reasons that projects over-run is that the "final" polishing and
error-correction takes very much longer than anticipated. In this way, projects can seem to be
"80% complete" for 80% of the time! What's worse, these projects can seem to be on schedule
until, all of a sudden, they over-run radically.
A good way of avoiding this is to schedule projects in distinct stages, where final quality,
finished components are delivered at the end of each stage. This way, quality problems can be
identified early on, and rectified before they seriously threaten the project schedule.

Project Review:
Once you have outlined the basic schedule, you need to review it to make sure that the timing for
each activity is aligned with the necessary resources.
Here are tools commonly used to do this:
"What if" scenario analysis – This method compares and measures the effects of different
scenarios on a project. You use simulations to determine the effects of various adverse, or
harmful, assumptions – such as resources not being available on time, or delays in other areas of
the project. You can then measure and plan for the risks posed in these scenarios.

Resource leveling – Here, you rearrange the sequence of activities to address the possibility of
unavailable resources, and to make sure that excessive demand is not put on resources at any
point in time. If resources are available only in limited quantities, then you change the timing of
activities so that the most critical activities have enough resources.

Critical chain method – This also addresses resource availability. You plan activities using their
latest possible start and finish dates. This adds extra time between activities, which
you can then use it to manage work disruptions.

Risk multipliers – Risk is inevitable, so you need to prepare for its impact. Adding extra time to
high-risk activities is one strategy. Another is to add a time multiplier to certain tasks or certain
resources to offset overly optimistic time estimation.
After the initial schedule has been reviewed, and adjustments made, it's a good idea to
have other members of the team review it as well. Include people who will be doing the work –
their insights and assumptions are likely to be particularly accurate and relevant.

Schedule Tracking:
▪ Conduct periodic project status meetings in which each team member reports

Rahul Kapse PHCET 28

AY 2021-22 Software Engineering Sem V

progress and problems.

▪ Evaluate the results of all reviews conducted throughout the software engineering
process.
▪ Determine whether formal project milestones (diamonds in previous slide) have
been accomplished by the scheduled date.
▪ Compare actual start-date to planned start-date for each project task listed in the
resource table
▪ Meet informally with practitioners to obtain their subjective assessment of progress
to date and problems on the horizon.
▪ Use earned value analysis to assess progress quantitatively.

• Earned value
– Is a measure of progress
– Enables us to assess the “percent of completeness” of a project using quantitative
analysis rather than rely on a gut feeling
– “provides accurate and reliable readings of performance from as early as 15 percent
into the project.” [FLE98]

Computing Earned Value:

• The budgeted cost of work scheduled (BCWS) is determined for each work task
represented in the schedule.
– BCWSi is the effort planned for work task i.
– To determine progress at a given point along the project schedule, the value of
BCWS is the sum of the BCWSi values for all work tasks that should have been
completed by that point in time on the project schedule.
• The BCWS values for all work tasks are summed to derive the budget at completion, BAC.
Hence,
• BAC = ∑ (BCWSk) for all tasks k

• Next, the value for budgeted cost of work performed (BCWP) is computed.
– The value for BCWP is the sum of the BCWS values for all work tasks that have
actually been completed by a point in time on the project schedule.
• “the distinction between the BCWS and the BCWP is that the former represents the budget
of the activities that were planned to be completed and the latter represents the budget of
the activities that actually were completed.” [WIL99]

• Given values for BCWS, BAC, and BCWP, important progress indicators can be computed:
• Schedule performance index, SPI = BCWP/BCWS

Rahul Kapse PHCET 29

AY 2021-22 Software Engineering Sem V

• Schedule variance, SV = BCWP – BCWS

• SPI is an indication of the efficiency with which the project is utilizing
scheduled resources.
• Percent scheduled for completion = BCWS/BAC
– provides an indication of the percentage of work that should have been completed by
time t.
• Percent complete = BCWP/BAC
– provides a quantitative indication of the percent of completeness of the project at a
given point in time, t.
• Actual cost of work performed, ACWP, is the sum of the effort actually expended on work
tasks that have been completed by a point in time on the project schedule. It is then
possible to compute
• Cost performance index, CPI = BCWP/ACWP
• Cost variance, CV = BCWP – ACWP

Questions:

1. Which tool is used for scheduling ?

2, What are scheduling inputs?

Rahul Kapse PHCET 30

AY 2021-22 Software Engineering Sem V

3. Consider the following table of activities: After 8 days of work, activity A has been completed
on time. Activity C has 4 deliverables and 3 have been completed. Assuming each day’s work
costs $100, what is the Cost Variance, the Schedule Variance, the CPI and SPI?

Rahul Kapse PHCET 31

AY 2021-22 Software Engineering Sem V

EXPERIMENT NO:7
Name of the Student: -__________________________________________________
Roll No.____________

Date of Practical Performed: -___________ Staff Signature with Date

& Marks

Aim: Write test cases for black box testing.

Theory:
Black-box testing is a method of software testing that examines the functionality of an
application without peering into its internal structures or workings. This method of test can be
applied virtually to every level of software testing: unit, integration, system and acceptance. It is
sometimes referred to as specification-based testing.

Test Procedure: Specific knowledge of the application's code, internal structure and
programming knowledge in general is not required. The tester is aware of what the software is
supposed to do but is not aware of how it does it. For instance, the tester is aware that a particular
input returns a certain, invariable output but is not aware of how the software produces the output
in the first place.

Typical black-box test design techniques include:

● Decision table testing
● All-pairs testing
● Equivalence partitioning
● Boundary value analysis
● Cause–effect graph
● Error guessing
● State transition testing
● Use case testing
● User story testing
● Domain analysis
● Syntax testing

● Decision table testing: Decision tables are a concise visual representation for specifying
which actions to perform depending on given conditions. They are algorithms whose
output is a set of actions. The information expressed in decision tables could also be

Rahul Kapse PHCET 32

AY 2021-22 Software Engineering Sem V

represented as decision trees or in a programming language as a series of if-then-else and

switch-case statements.

● Equivalence partitioning: This technique is also known as Equivalence Class

Partitioning (ECP). In this technique, input values to the system or application are
divided into different classes or groups based on its similarity in the outcome.Hence,
instead of using each and every input value, we can now use any one value from the
group/class to test the outcome. This way, we can maintain test coverage while we can
reduce the amount of rework and most importantly the time spent.

As present in the above image, the “AGE” text field accepts only numbers from 18 to 60. There
will be three sets of classes or groups.
Two invalid classes will be:
a) Less than or equal to 17.
b) Greater than or equal to 61.
A valid class will be anything between 18 and 60.
We have thus reduced the test cases to only 3 test cases based on the formed classes thereby
covering all the possibilities. So, testing with any one value from each set of the class is
sufficient to test the above scenario.
Boundary value analysis:
The name itself defines that in this technique, we focus on the values at boundaries as it is found
that many applications have a high amount of issues on the boundaries. Boundary refers to
values near the limit where the behavior of the system changes. In boundary value analysis, both
valid and invalid inputs are being tested to verify the issues.
For Example:

Rahul Kapse PHCET 33

AY 2021-22 Software Engineering Sem V

If we want to test a field where values from 1 to 100 should be accepted, then we choose the
boundary values: 1-1, 1, 1+1, 100-1, 100, and 100+1. Instead of using all the values from 1 to
100, we just use 0, 1, 2, 99, 100, and 101.

Test Cases and Test Suite

A test case describes input descriptions and an expected output description. Input are of two
types: preconditions (circumstances that hold prior to test case execution) and the actual inputs
that are identified by some testing methods. The set of test cases is called a test suite. We may
have a test suite of all possible test cases.

Questions:

1. What is Software Testing?

Rahul Kapse PHCET 34

AY 2021-22 Software Engineering Sem V

2. Define Test case?

3.List out advantages and disadvantages of black box testing?

Rahul Kapse PHCET 35

AY 2021-22 Software Engineering Sem V

EXPERIMENT NO:8
Name of the Student: -__________________________________________________
Roll No.____________

Date of Practical Performed: -___________ Staff Signature with Date

& Marks
Aim: Write test cases for white box testing.

Theory:

What is White Box Testing?

If we go by the definition, “White box testing” (also known as clear, glass box or
structural testing) is a testing technique which evaluates the code and the internal structure of a
program. White box testing involves looking at the structure of the code. When you know the
internal structure of a product, tests can be conducted to ensure that the internal operations
performed according to the specification. And all internal components have been adequately
exercised.

White Box Testing Techniques:

1. Statement Coverage
2. Branch Coverage
3. Path Coverage
Note that the statement, branch or path coverage does not identify any bug or defect that needs to
be fixed. It only identifies those lines of code which are either never executed or remains
untouched. Based on this further testing can be focused on.
Basic Procedures:
White-box testing's basic procedures require the tester to have an in-depth knowledge of
the source code being tested. The programmer must have a deep understanding of the application
to know what kinds of test cases to create so that every visible path is exercised for testing. Once
the source code is understood then the source code can be analyzed for test cases to be created.
The following are the three basic steps that white-box testing takes in order to create test cases:
1. Input involves different types of requirements, functional specifications, detailed
designing of documents, proper source code and security specifications. This is
the preparation stage of white-box testing to lay out all of the basic information.
2. Processing involves performing risk analysis to guide the whole testing process,
proper test plan, execute test cases and communicate results. This is the phase of

Rahul Kapse PHCET 36

AY 2021-22 Software Engineering Sem V

building test cases to make sure they thoroughly test the application and the given
results are recorded accordingly.
3. Output involves preparing final report that encompasses all of the above
preparations and results

Let’s understand these techniques one by one with a simple example.

1) Statement coverage:
In a programming language, a statement is nothing but the line of code or instruction for
the computer to understand and act accordingly. A statement becomes an executable statement
when
it gets compiled and converted into the object code and performs the action when the program is
in a running mode. Hence “Statement Coverage”, as the name itself suggests, is the method of
validating whether each and every line of the code is executed at least once.

2) Branch Coverage:
“Branch” in a programming language is like the “IF statements”. An IF statement has two
branches: True and False. So in Branch coverage (also called Decision coverage), we validate
whether each branch is executed at least once.

In case of an “IF statement”, there will be two test conditions: One to validate the true
branch and, Other to validate the false branch.
Hence, in theory, Branch Coverage is a testing method which is when executed ensures that each
and every branch from each decision point is executed.

3) Path Coverage
Path coverage tests all the paths of the program. This is a comprehensive technique which
ensures that all the paths of the program are traversed at least once. Path Coverage is even more
powerful than Branch coverage. This technique is useful for testing complex programs.

Let’s take a simple example to understand all these white box testing techniques. Also check =>
Different Types of testing.

White Box Testing Example

Consider the below simple pseudocode:
INPUT A & B
C=A+B
IF C>100
PRINT “ITS DONE”

Rahul Kapse PHCET 37

AY 2021-22 Software Engineering Sem V

For Statement Coverage – we would only need one test case to check all the lines of the code.
That means:
If I consider TestCase_01 to be (A=40 and B=70), then all the lines of code will be executed.
Now the question arises:
1. Is that sufficient?
2. What if I consider my Test case as A=33 and B=45?
Because Statement coverage will only cover the true side, for the pseudo code, only one test case
would NOT be sufficient to test it. As a tester, we have to consider the negative cases as well.
Hence for maximum coverage, we need to consider “Branch Coverage”, which will evaluate the
“FALSE” conditions.
In the real world, you may add appropriate statements when the condition fails.
So now the pseudocode becomes:
INPUT A & B
C=A+B
IF C>100
PRINT “ITS DONE”
ELSE
PRINT “ITS PENDING”
Since Statement coverage is not sufficient to test the entire pseudo code, we would require
Branch coverage to ensure maximum coverage.

So for Branch coverage, we would require two test cases to complete the testing of this pseudo
code.
TestCase_01: A=33, B=45
TestCase_02: A=25, B=30
With this, we can see that each and every line of the code is executed at least once.

Questions:

1. Explain Cyclomatic complexity with an example?

Rahul Kapse PHCET 38

AY 2021-22 Software Engineering Sem V

Q2. List out whitebox test techniques? Explain any one.

Q3. What is Path coverage?

Rahul Kapse PHCET 39

AY 2021-22 Software Engineering Sem V

EXPERIMENT NO:9
Name of the Student: -__________________________________________________
Roll No.____________

Date of Practical Performed: -___________ Staff Signature with Date

& Marks

Aim: Preparation of Risk Mitigation, Monitoring and Management Plan (RMMM).

Theory:

Software risks:
There are two characteristics of the risks
1. The risk may or may not happen. It shows the uncertainty of the risk.
2. When risks occur, unwanted consequences or losses will occur.
Different types of risk
1. Project Risk
Project risk arises in the software development process then they basically affect budget,
schedule, staffing, resources, and requirements. When project risks become severe then the total
cost of the project increases.
2. Technical Risk
These risks affect the quality and timeliness of the project. If technical risk becomes
reality then potential design, implementation, interface, verification and maintenance problems
get created.Technical risks occur when a problem becomes harder to solve.
3. Business Risk
When feasibility of a software product is in doubt then business risks occur. Business
risks can be classified as follows.
i. Market Risk
When the quality of a software product is built but if there is no customer for this product
then it is called market risk (i.e. no market for product).
ii. Strategic Risk
When a product is built and if it is not following the company’s business policies then
such product brings strategic risks.
iii. Sales Risk
When a product is built but how to sell it is not clear then such a situation brings sales
risk.

iv. Management Risk

Rahul Kapse PHCET 40

AY 2021-22 Software Engineering Sem V

When senior management or the responsible staff leaves the organizations then
management risk occurs.
v. Budget Risk
Losing the overall budget of the project called Budget risk.

4. Known risks are those that are identified by evaluating the project plan. There are two
types of known risk
a. Predictable Risk
Predictable risk are those that can be identified in advance based on past project
experience
b. Unpredictable Risk
Unpredictable risks are those that cannot be guessed earlier.
RMMM
RMM stands for risk mitigation, monitoring and management. There are three issues in
strategy for handling the risk is
1. Risk Avoidance
2. Risk Monitoring
3. Risk Management

Risk Mitigation
Risk mitigation means preventing the risk to occur (risk avoidance). Following are the
steps to be taken for mitigating the risks.
● Communicate with the concerned staff to find probable risk.
● Find out and eliminate all those causes that can create risk before the project starts.
● Develop a policy in an organization which will help to continue the project even though
the same staff leaves the organization.
● Everybody in the project team should be acquainted with the current development
activity
● Maintain the corresponding documents in timely manner
● Conduct timely reviews in order to speed up work.
● For conducting every critical activity during software development, provide the
additional staff if required.
Risk Monitoring
In the Risk Monitoring process the following thing must be monitored by the project
manager.
● The approach and behaviour of the team member as pressure of the project varies.
● The degree in which the team performs with the spirit of “Team-Work”.
● The type of cooperation between the team members.
● The type of problem occurs in team members.

Rahul Kapse PHCET 41

AY 2021-22 Software Engineering Sem V

● . Availability of jobs within and outside of the organization.

● The objective of risk mitigation is
● 16. To check whether the predicted risk really occurs or not.
● 17. To ensure the steps defined to avoid the risk are applied properly or not.
● 18. To gather the information this can be useful for analyzing the risk.

Risk Management
Project manager performs this task when risk becomes a reality. If project manager is
successful in applying the project mitigation effectively then it becomes very much easy to
manage the risks.
For example,
Consider a scenario where many people are leaving the organization then if sufficient additional
staff is available, if current development activity is known to everybody in the team, if latest and
systematic documentation is available then any ‘new comer’ can easily understand current
development activity. This will ultimately help in continuing the work without any interval.

Questions:

1. Difference between operational risk and strategic risk?

Rahul Kapse PHCET 42

AY 2021-22 Software Engineering Sem V

2. What is the RMMM Plan and give its Example?

3. What is Risk Monitoring?

Rahul Kapse PHCET 43

AY 2021-22 Software Engineering Sem V

EXPERIMENT NO:10
Name of the Student: -__________________________________________________
Roll No.____________

Date of Practical Performed: -___________ Staff Signature with Date

& Marks

Aim: Version controlling of the project.

Theory:

What is a “version control system”?

Version control systems are a category of software tools that helps in recording changes made to
files by keeping a track of modifications done to the code.
Why is the Version Control system so Important?
As we know that a software product is developed in collaboration by a group of
developers they might be located at different locations and each one of them contributes in some
specific kind of functionality/features. So in order to contribute to the product, they made
modifications in the source code(either by adding or removing).
A version control system is a kind of software that helps the developer team to efficiently
communicate and manage(track) all the changes that have been made to the source code along
with the information like who made and what change has been made. A separate branch is
created for every contributor who made the changes and the changes aren’t merged into the
original source code unless all are analyzed as soon as the changes are green signalled and
merged to the main source code.
It not only keeps source code organized but also improves productivity by making the
development process smooth.
Benefits of the version control system:
a) Enhances the project development speed by providing efficient collaboration,
b) Leverages the productivity, expedite product delivery, and skills of the employees through
better communication and assistance,
c) Reduce possibilities of errors and conflicts meanwhile project development through
traceability to every small change,

Rahul Kapse PHCET 44

AY 2021-22 Software Engineering Sem V

d) Employees or contributor of the project can contribute from anywhere irrespective of the
different geographical locations through this VCS,
e) For each different contributor of the project a different working copy is maintained and not
merged to the main file unless the working copy is validated. A most popular example is Git,
Helix core, Microsoft TFS,
f) Helps in recovery in case of any disaster or contingent situation,
g) Informs us about Who, What, When, Why changes have been made.
Use of Version Control System:
A repository: It can be thought of as a database of changes. It contains all the edits and
historical versions (snapshots) of the project.
Copy of Work (sometimes called as checkout): It is the personal copy of all the files in a
project. You can edit this copy, without affecting the work of others and you can finally commit
your changes to a repository when you are done making your changes.
Types of Version Control Systems:

● Local Version Control Systems

● Centralized Version Control Systems
● Distributed Version Control Systems

Local Version Control Systems: It is one of the simplest forms and has a database that kept all
the changes to files under revision control. RCS is one of the most common VCS tools. It keeps
patch sets (differences between files) in a special format on disk. By adding up all the patches it
can then re-create what any file looked like at any point in time.
Centralized Version Control Systems: Centralized version control systems contain just one
repository and each user gets their own working copy. You need to commit to reflecting your
changes in the repository. It is possible for others to see your changes by updating.
Two things are required to make your changes visible to others which are:

● You commit
● They update

Rahul Kapse PHCET 45

AY 2021-22 Software Engineering Sem V

The benefit of CVCS (Centralized Version Control Systems) makes collaboration amongst
developers along with providing an insight to a certain extent on what everyone else is doing on
the project. It allows administrators to fine-grained control over who can do what.
It has some downsides as well which led to the development of DVS. The most obvious is the
single point of failure that the centralized repository represents if it goes down during that period
collaboration and saving versioned changes is not possible. What if the hard disk of the central
database becomes corrupted, and proper backups haven’t been kept? You lose absolutely
everything.
Distributed Version Control Systems: Distributed version control systems contain multiple
repositories. Each user has their own repository and working copy. Just committing your changes
will not give others access to your changes. This is because commit will reflect those changes in
your local repository and you need to push them in order to make them visible on the central
repository. Similarly, When you update, you do not get other’s changes unless you have first
pulled those changes into your repository.
To make your changes visible to others, 4 things are required:

● You commit

Rahul Kapse PHCET 46

AY 2021-22 Software Engineering Sem V

● You push
● They pull
● They update

The most popular distributed version control systems are Git, Mercurial. They help us overcome
the problem of a single point of failure.

Purpose Of Version Control:

● Multiple people can work simultaneously on a single project. Everyone works on and
edits their own copy of the files and it is up to them when they wish to share the
changes made by them with the rest of the team.

Rahul Kapse PHCET 47

AY 2021-22 Software Engineering Sem V

● It also enables one person to use multiple computers to work on a project, so it is

valuable even if you are working by yourself.
● It integrates the work that is done simultaneously by different members of the team.
In some rare cases, when conflicting edits are made by two people to the same line of
a file, then human assistance is requested by the version control system in deciding
what should be done.
● Version control provides access to the historical versions of a project. This is
insurance against computer crashes or data loss. If any mistake is made, you can
easily roll back to a previous version. It is also possible to undo specific edits that too
without losing the work done in the meanwhile. It can be easily known when, why,
and by whom any part of a file was edited.

Version Control Systems

There are plenty of options available in the market. Few of them are listed below:

1. GitHub
GitHub helps software teams to collaborate and maintain the entire history of code
changes. You can track changes in code, turn back the clock to undo errors and share your efforts
with other team members.
It is a repository to host Git projects. For those wondering what is Git? It is an open
source version control system that features local branching, multiple workflows, and convenient
staging areas. Git version control is an easy to learn option and offers faster operation speed.

2. GitLab
GitLab comes with a lot of handy features like an integrated project, a project website,
etc. Using the continuous integration (CI) capabilities of GitLab, you can automatically test and
deliver the code.
You can access all the aspects of a project, view code, pull requests, and combine the
conflict resolution.

3. Beanstalk
Beanstalk is an ideal option for those who need to work from remote places. This
software is based on browser and cloud, allowing users to code, commit, review and deploy
using a browser.
It can be integrated with messaging and email platforms for efficient collaborations
related to codes and updates. It supports both Git and SVN and comes with built-in analytics
features.
For security, it leverages encryption, two-factor authentication, and password protection
functionalities.

Rahul Kapse PHCET 48

AY 2021-22 Software Engineering Sem V

4. PerForce
Perforce delivers the version control capabilities through its HelixCore. The HelixCore
comes with a single platform for seamless team collaboration, and support for both centralized
and distributed development workflows.
It is a security solution that protects the most valuable assets. HelixCore allows you to
track the code changes accurately and facilitates a complete Git ecosystem.

5. Apache Subversion
Apache Subversion is another open source version control system, which was founded by
CollabNet a couple of decades ago. Both the open source arena and enterprises consider it a
reliable option for valuable data.
Key features of Subversion include inventory management, security management, history
tracking, user access controls, cheap local branching, and workflow management.

6. AWS CodeCommit
AWS CodeCommit is a managed version control system that hosts secure and scalable
private Git repositories. It seamlessly connects with other products from Amazon Web Services
(AWS) and hosts the code in secured AWS environments. Hence, it is a good fit for the existing
users of AWS.
AWS integration also provides access to several useful plugins from AWS partners,
which helps in software development.

Questions:

1. Explain Change control with suitable flowchart.

Rahul Kapse PHCET 49

AY 2021-22 Software Engineering Sem V

2. List out Goals of SCM.

3. Write Process of SCM?

………………………………………………………………………………………………………
………………………………………………………………………………………………………
………………………………………………………………………………………………………
………………………………………………………………………………………………………
………………………………………………………………………………………………………
………………………………………………………………………………………………………
………………………………………………………………………………………………………
………………………………………………………………………………………………………
………………………………………………………………………………………………………
………………………………………………………………………………………………………
………………………………………………………………………………………………………
………………………………………………………………………………………………………
………………………………………………………………………………………………………
………………………………………………………………………………………………………
………………………………………………………………………………………………………
………………………………………………………………………………………………………
………………………………………………………………………………………………………
………………………………………………………………………………………………………
………………………………………………………………………………………………………

Rahul Kapse PHCET 50

Literary Terms
No ratings yet
Literary Terms
234 pages
Pipe Supports
100% (1)
Pipe Supports
147 pages
FSD Lab Manual
100% (3)
FSD Lab Manual
48 pages
Physical Science Q4 Week 2 v2
100% (1)
Physical Science Q4 Week 2 v2
20 pages
Software Engineering Manual
No ratings yet
Software Engineering Manual
85 pages
Math 6 - Q1 - W3.docx Edited
No ratings yet
Math 6 - Q1 - W3.docx Edited
11 pages
KET Speaking TIPS
No ratings yet
KET Speaking TIPS
3 pages
Software Enggniring: What Is A Software Process?
No ratings yet
Software Enggniring: What Is A Software Process?
13 pages
SE BCS 601 Notes Till ST-1
100% (1)
SE BCS 601 Notes Till ST-1
36 pages
Elevate Abap Ty M
100% (1)
Elevate Abap Ty M
141 pages
Amey B-50 Software Engineering Lab Experiment-1
No ratings yet
Amey B-50 Software Engineering Lab Experiment-1
14 pages
Software Engineering
No ratings yet
Software Engineering
76 pages
2020-09-07 WITS - MECN 5005A - Systems MGMT - Lecture 5 of 8 - Shared
No ratings yet
2020-09-07 WITS - MECN 5005A - Systems MGMT - Lecture 5 of 8 - Shared
73 pages
Software Engineering - Unit - 1
No ratings yet
Software Engineering - Unit - 1
22 pages
Software Engineering 1
No ratings yet
Software Engineering 1
39 pages
SE Report
100% (1)
SE Report
43 pages
A Brief History of Theatre Architecture and Stage
0% (1)
A Brief History of Theatre Architecture and Stage
53 pages
Dennis (Dennis 1975) : Pomberger and Blaschek (Pomberger 1996)
No ratings yet
Dennis (Dennis 1975) : Pomberger and Blaschek (Pomberger 1996)
29 pages
Ppt-Se-Unit 1
No ratings yet
Ppt-Se-Unit 1
24 pages
Practical 1
No ratings yet
Practical 1
13 pages
Se 004
No ratings yet
Se 004
23 pages
SE Syllabuspdf 2025 01 04 13 34 22
No ratings yet
SE Syllabuspdf 2025 01 04 13 34 22
4 pages
Linux Printout Final
No ratings yet
Linux Printout Final
8 pages
SLM - Unit 11
No ratings yet
SLM - Unit 11
24 pages
Week 1 Lec 1 & 2
No ratings yet
Week 1 Lec 1 & 2
52 pages
Lesson 6B - Software Development Life Cycle Models
No ratings yet
Lesson 6B - Software Development Life Cycle Models
10 pages
Software Engineering Cat One
No ratings yet
Software Engineering Cat One
4 pages
Se PR Pra
No ratings yet
Se PR Pra
47 pages
Software Engineering Lecture2
No ratings yet
Software Engineering Lecture2
64 pages
Department of Computer Science: Lab Manual
No ratings yet
Department of Computer Science: Lab Manual
94 pages
SE Unit I
No ratings yet
SE Unit I
20 pages
SE Lab Manual
No ratings yet
SE Lab Manual
78 pages
01CE0607SOFTWAREENGINEERINGpdf 2023 12 31 12 35 361pdf 2024 01 10 08 24 53pdf 2025 01 15 07 54 07
No ratings yet
01CE0607SOFTWAREENGINEERINGpdf 2023 12 31 12 35 361pdf 2024 01 10 08 24 53pdf 2025 01 15 07 54 07
5 pages
Experiment No
No ratings yet
Experiment No
13 pages
SE Prac
No ratings yet
SE Prac
40 pages
Screenshot 2025-04-13 at 9.59.14 AM
No ratings yet
Screenshot 2025-04-13 at 9.59.14 AM
11 pages
SoftwareEngineering Class 1
No ratings yet
SoftwareEngineering Class 1
5 pages
Se Lab
No ratings yet
Se Lab
7 pages
Lab Manual Soft Engg Odd Sem V
No ratings yet
Lab Manual Soft Engg Odd Sem V
84 pages
Cape Computer Science Unit 2 Alternative Software Process Models
No ratings yet
Cape Computer Science Unit 2 Alternative Software Process Models
5 pages
Alternative Software Process Models
No ratings yet
Alternative Software Process Models
5 pages
Lab Manual 1-5
No ratings yet
Lab Manual 1-5
11 pages
Lect2 1
No ratings yet
Lect2 1
134 pages
SE - KCA-302 - 2021-22 - AKTU - QPaper - Sol
No ratings yet
SE - KCA-302 - 2021-22 - AKTU - QPaper - Sol
20 pages
S.E Chapter 4
No ratings yet
S.E Chapter 4
36 pages
Software-Engineering Unit 1 Imp
No ratings yet
Software-Engineering Unit 1 Imp
50 pages
Unit - 1 Introduction To Software Engineering
No ratings yet
Unit - 1 Introduction To Software Engineering
120 pages
Software Engineering (23E05403T) : Department Computer Science and Engineeringof
No ratings yet
Software Engineering (23E05403T) : Department Computer Science and Engineeringof
64 pages
Sexy Beans FMT
No ratings yet
Sexy Beans FMT
74 pages
2.1selection of Appropriate Project Approach SPM
No ratings yet
2.1selection of Appropriate Project Approach SPM
71 pages
Btcse 505 Software Engineering Design and Algorithm
No ratings yet
Btcse 505 Software Engineering Design and Algorithm
11 pages
Course Name Date Course Code Slot Class No Lab Exercise 1.1: Analysis and Identification of The Suitable Process Models
No ratings yet
Course Name Date Course Code Slot Class No Lab Exercise 1.1: Analysis and Identification of The Suitable Process Models
6 pages
Unit 2 2
No ratings yet
Unit 2 2
20 pages
Gogte Institute of Technology: Karnataka Law Society's
No ratings yet
Gogte Institute of Technology: Karnataka Law Society's
11 pages
Assignment of Generic Models (Software Engineering)
No ratings yet
Assignment of Generic Models (Software Engineering)
8 pages
Software Life Cycle
No ratings yet
Software Life Cycle
42 pages
SPPM Notes 1
No ratings yet
SPPM Notes 1
12 pages
SE Practical List
No ratings yet
SE Practical List
20 pages
Software Engg
No ratings yet
Software Engg
66 pages
SDLC Chapter-1 Support
No ratings yet
SDLC Chapter-1 Support
57 pages
Administrative and Business Chapter 4
No ratings yet
Administrative and Business Chapter 4
20 pages
NICU Discharge Plan
No ratings yet
NICU Discharge Plan
58 pages
Voltage Drop
No ratings yet
Voltage Drop
39 pages
Chapter 2 - Life Cycle Models
No ratings yet
Chapter 2 - Life Cycle Models
42 pages
Lecture 03
No ratings yet
Lecture 03
51 pages
Attributes of God
No ratings yet
Attributes of God
13 pages
Vhfov2 User Manual
No ratings yet
Vhfov2 User Manual
10 pages
STUDY MATERIAL-4 - My Experiments With Truth - MIL - IV (English) - UG - SEM - 4 (Programme)
No ratings yet
STUDY MATERIAL-4 - My Experiments With Truth - MIL - IV (English) - UG - SEM - 4 (Programme)
9 pages
The National Shipbuilding Research Program: 1988 Ship Production Symposium
No ratings yet
The National Shipbuilding Research Program: 1988 Ship Production Symposium
10 pages
Role of Information System in Tourism PDF
No ratings yet
Role of Information System in Tourism PDF
18 pages
Theory of Elasticity and Plasticity. (CVL 622) M.Tech. CE Term-2 (2017-18)
No ratings yet
Theory of Elasticity and Plasticity. (CVL 622) M.Tech. CE Term-2 (2017-18)
2 pages
Recitation 2 Philosophy
No ratings yet
Recitation 2 Philosophy
3 pages
E11-15 Standard Specification For Woven Wire Test Sieve Cloth and Test Sieves
No ratings yet
E11-15 Standard Specification For Woven Wire Test Sieve Cloth and Test Sieves
9 pages
CEE 209 Course Objective and Outcome Form - October 2018
No ratings yet
CEE 209 Course Objective and Outcome Form - October 2018
2 pages
Kiss That Frog Book Review
No ratings yet
Kiss That Frog Book Review
6 pages
Estimation of Saturated Data Using The Tobit Kalman Filter
No ratings yet
Estimation of Saturated Data Using The Tobit Kalman Filter
6 pages
MZDG - 66172 1 en 0603
No ratings yet
MZDG - 66172 1 en 0603
44 pages
SAPinsider 2019 Compendium BI-Analytics-HANA
No ratings yet
SAPinsider 2019 Compendium BI-Analytics-HANA
68 pages
Bohler Art of Interpretation PDF
No ratings yet
Bohler Art of Interpretation PDF
20 pages
Hi Connections
No ratings yet
Hi Connections
6 pages
Name ... : Grade 5: Al Andalus International School
No ratings yet
Name ... : Grade 5: Al Andalus International School
26 pages
The C.P.A - Sunday Service of 17TH March 2024.
No ratings yet
The C.P.A - Sunday Service of 17TH March 2024.
3 pages
Lecture Notes On Streamlines and Electric Flux Density
No ratings yet
Lecture Notes On Streamlines and Electric Flux Density
5 pages
Multi-State and Multiple Decrement Models
No ratings yet
Multi-State and Multiple Decrement Models
11 pages
Defect Prediction in Software Development & Maintainence
From Everand
Defect Prediction in Software Development & Maintainence
Rudra Kumar
No ratings yet
Software Engineering New Approach (Traditional and Agile Methodologies)
From Everand
Software Engineering New Approach (Traditional and Agile Methodologies)
Ramisetty Rajeswara Rao
No ratings yet
Software Reuse: Methods, Models, Costs, Second Edition
From Everand
Software Reuse: Methods, Models, Costs, Second Edition
Ronald J. Leach
No ratings yet
Mastering Software Engineering: From Basics to Expert Proficiency
From Everand
Mastering Software Engineering: From Basics to Expert Proficiency
William Smith
No ratings yet
Software Testing Interview Questions You'll Most Likely Be Asked
From Everand
Software Testing Interview Questions You'll Most Likely Be Asked
Vibrant Publishers
No ratings yet