Proposal Process by hcj


									Hermes Team: Bosch-MSE 2006/07 Process Proposal

Process Proposal
This document describes the software development process used by team Hermes.

Document Information and Revision History
Document Information Title Process Document Upeka Owner Stored In Revision History # Version 1 1.0 2 1.1 3 1.2 4 5 6 7 8 1.3 1.4 1.5 1.6 1.7

Date 10/08/2006 12/10/2006 2/4/2007 3/24/2007 5/7/2007 06/13/2007 07/09/2007 10/5/2007

Author Upeka Ed Tadashi Fabian Ed Upeka Upeka Fabian

Comments Creation Modified to describe our use of TSP Added our process in the spring semester Updated the section about the spring semester process Add summer process Updated for summer Sprint 2 Updated after summer Sprint 2 Fall 2007 section

What we expect from a process
The process should give us guidelines, because it is a new environment for the whole team. The goal of the first semester is to gather the requirements. So the process should help us with this. The goal of the second semester is to gather the requirements and come up with the architecture. So the process should help us with this. The process should allow iterations, so that we can incorporate feedback from the customer The process should also describe team roles, so that we can separate responsibilities. The process should enable us to track project progress. Because one of the team goals is that we want to learn something new, a process should “ideally” be new to most of us.
Page 1 of 6

Hermes Team: Bosch-MSE 2006/07 Process Proposal

Fall 2006: TSP
Hermes has chosen TSP as their primary software engineering process. Upon initial review, is seemed to fulfill our expectations from a process. We also considered Agile processes, but we decided against the use of such a process because: - We expect that the requirements in the Hermes project are relatively stable. - The customer cannot be involved to such a grade that a lot of agile processes request. - The MSE program imposes constraints on how we can split our time for Studio in the semesters. The goal of most agile processes is to release a first version as quick as possible. There is no requirement (or time) for this for the Bosch CA tool. - All team members want to experience the development of a System Requirements Specification and then handle change requests in a defined Change Request process.

Tools support
To help us mitigate the administrative effort involved with TSP, we will use the TSP tool, provided from the SEI. The tool can be obtained from:

Software Process in the Fall ‘06 semester
The team will try to use TSP in its full scale. At the moment we don’t intend to tailor TSP. Our Fall-06 TSP cycle starts from the middle of the semester to the end of the semester. We will do only one cycle for the Fall-06 since there is not enough time for more than one cycle. We will not stretch the cycle over to Spring semester because we have deliverables due at the end of Fall semester. Since we decided to use TSP in the middle of the semester, after many tasks have already been planned and performed, we will hold an abbreviated Launch, Strategy, and Planning. Since the deliverable due at the end of Fall semester are documents (SRS and SoW), we will concentrate on Requirements process step and skip the Design, Implementation, and Test process steps. We will hold a Postmortem step at the end of the semester. We decided that we will not perform defect tracking for this semester because we did not feel that tracking document defects will provide information that is valuable enough to worth the overhead. We will perform defect tracking in Spring and Summer, however, because we realize the value of tracking design and coding defects. Therefore, we will not have formal inspection of requirements document.

Software Process in the spring ’07 semester (cycle one)
Page 2 of 6

Hermes Team: Bosch-MSE 2006/07 Process Proposal

The team will use TSP and ACDM. They will use TSP as a development framework and focus on developing architecture document in the spring semester. TSP: The reasons that the team has chosen TSP as the process in the spring semester are as follows. - TSP fits our software development environment. - We started using TSP in last fall semester and we would like to learn more about TSP TSP tools: We will use the following TSP scripts: LAU, STRAT, PLAN, REQ, DES, INS, PM, TASK, SCHEDULE. The tool can be obtained from: The TSP scripts can be obtained from Watts S. Humphrey, Introduction to the Team Software Process, 2000. ACDM: The team also uses ACDM as well as TSP. ACDM satisfies our requirements to develop our architecture so we decided to use it. Please refer to architecture proposal about developing architecture. Cycle We will iterate two or three cycles in the spring semester. Generally, one cycle is for 3 or 4 weeks, but it is based on the full-time software development. We have only 48 hours a week as a team therefore the first cycle in the spring semester is 7 week.

Software Process in the spring ’07 semester (cycle two)
For the second cycle we decided to use “ACDM inspired by TSP” as our process ACDM builds the core of the activities that we perform during the second spring cycle. Since ACDM is not a full process framework we support it with some TSP practices. TSP practices used: - We will establish a detailed plan of the cycle (see the planning proposal for further details) - We will use a tracking that is closely related to TSP’s tracking, although we don’t use the TSP form. We will also do earned value tracking. - We will still perform the Post mortem from TSP. - We will adhere to the TSP roles as our main roles for the cycle. The ACDM roles will just be used for the ACDM related activities. For the mapping we used to assign ACDM roles to TSP roles please refer to the architecture proposal.

Software Process in the summer semester
The team will use an iterative development process with a Scrum-styled management.
Page 3 of 6

Hermes Team: Bosch-MSE 2006/07 Process Proposal

Iterative development We will use an iterative development process, releasing the product in 4 cycles. Both the client and the team feel that a frequent examination will give us better feedback, resulting in a better product at the end. Scrum We will use a Scrum-styled management, with the daily 15-minute stand-up meetings facilitated by the Scrummaster. Progress will be tracked with burndown chart, which is similar to the EV chart that we have been using so far. We are using Scrum because we would like to gain the benefits of effective communications, we would like to learn Scrum, and we hope that it will result in less planning and tracking overhead. The difference between Scrum and our use of Scrum is based on the fact that Scrum is feature-driven while our project is time-driven. We must deliver the specified functionalities at the end of summer. We thus plan on iterative deliveries, laying out exactly what will be delivered at the end of each cycle to ensure that the last cycle will yield the complete product. At the end of the first Sprint (cycle), we will conduct a Sprint retrospective which is similar to a TSP postmortem. We will determine whether our use of Scrum is effective and appropriate and adjust our process accordingly. Sprint Retrospective These are the specific details for conducting the sprint retrospective at the end of each sprint.  We decided to conduct the retrospective, similar to TSP post mortem. As such, we will discuss how the team conducted each of the roles. o Team lead o Planning manager o QA manager o Support manager o Risk manager o Client liaison o Software developer For each of these areas we will ask three questions 1. What Didn't Go So Well - these items are used to record areas that the team felt didn't go as well as they would want. 2. What We Can Do Better - identifies specific actions or activities that could improve on the areas that didn't go so well. 3. What Went Well - identifies areas that the team see as positive to their performance.


Pasted from < tForRetrospectivesInScrumForTeamSystem.html>
Page 4 of 6

Hermes Team: Bosch-MSE 2006/07 Process Proposal

Handling client demos We would like to be able to stop at least 2 days before the demo, and bug fix for 2 days. As a solution, the team lead will unofficially (meaning unrecorded in the backlog or burn down chart) push team members to finish all implementation tasks 2 days before the release. This will allow us to test integration before the demo as well. The big picture The team reflected that we cannot tell the big picture of the tasks, because we do not know what is late or early when we are within each sprint. We decided that: o We don’t want to track in detail because that would be too much work, and going against the grain of scrum. o The team decided to track the status of each task qualitatively or perhaps some other mechanism (the stage each task is in). o Team lead will produce a mechanism for tracking and we will review it at each status meeting, and improve it over the course of sprint 3. Common hours Common hours will be from 9 to 4 on weekdays, to accommodate for team member’s personal commitments. We will address this during the sprint, if the team isn’t putting enough time. Saturday’s common hours are from 9.00am to 1.45pm. At 1.30pm we will have the stand up meeting, and then common hours will be over.

Software Process in the fall 2007 semester
The process for the fall semester will have two cycles. For fall the team will use a very lightweight process approach. The process has the following building blocks:   Planning The plan will include weekly milestones that the team needs to achieve. This should help the team to keep a constant work pace throughout the semester. Tracking The tracking part will consist of EV and time tracking. EV tracking will show if the team achieves the milestones as planned. Time tracking shows where the team spends its time. Postmortem In the middle and at the end of the semester the team will perform a postmortem to evaluate how the semester went and what we should improve (for the second half) Development For bug fixing and new feature development we will use the same development process that we used in summer. For the writing of the documentation we will use the following documentation
Page 5 of 6

 

Hermes Team: Bosch-MSE 2006/07 Process Proposal


process: Common hours: The team will spend 3 hours each week working at the cave together. This should increase the work efficiency. For the common hours the team is only allowed to work on studio. This should help the team, that the work is getting done.

Page 6 of 6

To top