1 This appendix details actions and associated expected outcomes that can be
used to assist with software development and Software Quality Assurance (SQA)
activities.
2 Activities, and where appropriate sub-activities, can be specific or
holistic in nature. The expected outcomes may result in documentation which should in
general align with the requirements of the quality management system being used. This
will in many cases result in evidence showing that the results of activities undertaken
comply with top-level requirements for the e-navigation systems being developed.
3 Depending on the required characteristics of the software system,
boundaries between activities may be flexibly arranged to help assist with effective SQA
across the software life cycle.
4 For Activity 1, it is recommended to define stakeholder requirements which
can include the following actions and expected outcomes:
| Activity or sub-activity
|
Actions/Outcomes
|
| Stakeholder requirements definition
|
✓ Elicit needs of stakeholders and identify the
context of use;
✓ Develop specification of the required
characteristics and context of use;
✓ Definition of the
constraints on the system to be developed;
✓ Traceability
of stakeholder requirements to stakeholders and their
needs;
✓ The basis for defining the system
requirements;
✓ The basis for validating the conformance
of the services; and
✓ A basis for negotiating and
agreeing to supply the system to be developed.
|
5 For Activity 2, it is recommended to conduct a system requirement analysis which can
include the following actions and expected outcomes:
| Activity or sub-activity
|
Actions/Outcomes
|
| System requirement analysis
|
✓ A defined set of functional and
non-functional requirements;
✓ Systems configuration for
the optimized solution;
✓ Correctness and testability
analysis of the system requirements;
✓ Impact analysis of
the system requirements on the operating environment;
✓
Prioritized, approved and updated set of the requirements when
needed;
✓ Consistency and traceability between the system
requirements and the stakeholder's requirements baseline;
and
✓ Impact analysis of changes to the baseline for
cost, schedule and technology.
|
6 For Activity 3, it is recommended to conduct system architectural design and
implementation which can include the following actions and expected outcomes:
| Activity or
sub-activity
|
Actions/Outcomes
|
| Software reuse
|
✓ A software architecture design
defining the elements of a system that meets the defined
requirements;
✓ Functional and non-functional
requirements of the system;
✓ Allocation of some of
requirements to the elements of the system;
✓ Internal
and external interfaces of each system element;
✓
Verification between the system requirements and the software
architecture;
✓ Traceability to the stakeholder's
requirements base line;
✓ Maintaining the consistency and
traceability between the system requirements and software architecture
design;
✓ Base lining the relationships between the
system requirements and the architecture design and informing all
affected stakeholders; and
✓ Incorporating human factors
principles and knowledge in system design.
|
| Implementation
|
✓A strategy for software
integration based on the priorities of the system
requirements;
✓Criteria to verify compliance with the
system requirements;
✓ Verification of system integration
by using the defined criteria;
✓ A regression strategy
for re-testing the system when changes are made;
✓
Establishment of consistency and traceability between the system design
and the integrated system elements;
✓ An integrated
system with compliance with the system design; and
✓ An
integrated system with a complete set of usable deliverable system
elements.
|
7 The software reuse activity falls within Activities 1, 2 and 3, which can include the
following actions and expected outcomes:
| Activity or sub-activity
|
Actions/Outcomes
|
| Software reuse
|
✓ Establishing the policy, plan and
processes for software reuse;
✓ Selecting representation
forms for the domain models and the domain
architectures;
✓ The boundaries of the domain and its
relationships to other domains;
✓ A domain model that
captures the essential common and different features, capabilities,
concepts, and functions in the domain;
✓ A domain
architecture describing the family of systems within the domain,
including their commonalities and differences;
✓
Specification of assets belonging to the domain;
✓
Acquisition, development and maintenance of assets belonging to the
domain throughout their life cycles; and
✓ Maintaining
the domain models and architectures throughout their life
cycles.
|
8 For Activity 4, it is recommended to conduct software integration, qualification and
testing, installation and acceptance, which can include the following actions and
expected outcomes:
| Activity or sub-activity
|
Actions/Outcomes
|
| Software integration
|
✓ Test coverage of system
requirements;
✓ Appropriateness of test methods and
standards used;
✓ Conformance to expected
results;
✓ Feasibility of software qualification testing;
and
✓ Feasibility of operation and maintenance.
|
| Software qualification testing
|
✓ A criteria for evaluating compliance with
system requirements;
✓ Testing the integrated system
using the defined criteria;
✓ Recording the test results;
and
✓ Assuring readiness of the system for
delivery.
|
| Software installation
|
✓ A software installation
strategy;
✓ Criteria for software installation showing
compliance with the software installation requirements;
✓
Installing the software in the target environment; and
✓
Assuring readiness of the software product for use in its intended
environment.
|
| Software acceptance support
|
✓ The completed software
system;
✓ Acceptance tests and reviews by
acquirer;
✓ Putting the completed software system into
operation in the intended environment;
✓ Identification
of problems detected during acceptance; and
✓
Notification of the identified problems to the responsible
party.
|
9 For Activity 5, it is recommended to conduct the software operation process and the
software maintenance process which can include the following actions and expected
outcomes:
| Activity or sub-activity
|
Actions/Outcomes
|
| Software operation
|
✓An operation
strategy;
✓Identification and evaluation of conditions
for correct operation of the software in its intended
environment;
✓Testing the software to determine the
operation in its intended environment;
✓Operating the
software in its intended environment; and
✓Assistance and
consultation for the stakeholders of the software product in accordance
with the agreement.
|
| Software maintenance
|
✓ A maintenance strategy to manage
modification and migration of products according to the release
strategy;
✓ Identification of the impact of changes to
the existing system on organization, operations or
interfaces;
✓ Updating system and software documentation
as needed;
✓ Modification of products without
compromising requirements;
✓ Migration of product
upgrades including data upgrade to the customer's environment;
and
✓ Informing all affected parties of the system
software modifications.
|
10 For Activity 6, it is recommended to conduct the system disposal process which can
include the following actions and expected outcomes:
| Activity or sub-activity
|
Actions/Outcomes
|
| System disposal
|
✓ A software/hardware disposal
strategy;
✓ Disposal constraints;
✓
Destruction of software/hardware elements as needed;
✓
Storage of software/hardware elements as needed;
✓ The
software environment left in an agreed-upon state;
✓
Records allowing knowledge retention of disposal actions and any
analysis of long-term impacts;
✓ Evidence showing that
the results above comply with top-level requirements of the e-navigation
systems to be developed;
and
✓
Confirmation that disposal is not detrimental to health, safety,
security and the environment.
|