CCIT leads, manages, develops, delivers, and support high value custom software solutions across multiple domains of knowledge & practice in achievement of its clients' goals. In order to accomplish this so as to achieve CCIT’s goals of highly-available, secure, stable, and cost-effective solutions, CCIT’s software development team maintains a versioned approach to software development.
As many disciplines are involved in the development of its proprietary software solutions, support for these issues is cross-functional and requires the close cooperation of CCIT’s team members. CCIT is committed to providing timely and comprehensive solutions to issues in a manner proportional to business need and potential or actual business impact for applications still within their defined support lifecycle.
With CCIT’s software development process, functionality is released in ordered, packaged deployments known as, well, “releases”. Releases are scheduled based upon resource availability and the time necessary to execute a successful project given the functionality to be delivered within a defined release.
-
Major Releases typically contain code re-writes and new development including sweeping architecture changes, high-value requests for enhancements, and significant user interface changes. Major releases are typically delivered in 6 to 12 month cycles.
-
Minor releases typically contain code optimizations, bug fixes, high-value/low-risk requests for enhancements, and minor user interface changes. There is limited architecture development in minor releases. The changes must be accomplished using the architecture deployed in a former major release. Minor Level Versions are released in 3 to 6 month cycles.
-
Revision releases are provided on an as needed basis and typically contain security fixes, baseline functionality fixes, and critical bug fixes. The critical label refers to defects that result in major loss of baseline function for which there is no workaround. Revision releases can be thought of as patches to existing functionality.
All releases go through testing and quality assurance prior to release.
Software development requests fall within two broad categories:
-
New feature requests are requests for enhancement to or a modification of the existing functionality of an application.
-
Support requests are requests concerning defects of delivered functionality within an application.
New Feature Requests
New feature requests are accepted via CCIT’s web and email request submission interfaces whereupon they are given a severity level of “enhancement” within CCITT’s Bugzilla knowledge management system.
With new feature requests, no service levels exist for acknowledgement, assessment, or incorporation of a new feature request.
Typically, during client consultations regarding functionality to be incorporated into forthcoming releases, CCIT will present all new features or enhancements received. Working with CCIT, the application’s clients would prioritize potential features or enhancements with respect to the application’s lifecycle, business need, and potential value.
If accepted for investigation, CCIT will assess the feature and the scope of work required to incorporate the feature. The assessment of the feature and a recommendation of how best to incorporate the feature amongst an application’s projected release schedule of major and minor releases.
If accepted for incorporation by the client group, it will be assigned to a future release and a schedule for the release will be established.
Support Requests
Support requests concerning delivered functionality are prioritized and assigned on the basis of actual or potential business impact. Our objective is to find a configure change, code change, or workaround that will provide a satisfactory solution. In the case where it is technically impossible to meet these targets, we will work with you to escalate the issue and establish a project plan.
The following chart defines how CCIT prioritizes and responds to software development support requests.
Severity Levels
Critical |
DescriptionThis is the highest level of severity and should only be assigned to issues that require immediate attention because they threaten business critical processes, involve major outages, or pose major safety and security issues. CriteriaA critical issue is one which satisfies any of the following criteria:
Service Level TargetsWithin or outside of normal business hours:
Target Release for Solution
Appropriate Request Submission InterfacesWeb & Phone |
Major |
DescriptionMajor issues are those that pose a serious impact to business processes if not addressed quickly. CriteriaA major issue is one which satisfies any of the following criteria:
Service Level TargetsWithin or outside of normal business hours:
Target Release for Solution
Appropriate Request Submission InterfacesWeb & Phone |
Normal |
DescriptionThis represents the ‘typical’ problem, and should be the most frequently assigned level of severity. CriteriaAn issue which satisfies any of the following criteria:
Service Level TargetsDuring normal business hours:
Target Release for Solution
Appropriate Request Submission InterfacesWeb & Email |
Minor |
DescriptionAn issue creating minor business impact as it does not threaten or impact productivity. CriteriaAn issue which satisfies any of the following criteria:
Service Level TargetsDuring normal business hours:
Appropriate Request Submission InterfacesWeb & Email |
