IBM Maximo Software Development Life Cycle

A new version of software requires the review and approval of a cross functional, executive Marketing Management Team (MMT), with representation from Development, Sales, Support and other key functional areas.    Documents that require executive level approval for a software development project include: Commitment Pitch, Go-To-Market Readiness Review (GTMR), and Offering/Launch Readiness Review. In addition, Quality Certification is required before a product release.

Project Content is controlled through the offering team, and offering plan documents. Only authorized people (developers) are allowed to make changes to source, or add new source files. Large scale and project level changes are analyzed by the project leadership team, and smaller scale changes are analyzed by cross functional scrum teams.  Potential changes are reviewed for reason or need for change, risk of breakage, impact of potential breakage, reviews and testing needs, documentation requirements, and action plan to roll out the change.

Major changes in a release are authorized through formal updates to the Commitment Pitch through Sense and Respond Playback reviews. Low level adjustment, enhancements, and improvements based on user feedback are made by the agile development team in conjunction with product management.

Changes control is applied throughout a Maximo product’s lifecycle.  Release change control is described by SOP AM050

Passport Advantage (PPA) tracks the products that a customer has purchased.  Since we do not sell products by version, PPA only tracks the product(s) and entitled features (ie. Maximo). 

New releases which deliver new (changed) capabilities, are announced to the field and to potential clients through the standing IBM product announcement process, and detailed change information is documented in release documentation.

Version.Release.Modification.Fixpack

• Version: Version indicates a separate IBM licensed program that usually has significant new code or new function. Each version has its own license, terms, conditions, product type number, monthly charge, documentation, test allowance (if applicable), and programming support category.

• Release: Release indicates a distribution of a new product or new function fixes for an existing product.

• Modification: Modification indicates new function is included in the maintenance deliverable, outside an announced V.R delivery.

• FixPack: A fix pack is cumulative, i.e. contains all the fixes shipped in previous maintenance to the release including previous fix packs. Fix pack level is indicated by the 4th number in the product version (V.R.M.F, i.e. 7.1.1.1) as an internal name to be recorded by the maintenance install tool.

IBM projects utilize Agile software development lifecycle methodology.  Agile is the use of continuous stakeholder feedback to produce high quality consumable code through use cases and a series of short time-boxed iterations. It has four key features: stable code, stakeholder feedback, self-directed teams and sustainable pace.  The end of each iteration produces stable code that is meaningful to a customer, and meets quality criteria.

When work begins on a specific Epic/Story, Tasks will be created for the different functional areas. The design will be written during the Sprint, either in a separate attached document, or directly in the Story or Task. Any feedback from the testers will be incorporated into the design before the Story can be closed.  A test case execution history can be found in either RQM or RTC.  In RTC line items are mapped to Epics and Stories that show executions of test cases. Test Case tasks are marked DONE when they have passed.

Requirements come from many sources and include Architectural Needs, Strategic Items, Known Requirements from Customers and Serviceability Requirements. These are considered Requests for Enhancements (RFE’s). RFE’s are then prioritized by Offering Management for upcoming releases. The development team utilizes the Agile Methodology, which is implemented using Rational Team Concert.  Those requirements that are accepted for a release can either generate an Epic or Story within an existing epic.

The requirement types can vary by release, but any requirement types can be addressed in a release. Some types, like performance, accessibility, serviceability and platform currency, are addressed in all releases.

Development - Programmer writes the code with the goal of delivering the functions as specified in the design document, or other appropriate document, such as a bug report, following the coding and documentation guidelines located on the Maximo internal development web site.

Debugging - As a part of Agile process, code reviews are tasks and must be executed to complete a story.

After the review is completed and approved by the team the review document is checked into our change management system (RTC). The review document is attached to the story and the task the review was performed.

Test execution may end when:

• 100% of Scenarios have been attempted or invalidated (deferred/permfailed)
• 95% of valid Scenarios have executed successfully (completed records), or Development must provide a targeted date for defects to be addressed, and the Verification team can re-test within 1 week of receiving the fix.
• All Severity Blocker, Critical and Major regression defects found during the test phase are fixed and closed.
• All Severity Normal and Minor regression defects are either closed or agreement to defer the issues.
• Any defects not found and not marked by Test case can be addressed during the Regression phase.
• Any severity Blocker, Critical or Major defects uncovered and either not fixed nor closed will be reviewed and marked with a resolution plan with the agreement of the development and test managers and may be addressed during the Regression cycle.
• Completion of a formal final assessment (Quality Certification or equivalent) and all of the objectives of the Quality Certification or equivalent are met.