Task Definition: Task III.15 Determine requirements for the requested enhancement
III.15.1 Identify requirements modifications that will be visible to the end users of the product/system;
III.15.2 Isolate differences in enhancement requirements if request comes from multiple customers or if enhancement is intended for different product lines;
III.15.3 Perform SCM functions;
III.15.4 Define final enhancement requirements;
EndTask definition Task III.15
Task Definition: Task III.16 Plan the enhancement
III.16.1
Develop cost/effort estimate for the enhancement;
III.16.2 Establish product enhancement, project duration, and resource requirements;
III.16.3 Derive enhancement schedule and strategy;
III.16.4 Develop a Project Plan for the enhancement;
EndTask definition Task III.16
Task Definition: Task III.17 Perform impact analysis for the enhancement.
III.17.1 Identify enhancement-specific risks and side effects.
III.17.2 Project likelihood that risks and side effects will occur.
III.17.3 Project impact of risks and side effects on developers / customers and on overall enhancement strategy.
III.17.4 Write a Risk/Side Effect Mitigation, Monitoring and Management Plan. Review as required.
EndTask definition Task III.17
Task Definition: Task III.18 Engineer for application enhancement
III.18.1 Refine analysis model to reflect application enhancement information;
III.18.2 Build prototypes, if required;
III.18.3 Engineer an analysis model with application enhancement refinements;
Begin Task III.18.3
case of: analysis approach:
analysis approach = structured analysis
repeat until (all data object, relationships, attributes are defined)
18.3.1 Engineer a data model using appropriate notation;
18.3.1.1 Identify data objects and control items that require change;
18.3.1.2 Define new data objects required for enhancement;
18.3.1.3 Indicate connections among objects and items;
18.3.1.4 Specify attributes for revised and new data objects;
18.3.1.5 Identify the relationships associated with each connection;
18.3.1.6 Develop or revise an entity relationship diagram, if required;
FTR: review the data model internally;
review the data model with the customer;
endrep
repeat until (data flow representation is complete)
18.3.2 Engineer a functional model using appropriate notation;
18.3.2.1 Revise the "context level" data flow model, if required;
18.3.2.2 Evaluate existing DFDs and define the domain of change;
18.3.2.3 Use grammatical parse on revised statement of scope for the enhancement;
18.3.2.4 Refine data flow model in domain of change;
18.3.2.5 Develop process specifications (PSPECs) for new transforms (functions) at lowest data flow level;
18.3.2.6 Revise process specifications (PSPECs) for modified transforms (functions) at lowest data flow level;
FTR:: review the revised data flow model internally;
review the revised data flow model (top levels only) with the customer;
endrep
repeat until (data flow representation is complete)
18.3.3 Engineer a behavioral model using appropriate notation;
18.3.3.1 Make a list of "events" that drive the system;
18.3.3.2 Indicate those system states that are externally observable;
18.3.3.3 Develop a top-level state transition model that shows how the product moves from state to state;
18.3.3.4 Refine the state transition model;
FTR:: review the behavioral model internally;
review the behavioral model with the customer;
endrep
analysis approach =object-oriented analysis
do while (class model needs refinement)
repeat until (all classes are defined)
18.3.1' Identify new classes to accommodate the enhancement;
18.3.1'.1 Identify classes/objects using grammatical parse of the enhanced software scope;
18.3.1'.2 Use inheritance to create enhanced classes ;
18.3.1'.3 Define relationships between classes;
18.3.1'.4 Define aggregate classes, as appropriate;
18.3.1'.5 Specify the class hierarchy;
FTR:: review the class model internally;
review the class model with the customer;
endrep
repeat until (all attributes are defined)
18.3.2' Specify attributes and operations for each class;
18.3.2'.1 Specify attributes for each class by identifying generic information that is relevant to all instances;
18.3.2'.2 Identify the methods (operations) that are relevant to each class;
FTR:: review the class model internally;
review the class model with the customer;
endrep
repeat until (class hierarchy are defined)
18.3.3' Engineer class hierarchy using appropriate notation.
18.3.3'.1 Specify public vs. private class attributes and methods.
18.3.3'.2 Describe object behavior.
review the class model internally;
review the class model with the customer;
endrep
enddo
18.3.4 Specify technical constraints and validation criteria.
18.3.5 Conduct formal technical reviews (FTRs) of model.
18.3.6 Make revisions as required.
18.3.7 Create requirements documentation (form will vary with project) using models as input.
18.3.8 Begin preliminary test planning.
endcase
end Task III.18.3
III.18.4 Engineer a design model with application enhancement refinements;
case of: design approach:
Begin Task III.18.4
design approach = structured design
repeat until (all data structures are defined)
18.4.1 Modify data structures based on analysis model;
18.4.1.1 Develop a data structure for each new data object;
18.4.1.2 Modify existing data objects, as required;
18.4.1.3 Modify database schema, If required;
18.4.1.4 Specify restrictions associated with each data structure.;
review the data design internally;
endrep
repeat until (program architecture is defined)
18.4.2 Engineer program architecture;
18.4.2.1 Map changes in data flow model into a revised program architecture;
18.4.2.2 Partition the architecture both vertically and horizontally and develop a revised structure chart;
review the architectural design internally;
endrep
repeat until (all program modules are described)
18.4.3 Describe new or revised program modules;
18.4.3.1 Adapt PSPECs (task 18.3.2.4) to become processing narratives for each new or revised module;
18.4.3.2 Develop description of each new or revised module interface;
18.4.4 Develop procedural (detailed) design for each new or revised module;
18.4.4.1 Develop a list of processing steps, based on processing narrative developed in Task 18.4.3.1;
18.4.4.2 Use stepwise refinement to develop a processing algorithm;
18.4.4.3 Apply "proof of correctness" techniques to verify correctness of the procedural design;
review the procedural design internally;
endrep
design approach = object-oriented design
repeat until (all subsystems are defined)
18.4.1' Modify each subsystem affected by the enhancement;
18.4.1'.1 Establish the level of concurrency for the problem;
18.4.1'.2 Allocate subsystems to processors;
18.4.1'.3 Allocate system functions to tasks;
18.4.1'.4 Define methods for managing global resources;
18.4.1'.5 Establish system control structure;
18.4.1'.6 Define mechanisms for initiation, termination and error handling;
review the system design internally;
endrep
repeat until (object design is complete)
18.4.2' Engineer reusable components corresponding to the class structure;
18.4.2'.1 Design classes in the problem domain;
18.4.2'.2 Design classes for the human-computer interface;
18.4.2'.3 Design classes for data management;
18.4.2'.4 Design classes for task management;
18.4.3' Modify object structure;
18.4.3'.1 Translate attributes into corresponding data structures;
18.4.3'.2 Design algorithms for each method, apply steps Task 18.4.4;
18.4.4' Modify message structure;
18.4.3'.1 Review the class relationship model developed in Task 18.3.1'.2;
18.4.3'.2 Define messages associated with each relationship;
18.4.3'.3 Create a message template [Booch, 1992];
18.4.3'.4 Consider message synchronization issues;
review the system design internally;
endrep
18.4.4 Specify revised interface design, if required;
18.4.5 Modify design documentation (form will vary with project) using the enhanced design model as input;
18.4.5 Conduct formal technical reviews (FTR) of model;
18.4.6 Make revisions as required;
endcase
III.18.5 Create a revised test plan and procedure for the enhancement;
EndTask definition Task III.18
Task Definition: Task III.19 Construct the enhanced deliverable
repeat until (deliverable is finalized)
if deliverable is non-executable then
DPP: develop appropriate documentation;
else {source code is to be generated}
do while (new or revised modules remain to be coded)
III.19.1 Select program components to be coded;
III.19.2 Code in the appropriate programming language;
III.19.3 Conduct code walkthroughs (FTR) of selected components;
III.19.4 Make revisions as required;
enddo
endif
endrepeat
EndTask definition Task III.19
Task Definition: Task III.20 Verify and validate the deliverable;
III.20.1 Revise existing test plan and procedure to accommodate the enhancement;
begin Task III.20.1
repeat until (test strategy is finalized)
20.1.1 Review validation criteria and existing test plan, if one has been written; modify to accommodate the enhancement;
20.1.1.1 Review the test plan to determine if project schedule provides completed modules when needed for testing;
20.1.1.2 Modify the test plan to conform to the actual module completion dates;
20.1.1.3 Review validation criteria to ensure that requirements changes have been accommodated;
20.1.1.4 Add new classes of tests, as required;
20.1.2 Describe the integration strategy for the enhancement;
20.1.2.1 Select order of functional implementation for the enhancement;
20.1.2.2 Define integration strategy for the enhancement;
20.1.2.3 Design clusters (builds) and indicate where stubs/drivers will be required;
parallel activity: CreateTestSoftware
do while (stubs and drivers remain to be developed)
analyze requirements/interfaces for stubs and drivers;
design stubs and drivers;
generate code for stubs/drivers;
test stubs and drivers to ensure accurate interfaces and operation;
DPP: create operating instructions for stubs and drivers;
enddo
endparallel
20.1.2.4 Consider regression testing requirements and indicate where regression tests are to be used;
20.1.2.5 Specify special testing resources;
20.1.3 Identify program components that require unit testing;
20.1.3.1 Define criteria for selection of unit test candidates;
20.1.3.2 Determine whether unit tests can be appropriately scheduled;
20.1.3.3 Estimate resources required to conduct unit testing;
end Task III.20.1
III.20.2 Design white-box and black-box tests with product enhancement refinements;
Begin Task III.20.2
repeat until (white box test cases are designed)
20.2.1 Review module procedural design to determine most appropriate white- box method for new and revised modules;
20.2.1.1 Compute module cyclomatic complexity, if this has not already been done;
20.2.1.2 Isolate all independent logical paths;
20.2.1.3 Isolate all loops;
20.2.2 Design basis path tests;
20.2.2.1 For each independent path, examine component interface to determine inputs that will force module to execute that path;
20.2.2.2 Specify output values/conditions that are expected;
20.2.2.3 Indicate any special testing considerations;
20.2.3 Design loop tests;
20.2.3.1 For each loop specify type;
20.2.3.2 For each independent path, examine component interface to determine inputs that will force module to execute loops as required by loop test criteria;
20.2.3.3 Specify loop exit values/conditions that are expected;
20.2.4 Design other white-box tests;
20.2.4.1 Consider efficacy of data flow testing and design tests if appropriate;
20.2.4.2 Consider efficacy of brach-relational operator testing and design tests if appropriate;
20.2.4.3 Consider efficacy of other white-box tests and design tests if appropriate;
endrep
end Task III.20.2
II.20.3 Design black-box tests for new and revised program components and for the integrated system;
Begin Task III.20.3
repeat until (black box test cases are designed)
20.3.1 Review existing black box tests to determine those that are applicable to the enhanced system;
20.3.1.1 Examine architecture to isolate modified component clusters (builds) that are candidates for black-box testing;
20.3.1.2 Isolate local requirements for each program cluster;
20.3.1.3 Review broad program requirements and test classes specified during analysis activities;
20.3.2 Design black-box tests for each new or revised component cluster for use during integration testing;
20.3.2.1 Define equivalence classes for data that flow into the cluster;
20.3.2.2 Define boundary values for data that flow into the cluster;
20.3.2.3 Specify corresponding equivalence class and boundary value tests;
20.3.2.4 Specify expected output;
20.3.3 Design black-box tests for the enhanced program as a whole;
20.3.2.1 Define equivalence classes for data that flow into the program;
20.3.2.2 Define boundary values for data that flow into the program;
20.3.2.3 Specify corresponding equivalence class and boundary value tests for the program;
20.3.2.4 Specify expected output;
endrep
end Task III.20.3
III.20.4 Conduct white-box and black-box tests with product enhancement refinements;
Begin Task III.20.4
20.4.0 Review all test cases to ensure that adequate test coverage has been achieved. Make revisions as required;
repeat until (white box tests have been executed)
20.4.1 Execute a white box test case;
20.4.1.1 Compare expected and actual results;
20.4.1.2 Note discrepancies;
20.4.1.3 Record all errors for later correction or immediate action. Create an error log;
parallel activity: debugging
do while (errors remain to be corrected)
diagnose error symptom;
if cause of error is known then
20.4.2 Correct error
invoke Task III.20.4.1;
20.4.3 Modify source code and design model based on debugging changes. Create a change log;
20.4.4 Review (FTR) all substantive changes for side effects;
else {cause of error is not known}
invoke Task III.20.2 to exercise code connected to symptom;
ask colleagues to assist in diagnosis;
endif
enddo
endparallel
endrep
repeat until (black box tests have been executed)
20.4.5 Execute a black box test case;
20.4.5.1 Compare expected and actual results;
20.4.5.2 Note discrepancies;
20.4.5.3 Record all errors for later correction or immediate action. Create an error log;
parallel activity: debugging
do while (errors remain to be corrected)
diagnose error symptom;
if cause of error is known then
20.4.6 Correct error;
invoke Task II.20.4.5;
20.4.7 Modify source code and design model based on debugging changes. Create a change log;
20.4.8 Review (FTR) all substantive changes for side effects;
else {cause of error is not known}
invoke Task III.20.3 to exercise code connected to symptom;
ask colleagues to assist in diagnosis;
endif
enddo
endparallel
endrep
end Task III.20.4
III.20.5 Conduct regression tests;
III.20.6 Prepare all product enhancement documentation;
III.20.7 Develop a strategy for re-introduction of the software;
Begin Task III.20.7
III.20.7.1 Define system integration strategy and initiate system integration testing. (see Task II.12.8.1);
III.20.7.2 Establish customer integration and live-test strategy;
III.20.7.3 Revise and implement customer training, as req'd. (see Task II.13.2);
end Task III.20.7
III.20.8 Create an revised Software Release Package;
Begin Task III.20.8
20.8.1 Ensure that all documents, data and programs are placed under formal configuration control (see Chapter 5, Umbrella Activity U.4);
20.8.2 Construct a set of deliverables for the customer;
20.8.3 Define a set of internal documentation for technical reference;
20.8.4 Develop a System Support Plan(large projects only);
20.8.5 Apply final SQA procedures to ensure completeness;
20.8.6 Write release memo;
end Task III.20.8
III.20.9 Roll-out to each customer;
end Task Definition Task III.20
Task Definition: Task III.21 Evaluate the enhancement
III.21.1 Deliver product to each customer;
III.21.2 Define feedback mechanisms;
III.21.3 Refine help-desk to accommodate multiple customer locations;
III.21.4 Conduct training and provide implementation support;
III.21.5 Collect and analyze customer feedback;
end Task Definition Task III.21
Use Browser "back" arrow or return to APM Process Design Language Description
