design management & job assignment

7/28/2019 Design Management & job assignment

1/34

NPS CS-92-020NAVAL POSTGRADUATE SCHOOLMonterey, California

>

A Design Management and JobAssignment System

Salah M. BadrValdis Berzins

Approved for public release; distribution is unlimited.Prepared for:

Naval Postgraduate SchoolMonterey, California 93943

FedDocsD 208.1M/2NPS-CS-92-020


2/34

NAVAL POSTGRADUATE SCHOOLMonterey, California

REAR ADMIRAL R. W. WEST JR.. HARRISON SHULLSuperintendent Provost

This report was prepared for and funded by the Naval Postgraduate School.Reproduction of all or part of this report is authorized.

This report was prepared by:


3/34

CLASSIFICATION OF THIS PAGE DUDLEY KNOX LIBRARYt.AWM pnRTftRADUATE SCHOOLREPORT DOCUMENTATION PAGE MONTEREY CA 93943*1 ui

SECURITY CLASSIFICATION UNCLASSIFIEDCLASSIFICATION AUTHORITY

1b. RESTRICTIVE MARKINGS3. DISTRIBUTION/AVAILABILITY OP REPORTApproved for public release;distribution is unlimitedI F ICATIONVdOWNgRAdINg SCHEDULE

ORGANIZATION REPORT NUMBER(S)CS-92-020

s. MONITORS organisation REPORT NumBER(S)

OP ERFORMINg ORGANIZATIONcience Dept. 6b OFFICE SYMBOL(if applicable)cs7a. NAME OF MONITORING ORGANIZATION

Naval Postgraduate SchoolPostgraduate School

(City, State, and ZIP Code)CA 93943-5000

7b. ADDRESS (City, State, andZIP Code)Monterey, CA 93943-5000

ME OP FUNDING/SPONSORINGPostgraduate School

8b OPPICE SYMBOL(it applicable)

9. PROCUREMENT INSTRUMENT IDENTIF ICATION NUMBER

10 SOURCE OP FUNDING NUMBERS(City, State, and ZIP Code)CA 93943-5000

PROGRAMELEMENT NO.

PROJECTNO.

TASKNO.

WORK UNITACCESSION NO.

(Include Security Classification)A Design Management and Job Assignment SystemAUTHOR(S) SALAH M. BADR, VALDIS BERZINS'

OF REPORT isb. TIME COVEREDfrom 05/89 to 03/90

15. PASE COUNT25EMENTARY NOTATION

14. DATE OF REPORT (Year, Month, Day)December 1992

COSATI CODESGROUP SUB-GROUP

18. SUBJECT TERMS (Continue on reverse if necessary and identify by block number)SOFTWARE EVOLUTION, JOB ASSIGNMENT, DESIGN DATABASE,EVOLUTION STEP, SOFTWARE PROTOTYPING.(Continue on reverse if necessary and identify by block number)This report introduces the basic approach taken in designing the designand job assignment system (DMJAS)for CAPS93. This approach uses aof software evolution [8] which defines how a software change, once hasapproved, will be applied to the software release (version) to produceversion of the software incorporating this change. This process isan evolution step. The proposed system represents a management layerthe user interface (supporting two user classes, managers and design-and the design database. The DMJAS controls the software evolution pro-in an incrementally evolving software system where The job steps to beare only partially known: time required, the set of sub-tasks forstep, and the input/output constraints between steps are all uncertain,are all subject to change as steps are carried out. Models of design data-and manager/designer interface are explained followed by the proposed

TRIBUTION/AVA ILAB I LITY OP AB5TRAC1Q SAME AS RPT. Q DTIC USERSLEIND,VIDUAL

21. ABSTRACT SECURITY CLASSIFICATIONUNCLASSIFIED22b. TELEPHONE/7nc/ude>4?a Code)(408) 656-2903 22C.OFFICE SYMBOL

1473, 84 MAR 83 APR edition may be used until exhaustedAll other editions are obsolete

SECURITY CLASSIFICATION OF THIS PAGEUNCLASSIFIED


4/34


5/34

A Design Management and Job AssignmentSystem 1Salah Badr

Valdis BerzinsNaval Postgraduate School

Department of Computer ScienceMonterey, California 93943-5100 USA

ABSTRACTThis report introduces the basic approach taken in

designing the design management and job assignment system(DMJAS) for CAPS93. This approach uses a model of softwareevolution [8] which defines how a software change, once hasbeen approved, will be applied to the software release (ver-sion) to produce another version of the software incorporat-ing this change. This process is called an evolution step.The proposed system represents a management layer betweenthe user interface (supporting two user classes, managersand designers) and the design database. The DMJAS controlsthe software evolution process in an incrementally evolvingsoftware system where The job steps to be scheduled are onlypartially known: time required, the set of sub-tasks foreach step, and the input/output constraints between stepsare all uncertain, and are all subject to change as steps arecarried out. Models of design database and manager/designerinterface are explained followed by the proposed system.KEYWORDSSOFTWARE EVOLUTION, JOB ASSIGNMENT, DESIGN DATABASE,EVOLUTION STEP, SOFTWARE PROTOTYPING,SOFTWARE ENGINEERING.

1. Introduction"The Computer Aided Prototyping System (CAPS) , an inte-

grated set of computer aided software tools, has been1. This research was supported in part by the Army Research Office under grant number ARO-145-91

A Design Management and Job Assignment System January 1993


6/34

designed to support prototyping of complex software systems.CAPS can increase the leverage of the prototyping strategyby reducing the effort of the designer puts into producingand adapting a prototype to perceived user needs." [7]

In the context of the CAPS system, there are three mainentities that interact to develop a software system. Thesemain entities are the project manager, the CAPS system, andthe software designers. Currently CAPJ92 has only two of thesemain entities: the designer and CAPS system. The designer canselect a tool, then select a prototype to work with. Thedesigner can commit his work to the design database wheneverhe wants. When a designer is modifying a prototype no otherdesigner can access the same prototype for modification. Cur-rently CAPS does not have any mechanisms for coordinatingparallel efforts by different designers. This paper presentsthe design of such a mechanism for C^PS93.

The inter-relation between these three main entities inCAPS93 is depicted in figures 1, 2, and 3 . The project managershould be able to enter/edit description of top level evolu-tion steps. An evolution step has many properties andoperations such as base version, change description, primaryinput, initial conditions, commit, abandon/suspend, and anyoptional data such as priority, or deadlines. The manager


7/34

should be able to monitor and control all the activities ofthe development team through making all the control informa-tion accessible to him such as the incremental task scheduledescribing who is supposed to do what and when. The Managercan act as a designer and can be assigned some developmenttasks

.

rManager

Change ListSuspend ListIncremental Sch.Assign Task

Base VersionChange descriptionPrimary inputInitial ConditionsCommitAbandon/SuspendOptional data.

FIGURE 1 . The DMJAS Manager InterfaceThe designer interface with the DMJA system is simplified

to keep the designer's attention on doing the tasks assignedto him. This interface can assign tasks from the system to thedesigner and gets back his commit response. Designers can workon parallel on different tasks related to the same software

A Design Management and Job Assignment System January 13, 1993


8/34

version, or on the same task splitting different variations(alternatives) .

Assign TaskRelease Task

CommitSuspendRelease

FIGURE 2 . DMJAS Designer InterfaceVersion control and design management are also part of our

contribution as tasks of the DMJA system as well as preservingdata consistency through propagating change consequences. Insection 2 some concepts used in the database schema for ourwork are defined. A comparison to the previous work is pre-sented in section 3. In section 4 the underlying design

database is defined. Sections 5 and 6 introduce both thedesigner and manager interfaces. The CMJA system is presentedin section 7. Finally conclusions and suggestions for futurework are presented in section 8.



9/34

2. DefinitionsSince the DMJAS is a management layer on top of the

design database, it gets most of its input data and sendsmost of its output data from/to the design database. It logsthe evolution steps with their relevant information to thehistory log, assigns variation and version numbers to thenew versions resulting from applying the evolution steps,queries the design database for the decomposition as well asthe dependency relations between different objects, copiesthe tasks to be modified to the assigned designer's workarea, and controls commitment of completed modifications tothe database. The underlying database schema for our work

includes the following concepts [8]:An object is a software component that is subject tochange. Objects can be either composite or atomic. Objectscan be changed only by creating new versions. Object is ageneralized type with many specialized subtypes that caninclude requirements, specifications, designs, code, testcases, etc.A version is an immutable snapshot of an object. Versionshave unique identifiers. New versions can be created, but

versions cannot be modified after they are created.



10/34

A variation of an object is a totally ordered sequence ofversions of the object which represent the evolution his-tory of an independent line of development.An evolution step represents the activity of creating a newversion of the source description of a software object.Evolution steps usually require creativity and humaneffort from the manager responsible for the step.

A software component or step is composite if it can beviewed as a collection of related parts, and is atomic oth-erwise.A top level Evolution Step represents the activity of ini-tiating, analyzing, and implementing a change request inthe system.

X uses Y: a relationship that is true if and only if thesemantics or implementation of one software object Xdepends on another software object Y [4],X used-by Y: same as Y uses X.

3. Previous WorkAccording to [11] representations of the versioning pro-

cess can be classified into two main models. The first modelis the conventional Version Oriented Model VOM in which a



11/34

system is divided into modules each of which is versionedindependently from the other modules. To configure a systemone has to select a version of each module of the system.This makes version a primary concept while change is a sec-ondary concept as a difference between versions. Both SCCSand RCS belongs to this model.

The second model is the Change Oriented Model COM. Inthis model the functional change is the primary concept.Versions are identified by a characteristic set of func-tional changes. To configure a system in this model one hasto select a set of mutually compatible functional changes.Versions in this model are global, meaning that to examine amodule one has to specify a single version of the systemfirst, then proceed to the required module. On the otherhand, in a VOM system, to examine a module one has to selectthe module first then individually select which version ofthis module is the target. Our work utilizes concepts fromboth models. A set of a changes to a base version of a soft-ware system leads to the versioning of both the individualobjects involved in the changes and also acts on the entiresoftware system producing a new release (version of thewhole system)

.


12/34

According to Kaiser and Perry [12] the main tools thatpropagate changes among modules are the following. However,none of these support the enforced model of cooperationamong programmers necessary for large maintenance/evolutionprojects or automatically assign tasks to programmers:Make: a UNIX tool that rebuilds the entire software system.It invokes the tools specified in the ^makefile' on changedfiles and their dependent files. Make is used for regener-ating up to date executables after source objects have beenchanged.Build: is an extension to make that permit various users tohave different views of target software system. A *view-path' defines a series of directories to be searched bymake to locate the files listed in the makefile.Cedar: the Cedar System Modeler uses an advanced version ofthe Make tool with version control to invoke the tools on aspecific versions of files. This System informs the^Release Master' , a programmer, about any syntactic inter-face errors. The Release Master is responsible for makingwork arrangements with responsible programmers.

A Design


13/34

DSEE: the Apollo Domain Software Engineering Environmentalso uses a Make-like tool with version control. DSEE alsohas a monitoring facility that permits programmers and/ormanagers to request to be notified when certain modules arechanged.Masterscope: Interlisp's Masterscope tool maintains cross-reference information between program units automatically.It also approximates change analysis of potential inter-ference between changes by answering queries about syntac-tic dependencies among program units.SVCE: the Gandalf System Version Control Environment per-forms incremental consistency checking across the modulesin its database and notifies the programmer of errors assoon as they occur. The consistency checking is limited tosyntactic interface errors. It supports multiple program-mers working in sequence but does not handle simultaneouschanges

.

Kaiser and Perry [12] also describe Infuse, a system thatautomates change management by enforcing programmers cooper-ation to maintain consistency among a sequence of scheduledsource code changes. Infuse automatically partitions thesemodules into a hierarchy of experimental databases. Thispartitioning may be done according to the syntactic and/orA Design Management and Job Assignment System January 13, 1993 9


14/34

semantic dependencies among the modules or according toproject management decision. Each experimental database pro-vides a forum for the programmers assigned to its modules ortheir managers, and provides also for consistency checkingamong those modules (meaning that the interface between themodules must be correct and that the modules can compile andlink successfully) . Consistency checking among the experi-mental database modules is a pre-condition for merging adatabase back to its parent experimental database. Infuseautomatically partitions the database into experimentaldatabases but programmers are assigned to the these data-bases manually. In our system tasks are assigned directly to

designers (programmers) according to their (uses) dependen-cies. Versions are generated automatically as soon as thework is done. Syntactic and semantic consistency checkingfor source code can be implemented by associating declara-tions of consistency constraints with steps, and triggeringthe required checking actions as part of the commit proto-col .

4. Design DatabaseThe main goal of the CMJA system is to provide automated

design data support for software development through allphases of the software life-cycle and to provide bilateralA Design Management and Job Assignment System January 13, 1993 10


15/34

communication between designers/programmers [7] as well asproviding for the management control over all the ongoingactivities. Keeping this objective in mind besides complyingwith both the Graph Model Of Software Evolution [8] and theANSI/IEEE standard [5], the design data base should have thefollowing characteristics [7] Minimize the communication time between designers/program-mers through keeping the development documents on-line.

Propagate change consequences to maintain the global con-sistency of the database.

Produce nondisruptive status reports for an ongoingproject

.

Provide a way of tracking the development history via keep-ing an up-to-date history file on-line that has all thedesign decisions and all relevant information to develop-ment history.

Support planning and scheduling any proposed changes/main-tenance by keeping the relationship between different dataobjects.

Support software reusability to save both cost and effort.

The proposed system will take care of the followingfunctionA Design Management and Job Assignment System January 1


16/34

Propagate change consequences. Schedule evolution and maintenance tasks to maximize con-currency and minimize rollbacks.

Record development history. Provide version and configuration management.

The interface between the DMJAS and the design databaseis illustrated in figure 3.

DMJASCreate Mutable CopyDecomposeUses, Used-byRead/ Add VersionCommit

FIGURE 3. The DMJAS Design Database InterfaceThe design database is divided into two main parts:

Shared data space where the frozen software objects arestored, and

Private workspaces where the development of new softwareobjects/versions takes place.



17/34

4.1 Shared data spaceThe shared data space is the repository that keeps all

of the verified software objects (versions or configura-tions) [5] . The versions in the shared data space are frozenand may not be changed under any circumstances. Any changesto any of the objects must be authorized by the managementand this will produce new versions. The shared data spacecontains the public releases of the software objects andthese objects may be checked out in write-protect mode only.The relations between the objects in the database are kept ina form accessible to the design management and job assign-ment system (DMJAS)

.

4.2 Private workspacesSince the data in the shared data space is frozen and

may not be changed, the private workspaces are used for pro-duction of new versions of existing objects or adding newobjects to existing software systems.

The mutable data contains a copies of the specific ver-sions of the software to which the changes are to be imple-mented (base versions) . Only the designer responsible for anevolution step has access to the mutable copy of the baseversion in that designer's private workspace. The process ofcopying objects to and from the designer's workspace is doneA Design Management and Job Assignment System January 13, 1993 13


18/34


19/34

pended task to the suspend log, and does not assign thedesigner any more tasks until he releases the suspended oneand commits it. (Such cases may happen if a designer takes ashort leave and his work may not affect the rest of the team,otherwise the manager should appoint someone else to do thejob) .

A typical scenario illustrating the operation of thedesigner interface follows. A designer Dl receives a messagefrom the system that he has been assigned a task Tl withinformation about the parent step, whether these tasks areprimary or induced, the specification of the changesrequired, and the time of the assignment. When Dl is ready tocommit his task he would invoke the system and commit thetask which may lead to another assignment if there is any.The designer can also receive messages from the DMJASdirecting him to abandon a task or to suspend activity on atask and switch to some other task. Such messages areresponses to policy decisions made by the project manager.

6. Manager InterfaceThe manager interface is a super-set of the designer

interface. Change requests are analyzed and entered into theDMJAS through the analyst's interface, which is beyond the

A Design Management and Job Assignment System January 1993 15


20/34


21/34

sub-steps for any management reasons. As a designer themanager can be assigned an object, edit it and commit it.Figure 1. shows the DMJAS Manager interface.

7. A Design Management and Job Assignment System(DMJAS).

The design management and job assignment system rep-resents a management layer between the interfaces to manag-ers, analysts, and designers, and to the design database.The DMJAS controls the software evolution process in anincrementally evolving software system with the followingspecial characteristics:

a. The job steps to be scheduled are only partially known:time required, the set of sub-tasks for each step, and theinput/output constraints between steps are all uncertain,and are all subject to change as steps are carried out.b. The method must support incremental replanning as addi-tional information becomes known, and it must minimizelost work due to reorganization of the schedule as well asworkers forced to wait for completion of sub-tasks in thisuncertain environment.

A Design Management and Job Assignment System January 13, 1993 17


22/34

c. Rescheduling of some jobs is required if new dependencyconstraints arise during scheduling of new jobs whichneeds the completion of the newly scheduled job beforealready scheduled (in-progress) jobs. This will lead tothe suspension of the dependent jobs and rescheduling themaccordingly. This function must be integrated with thedesign database access protocol because rescheduling canimply restarting an ongoing job step on different versionsof its input objects (documents)d. Allocation of agents (designers) can vary to fulfill thedeadline constraints, and in response to changing esti-mates of the effort required for each step.e. For those jobs that do not have a deadline the systemshould provide for earliest possible completion subject tothe other constraints.f. The goal is to determine and carry out a feasible sched-ule that meets the deadline requirements, provides formaximum concurrency, reduces/avoids rollbacks, and insuressystem integrity, while minimizing the amount of detailsthat must be explicitly considered by the project manager.

The functions of the proposed system are concerned withthree main tasks: version control, job scheduling and jobassignment. This system is intended to support a prototypingA Design Management and Job Assignment System January 13, 1993 18


23/34


24/34

a. decompose them if they are composite byquerying the database for the image in thedecomposition relation. andb. find the induced changes by querying thedatabase for the used-by relation for eachinput object resulted from step a above.c. 'repeat step a, b until no further objectsare found.d. check if any of the above objects is"used-by" any of the objects of the ongoingchanges (by any of the previous evolutionsteps that is not committed yet) . If any isfound either issue a warning to the manageror suspend the corresponding step accordingthe policies specified by management (auto-suspend or warning)

.

Build the dependency acyclic graph of the resultingobjects from step 3.

Build the lists of the changes that can be done concur-rently and the dependencies between these changes. Displaya copy to the manager [as a dependency graph]

.

Assign the objects to the designers according to the fol-lowing:

a. The author of each object.b. Names of the designers, andc. The status of the designer [free or busy]

.

d. If list X2 depends on list XI start byassigning the objects of list XI, aftereach object in XI is committed, check if anobject in X2 can be assigned, if so assignit, as soon as the objects of list XI are com-

A Design Management and Job Assignment System 20


25/34

mitted, assign the remaining objects of listX2, and so on.

Commit the step: as soon as all the objects of a top levelevolution step are committed and according to the speci-fied management policies either:

a. commit the step generating a new versionof the software, orb. Notify the manager that all the modifica-tion are done and ask for permission to com-mit .

Respond to the manager commands commit, suspend, abandonwith the corresponding action.

a. commit: commit the step generating a newversion by changing the mutable data toshared data space and update the history fileby the date and time the version is commit-ted.b. Suspend: by copying the modified data tothe suspended log with the reason why? andkeep the version labeling.c. Abandon: by copying the modified data tothe abandoned log with the reason why? andrelease the version labeling.d. Respond to the designer commands with thecorresponding action: a. "Suspend" by copyingthe suspended object to suspend log. b. "Com-mit" by copying the object back to the muta-ble database and check it done. c. "Release"by releasing the suspended object if there isone and copying it back from the suspendedlog to the designer's work area.

7.1 Management IssuesThe DMJAS partially automates most of the management

functions whether they are design data management or human

A Design Management and Job Assignment System January 13, 1993 21


26/34

management (design team) . The proposed system automaticallycreates mutable software versions in the private workspacesfrom the immutable base version, automatically constructs

breakdowns of evolution steps to their atomic componentsboth primary and induced, incrementally assigns tasks todesigners and keeps track of which jobs are assigned to whichdesigner, when assigned and when committed. This informationis available to the software manager who can judge the status

of the project and the productivity of the team. The systemalso automatically produces the new versions or splits offnew variations depending on the base version.

7.2 Job SchedulingJob scheduling is completely automated since the sys-

tem builds the dependency graph, prepare the dependencylists and assign a task to each designer based on his status,and his name. A task is chosen for a designer if he is notbusy and the priority goes to the task with his name as theauthor if there is one, otherwise to the task with the maxi-mum "used-by" relations (to release as many dependency con-flicts as possible) . As soon as a designer is done with atask by committing it he will be assigned another task on thesame basis. The committed task is checked done, its committime is recorded and its dependency relations are released.A Design Management and Job Assignment System January 13, 1993 22


27/34

The suspension of jobs because of dependency conflicts isdone automatically and those jobs are copied to the sus-pended log, the corresponding designers are assigned newjobs. These suspended jobs are placed in the correspondingdependency list to be assigned later. When a suspended job isassigned again it is copied from the suspended log back, tothe assigned designer's work area, and the validity of thesaved work is determined based on whether the input docu-ments were bound to new versions since the time when the jobwas suspended and the version bindings for its inputs werereleased.

8. ConclusionOur design management and job assignment system is a

design management layer between the manager/designer inter-face and the design database that contains all the projectsoftware objects. The goal of this system is to help theproject management to efficiently direct the efforts of thedesign team and to assure data consistency by propagatingthe change consequences to all the affected objects, auto-mating the identification of implied sub-steps, automatingjob assignment and keeping track of the activity of eachdesigner so the project manager can watch the progress of theteam closely and determine when corrective actions become


28/34


29/34

LIST OF REFERENCES

[ 1] Berzins and Luqi, "Software Engineering with Abstractions", Addison-Wesley 1990

[ 2] Borison E., "A Model of Software Manufacture", in Advanced ProgrammingEnvironment, Springer-Verlag, 1986, pp. 197-220.

[ 3] Feldman S. I., "Software Configuration management: Past Uses and FutureChallenges" Proceedings of 3rd European Software Engineering Conference,ESEC '91, Milan, Italy, October 1991

[ 4] Heimbigner D. and Krane S., "A graph Transform Model for ConfigurationManagement Environments", Proceedings of the ACM SIGSOFT/SIGPLAN, Nov. 28-30, 1988.

[5] "IEEE Guide to Software Configuration Management", Std 1042-1987,American National Standards Institute/IEEE, New York, 1988.

[ 6] Ketabchi M. A., "On the Management of Computer Aided DesignDatabase", Ph. D. Dissertation, University of Minnesota, Nov. 1985.

[ 7] Luqi, "Software Evolution Through Rapid Prototyping", IEEE Computer 22,5. May 1989, pp 13-25.

[ 8] Luqi, "A Graph Model for Software Evolution", IEEE Transaction onSoftware Engineering. Vol. 16. NO. 8. Aug. 1990[ 9] Mostov I., Luqi, and Hefner K., "A Graph Model for Software

Maintenance", Tech. Rep. NPS52-90-014, Computer Science Department,Naval Postgraduate School, Aug. 1989.

[ 10] Narayanaswamy K. and Scacchi W., "Maintaining Configuration of EvolvingSoftware System", IEEE Trans, on Software Eng. SE-13,3. Mar. 1987, pp.324-334.

[ 11] Lie A. et al, "Change Oriented Versioning in a Software EngineeringDatabase", Proceedings of 2nd International Workshop on SoftwareConfiguration Management, Princeton, New Jersey, Oct. 24,1989. pp. 56-65.

[ 12] Kaiser G. E., and Perry D. E., "Workspaces and Experimental Databases:Automated Support for Software Maintenance and Evolution", Proceedingsof IEEE conference on Software Maintenance 1987. pp. 108-114.

[13] D. Dampier, "A Model for Merging Different Versions of a PSDL Program",MS thesis, Computer Science, Naval Postgraduate School, June 1990.

[ 14] D. Dampier, Luqi, "A Model for Merging Software Prototypes", TechnicalReport, CS, NPS, 1992.


30/34


31/34


32/34


33/34


34/34

design management & job assignment

Documents