Work Product (Artifact): Development Process








var defaultQueryStr = '?proc={35359DDF-6361-43E5-8B1B-18D204DA8CFF}&path={35359DDF-6361-43E5-8B1B-18D204DA8CFF},{CD77CBDA-CC13-4593-BB81-41AF3FF7A84C},_pjIqoEoiEdqrjq4i3fchvA';
var backPath = './../../';
var imgPath = './../../images/';
var nodeInfo=null;
contentPage.preload(imgPath, backPath, nodeInfo, defaultQueryStr, false, true, false);










Work Product (Artifact): Development Process















This work product describes the process that a project is to follow in order to produce the project's desired results. This work product is also referred to as the Software Development Process.






Purpose



The purpose of the development process is to provide guidance and support for the members of the project. "Information at your finger tips" is a metaphor that aligns well with the purpose of this work product.



Relationships



RolesResponsible:



Process Engineer


Modified By:




Main Description



Every Process is comprised of an n-level breakdown structure. Core method content provides step-by-step explanations, describing how very specific development goals are achieved, independent of the placement of these steps within a development lifecycle. Processes take these method elements and relate them to semi-ordered sequences that are customized to specific types of projects. Thus, a process is a set of partially ordered work descriptions intended to reach a higher development goal, such as the release of a specific software system. A process focuses on the lifecycle and the sequencing of work in breakdown structures. There are different types of processes: Delivery Process and Capability Pattern. Delivery Process A Delivery Processes describes a complete and integrated approach for performing a specific type of development project. A Delivery Process is a process that covers a whole development lifecycle from beginning to end. A Delivery Process is used as a template for planning and running a project. It provides a complete lifecycle model with predefined phases, iterations, and activities that have been detailed by sequencing method content in breakdown structures. It is defined on the basis of experience with past projects or engagements, and/or the best practice use of a development or delivery approach. It defines what gets produced, how those items are produced, and the required staffing in the form of integrated Work, Work Product, and Team Breakdown Structures. For example, a process engineer can define alternative Delivery Processes for software development projects that differ in the scale of the engagement and staffing necessary, the type of the software application to be developed, the development methods and technologies to be used, etc. Although, the Delivery Process aims to cover a whole project, it keeps certain decisions that are too project-specific open. For example, the breakdown structure defines which Breakdown Elements have multiple occurrences or is repeatable via its respective attributes, but does not say how many occurrences and how many repeats/iterations it will have. These decisions have to be done by a project manager when planning a concrete project, project phase, or project iterations. Capability Pattern A Capability Pattern describes a reusable cluster of Activities in common process areas. Capabilities Patterns express and communicate process knowledge for a key area of interest such as a Discipline and can be directly used by a process practitioner to guide his work. They are also used as building blocks to assemble Delivery Processes or larger Capability Patterns ensuring optimal reuse and application of the key practices they express. Examples for Capability Pattern could be 'use case-based requirements management', 'use case analysis', or 'unit testing'. Typically but not necessarily, Capability Patterns have the scope of one discipline providing a breakdown of reusable complex Activities, relationships to the Roles which perform Tasks within these Activities, as well as to the Work Products that are used and produced. A capability pattern does not relate to any specific phase or iteration of a development lifecycle, and should not imply any. In other words, a pattern should be designed in a way that it is applicable anywhere in a Delivery Process. This enables its Activities to be flexibly assigned to whatever phases there are in the Delivery Process to which it is being applied. It is a good practice to design a Capability Pattern to produce one or more generic Deliverables. The typical configuration is that each Activity in the Capability Pattern produces one Deliverable, and the last Task Descriptor in the Activity explicitly outputs just this Deliverable. This enables the process engineer to select Patterns or just Activities by deciding which Deliverables are required. It also offers a simple integration approach: an Activity from a capability pattern is linked to the Phase or Iteration which is required to produce the Activity's Deliverable.



Properties



Optional


Planned



Key Considerations



You may decide not to capture the entire process in the Development Process. In some cases, a lot of responsibility, and decisions about the process, and the work products in particular, are delegated to members of the software development project. For example, if there is an experienced, good project manager, you may leave it to this individual to decide on what plans to produce and how to produce them. In the same way, many project managers aren't concerned about how each team member designs his or her part of the system, as long as they deliver the expected functionality on time and within a reasonable level of quality. One reason for having a process description at all is so several people can share information. If this is not the case, then the cost of maintaining the process description may be too high. Therefore, you may decide not to have, or maintain, the process description for one or several disciplines. This doesn't mean that you don't put effort into that particular discipline, nor does it mean that you don't think it's important. For example, you may employ an excellent test manager, provide all possible support, but leave it to that test manager to decide how to work and what work products to produce.





©  Copyright IBM Corp. 1987, 2006.  All Rights Reserved.







contentPage.onload();
contentPage.processPage.fixDescriptorLinks();