Make your own free website on Tripod.com

Capstone Roadmap

Project Guidelines- Spring 2006

Home
Overview
News
Course Schedule
Capstone Lecture Notes
FAQ's
Contact
Projects Managers
Job Opportunities
The Survivors
Capstone Showcase April 24, 2006

1- Introduction

 

Starting from Fall 2005, we unleashed a new version of the capstone course experience that is more adaptive, more team-intensive and more speedy. This version is a response to our evolutionary capstone experience in real world projects in which change management, effective collaboration and agility have been dominant factors in influencing team performance and problem solving quality. Our approach benefits tremendously from agile software development strategies with more emphasis on Scrum and FDD (feature driven development) as key models.

FDD-SCRUM Presentation

SCRUM Development Process

FDD Process Diagram

FDD Process Explained

UML Use Case , Class and Sequence Diagrams

UML Tutorial 1

UML Tutorial 2

2- Timeline

 

      As a result and based on the fact that the deadline for forming all teams and selecting all projects will be Friday Feb 3rd 2006 , the following is an illustration of how all projects will progress    :

 

1-      Each team will have to finish their project within a series of (5) sprints (or iterations) where each sprint is two-week long as follows   .

 

a.      Sprint (1) starts on Monday Feb 6th and concludes on Monday Feb 20th. The deliverables should be presented to the client during that week. A presentation to the class is also required on Tuesday Feb 21st, Wednesday Feb 22nd or Thursday Feb 23rd depending on your class time.  

b.      Sprint (2) starts on Monday Feb 20th and concludes on Monday March 6th .The deliverables should be presented to the client during that week. A presentation to the class is also required on Tuesday March 7th, Wednesday March 8th or Thursday March 9th depending on your class time. 

c.       Sprint (3) starts on Monday March 6th and concludes on Monday March 27th. The deliverables should be presented to the client during that week. No presentation is required to the class for this sprint

d.       Sprint (4) starts on Monday March 27th and concludes on Monday April 10th. The deliverables should be presented to the client during that week. No presentation is required to the class for this sprint.

e.       Sprint (5) [FINAL ONE] starts on Monday April 10th and concludes on Monday April  24th. The deliverables should be presented to  both the client and the class in the classroom . Depending whether you are in a Tuesday, Wednesday or Thursday project section, your FINAL PRESENTATION will be either on Tuesday April 25th, Wednesday April 26th, or Thursday April 27th.

 

2-      Development teams meet with the client, or product owner, before each sprint to prioritize the work to be done and select the tasks the team can complete in the upcoming sprint.

3-      During each sprint, the ideal situation is that the team stays on track by holding brief 30-minute daily meetings possible. If that was difficult, the team should have at least three brief 45-minute meetings each week.  

4-      At the end of each sprint, the team delivers a potentially shippable product increment.

3- Deliverables

 

The FDD methodology mandates five phases  :

 

1- Develop an Overall Model

2- Build a Features List

3- Plan by Feature

4- Design by Feature

5- Build by Feature

 

Project Deliverables and Timeline through the Five Sprints

 

Sprint number

Starting Date

Ending Date

Client Presentation

Class Presentation

FDD Phase

Deliverables

Key Roles

Sprint 1

 

(2 weeks)

Feb 6th

Feb 20th

Required

 

 

2/21/ 06

2/22/ 06

 

Present and deliver Sprint 1  in class

 

Progress report required

-Entry criteria

-Overall Model

-Feature List

-verification

-exist criteria 

-  Requirements analysis document

- features list

- Class Diagram

- Sequence Diagram

-Compliance with entry/exit criteria

-Project manager

-Chief Architect

-Modeling Team

- Features list team

-Chief Prog.

-Domain Expert

 

Sprint 2

 

(2 weeks)

Feb 20th

Mar 6th

Required

      3/7/06

      3/8//06

 

Present and deliver Sprint 2 in class

 

Progress report required

-Entry criteria

-Plan by Feature

-Design by Feature

-Build by Feature

-verification

-exist criteria 

First features set :

 

 -Plan document

-Design  document

- Features set prototype 

-Compliance with entry/exit criteria

-Project manager

-Chief Architect

- Chief Prog.

- Features sub-groups

 

Sprint 3

 

(2 weeks)

Mar 6th

Mar 27th

Required

No  class presentation

or deliverables required

 

Progress report required

-Entry criteria

-Plan by Feature

-Design by Feature

-Build by Feature

-verification

-exist criteria 

Second features set :

 

 -Plan document

-Design  document

- Features set prototype 

-Compliance with entry/exit criteria

-Project manager

-Chief Architect

- Chief Prog.

- Features sub-groups

 

Sprint 4

 

(2 weeks)

Mar 27th

Apr 10th

Required

No  class presentation

or deliverables required

 

Progress report required

-Entry criteria

-Plan by Feature

-Design by Feature

-Build by Feature

-verification

-exist criteria 

Third features set :

 

 -Plan document

-Design  document

- Features set prototype 

-Compliance with entry/exit criteria

-Project manager

-Chief Architect

- Chief Prog.

- Features sub-groups

 

Sprint 5

 

(2 weeks)

Apr 10th

Apr 24th

Combined with class presentation

4 / 25 / 06

4 / 26 / 06

 

Present and deliver all sprints from

 1-5   in class

 

Final Progress report required

-Entry criteria

-Plan by Feature

-Design by Feature

-Build by Feature

-verification

-exist criteria 

Forth and  combined features sets :

 

 -Plan document

-Design  document

- Features set prototype 

-Compliance with entry/exit criteria

-Project manager

-Chief Architect

- Chief Prog.

- Features sub-groups

 

 

4-   Key Definitions

 

-          Sprints: Time boxed two-week iterations .The team can reduce delivered functionality during the sprint but the delivery date cannot change.

-          Feature: Client-valued functions that can be implemented in two weeks or less .They usually refer to user-interface features. Features are grouped into feature Sets which represent a logical grouping of features that could be delivered to a user as a component in a short time frame.

 

Our feature-driven approach is comprised of three main phases:

 

(1) Project Evaluation Phase

(2) Feature Development Phase

(3) Project Completion Phase.

 

1- During the Project Evaluation Phase:

 

-          desired system functionality is captured as features

-          project scope is defined and negotiated,

-          features are assigned to groups for implementation

-          system requirements are negotiated with the customer

-          The project team is comprised of all members working collectively on system development

-          The project manager oversees the project development.

-          The project team meets with the customer to negotiate project scope

-          The negotiation process enables the project team to evaluate potential project completion in consideration of the resources (time, finances and manpower) available to them.

-          The project manager divides the team into several groups, each comprised of two or more individuals.

-          The project manager assigns the gathered features to these different groups for development.

-          Two artifacts are produced during this phase  :

 

1-      Project Plan

2-      Requirements Worksheet.

 

An overview in the Requirements Worksheet documents the gathered features, feature assignments to groups, scheduled project completion date, membership of the groups, and the team members’ assigned responsibilities. The project risks, addressed during weekly risk mitigation meetings, are also documented in the worksheet, or in a stand-alone Risk Sheet.

 

Several activities are performed in the Project Evaluation Phase. These are explained below.

 

 An initial meeting between the customer and the developers is held to gather desired system characteristics, which are collected as features. The collected features are analyzed to determine project scope, project risks, and required resources for project completion.

 The project manager divides the team equally into groups of two or more individuals.

 Before starting Feature Development, the project team negotiates the scope of the system requirements with the customer at a very high level.

 

2-      During the Feature Development phase

 

-          Features are planned, designed, implemented, tested, and integrated with the overall system.

-          At the beginning of this phase, the groups elicit requirements for the assigned features and analyze feature –scope

-          Additionally each group, with project manager’s lead, meets with the customer to negotiate and clarify requirements for the assigned features.

-          The groups also write acceptance tests for each feature-requirement before writing any code.

-          At this point the customer prioritizes each elicited feature requirement and reviews/approves the acceptance tests

-          The acceptance tests and the feature priorities are documented in the Requirements Worksheet.

-          After the negotiation activity, each group concurrently employs this approach to develop the assigned features

-          The actual completion date of each requirement is also documented in the Requirements Worksheet.

-          The initial prototype is ready for customer evaluation at the end of first Feature Development phase.

-          The customer evaluates the prototype system via the acceptance tests, and suggests modifications, if any.

-          The customer evaluation activity allows the project team to receive customer feedback/suggestions at the end of every Feature Development phase.

-          To ensure customer satisfaction and software quality, the Feature Development phase is iterated to incorporate customer-requested modifications or additions, until the customer finally approves the evolutionary prototype system.

 

Several activities are performed in the Feature Development Phase. These are explained below:

 

Each development group elicits requirements for the assigned features from the customer and group members further evaluate these features and their requirements, to determine if the features can be implemented with the available resources (manpower and time).

 

-After performing resource evaluation, each group, with the project manager’s lead, individually meets with the customer to negotiate the features’ requirements.

 

 After the feature requirements are negotiated, feature planning and design are performed during weekly risk mitigation meetings.

 

 It is recommended to do pair programming for implementation, as a technique to improve productivity and quality.

 

 Quality is addressed in several ways; one way is via testing techniques including feature testing, functional testing and acceptance testing. It is recommended to write acceptance and unit tests before coding.

 

 The customer evaluates each version of the prototype system via the acceptance tests to ensure the satisfaction of all system requirements. Customer satisfaction and software quality is achieved by performing iterations on the Feature Development phase to incorporate customer requested modifications, until the customer approves the evolutionary prototype system. The third phase of the model is called Project Completion Phase and it has two activities.

 

 The customer validates the completed prototype system. After final customer validation, the prototype system is packaged and delivered.

 

 After the system delivery, the development team evaluates the positive and negative experiences during the project. The goal is for the team to incorporate the positive experiences and conduct planning to avoid the negative experiences on future projects. The experiences and resulting plans are documented in a Final Project Report.