1. Aim: ToPrepare FTR version control and change control for software configuration
items.
2. Objectives: From this experiment, the student will be able to,
● To stress Understand FTR as a class of reviews that includes walkthroughs
and inspections.
● Understand different software versions in terms of configuration items in
formal review method.
3. Outcomes: The learner will be able to,
● An ability to match the industry requirements in the domains of Software
Engineering with the required configuration skills
4. Hardware / Software Required: Any Text editor
5. Theory: Formal technical review (FTR)
A formal technical review (FTR) is a software quality control activity performed by
software engineers (and others). The objectives of an FTR are:
(1) To uncover errors in function, logic, or implementation for any representation of
the software;
(2) To verify that the software under review meets its requirements;
(3) To ensure that the software has been represented according to predefined
standards;
(4) To achieve software that is developed in a uniform manner;
(5) To make projects more manageable. In addition, the FTR serves as a training
ground, enabling junior engineers to observe different approaches to software
analysis, design, and implementation. The FTR also serves to promote backup and
continuity.
Each FTR is conducted as a meeting and will be successful only if it is properly
planned, controlled, and attended.Regardless of the FTR format that is chosen, every
review meeting should abide by the following constraints:
58
• Between three and five people (typically) should be involved in the review.
• Advance preparation should occur but should require no more than two hours
of work for each person.
• The duration of the review meeting should be less than two hours.
Review Reporting and Record Keeping during FTR, a reviewer (the recorder) actively
records all issues that have been raised. These are summarized at the end of the
review meeting, and a review issues list is produced. In addition, a formal
technicalreview summary report is completed. A review summary report answers
three questions:
1. What was reviewed?
2. Who reviewed it?
3. What were the findings and conclusions?
The review issues list serves two purposes:
(1) To identify problem areas within the product and
(2) To serve as an action item checklist that guides the producer
as corrections are made.
What Is a Version?
A version can be defined as a particular form in which something is embodied.But not
all objects have numerous versions.In the real world, when you talk about two
versions of something, you assume the versions have something in common, and that
it is important to know that they have something in common. Otherwise you would
simply consider them to be two different objects, and would not use the word
“version”.
Two versions of an object in the repository have this in common: they are of
the same type and they are versions of the same object. This, actually, may be the
only correspondence.At times you create only a single version of an object; at other
times you create many versions, and you possibly throw away all but the final version.
Advantages of Versioning
• Provide Save-Points:
• The most common reason for tracking versions of objects is to provide
multiple save-points from which you can recover.
• Eliminate Separately Administered Copies:
• Track Revision History:
• Support Parallel Development:
• Implementation of Version Control:
• To manipulate objects under version control you use the check-in/checkout
functionality.
59
Check-in & Check-out Functionality
• Check-in Functionality
• To place an object under version control and make it available to other users,
you check in the object.
• Check-out Functionality
• To be able to modify an object in your work area, you check out the object.
• The Version Privilege
• In order to check in and checkout objects, you’ll need the Version privilege on
both the work area and the container that owns the object.
• Of course, if you have only Select privilege on a container or work area, then
you’re prohibited from checking in or checking out objects. However, you’re
still able to examine objects with only Select privilege.
• Change Control:
• Change management deals with how changes to the system are managed so
they don’t degrade system performance and availability. In effective change
management, all changes should be identified and planned for prior to
implementation.
Change management is implemented as:
Step 1: Define change management process and practices
• You must first craft a plan for handling changes. This plan should cover:
• Procedures for handling changes—how changes are requested, how they are
processed and scheduled for implementation, how they are applied, and what
the criteria are for backing out changes that cause problems
• Roles and responsibilities of the IT support staff—who receives the change
request, who tracks all change requests, who schedules change
implementations, and what each entity is supposed to do
60
• Measurements for change management—what will be tracked to monitor the
efficiency of the change management discipline
• Tools to be used
• Type of changes to be handled and how to assign priorities—priority
assignment methodology and escalation guidelines
• Back-out procedures—Actions to take if applied changes do not perform as
expected or cause problems to other components of the system
Step 2: Receive change requests
• Receive all requests for changes, ideally through a single change coordinator.
Change requests can be submitted on a change request form that includes the
date and time of the request.
Step 3: Plan for implementation of changes
• Examine all change requests to determine:
• Change request prioritization
• Resource requirements for implementing the change
• Impact to the system
• Back-out procedures
• Schedule of implementation
Step 4: Implement and monitor the changes; back out changes if necessary
• At this stage, apply the change and monitor the results. If the desired outcome
is not achieved, or if other systems or applications are negatively affected,
back out the changes.
Step 5: Evaluate and report on changes implemented
• Provide feedback on all changes to the change coordinator, whether they were
successful or not.
Step 6: Modify change management plan if necessary
• We need to modify the entire change management process to make it more
effective.
• All changes, big and small, should be covered. Minor changes can have major
effects on system performance and availability.
6. Procedure:
Prepare FTR for Case Study with the help of above description.
7. Conclusion:
FTR is helpful to uncover errors, to verify software under review for requirements,
standards & uniformity. It makes projects more manageable.
61
8. Viva Questions:
● What is FTR?
● Explain software configuration items.
● What is version control?
9. References:
1. people.cs.aau.dk/~bnielsen/TOV08/material/…/pressman_chap_8.pdf
2. soft-engineering.blogspot.com/2010/12/formal-technical-reviews.html
3. sers.csc.calpoly.edu/~jdalbey/308/Lectures/FTR_lecture.ppt
StudyMumbai.com is an educational resource for students, parents, and teachers, with special focus on Mumbai. Our staff includes educators with several years of experience. Our mission is to simplify learning and to provide free education. Read more about us.
GET INSTANT HELP FROM EXPERTS!
- Looking for any kind of help on your academic work (essay, assignment, project)?
- Want us to review, proofread or tidy up your work?
- Want a helping hand so that you can focus on the more important tasks?
Hire us as project guide/assistant. Contact us for more information
Leave a Reply
You must be logged in to post a comment.