Requests for Change: Change Management

Change Management is the process of managing requests to change the software after it has been deployed into production. This article discusses the concepts associated with change management including the change control manager, the change management request and the change management process.

What is Change Management?

Change management is the methodology used to manage changes to software in production. There are several reasons why software changes after it has been released into production:

1.    If a user uncovers a defect, not encountered during testing, a Request is submitted to fix the defect.

It may seem that if testing was performed on software defects should not be encountered. However, this thought is not true. When a test case is created, depending on the software functionality, variations of the test items are used to ensure the software behaves the way it is supposed to. For example, there may be a test case designed to test various scenarios associated with adding a customer order. For example, a requirement may state that “if, on Tuesday, a customer’s order is $100 or more the customer shall receive a $10 discount on the order.” This one requirement requires multiple test scenarios to ensure the system behaves as stated. For example, one test scenario may include creating an order, on Tuesday, that totals $99.99 to make sure a discount isn’t added to orders below $100. Another scenario may test adding an order on Monday to make sure the $10 discount isn't added to orders over $100.00. The tester will also need to create a test scenario to make sure the discount is added, to orders over $100.00, on Tuesday. The tester will even create scenarios that test adding orders over $100 for Thursday through Sunday to make sure discounts are only added on the correct day. This is necessary because there are various ways the requirements can be programmed. The programming logic used to create the procedure that calculates and applies the discount is what drives how the software will behave when tested using different scenarios. Therefore, it is possible for a tester to test the software and the user may still uncover a scenario that wasn’t covered during testing.

2.    If a user submits a Request identifying required software functionality that is missing; a request to enhance the software is submitted.

Let’s say all of the requirements have been gathered. Everyone agrees that all of the requirements are listed. The stakeholder prioritizes the requirements. However, a requirement that was supposed to be implemented in the first release was overlooked. For example, the “delete order” functionality was omitted. A customer then calls the Help Desk and requests to delete an order; but the functionality was not included in the current release. Although there is an upcoming planned release; an immediate enhancement may need to be performed to support customer satisfaction.

3.    A menu or button name or other text built into the software may be misspelled. A Request will also be submitted to request this change.

The Change Request

 

The Change Request (CR) is a form. An organization may use a paper CR or an online CR. IBM's Rational ClearQuest is the most commonly used Change Management software. However, online CRs are more practical because the software can ensure the process is properly executed for each request. The CR provides information about the software product to be changed, the type of change requested (i.e., enhancement, defect, etc.), details about the change, the name of the person requesting the change, etc.

Typically, during the planning phase of the project, a plan is defined regarding how the software change will be managed. This information is usually outlined in the Configuration Management Plan, which is part of the Software Development Plan. Configuration Management and Change Management typically go hand-in-hand. This is because Configuration Management involves concepts used to assign a unique identifier to software builds and artifacts so all items related to a particular version of software may can be identified.

The Change Management Process

Change Management is implemented as part of the Help Desk Support services. Often help desk software (such as IBM's Remedy) is used along with Change Management software. The Help Desk software manages problem requests. However, the problems may not require change to software. This is why the two separate software systems are used. For example, a user may encounter problems using software because the user may not understand how to properly operate the software. The user may then call the Help Desk. The Help Desk Specialist can instruct the user on how to perform the task properly and the Help Desk ticket is closed. Change Management software, on the other hand, captures requests for change or CRs. A Help Desk associate may enter the CR. Or, depending on the organization, business analysts and end-users may enter CRs.

The CR is associated with statuses so it may move through a process. This approach ensures the appropriate notifications are sent to the applicable people to alert them about the CR and related activities. The most commonly used statuses are as follows: Submitted, Postponed, Opened, More Information, Rejected, Assigned, Resolved, Test Failed, Verified, Closed.

When a CR is entered it is assigned a "Submitted" status. After the Change Control Board (CCB) accesses the CR it moves to the Open, More Info, Postponed, Rejected, or Closed state. Following is a brief description of these statuses:

• Open: The CR will be assigned so the software can be changed.
• Postponed: The change will be made to the software during an upcoming release.
• More Info: This status is assigned if the Business Analyst must gather additional information from the submitter.
• Rejected: The CR is assigned this status if the change is not approved. For example, if a duplicate CR is  found. When this occurs a second review is conducted to confirm that a duplicate exists. If it does the CR is Closed.
• Assigned: The CR moves to this state when a software developer has been assigned to make the changed.
• Resolved: Once the changes have been made the CR is marked as Resolved so the software change(s) can be verified.
• Verified: The software change(s) have been verified through testing. If the change(s) pass(es) testing the build is incorporated into a release and deployed into production. The Release build is verified again to make sure everything works fine. (Production testing is particularly important because the production server will usually have a different name from the test server. If an improper server name is used some of the code will not work. And, the production server may be configured differently from the test server, which will also cause problems.) If everything works fine the CR is closed. If there is a problem additional work is performed and the CR is verified again.
• Test Failed: Once the status is changed to resolved the changes are verified through testing. If the change fails testing the status of the CR is changed to "Test Failed". Additional changes must be made; and, once the software is tested. If the changes pass testing the status is then changed to Verified.

Change Control Board

The Change Control Board (also referred to as the change control manager) is responsible for ensuring a cohesive Change Control process is used. The Change Control Board is made up of a group of people who represent users, developers, testers, project managers and executives. The job of the Change Control Board is to review the CR to ensure the request is appropriate and necessary. A Chair is also assigned to head the Change Control Board. The Chair is used to handle problems and enforce the Change Control Board's decisions.

The amount of work performed by the Change Control Board is usually driven by the size of the organization. For example, a large organization that has multiple applications may need to review information from the Software Architecture before making a decision. The Change Control Board will request a report that shows software capabilities for each software component. Each software components is associated with the name of the software so the Change Control Board can tell what software offers what capabilities:

• Time Management Software
• Software Component: Projects
• Capability: Add Projects
• Capability: Update Projects
• Capability: Search Projects
• Capability: Add Project Tasks
• Capability: View List of Project Tasks
• Capability: Update Project Tasks
• Capability: Delete Project Tasks

If a request is made for software capability that already exists for the same software further clarification, regarding the request, is requested. In addition, the CCB may ask for an Impact Analysis Report. If this occurs a Tester is asked to create the test cases and test items. The test cases and test items are traced so the amount of work can be properly accessed by the CCB. The CCB takes costs, risks and other organizational objectives and concerns into consideration before making a decision. If the CCB agrees to the change it will also identify when the change should be made (i.e., now or a specific release).

Summary

Change management is the methodology used to manage changes to software in production. The Change Request (CR) is a form. An organization may use a paper CR or an online CR. IBM's Rational ClearQuest is the most commonly used Change Management software used to submit and manage change requests. The Change Control Board is also referred to as the change control manager. The change control manager is responsible for overseeing the overall Change Control process.

Each Change Request must move through the defined Change Control process. Depending on the organization the process may be as follows: The Submitter submits the Change Request. Next, the Change Control Board Reviews the request. If the change is approved the software developer makes the change; and, the technical writer and/or technical trainer updates related guides. Once the change is completed the tester tests the change. Lastly, once the change has successfully passed testing it is deployed into production as scheduled and the release notes are distributed to users.

Software Design with UML - Object Oriented Programming Intro

This blog article covers basic concepts associated with designing a business application. It walks through the most common Unified Modeling Language (UML) diagrams used to design business applications. The Unified Modeling Language is managed by the Object Management Group (OMG) at http://www.omg.org. This site contains additional information about UML and the diagrams discussed below.

The article assumes you are an IT professional familiar with basic software design concepts. The last part of the article provides a brief overview of object oriented programming primarily to provide insight to the Class diagram and the meaning of a class.

The System We Are Going to Design

 

In this article we are going to design part of the Time Management System (TMS). IT Department Staff will use TMS to submit the hours they spend on a customer's project. Project Managers will use TMS to Sign-Off on Timesheets. Human Resources will use TMS to print out a copy of each employee's timesheet for the employee file. The following Business Process Flow Diagram shows the current process used to process timesheets. In the following diagram the timesheets are ultimately sent to the Accounting Department for customer billing, but that aspect of the process is outside the scope of this article.


 

Features, Use Cases & User Stories

In this section we will take a quick look at the features and use cases we will use to model. We will also translate our use cases into user stories; and, take a look at how we can model user stories.

Feature	Description
FE1. Manage Timesheets & Approvals	This feature manages all requirements associated with creating a timesheet, submitting a timesheet, editing a timesheet, approving a timesheet and disapproving a timesheet.

Following is a partial list of use cases for TMS. These use cases would be grouped using FE1:
 

Use Case Name	Actor	Flow
UC1. Submit a Timesheet	All IT Department Staff	1. Add a new timesheet. 2. Complete the timesheet. 3. Click the Submit button. The timesheet is submitted.
UC2. Sign-Off On a Timesheet	Project Managers	1. Select a timesheet. 2. Review the timesheet. 3. Click Approve.  4. Submit the timesheet. The timesheet is marked as approved. Alternate Flow:  Branch at step 3. 3. Click Disapproved. 4. Submit the timesheet. The timesheet is marked as disapproved.
UC3. Add a Project	Project Managers	1. Select Projects from the menu. The Projects page displays. 2. Click Add Project button. The Add Project page displays. 3. Complete the fields on the page. 4. Click Save. The project is added.
UC4. Add Project Tasks	Project Managers	1. Select Projects from the menu. The Projects page displays. 2. Select a project. The Project Details page displays. 3. Click Add a Project Task. The Add a Project Task Page displays. 4. Complete the fields on the page. 4. Click Save. The project task is added and associated with the selected project.

UML diagrams provide a way to visually communicate software functionality to developers. An IT professional's design skills should include the ability to translate requirements into a cohesive software design that includes classes, the relationship between classes as well as interaction and communication among objects. As well as the state of an object as events occur.

Use Case Diagram

Use Case Diagrams provide a visual way to depict the use cases that make up a system, the actors that interact with the use cases, and the relationships and type of relationships (i.e., extends, includes) between use cases. Below is a partial TMS Use Case Diagram.

Understanding what use case extends another use case; or, what use case includes another use case is very useful. For example, since we know Submit Timesheet includes Add Project Tasks we know one cannot be implemented without the other if full functionality is to be achieved for the including use case. For example, if we implement the Submit Timesheet use case without the Add Project Tasks use cases users will not be able to assign their hours to a project task. These use cases should be prioritized in a way that ensures they are implemented either in the same release or releases in close proximity to one another. If the Submit Timesheet use case is assigned a "High" priority the Add Project Tasks use case should also be assigned a "High" priority. This would be done to ensure they are implemented within the same release or releases in close proximity to one another.

Note that there may be occasion for the stakeholder to agree to reduced functionality to get a part of the system into production as quickly as possible. If this is the case, the two use cases may be assigned different priorities and implemented during separate releases. These releases may or may not be in close proximity to one another.

An extends relationship does exactly what it says. It extends the behavior of a use case such that additional actions can be performed using the extended use case. In the above diagram Sign-off on Timesheet extends Submit Timesheet. This means, the Sign-off on Timesheet inherits most or all of the same capabilities as the Submit Timesheet use case. However, the Sign-off on Timesheet has additional functionality. In this example, the extended behavior is the ability to approve or disapprove a timesheet.

User Story Diagram

User stories can be diagrammed as well. Some developers and project managers may need to see diagrams to reinforce design information. The following diagram shows one way user stories can be captured using the use case diagram concept.

Class Diagram

The Class Diagram shows the classes used to build the application. The class diagram includes the behaviors of the class, shown as operations. For example, the Timesheet class includes the following operations getDate(Today), which is an operation used to return today's date to the timesheet. Each class also includes the attributes of the class. The attributes of the class are implemented as properties of a class. The properties of the class may implement business logic. The operations and the attributes may or may not be implemented in the same class, during development. It all depends on the approach being used to build the software. For example, web services versus regular web classes.

Sequence Diagram

The Sequence Diagram is used to show communication messages between the components or instances of the classes that make up of the application. The TMS Sequence Diagram below shows the communication between the user and the Timesheet, Employee, Projects and Project Task objects.

 

State Machine Diagram

The State Machine Diagram captures the state of an entity in response to events that affect the entity. The following State Machine Diagram shows the state of the timesheet as events (the text beside the arrows) cause the state (the green rectangles) to change.

Activity Diagram

The Activity Diagram can be used to model the flow within use cases. In the below example, the activity diagram reflects the activity as it pertains to the Timesheet. The forks in the flow capture the alternate flows within the use case. Alternatively, the Activity Diagram can also be used to model user interface screen flows and business process workflows.

Object Oriented Programming (Objects, Events, Methods And Properties)

Understanding Object Oriented Programming concepts is necessary to effective design business applications--particularly complex systems. The following paragraphs provide a brief overview of object oriented programming concepts.

In object oriented programming classes are used to build applications. For example, when you navigate to Facebook and click the Post button, that button was created from a Button class. To create the button object from the button class the developer must create a copy of the button class. The programming language used defines the code that must be written to create the copy. The most important thing about creating a copy of a class is that the copy must be given a unique name. Once a developer creates a copy of the class, also called an object, the developer can customize the object. When the developer creates a copy of the class the developer has actually created an instance of the class.

In .NET all classes are grouped by namespace. Therefore, if the developer wants to find a class he must look under the appropriate namespace. In the following example the the button class is located in the system.web.ui.webcontrols namespace. This makes sense because, in this example, we are building a web application. The buttons and other items on a web page are called controls. 

Lets look at what a developer would do to build a web page that a user can interact with. In our example, the developer is going to build the following:  1. a Login page; 2. a field so users can enter a user name; 3. a field for the user's password; 4.a button so users can submit the login credentials; and, 5. a cancel button in case the user changes his/her mind and wants to clear the username and password fields (also called textboxes).

The developer needs to create 5 objects. But, the developer only needs to use 3 classes to create the objects. The developer begins by creating an instance of the Page class and calls it frmLogin. Both the user name and password fields are created from a control called a textbox. Therefore, the Developer creates two instances of the Textbox class.  He calls the first Textbox instance txtusername. The second instance is called txtpassword. Lastly the developer needs a submit button and a cancel button. The developer creates 2 instances of the Button class. The first instance of the Button class is called btnSubmit. The second instance of the Button class is called btnCancel.  (Note that an IDE does not care what you call an object. You could call an object Goofy or SpongeBob and the IDE would accept those names.)

The developer now has 5 objects. The first is a frmLogin object, which is the login page. The second is called txtusername, which is the object that provides a way for users to enter a user name. The third is called txtpassword, which is the object that provides a way for users to enter a password. The fourth is the btnSubmit button, which is an object that lets users submit the  username and password to be validated for accuracy. The fifth is called btnCancel, which is a button object users can click to clear the username and password from the two textboxes.

Properties of a Class

All classes have properties, procedures (including methods) and events, which a Developer can access once an instance of the class is created. In our example, we've already created the instances so we can proceed to set our properties. If we want the Submit button to say "Submit"; and, we want the Cancel button to say "Cancel" we can set the Text property of each button. In VB.NET or C#.NET our code would look something like btnSubmit.Text="Submit" to set the text for the btnSubmit object. Next, we set the Text property of the Cancel button (we called btnCancel). Our code looks similar to btnCancel.Text="Cancel". Doing this causes the user to see two different buttons (a Submit button and a Cancel button) that, from a programming perspective, were developed from the same button class. The following list includes a few of the properties associated with the Button class.

Properties for the Button Object (or Control)

 

Methods & Events

In addition to properties, a class has methods and Events. A method is an existing block of code, also called a procedure, that can be called so an object performs an action. For example, the textbox control has a method called "Clear". When the "Clear" method is called all text is removed from the textbox. In addition to properties and methods, developers can also use an objects Events to add additional behavior to a business application. Each object has a list of events that apply to it. Many events vary from object to object. Also, what happens when the event occurs depends on code written by the developer. For example, a Button object has a Click event. The Click event occurs when the Button object (or control) is clicked. If we want a new page to display when a user clicks a button, we add the applicable code to the button's click event.

 

Summary

The Unified Modeling Language (UML) is commonly used to model applications, particularly complex business applications. This article discussed the Use Case Diagrams provide a visual way to depict the use cases that make up a system, the actors that interact with the use cases, and the relationships and type of relationships (i.e., extends, includes) between use cases. It also highlighted a way in which user stories can be modeled. This article also discussed the class diagram, which includes the behaviors of the class and the behaviors referred to as operations. And it discussed the the State Machine Diagram, which captures the state of an entity in response to events that affect the entity. Lastly, it provided an overview of the Activity Diagram, which can be used to model the flow within use cases as well as user interface screen flows and business process workflows.

If you are interested in learning more about programming following is a list of books you may consider purchasing. Once you get the books, you can download the code samples at: www.murach.com/downloads/index.htm.

1. Murach's Java Programming
2. Murach's ASP.NET 4 Web Programming with C# 2010
3. Murach's JavaScript and DOM Scripting
4. Murach's HTML5 and CSS3