![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Over the past several decades, we have seen an evolution in enterprise architecture. The evolution has gone from monolithic architectures (COBOL-based programs running on mainframes) to component-based architectures (Java EE and .NET applications) and headed towards Service-Oriented Architectures (transforming the enterprise into a highly interoperable and reusable collection of services which positions it to better adapt to ever-changing business needs).
As the progression of an architectural approach leads to more reuse and separation of concerns, enterprise application development continues to require well-defined processes and more tiers of technology. As a result, some areas of enterprise application development increase in complexity. In enterprise development (Java EE, .NET, etc.), software vendors have made strides to reduce this complexity by providing advanced code generation and process automated tooling, and have simplified complex aspects of enterprise development through usage of proven design patterns and best practices.
However, on the periphery, there is one aspect of enterprise development which may be often overlooked. This is software release management. Some of the challenges facing a Software Release Manager include the management of:
- Software Defects
- Issues
- Risks
- Software Change Requests
- New Development Requests (additional features and functions)
- Deployment and Packaging
- New Development Tasks
Now this may seem reasonable when you are focusing on a single software release of a stand-alone application, but…
Consider working with a highly complex transactional custom development non-shrink wrapped application. The application development team needs to be able to develop new features/functions and release them as generally accepted a half-dozen times a year to the user base (major releases). The application development team also needs to release 40-50 minor releases (additional feature/functions, patches, etc.), in addition to accounting for a mechanism to handle emergency release, which is any modification, update and or deployment of an application (typically a Enterprise Archive file or .ear, Java Archive or .jar, etc.) that has not been planned or scheduled.
Furthermore, the application has dependencies and interdependencies on other applications within the enterprise (in producing a successful build).
What is a Software Release Manager to do?
This article will present an implementation approach using IBM Rational ClearQuest as a foundational component to overcome some of the challenges facing a Software Release Manager.
The intent of the article is not that this is a new challenge or that Rational is the be-all, end-all. The challenge is an old one facing Software Release Managers, but the challenge is becoming ever more complex with global delivery, time pressures and systems integration needs. The solution will be one that focuses less on Rational as a tool and more on Rational as an enabler.
The Software Release Manager can use the Rational tools as an enabler to standard project management processes such as the "Project Management Institute’s Guide to Project Body of Knowledge" (PMBOK). The PMBOK identifies nine knowledge areas:
- Integration Management
- Scope Management
- Time Management
- Cost Management
- Quality Management
- Human Resource Management
- Communication Management
- Risk Management
- Procurement Management
This article will show how the process and tool can help the Software Release Manager enable four of the nine Knowledge Areas. The four areas are Scope, Quality, Communication and Risk Management. The enablement will be through a concept known as the Software Release Record. The Software Release Record is custom record type within Rational ClearQuest that will be described in detail as part of this article.
The remaining five and certain aspects of the other four would be handled by the integration of tools such as Rational Portfolio Manager (RPM) or Microsoft Project, which will not be covered.
Before we get into the Release Record and two closely related state-based record types, the Incident and Work Request, we should first get some definitions as provided in the PMBOK.
Scope Management provides guidance to ensure that the project includes the work required and only the work required to complete the project successfully.
Quality Management includes all of the activities of the performing organization that determine quality policies, objectives and responsibilities so that the project will satisfy the needs for which it was undertaken.
Communication Management employs the processes that ensure timely and appropriate generation, collection, distribution, storage, retrieval and ultimate disposition of communications.
Risk Management includes the processes concerned with conducting risk management planning, identification, analysis, responses and monitoring.
So after all the build up and useful industry accepted definitions, what is the Software Release Record?
The Software Release Record is a state based record type. It captures data elements such as the Release Manager’s name, release number, release type (compliance or discretionary), pre-production deployment date (when the software is deployed to an application server) and the production date (when the software is generally available).
Figure 1. The Software Release Record
Worth mentioning at this time is a standard for software release numbering. It is worth mentioning, because while it appears to be a trivial thing, I have seen much conjecture and debate over the topic. As a Release Manager, standards and process will be key to your overall success. Although the intention is not to present all of the standards and process that are needed to be an effective Release Manager. One of the foundational standards is the numbering convention for releases. Release Numbering should follow an industry standard like the International Organization for Standards (ISO). The figure below provides a standard for numbering and naming releases that is flexible enough to handle most software delivery situations.
Figure 2. The Release Numbering Standard
The Software Release record has a fairly basic workflow to track the progress in the software development lifecycle.
Here is the workflow of the software release record:
Figure 3. The workflow of the software release record
The Software Release record is a parent record to other state-based record types, which provides the Release Manager a 30,000-foot view of the release, but I’m sure you’re asking yourself, how do you manage the 10-foot view?
Taking a step deeper into the process we come upon two additional state-based record types, the Incident and Work Request records.
The incident record type can be classified as a defect, issue, risk, change request, etc and because of the different classifications, the incident record type has a fairly complex state transition matrix:
Figure 4. The incident record
The Incident record type captures the description, headline (a short description), owner name, priority, severity, related software release records, related Incident records and related work requests.
When an Incident record is moving into the Slotted state it must be associated with a Software Release record.
One of the complaints heard frequently from users is when they need to recreate a record because it is tedious to copy and paste the information from the current record to the new record which is easy enough to do but has great potential for errors such as pasting a value in the wrong field or forgetting to copy a value from the original record to the new record. One way to resolve that issue was to give users a way to clone a record without having to manually copy and paste. This not only creates a record and populates it with the data from the original record, but it also creates a link between the two records. The code to clone a record is available via Shmuel Bashan's developerWorks article in the resources section, below.
The code on developerWorks had to be broken up into different scripts to work with the various incident types. The first script (see the code sample attached to this document, contained in clone_record.zip) is to identify what type of incident record the user is attempting to clone which then executes the appropriate additional script to clone the record.
A limitation with a ClearCase/UCM/ClearQuest enabled implementation is that a record can only be assigned in one project/stream/view and only one person can be working on it at a time. However, it is likely that there could be several people working on a change at one time or they could be working on the same change in different streams, in different parts of the globe.
In order to overcome this limitation, one could implement the Work Request record type. The Work Request record could be a state-based record type with the Unified Change Management (UCM) package applied.
The work request record must be created from within an Incident record because many of the data elements are copied directly from the incident record to the work request record and the two records are then linked to each other. The work request record is almost ‘disposable’ in that it has a very short lifecycle and because the user does not have to input much data a work request can be easily created, assigned, worked on, and then closed. Once the developer has completed the coding changes, passed code review and unit tested the changes the record is closed. This will alert the incident manager that the record is ready to be moved to the next state.
The state transition matrix for the work request record is fairly simple:
Figure 5. The state transition matrix for the work request record
Since the Software Release record, the Incident record and the Work Request record are all related there are a couple of points where the system does some validation. When an incident record is moving into the Resolved state the system checks to ensure all work requests that are associated with the Incident are closed and will not permit the record to move into the Resolved state until they are. A similar validation happens when the incident record is being moved into the Closed state since the Quality Assurance team may create a new work request to track their work effort. The other validation happens when the Software Release record is moving into the Deployed state. The system will validate that all associated incident records have been closed before letting the software release record move into a deployed state.
To further exemplify the importance of the concept of Incident record, a sample use case which exercises the full integration among Rational Application Developer (IDE), Rational Clearcase (SCM) and Rational Clearquest (issue tracking) is detailed below.
Figure 6. The Rational Clearcase (SCM) and Rational Clearquest (Issue tracking)
As the illustration depicts above, the Incident record is the enabler which ties the concepts of incidents (defect), incident resolution (defect fix) resolution and issue tracking together.
The use case is as flows:
- Through testing, a software defect has been identified and entered as an incident in ClearQuest.
- Via ClearQuest, the defect manager then assigns the defect to an application developer for further analysis.
- The developer analyses the defect and proceeds to work on a defect fix. The developer accesses and checks code out from the RAD IDE.
- A dialogue box prompts the developer to associate the code checkout with an incident record. The developer identifying the appropriate incident record will tie the potential defect fix and software defect together.
- After the defect fix has been checked into Clearcase, the project manager or defect manager can run reports in Clearquest to monitor the progress and status of defects and issues.
- Deployment and Packaging
- New Development Tasks
One of the artifacts that result from this approach is the Software Release Calendar; the calendar can be categorized as a PMI Communication Management enabler. The easy production of a Release Calendar through Rational ClearQuest by querying the Release Record provides a single view of the releases scheduled for a given time frame (day, week, month, year). Other communication artifacts include but are not limited to include logs (issues, risk, etc.) and reports (defect, change request, etc)
Figure 7. Logs and Reports
- Make sure the development team understands the benefits of the release record and integrated software tools, processes, and project management discipline approach.
- Communicate, communicate and communicate. The Release Calendar is a powerful tool. Make sure people are using it a one of there main source of Release data.
- Use standards where possible, do not duplicate. For example there is a standard approach for numbering software releases, use it.
- Partner with the existing entity or establish a Governance Board for Software Tools and Processes.
- Ensure that your tool administrator understands your vision and the business environment and constraints.
By using the software tools, processes, and project management disciplines discussed the Release Manager can:
- Have a single view of the releases scheduled for a given time frame (day, week, month, year).
- Run complex relational queries based on management requirements and produce Metrics.
- Have access to the most current Release information
- Have a more granular view of issues, risks, defects, deployment requests and change requests to a given release.
- Produce a release calendar
- Move towards a more mature software configuration management process
- Support and enable regulatory requirements like the Sarbanes-Oxley Act of 2002 (SOX), through tracking, history collection, sign-off mechanisms and other programmatic and custom capabilities of the tool.
- Support and enable processes like the Capability Maturity Model Integration (CMMI), through standard processes and metric collection.
- Have any of the his or her constituencies view relevant data regardless of time and geography.
Regardless of the role you play in a Enterprise development project, weather it be the Release Manager, Project Manager, Analyst, Architect, Developer Tester, Deployment Manager or Executive, a strong project management foundation and software that is integrated into the Integrated-Development Environment (IDE), Software Configuration Management (SCM) system and the Project Management tools and development methodology is a must.
The authors would like to thank the following people for their contributions to this document:
- Nicolas Concha is a Senior IT Specialist for IBM Global Services. In his 6 years with IBM, Nicolas has specialized in onshore and offshore delivery roles as a J2EE technical lead and solution architect for custom built SOA applications. His core competency includes estimation, requirements management, design, and construction of systems leveraging both IBM WebSphere and IBM Rational tools. Nicolas complements his strong command of all phases of the project life cycle with his delivery experience across multiple industries.
- Cheri Bergeron is a veteran of the high tech industry with over 15 years of experience in enterprise software companies. Cheri was one of the early employees at Build Forge (now IBM Rational Build Forge), and has held key roles in product management and customer enablement. Cheri has studied the build and release space for many years, and has written several papers on how companies can achieve greater efficiencies through effective build and release management practices.
| Description | Name | Size | Download method |
|---|---|---|---|
| Code snippet example | Clone_record.zip | 2KB | HTTP |
Information about download methods
Learn
- Read also Darrell Schrag's developerWorks article:
Designing a release management strategy with IBM Rational ClearQuest and ClearCase UCM.
- Read about the latest release of the IBM Rational Software Development Platform in the developerWorks article:
Accelerating global software delivery.
- Learn more about the Project Management Institute Body of Knowledge (PMBOK) at pmi.org.
- Visit the Carnegie Mellon Software Engineering Institute's website at sei.cmu.edu.
- Read Tony O’Neill's developerWorks article on SOX compliance using IBM Rational ClearCase and ClearQuest.
- Learn how to clone a defect with attachments in Shmuel Bashan's developerWorks article.
- Learn more about how to benefit from IBM Rational products and technologies in
The Rational Edge e-zine.
- Browse for books on these and other technical topics at the
Safari bookstore.
Get products and technologies
- To learn more about IBM Rational products, visit the developerWorks Rational zone. You'll find technical documentation, how-to articles, education, downloads, product information, and more.
- Find more resources for ClearCase users and administrators in the ClearCase area of the developerWorks Rational
zone, including articles and whitepapers, plug-ins, scripts and triggers; and links to training, discussion forums, product documentation and support.
- ClearQuest users and administrators can find more resources in the ClearQuest section of the developerWorks Rational zone, including ClearQuest hooks, Eclipse plug-ins, product documentation, articles and whitepapers.
- To learn more about software build automation, visit the Build Forge area of developerWorks Rational.
Discuss
-
Participate in the developerWorks Rational discussion forums.
-
Participate in developerWorks
blogs and get involved in the developerWorks community.
David Lipien is a Senior Managing Consultant with IBM’s Global Business Services Financial Services Insurance practice. He has over 10 years of IT Systems Development and Leadership experience. He has expertise in all phases of the project life cycle and experience in numerous roles, including project manager, senior business analyst, and programmer. Specialties include internet-based technologies, wireless and object-based project methodologies.
Jennifer Haines is an IBM Certified ClearQuest Administrator with over 5 years experience. In that time she has worked in various areas of deploying and supporting IBM Rational ClearQuest as well as IBM Rational ClearCase. Her specialties include schema design and development using VB script or PERL, end-user training and on-going support. She is currently a student at DePaul University pursuing a Bachelor of Arts with a Focus on Leadership degree.
Patrick Gan is a senior information technology specialist with IBM Global Services. Patrick's expertise is in Java EE, object-oriented application development, and use of open source frameworks. Patrick primarily works on client engagements, assisting clients in the design and development phases of Java EE application development. He is also involved in the design, development, and maintenance of IBM-specific Java EE based frameworks. He has been with IBM for about six years and has a degree in computer science.
Table of contents
Local resources
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
