|
Offshore
Solutions Delivery Methodology
APC utilizes a development methodology which is an adaptation of Rational
Unified Process (RUP) methodology. The workflows and phases are the same as
RUP, but the activities and artifacts have been merged and refined to make it
easy to adopt and faster to implement on projects.
Methodology Benefits:
-
Is
more lightweight and better directed than the traditional RUP
-
Is
focused on production of simple artifacts understood by all project
stakeholders
-
Has
established guidelines and document wizards that help facilitate project
activities
-
Reduces
churn due to heavy focus on the requirements elicitation process
-
Resolves
architectural issues upfront
-
Delivers
project in small iterations and rapid fire deliverables
-
Has
a heavy emphasis on Testing and Quality Assurance procedures
There are 4 phases in the methodology process: Inception, Elaboration,
Construction, and Transition.
Inception Phase
Objectives
The first objective of the inception phase is to define the vision document,
which consists of the use cases, and the system and software requirements. The
requirements definition is the driver for subsequent phases. At the end of this
phase the team will have a well-defined vision document, with clear and
unambiguously documented user requirements. Other objectives are to develop a
detailed project plan based on the scope, develop a high level architecture,
develop a prototype and staff the project for subsequent phases. The
development environment is set up, also.
Define
the Vision and Scope of the System
The vision identifies the client’s and APC’s personnel responsible for defining
the requirements and developing the system. It also defines the primary
features of the system. For each requirement the QA specialist and the business
analysts decide acceptance criteria used to develop the test plans. To manage
dependencies they identify traceability items and determine their attributes to
form a multi-dimensional traceability matrix. Non-functional requirements like
platforms to be supported, operating systems, performance, and scalability are
documented. Each item of work is reviewed and its acceptance documented.
Planning
The project manager is responsible for planning and managing the entire
development project. The project manager translates the vision into concrete
project variables that must be tracked. These variables are: budget, timeline,
resources, infrastructure, and project success criteria.
The project manager and the system architect establish the order of priority
among features and use cases. The system architect prepares a high level
architecture of the system. An estimate of the total scope, effort, and cost of
the project effort is prepared. A plan for the project, focusing on major
milestones and key deliverables in the product lifecycle is developed. The
project plan is iteratively refined during this phase. Risk mitigation
strategies for all identified risk factors such as staffing, project plan, and
cost/schedule trade-offs are evaluated.
Plan
and Design System-Level Test
The project manager and the QA team ensure that there is adequate number of
test cases and procedures to validate system requirements. They identify and
describe the test cases, and structure the test procedures. This is reviewed
and base-lined for subsequent use.
Preparing
the Project Environment
The project manager, along with the system administrators, prepares a document
clearly laying out the servers, workstations, operating systems, configuration
management and version control tool, the compilers, application servers,
modeling tool, e-mail and other desktop office applications to be used. The
system administrators will ensure that all these are set up and available to
the team.
Exit
Criteria
The vision is refined, reviewed, and signed-off by the client’s and APC’s team.
The exit criterion for the inception phase is the completion of the following
activities:
-
Creation,
review and approval of the vision document which includes the software
requirements
-
Updated
Project Plan and estimates
-
Signoff
by the client on revised project and staffing plan
-
Environment
Description document review and approval
-
Creation
of baseline vision, use case, environment documents
Elaboration Phase
Objectives
The primary objective of the elaboration phase is to create realization models
for the use cases and set the stage for their implementation through a process
of Analysis and Design.
Refining
the Vision
The system analyst describes in detail the architecture for all the use cases
and scenarios by refining the vision. The system architect, project manager and
client refine the priority for implementing use cases. The project manager
ensures that the software requirements specification accurately depicts the use
case model and use case descriptions. It is the project manager’s
responsibility to ensure that the requirements traceability matrix is updated
accordingly.
The software architect considers the system requirements, the glossary, the use
case view, the business model and the development team’s domain knowledge to
identify the components of the system. In parallel, the team leads and the
system architect start finding analysis classes for this use cases and/or
scenarios, as well as create the use case realizations. The team leads and
their developers refine the classes identified by allocating responsibilities
to the classes, and updating their relationships and attributes. The data
transformation requirements are identified and the properties of the classes
for the same are defined.
The software architect includes these classes in the logical view. The
resulting analysis artifacts are then reviewed.
Design
The team leads and the developers build the detailed class diagrams and
interaction diagrams, which describe the realizations of the use cases and
business processes. The responsibilities for implementing these classes are
assigned to the developers. The resulting design artifacts are then reviewed.
The system architect studies the tasks and processes required and the physical
network of processors and other devices. An important input is the
collaborating objects in interaction diagrams. These objects are allocated to
tasks and processes, which in turn are allocated to processors and other
devices. This results in both a logical and physical distribution of
functionality. The architecture is reviewed.
Plan
Integration and Testing
The project manager and the QA team determine the order in which functional
units are put together to form a working and testable system. System level
integration depends upon functionality already implemented, and what
functionality is required to support the overall integration and test strategy.
The results are documented in an integration test plan. The integration test
plan defines the frequency of builds and when given ‘build sets’ will be
required for ongoing development, integration, and test.
Refine
Project Plan
The project manager compares the actual cost, schedule, and content with the
iteration plan; determines if rework needs to be done, updates the risk list;
updates the project plan; and prepares for the next phase.
Exit
Criteria
The exit criteria for this phase are the completion of the following
activities:
-
Review
and base-lining the refined Vision document
-
Comprehensive
Model and Design Review by the system architect and team leads’ updated project
plan
-
Base-lining
of model and design artifacts
-
Review
of the integration test plan with the whole team
-
Updated
requirements traceability matrix (RTM)
-
Baseline
logical and physical architecture
Construction Phase
Objectives
The primary goal of the construction phase is to complete the development of
the system based upon the base-lined architecture. The process of code review,
unit test, and integration test ensures the quality of each development unit.
Emphasis is given to managing all the resources to ensure adherence to the
plan. Other objectives are:
-
Achieve
a quality deliverable as rapidly as possible
-
Rapid
iteration to release usable software product with the required functionality
-
Incrementally
develop a complete product that is ready to transition to the QA and acceptance
phase
-
Achieve
optimal parallelism in the work of development teams
Develop
Code and Test Unit
Software engineers develop code in accordance with the project’s coding
guidelines implementing all components defined in the design. The unit test
plan is documented and reviewed by the developers and team leads with the
project manager. The unit test execution validates unit functionality against
requirements. The developers execute white box tests to ensure against
structural defects. They fix defects and provide feedback that may lead to
design changes based on discoveries made in implementation. Some of the
objectives of unit testing are to:
-
Ensure
that features and functionality of the unit are working as intended.
-
Ensure
that the unit in its various states performs to its specification and can
correctly accept and produce a range of valid and invalid data.
-
Test
the system architecture by having the developer of the unit ensures that the
logic can be successfully traversed through each of its decision paths.
The team lead and system architect review the unit-tested code.
Baseline
Code, Unit Test Plans, and Results
On successful completion of code review, the relevant construction artifacts
such as source code, unit test plans, and results are baselined and checked
into the development repository by the project manager.
Build
System
The developers, in accordance with the plan, integrate the system by bringing
together completed classes that constitute a build. The implementer integrates
the system incrementally from the bottom-up based on the compilation-dependency
hierarchy.
Integration
Test Execution
Software engineers develop the drivers required to support the integration
tests. They execute tests in accordance with the integration test plan. If
there are any unexpected test results, the defects are logged and fixed or put
up for arbitration if the matter is complex. The results are reviewed and when
the outcome satisfies the test goals, the system is made available for the next
phase.
Build
and Release System to QA
The project manager makes a formal “build” for release based on the checked in
versions of the modules. A formal release document is created and sent along
with the relevant configuration details to QA to initiate the formal testing.
Assess
Phase Objectives
After the iteration is complete it must be carefully assessed to determine
actual cost, time and effort, and content. A determination must be made whether
or not the iteration was a success or if work remains. If rework is required it
must be assigned to a future iteration. Lastly, the risk list and project plan
must be updated. The project manager is responsible for these activities.
Exit
Criteria
The exit criteria for the construction phase are the completion of the
following activities:
-
Unit
Test Plan Review
-
Successful
code review by system architect and team lead
-
No
critical/high defects found during unit tests
-
Baseline source code, unit test plans and results
-
Updated release schedule
Transition Phase
Objectives
The objective of the transition phase is to ensure that software is available
for end users. The transition phase can span several iterations, and includes
testing the product in preparation for release and fine-tuning the system. At
this point, all the major structural issues have been resolved much earlier in
the project lifecycle and the system is stable. At the end of the transition
phase, the lifecycle objectives are met and the system is baselined with a
version and release number.
Plan
the Transition
The main driver for planning is the delivery of reliable software, with
acceptable performance and complete functionality. Accordingly, the project manager and client plan rigorous acceptance testing of the integrated system. The testing results in
detected bugs, which are fixed to ensure compliance
with requirements. Based on the number and severity of the bugs, the project manager invokes risk management activities, for example in the management of
changing requirements, or architecture refinement. The project manager also
plans production deployment and the contractually formal aspects of acceptance
tests. The plan clearly states how the software is to be bundled, packaged, distributed, and installed. The plan covers providing help and training to the
end-users.
The project manager monitors and reports on the project status. At completion,
the results are examined; the project manager prepares the project for
shutdown.
Manage
Change
Given the nature of the iterative development process, it is expected that the
requirements will be very stable, if not completely frozen, by this time.
Feedback affecting system requirements or their interpretation is captured as
Change Requests.
All Change Requests are put through an accelerated lifecycle. Analysis and
design of new requirements ensures architectural integrity is maintained. All
run-time, distribution, performance, capacity, and reliability adjustments are
made. Based on the analysis and design, the developers incorporate changes and
fix defects. Changes are unit tested and integrated into the system and
regression testing is performed.
Create
Release
The system architect and the system administrator create a complete list of
artifacts called a Bill of Materials that makes up the build/product. The list
includes all the constituent parts of the version of the product, software
configuration items, documents and installation scripts.
The Bill of Materials is updated for each build and ensures that the packaging,
customization and installation are accurate. The project manager, in the role
of a configuration manager, collates the deployment unit, installation scripts,
and user manuals, and makes them available for packaging and delivery. The technical
writer develops the end-user support material. This includes
organizing information for ease of access and making available all instructions
that are easy to follow.
Install
and Execute Acceptance Test
The client’s QA department should be involved in formal QA and acceptance
testing of the system. Acceptance testing is formal testing conducted to
determine whether or not a system satisfies client acceptance criteria, and to
enable the client to determine whether or not to accept the system. The client
evaluates the deliverable artifacts, to determine whether they meet predefined sets of acceptance criteria, as described in the System/Acceptance Test Plan.
The system administrator ensures that the infrastructure (hardware and software
resources) and support software are ready for the upcoming test activities. The
testers load the software and test data files, and proceed with testing using
the collection of test cases, test procedures, test scripts, and expected test
results. Test results are recorded together with any discrepancies between the
expected and actual results.
Test results are reviewed at a Test Results Review Meeting. At this meeting,
results for each test case are reviewed and noted as being “acceptable” or “not
acceptable.” The minutes of the meeting record any significant discussions and
decisions.
When test results are considered “unacceptable” the process manager raises
Change Requests for the anomalies and submits them to the Change Control Board
(CCB). The configuration management activities continue in parallel with the
remaining implementation and test with increasing emphasis on the formality of
change control.
The process manager ensures that all the artifacts required for creating a
release are set as baselines and made available. The CM, as part of acceptance,
conducts a Functional Configuration Audit and a Physical Configuration Audit.
Migrate
to Production
APC allocates key resources to help the client migrate the software from
the dedicated QA environment and deploy it on the production box. The production box is monitored for a mutually agreed time and then handed over to
the client with all the relevant system operation and deployment documentation.
Transition
of Project Responsibilities
This transition phase culminates in the delivery to the client of a complete
system (and ancillary supporting artifacts) with functionality and performance
as specified, and demonstrated in acceptance testing. The client takes
ownership of the software after a successful acceptance test.
Exit
Criteria
The exit criterion for this phase is the completion of the following
activities:
-
No
critical/major system/acceptance defects are open or unresolved
-
The
system is delivering functionality as entailed in the Vision and SRS documents
-
Successful
deployment of system to production
|
GSA
