Kroll Rational Easy Made Unified
Kroll Rational Easy Made Unified
Kroll Rational Easy Made Unified
– Martin/Odell A B
– Shlaer/Mellor A B
– Rumbaugh A B
1 B
– UML A
• Results
– UML (Unified Modeling Language)
• An open standard for the modeling notations
– RUP (Rational Unified Process)
• A proprietary methodology by Rational
• Key concepts
– Use-case driven
– Iterative and Incremental process
– Architecture-centric
Logical Implementation
View View
Use-Case
View
Process Deployment
View View
• Use-Case View
– Contains a few key scenarios and use cases
– Initially used to drive the discovery and design of
architecture in the inception and elaboration phases
– Later used to validate the different views
• Activities
– The work performs by the role
• Artifacts
– Entities that the role creates, modifies, or controls
• Workflow
– A sequence of activities supported by the interaction of
roles that produces a result of observable value
• Examples of Artifacts
– Use-case model, design model
– Model element: class, use case, subsystem
– Document: software architecture document
– Source code
– Executables
Department of Information Engineering 34
Example of artifacts produces
Analyst
Role
Use-Case Use-Case
System Analyst Model Design
responsible for
Artifact
Use-case realization
• System analyst
– Business modeling workflow
– Requirements workflow
– Design and analysis workflow
• Project manager
– All of the workflows
• The objectives
– To allocate tasks and responsibilities to a team of
people
– To monitor progress and to detect potential
problems as the project is rolled out
Resemble a UML
activity diagram
• Ref:
– “Extreme Programming Explained” by Kent Beck
(Addison-Wesley, 2000)
• Rely on refactoring
– Instead of spending much time on initial architecture,
rely more on continuous redesign of the code
Cost of change
Cost of change
time
• Four values
– Communication
– Simplicity
– Feedback
– Courage
• Metaphor
– The metaphor is a simple shared story or description
of how the system works
• Testing
– Customers write functional tests to test the stories.
Programmers write tests to test anything that can
break in the code. Write tests before the code
– JUnit by Gamma and Beck
Department of Information Engineering 75
XP Twelve Practices
• Simple design
– Keep the design simple by keeping the code simple.
Continually look for complexity in the code and
removes it at once
• change names to be more appropriate, remove
comments by improving code
• Has the fewest possible classes and methods
– XP believes future is uncertain, and one can cheaply
change the mind, so don’t speculate too much
• Collective ownership
– Everyone owns all of the code. This means everyone
has the ability to change any code at any time
• On-site customer
– A real customer works in the development
environment full-time to help define the system, write
tests, and answer questions
• Coding standards
– The programmers adopt a consistent coding standard
• This site is full of useful information, the map below is just one of
the example
• Why?
– To outsource project, how to rate the contractors?
– To the contractor, how to improve the maturity of
its development process?
Department of Information Engineering 87
CMM (Capability Maturity Model)
• Maturity level is a measure of the process capability of the
organization
• CMM has
– 5 Levels
– 18 KPA
– 52 goals
• Goal-1
– System requirements that are allocated to software are
controlled to establish a baseline for software engineering and
management use
• Goal-2
– Software plans, products, and activities are kept consistent
with the system requirements allocated to software
• Goal-2
– Software project activities and commitments are planned and
documents
• Goal-3
– Affected groups and individuals agree to their commitments
related to the software project
• Goal-1
– Actual results and performance are tracked against the
software plans
• Goal-2
– Corrective actions are taken and managed to closure
when actual results and performance deviate
significantly from the software plans
• Goal-1
– The prime contractor selects qualified software subcontractors
• Goal-2
– The prime contractor and the software subcontractor agree to
their commitments to each other
• Goal-3
– The prime contractor and the software subcontractor
maintain ongoing communication
• Goal-4
– The prime contractor tracks the software subcontractor’s
actual results and performance against its commitments
• These goals fall outside the current scope of RUP and XP, and are
dependent on the organization
Department of Information Engineering 108
Software Quality Assurance
• To provide management with appropriate visibility
into the process being used by the project and the
products being built
• Goal-1
– Software quality assurance activities are planned
• Goal-2
– Adherence of software products and activities to the applicable
standards, procedures, and requirements is verified
objectively
• Goal-3
– Affected groups and individuals are informed of software
quality assurance activities and results
• Goal-4
– Noncompliance issues that cannot be resolved within the
software project are addressed by senior management
Department of Information Engineering 109
RUP’s perspective on quality assurance
• RUP’s milestone has specific completion criteria that can serve as
a basis for auditing
• Each activity within RUP has a separate review activity
• Each review has a set of checkpoints that need to be passed
• RUP’s metrics
– Progress (lines of code, number of classes, …)
– Quality (defect discovery rate, …)
– Maturity (test hours per failure)
– Expenditure profiles on resources (planned vs actual)
• Goal-4 falls beyond the scope of RUP
• Goal-1
– Software configuration management activities are planned
• Goal-2
– Selected software work products are identified, controlled, and
available
• Goal-3
– Changes to identified software work products are controlled
• Goal-4
– Affected groups and individuals are informed of the status and
content of software baselines
• www.azeus.com
– The first Chinese Level-5 company based in HK
Department of Information Engineering 113