29/04/2014
Using RUP
Following the RUP process
• You need a defined software process to follow in your projects:
– For CSCI222:
Examples and illustrations from various sources at Rational, other parts of
IBM’s “developerworks” site and the reference text
The Rational Unified Process: An Introduction: P Kruchten
(Available as electronic resource via Uni library)
• A1 : completion of design, and implementation
• A2 : initial requirements, and high level design
– For CSCI321:
• From requirements to delivery
• As mentioned before
– Agile methods – not really appropriate; they are too intense for student
projects (100% participation, whole group, daily scrum, osmosis, pairs, etc);
further, they don’t deliver many of items that would be required for
assessment (like design documentation!)
• Chosen approach : you will RUP
– OK, RUP is adjustable in its formality¶
– When you make your “development case” you will be able to
determine which RUP features to include in your CSCI321 project
1
¶Software Engineers have adopted the word “ceremony” – a regimented waterfall style development with lots of formalized
hand-over points is referred to as “high ceremony”, an XP development that degenerates into simple hacking would be
“low ceremony”. Weird term. Sounds to me like something to do with religious practices.
2
RUP – Principles
“Philosophies of RUPing”
• Principles:
– Adapt the process
– Balance stakeholder priorities
– Collaborate across teams
– Demonstrate value iteratively
– Elevate the level of abstraction
– Focus continuously on quality
“Key principles for business driven development”
Koll + Royce
3
Remember these?
RUP
4
Not Winston Royce of “waterfall” fame!
RUP – working it out
•
•
•
•
•
•
•
•
•
•
• Spirit
– Attack major risks early and continuously… or
they will attack you.
– Ensure that you deliver value to your customer.
– Stay focused on executable software.
– Accommodate change early in the project.
– Baseline an executable architecture early on.
– Build your system with components.
– Work together as one team.
– Make quality a way of life, not an afterthought.
Develop a Vision
Manage to the Plan
Identify and Mitigate Risks
Assign and Track Issues
Examine the Business Case
Design a Component Architecture
Incrementally Build and Test the Product
Verify and Evaluate Results
Manage and Control Changes
Provide User Support
“Ten Essentials of RUP” L Probasco
and these?
“Spirit of RUP” P Kroll
5
Maybe these?
6
1
29/04/2014
RUP – the principles
Adapt the process
• Complex systems  more process!
• Vary during lifecycle – at start when in innovative imaginative
phases use light “ceremony”; in later phases will want more
restrictions on changes.
• Try to improve process – assessments at end of iterations etc
• OK, these are a little remote from the
concerns of students doing standard
student projects!
• They are intended as guidelines almost
for IT managers negotiating with client
groups!
• Still, the principles are important …
7
8
Principles!
Collaborate across teams
Balance stakeholder priorities
• First: understand and prioritize business and stakeholder needs.
Involve the customer in the project to ensure you understand
their needs.
• Centre development activities around stakeholder needs.
Stakeholder needs will evolve. The development process needs
to accommodate these changes.
• Balance asset reuse with stakeholder needs – quite often a
large percentage of desired functionality can be realized simply
by adapting existing legacy systems (often just by putting a
WWW front-end on them!). Make sure that the remaining
desired functionality really justifies custom development.
• Utilize component technology to build systems from standard
subparts! Components substantially reduce the cost of
delivering desired functionality.
9
Principles
Demonstrate value iteratively
• Teams? Business, software, operations
• Empower the individual teams
– Ideas similar to “agile”; self-managed team,
with authority to make decisions
• Team Interactions?
– Facilitate through environment
• Wikis etc constructed to document the system
• Integrated development environments, change
management systems
Principles
10
Elevate the level of abstraction
• Deliver incremental value to enable early and
continuous feedback –
– Get the feedback early “Oh, no maybe that isn’t what
we really want; something more like …”; you can then
incorporate the changes before too much
commitment to an incorrect solution
• “One effective approach to reducing complexity is reusing
existing assets, such as reusable components, legacy systems,
existing business processes, patterns, or open source
software.”
– Reuse “middleware”: databases, Web servers and portals
– Exploit open source software
– Reuse existing assets through “service oriented
architectures”
• Iterative approaches also reduce risk
Principles
11
Principles
12
2
29/04/2014
Focus on Quality
Focus continuously on quality
• “Ensuring high quality requires more than the
participation of the testing team; it requires that the
entire team owns quality. It involves all team
members and all parts of the lifecycle.”
“One of the major benefits of iterative development is that it
enables a test early and continuously approach.
…
As we incrementally build our application, we should also
incrementally build test automation to detect defects early”
– Analysts: make sure that requirements are testable.
– Developers: design applications with testing in mind, test
their code.
– Testers (the “quality experts”) guide the rest of the team in
understanding software quality issues, and are responsible
for functional-, system-, and performance-level testing.
• “When we experience a quality issue, every team
member should be willing to chip in to address the
issue.”
13
Principles
RUP - Spirit
14
Principles and spirit
• Spirit
• The principles – well they are more for
your boss.
• The spirit – setting the culture of your
development group
– Attack major risks early and continuously… or
they will attack you.
– Ensure that you deliver value to your customer.
– Stay focused on executable software.
– Accommodate change early in the project.
– Baseline an executable architecture early on.
– Build your system with components.
– Work together as one team.
– Make quality a way of life, not an afterthought.
– Of course, some overlaps with principles
• Your boss has his principles
• Your team has spirit
• But much the same
15
16
Ensure that you deliver value
to your customer.
Attack major risks early and
continuously… or they will attack you.
• At the beginning of each iteration, revise your list of
risks. Prioritize the risk list, then decide what you
need to do to address.
• Examples of risks
• Use cases
– They are an expression of the customers needs
– They drive the entire project – every bit of code can
ultimately be related back to a defined use case.
– How to integrate with some legacy system: e.g. existing database is
hierarchical, the transaction system uses COBOL tasks,
– Ms. K. Styles, project liaison officer in the XXX department, has
negative approach to all new systems
– Requirement to use new technology – no existing experience
among team members
• Addressing the risks
– Subcontracting specialist tasks?
– Require written agreements on requirements from client
departments; keep them involved with prototyping; solicit their
feedback?
– Training?
Spirit
– Team members at all levels can relate their work back to
requirements
– Use cases – “user manual without the final user interface!”
17
Spirit
18
3
29/04/2014
Accommodate change early
in the project
Stay focused on executable
software.
• Change to the business model
• The best way of measuring progress is by
measuring what software is up and running.
– Can accommodate these in the “Inception” phase, after that
costs rise as such changes will involve major rework
– Get agreement on the business model at time “vision” is
agreed
– you should always strive to have working software
demonstrated and to look at test coverage and
test results
• Change of architecture
– Architectures are explored during elaboration, after that
changes will be costly
• Also, having working code allows you to start
on the supporting artifacts – the deployment
scripts, the database migration components
etc which you will need
• Change in design and implementation
– Proper component based, iterative development style can
accommodate such changes during construction phase.
Costs will rise if changes needed later during transition
• Change of scope
– Can always cut scope; “feature X will now appear in Release
2”
Spirit
19
20
Spirit
Baseline an executable
architecture early on.
Accommodate change - costs
• Largest project risks are associated with
the architecture.
• RUP make creation of a functioning
architecture the primary objective of the
Elaboration phase
• Architecture?
– The component building blocks and their
interfaces
21
Architecture
22
Spirit
Aside on “architecture”
• At this point, the “spirit of RUP” is concerned with “Enterprise”
systems – the kinds of software really used in commerce and
industry.
• Such systems are built on top of various middleware – Webservers, application servers, transaction monitors, databases,
message queue systems.
• These are not built for any particular project – rather projects
must be built on top of them.
• It is essential to get this architecture clear from the start.
• Student projects are of course very different
23
– You might get a Web-Server and a database involved but for
various reasons other middleware components are not covered at
university!
– Your architecture will be limited to defining different processes (if a
“system” rather than a program) and their interactions, and defining
any persistent data.
– Still you have to get even that simple architecture baselined during
your elaboration phase.
24
4
29/04/2014
Build your system with
components.
Work together as one team.
• “Traditionally, many companies have had a functional
organization: All the analysts are in one group, the
designers are in another group, and testers are in yet
another group.”
• “Component-based development encapsulates data
and the functionality operating upon that data into a
component.”
– Effective communication among the three groups becomes
compromised resulting in miscommunication, extra work,
and missed deadlines.
• For iterative developments, it is better to
Actually, this is a rather naïve view of components – it is really describing
Object based development. “Components” will be discussed more later;
one should try to exploit “real components” wherever possible.
Spirit
– Organize your projects around cross-functional teams
containing analysts, developers, and testers.
– Provide teams with the tools required for effective
collaboration across functions.
– Ensure that team members have the attitude of "I'll do what it
takesto get high-quality working software,"
25
Make quality a way of life, not
an afterthought.
Aside on the team
• Of course, in student projects you have
no choice;
you are the entire team – customer(!),
analyst, designer, tester
• Same as in the principles
– Design and implement for testability
– Always have working version
–…
27
RUP – working it out
•
•
•
•
•
•
•
•
•
•
28
Spirit
RUP – yes well you get the gist …
Develop a Vision
Manage to the Plan
Identify and Mitigate Risks
Assign and Track Issues
Examine the Business Case
Design a Component Architecture
Incrementally Build and Test the Product
Verify and Evaluate Results
Manage and Control Changes
Provide User Support
Ten essentials
26
Spirit
• Ten essentials
– More of the same
• But becoming slowly more concrete
– “Develop a Vision”
– “Manage by the Plan”
–…
29
30
5
29/04/2014
RUP: a process (meta) model
So, what is RUP?
• RUP: a model for a software development
process
• Possibly it’s more a meta-model (a model for a
set of models) because RUP is deliberately
flexible – RUP is to be tailored to the needs of
your project.
• The model is the defining core of RUP
And how do you follow it?
– Four phases
– Multiple disciplines
– Iterations
31
The essence of RUP
32
Scripts to guide you
For each phase
for each discipline
for each role in discipline
RUP has a script to guide you
What should you be doing?
What information will you need?
What artefacts should you produce?
You can never say that you don’t know what you should be doing!
You just have to check the relevant script!
33
Roles and disciplines
34
Analyst roles
• Clearly there are roles like “manager”, “analyst”,
“developer”, …
• RUP’s role definition is considerably more precise
listing numerous specialized roles
• The Analyst Roles
– Business-Process Analyst
– Business Designer
• The two “business” roles are not relevant for you. They belong to
BUSS/IS-IT graduates. They involve modelling the existing business
practices of an organization. They are looking at how the organization
will change as a result of new systems and technologies being
introduced.
– Not all projects require all roles to be filled e.g. “capsule designer”
is a specialized role relating to concurrent and time dependent
processing
– Some role sets have generally similar responsibilities, the different
roles capture subtle differences in emphasis
– System Analyst
• Remember – in every student project (and many real
projects) you will serve in different roles at different
stages of the project.
• The roles do matter; when your project group forms,
its first task will be to assign roles (and, hence,
responsibilities) to its members.
35
• Requirements elicitation
• Use-case modelling
– identifying actors and the use cases they will require when interacting with
the system.
– Requirements Specifier
• The Requirements Specifier specifies the details of the system's
functionality
– use cases,
– supplementary specifications (non-functional requirements)
36
6
29/04/2014
Developer Roles
Manager roles
• The Developer Roles
•
– Software Architect
The Manager Roles
– Project Manager
• Identify and document the architecture
• Major responsibility for minimizing technical risks.
• Allocates resources, shapes priorities, coordinates interactions with the customers
and users
• Establishes a set of practices to ensure the integrity and quality of project
artefacts.
– Designer
• Identify and define the responsibilities, operations, attributes, and
relationships of design elements.
– Change Control Manager
– User-Interface Designer
• The one responsible for agreeing to changes requested by stakeholders after
project commencement.
• Design of the user interface.
• Gathering of usability requirements
• Prototyping candidate user-interface.
– Configuration Manager
• Provides configuration management infrastructure and environment
– Capsule Designer
– Test Manager
• (Specialized role relating to concurrency and time critical operations)
• Quality and test advocacy, resource planning and management, and resolution of
issues that impede the test effort.
– Database Designer
• Defines the tables, indexes, views, constraints, triggers, stored
procedures, table spaces etc
• Deals with the CRUD operations (create, read, update, delete
persistent data).
– Deployment Manager
• Developing and testing “components”.
– Management Reviewer
• Plans the product's transition to the user community, and ensures its correct
delivery
– Process Engineer
• Revising and improving the software development process being employed
– Implementer
• Evaluate project planning and project assessment artefacts at major review
points in the project's lifecycle.
– Integrator
• Integration of implementation elements to produce builds.
37
Tester Roles
Clearly it would be unusual to have a person designated as “Process Engineer” whose only task was looking at how
to improve the development process. Like many of the roles, this would really be just one of the tasks of the “Project Manager”. RUP
defines the different roles so as to better characterize responsibilities and to allow the definition of workflows and artefacts.
38
Production and Support Roles
• The Tester Roles
• The Production and Support Roles
– Test Analyst
• Responsible for identifying and defining the required tests,
monitoring detailed testing progress and results in each test
cycle, and evaluating the overall quality experienced as a result
of testing activities.
– Test Designer
• Responsible for the planning, design, implementation, and
evaluation of testing, including generation of the test plan and
test model, implementation of the test procedures, and
evaluation of test coverage, test results, and effectiveness.
– System Administrator
• Maintains the development
– Technical Writer
• Produces end-user support material, such as user guides, help
texts, release notes, and so on.
– Graphic Artist
• Creates product artwork that is part of the product packaging
and documentation.
– Tool Specialist
– Tester
• Responsible for the core activities of the test effort, which
involves conducting the necessary tests and logging the
outcomes of that testing.
• Responsible for the supporting tools of the project – compilers,
IDEs, version management, libraries, frameworks, …
– Course Developer
• Develops training material to teach users how to use the
product.
39
Select your roles …
Your group will need to cover all roles that you identify as required in
your project. Individuals “bid” for roles on basis of skills – “I’ve done
CSCI235, so I can be database designer”. You will get multiple roles.
You need to understand how your roles fit with RUP’s main workflows.
40
… and start to RUP
41
42
7
29/04/2014
Start at Inception
RUP Phases – and milestones
Mostly requirements, a little analysis
and design –
identify the most important “use cases”,
evaluate possible architectures.
Support roles concerned with putting
in place infrastructure (project management
tools, development systems etc) as these
are identified.
43
44
We will ignore Business Modelling
Inception – “executive
summary”
Inception
• Understand the overall requirements.
• Determine the scope of the
development effort.
• Main goal of the inception phase is
achieve agreement among all
stakeholders as to the objectives for the
project.
• Objectives of the inception phase:
– Establish the project's software scope and acceptance
criteria.
– Establish the main use-case scenarios that define the core
functionality of the project.
– Evaluate alternative architectures; create the beginnings of
your preferred candidate architecture.
– Estimate the overall cost and schedule for the project.
– Estimate risks
– Produce the “business case” – the rationale for the “use
case” requirements, what is the business justification and
benefit from having the functionality provided.
– Create a work plan for the following elaboration phase (you
also create a tentative plan for the entire project – you will already be
starting to think in terms of phased delivery: use-cases 1..7 in construction
phase-1, 8..13 in phase-2; these will be “guesstimates” at this stage, you
will have a better idea by the end of the subsequent elaboration phase)
45
What must you produce
46
The Vision …
• A vision document
– the core project's requirements,
– key features,
– main constraints
• List all use cases and actors already identified
• An initial project glossary
• An initial business case, which includes the following:
– Business context
– Success criteria (revenue projection, market recognition, and
so on)
– Financial forecast
• An initial risk assessment
• An initial project plan, which shows the phases and
iterations
• What are you going to create?
– What is it?
– Who will it serve?
– What problems does it solve for them?
• Every group member keeps a copy pasted up by their
computer!
47
48
8
29/04/2014
Glossary
You might also produce …
• Glossary
– “a list of terms in a special subject, field, or area of
usage, with accompanying definitions”
• Does ATM stand for
– “Asynchronous Transfer Mode”
– “Automatic Teller Machine”
• Why do we have “corporate user” and
“user” – in what ways are they different?
• An initial use-case model (10% to 20%
complete)
• A development case description that
specifies the particular RUP process
features that will be used in subsequent
phases.
• Prototypes
49
You want to get to “Objective
Milestone”
50
Oh, you didn’t drop the subject
Elaboration!
– best get on with
• What’s this milestone thing?
– A chance to evaluate the project – do we continue, do we
cancel?
Requirements continue
to be refined and additional
use cases will be identified.
But now more into getting
a baseline architecture, and
working from use cases to
ideas for classes and their
interactions.
• Evaluation criteria:
– Stakeholder concurrence on scope definition and cost and
schedule estimates
– Requirements understanding as evidenced by the fidelity of
the primary use cases
– Credibility of the cost and schedule estimates, priorities,
risks, and development process
– Depth and breadth of any architectural prototype that was
developed
Student projects? Well, you can’t cancel (other than by dropping the subject!).
But you can always try a second iteration through inception if you aren’t confident
that you should start Elaboration.
51
Elaboration “the most critical
of the four phases”
52
Elaboration must deliver
“Executable architecture”
• Elaboration phase
• Executable architecture prototype is
– analyse the problem domain,
– establish a sound architectural foundation,
– built in one or more iterations,
– should address the critical use cases
identified in the inception phase.
• Architectural decisions must take account of:
– System scope,
– Major functionality,
– Non-functional requirements.
• Additional development of throwaway prototypes may
be necessary:
– develop the project plan,
– eliminate the project's highest-risk elements.
– explore a known risk (can we really get to talk to IMS?)
• Completion of Elaboration phase marks important switch
– explore trade-offs between design and requirements.
– Inception and elaboration – so far, low cost, exploratory work only,
no great dramas if cancelled
– Subsequently – project has acquired inertia, significant
expenditures made, cancellation could be traumatic
53
Note how all the SE processes have similar features – these additional
prototypes are much the same as XP’s “spikes”
54
9
29/04/2014
Elaboration - objectives
Elaboration …
• You must
• Elaboration objectives:
– Define, validate, and baseline the
architecture as rapidly as practical.
– Baseline the vision.
– Baseline a plan for the construction phase.
– Demonstrate that the baseline architecture
will support this vision for a reasonable
cost in a reasonable time.
– Finalize the “vision”
– Develop solid understanding of critical use cases.
– Put in place development environment, tools, test
automation systems etc
– Select components
• Can some subsystems be purchased (COTS – Common
Off the Shelf software)
• Select middleware components
55
56
“baseline” – they mean create it, where relevant make it work, put it under version control!
Elaboration – what do you
create?
Architecture milestone
• A use-case model (at least 80% complete) in which all use
cases have been identified in the use-case model survey, all
actors have been identified, and most use-case descriptions
have been developed
• Supplementary requirements that capture the non-functional
requirements
• A software architecture description
• An executable architectural prototype
• A revised risk list and a revised business case
• A development plan for the overall project, including the coarsegrained project plan, which shows iterations and evaluation
criteria for each iteration
• An updated development case that specifies the process to be
used
• A preliminary user manual (optional)
57
• Architecture Milestone: Evaluation
– Is the vision of the product stable?
– Is the architecture stable?
– Does the executable demonstration show that the major
risks have been addressed and credibly resolved?
– Is the construction phase plan sufficiently detailed and
accurate? Is it backed up with a credible basis for the
estimates?
– Do all stakeholders agree that the current vision can be
achieved if the current plan is executed to develop the
complete system, in the context of the current architecture?
• If the project fails to pass this milestone, it may be
aborted or considerably rethought.
Once again – student projects must pass, or you fail the project subject
58
Construction
Still here – well, you enjoy coding don’t you so you will love
Construction!
• The Construction Phase
– Develop remaining components and application
features
– Integrate all parts into the product
– Test all features thoroughly.
– Achieve useful versions (alpha, beta, and other
test releases) as rapidly as practical
Coding and testing,
more coding and testing,
delivering iterated versions
so some deployment and
configuration;
lots of version management;
elaborating the environment,
• Emphasis is typically on
Hopefully not too much
requirements, analysis,
design – but you cannot
escape project creep
–
–
–
–
59
Managing resources
Controlling operations to optimize costs,
Maintaining schedules,
Guaranteeing quality.
60
10
29/04/2014
Construction iterations are
planned!
Construction activities
•
•
•
•
Resource management, resource control,
and process optimization
Complete component development and
testing against the defined evaluation criteria
Assessment of product releases against
acceptance criteria for the vision
Produce “the product”
1. The software product integrated on the adequate
platforms
2. The user manuals
3. A description of the current release
• Your plan (started during Inception and refined in
Elaboration) will have defined a series of iterations
– Each Iteration
• List of use-cases that it incorporates
• Time schedule (time boxing)
• (Additional aspects like start to involve database in this
iteration, or start to use message queue – these define
activities for the “support” people looking after environment and
tools)
• Leads to a “build” that can be release to others
– Usability review and experimentation by customer representatives
– Integration and system testers who must thoroughly test
functionality
– Deployers – need to develop/refine deployment scripts, XML
configuration files, databases etc
61
Iteration releases – a chance
to replan
62
How long is an iteration?
• Depends on project size!
• With each iteration release, you revise
your plan
Lines of Code
5,000
20,000
100,000
1,000,000
– Maybe you are lagging – need to reduce
the scope?
• Move some features from next phase to later
phase
Number of People
4
10
40
150
Duration of an Iteration
2 weeks
1 month
3 months
6 months
• For little CSCI222 projects:
– 4 persons,
– Iteration time of one or two weeks;
– 2-3 iterations in construction.
– Maybe you have negative feedback from
the candidate “user” community:
• For CSCI321 projects;
• Re-analysis, re-design, re-work
– 6 persons
– Iteration time of three to four weeks
– 3 iterations in construction
63
Construction milestone
64
Congratulations, you’ve made it to Transition!
• Initial Operational Capability Milestone:
– You must decide whether the software, the sites,
and the users are ready to become operational
without exposing the project to high risks.
– This release is often called a beta release.
Hopefully no more changes in requirements,
or design!
Hopefully also not much more implementation!
• Evaluation criteria:
There will be overall testing to do, and some
details of deployment to complete.
– Is this product release stable and mature enough
to be deployed in the user community?
– Are all stakeholders ready for the transition into
the user community?
There will be quite a lot of work on setting up
for use of populated databases, parallel running
with existing software, phase out of existing
system.
• Transition will have to be postponed if the
project fails to reach this milestone.
65
66
11
29/04/2014
Transition
Transition – objectives, activities
• Transition phase
• Objectives:
– move the software product to the user community
• Phase starts when system is mature enough to be deployed in
the end-user domain.
– Usable subset of the system has been completed to an acceptable
level of quality
– User documentation is available
• Phase includes:
– Beta testing to validate the new system against users' expectations
– Parallel operation with the legacy system that the project is
replacing
– Conversion of operational databases
– Training of users and maintainers
– Rollout of the product to the marketing, distribution, and sales
teams
– Achieve user self-supportability.
– Achieve stakeholder concurrence that deployment baselines are
complete and consistent with the evaluation criteria of the vision.
– Achieve final product baseline as rapidly and cost-effectively as
practical.
• Activities include:
– Deployment-specific engineering,
•
•
•
•
cutover,
commercial packaging and production,
sales rollout,
field personnel training
– Tuning activities, including bug fixing and enhancement for
performance and usability
– Assessing the deployment baselines against the vision and the
acceptance criteria for the product
67
The final milestone
68
Roles known, overall
process “understood”
• Product Release Milestone:
What do you do, and when?
RUP’s process disciplines
– Evaluation criteria:
• Is the user satisfied?
• Was it produced on time and within budget?
70
69
Are you “the Manager”?
Aside – use of "Dilbert" cartoons
• A real manager?
• Wollongong University "web police"
required an acknowledgement of the
Dilbert cartoon figures used in
subsequent slides
– You mean you have a budget, you hire people,
you buy machines.
– Go away – nothing for you here
• A RUP manager?
• "I probably got the images of Dilbert and
his friends from http://www.dilbert.com/
but it might have been from another
site."
71
– Planning an iterative project through the lifecycle
and planning a particular iteration
– Risk management
– Monitoring the progress of an iterative project and
measurements
• Even limited RUP management is probably
outside the scope of most student projects.
72
12
29/04/2014
RUP – management plans
RUP management - planning
• Coarse grained phase plan:
– Dates of the major milestones
•
•
•
•
Lifecycle objective (end of inception, project well scoped and funded)
Lifecycle architecture (end of elaboration, architecture complete)
Initial operational capability (end of construction, first beta)
Product release (end of transition and of the cycle)
– Staffing profile: which resources are required over time
• Fine grained iteration plans in each phase
– The current iteration plan (the one for the current iteration), which is
used to track progress
– The next iteration plan (the one for the pending iteration), which is
built toward the second half of the current iteration and is ready at
the end of the current iteration
• An iteration plan uses traditional planning techniques and tools
(Gantt charts and so on) to define the tasks and their allocation
to individuals and teams.
73
RUP – Management – risks,
measures
74
RUP – Manager – your
artefacts
• For each risk, come up with some
strategy –
– Pro-active steps (send someone on a
training course, hire a specialist, …)
– Rework project so risk doesn’t arise?
• Measures
– Try to quantify how well things worked
– Identify problems
– Come up with solutions – so that life on the
next project will be better.
75
RUP – manager – Your
workflow
76
Is your role “Requirements”?
• Systems Analyst; Requirements specifier
77
Er? What is a storyboard – you’ve never mentioned it till now?
78
http://www.ibm.com/developerworks/rational/library/content/RationalEdge/nov03/f_usability_jh.pdf
13
29/04/2014
Storyboards, “user
experience” (UX) model, …
Storyboards
• A User Experience (UX) model
• Take your use case
– Specifies screens and screen content in
some abstract representation
– Characterize the actors
– Define usability requirements
– Identify “user experience” elements
– Model the use-case flow
– Define screen navigation
• Allows you to decide what information is
displayed without getting into detail of “pop-up
list” versus choicebox etc
• Storyboard
– Modelling a use-case flow in terms of UX
model screens etc
79
80
Requirements
Is your role “Requirements”?
• Your goals:
– Establish and maintain agreement with
stakeholders on what the system should do—and
why!
– Provide system developers with an understanding
of the system requirements
– Define the boundaries of the system
– Plan the technical contents of iterations
– Estimate cost and time to develop the system
– Define a user interface for the system
• Functional
– Those use-cases
• Non-functional
– Usability
– Reliability
– Supportability
– Performance
81
From requirements to …
82
A workflow to guide you …
83
84
14
29/04/2014
Analysis & design roles and
artefacts
Analysis and design roles
• Analysis
– Transform the requirements of the system into a set of
classes and subsystems.
– Driven by the use cases
– Focuses on ensuring that the system's functional
requirements are handled.
• Design
– Adapt the results of analysis to the constraints imposed by
non-functional requirements, the implementation
environment, performance requirements, and so forth.
– Design must define only enough of the system so that it can
be implemented unambiguously – i.e. don’t get stuck in ‘analysis
paralysis’, over-elaborating design instead of getting into the implementation
85
There is a list of things to do
for each role!
Implementation discipline
• Database designer
• Your work:
– Identify the persistent classes
– Design appropriate database structures
– Define mechanisms for storing and retrieving data that meet
performance criteria
• Capsule designer
–
–
–
–
86
Capsule – encapsulated threads of control
Protocols – message exchanges
Event – something to which system must respond
Signal – asynchronous event that may cause a state transition in a
subsystem
• User interface designer
– Storyboards
– User interfaces
– Navigation maps for web-sites etc
– Define the organization of the code in
terms of implementation subsystems
organized in layers
– Implement classes
– Test the developed components as units
– Integrate into an executable system the
results produced by individual
implementers or teams
87
Implementation discipline
88
Implementation discipline
• The key artefacts of implementation are as follows:
• “Build”
– Implementation Subsystem
– An operational version of a system or part of a system that
demonstrates a subset of the capabilities to be provided in
the final product.
– Integral to the iterative lifecycle
• A collection of implementation elements
• Structures the implementation model by dividing it into smaller
parts.
– Implementation Elements
• A piece of software code
– Integration Build Plan
• This document defines the order in which the elements and
subsystems should be implemented and specifies the builds to
be created when the system is integrated.
• Represent attempts to demonstrate the functionality developed
to date.
• Each build is placed under configuration control in case there is
a need to roll back to an earlier version when added
functionality causes breakage or otherwise compromises build
integrity.
• Typically, projects try to produce builds at regular
intervals, up to one each day, but at least one per
week toward the end of an iteration
89
90
15
29/04/2014
Implementation discipline workflow
Tester?
91
92
See P. Kruchten’s book for
lots more details
Tester?
• Lots more details for each of the roles
– What tools each role requires
– More on artefacts produced
–…
93
94
Building an architectural
prototype
Iterations
• He has passed “Objective” milestone
and has:
Examples from Kruchten
– List of actors
– Some use cases (most important ones)
– A sketchy project plan
– (And a Vision, Glossary, etc etc)
95
96
16
29/04/2014
Start iteration in the
elaboration phase
Elaboration iteration
1.
Software Architect and Project Manager
–
2.
Choose the use cases and scenarios that will be
considered when developing the architecture.
Systems Analyst and Requirements specifiers
–
–
3.
Develop more detailed versions of these use cases,
prioritize, identify complex high risk cases
Fill out “Use case model” and “Supplementary
Specification” documents
Software Architect and Project Manager
•
4.
Review elaborated use cases, set software architecture,
update iteration plan
User interface designer
–
–
Expand use case into “story boards”
Start prototyping user interface to get feedback
97
Continue elaboration iteration
5.
Continue elaboration iteration
Software architect + team
–
6.
8.
Using system requirements, glossary, use-case view, and
team’s general domain knowledge, sketch the outline of
subsystems
•
–
98
9.
10.
•
•
7.
Designers refine the classes identified, allocate
responsibilities, update attributes and relationships
Architect: identify classes that are architecturally
significant and add them to the logical view in Software
architecture Document
11.
•
•
12.
Plan system and integration tests
Implementers
•
•
Organize classes into “Design Packages”
Allocates packages to subsystems
Define order in which subsystems are implemented and
integrated
Test designer
•
Architect
Consider concurrency and distribution
Define an initial implementation view
System Integrator
•
Designers and system architect
Use cases to collaboration diagrams
Architect
•
•
Fill out “software architecture document”
Designers: Start finding the classes for this iteration’s use
cases. “Find the obvious classes”
Designers
•
Code and unit tests the classes needed for this baseline
architectural version
Package into subsystems as per implementation models
99
Complete elaboration
iteration
13.
Implementing the system
Systems integrators
•
14.
• He has completed Elaboration and a
couple of iterations of Construction
Integrate subsystems into architectural prototype
Systems testers and software architect
•
•
15.
Test the architectural prototype
Is it viable?
– Need to carry forward to release “initial
operational capability milestone”
Project manager
•
•
100
Evaluate
Revise work plans, risk-lists, etc
101
102
17
29/04/2014
A construction iteration
Construction iteration
1.
Project manager
•
Update Iteration plan
•
•
•
–
2.
Any new functionality?
Any carry features postponed from earlier phases?
Any corrections?
Maybe refine risks
Systems integrator
•
3.
Starts on build plan for this iteration, how will the new elements,
that are created in this iteration, be integrated with existing
system
Test designer
•
4.
Start planning how to conduct integration and system tests
Designers
•
•
5.
Refine classes that are to be implemented
Identify new functionality to be tested
Implementers
•
Do the coding and unit tests
103
Construction iteration
continues
104
That is how you RUP
6. Implementer
•
Integrate code into subsystem
7. Tester
•
•
Integration testing
Systems testing
8. Project manager
•
•
•
Track progress and costs
Update plans for future iterations
Revise risk list
105
I still don’t understand,
what do I really have to do?
Sigh
106
Inception-1
• You work as a team, everything done with your group
members.
• Talk to the users (fake this if it is a student project, you have no users),
What do they want the system to do?
• Try to refine these requests.
– Identify
• Actors – persons using the system
• Primary use cases – the main things they want done
• Back to your users – discuss what they want, now
using use-case terminology (and maybe employing some
simplified storyboarding to come to some agreement as to how
user interaction with the system will actually work)
• Determine their other requirements
– must be done in C++ on Solaris
– all user prompts in Swahili (or whatever)
107
108
18
29/04/2014
Inception-2
Inception-3
• Think about the architecture
– Is this a “program”?
– Is it a group of programs that share some persistent data?
– Does it involve concurrent processes – client-server or
other?
• Pick some candidate architecture so you have some
idea what it is that you have to build.
• Look for problematic aspects – the risks like
interfacing with legacy applications, using language
features you aren’t used to
• Review the user requests
• Compose that glossary – find out the real
meaning of all the funny terms the users were
employing in their descriptions
• Start to plan (you’ve just prioritized the
requirements)
• Complete the Vision thing
– Formalize them into more precise requirements
– Clarify business justification for each request
– Prioritize them
109
Inception completes
110
Aside: architectures
• You have
• You don’t know any “architectures” so how
can you be expected to pick one!
• Sigh again.
Well – really there aren’t many, and only a
subset are relevant in student projects.
–
–
–
–
–
–
Vision
Requirements listed and prioritized
Main use-cases, partially filled out
Probably some sketchy ideas on user interface
A chosen architecture that you hope will work
Some idea of risks (and what you intend to do
about them)
– Glossary
• You can try to pass “Objective” milestone
– Get all stakeholders to agree that project is
properly characterized
111
“Program” architecture
“Small system” architecture
• User employs program which may have
some associated persistent data.
Possible
use of
persistent
data
112
• User(s) employ several programs that create,
read, update, and delete data in a common
datastore.
Processing and
user interface in
the one program
Datastore
Processing and
user interface in
the one program
Web-server
running PHP scripts
Datastore
Internet Explorer
Processing and
user interface in
different programs
Too simple for real world – does suffice for some student projects
113
An extremely common architecture!
Many alternative
technologies
114
19
29/04/2014
“Real world system”
architecture
Elaboration -1
• Programs dependent on multiple services
•
•
Specialized client application
Queue service
– Baseline an executable architecture
Datastore1
•
Internet Explorer
Intermediary
Web-server
Application-server
hosting “business
components”
Datastore2
Still working as a group!
Remember the main goal of this phase
So:
1. Pick the use cases that are either high priority or
look most challenging, these are the ones that
you will use to test your architecture
2. As a group, develop the selected use cases
•
•
Another extremely common architecture!
Transaction
monitor service
115
Elaboration -2
•
Identify “the obvious classes”
Map from use cases to sequence diagrams
116
Elaboration-3
So:
1. …
2. …
3. Assign classes to packages and
packages to subsystems (different
programs)
4. Do just enough implementation to create
some classes that can be used in testing
your architecture
5. Build a first version
• Those risks – do any require that you create some
test code to see how to do something like connect to
a legacy system?
– If yes – do a little prototyping! (XP spikes)
• If the architecture appears to be viable continue with:
– Refine those use-cases
• Probably get some more by now, plus maybe the first changes
(if you have any real users that is)
– Design classes
• What do they own? What do they do? How do they relate to
other classes?
• Heavy UML-ing!
– Refine architectural issues like data-flow among processes
and process interfaces.
117
Elaboration-4
118
Complete elaboration
• Revise your list of risks
• Develop an construction plan
• Try to pass the “architecture milestone”
evaluation criteria.
– You’ve prioritized the use cases
– You’ve identified classes needed to
implement them
– You’ve identified constraints among
classes (dependencies that imply a
required ordering of their implementation)
– So you can say what should be
implemented in each construction iteration.
119
– In plainer English,
• Check that each member of group understands
what you are trying to build
• Since each member will be developing some
classes, make sure everyone understands the
architecture and how those classes will fit in
• Have agreed responsibilities – all very well to
be busy creating and testing your little set of
classes but who will take responsibility for
integration and system testing.
120
20
29/04/2014
Construction
Transition
• Partly individual, partly team work.
• Come on, you must understand this bit!
• You would be so lucky
– You write and test “component” code.
– You commit your tested 100% correct component
to the project work area
– The “integrator” integrates and builds the system
(hopefully largely automated by some shell or Perl
scripts that the group composes!)
– The “tester” performs integration and system tests.
• You conduct regular meetings reviewing
progress.
121
But I still don’t understand,
what do I really have to do?
Sigghhhh
122
What must you do
• Look at RUP workflows, artefacts, disciplines,
etc
• Plan
• Think!
• Try things
– Go on, the computer won’t bite
• Work
• and remember
123
Good software development
process …
124
Experience
• Good software development processes
and successful projects
are the result of experience
• Experience is obtained by surviving bad
software processes and unsuccessful
projects!
• and
125
126
21