Dashboard > CI Engineering > ... > CI System Engineering Methodology > Design Period Activities
Log In   View a printable version of the current page.
CI Engineering
Design Period Activities
Added by John Graybeal , last edited by John Graybeal on Jun 22, 2010  (view change)
Labels: 
(None)

Description

The focus of the design period is to refine the iteration task list per development team, based on risk assessment, prioritization and resource availability; to perform a task allocation to development team members; and to develop the necessary designs for the remainder of the iteration in the context of the overarching release architecture.

The Design Period is the two-week period that begins an iteration. Coming out of it, we have created or built upon a picture of the entire Release architecture, subject to all the things we will learn during the remaining iterations.

Iteration-Related Note: For Elaboration Iteration 3 activities (which you probably want, if you're reading this note), please see CI R1 E3 Design Period.

Required Before Starting

  1. Input task lists on Google docs: Produced by Architecture team and Design Experts
    1. This will get revised during the two weeks
    2. If this list does not include tasks that need to be carried over, you should start by adding them
  2. Iteration scoping page: Previously developed by Architecture team and Design Experts
  3. Existing requirements
  4. Open requests/suggestions from each IPT
  5. Architecture development support tools in place:
    1. Confluence page organization (and best practices, if there is a page to capture these)
    2. Enterprise Architect
    3. Jira - Must be set up for use by teams
    4. EtherPad/GoogleDocs/other as needed
    5. OmniGraffle + Visio
      1. best practice: upload both original (native) graphic, and png version @ 600DPI, to Confluence
    6. Remote collaboration tools - as needed/decided by each team
    7. Team contact lists| with roles, organization, and availability (leads can augment)
  6. Expected resources availability to accomplish tasks

Intended Products

The primary focus is on the tasks and materials for the current Phase, but products and outcomes should allow for the entire Release product where possible.

  1. Updated tasks lists in Google spreadsheets (using good engineering judgment)
    1. Described
    2. Metric for completion included
    3. Prioritized
    4. Estimated effort required/allocated
    5. Developer assigned as appropriate
    6. URL to Confluence documentation entered
    7. Reviewed by Architecture Lead
  2. Created draft design documentation in Confluence (1 design document can address more than 1 task)
  3. Change and clarification requests for requirements documentation
  4. Drawings and related artifacts
    1. Interaction roles, message types
    2. Updated (or new) UML diagrams representing component/service interactions
    3. Articulation of use cases/stress cases/usage scenarios AND/OR Sequence diagrams
  5. Discussion/analysis/report documents in Confluence (import an archival copy from other collaboration tools as needed)
    1. Put temporary/provisional work in the relevant iteration for that subsystem
    2. Put 'mainline progress' in the main documents area for that subsystem
    3. Integrate progress into the architecture document for the subsystem (process to be determined)
  6. Make sure the correct access/edit permissions exist on all the tools/repositories by all the participants
  7. Technology integration list/assessment (update strawman list, reflect acceptance/approval)
  8. Dependencies table (on other subsystem components, in particular)

The final steps are executed by management:

  1. Tasks/action items/bugs in Jira, assigned and prioritized and all the other stuff above
  2. Biweekly Report issued with those tasks

Task Checklist

No sequence is required in this checklist, but the following sequence is believed to work well.

ID Who Task
A SrDev Make the tasks list in Google docs up to date: (a) Check against Scoping document for this iteration and subsystem. (b) Review open 'Work Remains' tasks from previous iteration and bring them forward. In each case, put the Jira Task # into the appropriate column. This is an important step, so we can tell which tasks are carried forward.
B SrDev Allocate tasks under appropriate Release Task. Every task should be within a Release Task. If there isn't a suitable task, propose a modification to SrSysArch and SysDevMgr.
C SrDev Identify whether tasks are missing. (a) Review empty Release Tasks to make sure work is not needed at this time. (b) Has anyone defined any new needs that are timely? (c) Evaluate progress toward satisfying Product Description use cases that need your work.
D SrDev Assign a priority to the task, one of the following: Nice, Medium, High, Very High, and Showstopper. Priority should reflect risk of the relevant Release Task, and criticality of the task for this iteration (what depends on it, how much is it needed). A reference with these 5 terms will be provided under the Legend page.
E SrDev/Devs Provide description for each task, including a 'Completion Metric:' at end of the description, and estimate the task's length (floating point days). If the task's length is longer than 5 days, it probably should be multiple tasks; split it up as appropriate. If a task really is large, it may make sense to create a coordination task, and divide the rest of the work into other tasks. (Use the links 'organizes' and 'is organized under' in Jira to represent this relationship, but will not use subtasks because those are not tracked in the same way.)
F SrDev/Devs Identify suitable person to lead each task. (Ideally the developers are pleased with these assignments.) Put the person's Confluence/Jira ID into the Lead column. A reference for the possible leads IDs will be made available via the Legend pages.
G Devs Create a page for the design overview for this task, if one does not already exist. Put the URL of this page under Design URL column. All tasks must have a Design URL, but one design page can cover multiple tasks.
H Devs Fill out the broad design overview of the task in the design page. This page should provide enough information for your peers and managers to understand how you expect to achieve the task. After writing the Design overview, make sure the Description (and Completion Metric) of the task is appropriate, and that the WorkDays entry reflects the Descrption and design page.
I Devs When finished doing the above steps for all your assigned tasks, each Developer should confirm that he/she has a reasonable number of tasks, with reasonable likelihood of completing all of them. After doing so, the Developer should notify the Senior Developer that his tasks are good to go.
J SrDev The Senior Developer verifies the developers tasks are good to go, and when all of them are complete, the Senior Developer informs the System Development Manager.
K SysDevMgr/SrArch The System Development Manager and Senior System Architect review all the tasks and design descriptions, and when those have been reviewed and deemed ready, uploads the tasks into Jira. After so doing, the developers are notified and verify that their task lists are as expected.
L SysDevMgr The BiWeekly Report can now be issued for the Design Period.

The developers may not have their time filled during this two week period. At the beginning of the design period, they should continue review of tasks from the previous iterations. Once they have tasks defined and approved by their managers, they can begin work on those tasks.

Design Period Notional Schedule of Activities

Wm.n indicates task to be accomplished by day n in week m. Note that the first day of the Iteration shown here is a Thursday.

The IPTs are the 4 subsystem teams, the Implementation Teams (IPAA, EOI, Sensor Sets), and the Architecture Team.

The Senior Developers are the Senior Developers or leads of the IPTS, and any other senior personnel deemed necessary.

The Management Team is the Project Manager, System Development Manager, and Sr System Architect.

Most progress will be achieved by team members under the leadership of the IPT Lead. Team members may work together or independently, as appropriate to the tasks.

  1. (W1.1-Mo) System Development Manager: Identify availability of team members (optionally, recruit more)
  2. (W1.1-Mo) SrDevs: Identify issues requiring attention of Architecture or other teams; forward to those teams
  3. (W1.1-Mo) Sr. System Architect: Distribute spreadsheets containing Release Tasks in Google doc format
  4. (W1.2-Tu) Architecture Team: Determine proposed approach (priorities/schedule) for resolving Arch issues with IPTs.
  5. (W1.2-Tu) Development Team: Initiation Telecon (review schedule, review team resources, identify issues)
  6. (W1.3-We) SrDevs: Produce schedule of IPT meetings/activities for week, and deliver to Michael, John
  7. (W1.3-We) IPTs: Complete outline of strategy for accomplishing goals (prioritize issues received)
  8. (W1.3-We) IPTs: Placeholder products on Confluence
  9. (W1.4-Th) SrDevs: Progress Assessment Telecon (status, best practices, dependencies)
  10. (W1.5-Fr) IPTs: Preliminary task lists and priorities complete
  11. (W1.5-Fr) IPTs: Planned drawings and artifacts identified
  12. (W1.5-Fr) IPT Leads: Issues assessment (and promotion of major issues to Development Leads) complete
  13. (W1.5-Fr) IPTs: Architecture changes, reflecting current designs, discussed with Architecture Team
  1. (W2.1-Mo) SrDevs: Progress Assessment Telecon (status, best practices, dependencies)
  2. (W2.2-Tu) IPTs: Task lists prioritized and estimated
  3. (W2.2-Tu) IPTs: Drawings and related artifacts largely complete
  4. (W2.2-Tu) IPTs: Technology integration and Dependencies lists complete
  5. (W2.3-We) IPTs: All documentation updated and final on Confluence
  6. (W2.3-We) IPTs: Task lists finalized in Google docs
  7. (W2.3-We) SrDevs: Send mail to System Development Manager on completion of above tasks
  8. (W2.4-Th) Management Team: review task lists, Confluence documents
  9. (W2.5-Fr) Iteration 2 task lists transferred to Jira
Powered by Atlassian Confluence 2.7.1, the Enterprise Wiki. Bug/feature request - Atlassian news - Contact administrators