| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
|
Objectives:
The purpose of the Determine Code Version Control Method activity in the Develop & Test phase is to identify how developed code will be managed so that integrity and security of the development effort is maintained.
This activity is a subset of Integrated Change Control, also known as Configuration Management. Reference Project Control: Integration Management.
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
Objectives:
The purpose of the Develop & Review Content activity in the Develop & Test phase is to ensure that all customer-facing output conforms to StorageTek standards and has been reviewed by the business area and approved by the StorageTek Legal department (if needed) prior to implementation so that the product aligns with the consistent and professional StorageTek branded image as well as business area strategies and direction.
This activity addresses the need to clearly understand the business requirements for content. Content includes any text, pictures, instructions, etc. contained within a user interface or a web page. Content is static in nature. Content is NOT data populated from a system.
Customer-facing content (output) is any project deliverable that could be seen by StorageTek’s external customers and/or suppliers. This includes (but is not limited to) web pages, quotes, invoices and contracts. Content on customer-facing documents with legal implications, such as a notice on a web page that indicates pricing is subject to change without prior notice, must be approved by the Legal department.
If Legal approval is required, be sure to allow plenty of time in the schedule as it can take weeks to get something through Legal.
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
Objectives:
The purpose of the Develop Product activity in the Develop & Test phase is to construct the identified project solution so that the product meets all requirements and project objectives.
This activity involves technical construction of the product, including data conversion, system code, releases, installations, interfaces, reports, user interfaces, and supporting documentation. The product is the sum of all that is built and delivered as part of the project. This activity also includes implementation of the architectural plan as signed off by Green Team members. See Green Team Process for more details.
Develop Product, Conduct Unit Test, Perform Code Reviews and Conduct Functional Test activities are iterative in nature and are repeated until successful functional test results are achieved. It is also important to note that projects using an iterative approach may perform these activities several times throughout the project life cycle as they work through each iteration.
If this activity leads to any design changes, the project team needs to have the baseline design re-approved.
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
The purpose of the Conduct Unit Testing activity in the Develop & Test phase is to ensure all work units operate as designed, without error, so that there is confidence that the individual pieces work as expected and meet the required functionality.
This activity involves the individual component testing to verify functionality and expected results. This activity includes development of unit test cases, unit test design, execution, capturing and analysis of results, rework to fix defects and retest. Components include application changes and any new functionality, interfaces and data conversion. Additional components are hardware and software installs, database setup and security access.
Develop Product, Conduct Unit Test, Perform Code Reviews and Conduct Functional Test activities are iterative in nature and are repeated until successful functional test results are achieved. It is also important to note that projects using an iterative approach may perform these activities several times throughout the project life cycle as they work through each iteration.
Execute and test every line of code or widget for the work unit
Test the work unit for all of the following
all conditional and compound conditional variations
test loop limits
error handling
file and data interaction including empty and multiple record files
all user interaction including, but not limited to, screen layout and navigation, numeric and alpha numeric fields, list boxes, drop downs, scrolls, etc
Usability test
human factors, navigation, presentation
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
|
The purpose of the Perform Unit Test Code Reviews activity in the Develop & Test phase is to validate that code is documented, accurate, efficient and supportable so that rework costs are reduced and quality of project deliverables is increased.
This activity involves the review of project-delivered products by team members and technical experts to validate that code is document, efficient, accurate and supportable. Unit Test Code Reviews identify defects in project deliverables early in the project’s System Life Cycle. The earlier defects are identified, the less costly it is to take corrective action.
Unit Test Code Reviews are held by the project team to ensure that project deliverables meet functional and technical requirements, adhere to documented standards and procedures, are accurate and contain the appropriate level of detail. Participants of the review assume the responsibility for the overall quality of the deliverable by assisting in defect identification. The author of the deliverable is responsible for the implementation of the findings and recommendations of the Unit Test Code Review participants.
Unit Test Code Reviews are scheduled at specified points, based on project events (i.e. milestones) or time passage. Periodic and event-driven reviews for the project are included in the project schedule. As unplanned events, such as changes to requirements or conflicts not resolvable at lower levels, occur during the life of the project, additional event-driven reviews may be scheduled. These reviews will be scheduled on an as-needed basis.
If there are multiple deliverables completed at approximately the same time by the same author, the author should determine which deliverables are similar in nature and include those deliverables in one Unit Test Code Review session. This will help determine the type of skills necessary for the review participants to possess in order to effectively review the material (for example, review of source code may require participants to have programming experience at a minimum).
Develop Product, Conduct Unit Test, Perform Unit Test Code Reviews and Conduct Functional Test activities are iterative in nature and are repeated until successful test results are achieved. It is also important to note that projects using an iterative approach may perform these activities several times throughout the project life cycle as they work through each iteration.
There are various roles for participants to perform in the Unit Test Code Review process. The following is a brief definition of the responsibility of each role.
|
ROLE |
RESPONSIBILITY |
|
Developing Author |
Responsible for initiating the review, preparing the review package, and making any necessary changes to the deliverables. The author will work with the Project Manager or Technical Delivery Manager to fill the Unit Test Code Review roles with appropriate team members (could include members not specifically assigned to the project). The author will reserve the location and time for the session to occur. The author is usually the person that developed the work product to be reviewed. |
|
Facilitator |
Responsible for direction during the Unit Code Review session. The facilitator will review the purpose of the session, establish session guidelines and determine that all participants have satisfactorily prepared for the review session. The facilitator is responsible for ensuring that the Unit Test Code Review participants have come to an agreement on actions to be taken after the review session is completed The facilitator will also summarize the session. The facilitator is a unique role unless the project team is small (2-3 people) in which case the facilitator may be a reviewer and/or the recorder. The facilitator may never be the author. |
|
Reviewer |
Responsible for reviewing the project deliverables prior to the review session. The reviewer will actively participate in the session by voicing defects, issues, concerns, and/or comments regarding the deliverables being reviewed. The reviewer will determine actions to be taken after the review session is completed. This role is generally assigned to the technical leader for the project (or an appropriate designee). |
|
Recorder |
Responsible for formally documenting defects/issues/questions identified during the Unit Test Code Review session, properly storing the Unit Test Code Review Report and Unit Test Code Review Defect Record documents. The recorder will validate that all defects and issues have been resolved and sign the Unit Test Code Review Report upon resolution of all changes. The recorder will also be a reviewer. |
|
Project Manager (PM) |
Responsible for ensuring that unit test code reviews occur. The PM is also responsible for assigning resources and roles for the Unit Test Code Review session, with the assistance of the author and/or Technical Delivery Manager. Resources should be assigned based on work loads and on prior roles taken in previous Unit Test Code Reviews. (For example, a person should not always be the recorder for Peer Review sessions unless the project is staffed with only 2 people.) |
|
Software Quality Assurance (SQA) |
Observes the Unit Test Code Review session and determines if the Unit Test Code Review process is being followed. SQA will have an open invitation to all Peer Review sessions and will be required to attend a minimum as defined in the SQA plan. |
This activity includes the following steps.
|
Steps |
Description |
|
Initiate a Unit Test Code Review |
The author completes the projects deliverables (e.g. code, documentation, etc.) and moves these deliverables to the location designated in the project’s configuration plan. The author also prepares the Unit Test Code Review package (put the file names in here) |
|
Coordinate the Unit Test Code Review |
The PM and author reviews the skills necessary for the participants of the review. They should look at the availability of project team members in selection of assignment of roles. They select participants that have an appropriate level of detail knowledge, and have skills or knowledge that will enable the contribution of meaningful comments. There should be a facilitator, a recorder and a reviewer for the review to take place. It is possible for a single person, other that the author, to take any or all of these roles.
The author schedules a time a place for the Unit Test Code Review to occur, completes the peer review packet and distributes it to the unit test code review team.
Team members review the packet prior to the scheduled review using, but not limiting themselves to, the criteria outlined in the review checklist. |
|
Conduct the Unit Test Code Review Session |
The facilitator conducts the Unit Test Review Meeting and ensures that the results are recorded in the Unit Test Code Review form. The facilitator establishes the session guidelines, leads the reviewers though each deliverable asking for defects or issues page by page (or as appropriate in the case of a demo or prototype). The recorder will formally document any defect, issue or change discussed for a deliverable on the Unit Test Code Review form along with severity codes, fault reasons and fault classes for each defect as it is discussed or after all defects have been documented and prior to obtaining consensus on the endorsement action. (Issues will not have a severity code, fault reason or fault class).
The author may address specific areas of concern during the review session on any deliverable being received. Once all deliverables have been reviewed, the participants select an endorsement action for the review and the recorder records the effort metrics and summarizes the defects for review. The recorder then stores the document in the proper location. (see template instructions). |
|
Resolve Unit Test Code Review Defects |
The author updates affected deliverables and
provides answers to any outstanding questions.
|
|
Perform Unit Test Code Review Follow-Up |
The author contacts the recorder when changes have been completed on the deliverables with defects and to schedule a validation session. Once the correction of all defects have been verified, the recorder will enter the recording time, validation time and resolution time on the review form and calculate the total effort metric for the review. |
|
Update the Project Workbook |
The author places the session documentation
in the location outlined in he project’s configuration management plan.
|
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
The purpose of the Conduct Functional & User Acceptance Tests activity in the Develop & Test phase is to ensure that the application’s functional requirements have been met and that the application works end-to-end so that the product is ready for release testing.
Focused on work unit to work unit flow and control as well as data exchange and consistency
Organized by related business processes and functions
Includes test of application security
Network impact modeling, if necessary (Network impact modeling is required if new/changed network infrastructure components or client software are introduced with the project)
Includes user negative testing at the project team’s discretion
Includes revision of Requirements Document (Acceptance Criteria and Accepted By) indicating requirement was met
TestDirector is used to track functional and release test results. The project manager contacts the test team to request a project folder be set up in Test Director for their project. TestDirector produces reports which can be used in test review and readiness review meetings.
Develop Product, Conduct Unit Test, Perform Code Reviews and Conduct Functional Test activities are iterative in nature and are repeated until successful functional test results are achieved. It is also important to note that projects using an iterative approach may perform these activities several times throughout the project life cycle as they work through each iteration.
All of the web pages used to implement order entry functions for direct sales are tested together. Each ordering function is followed from start to finish within the application.
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
|
Objectives:
The purpose of the Conduct Performance Tests activity in the Develop & Test phase is to test the product in the environment so that any issues can be addressed prior to moving the product to the production environment to ensure the product meets the performance requirements.
This activity should be completed, when required, as early in the Develop & Test phase as possible because a negative outcome could mean redesigning the solution. It can be performed as soon as the product is stable enough to test and an environment is available. If issues are discovered, the project team may need to work with the architecture and infrastructure teams to determine a solution.
This activity includes defining the test needs, the test scenarios and requesting the test team perform the tests.
Performance test - Simulates realistic transaction volumes, based upon projected system usage and prior project experience
Stress test - Determine the maximum throughput of transactions and data
Desktop configuration test - Test new / changed client software on existing desktop configurations
Project manager fills out the Performance Test Request.
Submit to test team.
Test team will schedule meeting with the project manager to discuss details and options.
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
Objectives:
The purpose of the Revise Business Processes activity in the Develop & Test phase is to update the business processes impacted by the product so that business users will know how the product interacts with their processes.
This activity can begin as soon as the solution and design are complete. The project manager should coordinate this activity with the process owner. If the process owner determines that there is no change required to the process, the project manager must obtain a statement from the process owner (in writing or email) stating that no process change is required.
Copies of the current and new processes must be kept in the Develop & Test project folder. If there are no process changes required, file the current process and the process owner's statement that no process changes are required in this same location.
The tasks involved with this activity include:
Schedule a work session with the process owner and business users to identify the new or changed process activities
Facilitate the session
Document the new or changed process
Obtain the process owner’s approval
Hand off the new or changed process to the process owner
The process owner’s responsibilities include:
Identification of business users who need to assist in identification of the new or changed process activities
Provide clarification in areas of the process which may need clarification
Ensuring the process is communicated to the process users
Any training necessary for the new process
ISO document requirements ongoing (includes periodic reviews, updates, approvals, etc.)
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
Objectives:
The purpose of the Develop Training & User Documentation activity in the Develop & Test phase is to ensure that all the necessary training and reference materials are developed so that the product’s introduction into the business area is smooth.
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
Objectives:
The purpose of the Develop Maintenance & Support Turnover Documentation activity in the Develop & Test phase is to complete all tasks documented in the Maintenance & Support Turnover Plan so there is a smooth transition from the project team to the support team.
Per the Maintenance & Support Turnover plan, all necessary system and turnover documentation should be completed. This includes any required documentation specific for each support team, identified project documentation (e.g., configuration management, design documents, etc.), updating or creating the application disaster recovery report and updating or creating the WORP page.
The GIS PMP Checklist identifies project documentation that may be requested by the support teams.
Related Links:
Application Disaster Recovery Process
WORP Process
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
Objectives:
The purpose of the Develop Business Rollout Plan activity in the Develop & Test phase is to ensure that all required business-related activities have been identified, assigned and scheduled so that there is a smooth integration of the product into each of the affected business areas and that the product aligns with business area standards and procedures.
Below is a list of tasks which may need to happen (this should not be considered a complete list but rather a place to start):
Training
Training logistics (travel, room setup, etc.)
Communication
Update processes, procedures, flow charts, SORCAs
Update roles and responsibilities
New equipment setup
| Inputs | Outputs | Who Performs | Who Reviews | Tools |
|
|
|
|
Objectives:
The purpose of the Develop Technical Implementation Plan activity in the Develop & Test phase is to ensure that all required activities have been identified, assigned and scheduled to move the product into the production environment so that defects and scheduling problems related to turnover are minimized/eliminated.
Below is a list of tasks which may need to happen (this should not be considered a complete list but rather a place to start):
Setup production environment
Accuracy and completeness signoff on required project documentation.
Production change control
Note: All changes to the production environment as a result of project work need to be submitted at least two weeks early to change control. It is highly encouraged to submit changes even earlier, to guarantee your slot, and/or have the flexibility to rearrange schedules if conflicts are detected. Changes will be reviewed by the change review board every other week. Project managers will also be required to attend the change review board to represent their project.
Data conversions
Setup of business users environment
User access
Deployment notification
Contingency plan
Move to production (who does what and when, dependencies or a specific order in which code/modules must be migrated, etc.)
Setup war room if applicable
Identify maintenance and support team members and how the product will be turned over to them
Identify and develop production validation tests
Setup training environment