Statement of Work
From ZenWiki
Contents |
Introduction
Purpose
The purpose of this document is to establish an agreement between Software Engineering Institute (SEI), hereafter referred to as the client; and the members of the Master of Software Engineering (MSE) Zen team of 2006-2007 at Carnegie Mellon University (CMU), hereafter referred to as Team Zen. While the Statement of Work (SOW) is not legally binding, by accepting this document, both parties express their willingness to observe the terms and conditions as laid down herein in good faith.
Audience
The readers of this document include the members of Team Zen, the client, and the mentors. The secondary audience includes other MSE studio teams, studio mentors, and MSE faculty.
Scope of document
The provisions stated in this document shall be in effect for the duration of the MSE studio project. The duration of the project is from August 28, 2006 to August 10, 2007.
Project Overview
The project is to streamline a portion of the Service Migration and Reuse Technique (SMART) that helps organizations analyze legacy systems to determine whether their functionality, or subsets of it, can be reasonably exposed as services in a Service-Oriented Architecture (SOA). The project focuses on the data collection process guided by the Service Migration Interview Guide (SMIG). The process is currently manual and time-consuming. With the tool support, the client expects to see a fundamental improvement on efficiency and quality during SMART engagements.
Project Scope
The project scope is defined in three aspects:
- Time: the project will be completed within the time and resources described in the Project Resources section. Deliverables will be delivered according to the time lines specified in the Deliverables section.
- Features: The project requirements are defined in a separate document: Software Requirement Specification (SRS). They will be maintained in the following manner:
- Creation: New requirements will be recorded in the SRS upon elicitation/determination.
- Elicitation: A variety of methods will be used to elicit requirements of all levels as the project progresses. These methods will includes use cases, contextual design, usability analysis, and others. Some methods may require higher levels of customer involvement than others.
- Maintenance: All changes to existing requirements will be recorded in the SRS. Additionally, each set of updates to the SRS will result in an individual version of the SRS which will be stored in a version control repository to maintain visibility into requirement evolution. Finally, the SRS will include a revision history which is iteratively updated and will specify which requirements changed in each revision.
- Deletion: Any requirement considered to be no longer valid will be marked as "DELETED" but maintained within the SRS. This will ensure that requirement numbers will not be reused, which would cause confusion.
- Deliverable: Each requirement in the SRS will be marked as either "Required" or "Not Required". Any requirement marked as "Required" will be ultimately delivered in the final delivery to the customer, with the caveat that the list of requirements marked as "Required" may change due to tripwire events documented later on in this document. Please note that this does not preclude delivery of requirements not marked as "Required," it simply sets the minimum final delivery.
- Priority: Each requirement is assigned a priority. In scheduling development of the individual pieces of the project, Team Zen will schedule in the order of highest priority to lowest.
- Verification & Validation: For each requirement delivered to the customer, Team Zen will write a test case testing that specific requirement (with the allowance that some high level requirements may be tested by testing an aggregate of the test cases for the requirements to which it decomposes). Upon writing these test cases, Team Zen will validate the test cases by presenting them to the customer for approval. Team Zen will then verify these test cases by running them and documenting the test results in a manner acceptable by the customer (which can be determined during validation).
- Quality: the project will be guided by the business drivers and corresponding quality attributes.
The scope of project forms the basis for agreement between the client and Team Zen. It will also be the basis for all project related decisions and will be used to determine whether the project has been completed successfully.
Project Resources
Team Zen will supply the following developer resources.
| Fall-2006 Semester: August 28, 2006 ~ December 15, 2006 | 5 developers; each for 9 hours per week |
| Spring-2007 Semester: January 15, 2007 ~ May 4, 2007 | 5 developers; each for 12 hours per week |
| Summer-2007 Semester: May 21, 2007 ~ August 10, 2007 | 5 developers; each for 48 hours per week |
Responsibilities
Team Zen
Team Zen will fulfill the following responsibilities:
- Complete the project by August 10, 2007.
- Deliver a final product which implements all requirements marked in the SRS as "Required".
- Write, run, and provide documentation of test cases for all delivered requirements.
- If requested, demonstrate performance of test cases to the client.
- Perform knowledge transfer to the client by providing documentation (defined in the Deliverables section) and training.
- Provide online access to project status which can be accessed at any time and is updated on a weekly basis.
- Provide all other deliverables specified by Team Zen or the client.
- Perform Software Risk Evaluations (SREs) as needed, identify risks through each SRE, plan and implement mitigation strategies for the top 3 risks identified in the SRE. Team Zen will also periodically review risks currently being mitigated to see if they are still risks, and if they are not, the mitigation strategy will be discontinued.
- Provide initial installation of the final product of the ZEN Tool software.
- Provide training and/or documentation on future installation procedures.
Client
Involvement from the client is fundamental to the project's success. The client's responsibilities are as follows:
- Upon receiving a request for feedback on the SRS or Architecture document or other related documents, the client will provide the requested feedback within 1 week. If the client requires further explanation of the documentation in question prior to being able to provide useful feedback, the client must request the necessary clarifications within 3 days. In this case, the client will be provided with an additional 2 days to provide the requested feedback.
- Upon receiving a set of test cases for validation, the client will provide a yes/no response for each test case within the set as to whether the test case is sufficient to verify the requirement within 1 week. Additionally, if the client wishes to witness the test case being performed, the client must request this at this time.
- Assist in usability testing at least three (3) times during the project.
- Note: The same client representative is not required for all three tests.
- Further Note: Team Zen would prefer if all members of the SMART team assists in usability testing at least once, to ensure that all users are comfortable with the interface.
- Comply with the change management process specified in this document for all requirements changes in the Spring and Summer semesters.
- Reserve time for weekly face-to-face meeting (one hour minimal, more if requested).
- Note: a weekly meeting is not mandatory, but as the tripwire events mandate, no communication for at least 3 weeks results in a mandatory rescoping of the project.
- Keep Team Zen informed about the relevant issues that might affect the project's progress.
- Cope with tripwire events specified in the Tripwire Events section.
- Designate a primary contact who can make final decisions.
Deliverables
The project will be developed by using an iterative and incremental software development lifecycle. There will be three iterations in each semester, which sums up to nine iterations for the entire project. Team Zen will provide the following deliverables according to the given time lines. It is to be noted that deliverables will be iteratively refined before their final release to the client.
| Deliverable | Iteration Number | Delivery Date |
| Prototype delivery #1 | 3 | December 15, 2006 |
| Statement of Work | 3 | December 15, 2006 |
| Prototype delivery #2 | 4 | February 23, 2007 |
| Prototype delivery #3 | 5 | March 30, 2007 |
| Prototype delivery #4 | 6 | May 4, 2007 |
Requirements:
| 6 | May 4, 2007 |
| Prototype delivery #5 | 7 | June 15, 2007 |
| Prototype delivery #6 | 8 | July 13, 2007 |
| 9 | August 10, 2007 |
Points of Contact
Team Zen will appoint a primary contact in each semester. The primary contact will be responsible for all the projected related communication with the client. Additionally, a mailing list team-zen@lists.andrew.cmu.edu is created, and can be used for general purpose communication.
The client's primary contact:
| Grace Lewis |
| Senior Member of the Technical Staff - Integration of Software-Intensive Systems (ISIS) |
| Software Engineering Institute |
| (412) 268-5851 |
| glewis@sei.cmu.edu |
Change Management Process
After a baseline is established, any change (including change to this document) can only be made by following the Change Management Process. The process is defined in a separate document.
Tripwire Events
Tripwire events are certain circumstances in which project scope, resources and schedule can not be sustained by Team Zen. If any of these evens happen, the terms and conditions of this document will need to be renegotiated.
- Loss of a team member: a member of Team Zen is removed from the team for any reason.
- Excessive unavailability of a team member: a member of Team Zen is unavailable due to other commitments, sickness or any other reason for more than three weeks in Fall-2006 semester, two weeks in Spring-2007 semester, or one week in Summer-2007 semester.
- Change in client representative: the primary client representative is replaced at any time during the Fall-2006 or Summer-2007 semester.
- Excessive unavailability of any client input: no client representative is available, in any way, for more than three weeks during any time of the project lifecycle.
Communication
- Client meetings will be held once a week or as required by the current phase of the project
- All documents will be available on the Wiki page of the team or the version control system. Access to both will be provided to the key customer contact. Access to additional contacts on the customer's end will be added if and when required
- Agendas and other relevant artifacts will be provided 48 hours before the meeting with the customer or before expecting review comments from the customer. The communication medium for the same will be email, and the artifact can either be shared via email or present on the Wiki or the version control system, as required.
- The project plan and the current status of the project will be available in a central location which can be accessed by the customer. The plan will be updated at a minimum rate of once per week.
Glossary
The glossary is defined in a separate document.
Reference
- Grace Lewis, Ed Morris, Liam O'Brien, Dennis Smith, Lutz Wrage: SMART: The Service-Oriented Migration and Reuse Technique, September 2005.
- Grace Lewis: Studio Proposal 2006-2007, August 2006.
- Team Simulacrum: Statement of Work Version 0.7, February 2006.
- Team DaVinci: Statement of Work, June 2006.
- Krypto Team: Statement of Work Version 1.2, June 2001.
- Team Plato: Statement of Work Version 0.3, October, 1999.
