00001.tif

PDF

Download

Open document

Transcript (if available)

Content MODELING AND ANALYZING TH E SOFTW ARE PROCESS AND PROCESS BREAKDOW NS by Peiwei Mi A Dissertation Presented to the FACULTY OF TH E GRADUATE SCHOOL UNIVERSITY OF SOUTHERN CALIFORNIA In P artial Fulfillment of the Requirem ents for the Degree D O CTOR OF PHILOSOPHY (Com puter Science) December 1992 Copyright 1992 Peiwei Mi UMI Number: DP22851 All rights reserved INFORMATION TO ALL USERS The quality of this reproduction is dependent upon the quality of the copy submitted. In the unlikely event that the author did not send a complete manuscript and there are missing pages, these will be noted. Also, if material had to be removed, a note will indicate the deletion. Dissertation Publishing UMI DP22851 Published by ProQuest LLC (2014). Copyright in the Dissertation held by the Author. Microform Edition © ProQuest LLC. All rights reserved. This work is protected against unauthorized copying under Title 17, United States Code ProQuest LLC. 789 East Eisenhower Parkway P.O. Box 1346 Ann Arbor, Ml 48106- 1346 UNIVERSITY OF SOUTHERN CALIFORNIA THE GRADUATE SCHOOL UNIVERSITY PARK LOS ANGELES, CALIFORNIA 90007 P h - D . D p S * ^ 2 - IVlwig This dissertation, written by PEIWEI MI under f/ze direction of h.?.$...... Dissertation Committee, and approved by all its members, has been presented to and accepted by The Graduate School, in partial fulfillment of re quirements for the degree of DOCTOR OF PHILOSOPHY Dean of G raduate Studies Date Septem ber 2 2 , 1992 MMITTEE Chairperson Dedication I dedicate this dissertation to: Mian Li, my wife. Shouzeng Mi and Guocheng Feng, my parents. ii Acknowledgements I would like first to express my sincere gratitude to Dr. W alt Scacchi, my dissertation advisor, for his continuing and enthusiastic support, advice, and encouragement during the past years. I would like to thank him again for reading the early drafts of this dissertation, providing valuable suggestions, and pointing out gram m atic errors. W ithout his effort, this dissertation would not be in such a good shape. I also would like to thank the other members of my dissertation com m ittee - Dr. Ellis Horowitz and Dr. W illiams D utton for their valuable suggestions and comments on this dissertation. I would like to thank my colleagues and friends, Song Choi, Douglas Fang, An thony K arrer, Junhui Luo, and John Noll. They were all very helpful in all kinds of discussions and providing careful reviews of drafts of papers. W ithout their help, the ideas presented in this dissertation as well as the A rticulator system would be in terrible shape. I would also like to thanks those students who participated ini the development of the A rticulator system as their directed research during the past three years. These students include Mei-Ling Chang, Thom as Getzinger, June-Ming* Lee, M ian Li, Chung-An Lin, and Yu-ling Young. Their development contributions! to process modeling in some case studies, graphic process visualization tools, and process translation tools are acknowledged. I would like to thank the State Education Commission, the People’s Republic of China, for providing me w ith a scholarship which enabled me to come to USC for graduate study at the beginning. I would also like to thank the following government agencies and companies who have sponsored this research over the past five years. W ithout their continuous support, this research is not possible. These sponsors include: AT&T Inc., Hewlett-Packard Company, the Naval Ocean Systems Center. N orthrop Inc., and Pacific Bell. iii Contents D edication A cknow ledgem ents List O f Tables List O f Figures A bstract 1 Introduction 1.1 The Problem s and The S o lu tio n ................................................. 1.1.1 Software Process Definition and Static Analysis . . 1.1.2 Software Process Enactm ent and Dynamic Analysis 1.2 Research A p p ro a c h ......................................................................... 1.3 Overview of the D isse rta tio n ....................................................... 2 R elated W ork 2.1 Software Process Modeling T e c h n iq u e s ................................... 2.1.1 Programming-Based Modeling T e c h n iq u e s .............. 2.1.2 O bject-Based Modeling T e c h n iq u e s............................ 2.1.3 Evolution-Based Modeling Techniques ..................... 2.1.4 Sum m ary of Software Process Modeling Techniques 2.2 Empirical Studies of System Development ............................ 2.2.1 Studies In the System Factory P r o j e c t ..................... 2.2.2 Studies at M C C .................................................................. ; 2.2.3 O ther S tu d ie s ..................................................................... 2.2.4 Sum m ary of the Em pirical Studies ............................ 2.3 Project and Resource S c h e d u lin g ............................................. 2.3.1 Traditional Resource S cheduling................................... ; 2.3.2 AI-Based S c h e d u lin g ....................................................... 2.3.3 Re-planning and R e -sc h e d u lin g ................................... 2.3.4 Sum m ary of Project and Resource Scheduling . . . 2.4 Discussion and S y n th e sis 32 [ \ 3 A n SP M Formalism: T he A rticulator M eta-M od el 35 3.1 In tro d u c tio n ........................................................................................................... 35 3.2 SPM C o m p o n en ts................................................................................................ 38 3.2.1 A ctivity H ie r a r c h y ................................................................................ 39 3.2.2 Resource R equirem ents......................................................................... 39 3.2.3 Resource Possession................................................................................. 40 3.2.4 O ther Inform ation ................................................................................. 41 3.3 Definition of O bject C la s s e s ............................................................................ 41 3.3.1 The Agent Class .................................................................................... 41 3.3.2 The Task C l a s s ........................................................................................ 48 3.3.3 The Resource C la s s .............................................................. 54 3.4 S u m m a r y ............................................................................................................... 56 4 C onstruction and Static A nalysis of SP M s 57 4.1 In tro d u c tio n ........................................................................................................... 57 4.2 An SPM Definition M e th o d o lo g y .................................................................. 58 4.2.1 Process U nderstanding ................................................................ 60 4.2.2 Informal R e p re s e n ta tio n ...................................................................... 62 4.2.3 Formal R e p re se n ta tio n .......................................................................... 63 1 4.3 Static Analysis of S P M s ................................................................................... 63 j 4.3.1 Syntactic C h e c k in g ................................................................................. 64 i 4.3.2 Sem antic C h e c k in g ................................................................................. 65 1 4.3.3 Process V isu aliza tio n .................. 65 I 4.3.4 Process Query .......................................................................... 71 4.4 Sum m ary ........................................................................................................... 73 5 Case Studies: B uilding Software P rocess M odels 75 5.1 In tro d u c tio n ........................................................................................................... 75 5.2 The N orthrop Process 76 ; 5.2.1 Modeling S t e p s ........................................................................................ 76 5.2.2 The N orthrop Process Model ............................................................ 77 5.2.3 Lessons L e a rn e d ........................................................................................ 79 5.3 The SOFTM AN P r o c e s s .................................................................................... 86 5.3.1 Modeling S t e p s ........................................................................................ 86 5.3.2 The SOFTM AN Process M o d e l......................................................... 88 5.3.3 Lessons L e arn ed 93 i 5.4 The Develop-Change-and-Test-Unit P r o c e s s ............................................. 9 7 1 5.4.1 Modeling S t e p s ........................................................................................ 97 5.4.2 The Develop-Change-and-Test-Unit Process M o d e l ................... 97 5.4.3 Lessons L e a rn e d .......................................................................................... 101 5.5 S u m m a r y .................................................................................................................105 ;6 D ynam ic A nalysis and Sim ulation of SPM s 106 6.1 In tro d u c tio n ...............................................................................................................106 6.2 Enactm ent Semantics of S P M s............................................................................ 107 6.3 SPM S im u latio n ........................................................................................................115 6.4 S u m m a r y ............................................................................................... 119 7 A rticulation Specification 120 7.1 In tro d u c tio n ...............................................................................................................120 7.2 The Problem Space and D iagnosis..................................................................... 122 7.2.1 The Type of B reakdow ns........................................................................ 123 7.2.2 The Usage of A Problem atic Resource .............................................125 7.2.3 The Existence of A Production C h a in .................................................126 7.3 The Solution S p a c e .................................................................................................129 I 7.3.1 The Solution S p a c e ................................................................................... 129 7.3.2 Problem-Solving H eu ristics......................................................................132 7.4 Selection H e u ristic s................................................................................................. 134 7.4.1 Applicability H euristics............................................................... 134 7.4.2 Global Preference H e u ristic s...................................................................135 7.4.3 Circum stantial Preference H e u r is tic s ................................................. 135 7.5 Re-Scheduling Constraints ..................................................................... 136 7.5.1 Syntax of Re-Scheduling Constraints and H e u ristic s..................... 137 7.5.2 Re-Scheduling C o n s tra in ts ......................................................................139 7.5.3 Re-Scheduling H e u ristic s..........................................................................140 7.6 S u m m a r y ...................................................................................................................141 8 T he A rticulation P rocess 142 | 8.1 In tro d u c tio n ............................................................................ 142 8.2 The Diagnosis S u b -P ro cess................................................................................... 145 8.3 The Selection S u b -P ro c e ss........................................................... 149 8.4 The Recovery S u b -P ro c e ss................................................................................... 152' : 8.5 The Re-Scheduling S u b -P ro c e s s ....................................................................... 153 ! 8.6 S u m m a r y ...................................................................................................................160 9 Case Studies: D ynam ic A nalysis of SPM s 161 j i 9.1 T he Scenario for Case S tu d ie s ............................................................................ 161 9.2 Case Study: Process S c h e d u lin g .........................................................................162 9.2.1 Resource E s tim a tio n ................................................................................ 162 9.2.2 Resource A llo catio n....................................................................................167 , 9.3 Case Study: Process S im u la tio n .........................................................................169 | 9.3.1 Process Simulation on the First Resource A llo catio n ......................169 : j 9.3.2 Process Sim ulation on O ther Resource A llo catio n s........................173 1 9.4 Case Study: Process A r tic u la tio n .............................................................. . 175 9.4.1 A Process Breakdown .............................................................................175 9.4.2 Diagnosis ..................................................................................................... 177 9.4.3 S electio n .........................................................................................................178 9.4.4 R ecovery.........................................................................................................179 9.4.5 R e-S ch ed u le.................................................................................................1801 9.4.6 Repair S uggestion....................................................................................... 180 9.5 Lessons Learned from the Case S tu d ie s ...........................................................183 9.6 Sum m ary .................................................................................................................185 10 D iscussions and C onclusions 186 10.1 W hat have we l e a r n e d ........................................................................................ 186 10.2 In R e tr o s p e c t................................................................... 188 10.3 Sum m ary of Research Contributions .............................................................189 10.4 Directions for Future W o rk ................................................................................. 191 vii L ist O f T ables 2.1 Sum m ary of the Program m ing-Based Modeling Techniques . . . . . . 12 2.2 Sum m ary of the Object-Based Modeling Techniques ......................... . . 15 2.3 Sum m ary of the Evolution-Based Modeling T e c h n iq u e s................. . . 16 2.4 Sum m ary of the Empirical Studies ........................................................ . . 23 2.5 Sum m ary of the Scheduling M e c h a n ism s ............................................. 31 4.1 Guidance in Process U n d e rsta n d in g ........................................................ . . 60 4.2 A Simple Form at for Informal R e p re s e n ta tio n ................................... 63 6.1 Values of Status and Their D e fin itio n .................................................... . . 108 6.2 Types of SPM sim u latio n ............................................................................ . . 118 7.1 Dimensions of the Problem S p a c e ........................................................... . . 128 7.2 Dimensions of the Solution S p a c e ........................................................... . . 132 7.3 A Sample Set of Global Preference Heuristics ................................... . . 136 7.4 A Sample Set of Circum stantial Preference H e u ris tic s ..................... 136 8.1 D eterm ination of Breakdown T y p e s ........................................................ 148 9.1 A gent/R ole Requirem ents for the Two SPM ’s ................................... . . 163 9.2 Resource Estim ations for Separate SPM E n a c tm e n t........................ . . 165 9.3 Resource Estim ations for SPM E n a c tm e n t.......................................... . . 166 9.4 Schedules for Sequential SPM E n a c tm e n t............................................. . . 168 9.5 Schedules for Concurrent SPM E n a c tm e n t.......................................... . . 170 9.6 The First SPM Sim ulation T ra je c to ry .................................................... 171 9.7 The Second SPM Simulation Trajectory ............................................. . . 172 9.8 The T hird SPM Simulation T r a je c to r y ................................................. . . 173 9.9 SPM Sim ulation Trajectory on the Second Resource Allocation . . . . 174 9.10 SPM Sim ulation Trajectory on the Third Resource Allocation . . . . 176 9.11 M atch between Diagnosis and PSH ................................................ 179 9.12 The First Modified Schedule for the Two S P M s ......................................... 181 9.13 T he Second Modified Schedule for the Two S P M s ....................................... 182 10.1 Comparison between Program s and S P M s ...................................................188 viii L ist O f F igu res 1.1 Research A p p ro a c h ................................................................................................ 6 3.1 The A rticulator M eta-M o d el.............................................................................. 42 ' 3.2 Definition of Agent C la s s ..................................................................................... 43 i 3.3 Definition of In d iv id u a l-A g e n t and P eo p le S ubclasses...............................45 3.4 Definition of C o lle c tiv e -A g e n t and Team S u b c la sse s.................................. 47 3.5 Definition of Task C l a s s ..................................................................................... 49 : 3.6 Definition of A ctivity Hierarchy Relations .................................................. 50 j 3.7 Definition of R e so u rc e -S p e c if i c a t i o n ......................................................... 51 3.8 Definition of A c tiv ity S u b c la s s ....................................................................... 52 3.9 Definition of T a sk -c h a in S u b class.................................................................... 53 ! 3.10 Definition of Resource and Simple-Resource C la s s e s ......................................54 3.11 Definition of O ther O bject S ubclasses........................................... 55 I 4.1 A Sample Result from Syntactic C h e c k in g ................................................... 64 ] 4.2 A Sample Result from Semantic C h e c k in g ...................... 66 j 4.3 Task Decomposition G raph for P ro g ram m in g............................................... 67 | 4.4 Task Decomposition Table for P ro g ra m m in g ............................................... 68 | 4.5 Task Precedence Graph for P ro g ram m in g...................................................... 68 4.6 A gent/R ole Inform ation for Program m ing .................................................. 69 j 4.7 Resource Production Inform ation for P ro g ra m m in g ................................. 69 j 4.8 A Sample Result from Statistical C h e c k in g .................................................. 70 i 4.9 M et a-knowledge and Its Q u e rie s ....................................................................... 72 i 4.10 Examples of Inform ation Q u e r y ....................................................................... 72 5.1 N orthrop Process: A ctivity H ie ra rc h y ............................................................. 78 5.2 N orthrop-PM : Definition of F o rm u la te -R e q s ............................................... 80 5.3 P artial Sem antic Checking for N o rth ro p -P M ............................................... 81 5.4 Two Task Precedence Graphs for N o r th ro p - P M ........................................ 82 5.5 P artial Resource Production Inform ation for N o rth ro p -P M ....................... 83 | 5.6 Statistical Checking for N o rth ro p -P M ............................................................. 84 j 5.7 The Original SOFTM AN E n v iro n m e n t......................................................... 87 | 5.8 SOFTM AN Process: The Top-Level A ctivity H ie ra rc h y 89 J ; 5.9 SOFTM AN Process: A Second Level A ctivity H ie r a r c h y ....................... 90 I ix 5.10 SOFTM AN-PM : Definition of D esig n -M o d u le-C o n ten t......................... 91 5.11 The Process-driven SOFTM AN E n vironm ent.............................................. 92 j 5.12 Sem antic Checking for S O F T M A N -P M ......................................................... 93 ! 5.13 Top Level Task Precedence Graph for S O F T M A N -P M ....................... 94 5.14 P artial Resource Production Inform ation for S O F T M A N -P M ............. 95 5.15 Statistical Checking for S O F T M A N -P M ................................................... 96 5.16 Develop-Change-and-Test-Unit: A ctivity Hierarchy ........................ 98 5.17 Develop-Change-and-Test-Unit-PM : Definition of M odify-D esign . . 99 5.18 Sem antic Checking for D evelop-C hange-and-T est-U nit-P M ...................100 5.19 Task Precedence G raph for Develop-Change-and-Test-Unit-PM . . . . 101 5.20 P artial Resource Inform ation for Develop-Change-and-Test-Unit-PM . 102 5.21 Statistical Checking for Develop-Change-and-Test-Unit-PM . . . . . . 103 6.1 Transition of Process S t a t u s ..............................................................................110 6.2 E nactm ent Hierarchy of A c tiv ities....................................................................112 6.3 SPM S im u latio n ...................................................................................................... 115 6.4 A Sim ulation Rule for An Activity by In d iv id u a l-A g e n ts .......................118 7.1 Representation of A rticulation K n o w le d g e .................................................. 121 7.2 Definition of D i a g n o s i s .....................................................................................128 7.3 Algorithm ic Description of Redo-and-Review ........................................... 134 7.4 A Sample Applicability H e u r is tic ....................................................................135 8.1 The A rticulation P ro c e s s .....................................................................................143 ! 8.2 Sub-Process Interaction in the A rticulation P r o c e s s .................................146 | 8.3 The Diagnosis S u b -P ro cess................................................................................. 147 8.4 The Selection S u b -P ro c e ss ..................................................................................150 8.5 An OPS5 Rule to Select Applicable PSHs .................................... 151 8.6 The Recovery S u b -P ro c e ss................................................................................. 152 8.7 An OPS5 Rule to Execute P S H s ....................................................................... 153 8.8 The Re-Scheduling S u b -P ro c e ss.......................................................................155 9.1 Algorithm ic Description of R edo-and-Review ( P S H 1 0 ) ..........................179 ' 9.2 T he Modified D evelop-C hange-and-T est-U nit-P M .................................... 183 10.1 Software Process M echanisms in a Process-Driven S E E ..........................192 Abstract In recent years, software process technology has emerged as a promising direction in the study of new methodologies for large-scale software developm ent. Research into software processes has been focused in two directions. (1) Modeling of software proj cesses which proposes formalisms for specifying software processes, called Software Process Models (SPM s); (2) Enactm ent of SPMs which guides developers through software development. However, such research does not address issues of analyzing! validating, and articulating SPMs th at are created by a process formalism and exj ecuted during SPM enactm ent. Users m ust rely on their own skill and knowledge of process modeling to define a customized SPM. Even worse, to accom m odate enj vironm ental changes during SPM enactm ent, they have to update an SPM withoul any autom ated support. This makes it very difficult to integrate SPM enactm ent into a software engineering environment. The A rticulator system presented in this dissertation supports modeling anc analyzing software processes, and recovering from process breakdown during SPM enactm ent. The A rticulator incorporates an object-oriented representation of soft ware processes and process breakdown using a process m eta-m odel. This meta-j model enables the static analysis of SPMs as to help users describe and validate their own software processes. Static analysis of SPMs includes: an SPM definition methodology, mechanisms for checking SPM definitions, and mechanisms for pro-j cess visualization. This m eta-model also enables the dynam ic analysis of SPMs to help users estim ate and adjust the dynamics of SPM enactm ent, recover from pro-j cess breakdown during enactm ent, and evolve software processes through dynamic changes. Dynamic analysis of SPMs utilizes process sim ulation and articulation! As such, a num ber of case studies th at utilize process modeling and analysis are discussed which cover both academic and industrial applications. Overall, th e long-term goal of this research is to create a process-driven software engineering environment th at integrates process modeling, analysis, and enactm ent w ith new or existing software tools. Such an environment would provide users with process-guided activity execution, resource m anagem ent, and tool invocation. In the future, such an experim ent can be undertaken to integrate the A rticulator system w ith a commercial software engineering environment. xn Chapter 1 Introduction Study of the software process has focused in two research directions: modeling of software processes to support process understanding and definition, and enactment o f software process models to support process-driven software developm ent [7, 39, 63, 71, 94, 97]. A software process is the collection of related development activities, seen as a coherent process subject to reasoning, involved in the production of a software system [94]. A Software Process Model (SPM ) is a formalism th a t represents soft ware processes and the resources involved. Modeling of software processes proposes formalisms of SPMs and applies them to define software processes. SPM enactm ent facilitates software developers and managers in software development through ex ecuting an SPM as a guide to development activities. In recent years, a num ber of software engineering environments (SEE) have been prototyped th a t employ an SPM form alism and integrate SPM enactm ent w ith conventional SEEs. This type of state-of-the-art SEEs supports a new software development methodology called process-driven software development, and promises a higher level of productivity and predictability in software development [4, 11, 68]. However, problems exist th at prevent process-driven software development from large-scale applications. In this dissertation, two of these problems are identified and solutions to them are presented. This dissertation shows th at an SPM and its enactm ent need to be analyzed statically and dynam ically before it can be actually enacted. This is sim ilar to the debugging and testing of a com puter program . Unfortunately, there has been little research in building and analyzing SPMs to support understanding of the underlying software process. This is an issue of software process definition and static analysis, and involves forms of process representation and their validation. 1 Furtherm ore, SPM enactm ent progresses in an open environm ent where changes may invalidate a proven SPM. Such invalidation requires dynam ic analysis th a t diagnoses and repairs the broken SPM , and recovers th e suspended SPM enactm ent. This is an issue of software process enactment and dynamic analysis, and concerns the dynam ic evolution of SPMs and rearrangem ent of resource allocation. In this dissertation, the A rticulator system is presented which embodies a solution to these two problems. It consists of the A rticulator m eta-m odel, (i.e. a form alism of software processes and the resources involved), an SPM definition methodology, a m echanism for static analysis, a set of enactm ent semantics, and a m echanism for dynam ic analysis. In the first chapter, the two problems associated w ith current software process modeling and enactm ent are discussed. Then, a solution to these two problems and a research approach th a t im plem ents the solution are proposed. This research approach is a com bination of em pirical study and im plem entation investigations. This chapter concludes by presenting a m ap for the rest of th e dissertation. 1.1 The Problems and The Solution The notion of SPMs is crucial in process-driven software development for three reasons: First, an SPM is the repository of all inform ation related to a software process. Second, it guides software developers as to when and what to do in the developm ent. Last, it can be utilized by software m anagers to m onitor and control a software development project. Lack of inform ation, mis-guided development effort, and inappropriate m anagem ent jeopardize the progress of software development. Consequently, the construction of proper SPMs is a prerequisite for process-driven software development. U nfortunately, th e software process community, as a whole, has had little ex perience of th e construction and analysis of SPMs. Formalizations of SPMs and process-driven SEEs (PSEEs) have been presented in recent workshops and confer ences, but little experience w ith process model construction has been reported. The process modeling results th at have been presented either are based on informal rep resentation of software processes [25, 24, 98], or are aim ed at modeling small-scale software processes [82, 76]. Very little, if any, has been said about analyzing SPMs for enactm ent. As a result, the level of knowledge about SPMs is still at an early 2 stage. There is no methodology fo r S P M construction, nor any way o f analyzing and measuring SPM s fo r the purpose o f process understanding and presentation. Users have to rely on their own skill and knowledge of process modeling to define a custom ized SPM. Even if software m anagers can define reasonable SPMs based solely on their prior experiences, problems may arise after these SPMs are enacted in process-driven soft ware development. Since SPMs are enacted by developers in an open environm ent, changes in the environm ent may cause partial invalidation of the enacted SPM, m aking it inadequate or impossible to follow. Therefore, SPM enactm ent has to be suspended, and this is called process breakdown. W hen process breakdown occurs, developers and m anagers have to accom m odate the development to these changes. This m ay take several forms: For example, a software m anager can re-schedule h is/h er resource allocation in order to adapt to th e new resource configuration. Also, a m anager can re-plan the SPM by introducing necessary activities and local task reconfiguration. (However, managers need to know w hat the problem is before they can re-schedule or re-plan the SPM enactm ent.) In other words, to resolve process breakdown, managers face the task of diagnosing, re-scheduling, an d /o r re planning the broken SPM. Such a task is called process articulation. Additionally, to a larger extent, process articulation is a form of continuous process improvement; which is to say, no m atter how well an SPM is defined, the changing environment dem ands its evolution so th a t it matches the emerging needs of the workplace at all tim es. To be able to analyze SPMs against outside changes and to schedule resource usage accordingly is always a concern of software m anagers. Currently, there is no mechanism that supports such dynamic analysis o f SPM s and process articulation. The solution proposed and im plem ented in this dissertation is a research ap proach to modeling and analyzing software processes and process breakdown in order to support process-driven software development. This solution is embodied in th e A rticulator system , which includes a modeling form alism for software pro cesses, an SPM definition methodology, and a set of com putational functions for the static and dynam ic analysis of SPMs. Such a solution approach can benefit soft ware process modeling and enactm ent in two im portant aspects th a t are currently problem atic: namely, software process definition and static analysis, and software process enactm ent and dynam ic analysis as identified earlier. 3 1.1.1 S oftw are P r o c e ss D efin itio n an d S ta tic A n a ly sis SPMs represent software development approaches and resource configuration th at fa cilitate the approaches. Building a custom ized SPM th a t describes necessary knowl edge of a software process is the first prerequisite in SPM enactm ent. Software pro cess definition and static analysis are currently problem atic because current process modeling techniques have a narrow focus of the technological dimension of software processes. Furtherm ore, they do not provide mechanisms th a t support process def inition, m easurem ent, and analysis for the purpose of process understanding and presentation. The A rticulator supports SPM construction and static analysis through: (1) an object-oriented m eta-m odel of software processes and the resources involved; (2) an SPM definition m ethodology th a t guides knowledge acquisition during SPM con struction; and (3) static analysis of SPMs th a t detects syntactic and sem antic er rors, verifies inform ation consistency and completeness, and visualizes various forms of knowledge in an SPM. 1.1.2 Softw are P r o c e ss E n a ctm en t and D y n a m ic A n a ly sis Software process enactm ent represents execution of an SPM as a guide to software developers and managers. During SPM enactm ent, developers follow the SPM toj perform their assigned duties, and managers update and m onitor the SPM to ensurej successful completion. Currently, software SPM enactm ent is problem atic because PSEEs do not support dynam ic evolution of enacted SPMs. Therefore, they break down when outside changes invalidate an enacted SPM. T he A rticulator supports SPM enactm ent and dynam ic analysis through: (1) A set of enactm ent semantics th a t formally define the meaning and constraints for SPM enactm ent. It forms a basis for enacting an SPM. (2) Process sim ulation th at executes an SPM symbolically, and creates a trajectory of SPM enactm ent in term s of resource allocation and task execution. This type of trajectory estim ates how and when resources are needed, and how the SPM will be carried out under given resource constraints. (3) Process articulation th at dynam ically resolves breakdowns during SPM enactm ent and update an SPM to accom m odate outside changes in an 4 evolutionary fashion. Due to the unpredictability of changes in th e real world, un expected events occur during software development. Due to the lim itation of their knowledge about the future of the real world, developers make m istakes in configur ing activities and resources in SPMs. Process articulation is the response developers make to adapt to changes in the real world and to correct previous m isjudgm ent. T he A rticulator im plem ents process articulation by adopting a potential solution from previous knowledge and experience th a t represented as p art of th e A rticulator m eta-m odel. Knowledge and experience of process articulation in the A rticulator m eta-m odel is abstracted from th e observed solutions from em pirical studies. These observed so lutions are actual m ethods used by developers in real situations. In the A rticulator, they are abstracted into a taxonom ic hierarchy of problem-solving heuristics accord ing to their applicable types of breakdown. W hen a breakdown occurs, one of the problem-solving heuristics will be selected and instantiated to solve th e breakdown. These problem-solving heuristics are normally in the form of either restructuring the activities or rearranging the resources involved. 1.2 Research Approach T he research approach used to designing the A rticulator follows a methodological approach to providing a specification and support mechanisms at the same tim e. This research approach can be understood as depicted in Figure 1.1. F irst, three kinds of related work are surveyed. These related areas are (1) software process modeling which specifies formalisms for describing software processes, (2) em pirical studies of system development which observe the kinds of activities to be m odeled in the formalisms, and (3) project scheduling which arranges resource requirem ents for developm ent projects. Based on these related works, the A rticulator m eta-m odel of software processes was created to encapsulate m ost of the im portant features of SPM s, as well as knowledge of process articulation. This m eta-m odel is the form al ism for a family of software processes. Construction of SPMs is defined as creating custom ized SPMs according to vocabulary objects and relationships th a t constitute th e A rticulator m eta-m odel. To help users describe an SPM, an SPM definition m ethodology is defined to guide construction of SPMs, and static analysis of SPMs 5 Software Process Modeling Project Scheduling Empirical Studies on System Development r ---------------------------- - * ! TheA tcw aw ' My»-Maasl The Articulator LEGEND: | | R e la ted Work U A R esearch Component Figure 1.1: Research Approach is im plem ented to detect defects in the defined SPMs. Static analysis is aim ed at detecting syntactic and sem antic errors and ensuring inform ation consistency and completeness. These two supporting mechanisms facilitate the usability of the Ar ticulator m eta-m odel in software process modeling. To support the enactm ent of SPM s, the A rticulator im plem ents two types of dynam ic analysis: process simula tion generates task and resource estim ation; process articulation (as an integrated approach to diagnosis, re-planning, and re-scheduling) resolves process breakdowns. The uniqueness of th e solutions to the problems of SPM modeling and analysis lies in following characteristics of the A rticulator: 1. It embodies an object-oriented m eta-m odel of software processes for describing a large family of software processes,and process breakdowns. This m eta-m odel 6 Jwur uiS-m ar « SPM expands modeling capabilities to include specification of a num ber of resource! classes involved in software development, as well as specification of resource requirem ents and possessions. 2. It includes an SPM definition methodology, and static and dynam ic analysis of SPMs to help users specify custom ized SPMs. Static analysis of SPM s detectsj th e kinds of syntactic and sem antic mistakes. Sim ulation of SPM s, as one type of dynam ic analysis, estim ates possible resource allocation and task execution in m ulti-agent and m ulti-task environments. A rticulation, as another type of dynam ic analysis, repairs broken SPM enactm ent to accom m odate changes in process-driven software development. 3. It contains a taxonom ic definition of em pirically-grounded process breakdown, articulation knowledge, and articulation process th a t serves as a conceptual ba sis for modeling articulation work and its related knowledge and skills. Based on these models, heuristic process articulation, including diagnosis, selection, recovery, and re-scheduling, can be effectively integrated and then applied toj development circum stances. This definition represents th e first formalization' and operationalization of w hat was previously an inform al b u t commonly prac ticed activity w ithin software development. 4. It represents a process approach supported by a set of process mechanisms. This approach identifies a set of process activities, including definition, static analysis, sim ulation, enactm ent, and articulation. It also provides a set of autom ated process mechanisms th at support these process activities. 1.3 Overview of the Dissertation In C hapter 2, relevant research th a t influenced the developm ent of the A rticulator is presented. Three basic areas are investigated: formalisms for SPM s, empirical studies of articulation, and scheduling of project resources. C hapter 3 provides a form alism for representing SPM s, th a t is, the A rticulator m eta-m odel, and its capa bility to specify SPMs are described. In C hapter 4, an SPM definition m ethodology th a t guides the construction of SPMs and the static analysis of SPMs to detect both 7 syntactic and sem antic problems are defined SPMs. To help understand the A rtic ulator m eta-m odel, its SPM definition methodology, and static analysis, three case studies which reveal different kinds of SPMs and modeling problems are presented in C hapter 5. The dynam ic analysis of SPM s which includes process sim ulation and process articulation is discussed starting in C hapter 6, The next two chapters are devoted to process articulation since it is th e m ost im portant process m echanism im plem ented in the A rticulator. Of particular im portance here is (1) a taxonom ic representation of breakdowns and articulation in term s of object-oriented hierarchy and relationships; and (2) procedural representation of problem-solving m ethods and their connection to the taxonom ic representation. These two topics are the subject of C hapter 7 and C hapter 8 respectively. P u ttin g things together, Chap ter 9 explains dynam ic analysis of SPMs through another three case studies. These case studies dem onstrate different ways dynam ic analysis of SPMs can be applied in process-driven software development. Finally, C hapter 10 concludes by sum m arizing the m ethodological approach to the A rticulator, the m ajor research contributions of this work, and pointing out future research directions th a t will expand th e concep tu al foundations and functionality of th e A rticulator. 8 Chapter 2 Related Work Work in developing the A rticulator as a process modeling and analyzing environm ent has been influenced by ideas appearing in three areas: (1) emerging technologies of software process modeling, (2) em pirical studies on system developm ent, and (3) project and resource scheduling. However, th e A rticulator is unique w ith respect to other research efforts, since it is aimed at exam ination of issues th a t have not been investigated so far, such as static and dynam ic of SPMs. In this chapter, research projects in each of these areas are reviewed. First, systems th a t provide formalisms to represent the software process and a group of standard capabilities to model planned development activities th at are known be fore a project starts are identified. Second, em pirical studies of system development th a t help reveal developers’ behavior during software developm ent as well as in solv ing process breakdowns are discussed. Although process formalisms support process planning through definition of SPMs, they normally do not address issues of resource scheduling, re-planning, and re-scheduling. However, these issues are im portant to SPM enactm ent where artifacts are produced and resources are consumed in envi ronm ents where resource arrangem ents unexpectedly change or breakdown. Thus, th e th ird section reviews recent efforts in project scheduling, re-planning, and re scheduling in order to identify and reuse possible solutions for process scheduling in connection w ith SPMs. Overall, the review shows th a t (1) process analysis and articulation are im portant and recurring types of process modeling activities; (2) the reviewed technologies and systems do not address process analysis and articulation directly or indirectly; (3) the technologies exam ined provide their capabilities independent of each other, while 9 process analysis and articulation requires a m ore integrated approach to analyzing, planning, and scheduling SPMs and breakdowns. Such an integrated approach is J crucial to th e success of SPM enactm ent. Therefore, these technologies do not iform an adequate basis to support process analysis and articulation, although it is I _ i possible to reuse them as p art of an integrated approach. A new approach is needed to support process-driven software development as a whole, and process analysis and articulation work in particular. Such an approach is presented in th e following chapters. Nonetheless, th e research efforts in the three areas are exam ined in turn. ;2.1 Software Process Modeling Techniques j j M odeling software processes includes abstracting im portant features of software developm ent activities, formalizing them into SPMs, and supporting development through SPM enactm ent. This section surveys a group of representative state-of- !the-art modeling techniques. These modeling techniques are grouped into three categories based on their modeling formalisms. Of these, the th ird group is a lit tle different as it includes only those systems th a t support the evolution of SPMs, rath er th an software developm ent. These categories are: program m ing-based mod- jeling, object-based modeling, and evolution-based modeling. I ]2.1.1 P ro g ra m m in g -B a sed M o d elin g T ech n iq u es i I Program m ing-based modeling techniques use or expand program m ing language con stru c ts to m odel software processes. In 1987, Osterweil [71] stated th a t since software •processes can be described and formalized as software, they can be described by an expanded program m ing language. Thereafter, several efforts began to create a pro cess program m ing language, such as Arcadia, Inscape, OPM , and PDL. At the same tim e, other efforts are m ade to define software processes in term s of production rules, such as Marvel. A rcadia [71, 91] is an SEE which embodies a process program m ing technique. |In A rcadia, A ppl/A [75] expands th e A da program m ing language to program pre scriptive software processes. In A ppl/A , development activities are represented as process program s and functions. A language compiler for such process program s is ! j under developm ent for enactm ent of the process program s. Arcadia, at the same tim e, provides other development tools incorporated w ith process program s, such as object m anagem ent repositories and user interfaces. Inscape environm ent [73] is an integrated developm ent environm ent for build- 'ing large software systems. It provides predicate-based tools th a t are knowledgeable about the software process. Its modeling technique is based on a m odule interconnec tion language w ith predicates and sem antic interconnection of the predicates. These sem antics are used to enforce the consistent use of the predicates and to determ ine jthe im plication of changes in the predicates and their interconnections. O PM [89, 88, 90] is a process modeling environm ent. In O PM , GALOIS is a' C+-1— based process program m ing language th at includes descriptions of processes jand resources. OPM provides a user interface through which process model tem- I plates are designed, instantiated, and tracked. O PM also introduces a graphical no tatio n to describe overall process flow, which is supported by a conventional graph 'editing tool. PD L [45, 40] is a functional process program m ing language based on an algebraic context-free gram m ar. Its m ain capability is to describe software processes through! i :levels of abstraction and activity sequences. PDL has a m enu-oriented navigation system th at helps users travel through the defined activity structure and sequence. Oikos [1] and Adele-2 [4] are two other process modeling systems th a t utilize the i language-based modeling technique. Table 2.1 summarizes the im portant properties of these program m ing-based pro cess m odeling formalisms. I 2 .1 .2 O b je c t-B a se d M o d elin g T ech n iq u es i jThe object-based modeling technique views software developm ent as interactions) lamong a cluster of related objects. The objects we norm ally encounter in software jdevelopment can include developm ent activities, developers, and other com puting jfacilities. They are described in term s of object classes. T he interactions among them are described as relations and inheritances, although some techniques do not) juse relations at all. Therefore, rather than concentrating on how a software process t achieves its objective, th e object-based modeling techniques focuses on w hat are System, Modeled A ctivity Formalism Model Element Process Tool Arcadia Software Development Ada-based Process Programming Function, Procedure Compiler, User Interface Inscape System Construction Predicate, Interface Specification Data, Operation N /A OPM Software Development C++-based Process Programming Process, Resource, Environment Graphic Interface PDL Software Development Functional Process Programming Activity Hierarchy and Sequence Interpreter Oikos Software Development Smalltalk Task Modeling, Enactment Adele-2 Software Development Ada-like Language Task Modeling, Enactment Table 2.1: Sum m ary of the Program m ing-Based M odeling Techniques , th e involved object classes and their interactions. Furtherm ore, some object-based J m odeling techniques take advantage of the defined object hierarchy and integrate it | w ith production rules to m anipulate the defined software processes. Finally, object- ■ based modeling technique utilizes notational specifications th at are not designed as j program m ing languages. Following are some of the prototype im plem entations, j IPSE 2.5 [93] supports both software process modeling and the integration of| j SPM s and development tools. The process modeling language, PM L, is an object- based formalism. It defines an SPM as a network of objects which, in turn, describe ;the developers (as Roles), their activities (as E ntities), and th e integration of the activities w ith the com puting facilities (as Interaction). T he SPM enactm ent is im plem ented by a process control engine, which provides a working environm ent for Jits users based on the used SPM. An experim ental PSEE, called PSS, has been built jon top of IPSE 2.5 using PM L [11]. j ISHYS [26, 27] is a hypertext software developm ent environm ent. It provides an object-based process description. The object classes in the process description I includes processes, products and agents. These classes are linked together through object-based relations. SPM s, defined in ISHYS, are associated w ith program m ing and docum enting tools through an object-based specification. 12 i W illiam s [97] proposes a behavioral approach to m odeling of software process. This approach defines software process models in term s of behavior, rather th an per form ance procedure. The behavioral description includes inputs to a process activity^ as well as expected outputs, all of which are represented as objects in the overall ! model. A lthough not im plem ented directly, th e behavioral approach influenced a num ber of object-based process modeling techniques. SDA [54] provides a software process form alism th a t addresses functional and behavioral aspects of process modeling as well as SPM enactm ent. H FSP [50], is a process m odeling language th a t describes hierarchical and functional aspects of the software process. T he object classes in H FSP consists of representations of processes, products and tools. A process script is a description of the process formalism. E nactm ent of a process script creates a process enactm ent tree, which dem onstrates a norm al execution order of th e modeled software process. SO FTM A N [13] is a software developm ent and docum entation environm ent th a t adopts an object-based representation of software processes. It provides object classes, such as various types of life-cycle docum ents, and relations between them . By using the process descriptions as specifications of docum entation, SO FTM A N ’s m any developm ent tools are linked together and various integrity checks are m ade j possible. G rapple [37, 36] utilizes planning mechanisms to describe software processes. Here, a software process represents a plan, which consists of a set of goals and . action decompositions. Such a plan [96] is a com putational script or procedure th a t specifies w hat software development activities are and how developm ent tools should be invoked at w hat tim e. Process instantiation in G rapple autom atically creates a set of goals and actions th a t satisfy a predefined software developm ent goal. SPM enactm ent, on th e other hand, expands an d /o r executes a defined plan-based process i m odel. T he use of plans and planning mechanisms for th e software process was first j introduced by this research. j | M arvel [49, 47] is a modeling system th at uses rule-based representation of soft ware processes. In Marvel, developm ent tasks are defined as a rule-based production j system and enactm ent of these rules uses backward chaining to attem p t to satisfy | preconditions of these rules and forward chaining to carry out execution of these i 13 (rules. Recently, an experim ental PSEE has been developed using M arvel’s process (modeling technique [48]. i T he first version of the A rticulator [63] defines a hierarchical object-oriented: m eta-m odel of the software process and development workplaces. A software process is described by its tasks, agent roles, products (or resources), tools, and relation ships among them . Its rule-base m echanism supports process sim ulation, a symbolic execution of SPMs w ith resources to be or already enacted, and process query, J form of deductive retrieval of process definition and enactm ent. M erlin [20] has an object-based representation of process m odeling and a rule- based reasoning mechanism. The object-oriented model include such entities as roles, activities, deliverables, and resources. Merlin expresses an SPM in a rule-like form, which includes a knowledge base containing facts and rules describing a particular SPM. M erlin supports several process tools, such as query, symbolic execution, and \ a process interpreter. EPO S-PM [16] combines a rule-based representation w ith the Entity-R elationship model. It views a software process as a set of entities and rela tionships (ER), but represents it through Prolog rules w ith pre- and post-conditions. (There are two types of entity in EPOS-PM : T a s k E n t i t y describes active activities and D a t a E n t i t y describes passive d ata th at are m anipulated. EPO S-PM also im plem en ts an execution m anager to symbolically enact SPMS and a planner to assist | users to define custom ized SPMs. ! Table 2.2 lists im portant properties of these object-based process modeling for malisms. i j (2.1.3 E v o lu tio n -B a sed M o d elin g T ech n iq u es T he evolution-based m odeling technique supports evolution of SPMs. It supports updating forms of SPMs based on previous work experiences w ith the SPMs. It ; embodies a process description as well as facilitates th e evolutionary activities th at develop SPMs. i Prism [59, 58] is an experim ental process-oriented system supporting th e develop-! i m ent of SPMs, their instantiation, and their execution. T he Prism software process ,model is a com bination of Petri-nets and production rules, by which development I 14 System Modeled Activity Formalism Model Element Process Tool IPSE 2.5 Software Development Object-based Modeling Language Role, Task, Interaction PMMS ISHYS Software Development Object-based Spec. Process, Product, Agent Language Interpreter SDA Design and Cooperation Functional, Behavioral, Enactmental Spec. Process, Product, Tools Process Script, Enactment SOFTMAN Software Development and Documentation Object-based Spec Document, Relation Spec, of Product Doc. and Activity Grapple Software Development Plan Goal, Action Instantiation, Enactment Marvel Software Development Production Rule Task Modeling, Enactment Articulator Software Development Object-oriented, Rule-based Task, Product Agent, Tool, Tool, and relation Analysis, Query, and Simulation Merlin Software Development Object-based, Rule-based Task, Role, Deliverable, Resource Query, Execution, Interpreter EPOS-PM Software Engineering ER Model, Rule-based Task, Data Enactment, Planning Table 2.2: Sum m ary of the O bject-Based Modeling Techniques activities are defined. The Prism architecture supports th e evolution of SPMs in fol lowing stages: creation of an SPM; instantiation of an SPM based on a developm ent i 'situation; and execution of a project under th e guide of an SPM. j TAM E [3, 2] is another process-oriented system th a t is intended to study the | evolution of SPM s. It proposes an experim ental approach, called the im provem ent j paradigm , to define m easurable SPMs and to use this approach as a quantitative basis for selecting, evaluating, and improving SPMs. TAM E then utilizes th e “expe rience factory” (i.e., a repository for process enactm ent history) for (1) storing SPMs and previous experience in executing them , (2) providing th e ability to analyze the ‘SPMs and related experience w ith them , and (3) packaging em pirically grounded SPMs and other forms of process knowledge. Table 2.3 lists im portant properties of these evolution-based process modeling 'formalisms. 15 System Modeled Activity Formalism Model Element Process Tool Prism SPM Development Petri-net, Rule Activity, Object, Relation Development Instantiation Execution TAME SPM Development Improvement Paradigm Activity, Experience Selection, Generation, Feedback Table 2.3: Sum m ary of the Evolution-Based M odeling Techniques 2.1 .4 S u m m a ry o f S oftw are P r o c e ss M o d elin g T ech n iq u es i ! The modeling techniques are characterized by the type of developm ent activities they( [model, th e m odeling formalism, the elements in a model, th e tools supporting process ; modeling, and the tools supporting software developm ent. Table 2.1, Table 2.2, and Table 2.3 lists these features for each of the four process m odeling techniques. Thus, at this point, the contributions and lim itations of these process m odeling techniques I jean be identified: 1. SPMs created by these modeling techniques consist of descriptions of devel opm ent activities, developers, tools, artifacts and resources. Variations in l representation exist among these different formalisms. M any provide a specifi- j cation or program m ing language to let users define SPM s, such as A ppl/A [75] I and O PM [89, 88, 90]. However, other formalisms provide a meta-model th at ! describes a fam ily of SPMs, such as ISHYS [26, 27] and A rticulator [63]. j 2. Developm ent activities are a m ajor p art of an SPM. They are an abstract de scription of planned developm ent activities. A description of planned develop- | m ent activities norm ally includes activity decom position, execution sequence, and resource usage. The activities are represented either as production rules as1 ; in M arvel [49, 47], plans in G rapple [37, 36], process program s in A ppl/A [75], object classes in ISHYS [26], or an object decom position hierarchy in the Ar ticulator [63]. ! 3. Development tools are provided as part of the SPM environm ent for systems, such as the A rticulator [63] and M erlin [20]. These tools can be activated w ithin appropriate developm ent activities. Different activities require the use 16 J of different tools. M ajor types of development tools include those for software docum entation, specification, design, program m ing, and project m anagem ent. 4. E nactm ent of SPMs guides software developm ent by indicating necessary or rem aining activities and by invoking necessary tools. Software development is carried out according to th e sequence of planned activities. This perform ance sequence can be explicit as in process program s in A ppl/A [75j, ISHYS and A rticulator’s agent-task-product relations [26, 27, 63], or im plicit as effects of production rules in M arvel [49, 47] and subgoals in G rapple [37, 36]. 5. P rism [59, 58] and TAM E [3, 2] have their focus on analyzing and improving SPM s through em pirical m easurem ent evaluations and process refinements. They suggest a learning and feedback process so th a t developers can improve th eir practice of software engineering by having an im proved SPM. 6. None of the modeling techniques provides a m echanism describing and m od eling process breakdowns during SPM enactm ent. SPM enactm ent is only responsible for carrying out SPMs. W hen a breakdown occurs, enactm ent will ) be interrupted and development stopped. I | There also exist software process modeling techniques th a t do not fall into the I previous types. For example, MELMAC [19] uses a P etri-net representation to | describe SPM s, while SEPS [57] uses system dynam ics and fuzzy logic to describe jSPM s and sim ulate SPM enactm ent. 1 2.2 Empirical Studies of System Development i | Knowledge about software processes and attem pts at m odeling them is lim ited, j A lthough there exist a num ber of process modeling techniques, they are not yet applied in routine situations. At the 1st International Conference on the Software Process held recently in California, two types of practices on process m odeling were, reported. One type of practice does not apply any formal process modeling tech- jnique [25, 24, 98] while achieving satisfying outcom e for the organizations. A nother jtype of practice is based on a process modeling technique [82, 76]. In [82], process models are built in H FSP to model and com pare different types of software design 17 m ethodologies, such as JSD. In [76], a simple, b u t flexible requirem ents-specification process program called REBUS is w ritten in A ppl/A . However, these SPMs describe only small-scale software processes. Furtherm ore, their construction is m ostly ad hoc and does not follow a well-defined methodology. A num ber of em pirical studies have exam ined developers’ behavior in software 'developm ent projects and other types of system developm ent. In these studies, i two types of activities are identified. One type achieves predefined goals or products through successfully planned and executed activities. This type of activity is well un derstood, specified, and perform ed w ith expected order. For exam ple, program m ers often plan and then construct program s according to a previously prepared archi tectural design. A nother type of work called articulation, however, is a response to em ergent situations when planned activities fail or breakdown. For instance, a compiler bug may be discovered while writing and compiling program s. Usually, architectural design and program m ing activities generally would not anticipate such compiler bugs. B ut, th e program m ers involved m ust determ ine w hat to do in order to eventually com plete th e program m ing activity, either by getting the compiler bug fixed, or by somehow working around it. A rticulation work has not been studied, nor addressed as p art of any process | m odeling techniques. Therefore, the focus of attention in reviewing these studies ■ is to identify and com pare the kinds of breakdowns and the articulation work th a t jis perform ed in response. To this end, three sets of em pirical studies have been ifound which identify and describe articulation work: those in USC’s System Factory • P roject [5, 6, 46, 55, 78], those in the Design Process Group in M C C ’s Software, (Technology Program [18, 17, 32, 56, 92], and those about other types of software or (system developm ent work [28, 30, 86]. The findings of these em pirical studies are (presented next. (2.2.1 S tu d ie s In th e S y ste m F actory P r o je c t i Em pirical studies in the System Factory Project have focused on how developers (collectively perform various software developm ent activities. T he theoretical foun- 'dation for these studies is th e web o f computing introduced by Kling and Scacchi [55]. T he web of com puting is an open system model “for understanding th e dynam ics of! 18 com puting developm ent and use in organizational life.” It provides an em pirically j grounded approach for studying developers’ behavior and their relationships w ithin technological and organizational contexts. Scacchi [78] describes the first study th a t employs this model. He finds th at innovation o f computing is a type of articulation work to enhance or adopt the ex- listing of com puting resources in an organizational setting. Innovation of com puting is initiated when a m ism atch betw een existing com puting resources and dem ands ( from on-going developm ent activities occur which jeopardize the productivity of th e developm ent organization. Innovation of com puting generally consists of three sub-processes: fitting to adjust existing resources tow ard changing or circum stan tial dem ands, packaging to restructure the configuration of existing resources, and cycling to replace old resources w ith more powerful ones. Findings in [46] have | confirmed the superiority of the web perspective in exam ining processes associated w ith th e production and consum ption of software docum entation. This study shows th a t the production and use of software docum entation can be greatly facilitated when models of its production processes, products, and settings, are all integrated together and their interaction is explored. Bendifallah and Scacchi [5] find th a t prim ary work and articulation work are 'regular forms of software m aintenance in the observed developm ent organizations. 'A ccording to their study, articulation work emerges due to contingencies in a work pla ce, and it is th e way m aintainers resolve contingent breakdowns in th eir prim ary I developm ent work. They report th a t articulation work has two forms: accommo- ; dation to overcome breakdowns based on one person’s own knowledge or skill; and j negotiation between m ultiple developers in order to solve problems collectively. Their study includes an exam ple th a t presents several articulation m ethods a programmer! I m ight respond to critical resources th a t become tem porarily unavailable, such as l a stopped printer which has run out of paper. These m ethods are categorized as accom m odations (loading m ore paper or switching to another task if no paper is available), and negotiation (get someone else to add paper, or else modify printer softw are to keep track of pages printed and am ount of paper rem aining). i Bendifallah and Scacchi [6] in another study exam ine different forms of team work; in software specification. They again find the same types of breakdowns as reported ,in [5], which are caused by circum stantial contingencies th a t emerge while developing 1 19 j a large scale Software specification. Furtherm ore, they observe a new type of articu-1 lation m ethod: shift in team work structure. According to this study, developers in !a team environm ent frequently reconfigure their team structure, interactions among i :team m em bers, and work assignments in order to overcome unexpected breakdowns in planned work flow. 2 .2 .2 S tu d ie s at M C C i [Empirical studies conducted in the Design Process G roup at MCC are focused on jwhat they call th e software design process. Sum m ary of these em pirical studies appear in [17]. B ut here the individual studies are discussed. K rasner, C urtis and jlscoe [56] investigate formal and informal com m unication channels in large software |development projects and how breakdowns in com m unication occur. They describe jtypical com m unication breakdowns as lack o f communication between groups, mis- communication, conflicting inform ation from multiple sources, and communication problems due to project changes. They also observe a particular form of articulation: boundary spanning where some person acting as a m ediator is assigned to several groups in order to fill com m unication gaps and provide an overlap of inform ation and ! I knowledge among the groups. Guindon, K rasner, and C urtis [32] study individual program m ers’ work during software design. They identify two types of breakdowns: |lack o f application knowledge which is needed to solve the problem , and cognitive I lim itation th a t prevents th e problem solver from creating a im m ediate, com plete isolution. Walz, Elam , K rasner, and C urtis [92] take group specification work as the [subject, in which lack o f knowledge and group interaction are once again cited as two causes of breakdowns. No particular articulation m ethods are m entioned in these two studies. ! '2.2.3 O th er S tu d ies i T here also exists a group of field studies th a t are devoted to understanding o th e r, types of system development work. These studies identify sim ilar forms of break -downs and articulation work in other domains of developm ent work, such as com puting-related office work and service provision. ! ! 20 I Gasser [28] studies the integration of com puting and routine work in organiza tions. A rticulation work, in his study, is described as a m eans to “establish, m aintain, or break the coordinated intersection of task chains.” M isfit o f resource, which dete riorates th e provision of a resource to development work as an organization evolves, causes process breakdowns and contingencies. M any observations are m ade aboutj such breakdowns. This study describes three m ethods of articulation work to solve misfit of resource: Fitting to accom m odate a com puting misfit by either m odifying hardw are or software configuration or by restructuring the pattern s of routine work;! Augm enting to m ake up for a misfit by undertaking additional work; and working around to avoid a misfit by intentionally misusing current com puting arrangem ents or by using alternative means. Gerson and S ta r’s study [30] is focused on articulation work in working with organizational inform ation systems. Different viewpoints among various classes of users are identified as a m ajor cause of breakdowns. These different viewpoints reflect different interests th a t can generate conflicts. T he authors identify two types of articulation m ethods: skepticism , which criticizes or validates a particular solution to a breakdown; and trade-off, which balances different viewpoints and creates a compromise among them . They also report the effort of establishing a liaison role whose responsibility is to m ediate and describe different viewpoints and how th ey conflict. Suchman [87] also identifies similar breakdowns and articulation m ethods in her study of com puter-related office work. Lastly, Strauss [86] offers a theoretical framework for understanding how work w ithin projects is articulated. His framework includes several concepts th a t pertain to num erous interlocking and sequential elements of organizational work. A rticu lation work is defined as an organizational process th a t overcomes disruption and contingencies of project work caused by the nonroutineness of th e project and altered resource arrangem ents. In his view, articulation work ensures regular flow of project work and controls th e dynam ics of various types of developm ent work. Accordingly, Strauss finds th a t Interaction among developers, establishing and m aintaining align m ent between different developm ent tasks, and negotiation are activities central to the articulation process. 21 2 .2 .4 S u m m a ry o f th e E m p irica l S tu d ies Table 2.4 lists the basic findings about articulation work in these em pirical stud- I ies in term s of th e study, types of developm ent work exam ined, forms of process ! breakdowns th a t occur, reported causes of these breakdowns, and the m ethods of articulation work observed in response. From these findings, several conclusions can j be drawn: I 1. Two types o f activities are identified in software developm ent and other types of development: planned activities and articulation work. Planned activities account for expected work flow and constitute a m ajor p art of software devel-! opm ent. A rticulation work is the response to breakdowns in planned activities. Its purpose is to restore or reorganize intended work flow. j 2. T he occurrence o f breakdowns is a common phenom enon developers experience in m any types of developm ent projects. In software developm ent, breakdowns can occur in every developm ent phase. T he em pirical studies report break-; downs and articulation work in requirem ents specification, software design, m aintenance, and other development work. They also observe articulation work perform ed by both individuals and groups of individuals as th e common response to these breakdowns. 3. T he relationship between planned activities and articulation work is identified as an interruption-driven interaction, when the norm al progress of planned activities is interrupted by a breakdown, and articulation work is thus initiated to overcome the breakdown and resum e progress if and when possible. As j another breakdown occurs, articulation work will again be invoked to deal I ; w ith it. i j 4. Causes o f development breakdowns are circum stantial alterations in the pro duction and consum ption of resources used in planned activities. Since fluc tuations in th e availability or use of resources are a fundam ental aspect of any work environm ent, breakdowns are probable and frequent. In Table 2.4, twelve types of causes of breakdowns are identified. Among them , there exist four m ajor types. All other causes can be sorted into one of these types. The. Researcher Development Work Form o f Breakdown Cause o f Breakdown Method Scacchi [78] Computing Work Mismatch between Request and Computing Service Circumstantial Changes in Organizations Fitting, Packaging, Cycling Bendifallah and Scacchi [5] Software Maintenance Contingencies of Primary Work Changes in Workplace Accommodation and Negotiation Bendifallah and Scacchi [6] Software Specification Contingencies of Primary Work Idiosyncratic Setup, Changes in Workplace, Work Structure Adequacy Negotiation, Shifts in Work Structure Krasner, Curtis and Iscoe [56] Software Design and Communication No Communication, Miscommunication, Conflicting Info Difference in Skill and Incentive, Changes in Workplace Boundary Spanner as Articulator Guindon, etc [32] Software Design Group Work Ineffectiveness, Difficulties Lack of Knowledge, Cognitive Limitation N/A Walz, etc [92] Reqs Definition Group Work Contingencies of Group Work Lack of Knowledge Group Interaction N/A Gasser [28] Routine Use and Evolution of Org. Systems Disruption and Contingency of Routine Work Misfit of Resources Fitting, Augmenting, Workaround Gerson and Star [30], Suchman [87] Routine Use and Evolution of Office Systems Conflict of Interests Different Viewpoints, Changes in Workplace Skepticism, Trade-off, A Special Articulator Srauss [86] General Project Work Disruption, Contingencies Nonroutineness, Altered Arrangements Interaction, Alignment, Negotiation Table 2.4: Sum m ary of the Em pirical Studies first type of causes is change in workplace th a t represents internal evolution of resources, such as changes in software requirem ents. M isfit o f resources is the second type, which represents an inadequate m atch betw een a resource requirem ent and a resource provision. Examples include lack of resources, lack of knowledge, and cognitive lim itation. Group interaction is another type of causes th a t represents differences or conflicts among group m em bers, such as different viewpoints. Other breakdowns is the last types of breakdown (See also Figure 7.1). 5. Recurring articulation methods are observed which developers follow when per forming articulation work. They represent effective articulation skills gained through experience. Table 2.4 lists 14 different articulation m ethods. These m ethods can be grouped into a set of articulation heuristics, which will be presented later in C hapter 7. In com paring these findings w ith the process modeling, it becomes apparent th a t jcurrent software process modeling techniques m ay not be suitable for describing articulation work for the following reasons. First, the nature of articulation work has not been understood and m odeled from a software process viewpoint. Thus, there is no existing form alism th a t captures knowledge of breakdowns and articulation. Second, the occurrence of articulation work is unpredictable, though frequent in a jdevelopment project. B ut, articulation work cannot be planned or scheduled in an SPM using any of th e surveyed techniques. Last, there does not exist an integration of all necessary m echanisms to handle articulation work. Therefore, a new modeling technique is called for. To this end, these studies provide an em pirically-grounded bundation for a m odel of articulation work. T he A rticulator system presented in ;his dissertation is thus based on this foundation. 2.3 Project and Resource Scheduling \lth o u g h the process modeling techniques provide foundations to plan a software process, they do not support resource scheduling, re-planning, and re-scheduling during SPM enactm ent. On th e other hand, these issues are im portant to SPM enactm ent where artifacts are produced and resources are consumed in changing 24 jenvironments. Furtherm ore, re-planning and re-scheduling are necessary because SPMs are enacted in changing working environm ents where resource configuration jevolves and when articulation work occurs. As such, this section surveys repre sentative techniques in project and resource scheduling, as well as re-planning and re-scheduling from the point of SPM enactm ent. In the past, scheduling has traditionally been studied in the field of industrial engineering where people apply linear program m ing, dynam ic program m ing or other operation research techniques. During the past several years, techniques of expert jsystems and knowledge-based systems have been applied in scheduling. This results in some interesting systems. More recently, a particular technique of AI, called (constraint satisfaction, is being employed as a powerful m echanism to realize project 'and resource scheduling. These different techniques in scheduling are surveyed, while their strengths and weaknesses are pointed out. Finally, re-planning and re-scheduling deal w ith changes in plan execution. W hen ja plan is carried out in a changing environm ent, changes in resource configuration m ight bring exceptions, which will block the planned execution from continuing. Process breakdowns are a form of such exceptions. In the field of artificial intel ligence, a num ber of studies have proposed general re-planning and re-scheduling mechanisms to modify a plan in order to accom m odate the changes. In this section, these m echanisms will be surveyed and their relation to the articulation work will be discussed. 2 .3 .1 T ra d itio n a l R eso u rce S ch ed u lin g In projects, a schedule is defined as the conversion o f a project action plan into an j operating timetable [61]. As such, it serves as a fundam ental basis for m onitoring and controlling project activities and, taken together w ith th e plan itself, is probably the m ost im portant tool for project m anagem ent. In early days, the basic approach o scheduling was to construct a network of activity and event relationships th at )ortrays the sequential relations between the tasks in a project. To this end, tools such as the PER T chart and the Critical P ath M ethod (CPM ) were created and used widely. These tools consider precedence relationships betw een th e tasks and arrange a schedule according to these precedence relationships. 25 A lthough later systems follow the same direction, m ore features are added to scheduling systems. As Rodam m er and W hite point out in their survey of recent iprogress in project and resource scheduling [74], traditional scheduling techniques can be divided into five paradigm s: (1) m achine sequencing and scheduling theory, (2) resource-constrained project scheduling, (3) control theory, (4) discrete-event sim ulation, and (5) stochastic optim ization. To evaluate these paradigm s, five fea tures of typical resource scheduling environm ents are tested: (1) boundary stages, (2) process routings, (3) random events and disturbances, (4) perform ance criteria, and (5) m ultiple objectives. After exam ining these features, th e authors conclude th a t the AI technique is a promising new research approach for scheduling. They also point out th a t a synthesis of these paradigm s will be required in order to offer the basis for a unified theory of resource scheduling. Stepm an [85] summ arizes the known features of existing scheduling system s and identifies th e following typical functions in project and resource scheduling: (1) A network to represent precedence relationship between tasks. This network is com m only represented by PER T charts. (2) A common m ethod to create a schedule out of this task network is CPM . (3) Tim e m anagem ent is used to represent dura tion of tasks, execution order among tasks, due dates, and m ilestones. (4) Resource m anagem ent controls use of lim ited resources, which include hum an resources, fi nancial resources and inventory control. A common m ethod for resource allocation is resource-leveling. C A -SuperProject [15] is a commercial project m anagem ent software package mar- jketed by C om puter Associates, Inc. It is representative of the state-of-the-art for icommercial packages for project and resource m anagem ent. C A -SuperProject is jequipped w ith all the features identified in [85]. In particular, it provides (1) project (planning th a t organizes tasks according to task decom position, duration, and de pendency; (2) resource allocation th a t defines resources and assign them to tasks through resource or tim e-constrained leveling and smoothing; (3) cost estim ation th at helps to control various types of cost, such as variable, fixed, overtim e, and .overhead; and (4) an easy-to-use interface th a t presents planning and scheduling o u tp u t in different graphic forms, such as G antt, PER T charts, W ork Breakdown S tructure (W BS), and C ost/R esource charts. 26 In sum, th e traditional scheduling techniques have been used in vaxious engineer ing disciplines, but other problems rem ain. These problems include [53]: (1) The (systems do not use heuristics people use in real life. Most of them use an analytical form ula to create schedules, which often act in contrast to the workable heuristics (people use. (2) T he system s are not flexible to react on changes in projects. Changes ■ in reality require changes in schedules. B ut, these systems norm ally do not support dynam ic schedule changes or increm ental re-scheduling. 2 .3 .2 A I-B a se d S ch ed u lin g jThe A l-based approach to scheduling is being used to create m ore flexible scheduling m echanism s through knowledge representation and inference m echanisms. A very im p o rtan t, yet difficult, feature in scheduling is to create schedules th a t comply iwith given resource constraints. This problem is known to be N P-com plete [99]. Therefore, heuristic rules are often used to create a good schedule quickly. F urther more, various types of resource constraints also require different types of scheduling iheuristics in order to create efficient schedules. More recently, constraint satisfac tion is being used to support scheduling w ith resource lim itations. Accordingly, some p ro to ty p e im plem entations of A l-based scheduling are described next. ISIS [23] and OPIS [81] are two representative A l-based factory scheduling sys tem s, which m ainly deal w ith job shop scheduling. They are successful in term s of (providing knowledge representation and scheduling heuristics of factory scheduling jsituations. They have shown the feasibility and the prom ise of A l-based factory ischeduling, especially the way to represent scheduling entities using a knowledge representation language. Bruno, Elia, and Pietro [10] present a rule-based system for resource scheduling. jThey first identify three types of scheduling constraints: (1) operational constraints such as order of operation, due tim e and duration; (2) resource constraints such as order of operation and availability; and (3) capacity constraints such as machine lim it. They then use scheduling heuristics to represent procedural knowledge th at otherw ise are em bedded in th e detailed source code. These heuristics are m ade vis ible and modifiable from a user’s point of view. The actual scheduling algorithm is 27 based on these heuristics. It first selects tasks w ith th e highest value in their heuris tics, then it allocates the available machines to these selected tasks. Their system is im plem ented as a discrete-event sim ulation through forward-chaining production system rules. However, their system only provides a lim ited num ber of scheduling heuristics. Zhao and R am am ritham [99] propose a scheduling algorithm th a t uses simple and integrated heuristics to schedule tasks w ith tim e and resource constraints. These heuristics include m inim um duration first, m axim um duration first, m inim um dead line first, m axim um parallelism first as well as their com binations, which they call integrated heuristics. They conclude th a t a com bination of m inim um duration first, m inim um deadline first and m axim um parallelism first would achieve near-optim al schedules based on the results from their studies. Khoshnevis and Chen [53] propose another A l-based scheduling system based on a critical p ath heuristic. The system is im plem ented in LISP. A unique feature of their system is th a t it can dynam ically modify the plan when a re-schedule can not be generated. Fox, Sadeh and Baykan [22] propose the Constrained H euristic Search (CHS) as a general problem solving paradigm th a t combines constraint satisfaction w ith heuristic search. CHS consists of two fundam ental constructs: problem topology represents constraints im posed on th e set of variables, and problem tex tu re repre sents heuristic knowledge of search. Seven scheduling heuristics are discussed in the paper. T he CHS problem solving process is a com bination of constraint satisfaction and heuristic search. T he paper also gives two applications of CHS: spatial planning and factory scheduling. Keng and Yun [52] propose a sim ilar m ethodology to CHS w ith a fixed set of scheduling constraints and heuristics. Their m ethodology uses two heuristics to select candidates of variables (tasks) and values (resources): how critical a task is, and how crucial a solution is. Further, a task will be chosen among all the candidates if it has th e highest value of criticality during a loop of constraint satisfaction. A resource will be assigned to the chosen task only if it has the smallest cruciality. However, their m ethodology is lim ited to these two heuristics only. 28 2 .3 .3 R e-p la n n in g an d R e-sch ed u lin g M ost of th e scheduling systems exam ined so far do not handle situations when a schedule becomes invalid after changes in the world. Re-planning and re-schedulingi deal w ith changes in plans or schedules after they are created. Currently, two types of re-planning and re-scheduling are being investigated Increm ental planning and scheduling creates a partial plan or schedule w ith lim ited steps, hoping th a t changes will not occur in these steps. As changes are introduced, further steps of the plan or schedule will be created to incorporate them . Increm ental planning and scheduling solve only p art of th e dynam ic problem using available techniques. A nother type of re-planning and re-scheduling is reactive planning and scheduling. It discards part of an invalid plan or schedule when changes occur, and then creates a new partial plan or schedule to accom m odate them . Next, a num ber of m echanisms for re-planning and re-scheduling will be surveyed. SIPE [96] is a re-planner th a t repairs generic plan representation. It represents plans in term s of goals and actions and a broken plan is defined as unsatisfiable subgoals in a plan. SIPE includes a description of some generic classes of repair actions, such as rem oving subgoals and adding actions. CH EF [33] is another re-planner th a t repairs failed plans for Szechwan cooking. It uses a causal description of why a failure occurred to index to a set of strategies for repairing. It makes use of repair rules th a t are indexed by th e causal description. The repair rules them selves are fram es th a t are instantiated when a solution is created. This com bination of abstract repair knowledge and specific state inform ation results in a repair m echanism th a t is both general and powerful. Brown [8] proposes a dynam ic re-scheduler to assist m anaging change and adjust ing an active schedule to accom m odate new events in th e production environm ent. It uses techniques of hypothetical reasoning and constraint-directed re-scheduling to generate alternative adjusted schedules. It also uses a set of re-scheduling heuris tics to determ ine th e p art of an original schedule th a t has to be re-scheduled. The proposed re-scheduler had not been im plem ented when the paper was published. OPIS [72] describes a methodology for reactively revising schedules in response to unexpected events. The approach is based on recognition of constraint conflicts in th e existing schedule, and selection of re-scheduling actions to resolve the conflicts. 29 The re-scheduling actions represent different em phasis on solving conflicts, such as order-based or resource-based, which are im plem ented as re-scheduling heuristics. Logos [60] is a constraint-directed reasoning shell for scheduling. It provides: a constraint representation m echanism and a constraint-directed reasoning m echa nism. Re-scheduling is done by propagating new constraints th a t im pose new con ditions, so th e old schedule can be updated. 2 .3 .4 S u m m a ry o f P r o je c t an d R eso u rce S ch ed u lin g Table 2.5 lists th e basic characteristics abstracted from these scheduling mechanisms, including the system s, their task representation, scheduling m ethods, resource m an agem ent m ethods, and re-scheduling m ethods. Several conclusions can be drawn based on the analysis of these scheduling m ech anisms: 1. Task representation determ ines a scheduling system ’s capability. If a task rep resentation takes care of m ore objects and relations, it has th e potential to deal w ith m ore scheduling situations. At an early stage, task representation is dom inated by a directed network of tasks w ith task-on-the-edge or task-on-J the-node. Recently, object fram es and constraints are used to represent the task hierarchy. These new representations are m ore abstract and contain m ore types of inform ation th an ju st a partial execution order. T he types of inforj m ation now include resource requirem ents. Still, th e network representation is common, easy to read, and understand for hierarchical tasks. Therefore, most' of th e scheduling mechanisms provide a network representation interface for task hierarchies. 2. Scheduling algorithms are used to create schedules. To this end, CPM is one of the m ost influential m ethods in scheduling. In earlier tim es, it was th e m ost im portant and widely used m ethod. Recently, even though m any reasoning- based approaches are being investigated, CPM still provides a base scheduling heuristic for m ore advanced m ethods. 3. Resource management is a new addition to scheduling. To this end, resource leveling is a m ethod widely applied. Constraint satisfaction, created in the late 30 System Task Rep Method Resource Mgt Rescheduling PERT Precedence Net Critical Path N /A N /A CPM Precedence Net Critical Path Resource Leveling N /A CA-SuperProject [15] Precedence Net Critical Path Resource Leveling N /A ISIS [23] Frame, Relation Heuristic Search Resource Leveling N /A OPIS [81] Frame, Relation Heuristic Search Resource Leveling N /A Bruno and Pietro [10] Frame, Relation Rule-based N /A N /A Zhao and Ramamritham [99] Constraints Heuristic Search N /A N /A Khoshnevis and Chen [53] Lisp Predicate Heuristic Search N /A N /A Fox, Sadeh and Baykan[22] Constraints Constraint Satisfaction N /A N /A Keng and Yun [52] Precedence Net Constraint Satisfaction N /A N /A SIPE [96] Plan N /A N /A Classes of Repair Actions CHEF [33] Plan N /A N /A Heuristic Repair Rules Logos [8] Constraints Constraint Satisfaction N /A Constraint Propagation OPIS [72] Constraints Constraint Satisfaction N /A Heuristic Conflict Solving Brown [60] Frame, Relation Rule-based Reasoning N /A Constraint Propagation Table 2.5: Sum m ary of the Scheduling Mechanisms 1980s, deals w ith resource m anagem ent w ith much m ore flexibility although the fundam ental algorithm ic approach is similar. 4. Scheduling heuristics are the key to reducing the com plexity of scheduling. Since scheduling is N P-com plete, finding an optim ized schedule is computa-j tionally expensive. Early scheduling m echanisms, therefore, focus on creating a workable schedule for a given situation. In later stages, scheduling heuristics are used to help find a reasonably good schedule. In early stages, researchers' spent m uch effort to identify a good heuristic to a scheduling m echanism to ap ply and m ost m echanisms support a single heuristic. A fter A l-based scheduling 31 was introduced, it becam e relatively easy to study and apply new scheduling heuristics. Some of th e mechanisms can even support a group of scheduling heuristics at the same tim e giving users th e flexibility to choose th e heuristics they prefer. 5. Re-planning and Rescheduling use constraints to represent tasks and con strain t satisfaction, or heuristic search to create new plans or schedules. There exist two reasons for the selection of constraint-base approach. F irst, it is very flexible, so changes are easily introduced. Second, it is easy to update plans or schedules th a t are created earlier, which is im plem ented through constraint propagation. 2.4 Discussion and Synthesis T hree types of techniques for software process m odeling show how to support sys tem atic planning of software developm ent in term s of its activities and resource us age. Em pirical studies of system developm ent point out another yet-to-be-supported developm ent activity called articulation. A rticulation resolves process breakdowns th a t are introduced by changes in the environm ent, and adapts SPMs to them in process-driven software developm ent accordingly. Then, a num ber of system s for scheduling, re-planning, and re-scheduling show th e value of different heuristics and resource m anagem ent constraints when scheduling complex, dynam ically changing projects. Having surveyed related work, let us revisit th e problem s and the solutions identified in C hapter 1: • The process m odeling techniques currently support various SPM formalisms. These formalisms cover some aspects of software developm ent and involved developm ent artifacts. However, there does not exist a process m odeling for m alism th a t sim ultaneously supports: (1) conceptual form al descriptions of all kinds of developm ent artifacts, including those describing tasks, developers, products, resources, and tools; (2) conceptual descriptions of process break downs and knowledge of articulation abstracted from em pirical studies; and (3) knowledge-based m echanisms to support various kinds of process modeling and analyzing, such as sim ulation, enactm ent, articulation, and scheduling. Such 32 a form alism will provide a broader range of support in m odeling large-scale software processes. • There is very little experience with SPM construction, m ost of which is small- scale. This is partially caused by a lack of guidance and autom ated tools to support building custom ized SPMs. Furtherm ore, there is little capability to support static analysis of SPMs after SPM s are specified. Users are left alone when they use th e process modeling techniques to describe their own SPMs. Therefore, it is desirable for a process m odeling form alism to provide guidance to SPM construction, as well as support for process definition and static analysis which m ake SPM construction easier. • Since SPM s are enacted in changing environm ents, changes th a t occurs m ight m ake previously planned SPMs or scheduled resource allocation invalid, and stop norm al SPM enactm ent. The em pirical studies identify the frequent oc currences of both process breakdown and articulation work. U nfortunately, no m echanisms exist to support process articulation. This makes SPM enactm ent im practical for real applications. To this end, a repairing m echanism such as process articulation is needed as a back-end support during SPM enactm ent. • Techniques of project and resource scheduling, although dealing w ith prob lems th a t are related to SPM s, have not been integrated w ith current process m odeling techniques. They use different representation for their dom ain of knowledge respectively. Nonetheless, to make the use of SPM s and PSEEs practical, scheduling m echanisms m ust be incorporated. • T here are two forms of knowledge th a t can be reused to support articulation. On the one hand, em pirical studies on system developm ent identify a set of causes of process breakdowns and a set of commonly used articulation m ethods. On th e other hand, systems for scheduling, re-planning, and re-scheduling iden tify m echanisms to accom m odate global changes in developm ent projects. To apply these results in process articulation, one first needs to carefully evaluate the existing m echanisms and create a new m echanism to support articulation. Since articulation is a knowledge intensive process, use of heuristics is a way to reduce th e search com plexity and to be more domain-specific. Therefore, one 33 needs to abstract and represent th e observed articulation m ethods and adapt them to th e new articulation mechanism. To this end, the A rticulator system is designed and im plem ented to address these issues and provide autom ated support to process m odeling, definition, analysis, enactm ent, and articulation. T he rem aining chapters in this dissertation describe th e features of the A rticulator system , and how they are used to support th e static- and dynam ic analysis of SPMs. 34 Chapter 3 An SPM Formalism: The Articulator Meta-Model Knowledge representation is one means by which our understanding of a phenom enon, situation, or process can be formally described. As such, th e A rticula to r m eta-m odel is introduced as a formalism to present a set of classes for describing software processes, their developm ent environm ents, and their instances. Accord-j ing to the A rticulator m eta-m odel, a formal representation of SPMs has four basic com ponents: (1) an activity hierarchy which describes a work breakdow n structure and precedence relationship among developm ent tasks; (2) resource requirem ents for a task to be perform ed, such as requirem ents for agents, tools, required resources, and produced resources; (3) possessions of resource instances allocated to a task! th a t m atch the resource requirem ents; and (4) other inform ation for scheduling such as sta rt tim e and estim ated task duration. These types of inform ation are used as constraints to drive SPM enactm ent. As such, this chapter describes th e A rticulator m eta-m odel. 3.1 Introduction A knowledge-based representation of software processes is useful for th e followings reasons: • Inform ation repository. A knowledge-based model provides a conceptual repos itory and a consistent user interface to store and access all kinds of inform ation relevant to a software process. 35 • Structure o f inform ation. Most knowledge-based models use the object-oriented and rule-based technology to organize inform ation. The object- oriented technology presents knowledge and inform ation in term s of a set of related object classes and objects along w ith properties of relations and inher itances. Such a structure is easy to access and evolve. • Representation o f domain information. Knowledge of a specific dom ain is represented w ith a class by a set of attributes and relations to other classes. B oth attrib u tes and relations describe properties th a t are of interest and have a set of predefined values, which serve as a dom ain model to be studied. T he form alism used to represent knowledge and structure of SPMs is called the Articulator meta-model. A process m eta-m odel [29, 83, 84, 94] provides the basic ontology and vocabulary of components for constructing an SPM . Therefore, a m eta-m odel provides a set of basic object classes and relations for building an SPM. Further, a process m eta-m odel provides an articulate view of the m any aspects ofi software processes w ithin a single formalism. T he theoretical scheme underlying the A rticulator m eta-m odel is the web m odel of com puting introduced by Kling and Scacchi [55]. This web m odel relies on em pirical studies and makes explicit a variety of connections between com puting technologies, artifacts, activities, together w ith their em bedding social situations and organizational infrastructure. However, the A rticulator m eta-m odel further expands the context of the web m odel and formally represents this expanded context in a com putational form. T he A rticulator m eta-m odel shown in Figure 3.1 consists of an object hierarchy of these basic classes, such as re s o u rc e , a g e n t, and ta s k . T he class re s o u r c e is the root of this m eta-m odel hierarchy, while th e other object classes are subclasses of r e s o u rc e . Each of th e resource classes describes a type of entities th a t are used in a software process Overall, the A rticulator m eta-m odel consists of a web of resource classes th a t are relevant to software processes. T he A rticulator m eta-m odel is innovative in two aspects: F irst, it not only pro vides inform ation about resource classes and their use as in [96], b u t it further dis tinguishes betw een resource requirem ents and possessions. The distinction between resource requirem ents and resource possessions forms a basis for richer representa tion of breakdowns and articulation knowledge. Second, the generic resource class 36 in th e m eta-m odel is further divided into several types of usage subclasses, such as agents, tools, required resources, and provided resources. The A rticulator m eta-m odel is an open system, [35]. W hen applied, it assumes following special characteristics: • T he A rticulator m eta-m odel views its modeled world w ith a simple process orientation: the world consists of interacting processes th a t are perform ed by agents, consume required-resources, and produce provided-resources. This abstraction captures our fundam ental understanding of software processes. • T he boundary of th e A rticulator m eta-m odel and its interface w ith the outside world is determ inable, though not necessarily static. T he m eta-m odel, besides m anipulating its own resources, com m unicates w ith th e outside world. Such com m unication of th e A rticulator m eta-m odel w ith th e outside world is m ade possible through acquiring or providing resources. • All the object classes in th e A rticulator m eta-m odel have their own life-cycle. Every instance of an object is either created by some SPM , or introduced by th e outside world, persists for a period of tim e, and then is consum ed by other SPM or exported to th e outside. • An agent’s power to m anipulate the A rticulator m eta-m odel is lim ited and configurable. This m anipulation power includes possession or control of re sources, rights of inform ation access, and rights of task perform ance. This power can be restricted to some constraint over a period of tim e. On the other hand, this power m ay be reconfigured at any tim e by authorized agents. In this way, centralized control, distributed control, or som ething in between, can be im plem ented. • T he A rticulator m eta-m odel is a densely interrelated infrastructure. By def inition, any resource class in th e m eta-m odel is associated w ith m any other resource classes through relations. W ith this kind of infrastructure, enactm ent of a task can cause m any im plicit side effects besides its intended behavior. For exam ple, in an SPM , a m anager agent m ay assign a task to a developer agent w ithout allocating th e necessary resources for task com pletion. This 37 will not cause any problem in resource allocation, but will surely delay the; SPM enactm ent since th e developer agent will have to spend tim e to find thej resources required for SPM enactm ent. The consequences and im plications of! side effects are of interest because they resem ble real situations in m any ways. T he rem aining sections of this chapter describe the com ponents and objects incorporated in the A rticulator m eta-m odel for use in constructing SPM s. 3.2 SPM Components SPM s defined according to the A rticulator m eta-m odel represent a formal way to describe and study software life-cycle models, developm ent methodologies for eachj life-cycle stage, CASE tools, and developers. SPMs are specified as collections of objects which represent developm ent activities, developers, tools, resources, andj artifacts. Each of these objects describes a kind of inform ation th a t is involved in software developm ent. F urther, these objects are linked through m any kindsj of relations. A ltogether, SPMs serve as a repository of inform ation on th e status! of software processes and activities th a t get m anipulated throughout a software developm ent project. In the A rticulator m eta-m odel, such inform ation is organized into four basic com ponents to build an SPM . These SPM com ponents include: • An activity hierarchy th a t describes a work breakdown structure and prece dence relationship among developm ent tasks. • Resource requirements for a task to be perform ed, such as requirem ents for developers, developm ent tools, critical resources, and software artifacts. • Possessions o f resource instances allocated to a task th a t m atch the resource requirem ents. • Other inform ation fo r scheduling such as start tim e and estim ated task dura tion. 38 3.2.1 A c tiv ity H ierarch y An activity hierarchy represents th e decom position of an SPM into a hierarchy of sm aller actions called tasks and activities. Throughout this dissertation, subtasks will be used to refer to both tasks and activities since they are com ponents in an SPM . An activity hierarchy also provides an expected enactm ent order among the subtasks which is abstracted as a precedence relationship. Task decom position divides a task into a set of subtasks whose com bined de velopm ent results accomplish the task ’s expected objective. T he subtasks are then divided again into sub-subtasks. Levels of decom position w ithin a process or a task can be arb itrary depending on th e com plexity of the SPM and th e developer’s needs. T he top-level description of an SPM should be a task which is decomposed into a! set of interrelated subtasks. At the bottom of this hierarchy are activities, which: represent a single tool invocation and simple resource production. As such, task decom position forms a tree of subtasks th a t indicates how each subtask achieveJ p art of th e goal in its supertask. W ithin a level of a decom position there exists a partial enactm ent order am ong the subtasks. This partial enactm ent order defines th e sequences for executing sub tasks to realize their supertask’s goal. C onstructors are defined to specify four types of enactm ent order: Precedence enactm ent describes which subtask precedes another. Parallel enactm ent describes a set of subtasks to be executed in parallel. Conditional^ enactm ent describes selected execution among a set of subtasks. Iterative enactm ent is for repetitive execution of a set of subtasks. Functionally, an activity hierarchy specifies a developm ent plan to be carried out. It also acts as a sketch to attach other types of inform ation to be explained later (see Figure 3.6). 3 .2 .2 R e so u r c e R eq u irem en ts Resource requirements for an SPM or a subtask define th e classes of resource nec essary for th e subtask to perform as expected. These are specification of resource classes, not actually resource instances. Consider this exam ple: to finish a program m ing j°b , program m ers are a necessary resource. Here, the class of program m er is a resource requirem ent for the task program m ing. W ith this specification, when 39 program m ing starts, some people m ust be allocated to the role of program m er and preferably they are qualified program m ers. To further identify different uses of a resource in a subtask, th e A rticulator m eta-m odel lists four types of resource requirem ents. These four types of resource requirem ents for a subtask specify developers or developm ent organizations th a t perform which are called agents or roles, raw m aterials to be consumed which are called required-resources, developm ent tools to be applied which are called tools, and artifacts to be produced which are called provided-resources. A quan tity of resource requirem ents is also needed. In specifying an SPM , resource requirem ents are only needed for th e bottom -level activities. Resource requirem ents for tasks can be recursively retrieved from those of its subtasks. Figure 3.7 gives a definition of resource requirem ents which will be explained later. 3 .2 .3 R eso u rc e P o sse ssio n Resource possession includes real resource instances th a t are physically allocated and used in SPM enactm ent. It binds real resources to enactm ent. Consider again the previous exam ple: if m anagem ent allocates John and Doug, two program m ers, to program m ing, it can be expected th a t the task can be carried out smoothly. Corresponding to the four types of resource requirem ents, there are four types of re source possession defined in th e A rticulator m eta-m odel. In Figure 3.7, the a ttrib u te r e s o u r c e - p o s s e s s io n holds allocated resource instances th a t m atch the resource requirem ent. Separation of resource requirem ents and possessions brings an im portant feature to the A rticulator m eta-m odel: the qualification test. T he qualification test checks if allocated resource possessions for a subtask m atch the corresponding resource requirem ents. Such a m atch is crucial for a subtask to be successfully com pleted and it can be enforced on different levels of complexity. For exam ple, a simple qualification test checks th e class inform ation: A resource possession passes the qualification test if and only if it is an instance of the class in its corresponding resource requirem ent. A com plicated qualification test m ay state th a t a resource ipossession passes if and only if it belongs to a set of classes th a t are defined to be 40 sim ilar to th e class in its corresponding resource requirem ent. More complicated! algorithm ic qualification tests are possible based on user requirem ents when th e A rticulator m eta-m odel is used in real situations. These qualification tests can be im plem ented through user defined functions. 3 .2 .4 O th er In fo rm a tio n O ther inform ation for a subtask is basically for the purpose of scheduling. They are represented as attrib u tes w ithin an object class and have simple integral values. Exam ples of these attrib u tes include expected duration and start tim e. These types of inform ation will be given when the object classes in the A rticulator m eta-m odel are defined later. 3.3 Definition of Object Classes In this section, definitions of the object classes th a t realize these basic SPM compo nents are presented in detail, which includes task, agent, and resource (Figure 3.1). 3.3.1 T h e A g e n t C lass An a g e n t represents a collection of behaviors and associated attrib u tes. In the A rticulator m eta-m odel, behavior describes a specific way of selecting and executing SPM s. For exam ple, agents m ay choose to execute SPM s w ith th e highest assigned! priority. An a g e n t’s behavior emerges during the perform ance of tasks (including com m unications, accom m odation, and negotiation) given th e agent’s set of skills] available resources, and affiliated agents; th a t is, given the agent’s circum stantial situation. In this research, the notion of a g e n ts are used as a general m odel of both individual developers and developm ent team s. Figure 3.2 gives a definition for a g e n t class. An agent’s ability to perform tasks is defined by its working load, its agenda, its way of work, and its working tasks together w ith its behavior controller (its “self”). In order to perform a task, an agent m ust possess the necessary resources and rights of inform ation access. An agent may have affiliations w ith other organizations and play different roles in different organi zational situations [26, 55]. Besides these, agents have a knowledge representation 41 KC> KNOWLEDGE CRAFT C u rre n t c o n te x t: IROOr-COHfEXT Palm N etw ork E d ito r ' i enrpor< |Smna ] Ifcptions ‘SIMPLE-RESOURCE •COLLECT!VE-AGENT - •INDI VIDUAL-AGENT - •ROLE •MESSAGE •D O C U M E N T •SETTING COMMUNICATION 41EDIA •MISSION •BELIEF •AGENDA •SCHEDULE •SKILL •EXPERIENCE •INCENTIVE •MICROTHEORV •TEAM •ORGANIZATION •WORK CROUP— < •NQN-INTELLIGENT-AGGNT « '•1WTELLIGENT-AGENT - (elation Keys; 1(1) IS-A 3alin Compand: Create P«1*tion ■MLSi-swwnaynaroj r scrwuinp ; xwa - r r « n e /a r s - m e c a .s c r Figure 3.1: The A rticulator M eta-M odel which specifies their potential behavior, and this behavior can also be dynam ically sim ulated by its behavioral controller. Com m unication structure provides one-way, off-line com m unication between agents. It is currently functioning as a mail system. A gents com m unicate by sending and receiving messages from other agents. There are two types of messages: struc tu red messages, which are processed directly by th e A rticulator m eta-m odel, and unstructured messages, which are not processed at all. Task assignm ents, proposals, and resource requests are exam ples of structured messages. Also, the arrival of a m essage can in terru p t th e receiver’s current activity if required to do so. Inform ation retrieval gives access rights to a g e n ts . Knowledge and inform ation stored in the A rticulator m eta-m odel can be used by any agent when it is needed, b u t its access has to be controlled. Therefore, inform ation retrieval provides a way 42 {{A gen t is-a: m ax-working-load: agent-has-agenda: agent-play-role: agent-role-perform ing-top-task: Resource [fraction] [agenda-object] [roles] [SPMs] agent-role-received-m essage: [messages] agent-role-send-m essage: [messages] Figure 3.2: Definition of A gent Class to get inform ation about the current status of resource configuration, and provides restrictions and authorization of inform ation access as well. There are two subclasses of agents in th e A rticulator m eta-m odel: Individual agents are single entities, such as a single developer. Collective agents have infras tructures defined for a group of agents to work together, thereby enlarging their efforts. In a collective agent, individual agents work cooperatively or com petitively to achieve their collective and individual goals. However, collective agents can also( be in conflict over how to achieve their goals, as well as over which goals are worth achieving in w hat order. • An in d iv id u a l- a g e n t is a class of single agents th a t behave independently. Its definition (Figure 3.3) specifies an action controller to execute its defined behavior of task enactm ent. Behavior of task enactm ent is specified by a group of attrib u tes, for instance, ta s k - e x e c u tio n - s tr a te g y for selecting those as signed tasks and a r t i c u l a t i o n - p s - h e u r i s t i c s for available problem-solving heuristics (these attrib u tes are part of articulation specification and defined in C hapter 7 and C hapter 8). The action controller, together w ith agendas and attached functions, provides basic control on operational behavior for individual agents. T he controller models a single agent’s ability to select and perform an activity at a particular tim e. An agenda is defined as a tim e table which specifies which activity to perform for which tim e period. For exam ple, an agenda m ay record all activities a m anager should do on Tuesday, or in th e whole week. The only 43 difference is th a t agenda here records the sm allest activities perform ed by agents, any type of agents. At each tim e interval, th e activity controller picks up an activity assigned to the agent to perform at this m om ent, checks if all preconditions of th e activity are m et, and then perform s or enacts th e activity. In order to simplify th e processing, th e period of enactm ent of an activity is defined as num ber of unit tim es, such as 1, 2, or 10. O ther functions of the activity controller include checking message m ail, handling interruptions, and invoking articulation when needed. • P e o p l e is a subclass of individual agents and th e only subclass currently de fined in the i n d i v i d u a l - a g e n t class. Since m ost of th e properties have been defined in its super-classes, p e o p l e class only provide inform ation of access right to th e m odeled developm ent environm ent (Figure 3.3). As an exam ple, two instances of P e o p l e , M ary and Peter, are defined in th e figure. They are assigned to th e D e v e l o p - C h a n g e - a n d - T e s t - U n i t while M ary is its m anager. Individual task performance describes an individual people’s ability to perform tasks individually. W hen SPMs are assigned, th e individual first chooses a strategy, which is stored in the attrib u te t a s k - e x e c u t i o n - s t r a t e g y . Next, th e individual selects an activity according to t a s k - e x e c u t i o n - s t r a t e g y and perform s the activity. Currently, a num ber of task perform ance strategies are im plem ented to describe different developer behavior: — By-random: Random ly select and perform an SPM from th e assigned SPMs. — F i n i s h - o n e - F I F S : Finish one SPM at a tim e. SPMs will be selected based on their arrival tim e. The earlier an SPM comes, th e earlier it is perform ed. — F i n i s h - o n e - h i g h e s t - p r i o r i t y : Finish one SPM at a tim e. SPM s will be selected based on their pre-assigned priority. T he higher an SPM ’s priority is, the earlier it is performed. — F i n i s h - o n e - e a r l i e s t - d u e : Finish one SPM at a tim e. SPM s will be selected based on their com pletion due tim e. T he earlier an SPM is due, th e earlier it is perform ed. t 44 {{In dividual-Agent is-a: Agent action-cont roller: [controller-function] controller-goal: [controller-goal] controller- paramet er: [strings] task-execution-strategy: [behavioral-strategies] articulation-ps-heuristics: [problem-solving-heuristics] articulation-selection-heuristics: [selection-heuristics] }} {{People is-a: individual-agent people-role-has-info-access-authority: [information-retrieval] manager-of-task: [managed-tasks] }} {{Mary instance: People max- working-load: 1 agent -has- agenda: mary-agenda agent-play-role: Manager agent-role-performing-top-task: Develop-Change-and-Test-Unit task-execution-strategy: FIFS people-role-has-info-access-authority: all manager-of-task: Develop-Change-and-Test-Unit }} {{Peter instance: People max-working-load: 0.5 agent-has-agenda: peter-agenda agent-play-role: QA-Engineer agent - r ole- p er for mi ng-1 op-1 ask: Develop-Change-and-Test-Unit t ask-execution- st rategy: FIFS people-role-has-info-access-authority: all }} Figure 3.3: Definition of In d iv id u a l-A g e n t and P e o p le Subclasses 45 — F i n i s h - o n e - s h o r t e s t - d u r a t i o n : Finish one SPM at a tim e. SPM s will be selected based on their estim ated duration. T he shorter an SPM ’s duration is, the earlier it is performed. — F in is h - o n e - lo n g e s t- d u r a tio n : Finish one SPM at a tim e. SPM s will be selected based on their estim ated duration. T he longer an SPM ’s duration is, the earlier it is perform ed. — B y - t u r n - a l l : Perform one activity out of all assigned SPM s by turn. T he selection is based on SPM s’ arrival tim e. — B y - t u r n - h i g h e s t - p r i o r i t y : Perform one activity out of all assigned SPMs by turn. T he selection is based on SPM s’ priority. A nother type of task perform ance strategy is th e articulation strategy th a t di rects an individual people’s behavior during articulation. T he articulation strategy will be explained in later chapters together w ith th e articulation m odel. All these task execution strategies are im plem ented as forward-chaining OPS5 rules in th e A rticulator and executed during process sim ulation. • A c o l l e c t i v e - a g e n t is a group of agents working together to achieve larger- scale tasks. A collective-agent is defined to have organizational structures for owning resources and inform ation, having m em bers, and perform ing collec tively tasks (Figure 3.4). T he attrib u te c o l l e c t i v e - a g e n t - h a s - m e m b e r defines m em ber agents w ithin a collective-agent who are linked to it in order to perform assigned tasks spec ified in attrib u te c o l l e c t i v e - a g e n t - p e r f o r m i n g - t a s k . M em berships can be defined in a nested fashion, th a t is, collective-agents m ay have other collective- agents as th eir m em bers. For exam ple, team s can contains sub-team s each of which is responsible for a particular task. • A t e a m is the only subclass of c o l l e c t i v e - a g e n t and is a m odel of an or ganizational structure of several agents to coordinate a project task. In this respect, a t e a m is task-oriented. A team environm ent is cooperative: agents come to the team to accom plish a common goal and they are willing to coordi nate th eir efforts to create a b etter product. T e a m m e m b e r s are also willing to 46 { { C ollective- Agent is-a: collecti ve- agent- has-role: collective- agent-has-m em ber: collective-agent-ow n-resource: collective- agent- p erforming-1 ask: {{te a m is-a: team -has-subteam s: control-m echanism : com m unication-m echanism : work- assignm ent: {{S E -g ro u p l instance: collective-agent-has-role: collective-agent-has-m em ber: collective-agent-perform ing-task: cont rol- m echani sm : A gent [defined-roles] [mem ber-agents] [owned-resources] [assigned-tasks] }} Collecti ve- Agent [subteams] [controlling-strategies] [com m unication-strategies] [w ork-allocation-to-m em bers] } } team M anager Engineer Q A-Engineer M ary Peter John D evelop-C hange-and-T est-U nit egoless-team }} Figure 3.4: Definition of C o lle c tiv e -A g e n t and Team Subclasses share their knowledge and inform ation. This assum ption provides a basis for th e team knowledge structure, which can be used when a problem is encoun-! tered. T he attrib u tes of a team include: team m em bership, th e assigned task] team norm , team knowledge structure, team resources and control m echanisms (Figure 3.4). A team does not have activity controller as in d iv id u a l- a g e n ts have. B ut in order for its m em bers to execute th e task, a team provides task plan ning and scheduling to assign the m em bers a subset of th e task. Then each m em ber executes its own activity controller to finish th e job. Team coordi nation, therefore, is represented in the SPM , schedule, interactions between' th e m em bers, and task articulation. In Figure 3.4, a team instance called! S E -g ro u p l is defined. It has several roles and m em bers and is assigned to perform D ev elo p -C h an g e-an d -T est-U n it. 47 Collective task performance refers to an individual agent’s ability to work w ith o ther agents through interactions to get things done jointly. T he collective task perform ance, based on individual task perform ance, supports two basic kinds of interaction: com m unication and synchronization. Communication^ among agents is a way to exchange inform ation. In com m unication, agents exchange their inform ation and knowledge about th e resources and situations by sending and receiving messages. Through message exchange, they can also! integrate individual efforts by combining exchanged individual products to-j gether. Synchronization among agents arrange schedules for a group of agents work together in order to perform collective tasks. For a collective task, all its perform ers have to be present for them to be executed. On th e other hand] i these agents are norm ally executing their own individual tasks while some of them m ay initialize collective tasks at any m om ent. Synchronization arranges, schedules for collective tasks and is responsible for th e follow-up actions when this fails. 3 .3 .2 T h e T ask C lass A task class models software processes. T asks represent situations for work th a t agents perform . A t a s k is used to represent both a plan of th e actual task before it is carried out (a prescriptive model) and the actual execution trajecto ry of the task after it has been done (a descriptive model). B oth of these include an activity hierarchy, resource requirem ents and resource possessions. Definition of tasks are shown in Figure 3.5. In the definition, the strings at th e left side of th e semicolons represent nam es of attrib u tes, the strings at th e right side w ithin th e brackets ([| and ]) are definitions of th e values instead of real values. For exam ple, attribute! ta sk -h a s-c o m p o n e n t has values th a t are nam es of its subtasks. T he values for a ttrib u te s t a t u s are from a set defined by [ s t a t u s - v a l u e ] . Four groups of attrib u tes are defined for a task: T he first one is th e IS-A relation which defines T ask as a subclass of R esource. T he second group defines a ta sk ’s activity hierarchy through two sets of relations for activity hierarchy and partial enactm ent order respectively as discussed earlier. Figure 3.6 lists definitions for 48 {{T ask is-a: task-com ponent-of: task-has-predecessor: task-has-successor: task-has-agent-spec: task-has-tool-spec: task-has-required- resource-spec: task-has-provided-resource-spec: status: average-duration: due-tim e: earliest-start-tim e: latest-start-tim e: slack: actual-start-tim e: actual-finish-tim e: Resource [super-task] [predecessor-subtasks] [successor-subtasks] [agent-requirem ents] [tool-requirem ents] [input -resource- requi r em ent s] [output-resource-requirem ents] [status-value] [integer] [integer] [integer] [integer] [integer] [integer] [integer]}} [status-value] = N one, A llocated, Ready, A ctive, Stopped, Broken, D one, N ot-chosen Figure 3.5: Definition of T ask Class these two pair of relations. Relation definition includes: its dom ain which speci fies where th e relation sits, its range which specifies w hat classes can be its values,' its transitivity which specifies the depth of the p a th where inform ation is accessed] and its inverse relation. T a sk -c h a in -h a s-co m p o n e n t and ta sk -c o m p o n e n t-o f de fine com ponent subtasks for a task-chain (to be defined later). By this definition, activities are not allowed to have com ponents because, sem antically, they are th e b o tto m of task hierarchy. P artial enactm ent order is defined by another pair of rela-j tions: ta s k - h a s - p r e d e c e s s o r and ta s k - h a s - s u c c e s s o r , which defines precedence relationship among subtasks. W hen a relation is defined in the A rticulator m eta m odel, its inverse relation is always defined. In this way, th e system autom atically m aintains both of the relations when one of them is updated. For exam ple, when activity program m ing is inserted as a predecessor of activity t e s t i n g , t e s t i n g is autom atically asserted as a successor of program m ing. Inform ation about relation definitions will not be provided from now on, but rem em ber th a t all relations are defined in sim ilar fashion as the ones here. 49 { {task- component-of is-a: domain: range: transitivity: inverse: { {t ask-has- component is-a: domain: range: transitivity: inverse: {{task-has-successor is-a: domain: range: transitivity: inverse: { {task-has-predecessor is-a: relation domain: (type is-a task) range: (schema (type is-a task)) transitivity: (repeat (step task-has-successor t) 1 inf) inverse: task-has-successor}} F ig u re 3.6: D efin itio n o f A c tiv ity H ierarchy R e la tio n s The th ird group of attrib u tes points to resource requirem ents and possessions for a subtask. A class of object called r e s o u r c e - s p e c i f i c a t i o n is created to store resource requirem ents and possessions and is divided into four subclasses for th J four types of resource requirem ents. T he definition of r e s o u r c e - s p e c if i c a t i o n is shown in Figure 3.7. In th e definition, re s o u rc e -re q u ire m e n t, m inim um -quantity, and m axim um -quantity provide inform ation about type and quan tity of needed re sources, while r e s o u r c e - p o s s e s s io n points to th e real resource instances th a t are allocated to m eet th e resource requirem ents. T he figure also shows the resource spec ification for agents called a g e n t-s p e c which has a relation linking to a corresponding task. 50 relation (type is-a task) (schema (type is-a task-chain)) (repeat (step task-chain-has-component t) 1 inf) t ask- chai n-has- component} } relation (type is-a task-chain) (schema (type is-a task)) (repeat (step task-component-of t) 1 inf) task-component-of}} relation (type is-a task) (schema (type is-a task)) (repeat (step task-has-predecessor t) 1 inf) t ask- has- predecessor } } {{resource-specification is-a: resource-requirem ent: m inim um -quantity: m axim um -quantity: resource-possession: {{agen t-spec is-a: agent-role-spec-in-task: {{tool-sp ec is-a: agent-role-spec-in-task: {{required-resource-spec is-a: agent-role-spec-in-task: {{provided-resource-spec is-a: agent-role-spec-in-task: sim ple-resource [resource- classes] [integer] [integer] [allocated-resource-instances] } } resource-specification [attached-tasks] } } resource- specification [attached-tasks] } } resource-specification [attached-tasks] }} resource-specification [attached-tasks] }} Figure 3.7: Definition of R e s o u r c e - S p e c i f i c a t i o n T he last group of attrib u tes is for scheduling. They basically specify duration, sta rt tim e and finish tim e for a task. Also included is inform ation for arranging resources such as slack tim e. A task in th e A rticulator m eta-m odel is further divided into two subclasses: activities which are non-decom posable and task-chains which are decomposable: • An a c t i v i t y represents the smallest task perform ed by agents. An a c t i v i t y is an atom ic work un it th a t is directly perform ed by an agent or agents with! a single tool invocation on one or m ore resources. Definition of activity class is given in Figure 3.8. A ttributes p r e c o n d i t i o n and p o s t c o n d i t i o n are used to allow users define th eir constraints over an activity beside the precedence and resource con-j straints. In case an activity has an attached a function (in LISP or 0P S 5) th a t controls its behavior in SPM enactm ent, th e function is stored in a ttrib u te 51 {{Activity is-a: precondition: postcondition: acting: parameter: {{Modify-Design instance: task-component-of: t ask-has-predecessor: task-has-successor: task-has-agent-role-spec: task-has-required-resource-spec: task-has-provided-resource-spec: {{Modify-Code instance: task-component-of: task-has-predecessor: task-has-agent-role-spec: task-has-required-resource-spec: task-has-provided-resource-spec: task [functional-condition] [functional-condition] [function-name] [strings] }} activity Develop- Change- and-Test- Unit Assign-Task Modify-Code agent-for-modify- design required-for- mo dify- design provided-for-modify-design }} activity Develop-Change-and-Test-Unit Modify-Design agent-for-modify-code required-for-modify-code provided-for-modify-code }} Figure 3.8: Definition of A c tiv ity Subclass a c t i n g . T he default value of a c t i n g is a LISP function called p r i n t - f n which only signals its enactm ent. C urrently, three subclasses of th e a c t i v i t y class are defined. T he difference of these subclasses lies only in their behavior. A s t a n d a r d - a c t i v i t y requires com puterized developm ent tools and its enactj m ent can be fully supported through tool invocation. A s y m b o l i c - a c t i v i t y is one which does not use com puterized tools and its enactm ent will only be sym-J bolically recorded in the SPM in order to have a com plete process description and to support project m anagem ent. A s y s t e m - a c t i v i t y is an automated! activity whose attached function can be enacted by SPM enactm ent. Such! function is defined in its attrib u te a c t i n g . In Figure 3.8, two activities, called M o d i f y - D e s i g n and M o d i f y - C o d e are defined. They are com ponents of a pro cess called D e v e l o p - C h a n g e - a n d - T e s t - U n i t , a n d this SPM exam ple will be 52 {{T ask-C hain is-a: Task task-has-com ponent: [subtasks] task-has-m anager: [manager-agents] } } { { D evelop- Change- and- Test- U nit instance: Task-Chain task-has-com ponent: M odify-D esign M odify-C ode task-has-m anager: M ary }} Figure 3.9: Definition of T a sk -c h a in Subclass detailed later. In their definitions, th e relations w ithin the activity hierarchy are defined, but w ithout th e custom ized preconditions and post-conditions. Several s y s t e m - a c t i v i t i e s are defined to im plem ent various types of enact m ent order. Conditional enactm ent is represented by a pair, b r a n c h - b e g in - a c tiv ity and b r a n c h - e n d - a c tiv ity . Its enactm ent requires! th a t successors of a b r a n c h - b e g in - a c tiv ity represents a set of choices anc com pletion of one of the choices signals com pletion of the conditional enact m ent. Iterative enactm ent is represented by another pair, i t e r a t i o n - b e g i n - a c t i v i t y and i t e r a t i o n - e n d - a c t i v i t y . Its enactm eni requires th a t th e body betw een the pair of s y s t e m - a c t i v i t i e s is repeatedly executed until conditions specified in an i t e r a t i o n - b e g i n - a c t i v i t y is met! T here exist also some other s y s t e m - a c t iv i t i e s th a t provide other autom atic functions for th e A rticulator m eta-m odel. The exact enactm ent sem antics for these s y s t e m - a c t i v i t i e s will be given in C hapter 6. • A t a s k - c h a in is a decom posable task in the A rticulator m eta-m odel. It con sists of activities and others task-chains, which exist in several different lev els, representing several levels of decom position. Perform ance of a task-chain is therefore accom plished by the combined perform ance of all its component' subtasks. Similarly, com pletion of a task-chain is defined as th e com bined com pletion of all its subtasks. 53 {{R esource is-a: type: status: functional-description: resource-belong-to-agent-role: resource-locate-in-setting: resource-listed-in-specification: Physical-object [type-value] [status-value] [textual- description] [owner-agents] [physical-location] [resource-specification] }} {{Sim ple-R esource is-a: Resource }} [type-value] = standard, sym bolic, system , reusable, non-reusable Figure 3.10: Definition of Resource and Sim ple-Resource Classes Figure 3.9 gives definition of task-chain subclass. A ttrib u te t a s k - h a s - c o m p o n e n t stores com ponent subtasks for a task-chain and a ttrib u te t a s k - h a s - m a n a g e r points to m anager agents. Resource requirem ents for a task-chain can be sum m arized from its lower levels of subtasks recursively. Therefore, it is not necessary for a user to providJ such inform ation at this level. In fact, an autom atic function, called s u m - u p j has been im plem ented to fill out resource requirem ents for a task-chain once) its com ponent activities are given all resource requirem ents. In Figure 3.9, D e v e l o p - C h a n g e - a n d - T e s t - U n i t is defined as an instance of T a s k - C h a i n . It has two com ponents, M o d i f y - D e s i g n and M o d i f y - C o d e (m ore com ponents will be defined later) and a m anager agent called M a r y . 3 .3 .3 T h e R eso u rce C lass A r e s o u r c e , as a model of general artifacts, portrays the general properties of or ganizational entities. Accordingly, resources are objects consum ed and produced in tasks. Definition of r e s o u r c e class (Figure 3.10) provides inform ation of name, current status, functional description, physical location, ownership, and m ore im portantly, its usage in tasks. R e s o u r c e s in th e A rticulator m eta-m odel are further divided into several sub classes. Class t a s k and a g e n t are subclasses of r e s o u r c e . O ther subclasses are 54 {{Sim ple-resource is-a: Resource }} {{Softw are is-a: Sim ple-Resource } {{H ardw are is-a: Sim ple-Resource } {{D ocu m en t is-a: Sim ple-Resource } {{M essage is-a: Sim ple-Resource } {{R o le is-a: Sim ple-Resource } {{B u d get is-a: Sim ple-R esource } { { sun-workst ation 1 instance: hardware resource-belong-to-agent-role: SE -groupl resource-locate-in-setting: SE-building resource-listed-in-specification: change-req-spec }} {{c-com piler instance: software resource-belong-to-agent-role: com pany resource-listed-in-specification: change-req-spec }} Figure 3.11: Definition of O ther O bject Subclasses grouped into a m ajor subclass called s im p le -re s o u rc e m eaning they are only m a nipulated in tasks (Figure 3.11). These subclasses include s o ftw a re , h ard w are, etc! In Figure 3.11, two instances of s im p le -re s o u rc e are defined. T o o ls do not represent an independent class in th e A rticulator m eta-m odel. II is, rather, a usage concept. Therefore, any resource can be used as tools in tasks Currently, the only m eaningful a ttrib u te for tools is attrib u te p h y s ic a l- p a th whicli points to th e physical location of a software tool in a com puter’s file system . W hen this software tool is accesses, its physical code will be invoked as an independent! com puting processor. 55 3.4 Summary In this chapter, th e A rticulator m eta-m odel was presented. Such a knowledge-basec m odel was built to subjugate th e com plexity of understanding th e software process and its related workplace. This provides a framework to observe and study SPMs and process articulation which is norm ally em bedded in SPM enactm ent. A lthough the A rticulator m eta-m odel can be used to describe a wide range of software processes as to be shown in the next chapter, it is impossible for it to cover all different kinds; of software processes and other forms of organizational processes. Besides, it is by no m eans th a t th e developm ent of the A rticulator m eta-m odel is com pleted. On the contrary, th e A rticulator m eta-m odel has been and will be evolving as our knowledge of th e software process grows. To this end, a system atic approach to introduce new object classes and relations will be useful to insure th e consistency and correctness of the A rticulator m eta-m odel. T he A rticulator m eta-m odel has been im plem ented in a LISP-based expert sys tem developm ent environm ent called Knowledge-Craft (KC) [12]. Its basic objeci classes are organized into an IS-A object hierarchy as shown in Figure 3.1. By defin ing th e class re s o u r c e as th e root of IS-A hierarchy, it im plies th a t every objec class in th e A rticulator m eta-m odel is a class of re s o u r c e and can be treated either as a required-resource or a provided-resource in an SPM. For exam ple, it is possible for an SPM to introduce an agent to the system , or creates another an SPM as its provi ded- resource. Using the A rticulator m eta-m odel, SPM s can be constructed and subsequently analyzed before SPM enactm ent. T he rem ainder of th e dissertation focuses on static and dynam ic analysis of SPM s, whose purpose is to ensure use of proper SPMs during enactm ent. 56 Chapter 4 Construction and Static Analysis of SPMs T he A rticulator m eta-m odel discussed in the previous chapter provides an object- oriented language to specify SPMs in term s of a set of basic object classes, relations' and constructs. In this chapter, two initial stages in software process m odeling are described, as are associated autom ated support provided by th e A rticulator. T he first stage is construction of SPMs th a t defines custom ized SPM s in th e A rticulator m eta-m odel. In th e A rticulator, an SPM definition m ethodology supports construc tion of SPM s through guidance on knowledge acquisition and autom aton on process description. T he second stage is static analysis of SPM s th a t identifies and corrects errors in defined SPM s. In th e A rticulator, static analysis of SPM s is used to detecJ syntactic and sem antic errors. They also identify necessary inform ation th a t users forget to specify in SPMs. 4.1 Introduction The purposes of SPM construction and static analysis are to collect em pirical knowl edge about a software process, and to formalize it into a syntactically and sem anti cally correct SPM according to the A rticulator m eta-m odel. H um phrey [38] indicates th e im portance of SPM construction as follows: Software developm ent can be exceedingly complex and there are often m any alternative ways to perform the various tasks. A defined process can help guide the software professionals through these choices in an or derly way. W ith an established process definition they can b ette r under stand w hat they should do, w hat they can expect from their co-workers, 57 and w hat they are expected to provide in return. This allows th em to focus on doing their jobs. A defined software process also provides organi zations w ith a consistent working framework while p erm itting individual adjustm ent to unique needs (C hapter 13, Page 247). C onstruction of SPM s in th e A rticulator m eta-m odel consists of abstracting the necessary inform ation, grouping it according to th e defined object classes, and rep resenting it as an extended m odel of th e A rticulator m eta-m odel. To a large e x te n t, construction of SPM s is a knowledge acquisition process. Users m ust form ally rep resent knowledge of software processes in a well-defined form of object classes anc relations. To help users build custom ized SPMs, an SPM definition m ethodology is; needed, as are autom ated support mechanisms. Such a m ethodology helps users in two ways: It guides knowledge acquisition of a software process, and autom ates the m echanical translation of an inform al specification into a form al SPM representation Once an SPM is defined, users are interested in knowing if th e definition is correct As far as th e representation of inform ation is concerned, th e correctness of an SPM ^ is often viewed in term s of the syntactic and sem antic consistency and completeness At th e same tim e, users are interested in viewing an SPM from different perspec tives. In the A rticulator, interest of correctness checking and process visualization is served by static analysis of SPM s, which includes four types of analysis: (1) syntacj tic checking identifies gram m atical errors th a t violate th e A rticulator m eta-m odel syntax; (2) sem antic checking identifies sem antic errors th a t violate the A rticulator m eta-m odel semantics; (3) process visualization displays different perspective of a i l SPM based on different object classes defined in it using tex tu al or graphic display forms; and (4) process query allows users to query process inform ation defined in th e A rticulator through pre-defined queries. C onstruction and static analysis of SPMs can now be described. 4.2 An SPM Definition Methodology C onstruction builds an SPM for a software process. It is a knowledge acquisition process involving two aspects: first, understanding and gathering knowledge about *1 will not define a formal notion of correctness, but rather use it as a notion of common sense. 58 th e software process; and second, representing the knowledge as a form al m odel o: the A rticulator m eta-m odel. During th e past few years, several SPMs were built and these SPM s are presented in the next chapter. Based on these experiences ir SPM construction, a prelim inary SPM definition m ethodology can be establishes which identifies the necessary stages and provides guidance as well as support for construction of SPMs. 2 This SPM definition m ethodology focuses on two types of assistance according to th e n atu re of SPM construction. T he first focus is on guidance to knowledge acquij sition. U nderstanding is the key to SPM construction. W ithout good knowledge, it is im possible to define a good SPM . U nfortunately, knowledge of a software process is often spread across th e m inds of m any dom ain experts and m anagers. Therefore, it is crucial to interact w ith these experts and explore their respective knowledge as m uch as possible. In this regard, th e SPM definition m ethodology guides SPM con struction for w hat kinds of knowledge to capture as well as where and how to collec them . T he second focus of this m ethodology is on autom ated support for process specification. O nce knowledge of the process is collected, it can be represented in a form al SPM . This stage is m ostly a m echanical translation. Therefore, th e SPM definition m ethodology emphasizes autom ated tools th a t im plem ent th e translation to simplify th e work. To specify an SPM , users utilize a spread-sheet-like process editing tool, which does not require knowledge of th e form al definition language o: th e A rticulator m eta-m odel. T he SPM definition m ethodology views construction of SPM s in three steps: Step 1, process understanding studies and understands the software process to be modeled] Step 2, inform al representation records knowledge of the process in different types of object models and th e relations between them . Step 3, form al representation codifies th e inform al description in th e A rticulator m eta-m odel. The first two steps are knowledge acquisition and interact w ith each other. T he last step is translation] and it is executed by a process editing tool. N ext, these three steps will be presented in detail. 2Eventually, this methodology will be summarized into an SPM too. 59 What Kinds of Knowledge Where to Find Knowledge How to Gather Knowledge Object Models: - An Activity Hierarchy, - An Artifact Model, - An Agent Model, - A Tool Model; Object Relations: - Resource Consumption Relation, - Resource Production Relation, - Agent Performance Relation, - Tool Invocation Relation. Documents: - Development Plan, - Product Document, - Organization Document; Experts: - Organization Executive, - Project Manager, - Software Engineer, - Process Engineer. Read Documents; Observe Development; Interview Experts; Experiment with System; Group Discussion; Examine Tasks, Data, and Artifact Models; Identify Problems; Iterate Above. Table 4.1: G uidance in Process U nderstanding 4 .2 .1 P r o c e ss U n d ersta n d in g To help the understanding and collection of process knowledge, th e SPM definition m ethodology provides guidelines during the process understanding step. T he guid ance is directed tow ard th e kinds of knowledge to collect, w here to collect them , and how to collect them . In this section, the guidance for process understanding is detailed. As observed in the previous chapter, the A rticulator m eta-m odel describes an SPM in term s of an activity hierarchy and resource specification. It consists of a J activity hierarchy, a product model, an agent m odel, and a tool model. Equally im-j p o rtan t, th e A rticulator m eta-m odel identifies several kinds of relationships between these object m odels, such as resource production and consum ption. Furtherm ore, a J object m odel consists of a set of objects w ith decom position, interaction, and a set] of statu s values. A relation between two object models consists of type, cardinality] and inheritance constraints both on the dom ain and the range of the relation. T he stru ctu re of these object models and relationships are th e kinds of knowledge thafJ constitute an SPM and, therefore, are the exact knowledge to be collected during, process understanding. The kinds of object models and relations are listed in Ta ble 4.1, while th e detailed definition can be found in th e A rticulator m eta-m odel itself. Knowledge of process exists generally in two places: T here m ay be docum ents in th e organization th a t narratively describe a software process and th e other related resources. These docum ents represent official views of th e process. A nother source of process knowledge is from those people who actually design, control, a n d /o r perform 60 th e process. T heir experiences represent the actual process, b u t this m ay sometimes violate th e official view. It is the responsibility of th e user to determ ine the type o: th e process (official or actual) to m odel, and to integrate both views when necessary. A developm ent organization generally has a software developm ent plan th a t de scribes th e activity hierarchy for the process, a product docum ent th a t describes its product structure, and an organizational docum ent th a t specifies its organizational hierarchy and lines of com m ands. From these docum ents, prelim inary models of pro cess activities, product, and agents can be derived. On th e other hand, experts in the organization have hand-on experience and knowledge about th e process. High-level executives and project m anagers have good knowledge about th eir organizational stru ctu re and high-level description of the process. Process engineers are the people who actually w rite th e developm ent plan and know a lot about th e activity hier archy. P roject m anagers and software engineers are th e perform ers of th e process. T heir experiences are very helpful in the insight of th e process. Table 4.1 gives a list of th e sources of process knowledge. Experience w ith process understanding indicates th a t it is relatively hard to collect a tool m odel for two reasons: First, specification of tools norm ally is not included in any developm ent docum ent. Com panies m ay give their engineers th J freedom in choosing th e tools they prefer. Second, m any different tools exist for a particular task. It is especially tru e in software engineering com m unity. As a result, th e tool m odel and th e tool relations can be om itted in a prelim inary SPM , b u t be added when tool invocation becomes crucial to software developm ent. Given the kinds of process knowledge and where they are, users need to collect them in order to define an SPM . T he collection of process knowledge takes several forms. Since p art of process knowledge is docum ented, reading docum ents becomes an entry point to knowledge acquisition. Reading is very im portant because other people are generally too busy to teach you th e basics about a software process. It is through reading th a t users build a sketch of process knowledge and necessaryj vocabulary to talk about th e process. Then, users can either observe th e actual! process perform ance, interview w ith knowledgeable experts, or even experiment th e process in a controlled setting. Through these practices, users should be able toj collect actual process knowledge th a t exist only in the m inds of the experts. 61 4 .2 .2 In fo rm a l R e p r e se n ta tio n This m ethodology initially uses an informal representation to docum ent th e collectec process knowledge in a spread-sheet-like form at and to aid in its initial analysis for consistency and com pleteness. In this way, inform al representation should help w ith process understanding in a progressive and iterative fashion. As a result, whenever J new knowledge is collected, it should be docum ented. O n the other hand, wheneverj a problem is identified through studying the inform al representation, a new phase of process understanding is initiated. At early stages, users can use any form at to w rite down prelim inary object m od els. However, the final outp u t of this stage should be docum ented in a predefined form at. This form at contains basic inform ation about the object models and the relations, and will be used to generate an initial SPM in the form al representa tion stage. Table 4.2 shows th e predefined form at for th e activity hierarchy and its relations w ith th e agent, product, and tool models. It defines an SPM called P r o g r a m m i n g , which describes a simple process to create two source files, compile and debug them until it is correctly im plem ented. This sim ple SPM exam ple will: be used throughout th e chapter to present th e static analysis functions. In this for-J m at, L e v e l represents th e level of decom position for a subtask. T y p e indicates th e type of a subtask, such as TC represents T a s k - C h a i n and A represents a c t i v i t y . 3j Nam e defines th e nam e of a subtask and P r e d e c e s s o r gives a list of its predecessor subtasks. All th e other columns specify the relations to agent, required-resource, provided-resource, and tool models. Note th a t this form at includes only the very basic inform ation needed to generate an SPM , w ithout asking for other detailed in form ation. O ther detailed inform ation will be used to fill in values after an SPM is’ generated. Once th e spread-sheets are created for all object models and relations, they should be taken to th e experts to be evaluated. If any questions are raised or problem s are identified, users should go through process understanding to clarify or correct th e problems. 3IB and IE represent the beginning and end of an iterative enactment. CB and CE represent the beginning and end of a conditional enactment. 62 Level Type Name Predecessor Agent Required Provided Tool 0 TC Programming 1 A Create-Main Engineer main.c emacs 1 A Create-sub Engineer sub.c emacs 1 1 A IB Create-Make Loop-Begin Create-Main Create-Sub Create-Make Engineer QA-Engineer makefile emacs 1 A Compile Loop-Begin QA-Engineer main.c sub.c makefile main.o sub.o myprog make 1 1 A CB Debug Branch-Begin Compile Debug QA-Engineer Engineer myprog errors dbx 1 A Modify-Main Branch-Begin Engineer main.c main.c emacs 1 A Modify-Sub Branch-Begin Engineer sub.c sub.c emacs 1 A Modify-Make Branch-Begin Engineer makefile makefile emacs 1 CE Branch-End Branch-Begin Modify-Main Modify-Sub Modify-Make Branch-Begin QA-Engineer 1 IE Loop-End Loop-Begin Branch-End Engineer Table 4.2: A Simple Form at for Inform al R epresentation 4 .2 .3 F orm al R e p r e se n ta tio n A fter th e inform al representation is final validated, it is tim e to generate an SPh' in th e A rticulator m eta-m odel. This is done in th e A rticulator by an autom ated process translator. It reads th e defined spread-sheet as a tex t file in the format! shown in Table 4.2. Then it create either a set of objects in th e A rticulator, or a set of KC language constructors th a t defines th e SPM . In case there is other related inform ation, users can either issue th e KC com m ands or edit th e language file to fill necessary values. 4.3 Static Analysis of SPMs S tatic analysis of SPM s is perform ed after an SPM is created. Its purpose is to correct possible errors in th e SPM . As identified earlier, there are four types of static analysis in th e A rticulator: F irst, syntactic checking identifies gram m atical errors th a t are in violation of th e A rticulator m eta-m odel syntax; Second, sem antic checking identifies errors th a t violate the A rticulator m eta-m odel sem antics; Third] 63 Syntactic Checking for PROGRAMMING: I n s u b t a s k PROGRAMMING: n o e r r o r i d e n t i f i e d . I n s u b t a s k LO O P -EN D : n o e r r o r i d e n t i f i e d . I n s u b t a s k BRAN CH-END: n o e r r o r i d e n t i f i e d . I n s u b t a s k MODIFY-MAKE: n o e r r o r i d e n t i f i e d . I n s u b t a s k M O D IF Y -S U B : n o e r r o r i d e n t i f i e d . I n s u b t a s k M O D IFY -M A IN : n o e r r o r i d e n t i f i e d . I n s u b t a s k BR A N C H -B EG IN : n o e r r o r i d e n t i f i e d . I n s u b t a s k DEBUG: n o e r r o r i d e n t i f i e d . I n s u b t a s k C O M PILE: n o e r r o r i d e n t i f i e d . I n s u b t a s k L O O P -B E G IN : n o e r r o r i d e n t i f i e d . I n s u b t a s k CREATE-MAKE: n o e r r o r i d e n t i f i e d . I n s u b t a s k C R E A T E-S U B : n o e r r o r i d e n t i f i e d . I n s u b t a s k C R E A TE-M A IN : n o e r r o r i d e n t i f i e d . T o t a l S y n t a c t i c P r o b l e m s : 0 Figure 4.1: A Sam ple Result from Syntactic Checking process visualization displays different perspectives of an SPM based on different object types defined in it in tex tu al or graphic display forms. Finally, process query allows users to query process inform ation defined in th e A rticulator through cannec queries. In this section, static analysis of SPMs is presented. 4 .3 .1 S y n ta c tic C h eck in g Syntactic Checking searches for spelling and gram m atical errors in an SPM . Based on experience, when users follow th e form at defined earlier to define an SPM , the most! frequent errors are misspellings of an object th a t does not have a proper definition w hen referenced. Correcting such misspellings can be very tim e-consum ing and thus there is a need to provide this support by th e user’s requests. Currently, the syntactic checking tool searches for m isspellings in relations and values and points out them together w ith their class inform ation if possible. T he relations being checked in cludes: ta sk -h a s-c o m p o n e n t, ta s k - r e q u ir e - r e s o u r c e , ta s k - p r o v id e - r e s o u r c e , and others. 64 4 .3 .2 S e m a n tic C h eck in g Sem antic Checking identifies a num ber of sem antic errors common in SPM s anc. other possibilities which m ay cause problem s in SPM enactm ent. These sem antic errors identified by this checking tool include: • Illegal precedence relation. T he A rticulator does not allow a subtask to have a successor or predecessor sub task which is not under th e sam e supertask. • Illegal precedence cycle. The A rticulator does not allow a set of consecutive predecessor subtasks to form an iteration. • Illegal iteration and branch pairs. T he A rticulator does not allow to have unm atched iteration and branch pairs. • Isolated subtasks. The A rticulator gives a warning when a non-root subtask is defined w ithout any predecessor and successor subtasks. • Resource w ithout providers or consumers. T he A rticulator gives a warning when a required-resource in a subtask does not have a provider subtask, or a ! consum er subtask. • Incom plete activity inform ation. T he A rticulator gives a warning when an activity does not have inform ation about agents, tools, required-resources, or provided-resources. • Incom plete agent/role inform ation. T he A rticulator gives a w arning when an agent or role does not have inform ation about its assigned subtasks. • Incom plete tool inform ation. T he A rticulator gives a w arning when a tool does not have its assigned subtasks. 4 .3 .3 P r o c e ss V isu a liz a tio n Process visualization displays different process views of a defined SPM . In th e A r ticulator, an SPM consists of different entity models, such as an activity hierarchy, a product m odel, and an agent model, as well as relations am ong these models. It 65 Semantic Checking for PROGRAMMING N o t h i n g f o u n d ! N o t h i n g f o u n d ! N o t h i n g f o u n d ! N o t h i n g f o u n d ! N o t h i n g f o u n d ! I l l e g a l P r e c e d e n c e R e l a t i o n : I l l e g a l P r e c e d e n c e C y c l e : I l l e g a l I t e r a t i o n a n d B r a n c h P a i r s : I s o l a t e d S u b t a s k s : R e s o u r c e s w i t h o u t P r o d u c e r A c t i v i t i e s : R e s o u r c e s w i t h o u t C o n s u m e r A c t i v i t i e s : ERR O R S, S U B . 0 , M A IN .O I n c o m p l e t e A c t i v i t y I n f o r m a t i o n : CREATE-M AIN d o e s n o t h a v e r e q u i r e d - r e s o u r c e C REA TE-SU B d o e s n o t h a v e r e q u i r e d - r e s o u r c e CREATE-MAKE d o e s n o t h a v e r e q u i r e d - r e s o u r c e I n c o m p l e t e A g e n t / R o l e I n f o r m a t i o n : N o t h i n g f o u n d ! I n c o m p l e t e T o o l I n f o r m a t i o n : N o t h i n g f o u n d ! T o t a l S e m a n t i c P r o b l e m s : 6 Figure 4.2: A Sam ple Result from Sem antic Checking is very hard to look at these models and relations at th e sam e tim e. B ut very often users are interested in seeing some aspects of an SPM . For exam ple, an executive m ay only be interested in product progress, while a developer m ay be interested in only th e activities he/she has to be involved. Yet, a m anger m ust be concerned w ith the resource requirem ents and consum ption during SPM enactm ent. Several visualization tools have been im plem ented to display different aspects of an SPM: • Task display o utputs task decom position of an SPM , i.e., its activity hierar chy. O ther inform ation, such as agents and products can be attached to the hierarchy. T here are two forms of task display: the graphic form is shown in Figure 4.3; th e tex tu al form is shown in Figure 4.4. • Task precedence display outputs task execution order of a level of decom po sition of an SPM . O ther inform ation, such as agents and products can be attached to the hierarchy. Figure 4.5 shows th e task precedence graph for the program m ing process. • Agent display o utputs agent decom position of an SPM , i.e., its organizational hierarchy. O ther inform ation, such as tasks and products can be attached to th e hierarchy as shown in Figure 4.6 66 HJ Process Overview 1 3 ) £ 3 K Q u L X ~ t 3 f e 3 i E | j debug_loop_end| programming debug_.br anch_end modif y_make-Fi le modify_sub | modi-Fy_main| debug_.br anch_beg i n | debug compile debug_1oop_beg i n create_make*File create_sub create_main Figure 4.3: Task Decom position G raph for Program m ing • P roduct display outputs product production and consum ption of an SPM th a t is, products th a t are produced and consumed by subtasks. O ther infor m ation, such as agents and tools can be attached to the hierarchy as shown in Figure 4.7. • S tatistical inform ation display outputs statistics about an SPM , which in cludes: (1) th e num bers of tasks, activities, iterations, conditionals; (2) the level of decom position; (3) for tasks, m axim um , m inim um , and average num-J bers of th eir com ponent subtasks; (4) for activities, m axim um , m inim um , and average num bers of their predecessors, successors, required-resources, provided] resources, agents, and tools. An exam ple of statistical inform ation is shown in Figure 4.8. 67 SUBTASK AGENT REQUIRED-RESOURCE PROVIDED-RESOURCE PROGRAMMING CREATE-MAKE ENGINEER MAKEFILE CREATE-SUB ENGINEER SUB.C CREATE-MAIN ENGINEER MAIN.C LOOP-BEGIN QA-ENGINEER COMPILE QA-ENGINEER MAKEFILE MYPROG SUB.C SUB. 0 MAIN.C MAIN.0 DEBUG QA-ENGINEER MYPROG ERRORS BRANCH-BEGIN ENGINEER MODIFY-MAKE ENGINEER MAKEFILE MAKEFILE MODIFY-SUB ENGINEER SUB.C SUB.C MODIFY-MAIN ENGINEER MAIN.C MAIN.C BRANCH-END QA-ENGINEER LOOP-END ENGINEER Figure 4.4: Task Decom position Table for Program m ing p bi _______________ T A S K W IN D O W i p r o g r a m m i n g Developers m a r y_____ Develop"") | Detail | [ReadyActional [ History j |Hx3torjjReplay^ [ Info | | FiniaiT") | Mode | | Quit (Reduce) {Enlarge) |EnlargeHSpace| jEnlargeVSpace] (ReduceHSpi T a sk . L is t [Select] Hovel |l debug_1□ap_end 12debue^branch_and Hone ^ Done Active ^ Broken Reedy Stopped I j j j p l Allocated Ualt Resources ^ Not Chosen Assigned to other developer j3 modlfy_makgfHe 4 modify_sub [5 modifM.maln | f i debug„brarich_begii 7 debug B c o m p ile |9 debug—Aoop^-begin jlO create_makefiie 11 create.sub 12 create.maln Figure 4.5: Task Precedence Graph for Programming 68 Agent/Role Information for PROGRAMMING A g e n t / R o l e A s s i g n e d A c t i v i t y R e q u i r e d - R e s o u r c e R e q u i r e d - R e s o u r c e E N G IN E E R L O O P-E N D M ODIFY-M AKE M O D IFY -SU B M O D IFY -M A IN B R A N C H -B E G IN CREATE-M AKE C R E A T E -S U B C R E A T E-M A IN Q A -E N G IN E E R BRANCH-END DEBUG C O M PIL E L O O P -B E G IN M A K E FIL E S U B .C M A IN .C ERRORS M A K EFILE S U B .C M A IN .C M A K E FIL E S U B .C M A IN .C M A K E FIL E S U B .C M A IN .C MYPROG MYPROG S U B . 0 M A IN .Q Figure 4.6: A gent/R ole Inform ation for Program m ing R e s o u r c e U s a g e f o r PROGRAMMING R e s o u r c e P r o v i d e r A c t i v i t y C o n s u m e r A c t i v i t y MYPROG C O M PIL E DEBUG S U B . 0 C O M PIL E M A IN . 0 C O M PIL E ERRORS DEBUG M A IN .C M O D IFY -M A IN M O D IFY -M A IN C R E A T E-M A IN C O M PIL E S U B .C M O D IFY -SU B M O D IFY -SU B C R E A T E -S U B C O M PIL E M A K E FIL E M ODIFY-M AKE M ODIFY-M AKE CREATE-M AKE C O M PILE Figure 4.7: Resource Production Information for Programming Statistical Information for PROGRAMMING P a r t I . S u b t a s k s N u m b e r o f T a s k s : 1 N u m b e r o f A c t i v i t i e s : 8 N u m b e r o f I t e r a t i o n s : 1 N u m b e r o f C o n d i t i o n a l s : i T o t a l N u m b e r o f S u b t a s k s : 1 3 P a r t I I . T a s k S t r u c t u r e M ax N u m b e r o f D e c o m p o s i t i o n L e v e l s : N u m b e r o f T a s k s w i t h o u t C o m p o n e n t s : 2 0 F o r e a c h S u b t a s k : T y p e C o m p o n e n t P r e d e c e s s o r S u c c e s s o r M ax N u m b e r M in N u m b e r A v e r a g e N u m b e r 12 4 4 12 0 0 12.00 1 . 0 8 1 . 0 8 P a r t I I I . R e s o u r c e I n f o r m a t i o n N u m b e r o f A g e n t s a n d R o l e s : 2 N u m b e r o f D e v e l o p m e n t T o o l s : 3 N u m b e r o f R e q u i r e d R e s o u r c e s : 4 N u m b e r o f P r o v i d e d R e s o u r c e s : 7 F o r e a c h A c t i v i t y : T y p e A g e n t T o o l R e q u i r e d - R e s o u r c e P r o v i d e d - R e s o u r c e M ax N u m b e r M in N u m b e r A v e r a g e N u m b e r 1 1 1.00 1 1 1.00 3 0 0 . 8 7 3 1 1 . 2 5 P a r t I V . I n c o m p l e t e I n f o r m a t i o n NUMBER OF SU B TA SK S W ITH R E SO U R C ES: N u m b e r o f S u b t a s k s w i t h o u t A g e n t s : 0 N u m b e r o f S u b t a s k s w i t h o u t T o o l s : 0 N u m b e r o f S u b t a s k s w i t h o u t R e q u i r e d - R e s o u r c e s : 3 N u m b e r o f S u b t a s k s w i t h o u t P r o v i d e d - R e s o u r c e s : 0 Figure 4.8: A Sample Result from Statistical Checking 70 4 .3 .4 P r o c e ss Q u ery T he query m echanism accepts user queries to retrieve inform ation from the the A rticulator m eta-m odel, SPM s and other object instances. T he query functions are Prolog rules built in a bottom -up fashion. A set o: atom ic functions, im plem ented as forward-chaining rules, are used to get very basic inform ation about a ttrib u tes and relations. They are atom ic because they only re-| trieve attrib u tes and relations. Such a set of rules is used to find out if a designated relation exists between two objects. Higher level functions involve th e knowledge representation and provide inform ation about th e representation. Users are encour-j aged to develop th eir own queries using the facilities we provide. T he m ain concerr of the query m echanism is to provide a set of functionally-com plete basic facilities. T here are four types of queries supported in the query m echanism: m eta-knowledge queries, inform ation queries, history queries and w hat-if queries. A meta-knowledge query provides th e definition of an en tity and its related ter minology in th e A rticulator. It is based on th e inform ation given when an object is defined, which is stored as m eta knowledge. An exam ple definition of m eta knowl-j edge appears in Figure 4.9. This function is intended to help new users to understand th e A rticulator m eta-m odel. Users can also provide their own m eta-knowledge for models they define, in order to help guide other users’ interactions w ith a given model. A m et a-knowledge query is in form of q-WHAT. For exam ple, Figure 4.9 also lists a m eta-knowledge query about an organization called com pany F. An inform ation query provides inform ation about either a state of a software process m odel or th e m odel itself. It is generally concerned w ith resource values and configurations. Typical questions answered include “Is P eter a m em ber of Team-j A at tim e 1?” “W hat are the relations linking P eter and M ary now?” etc. An inform ation query has several basic functions for this kind of deductive retrieval. For exam ple, q - i s checks the existence of an entity in th e status, and q - r e l a t i o n finds' th e relations which link two given entities. Through th e use of an inform ation query] every value and every relation w ithin a state can be retrieved w ithout difficulty. More com plicated queries have been im plem ented as exam ples of query build ing using these basic functions. For exam ple, q - s u c c e s s o r and q - p re d e c e s s o r are used to find successor and predecessor subtasks of a given subtask along th e relation 71 ; Definition of meta-knowledge schema with definitions for explanation. { { Meta-knowledge l s - a : definition: unit: literature-available: SCHEMA [annotation for its definition] [unit of processing] [reference]}} ;; Definition of meta knowledge for RESOURCE { {Meta-resource unit: literature-available: l s - a : definition: META-KNOWLEDGE “RESOURCE is the basic entity in KB. It provides basic descriptions about entities in the meta-model. Every object must be a class of RESOURCE or an instance of RESOURCE.” NA m i90}} (attach-meta-schema ’RESOURCE ’Meta-resource) ;; Meta-knowledge query - W HAT question: ((q-WHAT 7ENTITY 7DEFINITION) < (:RELATED 7ENTITY IS-A RESOURCE) (BIND 7DEFINITION (GET-VALUE (GET-META-SCHEMA 7ENTITY) ’DEFINITION)) •) ((q-WHAT 7ENTITY 7DEFINITION) < (= 7DEFINITION ’ ’There is no such an entity in KB”) ! fail) ;; Example of use of W HAT question: what is Company-F? (q-WHAT Company-F 7DEFINITION) “Company-F is a software vendor. It develops software on SUN systems. Currently it has three members: Mary, Joe and Peter.” Figure 4.9: M et a-knowledge and Its Queries 72 ta s k - h a s - s u c c e s s o r . These two queries are utilized by users to check th e configu ration of th e tasks they perform . They are im plem ented by the q - r e l a t i o n query using ta s k - h a s - s u c c e s s o r as th e given relation. A nother exam ple is to get all com ponent m odules of a given software project, im plem ented as q - s o f t - c o n f ig u ra tio n . M any such queries w ith specific requirem ents can be built in the sam e m anner. In Figure 4.10, we provide some inform ation queries about our sim ple m odel of Com pany F. A history query traverses a trajecto ry of states created by an SPM sim ulation (to be discussed later), collects a record of changes on specified entities, th en sum m arizes th em to give clear and condensed inform ation about these changes. Typical infor m ation provided in history queries includes the activities perform ed by the agents in th e sim ulation period and th e resources consumed or produced by agents or team s. O ther specific queries m ay ask about th e consequence of a particular subtask, a' value change, or an inserted relation. Im plem entation of th e history query is based on inform ation queries and the instantiation m anager. T he form er provides facilities to retrieve inform ation w ithin a state, while the la tte r gives th e capability to traverse w ithin the state trajectory. Also, a history query has a facility to sum up gathered inform ation. A w hat-if query includes a com bination of sim ulation and history queries. It starts from a given state, or a m odification of a state in the m iddle of a sequence trajectory, and calls th e behavior sim ulator to sim ulate the given u pdated scenario. W hen th e sim ulation is done, a history query is activated to gather required inform ation. W hat-if queries are designed to facilitate the hypothesis testing scenarios and process articulation. 4.4 Summary This chapter addresses issues in supporting construction and static analysis of SPMs. In th e A rticulator, th e construction of SPMs is supported by an SPM definition m ethodology and static analysis of SPMs. In the first half of th e chapter, an SPM definition m ethodology was discussed which guides th e abstraction and construction of custom ized SPM s in the A rticulator m eta-m odel. T he em phasis of this m ethod ology is p u t on the acquisition of process knowledge while autom ating m echanical 73 aspects of process translation. Following the methodology, users are able to formally specify th eir own software processes. T he second half of this chapter presented static analysis of SPM s th a t searches for syntactic and sem antic errors as well as visualize and query inform ation in defined SPM s. T he static analysis of SPM s provides m ea surem ents about different aspects of SPM s, such as consistency and com pleteness o ‘ an SPM . To illustrate use of the SPM definition m ethodology and static analysis of SPMs three exam ple SPMs are described in the next chapter. This will dem onstrate how th e A rticulator m eta-m odel, th e SPM definition m ethodology, and static analysis of SPMs work together in practice. A fter presenting these th ree exam ple SPMsj discussion will shift to dynam ic analysis of SPMs. 74 Chapter 5 Case Studies: Building Software Process Models SPMs b u ilt using th e A rticulator m eta-m odel describe software processes th a t are perform ed everyday in software developm ent. T he power of the A rticulator meta-J m odel lies on its ability to describe a wide range of real software processes. This chapter introduces a set of case studies th a t build three exam ple SPMs according to the SPM definition m ethodology discussed in th e previous chapter. T he SPMsj m odel a diverse set of software processes: a com m ercial large-scale software pro cess, a software developm ent associated w ith a particular developm ent approach and corresponding tool set, and an experim ental process m odel th a t addresses current research issues. In addition, the static analysis of these SPMs is also presented. 5.1 Introduction Establishing a m odel of a software process is m ade possible by the A rticulator m eta m odel. To evaluate the power of the A rticulator m eta-m odel, a num ber of diverse SPM s were defined in th e past few years. In the case studies th a t follow, three rep resentative exam ple SPM s th a t dem onstrate various capabilities of th e A rticulator m eta-m odel are presented as well as their static analysis. T he first exam ple, th e N orthrop process m odel (N orthrop-PM ), describes a com m ercial large-scale software process. It involves several hundred developers orga nized into a large developm ent project. One purpose for m odeling the N orthrop software process is to evaluate th e A rticulator m eta-m odel’s ability to describe large-scale, real-world processes. T he focus is on specifying a com plete flow of de velopm ent activities and resource production, as these are the issues of greatest 75 interest to th eir project m anagers. T he second exam ple, T he SO FTM A N process m odel (SO FTM A N -PM ), represents an effort to m odel an SPM associated w ith a life-cycle-based developm ent approach and a corresponding set of developm ent tools. Com pared to th e N orthrop-PM , the SO FTM A N -PM focuses on m ulti-level decom position of developm ent activities and the association between developm ent activities and developm ent tools. Upon finishing the SO FTM A N -PM , this m odel isj used as input to a PSE E th a t supports software developm ent through enactm ent of th e SO FTM A N -PM . T he last exam ple, the Develop-Change-and-Test-U nit process m odel, deals w ith th e research topics th a t are of interest in the software process research com m unity. In fact, the exam ple itself was first created by th e organizing! com m ittee of th e 6th International Software Process W orkshop (1990). T he purpose of creating this SPM therefore focuses on answering questions raised in th e 1990- 1991 International Software Process W orkshops. As such, in th e following sections, these SPM s are explained in detail. T he chapter concludes w ith a discussion of the lessons learned in these case studies and potential enhancem ent to th e A rticulator process m odeling effort are pointed out. 5.2 The Northrop Process T he first case study involved building an SPM for corporate-level software develop m ent at th e B2 Division of N orthrop C orporation in Pico Rivera, California. It was created at th e request of, and in cooperation w ith engineers at N orthrop. 5.2.1 M o d e lin g S tep s M ost com panies th a t build large software system s organize th eir developm ent projects according to guidelines described in internal com pany docum ents. This study of th e developm ent process at N orthrop is representative in this regard. The N orthrop-PM is intended to describe current developm ent practice at th e B2 Divi sion as described in a series of narrative docum ents th a t prescribe th eir developm ent guidelines [42, 41, 43, 44]. The m ain docum ent is the C om puter Program Develop m ent P lan (C P D P ) th a t lays an overall stru ctu re for developers to follow. Therefore, 76 we started by reading and understanding these docum ents m ade available to us by N orthrop. An initial N orthrop process description was created after reviewing th e docu m ents. Several rounds of interview s w ith N orthrop personnel were then conducted to m odify th e N orthrop process description until engineers at N orthrop were sat isfied w ith its accuracy and completeness. D uring this period, m any changes were m ade in term s of both activity hierarchy and resource requirem ents. T hen, th e final N orthrop process description was codified as objects in the A r ticulator m eta-m odel and tested for its com pleteness and integrity. Static analysis of the SPM perform ed later resulted in some very interesting insights as to th e ef fectiveness of th e narrative guidelines for software engineering practice at N orthrop, some of which will be m entioned later in this section. Currently, we are continuing this direction of work w ith engineers at N orthrop. T he purpose of th e current project is to create and evolve an SPM th a t describes an process for future software developm ent practice at N orthrop. 5 .2 .2 T h e N o rth r o p P r o c e ss M o d e l T he N orthrop-PM consists of an activity hierarchy w ith four levels of decom position and resource requirem ents for resources and roles. Figure 5.1 displays th e task decom position graph for the N orthrop-PM . T he top- level (or Level 1) task is th e N orthrop-PM , which is th e root of all th e objects defined in th e SPM . Subtasks at Level 2 represent m ajor stages of developm ent, such as re quirem ents definition, design, and integration. Their execution order is sequential which corresponds to the classic W aterfall software life-cycle m odel according to CPD P. Each developm ent stage is divided respectively into a set of subtasks. C ur rently, subtasks at this level (Level-3) represent specific developm ent activities, and each activity is described by a separate developm ent docum ent. For exam ple, [41] is for integration test. F urther task decom position is possible if necessary, b u t such work was transferred to engineers at N orthrop. As of July, 1992, there are about th irty engineers at N orthrop who continue to expand th e N orthrop-PM . Resource requirem ents in the N orthrop-PM have two separate parts: Roles rep resent classes of developm ent agents who are responsible to perform some of the 77 Setup-Project Northrop Model ---------- »i Requi ement—Definition >, Desigi. Preliminary-Desi^n ---------- >i Detailed-Design Code-, ,nd-Unit-Test Form; 1-Test ----- »i Intec r-*- ration m --------- Analyze-System-Reqs Formulate-Requirements Decompose-Software-Reqs Build-and-Execute-System-ModeIs As se s s-Re qui rement-Tracebility Evaluate-Testability CP-Requlrements-Review # Task □ Action n conditional X j branch Successor — Component Figure 5.1: Northrop Process: A ctivity Hierarchy 78 subtasks. C urrently, there are seventeen role classes in th e N orthrop-PM . M ost of th em are linked to subtasks. A subtask m ay require several classes of roles to exe cute it. In th e N orthrop-PM , m ajor classes of resources include: docum ent, software, and hardw are. We also tried to identify developm ent tools, though unsuccessfully. T he reason is th a t their developm ent docum ents sim ply do not have such inform a tion. Figure 5.2 lists definition of subtask F o r m u l a t e - R e q s in the N orthrop-PM . In this definition, F o r m u l a t e - R e q s is a com ponent of R e q u i r e m e n t - D e f i n i t i o n , has predecessor A n a l y z e - S y s t e m - R e q s and successors D e c o m p o s e - S o f t w a r e - R e q s and B u i l d - a n d - E x e c u t e - S y s t e m - M o d e l s . It requires a S y s t e m - A n a l y s t as its agent, a S t a t e m e n t - o f - W o r k and a U s e r - S p e c as its in p u t, and produces a P r e l i m i n a r y - S y s / S e g m e n t - S p e c as its output. A fter an initial version of the N orthrop-PM is built, it was statically analyzed as described in th e previous chapter. Some of th e results from static analysis are listed here: Figure 5.3 is a partial o u tp u t from the sem antic check, which tells th a t some resources are defined w ithout activities th a t produce them , while others miss' activities th a t consume them . For exam ple, S ys-D E PE N D E N C Y -R E PO R T is a docu m ent used by activities in the N orthrop-PM . W hile there is not any activities th a t creates th e docum ent. Therefore, th e activities th a t use SYS-DEPENDENCY-REPORT m ay break when its enactm ent starts. As such, it is clear from this analysis th a t th e initial N orthrop-PM is not a com plete SPM. W hat is m issing is inform ation th a t is neither in th e internal guideline docum ents, nor readily accessible or easily recalled by th e participating N orthrop engineers. Figure 5.4 displays two task prece dence graphs for the N orthrop-PM , which shows the prescribed enactm ent orders of some subtasks. Figure 5.5 shows inform ation about production and consum ption for resources. Figure 5.6 lists statistics about subtasks in the N orthrop-PM . 5 .2 .3 L esso n s L earn ed T he following are some observations th a t emerged through construction of th e N orthrop-PM . • Since th e N orthrop-PM is basically a variant of the W aterfall m odel, its activity hierarchy is relatively straightforw ard to build. A t this m om ent, it contains no m ultiple choice and no iteration, m eaning th a t developm ent is suppose to 79 { {Form ulate-R eqs instance: t ask- com ponent-of: task-has-predecessor: task-has-successor: task-has-agent-role-spec: task-has-required-resource-spec: task-has-provided-resource-spec: { {agent-for-form ulate-reqs instance: agent-role-spec-in-task: resource-requirem ent: m axim um -quantity: resource-possession: { {required-for-form ulate-reqs instance: required-resource-spec-in-task: resource-requirem ent: m axim um -quantity: resource-possession: { {provided-for-form ulate-reqs instance: provided-resource-spec-in-task: resource-requirem ent: m axim um -quantity: resource-possession: task-chain Requi rem ent s- D efinition A nalyze-System -R eqs D ecom pose-Softw are-R eqs Build-and-E xecute-System -M odels agent-for-form ulate-reqs required-for-form ulate-reqs provided-for-form ulate-reqs} } agent-role-spec Form ulate- Reqs System -A nalyst 1 none }} required-resource-spec Form ulate- Reqs Statem ent-O f-W ork User-Spec 1 1 none }} provided-resource-spec Form ulate- Reqs P relim inary-Sys/Segm ent-Spec 1 none } } Figure 5.2: Northrop-PM : Definition of F orm u late-R eq s 80 Semantic Checking for Northrop-PM I l l e g a l P r e c e d e n c e R e l a t i o n : N o t h i n g f o u n d ! I l l e g a l P r e c e d e n c e C y c l e : N o t h i n g f o u n d ! I l l e g a l I t e r a t i o n a n d B r a n c h P a i r s : N o t h i n g f o u n d ! I s o l a t e d S u b t a s k s : N o t h i n g f o u n d ! R e s o u r c e s w i t h o u t P r o d u c e r A c t i v i t i e s S Y S -D E P E N D E N C Y -R E P O R T , R F P , C S C I-S O U R C E , R E U S E -O B J E C T , VD D, R E S O U R C E -S P E C R e s o u r c e s w i t h o u t C o n s u m e r A c t i v i t i e s P R O JE C T -S T A T U S -R E P O R T , P E R T -C H A R T , W B S, C H A N G E -IM P A C T -R E P O R T , T R A C T A B IL IT Y -D IS C R E P A N C Y -R E P O R T , C S C I-E X E C U T A B L E , S Y S -Q U A L IT Y -R E P O R T , S D F -D IS C R E P A N C Y -R E P Q R T , C S C -T E S T -P L A N , C S C I- T E S T - P L A N , B A S E L IN E -D IS C R E P A N C Y -R E P O R T , S T A T IC -E V A L U A T IO N -R E P O R T T o t a l S e m a n t i c P r o b l e m s : 1 8 Figure 5.3: P artial Sem antic Checking for N orthrop-PM proceed in a linear m anner. Subsequent refinem ents of this SPM can then identify where choices and iterative tasks are likely to occur. | i I T he execution order of developm ent tasks in Level 2 is sequential, which m eans | a task can’t be started until its predecessor stage is com pleted successfully; This constrained execution order is explicitly stated in th e C P D P in order' to fulfill general developm ent procedures prescribed by U.S. th e D epartm ent of Defense. However, th e order of task execution at lower levels is not so clear at th e beginning. For exam ple, requirem ents definition consists of a set of subtasks, such as analyzing developm ent requests, form ulating formalj requirem ents and decom posing requirem ents, etc. T heir order of execution was defined only after discussion w ith software m anagers at N orthrop. This reflects the difference between an official process view and an actual process i view. ! i I Some holes in th e SPM were identified during th e static analysis of th e | N orthrop-PM as shown in Figure 5.3 and the other figures. T here exist threej types of holes concerning: 1) Necessary inform ation about some subtasks are| TASK WINDOWt mlt_»td_prn Developer* m ary | Oevelop | | Detail | |ReadyActions| | History | |HistoryReplay| | Info | | Finish | | Mode | | Quit | | Task List {Select] |Hove| jReduce) {Enlarge} (EnlargeHSpacej |EnlargeVSpace| ]ReduceHSpace| fReduceVSpace] \2 reqs.definitlon f |3 design p \4 code_and_unittestf f5 fornal_teet I |S Integration f None ^ Active ^ Ready ^ Allocated ^ Ualt Resources ^ Oone Broken ^3%^ Stopped ^ Not Chosen Assigned to other developer: TASK WINDOWt reqs_defint£lon Developer* ntary I Develop | | Detail j [RegdyActions} | History | |HtstoiryReplay| ("'info'"I { Finish | | Mode ~| [ Quit ~] ii aaae98_req_trace«blJitn| ia cp_req9_r«vieu | |3 decDmpo9e_req9 | I4 bu t i d_elm_modeIs | I5 evsluate.teecabilitu 1 I6 anaiijze.reqe | \? formuists.reqa | (Select] |Move] (Reduce} {Enlarge] (EniargeHSpace) |EnlargeVSpace] [ReduceHSpacej ^ None A Done Active Broken Ready Stopped Allocated Not Chosen i falalt Resources Assigned to other deve Figure 5.4: Two Task Precedence Graphs for Northrop-PM R e s o u r c e N am e P R O JE C T -E S T IM A T IO N SR S P r o v i d e r T a s k C o n s u m e r T a s k E S T IM A T E -P R O JE C T S P E C -M G R -IN D IC A T O R ID E N T IF Y -R E U S E -C A N D A S S E S S -B A S E L IN E -T R A C T A B IL IT Y W A LK TH R O U G H -D ETA ILED -D ESIG N A S S E S S -R E Q -T R A C T A B IL IT Y E V A L U A T E -R E Q -F O R -T E S T A B IL IT Y C P -R E Q S -R E V IE W D EC O M PO SE-R EQ S SSDD S S S I CD B U IL D -S IM -M O D E L S ALLOCATE-COM PONENTS B U IL D -S IM -M O D E L S E V A L U A T E -T E S T A B IL IT Y A N A L Y Z E-R E Q S ID E N T IF Y -R E U S E -C A N D A N A L Y Z E-R E Q S P H Y S IC A L -C Q N F IG -A U D IT F U N C T IO N A L -C O N F IG -A U D IT T E S T -R E A D IN E S S -R E V IE W C R IT IC A L -D E S IG N -R E V IE W ID E N T IF Y -R E U S E -C A N D W A L K TH R O U G H -D E T A IL ED -D ESIG N D E C O M PO SE-SY S I D E N T I F Y - C S C I - T E S T S E V A L U A T E -R E Q -F O R -T E S T A B IL IT Y P R E L IM IN A R Y -D E S IG N -R E V IE W W RITE-M ANUAL FO R M U L A T E -D E SIG N C H E C K -R E Q S -F O R -C O N S T -C O M P -R E U S E D EC O M PO SE-R EQ S B U IL D -S IM -M O D E L S I D E N T I F Y - S Y S - T E S T C H E C K -R E Q S -F O R -C O N S T -C O M P -R E U S E D E C O M PO SE-R E Q S B U IL D -S IM -M O D E L S I D E N T I F Y - S Y S - T E S T E V A L U A T E -T E S T A B IL IT Y FO R M U L A T E -D E SIG N ID E N T IF Y -R E U S E -C A N D B U IL D -S IM -M O D E L S FO R M U L A T E -D E SIG N Figure 5.5: P artial Resource Production Inform ation for N orthrop-PM 83' S t a t i s t i c a l I n f o r m a t i o n f o r N o r t h r o p - P M P a r t I . S u b t a s k s N u m b e r o f T a s k s : 7 1 N u m b e r o f A c t i v i t i e s : 0 N u m b e r o f I t e r a t i o n s : 0 N u m b e r o f C o n d i t i o n a l s : 0 T o t a l N u m b e r o f S u b t a s k s : 7 1 P a r t I I . T a s k S t r u c t u r e M ax N u m b e r o f D e c o m p o s i t i o n L e v e l s : 4 N u m b e r o f T a s k s w i t h o u t C o m p o n e n t s : 6 2 F o r e a c h S u b t a s k : T y p e M ax N u m b e r M in N u m b e r A v e r a g e N u m b e r C o m p o n e n t 1 2 0 0 . 9 9 P r e d e c e s s o r 4 0 1 . 0 7 S u c c e s s o r 4 0 1 . 0 7 P a r t I I I . R e s o u r c e I n f o r m a t i o n N u m b e r o f A g e n t s a n d R o l e s : 1 3 N u m b e r o f D e v e l o p m e n t T o o l s : 2 N u m b e r o f R e q u i r e d R e s o u r c e s : 5 7 N u m b e r o f P r o v i d e d R e s o u r c e s : 6 6 F o r e a c h A c t i v i t y : T y p e M ax N u m b e r M in N u m b e r A v e r a g e Ni A g e n t 3 1 1 . 1 5 T o o l 1 0 0 . 0 3 R e q u i r e d - R e s o u r c e 9 1 2 . 8 7 P r o v i d e d - R e s o u r c e 5 0 1 . 8 2 P a r t I V . I n c o m p l e t e I n f o r m a t i o n NUMBER O F SU BTA SK S W ITH R E SO U R C E S: 6 2 N u m b e r o f S u b t a s k s w i t h o u t A g e n t s : 0 N u m b e r o f S u b t a s k s w i t h o u t T o o l s : 6 0 N u m b e r o f S u b t a s k s w i t h o u t R e q u i r e d - R e s o u r c e s : 0 N u m b e r o f S u b t a s k s w i t h o u t P r o v i d e d - R e s o u r c e s : 1 Figure 5.6: Statistical Checking for Northrop-PM not provided in th e docum ent. So their definition is not com plete. 2) Some re sources do not have producer subtasks, these resources are used in some other! subtasks. 3) No developm ent tools are specified in th e docum ents. These^ holes represent incom pleteness in developm ent docum ent for an SPM , w hich m ay m ake lack of proper m anagem ent of a developm ent project problematic! when the SPM is enacted. In fact, m anagers at N orthrop dem onstrated great interest in this kind of analysis and its outcom e. I 1 • T he current N orthrop process m odel is not decom posed into sufficient levels of detail. M ore levels of decom position are needed if th e intention is for SPM s toj provide practical assistance for project m anagem ent. At th e lowest level, each subtask still represents a type of developm ent which is described by a sepa-| rate docum ent. For exam ple, C ritic a l-D e s ig n -R e v ie w is a very im portant' developm ent work in the N orthrop-PM . Its decom position can be a rich set i of subtasks and related resources. Such a decom position will help developers' understand the requirem ents and the procedure of C ritic a l-D e sig n -R e v ie w .' i • Finally, this case study provides us w ith some valuable feedback from industrial practitioners. D uring th e case study, we had m any interaction w ith these practitioners and they had opportunity to learn and use th e A rticulator to build m ore SPM s them selves. As a result, a num ber of suggestion were m ade and later im plem ented. For exam ple, they suggested some of the static analysis tools, which were presented in th e previous chapter. T heir other suggestions are being im plem ented now. At the sam e tim e, we are planning to conduct, training workshops for SPM construction for other projects and divisions at; N orthrop. T he results of static analysis and our com m ents about th e N orthrop-PM were, sum m arized in a series of research reports which are forwarded to N orthrop. Further; jwork is underw ay to fill up the holes and to com plete the current N orthrop process1 m odel. This research will eventually lead to th e construction of a new N o rth ro p , process m odel th a t describes and guides software engineering practices at N o rth ro p ! ■ in 1990s. ! 85 5.3 The SOFTMAN Process T he second case study was to build an SPM for a software developm ent approach em bodied in an SEE called SO FTM A N [13, 14]. C reation of th e SO FTM A N -PM is' p art of an experim ent to support process integration [68] in SEEs. I 5 .3 .1 M o d e lin g S te p s T he SO FTM A N environm ent was the subject of Dr. Choi’s dissertation [13] th at' was developed in th e USC System Factory P roject over th e past three years. T h e1 com prehensive set of life-cycle support mechanisms and tools in SO FTM A N , on the one hand, m akes it a powerful environm ent to carry out large scale software devel opm ent. On the other hand, it can be difficult to learn th e SO FTM A N developm ent approach and to use its tools effectively. Novice users are often confused in choosing! ! th e appropriate tools a t different stages of developm ent. This experim ent there-; fore was aim ed at overcoming these difficulties, and at equipping SO FTM A N w ith' process guidance through an SPM . | T he steps taken to create the SO FTM A N -PM are: i 1. Exam ine basic concepts, functionalities, and tool invocation sequences of , SO FTM A N. 2. Form ally represent th e concepts, functionalities, and tool invocations in an! SPM . ! i The SO FTM A N environm ent is an integrated SEE supporting th e engineering! and reverse engineering of large scale software system s [14], SO FTM A N supports! an increm ental life-cycle developm ent approach, a product m odel for software docu m entation, and a set of structure-oriented tools. By using these, SO FTM A N is able! to support life-cycle developm ent activities, assure th e correctness of software prod-j ucts, as well as reverse software engineering. Figure 5.7 shows th e SO FTM A N userj interface where two activities take place: editing a design specification and viewing! Ln operational requirem ents. Software development guided by S O F T M A N follows an increm ental, tool-based' life-cycle approach, which creates and m anipulates a collection of docum ents fo r’ Soflrntxri moduy print Exit M Processor I Pr 1 nt 1 1 M odu 1 LeFtObJ I R I shtO bJ I H elp 1 1 Seve 1 1 Load I l/honie<i 'o h a p M /e fa d u li|'In tw V ie u 8 2 .6 S o ftin a n /F l 1 e e / 1 d Search Foruard[[Bepkmard | L R e p la o e l| R I1 | L j|Jump 11Undo F o r , Editing Connanda exaeute.cenwand I denanO response <chooc« si annaca < g > poiiun.uBcsdu O por'aT t I ona I Roqilii rsrtnontic For Ed i -t! ng Commends 2. 2 E d 1 1 1 ng Coimnands Required commands For edi -t I ng purposes c o n sists o -F a Fol lowing s e t o f Functions 2.2.x cursor—moveinen't® Functions Requl ree e n ts For the movements oF cursor 2.2.1.1 move th e cursor to the next I Ine 2.2.1.2 novo the cursor to th e previous line 2.2.1.3 move the cursor to the next character 2.2.x.A move the cursor to the previous character 2.2.2 search— fun ction s provide search Functions 2.2.2.X search a s t r |ng Forward 2. 2. 2 .2 search a s t r I rtg backward Figure 5.7: T he O riginal SOFTM AN Environm ent ■requirement analyses (R EQ ), requirem ent specifications (SPC ), designs (DES), irm ' plem entations (IM P), testing (TE ST ) and m aintenance (M A IN T). T he S O F T M A N I product model consists of a collection of software docum entation objects and relations jbetween them . M ore detailed inform ation is also provided so th a t all software objects j jhave a ttrib u tes which characterize their interfaces and interconnections. SO FT M A N . ■requires th a t a skeletal structure of docum ents, called the m o d u le -s tru c tu r e , be ere-: jated before its content, called the m o d u le -c o n te n t, can be created and m aintained; correctly throughout developm ent. We call this a structure-first, content-second' developm ent m ethod. For each developm ent stage, SO FTM A N provides a set of structure-oriented tools, i jWhich are used to create, modify, and m aintain both th e stru ctu re and th e content [ of software docum ent. These tools are m ainly language-directed editors to create, the content of each software life-cycle docum ent and graphical editors to m anip-j ulate docum ent structures. In addition, these tools com m unicate w ith an object m anagem ent subsystem th a t checks th e consistency, com pleteness, and tractab ility constraints on all docum ents so as to assure th eir overall correctness. A fter exam ining these features of th e SO FTM A N developm ent approach, dis cussing these features w ith Dr. Choi, th e author of SO FTM A N , and testing SO FT MAN environm ent, the SO FTM A N process m odel was defined to form ally represent these features. 5 .3 .2 T h e S O F T M A N P r o c e ss M o d el T he SO FTM A N -PM defines developm ent activities, th eir prescribed execution or- der, necessary tools for each developm ent activity (m ultiple tool choices m ay exist), and associated software docum ents required and provided in each activity. Figure 5.8 displays only th e top level activity hierarchy of the SO FTM A N -PM , although there are m ore levels of decom position in th e model. Overall, it follows th e SO FTM A N developm ent approach and the structure-first, content-second constraint. Therefore, from the point of view of developm ent activities, one can see an approach sim ilar to th e W aterfall m odel, i.e., requirem ents, specification, design, im plem entation, and testing. On th e other hand, one can also see th e structure-first and content-second s constraint for each developm ent activity. For exam ple, D S N - M o d u l e - S t r u c t u r e pre cedes D S N - M o d u l e - C o n t e n t and S P C - M o d u l e - S t r u c t u r e precedes S P C - M o d u l e - C o n t e n t . i A nother requirem ent for th e SO FTM A N -PM is th a t it m ust have sufficient lev els of decom position so th a t the lowest level of tasks represents single SO FTM A N itool invocation. T he SO FTM A N -PM consists of up to five levels of decom position. Figure 5.9 lists p art of these lowers levels for some of th e subtasks. Figure 5.10 gives definition for an activity, D esig n -M o d u le-C o n ten t w ithin the SO FTM A N -PM w ith its resource requirem ents of agents, required software doc- juments, provided software docum ents, and a developm ent tool. This is an exam ple of th e lowest level of detail which includes only a single developer, a single tool, and a few developm ent objects. Subsequently, th e SO FTM A N -PM was p o rtted into a process-based user inter face called P B I [68]. This integrates the SO FTM A N -PM , th e SO FTM A N prod uct m odel, and the SO FTM A N tool set. T he result of this integration forms REQ mod s t r u c t REQ mod co n t m o d if y_m od_coi c o r r e c t n e s s m odi fy _ m o d _ s tr u c t SPC mod s t r u c t q u e r y TEST mod s t r u c t TEST mod c o n t SPC mod c< n t DES mod s t r u d t DES mod c o n t MAINT mod s t r u c t T ask IMP mod s t r u c t A c t io n IMP mod c o n t b ra n ch C o n d itio n , 11 Has s u c c e s o r I t e r a t i o n MAINT mod c o n t Figure 5.8: SO FTM A N Process: T he Top-Level A ctivity Hierarchy 89 T a sk A c t i o n C o n d i t i o n a l b r a n c h c r e a t e O L oop s e l e c t S u c c e s s o r d e l e t e C o m p o n en t u r r e n t - p r o j e c t { M - d e t a i l ) MISC t o r in v o k e - - e d i t o r i - e d t o r N e w - e d i t o r s l g i n v o k e - s m a 1 1 -C Figure 5.9: SO FTM A N Process: A Second Level A ctivity Hierarchy i 90 {{Design-Module- Content instance: task-component-of: task-has-predecessor: task-h as-successor: task-has-agent-role-spec: task-has-tool-spec: task-has-required-resource-spec: task-has-provided-resource-spec: {{agent-for-DMC instance: agent-role-spec-in-task: resource-requirement: maximum-quantity: resource-possession: {{tool-for-DMC instance: tool-spec-in-task: resource-requirements: maximum-quantity: resource-possession: { {required-for-DMC instance: required-resource-spec-in-task: resource-requirement: maximum-quantity: resource-possession: { {provided-for-DMC instance: provided-resource-spec-in-task: resource-requirement: maximum-quantity: resource-possession: task-chain SOFTMAN-PM Design-Module-Structure Impl-Module-Content agent-for-DMC tool-for-DMC required-for-DMC provided-for-DMC} } agent-role-spec Design-Module-Content Engineer 1 none}} tool-spec Design-Module-Content emacs dsn.exe 1 1 none }} required-resource-spec Design- Mo dule-Content Architectural-Spec.doc 1 none }} provided-resource-spec Design-Module-Content Architectural-Spec.numil 1 none }} Figure 5.10: SO FTM AN-PM : Definition of D esig n -M o d u le-C o n ten t 91 j~Develop TASK WINDOW: s o ftm a n rnodel D evelopers so jtw a r e js n g in e e r I Petall | (Rea^ftcTlona) | History"! [HlstoryRepIaij] [ Info~| | Finish""] (Quit] Task. L ist |1 ■aint.„»od_coot \2 ■Bint_aod_atru (3 teat.aod-cont [4 teat.j»od,stru [5 lap_aod_cont |6 iap ^ao d Jatru lE B E B S B B I B S B S S B B j8 deaaodstru [9 3pec_«od_cont [lO 8pec_mod_at.ru [Selectj |Hove| [Reduce] [Enlarge] [EnlargeHSpace] |EniargeVSpace] |ReduceHSpace| [ReduceviSpa £) None Ready # Allocated Active “ ana i ACTION W INDOW t d es in o d c o n t D eveloper: query [14 correctness^ [15 modlfy_mod_atru [16 Modify_sod_cont |19 req,aod_contr [20~ ^eq_mod_atru dan.exe][vl[ txl 11j Processor j | Print H noduleQp|| Lef tubj j j RlghtObJ ] } He Lp| Search forward)] Backward! HuMil D esign d e s c rip tio n «*/ f o r Command Driver •/ module cofnmana_manager i s provide ©x»cute_comrtand; b u ffe r, filenam e buffer_poe Lt ion sc re e n _ p o sIt ion c_n«xt__paB® c_previouB_page re q u ire Figure 5.11: T he Process-driven SO FTM A N Environm ent an experim ental PSEE. Figure 5.11 shows the developer’s interface to the new 1 process-driven SO FTM A N environm ent. T he windows in th e developer’s inter face display th e SO FTM A N -PM as well as an activity window th a t executes the D esig n -M o d u le-C o n ten t defined in Figure 5.10. T he new SO FTM A N environm ent uses th e process-driven user interface and supports the SO FTM A N -PM as well as the original SO FTM A N d ata m odel and tool set. T he pro cess-driven SO FTM A N lenvironment preserves th e im portant SOFTM AN concepts and functionalities, while jadding support for process guidance and project m anagem ent. U nder th e process- 1 idriven SO FTM A N environm ent, users know w hat developm ent stage th ey are cu r-! jrently perform ing, choices of th e appropriate tools to use, software docum ents to b e : produced, and w hat is expected next. 92 Semantic Checking for SOFTMAN-PM I l l e g a l P r e c e d e n c e R e l a t i o n : N o t h i n g f o u n d ! I l l e g a l P r e c e d e n c e C y c l e : N o t h i n g f o u n d ! I l l e g a l I t e r a t i o n a n d B r a n c h P a i r s : N o t h i n g f o u n d ! I s o l a t e d S u b t a s k s : N o t h i n g f o u n d ! R e s o u r c e s w i t h o u t P r o d u c e r A c t i v i t i e s : L IF E -C Y C L E -M O D E L R e s o u r c e s w i t h o u t C o n s u m e r A c t i v i t i e s : N o t h i n g f o u n d ! I n c o m p l e t e A c t i v i t y I n f o r m a t i o n : V IS U A L IZ E -C R E A T E -IM P d o e s n o t h a v e t o o l s V IS U A L IZ E -C R E A T E -M A IN T d o e s n o t h a v e t o o l s V IS U A L IZ E -C R E A T E -D S N d o e s n o t h a v e t o o l s V IS U A L IZ E -C R E A T E -T E S T d o e s n o t h a v e t o o l s V IS U A L IZ E -C R E A T E -S P C d o e s n o t h a v e t o o l s V IS U A L IZ E -C R E A T E -R E Q d o e s n o t h a v e t o o l s M A IN T -V ISU A L -M O D U L E d o e s n o t h a v e p r o v i d e - r e s o u r c e EXECUTE-PROGRAM d o e s n o t h a v e t o o l s IM P -V IS U A L -M O D U L E d o e s n o t h a v e p r o v i d e - r e s o u r c e D S N -V IS U A L -M O D U L E d o e s n o t h a v e p r o v i d e - r e s o u r c e T E S T -V IS U A L -M Q D U L E d o e s n o t h a v e p r o v i d e - r e s o u r c e S P C -V IS U A L -M Q D U L E d o e s n o t h a v e p r o v i d e - r e s o u r c e I n c o m p l e t e A g e n t / R o l e I n f o r m a t i o n : N o t h i n g f o u n d ! I n c o m p l e t e T o o l I n f o r m a t i o n : N o t h i n g f o u n d ! T o t a l S e m a n t i c P r o b l e m s : 1 3 ■ Figure 5.12: Sem antic Checking for SO FTM A N -PM A fter the SO FTM A N -PM was built, it was statically analyzed as described in th e previous chapter. Some of the results from static analysis are listed here: Fig- ♦ 'ure 5.12 is a partial ou tp u t from the sem antic check, which tells th a t some activities ‘ are defined w ithout developm ent tools. Figure 5.13 displays th e top level task prece- I dence graph for th e SO FTM A N -PM . Figure 5.14 shows p art of inform ation about production and consum ption for resources. Figure 5.15 lists statistics about subtasks 'in th e SO FTM A N -PM . p .3 .3 L esso n s L earn ed This experim ent in developing th e SO FTM A N -PM leads to th e following observa tions: B j Ellg TASK W INDOW i s o ftm a n jn o d e l D eveloper! e n g in e e r Develop"] j Detail"! jReadyflctionaj | History"*! iHistoryReplayj | Info | | Finish""] | Node | | Quit | T a sk L ist |1 req_jnod_structure \2 req_mod_content [3 bb 14 lb [5 modlfy^raocLcontent }6 modlfy_wwd_3tr*ucture 7 correctness |8 le E be (10 spc_niod_structure (11 test„mod_structure | 12 spc„mod_content (l3 test_mod_content | 14 dsn_mod_3tructure 1 15 dsn„mod_content (16 malnt_jnod_.structure (17 lropjiiodjitnicturt* )l8 imp_c>od_content " " ' (19 malnt._iBod_cont,fcnt~ |Select| |Hove| (Reduce) (Enlarge) (EnlargeHSpacej |£nlargeVSpace( |ReduceHSpace| |ReduceVSpace| Q None Done ^ Active ^ Broken ) Ready | Stopped ||| Allocated 1 Not Chosen | 1 Uait Resources I Assigned to other developer: Figure 5.13: Top Level Task Precedence G raph for SO FTM A N -PM • A very im portant feature for th e SO FTM A N -PM is th a t it represents suffi cient levels of decom position and integral links to practical developm ent tools., Therefore, th e link from high-level, goal-directed tasks to detailed tool invoca tion constitutes realization of conceptual planning. » • T he SO FTM A N -PM has m ore types of precedence relationships such as m ul tiple choices and iteration. In th e SO FTM A N -PM , m ultiple choices are used to represent situations when m ore than one developm ent tool can be used to accom plish a single developm ent task. Therefore, each choice uses a differ-' ent tool to perform the task. Only once choice is needed in order to finish th e whole construct of a m ultiple choice. Also iteration is used to represent possible loops of activities such as creating m ultiple m odule structures and correcting identified program m ing bugs. Resource Name Provider Task Consumer Task ARCS 'n o d e s ^Y STEM -D IA G R A M -R E Q -SK E LE T O N GRAPHICAL-M ODEL SK ELETO N -STRU CTU RE-REQ ;g r a p h i c a l - m o d e l - s p c S K EL E TO N -ST R U C T U R E -SP C G R A PH IC A L-M O D EL-TEST |sKELETON-STRUCTURE-TEST GRA PHICA L-M ODEL-DSN ISK ELETO N-STRUCTURE-DSN [GRAPHICAL-M ODEL-MAINT jSK ELETON -STRUCTURE-M AIN T G R A PH IC A L-M O D EL-IM P S K EL E TO N -ST R U C T U R E -IM P L IF E -C Y C L E -M O D E L T E S T -R E S U L T S O B J - F I L E -DSN-DOCUMENTS QUERY-REPORT E X T ER N A L-R EPO R T T N TER N A L-R EPO R T PRO TO TY PE-REQ PRO TO TY PE-REQ RESTRU CT-REQ V IS U A L IZ E -R E Q V IS U A L IZ E -C R E A T E -R E Q V I S U A L IZ E -S P C V IS U A L IZ E -C R E A T E -S P C V IS U A L IZ E -T E S T V IS U A L IZ E -C R E A T E -T E S T V IS U A L IZ E -D S N V IS U A L IZ E -C R E A T E -D S N V IS U A L IZ E -M A IN T V IS U A L IZ E -C R E A T E -M A IN T V IS U A L IZ E -IM P V IS U A L IZ E -C R E A T E -IM P EXECUTE-PROGRAM CO M PILE-SO U R C E-C O D E D S N -E D IT D S N -V IS U A L -E D IT QUERY EXTERNAL INTERNAL R ESTRU CT-REQ R ESTRU CT-REQ M O D IFY -R ESTR U C T-R EQ -N O D E V IS U A L IZ E -C R E A T E -R E Q M O DIFY -REQ -N O D E V IS U A L IZ E -C R E A T E -S P C M O D IFY -SP C -N O D E V IS U A L IZ E -C R E A T E -T E S T M O D IFY -TE ST -N O D E V IS U A L IZ E -C R E A T E -D S N M O DIFY -D SN -N O D E V IS U A L IZ E -C R E A T E -M A IN T M O D IFY -M A IN T-N O D E V IS U A L IZ E -C R E A T E -IM P M O D IFY -IM P-N O D E C R EA TE-REQ -N O D E PRO TO TY PE-REQ V IS U A L IZ E -R E Q M A IN T -E D IT M A IN T-V ISU A L-M O D U LE EXECUTE-PROGRAM I M P - E D I T IM P-V ISU A L -M O D U L E M O DIFY -CORRECTN ESS CORRECT-D ELETE V IS U A L -C O R R E C T V IS U A L -D E L E T E M O DIFY -CORRECTN ESS CORRECT-D ELETE V ISU A L -C O R R E C T V IS U A L -D E L E T E M O DIFY -CORRECTN ESS CO RRECT-D ELETE V ISU A L -C O R R E C T V IS U A L -D E L E T E Figure 5.14: P artial Resource Production Inform ation for SO FTM A N -PM 95 Statistical Information for SOFTMAN-PM P a r t I . S u b t a s k s N u m b e r o f T a s k s : 2 1 N u m b e r o f A c t i v i t i e s : 7 4 N u m b e r o f I t e r a t i o n s : 9 N u m b e r o f C o n d i t i o n a l s : 2 3 T o t a l N u m b e r o f S u b t a s k s : 1 5 9 P a r t I I . T a s k S t r u c t u r e M ax N u m b e r o f D e c o m p o s i t i o n L e v e l s : 4 N u m b e r o f T a s k s w i t h o u t C o m p o n e n t s : 0 F o r e a c h S u b t a s k : T y p e M ax N u m b e r M in N u m b e r A v e r a g e N u m b e r C o m p o n e n t 2 2 4 7 . 5 2 P r e d e c e s s o r 1 2 0 1 . 1 4 S u c c e s s o r 1 2 0 1 . 1 4 P a r t I I I . R e s o u r c e I n f o r m a t i o n N u m b e r o f D e f i n e d A g e n t s a n d R o l e s : 5 N u m b e r o f D e f i n e d D e v e l o p m e n t T o o l s : 3 2 N u m b e r o f D e f i n e d R e q u i r e d R e s o u r c e s : 4 3 N u m b e r o f D e f i n e d P r o v i d e d R e s o u r c e s : 4 2 F o r e a c h A c t i v i t y : T y p e M ax N u m b e r M in N u m b e r A v e r a g e N u m b e r A g e n t 1 1 1 . 0 0 T o o l 6 0 1 . 1 9 R e q u i r e d - R e s o u r c e 1 8 1 3 . 0 3 P r o v i d e d - R e s o u r c e 6 0 1 . 5 8 P a r t I V . I n c o m p l e t e I n f o r m a t i o n TOTAL NUMBER OF SUBTASKS WITH RESOU RCES: 7 4 T o t a l N u m b e r o f S u b t a s k s w i t h o u t A g e n t s : 0 T o t a l N u m b e r o f S u b t a s k s w i t h o u t T o o l s : 7 T o t a l N u m b e r o f S u b t a s k s w i t h o u t R e q u i r e d - R e s o u r c e s : 0 T o t a l N u m b e r o f S u b t a s k s w i t h o u t P r o v i d e d - R e s o u r c e s : 5 Figure 5.15: Statistical Checking for SO FTM A N -PM • T he new process-driven SO FTM A N environm ent is flexible to changes. In| fact, variations of the SO FTM A N -PM have been tried so th a t these models 5 i support different developm ent approaches, b u t use th e sam e product m odel and tool set. In this way, variations of the SO FTM A N -PM effectively reconfigure' how tools and product resources are provided to users, w ithout any additional1 m odifications to th e tools or object m anagem ent subsystem . Thus, th e process-j I driven interface should be applicable to m ost SEEs which provide basic tool' 1 . . . . . . . . I and object integration m echanisms. However, validating this claim requires m ore experim ents along th e sam e direction. I I ; i 5.4 The Develop-Change-and-Test-Unit Process T he last case study is to build an SPM , called D evelop-Change-and-Test-U nit-PM , th a t describes a partial SPM w ithin software developm ent. It addresses research issues raised by the organizing com m ittees of th e 6th and 7th International Software, Process W orkshop in O ctober, 1990 [51] and O ctober, 1991 [34] respectively. T h e1 original problem served as a standard modeling problem for com paring various ap proaches to software process m odeling. This exam ple SPM was presented at th e 7th International Software Process W orkshop. 5.4.1 M o d e lin g S tep s jThe exam ple problem describes a software process, called D evelop-Change-and-Test-! |U nit, th a t modifies a software system ’s design and source code as p art of a software I developm ent project. T he docum ents [34, 51] provide a fairly com prehensive infor- imal description of th e SPM and their requirem ents are followed to create an SPM. 5 .4 .2 T h e D e v e lo p -C h a n g e -a n d -T e st-U n it P r o c e ss M o d e l D evelop-Change-and-Test-U nit-PM , whose definition is given in Figure 3.9, focuses, i . . . . . I Jon designing, coding, unit testing, and m anaging a localized change to a software, unit. It has only one level of decom position w ith seven activities. Figure 5.16 i gives its activity hierarchy and is straightforw ard to understand. It also show s' Modify-Design Modify-Code Test-Unit i I Assign-Task Modify-Test-Plan Modxfy-Test-Pk M o n i t o r Figure 5.16: D evelop-Change-and-Test-U nit: A ctivity H ierarchy the orders of execution am ong th e activities, represented as directed lines. For' exam ple, once A s s i g n - T a s k is done, three activities, M o n i t o r , M o d i f y - T e s t - P l a n , and M o d i f y - D e s i g n can be started. Figure 5.17 gives the definition of activity M o d i f y - D e s i g n w ith its resource re-, quirem ents. N ote th a t this SPM also does not have tool requirem ents. M o d i f y - D e s i g n requires two kinds of agents: d e s i g n e r and e n g i n e e r as well as; some other kinds of required-resources. In defining these requirem ents, resources, such as D e s i g n e r , could be assum ed to be defined elsewhere in the A rticulator. ; Figure 5.17 also provides an exam ple of resource possessions. Assum e th a t a: team of software engineers and other related resources are allocated for Develop-i Change-and-Test-U nit-PM . For M o d i f y - D e s i g n , John is assigned as a designer and- Doug as a engineer. For other resource classes, the sam e nam es are used to represent' instances w ithin the classes for this example. A lthough it is an oversimplified exam ple, it is easy to anticipate th a t given dif ferent sets of resource possession, SPM enactm ent will be different. It is also easy to _98j {{Modify-Design instance: t ask- component-of: task-has-predecessor: task-has-successor: task-has-agent-role-spec: t ask- has-requi red-resour ce- sp ec: t ask-has-provi ded-resource- sp ec: {{agent-for-modify-design instance: agent- role- spec-in-t ask: resource- requirement: maximum-quantity: resource-possession: {{required-for-modify-design instance: required-resource-spec-in-task: resource- requirement: maximum-quantity: resource-possession: {{provided-for-modify-design instance: provided-resource-spec-in-task: resource-requirement: maximum-quantity: resource- p ossession: activity Develop- C hange- and- Test- Unit Assign-Task Modify-Code agent-for-modify-design required-for-modify-design provided-for-modify-design) } agent-role-spec Modify-Design Designer Engineer 1 1 John Doug}} required-resource- spec Modify-Design System-Design-Doc Requirements-Change 1 1 System-Design-Doc Requirements-Change}} provided-resource-spec Modify-Design System-Design-Doc 1 System-Design-Doc}} Figure 5.17: D evelop-Change-and-Test-U nit-PM : Definition of M odify-D esign Semantic Checking for DEVELOP-CHANGE-AND-TEST-UNIT I l l e g a l P r e c e d e n c e R e l a t i o n : I l l e g a l P r e c e d e n c e C y c l e : I l l e g a l I t e r a t i o n a n d B r a n c h P a i r s : I s o l a t e d S u b t a s k s : R e s o u r c e s w i t h o u t P r o d u c e r A c t i v i t i e s : AUTHORIZATION R e s o u r c e s w i t h o u t C o n s u m e r A c t i v i t i e s : T E S T -R E S U L T , P R D JE C T-S C H E D U L E I n c o m p l e t e A c t i v i t y I n f o r m a t i o n : A S S IG N -T A S K d o e s M O D IFY -D E SIG N d o e s M ODIFY-CODE d o e s M O D IF Y -T E S T -P L A N d o e s M O D IF Y -T E S T -P K d o e s T E S T -U N IT d o e s MONITOR d o e s I n c o m p l e t e A g e n t / R o l e I n f o r m a t i o n : I n c o m p l e t e T o o l I n f o r m a t i o n : T o t a l S e m a n t i c P r o b l e m s : 1 0 Figure 5.18: Sem antic Checking for D evelop-Change-and-Test-U nit-PM see th a t whenever resource possession changes, SPM enactm ent changes accordingly. ! These changes give rise to the necessity for articulation, and therefore, the role of ;the A rticulator is to handle unexpected changes or failures in SPM enactm ent. This will be covered in later chapters. 1 A fter th e D evelop-Change-and-Test-U nit-PM is built, it was statically analyzed jas described in th e previous chapter. Some of the results from static analysis are jlisted here: Figure 5.18 is a partial o u tp u t from the sem antic check. It is clear th a t 1 this SPM does not have inform ation for developm ent tools. Figure 5.19 displays its task precedence graph. Figure 5.20 shows inform ation about production and consum ption for resources. Figure 5.21 lists statistics about subtasks in th e Develop- jChange-and-Test-U nit-PM . N o t h i n g f o u n d ! N o t h i n g f o u n d ! N o t h i n g f o u n d ! N o t h i n g f o u n d ! n o t h a v e t o o l s n o t h a v e t o o l s n o t h a v e t o o l s n o t h a v e t o o l s n o t h a v e t o o l s n o t h a v e t o o l s n o t h a v e t o o l s N o t h i n g f o u n d ! N o t h i n g f o u n d ! TASK W INDOW : develo p ch a n g e ja n d jte s tju n it D eveloper: rnary ( Develop | | Detail | |ReadyActlons| | History | |HlstoryReplay| | Info | f Finish | | Node | | Quit | Task List |Select| [Hove] |Reduce| (Enlarge] |EnlargeHSpace| [EnlargeVSpace] |ReduceHSpace| } l monitor j Q None ^ Active ^ Ready | | | | Allocated Uait Resources | 2 teat_unit j | 3 modify_unii_teot__pk[ Done Broken | | | | Stopped Not Chosen Assigned to other develi |4 modi.fy_test_plan | ( 5 modify.code | { 6 modify_design | | 7 033ign_tBsk | Figure 5.19: Task Precedence G raph for D evelop-Change-and-Test-U nit-PM 5 .4 .3 L esso n s L earn ed A lthough it is a simple SPM , D evelop-Change-and-Test-U nit-PM is of im portance because it addresses issues th a t have common interest am ong the research com m u nity of th e software process. T he exam ple process was designed by th e Workshop organizing com m ittee to pose various problem s for m odeling and com paring the SPM s, as well as several optional problems. These problem s are described next, as th eir solutions. • T he M odeling Problem : It is very easy to use the A rticulator m eta-m odel to create Develop-Change-and-Test-U nit-PM . T he inform al narrative form at of th e original problem is presented in [51, 34] and alm ost exactly m atches th a t of the A rticulator m eta-m odel. It provides inform ation for both activity hierarchy and resource requirem ents, although inform ation for resource possession is a little vague. 101 R e s o u r c e N am e P r o v i d e r T a s k C o n s u m e r T a s k REQUIREMENTS-CHANGE A S S IG N -T A S K TEST-OUTCOM E S Y S T EM -O B JE C T -C O D E U N IT -T E S T -P A C K A G E SY ST EM -D E SIG N -D O C SY STEM -SO U RCE-C O D E T E S T -P L A N AUTH ORIZATIO N T E S T -R E S U L T TEST-PA C K A G E-FEED B A C K TES T-F EE D B A C K PR O JE C T -S C H E D U L E P R O JE C T -P L A N T E S T -U N IT MODIFY-CODE M O D IF Y -T E S T -P K M O D IFY -D E SIG N M ODIFY-CODE M O D IF Y -T E ST -P L A N T E S T - U N I T T E S T -U N IT T E S T -U N IT A S S IG N -T A S K MONITOR A S S IG N -T A S K MONITOR A S S IG N -T A S K M O D IFY -D E SIG N M ODIFY-CODE M O D IF Y -T E S T -P L A N M O D IF Y -T E S T -P K T E S T -U N IT MONITOR MONITOR T E S T -U N IT M O D IF Y -T E S T -P K T E S T -U N IT M O D IFY -D E SIG N M ODIFY-CODE M O D IF Y -T E S T -P K MODIFY-CODE M O D IF Y -T E S T -P K M O D IF Y -T E S T -P L A N M O D IF Y -T E S T -P K A S S IG N -T A S K M O D IF Y -T E S T -P K MODIFY-CODE A S S IG N -T A S K MONITOR Figure 5.20: P artial Resource Inform ation for D evelop-Change-and-Test-U nit-PM 102 Statistical Information for DEVELOP-CHANGE-AND-TEST-UNIT P a r t I . S u b t a s k s N u m b e r o f T a s k s : 1 N u m b e r o f A c t i v i t i e s : 7 N u m b e r o f I t e r a t i o n s : 0 N u m b e r o f C o n d i t i o n a l s : 0 T o t a l N u m b e r o f S u b t a s k s : 8 P a r t I I . T a s k S t r u c t u r e M ax N u m b e r o f D e c o m p o s i t i o n L e v e l s : N u m b e r o f T a s k s w i t h o u t C o m p o n e n t s : 2 0 F o r e a c h S u b t a s k : T y p e C o m p o n e n t P r e d e c e s s o r S u c c e s s o r M ax N u m b e r 7 2 3 M in N u m b e r A v e r a g e N u m b e r 7 0 0 7 . 0 0 0 . 8 7 0 . 8 7 P a r t I I I . R e s o u r c e I n f o r m a t i o n N u m b e r o f D e f i n e d A g e n t s a n d R o l e s : 3 N u m b e r o f D e f i n e d D e v e l o p m e n t T o o l s : 0 N u m b e r o f D e f i n e d R e q u i r e d R e s o u r c e s : 11 N u m b e r o f D e f i n e d P r o v i d e d R e s o u r c e s : 1 2 F o r e a c h A c t i v i t y : T y p e A g e n t T o o l R e q u i r e d - R e s o u r c e P r o v i d e d - R e s o u r c e M ax N u m b e r M in N u m b e r A v e r a g e N u m b e r 2 1 1 . 1 4 0 0 0.00 6 2 3 . 2 9 4 1 2 . 0 0 P a r t I V . I n c o m p l e t e I n f o r m a t i o n TOTAL NUMBER OF SUBTASKS WITH RESOU RCES: T o t a l N u m b e r o f S u b t a s k s w i t h o u t A g e n t s : 0 T o t a l N u m b e r o f S u b t a s k s w i t h o u t T o o l s : 7 T o t a l N u m b e r o f S u b t a s k s w i t h o u t R e q u i r e d - R e s o u r c e s : 0 T o t a l N u m b e r o f S u b t a s k s w i t h o u t P r o v i d e d - R e s o u r c e s : 0 Figure 5.21: Statistical Checking for Develop-Change-and-Test-Unit-PM • M odify Code Details: This entails developing th e details of th e modify code step m ore fully. It requires specifications for lower level decom position with possible iteration, and specifications for tool invocation. B oth requirements are easy to address using th e A rticulator m eta-m odel. • Review Design Details: This entails developing th e details of th e review de sign step m ore fully. It requires specification for an interactive process. The A rticulator m et a-model is able to specify interactive processes for the globa] view, b u t is unable to address detailed interaction betw een individual agents However, if such an interactive process is actually an aggregation of a set of interacting processes controlled by individual agents, then it can be handled. • Scheduling and Resource C onstraints: This deals w ith project managem ent issues for scheduling and resource constraints, which falls into th e capability of th e A rticulator m eta-m odel. This capability will be investigated in later chapters. • A ggregation of M ultiple Changes: This entails th e consideration of m ultiple changes in a product produced by an SPM. It requires th e ability of a pro-J cess representation to specify independent and concurrent sub-processes and. to m aintain proper relationships among th e products u p d ated by the sub-| processes. To this end, the A rticulator m eta-m odel is equipped w ith concur-j rent sub-tasking capabilities for process activities. Users are allowed to define parallel sub-processes which update different p arts of a single product. • Process Changes: This involves identifying and im plem enting changes to pro cesses, as well as m ore challenging dynam ic change during enactm ent. To this end, process articulation, explained in later chapters, handles dynam ic changes to enacted SPMs. • P roduct Representation: This provides an opportunity to exam ine the rela tionships betw een a process modeling approach and th e underlying product representation. This requires identifying and exam ining th e ways in whiclJ th e product representation language im pacts th e SPM and the software pro cess m odeling approach. T he A rticulator m eta-m odel, currently, does not 104 have a system atic approach to take on this issue. O nly an initial experim ent was done when the SO FTM A N -PM was created, which suggests a consistent' object-oriented approach for both a process m odel and a product m odel can be realized in a straightforw ard way. In sum , th e A rticulator m eta-m odel is able to solve a large portion of these challenge problem s. It is particularly capable of addressing two issues: project scheduling andj process changes. T he results of this exam ple were presented at th e 7th International Software Process W orkshop [64]. 5.5 Summary In this chapter, three case studies to build SPMs in the A rticulator m eta-m odel were presented. These case studies establish a prelim inary validation for the Ar-| ticu lato r m eta-m odel, the SPM definition methodology, and th e static analysis of SPM s regarding their process specification capability. In other words, th e Articula-J to r m eta-m odel has dem onstrated its capability through these case studies. It is able to m odel m ost of th e encountered situations. Its practical utility was established byj our industrial sponsors. At th e same tim e, some enhancem ents to th e A rticulator m eta-m odel were identified and im plem ented. These case studies also dem onstrated th e use of static analysis to identify possible problem s in these SPMs. However, an SPM th a t has successfully passed through static analysis m ay en counter fu rth er problem s in SPM enactm ent. SPM s m ust be m easured against a set1 of dynam ic criteria to ensure proper enactm ent. In this regard, users are interested in knowing th e resource requirem ents of an SPM as well as th e tim ely allocation! of these resources. In th e case of process analysis, these resource requirem ents and! allocations represent the test d ata for dynam ic analysis. M ore im portantly, userJ should be able to accom m odate the dynam ic changes th a t occur during SPM enact m ent by a system atic mechanism. All these issues of dynam ic analysis of SPM s will be presented in th e next set of chapters. 105 Chapter 6 Dynamic Analysis and Simulation of SPMs T he dynam ic analysis of SPM s is th e m ain topic of this chapter. T he purpose of dynam ic analysis is to identify and correct potential process breakdowns before and during SPM enactm ent. T he A rticulator provides two types of dynam ic analysis: Process sim ulation resolves possible breakdowns before SPM enactm ent and process articulation resolves actual breakdowns during SPM enactm ent. SPM enactment! and sim ulation is built by using an operational sem antics th a t determ ines th e m ean ing of SPM enactm ent. T he discussion of dynam ic analysis is divided into three parts. In this chapter, the enactm ent sem antics and process sim ulation will first! be presented. In the next two chapters, a detailed description about process artic-j ulation will be given, followed by a chapter of case studies th a t dem onstrate the capability and utility of dynam ic analysis. 6.1 Introduction T he im portance of dynam ic analysis to SPM s can be understood from a com parison to the debugging to software program s. Program debugging identifies and corrects sem antic as well as algorithm ic errors through test cases. It also provides users w ith inform ation such as program perform ance and resource utilization. Based on this inform ation, users can modify and optim ize th eir program s to achieve th e com p utational goal of th e program correctly and m ore efficiently. In software process m odeling, dynam ic analysis provides sim ilar types of support for th e sam e purpose. It provide m eans of debugging to identify and correct process breakdow ns before and during SPM enactm ent. 106 T he A rticulator provides two m echanisms for dynam ic analysis: sim ulation and articulation. Before SPM enactm ent starts, sim ulation sym bolically enacts an SPM based on a hypothetical resource configuration. T he outcom e of sim ulation is a tra jectory of symbolic task execution and resource usage which can be used to generate estim ation of resource requirem ents and allocation for SPM enactm ent in similar situation. From this sim ulation trajectory, several kinds of inform ation can be cre ated to provide a picture of activity execution and resource transform ation for the given hypothesis. However, unlike program debugging, SPMs are enacted in open environm ents. Even though an SPM is well analyzed through sim ulation, it m ust accom m odate unexpected changes in the environm ent after it is enacted. It is these unexpected changes th a t cause breakdowns during SPM enactm ent. In other words] SPM s are modified in order to adapt to the changes. T he activity th a t im plem ents the adaptation is called articulation, as identified in C hapter 2. A rticulation is J dynam ic repair m echanism th a t evolves an SPM according to changes in th e envi ronm ent. SPM enactm ent and sim ulation are based on enactm ent sem antics th a t guides th e way an SPM is enacted both symbolically and in reality. T he enactm ent se-j m antics define the constraints th a t m ust be satisfied and th e execution order for the subtasks to be enacted. The inference rules in the enactm ent sem antics drive SPM' sim ulation or enactm ent according to the given constraints and resources in SPMsJ N ext presented are th e enactm ent sem antics and process sim ulation. 6.2 Enactment Semantics of SPMs E nactm ent sem antics o f SPM s enable execution or interpretation of an SPM accord ing to its activity hierarchy. It determ ines the order and rules for how subtasks in an SPM are perform ed, and w hat constraints m ust be satisfied before the subtasks are perform ed. It plays the role of an autom ated software process driver th a t initiates an SPM , enacts its subtasks, accepts developers’ inputs, updates and propagates th e statu s of these subtasks, and then triggers other subtasks. A key variable th a t represents the state of SPM enactm ent is status. T he status of an SPM or a subtask is an indicator of its current state of developm ent. T he statusj is u pdated by th e process driver based on interactivity w ith developers. U pdates to' 107 Value Its Definition for activities Its Definition for Tasks None Set initially Its subtasks are defined Allocated Its developers, tools, and required Resources have been allocated Its subtasks are in status Allocated Ready Allocated, and either without predecessors or its predecessors are done Some of subtasks are Ready, but none of them is Active Active Its enactment is in progress. The assigned developers are performing it Some of subtasks are Active Stopped Not being performed, voluntarily stopped Some of subtasks are Stopped, but none of them is Active, nor Broken, nor Ready Broken Either i) one or more required resources is unavailable, or ii) unable to continue due to some other reason Some of subtasks are Broken, but none of them is Active, nor Ready Done Execution is finished successfully Its subtasks are in status Done Not-chosen Not selected for execution Not available Table 6.1: Values of S tatus and T heir Definition th e current status value represent progress through enactm ent. To this end, SPMi enactm ent drives the status of an SPM from N o n e to D o n e . T he values of process statu s and their definitions are listed in Table 6.1. T he definition of an activity’s statu s is prim itive and determ ined by operations on it, while th e definition of a task ’s statu s is recursively defined and based on the status of its com ponent subtasks. Thus] while an SPM indicates a prescribed order of subtask enactm ent, a record of subtask! statu s transitions describe th e order in which subtask enactm ent actually occurred.J Developers sta rt enactm ent of an allocated SPM by issuing s t a r t on an initial R e a d y subtask to th e process driver. During perform ance of th e activities, some m ay be D o n e successfully, others m ay be S t o p p e d , or even becom e B r o k e n which! should be repaired by articulation. Once some o f th e activities are D o n e , they, trigger th e process driver to u p d ate the SPM and assert m ore R e a d y activities. The enactm ent continues until the SPM is D o n e . Accordingly, developers enact andj i process m anagers control SPM s through two different user interfaces. Figure 6.1 provides a com plete statu s transition graph w ith transition activities which will be defined later. For exam ple, S t a r t - A c t i v i t y changes an activ ity ’s statu s from either R e a d y or S t o p p e d to A c t i v e to signal th a t th e execution of the activity is in progress. However, a ta sk ’s status is only an aggregation of those of itsj com ponent subtasks and activities calculated recursively. Following are some basic’ operations th a t m anipulate status of a subtask: 108 A L(A p) i s t h e s e t o f t h e a c t i v i t i e s Ap i n P , w h e r e s t a t u s ( A p ) = A l l o c a t e d R E (A p) i s t h e s e t o f t h e a c t i v i t i e s Ap i n P , w h e r e s t a t u s ( A p ) = R e a d y C o m p u t e - S t a t u s ( A p ) i s a f u n c t i o n t o s e t t h e s t a t u s o f Ap a c c o r d i n g t o t h e s t a t u s t r a n s i t i o n g r a p h C o m p u te -A L (P ) c o m p u t e s A L(A p) f o r P C o m p u te - R e ( P ) c o m p u t e s R E (A p) f o r P T he statu s transition graph presented in Figure 6.1 actually represent three kinds of constraints th a t m ust be satisfied before an activity can be enacted: • Resource requirement constraints define th e required resources for an activity. T hey indicate th a t an activity can be enacted only when its resource posses-j sion satisfies its resource requirem ents. However, for dynam ic activities their resource allocation can be postponed. • User-defined constraints define user preferred constraints in forms of boolean conditions or procedures. They indicate th a t an activity can be enacted only when all user-defined constraints are satisfied. These two constraints are sat isfied in th e transition from None to A llo c a te d . • Precedence constraints define th e execution order of activities. They indicate th a t an activity can be enacted only when its predecessors are done. This is presented as transition betw een A llo c a te d to Ready. W hen SPM enactm ent initially starts, it opens the process library, th en retrieves and installs th e necessary SPM instance. Then resource instances are allocated tJ the SPM and th e process driver sets th e initial set of re a d y subtasks. An SPM canj be only enacted initially if its R E(A p) is not em pty. An algorithm ic definition of this initialization follows. In these definitions, P denotes an SPM instance; T p is a subtask in P; Ap is an activity in P; SPLib is a library th a t stores all enactable SPMs; Resource-Lib is a database th a t stores all resource instances. SPM enactment^ executes concurrently all the com ponent subtasks in RE(A p). 1 . 1 S t a r t - E n a c t m e n t P r e c o n d i t i o n : n o n e O p e r a t i o n : I n i t i a l i z a t i o n ) ; D o ( e a c h P ) [ R e s o - A l l o c a t e ( P , P ) ; 109 ot-chosen n allocated active ready done none broken stopped T r a n s i t i o n A c t i v i t i e s : 1 : R e s o - A l l o c a t e ; 2 : P r e d e c e s s o r - D o n e ; 3 : S t a r t - A c t i v i t y ; 4 : F i n i s h - A c t i v i t y ; 5 : S e a r c h - C h a n g e ; 6 : A r t i c u l a t e ; 7 : I t e r a t i o n ; 8 : S t o p - A c t i v i t y ; 9 : B r a n c h . Figure 6.1: Transition of Process S tatus E n a c t - P r o c e s s ( P ) ] 1 . 2 I n i t i a l i z a t i o n Q : / * i n i t i a l i z e t h e d r i v e r * / P r e c o n d i t i o n : P i n S P L i b O p e r a t i o n : O p e n ( S P L i b ) ; O p e n ( R e s o u r c e - L i b ) ; F o r ( e a c h P ) L o a d ( P ) ; I n i t i a l i z e d = t r u e ; 1 . 3 E n d ( ) : / * e n d t h e d r i v e r * / P r e c o n d i t i o n : I n i t i a l i z e d = t r u e O p e r a t i o n : F o r ( e a c h P ) S a v e ( P ) ; F o r ( e a c h R ) S a v e ( R ) ; C l o s e ( S P L i b ) ; C l o s e ( R e s o u r c e - L i b ) ; 1 . 4 R e s o - A l l o c a t e ( A p . P ) : / * a l l o c a t e d d e v e l o p e r s , t o o l s , a n d r e q u i r e d r e s o u r c e f o r A p i n P * / P r e c o n d i t i o n : A p i s a s u b t a s k o f P O p e r a t i o n : F o r ( e a c h d e v e l o p e r , t o o l a n d r e q u i r e d r e s o u r c e R i n A ) [ I f ( P h a s R ) a s s i g n - r e s o u r c e ; E L S E a s k - h u m a n - a s s i s t a n c e 3 c h e c k - u s e r - d e f i n e d - c o n s t r a i n t ; I f ( s u c c e s s f u l ) s t a t u s ( A p ) = A l l o c a t e d ; 110 Else status(Ap) = Broken; 1 . 5 S e a r c h - C h a n g e O : / * s e a r c h f o r c h a n g e s * / P r e c o n d i t i o n : n o n e O p e r a t i o n : s e a r c h f o r c h a n g e s i n R e s o u r c e - L i b , a n d m a k e c o r r e s p o n d i n g s t a t u s c h a n g e i n a l l p r o c e s s e s ; 1 . 6 E n a c t - P r o c e s s ( P ) : / * t h e m a i n l o o p t o e n a c t a p r o c e s s * / P r e c o n d i t i o n : P i s e n a c t a b l e O p e r a t i o n : S t a r t - T a s k ( P ) ; W hen a task (which is decomposed into a set of lower level subtasks) is enacted, it invokes enactm ent of its com ponent subtasks. This is done in SPM enactm ent' recursively. As soon as a com ponent subtask is com pleted, i.e., its statu s becomes D o n e , SPM enactm ent will com pute its RE(A p) again to get new com ponent subtasks^ whose statu s turns to R e a d y . These newly created ready com ponent subtasks willl be enacted im m ediately. For those subtasks whose statu s change to B r o k e n during j enactm ent, SPM enactm ent has to issue an a r t i c u l a t e task, which m akes changes in either resource possession or activity specification, and then puts th e status back to R e a d y . Once all th e com ponent subtasks are D o n e , the enactm ent of th e SPM is D o n e . Following is th e algorithm ic definition to start task enactm ent. 2 . 1 S t a r t - T a s k ( T p ) : P r e c o n d i t i o n : R E ( T p ) != e m p t y O p e r a t i o n : F o r ( e a c h c o m p o n e n t T i n R E ( T p ) ) [ I f ( T i s a s u b t a s k ) S t a r t - T a s k ( T ) ; E l s e I f ( T i s a n a c t i v i t y A p ) [ Do ( e a c h a c t i v i t y A p i n R E ( A p ) ) [ S t a r t - A c t i v i t y ( A p ) ] ( i n p a r a l l e l ) 33 F o r ( e a c h c o m p o n e n t T w h e r e S t a t u s ( T ) = B r o k e n ) [ A r t i c u l a t e ( T ) 3 S t a t u s ( T p ) = d o n e ; 2 . 2 A r t i c u l a t e ( T ) / * d e t a i l s t o b e p r e s e n t e d i n t h e n e x t c h a p t e r s * / W hen an activity is enacted, its enactm ent is th e unit of SPM enactm ent. Devel opm ent work defined in an SPM is carried out by enacting activities. Depending on specification of developers, developm ent tools, and required resources associated w ith activities, th eir enactm ent differs. For enactm ent purposes, we define an enactm ent hierarchy of activities according to the resource allocation, num ber of developers, and associated developm ent tools (Figure 6.2). Ill A c tiv ity Static Activity 'Single-agent Activity ’M ulti-agent A c tiv ity System A c tiv ity Standard S in g le-ag en t A c tiv ity Symbolic S in g le-ag en t A c tiv ity Standard M ulti-agent A c tiv ity Symbolic M u lti-ag en t A c tiv ity 1 Simple System A c tiv ity 1 Branch ► Dynamic A c tiv ity L> Ite r a tio n Figure 6.2: E nactm ent H ierarchy of A ctivities T here exist two general types of activity in term s of resource allocation. A static activity is one whose developers, tools and resources are allocated before its enact-j m ent starts. A dynam ic activity is one whose resource allocation is postponed until its enactm ent begins. Therefore th e first task for activity enactm ent is to allocate de-| velopers, tools and resources. A fterw ards, a dynam ic activity is treated th e same as a static activity. Three types of static activities are defined according to th e number, of assigned developers. A single-agent activity has only one developer. A multi-agent activity requires m ore th an one developer to work concurrently. A system activity is an autom ated activity which can be enacted by SPM enactm ent w ithout human! activity. N ext, a standard activity requires com puterized developm ent tools and itsj enactm ent can be fully supported through tool invocation. A symbolic activity is one which does not use com puterized tools and its enactm ent will only be symbolically recorded in th e SPM in order to have a com plete process description and to support project m anagem ent. Currently, there are three types of system activities: simple (Sim) system activities, iteration and branch. Following is an algorithm ic definition of enactm ent of different types of activities. 3 . 1 S t a r t - A c t i v i t y ( A p ) : P r e c o n d i t i o n : n o n e O p e r a t i o n : I f ( A p i s d y n a m i c ) R e s o - A l l o c a t e ( A p ) ; 112 Start-Static-Activity(Ap); 3 . 2 S t a r t - S t a t i c - A c t i v i t y ( A p ) : P r e c o n d i t i o n : R e s o - A l l o c a t e ( A p ) = D o n e O p e r a t i o n : S e l e c t ( a s s i g n e d d e v e l o p e r s o f A p ) [ C a s e s i n g l e - a g e n t : S t a r t - S a - A c t i v i t y ( A p ) ; C a s e m u l t i - a g e n t : S t a r t - M a - A c t i v i t y ( A p ) ; C a s e n o - a g e n t : S t a r t - S y s - A c t i v i t y ( A p ) ] 3 . 3 S t a r t - S a - A c t i v i t y ( A p ) : P r e c o n d i t i o n : n o n e O p e r a t i o n : w a i t - f o r - d e v e l o p e r - e n a c t m e n t - t o - s e l e c t S e l e c t ( t o o l s o f A p ) [ C a s e t o o l e x i s t s : S t a r t - S t d - S a - A c t i v i t y ( A p ) ; F i n i s h - A c t i v i t y ( A p ) ; S t o p - A c t i v i t y ( A p ) ; C a s e n o t o o l : S t a r t - S y m - S a - A c t i v i t y ( A p ) ; F i n i s h - A c t i v i t y ( A p ) ; S t o p - A c t i v i t y ( A p ) ] 3 . 4 S t a r t - M a - A c t i v i t y ( A p ) : P r e c o n d i t i o n : n o n e O p e r a t i o n : w a i t - f o r - d e v e l o p e r - e n a c t m e n t - t o - s e l e c t S e l e c t ( t o o l s o f A p ) [ C a s e t o o l e x i s t s : S t a r t - S t d - M a - A c t i v i t y ( A p ) ; F i n i s h - A c t i v i t y ( A p ) ; S t o p - A c t i v i t y ( A p ) ; C a s e n o t o o l : S t a r t - S y m - M a - A c t i v i t y ( A p ) ; F i n i s h - A c t i v i t y ( A p ) ; S t o p - A c t i v i t y ( A p ) ) 3 . 5 S t a r t - S t d - S a - A c t i v i t y ( A p ) : P r e c o n d i t i o n : S t a t u s ( A p ) = R e a d y I S t o p p e d O p e r a t i o n : i n v o k e a l l t h e t o o l s a n d e x e c u t e t h e m ; g e t a l l r e q u i r e d r e s o u r c e s a n d l o c k t h e m ; S t a t u s ( A p ) = A c t i v e ; 3 . 6 S t a r t - S t d - M a - A c t i v i t y ( A p ) : P r e c o n d i t i o n : S t a t u s ( A p ) = R e a d y I S t o p p e d & a l l i t s d e v e l o p e r s a r e i n s e s s i o n O p e r a t i o n : i n v o k e a l l t h e t o o l s a n d e x e c u t e t h e m ; g e t a l l r e q u i r e d r e s o u r c e s a n d l o c k t h e m ; S t a t u s ( A p ) = A c t i v e ; 3 . 7 S t a r t - S y m - S a - A c t i v i t y ( A p ) : P r e c o n d i t i o n : S t a t u s ( A p ) ~ R e a d y | S t o p p e d O p e r a t i o n : S t a t u s ( A p ) = A c t i v e ; 3 . 8 S t a r t - S y m - M a - A c t i v i t y ( A p ) : P r e c o n d i t i o n : S t a t u s ( A p ) = R e a d y I S t o p p e d & a l l i t s d e v e l o p e r s a r e i n s e s s i o n 113 Operation: Status(Ap) = Active; 3 . 9 S t a r t - S y s - A c t i v i t y ( A p ) : P r e c o n d i t i o n : n o n e O p e r a t i o n : S e l e c t ( t y p e o f A p ) C C a s e S i m p l e - S y s t e m - A c t i v i t y : S t a r t - S i m - S y s - A c t i v i t y ( A p ) ; C a s e I t e r a t i o n - a c t i v i t y : S t a r t - I t e r a t i o n ( A p ) ; Case Branch-activity: Start-Branch(Ap) 3 3 . 1 0 S t a r t - S i m - S y s - A c t i v i t y ( A p ) : P r e c o n d i t i o n : S t a t u s ( A p ) = R e a d y O p e r a t i o n : e x e c u t e t h e s p e c i f i e d t o o l o n t h e r e q u i r e d r e s o u r c e ( a n d c r e a t e o u t p u t ) ; F o r ( e a c h r e q u i r e d - r e s o u r c e R ) [ I F ( R i s n o n - r e u s a b l e ) d e l e t e n o n - r e u s a b l e r e q u i r e d r e s o u r c e s ; E l s e r e l e a s e r e u s a b l e r e q u i r e d r e s o u r c e s 3 s t a t u s ( A p ) = d o n e ; C o m p u t e - S t a t u s ( s u p e r t a s k ( A p ) ) ; F o r ( e a c h o f t h e s u c c e s s o r s A p l o f A p ) [ C o m p u t e - S t a t u s ( A p l ) 3 3 . 1 1 F i n i s h - A c t i v i t y ( A p ) : P r e c o n d i t i o n : S t a t u s ( A p ) = A c t i v e O p e r a t i o n : F o r ( e a c h r e q u i r e d - r e s o u r c e R ) [ I F ( R i s n o n - r e u s a b l e ) d e l e t e n o n - r e u s a b l e r e q u i r e d r e s o u r c e s ; E l s e r e l e a s e r e u s a b l e r e q u i r e d r e s o u r c e s 3 s t a t u s ( A p ) = d o n e ; C o m p u t e - S t a t u s ( s u p e r t a s k ( A p ) ) ; F o r ( e a c h o f t h e s u c c e s s o r s A p l o f A p ) [ C o m p u t e - S t a t u s ( A p l ) 3 3 . 1 2 S t o p - A c t i v i t y ( A p ) : P r e c o n d i t i o n : S t a t u s ( A p ) = A c t i v e & A p != S y s t e m - A c t i v i t y O p e r a t i o n : S t a t u s ( A p ) - S t o p p e d ; / * o t h e r s y s t e m a c t i v i t i e s f o r b r a n c h a n d i t e r a t i o n a r e o m i t t e d * / The described process driver can be executed in several ways by various appli cations. Two different applications th a t interact w ith the process driver have been im plem ented w ithin the A rticulator. The first one is process sim ulation. It contains models of developers and th eir anticipated ways of perform ing developm ent tasks. These models are used to execute the process driver, to provide m odeled developm ent behavior, and to sim ulate SPM enactm ent in a m odeled developm ent setting. T he second one is a process-centered user interface [68]. It provides a developm ent envi ronm ent for software developm ent to execute the process driver and enact software 114 Activity Al+M A c t i v i t y A1 A c t i v i t y |A2+Mf » . c t i v i t y A2 A c t i v i t y / a N+M AttivitV AN \ TimeN TimeN+1 TiraeN+2 TimeN+M Figure 6.3: SPM Sim ulation processes. It also provides m echanism s for enacting workspace, product resource, tool integration and invocation, which are necessary to perform developm ent tasks. 6.3 SPM Simulation SPM sim ulation begins w ith a set of agents. These agents are assigned to a set of SPM s to be sim ulated. At th e same tim e, a set of resources is also provided as its initial resource allocation. Some of these resources will be consum ed during SPMi sim ulation. O thers will only be used and returned. B ut all resource allocations] are subject to conflicts due to internal com petition in th e SPM s. SPM simulation' starts w ith all statu s of th e SPM s are set to be a llo c a te d . A sim ulation state isj defined as a step when all defined agents perform a single activity assigned to them . Therefore, a set of consecutive states from sta rt to end constitutes a sim ulated history or trajectory. Figure 6.3 gives a general description of SPM sim ulation. In th e figure, Tim e-N, Tim e-N +1 are states and lines represent activities. Activities use some resources which are represented as circles. O verlapping circles in d icatJ resource requirem ent conflicts, which can be resolved either through scheduling or articulation, as explained later. T here are several requirem ents to be observed during SPM sim ulation: 115 1. T he assignm ent of tasks to agents is stable, if not otherw ise explicitly changed. T his is to say th a t all th e agents m ust perform their assigned tasks. 2. A t any tim e step, an agent can not perform two activities sim ultaneously. B ut an agent m ay perform several tasks concurrently during a period. 3. At any tim e step, an agent cannot work on m ore tasks th an its supply of available resources allow. 4. E nactm ent sem antics discussed earlier m ust be followed which define th e kinds of preconditions and constraints. T he following is an algorithm ic description of process sim ulation: S t a r t - E n a c t m e n t ( ) ; s i m u l a t i o n - s t e p = 0 ; D o U n t i l ( s i m u l a t i o n - s t e p - e n d - s t e p ) ( s i m u l a t i o n - s t e p + + ; D o ( a m o d e l e d d e v e l o p e r D ) [ I f ( m a i l - a r r i v e d ) R e a d - M a i l ; I f ( m o r e - t a s k - a r r i v e d ) A g e n d a - T a s k ( n e w - t a s k s ) ; I f ( R E ( A p ) = HULL) [ I d l e ] E l s e [ A p = S e l e c t - A c t i v i t y ( R E ( A p ) ) ; I f ( S t a t u s ( A p ) = b r o k e n ) C A r t i c u l a t e ( A p ) ] E l s e [ S e l e c t ( A p ) [ C a s e A p i s n e w : S t a r t - A c t i v i t y ( A p ) ; C a s t A p i s c o n t i n u o u s : C o n t i n u e - A c t i v i t y ( A p ) ; C a s e AP i s e n d i n g : F i n i s h - A c t i v i t y ( A p ) ] ] ] ] ] E n d - E n a c t m e n t ( ) ; In th e algorithm , there are some newly defined system activities. R e a d - M a i l ac cesses th e agent’s m ailbox, retrieves newly arrived messages from other agents, and inform s th e agent. A g e n d a - T a s k arranges th e agent’s agenda according to the newly assigned SPM s and th e agent’s t a s k - e x e c u t i o n - s t r a t e g y . S e l e c t - A c t i v i t y se lects an activity to be enacted next according to th e agent’s t a s k - e x e c u t i o n - s t r a t e g y , such as f i n i s h - o n e - F I F S , which are defined in C hap ter 3. SPM sim ulation starts from th e initial stage and sim ulates the agents’ activities perform ing their assigned tasks. SPM enactm ent is accom plished by sim ulating 116 th e execution of the SPM in top-down fashion. T he higher levels of an activity hierarchy provide inform ation about work assignm ent and resource allocation. The lower levels of th e activity hierarchy provide links to procedural definitions which are executable in order to create new states. At each sim ulation step, sym bolic execution! first propagates th e necessary inform ation from higher levels to lower ones, checking constraints of an activity, and then invoking th e associated procedural definition toj propagate changes which impose modified or new constraints. All th e changes m ade by different agents are then com bined to form a new state in th e sim ulation. Twoj things condition the new state and SPM sim ulation. F irst, each agent selects the executing activity of its own choice. T he selected activity m ust be am ong its current work assignm ents. T he choice can be influenced b u t not determ ined by outsiders] Second, there are probably conflicts in resource requirem ents and th e changes which need to be solved through articulation (discussed in th e next chapters). P art of th e symbolic execution of an activity is shown in Figure 6.4, where th e rule gets an agent and its agenda, finds its current activity, and starts to execute th e activity symbolically. T he final result of SPM sim ulation is a trajecto ry over a period of tim e, in which every activity of th e tasks is perform ed once by a subset of th e agents in a simu-j lation state. Trajectories can be m ade persistent and evolvable. These trajectories can be subsequently studied according to different criteria in order to analyze in form ation about task perform ance, such as th e agents’ behavior during execution, th eir productivity, resource utilization, alternative “w hat-if” scenarios, and other interesting properties. However, SPM sim ulation is not guaranteed to finish success fully. Problem s m ay rise due to unexpected events th a t need to be articulated, or to have resources re-allocated. A rticulation of SPM sim ulation also affects th e above criteria and th eir consequences can be tracked as well. In C hapter 9, an exam ple to^ dem onstrate th e way process sim ulation works and its outcom e will be provided. Based on th e A rticulator m eta-m odel, m any types of agents and tasks can be- specified in an SPM . This m eans th a t SPM sim ulation can be divided into several types according to th e num ber of involved agents, and tasks shown in Table 6.2. For exam ple, SPM sim ulation can be used to sim ulate a group of agents who perform a set of concurrent SPM s on a set of available resource over a long tim e period. 117 ;; run the current activity. The rule selects the agent, its agenda, and ;; its current activity as the conditions. It then starts execution ( p R u n - a c t i v i t y : c o n t e x t t ( IN D IV ID U A L-A G E N T “ i n s t a n c e < > ( ) “ s c h e m a - n a m e < a g e n t > “ c o n t r o l l e r - g o a l C o n t r o l l e r - a c t i v i t y - c h e c k e d " a g e n t - h a s - a g e n d a < a g e n d a > ) (AGENDA “ i n s t a n c e < > ( ) “ s c h e m a - n a m e < a g e n d a > " c u r r e n t - s l o t < c - s l o t > “ t i m e - s l o t - a l l o c a t i o n < s l o t s > ) (A C T IV IT Y “ i n s t a n c e < > ( ) " s c h e m a - n a m e < a c t i v i t y > “ s c h e m a - n a m e ( s e l e c t - c u r r e n t - a c t i v i t y < > < s l o t s > < c - s l o t > ) ) — > ( f o r m a t t ‘ ‘ S t a r t t o e x e c u t e a c t i v i t y " A " & ’ ’ $ < a c t i v i t y > ) ( n e w - v a l u e $ < a g e n t > ’ c o n t r o l l e r - p a r a m e t e r l ( c u r r e n t - p - 1 $ < s l o t s > $ < c - s l o t > ) ) ( n e w - v a l u e $ < a g e n t > 1c o n t r o l l e r - g o a l ’r u n - a c t i v i t y ) ) Figure 6.4: A Sim ulation Rule for An A ctivity by Individual-A gents Type # of Agent # of Task Agent vs Task Agent vs Activity Simple-single One One One - One One - Many Multi-tasking One Many One - Many One - Many Multi-agent Many Many One - Many One - Many Coop-single Many One Many - One One - Many Collect-single Many One Many - One Many - Many Collect-multi Many Many Many - Many Many - Many Table 6.2: Types of SPM sim ulation 118 6.4 Summary In this chapter a type of dynam ic analysis called process sim ulation was presented. F irst, th e enactm ent sem antics of SPM s provide a set of constraints for SPM en actm ent and sim ulation, as well as a set of rules th a t tran sit an SPM from sta rt to com pletion. These sem antic rules form th e basis for SPM enactm ent and sim ulation. O perationally, sim ulation of SPM s is a realization of th e enactm ent sem antics in a hypothetical situation. Thus, SPM sim ulation was described next. T he purposes of sim ulation are to estim ate resource requirem ents and usage for an SPM , and to arrange necessary task execution sequence to ensure the success of SPM enactm ent. F urtherm ore, since process sim ulation is designed to support m ultiple agents and m ultiple interacting tasks, it handles complex situations very well. Some process sim ulation exam ples will be discussed later in the case studies. A rticulation, another type of dynam ic analysis supported by th e A rticulator, deals w ith breakdowns th a t occur during SPM sim ulation and enactm ent. Its p u r poses are to identify solutions to the breakdowns, and to im plem ent a selected so lution for SPM sim ulation or enactm ent to continue. In th e next two chapters, a knowledge representation of articulation and process of articulation will be pre sented. 119 Chapter 7 Articulation Specification Having presented th e A rticulator m eta-m odel, static analysis, and sim ulation of SPM s, the focus of discussion can now tu rn to process articulation. Process ar ticulation, as identified earlier, is a dynam ic process repair m echanism to resolve breakdowns during SPM enactm ent. It is p art of th e dynam ic analysis of SPM s th a t supports th e recovery of broken SPM enactm ent. This exam ination of process artic ulation is divided into two chapters: th e first describes th e representation of artic ulation knowledge, and th e second describes th e im plem entation of th e articulation process. T his chapter presents the representation of articulation knowledge, which is an abstraction of dom ain knowledge about process breakdowns and articulation m ethods. It is abstracted from and the em pirical studies of software developm ent surveyed in C hapter 2 and from experience during developm ent. T he representation of articulation knowledge consists of knowledge of process breakdowns, knowledge of articulation m ethods, and knowledge of re-scheduling. It is represented as an object-oriented m odel th a t follow th e A rticulator m eta-m odel. 7.1 Introduction As observed in Section 2.2, articulation is a kind of knowledge intensive work th a t recovers SPM enactm ent from process breakdowns. T h at sam e section identifies the m ajor stages of articulation as diagnosing, recovery, and re-scheduling, as well as commonly observed articulation m ethods. In this chapter, various forms of dom ain knowledge needed in articulation are brought together and th en form alized into an object-oriented model. 120 A rticulation Knowledge The Problem Space The Solution Space Selection H euristics Re-scheduling Knowledge- > Type of Breakdown Usage of Problematic Resource * Existence of Resource Producers > Type of Operation > Target Resource Usage * " Operand Resource Usage *• Operand Instance A pplicability H euristics > Global Preference H euristics Circum stantial Preference H euristics A ctivity Re-scheduling Constraints Resource Re-scheduling Constraints 1 A ctivity Re-scheduling H euristics Resource Re-scheduling H euristics Figure 7,1: R epresentation of A rticulation Knowledge T he dom ain knowledge of articulation is divided and represented as several sep arate classes of objects: th e problem space and diagnosis, th e solution space and problem -solving heuristics, selection heuristics, and re-scheduling constraints and heuristics. Figure 7.1 shows the object hierarchy th a t represents articulation knowl edge defined in the A rticulator. • T he problem space represents knowledge about process breakdowns. It consists of types of breakdown, usage of the problem atic resource in an activity, and existence of a production chain th a t produces the problem atic resource. D i agnosis is an object class to store values of the problem space for a particular process breakdown. 121 • T he solution space stores articulation m ethods called problem-solving heuris tics. T he solution space is indexed by four dim ensions th a t characterize the problem -solving heuristics. These four dim ensions include th e type of problem solving operation, target resource usage, operand resource usage, and operand resource instance. • Selection heuristics represent knowledge for using problem-solving heuristics under different circum stances. They consist of applicability heuristics th a t describe when a problem-solving heuristic can be applied to certain process breakdowns, global preference heuristics th a t describe global and constant preference in selecting problem-solving heuristics, and circum stantial prefer ence heuristics th a t describe circum stantial and changing preference in select ing problem -solving heuristics. • Re-Scheduling constraints and heuristics represent knowledge needed to re schedule SPM s under changing circum stances. Re-Scheduling constraints de fine scheduling restrictions, while re-scheduling heuristics state rule-of-thum b m ethods to select activities and resources to be scheduled. In th e following sections, these knowledge representations are presented in detail. 7.2 The Problem Space and Diagnosis The problem space is an abstraction of problem s caused by various types of break down situations. Once a breakdown occurs, th e A rticulator interprets it by finding its corresponding position in the problem space. T he problem space consists of three dimensions: (i) ty p e of breakdown, (ii) use of a problem atic resource, and (iii) exis tence of th e production chain for a problem atic resource. Together, these dimensions characterize a breakdow n situation. Each dim ension has a set of values. Along w ith each value, other inform ation m ay be attached. These dimensions, th eir values, and im plications are explained next. 122 7.2.1 T h e T y p e o f B reak d ow n s T he types o f breakdowns describe th e nature of breakdowns. Its values are types of breakdowns commonly seen during SPM enactm ent and recognized by th e A rticula tor. These values represent dom ain breakdowns for SPM s. A dom ain breakdown [33] is a problem th a t can be characterized in term s of th e operators and states in a dom ain. In th e dom ain of software developm ent, th e operators are activities and th e states are statu s for resources such as agents, tools, and software docum ents. Currently, seven types of breakdow n can be identified, each of which represents a particular class of problem s in a problem atic SPM: • I n c o m p l e t e - R e s o u r c e : Products are not created, or subtasks are not finished when SPM enactm ent is com plete. This type of breakdow n comes out of the assum ption th a t every subtask in an SPM contributes to th e overall objective of th e SPM . Failing to com plete any p art of an SPM , either its subtasks or products, results in failing to achieve the overall SPM objective. Consider the D e v e l o p - C h a n g e - a n d - U n i t - T e s t process m odel discussed in C hapter 5. If activity T e s t - U n i t is left unfinished when SPM enactm ent is com plete, this is considered as a breakdown of i n c o m p l e t e - r e s o u r c e . • R e d u n d a n t - R e s o u r c e : U nnecessary products are created, ex tra required re sources are allocated, or unnecessary subtasks are included. Here, unnecessary m eans resources are used or created for reasons th a t are not related to the ob jective of the SPM . In this sense, unnecessary products are often by-products of a SPM and unnecessary tasks are those th a t only produce unnecessary re sources. A lthough by-products are useful sometim es, they should be avoided in general. T he same is tru e for subtasks th a t produce only by-products. For exam ple, if it turns out th a t only one D e s i g n - E n g i n e e r is needed to com plete M o d i f y - D e s i g n , the ex tra requirem ent for a S o f t w a r e - E n g i n e e r causes a breakdow n of r e d u n d a n t - r e s o u r c e . • N o - R e s o u r c e - R e q u i r e m e n t : a resource is used in SPM enactm ent, b u t it is not specified in the resource requirem ents of th e executed activity. W hen such a unspecified resource instance is used, chances are th a t it is either not authorized or not properly scheduled. Problem s therefore occur. For exam ple, if agents 123 w ant to bring one m ore D e sig n -E n g in e e r to th e activity M odify-D esign,! this is considered a n o - re s o u rc e -re q u ire m e n t breakdown since no resource requirem ent is set for the ex tra D e s ig n -e n g in e e r and no allocation has been m ade. • N o - R e s o u r c e - P o s s e s s i o n : a resource requirem ent does not possess m inim um resource instances needed when an activity starts. This situation is th e op posite of th e previous one. Here, no resource instances are allocated ac cording to a resource requirem ent. Consider starting M o d i f y - D e s i g n w ith out any S o f t w a r e - E n g i n e e r . This violates th e resource requirem ents in M o d i f y - D e s i g n . • I n a d e q u a t e - R e s o u r c e - M a t c h : a resource possession does not m atch its corre sponding resource requirem ent although th e num ber of resources m atch. Both th e class m atch test and th e detailed qualification test are used to m ake sure th a t a m atch is adequate. So if either of the tests fail, a breakdow n occurs. Class m atch tests m atch the class of allocated resource instance to th e class of their corresponding resource requirem ent. Qualification tests are often domain- specific and should be provided by dom ain experts, if possible. For exam ple, this type of breakdown occurs if the process planner assigns a Q A - E n g i n e e r instead of S o f t w a r e - E n g i n e e r in M o d i f y - D e s i g n . The latte r role requires a different set of professional skills th an th e former. • R e s o u r c e - P o s s e s s i o n - O c c u p i e d : a possessed resource assigned to an activ ity is currently being used when the activity starts. Therefore, th e resource instance is not available for use by the activity. Normally, these types of break downs are th e results of conflicts in resource usage where a resource instance is allocated to several subtasks sim ultaneous, but physically it is impossible to do so. Let us consider th a t when M o d i f y - D e s i g n starts, Doug, th e assigned S o f t w a r e - E n g i n e e r , is actually perform ing another assignm ent th a t prevents him from joining th e activity. So a breakdow n of R e s o u r c e - P o s s e s s i o n - O c c u p i e d occurs. A m ajor issue to be resolved here is to have an increm entally updated working schedule for th e assigned agents and to arrange these activities w ithout conflict. 124 • R e s o u r c e - P o s s e s s i o n - B r o k e n : a possessed resource assigned to an activity does not function correctly when the activity starts. Therefore, the resource instance is not available for use. Consider th e exam ple of M o d i f y - D e s i g n ' again. Say at this tim e John is sick and will not come to work for a while. Therefore, a breakdow n of R e s o u r c e - P o s s e s s i o n - B r o k e n occurs. In com par ison to the previous case, a m ajor issue here is to find a replacem ent for John w ithin organizational lim itations. 7 .2 .2 T h e U sa g e o f A P r o b le m a tic R eso u rc e T he next dim ension is th e usage o f a problematic resource or resource requirement in a broken activity. A problematic resource is one th a t causes th e breakdow n and becomes th e object to be fixed or replaced. Different uses of resources in th e A rtic ulator not only indicates th e way a resource is used, b u t also influences th e way it is fixed when a breakdown occurs. For exam ple, agents norm ally arrange th e accessj rights for tools w ith th eir owners, while they negotiate directly w ith other agents about work assignm ent. Normally, finding th e required agent can be m ore difficult! th an finding a required raw m aterial or tool. Different resource usage also implies different sets of a ttrib u tes as well as inform ation to access and to provide. To this^ end, an agent instance provides a set of attrib u tes for knowledge, skills, and task; assignm ents while th e same instance, when used as a provided-resource, is mainlyj associated w ith its producers and producing subtasks. In th e A rticulator, a resource can be used in five different ways: • A c t i v i t y . An activity instance, as defined earlier, has a ttrib u tes th a t describe its activity hierarchy, resource requirem ents and resource possession. These- attrib u tes and th eir associated values are of prim ary interests when a resource is accessed as an activity. For a resource to be used as an activity, it m ust be an instance of class of t a s k or a subclass of t a s k . • A gent. W hen a resource instance is used as an agent, th e A rticulator basically focuses on th e capability th a t define an agent’s skill and knowledge of task perform ance, which are specified in a set of related attrib u tes defined earlier. 125 For a resource to be used as an agent, it m ust be an instance of class of a g e n t or a subclass of a g e n t. • T ool. T he prim ary concern for a tool usage is to be available when needed. T he availability of a tool is defined in two aspects: first, its usage is p r o p - j erly scheduled; second, its invocation can be autom atically configured w ithin th e scope of an SPM w ith the help of a underlying d a ta integration mecha-j nism when SPM enactm ent starts. T he A rticulator m eta-m odel arranges the proper use of tools to avoid scheduling conflict. For a resource to be used as a tool, it m ust be an instance of class of s im p le - re s o u r c e or a subclass of s im p le -re s o u rc e . • R e q u ire d -re s o u rc e . A required resource is input to an activity th a t is con sum ed as th e activity is perform ed. Its actual usage in an activity is sim ilar to th a t of tool usage in term s of scheduling and controlling. B ut further clarifica-j tion can be m ade for a required resource as for its reusability. A non-reusable i required resource disappears after it is used in an activity. A reusable required resource can be re-assigned to other SPMs when it is released. Any resource^ instance can be used as a r e q u ir e d - r e s o u r c e . • P ro v id e d -re s o u rc e . A provided-resource is a product from an activity and will later be used as a required resource by other tasks or SPM s. A ltogether, r e q u ir e d - r e s o u r c e s and p r o v id e d -r e s o u r c e s form a resource production chain th a t transform s raw m aterials into a final product. Specifications of this production chain enable us to reason about resources [95] and to gatherj valuable insights about an SPM such as its objective and resource requirem ents at a m om ent. Any resource instance can be used as a p ro v id e d -re s o u rc e . 7 .2 .3 T h e E x iste n c e o f A P r o d u c tio n C h ain T he last dim ension is th e existence o f a production chain with a problematic re source. A production chain consists of activities th a t create or m anipulate some resources. If one of th e resources is not in its working status, chances are th a t som ething m ay be wrong w ithin its production chain, i.e., th e resource is not pro duced correctly. Therefore, the production chain should be repaired. Consider the 126 D e v e l o p - C h a n g e - a n d - T e s t - U n i t . The original S y s t e m - D e s i g n - D o c m ust be m od ified in M o d i f y - D e s i g n before it can be used subsequently in M o d i f y - C o d e . If a S o f t w a r e - E n g i n e e r finds th a t S y s t e m - D e s i g n - D o c rem ains unchanged, he needs to check w ith th e D e s i g n - E n g i n e e r who is responsible for M o d i f y - D e s i g n . It mayj tu rn out the D e s i g n - E n g i n e e r forgot to save th e new code and m ust redo th e M o d i f y - D e s i g n . It is also possible th a t no production chain exists w ithin a SPM' w here a problem atic resource belongs, so there m ust be an external production chai J th a t introduces th e problem atic resource into the SPM. T he values for this dimension! are: • I n t e r n a l represents the existence of an internal production chain which pro duces the involved problem atic resource. In this case, this production chain is identified and saved. • E x te r n a l m eans no internal production chain exists. T he involved problem atic resource m ostly likely comes from outside through purchase or other form J of introduction. Som etim es, it is necessary to identify either the interface for th e external activity or the external production chain th a t introduces th J problem atic resource into an SPM. Table 7.1 lists th e three dimensions in the process breakdow n problem space. Having values for all the three dimensions in the problem space gives a clear taxo nom ic description which can be used to classify process breakdow ns, and thereforej m akes it possible to suggest solutions to fix it. In this regard, seventy types of process breakdow n situations are identified in th e cross product of seven breakdown! types, five resource usages, and tow production chains. F urther, this taxonom y and! its dim ensions can be easily expanded as new types of breakdow n situations are^ identified. Knowledge of breakdow n situations represented in the problem space is formally represented as a class of objects called d ia g n o s is . Definitions of d ia g n o s is includes th e th ree dim ensions in the problem space as well as related inform ation. Figure 7.2 shows the schem atic definition of d ia g n o s is and an exam ple instance which is taken from an exam ple discussed in th e next chapter. 127 B rea k d o w n T ype U sage o f R esou rce P ro d u ctio n C h a in Incom plete- Resource R edundant-R esource N o-Resource- Requirem ent N o-Resource- Possession Inadequate-R esource-M atch R esource-Possession-O ccupied R esource-Possession- Broken A ctivity A gent Tool Required- Resource Provided-R esource E xternal Internal Table 7.1: Dimensions of th e Problem Space {{diagnosis is-a: related-breakdown: breakdown-type: problematic-resource: problematic-resource-spec: problematic-resource-usage: problematic-resource-class: other-instances-of-req: latest-provider: others-providers: { { diagnosis-12+12 instance: related-breakdown: breakdown-type: problematic-resource: problematic- resource-requirement: problematic-resource- usage: problematic-resource-class: other-instances-of-req: problematic-resource-source: latest-provider: articulation-object [breakdown] [breakdown-type] [broken-resou r ce] [match-resource-spec] [resource-usage] [resource-class] [resource-instances] [production-chain] [production-activity] } } diagnosis breakdown-12+11 Inadequate- Resource-Match System- Design-Do c Required-for-Modify-Code required-resource System-Design-Doc-Class nil Internal Modify-Design}} Figure 7.2: Definition of D ia g n o s is 128 From th e point of view of understanding a breakdow n situation, th e diagnose sub-process discussed in th e next chapter identifies proper values of the problem space for a given breakdown situation. 7.3 The Solution Space T he solution space in th e A rticulator m eta-m odel is an abstraction of articulation, m ethods th a t recover breakdowns. In th e solution space, a recovery m ethod is called a problem-solving heuristic (PSH) which are indexed through four dim ensions in the solution space. T he four dim ensions in the solution space are designed to m ake these characteristics explicit. T he four dimensions for the solution space are: (i) type of operation; (ii) target resource usage; (iii) operand resource usage; and (iv) operand resource instance. In this section, these dim ensions are first explained as characteristics of PSHs and then th e functionality of th e PSH s is discussed. 7.3.1 T h e S o lu tio n S p ace T he solution space is an abstraction of articulation m ethods th a t recover from a breakdow n situation. In the solution space, articulation m ethods are categorized' and indexed according to four dimensions: the type of operation, th e targ et resource usage, th e operand resource usage, and the operand resource instance. F irst, th e type o f operation indicates operations th a t are used to fix a breakdown. These types represent abstracted articulation m ethods identified through em pirical studies. They range from finding alternative resources to adding new activities. Functionally, they im plem ent stru ctu ral or non-structural changes in an SPM . An operation th a t modifies the definition of the original SPM is called structural, while an operation th a t only involves reassignm ent of resource instances to th e SPM isj non-structural. W hile th e consequences of selecting one of these operations will be discussed in th e next section, this section focuses on th e operations them selves. C urrently, seven types of operation are defined: • R e p la c e -in s ta n c e replaces a problem atic resource instance by another in stance of th e sam e class. This m ethod is useful when a resource instance is 129 not available during its assigned subtask. Normally, r e p l a c e - i n s t a n c e is non-structural and imposes m inim um changes to an SPM . • R e p l a c e - c l a s s replaces a problem atic resource by an instance from a func tionally equivalent class. Its use is sim ilar to th e first m ethod above, but involves search for a functionally equivalent resource. R e p l a c e - c l a s s causesj stru ctu ral changes to an SPM if resource requirem ents are modified. In this case, an object class in resource requirem ents is replaced by an equivalent orj sim ilar object class in order to find available instance of the new class to be used. • R e s t r u c t u r e changes th e task hierarchy so th a t a breakdow n can be elim i nated. This includes operations such as add, delete, and reconfigure activities an d /o r resources. Some of these operations include com binations of re-planning actions suggested in [33, 95, 96]. R e s t r u c t u r e is always structural. • M o d i f y - v a l u e changes attrib u te values of concerned resources or activities. An exam ple of this type of operation is to change th e work span of an activ ity. M o d i f y - v a l u e is norm ally stru ctu ral since it modifies definitions of some aspect of an SPM . • R e d o - a n d - r e v i e w redoes a problem atic activity, o r its predecessor activity, and adds a review activity to m ake sure it is done correctly. It is useful when an activity does not produce its p r o v i d e d - r e s o u r c e s as expected. R e d o - a n d - r e v i e w imposes structurally a special p attern of activity hierar chy into p art of an SPM . It is created because m any occasions are encoun tered when it is necessary to have iteration in SPM s. In these occasions r e d o - a n d - r e v i e w is th e p attern m ost of SPMs are likely to have. • S p l i t - o r - m e r g e decomposes a task into a set of subtasks to create another layer of detail, or merge a group of subtasks into a supertask. This type ofi operation can be used to expand an SPM into one m ore level of decom position. It is stru ctu ral by nature. • O t h e r s are m ethods th a t do not involve SPM changes or resource configura tion. They include (1) wait, (2) give up a problem atic resource requirem ent 130 and its associated possession, and (3) re-negotiate the use of a problem atic resource instance. This group of operations does not represent m eaningful re-j planning actions as SPM s are concerned structurally. B ut in practice these m ethods are often applied. T he types of operations defined here is a richer set of re-planning actions than those in dynam ic planning m echanism s, such as [33, 96], for three reasons: F irst, the A rticulator m eta-m odel has expanded its form al representation to separate resource requirem ents w ith resource possession. This representation allows m ore types of breakdow n situations and m ore options th a t can resolve these breakdowns. Second] th e types of operations here include practical m ethods observed in em pirical studies.1 Theoretically, some of them m ay not represent re-planning actions, b u t practically] they are valid m ethods to use in certain situations. Therefore, these practical meth-j ods are included in th e types of operations defined here. T hird, also included are some aggregations of re-planning actions. T he aggregations included are th e pattern s which, when used in com bination, can effectively resolve some particular problems] An exam ple of th e aggregations is re d o -a n d -re v ie w which is frequently used to add necessary iteration to SPMs. In sum, by adding m ore sem antically aggregated types of operation, th e A rticulator m eta-m odel provides m ore powerful solutions to breakdow n situations. | T he second dim ension identifies th e intended resource, called a target usage, to be fixed by the chosen operation. It is the objective of th e chosen operation. TheJ A rticulator supports th e five resource usage to define this dim ension as discussed earlier: A ctivity, A gent, Tool, Required-resource, and Provided-resource. W hen a PSH is m atched to a diagnosis, its target resource usage has to m atch th e usage of a problem atic resource in the diagnosis. In this way, th e PSH is able to resolve th e breakdown as intended. T he last two dimensions of the solution space concern an operation’s operands. T he Operand usage gives th e class of the operand and the operand provides th e exact operand used in an operation. Values for an operand usage are again the five types of resource usage: A ctivity, Agent, Tool, Required-resource, and Provided-resource. T he operand resource instance refers to a resource instance th a t is used in an operation to recover from a breakdown. Values for an operand instance are: 131 T ype o f O p era tio n T arget U sage O p era n d U sage O p era n d Replace-i ns t ance R eplace-class R estructure M odify R edo-and-review Split-or-m erge Others A ctivity Agent Tool Required-resource Provided-resource A ctivity A gent Tool Requi red- resource P rovided- resour ce E xisting-self E xisting-other New Table 7.2: Dimensions of the Solution Space • e x i s t i n g - s e l f for a problem atic resource or a problem atic resource require m ent itself. • e x i s t i n g - o t h e r for using another existing instance/class. • n e w for creating a new instance/class. Table 7.2 lists th e dimensions in th e solution space and their defined values. 7 .3 .2 P r o b le m -S o lv in g H e u r istic s As noted earlier, th e dimensions in th e problem space reflect characteristics of PSHs. A tem plate of all four dim ension values indexes to a particular PSH. For exam ple, P S H l : C r e p l a c e - i n s t a n c e , r e q u i r e d - r e s o u r c e , r e q u i r e d - r e s o u r c e , e x i s t i n g - o t h e r > and P S H 2 : < r e d o - a n d - r e v i e w , r e q u i r e d - r e s o u r c e , a c t i v i t y , n e w > point out two PSHs th a t can be used to repair a breakdow n situation whose di agnosis is associated w ith required-resources. P S H l searches for another copy of a problem atic required-resource and replace it by the new instance. On the other hand, PSH2 adds m ore activities to m odify th e problem atic required-resources. A legal position in th e solution space is such a tem plate of four values pointing, to a valid class of PSHs. Therefore, th e collection of all classes of PSHs is indexed^ to th e collection of all the legal positions in the solution space. However, not allj com binations in th e solution space represent a valid PSH class. Only a subset of these com binations are legally defined. All together, 35 legal positions and 35 classes of PSHs are defined in the following form at: 132 {{problem -solving-heuristic is-a: heuristic applicable- to- di agnosi s : [diagnosis] type-of-operation: target-resource-usage: operand-resource-usage: operand-resource-instance: if-re-schedule: re-scheduled-activities: post-processing: suggested-repair-heuristics: im plem entation: [operation-type] [resource-usage] [resource-usage] [operand-type] y e s/n o [subtasks] yes / no [repair-suggestion] [pointer-to-rule-set] } } Besides th e dim ensions in the solution space, the definition of p r o b le m - s o lv in g - h e u r is tic also includes attrib u tes for re-scheduling and repair purposes. A ttrib u te im p le m e n ta tio n in th e definition is a pointer to th e set of in ference rules th a t realizes the functionality of th e PSH. For exam ple th e algorithm ic description of the above PSH2 is given in Figure 7.3. PSH2 represents a com bination of re-planning actions th a t creates a pair of activities and inserts to th e broken SPM O ther defined PSHs are im plem ented in sim ilar fashion as inference rules. {{PSH2 is-a: appli cable-to- diagnosi s: problem -solving-heuristic [diagnosis] type-of-operation: target-resource-usage: operand-resource-usage: operand- resour ce-i ns t ance: if-re-schedule: re-scheduled-activities: post-processing: suggested-repair-heuristics: im plem entation: redo- and-review required-resource activity new yes [subtasks] stop add-iteration redo-and-review -proc-1 }} T he A rticu lato r’s PSHs owe a great deal to research on plan repair [33, 96]. How ever, these PSHs are oriented to practical m ethods th a t are gathered from empirical studies [65], rath er than a collection of single re-planning actions. To this end, a PSH contains a set of sem antic changes th a t prove effective to a particular problem. Also, PSHs are organized such th a t a single breakdown can have m ultiple PSHs applied to it. 133 ( 1 ) C r e a t e a n o t h e r i n s t a n c e o f t h e a c t i v i t y t o b e r e d o n e ; ( 2 ) C r e a t e a new i n s t a n c e o f a c t i v i t y R e v ie w a n d a d d r e s o u r c e r e q u i r e m e n t s ; ( 3 ) L i n k t h e tw o a s a c t i v i t y ( 1 ) p r o c e e d s a c t i v i t y ( 2 ) ; ( 4 ) I n s e r t ( 3 ) i n t o t h e SPM j u s t b e f o r e t h e b r o k e n a c t i v i t y . Figure 7.3: A lgorithm ic D escription of R edo-and-R eview 7.4 Selection Heuristics S e le c tio n h e u r is tic s act as a bridge between diagnosis and PSHs. They help the selection sub-process in th e A rticulator m eta-m odel to locate a set of PSHs th a t satisfies a set of defined preference to fix a breakdown. T he selection sub-process th a t determ ines the chosen PSHs will be discussed in the next chapter. Two types of selection heuristics are defined in the A rticulator. A p p lic a b ility h e u r is tic s state th e classes of PSHs th a t are applicable to a class of diagnosis. P r e f e re n c e h e u r is tic s present developers’ preferences of PSH use under different circum stances, which are further divided into g lo b a l p r e fe r e n c e h e u r is tic s for overall or per-j sonal preferences over PSHs, and c ir c u m s ta n tia l p r e fe r e n c e h e u r is tic s for application of PSH s in various situations. Selection H euristics do not represent form al (theoretical) knowledge of articula tion. R ather, they are custom ized short-cuts indicating preferences of some PSHs under a given circum stance. From this point of view, selection heuristics only re-J duce th e search tim e needed to identify applicable PSHs before exhausting all th e possibilities. Due to this reason, only some of the selection heuristics have been im plem ented so far. Subsequently, use of selection heuristics is lim ited at this time! 7.4.1 A p p lic a b ility H e u r istic s A p p lic a b ility h e u r is tic s identify applicable PSHs for a diagnosis. They are partially collected from the result of the em pirical studies through th e observation th a t certain types of PSHs are used m ore often in some situations. A nother source of applicability heuristics is from th e functionality of th e defined operation types in th e solution space. Figure 7.4 lists an applicability heuristic in th e A rticulator which states th at 134 { { a p p h - 1 i s - a : a p p l i c a b i l i t y - h e u r i s t i c r e l a t e d - d i a g n o s i s : n o - s p e c - e x t e r n a l - a c t a p p l i c a b l e - p s h s : n o t - u s e - r e s o u r c e r e s t r u c t u r e - a d d - a c t i v i t y - n e w r e s t r u c t u r e - a d d - a c t i v i t y - e n h a n c e r e s t r u c t u r e - d e l - a l l - p o s s - f o r - a c t i v i t y r e s t r u c t u r e - d e l - a c t i v i t y - f o r - o t h e r s r e s t r u c t u r e - m o v e - a c t i v i t y » Figure 7.4: A Sample A pplicability H euristic th e set of PSHs defined in a ttrib u te a p p lic a b le - p s h s are applicable to th e diagnosis defined in a ttrib u te r e la te d - d ia g n o s is . T he current definition of applicability heuristics defines a m any-to-m any correspondence betw een diagnosis and PSHs in th e A rticulator. 7 .4.2 G lo b a l P r e fere n c e H eu r istic s Global preference heuristics describe global constraints or personal preferences over PSHs. They m ay exclude some PSHs under certain circum stances or ju st specify an order of PSH selection. Table 7.3 lists a sam ple set of global preference heuristics and their im plications. Some m ay be m utually exclusive, others m ay be m utually in-j elusive. Global preference heuristics are associated w ith agents indicating an agent’s preference in all possible circum stances. 7 .4 .3 C ir c u m sta n tia l P r e fere n c e H e u r istic s Circum stantial preference heuristics describe preferences over use of resources classes or instances under different circum stances. They m ay also include other local con straints. For exam ple, use of some resources can be prohibited at any given m om ent. C ircum stantial preference heuristics basically indicate under w hat circum stances (breakdowns situations) PSHs are m ore effective and therefore m ore preferable. Like global preference heuristics, circum stantial preference heuristics help to select PSHs^ before they are used to find solutions for breakdowns. However, circum stantial pref erence heuristics differ from global preference heuristics in th a t they depend heavily 135 N o. G lobal P referen ce H eu ristic s Im p lic a tio n s 1 Find a solution A solution is better than no solution 2 Find no solution No solution is better than a solution 3 Find best solution Best solution is preferred 4 Minimize extra work Solutions with less work 5 Maximize extra work Solutions with more work 6 Minimize work by self Solutions with less work by self 7 Maximize work by self Solutions with more work by self 8 Minimize work by others Solutions with less work by others 9 Maximize work by others Solutions with more work by others { { g l o b a l - p - h - 1 i n s t a n c e : g l o b a l - p r e f e r e n c e - h e u r i s t i c r e l a t e d - a g e n t : M ary p r e f e r : F i n d - a - s o l u t i o n M i n i m i z e - e x t r a - w o r k }> Table 7.3: A Sam ple Set of Global Preference H euristics on th e context of a developm ent situations, and m ay change dynam ically. O ther wise, use of circum stantial preference heuristics is sim ilar to th a t of global preference heuristics. Table 7.4 gives a sam ple set of circum stantial preference heuristics. 7.5 Re-Scheduling Constraints Re-Scheduling in the A rticulator is a dynam ic heuristic constraint-directed search [22, 52, 60]. Knowledge about re-scheduling is divided into two basic classes: N o. C irc u m sta n tia l H e u ristic s Im p lica tio n 1 Use local resources Local resources are easy to access 2 Use remote resources Remote resource have least local impact 3 Use same class Don’t have to evaluate a new class { { c i s - p - h - 1 i n s t a n c e : c i r c u m s t a n t i a l - p r e f e r e n c e - h e u r i s t i c r e l a t e d - a g e n t : M ary r e l a t e d - d i a g n o s i s : r e s o u r c e - p o s s e s s i o n - o c c u p i e d - e x t e r n a l - a g e n t p r e f e r : u s e - l o c a t e - r e s o u r c e u s e - s a m e - c l a s s » Table 7.4: A Sam ple Set of Circum stantial Preference Heuristics 136 re-scheduling constraints and heuristics. They are used to direct th e search for both th e candidate activities to be scheduled and th e candidate resources to be allocated. This section defines these definitions of re-scheduling constraints and heuristics. 7.5.1 S y n ta x o f R e -S c h e d u lin g C o n stra in ts an d H eu ristics Re-Scheduling constraints define a structural configuration of resources and activities as well as restrictions in using them . Re-Scheduling constraints in the A rticulator are defined w ith th e reference to th e related literatu re in the research field of pro duction scheduling [21, 77, 81]. Currently, the A rticulator supports three types of re-scheduling constraints: • Value constraints th a t define a value or a lim it for an o b ject’s attrib u te: { { v a l u e - c o n s t r a i n t i s - a : r e - s c h e d u l i n g - c o n s t r a i n t o b j e c t - c l a s s : [ r e s o u r c e - c l a s s ] a t t r i b u t e - n a m e : [ r e s o u r c e - a t t r i b u t e ] s p e c i f i e d - v a l u e : [ r e s o u r c e - a t t r i b u t e - v a l u e ] c o m p a r i s o n : n o n e / l a r g e r / s m a l l e r ]•}• T he attrib u tes o b j e c t - c l a s s , a ttr ib u te - n a m e , s p e c if ie d - v a lu e specify an a ttrib u te of an object associated w ith a predefined value. T he co m p ariso n a t trib u te defines how the actual value in th e specified a ttrib u te is com pared w ith s p e c if ie d - v a lu e if the re-scheduling constraint is satisfied. C om parison has1 three different defined values: Value none states th a t no com parison is needed.! Therefore as long as an object has a value in th e a ttrib u te , th e re-scheduling constraint is said to be satisfied. Value l a r g e r requires th e a ttrib u te ’s value to be larger th an s p e c if ie d - v a lu e in th e re-scheduling constraint in order to! satisfy it. Value s m a lle r has th e opposite result when com parison is made.; In sum, value constraints set a lim it for an a ttrib u te to satisfy. • Relational constraints th a t define relationship betw een objects: { { r e l a t i o n a l - c o n s t r a i n t i s - a : r e - s c h e d u l i n g - c o n s t r a i n t f i r s t - o b j e c t : [ s u b t a s k ] s e c o n d - o b j e c t : [ s u b t a s k ] » 137 Satisfaction of a relational constraint depends on th e direction of the re scheduling sub-process. If re-scheduling moves forward, the objects in s e c o n d -o b je c t are satisfied only when th e objects in f i r s t - o b j e c t are al satisfied. If re-scheduling moves backward, th e opposite is tru e for constraint satisfaction. • B oundary constraints th a t define a boundary for an a ttrib u te w ith high anc low values. { { b o u n d a r y - c o n s t r a i n t i s - a : o b j e c t - c l a s s : a t t r i b u t e - n a m e : a t t r i b u t e - v a l u e - h i g h : a t t r i b u t e - v a l u e - l o w : r e - s c h e d u l i n g - c o n s t r a i n t [ r e s o u r c e - c l a s s ] [ r e s o u r c e - a t t r i b u t e ] [ i n t e g e r [ [ i n t e g e r ] » A boundary constraint is satisfied when the a ttrib u te ’s value of a specifiec object falls betw een a t t r i b u t e - v a l u e - h i g h and a ttr ib u te - v a lu e - lo w . Exam ples of these re-scheduling constraints will be given later when activity and resource constraints are discussed. Re-Scheduling heuristics define experience-based criteria for selecting some con straints over others for re-scheduling. They are used in re-scheduling to reduce; search space and backtracking. Their definition, therefore, specifies both a set of re-scheduling constraints (as well as their related resources) to be selected and an algorithm ic way to order them . T he syntax of re-scheduling heuristics is defined as: { { r e - s c h e d u l i n g - h e u r i s t i c i s - a : a r t i c u l a t i o n - o b j e c t o p e r a t i o n : m a x /m in o p e r a t i o n - t y p e : v a l u e / n u m b e r o p e r a n d - c o n s t r a i n t : [ r e - s c h e d u l i n g - c o n s t r a i n t ] ]•]- A re-scheduling heuristic is used in conjunction w ith defined re-scheduling con straints. It orders a set of activities according to certain value in a defined re scheduling constraint. Such a value is defined in a re-scheduling heuristic as follows: T he o p e r a tio n attrib u te defines th e com parison to be m ade. Its value can either be| max for th e m axim um num ber, or min for th e m inim um num ber to be picked. The 138 o p e r a tio n - ty p e a ttrib u te defines how th e com parison is made: v a lu e indicates th a t values in an a ttrib u te are com pared; and number indicates th a t the com parison is m ade on th e num ber of values in an attrib u te, rath er than th eir actual values. The o p e r a n d - c o n s tr a in t attrib u te specifies a re-scheduling constraint to be com pared As an example: { { s m a l l e s t - s l a c k - t i m e i s - a : r e - s c h e d u l i n g - h e u r i s t i c o p e r a t i o n : m in o p e r a t i o n - t y p e : v a l u e o p e r a n d - c o n s t r a i n t : s l a c k - t i m e » This is a re-scheduling heuristic th a t picks an object who has the sm allest slack tim e defined in th e re-scheduling constraint s la c k -tim e . Exam ples of these re-scheduling heuristics will be given later when activity and resource heuristics are discussed. N ext, several types of re-scheduling constraints and heuristics defined in th e A rticulator are given. 7 .5 .2 R e -S c h e d u lin g C o n stra in ts Re-Scheduling constraints in the A rticulator are divided into a c tiv ity and re so u rc e c o n s tr a in ts th a t define lim itation for activities and resources respectively. • A c t i v i t y c o n s tr a in ts specify properties and lim its for activities. Several types of activity constraints have been defined such as duration, start-tim e, due-tim ej i predecessors, and successors. For exam ple, the definition of duration is defined, as: { { s t a r t - t i m e " i s - a : v a l u e - c o n s t r a i n t c o m p a r i s o n : l a r g e r a t t r i b u t e - n a m e : d u r a t i o n s p e c i f i e d - v a l u e : 3 } } • R e s o u r c e c o n s tr a in ts define relationships between objects. For exam ple, avail ability of a resource instance is represented as a boundary resource constraint: 139 { { r e s o u r c e - a v a i l a b i l i t y i s - a : b o u n d a r y - c o n s t r a i n t o b j e c t - c l a s s : r e s o u r c e a t t r i b u t e - v a l u e - h i g h : 10 a t t r i b u t e - v a l u e - l o w : 1 Re-Scheduling constraints can be updated dynam ically during re-scheduling so th a t they reflect the latest changes im posed by early steps in re-scheduling. 7.5 .3 R e -S c h e d u lin g H e u r istic s T he re-scheduling m echanism uses two types of re-scheduling heuristics to reduce th e search space and backtracking: • A ctivity search heuristics th a t direct th e selection of activities among all avail able candidates. Exam ples of activity search heuristics are: M inim um -slack— tim e -f i r s t which is equivalent to th e C ritical P ath M ethod. i E a r l i e s t - s t a r t - t i m e - f i r s t which selects activities in order of their specified start tim e (see th e definition below), and M ax im u m -n u m b er-o f-re so u rc e-req u ire m en t-f i r s t which chooses the activ ities w ith th e larger num ber of resource requirem ents first (see th e definition below). A set of activity search heuristics can be used as a group to filter the necessary selection. - f - C e a r l i e s t - s t - f i r s t i n s t a n c e : r e - s c h e d u l i n g - h e u r i s t i c o p e r a t i o n : m in o p e r a t i o n - t y p e : v a l u e o p e r a n d - c o n s t r a i n t : s t a r t - t i m e >} { ■ f m a x - n u m b e r - o f - r e q s i n s t a n c e : r e - s c h e d u l i n g - h e u r i s t i c o p e r a t i o n : max o p e r a t i o n - t y p e : n u m b e r o p e r a n d - c o n s t r a i n t : r e s o u r c e - r e q u i r e m e n t s » • Resource selection heuristics th a t direct th e selection of resource to satisfy resource requirem ents of activities. An exam ple is h ig h e s t - u s e - p r e f e re n c e which selects the resources w ith the highest levels of preference. 140 { { h i g h e s t - u s e - p r e f e r e n c e i n s t a n c e : r e - s c h e d u l i n g - h e u r i s t i c o p e r a t i o n : max o p e r a t i o n - t y p e : v a l u e o p e r a n d - c o n s t r a i n t : u s e - p r e f e r e n c e Besides th e set of system defined re-scheduling constraints and heuristics mentionec above, users can specify th eir own types of re-scheduling constraints and heuristics as subclasses of these. 7.6 Summary This chapter presents definitions of articulation object classes th a t represent both articulation knowledge and inform ation related to a particular articulation. These definitions provide a taxonom ic hierarchy for th e A rticulator to store breakdown situations, articulation knowledge, and related inform ation, which will be used sub-J sequently by th e articulation process. T he necessary definitions th a t define legal values for these objects and th eir attrib u tes are also presented. These definitions of articulation objects and necessary values provide a form al basis for the articu-j lation process to take place. T he next chapter describes a procedural definition of articulation. 141 Chapter 8 The Articulation Process This chapter provides a procedural description of articulation. This articulation process uses th e articulation knowledge defined in th e previous chapter. T he ar-j ticulation process consists of several sub-processes as including diagnosis, selection] recovery, and re-scheduling. These sub-processes are im plem ented as sets of forward-j chaining production rules, which m anipulate SPM instances and th eir surrounding situation. 8.1 Introduction To give an overview of the articulation process, th e integration of diagnosis, re planning, and re-scheduling can be understood as depicted in Figure 8.1. SPM enactm ent starts when a specific SPM is in stan tiated (called instantiation). A fter th e scheduling of its resources is com plete, enactm ent executes th e activities step by step, according to the defined enactm ent sem antics in Section 6.2. T here are two kinds of enactm ent: sim ulation is a symbolic SPM enactm ent whose purpose is to dynam ically analyze the SPM . T he other kind is th e real execution of SPM s by software developers whose purpose is to actually carry out th e developm ent and* to create a final product. The articulation process supports both kinds of SPM' enactm ent as either a research tool or a developm ent tool. Normally, process execution continues according to the specified execution order in th e SPM until all th e activities are finished. However, th e ongoing enactm ent of an SPM is blocked once a breakdown occurs. A rticulation, as em bodied in the' A rticulator, takes over and tries to recover th e enactm ent from th e breakdown. At 142 O rigin al SP M O rigin al S P M N ew S P M Solution Spac^ Problem Space S P M Repair Selection Instantiation Diagnosis Recovery Schedule Enactment Breakdown Enactment Instance Finished Instance Re-schedule Resources Articulation Figure 8.1: T he A rticulation Process this m om ent, inputs to th e articulation process are an executed SPM w ith allocatec resources, a broken activity in th e SPM , and an identified breakdown. T he articulation process consists of several sub-processes: diagnosis, selection of PSH s, recovery, and re-scheduling. T he diagnosis sub-process identifies possible causes for a breakdow n based on th e problem space described in th e previous chapter. From this point of view, the purpose of diagnosis is to locate a given breakdown in th e problem space according to the situation where the breakdown occurs. Once a diagnosis is identified, a solution m ust be created to resolve it. This stage is accom plished through indexing into the solution space and then selecting J pre-defined set of PSHs according to the selection sub-process. In other words, given 143 a position in th e problem space, the selection sub-process identifies a PSH w ith the help of selection heuristics. Constrained by the situated workplace, not all PSHs are applicable in the workplace at a given tim e. Also, due to knowledge lim itations,' agents m ay have different sets of PSHs available to them . Besides, there are also other preferences th a t lim it use of a particular PSH. All such issues of applicability and preference are abstracted into a set of selection heuristics. These heuristics are applied during PSH selection to determ ine which PSHs fit the situation well com pared to the others. T he next step is to apply th e chosen PSH to recover from th e breakdow n situ ation. D uring th e recovery sub-process, the chosen PSH is executed w ith a set of param eters, which define th e current situation gathered from diagnosis. Changes are then m ade in the broken activity, the SPM , a n d /o r th e related resource allo cation. Now th e breakdown is resolved as far as th e executed SPM is concerned. However, in some cases, this modified SPM can not be executed directly because th J original resource allocation m ay not be valid due to the changes. T he re-scheduling sub-process is then perform ed to rearrange the tim ing of changed resource usage] O therw ise, such changes m ay cause other breakdowns. Two o utputs result from articulation: a modified S P M instance and a repair suggestion. A modified SPM instance w ith allocated resources can th en be p u t into enactm ent. Therefore, SPM enactm ent, guided by the modified SPM , resumes. A ^ repair suggestion is forwarded to a user whose responsibility is to study sets of sucli suggestions in order to consider w hether the original SPM should be revised, or w hether th e breakdow n situation was idiosyncratic. This is called S P M repair. To sum m arize, the articulation process depends on th e interaction of following sub-process to accom plish its objective: • A diagnosis sub-process, based on the problem space, analyzes a given break down and creates a diagnosis of the breakdown situation. • A selection sub-process, based on the solution space and th e selection heuris tics, retrieves applicable PSHs for a diagnosis and chooses a suitable PSH from them according to th e given selection heuristics and th e current circum stances. 144 • A recovery sub-process invokes and executes th e chosen PSH from th e solution space to recover th e broken SPM instance and provides a suggestion to repair th e original SPM. • A re-scheduling sub-process dynam ically creates a p artial resource allocation for a specified period in response to changes in a recovered SPM instance and related resources. T he interaction of these sub-process is to exchange inform ation and to invoke designated others when one is com plete. This interaction is described in Figure 8.2 as a forw ard-chaining rule set and codified in 0 P S 5 . D etailed exam ples of thesJ sub-processes appear in the next chapter. N ext, im plem entation of these four sub-processes can be discussed, b u t manyj of th e im plem entation details will be skipped. However, these four sub-processes have all been im plem ented in 0 P S 5 , and are operating in th e A rticulator system.J These 0 P S 5 rules form a set of goal-driven modules as suggested by Schank [80] and Brow nston, et al. [9]. I 8.2 The Diagnosis Sub-Process Once a breakdow n occurs, diagnosis locates a position in th e problem space for the breakdow n situation. At th e same tim e, a necessary explanation is gathered to sup-j port th e diagnosis. To this end, diagnosis searches for a causal explanation th at will be form atted as directed by th e problem space. T he position of a breakdown will then be used as a pointer to th e solution space, which identifies a set of possible PSHs. Findings in diagnosis are sum m arized into a class of object called d ia g n o s is ] which serve as index to potential PSHs. A high level algorithm ic description of the diagnosis sub-process is given in Figure 8.3, which consists of determ ining the type of breakdow ns, determ ining resource usage for th e problem atic resource, and determ in ing th e production chain of the problem atic resource th a t created th e breakdown. W hen diagnosis starts, it first identifies the type o f breakdown by finding out answers to th e following questions: DQ1: I s t h e SPM e n a c t m e n t c o m p l e t e ? DQ2: I s t h e r e a p r o b l e m a t i c r e s o u r c e a s s o c i a t e d w i t h a b r e a k d o w n ? 145 Rule: start GOAL: Broken; CONDITION: SPM: M; Breakdown: A; ACTION: set GOAL diagnosis. Rule: diagnosis GOAL: diagnosis; CONDITION: Breakdown: A; ACTION: create Diagnosis: D-A; set GOAL selection. Rule: selection GOAL: selection; CONDITION: SPM: M; Breakdown: A; Diagnosis: D-A; ACTION: create Solution S-A; if succeed then set GOAL recovery; else abort. Rule: recovery GOAL: recovery; CONDITION: SPM: M; Breakdown: A; Diagnosis: D-A; Solution: S-A; ACTION: invoke S-A on M; if succeed then if S-A is structural then set GOAL re-schedule; else set GOAL end; else set GOAL selection. Rule: re-schedule GOAL: re-schedule; CONDITION: SPM: M; Solution: S-A; ACTION: re-schedule M; set goal end. Rule: end GOAL: end CONDITION: SPM: M; ACTION: set GOAL ready. Figure 8.2: Sub-Process Interaction in the A rticulation Process 146 No Yes s there an internal producer^ Identify Type of Breakdowns Create Diagnosis Trace the Internal Producer Activities Identify Usage of a Problematic Resource Figure 8.3: T he Diagnosis Sub-Process DQ3: I s t h e r e a p r o b l e m a t i c r e s o u r c e r e q u i r e m e n t ? DQ4: I s t h e r e a m a t c h b e t w e e n t h e p r o b l e m a t i c r e s o u r c e a n d i t s r e q u i r e m e n t ? DQ5: W hat i s t h e s t a t u s o f a p r o b l e m a t i c r e s o u r c e ? These questions are answered through both direct inform ation retrieval and de ductive reasoning, as provided by th e A rticulator. For exam ple, answers to DQ1 can be determ ined by gathering the developm ent status of each subtask in an SPM . On th e other hand, answers to DQ4 m ust be based on reasoning about relationships betw een the problem atic resource and the relate resource requirem ents as well as^ testing for qualifications. 147 Breakdown Type Answer to DQ1 Answer to DQ2 Answer to DQ3 Answer to DQ4 Answer to DQ5 Incom plete-R esource Yes Yes Yes Yes N /A R edundant-R esource Yes No N o N /A N /A N o- Resource- Requirem ent No Yes N o No R eady N o- Resource- Possession No No Yes No N /A Inadequate- Resource- M at ch No Yes Yes N o R eady Resource- Possession- Occupied No Yes Yes Yes A ctive Resource- Possession- Broken No Yes Yes Yes Broken Table 8.1: D eterm ination of Breakdown Types Answers to these questions classify the type of the breakdow n as one of th e seven recognized types. Table 8.1 gives the correspondence betw een these answers to types of breakdowns. Inform ation gathered from these questions is also saved for later useJ In case th e diagnosis sub-process cannot determ ine th e answers due to lack o: inform ation, it asks users to provide m ore inform ation, or direct answers. Then th e diagnosis sub-process determ ines the intended use o f a problematic resource, or a problematic resource requirement if the resource does not exist. This can be achieved by retrieving th e specified relationship betw een th e problem atic resource and th e broken activity. This is presented as a question: DQ6: How a r e t h e b r o k e n a c t i v i t y a n d t h e p r o b l e m a t i c r e s o u r c e r e l a t e d ? Answers to this question m ust relate activity, agent, tool, required-resource, anc provided-resource according to the defined relationship between the problem atic activity, th e problem atic resource, and the related resource requirem ent. Also, other related inform ation is collected such as p r o b l e m a t i c - r e s o u r c e - c l a s s indicating th e resource class and c u r r e n t - c o - u s e r s indicating other users of th e problem atic resource if they exist. For exam ple, if W r i t e - C o d e , a broken activity, identifies P eter j an instance of p e o p l e , to be its problem atic resource, the answer to DQ6 will be searched through following reasoning: D Q 6 -1 : I s P e t e r a s s o c i a t e d w i t h a r e s o u r c e r e q u i r e m e n t ? I f h e i s , c a l l i t R -R e q . D Q 6 -2 : W hat u s a g e c l a s s i s R -R e q : a c t i v i t y , a g e n t , t o o l , r e q u i r e d - r e s o u r c e , o r p r o v i d e d - r e s o u r c e ? D Q 6 -3 : I s R -R e q a r e s o u r c e r e q u i r e m e n t f o r W r i t e - C o d e ? 148 Answers to DQ6-1 and DQ6-2 m ust be yes for th e diagnosis sub-process to take th e answer to DQ6-2 as its answer to DQ6, which identifies th e resource usage for th e problem atic resource. T he next stage is to search fo r a production chain th a t created th e problem atic resource. It is identified by asking: DQ7: Is the problematic resource produced in the same SPM? T he answer can be found through inference of a producer activity of the prob lem atic resource and th e relationship between the producer activity and the broken activity. If th e producer activity can not be found, or is outside th e SPM to which the broken activity belongs, the diagnosis sub-process will not try to find its producers unless all other possibilities prove ineffective. If the producer activity is found, diagnosis then retrieves th e whole production chain th a t leads to th e current status of the problem atic resource. This produc-j tion chain consists of activities th a t m anipulate the problem atic resource in their execution order, th e developers involved in those producer activities, and other crit-| ical resources. Such a production chain provides a causal explanation about w hat1 happened to the problem atic resource and thus gives clue on how it should be fixed! T he result of th e diagnosis sub-process is saved into an object called d ia g n o s is whose definition is given in th e previous chapter. In total, there are 25 diagnosis subclasses w ith their corresponding values defined in th e problem space. 8.3 The Selection Sub-Process T he selection sub-process acts as a layered filter to th e m atch betw een a d ia g n o s is in th e problem space and a set of PSHs in the solution space. Once a diagnosis is created, th e selection sub-process retrieves its corresponding applicability heuristics to get all applicable PSHs. It then m atches these applicable PSHs against the in-j volved agent’s available PSHs to pick those to be applied by th e agent. N ext, the available applicable PSHs are ordered according to available global and circumstan-j tial preferences heuristics so th e top PSHs will be chosen as th e one to be applied in th e recovery sub-process. Figure 8.4 gives a top level algorithm ic description of 149, Pick up the First PSH in the List Filter through Availability Heuristics Order PSHs by Preference Heuristics Filter through the Agent's Available PSHs Figure 8.4: The Selection Sub-Process th e selection sub-process, which consists of filtering through availability heuristics, intersecting w ith agent’s PSHs, and ordering PSHs by preference heuristics. In th e A rticulator, the applicability heuristics are used to bridge a d ia g n o s is to! a set of applicable PSHs. Finding the applicable heuristics for a d ia g n o s is is done by filtering through the related applicability heuristic. Once a d ia g n o s is is given, its related applicability heuristic is retrieved and th e applicable PSHs are th en accessed.! Figure 8.5 shows an 0 P S 5 rule th a t accomplishes this. Since different agents m ay have different PSHs available to them , th eir actual articulation capabilities are, therefore, lim ited to th e available PSHs. In th e A rtic ulator, definition of an agent includes specification of its available PSHs th a t can be applied in articulation. C urrently there are a to tal of thirty-five subclasses of PSH s defined, b u t an agent instance m ay only have a subset of th irty five PSHs available to them . Through this m echanism , different levels of articulation skill can be m odeled when needed. 150 ( p a r t - p s h - i n t e r s e c t i o n : c o n t e x t t ( i n d i v i d u a l - a g e n t “ i n s t a n c e < > ( ) ‘ s c h e m a - n a m e < a g e n t > “ c o n t r o l l e r - g o a l a r t - p s h - i n t e r s e c t i o n “ s t a t u s < s t a t u s > “ a r t i c u l a t i o n - p s - h e u r i s t i c s ) “ i n s t a n c e < > ( ) “ s c h e m a - n a m e < a c t i v i t y > “ s c h e m a - n a m e ( m e m b e r < > < s t a t u s > ) “ a r t i c u l a t i o n - h a s - b r e a k d o w n ) “ i n s t a n c e < > ( ) “ s c h e m a - n a m e ‘ s t a t u s ( m e m b e r s t a r t < > ) “ i d e n t i l i e d - d i a g n o s i s < d i a g > ) ‘ i n s t a n c e < > ( ) “ i n s t a n c e < d i a g - c l a s s > ) ( a p p l i c a b i l i t y - h e u r i s t i c ‘ i n s t a n c e < > ( ) “ r e l a t e d - d i a g n o s i s < d i a g - c l a s s > ‘ a p p l i c a b l e - p s h s < a p p l i c a b l e > ) — > ( n e w - v a l u e s < d i a g > ’ c h o s e n - p s h ( i n t e r s e c t i o n < a p p l i c a b l e > ) ) ( n e w - v a l u e < a g e n t > ' c o n t r o l l e r - g o a l ’ a r t - p s h - s e l e c t i o n ) ) Figure 8.5: An 0 P S 5 Rule to Select A pplicable PSHs Once the set of applicable PSHs are retrieved for a d ia g n o s is , this set of PSHs are subjugated w ith the involved agent’s available PSHs to determ ine th eir inter-j section. T he o u tp u t of th e intersection is the applicable PSHs th a t are currently available to th e agent who is articulating the breakdown. This set of PSH s is callec the selected PSHs. T he next step is to order the selected PSH s according to an agent’ s global and circum stantial preference heuristics. As presented in the previous chapter, prefer-j ence heuristics provide the preferred PSHs and resources. As such, th e selected PSHs can be ordered so th a t the m ost preferable one is at th e top of th e list. T he ordering algorithm is a simple num eric one, since the num ber of the selected PSHs will probably not exceed 35. T he outcom e of the selection sub-process is an ordered list of PSHs. T he first PSH on th e list is th e chosen PSH which will be executed in the recovery sub-process. However, th e other PSHs in th e list m ay be executed if the previously chosen PSHs fail to recover the breakdown due to unexpected reasons. ( a r t i c u l a t i n g ( b r e a k d o w n ( d i a g n o s i s 151 PSHl PSH4 PSH3 ESHn PSH2 Get the Selected PSH and Execute One Below Figure 8.6: T he Recovery Sub-Process 8.4 The Recovery Sub-Process T he recovery sub-process is relatively easy. It invokes the im plem entation rules o f the chosen P SH w ith th e given inform ation in the related d ia g n o s is (Figure 8.6). Fig ure 8.7 displays the im plem entation code for th e PSH < re d o -a n d -re v ie w , r e q u ir e d - r e s o u r c e , a c t i v i t y , new>, in which th e function d u p l i c a t e - a n d - i n s e r t creates a modified instance of th e problem atic activity in! the production chain and an instance of th e rev ie w activity. It then inserts the two before th e broken activity. T he result of this PSH is a structurally modified p art of the original SPM where two activity instances are inserted. An exam ple of this kind of recovery will be shown in th e next chapter. A nother responsibility of the recovery sub-process is to verify the success o f exe cution o f the chosen PSH. If error codes are returned as the result of PSH execution, th e execution m ust be discarded and articulation has to backtrack to the selection sub-process and select another PSH to be invoked. 152 ( p a r t - p s h - 2 2 : c o n t e x t t ( i n d i v i d u a l - a g e n t “ i n s t a n c e <> ( ) “ s c h e m a - n a m e < a g e n t > “ c o n t r o l l e r - g o a l a r t - r e c o v e r y “ s t a t u s < s t a t u s > ) “ i n s t a n c e <> ( ) “ s c h e m a - n a m e < a c t i v i t y > “ s c h e m a - n a m e ( m e m b e r < > < s t a t u s > ) “ a r t i c u l a t i o n - h a s - b r e a k d o w n “ p r o b l e m a t i c - a c t i v i t y ) “ i n s t a n c e < > ( ) “ s c h e m a - n a m e “ s t a t u s ( m e m b e r s t a r t < > ) “ i d e n t i f i e d - d i a g n o s i s < d i a g > ) “ i n s t a n c e <> ( ) “ s c h e m a - n a m e < d i a g > “ c h o s e n - p s h “ l a t e s t - p r o v i d e r s < l a t e s t > ) ( r e d o - a n d - r e v i e w " i n s t a n c e <> ( ) “ s c h e m a - n a m e ) — > ( d u p l i c a t e - a n d - i n s e r t < l a t e s t > ) ( n e w - v a l u e < a g e n t > ’ c o n t r o l l e r - g o a l ’ a r t - e x e c u t e - e n d ) ) Figure 8.7: An 0 P S 5 Rule to Execute PSHs 8.5 The Re-Scheduling Sub-Process A rticulation requires scheduling to be reactive and partial. T he reason is th a t if th e executed PSH is structural, th e activity hierarchy of th e modified SPM must' be updated. T he re-scheduling sub-process m ust rearrange resource allocations that' becam e invalid. Since the re-scheduling sub-process is always called upon during th e m iddle of SPM enactm ent, it m ust be reactive and partial. F irst, th e re-scheduling sub-process is a response to changed resource arrangem ents. T he previous arrange m ent m ust be abandoned and new arrangem ents asserted. Second, only p art of the whole schedule needs to be modified while others rem ain th e same. As such, changes' should be lim ited as m uch as possible. In th e light of these two requirem ents, th e re scheduling sub-process is based on heuristic constraint-directed search [22, 52, 60]. Its constraint satisfaction has a sim ilar structure as those m ethods suggested in [22, 52, 60], b u t it is specially designed to be reactive and partial. It also takes ( a r t i c u l a t i n g ( b r e a k d o w n ( d i a g n o s i s 153 advantage of flexible re-scheduling heuristics to both reduce th e com putational com plexity and use different heuristics under different circum stances. Figure 8.8 gives a top level algorithm ic description of th e re-scheduling sub-process; this consists of abandoning a p art of th e old schedule, satisfying activity constraints, ordering activj ities by activity heuristics, creating a dem and window, selecting resources through resource constraints and heuristics, allocating resources, updating th e constraints and continuing the allocation loop as above until a term inating condition is reached! 1 T he re-scheduling sub-process takes over once th e recovery sub-process is sucj j cessfully finished. F irst, th e re-scheduling sub-process decides which part o f the previous schedule should be abandoned given the fact th a t p art of th e SPM has been modified. This p art is very im portant since it acts as a link betw een recovery and re-scheduling. This is done w ith reference to th e executed PSH and changes m ade during PSH execution. Therefore, it is possible for th e A rticulator to identify p art of the original schedule th a t m ust be modified. However, there exist several alternative strategies in deciding which p art should be abandoned: • R e - S c h e d u l i n g S t r a t e g y 1 is to abandon only those resource allocations for th e broken activity and all its successors. This strategy does not disturb the p a rt of th e original schedule th a t binds th e resources to unaffected activities! and therefore lim its the scope of changes. j • R e - S c h e d u l i n g S t r a t e g y 2 is to simply abandon all resource allocations th a t are associated w ith all th e rem aining un-started activities in an SPM alto-J gether. This second strategy creates m ore potential changes to th e original SPM , b u t m ay have a b etter result since it reconsiders necessary changes from a global point of view. • R e - S c h e d u l i n g S t r a t e g y 3 is ju st to schedule one activity at a tim e. There fore, only the schedule for th e broken activity m ust be redone. Of course, th e choice of these different strategies determ ines th e final outcom e of re-scheduling. Therefore, several runs of the re-scheduling sub-process m ay be necessary since it does not provide any optim ization m echanism at th e moment.I To illu strate this point, an exam ple will be given to show different results basedl on different strategies in th e next chapter. Once such a re-scheduling strategy is! 154 Abandon part of the old schedule Satisfy Activity Constraints Satify Resource Constraints Update Resource Constraints Satisfy Resource Constraints Satify Activity Heuristics Update Activtity Constraints Select Activities to be Rescheduled Pick up an Resource and Allocate it Pick up an Activity and Create Demand Window Figure 8.8: The Re-Scheduling Sub-Process 155 decided, th e set of activities to be re-scheduled can be determ ined, which can be either th e set of th e broken activity and its successors, or th e set of all rem aining 1 u n-started activities, or the broken activity only. All resource allocations associated w ith these activities have to be discarded. New re-scheduling constraints reflecting th e changes in th e SPM are then introduced. T he activities to be re-scheduled and available resources are represented in forms of activity- and resource-constraints, respectively. For each agent, available activity and resource heuristics are also given as re-scheduling criteria of activities and re-j sources so they are specific to each individual agent. T he re-scheduling sub-process uses these types of inform ation and knowledge to create a modified schedule. T he re-scheduling sub-process uses constraint satisfaction in sim ilar fashion as [22, 52, 60] to select the activities to be scheduled next. C onstraint satisfaction, foi a given set of activities, picks up a subset of activities th a t m eets a set of prede fined re-scheduling constraints. The actual im plem entation for satisfying a set of re-scheduling constraints is a repetitive procedure, In each step, th e re-scheduling sub-process tests th e activities against one particular re-scheduling constraint. Those activities th a t fail to satisfy the re-scheduling constraint are excluded for th e next iteration and therefore a sm aller num ber of activities rem ain. T he process continues until either all th e re-scheduling constraints are tested, or an em pty set of activities rem ains. j Since three types of re-scheduling constraints are defined in th e A rticulator, con strain t satisfaction has three separate types of tests: • A value constraint is to be tested between th e specified value of the re-scheduling constraint and the corresponding value in th e sam e a ttrib u te of th e activity according to the specified co m p ariso n in th e re-scheduling con-j straint. T hree types of co m p ariso n can be defined: — none: no test is made; — la r g e r : An activity, ACT, satisfies a value constraint, UC, when, for the specified a ttrib u te A TTR, the a ttrib u te value from A C T ’s A T TR is larger th an th a t of U C ’s ATTR. 156 — s m a lle r: An activity, A CT, satisfies a value constraint, UC, when, for the specified a ttrib u te A TTR, th e a ttrib u te value from A C T ’s A TTR is sm aller th an th a t of U C ’s A TTR. • A relational constraint is tested against th e direction of re-scheduling. C ur rently, all re-scheduling is in a forward direction. As such, an activity ACT satisfies a relational constraints, BU, where it appears in s e c o n d -o b je c t if all activities th a t appear in f i r s t - o b j e c t have been scheduled. • A boundary constraint is tested against the range of values it defines. An activity, ACT, satisfies a boundary constraint, BC, when, for th e specified attrib u te A TTR, the a ttrib u te value from A C T ’s A T TR is betw een th e values of a t t r i b u t e - v a l u e - h i g h and a ttr ib u t e - v a l u e - l o w in BC. An activity m ust satisfy all specified activity-constraints before it becomes a candidate for re-scheduling. T he subset of th e activities th a t satisfy all specifiec activity-constraints are then forwarded to th e next stage where they will be orderec according to activity heuristics. In case m ore th an one activity is satisfied by re-scheduling constraints, activity heuristics provide a m eans to order them . Ordering these activities is done through activity heuristics. T he im plem entation of activity heuristics support th e application of m ost commonly seen scheduling heuristics, such as shortest-slack-first and highest- priority-first. Furtherm ore, three other im portant features are also implemented'. F irst, com bination of these activity heuristics can be used to further lim it th e possible choices. Second, new activity heuristics can be added very easily. T hird, test runs can be used to verify how well some activity heuristics are used in a particular situation. Since each type of activity heuristic provides a way to order th e activities, a com bination of a set of activity heuristics results in an ordered of activities thafi m eet requirem ents from all th e activity heuristics. Therefore, ordering th e activitiei is a procedure th a t m eets m ultiple criteria. For a single activity heuristic defined as: {{heuristic is-a: articulation-object operation: max/min 157| operation-typa: value/number operand-constraint: [re-scheduling-constraint] » T here exists four possible orderings of o p e r a n d - a ttr ib u te according to th e com binations of all possible values in attrib u tes o p e r a tio n and o p e r a tio n -ty p e : o p e r a tio n is max and o p e r a tio n - ty p e is v a lu e : th e activities are listed ac cording to values in o p e r a n d - a ttr ib u te in a decrease order. o p e r a tio n is min and o p e r a tio n - ty p e is v a lu e : th e activities are listed ac cording to values in o p e r a n d - a ttr ib u te in an increase order. • o p e r a tio n is max and o p e r a tio n - ty p e is number: th e activities are listec according to th e num ber of values in o p e r a n d - a ttr ib u te in a decreasing order • o p e r a tio n is min and o p e r a tio n - ty p e is number: th e activities are listec according to the num ber of values in o p e r a n d - a ttr ib u te in an increasing order. W hen th e activities are ordered according to th e activity heuristics, th e first activity in th e list becomes the one to be scheduled at this step. T he first activity in the ordered list is selected to be scheduled next. Its resource requirem ents are translated into a set of dem and windows. A dem and window lists an activity’s resource requirem ent together w ith the expected tim e span: {{demand-window is-a: articulation-object required-resource-class: [resource-requirement-class] available-resource-instances: [resource-instances] maximum-quantity: [integer] minimum-quantity: [integer] start-time: [integer] end-1 ime: [int eger] assigned-instances: [allocated-resource-instances] » In the definition, r e q u ir e d - r e s o u r c e - c la s s defines the resource class requirec by th e activity w ith th e expected tim e span from s t a r t - t i m e to e n d -tim e . Accord ing to th e resource requirem ent, resource instances stored first in 158 a v a ila b le - r e s o u r c e - in s ta n c e s and satisfying the tim e span and other resource-j constraints and heuristics, can be allocated to a s s ig n e d - in s ta n c e s . For th e de-j m and window to be satisfied, th e num ber of allocated resource instances m ust be ’ i betw een m in im u m -q u an tity and m axim um -quantity. According to each of the dem and windows, the re-scheduling sub-process retrieves a set of available resource instances through resource constraints and resource heuris tics. T his sub-process is the sam e as th a t for selecting activities, b u t uses resource constraints and heuristics, instead. A very im portant system-defined resource constraint is th e availability-constraint An availability constraint for resources defines the tim e span during which th e re sources are available to be used. Therefore, it is a boundary constraint on resources. As th e resources are allocated, their availability-constraint will be reduced to J sm aller tim e span until all its tim e is used up. W hen th e selection of resource instances is successfully com pleted, each of the resource requirem ents will be m atched to a resource in two steps: first, it has J class m atch, th a t is, th e class of the resource instance is com patible to th e class of th e resource requirem ent; and second, it has th e availability constraint th a t at least covers th e tim e span in th e resource requirem ent. Since th e chosen activity’s resource requirem ents are m et by available resource instances, resource allocation is perform ed next. If th e dem and window can be satisfied w ith available resource instances, the activity chosen is allocated w ith these resources and changes on activities and re-J sources are propagated: F irst, th e activity is m arked sc h e d u le d and related activity-^ constraints are updated. Second, the availability-constraints of th e allocated re-j source instances are reduced to exclude the tim e span for th e chosen activity. Also o ther resource-constraints are updated if needed. T he re-scheduling sub-process then re-starts th e step to select th e next activity to be scheduled. If th e dem and window cannot be satisfied due to insufficient resources at the m om ent, th e chosen activity is postponed until the scheduling sub-process advances to th e next tim e step. Once all th e selected activities are scheduled or postponed for this tim e step, the scheduling sub-process advances to the next tim e step and the articulation process' continues selecting from possible activities. 159 The scheduling sub-process continues until one of th e following conditions occurs: 1. all activities, which are identified to be re-scheduled, are scheduled; 2. th e resources are used up in their available tim e; 3. scheduling iteration reaches a stop step specified by the user; 4. all specified activities are scheduled. T he re-scheduling sub-process can be applied on either a com plete SPM , or a part of it over a specified tim e span, depending on given activity and resource constraints! In th e la tte r case, only activity constraints are specified th a t state a m iddle statej w ith some activities are allocated and others are not. Resource constraints are set accordingly, so only those to be allocated are available for scheduling. 8.6 Summary This chapter describes th e four sub-processes in articulation, i.e. diagnosis, selection, recovery, and re-scheduling in detail. These sub-processes interact w ith each other to form an integrated approach to recover from breakdown situations during SPM enactm ent. Conceptually, different agents modeled in the A rticulator m ay have different knowledge specifications and articulation heuristics th a t result in different behavior! For exam ple, different agents can have different num ber of PSHs available for them! T he m ore PSHs an agent has at its disposal, the m ore choices it has in resolving a breakdow n situation, as dem onstrated in this chapter. T he same is tru e as for other kinds of knowledge specification, such as selection and re-scheduling heuristics. This m echanism for differential knowledge and skill is useful in m odeling th e collective behavior of an organization, such as developm ent team s, where these differences do exist. This direction of work can be explored in future research. To help further understand process articulation, several articulation exam ples are presented in the next chapter. 160 Chapter 9 Case Studies: Dynamic Analysis of SPMs This chapter provides three case studies to help readers understand th e dynam ic analysis of SPM s. These case studies dem onstrate different ways the A rticulator can be applied before or during SPM enactm ent. These case studies are based on th e following scenario: A team of developers perform two projects which are depicted by two SPM s. T he first case study shows how articulation can be used as a dynam ic scheduling tool in determ ining necessary resource allocation in order to do th e job efficiently before SPM enactm ent. T he second case study dem onstrates process sim ulation through th e enactm ent of two SPMs by a team of developers] i which is used to predict and adjust the possible enactm ent trajectory. T he third case study provides an exam ple to apply process articulation in recovering process breakdowns during SPM enactm ent. Last, th e chapter concludes w ith a discussion about lessons learned from these case studies. 9.1 The Scenario for Case Studies T he case studies presented in this chapter are based on a hypothetical developm ent scenario. In this scenario, a developm ent team performs two developm ent projects] T he developm ent team , Team-A, consists of a m anager, Mary, and several develop-| ers, P eter, John, Doug, and Chris. Some of them are in senior positions, others are in junior positions. Team-A is responsible for program m ing a software system andl enhancing another existing software system . These two developm ent projects are described by th e two SPMs presented in th e earlier chapters: P r o g r a m m i n g , whose task hierarchy is shown in Figure 4.3, and D e v e l o p - C h a n g e - a n d - T e s t - U n i t , whosej 161 task hierarchy is shown in Figure 5.16. Table 9.1 lists the agent/role requirem ents and th e subtasks’ expected durations for these two SPM s. Overall, four different roles are needed in these two SPMs: a m anager, a software designer, a software en-j gineer, and a QA engineer. For exam ple, M odify-D esign needs a software designer and a software engineer. In order for Team-A to finish the project as expected, M ary, its m anager, has the job of m anaging and controlling the SPM enactm ent. In this case, SPM enactm ent executes two SPM s by a team of developers playing different roles. Before th e SPM enactm ent starts, M ary needs to know how to assign her team m em bers so th e tasks can be finished as soon as possible. Once task assignm ent is done, M ary needs to have an estim ation about how she can expect her team m em bers to do th e jobs based on their working experience and past behavior. Then, M ary needs to have a m eans th a t can support her in handling breakdowns th a t m ay occur during SPM enactm ent. These case studies dem onstrate how th e A rticulator can solve these problem s. 1 9.2 Case Study: Process Scheduling T he first case study deals w ith process scheduling, whose purpose is to identify proper resource requirem ents for SPM s and allocate necessary resource instances to th e SPMs. In this scenario, this is th e first job for th e m anager before SPM enact-J m ent starts. At th e sta rt, process scheduling creates initial resource estim ation and allocation based on different ways th e two SPMs are anticipated to be enacted. Then] th e case exam ines resource estim ation first, and followed by resource allocation. I 9 .2 .1 R e so u r c e E stim a tio n Given th e task hierarchies and agent/role requirem ents for th e two SPM s, Mary, th e m anager, uses dynam ic analysis to create resource estim ation based on different ways th e two SPM s can be perform ed. The inputs to resource estim ation are the 1In principle, the Articulator is capable of handling all kinds of resources. But due to space| limitations, only the agent resources in these case studies are discussed. 162 (a) Develop-Change-and-Test-Unit Nam e Duration Agent/R ole Q uantity Assign-Task 1 M anager 1 Modify-Design 1 Designer Engineer 1 1 M odify-Code 1 Designer Engineer 1 Modify- Test- P lan 2 Q A-Engineer 1 M odify-Test-Pk 1 QA 1 Test-U nit 1 Designer QA-Engineer 1 1 M onitor 7 M anager 1 ( b ) P r o g r a m m i n g Nam e Duration Agent/R ole Q uantity C reate-m ain 1 Engineer 1 Create-sub 1 Engineer 1 Create-m ake 1 Engineer 1 Loop-begin 1 QA-Engineer 1 Compile 1 QA-Engineer 1 Debug 1 QA-Engineer 1 Branch-begin 1 Engineer 1 M odify-main 1 Engineer 1 M odify-sub 1 Engineer 1 M odify-make 1 Engineer 1 Branch-end 1 QA-Engineer 1 Loop-end 1 Engineer 1 Table 9.1: A gent/R ole Requirem ents for the Two SPM ’s two SPM s including their activity hierarchies, estim ation of activity durations, and resource requirem ents. F irst, M ary estim ates separate resource estim ation for th e two SPM s. She runs th e re-scheduling sub-process (see Section 8.5) w ith the r e q u i r e m e n t - r u n mode.J Table 9.2 lists the resource estim ations for different tim es given th e assum ption th at the SPM should be finished w ithout delaying th e activities on its critical path. In th e figure, three num bers are generated for each entry: T he first is th e m axim um num ber of the role in th e colum n to perform an activity at th a t tim e. T he second is th e num ber of the role in the column needed on th e critical p ath at th a t timeJ T he th ird is the num ber of the role needed, b u t not on the critical p ath at th a t tim e. In D evelop-Change-and-Test-U nit-PM , four different roles are needed. These roles are a m anager, a designer, a QA engineer, and an engineer. A t tim e step 2 ] five different people m ust participate th e task. Therefore, M ary needs five people] or else th e SPM enactm ent is delayed. In P r o g r a m m i n g , two different roles are required: a QA engineer and an engineer. T hree different people playing two roles are needed at m ost. M ary also notices th a t P r o g r a m m i n g has two non-determ inistic parts: th e num ber of iteration is determ ined by actual bug detection and resolution] T he num ber of modified files during each iteration is also unknown. Therefore, she m ust consider these two factors when arranging the schedule. In term s of SPM enactm ent, M ary can either perform th e two SPM s sequentially or concurrently. Table 9.3 lists resource estim ations for three different SPM enact-j m ent. It is clear th a t concurrent SPM enactm ent takes less tim e, b u t needs more hum an resources th an th e num ber of team m em bers in Team-A. Therefore, M ary’s job is to create a schedule th a t uses the five team m em bers while taking less tim e th an sequential SPM enactm ent. Again, she runs th e re-scheduling sub-process to create such a schedule. Several conclusions can be drawn from these tables: • T here m ust be at least five people in order to perform the two SPM s. This is suggested in th e to tal num bers at both tim e 2 in Table 9.3 (a) and (b). • T he six different roles needed for these two SPM s include: a m a n a g e r , a QA e n g i n e e r , a d e s i g n e r , and three e n g i n e e r s . Therefore, a decision m ust be| m ade as to which person in Team-A perform s which role. 164 (a) Develop-Change-and-Test-Unit-PM Tim e M anager QA-Engineer Designer Engineer Total 0 (1 1 0) ( 1 1 0 ) 1 ( 1 1 0 ) ( 1 1 0 ) (1 0 1) ( 1 0 1) (4 2 2) 2 ( 1 1 0 ) (1 1 0) (1 0 1) (2 0 2) (5 4 1) 3 (1 1 0) (1 1 0) (2 2 0) 4 ( 1 1 0 ) (1 1 0 ) (1 0*1) (3 2 1) ( b ) P r o g r a m m i n g Tim e M anager QA-Engineer D esigner Engineer Total 0 (1 3 0) (1 3 0) 1 (1 1 0 ) (1 1 0 ) 2 (1 1 0 ) (1 1 0 ) 3 (1 1 0 ) (1 10) 4 (1 1 0 ) (1 10) 5 (13 0) (13 0) 6 (1 1 0) (1 1 0 ) 7 (1 1 0 ) (1 1 0 ) Table 9.2: Resource Estim ations for Separate SPM Enactm ent • If the role assignm ent can be m ade successfully and the two SPMs are executec, sequentially, it can be expected th a t the two SPMS can be finished by tim e 12 using th e schedule in Table 9.3 (a). • If th e role assignm ent can be m ade successfully and th e two SPM s are executec concurrently, then th e two SPMS can be finished by tim e 7 using th e schedule in Table 9.3 (b). • In looking m ore closely at tim e 2 at schedule (b) in Table 9.3), six persons are actually needed in order to finish the two SPMs in the shortest duration sug gested by the schedule. However, Team-A only has five m em bers. Therefore, some delay is expected. 165 ( a ) S e q u e n t i a l E n a c t m e n t Tim e M anager QA-Engineer Designer Engineer Total 0 (1 1 0) ( 1 1 0 ) 1 ( 1 1 0 ) (1 1 0) ( 1 0 1) ( 1 0 1) ( 4 2 2) 2 ( 1 1 0 ) ( 1 1 0 ) ( 1 0 1) ( 2 0 2 ) (5 4 1) 3 ( 1 1 0 ) ( 1 1 0 ) (2 2 0 ) 4 (1 1 0) (1 1 0) ( 1 0 1) (3 2 1) 5 ( 1 3 0) ( 1 3 0) 6 (1 1 0 ) (1 1 0) 7 ( 1 1 0 ) (1 1 0 ) 8 ( 1 1 0 ) (1 1 0) 9 (1 1 0) (1 1 0) 10 ( 1 3 0) ( 1 3 0) 11 ( 1 1 0 ) ( 1 1 0 ) 12 (1 1 0 ) (1 1 0) ( b ) C o n c u r r e n t E n a c t m e n t Tim e Manager QA-Engineer Designer Engineer Total 0 (1 1 0) ( 1 3 0) ( 1 4 0) 1 (1 1 0) a 1 1 ) (1 0 1) (1 0 1) (4 2 3) 2 (1 1 0) ( i 1 1 ) (1 0 1) ( 2 0 2 ) (5 2 4) 3 (1 1 0) ( i 1 1 ) (2 2 1) 4 (1 1 0) ( 1 0 1) ( 1 0 1) (1 1 0 ) (4 2 2) 5 (1 1 0) ( 1 3 0) (2 4 0) 6 (1 1 0) (1 1 0) (2 2 0) 7 ( 1 1 0 ) (1 1 0) (2 2 0) Table 9.3: Resource Estim ations for SPM E nactm ent 166 9 .2 .2 R eso u rc e A llo c a tio n Based on this analysis, M ary could choose to allocate the team m em bers to different roles as follows: M ary is th e m anager, P eter plays the QA engineer, John is the designer, Doug and Chris are two engineers, one of whom plays two roles of engineer as required. A t this point, M ary could be interested in knowing th e effect of such a role allocation on her schedule. She th en runs the re-scheduling sub-process in th e s c h e d u lin g m ode, which in tu rn creates schedules related to different enactm ent styles as shown in Table 9.4 and Table 9.5. T he inputs to the re-scheduling sub-process includes the two SPM s, th e expected role allocation, th e tim e availability for all the team s m em bers, and some otherj resource scheduling constraints and heuristics. T he resource scheduling constraints and heuristics are intended to facilitate the re-scheduling sub-process. Their use is tested through several runs of the re-scheduling sub-process. 2 One assumption^ m ade about this schedule is th a t there is only one iteration is scheduled for the Develop- Change- and- Test- Unit- P M . T he o utputs are different schedules created according to th e given constraints and heuristics. These are shown in Table 9.4 for sequential enactm ent and Table 9.5 for concurrent enactm ent. In Table 9.4, Schedule (a) allocates the team m em bers toj different activities for a sequential enactm ent of the two SPM s. T he only activity constraint used is th e success constraint, and the only resource constraint used is th e availability constraint. No activity and resource heuristics are used. Com pare this schedule w ith th e original resource estim ation (a) shown in Table 9.3. HereJ one notices th a t since the th ird engineer role is perform ed by Doug and Chris, two m ore tim e steps are needed. Therefore, this schedule takes two m ore tim e steps to com plete th e two SPMs. Schedule (b) for sequential enactm ent basically does the sam e enactm ent. How ever, it allows some overlap, which m eans when some m em bers are perform ing P r o g r a m m i n g , others are allowed to start the D e v e l o p - C h a n g e - a n d - T e s t - U n i t - P M J T he result is a b etter schedule, which com pletes the two SPM w ith 11 tim e steps. 2Currently no help is provided on the use of these constraints and heuristics for an optimized schedule. Therefore, test runs are necessary in order to compare and select among a set of candidate! schedules. 167 (a) Sequential Enactment without Overlap T im e M ary P eter John D oug C hris 0 A ssign-Task 1 M onitor M odify-T est-Plan M odify-D esign M odify-D esign 2 M onitor M odify-T est-Plan M odify-Code M odify-Code M odify-Code 3 M onitor M odify-Test-Pk 4 M onitor Test-Unit Test-U nit 5 Create-M ain Create-Sub 6 Create-M ake 7 Loop-Begin 8 C om pile 9 D ebug 10 Branch-Begin 11 M odify-M ain M odify-M ake 12 M odify-Sub 13 Branch-End 14 Loop-End (b) Sequential Enactm ent w ith O verlap T im e M ary P eter John D oug C hris 0 Create-M ain Create-Sub 1 C reate-M ake 2 Loop-Begin 3 Com pile 4 Debug 5 Branch-Begin 6 A ssign-Task M odify-Test-Plan M odify-M ain M odify-M ake 7 M onitor M odify-Test-Plan M odify-Design M odify-Sub M odify-D esign 8 M onitor Branch-End M odify-Code M odify-Code M odify-Code 9 M onitor M odify-Test-Pk Loop-End 10 M onitor Test-Unit Test-Unit Table 9.4: Schedules for Sequential SPM Enactm ent 168 Table 9.5 shows two schedules for concurrent enactm ent where enactm ent of th e two SPMs starts at th e same tim e. T he difference is th a t Schedule (b) uses an activity heuristic called m a x - s u c c e s s o r - f ir s t, which m eans when selecting an activity to be scheduled, the one w ith m axim um num ber of successor subtasks will be chosen first. Also one m ore activity constraint is used to create these two schedules E a r l i e s t - s t a r t - t i m e acts to em ulate th e effect of th e critical p ath m ethod anc chooses those activities w ith earliest start tim e. In sum, process scheduling takes th e two SPMs and other related inform ation as inputs, then generates schedules in the form of resource allocations and their tim ing as its outputs. These outputs are then analyzed by m anagers and decisions can be m ade as to w hat schedule will be chosen to guide actual SPM enactm ent. 9.3 Case Study: Process Simulation A fter M ary gets th e schedules for the two SPM s, she m ight be interested in knowing how her team m em bers will perform th e two SPM s according to th e resource alloca-j tion and tim ing in these schedules. Process sim ulation generates an enactm ent tra jectory based on a given schedule and developer’s system ic behavioral specification] Therefore, M ary uses process sim ulation to validate how feasible these schedules arej As a results, several enactm ent trajectories are created by process sim ulation and explained as follows. 9.3.1 P r o c e ss S im u la tio n on th e F irst R e so u r c e A llo c a tio n At first, M ary chooses Schedule (b) in Table 9.5 as input to process sim ulation. She th en specifies three different types of behavioral specification for her team s members! Process sim ulation then generates three different process trajectories as follows: • T he first type of developm ent behavior states th a t developers random ly se lect an activity to execute from their list of available tasks. W hen any pro cess breakdown occurs, developers do not do any articulation work. This be havior is represented in term s of the agent’s t a s k - e x e c u tio n - s tr a te g y anc a cc o m m o d a tio n -stra te g y : t a s k - e x e c u t i o n - s t r a t e g y = r a n d o m 169, (a) Concurrent Enactment without Overlap Tim e M ary P eter John D oug C hris 0 A ssign-Task 1 M onitor M odify-Test-Plan M odify-Design M odify-D esign 2 M onitor M odify-Test-Plan Create-M ain C reate-Sub 3 M onitor M odify-Test-Pk M odify-Code M odify-Code M odify-C ode 4 M onitor Test-Unit Test-Unit C reate-M ake 5 Loop-Begin 6 Com pile 7 D ebug 8 B ranch-Begin 9 M odify-M ain M odify-M ake 10 M odify-Sub 11 Branch-End 12 Loop-End (b) C oncurrent Enactm ent w ith Overlap Tim e M ary P eter John D oug C hris 0 A ssign-Task Create-M ain Create-Sub 1 M onitor M odify-Test-Plan Create-M ake 2 M onitor M odify-Test-Plan M odify-Design M odify-D esign 3 M onitor Loop-Begin M odify-Code M odify-Code M odify-Code 4 M onitor Com pile 5 M onitor Debug 6 M onitor M odify-Test-Pk B ranch-Begin 7 M onitor Test-U nit Test-Unit M odify-M ain M odify-M ake 8 M odify-Sub 9 Branch-End 10 Loop-End Table 9.5: Schedules for Concurrent SPM E nactm ent Tim e M ary P eter John D oug C hris M anager Q A -Engineer D esigner Engineer E ngineerl 0 Idle Idle Idle Idle Idle 1 A ssign-Task W ait W ait Create-M ain Create-Sub 2 M onitor M odify-T est-Plan W ait W ait Create-M ake 3 M onitor M odify-Test-Plan W ait W ait W ait 4 M onitor Loop-Begin M odify-Design W ait M odify-D esign 5 M onitor Com pile W ait W ait W ait 6 M onitor Debug W ait W ait W ait 7 M onitor W ait W ait W ait Branch-Begin 8 M onitor M odify-T est-Pk W ait M odify-M ain W ait 9 M onitor Branch-End W ait W ait W ait 10 M onitor W ait W ait W ait Loop-End 11 M onitor Loop-Begin M odify-Code M odify-Code M odify-Code 12 M onitor Test-U nit Test-U nit Idle Loop-End 13 Idle Idle Idle Idle Idle Table 9.6: T he First SPM Sim ulation T rajectory a c c o i a m o d & t i o n - s t r a t e g y = w a i t Table 9.6 shows the output enactm ent trajecto ry created by process sim ulation: • T he second type of developm ent behavior states th a t developers randomly! select an activity to execute from their list of available tasks. W hen anyj process breakdown occurs, developers do not do any articulation work. This set of behavior is represented in term s of the agent’s ta s k - e x e c u tio n - s tr a te g y and a cc o m m o d a tio n -stra te g y : t a s k - e x e c u t i o n - s t r a t e g y = f i n i s h - o n e a c c o m m o d a t i o n - s t r a t e g y = w a i t Table 9.7 shows the outp u t enactm ent trajectory created by process simulation. • T he th ird ty p e of developm ent behavior states th a t developers select SPMs based on th eir assignm ent tim e. T he first assigned SPM will be perform ed 171 T im e M a ry P eter John D oug C hris M anager Q A -Engineer D esigner Engineer E ngineerl 0 Idle Idle Idle Idle Idle 1 A ssign-Task W ait W ait W ait W ait 2 M onitor M odify-Test-Plan M odify-Design W ait M odify-Design 3 M onitor M odify-Test-Plan M odify-Code M odify-C ode M odify-Code 4 M onitor M odify-Test-Pk W ait W ait W ait 5 M onitor Test-U nit Test-U nit W ait C reate-M ake 6 Idle W ait Idle Create-M ain Create-Sub 7 Idle W ait Idle W ait W ait 8 Idle Loop-Begin Idle W ait W ait 9 Idle C om pile Idle W ait W ait 10 Idle D ebug Idle W ait W ait 11 Idle W ait Idle W ait Branch-Begin 12 Idle W ait Idle W ait M odify-Sub 13 Idle Branch-End Idle W ait W ait 14 Idle W ait Idle W ait Loop-End 15 Idle Loop-Begin Idle W ait W ait 16 Idle C om pile Idle W ait W ait 17 Idle D ebug Idle W ait W ait 18 Idle W ait Idle W ait Branch-Begin 19 Idle W ait Idle M odify-M ain M odify-M ake 20 Idle W ait Idle Idle M odify-Sub 21 Idle Branch-End Idle Idle W ait 22 Idle W ait Idle Idle Loop-End 23 Idle Loop-Begin Idle Idle W ait 24 Idle Idle Idle Idle Loop-End 25 Idle Idle Idle Idle Idle Table 9.7: The Second SPM Sim ulation T rajectory 172 Tim e M a ry P eter John D oug C hris M anager Q A-Engineer D esigner Engineer E ngineerl 0 Idle Idle Idle Idle Idle 1 A ssign-Task Switch W ait Switch Switch 2 M onitor Switch W ait C reate-M ain Create-M ake 3 M onitor M odify-T est-Plan W ait Switch Create-Sub 4 M onitor M odify-T est-Plan W ait Switch Switch 5 M onitor M odify-Test-Pk W ait Switch Switch 6 M onitor Sw itch M odify-Design Switch M odify-D esign 7 M onitor Loop-Begin M odify-Code M odify-Code M odify-Code 8 M onitor Com pile W ait Switch Sw itch 9 M onitor Debug W ait Switch Sw itch 10 M onitor Switch W ait Switch B ranch-Begin 11 M onitor Test-U nit Test-Unit Switch M odify-M ake 12 Idle Switch Idle M odify-M ain M odify-Sub 13 Idle Switch Idle Idle Switch 14 Idle B ranch-End Idle Idle Switch 15 Idle Loop-Begin Idle Idle Switch 16 Idle Idle Idle Idle Loop-End 17 Idle Idle Idle Idle Idle Table 9.8: T he T hird SPM Sim ulation T rajectory and finished before th e other SPMs can be enacted. W hen any process break down occurs, developers first try to find another SPM to work w ith (th a t is, they look for som ething else to do), which has available activities to be enacted. Otherw ise, they simply wait for breakdowns to be resolved. This be-j havior is represented in term s of the agent’s t a s k - e x e c u tio n - s tr a te g y and a c c o ra m o d a tio n -strateg y : t a s k - e x e c u t i o n - s t r a t e g y = f i n i s h - o n e a c c o n u n o d a t i o n - s t r a t e g y = s w i t c h a n d w a i t Table 9.8 shows th e ou tp u t enactm ent trajectory created by process sim ulation. 9 .3 .2 P r o c e ss S im u la tio n on O th er R eso u rc e A llo c a tio n s Com paring the three different trajectories, M ary finds th a t t a s k - e x e c u tio n - s tr a te g y equals finish-one, while 173 Tim e M a ry M anager P eter Q A -Engineer Engineer2 John D esigner D oug E ngineer C hris Engineer 1 0 Idle Idle Idle Idle Idle 1 A ssign-Task Switch W ait Switch Switch 2 M onitor Create-M ake W ait Create-M ain Create-Sub 3 M onitor Loop-Begin W ait Switch Switch 4 M onitor Com pile M odify-Design Switch M odify-D esign 5 M onitor Debug M odify-Code M odify-Code M odify-Code 6 M onitor Switch W ait Switch Switch 7 M onitor M odify-Test-Plan W ait Switch B ranch-Begin 8 M onitor M odify-Test-Plan W ait M odify-M ain M odify-Sub 9 M onitor M odify-Test-Pk W ait Switch Switch 10 M onitor Switch W ait Idle Switch 11 M onitor M odify-M ake W ait Idle Switch 12 M onitor Branch-End W ait Idle Switch 13 M onitor Switch W ait Idle Loop-End 14 M onitor Loop-Begin W ait Idle Switch 15 M onitor Switch W ait Idle Loop-End 16 M onitor Test-Unit Test-U nit Idle Idle 17 Idle Idle Idle Idle Idle Table 9.9: SPM Sim ulation T rajectory on the Second Resource Allocation a c c o m m o d a tio n -stra te g y equals s w itc h creates b etter results, i.e., the second pro cess trajectory. However, she wonders w hat would happen if other resource alloca tions are used. Therefore, the following two sim ulations are generated based on this observation: C reation and modification in program m ing needs three engineers at about th e sam e tim e. In the earlier cases, only two engineers, i.e., Doug and Chris] are allocated, which caused some delay during SPM enactm ent. On th e other hand] P eter and John have a lighter work load and are capable of acting as an engineer! If they can perform some of the engineer’s job, the SPMs m ay be com pleted earlier] • P eter is assigned to act as th e third engineer role and perform two m ore ac tivities: c re a te -m a k e and m odify-m ake. Table 9.9 shows th e corresponding process trajecto ry created by process sim ulation. 174 ___ 1 • John is assigned to play th e th ird engineer role and plays two m ore activi-j ties: c re a te -m a k e and m odify-m ake. Table 9.10 show the process trajectory created by process sim ulation. In sum, th e inputs to process sim ulation are the schedules created by process scheduling and th e system ic behavioral specification for developers. In tu rn , process sim ulation creates process trajectories th a t depict possible SPM enactm ent under th e given situation. 9.4 Case Study: Process Articulation In th e previous sections, M ary uses process scheduling and sim ulation to create estim ations of resource requirem ents and enactm ent trajectories before actual SPM. enactm ent. This helps her as a project m anager to arrange resources and control SPM enactm ent. However, it is also im portant to be able to deal w ith resource changes dynam ically during SPM enactm ent. In the A rticulator, this is accom plished through process articulation. In this section, M ary uses process articulation to resolve process breakdowns. During process articulation, process scheduling and sim ulation can be invoked as p art of th e efforts to resolve process breakdowns. I Following th e generated schedule (a) in Table 9.5, Team-A starts to enact the two SPM s. A process breakdown occurs which is described next. 9.4.1 A P r o c e ss B reak d ow n As seen in the D evelop-Change-and-Test-U nit-PM (Figure 5.16), M odify-D esign precedes M odify-Code. W hen an SPM enactm ent starts M odify-D esign w ith two- assigned agents, John and Chris, according to Schedule (a) in Table 9.5 it creates J new version of S y stem -D esig n -D o cth at is suppose to specify correctly the changes ini system design. T he SPM enactm ent then initiates M odify-Code which is assigned! to John, Doug and Chris. W hile modifying the source code in M odify-Code, its assigned agents John, Doug and Chris find th a t th e modified design docum ent has! flaws th a t cause new problems for the software system . Subsequently, this makes System -D esign-D oc inappropriate to follow when modifying th e system ’s sourcJ 175 Tim e M ary M anager P eter Q A -Engineer John D esigner Engineer2 D ou g Engineer C hris E ngineerl 0 Idle Idle Idle Idle Idle 1 A ssign-Task Switch Switch Switch Switch 2 M onitor Switch Create-M ake Create-M ain C reate-Sub 3 M onitor M odify-T est-Plan Switch Switch Switch 4 M onitor M odify-Test-Plan M odify-Design Switch M odify-Design 5 M onitor M odify-T est-Pk M odify-Code M odify-Code M odify-Code 6 M onitor Test-U nit Test-U nit Switch Switch 7 Idle Switch Switch Switch Switch 8 Idle Loop-Begin W ait W ait W ait 9 Idle C om pile W ait W ait W ait 10 Idle Debug W ait W ait W ait 11 Idle W ait W ait W ait B ranch-Begin 12 Idle Branch-End W ait W ait W ait 13 Idle W ait W ait W ait Loop-End 14 Idle Loop-Begin W ait W ait W ait 15 Idle C om pile W ait W ait W ait 16 Idle D ebug W ait W ait W ait 17 Idle W ait W ait W ait B ranch-Begin 18 Idle W ait M odify-M ake M odify-M ain M odify-Sub 19 Idle B ranch-End Idle Idle W ait 20 Idle W ait Idle Idle Loop-End 21 Idle Loop-Begin Idle Idle W ait 22 Idle Idle Idle Idle Loop-End 23 Idle Idle Idle Idle Idle Table 9.10: SPM Sim ulation Trajectory on the Third Resource Allocation 176 code. Therefore, there is a breakdown situation and it is handed over to articulation A breakdow n object is therefore created as: { { b r eakdown-12+11 instance: breakdown related-activity: M odify-C ode developers: John D oug Chris } } T he system -generated num bers in th e nam e of this breakdown instance (in this case 12+11) assigns th e object a unique nam e in the A rticulator. This is done for all breakdow n instances. Subsequently, this breakdown object is then input to the articulation process, which then starts its diagnosis. 9 .4 .2 D ia g n o sis T he diagnosis sub-process in the A rticulator first searches th e dimensions of the problem space. Answers to the questions are derived as follows: D Q l: I s t h e SPM e n a c t m e n t c o m p l e t e ? F a c t : M o d i f y - C o d e h a s s t a t u s b r o k e n . A n s w e r : N o . D Q 2: I s t h e r e a p r o b l e m a t i c r e s o u r c e a s s o c i a t e d w i t h a b r e a k d o w n ? F a c t : T t i s S y s t e m - D e s i g n - D o c . A n s w e r : Y e s . D Q 3: I s t h e r e a p r o b l e m a t i c r e s o u r c e r e q u i r e m e n t ? F a c t : I t i s r e q - s p e c - f o r - m o d i f y - c o d e . A n s w e r : Y e s . D Q 4: I s t h e r e a m a t c h b e t w e e n t h e p r o b l e m a t i c r e s o u r c e a n d i t s r e q u i r e m e n t ? F a c t : T h e r e s o u r c e p o s s e s s i o n d o e s n o t m a t c h t h e r e s o u r c e r e q u i r e m e n t . A n s w e r : N o . D Q 5: W h a t r e s o u r c e s d o e s t h e b r o k e n a c t i v i t y p r o v i d e ? F a c t : S o u r c e - C o d e a n d O b j e c t - C o d e . A n s w e r : S o u r c e - C o d e a n d O b j e c t - C o d e . Based on this inform ation, the breakdown type is determ ined to be In ad eq u ate-R eso u rce-M atch . between System -D esign-D oc and its resource requirem ents. N ext, other dimensions are exam ined: 177 DQ6: How a r e t h e b r o k e n a c t i v i t y a n d t h e p r o b l e m a t i c r e s o u r c e r e l a t e d ? F a c t s : T h e r e e x i s t a R e q u i r e d - R e s o u r c e - S p e c l i n k i n g t h e m . A n s w e r: M o d if y - C o d e r e q u i r e s S y s t e m - D e s i g n - D o c . DQ7: I s t h e p r o b l e m a t i c r e s o u r c e p r o d u c e d i n t h e sam e SPM? F a c t s : S y s t e m - D e s i g n - D o c h a s a p r o d u c e r a c t i v i t y . A n s w e r: Y e s , I t w as l a s t m o d i f i e d b y M o d i f y - D e s i g n . Therefore, th e following values are identified for this breakdown: And a diagnosis is created as follows: { { breakdow n-12-1-11 instance: related-activity: developers: identified- di agnosi s: { { di agnosi s-12+ 12 instance: related-breakdown: breakdown-type: problem atic-resource: problem atic-resource-requirem ent: problem atic-resource-usage: problem atic-resource-class: other-instances-of-req: problem atic-resource- source: latest-provider: 9.4 .3 S e le c tio n Once a diagnosis is created as above, th e selection sub-process takes over to choose a PSH th a t is both applicable to the diagnosis and m ost suitable to use at this m om ent J According to the applicability heuristics, following PSHs can be used to solve this particular breakdown and they are indexed as a tuple of the four dimensions in the solution space shown in Table 9.11. In th e figure, ’*’ refers to all possible values in th e dim ension. If is used in a position for a type of resource usage, it can be one of agent, activity, tool, required-resource, and provided-resource. If it is for a J 178 breakdown M odify-C ode John D oug Chris diagnosis-1 2 + 1 2 } } diagnosis breakdow n-12+11 Inadequate-R esource-M atch System -D esign-D oc Required-for- M odify- Code required-resource System -D esign-D oc- Class nil Internal M odify-D esign}} Name Type of Operation Target Usage Op. Usage Op. Instance PSH1 replace-class * activity existing-other PSH2 replace-class others others existing-other PSH3 replace-class others others new PSH4 replace-instance others others existing-other PSH5 modify-spec others others * PSH6 restructure-add-activity-create others activity new PSH7 restructure-add-activity-enhance others activity new PSH8 restructure-del-all * others * PSH9 restructure-del-activity others activity * PSH10 redo- and- review others activity new Table 9.11: M atch between Diagnosis and PSH ( 1 ) C r e a t e a n o t h e r i n s t a n c e o f t h e a c t i v i t y t o b e r e d o n e ; ( 2 ) C r e a t e a new i n s t a n c e o f a c t i v i t y R e v ie w a n d a d d i t s r e s o u r c e r e q u i r e m e n t s ; ( 3 ) L i n k t h e tw o a s a c t i v i t y ( 1 ) p r o c e e d s a c t i v i t y ( 2 ) ; ( 4 ) I n s e r t ( 3 ) i n t o t h e p l a n j u s t b e f o r e t h e b r o k e n a c t i v i t y . Figure 9.1: A lgorithm ic D escription of R edo-and-R eview (PSH10) operand instance, it can be one of existing-self, existing-other, or new. And ’others refers to tool, required-resource, and provided-resource. Some of th e PSHs are easily excluded from th e current constraints for this ex am ple. For instance, PSH1 to PSH3 are not useful since no other functionally equivalent resource classes can replace System -D esign-D oc. PSH4 cannot be used because there exists no other instance to choose from. Following sim ilar steps, there is only one qualified PSH th a t can be used in this situation: PSH10. Therefore, it! is chosen by the selection sub-process. 9 .4 .4 R ec o v ery T he chosen PSH10 is then invoked w ith the identified diagnosis. PSH10 represents a com bination of re-planning actions th a t creates a pair of activities and inserts to the broken plan. Figure 9.1 gives an algorithm ic description of this PSH. W hen PSH10 is executed, a modified plan is created as in Figure 9.2. Since PSH10 is structural, this modified plan is not yet ready for enactm ent. Its current resource allocation has to be rearranged for the new p art. As such, we now explain _________________________________________________________________________________179 th e re-scheduling sub-process th a t com pletes the rem aining p art before enactm ent' re-starts. 9.4.5 R e-S c h e d u le T he articulation process now turns to consider the modified Develop-Change-and- Test-U nit-PM for re-scheduling (see Figure 9.2 for its activity hierarchy) togethex w ith P r o g r a m m i n g . The original schedule is Schedule (a) in Table 9.5. Two new schedules are created for this exam ple as shown in Table 9.12 anc Table 9.13 respectively. M ary assigns R e v i e w - D e s i g n to three agents, John, Doug] and Chris. Their presence is required for th e activity to be perform ed. T he schedule in Table 9.12 is based on R e - S c h e d u l i n g S t r a t e g y 1 th a t re-schedules the broken activity and all its successor activities. Table 9.12 (a) is th e rem aining schedule after p art of it is abandoned, and Table 9.12 (b) is the updated schedule. The schedule in Table 9.13 is based on R e - S c h e d u l i n g S t r a t e g y 2 th a t re-schedules all th e activities which are not started. Table 9.13 (a) is th e rem aining schedule after p art of it is abandoned and Table 9.13 (b) is the updated schedule. It turns out th a t th e schedule in Table 9.13 takes less tim e to com plete th an the one in Table 9.12] because of a b e tte r task allocation for the involved developers. At this m om ent, the re-scheduling m echanism does not optim ize modified schedules, but is equipped w ith capability th a t allows users to try out different strategies. 9.4.6 R ep a ir S u g g e stio n Now, consider w hat kind of model repair the discussed breakdown brought. For this exam ple, th e repair suggestion is to add an iteration th a t covers M o d i f y - D e s i g n anc R e v i e w - D e s i g n . T he rationale is to m ake sure the updated system design is correct before it goes to M o d i f y - C o d e . So if som ething is wrong in S y s t e m - D e s i g n - D o c , de-j velopers m ust redo M o d i f y - D e s i g n . As a result, though there is no iteration defined in the SPM (Figure 5.16) initially. However, after a breakdown of I n a d e q u a t e - R e s o u r c e - M a t c h is articulated. T he A rticulator introduces a new p art to th e SPM , as shown in Figure 9.2. Furtherm ore, after a plan repair, an iteration to encapsulate th e two activities in the generated repair is included in th e repair suggestion. If a m anager accepts this suggestion, she/he incorporates it into the 180, T im e M a ry P eter John D oug C hris M anager Q A -Engineer D esigner Engineer E ngineerl (a) T he Rem aining Schedule 0 A ssign-Task 1 M onitor M odify-T est-Plan C reate-M ain C reate-Sub 2 M onitor M odify-T est-Plan M odify-Design M odify-D esign 3 (canceled) Loop-Begin C reate-M ake 4 (canceled) C om pile (canceled) (canceled) (canceled) 5 (canceled) Debug 6 (canceled) M odify-Test-Pk Branch-Begin 7 (canceled) (canceled) (canceled) M odify-M ain M odify-M ake 8 M odify-Sub 9 B ranch-End 10 Loop-End (b) The M odified Schedule 0 A ssign-Task 1 M onitor M odify-T est-Plan Create-M ain Create-Sub 2 M onitor M odify-T est-Plan M odify-Design M odify-Design 3 M o n ito r Loop-Begin Create-M ake 4 M o n ito r C om pile M o d if y - D e s ig n M o d if y - D e s ig n 5 M o n ito r D ebug 6 M o n ito r M odify-Test-Pk Branch-Begin 7 M o n ito r M odify-M ain M odify-M ake 8 M o n ito r M odify-Sub 9 M o n ito r B ranch-End 10 M o n ito r Loop-End 11 M o n ito r R e v i ew -D e s i g n R e v ie w - D e s ig n R e v ie w - D e s ig n 12 M o n ito r M o d ify -C o d e Modi fy - C o d e M o d ify -C o d e 13 M o n ito r T e s t - U n i t T e s t - U n i t Table 9.12: The First Modified Schedule for the Two SPMs 181 T im e M a ry P eter John D oug C hris M anager QA-Engineer D esigner Engineer E ngineer 1 (a) The Rem aining Schedule 0 A ssign-Task 1 M onitor M odify-Test-Plan Create-M ain C reate-Sub 2 M onitor M odify-Test-Plan M odify-Design M odify-Design 3 (canceled) (canceled) (canceled) 4 (canceled) (canceled) (canceled) (canceled) (canceled) 5 (canceled) (canceled) 6 (canceled) (canceled) (canceled) 7 (canceled) (canceled) (canceled) (canceled) (canceled) 8 (canceled) 9 (canceled) 10 (canceled) (b) The M odified Schedule 0 A ssign-Task 1 M onitor M odify-T est-Plan Create-M ain Create-Sub 2 M onitor M odify-Test-Plan M odify-Design M odify-D esign 3 M o n it o r L o o p -B e g in C r e a te -M a k e 4 M o n it o r C o m p ile Modi f y - D e s i g n M odi f y - D e s i g n 5 M o n it o r R e v ie w - D e s ig n R e v ie w - D e s ig n R e v ie w - D e s ig n 6 M o n it o r D ebug Modi fy -C o d e M o d ify -C o d e M o d ify -C o d e 7 M o n it o r M o d if y - T e s t - P k B r a n c h - B e g in 8 M o n it o r T e s t - U n i t T e s t - U n i t M o d ify -M a in Modi fy-M ak e 9 M o d ify -S u b 10 B r a n c h -E n d 11 L oop -E n d Table 9.13: T he Second Modified Schedule for the Two SPMs 182 T A SK W IND O W t d e v e lo p _ c h a n g e _ a n d _ te s tju n it D eveloper! m a r y | Develop | | Detail | |Readyftctions| | History | |HiatoryReplayj | Info { f Finish | | Hode | [ Quit | T a s k L is t |Select[ jMove| |Reduce| |£nlBrge| |£nlargeHSpece| |EnlargeVSpacej |ReduceHSpace| |1 monitor | O N°ne © Active ^ Ready $ j j j | Allocated ^ Uait Resources Done Broken Stopped Not Chosen Assigned to other develops |2 test_unit | {3 modify_test_pk ] |4 modify_test_plan] |5 modify_code | | 6 loop_end | [7 revleu_design | |8 modify.deslgn | j 9 loop.begirt | j 10 assign_task | N .* Figure 9.2: T he Modified D evelop-Change-and-Test-Unit-PM original SPM . This new version of the SPM , depicted in Figure 9.2, takes care of a problem th a t was not addressed in th e previous version. Therefore, sim ilar break-J downs could be avoided in th e future. In this way, th e perform ance as well as the representation of an SPM is improved. 9.5 Lessons Learned from the Case Studies In this chapter, a scenario for a developm ent team enacting two SPM s is used to dem onstrate dynam ic analysis of SPMs in the A rticulator. T he dynam ic analysis of SPM s, i.e., process scheduling, sim ulation and articulation, is shown in three case studies. From these case studies, a num ber of lessons can be sum m arized as follows: • Process scheduling estim ates resource requirem ents and their tim ing for an SPM . In this study, process scheduling is used before SPM enactm ent starts to arrange proper resource allocation. Com pared to existing project scheduling 183 software packages, this process scheduling has two novel features: first, it pro vides user configurable resource constraints and heuristics, therefore it is easier to generate schedules th a t m atch an organization’s own objectives. Second, it operates on a consistent model of software processes, i.e., th e A rticulator m eta-m odel. Thus it provides users w ith an integrated framework. • Process sim ulation, based on th e results from process scheduling and devel opers’ behavioral specification, generates anticipated enactm ent trajectories. This helps m anagers predict w hat events can occur for a given schedule andj therefore be able to b ette r control SPM enactm ent. Process sim ulation takes into consideration resources th a t are produced and consumed w ithin SPM en-j actm ent when it creates an enactm ent trajectory, which process scheduling norm ally does not consider. However, this capability does not appear in these case studies due to space lim itations. A lthough some functionality of process sim ulation overlaps w ith process scheduling, process sim ulation handles more types of param eters th an process scheduling. Therefore, process sim ulation should be used when situations give arise the need for thorough study of SPM enactm ent and developers’ system ic behavior. • Process articulation is the m ost im portant and m ost difficult feature in dy nam ic analysis. It resolves process breakdowns th a t are caused by changes in th e environm ent. Such changes often invalidate resource allocation, a schedule,! or even the enacted SPM . As such, process articulation diagnoses the break-j down, and modifies either the resource allocation, the schedule, or the SPM accordingly. During process articulation, process scheduling and sim ulation are invoked to create new arrangem ents th a t accom m odate th e changes and ensure continuous SPM enactm ent. • W hen process articulation resolves a process breakdown, a solution can have two levels problem-solving complexity. If the breakdown can be overcome through rearranging resource allocation, the solution involves only resource reconfiguration and re-scheduling. This is relatively easier. On the other hand] if it turns out th at the enacted SPM m ust be modified, this involves a higher level of complexity. Process articulation m ust identify stru ctu ral changes to 184 th e SPM , im plem ent it, and re-schedule new resource allocation. T he last case study provides such a situation where SPM reconfiguration appears. At this tim e, there is little experience on using process articulation in real developm ent projects. Therefore, this rem ains a topic for the future research. 9.6 Summary T he dynam ic analysis of SPMs provides process m anagers w ith capabilities for ar ranging resource allocation and controlling SPM enactm ent statically and dynam-j ically. In this chapter, three case studies dem onstrated how dynam ic analysis of SPM s can be used in different ways. So far, a small num ber of exam ples have beeJ compiled th a t serve m ainly to dem onstrate, refine, and validate how process articu-j lation operates, as well as how resource scheduling, breakdown diagnosis, selection] recovery, and re-scheduling can be integrated. Nonetheless, these initial results are prom ising, and thus suggest the potential u tility for the form alization and oper ationalization of process articulation in support of software developm ent projects. B ut clearly, further testing in real developm ent scenarios is required before pro-J cess articulation can become a standard com ponent of commercial software project m anagem ent packages. 185 Chapter 10 Discussions and Conclusions T he research in this dissertation covers a m eta-m odel of software processes, an SPMl definition methodology, and static and dynam ic analysis of SPM s. In this chapter] th e lessons learned from this research are presented first. Then, the overall approach to software process modeling and analysis is com pared to th a t of software program m ing, from which m any developm ent concepts and approaches were reused. Next, th e m ajor contributions emerging from this research and from th e A rticulator sys tem to software process m odeling and enactm ent are identified. Last, future research work th a t expands th e process modeling, analysis, and articulation concepts, as well as functionality of the A rticulator is described. 10.1 What have we learned A t the beginning of this research, open issues of software process modeling and pro cess-driven software developm ent were surveyed and com pared. Based on the survey, two problems were identified: first, there exists little autom ated support for SPM construction, m easurem ent, and validation. This is called static analysis. Sec ond, there exists no models to describe the sim ulation of SPM s and th e articulation of process breakdown situations during SPM enactm ent. This is called dynam ic analysis. These two problem s of SPM analysis are considered crucial to the success of software process m odeling and process-driven software developm ent, as identified in th e em pirical studies surveyed in C hapter 2. The A rticulator is designed and im plem ented as an em bodim ent of a solution to the problems, First, the A rticulator provides a m eta-m odel of software processes 186 and th e resources involved. It acts as an object-oriented language th a t is capable of representing a family of software processes. The applicability of th e A rticulator m eta-m odel was dem onstrated through three case studies. These case studies de-j scribe different kinds of software processes ranging from small-scale research-oriented activities to large-scale commercial development. W hile defining the A rticulator m eta-m odel is a research topic, enhancing its usability is a practical issue th a t is equally im portant to end users if the A rticulator is to be used in th e real world. To this end, two mechanisms were im plem ented th a t support users when building custom ized SPMs in th e A rticulator m eta-m odel: First,! th e SPM definition methodology guides users to collect necessary knowledge and to| form ally represent the knowledge in form of an SPM. Second, th e static analysis of SPM s is a m eans to m easure custom ized SPMs. It indicates to users where and whyj an SPM has defects th a t needs to be enhanced. It also provides visualization tools: for process presentation. A lthough SPMs them selves are a useful outcom e for software m anagers, th e m ost im portant application of SPM s is to support actual software developm ent through! SPM enactm ent. To this end, this research provides two mechanisms: F irst, enact-j m ent sem antics formally define the m eaning and constraints for SPM enactm ent.' It forms a basis for enacting an SPM. Second, the dynam ic analysis of SPMs ab-J stracts em pirically observed knowledge of articulation and uses it to arrange resource requirem ents before and during SPM enactm ent, as well as resolve process break-J downs th a t are caused by outside changes. T he im portance of dynam ic analysis of SPMs lies in the fact th at environm ental changes are inevitable in SPM enactm ent! Therefore, such a m echanism is a m ust for successful SPM enactm ent. T he Articu-j lato r’s process articulation utilizes a knowledge-based technique, which uses existing articulation knowledge and is expandable to newly acquired articulation knowledge! In sum, th e m ethodological approach used in this research originates from a well established foundation. It provides not only form alism s th a t describe a fam ily of software processes and articulation knowledge; but also m echanisms th a t support^ the use of these formalisms. Finally, a num ber of case studies were presented to^ illustrate how these formalisms and mechanisms should be used. In th e next sec tion, this m ethodological approach is com pared w ith the well-known program m ing m ethodology th a t has formed m odern practice of com puter program m ing. 187 Development Stage SPMs Programs Representation The Articulator meta-model A Programming Language Coding Methodology SPM Definition Methodology Programming Methodology Coding Process Definition Table Language-directed Editors Static Checking Static Analysis Compilation Debugging SPM Simulation Software Test Reuse SPM Component Software Module Enactment Process Articulation None Table 10.1: Com parison between Program s and SPMs 10.2 In Retrospect The m ethodological approach to modeling, analyzing, and articulating software pro cesses using th e A rticulator system can be com pared w ith th e m ethodology for software program m ing and the im plem entation of a program m ing language. Ta-J ble 10.1 summ arizes this analogy between program s and SPM s from their respective developm ent activities. SPM s in the A rticulator have their own life-cycle. They experience sim ilar kinds of processing as program s do. For example, a presentation form alism is needed to describe both of them , th a t is, a program m ing language for program s and the A rticulator m eta-m odel for SPMs. The A rticulator m eta-m odel can be viewed as an object-oriented language for specifying and im plem enting SPMs. Second, con-j struction of SPMs is guided through the SPM definition methodology ju st like a program m ing methodology, such as [31]. SPMs are coded as a process input table to present approaches to software developm ent. Third, both program s and SPM s can be analyzed for their own m easurem ents. SPMs m ust be compiled and debugged before they are enacted. T he com pilation is done through static analysis, and the! debugging is supported through SPM sim ulation. Finally, SPMs can be reused oncej they are analyzed. As a result, construction of SPMs is sim ilar to th a t of program s and thus establishm ent of a process engineering m ethodology should take advan tage of th e experience from program m ing and program m ing methodologies. The A rticulator system described in this research embodies such a process engineering methodology. It follows the stages of construction, coding, debugging and execution for SPM s, and it provides autom ated support in each of the stages. 188 Unlike software program s which are executed in a closed system , SPM s are en acted by people in an open environm ent. Changes th a t alter th e environm ent and unexpected events th a t invalidate underlying constraints occur from tim e to tim e. Furtherm ore, developers often do not exactly follow an SPM as prescribed during their work. All these alterations bring updates to SPMs th a t m ust accom m odate th e outside world. To this end, process articulation acts as a repair and evolution mech-j anism th a t realizes the necessary changes to SPMs. As such, th e A rticulator is able to support dynam ic evolution of SPM th a t accom m odates changes, and therefore b e tte r ensure th e success of SPM enactm ent. 10.3 Summary of Research Contributions T he m ajor contributions of this work can be sum m arized as follows: 1. T h e A r tic u la to r m e ta -m o d e l, as a whole, provides a set of basic classes for describing a large family of software processes and process breakdowns. T he uniqueness of this m eta-m odel includes its ability to specify a num ber of types of resources involved in the software process w ithin a interrelated and knowledge-based framework. These basic object classes and relations provide fundam ental elem ents to modeling software processes. T he A rticulator’s SPM is the only form alism for specifying software processes w ith all following features: (1) an activity hierarchy w ith decom position of task stru ctu re and four types of execution orders, such as sequential, parallel, itera tive, and m ultiple choices; (2) resource requirem ents th a t include four types of resource usage: agent, tool, required-resource, and provided-resource; (3) re source allocation instances th a t are assigned to m atch resource requirem ents; and (4) relations among the features th a t define local constraints for SPM in stantiation and enactm ent. These features prove to be crucial in representing knowledge of large-scale software process, breakdowns, and articulation. T he A rticulator’s SPM includes a notation th a t separates the specification of process resource requirem ents and allocation. In research of project planning, including resource inform ation into a plan form alism was considered a m ajor contribution m ade by SIPE [95, 96]. The resource inform ation has been proved 189 valuable in providing m ore reasoning capability as to resource m anagem ent. Following the same direction, the A rticulator m eta-m odel further separates the notion of resource requirem ents and resource possession, which forms the underlying basis for detecting a wider range of breakdowns and repairs than those suggested in SIPE. 2. A n S P M d e fin itio n m e th o d o lo g y th a t guides the acquisition of software process knowledge and helps users specify SPM s based on this knowledge. Us-J ing this methodology, a num ber of exam ple SPMs were defined th a t describe various kinds of real processes. These SPMs can be reused in other organi zational settings as well. Further process definition and elaboration effort is under way to provide a m ore com plete process library [66] to enhance the reusability of these exam ple SPMs. 3. A fra m e w o rk fo r th e s ta tic a n d d y n a m ic a n a ly s is o f S P M s was de signed and im plem ented to provide m ore com prehensive support for process definition and analysis. Static analysis of SPM s detects the kinds of syntac tic, and sem antic m istakes commonly m ade by users and point out solutions. Sim ulation of SPM s, as one type of dynam ic analysis, estim ates possible re source allocation and task execution in m ulti-agent and m ulti-task environ m ents. A rticulation, as another type of dynam ic analysis, repairs broken SPM enactm ent to accom m odate environm ental changes in process-driven software developm ent. These process support m echanisms have been proven valuable for both research studies and early industrial applications. 4. A ta x o n o m ic m o d e l o f p ro c e ss b re a k d o w n , a r tic u la tio n k n o w le d g e , a n d a r tic u la tio n p ro c e ss th at serves as a conceptual basis for modeling articulation work and its related knowledge and skills. The m odel of pro cess breakdown includes a taxonom y of the observed breakdowns in em pirical studies and enables idiosyncratic breakdowns to be classified. The model of process articulation is a taxonom y of em pirically-grounded articulation m eth ods. Based on these models, heuristic process articulation, including diagnosis, selection, recovery, and re-scheduling, can be effectively indexed according to developm ent circum stances. This provides a form alism to study and abstract 190 further knowledge of articulation and evolve them as our understanding of articulation grows. This model represents the first form alization and oper ationalization of w hat was previously an informal but commonly practiced activity w ithin software developm ent, and forms an integrated support mech anism for SPM enactm ent. 5. Finally, th e A r tic u la to r s y s te m r e p re s e n ts a p ro c e ss e n g in e e rin g a p p ro a c h s u p p o r te d b y a s e t o f p ro c e s s m e c h a n ism s. This approach iden tifies a set of process engineering activities, such as definition, static analysis, sim ulation, enactm ent, and articulation. The approach also utilizes the A rtic ulator to provide a set of autom ated process mechanisms th a t support these process engineering activities. As such, w hat rem ains to be discussed is a' conceptual vision th a t integrate these process mechanisms. 10.4 Directions for Future Work The current im plem entation of the A rticulator, on one hand, m arks significant progress in modeling and analyzing software processes and process breakdowns. It also brings exciting opportunities for further research along the same direction. Ini simple term s, one focus for future research lies in integrating available process mech anisms as com ponents to support process-driven software developm ent [62, 67, 69]. An integrated PSEE is currently being im plem ented th a t realizes this conceptual architecture [79]. Conceptually, a PSEE manages and supports the production of software objects and th e invocation of developm ent tools guided by an SPM. T he architecture of this] PSEE is shown in Figure 10.1. Software components in a PSEE are represented as boxes in the figure: There is a distributed repository system [70] th a t stores and manages three kinds of objects: software objects produced by the PSEE, such as software docum ents and executables; development tools used in th e PSEE, such as language-directed editors and compilers; SPM s enacted in the PSEE. A user inter face provides user access to the objects in the repositories and a graphic workspace. Four process m echanisms are represented as circles in the figure. Each mechanism takes some objects as inputs and others as outputs, as suggested by the directed 191 r User I n te r f a c e T ro c e ss D e fin itio n T rocess Enactm ent p ro cess A rtic u la tio n ro c e ss R e p o s ito r Softw are R epository Tool R e p o sito ry A D is trib u te d R ep o sito ry System Figure 10.1: Software Process M echanisms in a Process-Driven SEE lines betw een the software com ponents and the process mechanisms. We believe th a t these four process mechanisms constitute a key set of functionality needed to support a PSEE. Process definition helps process designers to create SPM s. W hen defining an SPM , a designer uses a form alism to specify an SPM based on project-specific task and resource requirem ents. To take advantage of existing process knowledge, the designer can access and browse th e process repository, called SPLib, in order to help define or reuse other SPMs. The A rticulator m eta-m odel, static analysis of SPMs,I and sim ulation presented in this dissertation provides th e capability of defining syn tactically and sem antically correct SPMs. S P M enactm ent executes an SPM according to the enactm ent semantics. This is the core of a PSEE th a t helps realize actual software production. During SPM enact m ent, software artifacts and executables are produced w ith the support of specified developm ent tools. For exam ple, when a developer executes an edit activity to mod ify a source code object, SPM enactm ent can invoke a language-directed editor w ith th e source code object from their respective repositories and retu rn th e results in the 192 same m anner. T he outcom e of an SPM is either th e SPM ’s designated ou tp u t prod ucts, or a process breakdown th a t prevents further enactm ent. In our PSEE, PB I1 serves as an SPM enactm ent driver th at im plem ents th e SPM enactm ent semantics^ to control and visualize SPM enactm ent through a graphic user interface [68]. PBI| provides two user interfaces for software product developers and process managers to use w ithin a PSEE. A developer’s interface provides a workspace and a m anager’s interface provides a m onitor and control m echanism for enactm ent. Process articulation is a form of dynam ic process analysis th a t reactively repairs or restructures the enacted SPM in order to resolve or avoid process breakdowns Therefore, as soon as a problem occurs, SPM enactm ent should switch the enacted SPM to process articulation, T he articulation process described in this dissertation! analyzes of the situation and the available resources in th e PSEE, then seeks to identify or suggest a solution th a t can be im plem ented by modifying th e SPM orj its resource configuration. The modified SPM can then be used to continue SPM] enactm ent. This continues until the SPM enactm ent is complete. Process repository manages th e access and reuse of SPMs in the distributed repos itory system . It defines th e storage architecture of all the SPMs and acts as an inter face to them . It also provides a set of operations th a t facilitate search, composition, and reuse of SPM s. T he process repository system in the PSEE is called SPLib [66] J It represents software processes as different classes and instances. It also defines relationships among SPMs to indicate instantiation, abstraction, composition, or, derivation. Such an architecture for PSEE supports process-driven software developm ent through integration of process definition, analysis, enactm ent, articulation, and repository. To this end, the process mechanisms described in this dissertation playj a key role to the success of PSEE. Such an integrated process-driven environm ent will be the center of a D istributed System Factory as described in [79]. Overall, th e A rticulator system embodies a software process engineering ap proach th a t supports modeling and analyzing software processes, and recovering from process breakdown during SPM enactm ent. T he A rticulator incorporates an object-oriented representation of software processes and process breakdowns using, a process m eta-m odel. This m eta-m odel enables the static analysis of SPMs as to help users describe and validate their own software processes. This m eta-m odel 193 also enables th e dynam ic analysis of SPMs to help users estim ate and adjust the. dynam ics of SPM enactm ent, articulate process breakdown situations, and evolve software processes through dynam ic changes. As such, a num ber of case studiesj th a t utilize process modeling and analysis are discussed which cover both academ ic and industrial applications. The long-term goal of this research is to create a PSEE' th a t integrates process definition, analysis, enactm ent, and articulation w ith new or existing software engineering tools. Such an environm ent would provide users with process-guided activity execution, resource m anagem ent, and tool invocation. In the future, such an experim ent can be undertaken to integrate the A rticulator system! w ith a commercial SEE. 194 Reference List [1] V. Am briola, P. Ciancarini, and C. M ontangero. Software Process E nactm ent in Oikos. In Proc. o f the 4th A C M SIG SO F T Sym posium on Software Development Environm ents, pages 183-192, Irvine, CA, Dec. 3-5 1990. [2] V .R. Basili. Software Development: A Paradigm for th e Future. In Proc. oj C O M P SA C ’ 89, pages 471-485, Orlando, FL, Sept. 1989. [3] V.R. Basili and H.D. Rombach. T he TAM E Project: Towards Improvement- O riented Software Environm ents. IE E E Trans, on Software Engineering, 14(6), June 1988. [4] N. B elkhatir, J. Estublier, and W .L. Melo. Adele 2: A Support to Large Soft ware Development Process. In Proc. o f the 1st International Conference on the Software Process, pages 159-170, Redondo Beach, CA, O ct 1991. [5] S. Bendifallah and W . Scacchi. U nderstanding Software M aintenance Work. IE E E Trans, on Software Engineering, 13(3):311-323, M ar 1987. [6] S. Bendifallah and W . Scacchi. Work Structures and Shifts: An Em pirical Analysis of Software Specification Teamwork. In Proc. o f the 11th International Conference on Software Engineering, pages 260-270, P ittsburgh, PA, May 1989. [7] B.I. Blum. Thoughts on the Software Process. A C M S IG SO F T Software E n gineering Notes, ll(4):25-26, Aug 1986. [8] M.C. Brown. The Dynam ic Rescheduler: Conquering the Changing Production Environm ent. In IE E E fth Conference on Artificial Intelligence Applications, pages 175-180, 1988. [9] L. Brownston, R. Farrell, E. K ant, and N. M artin. Programming Expert Systems in OPS5. Addison-W esley Publishing Company, Inc., 1985. [10] G. Bruno, A. Elia, and P. Laface. A rule-based system to schedule production. IE E E Computer, 19(7):32-39, 1986. [11] R .F. Bruynooghe, J.M . Parker, and etc. PSS: A System for Process Enactm ent. In Proc. o f the 1st International Conference on the Software Process, pages 128- 141, Redondo Beach, CA, Oct 1991. 195 [12] Carnegie Group Inc. Knowledge Craft U ser’ s Guide (Vol.l, Vol.2, and Vol.3), 1986. [13] S.C. Choi. SO F TM A N : A n Environm ent Supporting the Engineering and R e verse Engineering o f Large Scale Software Systems. PhD thesis, Com puter Science D ept, USC, CA, May 1989. [14] S.C. Choi and W . Scacchi. SOFTM AN: An Environm ent for Forward and Reverse CASE. Inform ation and Software Technology, 33(9), Nov. 1991. [15] Inc. C om puter Associates. CA-SuperProject U ser’ s Guide. 1992. [16] R. Conradi, E. Osjord, and etc. Initial Software Process M anagem ent in EPO S. Software Engineering Journal, 6(5):275-284, Sept 1991. [17] B. C urtis, H. K rasner, and N. Iscoe. A Field Study of the Software Design Process for Large Systems. Com munications o f ACM , 31(11):1268-1287, Nov 1988. [18] B. C urtis, H. K rasner, V. Shen, and N. Iscoe. On Building Software Process Model U nder th e Lam ppost. In Proc. o f the 9th International Conference on Software Engineering, pages 96-103, M onterey, CA, A pr 1987. [19] W . D ieters and V. Grulm. M anaging Software Processes in the Environm ent M ELM AC. In Proc. o f the 4th A C M SIG S O F T Sym posium on Software Devel opment Environments, pages 193-205, Irvine, CA, Dec. 3-5 1990. [20] W . Em m erich, G. Junkerm an, and etc. Merlin: Knowledge-based Process Mod eling. In Proc. o f 1st European Workshop on Software Process Modeling, pages 181-186, 1991. [21] M.S. Fox. Constraint-guided scheduling - a short history of research at emu. Computers in Industry, 14:79-88, May 1990. [22] M.S. Fox, N. Sadeh, and etc. Constrained H euristic Search. In Proc. o f Joint International Conference on Artificial Intelligence, pages 309-315, 1989. [23] M.S. Fox and S.F. Sm ith. ISIS: A Knowledge-based System for Factory Schedul ing. Expert System s, 1:25-49, 1984. [24] D. Frailey. Defining a Corporate-wide Software Process. In Proc. o f the 1st In ternational Conference on the Software Process, pages 113-121, Redondo Beach, CA, Oct 1991. [25] D. Frailey, R. Bate, and etc. Modeling Inform ation in a Software Process. In Proc. o f the 1st International Conference on the Software Process, pages 60-67, Redondo Beach, CA, O ct 1991. 196 [26] P.K. Garg. Inform ation M anagement in Software Engineering, A Hypertext Based Approach. PhD thesis, Com puter Science D ept, USC, Feb 1989. [27] P.K. Garg and W . Scacchi. ISHYS: Designing Intelligent Software H ypertext Systems. IE E E Expert, 4(3):52-63, 1989. [28] L. Gasser. T he Integration of Com puting and R outine Work. A C M Trans, on Office Inform ation System s, 4(3):205-225, July 1986. [29] M. Genesereth. An Overview of M eta-level A rchitecture. In Proceedings A A A I- 83, W ashington, DC, 1983. [30] E.M . Gerson and S.L. Star. Analyzing Due Process in the W orkplace. A C M Trans, on Office Inform ation System s, 4(3):257-270, July 1986. [31] D. Gries. Programming Methodology. 1981. [32] R. G uindon, H. K rasner, and B. Curtis. Breakdowns and Processes during the Early A ctivities of Software Design by Professionals. In G.M Olson, S. Shep pard, and E. Soloway, editors, Empirical Studies o f Programmers (Second Work shop), pages 65-82. Ablex Publishing Corporation, 1987. [33] K .J. Ham m ond. Explaining and Repairing Plans th a t Fail. Artificial Intelli gence, 45(3): 173-228, 1990. [34] D. Heimbigner. Software Process Exam ple for ISPW -7. In The 7th Interna tional Software Process Workshop. California, Oct 1991. [35] C. H ew itt. Offices Are Open Systems. A C M Trans, on Office Inform ation System s, 4(3):271-287, July 1986. [36] K .E. Huff. Plan-Based Intelligent Assistance: A n Approach to Supporting the Software Development Process. PhD thesis, C om puter and Inform ation Science D ept, University of M assachusetts, 1989. [37] K.E. Huff and V.R. Lesser. A Plan-Based Intelligent A ssistant T h at Supports the Process of Program m ing. A C M SIG SO F T Software Engineering Notes, 13:97-106, Nov 1988. [38] W.S. Humphrey. Managing the Software Process. Addison-W esley Publishing, Company, Inc., 1989. [39] W.S. H um phrey and M.I. Kellner. Software Process Modeling: Principles of E n tity Process Models. In Proc. o f the 11th International Conference on Soft ware Engineering, pages 331-342, P ittsburgh, PA, May 1989. 197 [40] H. Iida, T. Ogihara, and etc. G enerating A M enu-Oriented N avigation Sys tem from Development A ctivity Sequences. In Proc. o f the 1st International Conference on the Software Process, pages 45-57, Redondo Beach, CA, Oct 1991. [41] N orthrop Inc. AV-1 Flight M anagem ent O perational Flight Program : Integra tion Test Plan. Technical report, N orthrop Inc., M ar 1986. [42] N orthrop Inc. Com puter Program Development Plan. Technical report, N orthrop Inc., June 1987. [43] N orthrop Inc. Software Test Development Folder. Technical report, N orthrop Inc., Oct 1987. [44] N orthrop Inc. N orthrop B2 Division Software Engineering Practices. Technical report, N orthrop Inc., Sept 1990. [45] K. Inoue, T. Ogihara, and etc. A Formal A daptation M ethod for Process Descriptions. In Proc. o f the 11th International Conference on Software Engi neering, pages 145-153, P ittsburgh, PA, May 1989. [46] A. Jazzar and W. Scacchi. U nderstanding Software Docum entation: Products, Processes and Settings. Technical report, Com puter Science D ept. USC, Oct 1987. [47] G.E. Kaiser. Rule-Based Modeling of th e Software Development Process. In The 4th International Software Process Workshop, pages 84-86, New York, NY, 1988. [48] G.E. Kaiser, N.S. Barghouti, and M.H. Sokolsky. Prelim inary Experience with Process M odeling in th e Marvel Software Development Environm ent Kernel. In Proc. o f the 23rd Annual Hawaii International Conference on System, Science, pages 131-140, Jan 1990. [49] G.E. Kaiser and P. Feiler. An architecture for intelligent assistance in soft ware developm ent. In Proc. o f the 9th International Conference on Software Engineering, pages 180-187, M onterey, CA, Apr 1987. [50] T. K atayam a. A Hierarchical and Functional Software Process Description and Its Enaction. In Proc. o f the 11th International Conference on Software Engineering, pages 343-352, P ittsburgh, PA, May 1989. [51] M. Kellner, P.H. Feiler, A. Finkelstein, and etc. Software Process Modeling Exam ple Problem . In The 6th International Software Process Workshop. Japan, Oct 1990. 198 [52] N. Keng and D.Y.Y. Yun. A Planning/Scheduling M ethodology for the Con strained Resource Problem . In Proc. o f Joint International Conference on A r tificial Intelligence, pages 998-1003, 1989. [53] B. Khoshnevis and Q. Chen. Integration of process planning and scheduling functions. Journal o f Intelligent M anufacturing, pages 165-176, 1990. [54] K. K ishida and T. K atayam a. SDA: A Novel Approach to Software Environ m ent Design and Construction. In Proc. o f the 10th International Conference on Software Engineering, pages 69-79, Apr 1988. [55] R. Kling and W . Scacchi. The Web of Com puting: Com puter Technology as Social O rganization. In Advances in Computers, Vol.21, pages 1-90. Academic Press, Inc., 1982. [56] H. K rasner, B. C urtis, and N. Iscoe. Com m unication Breakdowns and Bound ary Spanning A ctivities on Large Program m ing P roject. In G.M Olson, S. Shep pard, and E. Soloway, editors, Em pirical Studies o f Programmers (Second W ork shop), pages 47-64. Ablex Publishing Corporation, 1987. [57] R.R. Levary and C.Y. Lin. Modeling the Software Development Process Using an E xpert Sim ulation System Having Fuzzy Logic. Software - Practice and Experience, 21 (2): 133-148, Feb 1991. [58] N.H. M adhavji. The Process Cycle. Software Engineering Journal, 6(5):234- 242, Sept 1991. [59] N.H. M adhavji and V. G ruhn. Prism = M ethodology + Process-oriented Envi ronm ent. In Proc. o f the 12th International Conference on Software Engineer ing, 1990. [60] C. Meng and M. Sullivan. Logos: A C onstraint-D irected Reasoning Shell for; O perations M anagem ent. IE E E Expert, 6(l):20-28, Feb 1991. [61] J.R . M eredith and Jr. S.J. M antel. Project M anagement: A M anagerial A p proach. John W iley and Sons, Inc., 1985. [62] P. Mi, A. K arrer, and W . Scacchi. Supporting Software Development through M ultiple Interacting Software Process Models. Technical report, C om puter Sci ence D ept. USC, Los Angeles, CA, June 1992. Subm itted for Publication. [63] P. Mi and W . Scacchi. A Knowledge-based Environm ent for Modeling and Sim ulating Software Engineering Processes. IE E E Trans, on Knowledge and Data Engineering, 2(3):283-294, Sept 1990. 199 [64] P. Mi and W . Scacchi. A rticulation: Supporting Dynam ic Evolution of Software Engineering Processes. The 7th International Software Process Workshop, Oct 1991. [65] P. Mi and W . Scacchi. Modeling A rticulation Work in Software Engineering Processes. Proc. o f the 1st International Conference on the Software ProcessJ pages 188-201, Oct 1991. [66] P. Mi and W . Scacchi. A Knowledge-based Software Process Library for| Process-driven Software Development. Technical report, Com puter Science D ept. USC, Los Angeles, CA, April 1992. to be published at the 7th Knowledge- Based Software Engineering Conference. [67] P. Mi and W . Scacchi. A Unified Model of Software Systems, Agents, Tools, and Processes. Technical report, Com puter Science D ept. USC, Los Angeles, CA, June 1992. Subm itted for Publication. [68] P. Mi and W . Scacchi. Process Integration in CASE Environm ents. IE E E Software, 9(2):45-53, M arch 1992. [69] P. Mi and W . Scacchi. Software Process Development Mechanisms for Process- Centered Environm ents. Technical report, Com puter Science Dept. USC, Los Angeles, CA, April 1992. Subm itted for Publication. [70] J. Noll and W . Scacchi. Integrating Diverse Inform ation Repositories: A Dis trib u ted H ypertext Approach. Computer, 24(12);38-45, Dec. 1991. [71] L. Osterweil. Software Processes are Software Too. In Proc. o f the 9th Inter national Conference on Software Engineering, pages 2-13, M onterey, CA, Apr 1987. [72] P.S. Ow, S.F. Sm ith, and A. Thiriez. Reactive plan revision. In Proc. o f 7th National Conference on AI, pages 77-82, Aug. 1988. [73] D.E. Perry. The Inscape Environm ent. In Proc. o f the 11th International Con ference on Software Engineering, pages 2-12, P ittsburgh, PA, May 1989. [74] F.A . Rodam m er and Jr. K.P. W hite. A recent survey of production scheduling. IE E E Trans, on System s, Man, and Cybernetics, 18(6):841-851, 1989. [75] Jr. S. Sutton, D. Heimbigner, and L.J. Osterweil. Language C onstructs for M anaging Change in Process-Centered Environm ents. In Proc. o f the 4th AC M SIG SO F T Sym posium on Software Development Environm ents, pages 206-217, Irvine, CA, Dec. 3-5 1990. 200 [76] Jr. S. Sutton, H. Ziv, and etc. Program m ing a Software Requirem ents- Specification. In Proc. o f the 1st International Conference on the Software Process, pages 68-89, Redondo Beach, CA, Oct 1991. [77] A. Sathi, M.S. Fox, and M. Greenberg. R epresentation of activity knowledge for project m anagem ent. IE E E Trans, on Pattern Analysis and M achine Intel ligence, 7(4):531-552, 1985. [78] W . Scacchi. The Process o f Innovation in Computing: A Study o f the Social D y namics o f Computing. PhD thesis, D ept, of Inform ation and C om puter Science] Univ. of California, Irvine, 1981. [79] W . Scacchi. The Software Infrastructure for A D istributed System Factory. Software Engineering Journal, 6(5):355-369, Sept 1991. [80] R.C. Schank. Explanation Patterns: Understanding Mechanically and Cre atively. Erlbaum Hillsdale, N J, 1986. [81] S.F. Sm ith, M.S. Fox, and P.S. Ow. C onstructing and M aintaining Detailec Production Plans: Investigations into the Development of Knowledge-based Factory Scheduling Systems. A I Magazine, pages 45-61, Fall 1986. [82] X. Song and L. Osterweil. Com paring Design M ethodologies through Process Modeling. In Proc. o f the 1st International Conference on the Software ProcessJ pages 29-44, Redondo Beach, CA, Oct 1991. [83] M. Stefik. M OLGEN P art 1: Planning w ith Constraints. Artificial Intelligence, 16(2):111— 139, May 1981. [84] M. Stefik. M OLGEN P art 2: Planning and M eta-Planning. Artificial Intelli gence, 16(2):141-169, May 1981. [85] K. Stepm an. B u yer’ s Guide to Project M anagement Software. New Issues, Inc.. 1986. [86] A. Strauss. The A rticulation of Project Work: An O rganizational Process. Tht Sociological Quarterly, 29(2):163-178, A pr 1988. [87] L.A. Suchman. Office Procedure as Practical Action: Models of Work and System Design. A C M Trans, on Office Inform ation System s, l(4):320-328, O ct 1983. [88] Y . Sugiyama. Object Process Modeling and the Process Programming Language G ALO IS. PhD thesis, C om puter Science D ept. University of Southern Califor nia, Apr 1990. 201 [89] Y. Sugiyama and E. Horowitz. OPM : An O bject Process M odeling Environ-j m ent. In The 5th International Software Process Workshop, pages 134-136, Oct* 1989. [90] Y. Sugiyama and E. Horowitz. Building Your Own Software Development En vironm ent. Software Engineering Journal, 6(5):317-331, Sept 1991. [91] R.N. Taylor, F.C . Belz, L.A. Clarke, and L. Osterweil. Foundations for the A rcadia Environm ent A rchitecture. A C M S IG P L A N Notice, pages 1-13, Feb 1989. [92] D.B. Walz, J.J. Elam , H. K rasner, and B. Curtis. A M ethodology for Studying Software Design Teams: An Investigation of Conflict Behaviors in the Require-! m ents Definition Phase. In G.M Olson, S. Sheppard, and E. Soloway, editors,! Em pirical Studies o f Programmers (Second Workshop), pages 83-99. Ablex P ub lishing Corporation, 1987. [93] B. Warboys. T he IPSE 2.5 Project: Process Modeling as the Basis for a Support Environm ent. Technical report, University of M anchester, Sept. 1989. [94] J.C . W ileden. This is IT: A M eta-M odel of the Software Process. A C M SIG S O F T Software Engineering Notes, 11(4):9-11, Aug 1986. [95] D.E. W ilkins. Dom ain-independent Planning: Representation and P lan Gener ation. Artificial Intelligence, 22(3):269-301, April 1984. [96] D.E. W ilkins. Practical Planning: Extending the Classical A I Planning Paradigm. M organ Kaufm ann Publishers, Inc., 1988. [97] L.G. W illiams. Software Process Modeling: A Behavioral Approach. In Proc. o f the 10th International Conference on Software Engineering, pages 174-200, Apr 1988. [98] H .T. Yeh. Re-Engineering a Software Development Process for Fast Delivery. In Proc. o f the 1st International Conference on the Software Process, pages 106-112, Redondo Beach, CA, Oct 1991. [99] W. Zhao and K. R am am ritham . Simple and integrated heuristic algorithm s forj scheduling tasks w ith tim e and resource constraints. Journal o f System s and Software, 7:195-205, 1987. 202

Abstract (if available)

Linked assets