The material presented in this appendix is not part of the overall book, but it is something that can be used to help you make decisions. Too often in software engineering, people make decisions based on what are the "right" reasons. However, those reasons are in fact decisions made in meetings based on somebody's opinion. That, in general, is not a bad thing, but using only that sort of decision-making leads to problems in the development of the software application. The purpose of this appendix is to make the decision involved in selecting features and finding problems a process that can be expressed using a mathematical formula.
The first step is to define the action set that will be implemented. The action could be correlated to the feature set, but defines a set of actions that need to be implemented. Features can be actions, and actions can be features, and if it makes you happier , you can use the term "feature" instead of "action." The term "action" is used because "action" is more generic. For example, an action could be maintaining old code, which is definitely not a feature.
Actions could be represented in any format you desire , which could be a spreadsheet or word processor. Since XML is used throughout this book, the actions will be represented as an XML document. For example, Listing A.1 shows a sample action and proposed sub- actions.
<action name="proposed" category="design" date="2002-01-16" timeToImpl="1" timeToImplRisk="1"> <title>Define Web Service Interface</title> <description> Do a high-level analysis of what the Web Service will expose as methods </description> <action name="proposed" category="meeting" date="2002-01-16" timeToImpl="1" timeToImplRisk="8"> <title>Talk to Business</title> <description> Get the business team involved and ask them what they would like to see </description> </action> </action>
In Listing A.1, an XML fragment is used, and multiple actions, with various attributes, are being defined. First, consider in this fragment that there are two action tags. The reason for this is to simplify action dependencies. For example, a higher task might be designing the Web Service. Here, one of your tasks will be to talk to the business team. The two actions are dependent on each other. This is important because it means that if for some reason the Web Service Definition action is not required, then neither is the discussion with the business team.
It's very important, therefore, that the granularity of the action be fine. Otherwise, you will not have control of your software engineering process. The key when you are defining a good process is being able to conceptually figure out what is important and what is not. In the action definition process, your objective is to define a set of variables that you think is correct and then, after the project, to correlate what was actually correct. This way, you can adjust your software process to your specific situation.
Each action tag has the following attributes:
name : This is the identifier of the action tag used to uniquely define the action.
category : This is the category of the action, which can be whatever your internal process is. Examples include design, management, and other terms related to the software engineering process.
date : This is the date at which this action item was created or last edited.
timeToImpl : This is the proposed time that it will take to realize this action. This could be hours, minutes, days, months, or years . It's typical to use days.
timeToImplRisk : This is the certainty of realizing the action as per the timeToImpl attribute. A lower number indicates no risk, whereas a higher number indicates risk. The idea with this attribute is to assign how certain anybody is of realizing a specific action. It is a good idea because it adds a certain boundary of tolerance when you are realizing actions. When the attribute timeToImpl is combined with the attribute timeToImplRisk using a formula, the true time to implement is calculated even though you might not believe it initially.
Besides the child element action , there are two other child elements: title and description . These two fields provide components that make the action understandable to humans . The child elements used in this example are for illustration purposes only and can be whatever the software process specifically needs.