From DaVinci

Contents 1 Purpose 2 Project Overview 2.1 Project Scope 2.2 Mile Stones 3 Project success criteria 4 Responsibilities 5 Dependencies 6 Constraints 7 Assumptions 8 Resources 8.1 Roles 8.1.1 Team Lead 8.1.2 Customer Contact / Requirements Lead 9 Deliverables 10 Project Management 10.1 Project Communication 10.2 Change Management Process 10.3 Acceptance process 11 Addendums 11.1 Addendum A1 11.1.1 Feature Commitments 11.2 Addendum A2 11.2.1 Feature Commitments 11.3 Addendum A3 11.3.1 Feature Commitments 11.4 Addendum A4 11.4.1 Feature Commitments 11.5 Addendum A5 11.6 Addendum A6 11.7 Addendum A7 12 Acronyms 13 Glossary 14 Document Approval

Purpose

This document outlines the relationship between the Software Engineering Institute (SEI), hereafter referred to as the customer, and the members of the Master of Software Engineering (MSE) DaVinci team of 2005-2006 at Carnegie Mellon University (CMU), hereafter referred to as team DaVinci, as pertains to team DaVinci's participation in the development of the SEI's Open-source AADL Tool Environment (OSATE). The portion of development for OSATE for which team DaVinci is responsible will hereafter be referred to as the project.

The statement of work (SOW) is as an agreement that defines the responsibilities of the customer and team DaVinci to complete the project. It outlines the services to be performed by each party, the deliverables, and the dependencies. Major deviations from this agreement require renegotiation of the SOW.

Project Overview

The goal of the OSATE is to facilitate the growth of the AADL user community. AADL is a new standard that was developed under the guidance of the customer. This standard aims at improving the ability to, and benefits from, modeling embedded systems. Currently AADL has a very limited user base. Most potential users are looking for AADL tool support. Tool vendors are reluctant to create AADL tools until they see a significant group of AADL users to which they can market such tools. The customer aims to solve this "chicken and egg" problem by providing the OSATE tool free of charge, as open-source software. This works within the customer's business model since the customer generates funding primarily through offering services, and not by creating or supporting tools. Extending the functionality of OSATE creates a more usable tool for the engineering community, and supports the growth of the AADL user base. An increase of AADL users is in turn an increase in potential consumers of the customer's services.

Project Scope

The high-level scope of the project is defined by the following list of functional areas related to OSATE:

• Automated AADL model transformations.
• Automated AADL model refactoring capabilities.
• Automated AADL model optimizations.
• Recommendations on methods for implementing AADL model transformations.
• Usage methods of ATL model transformation framework.

Due to the exploratory nature of this project, the detailed scope of the project will be defined iteratively with the intention of embracing change as the customer and team DaVinci gain knowledge. The project will be made up of a series of iterations. Each iteration will have a defined length and list of outputs as defined and agreed upon by both the customer and team DaVinci prior to the start of the iteration. The results of each iteration are expected to be used as input for the definition of the following iteration. The goal of this approach is to minimize the effect of change on team DaVinci, while allowing for change and maximizing the benefit of team DaVinci's effort for the customer. The definition of each iteration will be an addendum to this document.

Mile Stones

Team DaVinci's participation in the project commenced on August 30, 2005, when team DaVinci was assigned to the customer for purposes of CMU's MSE program. Team DaVinci's participation in the project will terminate with the end of CMU's 2006 summer semester, scheduled for August 10, 2006.

Team DaVinci is responsible for following Mile Stones

No	Mile Stone	Completion Date	Expected deliverable
1	SOW	December 1, 2005	Doc Release (including first addendum)
2	Iteration 1	December 2, 2005	See addendum A1
3	Iteration 2	December 16, 2005	See addendum A2
4	Iteration 3	February 10, 2006	See addendum A3
5	Iteration 4	March 3, 2006	See addendum A4

Project success criteria

The customer's goal for this project is to learn and improve their understanding in several key areas listed below:

• Model transformations using ATL.
• Programmatic model transformations through hand coded transformations.
• Model refactoring using both model transformation techniques (programmatic and ATL).
• Model optimizations using both model transformation techniques (programmatic and ATL).

The project will be considered a success if the following minimum criteria are met:

• Implement one example of each of the two model transformation types (programmatic and ATL).
• Describe how to decide the appropriate technique for a given transformation and guidance on how to implement the transformation types.
• Implement one example of refactoring for both transformation types (programmatic and ATL).
• Implement one example of a model optimization transformation.

Responsibilities

The customer is responsible for

• Providing initial responses to all communications from team DaVinci within two business days.
• Attending iteration planning and review sessions – one each per iteration.
• Providing team DaVinci with remote access to the OSATE source code and version control system. Unavailability of these systems may require adjustment of deliverables for the iteration during which the systems are unavailable.
• Providing team DaVinci with remote access to the OSATE bug tracking system.
• Providing end user input or access to end users when requested by team DaVinci.
• Providing a team liaison.
• Providing notification of changes to primary points of contact three business days in advance.

Team DaVinci is responsible for

• Requesting customer participation at least five business days in advance
• Planning activities necessary to complete the deliverables as stated in sections 9 and 11.
• Completing tasks as listed in the addendums.
• Providing meeting agendas at least 48 hours before a meeting.
• Providing meeting minutes within 24 hours of the meeting.
• Providing read-ahead materials and documents for review at least 48 hours before a meeting.
• Providing a customer liaison.
• Delivering all documents in MS Word 2003 format.

Dependencies

The known dependencies for this project are as follows:

• The customer owns and maintains the OSATE source code version control system.
• The customer owns and maintains the bug tracking facility for OSATE.
• Team DaVinci controls modifications to the source code they develop or alter for the project, for the duration of the project. Upon the termination of team DaVinci's participation in the project, modification control of all said code will be transferred to the customer.
• Team DaVinci maintains and controls modifications to all documents they develop or alter for the project, for the duration of the project. Upon the termination of team DaVinci's participation in the project, modification control of all said documents will be transferred to the customer.
• Team DaVinci will develop the feature list document for the project.

Constraints

The known constraints for this project are as follows:

• Team DaVinci will work off the "davinci" branch of the official OSATE release version 1.1.
• The target development platform is Eclipse version 3.1.

Assumptions

Team DaVinci's planning and task definitions are based on the following assumptions:

• Team DaVinci is not responsible for integrating parallel development effort beyond branched release.
• Team DaVinci will not be requested to port developed functionality of OSATE to new versions of Eclipse.

Resources

Team DaVinci will supply the customer with five engineers for the duration of the project with varying time commitments as defined below.

	August 30, 2005, to December 9, 2005. 14 weeks.	January 16, 2006, to May 5, 2006. 14 weeks.	May 22, 2006, to August 10, 2006. 11 weeks.
Harry Gunnarsson	9 hours/week	12 hours/week	36 hours/week
Christopher Nelson	9 hours/week	12 hours/week	48 hours/week
Chung-Hao Shih	9 hours/week	12 hours/week	48 hours/week
Jose Luis Rios Trevino	9 hours/week	12 hours/week	48 hours/week
Carl Wang	9 hours/week	12 hours/week	36 hours/week

Roles

The roles below will change at the beginning of each academic semester. The semester dates are listed in the table above.

Team Lead

Chung-Hao Shih Email: chunghas@andrew.cmu.edu

Customer Contact / Requirements Lead

Jose Luis Rios Trevino Email: jriostre@andrew.cmu.edu

Deliverables

The deliverables for the project will be defined in an iterative fashion in conjunction with the project's scope. Deliverables defined for each iteration will be captured in the SOW's addendums. High-level deliverables that span multiple iterations and require specific attention are listed below with their delivery date(s). During the project it may be determined necessary to add deliverables to the below list.

Deliverable	Description	Delivery Date
SOW	Documents the agreement between the customer and team DaVinci regarding the relationship between these two parties for the duration of the project. Subject to change with each iteration.	<<Defined iteratively>> Version 1 – 12/01/2005
Feature list	The document that lists and prioritizes all high-level features/stories for the project and links them back to the specific detailed requirements of the project. Intended for input into iteration planning.	<<Defined iteratively>> Version 1 – 11/09/2005 Version 2 – 12/02/2005

Project Management

Project Communication

Formal communications of project status will occur at the end of each iteration. The subset of features, from the feature list, committed to by both customer and team DaVinci will be reviewed along with their status, estimated effort, and actual effort. This information will feed into the planning for the following iteration.

Change Management Process

Team DaVinci is willing to accept change proposals at anytime during the project; however, these proposals will only be considered at the end of the project iteration during which they were received. An internal change control board (CCB) will review the change proposals to determine their impact on the project if accepted, and this impact will be communicated to the customer. If the customer accepts the impacts of a change as determined by team DaVinci, then team DaVinci will accept and act upon the change.

Acceptance process

The acceptance process will vary depending on the goal(s) of an iteration. Therefore, each addendum to the SOW that defines the scope of an iteration will also define the acceptance process and quality measures for that iteration.

Addendums

Addendum A1

Iteration 1 is exploratory. The features committed to for the iteration are expected to allow team DaVinci to better understand the project and the technologies involved. The code deliverables for this iteration are not expected to be committed to OSATE source, and therefore there is no expected level of quality for the code developed for this iteration.

Feature Commitments

Feature	Feature description	Feature decomposition
4.002	Reduce number of connections by introducing port groups.	Programmatically determine candidate ports for being collapsed into port groups.

Addendum A2

Iteration 2 is exploratory. The features committed to for the iteration are expected to allow team DaVinci to better understand the project and the technologies involved. The code deliverables for this iteration are not expected to be committed to OSATE source, and therefore there is no expected level of quality for the code developed for this iteration.

Feature Commitments

Feature	Feature description	Feature decomposition
4.002	Reduce number of connections by introducing port groups.	Programmatically collapse candidate ports into port groups.

Addendum A3

Iteration 3 is exploratory. The goal of the iteration is to allow team DaVinci to better understand some of the technologies involved in the project, particularly some elements of the AADL meta model and also the Ecore framework used as the mechanism to manipulate instances of that meta model. The experimental code resulting from this iteration will not be part of the OSATE code base, and therefore there is no expected level of quality for the code developed for this iteration.

Feature Commitments

Feature	Feature description	Feature decomposition	Deliverables
4.002	Reduce the number of connections by introducing port groups.	Programmatically collapse candidate ports into port groups.	Experimental eclipse plugin implementing the collapse of candidate ports into port groups. This collapse will be implemented only at the top hierarchical level of the AADL model used as input.

Addendum A4

Iteration 4 consists in the partial implementation of the feature number 4.002 listed in the product backlog. The implementation is intended to be part of the OSATE tool.

Feature Commitments

Feature	Feature description	Feature decomposition	Deliverables
4.002	Reduce the number of connections by introducing port groups.	Programmatically collapse connections into port groups.	Connections will be programatically collapsed into port groups. This collapsing will be implemented only at the top hierarchical level of the AADL model. The implementation will be in the form of an eclipse plugin.

Addendum A5

Tasks to be completed in Sprint 5 are marked in green in the Sprint 5 backlog

Addendum A6

Tasks to be completed in Sprint 6 are marked in yellow in the Sprint 6 backlog

Addendum A7

Tasks to be completed in Sprint 7 are marked in green in the Sprint 7 backlog

Acronyms

AADL	Architectural Analysis & Design Language
ATL	ATLAS Transformation Language
CCB	Change control board
CMU	Carnegie Mellon University
MSE	Master of Software Engineering
OSATE	Open-source AADL Tool Environment
SAE	Society of Automotive Engineers
SEI	Software Engineering Institute
SOW	Statement of work

Glossary

• Change control board – An entity internal to team DaVinci responsible for reviewing change proposals/requests from the customer to determine the potential impact of the change on the project.
• Eclipse – An extensible development platform and application frameworks for building software (http://eclipse.org).
• Feature list – The document that lists and prioritizes all high-level features/stories for the project and links them back to the specific detailed requirements of the project. Intended for input into iteration planning.
• Open-source software – Open-source software refers to computer software and the availability of its source code as open source under an open source license to study, change, and improve its design (http://en.wikipedia.org/wiki/Open-source_software).
• Statement of work – Documents the agreement between the customer and team DaVinci regarding the relationship between these two parties for the duration of the project. Subject to change with each iteration.
• Version control system – A system for the management of multiple revisions of the same unit of information (http://en.wikipedia.org/wiki/Version_control_system).

Document Approval

The following signatures are required for approval of this document.

• Peter Feiler
• Lutz Wrage
• Luis Rios
• Christopher Nelson