Value Function Deployment In A SoftwareProcess
Petri J. Pulli, Marko Heikkinen · WIT transactions on information and communication technologies · 1970
Quality Function Deployment (QFD) is widely accepted as a value function to guide product development to meet customer needs. We propose a complimentary value function, Risk Function Deployment (RFD), to guide through the uncertainties and risks associated with the product development. RFD makes use of QFD-style matrix-based correlation techniques in risk analysis and prioritization to capture product risk-elements and their probabilities and losses, and to detect risky parts of the product. RFD also supports risk management by evaluating the effect of individual risk mitigation activities. According to our experiences, the benefit of RFD lies in visualizing the complementary sides of decision making, benefits and risks, and by providing a framework for balancing them. The role of value functions, such as QFD and RFD in the software development process is discussed. Our point of view is from the development of embedded real-time systems. We believe that value functions are able to increase the visibility of the evolving software product, reduce change penalty, and bring closer discipline specialists. Use of value functions enables new management approaches to software development process that are more concurrent and goal-directed rather than activity-based and serialised. Management issues of concurrent goal-oriented software development processes are not well understood and thus open interesting new avenues for research. INTRODUCTION Much of the recent research in software process improvement is related to software process maturity movement ignited by Carnegie-Mellon University Software Engineering Institute followed by similar activities in Europe, such Transactions on Information and Communications Technologies vol 8, © 1994 WIT Press, www.witpress.com, ISSN 1743-3517 476 Software Quality Management as Esprit/Bootstrap project. We acknowledge these activities with high respects. However, we see these approaches good for catch ing-up genericsoftware process when the starting point is fairly low. However, maturity movement with its generic process assessment does not give sufficient direction for companies aiming further. We believe especially in the domain of embedded real-time systems that the way to improve the software process is to customise each instance of the software process according the product under development. This means that the underlying generic software development process must be instantiated and run bearing in mind t he goal(s) of the product to successfully enter the marketplace. Traditionally instantiation of t he process is carried out by project planning, i.e. definition of work breakdown structure (WHS) leading to a set of activities. Then a project schedule is drawn that describes a plan to run this set of activities concurrently taking into account the resources planned to be available. The point of our critic is that this kind of project plan is just an intelligent guess how things could go. not a real instantiation of a project. Running a project is trying to keep deviations to the project plan as small as possible. Typically, progress monitoring is based on percentage activities completed. Most of the projects run this way show relative good progress in completing the early activities where the completion of the activities is easy since the ambition level can he adjusted. The going gets tougher later when work is built upon results of earlier activities. Typically, in real-time software development projects this leads often to huge testing and integration problems many times 50 percent of project effort is spent on integration testing. The point of our critic is that project managers tend to monitor percentage activities completed rat her than how far the product under development is from the goal. A natural consequence of t he guess-based process instantiation and percentage based activity monitoring is the need to change project plans frequently late in the project when the project manager no longer can hide the deviations. The longer the project manager tries to hide deviations, the longer he/she is ignoring signals from the process that could be used to guide the process towards its goals. A new project plan is typically created by killing some of the less important activities and concentrating effort on delayed essential activities. The result of this kind of projects is often a handicapped product entering the market too late. We are looking for improved techniques for both process instantiation and running the process. We have directed our interest to • Goal-directed software development process models fl] which support Transactions n Information and Communications Technologies vol 8, © 1994 WIT Press, www.witpress.com, ISSN 1743-3517 Managing Quality Systems 477 instantiation based on market and product characteristics. • Value functions, since they have potential to give insight on how far the product under development is from the goal(s). GOAL-DIRECTED PROCESS A goal-directed approach views the process instantiation as setting of highlevel explicit goals and defining the policy to decompose those goals further into explicit sub-goals. Running a goal-directed project is maintaining the dependencies of sub-goals on goals, and changing, deleting or defining new goals. The essential mechanisms are: Defining goals and rationales: The designer working in an a goal-directed process environment sees a list of goals to achieve. Also the rationales for these goals are explicit, at least how they relate to higher level goals. Allocation of goal tree to concurrent sub-goal trees: Decomposition of development task into smaller, lower-level (less abstract) development tasks to development teams or individuals. The purpose is to find sub-goal trees with high internal cohesion and relative low mutual coupling. Pattern-matching a sub-goal tree for reuse: Lookup of existing fully elaborated sub-goals if (parts of) the current sub-goal can be substituted by reusable components. At the lowest level this could be matching against the programming language statements Validation of a Sub-Goal: Checking the consistency of a state of a subgoal tree. Verification between Sub-Goals: Ensuring that the interfaces between concurrently proceeding sub-trees match so that they fill the upper level goals. Storing Intermediate States of a Goal Tree: Recording the route how the goal tree has been built. Redoing a Sub-Goal: The purpose of redoing mechanism [2 is to support re-running the process with different goals, i.e. making changes to the product. QUALITY FUNCTION DEPLOYMENT Goal-directed process needs a reliable set of value functions for pruning sub-goal candidates at any level of goal tree. Otherwise the benefits of the process model are difficult to access, since without sufficient control information, the process is in danger of getting lost in the multitude of design Transactions on Information and Communications Technologies vol 8, © 1994 WIT Press, www.witpress.com, ISSN 1743-3517 478 Software Quality Management