planning planning planning planning planning planning

Planning

Change Request Tickets

In a maintenance project whenever we receive a change request ticket from the customer, it is first analyzed by the developer. The developer determines whether it is a bug or an enhancement. Sometimes it can be neither. In such cases it is identified as an issue in user understanding. Once an issue is identified as a bug or enhancement then it is logged in the CR log for prioritization.

Impact analysis

Impact analysis is done to help users think through the full impact of a proposed change request ticket. As such, it is an essential part of the evaluation process for a maintenance project. More than this, it gives the ability to spot problems before they arise, so that we can develop contingency plans to handle issues smoothly. It includes answering the following questions (and more):

  • Identifying any existing requirements in the baseline that conflict with the proposed change.
  • What are possible adverse side effects or other risks of making the proposed change?
  • Will the change affect any system component that affects critical properties such as safety and security, or involve a product change that triggers recertification of any kind?
  • How will the proposed change affect the sequence, dependencies, effort, or duration of any tasks currently in the project plan?
  • Will the proposed change adversely affect performance requirements or other quality attributes?

Effort Estimate

Once the Impact analysis is done we estimate the effort to fix the change request in the system. This estimate includes the code changes, testing and other activities such as deployment and release.

next phase: Development
testing testing testing testing testing testing

Testing

Unit Testing

Unit testing is a method of testing that verifies the individual units of source code are working properly. This is done by the Software engineers. The goal of unit testing is to isolate each part of the program and show that the individual parts are correct. A unit test provides a strict, written contract that the piece of code must satisfy. Unit tests find problems early in the development cycle. This reduces a lot of effort on review and rework at a time of QA.

QA

Software is tested from two different perspectives:

  • Internal program logic is exercised using “white box” test case design techniques.
  • Software requirements are exercised using “black box” test case design techniques.

In both cases, the intent is to find the maximum number of errors with the minimum amount of effort and time. A set of test cases designed to exercise both internal logic and external requirements is designed and documented, expected results are defined, and actual results are recorded. When we begin testing we change our point of view. We try hard to “break” the software!

This way we catch most of the bugs/issues before the application actually gets deployed at the client’s server.

UAT

User Acceptance Testing (UAT) is a process to obtain confirmation by a Subject Matter Expert (SME), preferably the owner or client, through trial or review, that the software meets mutually agreed-upon requirements.

The UAT acts as a final verification of the required business function and proper functioning of the system, emulating real-world usage conditions on behalf of the paying client or a specific large customer. If the software works as intended and without issues during normal use, one can reasonably infer the same level of stability in production.
next phase: Release