The flow of the adaptable process model is described using a process design language that can be interpreted much like pseudocode. The process design language describes:
• major and minor software engineering tasks and related project decisions, conditions, events, and quality assurance check points;
• umbrella activities that occur in parallel with major software engineering tasks; specific umbrella tasks are noted by their acronym (e.g., software project management tasks are preceded by the acronym SPM;
It should be noted that some aspects of the process that are represented as sequential activities may in fact occur concurrently. For example, modeling and implementation may occur at the same time for large projects.
It should also be noted that the process flow presented here, although detailed, should be further modified to reflect your local situation accurately. You might add (or delete) steps or tasks; indicate new decisions (conditions) and actions, and/or add a unique project type.
The APM Process
process: APM
parallel activities (asynchronous):
- initiate APM tasks;
initiate risk management (RM);
initiate software project management (SPM);
initiate formal technical reviews (FTR);
initiate software quality assurance (SQA);
initiate software configuration management (SCM)
initiate reusability management (RM);
initiate measurement (M);
initiate document preparation and production (DPP);
end parallel activities
subprocess APM tasks
SPM: determine project type;
SPM: select task set using approach defined in SPM task;
case of project type:
- concept development
- new application development
- application enhancement
- maintenance
- reengineering
- Web application development
project type = concept development:
- repeat until (final deliverables are completed)
- repeat until (customer agrees with scope definition)
- Task I.1 scope and bound the concept ;
FTR: review scope with customer;
endrep
repeat until (project has been approved)
- Task I.2 plan concept development approach;
Task I.3 conduct technology risk assessment;
FTR: review plan and risks with management;
endrep
repeat until (customer approves/rejects concept)
- Task I.4 develop proof of concept;
Task I.5 implement concept;
DPP: develop concept deliverables as required;
FTR: review concept deliverables with customer
Task I.6 obtain customer reaction to concept
If customer requests major revisions
- then exit repeat until;
else record minor changes for deliverable adjustment;
endif
endrep
endrep
if application development project has been approved
- then
- set project type = application development;
invoke subprocess APM tasks;
else exit subprocess APM tasks;
endif
endcase of concept development
project type = new application development
- repeat until (final deliverables are completed)
- repeat until (customer agrees with scope definition)
- Task II.7 develop/revise scope;
FTR: review scope with customer;
endrep
repeat until (project has been approved)
- Task II.8 plan development approach;
RSK: Task II.9 assess project risk;
FTR: review plan and risks with management;
if management rejects plan and project is 'no-go'
- then exit subprocess APM tasks;
else note recommended changes to plan; endif
endrep
repeat until (customer accepts final deliverable)
- do while (engineering models remain to be developed)
- Task II.10 develop analysis and design models;
FTR: review model internally;
SQA: ensure models conform to content standards;
M: collect technical metrics;
SCM: baseline models as required;
REUSE: evaluate existing reusable components;
enddo
repeat until (verification of deliverable is complete)
- Task II.11 construct a deliverable;
DPP: develop deliverables as required;
FTR: review concept deliverables with customer;
Task II.12 verify and validate deliverable;
correct errors uncovered during Task II.12;
endrep
Task II.13 evaluate the deliverable;
Task II.14 define recommended customer modifications;
SCM: invoke change control procedures if required;
endrep
endrep
endcase of new application development
project type = application enhancement
- repeat until (final deliverables for enhancement are completed)
- repeat until (requirements modifications are defined)
- Task III.15 identify requirements modifications;
FTR: review scope with requester;
endrep
repeat until (project has been approved)
- Task III.16 plan the enhancement;
do while (potential impact remains to be evaluated)
- Task III.17 perform impact analysis
consider impact of modification to data, programs;
evaluate interoperability issues;
DPP: document impact and associated risk
FTR: review impact internally and with requester;
if impact risks are too high
- then exit subprocess APM tasks;
else develop impact mitigation strategy;
endif
enddo
endrep
repeat until (customer accepts final deliverable for enhancement)
- do while (engineering models remain to be developed)
- Task III.18 develop analysis and design models;
evaluate existing application design;
reverse engineer data structures and or design as required;
model enhancement;
FTR:: review model internally;
SQA: ensure models conform to content standards;
M: collect technical metrics;
SCM: baseline models as required;
REUSE: evaluate existing reusable components;
enddo
repeat until (verification of deliverable is complete)
- Task III.19 construct a deliverable;
REUSE: acquire reusable components from library;
DPP: develop deliverables as required;
FTR: review deliverables with customer;
SQA: ensure deliverables conform to content standards;
Task III.20 verify and validate deliverable;
if deliverable is executable
- then select and execute regression tests;
else skip
endif
correct errors uncovered during Task III.20;
endrep
Task III.21 evaluate the deliverable;
SCM: invoke change control procedures if required;
SQA: ensure that related configuration items have been updated;
endrep
endcase of application enhancement
project type = maintenance
- repeat until (final updated application is complete)
- repeat until (scope of change is defined)
- Task IV.22 evaluate request for change;
FTR: review request for change with originator;
endrep
repeat until (change request has been approved)
- SCM: involve change control process;
Task IV.23 plan the change;
do while (potential impact remains to be evaluated)
- Task IV.24 perform impact analysis;
consider impact of modification to data, programs;
evaluate interoperability issues;
DPP: document impact and associated risk
FTR: review impact internally and with originator;
if impact risks are too high
- then exit subprocess APM tasks;
else develop impact mitigation strategy;
endif
enddo
endrep
repeat until (change has been released)
- do while (engineering models remain to be developed)
- Task IV.25 make necessary changes to models;
evaluate existing application design;
reverse engineer data structures and or design as required;
model change as required;
FTR: review revised model internally;
SQA: ensure models conform to content standards;
M: collect technical metrics;
SCM: baseline models as required;
REUSE: evaluate existing reusable components;
enddo
repeat until (verification of deliverable is complete)
- Task III.26 construct modified deliverable;
REUSE: acquire reusable components from library;
DPP: develop deliverables as required;
FTR: review deliverables with customer;
SQA: ensure deliverables conform to content standards;
Task IV.27 verify and validate deliverable;
if deliverable is executable
- then select and execute regression tests;
else skip; endif
correct errors uncovered during Task III.27;
endrep
Task III.28 release modified deliverable;
SCM: invoke change control procedures if required;
endrep
endcase of maintenance
project type = reengineering
- repeat until (final reengineered system is delivered)
- repeat until (reengineering scope is established)
- Task V.29 define the reengineering scope;
analysis business requirements and process;
define the scope of changes to the existing system;
determine required technology;
conduct feasibility analysis;
DPP: produce reengineering scope;
FTR: review scope with requester;
endrep
repeat until (reengineering plan has been approved)
- Task V.30 develop a reengineering plan;
do while (risks remain to be evaluated)
- Task V.31 perform risk analysis;
DPP: document risk;
FTR: review risk internally and with requester;
if impact risks are too high
- then exit subprocess major APM tasks;
else RSK: develop risk MMM strategy;
endif
develop 'cut-over plan' for reengineered system;
enddo
endrep
repeat until (reengineering is complete)
do while (engineering models remain to be developed)
- Task V.32 extract engineering information;
evaluate existing application design;
reverse engineer data structures and or design as required;
revise design information to reflect reengineering requirements;
Task V.33 engineer new target application;
FTR: review design internally;
SQA: ensure models conform to content standards;
M: collect technical metrics;
SCM: baseline models as required;
REUSE: evaluate existing reusable components;
enddo
repeat until (verification of deliverable is complete)
- Task V.34 construct a deliverable for reengineered system;
REUSE: acquire reusable components from library;
DPP: develop deliverables as required;
FTR: review deliverables with customer;
SQA: ensure deliverables conform to content standards;
Task V.35 verify and validate deliverable;
if deliverable is executable
- then select and execute regression tests;
else skip
endif
correct errors uncovered during Task V.35;
endrep
Task V.36 evaluate the reengineered deliverable;
SCM: invoke change control procedures if required;
SQA: ensure that related configuration items have been updated;
endrep
endcase of reengineering
----------------------------------------------------------
UNDER CONSTRUCTION
The following section of the APM is currently under construction.
----------------------------------------------------------
project type = Web application development
repeat until (final WebApp is delivered)
repeat until (WebApp scope is established)
Task VI.1 Formulate WebApp project goals and objectives ;
understand the motivation for the WebApp;
list reasons that the WebApp is needed;
establish end-user profile(s)
define informational and applicative goals for the WebApp;
bound the scope for the WebApp;
determine required technology;
conduct feasibility analysis;
DPP: produce description of WebApp;
FTR: review scope with requester;
endrep
repeat until (WebApp plan has been approved)
Task VI.2 develop a WebApp plan;
consider cost, project, business, technology and schedule risks
FTR: review risk internally and with requester;
if impact risks are too high
then exit subprocess major APM tasks;
else RSK: develop risk MMM strategy;
endif
document WebApp plan as required and approve for continuing work;
enddo
endrep
repeat until (analysis activity is complete)
Task VI.3 analyze customer and end user requirements;
perform content analysis and create appropriate models;
define all major content objects and their relationships;
perform interaction analysis and create appropriate models;
establish interaction metaphor and objects/actions;
perform functional analysis and create appropriate models;
decompose WebApp functions, as required;
perform configuration analysis and create appropriate models;
define infrastructure support requirements;
enddo
DPP: produce analysis model for WebApp;
FTR: review analysis results (models) internally;
endrep
repeat until (design activity is complete)
VI.5 Perform architecture and navigation design
evaluate WebApp requirements to determine applicable architectural style;
select WebApp architectural alternatives;
evaluate architectural alternatives and select dominant architectural style;
do while (semantic navigation units remain to be defined)
repeat until (all user roles have been addressed)
repeat until (all WebApp goals have been considered)
define navigation requirements associated with different WebApp goals;
establish way of navigating (WoN) to achieve goals
associate navigation nodes (Web pages) and links between nodes for each WoN;
define mechanics for each navigational link;
establish navigation conventions and aids;
endrep
endrep
enddo
VI.6 Perform interface design
evaluate results of interaction analysis and functional analysis;
define and classify all interactive tasks;
establish the sub-goals and intentions for each task;
map each goal/intention to a sequence of specific actions;
specify the action sequence of tasks and subtasks, also called a user scenario;
Indicate the state of the system after a user scenario is performed;
do while (interface object/actions remain)
refine interface objects/actions
define control mechanisms, i.e., the objects and actions available to the user to alter the system state.
show how control mechanisms affect the state of the system;
enddo
indicate how the user interprets the state of the system;
establish appropriate interaction metaphor;
VI.7 Generate and Test WebApp pages
produce WebApp using standardized techniques;
FTR: review content model to uncover content errors (copyedit);
FTR: review design model to uncover navigation errors
unit test all processing components;
construct architecture and run tests while integrating WebApp components;
do while (different environmental configurations remain)
evaluate content presentation for correctness and aesthetics;
conduct validation tests against complete WebApp;
record all errors encountered and correct as required;
enddo
endsubprocess APM tasks
