International Journal of Advanced Science and Technology

Vol. 48, November, 2012

RUP Certification via CRM Certification Process: Development of

Software with Zero Defect Rate
Muhammad Javed, Bashir Ahmad, Muhammad Ahmad Jan, Muhammad Ali Abid
and Muhammad Ali Shah
Institute of Computing and Information Technology Gomal University,
K. P. K, D. I. Khan, Pakistan
[email protected] , [email protected], [email protected]
[email protected],[email protected]
Abstract
RUP is based on UP and OOP methodology in order to develop an application whose
scope spans to enterprise level but it is labeled as a immature and disorganize development
as it involves rework, provided any shortcomings are found in the accomplished phases.
Moreover it is observed that risk identification and resolution is not properly handled in RUP
as its analysis has no roots towards mathematical framework and no statistical grounds for
correctness and reliability. The RUCM, Rational Unified Cleanroom Model- The proposed
model, comprises of best practices and principles both of CRM and RUP. Mathematical
framework, Mathematical modeling, quantification, statistical test, certification process are
the implemented best practices which ultimately leads towards the complete customer
satisfaction and a defect rate of zero percentage.
Keywords: RUP (Rational Unified Process Model, Rework, RUCM (Rational Unified
Cleanroom), Zero defect rat

1. Introduction
Only the two phases of RUP Inception phase and Elaboration phase can be mapped with
Cleanroom methodology whereas Construction phase and Transition Phase play the same role
for development as in Cleanroom methodology. For first phase of RUP, the Use cases can be
mapped with Box structure of Cleanroom methodology and for second phase of RUP,
Analysis can be mapped with Correctness process of Cleanroom methodology [1].
In Cleanroom methodology box structure is used for defining the behavior of system and it
is used to collect the system requirements. In Cleanroom methodology refinement process for
requirements specification is also performed by box structure.
On the other hand in RUP use cases are used to confine the requirements of the system.
The behavior of the entire system in RUP can also be expressed by means of use cases. In
Cleanroom methodology each and every activity is verified means of validation process i.e.
all the defects are removed from an activity, 100 % customers needs are satisfied and no
further iteration is required for the refinement process of that activity.
On the other hand in RUP there is no verification and validation process is found to check
the reliability and efficiency of an activity. When the required expectations are not achieved
then there is a need of rework for that activity which is the major drawback of this process, so
there is a need to map the verification process of Cleanroom methodology to RUP.

International Journal of Advanced Science and Technology

Vol. 48, November, 2012

Cleanroom methodology has100 % levels of certification of a process completion. When

100% customers needs are satisfied then acceptance certificate is to be issued for the
completion of an activity process.
On the other hand in RUP, when the activity is completed in any iteration then certificate is
not to be issued, due to this major flaw reworking process is performed for that activity when
the desired expectations are not meet. In Cleanroom methodology there is no reworking
process, because each and every activity is completed with proper certification process. So
this feature of Cleanroom methodology should be map with RUP.

2. RUP
It was Philippe Kruchten, Ivar Jacobson and few others who conceptualized the RUP as a
process harmonized to UML. Rational Software Corporation provides the RUP as the process
product for execution of the projects along with its standards, guidelines and templates [2].
RUP can be viewed using both the static and dynamic aspects. Static aspect of RUP involves
Role, Activity, Workflow and Artifacts where as dynamic aspects involve various phases and
their iterations. RUP comprises of four phases as shown in Figure 1.

Figure 1. Overview of RUP Model

2.1 Inception Phase
The paramount intention of the Inception phase is the involvement of all stakeholders in
the objectives of the project. The major artifacts of Inception phase are

An initial use-case model (10% or 20% complete) when dealing with an initial
development cycle

A domain model which is more sophisticated than a glossary

A business model , One or several prototypes

A preliminary development case description.

International Journal of Advanced Science and Technology

Vol. 48, November, 2012

A landmark or milestone is established which is "life cycle objective". The appraisal

criterions of Inception phase encompasses Stakeholder agreement on scope characterization
and cost and on schedule approximations, Requirements consideration, trustworthiness of the
expenditure and plan estimates, prioritize risks and development process, and Depth and
breadth of any architectural prototype.
2.2 Elaboration Phase
It is considered as the most critical of all the phases of RUP. Its main objective is to
scrutinize the problem realm, set up a sound architectural groundwork, widen the project plan
and eradicate various risks and threats to project. The various conclusions of the elaboration
phase are

A use case model which includes all possible use cases

List of accompanying obligations responsible for non functional requirements

Explanation of software architecture

An executable architecture prototype

A improved list of risks

A comprehensive project plan

An modernized development case that identified the process to be used

A preliminary user instruction manual

2.3 Construction Phase

In this phase, all residual machinery and functions are industrialized and interacted into the
product plus all the features are debugged. The construction phase is carried out in parallel if
the project is large enough. The outcomes of construction phase are

Fully tested and reliable product incorporated and integrated on platform

Comprehensive instruction manuals

Details of current release

2.4 Transition Phase

Transition phase is the handing over the product in the user control. Delivery of the product
does not ends the responsibility of the development team rather the development team
continues to work on the maintenance and keep on producing new releases till the stability is
achieved.
The essential activities of the transition phase are

Deployment of the product

International Journal of Advanced Science and Technology

Vol. 48, November, 2012

Optimizing and tuning the processes along with bug fixing, if any

Evaluating the deployment requirements according to available circumstances

RUP is considered as one of mature software development standards and is applicable to

versatile projects. The best practices of RUP are Development of software in iterations,
Requirement management, Architecture and use of components, visually modeling the
software like prototyping, Controlling and Managing requirements and constantly evaluating
the quality of end product [10].

3. Cleanroom Software Development Methodology

Dr.Harlan Mills along with his a number of colleagues are considered as the pioneer of the
Cleanroom process. The main intent of this process is to make the final deliverable
completely error free as this itself is the standard of a low cost product [4]. This process of
making error free product yields an output of highest quality and at the same time critical for
decision making. The Cleanroom process is an end to end disciplined approach for software
development which involves all the stages like planning, designing, testing. At the end of a
successful development increment, a certificate is issued which certifies that the increment is
completely error free and is at zero defects rate, confirming there will be no need of rework
[3].

Figure 2. Cleanroom Certification Process Model

3.1 Requirement Gathering
Requirements gathering phase involve all comprehensive details of the requirements
of the customer which will be analyzed and designed in each increment.
3.2 Box Structure Specification
Box structure involves the separation and isolation of behavior, data and procedures
defined in the functional specification phase.

International Journal of Advanced Science and Technology

Vol. 48, November, 2012

3.3 Formal Design

Various specifications, also known as black boxes, keep on being refined and polished in
every upcoming increment so that they become equivalent to the architectural and procedural
designs, which are also known as state boxes and clear boxes, correspondingly [5].
3.4 Correctness Verification
The correctness verification is carried out starting from the box structure which is at the
highest level and then progressing towards the detailed design and coding by means of
correctness questions. If by any chance these practices do not certify the correctness of the
specifications, then as a result of this more ceremonial mathematical routines are used for
authentication.
3.5 Code Generation, Inspection and Verification
The box structure specifications which are symbolized using their appropriate languages
are transformed into suitable programming languages.
3.6 Statistical Test Planning
It involves the planning and designing of a series of test cases which put into effect the
probability distribution.
3.7 Statistical Usage Testing
The Statistical Usage Testing accomplishes a set of tests which are originated from a
statistical sample possible program by all users. It involves the creation of test cases, their
respective execution and collection of error data [6].
3.8. Certification
As all the verification, inspection and usage testing is successfully accomplished plus all
possible and potential errors are corrected, then the increment is given a clearance certificate
which guarantees that it can be integrated easily.

4. Mapping of CRM into RUP

RUP consists of four phases .Each activity in every phase of RUP can be completed in
number of iterations and after the completion of each iteration there is a need to issue a
certificate to carry on work successfully and verified by the customer needs via this
certificate. The next iteration can never be started until or unless if the acceptance certificate
is not to be issued to the previous iteration. The acceptance certificate will be issued only on
these conditions, there should be no existence of defect rate, the correctness and verification
is to be performed by statistical test and customer needs must be satisfied if any one condition
is not to be satisfied then the acceptance certificate can never be issued for the completeness
of that activity.

International Journal of Advanced Science and Technology

Vol. 48, November, 2012

4.1 Overview of Mapping of Major Features of CRM and RUP for Box Structure and
Use Case
By incorporating all the best features of CRM into RUP, the overall documentation,
quality, efficiency and performance is to be increased up to the highest level of satisfaction
and the time for development is also decreases through proposed model named as RUCM
(Rational Unified Cleanroom Model).
Table 1. Overall Mapping Features of Cleanroom Methodology and RUP Box
Structure and Use Case

5. RUCM
RUCM comprises of two additional phases which are not available in RUP. These phases
are System perception phase and planning phase, and number of changes has been made in
elaboration phase of RUP by adopting the best features of Cleanroom methodology to
increase the documentation regarding quality, efficiency and performance. The effort required
for the completion of project is also decreased.
According to Authors proposed model When the features of Cleanroom software
engineering are incorporated into RUP in inception phase, the sub phases of RUP i.e.
identification of most essential requirements, Mile-wide inch deep description and the
detail key actors and use cases are combined then a new phase is generated named as System
perception phase where these three phases are merged. The logical flow of these steps with a
new sequence for System perception phase in proposed model as shown in Figure 3.

International Journal of Advanced Science and Technology

Vol. 48, November, 2012

Figure 3. System Perception Phase

6. Certification process for System Perception phase

The detail certification process for each activity involved in the System Perception phase is
as under:
6.1 Certification of User
For the issuance of users certificate it is to ensure that all the actors have been properly
identified and their roles are well understood.
Table 2 illustrate that during the first iteration objectives of the user specification have
been achieved to fulfill the customer needs therefore certificate has been issued in first
iteration.
6.2 Certification of Business Process Specification
For the issuance of Business process specification certificate, when all the required
business processes are covered by business process specification then certificate will be
issued. For this activity the statistical test can be applied between customer needs and leading
of defects. When the results are to be achieved after verifying these fields Customers need,
zero defect rate, statistical test then acceptance certificate will be issued. In Table 2 results are
not achieved according to the required customers expectations in iteration-1 (I-1) because
customers needs are not satisfied and defect rate is also exist and statistical test is not
verified so certificate is not issue for the completion of this activity, so the iteration-2 (I-2) is
required to refine the Business process Specifications .In this iteration customer needs are
satisfied but the defect rate is also exist and the statistical cannot be verified so certificate is
not to be issued for this iteration , there is a need of iteration-3 (I-3). In iteration-3 the
customer needs are satisfied but defect rate is still exist and the statistical test can not verify
this activity so certificate is not to be issued , so there is a need of iteration-4 (I-4). In this

International Journal of Advanced Science and Technology

Vol. 48, November, 2012

iteration the activity is completed , because customers needs are satisfied , and defect rate is
not exist , the statistical test is also verified , so the acceptance certificate is to be issued for
the completion of this activity as illustrated in Table 2.
The same analogy will be applied to all the activities in Table 2.
6.3 Certification of Functional Areas
For the functional Areas activity customer needs must be 100 % satisfied , because this
activity is completed by programming and if any defect is found in functional area then
required results cannot be achieved for a specific function , this activity is also completed in
iteration-4 as shown in Table 2 where customer needs are satisfied , and defect rate is not
exist , the statistical test is also verified , so the acceptance certificate is to be issued for the
completion of this activity.
6.4 Certification of Non-Functional Requirement
It is not easy process that the non-functional requirements are added in system at the end.
The non-functional requirements should be included throughout the development process.
Table 2 illustrates that during the first iteration all customers needs are to be satisfied, so
the acceptance certificate is to be issued for the completion of this activity.
6.5 Certification of Business Process Execution
For the issuance of Business process executions certificate it is to ensure that all the basic
plans and normal the iteration-4 this activity is completed, where all the customers needs are
needs are cause of actions and standards provided to execute the business process.
Table 2 illustrates that during to be satisfied and no defect exist and statistical test is also
verified, the acceptance certificate is to be issued for the completion of this activity.
6.6 Certification of Use Cases
Use cases are used in system analysis to identify, clarify, and organize system
requirements. The use case is made up of a set of possible sequences of interactions between
systems and users in a particular environment and related to a particular goals, if all the
functional requirements are organized and customers needs are fulfill and having no defect in
System requirements and statistical test is also verified then certificate is to be issued for the
completion of this activity. This activity is completed in iteration-2 as illustrated in Table 2.
6.7 Certification of Functions Deliverables
For function deliverable activity, the objective of statistical test over function test is to
measure the quality of the functional (business) components of the system whether the
function is deliverable or not if the function is ready to deliver for any system and fulfill all
the needs of customer then certificate will be issue and if the function deliverable not fulfill
all the customers needs then next iteration is to be required to clarify function deliverables.
This activity is completed in iteration-4 where customer needs are satisfied and defect are not

International Journal of Advanced Science and Technology

Vol. 48, November, 2012

exist, statistical test is also verified so the acceptance certificate is to be issued for the
completion of this activity as illustrated in Table 2.
6.8 Certification of Formal Specifications
For the certification of formal specification activity, when requirement specifications to be
clarified, precision and accuracy is to be improved in requirement specification then
certificate is to be issued. This activity is completed in iteration-4 where the customers needs
are to be satisfied and no errors are defects are to be found and statistical test is also be
verified so the acceptance certificate is to be issued for the completion of this activity as
illustrated in Table 2.
6.9 Certification of Functional Analysis
For the issuance of certificate for Functional analysis, when required tasks for processing
are refined for desired functions then certificate will be issued. This activity is completed in
iteration-2 Functional where all the customers needs are to be satisfied and defect are not
exist, statistical test is also verified so the acceptance certificate is to be issued for the
completion of this activity as illustrated in Table 2.
6.10 Certification of Document Functional Requirements
For the issuance of certificate to this activity, when all the functional requirements are
associated with business requirements and all plans are provided for functional requirements
then certificate will be issued. This activity is completed in iteration-1 where all customers
needs are satisfied, so certificate is to be issued for the completion of this activity as
illustrated in Table 2.
6.11 Certification of Document Subsystem
For the certification of document subsystem when each subsystem defined the customers
needs then certificate will issued. This activity is completed in iteration-1 where all
customers needs are satisfied, so certificate is to be issued for the completion of this activity
as illustrated in Table 2.
6.12 Certification of Traceability Matrix
For the certification of traceability matrix when all the test cases are to be properly mapped
to customers requirements, system specification should be validated and verified and quality
of system should also improved against identifying requirements. This activity is completed
in iteration-4 where the customers needs are to be satisfied and no errors are defects are to be
found and statistical test is also be verified so the acceptance certificate is to be issued for the
completion of this activity as illustrated in Table 2.

International Journal of Advanced Science and Technology

Vol. 48, November, 2012

Table 2. Execution of Template for Certification of Perception Phase

7. Conclusion
It has been observed by adopting the best features of Cleanroom methodology to increase
the documentation regarding quality, efficiency and performance. The effort required for the
completion of project is also decreased. The RUCM is all about focusing on software
development with the involvement of all stakeholders at greatest possible level and this yields
improved process quality. Certifying each increment guarantees the improved process quality
and that is what lies at the heart of RUCM. As far as quality of each increment is considered
in RUP, each increment is not thought as the mature one but at the same time RUCM carries
the opposite properties to that of RUP in this regard.

References
[1] B. Ahmad, et. al., Exploring Documentation: A Trivial Dimension of RUP, Computer Engineering and
Intelligent Systems, ISSN 2222-1719, (Paper) ISSN 2222-2863, vol. 2, no. 4, (2011).
[2] P. Kruchten, "Rational Unified ProcessAn Introduction", Addison-Wesley, (1999).
[3] H. Mills, M. Dyer and R. Linger, "Cleanroom software Engineering, IEEE Software, vol. 5, (1987)
September, pp. 19-25, doi:10.1109/MS.1987.231413.
[4] https://dap.dau.mil/policy/Documents/Policy/003EVDOC.doc.
[5] M. J. Banks, Formal Modeling of Secure Systems Qualifying Dissertation, (2009) July.
[6] C. Trammell, Quantifying the reliability of software: statistical testing based on a usage model, Experience
and practice, Proceedings, Second IEEE International, (1995) August.

10