CSE6364 Software Evolution and Maintenance
Tutorial 10
Topic (Lecture 10): Software Change Management 3
1. Discuss the tasks to be performed after the approval of a Change Proposal.
Work Allocation: The change is formally documented as a work order or assignment
and passed down to the maintenance team.
Baseline Allocation: The CCB allocates the change to a specific software release
package and assigns a modifier.
Artifact Checkout: Developers check out the necessary work products
(requirements, source code, designs) from the Configuration Management System.
Sequential Modification: Implementation tasks execute systematically, beginning
with updating high-level documents (requirements/design specifications) before
modifying the actual application code.
Verification & Testing: The changes are verified by downstream testers/reviewers.
If verification fails, it rolls back, if it passes, the modified products are checked back
in, installed, and a new baseline is defined.
2. Describe the typical contents of a Work Order. How are the contents determined?
Typical Contents: It includes basic job metadata (date, customer/job name, location,
terms), a detailed Description of Work, a Labor tracking section (recording hours
spent and hourly rates), and a Materials section (quantities, unit prices, and amounts)
to compute a final cost total.
How Contents are Determined: The tasks, schedule constraints, and resource
breakdowns are extracted directly from the approved Change Proposal and adjusted
to match the real-world resource constraints of the development team.
3. Discuss the differences between structured maintenance and unstructured
maintenance.
Feature Structured Maintenance Unstructured
Maintenance
Artifact Complete software Only the raw source code is
Availability configuration documentation available.
exists.
Core Evaluates design specs, plans Directly evaluates code,
Workflow an approach, modifies design, makes raw changes, and
reviews, and then codes. reviews code.
Impact Wasted effort is heavily Highly difficult to
Assessment minimized because change accurately assess how
impact can be thoroughly changes ripple across the
assessed. system.
Regression Thorough regression testing Regression testing cannot
Testing can be safely executed before be done due to a total lack
release. of previous test records.
Origin Cause Results from applying sound Caused by developing
Software Engineering software without any well-
methodologies early on. defined methodology.
4. In the Change Management process, what types of reviews are performed?
Change Request/Proposal Reviews: Conducted alongside stakeholders before
approval. This review ensures the request's details are accurate, checks that missing
system impacts are captured, and confirms that all affected domains understand and
agree to the implementation.
Work Product Technical Reviews: Executed after the modifications are coded.
Affected technical items (revised requirements documents, design descriptions, UI
code, test documentation, user manuals) are put through formal Software Quality
Assurance (SQA) peer reviews. The review team typically features maintainers,
managers, QA representatives, and customers.
5. Describe the typical contents of a Software Error Report. Explain how the contents
would help the process of identifying the cause of the error.
Typical Contents: It must include a unique ID/Bug name, Reporter/Submit date, Bug
Overview (Summary, URL, Platform, Environment/OS/Browser details), Bug Details
(Steps to reproduce, Expected results, Actual results, Description), and Bug Tracking
fields (Severity, Priority, Assigned Developer).
How it Helps Identify Causes: Allows maintainers to exactly recreate the precise
input states and user actions that triggered the error.
• Expected vs. Actual Results: Highlights the exact deviation in logic flow,
pinpointing where calculations or data handling broke down.
• Environment data (Build/Platform): Helps isolate whether a bug is an
environmental configuration issue (e.g., specific to a browser or OS) or a
universal code flaw.
• Evidence Attachments: Appending log file text, error strings, screenshots, or
videos helps display intermittent faults or hidden system behaviors that steps
alone cannot capture.
6. Discuss some of the approaches to debug a program.
Brute Force: The developer attempts to "let the computer find the error". This is
done by analyzing extensive memory dumps, tracing run-time paths, or scattering
numerous print (WRITE) statements throughout the code to generate clues.
Backtracking: A highly common technique where the developer identifies the exact
point of visible failure and carefully traces the source code backward through
execution paths until the root cause is uncovered.
Cause Elimination: A logical approach driven by induction or deduction. The
developer uses "binary partitioning" to systematically isolate all potential causes,
designing tests to evaluate and cross out each potential culprit one by one until only
the true cause remains.