Zen Development Method
From ZenWiki
Contents |
PURPOSE
(see discussion page)
The ZDM is an ACDM process that was specifically modified for the purpose of Team Zen’s development preference and to conform to the studio schedule for deliverables. We based ourselves on ACDM because of our desire for an architecture based process. However, we made some modifications to ACDM for the following reasons:
- Our desire to experiment on features and release them iteratively to the client
- Role modifications to fit with our desire to manage risk throughout the process
- Equal distribution of tasks and responsibilities
- Nature of the deliverables and schedule of the Studio I course
Advantages (ACDM based)
- Help refine the functional requirements, quality attribute requirements, and constraints
- Help set and maintain expectations in stakeholders
- Define the team structure
- Aid in creating more accurate project estimates
- Establish the team vocabulary
- Help identify technical risk early
- Guide the creation of a more realistic and accurate production schedule and assist in project tracking and oversight
- Provide an early vision of the solution/system
STEPS
| Stage | Description | Activities and artifacts |
| 1 | Elicit requirements and architectural drivers | Meet with client stakeholders to discover and document project requirements and architectural drivers: high-level functional requirements, constraints and quality attributes. |
| 2 | Establish project scope | Distill architectural drivers and client requirements into a software requirements specification (SRS). Create a Statement of Work, project proposals, and a Preliminary Project Plan. |
| 3 | Refine SRS to create notional architecture | Refine the SRS and elicit additional information from the client to make it more stable.
Create the initial architecture which includes a physical view of the system. |
| 4 | SRS and architectural review | Review the SRS and architecture to discover and document risks and issues, make proper modifications to the artifacts, and determine what module needs to be implemented next. |
| 5 | Modular production Go / No-Go | Prioritize and list the risks and issues discovered during the architecture review and decide whether the modular piece of the architecture is ready for production (production step 6) or whether it needs to be experimented to refine it (refine step 6). |
| Refine (No-Go) – Architecture needs to be refined | ||
| 6 | Modular experimenting | Team creates experiments that explore a possible implementation of the solution, and mitigate risks and/or issues that were discovered. The experiments are designed using a combination of a mini-ATAM and ADD analysis to reflect a quality attribute scenario and relate the experiment to the architecture. |
| 7 | Experiment review and architecture refinement | The architecture is refined based on the experiment review (as long as changes are of types 1 or 2; type 3 requires an architectural redesign). |
| Return to stage 4 to review the refined SRS and architecture | ||
| Production (Go) – System or module of the system are ready for construction | ||
| 6 | Production planning | Team creates a detailed plan for the construction of the system based on the refined architecture. Each element of the architecture has an “owner” and shepherds the construction of the element to completion. The plan schedules time and resources for detailed element design, reviews, construction, test, and so forth. |
| 7 | Production | The team executes the production plan and is actively engaged in building the system. Production includes construction of the elements of the architecture, integration of the system, as well as element and system test. Production may result in producing the whole system, parts of the system, or in deliverable increments of the system. |
| Return to stage 4, Architectural Review, and iterate stages as needed | ||
ROLES
Team Zen has defined roles similar but slightly different from the ACDM roles. The key points to note are:
- The Team Lead role will ensure that the ZDM is being followed, not the Support Engineer
- The SOW will be owned and managed by the support engineer, not the Requirements Engineer, to distribute tasks more evenly.
- The Software Engineer role will be assumed by every member of the team, and will follow the XP methodology, described in Team Zen’s implementation proposal.
Team Zen will be using the following general roles based on the Microsoft Solution Framework (MSF) roles and ACDM roles:
| Role | Description | Member |
| Program manager / Team lead / Managing Engineer: | Responsible for the development process (definition and tracking) and for delivering the solution to the customer within the project constraints.
Coordinate the creation and documentation of the preliminary and production plans and schedules. Conduct project tracking and oversight. Ensure that the ZDM is followed, record deviations from the method, document changes to the ZDM as required. | Session |
| Product manager / Customer relations manager / Requirements engineer: | Responsible for managing customer communications and expectations. Act as lead in gathering and documenting functional requirements; Coordinate quality attribute discovery and documentation. The product manager ensures that customer business needs are met. The product manager also works on project communication plans such as briefings to the customers, marketing to users, demonstrations, and product launches. | Marc |
| Development manager / Chief scientist: | Responsible for developing the technology solution according to the specifications provided by the program manager role.
Coordinate the creation and documentation of the experiments and research studies. Coordinate test planning, documentation of the test plan, and test execution. | Sajjad |
| Support engineer: | Set up and maintain development support tools (development environments, CM, and so forth). Establish and maintain web presence as necessary. Establish and maintain a defect logging and tracking processes.
Responsible for identifying and addressing all product quality issues and approving the solution for release. This role evaluates and validates design functionality and consistency with project vision and scope. Analyzes performance needs and support issues of the users and considers the product implications of meeting those needs. | Allen |
| Release manager / Chief architect: | Coordinate creation of the notional architecture and refining it as necessary; Coordinate architectural reviews; capture and document architectural risks and tradeoffs; Coordinate creation and maintenance of architecture documentation.
Responsible for smooth deployment and operations of the solution. The release manager validates the infrastructure implications of the solution to ensure that it can be deployed and supported. | Somakala |
ZDM Roles also follow the stage-specific roles recommended by ACDM. The differences are the following:
- The stage name
- The Software Engineer role is assumed by all members
- The tasks of the additional roles in the stages are defined in greater detail in the Zen Semester Plans.
