Problem Definition Proposal

1. Inception (Fall 2010) 1.1. Contextual Design Objective Deliverables Approaches Analysis Result Reflection 1.2. Knowledge Transfer Sessions Objectives Deliverables Approaches Analysis Result Reflection 1.3. TSP Team Member Training Objectives Deliverables Approaches Analysis Result 1.4. Use Case Analysis Objectives Deliverables Approaches Analysis Result Reflection 1.5. UI Mock-up Prototype Objectives Deliverables Approaches Analysis Result Reflection 1.6. Software Requirement Specification (in User Stories format) Objectives Deliverables Approaches Analysis Result Reflection 2. Elaboration (Spring 2011) 2.1. Quality Attribute Workshop (QAW) Objectives Deliverables Approaches Analysis Result 2.2. UI Training Workshop Objectives Deliverables Approaches Analysis Result 2.3. Refined UI Prototype Objectives Deliverables Approaches Analysis Result 2.4. Requirement Change Management 3. Construction (Summer 2011) 4. Transition Introduction The objective of this proposal is to document all the activities related to the definition of the problem. In other words, this proposal describes

specifics of the requirement engineering the Tx team will perform in order to understand, define the need of the client and define scope of the project. This proposal will follow the following structure: Objective: Intention for doing this activity. (What do we want to achieve?) Deliverables (is applicable): Any artifacts that will result from this activity Approaches: Methods and techniques to be used to carry out this activity Analysis: The performance index of the activity. How the team knows the method is working? Results: Post-condition of the activity. Reflections: Post-Mortem. Grading of the activity: what worked, what failed, what can be improved?

NOTE: The team is using TSP as the process for software development. At the time when the Proposal was done (October 20, prior to the first launch), the length of the cycles has not been defined, therefore the RUP's phases are used as the basis of planning.

1. Inception (Fall 2010)

This cycle is when most requirement-gathering activity will take place. The following activities will be carried out: Contextual Design Knowledge Transfer Session (KTS) TSP Team Member training Use Case Analysis Mock-up Prototype Documentation of Software Requirement Specification (SRS) Also the First TSP Launch will be held in which business goal along with the initial plan will be defined. The main exit criteria of the Cycle 1 is the release and approval of SRS which will define the scope of the project.

1.1. Contextual Design

This elicitation method will help the team understand how the actual user (TSP practitioner) uses the existing Excel tool.

Objective
To understand the usage of the existing tool To find out any difficulties (breakdowns) the users have when using the existing tool To create a visual model for common understanding. To create an initial vision that narrows the direction of the project

Deliverables
Context Diagram working models: Flow, Sequence, Artifact and Culture model. The vision and the storyboard The User Environment Design

Approaches
Observe and interview two users of different roles from the senior team doing actual work with the existing tool The two users will be observed in two different sessions.

Analysis
Team level of understanding Client review

Result
Two users (Team leader and Plan Manager) from YALA team were observed and interviewed while they were using the Workbook tool. The Working Models were obtained: Flow Model, Sequence Model, Artifact Model, Physical Model The consolidated models from the two users were also obtained.

Reflection
[11/01/2010 - Young] The Physical model were not relevant [11/27/2010 - Sanchai] This method is not appropriate. We spent a lot of time but learn a few things. The most important things I learned are how to use the Excel tool and problem on usability aspects. [11/27/2010 - krishna] We were under the impression that we have to build the TSP tool and hence we did the contextual design on the excel tool. Later, we came to know that we would only be implementing PSP, and hence this work was not useful at all for the studio.

However, we came to know a bit about the excel tool.

1.2. Knowledge Transfer Sessions

One of the considerations for this project is the knowledge acquisition from the previous PSP/TSP team (ProTech+).

Objectives
To acquire knowledge from ProTech+ team regarding their project The transferred knowledge should be enough for the team to be able to: Make architecture and design decision Modify by enhancing and/or extending the existing code base.

Deliverables
A report containing Context and characteristics of the system Continuation of the existing system. Approaches, rationale, and alternatives. Reuse boundary: Parts that will be reused as-is. Enhance boundary: Parts that will be modified for enhancements. Possible extension: New part added on top of the existing system.

Approaches
Hold series of sessions with the ProTech+ team Create Artifact Analysis Reports

Analysis
Quizzes Analysis reports

Result
[11/01/2010 - Young] Source code Analysis

Reflection
[11/27/2010 - Sanchai] Knowledge transfer session is good. The drawback of this method is taking a lot of time. I am ok with quiz but questions is sometimes hard or vague. The objective is to discuss as a team however, it is not good for the first semester because we did not have enough time to discuss. [11/27/2010 - Krishna] We understood the broad details of the system, the design decisions that went in, etc. However, we did not get any concrete information (e.g. how much time would it take to implement automated testing on the code, how much time can it take to resolve the known issues, how many unknown issues are estimated to be in the code,etc) [11/30/2010 - Ming] Some of the topics in knowledge transfer session can be understood better, if we have taken the corresponding class. For example, Domain Object, Data model, and Architecture, we have to take the 2nd semester's classes to understand these topics.

1.3. TSP Team Member Training

The TSP Coach will train the team member in order to increase the domain knowledge.

Objectives
To all team members become proficient in TSP.

Deliverables
N/A

Approaches
Hold series of training session on Fridays with the TSP Coach.

Analysis
Coach evaluation

Result
[11/27/2010 - Sanchai] Overall is great but it can be shorten. We learned detail of each meetings but we forgot when real launch meeting. [11/27/2010 - Krishna] Gave a good idea of TSP. However, some of the information was already known (TSP symposium). Some aspects were clear at a theoretical level, but we did not understand the practical significance (e.g. risk identification,etc). Also, our launch was delayed because of the training. Overall, a one day session would have been very effective. [11/27/2010 - Young] The exercises (i.e. the EV calculation) were useful. The explanation about the meetings could have been summarized. [11/30/2010 - Ming] We got a general idea of TSP. If we could learn some practical methods, the training would be more helpful.

1.4. Use Case Analysis

Use Cases modeling will be used to further analyze the "who, what, how".

Objectives
To analyze in-depth the feature set provided by the client in terms of "who" can do "what" and "how". To concretely describe the user stories and prioritize client needs. To narrow down the scope of the project.

Deliverables
Use Case Diagrams Conceptual Use Case Base Use Cases Use Case Specifications Business Domain Use Case Catalog

Approaches
Hold a session with the client and inquire the details of features and user stories Analyze the information provided by the client and identify actors and use cases Perform standardization of style, format, and formality. Perform factorization Document the materials Validate with the client and go through more iteration until satisfied (two iteration expected)

Analysis
[11/27/2010 - Young] The original intent was to show the UC to the client for revision and scope definition. It was later changed to user stories by mentors suggestion.

Result
Use case diagrams of PSP and TSP which included main use cases.

Reflection
[11/27/2010 - Sanchai] I have no comment bacause I am not familiar with use cases [11/27/2010 - Krishna] Was good, but again, same comment as in CD. Not relevant to studio. [11/27/2010 - Young] The interactive session with the client was interesting. Nevertheless, our mentor suggested using user stories instead, so the UC turned out to be less relevant. [11/30/2010 - Ming] It is a nice opportunity to practice. However, we are building a software(PSP tool) from scratch, so the most important thing to know is what is our client intend for. UC tend to model the interact between users and system, it drive us to make certain design decisions at early stage. As our mentor suggested, using user stories would be more suitable.

1.5. UI Mock-up Prototype

A prototype will be used to validate the "big picture" of the system.

Objectives
To synthesize main user scenarios in a concrete visual way. To validate the main user scenarios from the client. To have a more precise idea of the client's expectation.

Deliverables
Storyboard of the main user stories.

Approaches
Define with the client the main focus areas to prototype. Narratively describe the user scenarios. Use PowerPoint or HTML to draw the screens. Have the client simulate a scenario.

Analysis
[11/27/2010 - Young] Although the UI were created,

Result
A medium-fidelity UI prototypes for Estimation and Task/Schedule focus area

Reflection
[11/27/2010 - Sanchai] In fall semester, I created prototype for method class. It is not good because I focused to create wonderful prototype to satisfy graders. [11/27/2010 - Young] I wonder if the client would be interested in the paper prototype, (the previous team has done this and seems that they did not get much value out of this activity because of the nature of the project). Perhaps a running UI with actual technology candidate would catch client's interest.

1.6. Software Requirement Specification (in User Stories format)

The SRS is the document that will define the scope of the project.

Objectives
To list up the functional requirements in a testable format

Deliverables
List of User Stories and Test Cases

Approaches
A group of three people will brainstorm and define the format to be used for the user stories document. The stories will be listed and divided into the 5 members. Each member will write the assigned user stores. The user stories will be peer reviewed

Analysis Result Reflection

[11/29/2010 - Young] Still a little confused about user strories and story cards. [11/30/2010 - Ming] Although I spend a lot of time to indentify the difference between user stories and story cards, I did not find any clues. [11/30/2010 - Ming] The objective or purpose of using user stories is not clear(for me). To list up the functional requirements in a testable format, our client would like to see more readable format to approve the SRS. [11/30/2010 - Ming] Using user story means that we have to constantly negotiate each user story with users or our client. For our project, users and clients are not readily available.

2. Elaboration (Spring 2011)

In this cycle, based on the approved SRS, the team will carry out activities to complement, clarify and add further information that may be missing in the SRS. Also changes to the requirement will be manages accordingly. The activities included in this cycle is as follows

Quality Attribute Workshop UI Prototype Requirement Change Management

2.1. Quality Attribute Workshop (QAW)

The QAW will identify the quality attributes that will be the bases for architectural drivers. (Responsibles)

Objectives
To identify the quality attributes To precisely define the quality attributes To prioritize the quality attributes

Deliverables
Prioritized list of quality attributes Definition of quality attribute items

Approaches
Follow the QAW 3rd edition document: TECHNICAL REPORT, CMU/SEI-2003-TR-016, ESC-TR-2003-016

Analysis Result

2.2. UI Training Workshop

A short training about User Interface.

Objectives
To improve our skill in UI design.

Deliverables
N/A.

Approaches
Either a person from HCII or Marsha will give a "crash course" on UI design.

Analysis
TBD

Result

2.3. Refined UI Prototype

The resulting product of the project involves a lot of user interaction. The UI prototype will mitigate the risk of requirement volatility in the presentation layer.

Objectives
To have precise idea of the look and feel and flow of the user interface.

Deliverables
User Interface templates. User Interface standard guideline.

Approaches

HTML or the actual technology for presentation layer will be used to create set of sample user interfaces. (Check for alternative Tools, check for HCI people, codegen) The customer will navigate through the interfaces and give opinions. The design principles (CRAP) will be taken into consideration to define the UI standard. Receive an acceptance from the client. (prior Schedule, or surrogate)

Analysis Result

2.4. Requirement Change Management

Refer to Project (Process?) Planning: Requirement Change Management. Also see Statement of Work

3. Construction (Summer 2011)

The Requirement should not change from this point, except for minor fixes. No activity is planned. Minor fixes are those that does not affect the architecture, does not impact the schedule for more than 5 days.

4. Transition