Applications and systems, with a commercial lifecycle longer then 2 years and expected volatility around the adoption of the system to its environment, will benefit from the integrated approach of ALM.
- Keeping knowledge intact
- Simple and fast startup of projects
- Continuity and guaranteed development capacity
- Direct handling of issues
- Added value for functional and application management
- Better business and ict alignment, architecture driven maintenance
Based on the ASL (Application Services Library) framework as sketched in the figure below, Chess provides the following activities:
1. Governance supporting your application on the ICT developments strategy, including its lifecycle management.
2. Management supporting your application on the planning, control, cost, quality and service.
3. Operations handling incidents, service requests, renovation and changes.
According to the Chess architectural principles part of these are customers responsibilities (Orange), part is Chess ALM responsibilities (Blue) and some process are a shared responsibility (Shaded). See figure 1.
Activities
Governance
See figure 2
In the governance process, Chess addresses the practices lifecycle management and ICT Developments strategy.
Lifecycle management
Chess develops and maintains your application according to strict development and test procedures. These are documented in the software development plan. Each year, Chess will review these procedures. Also the software code quality can be reviewed by the Software Improvement Group (SIG) per release. Together with SIG, the remarks in the reports are assessed and transferred into issues in ChessForge, and consequently will be planned in the next releases.
Chess guards the architecture and the corresponding way of documenting of JSTD16 by evaluating and updating the OCD and SSDD documents. See figure 3
Chess guards and documents the change process and secures that all change requests are justified against these Standards. The Change Control Board will inform the Architecture Board on foreseen architectural changes.
ICT Developments strategy
Chess also gives advice on advancements in technology and its implications on the application. Newly available software versions of Java components, browsers, databases, OS, or new (‘faster’) hardware or external interfaces that are modified or new versions of the Standards that may affect the application.
Management
See figure 4
Chess will together with you set up a Release Calendar for the next 12 months. This Release Calendar acts as the reference for all the work that has to be done. Also the team staffing is based on the Release Calendar. Revision of the Release Calendar takes place on a quarterly basis. This is done in the Change Control Board.
Chess is responsible for managing the product team. This means that the staff can optimally be assigned to maintenance and development tasks. Chess is also responsible for scaling the team up and down.
Chess will report on each activity (maintenance/support or development) that is executed. This report contains the status of the activity as well as the hours spent.
Chess is also responsible for:
• Change- and release management
• Version- and configuration management
Operations
See figure 5
Chess will be responsible for development and corrective maintenance/support of the application.
In the development cycle, Chess investigates the impact (both technically and financially) of ‘Requests for Change’ on the application. An impact is established in two steps:
1. A Quick Scan to see if it is the change is feasible, and what the costs are. Based on that information, you decide for a (see 2).
2. Full Elaboration of the ‘Request for Change’.
After approval, realization starts:
• Requirements documentation
• Application design
• Coding
• Unit, integration and regression testing
• Delivery
And finally:
• Acceptance
• Implementation.
In the maintenance cycle, Chess will execute the 2nd –line service desk according to the Software Support Plan, see Error! Reference source not found.:
• Support and service requests
• Service level management
• Incident- and problem management
• Incident- and problem solving, corrective maintenance
• Monitoring applications by continuous checking of automatically generated e-mails, and taking appropriate actions if required.
• Maintaining the development and test environment, and the issue tracking system ChessForge (see figure 6).
Deliverables
Governance
• An annual review by Chess on the application covering among other aspects the total costs of ownership, changes in IT and in your specific domain standards influencing the application, capacity management, a technical review of all tools and frameworks used in the application.
• Chess also provides impact analyses on new functions or rollouts in advance as input for future releases.
• An updated architecture: OCD and SSDD approved by the architecture board.
• An optional independent SIG report for each release on the quality aspects of the application.
Management
• An annual release calendar that is updated every quarter based on input from your management / board.
• A set team consisting (minimally) of the product lifecycle management team capable of handling the releases specified in the release calendar.
• A monthly report on each activity executed, including a service level management report.
Operations
• 2 to 4 software production-releases per year including all documentation
• Monthly reports on the day to day operations of your application
• Tooling for registration of incidents and Change requests
• Incident reports
• Estimates for small changes
• Software executable and configuration files
• Software source code
• J-STD-016 documentation:
o Software Requirements Specification
o Interface Design Description
o Software Design Description
o Database Design Description
o Software Development Plan
o Software Test Plan
o Software Test Descriptions
o Software Test Report
o Software Version Description
o Software Center Operator Manual
o Software User Manual (by the Customer)
• Development and test environment, issue tracking system ChessForge.
Organization
Organization chart
The organization consists of two operational groups, maintenance and development. The Change Control Board does the daily management of these groups, and reports to the Project Board.
The Change Control Board will inform the Architecture Board on foreseen architectural changes.
Team
The basic ALM team is responsible for all tasks under governance, management and operations and has software development capacity.
The basic team development capacity can be extended with no additional overhead to a maximum of app. 6000 hours with 500 hours test management. Exceeding this will lead to extra architecture and management capacity.
The exact increase of the basic team will be planned on a yearly basis, lead time during the year for decreasing or increasing will be 3 months.
Meetings
A Governance meeting is held bi-annually with the project board. Topics are:
• The release calendar
• Architecture in combination with the Architecture board.
• Bi-annual software quality monitoring reports (optional by SIG)
• Bi-annual service report
A governance meeting is also held in case of an escalation.
A Management meeting is held quarterly by the Change Control Board. Topics are:
• The release calendar
• Software quality monitoring report per release (optional)
• Project plans
• Dynamic team staffing
Operational meetings are held monthly by the Change Control Board and the operational teams. Topics are:
• Service level report
• Development progress report |
 |
Figure 1
|
 |
Figure 2
|
 |
Figure 3
|
 |
Figure 4
|
 |
Figure 5
|
 |
Figure 6
|
|
)
)
)
)
)
)