a mvp-l solution for the software–process …mvp–l is a prototype process speciﬁcation and...

A MVP-L Solutionfor the

Software–Process Modeling Problem�

Christopher M. LottMarcos Pantelis

H. Dieter RombachDepartment of Computer Science

University of MarylandCollege Park, Maryland 20742

Tel.: (301) 405-2707Fax: (301) 405-6707

E-mail address: [email protected]

Presented at ISPW-7, Yountsville, CA, October 1991

AbstractThis paper gives a solution in MVP–L to the Software Process Modeling Example Problem

that was presented at the 7th International Software Process Workshop. MVP–L is a prototypeprocess specification and design language developed as part of the MVP project at the Universityof Maryland. The solution presented here is a revision of the solution submitted for ISPW–6according to the extensions requested by the program committee for ISPW–7. Changes inthe language and the previous solution are discussed, and some future changes to MVP–L areoutlined.

1 Introduction

The MVP project at the University of Maryland focuses on methods for developing, representing, andusing software process models in the context of the quality improvement paradigm [1, 2]. MVP–Lis a prototype process representation language developed as part of the MVP project. The languagewas designed to enable specifying and designing real-world software processes, packaging processesinto reusable models, instantiating models in the context of new project plans, analyzing projectplans, and enacting project plans to guide projects [7].

The MVP–L solution presented in this paper is a revision of the solutionsubmitted for ISPW-6 [4].This revision reflects some recent changes in the representation language as well as changes madeto the example problem. Both kinds of changes are discussed in this paper. Finally, possible futurechanges to MVP–L that were motivated in part by the ISPW–7 problem are outlined.

2 Changes Since ISPW–6

We made a number of changes to the MVP–L language that were motivated by our work on theISPW–6 solution as well as other efforts [8, 3]. We included new features to increase the expressive

�Funding for this project was provided in part by the National Science Foundation under grant CCR-9057874.

1

power of MVP–L, as discussed in Section 2.1, and formalized the intuitive state-based executionsemantics by defining the notions of state and state transitions, as discussed in Section 2.2.

2.1 New features

A number of new features were implemented in MVP–L to increase the expressive power of thenotation. Foremost among these is the development of attribute model types. We also inventedproject plan objects, refined the specification of data dependencies in process model types, and addedinstantiation parameters.

2.1.1 Attribute models

The most significant addition was the development of attribute model types. Attribute models aretype descriptions for measurable characteristics of product, process, and resource models. Eachattribute model specifies a type and a manipulation for an attribute. Sample types are integers, reals,and enumerated values. The manipulation section defines the possible changes in the attribute value.For example, a “process status” attribute model may defined with an enumerated type that specifiesvalues such as “disabled” and “enabled active.” In the manipulation section of the attribute model,the status value can be updated in response to events or invocations predefined by the language.Possible events are the entry criteria of the process becoming true or false. Possible invocations areuser requests to start or complete execution of the process.

Attribute models define legal values for attributes and thereby legal project states. These typesformalize the state transitions for values of elementary model attributes by specifying the legalmanipulations of those attributes, and thereby make automated analysis of project plans possible.Attribute model types are represented separately from other elementary models so that elementarymodels can share attribute types. An example of an attribute model that captures status informationfor products appears in Figure 59 on page 40.

In order to facilitate the use of attribute model types, an “imports” section was added to productand resource model specification parts and to process body refinement parts. (This section alreadyexisted in process specification parts.) The imports section names those model types that will beused in that model.

2.1.2 Project plans

The second, major addition to MVP–L was the introduction of a “project plan” object. Project plansprovide for the description and instantiation of complex process models, and are the only enactableMVP–L objects. A project plan is not a type description, like a process, product, or resource model,but an object that provides the context for enaction of process objects by supporting the instantiationof process objects and the binding of product objects to formal interface parameters of processobjects. In the previous version of the language, we did not explicitly provide a context for processenaction. The project plan object for our solution appears in Figure 2 on page 8.

2.1.3 Instantiation vs. enaction

The addition of a project plan allows us to distinguish clearly between instantiation and enaction.Instantiation refers to the creation of process, product, or resource objects in the context of a projectplan or process model. For example, a document object may be instantiated in the context of a projectplan or any process model. Enaction refers to the execution of a project plan for analysis or processguidance. In Figure 2, the objects declared in the “objects” section are instantiated in the context ofthe project plan, and the project plan may be enacted.

2

2.1.4 Data dependencies

Process models in MVP–L describe data flow using the “consume produce” section and data de-pendencies other than data flow using the “context” section. The “context” section was addedto emphasize the representation of data dependencies in the model as distinct from data flow de-pendencies. A process model type for the top level, named “Technical Steps,” appears followingpage 19.

2.1.5 Instantiation parameter

The third significant change was the addition of an instantiation parameter to process, product, andresource models. This facility provides a small part of the functionality of general type hierarchies.An instantiation parameter allows customization of a model type by specifying a (possibly empty)list of attribute values that are referenced within the object created from the model type description.Among other uses, initial values of object attributes may be specified in this way. For example,Figure 4 on page 10 shows a product model for “component code.” This model uses an instantiationparameter to set the initial value of the status attribute for objects instantiated using that typedescription.

2.2 Execution semantics

The execution model for MVP–L is based on the notion of project state [7]. This section defines thenotion of project state, and discusses how transitions between project states are guided by criteria.

2.2.1 Project state

Project state is defined as the union of all attribute values of all objects instantiated within a projectplan or as descendants of the plan. We define object state for product and process objects as aprojection of the project state onto all attributes defined within that object, as follows. For productobjects, the state consists of the values of all attributes defined in the model for that product. Forprocess objects, the state of that object consists of the values of all of its attributes plus the values of allattributes of all objects named in the “consume produce” and the “context” sections. We also definethe special attribute “status” for process objects as follows. The status attribute has value “disabled”when the entry criteria evaluate to false. The status attribute takes on value “enabled passive” whenthe entry criteria evaluate to true, but the process is not yet invoked. Finally, the status attribute hasvalue “enabled active” when the entry criteria are true and the process is being executed.

2.2.2 State transitions

The development of attribute models, as discussed previously in Section 2.1.1, supports the definitionof execution semantics in terms of transitions between project states by defining valid transitions forattributes of elementary models. Transitions are triggered as a result of actions on process objects,such as start and stop actions, or as a result of exceptional conditions. Each action on a processobject may have significant potential effects. The immediate effects are on the particular object thatreceives the action; attribute values for it are changed appropriately. Changes are then applied in arecursive manner on all objects that are related to the affected object through the affected attribute(s).We say that objects are related through an attribute if that attribute occurs in the object state (seeSection 2.2.1) of both process objects. The effects on an attribute are formally described in thecorresponding attribute model.

3

2.2.3 Criteria sections

The use of attribute models gives the criteria sections considerable power for describing the constraintson possible execution paths of a complex process model. Criteria use attributes to describe in whichstates processes can start and which states are produced upon completion in accordance with theplan. A criteria section specifies local and global criteria for both entry and exit. Local criteria applyto objects named in the “consume produce” section, and global criteria apply to objects named in the“context” section. The semantics of the “entry exit criteria” section are briefly explained as follows.A process may begin (becomes enabled) when both local and global entry criteria sections evaluateto true. When a process termination is told to the system by a user, both exit criteria are expected tobe true.

3 Solution for ISPW–7

We reused our solution to ISPW–6 and adapted it to the revised language definition that was describedearlier. The entire solution appears in an appendix. Changes that were due to revisions in thelanguage affected every model in our solution. Overall, the changes to our previous solution requiredapproximately 6 staff-hours to make. Our formalism was not changed in any way to accommodate theextensions proposed by the ISPW–7 program committee. We repeat here that our solution is limitedto representing the technical steps of the software-process modeling problem, and that planning andreplanning activities are outside the scope of our process representation.

3.1 Online vs. offline changes

We partition the changes proposed by the program committee into two parts, namely offline changesand online changes to the project plan. Offline changes change the plan statically; i.e., not duringenaction. Online changes are those which affect a plan during enaction. Following an onlinechange, the revised project plan must be applied to the state of the project plan before the changewas performed. Our solution only addresses the offline changes because we haven’t yet definedoperations to handle recovery following online changes. Although many of the online changes couldhave been expressed in some way as offline changes, we made no attempt to do so. We addressedextensions 4.1.1 and 4.1.2 fairly thoroughly, and extension 4.1.3 partially.

3.2 Extension 4.1.1, Resource management

Our schedule estimates 56 staff hours to accomplish the work of making design and code changesand validating the work. This number is shown in Figure 2 on page 8, where it is supplied to the“Technical steps” process model as an instantiation parameter. Estimated schedule hours are alsosupplied to subordinate process objects via instantiation parameters. Process conformance to thisschedule is checked by clauses given in “local exit criteria” sections of each process type description.Subprocesses are assigned some percentage of the activity hours allocated to a process abstraction;this assignment is again modeled in the instantiation parameters for those subprocesses.

The extension to reflect schedule was made straightforwardly to our prior solution, but affectedevery process model in our solution. Local exit criteria provide a natural place to specify that thework should be complete after some number of effort hours have been expended. Instantiationparameters allow these schedule numbers to be specified at the top, in the project plan, and thenpassed down the abstraction hierarchy to be referenced by the criteria sections of processes in themodel. Process model “Major design review” (following page 24) illustrates our representation ofscheduling information. The last clause in the “local exit criteria” is “effort <= eff 0.” Here,

4

“eff 0” is the instantiation parameter and “effort” is an attribute of the process model. The semanticsof this statement are that execution cannot be considered complete in accordance with the plan unlessthe effort used was less than what was allotted.

Individual and team personnel resources were modeled using MVP–L resource models. Forexample, Figure 55 (page 38) shows a resource model that represents the project team. Assignmentof these resources in process model type descriptions is done using the “resource assignment part”of process models. The assignment of resources done in our solution models the roles of individualson the project. We consider the assignment of specific individuals to the various processes to be partof the original planning activity, and therefore outside the scope of our solution.

3.3 Extension 4.1.2, Coordination and communication

Extension 4.1.2, the change requiring the parallel change of multipleparts of the software component,results in a process model that can have a number of instances of the same process and product at acertain level in the plan. The resulting MVP-L project plan requires further input from the user atrun-time to specify the exact number of instances that are expected to be created.

The change to the MVP–L code for the resulting from extension 4.1.2 is confined entirely tothe process named “modify code,” which is diagramed in Figure 33 on page 26. The MVP–Lrepresentation for the “modify code” process model follows page 26. In the previous solution,that process was a leaf process, i.e., not refined further. For the current problem, the specificationpart of the process is still appropriate and was not changed. To expand the solution to match therequirements of extension 4.1.2, the “modify code” process body was refined into an unspecifiednumber of subcomponents of type “modify code component.” The source code document was alsorefined into an unspecified number of source code components (Figure 12, page 15), and likewisefor the object code document (Figure 8, page 12). We expect that one “modify code component”process will work on each source code component and produce one object code component.

Each “modify code component” process type consists of two subprocesses, namely “mod-ify one component” and “propagate changes.” The refinement is shown in Figure 35 (page 27)and the subordinate models are diagramed in Figures 37 and 39 (pages 28 and 29). The “propa-gate changes” process is intended to model the interaction of developers who are modifying codethat has various interdependencies. We were unable to model formally the impact on related sourcecode components of making changes to one component, but have modeled the personnel interactionto reflect the activity that we expect must occur.

The run-time behavior of a process model with an unspecified number of products and processesis straightforward to explain. User interaction is required to start some number of instances of theparticular processes and to declare some number of instances of products. New instances of processesand products should be named in some meaningful way by the user. No provision for access to theinstantiation parameter is envisioned.

3.4 Extension 4.1.3, Teamwork

As mentioned in Section 3.2, teams are modeled and assigned to processes using MVP–L resourcemodels and resource assignment parts in process models. Figure 55 on page 38 represents theabstraction for the project team, and an instance of this type is instantiated in the project plan(Figure 2). However, our solution expresses no coordination activity among teams or individuals.

5

4 Future Language Changes

As a result of working on the ISPW–7 extensions, we intend to implement the following changes toMVP–L. The first change to the language will enable the specification of a process which consumesor produces an unspecified number of objects. We could have used this facility to help us model theISPW–7 extension in which an unspecified number of code components may have required changesin response to changes in the requirements. Some user interaction would be required at executiontime to map objects created at the appropriate level to the input ports.

A second change will add the ability to specify inter-product and inter-resource dependenciesin product and resource refinement parts. Specification of a dependency relationship within therefinement, e.g., a “uses” relationship, would be useful. Currently, we can only specify the compo-sition of an MVP–L abstraction in terms of subordinate objects and can make no statement aboutthe relationship of the subordinates to each other. This new capability would have permitted us toexpress the dependencies between source code components according to ISPW–7 extension 4.1.2.MVP–L does not provide any easy way of specifying the interactions and cooperation among theparallel processes modifying the code, nor of the interdependencies of the code documents.

Third, MVP–L currently lacks the facilities to modify a project plan during enaction in sucha way that will permit enaction to continue. We are defining operations that will permit us toperform functions such as saving the current project state, applying the project plan to the previousproject state, etc. We do not expect major problems in this effort, because our notation supports thedefinition of explicit project state and and permits explicit references to the project state, as discussedin Section 2.2.1.

Finally, we note that an inheritance mechanism would be useful. Objects that are declared to bespecializations of some other object would inherit all of the attributes declared at the higher level. Forexample, a standard “document” object could serve as the parent object for objects of type “designdocument,” etc.

5 Conclusion

The previous MVP–L solution was expanded cheaply and fairly easily to include some of theextensions of ISPW–7. As a result of this exercise, we discovered a number of interesting issues anddeficiencies in our language that merit further study. We thank the program committee of ISPW–7for the opportunity to exercise our language and detect areas that need improvement.

References

[1] V. R. Basili. “Software Development: A Paradigm for the Future,” Proceedings of the Thir-teenth Annual International Computer Science and Applications Conference, Orlando, Florida,September 1989, pp. 471–485.

[2] V. R. Basili and H. D. Rombach. “The TAME Project: Towards Improvement-Oriented SoftwareEnvironments,” IEEE Transactions on Software Engineering, v. SE-14, n. 6, June 1988, pp. 758–773.

[3] C. D. Klingler, C. M. Lott, H. D. Rombach, M. Neviaser, and A. Marmor-Squires. “A ProcessProgramming Experiment: Initial Lessons Learned,” Technical Report, TRW Systems Division,Fairfax, VA 22031.

6

[4] Christopher M. Lott and H. Dieter Rombach. “An MVP–L1 Solution for the Software Pro-cess Modeling Problem,” Proceedings of the Sixth International Software Process Workshop,Hakodate, Hokkaido, Japan, 29-31 October 1990; publ. by IEEE Computer Society Press, 1991.

[5] H. Dieter Rombach. “A Specification Framework for Software Processes: Formal Specificationand Derivation of Information Base Requirements,” Proceedings of the 4th International SoftwareProcess Workshop published as ACM Software Enginering Notes v. 14, n. 4, June 1989, pp. 85–90.

[6] H. Dieter Rombach. “An Experimental Process Modeling Language: Lessons Learned fromModeling a Maintenance Environment,” Proceedings of the Conference on Software Mainte-nance - 1989, IEEE, October 16-19, 1989.

[7] H. Dieter Rombach. MVP–L: A Language for Process Modeling In–the–Large, University ofMaryland Institute for Advanced Computer Studies Technical Report UMIACS–TR–91–96,CS–TR–2709, Department of Computer Science, University of Maryland, College Park, MD20742.

[8] H. Dieter Rombach and Brad T. Ulery. “Improving Software Maintenance Through Measure-ment,” Proceedings of the IEEE, v. 77, n. 4, April 1989, pp. 581–595.

[9] H. Dieter Rombach and Leo Mark. “Software Process and Product Specifications: A Basisfor Generating Customized Software Engineering Information Bases,” Proceedings of the 22ndAnnual Hawaii International Conference on System Sciences, Vol. II - Software Track, IEEE,January 1989, pp. 165–174.

7

A MVP–L Solution

A.1 Project plan

t: Technical_StepsRequuirements_change

req_change: Design_rev_feedback:

review_feedback

sw_component:Software_component

Figure 1: Graphic Representation of the Project Plan

project_plan Develop_change_and_test_unit is

importsproduct_model Requirements_change, Software_component;product_model Design_review_feedback;process_model Technical_steps;resource_model Project_team;

objectsreq_change : Requirements_change(‘approved’);sw_component : Software_component(‘incomplete’);rev_feedback : Design_review_feedback(‘nonexistent’);

-- 40% of the total effort is the target effort for design change.-- 60% of the total effort is the target effort for code change.-- These figures include modification and validation processes.t: Technical_Steps(56); -- 56 hoursproj_team: Project_team;

object_relationst(i1 => reg_change, io2 => sw_component, o3 => rev_feedback);

end project_plan Develop_change_and_test_unit.

Figure 2: Project Plan for the MVP–L Solution

8

A.2 Product models

Product model type descriptions for the MVP–L solution follow this page.

Requirements_change

Design_review_feedback

Unit_test_feedback

cd: cc: ct:

cd: co: tps: tpk: tr:

Software_component

Component_design Component_code Component_test

Unit_test_resultsUnit_test_packageUnit_test_plansObject_codeSource_code

Figure 3: Product Hierarchy for the MVP–L Solution

9

product_model Component_code(status_0 : Product_status) is-- ABSTRACTION for source/object code of a software component

product_interfaceimportsproduct_attribute_model Product_status;

exports-- attributesstatus : Product_status := status_0;

end product_interface

product_bodyrefinement-- comp’nt code is composed of the following componentsimportsproduct_model Source_code, Object_code;

objectscs : Source_code;co : Object_code;

object_relations( cs & co );

attribute_mappingsstatus:‘nonexistent’ <-> (cs.status = ‘nonexistent’) and(co.status = ‘nonexistent’);‘incomplete’ <-> (cs.status = ‘incomplete’) or(co.status = ‘incomplete’);‘complete_unval’ <-> (cs.status = ‘complete_unval’) and(co.status = ‘complete_unval’);‘complete_val’ <-> (cs.status = ‘complete_val’) and(co.status = ‘complete_unval’);

end product_body

end product_model Component_code.

Figure 4: Product Model “Component code”

product_model Component_design(status_0 : Product_status) is-- the design document for the software component to be changed




product_bodyimplementation-- this product has no refinement

end product_body

end product_model Component_design.

Figure 5: Product Model “Component design”

10

product_model Component_test(status_0 : Test_status) is-- ABSTRACTION for products involved in testing a software component

product_interfaceimportsproduct_attribute_model Test_status;

exports-- attributesstatus : Test_status := status_0;


product_bodyrefinement-- test component is composed of the following componentsimportsproduct_model Unit_test_plans, Unit_test_package, Unit_test_results;

objectstps : Unit_test_plans;tpk : Unit_test_package;tr : Unit_test_results;

object_relations( tps & tpk & tr );

attribute_mappingsstatus:‘nonexistent’ <-> tps.status = ‘nonexistent’ andtpk.status = ‘nonexistent’ andtr.status = ‘nonexistent’;‘incomplete’ <-> tps.status = ‘incomplete’ ortpk.status = ‘incomplete’ ortr.status = ‘incomplete’;‘complete’ <-> tps.status = ‘complete’ andtpk.status = ‘complete’ andtr.status = ‘complete’;

end product_body

end product_model Component_test.

Figure 6: Product Model “Component test”

product_model Design_review_feedback(status_0 : Review_feedback_status) is-- feedback from the design review

product_interfaceimportsproduct_attribute_model Review_feedback_status;

exports-- attributesstatus : Review_feedback_status := status_0;



end product_body

end product_model Design_review_feedback.

Figure 7: Product Model “Design review feedback”

11

product_model Object_code(status_0 : Product_status) is-- object code produced by compiling the source code


exports-- attributesstatus : Product_status := status_0;target_system : text := "system-name";


product_bodyrefinementimportsproduct_model Object_code_component;

objectsocc : Object_code_component;

object_relations( ( occ ) exp * );

attribute_mappings-- for all i, ....

end product_body

end product_model Object_code.

Figure 8: Product Model “Object code”

product_model Object_code_component(status_0 : Product_status) is-- object code component produced by compiling the source code


exports-- attributesstatus : Product_status := status_0;target_system : text := "system-name";


product_bodyimplementation

end product_body

end product_model Object_code_component.

Figure 9: Product Model “Object code component”

12

product_model Requirements_change(status_0 : Requirement_change_status) is-- A requirements change as input to the software change process

product_interfaceimportsproduct_attribute_model Requirement_change_status;

exports-- status ’nonexistent’ is outside the scope of this problemstatus : Requirement_change_status := status_0;



end product_body

end product_model Requirement_change.

Figure 10: Product Model “Requirements change”

13

product_model Software_component(status_0 : Product_status) is-- ABSTRACTION for a software system component (design/code/test comp’nts)




product_bodyrefinement-- system comp’nt is composed of the following componentsimportsproduct_model Component_design, Component_code, Component_test;

objectscd : Component_design;cc : Component_code;ct : Component_test;

object_relations-- specify that all objects are required( cd & cc & ct );

attribute_mappings-- comp’t is done when all subcomp’nts are cmplt/cmplt_valstatus:‘nonexistent’ <-> (cd.status = ‘nonexistent’ andcc.status = ‘nonexistent’ andct.status = ‘nonexistent’);‘incomplete’ <-> (cd.status = ‘incomplete’ orcc.status = ‘incomplete’);‘complete_unval’ <-> (cd.status = ‘complete_unval’ andcc.status = ‘complete_unval’ and(ct.status = ‘nonexistent’ orct.status = ‘incomplete’));‘complete_val’ <-> (cd.status = ‘complete_val’ andcc.status = ‘complete_val’ andct.status = ‘complete’);;

end product_body

end product_model Software_component.

Figure 11: Product Model “Software component”

14

product_model Source_code(status_0 : Product_status) is-- a source code document




product_bodyrefinementimportsproduct_model Source_code_component;

objectsscc : Source_code_component;

object_relations( ( scc ) exp * );

attribute_mappings-- for all i, ....

end product_body

end product_model Source_code.

Figure 12: Product Model “Source code”

product_model Source_code_component(status_0 : Product_status) is-- a source code subcomponent




product_bodyimplementation

end product_body

end product_model Source_code_component.

Figure 13: Product Model “Source code component”

15

product_model Unit_test_feedback (status_0:Test_feedback_status) is-- feedback from the unit test process

product_interfaceimportsproduct_attribute_model Test_feedback_status;

exports-- attributesstatus : Test_feedback_status:= status_0;



end product_body

end product_model Unit_test_feedback.

Figure 14: Product Model “Unit test feedback”

product_model Unit_test_package (status_0:Test_status) is-- Executable document for testing the unit





end product_body

end product_model Unit_test_package.

Figure 15: Product Model “Unit test package”

16

product_model Unit_test_plans (status_0:Test_status) is-- plans for testing the software system


exports-- attributesstatus : Test_status:= status_0;



end product_body

end product_model Unit_test_plans.

Figure 16: Product Model “Unit test plans”

product_model Unit_test_results (status_0:Test_status) is-- outcome of the unit testing process





end product_body

end product_model Unit_test_results.

Figure 17: Product Model “Unit test results”

17

A.3 Process models

Process model type descriptions for the MVP–L solution follow this page. In order to reduce thepage volume of this document, process models are shown in a smaller format.

minr:Minor_design_review

majr:Major_design_review

Run_unit_testrut:mutp:

Modify_unit_test_package

Modify_mtp:

test_plans

mcc*:Modify_code_component

component

moc:Modify_one

pc:Propagate_changes

Modify_and Modify_and

Technical_steps

mvd:

validate_design

mvc:

validate_code

md:Modify_design

vd:Validate_design

mc:Modify_code

vc:Validate_code

Figure 18: Process Hierarchy for the MVP–L Solution

18

comp_des:

designComp’nt_

comp_code:

codeComp’nt_ Comp’nt_

comp_test:

test

o3: Des’nreview_feedback

Req’nts_i1:

change

Modify_and Modify_andmvd:

validate_design

mvc:

validate_code

io2: Software_component

io2: Software_component

Figure 19: Graphic Representation of Process Model “Technical Steps”

process_model Technical_steps (eff_0:Process_effort) is -- first-level ABSTRACTION of the software change process -- uses the Technical Steps abstraction as suggested in Sec 2.2: -- Define "technical steps" as those not performed by the project manager -- -- From Section 2.1: -- The core problem is scoped as a relatively confined portion of the -- software change process. It focuses on the designing, coding, unit -- testing, and management of a rather localized change to a software system. -- This is prompted by a change in requirements, and can be thought of as -- occurring either late in the development phase or during the support -- (maintenance and enhancements) phase of the life-cycle. In order to -- confine the problem, we assume that the proposed requirements change has -- already been analyzed and approved by the Configuration Control Board -- or other appropriate authority. It has been determined that only a -- single code unit (e.g., module) is to be affected. -- -- This abstraction encapsulates all technical steps (modification -- and validation of all products). The next level of abstraction is -- MVD (modify and validate design) and MVC (modify and validate code). process_interface imports -- external entities that appear in this spec product_model Requirements_change, Design_review_feedback; product_model Software_component; process_attribute_model Process_effort; exports -- attributes of this process effort : Process_effort:= eff_0; consume_produce -- functional focus: input objects -- according to Section 2.1, RC is a single change -- and only one source code module is affected -- functional focus: output objects i1 : consume Requirements_change; io2 : consume_produce Software_component; o3 : produce Design_review_feedback; context entry_exit_criteria local_entry_criteria -- behavioral focus: process can run when this is true i1 = ‘approved’ and io2.status = ‘incomplete’; global_entry_criteria local_exit_criteria -- behavioral focus: one clause true upon exit ((io2.status = ‘complete_val’ and i1.status = ‘completed’) or (io2.status = ‘incomplete’ and i1.status = ‘cancelled’)) and effort <= eff_0; global_exit_criteria end process_interface process_body -- implementation of the abstract spec refinement -- S/W component is broken here into subcomponents, as specified imports

product_model Component_design, Component_code, Component_test; process_model Modify_and_validate_design, Modify_and_validate_code; objects comp_des : Component_design(‘incomplete’); comp_code : Component_code(‘incomplete’); comp_test : Component_test(‘incomplete’); mvd: Modify_and_validate_design(0.4*eff_0); mvc: Modify_and_validate_code(0.6*eff_0); object_relations (mvd & mvc); interface_refinement io2 = (comp_des & comp_code & comp_test); interface_relations -- input/output among process objects mvd(i1 => i1, io2 => comp_des, o3 => o3); mvc(i1 => i1, i2 => comp_des, io3 => comp_code, io4 => comp_test); attribute_mappings -- computation of attributes of technical steps effort = mvd.effort + mvc.effort; end process_body process_resources -- resources assigned or available to this process personnel_assignment -- employees are assigned imports resource_model Project_team; objects pteam : Project_team; tool_assignment -- tools are available for use by assigned personnel imports resource_model System_editor; objects vi : System_editor; end process_resources end process_model Technical_steps.

Figure 20: Process Model “Technical steps”

19

Req’nts_i1:

changeComp’t_io2:

design

o3: Des’n_review_feedback

md: vd:Modify_design Validate_design

Figure 21: Graphic for Process Model “Modify and validate design”

process_model Modify_and_Validate_Design (eff_0:Process_effort) is -- ABSTRACTION of the software change process, design aspects -- This process abstracts the modification and review steps of the design -- document (steps 2.5 and 2.6). The next level of abstraction is -- MD (modify design) and VD (validate design). process_interface imports -- external entities that appear in this spec product_model Requirements_change, Component_design; product_model Design_review_feedback; exports -- attributes of this process effort : Process_effort:= eff_0; consume_produce -- functional focus: input objects -- functional focus: output objects i1 : consume Requirements_change; io2 : consume_produce Component_design; o3 : produce Design_review_feedback; context entry_exit_criteria local_entry_criteria -- behavioral focus: process can run when this is true i1.status = ‘approved’ and io2.status = ‘incomplete’; global_entry_criteria local_exit_criteria -- behavioral focus: one clause is true upon exit (( io2.status = ‘complete_val’) or ( io2.status = ‘incomplete’ and i1.status = ‘cancelled’ )) and effort <= eff_0; global_exit_criteria end process_interface process_body -- implementation of the abstract spec refinement imports process_model Modify_design, Validate_design; objects -- all objects (products/processes) used internally md : Modify_design(0.4*eff_0); vd : Validate_design(0.6*eff_0); object_relations (md & vd); interface_refinement interface_relations -- input/output among process objects md(i1 => i1, io2 => io2, i3 => o3); vd(i1 => i1, i2 => io2, o3 => o3); attribute_mappings -- computation of attributes of technical steps

effort = md.effort + vd.effort; end process_body process_resources -- resources assigned or available to this process personnel_assignment -- employees are assigned imports resource_model Mod_val_design_team; objects mvdt: Mod_val_design_team; tool_assignment -- tools are available for use by assigned personnel imports resource_model System_editor; objects vi : System_editor; end process_resources end process_model Modify_and_validate_design.

Figure 22: Process Model “Modify and validate design”

20

Req’nts_i1:

change

io2:Comp’nt_design


Modify_Design

Figure 23: Graphic for Process Model “Modify design”

process_model Modify_design(eff_0 : Process_effort) is -- 2.5.1. Description -- This step involves the modification of the design for the code unit -- affected by the requirements change. It is a highly creative task. -- The modified design will be reviewed and ultimately implemented in code. -- This step may also modify the design based upon feedback from the -- design review. -- Assumptions about the status of the design document: -- initially it is marked incomplete (because the change is new). -- After modification, the status is marked complete_unval to trigger the -- review process. An unsuccessful review returns the status of the doc -- to incomplete, signalling MD (modify design) to begin again. -- A successful review sets the status to complete_validated process_interface imports -- external entities that appear in this spec product_model Requirements_change, Component_design; product_model Design_review_feedback; process_attribute_model Process_status; exports -- attributes of this process effort : Process_effort := eff_0; consume_produce -- 2.5.2. Inputs -- 1. Current design (from software design document file) (hand carried) -- 2. Design review feedback (from design review) (hand carried) -- 2.5.3. Outputs -- 1. Modified design (to review design, modify code, modify unit test -- package) (hand carried) i1 : consume Requirements_change; io2 : consume_produce Component_design; i3 : consume Design_review_feedback; context entry_exit_criteria local_entry_criteria -- 2.5.5. Constraints -- 1. This step can begin as soon as the task has been assigned by the -- project manager. -- 2. Subsequent iterations can begin as soon as the design review is -- completed (when the design is not approved). -- 3. This step ends when its output has been provided. i1.status = ‘approved’ and io2.status = ‘incomplete’; global_entry_criteria local_exit_criteria -- behavioral focus: clause is true upon exit (io2.status = ‘complete_unval’ or io2.status = ‘incomplete’ and i1.status = ‘cancelled’) and effort <= eff_0; global_exit_criteria end process_interface process_body implementation -- this process has no refinement end process_body process_resources

-- resources assigned or available to this process personnel_assignment -- employees are assigned -- 2.5.4. Responsibility -- [ Modify design ] is carried out by the assigned design engineer. imports resource_model Design_engineer; objects de : Design_engineer; tool_assignment -- tools are available for use by assigned personnel imports resource_model System_editor; objects vi : System_editor; end process_resources end process_model Modify_design.

Figure 24: Process Model “Modify design”

21

Req’nts_i1:

change designComp’nt_


i2:

minr: majr:Minor_design_review review

Major_design_

Figure 25: Graphic for Process Model “Validate design”

process_model Validate_design (eff_0 : Process_effort) is -- ABSTRACTION of the software change process, validate design process -- This process abstracts two subactivities of Step 2.6, Review design. -- The two subactivities are MAJR (major design review) and MINR (minor -- design review). -- -- 2.6.1. Description -- This step involves the formal review of the modified design. It is -- conducted by a team including the design engineer who produced the design -- modifications. There are three alternative outcomes of the review: -- 1. Unconditional approval -- The design is totally approved; the -- approved modified design is incorporated into the software -- design document. -- 2. Minor changes recommended -- Minor changes to the design are -- required and feedback is provided to the designer. The -- re-review is expected to be perfunctory. -- 3. Major changes recommended -- Major changes to the design are -- required and feedback is provided to the designer. -- At the conclusion of the review, the project manager is notified of the -- outcome. Due to the fact that formal design reviews are a relatively new -- step in this organization’s process, they are recording certain -- measurements to help evaluate its impact. In particular, the number of -- defects identified, and the aggregate effort of the review team in -- preparing for and conducting the review are reported to the project -- manager. process_interface imports -- external entities that appear in this spec product_model Requirements_change, Component_design; product_model Design_review_feedback; process_attribute_model Process_effort; exports -- attributes of this process effort : Process_effort := eff_0; consume_produce -- 2.6.2. Inputs -- 1. Modified design (from modify design) (hand carried) -- 2.6.3. Outputs -- 1. Design review feedback (to modify design) (hand carried) -- 2. Approved modified design (to software design document file) -- (hand carried) -- 3. Outcome notification, number of defects identified, aggregate -- effort (to monitor progress) (e-mail) -- Note: CD is modelled as emanating from MD (modify design), not -- from the review. Also, the outcome notification is -- contained within the design review feedback output. i1 : consume Requirements_change; i2 : consume Component_design; o3 : produce Design_review_feedback; context entry_exit_criteria local_entry_criteria -- 2.6.5. Constraints -- 1. This step will be carried out when it is scheduled to occur, -- provided that the modified design is available at that time. -- (Note that in cases of delay, the monitor progress step will -- reschedule the review to a later date.) -- 2. This step ends when its outputs have been provided; assume -- that all outputs are produced simultaneously. i1.status = ‘approved’ and i2.status = ‘complete_unval’;

global_entry_criteria local_exit_criteria -- behavioral focus: one clause is true upon exit ( o3.status = ‘approve’ and i2.status = ‘complete_val’ or o3.status = ‘minor_changes’ and i2.status = ‘incomplete’ or o3.status = ‘major_changes’ and i2.status = ‘incomplete’ or i2.status = ‘incomplete’ and i1.status = ‘cancelled’) and effort <= eff_0; global_exit_criteria end process_interface process_body -- implementation of the abstract spec refinement -- refine abstract spec given above imports process_model Minor_design_review, Major_design_review; objects -- all objects (products/processes) used internally minr : Minor_design_review(eff_0); majr : Major_design_review(eff_0); object_relations (minr | majr); interface_refinement interface_relations -- input/output among process objects minr(i1=>i1, i2 => i2, o3 => o3); majr(i1=>i1, i2 => i2, o3 => o3); attribute_mappings -- computation of attributes of technical steps effort = minr.effort + majr.effort; end process_body process_resources -- resources assigned or available to this process personnel_assignment -- employees are assigned -- 2.6.4. Responsibility -- [ Validate Design ] is carried out by the design review team -- assigned by the project manager. This team includes the design -- engineer, QA engineer, and two other software engineers. imports resource_model Mod_val_design_team; objects mvdt: Mod_val_design_team; tool_assignment -- tools are available for use by assigned personnel imports resource_model Sytem_editor; objects vi : System_editor; end process_resources end process_model Validate_design.

Figure 26: Process Model “Validate design”

22

Req’nts_i1:

change

i2:Comp’nt_design


Minor_design_review

Figure 27: Graphic for Process Model “Minor design review”

process_model Minor_design_review(eff_0 : Process_effort) is -- review design process; only a minor review -- This process is expected to be active only following a major -- review and subsequent design modification when the outcome -- of the first review was ’minor changes required.’ -- MINR differs from MAJR only in the precondition, but it is -- expected that the implementation of the two different procs -- would be quite different. process_interface imports -- external entities that appear in this spec product_model Requirements_change, Component_design; exports -- attributes of this process effort : Process_effort := eff_0; consume_produce i1 : consume Requirements_change; i2 : consume Component_design; o3 : produce Design_review_feedback; context -- empty entry_exit_criteria local_entry_criteria -- behavioral focus: process can run when this is true i1.status = ‘approved’ and o3.status = ‘minor_changes’ and i2.status = ‘complete_unval’; global_entry_criteria local_exit_criteria -- behavioral focus: clause is true upon exit (o3.status = ‘approve’ and i2.status = ‘complete_val’ or o3.status = ‘minor_changes’ and i2.status = ‘incomplete’ or i2.status = ‘incomplete’ and i1.status = ‘cancelled’) and effort <= eff_0; global_exit_criteria end process_interface process_body implementation -- this process has no refinement end process_body process_resources -- resources assigned or available to this process personnel_assignment -- employees are assigned imports resource_model Mod_val_design_team; objects mvdt : Mod_val_design_team; tool_assignment -- tools are available for use by assigned personnel imports resource_model System_editor; objects

vi : System_editor; end process_resources end process_model Minor_design_review.

Figure 28: Process Model “Minor design review”

23

Req’nts_i1:

change

i2:Comp’nt_design


Major_design_review

Figure 29: Graphic for Process Model “Major design review”

process_model Major_design_review(eff_0 : Process_effort) is -- major review design process -- This process serves as the initial design review process and -- as all subsequent reviews when major changes are required -- (i.e., not invoked when only minor changes are required). -- MAJR differs from MINR only in the precondition, but it is -- expected that the implementation of the two different procs -- would be quite different. process_interface imports -- external entities that appear in this spec product_model Requirements_change, Component_design; product_model Design_review_feedback; process_attribute_model Process_effort; exports -- attributes of this process effort : Process_effort := eff_0; consume_produce i1 : consume Requirements_change; i2 : consume Component_design; o3 : produce Design_review_feedback; context entry_exit_criteria local_entry_criteria -- behavioral focus: process can run when this is true i1.status = ‘approved’ and o3.status != ‘minor_changes’ and i2.status = ‘complete_unval’; global_entry_criteria local_exit_criteria -- behavioral focus: clause is true upon exit (o3.status = ‘approve’ and i2.status = ‘complete_val’ or o3.status = ‘minor_changes’ and i2.status = ‘incomplete’ or o3.status = ‘major_changes’ and i2.status = ‘incomplete’ or i2.status = ‘incomplete’ and i1.status = ‘cancelled’) and effort <= eff_0; global_exit_criteria end process_interface process_body implementation -- this process has no refinement end process_body process_resources -- resources assigned or available to this process personnel_assignment -- employees are assigned imports resource_model Mod_val_design_team; objects mvdt : Mod_val_design_team; tool_assignment -- tools are available for use by assigned personnel

imports resource_model System_editor; objects vi : System_editor; end process_resources end process_model Major_design_review.

Figure 30: Process Model “Major design review”

24

tf:

Unit_test_

feedback

mc:Modify_code

vc:Validate_code

io3: Component_code io4: Component_testi1:Req’nts_change

i2:Comp’nt_design

Source_ Object_

io3: Component_code io4: Component_test

cs:

code

co:

code

tps:Unit_test_plans

tpk:Unit_test_package

tr:Unit_test_results

Figure 31: Graphic for Process Model “Modify and validate code”

process_model Modify_and_validate_code (eff_0:Process_effort) is -- ABSTRACTION of the software change process, code modif/val aspects -- This process abstracts the modification and validation steps of the -- source code document, test plan document, and test package document. -- Steps 2.7 (modify code), 2.8 (modify test plans), 2.9 (modify test -- package), and 2.10 (run unit test) are abstracted in the next two -- abstractions, MC (modify code) and VC (validate code). process_interface imports -- external entities that appear in this spec product_model Requirements_change, Component_design; product_model Component_code, Component_test; process_attribute_model Process_effort; exports -- attributes of this process effort : Process_effort:= eff_0; consume_produce -- functional focus: input objects -- functional focus: output objects i1: consume Requirements_change; i2: consume Component_design; io3: consume_produce Component_code; io4: consume_produce Component_test; context entry_exit_criteria local_entry_criteria -- behavioral focus: process can run when this is true i1.status = ‘approved’ and io3.status = ‘incomplete’ and io4.status = ‘incomplete’ and ( i2.status = ‘incomplete’ or i2.status = ‘complete_unval’ or i2.status = ‘complete_val’ ); global_entry_criteria local_exit_criteria -- behavioral focus: one clause is true upon exit ( io3.status = ‘complete_val’ and io4.status = ‘complete’ or io3.status = ‘incomplete’ and io4.status = ‘incomplete’ and i1.status = ‘cancelled’ ) and effort <= eff_0; global_exit_criteria end process_interface process_body -- implementation of the abstract spec refinement -- refine code comp’nt into source, object; test component into p,p,r imports product_model Source_code, Object_code, Unit_test_plans; product_model Unit_test_package, Unit_test_results, Unit_test_feedback; process_model Modify_code, Validate_code; objects cs : Source_code(‘incomplete’); co : Object_code(‘incomplete’); tps: Unit_test_plans(‘nonexistent’); tpk: Unit_test_package(‘nonexistent’); tr : Unit_test_results(‘nonexistent’);

tf : Unit_test_feedback(‘faulty_code’); mc : Modify_code(0.4*eff_0); vc : Validate_code(0.6*eff_0); object_relations (mc & vc); interface_refinement io3=(cs & co); io4=(tps & tpk & tr); interface_relations -- input/output among process objects mc(i1=>i1, i2=>i2, i3=>tf, io4=>cs, o5 => co); vc(i1=>i1, i2=>i2, i3=>cs, i4 =>co, io5=>tps, io6=>tpk, io7=>tf, o8=>tr); attribute_mappings -- computation of attributes of technical steps effort = mc.effort + vc.effort; end process_body process_resources -- resources assigned or available to this process personnel_assignment -- employees are assigned imports resource_model Mod_val_code_team; objects mvct : Mod_val_code_team; tool_assignment -- tools are available for use by assigned personnel imports resource_model System_editor; objects vi : System_editor; end process_resources end process_model Modify_and_validate_code.

Figure 32: Process Model “Modify and validate code”

25

Req’nts_ Source_ Object_i3:Unit_test_feedback

i1:

change

i2:Comp’nt_design

io4:

code

o5:

code

mcc*:Modify_code_component

Figure 33: Graphic for Process Model “Modify code”

process_model Modify_code (eff_0:Process_effort) is -- 2.7.1. Description -- This step involves the implementation of the design changes into code, -- and compilation of the modified source code into object code. -- Implementation is accomplished by modifying existing source code. This -- step may also be based upon feedback from testing, indicating that -- additional source code modifications are required. -- -- FROM ISPW-7: -- Modification 4.1.2 -- The modify code activity now consists of several activities carried -- out in parallel -- -- Notes on this process: -- Only one code module (cs == comp’nt source) is affected (Section 2.1) -- Code status transitions from incomplete -> complete_unval -> complete_val -- possibly returning to incomplete status during validation process_interface imports -- external entities that appear in this spec product_model Requirements_change, Component_design, Source_code; product_model Object_code, Unit_test_feedback; process_attribute_model Process_effort; exports -- attributes of this process effort : Process_effort:= eff_0; consume_produce -- 2.7.2. Inputs -- 1. Modified design (from modify design) (hand carried) -- 2. Current source code (from software development files) -- (computer I/O) -- 3. Feedback regarding code (from test unit) (verbal) -- 2.7.3. Outputs -- 1. Modified source code (to software development files, computer I/O) -- 2. Object code (to software development files) (computer I/O) i1 : consume Requirements_change; i2 : consume Component_design; i3 : consume Unit_test_feedback; io4 : consume_produce Source_code; o5 : produce Object_code; context entry_exit_criteria -- 2.7.5. Constraints -- 1. This step can begin as soon as the task has been assigned by the -- project manager. (Thus, it is possible, if not advisable, to -- begin coding before the design work has even begun.) The -- engineer’s discretion determines when this task will actually -- commence, if the design has not yet been approved. If this step -- has not commenced earlier, it will begin when the design is -- approved. -- 2. Modified code released for testing is to reflect the approved -- modified design. One consequence is that this step cannot be -- completed before the modified design has been approved. -- 3. This step ends when a clean compilation (no errors) has been -- accomplished and its output has been provided. -- 4. Subsequent iterations (if required) can begin as soon as the -- test unit step has completed. local_entry_criteria i1.status = ‘approved’ and ( i2.status = ‘incomplete’ or i2.status = ‘complete_unval’ or i2.status = ‘complete_val’ ) and ( i3.status = ‘nonexistent’ or i3.status = ‘faulty_code’ or

i3.status = ‘faulty_test’ ) and io4.status = ‘incomplete’; global_entry_criteria local_exit_criteria -- behavioral focus: clause is true upon exit ( io4.status = ‘complete_unval’ or (io4.status = ‘incomplete’ and i1.status = ‘cancelled’ ) and o5.status = ‘complete’ and) effort <= eff_0; global_exit_criteria end process_interface process_body -- the two sub processes perform all the work refinement imports product_model Source_code_component, Object_code_component; process_model Modify_code_component; objects scc : Source_code_component; occ : Object_code_component; mcc : Modify_code_component; object_relations ( ( mcc ) exp * ); interface_refinement io4 = ( ( scc ) exp * ); o5 = ( ( occ ) exp * ); interface_relations -- input/output among process objects mcc (i1 => i1, i2 => i2, i3 => i3, io4 => scc, o5 => occ ); attribute_mappings -- For all i, mc[i], .... end process_body process_resources -- resources assigned or available to this process personnel_assignment -- employees are assigned -- Section 4.1.2: team of design engineers modifies the code imports resource_model Mod_code_team; objects mct : Mod_code_team; tool_assignment -- tools are available for use by assigned personnel imports resource_model System_editor; objects vi : System_editor; end process_resources end process_model Modify_code.

Figure 34: Process Model “Modify code”

26

o5:Object_codefeedback

i3:Unit_test_

designComp’nt_i2:

Req’nts_i1:

change

moc:Modify_one_component

pc:Propagate_changes

code

io4:Source_

Figure 35: Graphic for Process Model “Modify code component”

process_model Modify_code_component(eff_0 : Process_effort) is -- modifies a single component and produces object code process_interface imports product_model Requirements_change, Component_design; product_model Unit_test_feedback, Source_code; process_attribute_model Process_effort; exports effort : Process_effort := eff_0; consume_produce i1 : consume Requirements_change; i2 : consume Component_design; i3 : consume Unit_test_feedback; io4 : consume_produce Source_code; o5 : produce Object_code; context entry_exit_criteria local_entry_criteria i1.status = ‘approved’ and ( i2.status = ‘incomplete’ or i2.status = ‘complete_unval’ or i2.status = ‘complete_val’ ) and ( i3.status = ‘nonexistent’ or i3.status = ‘faulty_code’ or i3.status = ‘faulty_test’ ) and io4.status = ‘incomplete’; global_entry_criteria local_exit_criteria io4.status = ‘complete_unpropagated’ and o5.status = ‘complete’ and effort <= eff_0; global_exit_criteria end process_interface process_body refinement -- two sub processes perform all the work imports process_model Modify_one_component, Propagate_changes; objects moc : Modify_one_component(eff_0 * 0.5); pc : Propagate_changes(eff_0 * 0.5); object_relations (moc & pc); interface_refinement interface_relations -- input/output among process objects moc (i1 => i1, i2 => i2, i3 => i3, io4 => io4, o5 => o5 ); pc (io1 => io4); attribute_mappings end process_body

process_resources personnel_assignment imports resource_model Mod_code_team; objects mct : Mod_code_team; tool_assignment imports resource_model System_editor; objects vi : System_editor; end process_resources end process_model Modify_code_component.

Figure 36: Process Model “Modify code component”

27

o5:Object_codefeedback

i3:Unit_test_

designComp’nt_i2:

Req’nts_i1:

change

Modify_one_component

code

io4:Source_

Figure 37: Graphic for Process Model “Modify one component”

process_model Modify_one_component(eff_0 : Process_effort ) is -- modifies a single code component -- is paired with a prop_change process at the next higher level -- produces object code process_interface imports product_model Requirements_change, Component_design; product_model Unit_test_feedback, Code_component; process_attribute_model Process_effort; exports effort : Process_effort := eff_0; consume_produce i1 : consume Requirements_change; i2 : consume Component_design; i3 : consume Unit_test_feedback; io4 : consume_produce Code_component; o5 : produce Object_code; context entry_exit_criteria local_entry_criteria i1.status = ‘approved’ and ( i2.status = ‘incomplete’ or i2.status = ‘complete_unval’ or i2.status = ‘complete_val’ ) and ( i3.status = ‘nonexistent’ or i3.status = ‘faulty_code’ or i3.status = ‘faulty_test’ ) and io4.status = ‘incomplete’; global_entry_criteria local_exit_criteria io4.status = ‘complete_unpropagated’ and o5 = ‘complete’ and effort <= eff_0; global_exit_criteria end process_interface process_body implementation end process_body process_resources personnel_assignment tool_assignment end process_resources end process_model Modify_one_component.

Figure 38: Process Model “Modify one component”

28

changes

code

io4:Source_

Propagate_

Figure 39: Graphic for Process Model “Propagate changes”

process_model Propagate_changes(eff_0 : Process_effort) is -- the propagate change process models the activity of -- the developer who notifies dependents on a particular -- code module of any changes that affect them. -- MVP-L doesn’t permit us to model the interdependencies -- of products. -- An instance of this process is paired with each instance -- of modify_code_component process_interface imports -- external entities that appear in this spec product_model Source_code; process_attribute_model Process_effort; exports -- attributes of this process effort : Process_effort := eff_0; consume_produce io1 : consume_produce Source_code; context -- empty entry_exit_criteria local_entry_criteria i1.status = ‘complete_unpropagated’; global_entry_criteria local_exit_criteria i1.status = ‘complete_unvalidated’ and effort <= eff_0; global_exit_criteria end process_interface process_body implementation -- no refinement end process_body process_resources personnel_assignment imports resource_model Mod_code_team; objects mct : Mod_code_team; tool_assignment -- tools are available for use by assigned personnel imports resource_model System_editor; objects vi : System_editor; end process_resources end process_model Propagage_changes.

Figure 40: Process Model “Propagate changes”

29

Req’nts_

mtp:Modify_test_plans Modify_unit_

test_package

mutp: rut:Run_unit_test

i1:

changeSource_ Object_

i2:Comp’nt_design

io5:Unit_test_plans

i3:

code

io7:Unit_test_feedback

io6:Unit_test_package

i4:

code

o8:Unit_test_results

Figure 41: Graphic for Process Model “Validate code”

process_model Validate_code (eff_0:Process_effort) is -- ABSTRACTION of the software change process, code validation -- This process abstracts Steps 2.8 (modify test plans), 2.9 (modify -- test package), and 2.10 (run unit test). -- Together, these steps validate the source code by examining the -- source code and testing the object. process_interface imports -- external entities that appear in this spec product_model Requirements_change, Component_design, Unit_test_plans; product_model Source_code, Unit_test_feedback, Unit_test_package; product_model Object_code, Unit_test_results; process_attribute_model Process_effort; exports -- attributes of this process effort : Process_effort:= eff_0; consume_produce -- functional focus: input objects -- functional focus: output objects i1 : consume Requirements_change; i2 : consume Component_design; i3 : consume Source_code; i4 : consume Object_code; io5 : consume_produce Unit_test_plans; io6 : consume_produce Unit_test_package; io7 : consume_produce Unit_test_feedback; o8 : produce Unit_test_results; context entry_exit_criteria -- behavioral focus: process can run when this is true local_entry_criteria i1.status = ‘approved’ and io5.status = ‘incomplete’ and io6.status = ‘incomplete’ and ( i2.status = ‘incomplete’ or i2.status = ‘complete_unval’ or i2.status = ‘complete_val’ ) and ( i3.status = ‘incomplete’ or i3.status = ‘complete_unval’ ); global_entry_criteria local_exit_criteria -- behavioral focus: clause is true upon exit ( io5.status = ‘complete’ and io6.status = ‘complete’ and i3.status = ‘complete_val’ and io7.status = ‘pass’ ) or ( io5.status = ‘complete’ and io6.status = ‘complete’ and i3.status = ‘incomplete’ and io7.status = ‘faulty_code’ ) or ( io5.status = ‘incomplete’ and io6.status = ‘incomplete’ and i3.status = ‘incomplete’ and i1.status = ‘cancelled’ ) and effort <= eff_0; global_exit_criteria end process_interface process_body -- implementation of the abstract spec refinement -- refine abstract spec given above imports process_model Modify_test_plans, Modify_unit_test_package;

process_model Run_Unit_Test; objects -- all objects (products/processes) used internally mtp : Modify_test_plans (0.3*eff_0); mutp : Modify_unit_test_package (0.3*eff_0); rut : Run_unit_test (0.4*eff_0); object_relations (mtp & mutp & rut); interface_refinement interface_relations -- input/output among process objects mtp (i1 => i1, i2 => i2, io3 => io5); mutp(i1 => i1, i2 => i2, i3 => i3, i4 => io5, i5 => io7, io6 => io6); rut (i1 => i1, i2 => i3, i3 => i4, i4 => io6, o5 => io7, o6 => o8); attribute_mappings -- computation of attributes of technical steps effort = mtp.effort + mutp.effort + rut.effort; end process_body process_resources -- resources assigned or available to this process personnel_assignment -- employees are assigned -- Section 2.8.4, 2.9.4, 2.10.4: Software engineering -- staff modifies the test plan and package, tests code imports resource_model Val_code_team; objects vct : Val_code_team; tool_assignment -- tools are available for use by assigned personnel imports resource_model System_editor; objects vi : System_editor; end process_resources end process_model Validate_code.

Figure 42: Process Model “Validate code”

30

Modify_Test_Plans

Req’nts_i1:

change

i2:Comp’nt_design

io3:Unit_test_plans

Figure 43: Graphic for Process Model “Modify test plans”

process_model Modify_test_plans(eff_0 : Process_effort) is -- 2.8.1. Description -- This step involves the modification of test plans and objectives to -- include testing of capabilities related to the requirements change -- prompting this software modification. These test plans are analogous to -- software designs. They identify the functionality and capabilities to -- be tested, and the approach to be taken. On the other hand, the -- actual test data, procedures, and so forth are dealt with in the -- subsequent step (modify unit test package). process_interface imports -- external entities that appear in this spec product_model Requirements_change, Component_design, Unit_test_plans; process_attribute_model Process_effort; exports -- attributes of this process effort : Process_effort := eff_0; consume_produce -- 2.8.2. Inputs -- 1. Current test plans (from test plans file) (hand carried) -- 2.8.3. Outputs -- 1. Modified test plans (to test plans file) (hand carried) i1 : consume Requirements_change; i2 : consume Component_design; io3 : consume_produce Unit_test_plans; context entry_exit_criteria local_entry_criteria -- 2.8.5. Constraints -- 1. This step can begin as soon as the task has been assigned by the -- project manager. -- 2. This step ends when its output has been provided. i1.status = ‘approved’ and io3.status = ‘incomplete’ and (i2.status = ‘incomplete’ or i2.status = ‘complete_unval’ or i2.status = ‘complete_val’); global_entry_criteria local_exit_criteria -- behavioral focus: when true, process can exit (io3.status = ‘complete’ or io3.status = ‘incomplete’ and i1.status = ‘cancelled’) and effort <= eff_0; global_exit_criteria end process_interface process_body implementation -- this process has no refinement end process_body process_resources -- resources assigned or available to this process personnel_assignment -- employees are assigned -- 2.8.4. Responsibility -- [ Modify Test Plans ] is carried out by the assigned QA engineer imports

resource_model QA_engineer; objects qa_eng_b : QA_engineer; tool_assignment -- tools are available for use by assigned personnel imports resource_model System_editor; objects vi : System_editor; end process_resources end process_model Modify_test_plans.

Figure 44: Process Model “Modify test plans”

31

Req’nts_

Modify_unit_test_package

i1:

change PlansSource_

i2:Comp’nt_design

i4:Unit_test_

i3:

code

i5:Unit_test_feedback

io6:Unit_test_package

Figure 45: Graphic for Process Model “Modify unit test package”

process_model Modify_unit_test_package(eff_0 : Process_effort) is -- 2.9.1. Description -- This step involves the modification of the actual unit test package -- for the affected code unit, in accordance with the modifications made to -- the test plans and objectives. It will be assumed that the test package -- contains computer software to drive and evaluate the unit under test, -- along with narrative procedures recorded in accompanying computer files. -- test packages are under automated configuration management, and a new -- version of the unit test package is created when this step ends. Finally, -- it is noted that the modified design and/or the source code for this unit -- may be used as input to this step; however, this is not always the case. -- Subsequent iterations of this step may be based upon feedback from -- testing, indicating that additional modifications to the unit test package -- are required. process_interface imports -- external entities that appear in this spec product_model Requirement_change, Component_design, Unit_test_plans; product_model Source_code, Unit_test_feedback, Unit_test_package; process_attribute_model Process_effort; exports -- attributes of this process effort : Process_effort := eff_0; consume_produce -- 2.9.2. Inputs -- 1. Modified test plans (from test plans file) (hand carried) -- 2. Current unit test package (from test package file) (computer -- I/O) -- 3. Modified design (from modify design) (hand carried) -- 4. Source code (from software development files) (computer I/O) -- 5. Feedback regarding test package (from test unit) (verbal) -- 2.9.3. Outputs -- 1. Modified unit test package (to test package file) (computer I/O) i1 : consume Requirements_change; i2 : consume Component_design; i3 : consume Source_code; i4 : consume Unit_test_plans; i5 : consume Unit_test_feedback; io6 : consume_produce Unit_test_package; context entry_exit_criteria local_entry_criteria -- 2.9.5. Constraints -- 1. This step can begin as soon as the modify test plans step has -- completed. -- 2. This step ends when its output has been produced. -- 3. Subsequent iterations (if required) can begin as soon as the -- test unit step has completed. i1.status = ‘approved’ and i4.status = ‘complete’ and io6.status = ‘incomplete’ and (i2.status = ‘incomplete’ or i2.status = ‘complete_unval’ or i2.status = ‘complete_val’) and (i3.status = ‘incomplete’ or i3.status = ‘complete_unval’); global_entry_criteria local_exit_criteria (io6.status = ‘complete’ or (io6.status = ‘incomplete’ and i1.status = ‘cancelled’)) and effort <= eff_0; global_exit_criteria

end process_interface process_body implementation -- no refinement exists for this process end process_body process_resources -- resources assigned or available to this process personnel_assignment -- employees are assigned -- 2.9.4. Responsibility -- [ Modify Unit Test Package ] is carried out by the assigned QA -- engineer. imports resource_model QA_engineer; objects qa_eng_b : QA_engineer; tool_assignment -- tools are available for use by assigned personnel imports resource_model System_editor; objects vi : System_editor; end process_resources end process_model Modify_unit_test_package.

Figure 46: Process Model “Modify unit test package”

32

o5:Unit_test_feedback

Run_unit_test

i4:Unit_test_package

i3:Object_code

o6:Unit_test_results

i1:Req’nts_change

i2:Source_code

Figure 47: Graphic for Process Model “Run unit test”

process_model Run_unit_test(eff_0 : Process_effort) is -- 2.10.1. Description -- This step involves the application of the unit test package on the -- modified code, and analysis of the results. Both the design and QA -- engineers participate in this step. The entire test package is run -- before any analysis or further action is taken. Although the unit tests -- are primarily functional, an automated coverage analyzer is employed to -- determine that adequate test coverage of the unit’s code has been -- achieved. A 90% threshold has been established as acceptable. -- If all tests are successfully completed, and 90% coverage attained, then -- the unit has successfully passed. When this is not the case, the design -- and QA engineers jointly analyze the test results and determine -- appropriate actions. In order to confine the problem, assume that either -- or both of the following are the outcomes of this analysis: the source -- code needs to be modified further, the unit tests need to be modified -- further. When the indicated modifications have been made, the unit can -- be retested. -- If the unit passes its tests and meets an acceptable coverage level, -- then this example process has been completed. Steps beyond unit testing, -- such as integration testing, are beyond the scope of the core problem. -- The project manager is notified that the latest version of the unit code -- is available for integration testing. process_interface imports -- external entities that appear in this spec product_model Object_code, Unit_test_package, Unit_test_feedback; product_model Source_code, Unit_test_results, Requirements_change; process_attribute_model Process_effort; exports -- attributes of this process effort : Process_effort := eff_0; consume_produce -- 2.10.2. Inputs -- 1. Object code (from software development files) (computer I/O) -- 2. Unit test package (from test package file) (computer I/O) -- 2.10.3. Outputs -- 1. Test results (to test history file) (computer I/O) -- 2. Feedback regarding code (to modify code) (verbal) -- 3. Feedback regarding test package (to modify unit test package) -- (verbal) -- 4. Notification of successful testing (to monitor progress, e-mail) -- (Assume that TF (test feedback) include test results; the results -- are thereby passed to modify code, modify test package, etc.) i1 : consume Requirements_change; i2 : consume Source_code; i3 : consume Object_code; i4 : consume Unit_test_package; o5 : produce Unit_test_feedback; o6 : produce Unit_test_results; context entry_exit_criteria local_entry_criteria -- 2.10.5. Constraints -- 1. This step can begin as soon as both the object code and unit -- test package are available. -- 2. This step ends when its outputs have been provided; assume that -- all outputs are produced simultaneously. i1.status = ‘approved’ and i2.status = ‘complete_unval’ and i4.status = ‘complete’; global_entry_criteria local_exit_criteria -- behavioral focus: when true, process can exit

(i2.status = ‘complete_val’ and o6.status = ‘pass’ or i4.status = ‘incomplete’ and o6.status = ‘faulty_test’ or i2.status = ‘incomplete’ and o6.status = ‘faulty_code’ or i2.status = ‘incomplete’ and i1.status = ‘cancelled’) and effort <= eff_0; global_exit_criteria end process_interface process_body implementation -- this process has no refinement end process_body process_resources -- resources assigned or available to this process personnel_assignment -- employees are assigned -- 2.10.4. Responsibility -- [ Test Unit ] is carried out jointly by the design and QA engineers imports resource_model Val_code_team; objects vct : Val_code_team; tool_assignment -- tools are available for use by assigned personnel imports resource_model System_editor; objects vi : System_editor; end process_resources end process_model Run_unit_test.

Figure 48: Process Model “Run unit test”

33

A.4 Resource models

Resource model type descriptions for the MVP–L solution follow this page.

34

Project_team

pm:Project_manager

mvdt:Modify_val_design_team

mvct:Modify_val_code_team

mct:Modify_code_team

vct:Validate_code_team

Design_engineerqa_eng_b:QA_engineer

des_eng:

des_eng:

Design_engineereng_a: eng_b:X_engineer X_engineer

des_eng:Design_engineer

qa_eng_a:QA_engineer

eng_a:X_engineer

eng_b:X_engineer

Figure 49: Resource Hierarchy for the MVP–L Solution

resource_model Design_engineer() is

resource_interfaceimportsexports

end resource_interface

resource_bodyimplementation

-- Design engineer information.

end resource_body

end resource_model Design_engineer.

Figure 50: Resource Model “Design engineer”

35

resource_model Mod_code_team() is



resource_body

refinementimports

resource_model Design_engineer, X_engineer;

objectsdes_eng : Design_engineer;eng_a, eng_b : X_engineer;

object_relations(des_Engineering & eng_a & eng_b);

attribute_mappings

end resource_body

end resource_model Mod_code_team.

Figure 51: Resource Model “Mod code team”

resource_model Mod_val_code_team() is



resource_bodyrefinementimports

resource_model Mod_code_team, Val_code_team;

objectsmct : Mod_code_team;vct : Val_code_team;

object_relations(mcd & vct);

attribute_mappings

end resource_body

end resource_model Mod_val_code_team.

Figure 52: Resource Model “Mod val code team”

36

resource_model Mod_val_design_team() is



resource_bodyrefinement

importsresource_model Design_engineer, QA_engineer, X_engineer;

objectsdes_eng: Design_engineer;eng_a, eng_b: X_engineer;qa_eng_a: QA_engineer;

object_relations(des_Engineering & eng_a & eng_b & qa_eng_a);

attribute_mappings

end resource_body

end resource_model Mod_val_design_team.

Figure 53: Resource Model “Mod val design team”

resource_model Project_manager() is




-- Project manager information.

end resource_body

end resource_model Project_manager.

Figure 54: Resource Model “Project manager”

37

resource_model Project_team() is



resource_bodyrefinement

importsresource_model Project_manager, Mod_val_design_team;resource_model Mod_val_code_team;

objectspm : Project_manager;mvdt : Mod_val_design_team;mvct : Mod_val_code_team;

object_relations(pm & mvdt & mvct);

attribute_mappings

end resource_body

end resource_model Project_team.

Figure 55: Resource Model “Project team”

resource_model QA_engineer() is




-- Quality Assurance engineer information.end resource_body

end resource_model QA_engineer.

Figure 56: Resource Model “QA engineer”

38

resource_model Val_code_team() is



resource_bodyrefinementimports

resource_model Design_engineer, QA_engineer;objects

de : Design_engineer;qa_eng_b : QA_engineer;

object_relations(de & qa_eng_b);

attribute_mappings

end resource_bodyend resource_model Val_code_team.

Figure 57: Resource Model “Val code team”

resource_model X_engineer() is

resource_interfaceimportsexportsend resource_interface


-- X engineer information.end resource_body

end resource_model X_engineer.

Figure 58: Resource Model “X engineer”

39

A.5 Attribute models

Attribute model type descriptions for the MVP–L solution follow.

product_attribute_model Product_status () is

attribute_type(‘nonexistent’, ‘incomplete’, ‘complete_unval’, ‘complete_val’);

attribute_manipulationinvocation_based

Product_status x invocation -> Product_status

case invocation iswhen produce.start =>

case Product_status iswhen ‘non_existent’ => Product_status:= ‘incomplete’;when others => null;

end casewhen produce.complete =>

case Product_status iswhen ‘incomplete’ => Product_status:= ‘complete_unval’;when others => null;

end casewhen others => null;

end case

end product_attribute_model Product_status.

Figure 59: Attribute Model “Product status”

product_attribute_model Requirement_change_status () is

attribute_type( ‘approved’, ‘cancelled’, ‘completed’ );


Requirement_change_status x invocation -> Requirement_change_status

case invocation iswhen produce.complete =>

case Requirement_change_status iswhen ‘approved’ => Requirement_change_status:= ‘completed’;when others => null;


end case

end product_attribute_model Requirement_change_status.

Figure 60: Attribute Model “Requirement change status”

40

product_attribute_model Review_feedback_status () is

attribute_type(‘nonexistent’, ‘approve’, ‘minor_changes’, ‘major_changes’);


Review_feedback_status x invocation -> Review_feedback_status


case Review_feedback_status iswhen ‘approve’ => Review_feedback_status:= ‘nonexistent’;when ‘minor_change’ => Review_feedback_status:= ‘nonexistent’;when ‘major_change’ => Review_feedback_status:= ‘nonexistent’;when others => null;


end case

end product_attribute_model Review_feedback_status.

Figure 61: Attribute Model “Review feedback status”

product_attribute_model Source_code_status () is

attribute_type(‘nonexistent’, ‘incomplete’, ‘complete_unpropagated’,‘complete_unval’, ‘complete_val’);

attribute_manipulation-- empty; no default manipulations

end product_attribute_model Source_code_status.

Figure 62: Attribute Model “Source code status”

product_attribute_model Test_feedback_status () isattribute_type

(‘pass’, ‘faulty_code’, ‘faulty_test’ );


Test_feedback_status x invocation -> Test_feedback_status

case invocation iswhen produce.complete =>

case Test_feedback_status iswhen ‘faulty_code’ => Test_feedback_status:= ‘pass’;when ‘faulty_test’ => Test_feedback_status:= ‘pass’;when others => null;


end case

end product_attribute_model Test_feedback_status.

Figure 63: Attribute Model “Test feedback status”

41

product_attribute_model Test_status () is

attribute_type(‘nonexistent’, ‘incomplete’, ‘complete’);


Test_status x invocation -> Test_status


case Test_status iswhen ‘non_existent’ => Test_status:= ‘incomplete’;when others => null;

end casewhen produce.complete =>

case Test_status iswhen ‘incomplete’ => Test_status:= ‘complete’;when others => null;


end case

end product_attribute_model Test_status.

Figure 64: Attribute Model “Test status”

process_attribute_model Process_effort () isattribute_type

integer;

attribute_manipulationevent_based

Process_effort x event -> Process_effort

case event iswhen (global_date.week:= global_date.week+1) =>

Process_effort:= Process_effort + call(effort_collection_tool);end case

end process_attribute_model Process_effort.

Figure 65: Attribute Model “Process effort”

42

a mvp-l solution for the software–process …mvp–l is a prototype process speciﬁcation and...

Documents