![](bg2.png)
in the information technology environment (Chang
and Atallah, 2001) (Wyk and McGraw, 2005) or re-
liability improvement in software (Herrmann, 1999)
(SAE, 2004) (Keene, 1999) (Lakey and Neufelder,
1997).
For safety-related software, Parnas and associates
(Parnas et al., 1990) focus on disciplined design, doc-
umentation, testing and review. Mathematical nota-
tion is recommended over natural language structures,
and independence is required of the reviewers. Thor-
ough testing make up the third leg of their propos-
als to enhance safety. Wilson and associates (Wil-
son et al., 1995) propose development of supporting
evidence for attaining safety goals. For better relia-
bility, JA1003 (SAE, 2004) proposes including relia-
bility techniques in the software engineering frame-
work and developing supporting evidence for relia-
bility goals. Chang and associates (Chang and Atal-
lah, 2001) have proposed methods to protect program
integrity and enhance security by multiple security
modules. It is proposed to use each of these con-
cepts to create higher integrity software modules in
the form of web services.
3 DEVELOPMENT PROCESS
FOR INTEGRITY
The specific process model used in this paper is an
internal company model closely related to ISO/IEC
15504 and IEEE/IEC 12207. This model is aug-
mented to focus on integrity, using ideas from the
safety case and reliability case proposals discussed
previously (SAE, 2004) (Parnas et al., 1990).
As the software process begins, a new document,
the software integrity plan, is started and developedin
parallel with the software while the software require-
ments are derived from the system design specifica-
tions and include the safety, reliability, and security
criteria. Those requirements that are integrity-related
are identified and used to develop a requirements
tracking database. This database is used through the
design stage, into the code development, and through
verification/validation activities. Software safety, re-
liability, and security are analyzed and graded by pre-
determined criteria, and those grades are used to de-
termine the degree of scrutiny imposed on each soft-
ware deliverable.
The software design process uses UML and for-
mal notation to assure requirements are tracked into
design and into validation. Specific modules are con-
sidered as guards for software security, and redun-
dant services are considered to meet reliability cri-
teria. Design artifacts are captured and traceability
is formally verified between each development stage.
A software causal analysis is performed to determine
potential failure modes of the final software design.
Once implemented into code, the software is sub-
ject to formal review and interface analysis. Testing
is performed to a high level of coverageand includes
requirements testing, functionality testing, fault in-
jection, and performance testing. Finally, the design
team brainstorms potential abnormal events and “rare
events” testing to complete the test suite. The in-
tegrity plan mentioned previously does not capture
the detail of the testing, but does document that test-
ing is performed. Testing detail is captured in the soft-
ware (and system) validation plan(s) and qualification
activities are captured in the software (and system)
qualification plan(s). Traceability is also captured and
demonstrated in the integrity plan through traceability
matrices.
Deployed into its production environment, quali-
fication reviews are performed on the software and a
subset of the test suite is used to validate the software
with the customer and other interested parties. Each
software artifact is verified and traceability is demon-
strated throughout the entire process. Qualification
review results are captured in the qualification plan,
but completion of the qualification activities is docu-
mented in the integrity plan.
3.1 The Software Integrity Plan
The integrity plan consists of four major sections.
The first section provides project-specific informa-
tion, governing criteria, and the project scope. Section
two addresses the project management activities, nor-
mally by pointing to a separate project management
plan. Specifically, integrity management can point to
the other project artifacts for such management prac-
tices as development, resources, configuration con-
trol, and software quality assurance. Section three
addresses preliminary integrity analyses and grading.
This section also provides additional detail to flow
system hazards and system risk criteria down as the
starting point for the software integrity process. Sec-
tion four follows each stage of the enhanced-integrity
life cycle development process. Separate subsections
address the development activities for each of the as-
sociated life cycle phase practices, but from an in-
tegrity position. For instance, at the requirements
stage, those requirements that are integrity related are
identified and used to develop a requirements track-
ing database. This database is added to the plan and is
part of the resulting evidence package. Likewise, the
design stage focuses on flow down from the integrity-
related requirements and assures that any integrity-
ICSOFT 2010 - 5th International Conference on Software and Data Technologies
152