University of Southern California Dissertations and Theses

An integrated systems approach for software project management

(USC Thesis Other)

An integrated systems approach for software project management

PDF

Download

Open document

Flip pages

Download a page range

Download transcript

Copy asset link

Request this asset

Transcript (if available)

Content AN IN TEG R A TED SYSTEMS A PPR O A C H FO R SO FTW A RE P R O JE C T M A NAGEM ENT by Lung-Chun Liu A D issertation Presented to the FACULTY OF TH E GRADUATE SCHOOL U N IV ERSITY OF SOUTHERN CA LIFORNIA In P artial Fulfillment of the Requirem ents for the Degree D O C T O R O F PH ILO SO PH Y (C om puter Science) December 1988 UMI Number: D P22778 All rights reserved INFO RM ATIO N 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 D P22778 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 4 8 1 0 6 -1 3 4 6 UNIVERSITY OF SOUTHERN CALIFORNIA THE GRADUATE SCHOOL UNIVERSITY PARK LOS ANGELES, CALIFORNIA 90089 This dissertation, w ritten by under the direction of hi-.S. Dissertation Committee; and approved by all its members, has been presented to and accepted by The Graduate School, in partial fulfillm ent of re quirements for the degree of T h .D . Cp S L 7SJ Lung-Chun L iu D O C TO R OF PH ILOSOPH Y Dean of Graduate Studies Date DISSERTATION COMMITTEE '.hairperson Acknowledgment s I would like to express my appreciation to m y thesis advisor, Professor Ellis Horowitz for his direction and guidance throughout my studies. His enthusiasm tow ards research and his instinctive view into th e problem s of software engi neering m ade this thesis possible. O ther m em bers of m y dissertation com m it tee, Professor Dennis M cLeod, and Professor Jean-Luc G audiot deserve special thanks for th eir valuable com m ents and suggestions which enhanced the tech nical contents of this dissertation. I would like to th an k m y friends at USG for the w arm friendship, especially the people in th e Script W riter Lab. In particular, I am grateful to Dr. Rajiv G u p ta for providing me access to the com puting resource, Sheng-Yaw Lin for lending me the equipm ent to draw all the figures, Qiang W an for fixing some X window problem s, and Wesley Cheng and Ido H ardonag for discussing various problem s in Vbase. I th an k m y parents for their endless love, support and encouragem ent, which m ade it possible for me to continue m y graduate study. Finally, I wish to express m y greatest g ratitude to m y wife, Jill, for m ore th an I can ever acknowledge here, for her confidence and patience in m e throughout th e long journey of research. Contents I A c k n o w led g m e n ts i L ist o f F ig u res A b str a c t 1 1 In tr o d u c tio n 1.1 The T raditional Elem ents of P roject M anagem ent 1.1.1 Basic Definitions of P roject M anagem ent 1.1.2 T he Traditional M o d e ls................................ 1.2 P roject M anagem ent Systems ................................ 1.2.1 Existing P a c k a g e s .......................................... 1.2.2 Cost E stim ation M o d e l s ............................ 1.3 Inadequacies of the Existing M o d e ls ..................... 1.4 O rganization of th e D is s e r ta tio n ............................ 2 R e la te d R esea rch 2.1 Project Knowledge R e p re se n ta tio n ......................... 2.2 Project P la n n in g ........................................................................................... 2.3 Resource A llocation and S c h e d u lin g ..................................................... 2.4 Project Progress M o n ito r in g ................................................................... 2.5 Software Engineering Support ............................................................... 2.5.1 S O D O S .................................................................. ........................... 2.5.2 P M D B .............................................................................................. 2.5.3 I S T A R .............................................................................................. 2.6 Sum m ary of R elated R e s e a r c h ............................................................... D e s ig n N e t — A H y b rid M o d el for S oftw are P r o je c t M a n a g em en t 3.1 T he Software Process Model ................................... . . . 3.2 Some Potentially Useful Models .............................................. 3.2.1 A nd-O r G r a p h s ............................................................................. 3.2.2 P etri Net M o d e l............................................................................. 3.2.3 Inadequacies of These M o d e ls ................................................. 3.3 A H ybrid M odel Solution — the DesignNet M odel . .................. 3.3.1 T he DesignNet M o d e l................................................................. 3.3.2 M apping th e W aterfall M odel onto the DesignNet . . . . 3.3.3 Im plications of the Model ........................................................ 3.4 Analysis of D e s ig n N e ts .............................................................................. 77 4 O b jec t D a ta b a se S u p p o rt for th e D e s ig n N e t M o d e l 84 4.1 Software P roject M anagem ent D ata Requirem ents . ....................... 86 4.2 The DesignNet M odel in Term s of O b j e c t s ............................................89 4.3 Relationships am ong O bject Types .......................................................... 90 4.4 Tim e N otation and Stam ping M e c h a n ism ................................................94 4.5 W ork Breakdow n S tructure R e p re s e n ta tio n ............................................98 4.6 Event M onitoring and Project History R eco rd in g ............................... 100 4.7 D ocum ent Version C ontrol ......................................................................107 5 D e sig n P la n — A n In te g r a te d S y ste m for S oftw are P r o je c t M a n a g em en t 112 5.1 Overall System A r c h ite c tu r e ...................................................................... 113 5.1.1 An O bject Program m ing In te rfa c e .............................................. 118 5.1.2 Interfaces to O ther T o o ls ............................................................... 130 5.2 User P e rs p e c tiv e ...............................................................................................132 5.2.1 Q uery E x a m p le s.................................................................................134 5.3 Scenarios of P rototype .................................................................................141 6 C o n clu sio n s an d F u tu re R esea rch 155 6.1 Results and C ontributions ......................................................................... 155 v 6.2 Future Research D ire c tio n s ........................................................................158 A S y n ta x D e sc r ip tio n o f T D L an d C O P 162 B A G rap h ic O rien ted V b a se O b ject T y p e H iera rch y B r o w se r l6 5 B .l Introduction . . . . ............................................ 165 B.2 D em onstration S c e n a rio ...............................................................................167 B.3 In tern al D e sig n ................................................................................................168 B.3.1 D ata S tructure ................................................................................180 B.3.2 A lg o rith m s..........................................................................................182 B.4 S u m m a ry ..................................... 186 B ib lio g r a p h y 189 List of Figures 1.1 A Sam ple W ork Breakdown S t r u c t u r e .............................................. 6 1.2 Segment of W BS for H ypothetical P r o je c t........................................ 8 1.3 A Sam ple G an tt C hart .......................................................................... 9 1.4 Tw o G raphical Ways to Show an A ctivity N e tw o rk .......................... 11 1.5 An activity-on-edge project exam ple.........................................................12 1.6 A ssociated tim e values com puted from th e exam ple project. . . 14 1.7 B eta D istribution for P E R T A c tiv itie s ...................................................15 2.1 P artial O rdering of A c tio n s ........................................................................31 2.2 Fram e G estalt ................................................................................................ 33 3.1 W aterfall m odel.................................................................................................45 3.2 P etri net of a sender-receiver system .........................................................50 3.3 A n exam ple of the D esignN et...................................................................... 57 3.4 T he token propagation through stru ctu ral operators..................... 60 3.5 DesignNet graphical re p re sen ta tio n .......................................................... 62 3.6 DesignNet of Life Cycle P h a s e s ................................................................. 66 vii 3.7 Sam ple decom position of a design task .....................................................68 3.8 Legal stru ctu ral connection types............................................................... 79 3.9 Existence of a success-execution loop........................................................83 4.1 O bject type hierarchy of D e s ig n N e t....................................................... 90 4.2 R elationships am ong object types in D esig n N et..................................92 4.3 Tim e object type and operation definition . ..................................... 95 4.4 CO P program segment for current tim e o p e r a t i o n ........................... 96 4.5 S tru ctu ral operator and wbs link d e f in itio n ......................................... 99 4.6 A ctivity cost com putation m ethod .......................................... 101 4.7 Transition subtypes d efin itio n...................................................................103 4.8 P lanned place and token d e f in itio n s .....................................................106 4.9 P lanned product and product token d e fin itio n s ................................109 4.10 CO P for creating a new product v e rs io n ..............................................110 5.1 A rchitecture of the D esignPlan S y s t e m ..............................................114 5.2 Im p o rt/E x p o rt m echanism in D e s ig n P la n .......................................... 131 5.3 D esignPlan top level screen. ................................................................... 142 5.4 Subfunctions under project com m and.....................................................143 5.5 Project object creation form ....................................................................... 144 5.6 Assigning the m anager to a p ro ject......................................................... 145 viii 146 147 148 149 150 151 152 153 154 169 170 171 172 173 174 175 176 177 178 ix Recursive creation of the person o b ject........................................... C reating a tim e object for the project sta rt tim e........................ T he created project w ith default decom position.......................... Subfunctions under wbs com m and..................................................... Selecting the stru ctu ral operator ty p e............................................. Defining properties of lower level place........................................... T he wbs after decom position............................................................... F urther decom position of the activity hierarchy. ..................... C onstrained view of the design activity hierarchy....................... Functions available under browse com m and.................................. Select either user defined object types or predefined system types.............................................................................................................. O bject type hierarchy rooted at SPlace o b ject............................. P roperties defined under $Project o b ject....................................... Select system type library through in p u t....................................... Choose to view the SAggregate object type hierarchy. . . . . O bject ty p e hierarchy rooted at $ A ggregate o b ject.................... Scrolling to th e right of th e $ Aggregate hierarchy....................... P roperties defined under $ A rray o b ject.......................................... P roperties defined under $Stack o b ject........................................... B .ll B.12 O bject type hierarchy rooted at $Type o b ject................................... 179 Tree node d a ta structure d e fin itio n ....................................................... 180 x Abstract This dissertation presents a m odel, th e DesignNet m odel, for describing and m onitoring th e software developm ent process, and a system , the D esignPlan system , to support an extensible software project m anagem ent environm ent. DesignNet utilizes th e A N D /O R graph and P etri net n o tatio n to provide the description of a project work breakdow n structure and th e specification of re lationships am ong different project inform ation types — activity, product, re source, and statu s report inform ation. Its m ost novel feature is th a t it allows for th e re-initiation of activities and for the re-structuring of th e plan, two phe nom ena th a t are common for software developm ent, b u t not addressed in any existing models. A nother unique characteristic of the DesignNet is th a t the project history is autom atically tracked down by the system . This feature is achieved through a tran sitio n firing and token in stan tiatio n m echanism . T hus, b o th the static construct, th e project plan, and th e dynam ic p art, th e project execution history, of a project are captured. As a new theory of software project m anagem ent, we first judge its value in relation to the process it models. We show how the classical w aterfall m odel can be described using DesignNet. T hen we show how th e m odel leads to im p o rtan t com putable notions such as connectedness, plan com plete, plan consistent, and well-executed. A project m anager can use these analysis techniques to help him detect any problem concerning project planning or execution. T he D esignPlan system is a prototype built to illustrate the applicability of D esignN et. T he front end of the system is a window based user interface. Be n eath th e DesignNet representation is an object-oriented database th a t supports the project inform ation storing and retrieval. An object program m ing interface is defined and higher level m anagem ent tools can be easily incorporated into the system thro u g h this interface. C urrently three functional m odules are included in th e system , th e activity scheduling m odule, th e resource allocation m odule, and th e cost estim ation m odule. Such an architecture offers an open and ex tensible software engineering environm ent. T he developm ent environm ent can be set up in an increm ental m anner. A lthough its m ain application is not related to project m anagem ent, a graphic oriented object type hierarchy brow ser is also im plem ented to show how software tools can be built into the system and the integrated design ap proach of th e system . Chapter 1 Introduction As hardw are technology advanced rapidly and cost reduced dram atically during th e last decade, sophisticated software system s were built to offer more powerful com puting environm ents. The com plexity of a larger software sys tem , w ith thousands or even millions lines of code, is beyond one’s envision. Besides th e complexity, th e long software operation duratio n plus its sucessive m aintenance and enhancem ent introduce a huge burden on th e software devel opm ent process. As a result, effective m anagem ent of a com plicated software system developm ent is far m ore difficult to achieve. Some software engineering disciplines and new developm ent approaches, such as stru ctu red program m ing, chief-program m er team m anagem ent, high level specification and design lan guages, and cost estim ation m ethods[Baker 72, Zelkowitz 79, Boehm 81], have been introduced to im prove this situation. However, m ost these techniques are focused on developm ent issues th a t im prove the individual project personnel perform ance. M anagem ent issues concerning the effective planning and m oni toring o * f a software project are hardly resolved. P roject m anagem ent support is crucial to th e success of a software de velopm ent process. It has been observed th a t m any factors which cause a project to fail come from poor m anagem ent [Donelson 76, Keider 74, M artin 77, Scacchi 84]. This problem persists despite th e introduction of. software engi neering concepts. T hough existing project m anagem ent tools [Thayer 84] assist 1 in planning and cost estim ation, they are not designed to help the m anager m onitor and avoid cost and schedule slippage. T raditional project m anagem ent approaches (such as G an tt, P E R T , CPM ) are valuable tools for graphically showing interrelationships am ong project ac tivities and pinpointing critical tasks. However, we will see th a t several key lim itations exist. T he m ajor deficiencies are listed here. These lim itations will be discussed in greater detail later on. • T heir focus is on activity and resource scheduling, b u t they lack the ca pability to analyze and reason about the progress of activities. Though project delay is often the result of a chain reaction am ong several activ ities, existing system s are unable to identify the extent of th e effect th a t individual activities contribute to the delay. • W hile a project plan is constructed in a hierarchical m anner, existing systems only permit user views and manipulation on the bottom level of activities. This is not suitable for the hierarchy of m anagers th a t are involved in th e p ro je ct’s life cycle. • Traditionally an activity is begun when all of its predecessors are com plete. However, some activities require pre-conditions to be tru e before starting. T he value of these pre-conditions vary over tim e. Incorporating pre-conditions is not possible. • An underlying assum ption is th a t over tim e the project progresses and activities, once com pleted, are never retu rn ed to. However, th e n atu re of a design project is th a t activities m ay be executed repeatedly, depending on testing results or requirem ent changes. Replanning and regenerating activities and schedules is often required, but not permitted. 2 • Predecessors of an activity only specify a conjunctive condition, while in general an activity can be triggered from one of a set of different situa tions. Systems are unable to represent disjunctive dependencies between activities. • Even th e best of system s can be m ade useless if the d a ta is out of date or inaccurate. P roject m anagem ent system s are d a ta collection intensive. B ut rarely is provision made to assist in the updating of information. • P ro ject m anagem ent system s are closed. There is a need to interface w ith a database th a t contains th e life cycle products. Also organizations have widely varying analyses th a t they wish to perform on th e data. The lack of ability to interface with either a database or other life cycle tools is a major weakness. This dissertation describes research work th a t com bines results from knowl edge representation theory and object-oriented database research, to produce a m ore effective project m anagem ent tool, one th a t overcomes th e lim itations described above. It has two m ajor objectives. T he first goal is to derive a m odel, th e D esignNet m odel, th a t is suitable for describing th e n atu re of a de sign project and is rich enough to overcome the deficiences m entioned above. This m odel serves as a fram ew ork for an integrated software project m anage m ent environm ent. T he second objective is to design a system based upon the m odel, followed by an analysis of its applicability. As a result of this research, there will be theoretical results (the m odel), analytical results (com puting tim e analyses of critical algorithm s), and system results (a working prototype show ing th e feasibility of th e derived concepts). Several issues regarding a friendly user interface and the underlying database, th a t arose during th e construction of an actual prototype, are investigated in fu rth er detail. Though the m ain application for this work is th e developm ent of large-scale software system s, 3 i.e. software engineering, th e research has wider application to m any types of large-scale design projects. T he DesignNet m odel is a hybrid m odel for describing and m onitoring the softw are developm ent process. The aim of this m odel is to provide th e concep tu a l basis for a higher level integrated software project m anagem ent environ m ent. It utilizes A N D /O R stru ctu ral operators to describe the work breakdown structure (wbs) and P etri net notation to represent the dependencies and par allelism am ong activities, resources, and products. It is an event-driven m odel since th e project state is changed only when some events happen (e.g. spec changes, reported bugs, departure of personnel). W hen such events are subm it ted to th e m odeled project, the desired reactions will be autom atically triggered according to a predefined project plan. M eanwhile, th e relationship betw een th e event and th e triggered activities will be tracked in th e underlying database. T hus, a com plete project history log is m aintained w ithout m anual intervention. In supporting th e m anipulation of project inform ation m odeled by Design- N et, a powerful underlying database is essential to th e successful realization of th e m odel. To choose a suitable database m odel, th e d a ta m anagem ent re quirem ents are identified first. A n object oriented database approach has been judged as th e m ost appropriate underlying database m odel according to the desired capabilities. W ith th e power of object program m ing and th e efficient m anagem ent of d ata, an object oriented database m odel facilitates th e infor m ation representation and m anagem ent functions required by th e DesignNet. T he rem ainder of this chapter is organized into four sections. Section 1.1 gives a basic definition of project m anagem ent and reviews several traditional m odels used for project planning and control. Section 1.2 contains a survey of the existing project m anagem ent system s and their current statu s. Section 1.3 sum m arizes the deficiencies of the traditional models and addresses new 4 directions this research will lead to. T he last section outlines the stru ctu re of subsequent chapters of this dissertation. 1.1 T h e T rad itio n a l E lem en ts o f P r o je c t M a n a g em en t This section gives th e definition and description of basic term inology regard ing project m anagem ent. A n exam ple of the software developm ent process is shown here to illustrate how design projects differ from conventional projects in having unpredictable re-initiation of activities. T hree widely used project m anagem ent m odels are reviewed in the second subsection. 1 .1 .1 B a sic D e fin itio n s o f P r o je c t M a n a g em en t A project is com posed of a series of activities directed to th e accom plishm ent of a desired objective which usually results in th e delivery of a prototype system or pro d u ct. A project will generally have a m inim um set of features including: • a specific objective to be com pleted w ithin certain specifications • defined sta rt and end dates • funding lim its (budget) • consum ption of resources (i.e., money, people, equipm ent) An activity is a task w ith a well-defined beginning and a well-defined end th a t can be perform ed by a single functional entity. An event (also called mile stone) is an occurrence at a point in tim e th a t signifies the sta rt or com pletion of one or m ore tasks or activities. 5 Design Output Testing Input System Spec. User Interface Operation Requirement Analysis Command Processing Implementation Spreadsheet Project Figure 1.1: A Sam ple W ork B reakdow n S tructure A work break-down structure (wbs or sometim es called a pbs for project break-dow n stru ctu re) is a graphic portrayal of th e p roject, exploding it in a level-by-level fashion down to the degree of detail needed for effective planning and control. It m ust include all deliverable end item s (consum able goods, m a chinery, equipm ent, facilities, services, m anuals, reports, and so on) and includes the m ajo r functional tasks th a t m ust be perform ed, [Kerzner84, B oehm 81]. An exam ple wbs tak en from a software project is show n in Figure 1.1. T he root node is decom posed into six m ajor tasks according to steps in th e traditional software developm ent life cycle.1 One of the tasks is fu rth er decom posed into th e next level tasks. All of th e tasks m ay be extended several levels further, b u t only a few levels are shown here for simplicity. Project management is th e m ixture of people, resources, system s, and tech niques required to carry the project to successful com pletion, see e.g. [Kerzner84, 1A w b s for r e c e n tly p rop osed a lter n a te life cy cle d efin ition s is ea sily co n stru cted . 6 Boehm 81]. T he goal of project m anagem ent is to accom plish th e project before the designated deadline, w ithin th e budget, and utilizing th e existing resources efficiently. Sym ptom s caused by poor project m anagem ent include: late com pletion, penalties, cost overruns, project staff turnover, duplication of effort, and inefficient use of functional specialists. Innovation of project m anagem ent tools is especially crucial for design projects which are characterized as applying new technologies to develop new products in an uncertain environm ent. To m ake these definitions concrete, consider a softw are exam ple. A sam ple project m ight be: to develop a Lotus 1-2-3 work-alike spreadsheet package. A sam ple task m ight be: to design and build a plotter driver for the spreadsheet package. This task description could be an aggregate of five conditions such as: 1. Once the item s: the form at of the graphic com m and file, an experienced system program m er, a p lo tter program m ing m anual, and funding, are available, the design task can be initiated. 2. after design is com pleted, th e coding phase can begin. 3. W hen th e driver is finished and test m aterial has been prepared, functional testing can be started . 4. If the graphic com m and form at (specification) has been changed or func tional testing shows any failure, th e p lo tter driver has to be redesigned. 5. If th e p lo tter m alfunctions, a proper request m ust be su b m itted to the equipm ent support departm ent and th e testing activity will be tem p o rar ily suspended. T he testing staff m ay be assigned to o ther tasks during this period. In Figure 1.2 we see an expansion of the wbs for these tasks and activities. Triggering of the Plotter_Driver^Design task is based on previous activity com- 7 Design Testing System Spec. User Interface Operation Requirement Analysis Command Processing Plotter Driver Testing Plotter Driver Design Implementation Plotter Driver Coding Spreadsheet Project Graphics Command Specification Figure 1.2: Segm ent of W BS for H ypothetical P roject pletion (G raphic com m and specification) and resource availability, (Funding, Program m er, M anual). A t any tim e during th e Design, Coding or Testing ac tivities, o th er activities are going on concurrently. One of these m ay necessitate a change in th e Format, causing a re-scheduling of this entire task. In practice the Design task m ay have to be rescheduled several tim es due to a variety of conditions. In fact, th e entire p lo tter driver task m ay have to be rem oved due to a change in requirem ents. From th e above exam ple we see th a t th e events th a t influence th e activities of a design project are m ore complex and unpredictable th a n th a t of projects from the construction industry. 1 .1 .2 T h e T ra d itio n a l M o d els T here are several traditional project planning and control m odels th a t are used and it is instructive to exam ine th em [Fabrycky 84, Davis 83]. In this 8 Lotus 1-2-3 Work-alike Project May’1987 Jun’1987 Jul’1987 Aug'1987 Sep’1987 | -----| -----1 ---- 1 ---- i ---- 1 ---- 1 ---- , ---- 1 ---- 1 _ 1 Buy Furniture I— > 2 Find Computers I------- 3 Requirements j _ 4 Design 5 Detailed Design 6 Outside Review 7 Coding 8 Inhouse Testing 9 *Beta Test 10 *Release 1 T > > ■ Figure 1.3: A Sample G an tt C hart section, three m ost widely used models are investigated. T h e G a n tt M o d e l In this scheme project activities are represented as lines on a calendar- oriented ch art, w ith special m arks to indicate m ajo r m ilestones and activities th a t cannot be delayed w ithout delaying th e entire project (critical activities). In Figure 1.3 you see a sam ple of a G an tt chart. Some special features to notice are: th e tim e scale on th e top line, how th e critical activities are highlighted w ith double bars, and how slack tim e is shown as a series of dots. See [Davis 83] for m ore details. G an tt charts provide a graphic illustration of activities to be perform ed. T he sta tu s of each activity, in term s of its d uration and level of com pletion, is indicated either graphically or w ith num erical percentages. T hough easy to read, th e ch art fails to represent activity interrelationships. 9 T h e C r itica l P a th M e th o d (C P M ) M o d el This m odel em phasizes the interconnections betw een activities, nam ely their predecessors and successors. T he collection of activities and links form s a di rected acyclic graph. Each activity is assum ed to be defined by two events: th e sta rt of th e activity and th e com pletion of th e activity. T he order in which activities are done depends on predecessor and successor relationships betw een th e events and th e activities. These are governed by th e following rules: • T h e sta rt event of an activity precedes th e end event for th e sam e activity by a tim e d uration called th e activity time. • T he start event of an activity succeeds end events for all activities pre ceding it.2 • T he event project start precedes all activities and events in th e project. • T he event project end succeeds all activities and events in th e project. T here exist two alternatives for graphical representation of activities and events, b o th of which are shown in Figure 1.4. One way is th a t activities are represented by an oriented arc, w ith the sta rt and com pletion events represented by vertices. T he second way is th a t activities are represented by th e vertices of th e graph and predecessor/successor relationships are shown by arcs. Using th e C PM graph m odel one m ay derive algorithm s for com puting cer ta in functions over this graph. Given project sta rt, project end, and activities’ d u ration, algorithm s can com pute th e following inform ation for each activity: (1) earliest startin g tim e; (2) latest startin g tim e; (3) earliest com pletion tim e; (4) latest com pletion tim e; (5) m axim um available tim e; and (6) slack. 2In p ra ctice, a su ccesso r a c tiv ity ca n sta rt after its p red ecessor is p a rtia lly co m p lete. 10 --------------- n activity /"----------------n event ) ► ( event j n event / -------; -------- \ activity j —: ------------------► ( activity ) Figure 1.4: Two G raphical W ays to Show an A ctivity Network C P M A lg o r ith m T he C PM com putation algorithm is a recursive algorithm . T he param eters th a t m ust be know n before applying the algorithm are individual activities’ d u ratio n and th eir predecessor/successor relationships. Tw o global tim e values m ust also be given — the project sta rt and the project end. In this algorithm description, we assum e th a t each activity is delineated by its sta rt and end events. Suppose an activity th a t has its sta rt event labeled i an d its end event labeled j is represented by a pair (i , j ). T he d uration of this activity, represented by Y{j, is a know n value. Define th e earlist and latest possible tim e of the occurrence of event i as T E i and TL{. T he event 0 denotes th e project start and T E 0 is th e project start tim e. T h e event s denotes th e project end and T L a is th e targ eted project finish tim e. By assum ption, b o th T E q and T L S are know n values. From the relationships betw een events and activities, it is possible to develop th e following recursive relationships for com puting T E i and T L i of a project P. , T E 0 i = 0 T E i = { m ax (TEk -f Yki) for all (k , i ) 6 P 11 Figure 1.5: An activity-on-edge project exam ple. TLi = T L S i = s m ln (T L k + Yik) for all (i , k) £ P From these equations, it is possible to com pute th e following inform ation for each activity: (1) Earliest startin g tim e, TE i (2) L atest startin g tim e, T L j — (3) Earliest com pletion tim e, T E i + Yij (4) L atest com pletion tim e, T L j (5) M axim um available tim e, T L j — TEi (6) Slack, T L j - T E i - Yij 12 In Figure 1.5 you see an activity-on-edge graph containing 22 activities. Based on th e defined algorithm , th e associated tim e values are com puted and displayed in figure 1.6. T he table containing six colum ns w ith the above values com puted. A discussion of d a ta structures and algorithm s for com puting these values can be found in [Horowitz 76]. T h e P E R T M o d e l T he P rogram E valuation and Review Technique (or P E R T ) is related to th e netw ork screen of th e G an tt chart. However rath er th a n a fixed sta rt and end d ate for each activity, three tim e estim ates are m ade for activity tim e: (1) th e probable earliest com pletion tim e, (2) th e probable latest com pletion, and (3) th e m ost probable com pletion tim e. T im e is m easured by random variables w ith an assum ed probability distribution. T hus th e activity tim e is defined as a random variable w ith a b e ta distribution as shown in Figure 1.7. From th e b e ta distribution one m ay derive th e following equations: mean for activity time = (a + 4m + b)/6 variance for activity time = [(& — a )/6 ]2 All of these three m odels, G a n tt, C PM , an d P E R T , focus on th e tim e scheduling of activities. T he underlying graph representation for C PM and P E R T m ake the com putation of useful scheduling functions straightforw ard. T he use of three separate tim e estim ates and the calculation of probability estim ates of m eeting specified schedule dates axe th e m ajor features of th e P E R T approach. CPM uses only one tim e estim ate for each activity and th u s no statistical treatm e n t of uncertainty. However, th e inclusion of tim e versus cost com putation as a criteria to m inim ize the to ta l project cost is first introduced by C PM . This concept 13 Activity Earliest Starting Time Latest Starting Time Earliest Completion Time Latest Complete Time M aximum Available Time Activity Slack Time 1 0 0 20 20 20 0 2 0 10 75 85 85 10 3 0 15 35 50 50 15 4 0 10 20 30 30 10 5 20 20 40 40 20 0 6 20 30 75 85 65 10 7 20 30 40 50 30 10 8 20 40 20 60 40 20 9 40 40 60 60 20 0 10 40 60 60 80 40 20 11 40 55 85 100 60 15 12 40 65 70 95 55 25 13 40 50 90 100 60 10 14 40 60 60 80 40 20 15 60 80 80 100 60 40 16 60 80 80 100 40 20 17 60 80 85 85 25 0 18 85 100 105 120 35 15 19 85 85 120 120 35 0 20 70 95 75 100 30 25 21 70 100 90 120 50 30 22 90 100 110 120 30 10 Figure 1.6: A ssociated tim e values com puted from th e exam ple project. 14 S 3 CO S 3 O CL b Tim e tr a m Optimistic tim e Most likely time Pessimistic tim e Figure 1.7: B eta D istribution for P E R T A ctivities leaded to fu rth er extension on th e project resource allocation an d m ultiproject scheduling problem s. 1.2 P r o je c t M a n a g em en t S y stem s This section reviews how software project m anagem ent is currently prac ticed. T he functions of existing project m anagem ent packages are sum m arized in th e first subsection. It is observed th a t identical tools are used for software projects and o ther types of projects although design projects need particular considerations in m any aspects. T he second subsection discusses another m ajor issue th a t is unique to softw are projects — th e cost estim ation. In order to have an accurate estim ate, software projects requires different techniques th a t take various developm ent and pro d u ct param eters into account. 15 1 .2 .1 E x istin g P a ck a g es M any com m ercial project m anagem ent packages are available on a vari ety of operating system s, such as MacProject[M acProject] from Apple for th e M acintosh, Pro?ect[Microsoft] under DOS, Ft/i?[VUE] from N ational Infor m ation System s under VM S, .SunTracfSuperProject 86] for Sun w orkstations, MasterPlan[M asterplan 87] from Q uality Software P roducts under UNIX, M icroTra&[Microtrak] from Softrak under UNIX, and SuperProject [SuperProject 86] from C om puter A ssociates also under DOS. All of th em u ti lize tra d itio n al techniques — P E R T , G an tt C harts, and C PM — to perform th e scheduling, costing, reporting, and u p dating of activity inform ation. The b e tte r system s p erm it th e user to edit and display tasks graphically and to com pare original project d a ta w ith th e current actual d ata. One m ajor enhancem ent contained in some of these system s is th e scheduling an d m anagem ent of resources. In addition to the project calendar, each resource can have its own calendar. A task will be autom atically delayed if its required resources are not available in its currently scheduled tim e slot. A user can assign priorities to resources and th e system perform s resource leveling w hen th e to tal dem and by a num ber of tasks, for th e same resource, exceeds the supply. Some system s m ake provision for th e whs by p erm itting links to sub-projects. A super-project can contain m any sub-projects and a sub-project can contain oth er sub-projects. T hus, it provides a way to hierarchically decom pose a large project into sub-tasks. Though this perm its a representation of th e hierarchi cal wbs in some form , these system s are still lim ited in th eir focus to keeping track of schedules. The lim itations depicted earlier are still unresolved. These system s only play a passive role, while m ore powerful and au tom ated tools are im aginable and desirable. 16 1 .2 .2 C o st E s tim a tio n M o d e ls A n essential p art of software m anagem ent is to m ake an accurate cost es tim a te prior to th e project being initiated. However, unlike other engineering fields, there is no stan d ard estim ation technique th a t can be applied to all types of softw are developm ent. Several m odels have been proposed to do software cost estim ation, e.g. [Brown78, T hibodeau 78, Boehm 81]. T he assum ption these m odels are based on is th a t life cycle cost is predictable using variables th a t sim ply describe th e product and th e developm ent environm ent (i.e. th e type of contract, the m an-m onths spent, the delivered source instructions, etc.). Based on heuris tics, different com putation functions can be applied to estim ated efforts to give estim ated cost. T he CO CO M O (C o n stru ctiv e C O st MO del), proposed by Boehm , is a hier archical software cost estim ation m odel. T he top level of th e hierarchy is Basic CO CO M O which only uses a function of th e size in delivered source in stru c tions to estim ate th e cost of a software project. T he next level of th e hierarchy is In term ed iate CO CO M O which estim ates th e cost of a softw are project as a function of size and several other software cost driver a ttrib u tes, such as p er sonal experience and capabilities, com puter hardw are constraints, and degree of use of m odern program m ing practices. T he D etailed CO CO M O is the m ost accurate level of the hierarchy. It uses th e cost driver attrib u tes to estim ate th e softw are p ro d u ct’s costs by individual phase, sub-system , and m odule. See [Boehm 81] for details. T he estim ation procedure begins by developing an initial whs for th e project. It th en allocates th e developm ent cost to individual elem ents in the wbs. T he P E R T chart technique is used next to establish an activity netw ork th a t ex 17 presses th e required project schedule and th e tim e-dependencies of project tasks. O nce th e cost, effort, and schedule required for each m ajor task have been de fined, th e prim ary com ponents of the p ro ject’s resource plan, such as personnel plan and project work authorizations, can be established and assigned to respon- - j sible individuals. CO COM O also provides two basic capabilities for tracking project progress, th e time card reports how m uch of a project m em ber’s tim e has been devoted to th e p ro ject’s various whs elem ents, and th e Unit Devel opment Folder records how m uch progress has been m ade tow ard th e project m em ber’s objectives. To provide a long-range cost estim ation capability, th e d a ta collected via planning an d control activities are kept in a cost d a ta base. By analyzing collected d a ta and determ ining how the actual software costs differ from the CO CO M O estim ates, th e differences are fed back into an im proved cost esti m ation m odel calibrated to th e organization’s experience. 1.3 In a d eq u a cies o f th e E x istin g M o d els As review ed in previous sections, m ost project m anagem ent tools are based on th e three trad itio n al m odels, G a n tt, C PM , and P E R T . All of these three m odels focus on th e tim e scheduling of activities. T he underlying graph repre sentation m akes th e com putation of useful scheduling functions straightforw ard. However, we have already observed th a t this sim ple form ulation does not cap tu re im p o rtan t characteristics of a design project, w ith th e consequence th a t th e schedule often goes out-of-date. Having looked at th e trad itio n al m odels, it is useful to pause and consider in w hat ways they are deficient. A n im p o rtan t factor for a successful softw are project m anagem ent m odel is th e capability to analyze and reason about the progress of activities. W hen __ 18 a project shows delay at a stage, the m anager w ould either like to ’cure’ the schedule by adding m ore resources to those activities causing the delay, cor rect some existing precondition th a t is in a negative state, or reschedule those activities th a t will be affected. However, none of these m odels provides th e inform ation th a t would perm it such a determination. T he current m odels focus on scheduling activities. However, the wbs is m ore descriptive of th e entire project and necessary for carrying out logical reasoning over th e life of th e project. Even though some existing system s allow linking activities to external projects, activities in a sub-project are considered to be a t th e sam e level of functionality as the super-project. This is u n fo rtu n ate as project plans are generally constructed hierarchically. Providing a tru e wbs representation facility is necessary to perm it responsible staff at different levels to construct and m onitor th eir ow n tasks independently, while integrity of the en tire project is m aintained. Once again, current m odels are inadequate for representing th e wbs as an integral system com ponent. A nother m ajor task during th e planning phase is to determ ine th e depen dencies (predecessor and successor relationships) am ong activities. However, th e event th a t causes a prerequisite condition to becom e tru e m ay be beyond th e control of the project m anagers. For exam ple, building a p lo tter driver requires a p lo tter for testing. T he Program m ing G roup can check w hether a p lo tter is available, b u t it is th e responsibility of th e E quipm ent D epartm ent to allocate such a resource. T hus th e Program m ing G roup m ay not know w hat activity will allocate the required device (which m ay be purchased, leased, or borrow ed) nor do they have supervisory control over it. T hus, activity depen dencies m ust include th e notion of Boolean conditions, as well as predecessor activity com pletion. D ue to th e n atu re of a design project, some activities m ay have to be ex 19 ecuted m ultiple tim es. For exam ple, if th e specification changes, the plotter driver design activity needs to be executed again. L ater it m ay be cancelled, e.g. a driver designed by another vendor is available. C urrent m odels are unable to regenerate and reschedule activities autom atically. W h at is really needed is a tw o-part m echanism , one th a t creates instances of th e sam e activity whenever it is re-executed and one th a t m ay reconfigure a set of activities if a change in stru ctu re is required. T he notion we are suggesting here is th a t th e project plan only acts like a tem plate. As an activity is begun, an elem ent of the plan is in stan tia te d w ith all related inform ation, such as preconditions, being attached. A t a later tim e, if th e sam e activity m ust be rescheduled, th e sam e tem plate is used to generate another instance w ithout dam aging th e earlier schedule. A related issue is th e need to m aintain th e set of predecessors and preconditions th a t caused a single activity to be scheduled. In th e P E R T and G an tt m odels, predecessors of an activity only define a conjunctive ’A N D ’ dependent condition. A n activity can be in itiated only if all its predecessors are finished. In some cases, an activity should be triggered after any dependent condition becom es tru e (e.g. if th e specification changes ’O R ’ testing fails, th en this causes th e Design activity to be rescheduled). Existing system s should be augm ented to provide disjunctive dependency specification and a triggering m echanism . Since an activity can be executed due to different conditions and since an activity can be executed m any tim es, it is necessary to record th e facts th a t triggered each instance. A large scale project m ay have thousands of activities. E ach activity ini tially has a set of inform ation th a t m ay require as m uch as a single screen to display. The need to continually u p d ate activity progress m akes the to ta l d ata requirem ent potentially im m ense. Though existing system s have reasonably nice user interfaces, m an-m achine com m unication th a t supports d a ta collection 20 on. a broad scale is not provided. Such collection can be view ed as a database problem w here th e schem as are defined by th e underlying m odel. In general such schem as are highly stru ctu red . An object oriented database system coupled to th e project m anagem ent system w ould substantially im prove this problem . The d a ta m anagem ent issues will be investigated in fu rth er detail in a later chapter. A final lim itatio n is th e fact th a t m ost system s are closed, in term s of their inability to work w ith o ther life cycle tools. T his is u n fo rtu n ate, as in general com panies desire to take project d a ta and work w ith it in a variety of ways. For exam ple, one com pany m ay w ant to com pute earned value analysis as a m easure for tracking progress, see e.g. [Boehm 81, N orm an 84]. A nother m ay need to take resource financial d a ta and send it to a financial rep o rtin g system . This la tte r system m ay be able to report progress using pre-defined forms and functions. Finally it is generally im possible to predict in advance th e form in w hich m anagem ent will require reports. T hus a general rep o rt creation capa bility, b u t m ore likely an interface to one, such as discussed in [Horowitz 85], is m ore desirable. T he m odel advocated here is a know ledge-based, object-oriented approach th a t represents a m ajor extension of capabilities beyond th e trad itio n al. T he m ajo r focuses are to provide th e project m anager assistance in b o th th e planning stage and th e execution stage. D uring th e planning stage, D esignNet allows individual task supervisors to develop th e activities of th eir own task in a hierarchical m anner and specify th e resource requirem ents and product types of each activity. B o th conjunctive and disjunctive dependent conditions for in itiatin g activities are supported. An autom atic project wbs construction function then can be invoked to construct th e entire project netw ork. In th m ean tim e, D esignNet can analyze th e project plan for th e presence of desirable or undesirable properties, such as connect 21 edness, plan com plete, and plan consistent. A project m anager can use these analysis techniques to help him detect any problem concerning project planning earlier before th e project is actually initiated. D uring th e execution phase, project personnel rep o rt th e event happened directly to th e system and th e desired reactions will be autom atically triggered according to th e predefined project plan. M eanwhile, th e relationship betw een th e event and th e triggered activities will be tracked in the underlying database as object instances. R e-initiations of th e sam e activity will cause new instances to be created. T hus, a com plete project history log is m aintained w ithout m an ual intervention. T he project m anager is able to evaluate th e project progress against th e plan via this recording. Though a project m ay have m any iterations am ong activities, it is still possible to reason am ong any_schedule delay and cost increase by tracing thro u g h the actual activity execution instances. 1.4 O rg a n iza tio n o f th e D isse r ta tio n This chapter gave a background of general concepts of th e project m anage m ent and addressed considerations th a t are p articu lar to software developm ent projects (or m ore broadly — design projects). Lim itations of existing models w ere also designated. C hapter 2 surveys how o th er aspects of project m an agem ent are pursued in recent research. T he issues include project knowledge representation, activity planning and scheduling, resource allocation, project progress m onitoring, and higher level software engineering support. C hapter 3 describes th e background of th e proposed m odel and gives a form al specification of D esignN et. T he practical im plications behind th e theory of D esignN et and how D esignNet can be used to express life cycle phases, such as th e w aterfall m odel, are also discussed. C hapter 4 exam ines th e d a ta m anagem ent require 22 m ents related to softw are project m anagem ent and shows w hat representation techniques are neccessary in order to support th e conceptual level notations depicted by D esignN et. C hapter 5 contains th e design and im plem entation of a system called D esignPlan. It is a prototype system of softw are project m an agem ent th a t utilizes D esignNet as th e theoretical foundation. T he concepts presented by D esignN et are realized in this prototype. Finally, C h ap ter 6 sum m arizes th e contributions of th is dissertation and discusses directions for future research. 23 Chapter 2 Related Research Besides th e activity scheduling which m ost trad itio n al m odels try to deal w ith, m any o th er aspects also need to be considered in m anaging a project. Re lated work in these areas has inspired creative ideas for this research. However, th eir focuses are m ainly in a specific function involved in project m anagem ent. To su p p o rt an in teg rated project m anagem ent environm ent, it is necessary to investigate th em in m ore detail an d come out w ith a platform th a t is able to accom m odate th em to achieve various m anagem ent functions. T his ch ap ter presents research work th a t deals w ith project knowledge repre sentation, activity planning and scheduling, resource allocation, project progress m onitoring, and higher level software engineering support. For each category, we have chosen representative system s for fu rth er exam ination. T he first section describes recent w ork th a t applies knowledge representation techniques to activ ity representation. T he prim ary technique used is th e fram e-based description. T he next section surveys several planning approaches in th e artificial intelligence field. O perators axe introduced in these schemes to perform task planning and to construct job flow netw orks. T he th ird section discusses know ledge-based re source scheduling system s. T heir m ain goals are to resolve resource conflicts by choosing ap propriate alternatives. T he fourth section surveys m odels for m on itoring concurrent progressing activities. A m ong th e m odels, th e P etri net has been verified as a very powerful one in reflecting concurrent and asynchronous 24 behaviors. T he D esignNet m odel is a com bination of P etri net and A nd-O r graphs w ith some extensions. We will discuss it in m ore detail in next chapter. T he final section presents work on software engineering environm ents th a t are related to project m anagem ent. 2.1 P r o je c t K n o w led g e R e p r e se n ta tio n As discussed in th e previous chapter, an activity representation m odel is a foundation of th e overall project m anagem ent system . It should provide th e capabilities to organize activities in a hierarchical m anner (i.e. speci fying th e wbs), to declare th e precedence constraints of individual activities, and to perform higher level planning and m onitoring functions. The Callisto system fSathi 85], developed at Carnegie M ellon U niversity under th e direction of A .S athi, M .S.Fox, and M .G reenberg, is one of th e first few system s th a t applies artificial intelligence techniques to project m anagem ent. Callisto is an intelligent project m anagem ent system th a t utilizes knowledge rep resen tatio n techniques to in teg rate th e theories of activity, tim e, causality, m anifestion, and in stan tiatio n to accom plish th is goal. It exam ines th e exten sion and application of fram e-based knowledge representation techniques [Minsky 75] to th e dom ain of large project m anagem ent. It also provides de cision su p p o rt and decision m aking facilities for activity m anagem ent, product m anagem ent, and resource m anagem ent tasks. C allisto uses th e SRL knowledge representation language as a basis, and de fines a set of conceptual prim itives including tim e, causality, object descriptions, possession, and organizational au th o rity to m odel th e concept of activities and th e project organization. 25 R e p r e s e n ta tio n s c h e m e A schema is used as the m ost basic, prim itive rep resentation stru ctu re in Callisto. It is com posed of a schem a nam e together w ith a set of slots and serves as a concept tem plate. A schem a is always enclosed by double braces w ith th e schem a nam e appearing at th e top. Any generic concept is defined as a collection of assertions, and an assertion is a schem a-slot-value trip let. For exam ple, given th e following activity schem a {•{activity start_date: duration: cost and th e facts th a t th e Plotter driver design activity sta rts on M ay 1, takes 10 days and costs $800 of program m er tim e, it can be represented by th e concept {{plotter.driver.design start.date: May-1-86 duration: 10 cost: $800}-}• Set, individual, and p rototype are distinguished schem a types. A set is a concept defined as a collection of things th a t belong or are used together. An individual is a m em ber of th e set. A prototype is a concept which describes the typical features of th e m em bers of a set. Set provides group characteristics of th e individuals in th e set, such as th e to tal cost of a design task w hich includes several design activities. K n o w le d g e s t r u c t u r e Knowledge in Callisto is stru ctu red using six relations to provide defaults, classification, elaboration, revision, individuation, and ag- 26 gregation. A set of prim itives is used to define th e inheritance sem antics for each relation. Default is defined by an i s - a relation and restricted only to th e default prop erties. T hus, if Input-design i s - a Design activity, th e properties in th e concept Input-design inherit th eir default values from th e Design schem a. Classification is defined by a s u b s e t- o f (inverse h a s - s u b s e t) relation. It is a process th a t p artitio n s a set in to subsets on th e basis of some a ttrib u te value. Elaboration is defined by an e la b o r a tio n - o f (inverse h a s - e la b o r a tio n ) relation. It takes a concept and fills in details. This process only operates on individuals and prototypes. Aggregation is defined by a p a r t - o f (inverse h a s - p a r t) relation. It combines p arts to m ake a whole. P a rts inherit some a ttrib u te s from th eir aggregation (e.g. responsible personnel), others are ag gregated (e.g. cost), or averaged (e.g. perform ance). For exam ple, b o th Input- design and Output-design are p a r t - o f User-interface-design. Revision is defined by a r e v i s i o n - o f (inverse r e v is e d - b y ) relation. It is a transform ation process which converts a range object into a dom ain object by adding im provem ents in its representation. For exam ple, Plotter driver version 2 is a r e v i s i o n - o f version 1. Individuation is defined by an instance relation. It generates a copy of th e prototype w ith an individual nam e and any exceptions. For exam ple, Plotter driver design is the design activity of p lo tter driver, while Plotter driver design # 1 is an instance of p lo tter driver design for H ew lett Packard plotters w ith specific startin g and ending dates. Based upon th e defined stru ctu ral relations, a theory of activity, theory of states, goals, theory of tim e, and theory of causality can be defined clearly. For | i exam ple, an activity can be decom posed in to several sub-activities by p a r t - o f i and i s - a relations. 27 T h e activ ity representation scheme and knowledge stru ctu re proposed by C allisto is very suitable for describing th e wbs due to th e hierarchical n atu re of a p roject. A ctivity can be an aggregation of subactivities. Lower level activities can inherit inform ation from higher levels. T he higher level activities can also aggregate inform ation from lower levels. It also integrates th e theories of ac tivity, tim e, causality, m anifestion, and in stan tiatio n together, which facilitates th e accurate and consistent representation of all relevant project m anagem ent inform ation. W h at is not addressed here is higher level au to m ated planning and scheduling m echanism s. It only captures th e static constructs of a project while th e detailed control functions (such as activity triggering and in stan tiatio n ) are not handled. 2.2 P r o je c t P la n n in g In artificial intelligence, planning is one kind of problem -solving technique [Cohen 82]. It is a process of developing a sequence of actions to achieve a goal. A plan is, thus, a representation of a course of action. A plan usually has an im plicit ordering of its goals; for exam ple, the construction of a building requires th a t installing electrical w iring be finished before installing a dry wall. M ost plans have a rich subplan structure; each goal in a p lan can be replaced by a m ore detailed subplan to achieve it. In term s of project m anagem ent, plans can be used to m onitor progress during th e p roject life cycle and to detect errors before they do too m uch harm , especially for th e unpredictable environm ent of a design project. Four distinct approaches to planning are proposed: nonhieraxchical planning, hierarchical planning, script-based planning, and opportunistic planning. See [Cohen 82] for details. T he hierarchical planning works in a top-dow n m anner w hich is 28 very close to project planning. It first sketches a plan (e.g. designing a software package) w hich is com plete b u t vague, and th en refines it in to m ore detailed subplans (e.g. requirem ent analysis, design, im plem entation, testing, etc.). The following paragraphs give one exam ple of a hierarchical planning system . NOAH (N ets of A ction H ierarchies) [Sacerdoti 74] is a hierarchical planner system th a t expands th e original goal of th e problem in to a series of sub-goals u n til a level of sim ple operators can achieve them . T he representation of a plan is called a procedural net which represents b o th procedural an d declarative knowledge ab o u t the plan to be expanded. T he procedural knowledge includes functions th a t expand statem ents of goals in to sub-goals. D eclarative knowledge represents th e effect of executing these functions. T he planning in NOAH is accom plished by expanding th e procedural net. From a single node to achieve th e original goal, a hierarchy of nodes is developed th a t represent subgoals to be achieved. T he original goal node contains a pointer to a set of functions th a t expand goals into subgoals. W hen one or m ore of these functions are executed, subgoal nodes are added to th e procedural net. These nodes are them selves expanded as their p aren ts was. Eventually, it will reach a level of goals th a t can be im m ediately a ttain ed by sim ple operators. NOAH was applied in th e dom ain of assem bly tasks. NOAH has been extended by A. T ate [Tate 77] to generate p roject plans as a p artially ordered netw ork of actions to aid in project netw ork construction. A task form alism (T F ) has been specified to enable actions in a dom ain to be described in a hierarchical fashion. A non-linear planner (N O N LIN ) generates plans from task descriptions given in the task form alism . Using T F , sub-task descriptions can be w ritten independently of th eir use at higher levels, and th u s encourages th e w riting of m odular jo b descriptions 29 at various levels of detail. T he specification of each task includes inform ation about • w hen to introduce an action in th e plan • th e effect of an action • w hat conditions m ust hold before an action can be perform ed • how to expand an action to lower level actions T he following exam ple shows th a t decorate can be expanded in to six lower level actions w ith th e p artial ordering shown in Figure 2.1. T he supervised conditions are different from th e unsupervised ones as they involve details th a t can be expanded by th e planning system and thus, involves no in teractio n w ith o ther high-level activities. actschema DECOR pattern «DEC0RATE» 1 action «FASTEN' PLASTER AND PLASTER B0ARD» 2 action «P0UR BASEMENT FL00R» 3 action «LAY FINISHED FL00RING» 4 action «FINISH CARPENTRY» 5 action «SAND AND VARNISH FL00RS>> 6 action <<PAINT>> orderings 1--->3 6--->5 sequence 2 to 5 conditions unsupervised «R0UGH PLUMBING INSTALLED>> at i unsupervised «R0UGH WIRING INSTALLED» at 1 unsupervised «AIR CONDITION INSTALLED>> at 1 unsupervised <<DRAINS INSTALLED>> at 2 30 2 ► 6 Figure 2.1: P a rtial O rdering of A ctions unsupervised «PLUMBING FHJISHED» at 6 supervised <<PLASTERIMG FINISHED» at 3 from 1 supervised <<BASEMENT FLOOR LAYED» at 3 from 2 supervised <<FL00RIWG FIMISHED>> at 4 from 3 supervised «CARPENTRY FIHISHED» at 5 from 4 supervised <<PAINTED>> at 5 from 6. A goal stru ctu re is used for each plan to provide inform ation to aid th e search of th e planner and also contains valuable inform ation for m onitoring th e execution of a plan. NONLIN starts w ith a single node representing the task to be planned, expands th e node at g reater levels of detail, and handles interactions betw een sub-plans. All alternatives generated at choice points in th e p lan n er’s search space are kept for backtracking. To apply this planning technique to software project m anagem ent, th e user can specify th e preconditions before an activity can sta rt and th e effects after it finishes, an d th e n let th e planner achieve th e project objective. T he planner will search th ro u g h those effects (results of activity) th a t can satisfy preconditions of an o th er activity, and link th em together. T he advantages of planning can be sum m arized as reducing m anual efforts to construct th e activity netw ork, resolving goal conflicts, and providing a basis for error recovery. 31 2.3 R eso u rc e A llo c a tio n and S ch ed u lin g One of th e m ost difficult tasks in any design project is th e allocation of personnel resources. A ctivities in a design project m ay em ploy a diversity of people including: scientists, engineers, m anagers, consultants, and even execu tives. T hese people will have different backgrounds and abilities. If a desired person is not available for a specific activity, can th e system choose an altern a tive th a t has th e sam e background and is able to perform th e sam e job? M ost trad itio n al approaches require th a t a fixed resource (e.g. program m er John) of an activity (design th e p lo tter driver) be specified before project scheduling. If th a t resource is not available (e.g. on vacation or involved in an o th er activity), th e activity will be delayed. A m ore powerful allocation strateg y is necessary. T he resource scheduling algorithm has to consider th e conflicts and load bal ance problem s betw een resources. If th e system allows a project staff m em ber to be involved in several activities at the sam e tim e, th en does this staff m em b er w ork w ith equal percentages on all th e activities and how m uch does his effort contribute to an activ ity ’s progress? In this section, a know ledge-based scheduling system is described. N U D G E [Goldstein 77] was directed by I.P.G oldstein and R .B .R oberts. It focuses on th e use of fram e representations to debug scheduling requests by supplying typical values for qualitative constraints, supplying m issing details an d resolving m inor inconsistencies. T he application dom ain chosen is office scheduling in which scheduling requests are typically inform al. This schedul ing technique can be applied to th e resource m anagem ent and coordination of personnel engaged in a group project. N U D G E contains a hierarchy for the activities, th e people, and th e asso ciated dem ands on tim e, space an d personnel in th e office environm ent. E ach 32 Time Moment Interval Thing Activity I Meeting People Action Person Schedule Moment54 Intervall7 PA-Meeting Manager Staff Schedule 1 Meeting37 Jackson Bruce Figure 2.2: Fram e G estalt object in th e hierarchy is described by a generalized p ro p erty list called a fram e. To deal w ith m issing inform ation and conflicts, a fram e gestalt is constructed appropriately for a p articu lar scheduling request. Inform ation m issing in the request is th en com puted from defaults, constraints, and procedures. For ex am ple, to schedule a m eeting betw een Jackson and Bruce on next M onday, a g estalt as in F igure 2.2 (from [Goldstein 77]) is constructed. In th e gestalt, lower level nodes are subclasses of higher level concepts and th e leaf nodes instances of generic concepts. O nce a fram e gestalt is built w ith conflicts or m issing inform ation, a schedul ing program , BA RG A IN , is used to control th e search process by incorporating a best-first search m easured by: th e num ber of violated preferences, their re spective utilities, and th e num ber of rem aining conflicts. A set of eight search operators are em ployed to debug tim e conflicts. E ach strateg y has a cost asso ciated w ith it th a t allows th e bargaining betw een goals. R e p r e s e n ta tio n T e c h n o lo g y Six representation techniques are em beded in N U D G E: com m ents, abstractions, defaults, constraints, indirection and proce- 33 dural attach m en t. Comments record the source of th e value in each slot. This com m entary provides guidelines for BA RGA IN to judge the stren g th of differ en t slot values during conflict resolution. Abstraction allows inform ation to be in h erited betw een concepts. Inform ation in a generic fram e can be acquired by a specialized instance of th a t fram e. Defaults supply default answ ers to th e com m on questions asked about a specific event. In form ing a fram e gestalt, the defaults of superior fram es are used unless th ey are overridden by explicit constraints. Constraints specify the facets for requirem ents and preferences. For exam ple, a m eeting m ay require th a t th e d ep artm en t m anager m ust join as the chairm an. Indirection intercon nects sep arate hierarchies to construct a knowledge netw ork. It is a simplified kind of m apping betw een concepts and also avoids duplicates. Procedural at tachment provides a m echanism for triggering arb itra ry procedures to add or supply a value to a slot. A ttached procedures are also used to m ain tain the in teg rity of th e database. Even though N U D G E is used prim arily for office scheduling, it can be ad ap ted easily to resource allocation and scheduling for project m anagem ent. T h e knowledge representation schem e described provides a fram ew ork for higher level m anipulations. O perators to determ ine alternatives and resolve conflict can be built upon it. 2.4 P r o je c t P ro g ress M o n ito rin g T he execution of a project shows a high degree of parallelism . N um erous activities progress at th e sam e tim e. The delay or re-initiation of one activity m ay cause d ram atic effect on schedules of o ther activities an d th e project com- 1 pletion tim e. It is essential for a project m anagem ent system to incorporate a 34 m odel th a t is capable of describing th e concurrent behaviors and tracking down th e conditions which in itiate th e execution of all activities. T here exist several m odels th a t are suitable for representing concurrent sys tem s, am ong w hich th e P e tri net m odel appears to be th e m ost com pletely developed. T h e P etri n et was originally developed by C .A .Petri in Germ any. See th e survey by [Peterson 77]. It is an ab stract m odel for inform ation and control in system s exhibiting concurrent and asynchronous behavior. T he re lationships betw een th e p arts of a system can be represented by a graph or netw ork. T he g raph consists of two types of nodes: places (represented by circles) w here one or m ore tokens can reside and th e transitions (represented by bars) w hich can be fired to move tokens from in p u ts to o u tp u ts. A tran sitio n is enabled w hen all of its in p u t places have tokens. T he firing of a tran sitio n causes tokens to be m oved from th eir in p u t places to th eir o u tp u t places. P etri nets can be used to m odel th e static and dynam ic properties of system s. S tatic properties of system s are represented by th e graphical p a rt of a P e tri net. D ynam ic properties of a system can be determ ined from th e P etri net graph, th e in itial m arking, an d th e sim ulation rule. T he net graph m odels two aspects of system s : events and conditions, and th eir relationship. Firing transitions can be used to m odel th e process of producing and consum ing th e resources. Several sub-classes and extensions of ordinary P etri nets have been studied eith er to increase th e m odeling power or m odeling convenience, or to facilitate th e solution of analysis problem s[Y au 83]. Some extensions add a predicate to tran sitio n s an d associate attrib u te s w ith tokens to represent value-dependent sem antics. A technology [Nelson 83] for tran slatin g P e tri nets in to a special pro cedural language nam ed X L /1 w hich can, in tu rn , be optim ized’and tran slated 35 in to existing com piled in p u t languages has also been presented. A nother extension to th e classic P etri net definition is to incorporate the notion of tim e. In th e extended m odel of [R am am oorthy 80], tran sitio n s are used to m odel processes and th e firing of a tran sitio n becom es an event w ith a d u ratio n equal to th e execution tim e of th e process. A sim ilar extension was m ade by [Coolahan 83] w ith th e exception th a t places are used to represent processes. T he execution of a process is m odeled by a tran sitio n representing th e in stan tan eo u s sta rt of execution w ith a directed arc to a place representing th e condition of th a t process being in execution. In sum m ary, there are several advantages of m odeling a dynam ic system using P etri nets. For exam ple, th e ability to produce a precise, graphical rep resentation, th e existence of analysis tools for determ ining and verifying the dynam ic behavior of system s from th eir stru ctu re, and th e capability of design ing system s using top-dow n or bottom -up approaches. It is especially suitable for m onitoring progress of concurrent activities w ith an extension of th e tim e dom ain as in [Coolahan 83]. 2.5 S oftw are E n g in eerin g S u p p ort M any developm ent tools and design m ethodologies have been introduced in to th e softw are engineering environm ent during th e last two decades (e.g., P S L / P S A [Teichr oew 77], S REM [Davis and Vick 77], SCCS[Rochkind 75]). However, m ost of th em are m ainly concerned w ith a single phase or a single func tio n of th e softw are life cycle, such as requirem ent analysis, program m ing, doc u m en tatio n , version control, or configuration m anagem ent. A recent research direction is th e exploration of an underlying project d atab ase w hich m odels all inform ation produced thro u g h th e entire life cycle[Horow itz 86a, Penedo 86]. 36 W ith these issues being explored, it encourages us to design an d build an in teg rated softw are project m anagem ent system th a t assum es and m akes use of such a database. T his section gives a brief review of several system s th a t provide in teg rated d atab ase support for softw are developm ent. 2.5.1 S O D O S SODOS (Softw are D ocum entation Support)[H orow itz 86a, H orow itz 86b] is a system w hich supports th e definition and m anipulation of docum ents used in developing softw are. Its objective is to com bine object oriented representation an d d atab ase technology w ith a user-friendly interface to support docum ent prod u ctio n th ro u g h o u t softw are life cycle. A graph m odel is defined for a for m al description of consistency, com pleteness, and traceab ility of th e software docum entation. In SODOS a docum ent is represented as a com plex object an d is stored as a set of stru ctu red com ponents w ithin an extended relational d a ta m odel context. A predefined hierarchy of docum ent class and subclasses serves as a tem p late for constructing an instance of th e docum ent. This tem p late consists of the ty p e of th e inform ation to be stored, its stru ctu re, th e operations th a t m ay b e perform ed on th e docum ent and the relationships betw een docum ents. By in stan tiatin g th e docum ent class, designers and program m ers can create new docum ents. T he docum ents are associated w ith each o ther based on predefined relationships w hich depend on th e sem antic context of th e docum ents. Each docum ent class and subclasses contain a schem a th a t defines th e relationships of each docum ent instance w ith other docum ent instances. T h e user can create, u p d ate, and relate docum ents th ro u g h a window interface. A simplified QBE 37 language allows th e user to query th e inform ation and relationships associated w ith th e docum ents. SODOS has defined a good fram ew ork for m anipulating software docum ents. However, th ere are m any feasible extensions of it. Since docum ents are results of various developing activities in a project, it can have m ore powerful capabil ities if we in corporate it in to a project m anagem ent system . For exam ple, the Plotter-driver-design activity takes th e g ra p h ic -c o m m a n d -s p e c ific a tio n as in p u t an d generates a code m odule p l o t t e r . d r iv e r . T he relationship betw een b o th docum ents is im plicitly form ed by th e execution of th e activity while the user has to relate th em explicitly in SODOS. W e can also query m ore inform a tio n besides th e docum ent alone. For exam ple, if la te r testin g shows th a t the driver does not m eet the required functions, we can find responsible staff for b o th design an d im plem entation activities and schedule a review m eeting. 2.5.2 P M D B PM D B (P ro ject M aster D ata Base)[Penedo 86] is an environm ent database for software engineering w hich contains a collection of p roject products which includes plans, docum ents, form s, code, schedules, resources, etc. Its goal is to provide a high level of integ ratio n am ong project com ponents and easy access to all its inform ation. PM D B defines a m odel for the project fife cycle process by capturing d a ta an d th eir relationship from th e proposal phase through m aintenance. Objects are th e com ponents of th e PM D B m odel which characterize types of d a ta which are relevant to a project. O bjects are in stan tiated and each instance is used to represent a different occurrence of th a t object. For exam ple, th ere will be as m any instances of th e object Person as th e num ber of persons in the 38 p roject. Each object has a set of attributes describing th e characteristics of th e object and each instance of an object m ay have different values for those a ttrib u te s. Relationships show: th e connectivity betw een objects. T here are several m echnism s defined to su p p o rt th e integrity and consistency of th e d ata, to support version control, and to control access and u p d ate. A p ro to ty p e has been im plem ented by tran slatin g the object view into Ingres relations and U N IX files. T h e PM D B m odel can act as th e core of a softw are engineering environm ent. It captures d a ta w hich is com m on across large software pro jects b u t does not support any specific technique or tool (e.g., SREM [Davis an d Vick 77] for re quirem ent analysis, SCCS[Rochkind 75] for source code control). D ue to th e dynam ic n atu re of th e object view, it is extensible and allows new d a ta to be added to its core w hen a specific technique is supported. T hus softw are project m anagem ent functions m ust be built upon such a com prehensive d atab ase core. 2.5.3 I S T A R IST A R [Dowson 86] is an in teg rated project support environm ent th a t a t tem p ts to provide support for every aspect of software and system production. In stead of in teg ratin g existing project support tools together, it adopts the top- dow n approach which sta rts from a definition of th e overall requirem ents for softw are project support and th e associated d atab ase needs, an d th en leads to th e developm ent of a set of tools to supply coherent su p p o rt. IST A R uses a contractual approach to develop th e fram ew ork. Every activity in th e software process is a contract and is conducted by a co n tracto r (e.g., a program m er or team of program m ers) for a ‘client’ (e.g., a m anager). A co n tract m ay be decom posed in to several subcontracts to help fulfill th e original 39 co n tract. T he collection of tasks th a t com pose a com plete softw are project form s a contract hierarchy. T he root of th e hierarchy is th e contract for th e p roject as a whole. T he leaves are self-contained contracts which are com pleted w ithout lower level subcontracts. A n independent contract database is m ain tain ed for each individual contract w ithin a p ro ject. It is possible to distrib u te th e hierarchy of contract databases over a netw ork of host m achines. Every task in a p roject requires some degree of planning, scheduling, and resourcing. T he initial ISTA R tool set — th e project, resource and d a ta m anagem ent tools — is designed to facilitate th e base level su p p o rt. To em ploy existing tools into ISTA R , two p o ten tial problem s m ust be con sidered. F irst, these tools will not in teract w ith th e co n tract databases, b u t ra th e r will o p erate on some collection of files. Second, th e tools will n o t reflect IS T A R ’s user interface conventions. In order to solve these problem s, each ex isting tool is packaged in an envelope. This envelope in tera cts w ith th e user via th e stan d a rd interface an d accesses th e contract d atabase. T he existing tool is invoked by its envelope. T he m ajor contribution of IST A R is its intention to support all th e activities involved in conducting a softw are project. Existing tools can b e in teg rated into th e sup p o rtin g environm ent by appropriate packaging w ith a standarized user interface an d com m on access to th e contract d atab ase. It provides tw o very crucial com ponents of software project m anagem ent before em ploying existing tools, th e user interface and th e project database. 40 2.6 S u m m a ry o f R e la te d R esea rch In sum m arizing th e related w ork, th e m odels and system s described in this ch ap ter provide some resolution to the lim itaions p o in ted out in chapter 2. However, th ey only cover certain issues and need to be fu rth er extended before they can be ad opted to software project m anagem ent. C allisto provides a fram ew ork for hierarchical activity representation and de rives a set of project m anagem ent related theories. Since th e article [Sathi 85] only concerns knowledge representation, several issues are not explored such as au to m ated planning and scheduling, activity triggering and in stan tiatio n , etc. N O A H and its extension use searching and conflict resolution techniques to perform planning and project netw ork generation. However, th ey only consider prim itive single-valued (tru e an d false) conditions. Resource requirem ents and disjunctive preconditions of an activity are not taken in to account and need a m ore sophisticated planning m echanism . T he scheduling approach introduced by N U D G E can be applied to intelligent resource allocation and scheduling for p roject m anagem ent. T he knowledge representation schem e described provides a fram ew ork upon w hich higher level m anipulation operators to determ ine al tern ativ es and resolve conflicts can be built. Since th e softw are developm ent process is a highly parallel environm ent, incorporating a m odel th a t is able to m onitor progress of concurrent activities is necessary. T he P etri net m odel seems to m eet th is requirem ent. However, we need fu rth er extension of th e P etri net m odel to perform activity in stan tiatio n an d keep track of historical project inform ation. T he extended m odel should also provide an interface betw een higher level existing tools and th e underlying database. T he conceptual level stru ctu re of the system s surveyed in this ch ap ter falls 41 in to two categories, fram e-based (C allisto, N U D G E) or object-oriented (SO D O S, PM D B , an d ISTA R ). A fram e collects all inform ation related to one concept to g eth er and typically has a fixed num ber of slots for each expected entity. T he num ber of entries in each slot can be variable. T he value in each slot can be, in tu rn , defined by another fram e. Fram es are effective in handling com plex stru ctu res. T hey m ay have a fairly clear hierarchical stru ctu re w ith th e slots equivalent to th e d atab ase schem a. In an object-oriented system , the knowledge is encoded in th e connections betw een object entities and th is forms a sem antic n et. It can b e seen as th e converse of fram es. All th e inform ation depends on th e relationship betw een one fact and another. Fram es are suitable for hierarchical representation. However, th ey m ay have difficulties in describing m any-to-m any relationships. For exam ple, a program m er can w ork on several activities an d an activity can have several personnel involved. B o th entities are in th e fram e stru ctu re and m ust include each other as a slot for efficient accessing. T he indirection m apping used in N U D G E can solve th e redundancy problem , b u t m ore efforts are required to m ain tain d a ta consistency. Interfaces betw een th e languages used for fram e rep resen tatio n and th e languages used for d atab ase m anagem ent are difficult to build. O n th e o th er h and, an object-oriented system can encode m any-to-m any relationships easily, as a rb itrary connections betw een objects is p erm itted . O n th e o ther h an d , it has th e defficiency th a t one has to define subtle connection types betw een objects such as p ro p erty inheritance from supertype to subtype and th e distinction betw een instance variable and class variable. T he decision to choose one approach over th e o th er depends on th e extent to w hich one needs to interface th e d atab ase to o th er tools. 42 Chapter 3 DesignNet — A Hybrid M odel for Software Project Management T h e m ain goal of this ch ap ter is to derive a m odel for th e description and analysis of a softw are developm ent project th ro u g h o u t its planning an d exe cution phases. Such a m odel m ust be able to describe th e n atu re of a design p roject an d is rich enough to overcome th e deficiences m entioned in earlier chapters. T he m ajo r distinction betw een software projects (or m ore broadly design projects) and m anufacturing projects is th a t form er ones do not progress in a sim ple, linear m anner from application concept to operational system[Dowson87]. R ep etitio n of th e sam e activities, due to change of previous decisions, seems to be central to th e software process. Besides errors and m istakes, th e evolution of a softw are system (e.g. new release w ith enhanced features) also leads to iteratio n s of th e process. T he first section addresses the concerns in deriving a m odel w hich is able to handle iterations. DesignN et is a m odel w hich utilizes A N D /O R stru ctu ral operators to de scribe th e work breakdown structure (whs) and P etri net n o tatio n to represent th e dependencies and parallelism am ong activities, resources, and products. T h e project m anager can use backw ard transitions in th e project plan to cap tu re possible iterativ e situations. A triggering m echanism is defined w ith th e 43 tran sitio n firing o p eratio n to au to m ate th e activity in itiatio n , replanning, and rescheduling w hen activities have to be re-initiated. T hus, th e iteratio n process can not only be m odeled b u t also be autom atically recorded. P rio r to th e description of D esignN et, section tw o gives a brief review of two p o ten tial useful m odels — th e A N D /O R graphs an d P etri nets — w here D esignN et’s central concepts are derived from . T he inadequacies of these two m odels are also presented. T he th ird section contains th e form al definition of th e DesignN et m odel in term s of its m odeling constructs and interacting m echanism s. This definition is given by a com plete g raph m odel w ith different graphical no tatio n s for various inform ation m odeled by D esignN et. A fter being form ally defined, th e m odeling pow er of D esignNet is th e n illu strated through an exam ple th a t m aps a popular existing softw are process m odel in to D esignN et. T h e im plication of th e m odel and some analytical properties associated w ith m odeled projects are addressed in another tw o subsections. 3.1 T h e S oftw are P r o c e ss M o d el R ecently there has been a great deal of discussion an d concern ab o u t th e lack of an ap p ro p riate m odel for th e developm ent of large-scale softw are[A gresti 86, C urtis et al. 87, Dowson87, M cCracken, Royce 87]. W hy should we atte m p t to develop m odels of th e software developm ent process? O ne reason is th a t by having a m odel we can u n d erstan d for ourselves and explain to others the various steps th a t we m ust go thro u g h before com pleting a p roject. So a m odel is a m eans of com m unication betw een th e developers and th e custom er and betw een th e developers them selves. A nother use of a m odel is for assisting in th e m anagem ent of th e process. A m odel can provide m anagem ent w ith a set of points, (m ilestones), th a t can be exam ined to determ ine th e ra te of progress 44 c requirement analysis / preliminary design h . f'd e ta i l design h . r (^implementation ( \ testing c > 1 operation 3 Figure 3.1: W aterfall m odel. of th e p roject. A th ird advantage of a m odel is th a t it gives softw are engineers direction in building tools th a t will support and enhance the softw are process. T h e tra d itio n al m odel for softw are developm ent is th e so-called w aterfall m odel. A com plete picture of th is m odel is found in [Royce 87] and is re produced in figure 3.1. T h e w aterfall m odel views software developm ent as a m anufacturing process. Each step is a phase, and th e com pletion of one phase leads to an o th er. E ach phase has in p u ts from a previous phase an d o u tp u ts, (som e of w hich are deliverables), th a t it produces. These o u tp u ts are used by m anagem ent for tracking th e progress of a project. For exam ple, Royce lists six types of docum ents as o u tp u ts, software requirement document, preliminary design specification, interface design specification, final design specification, test plan, an d operating instruction manual. 45 T h e w aterfall m odel is often shown w ith back pointing arrow s as well as forw ard pointing arrow s, indicating acknow ledgem ent th a t th e m anufacturing m odel cap tu red in th e w aterfall ch art is not precise, and th a t previous phases m ay be retu rn ed to. Royce also em phasizes th a t th e w aterfall ch art is not in ten d ed to preclude prototyping. Criticism s of th e w aterfall m odel have appeared in several places, e.g. [C urtis et al. 87, M cCracken], who observe th a t • it is foolish to believe th a t one m odel is ap propriate for all softw are de velopm ent projects, • th ere is in ad eq u ate m odeling of th e fact th a t requirem ents change • th ere is no m odeling support th a t involves th e end users in th e develop m ent process. • it fails to tre a t softw are developm ent as a problem solving process and therefore offers little insight in to the actions and events th a t precede the finished pro d u cts. A gresti develops th ree altern ativ e m odels, called (i) proto ty p in g , (ii) opera tional specifications, an d (iii) transform ational im plem entation. A fter studying these alternatives, C urtis et al. conclude th a t these m odels are based on tech nologies th a t are new and unproven and hence it is unclear w hether they will scale up to in d u strial size. It is our belief th a t a single m odel m ay not exist w hich will perfectly describe th e softw are developm ent process from all angles. However, for th e purpose of this thesis we w ould highlight th e m ajor features th a t we feel are essential. 1. T he m odel m ust adequately describe th e fact th a t softw are developm ent is 46 a design process. Design is inherently an evolutionary process w here steps are continually retu rn ed to , and m oreover, som etim es steps are entirely abandoned and new steps inserted. 2. T he m odel should be able to include th e fact th a t a large-scale software developm ent p roject is inherently a parallel process w ith m any people u n d ertak in g tasks sim ultaneously. 3. T he m odel should be able to indicate th a t a diverse set of conditions m ust exist before an activity can be undertaken. 4. T he m odel should be able to indicate all artifacts th a t are produced at various points in th e process. 5. If an activity fails, th e m odel should be able to in d icate th e activities and resources th a t are affected. Affected activities m ay have to be re-executed. 6. T he m odel should be able to indicate th e extent an d n a tu re of resources in volved in a subtask, including people, consum m able and non-consum m able resources. T h e D esignN et m odel proposed here atte m p ts to satisfy all of these criteria. T his m odel is a hyb rid m odel which utilizes A N D /O R stru ctu re operators to describe th e work breakdow n stru ctu re an d P etri net n o tatio n to represent the dependencies am ong activities, resources, and products. It not only provides th e p roject staff w ith a stru ctu ral view of th e project inform ation, b u t it also assists th e project m anager in m onitoring progress. 47 3.2 S o m e P o te n tia lly U sefu l M o d els In th is section we provide a brief in tro d u ctio n to two com putational m odels th a t we in ten d to use to describe th e software developm ent process. N either m odel by itself is adequate to describe th is process. However, as we shall see, in com bination they correct for all th e deficiencies m entioned at th e end of the first section. 3 .2 .1 A n d - O r G r a p h s A N D -O R graphs are used in artificial intelligence to m odel a task in term s of a series of goals and subgoals [W inston 84]. E ach goal is represented by a node and its successor nodes are, in some sense, m ore prim itive goals. Those goals, w hich can be satisfied only w hen all of th eir im m ediate subgoals are satisfied, are represented by AND nodes. O ther goals, which can be satisfied w hen any of th eir im m ediate subgoals are satisfied, are represented by O R nodes. In m any applications, th e g rap h is usually generated at run-tim e while th e program is attem p tin g to satisfy th e m ain goal. A N D -O R graphs have also been proposed as a m odel for describing C A D /V L SI system s [McLeod 83]. A n AN D -O R graph is a directed, acyclic graph containing three types of nodes: 1. A n AND node denote an object th a t is an aggregation of all of its successor nodes. 2. A n O R node denote an object defined by only one of its successor nodes. 3. L E A F nodes denote atom ic entities. T hey have no outgoing arcs. D uring its in itiatio n , a softw are project is usually decom posed top-dow n u n til th e softw are functional elem ents are sufficiently sm all to be estim ated, 48 planned, and executed. E stablishing a wbs becom es th e m ajo r task in th e early stage of softw are developm ent an d a representation schem e is required. T he wbs is a directed acyclic graph, so it m akes sense to exam ine th e A N D -O R g rap h to see if th e extension of A N D /O R nodes produces additional m odeling pow er. T h e trad itio n al wbs essentially has only AND nodes. A dding th e idea of an O R node w ould be an im provem ent, b u t a sm all one. T he problem of m ultiple instances of th e wbs is not solved, th e problem of parallel activities is not addressed, and th e problem of the activities changing radically is not addressed. 3 .2 .2 P e tr i N e t M o d e l T h e P e tri n et m odel is an ab stract m odel for describing and analyzing in form ation an d control flow in asynchronous concurrent system s[Peterson 77]. T h e relationships betw een th e p arts of a system can be represented by a graph or netw ork. T h e g raph consists of two types of nodes: places (represented by circles) w here one or m ore tokens (represented by sm all dots) can reside and th e transitions (represented by bars) which can be fired to move tokens from in p u ts to o u tp u ts. A P etri net w ith tokens is called a m arked P e tri net and th e num ber of tokens in a place is called th e m arking of th a t place. A tran sitio n is enabled w hen all of its in p u t places have tokens. T he firing of a tran sitio n causes tokens to be m oved from th eir in p u t places to th eir o u tp u t places. F igure 3.2 shows th e P etri net of a typical send-receive m echanism in a com m unication system . It m odels three p a rts of th e system : th e sender, the receiver, and th e m edium . Initially, two tokens are placed in th e n et. This is called th e in itial m arking of th e P e tri net. T he sender is in processing state (i.e. fo rm attin g a m esssage according to a designated protocol). T he receiver is in a ready-to-receive sta te w aiting for any incom ing m essage. Once a message 49 message sent send message ready-to-receive ready-to-send receiving message wait-for response message received message formatted processing finished i i sending acknowledg processing o processing acknowledged acknowledgement Medium Sender Receiver Figure 3.2: P etri net of a sender-receiver system . is fo rm atted (th e new com m and fo rm atted tran sitio n is fired), th e sender will tra n sit to a ready-to-send state. W hen th e m essage is tra n sm itte d th ro u g h the com m unication m edium , th e send-m essage tran sitio n is fired an d two tokens are created, one to th e w ait-for-response place on th e sender side, th e o ther to the m essage-sent place on th e m edium . Now th e receiving message tra n sitio n on th e receiver side can be fired and th e receiver tra n sits to m essage-received state. A fter th e m essage is verified, receiver sends an acknow ledgem ent response to th e sender and sta rts to process this m essage. W hen this response is received by th e sender side, th e sender goes back to processing state an d is ready to accept any fu rth e r request. W hen th e processing of th e message is finished, th e receiver also goes back to ready-to-receive state. In this exam ple, static properties of a system are m odeled by th e graphical rep resen tatio n of a P etri net. D ynam ic properties of a system result from its 50 execution an d can be determ ined by th e net graph, th e in itial m arking, and th e tra n sitio n firing rules. T he net g raph m odels tw o aspects of system s: events an d conditions, and th eir relationships[Peterson 77]. Tokens in places denote th e existence of certain conditions. T he fact th a t these conditions hold m ay cause th e occurrence of certain events. Firing a tran sitio n can be considered as th e happening of an event. It m ay change th e sta te of th e system , causing some conditions to cease holding and others to begin to hold. Form ally, a P etri n et C is defined as a four-tuple C = (P ,T , I> 0). P (the set of places) and T (th e set of transitions) are th e tw o m ajo r com ponents of a n et. T hey are associated w ith th e circles and bars in a P etri net graph. D irected arcs from th e places to th e tran sitio n s and from th e tran sitio n s to the places are represented by th e in p u t and o u tp u t functions. T he in p u t function I defines, for each tran sitio n tj, th e set of in p u t places for th e tran sitio n I(tj). T h e o u tp u t function 0 defines, for each tran sitio n t j , th e set of o u tp u t places for th e tran sitio n 0 (tj). A m arking vector p — ( p i , p 2, ...,p n ) gives th e num ber of tokens in a place for each place at a p articu lar tim e. T he num ber of tokens in place pi is pi. A P e tri net G = (P, T, I, 0 ) w ith a m arking p becom es the m arked P e tri n et, M — (P , T , I , 0 , p ). T he n ex t-state function 8 defines th e change in sta te by firing a tran sitio n . It changes th e m arking of th e P etri net p, to a new m arking p ‘. If < t - is enabled in m arking p, th en 8 (p ,tj) = p ', where p' is th e m arking th a t results from rem oving tokens from th e input of tj an d adding tokens to th e o u tp u ts of tj. Tw o sequences result from th e execution of th e P etri net: a sequence of m arkings (p °, p 1, p 2, . . . ) and a sequence of tran sitio n s (tj(o), ^'(2)? • • •) such th a t 8(pk,tj(k)) = fJ > k+1 for k = 0, 1, 2 , ----- Since th e P e tri n et m odel is a m ore pow erful m odel th a n fin ite-state m a chines, m any analysis questions tu rn out to be unsolvable or solvable at a high 51 cost requiring exponential tim e and space. Several sub-classes of P etri net pose restrictions on its m odeling ability in th e hope th a t th e decision power will b e increased [Peterson 77]. T here are also several extensions of P etri nets proposed th a t either increase th e m odeling power or ad ap t to certain types of applications. Some extensions add a predicate to tran sitio n s an d associate a ttrib u te s w ith tokens to represent value-dependent sem antics. In [Yau 83], a m odified P etri net m odel is used to describe a d istrib u ted softw are system design representation. A m ethod [Nelson 83] for tran slatin g P e tri nets in to a special procedural language nam ed X L /1 w hich can, in tu rn , be optim ized and tra n slated into existing com piled languages has also been presented. A nother extension to th e classic P etri n et definition is to in co rp o rate th e n otion of tim e. In th e extended m odel of [R am am oorthy 80], tran sitio n s are used to m odel processes and th e firing of a tran sitio n becom es an event w ith a d u ratio n equal to th e execution tim e of th e process. A sim ilar extension was m ade by [C oolahan 83] w ith th e exception th a t places are used to represent processes. T he execution of a process is m odeled by a tran sitio n representing th e in stan tan eo u s sta rt of execution w ith a directed arc to a place representing th e condition of th a t process being in execution. In sum m ary, th ere are several advantages of m odeling a concurrent system using P etri nets. Its graphical representation provides an intuitive an d inform al view of th e underlying system behavior. T h e existence of analysis techniques allows th e designer to derive th e properties of a system and determ ine th e com plexity to verify w hether th e m odeled system has such properties. T he ability to m odel a system hierarchically facilitate th e designer to apply top-dow n or b o tto m -u p approaches during the design phase. It is especially suitable for m onitoring progress of concurrent activities w ith an extension of the tim e do m ain as in [Coolahan 83]. T his gives rise to fu rth er investigation-of its p o ten tial 52 application in m odeling the software design process. \ 3 .2 .3 In a d e q u a c ie s o f T h e s e M o d e ls i I ■ T he hierarchical n atu re of th e A N D /O R g raph m odel provides a stru ctu ral view in to th e m odeled design objects. However, it only describes th e vertical stru ctu re. T he inform ation involved in th e softw are process consists of several ! I types, nam ely, th e pro d u ct — b o th th e in tern al docum entation and deliverable | end item s, th e activ ity — carried out to accom plish th e p roject, th e resource — consum ed during th e execution of th e p ro ject, and th e sta tu s rep o rt — is sued at various checkpoints. T he A N D /O R g raph m odel does n o t provide th e dependency relationships am ong different inform ation types. Since for each in- ' form ation type, an associated wbs can be constructed w ith it, we have a set of wbs’s represented in A N D /O R graphs. W ith o u t fu rth er stru ctu ra l connection, we cannot know w hat resouces are utilized during th e execution of an activity , to generate th e required p ro d u ct. T here is also no traceab ility am ong infor m atio n in different phases. Several m anagerial questions, such as: w hat is th e associated specification for a specific code m odule, and w hat responsible staff need to m eet if a portion of th e requirem ent is not m et, cannot be answ ered. If one tries to apply th e P etri net m odel directly to softw are p roject m an agem ent, th is is also inadequate in several aspects. F irst, a token only assum es a Boolean value condition. Suppose a place is used to represent a planned ac tiv ity and a token inside it m eans th a t th is activ ity is currently active(being executed). R elated inform ation, such as w hen it is sta rted , how soon it is ex p ected to finish, and how m uch it contributes to th e overall project cost, m ust be a ttac h e d to this token. A ssociating properties w ith tokens enables th e net to carry m ore d a ta flow inform ation. T hus, nodes or places in a P etrie net need to be of several different types. In our proposed m odel, a token is defined as a 53 com posite object and carries m ore inform ation. Second, th e execution of a P etri net is nondeterm inistic. If m ore th a n one tran sitio n is enabled at any tim e, it is not predictable which one will fire first. T his m akes it m ore com plicated to analyze th e properties of a system . In an a ctu al im plem entation, we can associate an executable procedure w ith each tran sitio n . T he procedure will be invoked w henever th e tran sitio n is enabled an d determ ine globally w hat tran sitio n to fire first if m ore th a n one are en- i abled. T his approach is explanined in th e next section. T he nondeterm inism is elim inated via th is m echanism . F urtherm ore, th e P e tri net m odel does not provide for th e representation of aggregates of nodes. In a knowledge representation schem e, some properties of higher level nodes are defined through aggregate functions over properties of low er level nodes. For instance, th e cost of a task is a sum m ation of the cost of its co n stitu en t activities and th e com pletion tim e of a task is th e latest com pletion tim e am ong its constituent activities. T his capability should not b e confused w ith th e hierarchical m odeling in a P e tri net. A P etri net m odel allows an entire net to be replaced by a single place or tran sitio n for m odeling at a m ore a b strac t level. It also allows places and tran sitio n s to be replaced by subnets to provide m ore detailed m odeling[Peterson 77]. T hus it cannot be directly used for m odeling th e wbs. To keep track of th e project execution history for la te r reasoning, th e token flow th ro u g h th e net m ust be recorded. T he tran sitio n firing in a P etri net is volatile. T his m eans once a tra n sitio n is fired, th e tokens in its in p u t places are rem oved. T here is no way to inquire if a token h ad existed earlier at a place. It does not provide for m ultiple instances of tokens in th e n et. T hus it cannot be directly used for m odeling the event th a t occurs w hen an already executed activ ity now needs to be re-executed. 54 3 .3 A H y b rid M o d el S o lu tio n — th e D e s ig n N e t M o d e l T he m odel proposed here is called th e DesignNet m odel1. It is a hybrid m odel th a t utilizes b o th th e A N D /O R graph and P etri n et n o tatio n to facilitate th e planning and m onitoring of a softw are project. T h e form al definition of this m odel is given in th e first subsection. How to m ap a wbs onto a D esignN et and th e im plication of th e m odel to softw are iterativ e processes, are discussed in following subsections. T h e last section defines a set of properties th a t can be verified from a p ro je c t’s D esignN et representation. T h e algorithm s to id en tity these properties and th eir com plexity analyses are also presented. 3 .3 .1 T h e D e s ig n N e t M o d e l Basically, th e D esignN et m odel follows th e term inology used in A N D /O R graphs an d P etri nets. W e will give an in tro d u cto ry exam ple and illu strate how a p o rtio n of a softw are p roject can be m apped onto th is m odel. A form al definition is given after th is brief introduction. A D esignN et consists of a set of places, a set of stru c tu ra l operators, and a set of tran sitio n s. Places are typed. A token of a specific place ty p e can only represent inform ation of th a t type. Five place types are defined including project, activity, resource, product, and status report. T h e project type place is th e root node of a wbs. S tru ctu ral operators connect places of th e sam e type on tw o adjacent levels w here th e lower level places are th e decom position of the higher level place. T he hierarchy resulting from th e connection of stru ctu ral o p erato rs is th e wbs of th e project. P rerequisite conditions(products an d re sources required) before an activity can sta rt and th e p ro d u cts generated by an 1T his name is based on its applicability to a design oriented project. It should not be confused with only the design phase of the software development process. 55 activ ity are linked to activities by transitions. T his linkage defines th e depen dencies am ong life cycle phases. T he firing of transitions creates new instances of tokens and sim ulates th e p roject execution process. Each token is associated w ith tim e dependent inform ation an d represents an occurrence of an itera tio n in th e softw are developm ent process. For exam ple, tokens in a pro d u ct place d enote various versions of th a t product. A n exam ple of a D esignNet is shown in F ig.3.3. T he activity places activity, design & implementation, and testing to g eth er w ith th e AND o p erato r form an activ ity wbs. T h e pro d u ct places graphic command spec., test plan & procedure, driver code, operation manual, baseline code, an d version description, also form a p ro d u ct wbs. T h e plotter driver design activity is in itiated either w hen a new version of th e graphic specification is generated or w hen th e testin g shows a failure. B o th situations require th e resource, system programmer, to be involved in th e design task. O ther elem ents in this figure, such as th e concepts of place ty p e, in sta n tia te d tokens, aggregation w ith stru ctu ra l operators, and tra n sitio n firing rules, will be explained in th e following paragraphs. F o rm a l D e fin itio n DesignNets are com posed of th ree basic com ponents: • a set of places, P, w here P is a union of five possible place types'. Pj for p rojects, Pa for activities, Pr for resources, Pp for pro d u cts, and Ps for statu s rep o rt. Specific sym bols are used to represent these place types. A circle denotes a project place. It is always th e root node of a wbs hierarchy. A n oval represents an activity place. A punched card sym bol is used for the resource place, since resources can be considered as in p u t of activities. P ro d u ct places are draw n as p rin ted o u tp u t sym bols as in 56 project activ ity testin g graphic command spec. o peration m anual A * system irogram m er driver jdesign & imple. test plan & procedure success baseline code success driver code version description driver te stin g fails testin g staff fail Figure 3.3: A n exam ple of th e D esignN et. 57 conventional flow charts, since they are entities g enerated after activities are finished. A square box represents a sta tu s rep o rt place. • a set of structure operators, S, is a union of two types of operators, an AND o p erato r, Sa, and an O R o p erato r, S 0, w here th e o p erato r con nects nodes of th e sam e type, (activity to activity, p ro d u ct to p ro d u ct, resource to resource), and th e AND o p erato r defines an AND relationship am ong th e successor nodes and the O R o p erato r defines an O R relation ship am ong th e successor nodes. G raphically, an AND stru ctu re o p erato r is represented by a Boolean logic AND gate sym bol, and an O R stru ctu re o p erato r is represented by a Boolean logic O R gate sym bol. • a set of execution transitions, T, w here T is a union of tw o possibilities, Ts,T f w here each is an executable procedure. This m akes th e m odel de term inistic. Ts is a tra n sitio n to sta rt an activity and Tf is a tran sitio n after an activity is com pleted. In graphical rep resen tatio n , a b ar repre sents a tran sitio n . Since it is clear from the position of th e b ar w hether it stands for a Ts or a Tf tran sitio n , no visual distinction is m ade betw een Ts and Tf. Places are strongly-typed. E ach place type can be fu rth e r classified into several subtypes. For exam ple, th e requirem ent docum ent, prelim inary design specification, interface design specification, code, test plan, an d op eratin g in stru ctio n m anual are possible subtypes of th e p ro d u ct place type. T he tokens resident in places carry m ore inform ation th a n ju st a Boolean value. For each place type, a set of properties are defined and any token in a place becom es a com posite object of a specific token type. For exam ple, a token in a resource place m eans th a t a resource has been allocated in an ticip atio n of an activity startin g . In addition to its allocation statu s, th e following relevant inform ation can be stored w ithin this token: resource type (system an aly st, program m er, 58 or technical w riter), skills, hom e d ep artm en t, unit cost, percentage of w orking tim e available, etc. Places of th e sam e type form a hierarchical lattice via thq connection of stru ctu ral operators. T here is one place node denoted as th e root and defined to b e at level zero. T he AND o p erato r defines th e subcom ponents of an aggregate entity. T he O R o p erato r specifies w hat alternatives are available for a design object. T h e m anner in w hich places on adjacent levels are connected is defined b y th e four functions: I a, I 0, Oa, O0. • T he function Ia represents th e set of in p u t arcs for connecting a place node to an AND o p erato r S a• • T he function I a represents th e set of in p u t arcs for connecting a place node to an O R o p erato r S 0• • T h e function 0 a represents th e set of o u tp u t arcs from an AND o p erato r to a place one level above th e place associated w ith its in p u t. • T h e function Oa represents th e set of o u tp u t arcs from an O R o p erato r to a place one level above th e place associated w ith its in p u t. • In th e g rap h rep resen tatio n , th e four functions Jc, Oa, O0 are repre sented by th e directed arcs from th e places to th e operators an d from th e operators to th e places respectively. T h e stru c tu ra l operators have two m ajo r functions. F irst, th ey allow aggregate inform ation of a higher level place to be collected from its constituents. For exam ple, we can define th e cost of a higher level activity as a sum m ation of th e cost from its AND children activities and th e com pletion tim e of a higher level activity as th e latest com pletion tim e am ong its AND children activities. Second, th ey allow newly created tokens on lower levels to propagate upw ard. 59 (a) (b) (d) (c) F igure 3.4: T h e token propagation th ro u g h stru c tu ra l operators. Let us use an exam ple to illu strate how this m echanism works. Suppose we have a product of program m odule pi w hich is fu rth er decom posed in to two subm odules p 2 an d ps as show n in F ig.3.4(a). A t tim e i, a version p 2(i) of P2 is generated. T he AND o p erato r will autom atically create a token instance p ^ of pi. T his is show n in Fig.3.4(b). A t tim e j , a v e rsio n Ps(j) Vz generated. T h e AND o p erato r now creates an instance Pi(j) w hich is com posed of p2(i) and Pz(j) as Fig.3.4(c). L ater, a t tim e k, due to th e existence of a new version of p 2, a new version P2(k) is generated. A utom atically a token pi(fc), w hich is com posed of P2(k) and P3(j), is created as in Fig.3.4(d). T his m echanism provides valuable assistance for version control and configuration m anagem ent. 60 T he relationships am ong different place types are defined by th e connections of tran sitio n s. T h e m anner in w hich th e places on th e sam e level are connected ; is defined by four functions Ia, If, Os, Of. • T h e function I3 represents th e set of in p u t arcs for a tra n sitio n Ta, from a place which is of ty p e p ro d u ct or resource. • T h e function I f represents th e set of in p u t arcs for a tra n sitio n T f, from a place w hich is of ty p e activity or statu s. • T h e function Oa represents th e set of o u tp u t arcs for a tra n sitio n Ta, to a place w hich is of type activity. • T h e function Of represents th e set of o u tp u t arcs for a tra n sitio n Tf, to a place w hich is of type product. • In th e graph rep resen tatio n , th e four functions If, Is, Of, Oa are repre sented by th e directed arcs from th e places to th e tran sitio n s and from th e tran sitio n s to th e places respectively. N ote th a t an activity place is never connected to an o th er activ ity place w ith a tra n sitio n betw een th em , since Ta only connects p ro d u ct and resource to activity an d Tf only connects activity to pro d u ct. T his restrictio n avoids establishing th e dependencies directly betw een activities an d rem oves th e lim itatio n of the tra d itio n al P E R T approach th a t only allows conjunctive ’A N D ’ dependent con ditions to be specified. In F ig.3.3, th e p lo tte r driver design activity will be triggered either w hen a new version of graphic specification is g enerated or w hen th e testin g shows a failure. T hus, disjunctive dependencies can be built. A DesignNet graph D is defined as a five-tuple D — (P, T, S, I, 0 ) where P = {Ps,P .,P „ P r ,P .}, T = S = { S .,S .} , I = and 61 Pr O s 7 f C ~ * C p « X j */ Figure 3.5: D esignN et graphical representation O = { 0 S, O f, Oa, 0 o}. Figure 3.5 sum m arizes th e symbols used an d th eir con nections. T he D esignN et graph still preserves th e bipartite p ro p erty satisfied by P etri nets, since its nodes can be p artitio n ed in to three sets (transitions, places, and stru c tu ra l o perators) and in th e tw o subset com binations (P, S , I a, I 0iOa, 0 0) an d (P , T , I s, I f , 0 3, 0 f ) each arc is directed from an elem ent of one set to an el em ent on th e o th er set. N otice th a t there is no arc linkage betw een transitions a n d stru c tu ra l o p erato rs, th e tw o sets 5 , T are disjoint. A nother interesting p ro p erty is th e projection of th e net into subsets of its dom ain. R em oving T an d its connections I a, I f t Os, O f , we get four p artitio n s (activity, resource, 62 p ro d u ct, sta tu s rep o rt) of th e wbs and lose th e dependencies betw een different inform ation types. F urtherm ore, if we w ant to focus on only one product type, for exam ple th e program , we can fu rth er prune away th e undesired product types an d have a program configuration tree resulting. Rem oving S an d its i connections I a, I 0, Oa,O a, th e b o tto m level of th e n et becom es an activ ity net- i i w ork analogous to a P E R T chart, b u t th e hierarchical wbs is lost. T hus, th e 1 pro jectio n of a D esignN et into various dom ains provides different views of a pro ject. A D esignN et executes by firing transitions. Unlike th e firing of a tran sitio n in th e trad itio n al P etri n et, which causes tokens to be m oved from th eir in p u t places to th eir o u tp u t places, th e tran sitio n firing in a D esignN et is a nonvolatile process. A token can b e in one of th ree possible states, active, consumed, or discarded. W hen a token was created, it was p u t in an active state. A tran sitio n m ay fire if it is enabled. A tra n sitio n is enabled if each of its in p u t places has a t least one active token in it. Firing a tran sitio n does not rem ove tokens from its in p u t places. In stead , it changes th e tokens in its in p u t places to a consum ed sta te such th a t any fu rth er firing resulting from th e sam e token is prohibited. T h e tokens created in its o u tp u t places are p u t in an active state. W hile creating new tokens, it also checks w hether any token in o u tp u t places is already in an active state. If th ere are, th en it changes th em to a discarded state. T his guarantees th a t at m ost one token is in an active sta te for any place a t any tim e. N ote th a t we p erm it any num ber of tokens to reside at a place, and each to k en w ould represent an instance of the place w hen th e token was created. D epending on place ty p e, th e num ber of tokens inside a place has different m eanings. T he num ber of tokens in an activity place m eans th a t th e activity ’ has been executed this num ber of tim es. If we w ant to know th e detail of each 63 execution, we can inquire for th e inform ation associated w ith an individual activ ity instance. O n th e o th er h an d , th e num ber of tokens in a p ro d u ct place m eans th a t th ere are so m any versions generated w ith this p ro d u ct. E ach token has a p o in ter to th e d a ta it represents (e.g. th e file nam e of a code m odule). Since a token is not rem oved (just consum ed) after a tra n sitio n is fired, th e num ber of tokens in a place will increase m onotonically. To handle th e tran sitio n firing operation, each tra n sitio n can be considered as an executable procedure. W hen a new token is created in th e in p u t places of a tran sitio n , th e procedure associated w ith th e tran sitio n will be executed. T his procedure w ould check against all th e in p u t places. If all th e in p u t places have active tokens, it perform s th e firing o p eration by setting th e in p u t tokens to consum ed sta te an d creates new tokens in o u tp u t places th ro u g h in sta n tia tion. T his m echanism can be achieved by a triggering operation using object program m ing techniques[G oldberg 82]. A m arking y of a D esignN et is an assignm ent of tokens to th e places in th a t n et. T h e vector y = ( y lf y2, y n ) gives th e num ber of tokens in a place for each place in th e D esignN et an d th e num ber of tokens in place pi is yi, for i = 1, ..., n. Since th e tran sitio n firing is nonvolatile, th e num ber of tokens in a place will never decrease and for a place pi, y ^ is g reater th a n or equal to y ^ for any tim e t later th a n th e tim e s. T he sequence of m arkings (y °, y 1, y 2, . . . ) at th e tim e index 0 ,1, 2,..., to g eth er w ith th e inform ation stored w ith individual tokens, gives th e execution history of a D esignN et. W ith all th e previous definitions, a project J can be defined as a seven-tuple J = (R , P , T , 5 , 1, O , y) w here P , T, S , I , O, y are defined as before an d R is th e root place representing th e project as a whole. T he level next to R , connected th ro u g h an AND stru c tu ral o p erato r, contains th e four activity, resource, p ro d u ct, and sta tu s rep o rt wbs. N otice th a t th e elem ents R , P , T , S , I , 0 to g eth er 64 define th e sta tic plan of a project and th e m arking p keeps th e execution history of th e p roject. 3 .3 .2 M a p p in g th e W a te r fa ll M o d e l o n to th e D e s ig n N e t T h e w aterfall m odel[Royce 87] for software developm ent contains six m ajo r > ( phases. D ifferent personnel skills and developm ent disciplines are required for i different phases. Also, each phase has its own p ro d u ct types. Figure 3.6 shows th e D esignN et rep resen tatio n of th e six developm ent phases. This life cycle phase representation w orks as th e to p level of th e wbs. T he p roject m anager determ ines w hat m ethodology is used for each phase an d de fines th e stru c tu re an d acceptance criteria of th e end p ro d u ct. Verifying func tions of these accepting criteria can th en b e atta ch ed to th e finish tra n sitio n of predefined activ ity types. In the in itial requirement analysis phase, th e user and th e system analyst are involved in defining th e system specification based on the custom er co n tract. Tools for au tom ating th e requirem ent and specification de velopm ent, such as SREM [Davis and Vick 77], can be used at th is stage. D uring preliminary design, system engineers tak e th e specification as in p u t and gener a te th e functional design docum ent, th e interface control docum ent and th e test plan of each m odule. Special design tools (e.g. P SA /PSL [T eichroew 77]) can be used a t th is stage. In detail deisgn and implementation, program m ers tran slate these design descriptions in to code modifies. T he code m odules together w ith te st plans an d testin g procedures generated in earlier stages are th e n tested (testing phase) by testin g engineers and quality assurance staff. W hen th e final p ro d u ct goes into operation, pro d u ct control staff an d th e software m anager are in charge of th e u p d ate and docum ent change. For th e sake of sim plicity, this figure only shows th e tran sitio n s w hich are 65 customer contract system lecification test plan system analyst preliminary design functional^ design doc. system engineer interface control functional design doc. interface control detail design testing nocedure system programmer detail1 design doc. code module programmer success testing engineer testing report quality assurance operation instruction success b'asdm T ^I — testing j V system J change ( bUS I \ l —°^o rt product control staff software manager V v j J update 1 L rpvjsion j w / * documcnTl ^ I operation T change I Figure 3.6: D esignN et of Life Cycle Phases 66 fired w hen activities are successfully executed. If any failure rep o rt is issued while an activity is being executed, p roper backtracking tran sitio n s to previous phases are necessary. Such itera tio n p ath s are o m itted in this figure. However, F ig.3.3 shows one exam ple of this rep etitio n (from driver testin g to driver de sign). In actu al cases, m any repetitions will occur and th e p roject m anager can ad d tran sitio n s w ith ap p ro p riate sta tu s rep o rt places th a t loop back to earlier phases. 3 .3 .3 Im p lic a tio n s o f th e M o d e l T his section describes w hat th e im plications are w hen one applies th e design net m odel techniques to various stages of th e softw are developm ent process. P r o je c t P la n n in g an d C o st E s tim a tio n At th e beginning of a softw are p ro ject, th e p roject m anager is responsible for choosing th e developm ent m ethodology and defining th e typical activ ity be havior an d requirem ents of each phase. These definitions are th e n represented in th e D esignN et m odel and entered in to th e system . T h e D esignN et of the w aterfall m odel described in th e previous section is ju st one tem p late for devel oping th e project plan. D uring th e planning stage, each phase is decom posed in to lower level subactivities th a t inherit th e resource requirem ents an d product specifications from its p aren t activity w ith some elaboration. T his decom posi tio n is perform ed u n til a level is reached such th a t a concrete w orking package can be assigned. Figure 3.7 shows a sam ple decom position of th e p lo tter driver design task. A fter th e wbs has been constructed, the p ro ject m anager can invoke th e cost 67 ( Spreadsheet 'N Project J = j ( Design J ^ Interface ^ ^ Command ^ Q Input ^ Q Output ^ ancL., _ z n C With " N f" Without ^ f Screen ^ C Graphics ''N V Mouse J I Mouse J V bcreen J I Report J ( X window s) Suntools 3 C D ri"os f SiC T ) Figure 3.7: Sam ple decom position of a design task. 68 estim ation function to com pute to ta l project cost b o tto m -u p , level-by-level. In th e design n et, a user can a tta c h different heuristic functions to evaluate prop erties of aggregate objects. Based on th e m ethodology used, a design activity m ay use th e num ber of person hours for estim ation an d an im plem entation ac tiv ity m ay use num ber of lines-of-code for estim ation. A ctually, we only need to apply estim atio n functions to b o tto m level activities. T h e cost of in term ed iate { level nodes are sum m ations of constituent activ ities’ cost and can be com puted J t autom atically. T he existence of a wbs greatly reduces th e m an u al effort spent j on cost com putation. P r o je c t N e tw o r k C o n str u c tio n T he wbs of each phase is derived by individual phase supervisors. Somehow these phases m ust be com bined to produce a single wbs. U sing our m odel we can connect all th e phases in to a single wbs autom atically by applying search ing op erato rs to th e p ro d u ct places. Since an activity takes p ro d u cts as in p u t, it can be sta rte d only after th e activ ity th a t generates th e required pro d u ct is finished. T he predecessor and successor relationships am ong activities are based on th e docum ent (or p ro d u ct) flow across phases. In co n trast to tra d i tio n al C PM an d P E R T m odels, w here th e dependencies are b uilt directly upon activities and m ost of th e planning efforts are spent on m anually co n stru ct ing th e netw ork, including pro d u ct inform ation in th e p roject hierarchy m akes au to m atic netw ork construction possible. A fter connecting all th e o u tp u t pro d u ct places to th e in p u t places of asso ciated activities in th e wbs, th e project netw ork is constructed autom atically a n d th e p roject planning is th en com pleted. In th e m ean tim e, th e project 1 m anager can also discover incom plete or red u n d an t p a rts of th e plan, such as 69 a specification w hich is not followed by a design activity, or a test p lan th a t is n o t used by any testing activity. I te r a tio n a n d A u to m a tic A c t iv ity T rig g erin g D ue to th e n atu re of a design project, th e sam e2 activ ity m ay be executed m ultiple tim es depending on various conditions. To avoid destroying th e project history, different token occurrences of th e sam e activity should be created w hen ever it is executed. T he firing of a sta rt tra n sitio n of an activ ity perform s the in stan tia tio n operation. Since th e activity only acts as a tem p late, every tim e its preconditions are m et, th e sta rt tra n sitio n will be fired an d create an in stance of th e token in th e activity place and store the relevant inform ation w ith th is token. D uring th e execution of a p ro ject, th e current p roject sta te is affected only w hen any token value is changed. T h e project progress can be considered as a to k en driven process. U nlike th e P e tri net which is a closed system , a DesignN et is an open system . All th e statu s rep o rt places and certain p ro d u ct subtype places (e.g. custom er co n tract, change request, an d th e bug rep o rt) accept externally supplied tokens. Responsible staff will subm it to th e system the tokens th a t reflect events in th e process. T he system will react according to the D esignN et definition. 2Here the ’sam e’ activity means the planned activity which may be executed at different times. Chronologically, two activities executed at different tim es cannot be the same even though they perform the sam e job. 70 T o k en I n s ta n tia tio n an d H isto r y R e c o r d in g To autom atically accom plish th e project history recording, th e tra n sitio n j firing does a token in sta n tia tio n o p eratio n on all its o u tp u t places. Originally, th e places representing th e plan only contain tim e an d execution independent inform ation. For exam ple, an activity requires som e resources to be involved in. ■ O nly resource types (e.g. program m er or system analyst) are given in resource places to designate th a t certain staff skills are needed for this activity. W hen th e tra n sitio n before this activity gets fired, a new token is created in this activ ity w ith tim e and execution dependent inform ation (e.g. activity sta rts a t 0 5 /0 1 /8 8 and program m er Tom is assigned to th is task ). T his inform ation im plicitly carry th e project execution history. Let us use th e p lo tte r driver design exam ple again to show how this m ech anism works. Suppose we have th e facts th a t: 1. graphic com m and specification (in file G raph, sp ec . r e v l ) is generated on Jan . 7, 2. program m er Jo h n is assigned to this design job on Jan . 10. T h e first fact does not in sta n tia te th e design activity because th e o th er token is not tru e . W hen th e program m er requirem ent token is set to tru e , th e sta rt tran sitio n of plotter„driver_design will create th e following instance, plotter_driver.design instance.index: 1 start.on: 01/10/88 initiated with: programmer: John, 01/10/88 spec: Graph.spec.revl, 01/07/88 71 If th e activ ity is com pleted on Jan . 16 w ith a program P l o t.drv.verl, th en th e following entries are attach ed to th e previous instance end_on: 1/16/88 finished with: ! code module: Plot.drv.verl, 1/16/88 ! * Suppose a la te r testin g activity (activ ity I.D . d r i v e r _ t e s t : l ) shows th a t the driver does not w ork properly, an d we have fu rth er facts: 1. som e bugs are found in testin g of th e driver on Jan . 18, 2. program m er Jo h n is assigned to this task again on Jan . 19, 3. th e driver redesign is finished on Jan . 23 w ith driver program Plot.drv.ver2. A n o th er instance w ould b e created w ith following description plotter_driver_design instance_index: 2 start_on: 1/19/88 end_on: 1/23/88 initiated with: programmer: John, 1/19/88 test_fail: driver_test:1, 1/18/88 finished with: code module: Plot.drv.ver2, 1/23/88 O ne m o n th later, some new graphic com m ands are desired an d specification is m odified: 72 1. new graphic com m and specification (in file G raph, s p e c .r e v 2 ) is gener ated on Feb. 10, i 2. program m er Tom is assigned to the job this tim e on Feb. 12, 3. it is finished on Feb. 18 with driver program Plot .drv. ver3. W e have th e following new in stan ce of th e activity plotter_driver_design instance_index: 3 start_on: 2/12/88 end_on: 2/18/88 initiated with: programmer: Tom, 2/12/88 spec: Graph.spec.rev2, 2/10/88 finished with: code module: Plot.drv.ver3, 2/18/88 T his in sta n tia tio n process m aintains historical progress of a p roject w ithout overw riting th e original project plan. W ith all of th is stru ctu red d a ta , higher level m anagem ent functions can be built. T r a c e a b ility Effective m anagem ent of num erous project inform ation is a crucial facto r to th e success of a softw are p ro ject. T he inform ation includes activities executed, resources consum ed, reports issued, docum ents generated, plus th e relationships betw een these entities and linkages across phases. F urtherm ore, unpredictable backtracking m akes it m ore difficult to m ain tain these relationships. D esignN et provides an au to m atic inform ation tracking m echanism . W ith th e p roject in form ation being recorded autom atically, th e p roject m anager can issue queries against th e project d atab ase to analyze and reason ab o u t th e p ro je ct’s pro- : gression, especially ab o u t those d a ta th a t are d istrib u ted in several phases. For instance, to know w hat code m odules are affected w ith respect to a specification change, we can sta rt from th e token associated w ith th a t change, trace th ro u g h all th e design, im plem entation and testing activities triggered, an d th en locate th e resulting m odules. By tracing th ro u g h th e tokens and links, we can derive th e answ er to several m anagerial type questions. For exam ple, w hat activities have caused th e m ajor delay or cost overrun? If an activ ity has been executed often, who has been responsible for it? If we change the requirem ent for th e p lo tter o u tp u t, how m uch m ore tim e and resource will be needed to com plete th e job? W h at o th er activities are delayed? If th e project shows some delay, is it possible to m ake up th e delay by introducing ex tra resources? If yes, add to w hat activities? W hen personnel turnover occurs, can we find th e staff who w ere involved w ith an activity executed tw o m onths ago? C om plete historical d a ta is th e basis for th e satisfaction of an au d it. De signN et also provides th e version developm ent traceab ility at a coarse level of granularity. Tokens in th e sam e place denote different occurrences of th a t place. T im e dependent properties stored w ith each token provide flexibility for build ing finer level version control. For exam ple, a version index is stored w ith th e token of a code pro d u ct place. We can incorporate any source code version control system (e.g. SCCS[Rochkind 75]) an d use th e version index to locate th e version generated at a specific tim e. 74 P o in ts o f C la rific a tio n I • T he m odel is intentionally designed to be passive, in th e sense th a t it per m its th e collection of d a ta and it can rep o rt th e com plete history of th e p ro ject, b u t it does not try to reallocate resources o r even to determ ine w hen an activity has been successful or not. All of these la tte r issues are determ ined by th e project m anager or m anagers. W e don’t believe th a t at th is tim e we know enough about building tools th a t autom atically de term ine th e allocation of resources or th e definition of activities to satisfy a p roject. • One should not view D esignN et as an extension of P e tri N et, because th ere are m ajo r differences. In p articu lar D esignN et is an O P E N system , an d some tokens for certain places are assum ed to b e provided by project personnel. A nother m ajo r difference is th a t D esignN et is determ inistic because one needs in a softw are project to determ ine w hether an activity succeeded or needs backtracking to previous activities. • To represent th e wbs, th e choice was m ade to use A N D /O R n o tatio n as opposed to tra n sitio n diagram s. T he m ajo r reason is because w hen a lower level place produces a new token, (i.e. th e sta te of th e p roject has been changed), th en th a t token m ust im m ediately be p ro p ag ated up th e wbs. T h e tra n sitio n diagram n o tatio n does n o t fire u n til all dependent nodes are ready. T he m ore accurate rep resen tatio n of th e life cycle is th ro u g h th e use of A N D /O R nodes. • O ne m ust be careful ab o u t in terp retin g th e AND an d O R nodes in a D esignN et. W hen an O R node is used to connect several subactivities to an activity, th en it m eans th a t w hen only one of those subactivities is done, th en th e p aren t activ ity is p artially done. For exam ple using F igure 3.7, 75 w hen th e X -W indow s activity is done, and all its p aren t activities to th e root of th e wbs, th en even th o u g h th e wbs is not com pleted, it is partially com pleted and th e version of th e softw are th a t supports X -W indow s can b e shipped. In fact, it m ay be th e case th a t th e ro o t node of th e wbs never reaches a sta te of com pletion, b u t is always p artially com plete and softw are is being shipped, b u t not all activities are finished executing. • A nother point is th a t th e wbs does not necessarily reflect th e stru ctu re of th e code. It m erely describes th e way in which th e activities are divided an d th e way in w hich p ro d u cts are decom posed. • No plan can ever cover all of th e possibilities. For exam ple, suppose som eone quits in th e m iddle of an activity. How does D esignN et handle th is? T he m anager w ould go in to D esignN et an d add a S tatu s R eport Node to th e activity th a t has been ab o rted . He th en rep o rts w hat has occurred and adds in a tran sitio n to an activity th a t is to b e followed a t th is p oint. T h a t activity m ay be to assign a new resource and re s ta rt th e previous activity again, or he m ay decide not to re tu rn to this ab o rted activity. T hus th e project p lan can still be u p d a te d to cover th e u n an ticip ated case. • D esignN et does not explicitly handle resource allocation. In general peo ple are w orking on m ultiple projects at th e sam e tim e. T he problem of optim al allocation is com putationally intensive, an d th e factors th a t m ust be used to determ ine allocation are com plex and n o t describable by a netw ork m odel such as D esignN et. T herefore we assum e th a t project personnel assign resources to activities. • T hough th e exam ple in this p ap er shows th e w aterfall m odel, it is equally easy to in corporate o th er life cycle developm ent m odels in to D esignN et. 76 • C onsider th e situ atio n when driver testin g uncovers bugs and driver design is restarted . D river design com pletes and th e driver is being recoded, w hen a change in specification causes driver design to be re-started . How does D esignN et detect th e case th a t m ore th a n one of th e sam e activity is concurrently active, an d how does it resolve th is anom aly? D etection in D esignN et is straightforw ard, as one can trace from an active node to th e finished p ro d u ct to see if o th er active nodes exist. However, th e m odel assum es th a t p ro ject personnel will decide w hether to a b o rt one of the activities, or to continue w ith b o th of them . 3 .4 A n a ly sis o f D e s ig n N e ts A nother application of th e D esignNet is to tak e th e graphical rep resen ta tio n of a p ro ject, and analyze it for th e presence of desirable or undesirable properties. W ith th e properties derived from a D esignN et, we can derive the p roperties of th e project which th e net m odels. A p roject m anager can use these analysis techniques to help him detect any problem concerning project planning or execution. This section defines several in terestin g properties of th e D esignN et. T h e algorithm s to verify th e existence of these p roperties and th eir com plexity are also presented. Before we define and analyze any pro p erty of a D esignN et, som e assum ptions have to be m ade in order to m easure the com plexity of th e algorithm s. Since pro jects m ay have a rb itrary level of decom position an d arb itra ry num ber of activities depending on th eir scales, these assum ptions help us to establish a m easurem ent basis. We assum e n x m axim um num ber of decom positions a place can have. I x m axim um num ber of levels a p ro je ct’s wbs can have. 77 N : num ber of places in a p ro je c t’s wbs < — 1 -f n + n 2 + . . . + n i_1 = E 'iZ l nc— 1 n— 1 T h e num ber of places a project can have is th en bounded by 0(n*). D e fin itio n 3.1 A DesignNet is c o n n e c te d if and only if for all the places p , there exists a path from p to the root place R through structural operators and the arcs I a, I a, Oa, Oa. T his p ro p erty defines p roject plan connectivity. For a large project w ith hundreds of activities, th e planning is usually conducted by several task super visors concurrently and each one builds only a p a rtia l wbs of th e whole plan. T h e overall wbs is constructed by applying searching operators to all places and th e places w ith th e sam e nam e are m erged w ith a single place. All incom ing an d outgoing arcs to these duplicate places are linked to th e new m erged place. If th e wbs is fully p lan connected, th ere will be no disjointed elem ents. This p ro p erty insures th a t, after in teg ratio n , all activities co n trib u te tow ard th e ac com plishm ent of th e project an d no irrelevant activity or pro d u ct is created. To verify th a t th e D esignN et of a project is connected, apply th e following algorithm to th e net. A lg o r ith m 3.1 1. for each place pi, i = 1, 2 , . . . , n d o 2. i f Pi has no outgoing structural arc and pi is not the root th e n stop and the net is not connected. e lse for each outgoing structural arc aout of pi £ I a or I Q , do 78 Figure 3.8: Legal stru c tu ra l connection types. 3. i f is directed, to some structural operator s and there exists an arc ain G Oa or O0 from s to another place pj t h e n continue else stop and the net is not connected. Graphically* this algorithm checks th e existence of any connection other th a n th e legal connection types shown in figure 3.8. Since every place is visited only once, th e tim e required is O(N). T he space used by this algorithm only needs a few tem p o rary variables, th u s th e space com plexity is of 0 (1 ). D e f in itio n 3 .2 A project is p la n c o m p le te if and only if its asso ciated DesignNet is connected and for all intermediate product places pp, there exists a transition ts in Ts such that t a takes pi as input and there exists a path from t a to some final deliverable product places. S tated in term s of g raph theory, th is p ro p erty requires th a t th e transitive closure of each in term ed iate pro d u ct place contains at least one final deliver able p ro d u ct place. D uring th e softw are developm ent process,.m any types of docum ents are generated. Some of th em are final deliverable p ro d u cts, such as release notes, executable code, and operational m anual. O thers are ju st for in tern al use, such as system requirem ent, interface design specification, control design specification, and test plan. W e consider th e p ro d u cts th a t are tak en as in p u t to some activ ity in successive phases as in term ed iate pro d u cts. If no activ ity takes an in term ed iate product as in p u t for fu rth e r processing, p a rt of th e desired functions will n o t be im plem ented and th e final developed system j will be incom plete. T his p ro p erty assures th e robustness of a plan. To check plan completeness of a p roject, apply th e following procedure for each final I deliverable p ro d u ct place. A lg o r ith m 3.2 1. fo r each final deliverable product place pp E Ppfinal d o 2. mark pp as visited, 3. find the activity place pa that generates this product, 4 . if pa has any precedent product place t h e n recursively apply step 2, 3 and 4 above to all precedent product places of pa e lse break. 5. Upon completion, if there still exists any unmarked product place, the associated project is plan incomplete. T his algorithm visits every place once, th e tim e required is still O(N). How ever, since it uses recursive checking, th e space required is also of 0 ( N ) which is larger th a n th e algorithm in verifying plan connectedness. D e f in itio n 3 .3 A project is p la n c o n s is te n t if and only if it is plan complete and for each activity place p a, the level (distance to the root place) o f this place is the same as the levels o f its preceding and succeeding activity places. A rigid hierarchical decom position requires th a t at any level in th e hierar chy, each subdivision m ust be consistent w ith o th er corresponding phases. For 80 exam ple, if th ere are three subtasks defined u n d er th e specification phase, th e design phase has to be decom posed in to th ree subtasks and each subtask p e r form s its specific system design function in correspondence to th e subtasks of th e previous phase. If one of th e specification subtasks is fu rth er decom posed in to several subactivities, th e associated design subtask m ust also be decom posed in to th e sam e num ber of subactivities to cover all aspects at th e sam e level of detail. To check th e plan consistency of a p ro ject, tw o passes are required in traversing th e wbs as described in th e following algorithm . A lg o r ith m 3 .3 1. compute the depth of each place, 2. apply a similar search algorithm used to check plan completeness. This time, when tracing activity dependencies, make sure that the level of each activity along the path is the same. U sing an inorder tree trav ersal algorithm , th e first step takes 0 ( N ) to label th e d ep th of all places [Horowitz 76]. T he second step takes th e sam e num ber of opeartions as th e previous algorithm , so th e tim e required is still 0 ( N ) and th e space required is also of O(N). D e f in itio n 3 .4 A DesignNet is s u c c e s s -e x e c u tio n lo o p fre e if and only if for all the activity places p a, there exists a status place of success type such that both places together enable a transition to form a success execution path and there is no loop that exists along this success execution path. One com m on problem am ong concurrent system s is th e detection of the existance of loops th a t m ay be executed infinitely. R esearchers have shown 81 th a t th ere is no explicit m ethod to distinguish w hether a loop is in a dead sta te or it can still lead to v ital execution. In th e case of a design p roject, th is is slightly different. T he developm ent cycle can rep eat infinitely as long as th e p ro d u ct is continuously being m odified and enhanced. However, one ' type of loops should be prohibited. W henever an activ ity is finished w ith a j i success re p o rt, th e triggered activity m ust be from la te r phases. If it leads to an activity of an earlier phase, it m eans th a t th e p roject plan was not built properly. T his p ro p erty helps th e m anager to prevent planning m istakes. The following algorithm verifies th e existence of any success-execution loop. A lg o r ith m 3 .4 1. define a stack S for storing the activity places that are traversed by current path, 2. fo r each activity place pa with no enabling transition d o 3. i f pa does not have a success report place that together with p a enables a finish-transition t h e n continue, e lse search S for pa 4■ i f pa is already in S t h e n stop and a loop exists, e lse push pa onto S and recursively do steps 3 to 4 for all activities triggered by the finish of pa. G raphically, this algorithm checks th e existence of any loop show n as in figure 3.9. T h e stack search in step 4 takes 0 ( N ) tim e. T h e o u ter loop from step 3 to step 6 th e n takes 0 ( N 2). Since it also uses recursive checking, the space required is also of O(N). 82 success success Figure 3.9: E xistence of a success-execution loop. D e f in itio n 3 .5 A project is w e ll-e x e c u te d if and only if there is at m ost one token in an active state in all places at any time. Several possibilities m ay cause a place to have m ore th a n one token in active sta te . C onsider th e p lo tter driver design exam ple. If th e driver design activity is active and a system analyst decides to ad d in new graphic com m ands, a new design activ ity will be in itiated in response to this change. Even though this kind of late m odification is discouraged by softw are design m ethodology, such situ atio n s do h ap p en regularly in actu al practice. However, if we allow th e sam e activ ity to be executed by different personnel based on different versions of in p u t docum ents a t th e sam e tim e, it will result in generating inconsistent pro d u cts. O ne way to resolve this anom aly is to cancel th e cu rren t active activ ity w hen it needs to be re-executed. M eanw hile, we have to release th e allocated resources, reschedule th e successive activities, and call a staff m eeting if different personnel are assigned to these tw o activities. T ransition firing in D esignN et changes a token from active state to discarded sta te w hen it creates a new token of th e sam e place. T his m echanism enforces a p ro je c t’s w ell-executed property. Since th e user can a tta c h executable procedures to a tra n sitio n in a D esignN et, th e resource release, rescheduling, and staff synchronization can be fulfilled by these procedures. 83 Chapter 4 | i ! ■ Object Database Support for the DesignNet M odel T h e softw are developm ent process involves num erous types of inform ation an d enorm ous am ounts of d a ta . T hese d a ta item s can be m ain tain ed in various form ats an d m edia. Source program s follow strictly th eir languages’ syntax, ob ject code and binary executables are m achine dependent b u t can be stored in system s o th er th a n th e targ et m achines, docum ents are in te x tu a l or ty p esettin g fo rm at, an d com m unication betw een project personnel are in w ritten m em os or electronic m ail. It is believed th a t in teg rated d atab ase su p p o rt will greatly re duce th e efforts spent in m aintaining this d a ta an d im prove th e overall produc tiv ity for softw are pro d u ct developm ent [E astm an 81, K atz et al. 84, K atz 84, B ernstein 87]. Such an environm ent d atab ase has been identified as th e core of any a u to m ated Softw are Engineering Environm ent (SE E ) an d is vital to th e success of a C om puter-A ided Softw are Engineering tool (C A SE )[Penedo 86, S tenning 87]. In co n trast to th e large volum es of d a ta produced by th e developm ent pro cess, th e relationships am ong these d a ta item s are far m ore com plicated to m ain tain . U sually these relationships are loosely coupled. For instance, w hen a function needs to be changed in th e specification or new features are added in, a caucus m ust be held to determ ine w hat docum ents have to be reviewed, 84 w hat activities m ust be rein itiated , w hat program m odules and m an u al pages will b e affected, who are th e project staff to be involved in these task s, and w hat will be th eir responsibilities. This m anagem ent level inform ation is m ore likely to be held in p ap er form or in people’s m inds and be exchanged orally 1 w ith o u t records. For a project of long d u ratio n , staff turnover is th e norm and effective p ro ject m anagem ent becom es th reaten ed due to th e lack of sufficient inform ation. To overcom e th e deficiencies of trad itio n al m anagem ent tools an d construct an extensible d atab ase core for an in teg rated SEE, th e D esignN et m odel has been derived to support this need[Liu and H orowitz 87]. T h e D esignN et m odel is a hyb rid m odel for describing and m onitoring th e softw are developm ent pro cess. T h e aim of this m odel is to provide th e conceptual basis for a higher level in teg ra te d softw are project m anagem ent environm ent. It utilizes A N D /O R stru c tu ra l operators to describe th e work breakdown structure (wbs) and P etri n et n o tatio n to represent th e dependencies and parallelism am ong activities, resources, an d p ro d u cts. It is an event-driven m odel since th e p ro ject sta te is changed only w hen some events happen (e.g. spec changes, rep o rted bugs, de p a rtu re of personnel). W hen such events are su b m itted to th e m odeled p roject, th e desired reactions will be autom atically triggered according to a predefined p ro ject plan. M eanwhile, th e relationship betw een th e event and th e triggered '* ■ activities will be tracked in th e underlying database. T hus, a com plete project h isto ry log is m aintained w ithout m anual intervention. T his ch ap ter describes th e object-oriented d atab ase su p p o rt for th e Design- N et m odel. O th er im plem entations of engineering design d atabases [Wong 79, S tonebraker 83, Penedo 86] are based on th e relational m odel, although th eir conceptual m odels are either defined w ith ab stract d a ta types, entity-relationship, or object-oriented m ethodology. T he exam ples here an d our p ro to ty p e use On- 85 tologic’s V base p ro d u ct [Ontologic 87, A ndrew s and H arris 87], one of th e first of few object oriented databases available. It describes th e actu al definition an d construction of th e d atab ase layer of th e D esignN et m odel based on an object-oriented developm ent environm ent. T h e ch ap ter begins w ith justification for choosing an object-oriented ap proach versus a record-oriented approach. N ext, th e elem ents of th e D esignN et m odel are described in term s of object types. T he object ty p e hierarchy is also presented. T h e following sections discuss th e techniques used in accom plishing various m anagem ent functions, such as w ork breakdow n stru ctu re represen ta tio n , tim e stam ping m echanism , project history recording, event triggering, an d concurrent activ ity m onitoring. T h e final section presents o u r conclusions regarding th e stren g th s and w eaknesses of an object system for m aintaining softw are p roject m anagem ent inform ation. 4.1 S o ftw a re P r o je c t M a n a g em en t D a ta R e q u ir e m e n ts To choose th e m ost suitable d atab ase approach for supporting software p ro ject m anagem ent, th e d a ta m anagem ent requirem ents m ust be identified first. T his section investigates these issues an d th en , based on th e desired capa bilities, concludes th a t an object oriented d atab ase m odel is m ost ap propriate. T h e project work breakdow n stru ctu re is th e central targ e t for m anagem ent. A large, com plex system cannot be tackled w ithout being decom posed in to sev eral m ajo r task s. D epending on its com plexity, each m ajo r task can b e fu rth er decom posed in to th e next level subtasks. T his decom position m ay extend sev eral levels below . A ny task in th e hierarchy is an aggregate en tity of its next level co n stitu en ts. A ggregate inform ation of a task can be collected recursively from th e subhierarchy rooted at this task(e.g. th e m an hours sp en t, th e cost, 86 an d th e d u ratio n of a task ). T his hierarchical stru ctu re does not exist only for th e activities executed, b u t also for the staff involved, docum ents generated, an d rep o rts issued. T hus, representation of hierarchical d a ta and aggregate l entities is essential. I I I T h e hierarchical n atu re of the whs also introduces th e concept of level of ; data abstraction. For exam ple, suppose th a t we uniform ly tre a t all th e d a ta i elem ents g enerated in th e developm ent process as product. T hen, we can cat egorize th em in to several specific types such as requirem ents docum ent, func tio n al specification, m odule design description, test plan, program m odule, and in stru ctio n m anual. Each type m ay need m ore classification(e.g. th e m od ule design description contains b o th th e m odule interface description an d th e control flow description). T he resu ltan t stru ctu re is th e object type hierarchy w here lower level subtypes can share and inherit com m on properties of th eir supertypes. T his generalization/specification, aggregation, an d classification ab straction[S m ith 77, M ylopoulos 80] has been used for a long tim e to repre sent know ledge in artificial intelligence. Em ploying such a knowledge represen ta tio n schem e not only helps us in organizing th e d ata, b u t also lets us enforce in teg rity co nstraints on different object type levels. In a design environm ent, d a ta entities can incur a long period of evolution. W hile one version of th e product is in operation, bug fixes, new ly added fea tu res, plus new configurations m ay spaw n several divergent pro d u cts. Different versions of program s an d docum ents m ust be sustained so th a t later exam ina tio n and com parison are possible. O n the m anagem ent level, in order to reason ab o u t th e progress of activities, m aintaining th e entire p ro je ct’s chronological records is inevitable. T he project m anager should be able to look back at any p o in t in tim e and see w hat sta te th e project was in. K eeping a single sta te of a d a ta object is not sufficient. Versioning, historical recording, and alternatives 87 m ust b e handled properly by th e supporting database. C urrent project m anagem ent tools are centralized m anagem ent tools in th e I sense th a t all p roject sta tu s changes are collected to g eth er and u p d a te d into ; th e system by a single authority. For a large project w ith hundreds of activi- | ties, such m anagem ent m ethodology dem ands su b stan tial m anual efforts. T he I D esignN et m odel defines a triggering m echanism to au to m ate th e activ ity in iti atio n , replanning, and rescheduling w hen activities have to be redefined a n d /o r re-in itiated . P ro ject personnel rep o rt th e events directly to th e system . T he system will trigger actions depending upon these events. For exam ple, a speci fication change requires th e design activity to be rein itiated or th e com pletion of im plem enting a pro g ram m odule in itiates th e testin g activ ity of th is m od ule. T hus, th e d atab ase needs to m odel th e behaviors as well as th e possible in teractio n am ong objects. H aving looked at th e related issues, th e decision is ap p aren t. A n ideal d atab ase m odel for th is purpose should have th e following capabilities: the pow er to m odel hierarchical d a ta and aggregate objects, th e distinction be tw een d a ta ty p e and instance, th e inheritance of properties an d operations dow n th e wbs hierarchy, th e ability to handle design evolution including ver sion an d altern ativ e control, an d a procedure triggering m echanism . C u rren t record-oriented d atab ase m odels such as th e hierarchical, netw ork, an d rela tio n al d atab ase m odels have deficiencies in supporting all th e above notions an d m echanism s. T he recent developm ent of object-oriented d atab ase m odels, w hich com bine th e pow er of object program m ing an d th e efficient m anagem ent of d a ta , provides a feasible solution for th e issues described above. 88 4 .2 T h e D e s ig n N e t M o d e l in T erm s o f O b je c ts U tilizing an object-oriented d atab ase to design an application system is a tw o-stage task. T h e object ty p e hierarchy design comes first and th e application program design comes n e x t.1 However, these two stages are coupled together closely since th e operations and procedures th a t m an ip u late objects m ust also b e included in th e ty p e definitions. T he ty p e hierarchy is analogous to th e conceptual schem a of conventional database system s except th a t ty p e defini tio n contains m ore behavior description for each object ty p e such as m ethods, operations, exceptions th a t can be raised, and triggers for in teg rity enforce m en t. To th e application system , only th e nam e of th e object and th e functions th a t can m anipulate th e object are known. T his data abstraction concept is a m eans of im plem enting inform ation hiding and is a pow erful feature in object program m ing. U nder th e current p ro to ty p e im plem entation, all com ponents in D esignN et are represented as objects in th e d atabase. Several subtypes are defined under each com ponent. Figure 4.1 shows th e object ty p e hierarchy. T h e hierarchy de scribes th e ty p e stru ctu re of all objects included in D esignN et. O n th e leftm ost p a rt of th e hierarchy are th ree object types for tim e object rep resen tatio n and m anipulation. T he execution tran sitio n ty p e has tw o subtypes, th e planned tra n sitio n and th e fired tran sitio n . The stru ctu ral o p erato r is an enum erative object an d has th ree alternatives. T he planned place an d th e token are th e m ajo r object types th a t encapsulate project inform ation. P lace is a supertype of th e planned place and th e token. B oth types are fu rth er decom posed into five subtypes for m ore specific inform ation types. T he to k en state is also an enum erative object th a t corresponds to th e possible token states: th e active, xThe current release of Vbase does not support run-time type definition update. Any type definition change must be done on the first stage. 89 Structural Operator Transition Time Place 1 i Fired Transition Temporal Relation. Planned Place Token O r Operator Planned Transition Time Scale Project Token Project Token State Activity Token Activity Active Resource Resource .Token Consumed Product Token ■ Product Discarded Status Token Status Report Figure 4.1: O bject type hierarchy of D esignNet th e consum ed, and th e discarded state. Several predefined resource and pro d u ct types are also included. Since th eir definition depends on th e life cycle phases chosen by th e p roject m anager, th eir subtypes are not show n here. 4.3 R e la tio n sh ip s a m o n g O b ject T y p e s In conventional databases, th e inform ation is usually m odeled as records. R elationships am ong d a ta entities are constructed th ro u g h prim itive references to related records. To set up a one-to-m any or m any-to-m any relationship am ong several record types in th e relational m odel, a new record ty p e is in tro duced and th e key fields of associated record types are used to designate records th a t m ake u p th e relationship. In th e netw ork and hierarchical m odel, links are used in connecting occurrences of th e associated records. 90 O bject-oriented databases use different approaches in cap tu rin g relation ships of objects. T hey m ostly allow m ore com plicated relationships. For ex am ple, an association betw een entities m ay itself be considered as an en tity an d fu rth er relationships can be built upon th is entity. D epending on m od els, th e associations are represented in various form s. For instance, th e 3DIS m odel[A fsarm anesh 85] uses a generic mapping object ty p e to relate tw o objects together. All inform ation are kept in th e form of (d o m ain , m apping, ra n g e ) triples. In V base, th ere is no explicit object ty p e for establishing relationships betw een objects. In stead , properties of an object can have highly com plicated constructs an d can be used for this purpose. A p ro p erty can be a prim itive ty p e object(e.g. a num ber or a string), a reference to an o th er object, or an aggregate object in which individual elem ents are references to o th er objects. T h e la te r two cases are usually th e way relationships are m odeled. T h e hierarchy in figure 4.1 only shows th e supertype and subtype relations of objects in a generalization and specialization m anner. In this section, we will define th e relationships am ong objects th a t are necessary for th e Design- N et m odel. Identifying all desired relations is a crucial task in designing any application system th a t utilizes object-oriented d atab ase approach. Figure 4.2 shows th e relationships defined am ong objects types in D esignN et. T h e place, transition, time, an d structural operator types are th e to p level object types. T h eir relationships are shown in figure 4.2.(a). Since th e tim e a place is created in th e project p lan and the tim e a tran sitio n is defined to connect places is im p o rtan t for tracking th e project planning, they b o th have a createtime p ro p erty to denote w hen th ey are created. T he wbs of a project is m aintained by th ree associations. T he decomposetype of a place is initialized to be th e N O N E o p erato r w hich m eans no decom position. W hen a place is decom posed, th e decomposetype specifies either an AND or an O R stru c tu ra l o p erato r. The 91 parent createdme ^ ^ T ra n sitio n ^ ^ decomposetype decomposedinto (a) tntrans,outtrans PlanTran fired FiredTran PlanPlace inplaces,outplaces | instanceof tokens intokens,outtokens ^ ~'£^T oken ' \ —— intrans,outtrans (b) instanceof Structural Operator Token State tarttime,finishtime tokens instanceof Project Token Project tokens instanceof Activity oke Activity umeTHnishtime available tokens instanceof Resource Token Resource Time tokens instanceof generateatime Product Token issuedtime tokens instanceof Report Token Report (C) Figure 4.2: Relationships among object types in DesignNet 92 decomposedinto to g eth er w ith th e parent associations sustain th e one-to-m any decom position relationship. T he decomposedinto is a set object containing all th e places th a t a place is decom posed into. T he parent is an object reference j to a place w here th e current place is decom posed from . I ; As a result of itera tio n in design projects, th e sam e elem ent in a project j p lan m ay have several occurrences(e.g. an activity being executed m ore th a n once, a code m odule having m ultiple versions). T here exists a one-to-m any relationship betw een th e p lan elem ents and th eir actu al execution elem ents. Figure 4.2.(b) shows th e one-to-m any relationship betw een planned places and to k en s(th e fired and instanceof p ro p erty ) as well as th e one-to-m any relation ship betw een p lanned transitions and fired tra n sitio n s(th e tokens an d instanceof p ro p erty ). T h e connection am ong tran sitio n s and places encapsulates th e dependencies betw een different project inform ation. T he intrans p ro p erty of a place links to th e tran sitio n s w here it can be triggered from . T he outtrans p ro p erty of a place connects to th e tran sitio n s w here it will enable after an active token is generated. T h e inplaces and outplaces properties of a tra n sitio n connect to its in p u t an d o u tp u t places. All th e above relations are represented th ro u g h set objects since th ey are m any-to-m any m appings. T h e p lanned place object type is fu rth er refined in to five lower level types, nam ely th e p roject, activity, resource, p ro d u ct, and rep o rt types. Accordingly, th e token object type is also refined to five lower level token types. T he original relationships betw een planned places and tokens m ust also be refined to reflect th is subtype specialization. Figure 4.2.(c) shows th e redefined m appings am ong these subtypes. T h e refined token types also have new ly defined relations w ith ■ tim e objects. T he project token and activity token have two associated tim e stam p s, th e starttime and finishtime. The resource token keeps track of th e 93 tim e th a t a resource is available (i.e. th e tim e assigned to an activity). T he p ro d u ct token keeps th e generation tim e an d th e rep o rt token keeps th e issued tim e. 4 .4 T im e N o ta tio n an d S ta m p in g M e ch a n ism O ne crucial elem ent in th e project developm ent cycle is th e recording of all events. T his recording relies heavily on a tim e basis and is necessary for b o th th e planning an d executing phases of a p ro ject. D uring th e p roject planning stage, we m ust p u t dow n th e tim e w hen every piece of th e plan is constructed by th e project m anager and supervisors of tasks. T his helps us to review , evaluate an d m odify th e p roject plan. W hen a project is being executed, an activ ity can be in itiated m ore th a n once an d a docum ent can have several revisions. T he tim e an activity is in itiated and th e tim e a docum ent is created m ust be stored w ith th eir corresponding instances. Therefore, m ost objects in D esignN et have to be associated w ith tim e. Since th e current V base release does not support a tim e object and tim e stam p m echanism , th e first task is to define a generic tim e n o tatio n and th e m an ip u latin g operations. Figure 4.3 shows th e T D L (T ype D efinition Language) definition of th e desired properties an d operations for tim e. For a description of T D L n o tatio n , see th e appendix. T hree o bject ty p es(TemporalRelation, TimeScale, Tim e) and th ree basic operations(5'famp, Comparison, Current) have been defined for th is purpose. T h e tstamp p roperty(line 8) of th e time object contains a tim e value m easured in seconds startin g from th e clock in itiated tim e chosen by th e system (w hich is 00:00:00 G M T , Jan u ary 1, 1970 on our UNIX system ). It keeps a global tim e- of-day reference in th e second level of g ran u larity which is quite enough for m ost 94 1 1 1 Time object and manipulating operations definition 2 define Type TemporalRelation is enum (BEFORE, AFTER, EQUAL); I 3 define Type TimeScale is enum (MINUTE,HOUR,DATE,MONTH,YEAR); 1 4 define Type Time 5 supertype = {Entity}; ! 6 properties = T { 8 tstamp: Integer; 9 minute: Integer; 10 hour: Integer; 11 date: Integer; 12 month: Integer; 13 year: Integer; 14 >; 15 operations = 16 { 17 Stamp (type : Type, 18 keywords 19 minute: Integer, 20 hour: Integer, 21 date: Integer, 22 month: Integer, 23 year: Integer) 24 raises (StampOverflow) 25 returns (Time) 26 method (TimeStamp); 27 28 Comparison (tl:Time,t2:Time,granularity 29 returns (TemporalRelation) 30 method (CompareTime); 31 >; 32 define procedure Current() 33 returns (Time) 34 raises (SystemTimeFailure) 35 method (CurrentTime) 36 end Current; 37 end Time; Figure 4.3: Time object type and operation definition 95 1 #include <time.h> 2 enter module $Time; 3 4 method obj $Time CurrentTime() 5 - C 6 struct tm *time; 7 long tstamp; 8 Q obj $Time currentTime; 10 tstamp = time ((long *) 0); 11 time = localtime (fttstamp); 12 currentTime = $Time$[stamp: tstamp, 13 minute: t ime->tm_min, 14 hour: time->tm_hour, 15 date: t ime- > t m_mday, 16 month: time->tm_mon, 17 year: time->tm_year]; 18 return (currentTime); 19 > Figure 4.4: C O P program segm ent for current tim e operation applications. T h e calendar values of year, m onth, d ate, hour, and m inute(lines 9-13) are also stored w ithin th e tim e object. P resum ably these values can always be com puted from th e global clock tstamp reference. However, current V base does n o t support v irtu al p ro p erty fields and th ere is also a tradeoff betw een space and tim e. If all calendar fields are com puted w henever th ey are accessed, com putation overhead can degrade th e system perform ance. Figure 4.4 shows a C O P (C O bject Processor) language im plem entation of th e Current o p eration w hich is im plem ented by th e m eth o d CurrentTime. For a description of C O P n o tatio n , see th e appendix. It retrieves th e current global tim e in seconds(line 10), tran slates it in to calendar form at(line 11), creates a tim e object w ith th e associated tim e values(lines 12-17) an d retu rn s it. This operation can be atta ch ed to an o b je c t’s tim e p ro p erty as an im’ t(initialization) 96 op eratio n such th a t w henever an instance of th a t object is created, it will be auto m atically tim e stam ped. For instance, suppose a docum ent object has a timecreated p ro p erty to denote th e tim e w hen its instances have been created. T h e following definition will cause a tim e stam p to be tra n sp aren tly a ttach ed to th e docum ent: define Type Document properties = - c timecreated: $Time define init method(CurrentTime); > O n th e o th er h an d , th e Stamp operation(lines 17-26 in Fig. 4.3) perm its an a rb itrary tim e setting given th e calendar tim e. It is used for th e tim e setting on a value o th er th a n th e current tim e(e.g. an activity is expected to finish on Jan . 10, 1988). T he Comparison operation(lines 28-30) takes tw o tim e objects an d com pares th em on th e given tim e granularity. T he gran u larity p aram eter allows one to com pare th e tim e on th e desired tim e scale. For exam ple, we can ask if two activities sta rt on th e sam e m o n th (a large granularity) or if one code m odule is generated earlier th a n th e o th er(a sm all g ran u larity ). T his operation retu rn s th ree possible tem p o ral relations(line 2) — before, after, or equal. T h e above definitions m erely provide prim itive m anipulation functions. H igher level functions can be built upon these operations w ithout difficulty. O ne m ajo r extension is the com parison of two tim e durations an d th eir tem poral relations. W e can determ ine if an activ ity sta rts before or after an o th er activity. O r we can ascertain if tw o activities overlap, m eet, or contain each other. We can also decide if tw o activities have th e sam e sta rt d ate, end d ate, or duration. K eeping a com plete historical record is th e basis for th e satisfaction of p ro ject auditing. This record should m ain tain a wide range of inform ation. W ith th e tim e stam p m echanism , D esignN et provides th e version developm ent traceab ility at a coarse level of granularity. Since tokens in th e sam e place de note different occurrences of th a t place, tim e dependent properties stored w ith each token provide flexibility for building finer level version control. For exam ple, a version index is stored w ith th e token of a code p ro d u ct place. W e can incorporate any source code version control system (e.g. SCCS) an d use the version index to lo cate th e version generated at a specific tim e. 4 .5 W ork B rea k d o w n S tru ctu re R e p r e se n ta tio n For a com plex p ro ject, th e whs m ay extend m any levels deep in th e hierarchy. M ost existing p ro ject m anagem ent tools [SuperProject 86, M icrosoft] use an artificial coding m ethod for distinguishing different level entities (e.g. an eight digit code for a m axim um of eight-level hierarchy). T his m echanism can be im plem ented easily under relational databases. N evertheless, users can only select certain code com binations th a t group th e required entities together for rep o rt generation purposes. N either th e au to m atic aggregate d a ta collection n o r th e u nlim ited level representation is considered. U nder th e object-oriented schem e, th e capabilities of defining aggregate objects and procedure attach m en t afford a b e tte r solution. In D esignN et, th e wbs is represented th ro u g h stru ctu ral operators and links. A stru c tu ra l o p erato r connects places of th e sam e ty p e w here its o u tp u t arc p oints to a single place for th e node to be decom posed and its in p u t arcs come from nodes denoting th e constituents. It is always a one-to-m any m apping from a place to its decom posed places. O n th e object ty p e definition, since a 98 1 ' / Structural Operator definition 2 define Type SOperator is enum (None, And, Or); 3 define Type Place 4 supertype = {Entity}; 5 properties = 6 { 7 8 decomposetype: SOperator := None; 9 parent: optional Place; 10 decomposedinto: optional distributed Set[Place] 11 inverse $Place$parent; 12 13 }; Figure 4.5: S tru ctu ral o p erato r and wbs link definition stru c tu ra l o p erato r m erely carries th e logical one-to-m any decom position and no p ro p erty is associated w ith it, defining it as an enum erative literal object is sufficient. T he fink th en can be defined as a p ro p erty of th e place object. W ith no e x tra level of stru c tu ra l o p erato r object being created, we can save half th e object accessing tim e during th e wbs traversal. Figure 4.5 shows th e T D L definition of th e stru ctu ral o p erato r object and th e links used to construct th e wbs. T he stru ctu ral o p erato r is defined as an enum erative object w ith th ree literal values(line 2). T he place object contains th ree p ro p erties for wbs links. W hen a place is originally created, it is n o t de com posed and its default stru ctu ral decom posetype is null(line 8). If a place has been decom posed in to lower level places, th e o p erato r ty p e is defined and saved in th e decom posetype property. All co n stitu en ts of th is place are stored as a set in th e d eco m p o sed in to pro p erty (lines 10, 11). T he p a r e n t prop- erty(line 9) is a reference to its p aren t place w here this place is decom posed from . If th is p ro p erty has a null value, th en this place is th e ro o t of a wbs hierarchy. T h e d eco m p o sed in to pro p erty provides a top-dow n traversal link while th e p a r e n t p ro p erty provides a b o tto m -u p traversal link. M aintaining a two-way link allows efficient access in either direction. T he in v e r s e clause in th e d eco m p o sed in to p ro p erty guarantees th a t w henever a child place is added in to th is set, th e p a r e n t p ro p erty will also b e u p d ated . It enforces th e integrity betw een th e double links. For those properties th a t m ust be aggregated from lower level places, a m eth o d is defined for th e p ro p e rty ’s get operation. T his m ethod checks if th e place has been decom posed in to lower level places. If yes, it will recursively retrieve an individual co n stitu en t’s value and perform th e desired aggregate function to yield th e final p ro p erty value. Figure 4.6 shows one such exam ple, th e com p u tatio n of an a ctiv ity ’s cost. P a rt (a) shows th a t th e m eth o d ActCost is attach ed to th e cost p ro p erty ’s get operation(line 7). P a rt (b) is th e C O P code for th is operation. If an activity is not on th e b o tto m level(i.e. a task), its cost is a sum m ation of th e cost from its A N D ’ed children activities (lines 12- 16) or th e m axim um cost am ong all its O R ’ed children activities(lines 17-22). A ttaching a retrieving m eth o d to an aggregate p ro p erty ensures th a t th e d a ta is always collected from th e current state of th e d atab ase. A n altern ativ e way to achieve th e d a ta integrity is to atta c h a m odification m ethod(i.e. th e set operation) such th a t w hen th e p ro p erty value is u p d ated , th e m ethod invokes higher level en tities’ com putation m ethod recursively and propagate th e change upw ard to th e topm ost level entity. 4 .6 E v en t M o n ito rin g an d P r o je c t H isto r y R ec o rd in g D ue to th e n a tu re of a design project, th e sam e activity m ay be executed m ultiple tim es depending on various conditions. To avoid destroying th e project history, different instances of th e sam e activity m ust b e created w henever it is 100 I 1 define Type Activity i 2 supertype = {Place}; • 3 properties = ' 4 { 1 5 ♦ • • 6 cost: $Real 7 define get meth.od(ActCost) ; 8 . . . 9 }; (a) Activity object type definition 1 enter module $Place; 2 enter module $Activity; 3 method obj Real ActCost(act) 4 obj $Activity act; 5 { 6 obj $Real total; 7 obj ^Activity curAct; 8 9 total = 0; 10 if (act.decomposetype == $S0perator$Hone) 11 total = act.cost; 12 else if (act.decomposetype == $SOperator$And) 13 { 14 iterate (curAct = act.decomposedinto) 15 total += curAct.cost; 16 } 17 else if (act.decomposetype == $S0perator$0r) 18 { 19 iterate (curAct = act.decomposedinto) 20 if (curAct.cost > total) 21 total = curAct.cost; 22 } 23 return (total); 24 } (b) Activity cost computation method Figure 4.6: A ctivity cost com putation m ethod 101 rein itiated . T his process can be au to m ated since th e project sta te is changed only w hen new tokens have been created or existing tokens’ values have been u p d a te d (b o th cases indicate th e occurrence of an event). This section describes w hat object types and th eir properties have been defined to accom plish this event-driven m anagem ent m ethodology. Initially, th e p roject m anager only defines th e dependencies am ong activi ties, resources, an d products th ro u g h th e tran sitio n connections in th e p roject plan. A n in sta n tia tio n m echanism has been defined in D esignN et such th a t a new ly occurred event will always trigger its associated tra n sitio n during th e p ro ject execution period. This tran sitio n checks w hether all its in p u t places have active tokens. If so, it fires itself by creating a fired tra n sitio n instance of itself, one token for each of its o u tp u t places, and connections am ong th e in p u t an d o u tp u t tokens. All these Operations are handled autom atically by th e system . To distinguish betw een th e project plan and actu al in itiated instances, b o th th e tra n sitio n and th e place object have tw o subtypes defined u nder them . , Figure 4.7 shows th e tw o subtype definitions of th e execution tra n sitio n — th e planned tra n sitio n subtype P lan T ran (lin es 1-23) an d th e fired tra n sitio n subtype F ire d T ra n (lin e s 25-42). A one-to-m any m apping exists betw een th e planned tran sitio n and th e fired tran sitio n since a planned tran sitio n can be fired m ore th a n once. T his m apping is im plem ented w ith a set p ro p erty f ire d (lin e s 6, 7) in th e planned tran sitio n an d a single value p ro p erty in s ta n c e o f (line 30) in th e fired tran sitio n . T h e f i r e d p ro p erty contains all fired instances associated w ith this planned tra n sition. T he in s ta n c e o f p ro p erty is a backw ard link to its planned tran sitio n . A gain, th e in v e r s e clause guarantees th e in teg rity of this double linked m ap ping. T he separation of one representative object en tity (e.g. th e planned 102 1 ' / . Planned Transition definition 2 define Type PlanTran j 3 snpertypes = {Transition}; | 4 properties = i 5 { fired: optional distributed Set[FiredTran] j 6 inverse $FiredTran$instanceof; 7 inplaces: optional distributed Set[Place] 8 inverse $PlanPlace$outtrans; 9 outplaces: optional Set [Place] 10 inverse $PlanPlace$intrans; 11 }; 12 operations = 13 { Fire (type: Type, keywords transition: PlanTran) 14 raises (UotEnabled) 15 method (TranFiring); 16 17 EnabledCheck (type: Type, keywords intoken: Token) 18 raises (Enable) 19 method (CheckTranEnable); 20 }; 21 end PlanTran; 22 23 ' / , Fired Transition definition 24 define Type FiredTran 25 supertypes = {Transition}; 26 properties = 27 { instanceof: PlanTran; 28 intokens: optional Set[Token]; 29 inverse $Token$outtran; 30 outtokens: optional Set [Token]; 31 inverse $Token$intran; 32 }; 33 operations - 34 { refines Create (ft: FiredTran) 35 triggers (ConsumelnTokens) 36 triggers (DiscardOutTokens); 37 }; 38 end FiredTran; Figure 4.7: Transition subtypes definition 103 tran sitio n ) an d its actu al m em bers(e.g. th e fired tran sitio n ) into tw o subtypes provides us a work around approach in the system s th a t do n o t su p p o rt ru n tim e object ty p e creation. O n th e o th er h an d , th is distinction requires th a t all subtypes u nder these tw o subtypes be separated as well. In D esignN et, a place can denote five different inform ation entities. U nder this separation, tw o p ar allel subtypes are defined for each inform ation ty p e and a to ta l of te n subtypes result. Since a tra n sitio n can be enabled by conjunctive conditions an d can trigger m ore th a n one event after its firing, th e tra n sitio n and place have a m any-to- m any relationship. B oth th e planned tra n sitio n and th e fired tran sitio n have m ultiple links to th eir in p u ts and o u tp u ts. For a planned tran sitio n , th e in p u ts an d o u tp u ts are planned places(lines 8-11). For a fired tran sitio n , th e in p u ts are tokens th a t enable this tran sitio n and th e o u tp u ts are tokens created after its firing(lines 31-34). Tw o operations are defined w ith planned tran sitio n . T he E nabledC heck op- eration(lines 19-21) checks to see if all th e in p u t places of th e tra n sitio n have ac tive tokens. If yes, an Enable exception is raised. T his op eratio n is invoked when any of its in p u t places has a newly created token. T he F i r e operation(lines 15- 17) will fire th e planned tran sitio n by creating a new fired tran sitio n instance an d perform th e token bindings. T he fired tran sitio n has tw o trigger functions a tta c h e d to its create operation(lines 39, 40). One function(C onsum elnTokens) changes all th e active in p u t tokens to consum ed sta te to prevent th e sam e tra n sition being fired once m ore. T he o ther fu n ctio n (D iscard O u tT o k en s) checks to see if o u tp u t places already have active tokens, an d if so, p u ts th em into discarded sta te . T his trigger guarantees th a t only one token can be in an active sta te a t a tim e. Such a situ atio n happens w hen one activity is ongoing an d new changes from earlier phases require rein itiatio n of th is activity. H aving m ore 104 th a n one active token in th e sam e activity m eans th a t red u n d an t efforts are spent on th e sam e task and m ay result in inconsistent pro d u cts. If any token is already in an active state, th e D iscard O u tT o k en s trigger sends m ail to the t responsible staff notifying th e existence of th e situation. Places are th e en tities containing the prim ary inform ation involved in the p ro ject developm ent cycle. Figure 4.8 shows th e subtypes definition of th e place object. T h e place ty p e also has tw o subtypes, th e P la n P la c e (lin e s 1- 12) for planned place an d th e Token(lines 14-31) for actu al instances generated during execution. A one-to-m any relationships m apping exists betw een th e p lanned place an d th e token since a planned place can have m ultiple copies of inform ation due to re-initiation(e.g. a specification changed or a bug being found). T his m apping is m aintained by th e to k e n s property(lines 6, 7) of the p lanned place an d th e in s ta n c e o f property(line 20) of th e token. T he to k e n s p ro p erty is a set object th a t collects all object references of tokens associated w ith th is planned place. T he in s ta n c e o f p ro p erty is a backw ard link from th e token to its tem plate. Sim ilar to th e tra n sitio n firing, th e planned place has m ultiple links to in p u ts an d o u tp u ts since a place denotes an event th a t can be triggered from disjunctive events and m ay enable o th er transitions depending on th e project state. For a p lanned place, th e in p u ts an d o u tp u ts are planned transitions(lines 8, 9). On th e contrary, only a single in p u t an d a single o u tp u t fired tra n sitio n is necessary for a token since a token is created due to th e firing of a tra n sitio n even though its associated planned place m ay have m ore th a n one in p u t tran sitio n . T hus, th e i n t r a n an d o u t t r a n properties(lines 23, 24) of a token are single-valued properties while th e i n t r a n s and o u t t r a n s properties of a planned place are set variables. A trigger operation F o rw ard E n ab le is attach ed to th e default create oper- 105 I i 1 V , Planned Place definition 2 define Type PlanPlace 3 supertypes = -[Place}; 4 properties = 5 { 6 tokens: optional distributed Set[Token] 7 inverse $Token$instanceof; 8 intrans: optional Set[Transition]; 9 outtrans: optional Set[Transition]; 10 refines decomposedinto: optional Set[PlanPlace]; 11 }; 12 end PlanPlace; 13 14 V , Token definition 15 define Type TokenState is enum (Active, Consumed, Discarded); 16 define Type Token 17 supertypes = {Place}; 18 properties = 19 { 20 instanceof: PlanPlace; 21 state: TokenState := Active 22 define set triggers (TokenStateSet); 23 intran: optional FiredTran; 24 outtran: optional FiredTran; 25 }; 26 operations = 27 { 28 refines Create (t: Token) 29 triggers (ForwardEnable) 30 }; 31 end Token; Figure 4.8: Planned place and token definitions 106 ation(lines 28, 29). This trigger checks if any o ther tra n sitio n will be enabled due to th e creation of this token. F iring a tran sitio n creates tokens on all its o u tp u t places an d these tokens m ay fu rth er enable tran sitio n s of la te r life cycle phases. A chain reaction can result. For exam ple, w hen a program m er reports th e com pletion of a code m odule, a tran sitio n is fired to upgrade th e new ver sion code in to th e system , and this new code will also fire an o th er tran sitio n to in itia te th e testin g of th is code m odule. 4 .7 D o c u m e n t V ersio n C o n tro l In each phase of th e software developm ent process, various types of docu m ents (or p ro d u cts) are generated. Some of th em are final deliverables, such as program m odule, reference m anual, and operation in stru ctio n . T he others are in term ed iate results for in tern al usage only, such as requirem ents docum ent, system specification, m odule design description, test d a ta, an d test plan. B o th th e docum ents and th eir relationships to each o th er m ust be recorded in th e p ro ject d atab ase. As th e project progresses and design evolves, new versions of docum ents are created. This m akes th e relationships am ong docum ents m ore com plicated. O ne m ight w ant to ask w hat program m odules have been im ple m en ted w ith respect to a specification change or w hat m anual parag rap h s have been added for th e new version of a program . O ne aspect of software project m anagem ent is to keep tra ck of all versions of th e docum ents. Several issues need to be considered here. F irst, com pact rep resen tatio n of different versions of th e sam e docum ent is desired in order to keep a m inim um of redundancy and save storage. Tools like SCCS and RCS keep a single version of th e docum ent and use change logs to reconstruct different versions. T his is a tim e-consum ing task. O n th e o th er h an d , versioning can be 107 im plem ented in a d atab ase system , as suggested by [Bernstein 87]. It can be done on fine granularity and still be efficient. Second, traceab ility am ong related docum ents of different versions should be provided. For exam ple, program m odule P is th e im plem entation associated w ith function F . W e m ay have three versions of P denoted as P _ l, P_2, P_3, and tw o versions of F , F_1 and F_2. T h e relationships betw een P an d F are th a t P_1 is th e code of F _ l, P_2 is a new version w ith some bug fixes, and P_3 is an u p d a te d version after new requirem ents have been added to F_2. These relationships m ust be m aintained som ehow . T his section describes th e approach th a t D esignN et uses to handle doc u m en t versions an d th eir relations. Figure 4.9 shows th e definitions of the planned pro d u ct type P ro d u c t (lines 1-21) and th e actu al generated product 1 ty p e P roductT oken(lines 23-34). T h e form er one is a subtype of th e P la n P la c e an d th e second one is a subtype of th e Token. Since b o th types are subtypes of Place, th e tim e stam ping m echanism is in h erited from th e Place supertype. W henever a new docum ent is generated, th e creation tim e is autom atically a ttach ed to th e associated object. It is not necessary to redefine it again here. A pro d u ct place(lines 1-21) only represent a logical docum ent e n tity in th e p roject plan. T he actu al p ro d u cts created, which are of m any different versions, are stored as ProductToken objects(lines 23-34). T h e tokens property(line 6) of a product place contains a set ofq^roduct tokens th a t represent individual versions associated w ith th e sam e p ro d u ct. V ersion index num bers are usually used to distinguish betw een different versions of th e sam e docum ent. C urrently, two levels of version index num ber are su p p o rted in D esignN et. T he v e rs io n in d e x l(lin e 30) defines th e m aster version index and th e v e rsio n in d e x 2 (lin e 31) defines a second level of index. T h u s, we can have a docum ent w ith version 1.0, 1.1, ..., 2.0 etc. T his scheme l 108 1 ' / Product Place definition 2 define Type Product 3 supertypes = {PlanPlace}; ! 4 properties = 1 5 - C 6 refines tokens: distributed Set[ProductToken]; 7 latestvindexl: Integer := 0; 8 latestvindex2: Integer := 0; 9 >; 10 define procedure NewVersion ( 11 product:Product,file:String,createdby:Person) 12 returns (ProductToken) 13 raises (ProductMotFound, CannotCreate) 14 method (CreateNewVersion) 15 end NewVersion; 16 17 define procedure UpdateMasterIndex (product: Product) 18 raises (ProductNotFound) 19 method (Update_M_index); 20 end UpdateMasterIndex; 21 end Product; 22 23 ' / , Product Token definition 24 define Type ProductToken 25 supertypes = {Token]-; 26 properties = 27 { 28 refines instanceof: Product; 29 fileindex: String; 30 versionindexl: Integer; 31 versionindex2: Integer; 32 createdby: Person; 33 }; 34 end ProductToken; F igure 4.9: P lanned pro d u ct and p ro d u ct token definitions 109 1 enter module $Product; 2 import $ProductToken; 3 import $Person; 4 method obj ProductToken CreateNewVersiob(prod, file, by) 5 obj $Product prod; 6 obj $String file; ; 7 obj $Person by; 8 { 9 obj $ProductToken prod_newversion; 10 11 prod.latestvindex2 += 1; 12 prod_newversion = ProductToken$[ 13 instanceof: prod, 14 fileindex: file, 15 versionindexi: prod.latestvindexl, 16 versionindex2: prod.latestvindex2, 17 createdby: by]; - 18 return (prod_newversion); 19 > Figure 4.10: C O P for creating a new p ro d u ct version can be easily extended to contain m ore levels by adding m ore index num ber properties. T h e user can control th e version sequence directly by m an ip u lat ing these properties. T he f i l e i n d e x property(line 29) stores th e file nam e inform ation or even th e directory inform ation. T he la te s tv in d e x l( lin e 7) an d la te s tv in d e x 2 ( lin e 8) properties contain th e la te st version num ber th a t a p ro d u ct has. Two procedures are defined for th e product object. T h e NewVersion pro- cedure(lines 10-15) is invoked w hen a new version of a p ro d u ct is created. T he UpdateMaster Index procedure(lines 17-20) is called to advance th e m as te r index to th e next higher version. T his procedure is invoked only when a new release of th e system is created. Since th e index u p d a te op eratio n is p re tty straightforw ard, we do not discuss it in m ore details here. However, th e 110 NewVersion procedure involves several operations and fu rth er description is re quired. Figure 4.10 shows th e C O P code of th is procedure. T h e ro u tin e takes th e planned p ro d u ct, actu al file, and th e person who creates th e new version as param eters (line 5-7). It advances th e second index num ber by one(line 11), th e n does a default create of th e product token(lines 12-17), and retu rn s th e new p ro d u ct token. N otice th a t it is not necessary to do a $Set$Insert oper atio n to ad d th e new product token into th e tokens p ro p erty of th e planned p ro d u ct since it is defined as a d istrib u ted inverse set. W hen th e default cre a te o p eratio n p u ts th e planned p ro d u ct object reference in to th e instanceof property, th e new to k en ’s object reference is autom atically inserted in to th e tokens set property. If th e routine does an o th er set insert op eratio n , one ex tra object reference will be included in th e tokens p ro p erty w hich points to th e sam e version. Chapter 5 ■ DesignPlan — An Integrated System for Software Project Management T his ch ap ter presents th e detail design concepts of th e D esignPlan system . It is an in teg rate d softw are p ro ject m anagem ent system w ith an open arch itectu re design. Its d istinct characteristics include: softw are engineering tools can be ' in co rp o rated into th e system increm entally, all th e tools share th e sam e project inform ation d atab ase, a com m on user interface is su p p o rted , an d a general object n av ig ato r is im plem ented to allow th e users to brow se and u p d a te existing p ro ject d a ta . T he first section gives a detailed description of the^system arch itectu re and th e function perform ed by each system m odule. T h e next section discusses th e design of an object program m ing interface. T his is th e foundation of an extensible environm ent. H igher level functional m odules or tools access th e p roject inform ation an d in tera ct w ith the D esignN et m echanism th ro u g h this interface. B oth th e interface w ith existing tools and users are th en discussed. T he user perspective section shows several exam ples th a t answ er th e queries of m anagem ent functions via sequences of calls to th e object program m ing interface. Finally, scenarios of th e p ro to ty p e are illu strated . 112 5.1 O v era ll S y ste m A r c h ite c tu r e i 1 T h e D esignPlan system consists of six com ponents, nam ely th e user in ter face m odule, th e activity scheduling m odule, th e resource allocation m odule, the I cost estim atio n m odule, th e D esignN et representation m odule, an d th e d atab ase su p p o rt m odule. Its arch itectu re is as show n in figure 5.1. C en tral to th is sys te m is th e D esignN et m odel th a t describes th e project plan and su p p o rts th e whs an d precondition dependency definition. All th e conceptual p roperties of a p ro ject are represented in D esignNet n o tatio n defined in ch ap ter 3. B eneath ■ it is a n object-oriented d atab ase system th a t contains th e stru c tu ra l and his torical inform ation of th e p roject. T he detail design of th e d atab ase support has been described in ch ap ter 4. A generic object pro g ram m ing interface is defined on to p of th e conceptual layer m odeled by D esignN et. T hree higher level functional m odules accesses m anagem ent inform ation th ro u g h th is in ter face. E xisting tools can also access th e p roject p lan th ro u g h th e predefined interface. T h e C o n c e p tu a l L ayer a n d th e D a ta b a se S u p p o r t M o d u le C en tral to th e D esignN et m odel is a form ally constructed whs th a t is consid erably enhanced over th e trad itio n al m odel. It provides a com m on fram ew ork from w hich planning can be perform ed, cost and budgets can be established, netw ork construction and control planning can be in itiated , an d perform ance can be evaluated. P e tri n et n o tatio n s axe in co rp o rated in to th e wbs to m oni to r th e asynchronous and concurrent project activities. T his conceptual layer has four m ajo r goals. F irst, defining a representation schem e to provide the description of a hierarchical activity netw ork, w ith precedence and resource . co n strain ts, aggregations and linkages, as well as inform ation flow across these 113 Resource Allocation Activity Scheduling Cost Estimation DesignNet Model User Interface Object-oriented Project Database Figure 5.1: A rchitecture of th e D esignPlan System 114 relations. Second, defining a triggering m echanism to au to m ate th e activity in itiatio n , replanning, and rescheduling w hen some activities have to be ite ra tively executed during th e design process. T hird, building functions to evaluate p ro ject perform ance, detecting deviations from th e schedule. Finally, defining a i unified interface for th e possibility of em ploying existing application tools. Since ! th e D esignN et rep resen tatio n is m erely an ab stract layer, all th e inform ation entities an d m echanism s are defined and sup p o rted by th e d atab ase m odule. A c t iv ity S c h e d u lin g M o d u le T h e activ ity scheduling m odule uses th e critical p a th m eth o d to schedule th e b o tto m level activities in th e wbs. W henever resource availability or th e project p lan is changed, this m odule is invoked for activity rescheduling. G an tt charts an d P E R T charts are draw n based on th e tim e d u ratio n an d dependencies of activities. Unlike trad itio n al G an tt m odel, w here m ilestones are represented by zero d u ratio n activities, m ilestones in D esignPlan are defined as a com bination of states. T his is especially im p o rtan t to perceive abnorm al p roject behaviors. For instance, a m ilestone can be defined as w hether an activ ity place has m ore th a n a certain num ber of tokens. T his m ilestone m ay or m ay n o t be reached. If such m ilestone is reached, th e activity has been executed to o m any tim es an d p ro p er m anagem ent actions should be taken. A nother exam ple is to use m ilestone to detect cost overruns or schedule delays(e.g. th e cost exceeds the budget by te n percent or th e design task is still active tw o m onths after it is supposed to finish). 115 R e so u r c e A llo c a tio n M o d u le T he resource allocation m odule determ ines th e resource availability given various allocation requests. W hen tokens get created in pro d u ct places on front of tran sitio n s before activities, th e Fire operation associated w ith th e tra n si tio n will check w hether all in p u t places have active tokens(i.e. the tran sitio n is ' enabled). If only resource places do not have active tokens, th a t m eans th e ac tiv ity is w aiting for resource assignm ent and can be in itiated after th e resources have been allocated. T his op eratio n th en collects all th e required resources and constructs th em as resource request packets. E ach packet contains th e skill re quirem ent, task d u ratio n , and previous assignm ent inform ation. T h e previous assignm ent inform ation im poses higher priority to allocate th e sam e resource th a t was assigned to th e sam e activity before. T h u s, if th e sam e activity needs to be executed m ore th a n once, th e personnel involved in earlier execution are preferred for re-executing th e activity. W h en th e resource allocation m odule receives th e resource request packets, th e ir availabilities are checked. If conflict arises, it would decide w hether al tern ativ e resources exist and can be assigned instead. Since an organization only has a lim ited am ount of resources(e.g. fixed num ber of m achines an d en gineers), th e requests can come from different projects. T he allocation strateg y used now is in a first-com e-first-service basis. T he first resource th a t m eets the requirem ent of a request is allocated to th a t request. O nce th e resources have been allocated, new tokens representing th e allocated resources are sent back to th e system . T h e tra n sitio n firing procedure will be invoked again. If all th e resources required by an activity are all allocated, th e activity is in itia te d then. 116 C o st E s tim a tio n M o d u le T h e cost estim ation and rep o rtin g m odule is an im plem entation of a subset of th e C O CO M O m odel. T he to tal cost of a p roject is derived from individual activ ity costs in th e whs. T he deviation betw een estim ated cost and actual expense is also tracked by th e com parison of planned activities w ith com pleted activities an d those still in progress. T h e estim atio n is prim arily based on a couple of softw are cost driver a t trib u te s, such as source instructions size, personal experience and capabilities, com puter hardw are constraints, and degree of use of m odern program m ing p rac tices. These a ttrib u te s are defined as properties of associated object types. T he estim ation procedure is done in a b o tto m -u p m anner. T he cost of th e b o tto m level m odules are estim ated first. T he cost of sub-system s are com puted next. T h e cost of individual phases and th e cost of th e entire project are com puted finally. U se r In te r fa c e M o d u le T h e user interface m odule enables th e project m anager and task supervisors to create th e project plan an d activate lower level functions such as activity scheduling an d cost reporting. It is a window based interface w ith graphical capabilities and pointing devices. T he user can brow se th ro u g h and u p d a te th e p ro ject inform ation via th is interface. G raphical o u tp u ts axe used w henever possible to provide th e users an intuitive view of th e p ro ject hierarchy and activ ity dependencies. Users can also constrain th e hierarchy to certain levels o r p roject th e hierarchy in to a p articu lar inform ation type(e.g. only views th e activ ity or p ro d u ct hierarchy). T hus, a task supervisor only views and m anages h is/h e r own portion. 117 5 .1 .1 A n O b je c t P r o g r a m m in g In terfa ce To m ake th e D esignPlan system an open an d extensible platform , a generic o bject program m ing interface is designed to provide higher level tools access to th e p roject d a ta . This interface facilitates th e incorporation of b o th existing tools and new tools in to th e in teg rated environm ent. A pplication tools do not access th e project inform ation in th e d atab ase directly, nor do th ey control the D esignN et token in stan tiatio n m echanism . D a ta entities are passed as objects th ro u g h th is interface. S tate changes or actions are driven by event tokens passed across th is interface. T his section defines a sm all set of prim itives th a t are necessary for sup p o rtin g th e D esignN et concepts. T hey are defined in subroutine call form ats an d are presented in several categories. To avoid using any specific language sy ntax, th ey are described in a sym bolic sy n tax m anner. However, these in terface routines can be transform ed in to any object oriented language w ithout difficulty. O p e r a tio n s A s so c ia te d w ith T im e • F u n c tio n n am e: get„current-.timestamp In p u t o b je c ts: none O b je c ts retu rn ed : time W hen th e application program needs to a tta c h th e current tim e stam p to an o bject, this ro u tin e is called first and th e retu rn ed tim e object is th en stored in this associated property. T his routine is also used as a trigger m eth o d w henever au to m atic tim e stam pping is required. • F u n c tio n n am e: set^ aM m estam p 118 In p u t o b je c ts: year,month,date,hour,minute O b je c ts re tu rn ed : tim estam p T his ro u tin e is used for setting a tim e object w ith values o th er th a n th e cur- i ren t tim e. M ost planning inform ation requires th is setting, such as p roject sta rt ■ d ate an d deadline, activ ity scheduling fram e, an d resource allocation duration. • F u n c tio n n am e: com pareJim estam ps In p u t o b je c ts: stam p 1,stam p2,granularity O b je c ts retu rn ed : temporaLrelation T his o p eratio n com pares tw o tim e stam ps according to th e given tim e gran ularity. T h e gran u larity can be any tim e scale from th e sm allest m inute scale to th e largest year scale. T he tem poral relation betw een th e tw o stam p s can be before, after, or equal. • F u n c tio n n am e: compare-time.frames I n p u t o b je c ts: fram el,fram e2,granularity O b je c ts re tu rn ed : durationjrelation T his op eratio n com pares tw o tim e fram es according to th e given tim e gran ularity. E ach tim e fram e consists of two tim e values, th e sta rt tim e of th e d u ratio n and th e end tim e of th e duration. T h e gran u larity can be any tim e scale from th e sm allest m inute scale to the largest year scale. T h e d u ratio n relatio n betw een th e tw o fram es can be before, after, m eets, overlaps, contains, sam e-begin, sam e end, or duration-equal. 119 O p e r a tio n s A s s o c ia te d w ith P r o je c t : • F u n c tio n n am e: project.create In p u t o b je c ts: list o f properties O b je c ts retu rn ed : project T his o p eratio n creates a new project w ith associated properties such as th e p ro ject nam e, s ta rt date, deadline, m anager, budget etc. T he project nam e will also be entered in to th e project dictionary for efficient searching. T he created p ro ject is autom atically decom posed in to four to p level places, th e to p level activity, th e to p level resource, th e to p level p ro d u ct, and th e to p level statu s rep o rt. These to p level places are th e root node of individual w ork breakdow n ■ stru ctu re hierarchy. • F u n c tio n n am e: project-.open In p u t o b je c ts: projectjnam e O b je c ts re tu r n ed : project T his ro u tin e opens a project associated w ith th e nam e supplied and m akes it as th e currently active context. All fu rth e r project level operations are restricted to th is active p roject. U pon re tu rn of th e routine, th e wbs of th e project is also constru cted an d displayed. T h e user can th e n constrain th e wbs to a p o rtio n of th e en tire p ro ject. T he object navigator is also activated to allow th e user to brow se th e d etail inform ation of objects. • F u n c tio n n am e: project.close In p u t o b je c ts: project O b je c ts retu rn ed : none 120 T his op eratio n closes th e currently active project. No fu rth e r p roject m a n ip u latio n functions can be perform ed u n til th e user open an o th er p roject. Internally, th is routine releases all m em ory buffers allocated for th e opened p ro ject, frees th e wbs stru ctu re, deactivates th e object navigator function. • F u n c tio n n am e: project-delete I n p u t o b je c ts: project^nam e O b je c ts retu rn ed : none T his o p eratio n rem oves a project perm anently from th e d atab ase. R elated inform ation are also deleted including th e project plan and its history. • F u n c tio n n am e: project^activities In p u t o b je c ts: project O b je c ts r etu r n ed : set o f activities T his o p eration constructs a set object th a t consists of all th e activities defined in a p roject. It serves as th e activity d a ta dictionary for p roject activity m anipulation. • F u n c tio n n am e: projectjresources In p u t o b je c ts: project O b je c ts retu rn ed : set o f resources T his o p eratio n constructs a set object th a t consists of all th e resources defined in a p ro ject. It serves as th e resource d a ta dictionary for p roject resource m anipulation. • F u n c tio n n am e: projectjproducts 121 I n p u t o b je c ts: project O b je c ts r etu rn ed : set of products T his op eratio n constructs a set object th a t consists of all th e p roducts de- . fined in a p roject. It serves as th e product d a ta dictionary for project product m anipulation. • F u n c tio n n a m e : projectjreports I n p u t o b je c ts : project O b je c ts r e t u r n e d : set of reports T his op eratio n constructs a set object th a t consists of all th e statu s rep o rts defined in a p ro ject. It serves as th e statu s rep o rt d a ta dictionary for project sta tu s rep o rt m anipulation. • F u n c tio n n a m e : find.project I n p u t o b je c ts : none O b je c ts r e t u r n e d : project T his o p eration provides an interactive selection m echanism for th e user to locate a specific p ro ject. It pops up a m enu w ith a full project-nam e list and let th e user pick up a p artic u la r en try by clicking th e m ouse. T he object reference of th e selected ite m is returned. • F u n c tio n n a m e : find-activity I n p u t o b je c ts : project O b je c ts r e t u r n e d : activity 122 T his operation provides an interactive selection m echanism for th e user to locate an activ ity inside a project. It p o p s u p a m enu w ith a full activity-nam e j list and let th e user pick u p a p articu lar en try by clicking th e m ouse. T h e object ' reference of th e selected item is returned. i I I • F u n c tio n n am e: find-resource 1 1 In p u t o b je c ts: project [ O b je c ts retu rn ed : resource T his operation provides an interactive selection m echanism for th e user to locate a resource inside a p roject. It pops up a m enu w ith a full resource-nam e list and let th e user pick u p a p articu lar en try by clicking th e m ouse. T h e object reference of th e selected item is retu rn ed . • F u n c tio n n am e: find-product In p u t o b je c ts: project O b je c ts r etu rn ed : product T his operation provides an interactive selection m echanism for th e user to locate a p ro d u ct inside a p roject. It pops up a m enu w ith a full p ro duct-nam e list and let th e user pick u p a p articu lar en try by clicking th e m ouse. T h e object reference of th e selected item is returned. • F u n c tio n n am e: find^report In p u t o b je c ts: project O b je c ts r etu rn ed : report T his operation provides an interactive selection m echanism for th e user to locate a sta tu s rep o rt inside a project. It pops up a m enu w ith a full statu s 123 rep o rt list and let th e user pick up a p articu lar en try by clicking th e m ouse. T h e object reference of th e selected item is returned. O p e r a tio n s A s s o c ia te d w ith W B S • F u n c tio n n am e: set^decomposition-type In p u t o b je c ts: place, decomposition-type O b je c ts retu rn ed : none T his op eratio n defines th e stru ctu ra l decom position ty p e th a t a place will be decom posed. W hen a place is created initially, th e decom position ty p e is set to None. A place can b e fu rth er decom posed either th ro u g h And or Or stru c tu ral op erato r. T he stru c tu ra l o p erato r to g eth er w ith th e decom position links form th e wbs of a p roject. • F u n c tio n n am e: add_to_decomposedintoset In p u t o b je c ts: parentjplace,child^place O b je c ts retu rn ed : none T his op eratio n adds one m ore child place in to th e p aren t place’s decom po sition set. T h e wbs is constructed increm entally by extending th e stru ctu ral decom position of th e hierarchy. • F u n c tio n n am e: remove.from^decomposedintoset In p u t o b je c ts: parentjplace,childjplace O b je c ts retu rn ed : none This operation rem oves one child place from th e p aren t place’s decom posi tio n set. It is invoked w hen th e project plan is changed and th e wbs needs to be restru ctu red . 124 • F u n c tio n n am e: get-decom posedintoset In p u t o b je c ts: place O b je c ts retu rn ed : decompositionJ,ype, set of children places T his operation allows th e application program to inquire th e stru c tu ra l de com position ty p e of a place and its next level constituents. T he children place set can b e ite ra te d for collecting aggregate inform ation from lower level places, t For exam ple, th e d u ratio n of a higher level task is a union of lower level ac tiv ities and th e num ber of program lines of a p ro d u ct is th e sum of low er level program m odules. • F u n c tio n n am e: getjparent In p u t o b je c ts: place O b je c ts retu rn ed : decomposition-type,place T his op eratio n provides an upw ard traverse from a lower level place to its p aren t place. It is invoked by th e token in stan tiatio n m echanism w here tokens generated on b o tto m level places needs to be p ro p ag ated upw ard. • F u n c tio n n am e: constrain In p u t o b je c ts: place,level O b je c ts re tu rn ed : none T his o p eratio n restricts th e view and m anipulation of a project wbs to only a p o rtio n of th e entire hierarchy. T he user can view only th e hierarchy rooted a t th e given place w ith th e specified level. T his function enforces th e stru c tu ra l m anagem ent w here task m anagers can supervise th e project a t different levels. • F u n c tio n n am e: clear-constrain 125 In p u t o b je c ts: none O b je c ts retu rn ed : none T his operation rem oves any constrained view im posed by previous c o n s tr a in operations. T h e project wbs retu rn s to its original hierarchy. T h e user can brow se or m an ip u late th e entire project. O p e r a tio n s A s s o c ia te d w ith D e p e n d e n c y • F u n c tio n n am e: build-dependency In p u t o b je c ts: set o f places, set o f places O b je c ts retu rn ed : transition T his op eratio n sets u p a dependency relationship betw een tw o sets of places. Since th e dependency is a m any-to-m any relation, tw o sets are required. It creates a new tran sitio n object w ith links to b o th th e in p u t places and th e o u tp u t places. T h e object reference of th e new tran sitio n is retu rn ed . • F u n c tio n n am e: add-to-dependant In p u t o b je c ts: transition,place O b je c ts retu rn ed : none T his op eratio n adds one m ore place in to a tra n sitio n ’s in p u t places set. T he dependency am ong places can be constructed increm entally by extending the entities involved in th e relation set up by a tran sitio n . • F u n c tio n n am e: add-to-dependee In p u t o b je c ts: transition,place O b je c ts r etu rn ed : none 126 T his operation adds one m ore place in to a tra n sitio n ’s o u tp u t places set. T h e dependency am ong places can be constructed increm entally by extending i , th e entities involved in th e relation set up by a tran sitio n . • F u n c tio n n am e: remove_from_dependant i : , In p u t o b je c ts: transition,place ' O b je c ts retu rn ed : none T his operation rem oves one place from a tra n sitio n ’s in p u t places set. It is invoked w hen th e project plan is changed and th e tra n sitio n is no longer dependent on th e rem oved place. • F u n c tio n n am e: remove Jrom-dependee In p u t o b je c ts: transition,place O b je c ts retu rn ed : none T his op eratio n rem oves one place from a tra n sitio n ’s o u tp u t places set. It is invoked w hen th e p ro ject plan is changed and th e o u tp u t place is no longer dependent on th e tran sitio n . • F u n c tio n n am e: inquiry.of-transition In p u t o b je c ts: transition O b je c ts r etu rn ed : set o f dependant places, set of dependee places T his op eratio n allows th e application program to inquire th e places th a t th e tra n sitio n depends on(precedent) and th e places th a t depend on th e transi- tion(successive). T he dependant places provide the backw ard tracing capability an d th e dependee places provide th e forw ard tracing capability. 127 • F u n c tio n n am e: inquiry.ofjplace In p u t o b je c ts: place O b je c ts retu rn ed : set of enabling transitions, set of enabled transitions T his o p eration allows th e application program to inquire th e enabling tran - sitions(precedent) an d th e enabled transitions(successive) of a place. T he en abling tran sitio n s provide th e backw ard tracin g capability an d th e enabled tra n sitions provide th e forw ard tracing capability. • F u n c tio n n am e: add^trigger^to^transition In p u t o b je c ts: transition,procedure O b je c ts retu rn ed : none This o p eratio n attach es a new procedure to a tran sitio n . T his procedure is triggered w hen th e tran sitio n is fired. T he related d a ta entities th a t enables th e tra n sitio n are passed to th e procedure as p aram eters. T he functions of these procedures are prim arily for design rule checking(e.g. th e program follows th e sy n tax convention) or post processing(e.g. u p d atin g source code library). • F u n c tio n n am e: removeJ,riggerJromJ,ransition In p u t o b je c ts: transition,procedure O b je c ts r e tu rn ed : none This operation rem oves an existing trigger procedure from a tran sitio n . It is invoked w hen th e project plan is changed and th e trigger is no longer needed. 128 O p e r a tio n s A s so c ia te d w ith H isto r y • F u n c tio n n am e: get_executionjoccurrances In p u t o b je c ts: place O b je c ts r etu rn e d : set o f tokens T his operation retu rn s th e set of all tokens associated w ith a place. Each token represents an execution instance of th e plan. For exam ple, a token in an activ ity place m eans th e occurrence of an itera tio n an d a to k en in a product place m eans a version of th a t p ro d u ct. D etail execution dependent inform ation are defined in th e properties of token objects. • F u n c tio n n am e: getjplanSnform ation In p u t o b je c ts: token O b je c ts retu rn ed : place T his op eratio n allows th e application program to inquire th e p roject p lan inform ation associated w ith a token. It is used for locating static dependency inform ation. For instance, an activ ity can have disjunctive dependencies and only one tra n sitio n enables th e generation of th e token(i.e. triggered by one dependency) in an activity place. O ther dependency inform ation can only be accessed by going back to th e project plan. • F u n c tio n n am e: events_occurredjinJ,im e.fram e In p u t o b je c ts: place,start-tim e,end-tim e O b je c ts retu rn ed : set o f tokens T his o p eratio n retu rn s th e set of tokens created in a p artic u la r tim e fram e associated w ith a place. It is used for project history inquiry, for exam ple, to 129 inquire th e p roject personnel assigned to a task last m o n th and th e versions of a docum ent generated last year. 5 .1 .2 I n te r fa c e s to O th er T o o ls T h e object program m ing interface of th e D esignPlan system provides a ker nel set of operations into th e D esignN et representation an d th e underlying j p ro ject datab ase. New developm ent tools can be in teg rate d in to th e system as long as th eir im plem entation conform s to th is interface. However, in teg ra tio n w ith existing tools needs m ore support since m ost of th em have th eir own d a ta file form at or d atab ase support. For stan d alone tools th a t require interactive user operations, th e user can in voke th e m w ithin D esignPlan w ithout re-design or re-im plem enting these tools. To achieve th is transparency, an im p o rt and export m echanism is defined in D e signP lan for supp o rtin g these foreign tools w ith different d a ta representation. Before invoking a specific tool, th e desired inform ation is ex p o rted from th e D esignPlan d atab ase to th e to o l’s ow n form at. T he user can activate th e tool u n d er th e to p level user interface of D esignPlan. O nce th e tool finishes its pro cessing, th e u p d ated inform ation is im p o rted back to th e D esignPlan database. Figure 5.2 shows th e functional diagram of th e d a ta conversion schem e betw een th e foreign tools and th e underlying database. D epending on th e interface functions supplied by existing tools, tools can also be triggered autom atically by th e D esignPlan system w hen certain events occur. T his is accom plished by attach in g procedures to th e tran sitio n s before or after an activity. T his m ay be as sim ple as a single com m and or a shell script, for exam ple, a d elta operation in to th e SCCS w hen a code m odule is m odified and debugged. It m ay have to perform several calls to another system , for exam ple, 130 ! User Interface Object-oriented Project Database Import/Export Existing Mechanism Tools .. . . . . . ^ t DesignNet Tools Information Model Storage Figure 5.2: Im p o rt/E x p o rt m echanism in D esignPlan 131 to build a relationship betw een tw o docum ents in SODOS. O r it m ay in itiate a sta n d alone process, for exam ple, a financial rep o rt generating program . i i 5.2 U se r P e r sp e c tiv e i i ■ ( H aving u n d ersto o d th e in tern al design concepts of D esignPlan and defined ■ a generic program m ing interface, now we are able to investigate w hat kinds of m anagem ent functions can be perform ed on th e system from th e u ser’s point of view. T h e user interface is a m ultiple window environm ent as offered by a SUN w orkstation (under X W indow s) which contains several panes or subwindows th a t provide different views of th e project inform ation. A user selects com m ands from pop-up m enus w ith a display pointing device (a m ouse). High resolution graphics are used to provide a visible illu stratio n of th e wbs h ierar chy, tim e-line based schedule, P etri n et constructs, etc. W ith Q BE-like queries an d brow sing functions, th e user can establish, u p d ate, an d inquire ab o u t any p ro ject inform ation im m ediately. W ith a predefined activity ty p e for each life cycle phase, th e project planning task is m erely a stepw ise jo b decom position process th a t results in a refined wbs. T h e p roject m anager can m an ip u late directly th e graphical wbs representation. W hile th e system is constructing th e p roject netw ork by connecting product dependencies to g eth er, th e com pleteness an d consistency of th e p lan can be verified. W e m ay check if all specifications are designed an d im plem ented, w hether a te st p lan is m issing for some m odules, and if a task is decom posed in to th e sam e co n stitu en t com ponents in different phases. Since th e wbs built from D esignPlan captures th e activity, th e resource, 132 an d th e p ro d u ct aspects of a p ro ject, a project m anager can derive th e answ er to several im p o rtan t m anagem ent questions. How m uch m oney is needed for th is pro ject? How m any com puters or o th er equipm ent are necessary? W hat personnel are required? Do they have sufficient skills? Do we need personnel retrain in g or recruiting m ore staff? How soon will th e project finish if no activity is delayed? W h at is th e stru ctu re of th e end p roduct? W h at acceptance criteria will be applied to various docum entation? C an these verifying functions be a tta c h e d to th e finish tran sitio n of predefined activ ity types? These are th e questions th a t m ight be asked before a project is in itiated . As described in previous chapter, the in sta n tia tio n of an activity will not only create an activ ity w ith proper tim e stam ps b u t also track dow n associ ated in p u t an d o u tp u t conditions as well as resources consum ed (or personnel involved). W ith th e p ro je c t’s historical inform ation having been recorded au tom atically, th e project m anager can issue queries against th e project d atab ase to analyze and reason ab o u t th e p ro ject’s progress, especially about those d a ta th a t are d istrib u ted in several phases. For instance, to know w hat code m od ules are affected regarding a specification change, we can sta rt from th e token associated w ith th a t change, tra ce thro u g h all th e design, im plem entation and testin g activities triggered and th en locate th e resulting m odules. A fter a project is in itia te d and planned activities get in stan tiate d , a project m anager can derive inform ation for m onitoring p roject progress and detecting deviation from th e schedule. W h at is th e current sta tu s of th e design task? H ave all th e design activities been finished yet? Is there any delay so far? If yes, how m uch will it affect th e final project com pletion tim e? How m uch m oney has been spent so far? W h at activities cause th e m ajo r delay or cost overrun? If an activity (p lo tter driver design) has been executed often, who has been resp o n sib le for it? If we change th e requirem ent for th e p lo tter o u tp u t, how 133 m uch m ore tim e and resource will be needed to com plete th e job? W h at other activities are delayed? If th e project shows some delay, is it possible to m ake up : th e delay by introducing ex tra resources? If yes, ad d to w hat activities? W hen personnel tu rn o v er occurs, can we find th e staff w ho w ere involved w ith an activ ity executed tw o m onths ago? T h e activity in sta n tia tio n process will keep ; a p roject log for th e whole project life span. It is a valuable tool in perform ing post-m ortem s. 5 .2 .1 Q u e r y E x a m p le s T his section shows several sam ple queries th a t m ight be expected to arise in a m anagem ent situ atio n . T hese queries are form ulated as a sequence of calls to th e object program m ing interface. We can see how high level project inform ation is derived th ro u g h these prim itive object operations. Since all the queries are issued against a p articu lar p ro ject, a global project variable(obj $ P r o je c t p r o j e c t ) is defined as th e current active project. E x a m p le 1 How m uch m oney is needed fo r this project? p r o c e d u r e { obj $Real T otalC ost; T otalC ost = project.activity.cost + project.resource.cost -f pro ject .product .cost + p ro ject.statu s.co st; re tu rn (T otalC ost); } T his exam ple shows how th e to ta l project estim ated cost is com puted from th e top level activity, resource, p ro d u ct, and statu s rep o rt entries. Since a trigger op eratio n is defined at th e cost p ro p erty of th e P la c e object type, costs a t lower level nodes are autom atically com puted recursively. 134 E xam p le 2 How much money has been spent so fa r? p r o c e d u r e { obj $Set allactivities[$A ctivity]; obj $Set a!ltokens[$ A ctivity Token]; obj $ A ctivity act; obj $ A ctivity Token acttoken; obj $Real cost = 0.0; allactivities = project^activities (project); ite ra te (act = allactivities) { alltokens = get„execution„occurrances (act); ite ra te (actto k en = alltokens) { cost + = acttoken.cost; } } re tu rn (cost); } Since th e sam e activity m ay be executed m ultiple tim es, th e current cost of a project should include every iteratio n of all activities. T h e cost of unexecuted activities is not counted in th e figure. E x a m p le 3 How m any com puters or other equipm ent are necessary? p r o c e d u r e { o bj $Set allresources[$Resource]; o bj SResource res; allresources = projectjresources (project); ite ra te (res = allresources) { if (res.type = = ’’C om puter” or res.type = = ’’E quipm ent”) p rin t (res.nam e); } } T his exam ple gives a list of all required resources which are of type Com puter or E quipm ent. 135 E x a m p le 4 What is the structure of the end product? p r o c e d u r e show.product-hierarchy (obj SProduct p roduct){ obj $Set next Jevel_prods[$Product]; obj SProduct prod; next_level_prods = get.decom posedinto.set (product); ite ra te (p ro d = next JeveL prods) { p rin t (prod.nam e); forw ardJindent (); show.productJhierarchy (prod); backward.indent (); } } T his exam ple displays an indented hierarchy of th e pro d u ct stru ctu re. It can be called at any level of th e pro d u ct. For in stance, showjproductJiierarchy (pro d u ct.n am e = = ’’U ser M anual” ) will shows th e hierarchy of th e user m anual an d showjproductJiierarchy (product.nam e = = ’’System Specification” ) gives th e hierarchy of th e system specification. E x a m p le 5 W hat is the current status o f the design task? p r o c e d u r e show .activity.state (obj SA ctivity h ig h Jev eL act) { obj $Set next Jevel_acts[$A ctivity]; obj $Set a!ltokens[$ A ctivity Token]; obj $ A ctivity act; obj SA ctivityToken acttoken; n ext Jev eL acts = get.decom posedinto.set (highJeveL act); ite ra te (act = next Jev eL acts) { p rin t (act.nam e); alltokens = get.execution.occurrances (act); ite ra te (actto k en = alltokens) { p rin t (actto k en .state); p rin t (a ctto k en .startd ate); p rin t (acttoken.enddate); } show.activity.state (act); } } 136 : T his exam ple p rin ts o u t all th e activities u n d er th e design task w ith the activ ity nam e, states(i.e. active or finished), sta rt d a ta an d end date. E x a m p le 6 Have all the design activities been finished yet? j p r o c e d u r e listjunfinished_activity (high_Level_act) { o b j $Set next Jevel_acts[$ A ctivity]; 1 obj $Set alltokens[$A ctivityToken]; ' obj $ A ctivity act; obj $A ctivityToken acttoken; next_level_acts = get-decomposedinto_set (high_level_act); ite ra te (act = next JeveL acts) { alltokens = get-execution.occurrances (act); if (alltokens = = em ptyset) p rin t (act.nam e + ” not executed” ); else ite ra te (acttoken = alltokens) if (actto k en .state = = ’’active”) prin t (act.nam e + ” currently being executed” ); Ustjunfinished_activity (a c t); } } T his exam ple shows tw o types of unfinished activities, either those currently being executed or those not yet started . E x a m p le 7 What activities cause the major delay or cost overrun? p r o c e d u r e { obj $Set allactivities[$A ctivity]; obj $Set alltokens[$A ctivityToken]; obj $ A ctivity act; obj $A ctivityToken acttoken; allactivities = project^activities (project); ite ra te (act = allactivities) { alltokens = get^execution^occurrances (act); ite ra te (actto k en = alltokens) 137 if (acttoken.end.date > act.en d d ate or acttoken.cost > act.cost) p rin t (act.nam e); T his exam ple gives a list of th e activities w ith cost higher th a n planned or end d ate la te r th a n planned. E x a m p le 8 I f we change the requirement for some functions, how much more time and resource will be needed to complete the job? What other activities are affected? p r o c e d u r e forward^dependencies (obj SProduct prod) { o bj $Set triggered_transitions[$T ransition]; obj $Set dependent_places[$Place]; obj $ A ctivity act; obj $Resource res; obj $T ransition tran s; obj $Place place; triggered_transitions = inquiry-of-transition (prod); ite ra te (tra n s = triggered_transitions) { dependent_places = inquiry_ofjplace (tran s); ite ra te (place = dependent .places) { if (place.basetype = = $A ctivity) { p rin t (’’activity affected:” + place.nam e); p rin t (’’tim e required:” + place.duration); } if (place.basetype = = $Resource) p rin t (’’resource required:” + place-nam e); if (place.basetype = = S Product) forward-dependencies (place); } } } T his exam ple shows th e forw ard dependencies of a specific p ro d u ct place. T h e places depending on this p ro d u ct place will be affected w hen a new pro d u ct 138 version is created. A ctivities in th e list need to be re-in itiated an d resources in th e list need to be re-allocated. E x a m p le 9 What are the activities executed too often (e.g. more than five times)? Who have been responsible fo r them? p r o c e d u r e { obj $Set allactivities[$A ctivity]; obj $Set alltokens[$A ctivityToken]; obj $ A ctivity act; obj $A ctivityToken acttoken; allactivities = project.activities (project); ite ra te (act = allactivities) { alltokens = get-execution.occurrances (act); if (actto k en .C ard in ality > 5) { p rin t (act.nam e); p rin t (” supervised b y ” + act.supervisedby.nam e); } } T his exam ple locates activities w ith m ore th a n five tokens in it an d p rin ts th e person in charge of th e activity. A token represents one execution instance of th e activity. E x a m p le 10 What are the requirement, specification, and design document associated with a particular code module(e.g. the plotter driver)? p r o c e d u r e products „depended„on (obj SProduct prod) { obj $Set triggering_transitions[$Transition]; obj $Set places_depended_on[$Place]; obj ST ransition tran s; obj $Place place; triggering_transitions = inquiry_o^transition (prod); ite ra te (tran s = triggering_transitions) { places_depended_on = inquiry_of[.place (tran s); 139 ite ra te (place = places_depended_on) if (place.basetype = = S P roduct) { p rin t (’’depends on p ro d u ct:” + place-nam e); products_.depended.on (place); } T his exam ple searches for th e products th a t a p artic u la r pro d u ct m odule depends on. T he result shows a backw ard tracing record w here th e p ro d u ct is derived from . E x a m p le 11 What are the activities with personnel turnover? p r o c e d u r e { obj SSet allactivities[$A ctivity]; obj SSet alltokens[$ A ctivity Token]; obj SSet allpersons[SPerson]; obj $ A ctivity act; obj SA ctivityToken acttoken; allactivities = project.activities (project); ite ra te (act = allactivities) { alltokens = get.execution.occurrances (act); allpersons = $Set[obj $Person]$[]; ite ra te (actto k en = alltokens) SSetSlnsert (allpersons, acttoken.supervisedby); if (allpersons.C ardinality > 1 ) p rin t (act.nam e + ” has personnel tu rn o v er” ); } } T his exam ple locates th e activities th a t are executed m ultiple tim es and have different supervisors. It iterates thro u g h all tokens of an activ ity place a n d creates a set of responsible persons. Since th e set insert operation removes duplicate elem ents, its cardinality shows th e distinct people involved in an ac tivity. 140 E x a m p le 12 Are the delayed activities caused by personnel turnover? p r o c e d u r e { obj $Set delayed_activities[$A ctivity]; obj $Set turnover^activities[$A ctivityToken]; obj $ A ctivity act; delayed_activities = get^delayed^activities (project); turnover_activities = getAurnover^activities (project); ite ra te (act = delayed_activities) { if (IsM em ber (turnover_activities, act) p rin t (’’delay of ” + act .nam e + ” is caused by personnel tu rn o v er” ); } } T his exam ple identifies th e activities w ith th e schedule delay and also th e personnel turnover. It first creates tw o set of activities th a t contain those de layed activities and personnel turnover activities. T hen, it finds th e intersection of these tw o sets. 5.3 S cen a rio s o f P r o to ty p e T his section contains a d em onstration of th e functions currently im ple m en ted in th e D esignPlan p ro to ty p e. T he user interface is im plem ented on X W indow s version 10 release 4. T he interface takes advantages of th e bitm ap display and w indow ing m echanism . T he targ et m achine it runs on is a Sun 3 /6 0 . T he underlying object d atab ase used is V base version 1.0. W e illu strate th e creation of a sam ple project, th e spreadsheet p ro jecty an d th e decom position of its w ork breakdow n stru ctu re thro u g h a set of screen dum ps. Figure 5.3 is th e sta rtu p screen of th e p rototype. T h e screen has th ree m ajo r areas. T he top area contains th e system logo and is reserved for displaying p ro ject inform ation w hen a project is opened. B eneath th e title region is a list 141 DesignPlan : An Object-Oriented Software Project Management System P ro je ct WBS Dependency B row se E vent H isto ry G a n tt PERT R esource Q uit Figure 5.3: D esignPlan top level screen. 142 DesignPlan : An Object-Oriented Software Project Management System WBS Dependency B row se E vent | H isto ry G a n tt PERT R esource Q u it P ro ject P r o j e c t Open Close Delete Project Figure 5.4: Subfunctions under project com m and. of to p level com m ands. T h e box surrounding each com m and is created as a window such th a t th e m ouse en ter and leave events can be detected. W hen th e m ouse enters a p articu la r com m and box, th e region is p u t in reverse video to highlight its active state. T he region is back to norm al video after th e m ouse leaves th a t box. T he large blank area below th e top level com m and choices is for graphic display and o th er m anipulation functions. To select th e com m ands available u nder a specific to p level com m and, place th e m ouse in th e com m and box and press a m ouse b u tto n . A pulldow n m enu is th en displayed under this box. Figure 5.4 shows th e pulldow n m enu of th e to p 143 DesignPlan : An Object-Oriented Software Project Management System Project W BS Dependency Browse Event History Gantt PERT Resource Quit P ro je c t O bject |Done ||Abort I T S T I if B ; Spreadsheet P ro ject^ Manager : S ta r t d ate : Deadline : Figure 5.5: P roject object creation form . level p roject function. As you m ove th e m ouse dow nw ard( while you still hold dow n th e m ouse b u tto n ), th e en try pointed at by th e m ouse will be highlighted in reverse video. To activate any com m and, release th e b u tto n w hen th e com m an d is highlighted. You can see th a t four subfunctions are defined u n d er th e pro ject com m and box. T he new function allows you to create a new project. T h e open and close functions let you open/close an existing p ro ject. T he delete function rem oves a project perm anently from th e d atab ase. Suppose we w ant to create a new p roject, we can execute th e new com m and by pointing th e m ouse to th a t en try an d releasing th e m ouse b u tto n . T he system 144 DesignPlan : An Object-Oriented Software Project Management System 1 W BS Dependency Browse Event History || Gantt 1 PERT 1 I Resource 1 1 Quit P ro je c t O bject Name : Spreadsheet P ro je c t jDone (Abort EHSBsSS : S ta r t d ate : D eadline : Lung'-Chun Liu P e r s o n Figure 5.6: A ssigning th e m anager to a project. will th e n ask you to place a window on th e screen for th e project object creation form . You can drag th e form w herever you like and press a m ouse b u tto n to place it. Now a form is displayed for you to define detail p roject inform ation, such as th e project nam e, m anager, sta rt d ate, an d end date(show n in figure 5.5). N otice th a t some properties of a project are object references to o th er ob jects. For these non-prim itive object properties, th e user can not specify their values ju st by typing in strings or integers. A n object identifying m echanism m u st be used to define these properties. T he m anager p ro p erty is one of these 145 DesignPlan : An Object-Oriented Software Project Management System WBS Dependency B row se | E vent H isto ry G a n tt PERT R esource Q uit P ro ject P ro je c t O bject Name : Spreadsheet P ro ject GEBSHS • __________________ S ta r t d ate : _________________________ Deadline r (Done Ijftbort Person Object |Done ||Abort Name ♦ Robert Johnson Phone ♦ 743550Q T itle x Senior Programmer Department i Computer Science B gT O W P I Person Object [Done ||Abort Name * E ric Simpson Phone T itle 7430010 General Clerk Computer Science! S ecretary x Figure 5.7: R ecursive creation of th e person object. properties. T hus, w hen th e user choose to define this property, th e system pops u p a list of th e existing persons’ nam es. T he user can either pick up a person w hich is already existed or define a new person. T his is show n in figure 5.6. If we assign a non-existing person to th e p roject by selecting th e new entry, a form for creating th e person object will be displayed. Since th e secretary p ro p erty of th e person object is also a reference to an o th er person object, th e m echanism used for defining th e m anager is also used for defining th e secretary here. T his recursive object creation can go on to any num ber of depth. Figure 5.7 shows th a t we also define a non-existing person as th e secretary of the 146 DesignPlan : An Object-Oriented Software Project Management System P ro ject WBS Dependency Browse Event History Gantt PERT Resource Quit P ro je c t O bject |Done liftbort Name ; Spreadsheet P ro je c t A Manager j Robert Johnson D eadline : Time Object iDone ~||Abort Hour : 0 Minute : 0 Date : 1 Month t 7 U skV J s 19B8| Figure 5.8: C reating a tim e object for th e p roject sta rt tim e, p ro ject m anager. O nce we assign th e project m anager, we can now define th e sta rt tim e and end tim e for th e p roject. A gain, b o th properties are objects, n o t prim itive properties, and a form is used to specify th e tim e values. Figure 5.8 shows how we assign th e sta rt tim e of a project. T he end tim e is defined in th e sam e m anner. A fter all th e properties are given, we can select th e done box on th e upper rig h t corner to activate th e project creation process. T he system creates th e i p roject object an d sets up th e links to o ther objects(i.e. th e m anager, sta rt tim e, 147 Project W BS Dependencj Browse Event History Gantt PERT Resource Quit DesignPlan : An Object-Oriented Software Project Management System Project : Spreadsheet Project Managed by : Robert Johnson Start date : Thu Jun 30 17:00:00 1983 Deadline : Sat Jul 30 17:00:00 1988 Toplevel. activity) Toplevel.resourc Spreadsheet Proj Toplevel. product Toplevel.status Figure 5.9: T he created project w ith default decom position. 148 DesignPlan : An Object-Oriented Software Project Management System P ro ject : S p read sh eet P ro ject S ta rt date : T hu Ju n 30 17:00:00 1983 M anaged by : R obert Johnson D eadline : S at Ju l 30 17:00:00 1988 P roject WBS Brow se Event H istory G an tt PERT R esource Q uit WBS C o nstrain V iew A ll D ecom pose ^T o p lev el.aetiv ity ) -(Toplevel.iesourc WBS S p read sh eet Proj I T oplevel. pro duet T o p lev el.statu s Figure 5.10: Subfunctions under wbs com m and. an d end tim e references to o ther objects). T he project is decom posed in to four to p level entities by default, th e top level activity, th e to p level resource, th e to p level p ro d u ct, and th e to p level statu s rep o rt. T he new o p eratio n will also open th e newly created project autom atically. Figure 5.9 shows th e created project. N otice th a t th e detail inform ation of th e project, including th e project nam e, m anager, sta rt tim e, an d tim e, are displayed on th e to p region. T h e work breakdow n stru ctu re of a project is constructed interactively under th e wbs top level com m and. Figure 5.10 is a list of th e wbs sub-com m ands ! available. Suppose we w ant to decom pose the to p level activity in to six phases, 149 DesignPlan : An Object-Oriented Software Project Management System P ro ject : S p read sh eet P roject M anaged by ; R o bert Johnson S ta rt date : T hu Ju n 30 17:00:00 19SS D eadline : S at Ju l 30 17:00:00 1088 iD ependencj] Browse Event H isto ry G a n tt PERT R esource Q uit T o p le v el.ac tiv ity ) > T r D e c o m p o s e T y p e And O perator S p read sh eet Proj Or O perator D e c o m p o s e T y p e T o p lev el.statu s Figure 5.11: Selecting th e stru ctu ra l o p erato r type. 150 DesignPlan : An Object-Oriented Software Project Management System P ro ject : S p read sh eet P ro ject M anaged by : Robe rt Johnson P ro ject S ta rt date : T hu Ju n 30 17:00:00 1988 D eadline : S at Ju l 30 17:00:00 19S8 Dependency Brow se E vent H isto ty G a n tt PERT R esource Q uit T o p lev el,activ ity ) evel.resourc S p read sh eet Proj T opley e 1. p r o d uc t T oplevel.status Activity Object [Done IfAbort Name . Requirement Analysis Duration : 12 Estimate X : 0 Min. Duration : 12 Max. Duration : 16 Supervised By : Lung-Chun Liu iHBSfi! * 100.001 Figure 5.12: Defining properties of lower level place. 151 I I D e s i g n P l a n : A n O b j e c t - O r i e n t e d S o f t w a r e P r o j e c t M a n a g e m e n t S y s t e m P ro je ct : S p read sh eet P ro ject M anaged by : R obert Johnson S ta rt date : T hu Ju n 50 17:00:00 19SS D eadline : S at J u l 30 17:00:00 1988 P ro ject WBS Dependency Brow se Event H isto ry G a n tt PERT R esource Q uit T oplev el.activ i tyj- (Toplevel.resourc S p read sh eet Proj iT oplevel.p ro duct T o plevel.status i Figure 5.13: T he w b s after decom position. 152 D e s i g n P l a n : A n O b j e c t - O r i e n t e d S o f t w a r e P r o j e c t M a n a g e m e n t S y s t e i S ta rt date : T hu Ju n 30 17:00:00 1988 D eadline : S at J u l 30 17:00:00 1988 P ro ject : S p read sh eet P ro ject M anaged by : R o bert Johnson P ro ject D ependencj Browse E vent PERT WBS H isto ry G a n tt R esource Q uit R equirem ent A na) P re lim in ary D esi) Inti Coi T estin g S p read sh eet Proj O p eratio n [Toplevel.resourc T oplevel .product T o plevel.status Figure 5.14: F u rth er decom position of th e activity hierarchy. we can first select th e decom pose entry. T he system will th en ask us to locate a place for decom position. If th e place has not been decom posed before, the stru c tu ra l o p erato r type is asked first and a form is shown for th e user to fill in th e detail inform ation of th e lower level place. Figure 5.11,5.12, and 5.13 show th e sequence of adding th e requirement analysis activ ity to th e to p level activ ity decom position set. T h e decom position can be continued to as m any levels as necessary. We use th e exam ple show n in figure 3.7 as a guideline an d decom pose th e design activ ity of th e spreadsheet project in to several levels deep. T he result is shown 153 DesignPlan : An Object-Oriented Software Project Management Systei P ro ject : S p read sh eet P roject M anaged by : R obert Johnson S ta rt date : T hu Ju n 30 17:00:00 1988 D ead lin e : S at Ju l 30 17:00:00 1983 P ro ject WBS Dependency Brow se Event H isto ry G a n tt PERT R esource Q uit (In te rfa c e D e sig n ^ w ith M ouse Input W ithout Mqusb^ ) S creen O utput G rap h ic R e p o rt^ ) Figure 5.15: C onstrained view of th e design activity hierarchy, in figure 5.14. T he constrain sub-com m and is for restricting th e view of a large project in to a sm all p o rtio n . For instance, if we w ant to view only th e hierarchy under th e design activity, we can constrain th e wbs at th a t node w ith th e num ber of d ep th level. Figure 5.15 shows a constrained wbs rooted a t th e design activity w ith five levels of depth. 154 Chapter 6 ! Conclusions and Future Research This d issertation presents a com plete m odel, th e D esignN et m odel, to de scribe th e p roject p lan an d m onitor th e p roject execution, an object-oriented approach to support th e m odel, an d an open and extensible p ro to ty p e system , th e D esignPlan system , based on th e m odel. In th e beginning, existing project m anagem ent approaches and related issues are investigated. Deficiencies or in adequacies w ith these approaches are th en addressed w ith respect to th e special requirem ents of th e software developm ent process. O n presenting the m odel, we sta rt w ith graphical representation, follow w ith a form al definition, verify its applicability by showing project characteristics im plied by th e m odel, and derive th e properties in analyzing behaviors of a p ro ject. O n realizing th e con cept, a generic object program m ing interface is defined, integ ratio n w ith higher level functional m odules is discussed, and a p ro to ty p e is im plem ented. T his ch ap ter addresses th e m ain contributions of this thesis and possible fu tu re research directions in this area. 6.1 R e su lts an d C o n trib u tio n s T hree m ajo r results are accom plished in this thesis. T h e D esignN et m odel, its underlying d atab ase su p p o rt, and th e D esignPlan p ro to ty p e system . These 155 results altogether co n trib u te to th e construction of an in teg rate d softw are project m anagem ent system . T he DesignN et m odel is a m odel for describing and m onitoring th e software I : developm ent process. This m odel utilizes th e A N D /O R g raph and P etri net no- | ta tio n to provide th e description of a project work breakdow n stru ctu re and th e ' specification of relationships am ong different project inform ation types(activity, p ro d u ct, resource, an d sta tu s rep o rt inform ation). Tokens are objects w ith spe cific properties. Token propagation thro u g h stru c tu ra l finks allows aggregate inform ation to be collected autom atically at different levels of detail. T he tra n sition firing is a nonvolatile process and creates new token instances w ith tim e dependent inform ation. T he ty p ed places, to g eth er w ith connections am ong th em , defines th e static construct of a project. W henever tran sitio n s are fired, th e project execution history is autom atically recorded by th e token instances created. U sing th e m odel, we have provided definitions for basic properties of a suc cessful p ro ject, nam ely connectedness, plan com plete, plan consistent, and well- executed. W e have given algorithm s for com puting these functions and shown th a t th e com puting tim e is linear in the size of the p roject. T his assures th a t any system based on D esignN et should be able to com pute these functions ef ficiently. Finally, we have shown how th e w aterfall life cycle m odel m aps onto a D esignN et an d th e im plications for project planning, cost estim ation, project netw ork construction, re-initiation of activities, an d traceab ility across th e life cycle. O th er life cycle m odels can be equally treated . In judging th e applicability of D esignN et, we w ould like to evaluate it w ith respect to th e requirem ents sum m arized in [Dowson87](a review of th e 3rd In te rn atio n al Software Process W orkshop). 156 • Capturing iteration'. B acktracking behaviors can be represented by back w ard transitions. T he project m anager can add transitions w ith appro p ria te sta tu s rep o rt places th a t loop back to earlier phases. Users are able to sim ulate any repetitive activities. • Reflecting decision changes and design evolution: T h e p ro ject p lan and th e history are kept separately in D esignN et. Any decision change or pro d u ct evolution triggers th e creation of new tokens th a t fu rth e r enable succeeding activities. T h e upw ard propagation of pro d u ct tokens through stru ctu ra l operators develops different pro d u ct hierarchies at various tim e. • Representing dependencies between the activities and objects: T yped de pendencies and changes are enforced by statu s rep o rt tokens connected before transitions. Defining m ore th a n one tra n sitio n in front of an activ ity specifies disjunctive dependencies. C onstraining th e wbs in to a p artial hierarchy is a m ean of p artitio n in g graphs in to subgraphs. E xam ining th e tra n sitio n arcs helps us in determ ining w hether changes are tra n sitiv e and w hat objects are affected. • Showing an executable representation of the software process: T he P etri n et n o tatio n itself is in an executable form . T he execution is driven by events occurred in th e software process. T he control flow depends on the enabled transitions. T he d a ta flow is recorded on tokens w ithin places. Com bined w ith the m ethod triggering technique of object program m ing, th e execution can be in a parallel fashion. In supporting th e m odel, an object oriented d atabase is used to m aintain th e entire project d a ta and keep track of th e project history. We first identified th e d a ta m anagem ent requirem ents related to softw are project m anagem ent. T h e object ty p e hierarchy an d th eir relationships are defined n ex t. T hen it is 157 show n how th e DesignNet concepts of th e w ork breakdow n stru ctu re, project history, event m onitoring, docum ent version control, and re-initiation of tasks are realized in a specific object-oriented system . B o th th e desired object prop erties and operations are described in details. L im itations of existing object oriented d atab ase system s are identified, w ith respect to im plem enting these concepts. T he D esignPlan p ro to ty p e is a realization of th e D esignN et m odeling con cepts. T he arch itectu re offers an open and extensible environm ent. A window oriented user interface is provided for th e user to define, access, modify, and graphically display th e work breakdow n stru ctu re of a project as well as th eir dependencies. A n object brow ser is im plem ented to allow th e navigation of object relationships and detail properties. H igher level tools are in teg rated into th e system via a generic object program m ing interface. Users can activate these tools th ro u g h th e com m on user interface. A d a ta export and im p o rt m echanism is proposed for th e in teractio n w ith existing tools. T his p ro to ty p e is an effort tow ard building an in teg rated software p roject environm ent. 6.2 F u tu re R esea rch D ir e c tio n s T he D esignN et m odel establishes an in teg ra ted platform for softw are project m anagem ent. W ith an open and extensible architecture, its applicability is n o t lim ited to th e current p ro to ty p e effort. Several interesting issues can be investigated in fu tu re researches. T he m ain focus here is how to achieve a fully in teg rate d com puter-aided software engineering environm ent(C A SE ). This section gives a few directions th a t th e DesignN et m odel or th e D esignPlan system can b e extended in th e future. 158 A n I n te llig e n t F ron t E n d Q u ery In terfa ce Since th e D esignN et m odel captures b o th th e project plan and th e execu tion history, users can analyze an d reason ab o u t th e p roject progress through queries. W e have show n a couple of query exam ples in answ ering various m an agem ent questions. These queries are presented in term s of th e underlying object program m ing interface. It is procedure oriented ra th e r th a n descrip tive. T his m ay not be ap p ro p riate for high level m anagers. T hus, a QBE- like[Zloof 75] or SQL-like user interface is necessary. T h e interface can provide a m ore in tu itiv e access to th e project inform ation. T h e user interface can also incorporate expert system approaches to assist th e project m anager in m aking decisions. Form ulating expertise from earlier m anagem ent experience in to rules provides m anagers advises for conducting a p roject. F urtherm ore, resource and schedule conflicts are norm al phenom ena in.m anaging large scale projects. Conflict resolution strateg y can b e considered in defining these rules. M o r e S o p h istic a te d R e so u r c e A llo c a tio n As p o in ted out in [Davis 83], resource allocation am ong m ulti-projects is a dynam ic program m ing problem . T here is no global optim al solution for m ulti p roject resource allocation. Several factors dom inate~the optim al allocation based on scheduling priorities. T here are at least eight factors one w ould try to optim ize. Some of th em conflict w ith each other. For instance, if we focus on m inim izing one p ro je c t’s schedule, other projects usually get prolonged. This is because resources are assigned to a p artic u la r project w ith higher priority w hen contention arises. If we try to reduce th e resource cost by selecting less expensive resources (e.g. novice program m ers vs. senior program m ers), some 159 i activities will be delayed due to th e lack of proficiency. O n th e o ther h an d , if we utilize th e m ost skillful staff first, th e load am ong resources w ould not be balanced. T h e current resource allocation strateg y of D esignPlan is in a first-com e- 1 * • ' first-service basis. T he first unoccupied resource th a t has th e desired skills is assigned in accordance w ith th e request. No a tte m p t is m ade to optim ize any factor of th e above criteria. However, due to its m odular design, th e resource allocation m odule can be redesigned independently to consider m ore sophisti cated cases. O ne possible extension is to let th e users specify preference orders. For exam ple, m inim izing th e p roject d u ratio n first, th e cost second, and th e load balance next. O ther hum an factors can also be tak en in to accounts, such as never assign th e sam e person for designing and testing th e sam e program m odule. I n te g r a tio n w ith V er sio n C o n tro l an d C o n fig u r a tio n M a n a g e m e n t S y ste m s Version control and configuration m anagem ent axe tw o crucial aspects of softw are design. W ith new versions of softw are, new features an d design changes can spaw n m any new releases. M aintaining several versions of th e sam e software is a m u st. O n configurations, po rtab le products are m ore plausible these days due to th e recent efforts in pursuing standardized execution environm ents. It is m uch easier to develop softw are th a t runs on m any system s th a n before. As a result, softw are runs on m ore configurations th a n ever. For exam ple, it is com m on for a spreadsheet package to ru n on a personal com puter or a m ultiuser system w ith eith er character-oriented term inals or b itm ap screens and m ouse pointing devices. M eanw hile, th e package m ay support a wide range of h ard copy o u tp u t devices, such as dot m atrix p rin ters, plotters, and laser printers. 160 D esignN et only provides th e version and configuration inform ation at the m anagem ent level. T he A N D /O R stru ctu ral operators p erm it th e specification of various configurations. T he token in stan tiatio n and pro p ag atio n m echanism keeps track of all versions generated. It is necessary for th e system to in teg rate w ith version control and configuration m anagem ent tools dealing at th e product level. T ow ard a D is tr ib u te d M a n a g e m e n t S y ste m It is com m on th a t m any authorities are involved in conducting a project an d m aking decisions inside an organization. Usually, resources and equip m ent are allocated by one d ep artm en t and products are controlled by another d ep artm en t. F urtherm ore, project personnel from different divisions partici p ate in different phases of th e developm ent cycle(e.g. pro d u ct is developed by th e engineering d ep artm en t and m aintained by th e custom er service d ep art m en t). T h u s, th e m anagem ent functions are perform ed by dispersed staffs. T h e goal of th e d istrib u ted m anagem ent here is not only to m ain tain th e phys ically d istrib u ted m anagem ent inform ation b u t also to accom plish th e logically d istrib u ted m anagem ent operations. T he token passing m echanism defined in DesignNet already provides a foun d atio n for th e d istrib u ted m anagem ent system . Tokens can b e encoded in elec tronic m ail form at an d transferred back-and-forth am ong th e netw ork. T he tran sitio n firing m echanism will signify relevant authorities w ith proper tokens w hen certain events occur. R esponsible personnel can th en react in response to these events. Incorporating an office au to m atio n system w ould m ake th e d istrib u ted m anagem ent goal come true. 161 Appendix A i I ‘ Syntax description of TDL and COP i T his appendix gives a brief description of th e TD L an d C O P language syn ta x . It only contains th e sy ntactic constructs th a t are required in un d erstan d in g th e exam ples given in this p ap er. Refer to [Ontologic 88] for a full description. T D L : O b je c t T y p e D e fin itio n L a n g u a g e TD L is a d a ta definition lan guage used to create a typing stru ctu re in th e d atab ase to serve as a conceptual schem a for applications. T h e basic form of an object ty p e definition is as follows d e fin e ty p e type-name s u p e r ty p e s = {type-name}; p r o p e r tie s = { prop-name: vspec-expr; }; o p e r a tio n s = 162 op-name(arg-name:vspec-expr,...,arg-name:vspec-expr) r e t u r n s (vspec-expr) r a is e s (exception-name) tr ig g e r s (trigger-name) m e th o d (method-name)\ }; e n d type-name; T he d e fin e ty p e type-name and e n d type-name clauses delineate th e be gin and end of a new object ty p e definition. T he supertypes clause is used to establish th e location of a new user-defined type in th e ty p e hierarchy, by speci fication of a direct supertype for th e new type. T he properties clauses establish properties for w hich instances of th e newly defined ty p e m ay have values. If a p ro p erty defined by some type is o p tio n a l, an instance of th e type can be created w ithout any value for th e property. If a property, p , is defined to be th e in v e rs e of an o th er property, q , then w henever th e value of q is established or dis-established, th e system u p d ates th e o th er appropriately. If we w ant th e inverse association to be from an individual elem ent of a set, th e d i s tr ib u te d reserved w ord can be included before th e valuespec expression. A n enum erative object is defined by th e e n u m reserved w ord followed by a list of elem ents in a p air of parentheses. T h e o p e r a tio n s clause provides nam es of operations w hich can be per form ed on instances of th e defined type, as well as a form al argum ent fist for 163 each operation, specifying argum ent nam es and value-specs. For a k e y w o rd argum ent, th e arg u m en t’s nam e determ ines which form al p aram eter it gets assigned to. T he keyw ord argum ents, passed during execution tim e, are insen sitive to th e position or th e order in w hich they appear. T he value retu rn ed by th e op eratio n is defined in th e r e t u r n s clause. A n e x c e p tio n can be raised at ; a certain p oint in th e flow of execution to indicate the existence of an error con dition. T h e nam e of th e o p eratio n ’s m e th o d is specified finally. T h e m e th o d i is an o p eratio n ’s im plem entation. It is a p o rtio n of C O P program w hich d eter m ines w hat th e operation should do and w hat object it should retu rn . C O P : C O b je c t P r o c e s s o r T he C O P language is an extended version of C ; th a t can m an ip u late V base d atab ase objects. A C O P program is a C program w hich has extended sy n tax for refering to types and objects defined in th e TD L. In a C O P program , an identifier is recognized as a d atab ase nam e if it contains a dollar-sign. T h e d atab ase nam e is a root-based p ath n am e in th e object type hierarchy. For exam ple, $Place$Activity$Cost refers to th e cost p ro p erty of th e activity object w hich is a subtype of place, as show n in Figure 4.6(a). A n enter module declaration establishes visibility for all nam es defined in a specified m odule. A n object variable is declared as o b j type idn[,idn...]; D atab ase properties can be accessed by appending th e p ro p erty nam e to an object variable, using dot n o tatio n , as id n .p ro p e rty -n a m e . T he constructor operators [ an d ] can be used to create a d atab ase object in an assignm ent form as idn = type$ [property-list]. 164 Appendix B A Graphic Oriented Vbase Object Type Hierarchy Browser B .l In tr o d u c tio n T his appendix describes th e operation of a V base1 object ty p e hierarchy brow ser. It is im plem ented as a subfunction u nder th e thesis p ro to ty p e . V base[O ntologic 87] is an object-oriented d atab ase system w hich supports object ty p e definitions for m odeling d a ta entities and language interfaces for building object-oriented applications. Designing an application system based upon V base is a tw o-stage task. T he hierarchy of th e object types an d th eir properties m ust be defined first by using th e T D L (T ype D efinition Language). T h e type hierarchy is analogous to the conceptual schem a of conventional d atab ase system s except th a t type definition contains m ore behavior descrip tio n for each object type such as m eth o d sr operations,-exceptions th a t can be raised, and triggers for integrity enforcem ent. To th e application system , only th e nam e of th e object an d th e functions th a t can m anipulate th e object are know n. T he provision of p ro p erty and operation inheritance is a distinct feature of object oriented d atab ase system s. 1 Vbase is a registered trademark of Ontologic Inc. 165 T h e application program design is accom plished th ro u g h language interfaces i em bedded in some host languages. C urrently, an extension of th e C language, called C O P (C language O bject Preprocessor), is provided. T D L com pilation a n d C O P developm ent are closely coupled since th e operations and procedures th a t m an ip u late objects m ust also be included in th e ty p e definitions. Since th e current release of V base does not support run-tim e ty p e definition u p d ate, any ty p e definition change m ust be done during th e TD L stage. R ecom pilation of th e application program is usually necessary for incom patible object type changes. M igrating existing object instances to new definitions also requires e x tra effort. Initially, th e object type definitions are in te x t file form at w ith TD L syn tax . However, users can exam ine th e type hierarchy in a m ore intuitive way via window oriented interfaces w ith m ouse and scrolling functions. From the u ser’s po in t of view, a graphical representation offers an im proved way to view com plicated stru ctu red object hierarchies. G iven such a tw o dim ensional rep resen tatio n , a graphical type hierarchy brow ser becom es necessary. T he object ty p e hierarchy brow ser th a t has been done is im plem ented under V base version 1.0. T h e user interface is im plem ented on X W indow version 10 release 4. T he interface takes advantages of th e b itm ap display and windowing m echanism . T he targ et m achine it runs on is a Sun 3/60. In section tw o, a scenario will guide you th ro u g h a set of operations th a t illu strate th e brow sing functions provided. T he sum m ary section addresses some experiences learned from th is im plem entation and possible enhancem ents. 166 B .2 D e m o n str a tio n S cen ario In th is section, you can assum e th a t you are sitting on front of a w orkstation w ith m ouse and keyboard to perform th e brow se function. V base has a set of predefined system types. Even if there is no user defined object ty p e, you can ! still browse th e system ty p e library. You will see some types defined by th e D esignPlan system in this scenario. These will be used as exam ples. Figure B .l shows th e pulldow n m enu of th e top level brow se function. You can see one of th e browse functions is th e TD L entry w hich is th e object type hierarchy brow ser. We can now execute th is com m and by pointing th e m ouse , to th e TD L en try and releasing th e m ouse b u tto n . A fter you select th e TD L brow se function, an o th er popup m enu is displayed to show th e to p level object types defined by th e user. T his is shown in figure B.2. T he last entry, input select;, is for the user to choose any predefined system object ty p e thro u g h keyboard in p u t. Suppose we would like to see th e object ty p e hierarchy rooted at th e $Place type, we can move th e m ouse dow nw ard to th e $Place entry and release th e b u tto n . T he ty p e hierarchy defined under $Place is shown in figure B.3. T h e hi erarchy is displayed as a tree stru ctu re from left to right on th e w orking area of th e screen. As you can see from th e hierarchy, $Place has tw o subtypes, $PlanPlace and $Token. Each subtype, in tu rn , has an o th er five subtypes defined. Now, suppose we w ant to view all the properties defined u n d er a p artic u la r object ty p e, we can place th e m ouse on th e type node and click a m ouse b u tto n . A te x t window will be popped up on the lower left corner of th e w orking area an d display all th e p ro p erty nam es w ith th eir associated value specification. 167 T h e view of th e $ P la c e properties is shown in figure B .4. I T he entire user defined object type hierarchy can be viewed by selecting each , of th e item s in th e TDL View popup m enu. To brow se predefined system types, we have to use th e input select com m and as show n in figure B.5. T he input i select com m and uses a one line dialogue box on th e b o tto m of th e screen. Figure J B.6 shows th a t we choose to view th e hierarchy of th e $Aggregate system type. Figure B.7 shows th e $Aggregate hierarchy. Since th e $Aggregate hierar chy has m ore levels th a n th e working area can display, tw o scrolling indicator boxes, one for th e left and th e o ther for th e rig h t, are shown on th e u pper right corner. By clicking th e m ouse b u tto n in th e right arrow box, th e $Aggregate hierarchy is shifted to lower levels of th e stru ctu re as show n in figure B.8. For hierarchies th a t do not fit in vertical direction, tw o o th er scrolling indicators, u p and dow n arrow s, will also be shown on th e u p p e r rig h t corner. W e can still display any object type definition of system defined types. Figure B.9 and B.10 show th e properties defined under th e $A rray an d $ S tack object types. So far, you have gone th rough all th e functions im plem ented for 1 object ty p e hierarchy browsing. B .3 In te r n a l D e sig n This section describes th e in tern al d a ta stru ctu res and algorithm s of the type hierarchy brow ser. T he d a ta stru ctu re definition is given in th e C language syntax. In order to avoid going into to o m uch detail, th e algorithm is presented is a higher level descriptive sy n tax rath er th a n in a specific language. Since th e design already considers a wide range of hierarchical stru ctu re, the d a ta stru ctu res and algorithm s presented here can be applied to o ther object 168 D e s i g n P l a n : A n O b j e c t - O r i e n t e d S o f t w a r e P r o j e c t M a n a g e m e n t S y s t e m Project WBS Dependency Event History G antt PERT Resource Quit B r o w s e TDL Forw ard Backward B r o w s e 05 C O Figure B.l: Functions available under browse com m and. I D e s i g n P l a n : A n O b j e c t - O r i e n t e d S o f t w a r e P r o j e c t M a n a g e m e n t S y s t e m Project WBS Dependency Event History G antt PERT Resource Quit T D L V ie w $Time {Transition input select: T D L V ie w gure B.2: Select either user defined object types o r predefined system types. D e s i g n P l a n : A n O b j e c t - O r i e n t e d S o f t w a r e P r o j e c t M a n a g e m e n t S y s t e m Project WBS Dependehcy Browse Event History G antt PERT Resource Quit SResource [SProduct $ProjectToken SResourceToken $ProductToken SToken JA ctivityToken SStatusToken SStatus SProject SActivity SPlace t- Figure B.3: Object type hierarchy rooted at $Place object. D e s i g n P l a n : A n O b j e c t - O r i e n t e d S o f t w a r e P r o j e c t M a n a g e m e n t S y s t e m Project WBS Dependency Browse Event History G antt PERT Resource Quit $ Activity SStatusToken SResource SPlanPlace SPlace SProductToken SPiojectToken SPioduct SToken SResourceToken SActivityToken $Status Type : SProject tokens: ProjectToken start: Time deadline: Time managedby: Person activity: Activity resource: Resource product: Product status: Status Press any button to continue t - Figure B.4: Properties defined under SProject object. I D e s i g n P l a n : A n O b j e c t - O r i e n t e d S o f t w a r e P r o j e c t M a n a g e m e n t S y s t e m Project WBS Dependency Event History G antt PERT Resonrce Quit T D L V ie w STime SPlace STransition input select: T D L V ie w CO t - Figure B.5: Select system type library through in p u t. t- rH D e s i g n P l a n : A n O b j e c t - O r i e n t e d S o f t w a r e P r o j e c t M a n a g e m e n t S y s t e m Project WBS Dependency Event History G antt PERT Report Quit Obejct type name: SAggregate Figure B.6: Choose to v ie w the SAggregate object type hierarchy. D e s i g n P l a n : A n O b j e c t - O r i e n t e d S o f t w a r e P r o j e c t M a n a g e m e n t S y s t e m Dependency Browse WBS Projeet Event History G antt Quit PERT Report SSUOD $Set SAssociation SQueue SObjString SDeque $List SOrderedDiction $Collection $Class SlnsertOrderDefi SStack SUnorderedDicti Figure B.7: Object type hierarchy rooted at $ Aggregate object. CO r - D e s i g n P l a n : A n O b j e c t - O r i e n t e d S o f t w a r e P r o j e c t M a n a g e m e n t S y s t e m Event Dependency Browse History Gantt WBS PERT Quit ' Project Report SDynariay SSet $SUOD SUnorderedDicti SQueue $IdentityDefined SSequence SlnsertOrderD efi SObjString SStack SDeque SD istributedSet SOrderedDiction $Class SList SRecoverySet SCollection Figure B.8: Scrolling t o the right o f the SAggregate hierarchy. D e s i g n P l a n : A n O b j e c t - O r i e n t e d S o f t w a r e P r o j e c t M a n a g e m e n t S y s t e m Event History Gantt Browse PERT Dependency Report Quit WBS Project SSUOD SSet Type : SStack ♦•Array Integer Integer Data: UBound: Stkptr: Cardinality: Integer Press any bntton to continue SStack SInsertOrderDefi SIdentityDefined SQueue SSequence SArray SUnorderedDicti $Bag SDeque SCollection $Class SList SOrderedDiction SAssociation t - t Figure B.9: Properties defined under $ Array object. oo t- rH D e s i g n P l a n : A n O b j e c t - O r i e n t e d S o f t w a r e P r o j e c t M a n a g e m e n t S y s t e m PERT History G antt Event Browse Report Dependency Quit WBS Project SSUOD $Set Type : {Array LowerBound: Integer UpperBound: Integer Data: frArray Cardinality: Integer Press any button to continue SArray SIdentityDefined {Collection {Class {Queue SlnsertOrderD efi {Association {Deque {Stack SOrderedDiction SList SUnorderedDicti Figure B.10: Properties defined under SStack object. D e s i g n P l a n s A n O b j e c t - O r i e n t e d S o f t w a r e P r o j e c t M a n a g e m e n t S y s t e m Project WBS Dependency Browse Event History G antt PERT Resource Quit SOperType SException SRecordType SType SSetOp SInitOp $CreateOp SGetOp 03 b- Figure B .ll: Object type hierarchy rooted at $Type object. typedef struct { char *Name; int x, y; int colcord, rowcord; int ChildSize; int ChildLimit; int *Children; unsigned char onscreen; unsigned char nodetype; unsigned char constrained; obj $Entity objref; } • TreeMode; Figure B.12: Tree node d a ta stru ctu re definition hierarchy as well. You m ay find some superfluous d a ta fields in th e d a ta struc tu re. These fields are introduced to accom odate m ore general applications. For instance, th e D esignPlan system allows a user to brow se th e work breakdow n stru ctu re(also in a hierarchical m anner b u t w ith m ore inform ation carried by each node) of a project. B .3 .1 D a ta S tr u c tu r e C entral to th e brow ser design is a tree representation schem e. E ach node in th e tree hierarchy m ust contain th e desired inform ation so th a t th e hierarchy can be constructed. T his includes th e node nam e to be displayed, th e actual coordinates on th e screen, children nodes references, special indicators for each node, an d a reference to th e object it represents. Figure B.12 shows th e node representation d a ta stru ctu re. T h e name field is a string pointer. Since V base does not have lim itatio n on string length, the nam e buffer is allocated dynam ically instead of a fixed size character array. 180 T he x an d y fields hold th e coordinates on th e screen in pixels. A n algorithm is designed to com pute th e coordinates depending on th e orientation(top-dow n or left-to-right). T he c o lc o rd and row cord fields contain th e v irtu al coordinates of nodes in an integer grid system (sim ilar to th e colum n and row position in a m atrix ). These two coordinates are useful in logical m anipulation versus the pixel valued coordinates. T he children nodes inform ation is stored in a dynam ic integer array pointed to by th e Children field. Since th e entire tree itself is also stored in a dynam ic tree node array, the index to th e tree array is used as a reference to a spe cific node. Using an array representation provides a fast and direct access to individual nodes. For efficiency reasons, th e dynam ic array is not reallocated w henever a new node is inserted. A llocating m em ory node by node will cause too m any small m em ory fragm ents and th e allocation tim e introduces too m uch overhead. In stead , a fixed size m ore elem ents are allocated w henever th e array is full an d a new elem ent has to be inserted. T hus, ChildSize field holds the size of th e children indices array allocated. Not all th e elem ents are used in th is array. T he ChildLimit has th e actual num ber of children nodes stored. M em ory reallocation is required only w hen th e ChildLimit value goes beyond th e ChildSize value. T hree flags axe defined on each node for special operations. T he onscreen is a true-false flag indicating w hether th e node is currently laying on th e screen display area. Since th e screen m ay accom odate only a sm all p a rt of th e hierar chy, this flag prevents us from searching through th e entire hierarchy w hen we try to locate a node on th e screen. T he nodetype is used to distinguish different node types if nodes are fu rth er classified. T his field is not used in th e type hi erarchy brow ser. T he constrained flag is used for subtree displaying purpose. W hen th e user chooses to display a subset of th e hierarchy, the nodes excluded 181 out by th e user are not actually pruned away from th e hierarchy. Instead, this flag is set accordingly so th a t th e user can still add in th e excluded nodes later. T h e o b j r e f field keeps th e object reference to th e represented object. W hen th e user needs to view m ore details of an object type, th is reference allows us to get a direct access to th e object. A nother m ethod is to use th e nam e string and calls th e ITS_Lookup routine to get th e correspondent object. However, this takes one m ore nam ing look up operation. T he hierarchy itself is defined as a dynam ic array of TreeNode elem ents as th e following statem ents. int TreeSize; int TreeLimit; TreeNode *Tree; B .3 .2 A lg o r ith m s T h e algorithm s of th e brow ser can be sequenced in four m ajo r phases. 1. C onstruct hierarchy w ith th e p aren t and children relationships. 2. C om pute th e v irtu al coordinates. 3. C om pute th e screen coordinates in pixels. 4. D isplay th e hierarchy and set up scrolling indicators. T h e first algorithm C o n stru ct_ T D L _ H ierarch y is a recursive algorithm th a t constructs th e object type hierarchy. Only th e p aren t and children relationships are set up at this stage. C oordinate inform ation can only be com puted after th e en tire hierarchy has been built up. Since it is possible to have an object 182 type defined as a subtype several levels below itself(e.g. th e SE ntity object ty p e), th e construction process can fall into an infinite loop if such recursive : definition is not detected. A stack is used to store th e p a th from th e root node to th e current node. If th e current node already appears in th e p a th , a recursive definition exists. T he algorithm should not derive th e sub-hierarchy below this , node. A lg o r ith m B . l C o n stru ct_ T D L _ H iera rch y (obj $Entity ent, obj $Integer parent) • global variables: Tree - dynamic hierarchy array pointer LastNode - pointer to the last node in the hierarchy local variables: ent - object reference of the node parent - parent node index [ current - current node index childent - current node object reference 1. [check for recursive definitions] i f current node appears on path stack th e n return; e lse insert current node on path stack; 2. [update the tree size] LastNode = LastNode + 1; i f exceeds the Tree array limit th e n reallocate the Tree array; 3. call ITS-G etN am e to get the object type name; 4- [update current node index] current = LastNode; 5. insert node information into Tree, initialize children dynamic array; 183 6. insert current node into parent node’s children list; 7. [construct recursively on subtypes] ite r a te (childent — ent.subtypes) C o n stru ct_ T D L _ H iera rch y (childent, current); . 8. pop out the current node from path stack; T he v irtu al coordinates com putation algorithm has two p arts. T he first p a rt C om pute_V irtual_C oord does th e initialization operations and th en calls th e second p a rt Align, th a t recursively com putes th e v irtu al coordinates in an interger grid system . T his process uses depth first traversing approach to determ ine th e row and colum n index of a node in a two dim ensional layout. A lg o r ith m B .2 C o m p u te_ V irtu a l_ C o o rd (current, curjrow, cur^col) global variables: Tree - dynamic hierarchy array pointer MaxRow,MaxCol - m axim um rows and columns allocated so far local variables: current - current node index curjrow - current node row index cur^col - current node column index 1. [initialize] MaxRow = MaxCol — 0. 2. [reset coordinates] for i = 1 to LastNode d o Tree [i].rowcord = Tree[i].colcord = 0. 3. [start up] curjrow = cur^col = 1. 4. [compute recursively] 184 A lig n (1, curjrow, cur.col). 5. [finished] MaxRow = currow - 1; MaxCol — MaxCol + 1; i A lig n (current, curjrow, cur^col) ; 1. [detect loopfif node already aligned t h e n return; i 2. [align current node] Tree[current] .rowcord — curjrow; Tree[current].colcord — cur_col; 3. [update m axim um column] if cur.col > MaxCol t h e n MaxCol = cur^col; 4. [advance to next row and column] cur.col = cur-col -f 1; cur_row = curjrow + 1; 5. [compute recursively on children nodes] fo r i = 1 to Tree [current], ChildLimit d o A lig n ( Tree]current]. Childrenfi], curjrow, cur_col); T he approach used to com pute th e screen pixel coordinates is analogous to th e one used to com pute th e virtu al coordinates. T he only difference is to u p d ate th e respective screen pixel coordinates w ith each node in th e A lig n routine shown above. T he algorithm is om itted here. T he last H ie ra rc h y .D is p la y algorithm is p retty straightforw ard. It exam ines each node to see if it is constrained. If it is not, th en check if it lies on th e screen. It yes, draw th e node and outgoing connection lines to its children nodes. T he o n s c re e n flag is also set accordingly. This flag will save th e node locating tim e since not all th e nodes appear on th e screen. A lg o r ith m B .3 185 H ie r a rc h y J D is p la y (W indow win) global variables: Tree - dynamic hierarchy array pointer LastNode - pointer to the last node in the hierarchy 1. [iterate through all nodes] fo r i = 1 to LastNode d o i f TreeNode[iJ.constrained = TRU E t h e n continue; e lse [check if node on screen] i f (%,y) or (x+nodewidth,y+nodeheight) is on screen th e n TreeNode[ij. onscreen = TR U E ; draw the node; [draw outgoing connections] fo r j — 1 to ChildLimit d o draw edge to TreeNode[i].Children[j]; B .4 S u m m a ry T he type hierarchy brow sing function im plem ented here provides a b e tte r visual display of th e object type stru ctu re. N evertheless, it can be enhanced to offer m ore pow erful functions thro u g h graphic operations. One simple enhancem ent is to show not only th e properties b u t also th e operations and procedures defined under a specific object type. However, this requires m ore knowledge of V base’s in tern al object representations. A nother valuable extension is to incorporate editing functions to allow user creation and 186 u p d ate of TD L definitions. These definitions are th en tra n slated into regular tex t file for TD L com pilation. Such a graphic TD L front end tool can reduce < users’ efforts dram atically for object type definition. I One experience which is w orth m entioning is how to ex tract th e top level user defined types from all object types. V base has a large num ber of predefined types. Users m ay not be in terested in these types in th e first place, b u t w ould . ra th e r view th eir own types directly. Since th ere is no im plicit way to achieve this, a new object type, called U serType, is introduced as a subtype of Type. It is defined as follows d e f in e Type U serType s u p e rty p e s = -C$Type3-; c la s s ty p e = e x p l i c i t C l a s s ; end U serT ype; T he user has to define h is/h e r object types using th e d e f in e U serType clause in stead of th e d e f in e Type clause. Figure B .l l shows th e type hierarchy of type $Type after introducing th e U serType type. T he U serType has an explicit class type. T he application(i.e. th e brow ser) can now itera te through th e user defined types. This m echanism has two draw backs. F irst, it requires u sers’ cooperation. T he second one, which is serious, is th a t U serType can only be applied to the direct types below the type $Type. Suppose th e user defines an enum eration type, for exam ple, 187 ! define Type Sex is enum (MALE, FEMALE); I this type is an instance of the $EnumType type which is at th e sam e level as th a t of $U serType(see figure B.10). An iteratio n of the U serType class would not catch this definition. Hopefully, this problem can be solved in a future release of V base. Bibliography [A fsarm anesh 85] A fsarm anesh, H., K napp, D ., M cleod, D., and P arker A. “A n E xtensible, O bject-O riented A pproach to D atabase for V L SI/ C A D ”, in Proc. of the Inter. Conf on VLDB, Aug, 1985. [Agresti 86] A gresti, W .W ., “W hat are th e new paradigm s” , New Paradigms for Software Development: Tutorial, IE E E C om puter Society, W ashington D.C. 1986, 6-10. [Andrews and H arris 87] A ndrew s, T im othy and H arris, Craig, “Com bining Languages and D atabase Advances in an O bject-O riented De velopm ent E nvironm ent,” Proceedings of A C M Conference on Object-Oriented Programming Systems, Languages and Applica tions, O ctober 4-8, 1987, O rlando, Florida, pp. 430-440. [Baker 72] B aker, F .T ., “Chief Program m er Team M anagem ent of P roduc tion P rogram m ing” , IB M Systems Journal, 11, n o .l, 1972. [Bernstein 87] B ernstein, Philip A. “D atabase System Support for Software Engineering — A n E xtended A bstract — ,” Proc. 9th Interna tional Conf. on Software Engineering, M arch 30-April 2, 1987, M onterey, California, pp. 166-178. [Boehm 81] B oehm , B arry W ., Software Engineering Economics, Prentice- Hall Inc., 1981. See also IE E E Trans, on Software Engineering, Jan . 1984. [Brown78] Brow n, John R . “ M odelling, M easuring, and M anaging Soft w are C ost” , Second Software Life Cycle Management Workshop, A ug., 1978. [Cohen 82] Cohen, P.R ., and Feigenbaum , E .A .,The HandBook of Artificial Intelligence, C h ap ter XV, Vol.3, W illiam K aufm ann, Inc. 189 [Coolahan 83] Coolahan, Jam es E. Jr., and Roussopoulos, Nicholas, “Tim ing R equirem ents for Tim e-D riven System s Using A ugm ented P etri N ets” , IE E E Trans, on Software Engineering, Vol.SE-9. N o.5. p p .603-616, Sept, 1983. [Curtis et al. 87] Bill C urtis, Herb K rasner, V incent Shen, and Neil Iscoe, “On B uilding Softw are Process M odels U nder th e L am ppost” , Proc. 9th International Conf. on Software Engineering, M arch 30- A pril 2, 1987, M onterey, California, pp. 96-103. [Davis and Vick 77] D avis, C.G . and Vick, C .R ., “T he Softw are Developm ent System ” , IE E E Trans, on Software Engineering, Vol.3. N o .l. pp.69-84, Jan ., 1977. [Davis and Vick 77] Davis, C.G . and Vick, C .R ., “T he Softw are D evelopm ent System ” , IE E E Trans, on Software Engineering, Vol.3. N o.l. pp.69-84, Jan ., 1977. [Davis 83] D avis, E.W . editor, Project Management: Techniques, Applica tions, and Managerial Issues, In d u strial Engineering and M an agem ent Press, 1983. [Donelson 76] Donelson, W illiam S. “P roject P lanning and C ontrol” , Datama tion, June, 1976. [Dowson 86] Dowson, M. “ISTA R — An In teg rated P ro ject Support E nviron m en t” , Proceedings of the A C M S IG S O F T /S IG P L A N Software Engineering Symposium on Practical Software Development E n vironments, p p .27-33, Dec., 1986. [Dowson87] Dowson, M. “Iteratio n in th e Software Process” , Proc. 9th In ternational Conf. on Software Engineering, M arch 30-April 2, 1987, M onterey, California, pp. 36-39. [E astm an 81] E astm an , C.M ., “D atabase Facilities for E ngineering D esign,” Proceeding IEEE, Vol.69, No.10, O ctober, 1981. [Fabrycky 84] Fabrycky, W .J., Charge, P.M ., and Torgersen, P .E ., Applied Op erations Research and Management Science, Prentice-H all, Inc., 1984. [Feldm an 79] Feldm an, Stuaxt I., “M ak e— A P ro g ram for M aintaining Com p u ter P rogram s,” Software Practice and Experience, M arch, 1979. [Goldberg 82] A. Goldberg, “Sm alltalk-80: T he interactive program m ing envi ro n m en t,” Xerox Corp., Tech. R eport, 1982. [Goldstein 77] G oldstein, Ira P. and R oberts, R. Bruce “N U D G E, a Knowledge- based Scheduling P rogram ” , in Proc. 5th Int. Joint Conf. Artif. Intell., 1977. [Horowitz 76] H orowitz, E. and Sahni, S. Fundamentals of Data Structures in Pascal, 2nd edition, C om puter Science Press, 1985. [Horowitz 86a] H orow itz, E. and W illiam son, R.C. “SODOS: A Software D ocu m entation Support Environm ent — Its D efinition” , IE E E Trans, on Software Engineering, Vol.SE-12. No.8. p p .849-859, Aug., 1986. [Horowitz 86b] H orow itz, E. and W illiam son, R .C . “SODOS: A Software Doc u m en tatio n Support Environm ent — Its Use” , IE E E Trans, on Software Engineering, Vol.SE-12. N o.11. p p .1076-1087, Nov., 1986. [Horowitz 85] H orow itz, E. and K em per, A. “A Survey of A pplication G ener ato rs” , IE E E Software, 1985. [Katz et al. 84] K atz, R.H., W . Scacchi, P. Subrahm anyam , “Developm ent E n vironm ents for VLSI and Softw are,” Journal of Systems and Software, 4, 13-26, 1984. [Katz 84] K atz, R andy H. “Inform ation M anagem ent for Engineering De sign” , Springer-Verlag Surveys, 1984. [Keider 74] K eider, Stephen P. “W hy P rojects Fail” , Datamation, Dec., 1974. [Kerzner84] K erzner, H. Project Manament, A Systems Approach to Plan ning, Scheduling, and Controlling. Van N ostrand Reinhold Com pany Inc., 1984. [Liu and Horowitz 87] Liu, L.C. and Horowitz, E. “A Form al M odel for Soft w are P roject M anagem ent,” Technical R eport CR I 87-41, Uni versity of Southern California, 1987. 191 [M acProject] M acProject for th e M acintosh, Apple C om puter C orp., C uper tino, Ca. 1986. [M artin 77] M artin, George, N. “P roject M anagem ent - P ro and C on” , Jour nal of Systems Management, Nov., 1977. [M asterplan 87] Masterplan Reference Manual, Q uality Softw are P ro d u cts, 1987. [McCracken] M cCracken, C.C. and Jackson, M .A., “A M inority D issenting O pinion” , Systems Analysis and Design - A Foundation for the 1980s edited by W . C otterm an New York, Elsevier, 551-553. [McLeod 83] M cLeod, D ., N arayanasw am y, K ., B apa R ao, K .V ., “A n Ap proach to Inform ation M anagem ent for C A D /V L SI A pplications” , Proceedings of the AG M -SIGM OD International Conference on the Management of Data, May, 1983. [Microsoft] M icrosoft P ro ject, M icrosoft Corp. Bellevue, W ashington, 1986. [M icrotrak] Softrak Inc. Salt Lake City, U tah 1986. [Minsky 75] M insky, M. A Framework for Representing Knowledge, (Ed. W inston), 1975. [Mylopoulos 80] M ylopoulos, J. “A n Overview of Knowledge R epresentation,” Proc. of Workshop on Data Abstraction, Database, and Concep tual Modeling, Pingree P ark , Colorado, June, 1980. [Nelson 83] Nelson, R obert A., H aibt, Lois M. and Sheridan, P eter B. “C ast ing P etri N ets in to P rogram s” , IE E E Trans, on Software Engi neering’ , Vol.SE-9. N o.5. p p .590-602, S ept,1983. [Norm an 84] N orm an, R .H ., “M anaging Software Developm ent P ro jects for M axim um P ro d u ctiv ity ”, IE E E Trans, on Software Engineer ing, Vol.SE-10. N o .l. pp .27-35, Jan ., 1984. [Ontologic 87] Vbase Technical Overview, Ontologic, Inc., M arch, 1987. [Ontologic 88] Vbase Technical Notes, Ontologic, Inc., February, 1988. 192 [Penedo 86] Penedo, M. H. “P rototyping a P ro ject M aster D ata Base for Software Engineering E nvironm ents” , Proceedings of the A C M S I GS OF T /S I GPL A N Software Engineering Symposium on Prac tical Software Development Environments, p p .1-11, Dec., 1986. 1 , [Peterson 77] P eterson, J.L . “P etri n ets” , A C M Computer Surveys, Sept., 1977. ■ [R am am oorthy 80] R am am oorthy, C.V. and G.S. Ho, “Perform ance Evalua tion of A synchronous C oncurrent System s Using P e tri N ets” , IE E E Trans, on Software Engineering, Vol.SE-6. pp.440-449, S ept,1980. ' [Rochkind 75] R ochkind, M arc J., “T he Source Code C ontrol System ” , Pro ceedings of the First National Conference on Software Engineer ing, IE E E , New York, 1975, p p .37-43. [Royce 87] Royce, W inston W ., “M anaging th e D evelopm ent of Large Soft w are System s” , Proc. 9th International Conf. on Software Engi neering, M arch 30-April 2, 1987, M onterey, California, pp. 328- 338. [Sacerdoti 74] Sacerdoti, E.D ., “P lanning in a H ierarchy of A bstraction Spaces” , Artificial Intelligence, Vol.5, no.2, p p .115-135, 1974. [Sathi 85] Sathi, A rvind, Fox, M ark S., and G reenberg, M ., “Represen tatio n of A ctivity Knowledge for P roject M anagem ent” , IE E E Trans, on Pattern Analysis and Machine Intell., Sept., 1985. f , [Scacchi 84] Scacchi, W . “M anaging Software Engineering P ro jects” , IE E E Trans, on Software Engineering, Vol.SE-10. N o .l. pp.49-59, Jan ., 1984. [Smith 77] Sm ith, J.M ., and Sm ith D .C.P. “D atabase A bstractions: Ag gregation and G eneralization,” A C M Transactions on Database Systems, pp. 105-133, June, 1977. [Stenning 87] Stenning, Vic “O n th e Role of an E nvironm ent,” Proc. 9th In ternational Conf. on Software Engineering, M arch 30-April 2, 1987, M onterey, California, pp. 30-34. 193 [Stonebraker 83] Stonebraker, M .R., et. al., “A pplication of A bstract D ata T ypes and A bstract Indices to CAD D atabases,” Proc. ACM SIGM OD Conference on Engineering Design A pplications, June, 1983. [SuperProject 86] Staff, SuperProject: Project and Resource M anagement Sys tem, C om puter Associates, 1986. [SuperProject 86] Staff, SuperProject: Project and Resource Management Sys tem, C om puter Associates, 1986. [Tate 77] T ate, A ustin “G enerating P roject N etw orks” , in Proc. 5th Int. Joint Conf. Artif. Intell., 1977. [Teichroew 77] Teichroew, D. and Hershey, E.A. “P S L /P S A : A C om puter- aided Technique for S tructured D ocum entation and A nalysis of Inform ation Processing System s” , IE E E Trans, on Software E n gineering, Vol.SE-3. N o .l. pp.41-48, 1977. [Thayer 84] T hayer, R.H ., P y ster, A.B. Special Issue on Software Engineer ing P roject M anagem ent, IE E E Trans, on Software Engineering, Vol.SE-10. N o .l. Jan ., 1984. [T hibodeau 78] T hibodeau, R obert and D odson, E.N . “T he Im plications of Life Cycle P hase Interrelationships for Software Cost E stim atin g ” , Second Software Life Cycle Management Workshop, Aug., 1978. [Tichy 85] Tichy, W .F ., “RCS — A System for Version C ontrol,” Software Practice and Experience, 15, 1985. [VUE] N ational Inform ation Systems [W inston 84] W inston, P atrick H., Artificial Intelligence, second edition, Addison-W esley, 1984. [Wong 79] W ong, S., W . B ristol, “A C om puter Aided Design D atab ase,” Proc. 16th A C M /IE E E Design A utom ation Conference, June, 1979. [Yau 83] Yau, Stephen S., and Caglayan, M ehm et U. “D istributed Soft ware System Design R epresentation Using M odified P etri N ets” , IE E E Trans, on Software Engineering, Vol.SE-9. N o.6. p p .733- 745, Nov, 1983. 194 [Zelkowitz 79] Zelkowitz, M arvin V., Shaw, A lan C. and G annon, John D. Principles of Software Engineering and Design, Prentice-H all, Inc.,1979. [Zloof 75] Zloof, M ., “Q uery by Exam ple” , in Proc. N C C y vol. 44, 1975. 195

Linked assets

University of Southern California Dissertations and Theses

Conceptually similar

PDF

Automatic code partitioning for distributed-memory multiprocessors (DMMs)

PDF

Automatic array partitioning and distributed-array compilation for efficient communication

PDF

A framework for coarse grain parallel execution of functional programs

PDF

A framework to support software system evolution.

PDF

A hierarchical knowledge based system for airplane recognition

PDF

A framework for supporting data integration using the materialized and virtual approaches

PDF

A learning-based object-oriented framework for conceptual database evolution

PDF

A unified model and methodology for conceptual database design and evolution

PDF

A federated architecture for database systems

PDF

Continuous media placement and scheduling in heterogeneous disk storage systems

PDF

A system for object-based conceptual schema evolution

PDF

An extensible object-oriented framework for engineering design databases

PDF

A unified approach to the construction of correct concurrent programs

PDF

Bayesian analysis of software cost and quality models.

PDF

An analysis of bit blitting and polygon clipping

PDF

An algebraic view of protection and extendibility in abstract data types

PDF

Spam e-mail filtering via global and user-level dynamic ontologies

PDF

Ontology-based semantic integration of heterogeneous information

PDF

Conflict identification and resolution for software attribute requirements

PDF

Algorithms for trie compaction

Asset Metadata

Creator Liu, Lung-Chun (author)

Core Title An integrated systems approach for software project management

Degree Doctor of Philosophy

Degree Program Computer Science

Publisher University of Southern California (original), University of Southern California. Libraries (digital)

Tag Computer Science,OAI-PMH Harvest

Language English

Contributor Digitized by ProQuest (provenance)

Advisor Horowitz, Ellis (committee chair), Gaudiot, Jean-Luc (committee member), McLeod, Dennis (committee member)

Permanent Link (DOI) https://doi.org/10.25549/usctheses-c17-771660

Unique identifier UC11347824

Identifier DP22778.pdf (filename),usctheses-c17-771660 (legacy record id)

Legacy Identifier DP22778.pdf

Dmrecord 771660

Document Type Dissertation

Rights Liu, Lung-Chun

Type texts

Source University of Southern California (contributing entity), University of Southern California Dissertations and Theses (collection)

Access Conditions The author retains rights to his/her dissertation, thesis or other graduate work according to U.S. copyright law. Electronic access is being provided by the USC Libraries in agreement with the au...

Repository Name University of Southern California Digital Library

Repository Location USC Digital Library, University of Southern California, University Park Campus, Los Angeles, California 90089, USA