American Public University System Characteristics
StarTeam
StarTeam is a change management system that was developed by a company named Micro Focus. The system’s main intent is to support an enterprise that can service anyone, no matter where they are located. This system is mainly used in my organization as a software development tracking tool that allows you to track the software development lifecycle through the StarTeam Change Request Workflow process. It also allows the program managers and system developers the ability to collaborate on projects and track the change management. Workflow is a term used to describe by which members of an organization completes difficult tasks or projects. This process allows one user to begin a task and pass it along to the next individual for review. Once that user is complete with their portion they will pass the project to another person to complete and finalize the review. This process will continue on until the project is developed, tested and deployed into production.
Characteristics of the Users of the System
The employees that mainly use the StarTeam system are the requirement managers, project managers, project functionals, analysts and system developers. The requirement and project manager’s responsibility is to review and validate the change requirements and update the objective scoring module in the Requirement Management System prior to it being imported into StarTeam. The project functional system evaluates the request, then decides if the request should be pursued. Once the project is given the go ahead, the project goes through the analysts for review and accuracy, then to the software developers to write code and develop the system.
Features and Usage of the System
The StarTeam Change Request Workflow strictly defines the change requests process, enhancing productivity and facilitating management oversight. The workflow also enforces the security it requires to ensure only authorized personnel for specific data can update that data element at the appropriate point in the workflow. All change request in StarTeam are controlled by a workflow. The workflow allows users to track the progress of any change request from when it is entered into StarTeam, to when it is closed. Each department that has a role to perform on the change request is reflected by the “Air Force Change Request Status” of the change request. Upon logging into StarTeam the first thing you see is a listing of projects broken out by system name. When clicking on a project, the main window that pops up is the Cross-Platform Client also known as the project view window. The Content Perspective view is the default view that you see when you open the Cross-Platform Client. On the Cross-Platform Client view is a series of Menus from the folder tree, upper pane, component tabs, and lower pane, and information tabs. The most important menu we use is the Upper Pane menu that consist of a list of items associated with the folder that is displayed in the folder tree. Even though each folder can contain items of different types of projects, the upper pane displays only one type of data at a time. This is where we are able to see where in the workflow process our project is currently at.
The Enterprise workflow process starts at the status of “Enter”. This is a system status that is invisible to the user. The user is automatically advance to “New” for standard workflow or “Technical Analysis” for maintenance workflow. Under the “New” status the change request is imported from another system call Remedy and the Requirements Management System as well as those created manually inputted directly into StarTeam. For all manually created change requirements, the user will enter the required data using the change request form. For all others that are imported, the data required is captured during the import process and the change request is then displayed with an “Air Force Change Request Status” of “New”. The status is reviewed by the Air Force Personnel Operations Agency (AFPOA) Management. Once complete, it is then assigned to an AFPOA Functional and the status is changed to “AFPOA Functional”.
While in the “AFPOA Functional” status the request is reviewed by the assigned AFPOA Functional. Fields such as the Description, Synopsis, Contact, Info, and Application System are validated at this point. This is where any files in support of the change request are checked into StarTeam and linked to the requirement. If the change request affects multiple systems, the AFPOA Functional will coordinate the creation of additional StarTeam change requests. All change requests and requirements arising from the change request will be linked even if they are in different projects originating from this change request. Within this status there are multiple sub-statuses to allow AFPOA to monitor the change request throughout the AFPOA process. Once the change request has moved through the AFPOA process the change request is ready for the business process owners (BPO) input, the AFPOA Functional will then change the request status to “BPO Eval” and inform the BPO that it is ready for their coordination.
In the “BPO Eval” status the BPO will update the weighted factors and review the data entered thus far to ensure the change request accurately reflects the desired system change. When the BPO has finished the actions required, the status is changed to “AFPOA QC” and the AFPOA point of contact is notified that the change request is ready for their action.
While in the “AFPOA QC” status the point of contact performs their final validation of the change request before it is made available for the Project Management Office (PMO) to begin their work on the change request. Once the change request is ready for the PMO, the AFPOA QC changes the status to “Tech Analysis” for the Analyst QC’s coordination. In the “Tech Analysis” status the requirement is assigned to an analyst. The analyst will check-in any supporting documentation and link it to the change request. While in this status there are multiple sub-statuses in order to allow the project management office analysts to monitor the coordination throughout the Technical Analysis process. Once complete, the change request status is changed back to the “AFPOA Functional” for their approval.
At this point, the AFPOA Functional reviews the change request to determine if it is ready for development. When the requirement is ready for development, the AFPOA Functional changes the status to “Development”. During the development step the change request is assigned to a developer by the Developer QC. The developer will complete the required modifications to the code and any documentation will be checked-in to StarTeam and linked to the change request. Once the requirement is coordinated through the developer the change request is developed and ready for testing. The Developer QC changes the status to “Testing” and the Test Manager is notified that the change request is ready for testing. Once the testing manager assigns the requirement to a tester, the tester executes the test plan in accordance to the requirement. There are several Test Phases that the requirement goes through before the change request is ready for acceptance testing. Once the requirement is ready for acceptance testing, the Test Manager changes the status to “Acceptance Testing”, then the Test Manager notifies the AFPOA QC and notifies them that the change request is ready for action.
During the Acceptance Testing step the AFPOA QC changes the Test Phase on the Testing tab to User Acceptance Testing and the Test Status to “Testing Ready”. After testing is completed successfully, the AFPOA QC changes the Test Status to Passed. When the change request is ready for production the AFPOA QC changes the status to “Prod Ready” and notifies the analyst that the change request is awaiting their action. In “Prod Ready” status the analyst prepares the change request and links any files for migration to production. After the migration is complete the analyst will change the status to “Released”. After all the actions are accomplished for production, the requirement’s status is changed to “Closed” and the closure reason to “Released”. That completes the Enterprise Workflow process and the desired system change is released to all users with the new system capability.
Impact of the System
The lack of StarTeam would hamper the developmental cycle and dramatically increase the time it would take to implement a new IT system. StarTeam is the glue that holds the entire system together. It documents all of the steps in the development cycle. All comments and notes are store on the StarTeam server. If someone needs to go back and check to see if a step was missing, that information is available for everyone on the project team to look at and evaluate. Life without StarTeam would definitely cause our employees to do everything manually. Doing things manually will dramatically increase the time spent on a project, as well as an increase in cost to pay the employees for the additional time needed to process each project. An increase of employees would also be required in order to keep track of each project status. Doing things this way will cause a tremendous delay and an increase in the cost of any system enhancement submitted, which in turn can cause mission degradation for the Air Force.
One negative impact StarTeam has, is that the main users of the system are overly-dependent on the system and are not able to accomplish their job if the system was to go down because every change requirement project they are working on is stored in StarTeam. They have no other tracking mechanism they use to track and store the requirements that are being worked.
Conclusion
StarTeam is a critical system to the Air Force development cycle because of what we use it for. I’ve discussed how we used StarTeam through the enterprise workflow process. The first step is for the BPO to submit a needs requirement statement into the Requirement Management System which then flows into StarTeam. Once the requirements needs statement is submitted, the appropriate functional system manger evaluates the request, then decides if the request should be perused. If the project is given the go ahead, the project moves to the next step in the requirements process which is the project development. While in project development, the software developers begin to write code and develop the system. After the development is complete, the project, then moves into the testing cycle. In the testing cycle, bugs and defects are found and fixed. The main goal of testing is to ensure the system works as designed. Once testing is complete the project is deployed with the new or updated system capability. The lack of StarTeam will definitely delay any system enhancement submitted and cause us not to complete our Air Force mission.
References