Software Process Specification

From DaVinci

Contents 1 Introduction 2 Process 2.1 Decision 2.1.1 Alternative 2.1.2 Tracking 2.2 Meeting 2.2.1 Common Hour 2.2.2 Status Meeting 2.2.3 Discussion Meeting 2.2.4 Planning Meeting 2.2.5 Customer Meeting 2.3 Selection of project management approach 2.4 Risk Management 2.4.1 Process Steps 2.4.2 Artifacts 2.4.3 Definitions 2.5 Requirement Traceability 2.6 Coding 2.7 Code Review 3 Estimates 4 Software Configuration Management Plan 4.1 Introduction 4.2 SMC Management 4.2.1 Organization 4.2.2 SMC Responsibilities 4.3 SMC Activities 4.3.1 Configuration Identification 4.3.2 Configuration Control 4.3.3 Configuration Status Accounting 4.4 SMC Resources 4.5 SMC Plan Maintenance 4.5.1 Customer Deliverables 4.5.2 Quality Control 5 Roles 5.1 Project Management Roles 5.1.1 Product Owner 5.1.2 Scrum Master 5.1.3 Developer 5.1.4 Communication Lead 5.1.5 Process Lead 5.1.6 Risk Manager 5.1.7 Team Lead 5.1.8 Customer Manager 5.1.9 Infrastructure Lead 5.2 Meeting Roles 5.2.1 Facilitator 5.2.2 Time Keeper 5.2.3 Scribe

Introduction

This document describes in detail various processes that are practiced by Team DaVinci to execute Software Engineering Institute (SEI) sponsored studio project: Open-source AADL Tool Environment (OSATE) tool enhancement and the responsibility of different roles adopted by team members to execute the process.

Process

Decision

In the case of resolving conflict among team members, DaVinci shall make decision using one of following methods or combination in the order listed.

1. Poll for consensus - The discussion lead inquires opinion on same issue from the team members one by one. The lead then makes a combined summary of opinions to see if the team agrees.
2. Vote - Any team member can ask for a voting decision. If the lead agrees, each team member will have one vote (agree/disagree/abstain) on the issue. Decision is made on majority vote (no of agreed vs. no of disagreed).
3. Team lead decision - Team lead decision is the final ruling on any issue with one exception. Any team member may ask for a vote against team lead's decision but it requires all team members (except the lead) to vote against the team lead to over turn the ruling. In which case the team member asking for the vote shall move to collect more fact and coordinate a follow up discussion.

Alternative

If the issue is new or insufficient facts is available, the discussion or team lead may choose to defer the decision by assigning a member to collect more facts and coordinate a follow up discussion (meeting). However, same issue shall not be deferred twice.

Tracking

Team DaVinci will track all decisions made by the team on the Team Decisions wiki page. It is the responsibility of the scribe to record decisions for tracking just as they record action items. It is the responsibility of the team to verify that the decisions are recorded and are recorded accurately.

Meeting

Team DaVinci plans five types of meeting throughout the studio project to gather team members for a purpose: Common Hour, Status Meeting, Discussion Meeting, Planning Meeting, and Customer Meeting.

The meeting facilitator is required to generate an meeting agenda for any planned meeting (except common hour). If an agenda is not created in Team Meeting Agendas And Miniutes wiki page and informs meeting attendees 24 hours prior to the meeting, attendees have the option of not attending the meeting.

Common Hour

The sole purpose of common hour is having all team members present at the same time. Therefore, no agenda is created for this planned meeting. Due to the distributed team nature, this is also the only time when adhoc team discussion may take place. However, if a team member wishes to call an adhoc meeting during common hours all team members have the option to participate or not. If insufficient participant is available, person requesting the meeting has to conduct a standard planned meeting outside of common hour.

Starting in Spring 06, team DaVinci meets on a fixed (common) hours: Tuesday/Thursday (7PM - 9PM) and Saturday (9AM - 1PM). A "scrum daily meeting" is conducted at the begining of Tuesday/Saturday session during the sprint. This is a quick stand-up meeting for team members to discuss what other team members are currently working on and a chance to identify issues or neededed support. Prior to the meeting, each team member is to post answers to the three Scrum meeting questions in the Scrum Meeting Forum on the team BB.

Any team member missing planned working hours must notify the team via email at least 48 hours in advance of the start of the common hours that will be missed (except in cases of emergency).

Summer 06 : TBD.

Status Meeting

Team Davinci has a weekly team status review meeting. This meeting is held with the (optional) presence of team Mentors.

Team Lead is the designated facilitator for this meeting. In addition to the responsibility of the facilitator, the team lead is responsible for generating current team progress report to be included in the agenda for attendee review.

The progress report should include:

• Current burndown chart
• Workload distribution chart
• High-level task progress (e.g. Risk Management, Refine Architecture, Update Proposals)
• Open action items

The meeting serves as the ground for identifying team performance or communication issues. It is not necessary to resolve the issues in this meeting. However, it is expected to generate action items directed to bring issues discussed to resolution. The team lead is responsible for assigning responsible actionee.

The agenda should include the following topics:

• Agenda review
• Overall status review
• Status update by role
• Review of previous/open action items
• Member discussion (team member concerns/questions/problems)
• Questions to the mentors (consider 7 - 10 minutes discussion per question)
• Meeting evaluation
• Review of new action items

The team lead assigns time keeper and scribe for the meeting by rotating role among team members.

The agenda should be provided to the requested attendees 24 hours prior to the meeting in an email including:

• a link to the agenda
• a link to the detailed status report
• the list of questions for the mentors

To generate a list of questions for the mentors, the team should hold a brainstorming meeting for 15 - 30 minutes the day before the status meeting (allow for time to add questions to agenda and get agenda sent 24 hours before meeting).

Discussion Meeting

Team Davinci when needed calls a discussion meeting. This meeting is held among team members with optional invitation to team Mentors. The purpose of the meeting is always to discuss a specific subject/issue with the focus to completion/resolution.

Any team member with a specific subject or issue can call the meeting and takes on all responsiblities of a facilitator and assigns time keeper and scribe for this meeting.

This meeting has the intention to resolve a specific subject or issue identified in the agenda. In the case of conforntation, only one follow up discussion meeting can be scheduled to achieve a decision if it is not resolved in first discussion meeting.

Team DaVinci also have a planed discussion meeting. Prior to the spring planning, team DaVinci shall conduct a customized discusssion meeting as the reflection meeting.

Planning Meeting

• Goal: Define our planning meeting process and identify the reasoning and benefits of each planning phase in order to have the refinement and reflection to our planning meeting later

• Precondition and Inputs:
  • Finished the reflection meeting for the previous sprint
  • Finished the review meeting with customers
  • Propose the high level goals by team leader and tasks we want to achieve in this sprint and got the feed back from the customers
  • A contiuous time period for the team to do the Task Estimation, Task Prioritization, Task Assignment phases at once. (2 hours at least)
  • We declare the percentage of our time for our planning tasks at the begining of our planning meeting

• Outputs:
  • Prioritized tasks documented
  • Estimation hours of each tasks documented
  • Each task has assigned an owner
  • Entry and Exit criteria documented

• Rules:
  • No task group in the planning should be greater than 18 hours (~2 days). Task groups greater then this should be divided into multiple task groups.

• Phases:

Phases	Steps	Description
High-level task identification	Generate the high level task	Before each planning meeting, team leader generates the high level tasks from: The tasks that haven't been finished in previous sprint The new tasks from Product Backlog The major tasks from our Big Picture of the next sprint The inputs from the customer review meeting in the previous sprint
	Assign Owner	Each high level task will assign an owner 48 hrs before the actual planning meeting based on the team role and the knowledge the person had.
Subtask identification (exit/entry)	Response from owners of high-level tasks	The owner of the tasks will have to generate three artifacts to the team leader 24 hours before the actual planning meeting: The subtasks of the high level task The estimation hours of each subtask (Considering past data for similar tasks and with aid from other team members or outside experts when available) Entry and Exit criteria of each subtask
	Collect tasks	Team leader will have to collect the tasks from the task owners before the actual planning meeting
Task Estimation	Identify tasks for team estimation	Team members will suggest tasks to be estimated using Wideband Delphi that they either had a hard time estimating alone, or that are new tasks involving multiple unknowns.
	Entry/Exit Clarification	When Team members come to the consensus of the definition of each of the subtask, Start round 1 of the Wideband Delphi Estimation process for tasks requiring team estimation.
	First round of the Wideband Delphi	Each team member give the estimation hours of each task based on the experience and knowledge they have and send it back the team leader. After gathering all of the estimation from the team members, team leader will go through each of the task estimation. Identify the person who has the highest and lowest estimation of each task and ask for the reasoning for their estimation.
	Second round of the Wideband Delphi	Each team member give the estimation hours of each task based on the knowledge acquired from the first round of the Wideband Delphi and send it back the team leader.
Task grouping	Group similar tasks in chunks of time less then 18hrs (~2 days)	Tasks are grouped for prioritization and tracking purposes.
Customer feedback	Get Feedback from Customer	Show customer the task groups we will be doing in this sprint and get the input from the customer regarding missing tasks or change in priorities. New tasks will be identified from the customer and those tasks will estimated and grouped by the team prior to the prioritization step.
Task Group Prioritization	Prioritize Task Groups	Each team member give the priority of each of task identified in the previous phases and send it back to the team leader. Based on the working hours we have each sprint, identify the tasks we can do within this sprint. The requirement manager should organize the tasks we couldn't do in this sprint and change the Product Backlog.
Task Assignment	Assign Tasks	Assign the tasks to the team members based on member roles, skills, and anticipated work load.

Customer Meeting

see Scrum Review Meeting Guideline

Selection of project management approach

Team DaVinci conducted extensive research on known processes to select the process most suitable for the team and nature of the project. Firstly, a rather comprehensive list of known processes ([1]) was produced together with a graphical categorization ([2]) showing how processes relate amongst themselves. These artifacts were used as reference material in process comparisons and process selection discussions. Secondly, the team performed surveys regarding each team member's viewpoints, as they were understood at the time, on the issues of:

• Team Characteristics
• Required Effort of Learning
• Requirement
• Design
• Product
• Delivery
• Customer
• Development Lifecycle

From the list consisting of more than ten processes, the team decided to look further into two processes, ACDM and Scrum, both of which seemed to address the needs of the project. The artifact documenting this selection is [3].

Team DaVinci was divided into two subteams with responsibilities to further look into Scrum/XP and ACDM respectively. The artifacts for this effort are [4] and [5]. The final artifact for the process selection is [6], which, in detail, discusses pros and cons for ACDM and Scrum/XP.

Based on the consensus acquired from the surveys and key factors and characteristics representative of the project, the team decided to adopt Scrum. The main project characteristics and needs identified are listed below. We have also explained how they are addressed by Scrum.

• Volatile Requirements Scrum proposes short iterations called sprints, during which requirements are frozen. Between sprints, requirements or prioritization may change based on product owners' input. The process protects against floating requirements during implementation and makes product owners thoroughly justify requirement changes.
• Periodic Deliveries The product owners are not quite sure about requirements, therefore a prototyping approach mitigates risks of developing the wrong product. This approach was also requested by the product owners themselves.
• Research Oriented Project Throughout the course of the project, new ideas regarding the final product may arise due to the research oriented nature of the project. As mentioned above, Scrum appropriately addresses evolutionary requirements.
• Small Distributed Team Scrum is suitable for small teams like team DaVinci. Team DaVinci believes that frequent Scrum meetings will address the additional needs of a distributed team and keep the team adequately synchronized.

Risk Management

Process Steps

1. SRE - Generate risk list.
2. Risk Prioritization - Multiple rounds of voting to achieve convergence on risk priorities.
3. Mitigation Strategy Brainstorming - Generate a list of sources and mitigation strategies for each factor of each risk in top 5 risks.
4. Mitigation Strategy Prioritization - Prioritize the mitigation strategies for each risk based on how many, and which, factors they mitigate.
5. Action Plan Definition - Define an action plan for the two highest priority mitigation strategies for each of the top 5 priority risks.
6. Execution and Tracking of Action Plans - Schedule and execute the tasks defined by the action plans as sprint tasks. Tasks should be assigned to team members other than the Risk Manager. Progress of the execution and status of triggers should be tracked by the Risk Manager and briefly mentioned during weekly status meetings.
7. Risk Tracking - At the completion of each sprint, activation of a trigger, or occurrence of a project life-event, update the risk list with any new risks that may have been identified and then go back to step 2 (completing each step less formally and rigorously than the first time through the process) .

Artifacts

Prioritized Risk List

Prioritized Mitigation Strategies

Action Plans

Definitions

• Action Plan - A list of tasks and triggers for a specific mitigation strategy.
• Life-Event - A major event in the project such as a change in scope or customer, or a drastic change in feature prioritization.
• Risk Factor - One of the factors contributing to a risk (i.e., source, condition, consequence, probability, and time frame).
• Trigger - Defined as events that either occur or do not occur and specified with a timeframe.

Requirement Traceability

Team DaVinci project requirements are defined in Product Backlog. Each product feature requirement are mapped to a use case as captured in product use cases where a bidirectional traceability between the product feature and use case is maintained. The detail requirements are finalized with customer and captured as acceptance criteria in the addendums of SOW for the expected feature delivery sprint.

Team DaVinci develops one or more eclipse plug-in based on use case to satisfy a product feature. The detail feature requirements are captured as use case scenarios. Team maintains an unidirectional traceability to detail requirements. The validation of the use case scenarios is based on test cases as captured in the function test plan.

Note: Customer is not confident of what constitue a "complete" solution. The use case scenario using predefined AADL model is agreed upon as the acceptance criteria. Phased delivery as defined per sprint is planned to allow re-negotiation of task priority on a sprint level.

Coding

Pair Programming - Two person working side by side to develop code on one machine together.

Team DaVinci shall adopt pair programming during feature development with following exceptions. In which case, conventional coding practice is followed.

• New development area or when ever expertise is not avaiable in the area of development.
• Assigned developers working on a feature are in separate location.

Code Review

Team DaVinci shall perform code review using one of the following three alternative styles based on development practice. Pair Programming - There is no formal code review in this case. The developer shall inspect each others code while coworking on the program in real-time.

Code inspection - This style is used when reviewer is an expert in the technology area being reviewed and not doing pair programming. The developer shall provide all the implementation source files of the feature developed to the reviewers using Code Review Template. Individual reviewers shall go through the source code line by line and provide feedback to the developer for review discussion.

Code walk throught - This style is used when reviewer is not an expert in the technology area being reviewd and not doing pair programming. The developer shall get together with the reviewer (in a meeting) explain the logical flow of the source code to the reviewer. Reviewer ask question or provide comments in real-time.

Estimates

Team DaVinci follows the scrum task management process to continually estimate task duration update until the task is completed.

• Initial task duration estimation: Baseline task estimation is done using Wideband Delphi. Prior to the planning meeting the team will break down tasks and then makes estimation in 2 rounds as described in planning meeting. The baseline estimation for each task will be the average of all team members 2nd round estimates.
• Task duration estimation update: Task estimation update is done by expert judgment.
  • Normally, individual task owner updates the remaining task effort estimate as part of individual project status report submitted following the common hour.
  • At daily scrum status meeting, team lead alerts individual task owner on over-run task or task re-estimation that exceeds 8 hrs task limits. Team lead shall work with task owner to come up with mitigation plan and/or refined task break down that is less than 8 hours.

Software Configuration Management Plan

Introduction

SMC Management

Organization

SMC Responsibilities

SMC Activities

Configuration Identification

Configuration Control

Configuration Status Accounting

SMC Resources

SMC Plan Maintenance

--Harry 10:51, 14 April 2006 (Eastern Daylight Time) The below sections are to be deleted....

Customer Deliverables

User Operational Manual - Programmer's Guide -

Quality Control

Functional Test Plan - is a description of a test bench (environment) setup and including a series of test cases designed to black-box test a specific software component. These test cases executed under the specified test environment constitutes the verification of a feature described in the related use case traceable to the Product Backlog.

Roles

Team DaVinci has identified the following roles for the Studio project. Some roles are directly derived from Scrum, which is the basis of project management process that the team models for the project, whereas other roles are created in anticipation of practical work area that need attention throughout the project.

Project Management Roles

Scrum, being an Agile process, does not define an abundance of roles, only the project lead, i.e. Scrum Master, and developers. The customer stake-holder is represented by the role of Product Owner. Other roles described below are defined by Team DaVinci for scoping responsibility in specific area of interest.

Product Owner

The product owner is the customer representative who will benefit from the end product produced by the DaVinci team. The product owner should have great interest in defining the product requirements and in providing feedback on artifacts and prototypes produced by the team. The responsibilities include

• Prioritization of the Product Backlog
• Committing to fixed set of requirements during a sprint.

Scrum Master

The definition of a Scrum Master could be stated as: The Scrum Master is the person who conducts the Scrum meetings, empirically measures progress, makes decisions, and gets impediments out of the way of slowing or stopping work. The Scrum Master role is typically filled by a Project Manager or a Technical Team Leader. Some of the responsibilities are the following

• Facilitating the Daily Scrum Meeting and becomes responsible for removing any obstacles that are brought up by the team during those meetings.
• Asking the following questions to the team
  • What did you do since last Scrum
  • What got in your way of doing work
  • What will you do before the next Scrum
• Resolving work impediments ASAP
• Identifying initial backlog

Developer

Everyone else in the team, except the Scrum Master, serves the role as a developer, which is responsible for working on the tasks in the backlog. Scrum teams do not include any of the traditional software engineering roles such as Programmer, Designer, Tester, or Architect. Everyone on the project works together to complete the set of work they have collectively committed to complete within a sprint.

Communication Lead

In order to enable efficient team communication policies, it was decided to create a role for the purpose of establishing, monitoring and improving communication.

• Creating and maintaining team communication processes, such as email policies, document review feedback due dates etc.
• Monitoring and improving communication means and their usage, and, if so feasible, suggesting updates to the communication processes as currently defined.

Process Lead

Scrum is the development process for the DaVinci team and therefore there is a need to document how the team implements the process for the purpose of the studio project. The responsibilities of the process lead are

• Writing and maintaining the Software Development Process Definition document. This document will describe the team’s adoption of Scrum and possible process tailoring.
• Ensuring that the process is followed according to the definition. If any deviations from the process definition are found, either the team should comply to the process in the future or update the definition if so appropriate.
• Actively finding optimizations to the process definition that enable the team to more effectively run the project and propose process definition updates to the team for its review.

Risk Manager

For a project with volatile requirements, it would seem appropriate to identify and mitigate risks as a continuous effort in the project. The risk manager will address the following:

• Writing and maintaining the Risk Management Process, which will describe the team’s risk process implementation and the tasks associated with risk identification and mitigation.

• Writing and maintaining a current Prioritized Risk List describing the top risks in the project at any given time. For these prioritized risks, Action Plans are to be created to execute Prioritized Mitigation Strategies.

• Making sure that the risk process is followed, as documented, by the team.

Team Lead

There are some administrative tasks associated with the studio projects that need one team member’s attention

• Acting as the team’s interface to the studio manager and bypass all relevant information to the rest of the team.
• Coordinating status team meetings, which are attended by the mentors.
• Creating and maintaining the project plan, this is used by the mentors when assessing progress of the team.

Customer Manager

In order to simplify and avoid communication confusion the team’s interactions with the customer, it was decided to assign customer related tasks to one team member, which is responsible for the following

• Acting as a single point of contact for the customer side, which should facilitate team-customer communication, since the customer always knows who to talk to.
• Coordinating requirement elicitation activities, which naturally involve customer communications.

Infrastructure Lead

Throughout the project, the team will have access to a server for the purpose of supporting studio project activities. As a part of the studio project, the team is required to set up a webpage, and furthermore, the team has internal tool needs as well. The role has the following responsibilities.

• Maintaining server configurations in terms of firewalls, network access, account creation etc.
• Installing and maintaining a variety of tools, for instance
  • Subversion. A configuration management tool mainly intended for maintaining team artifacts.
  • VNC. A tool useful for remote access.
  • MediaWiki. A tool selected for maintaining evolving team documents and for serving as a web interface.
  • Skype. A voice and video tool suite useful for distributed team communication.

Meeting Roles

Team DaVinci define the following roles to carry out team meetings as described in [meeting process] section.

Facilitator

The Facilitator has several responsibilities before and during the meeting. Before the meeting:

• Create Meeting Agenda
• Determine meeting particpant based on meeting agenda
• Coordinate meeting resources (time and place of meeting, and communication mechanism if distributed participants)
• Coordinate preparation materials for meeting
• Notify the time, place, communication, and agenda of meeting to participant list one day before the meeting.

During the meeting:

• Maintain focus of meeting (Redirect out of scope topic)
• Assign action items

Time Keeper

The Time Keeper is responsible for controlling the paste of meeting to keep the meeting complete on time. E.g. Remind the speaker when a discussion topic is exceeding set time or taking too long.

Scribe

The Scribe has several responsiblities during and after the meeting. During the meeting:

• Record discussion transactions.
• Take notes of action items
• Reconfirm action items at the end of the meeting.

After the meeting:

• Distribute meeting minutes.
• Enter action items into Action Item Data Base.
• Enter decisions on Team Decisions.