Date post: | 23-Dec-2015 |
Category: |
Documents |
Upload: | abner-snow |
View: | 212 times |
Download: | 0 times |
2
Per Kroll - Background
• Project lead – Eclipse Process Framework
• Development Manager – RUP / Rational Method Composer
• Process Technology Strategist – IBM Rational
• (Co-) Author of – The Rational Unified Process
Made Easy – A Practitioner’s Guide to RUP
– Agility and Discipline Made Easy – Practices from OpenUP and RUP
3
Brian Lyons - Background• Content Lead, OpenUP/Basic Process; Committer,
Eclipse Process Framework
• Chief Technology Officer – Number Six Software
• Co-Founder – Number Six Software
• (Co-) Author of – UML 2 Toolkit
4
Agenda
• What is OpenUP?• Collaboration• Intent• Management• Solutions Development• Summary
5
Eclipse Process Framework (EPF) Project
Provide an open and collaborative ecosystem for evolving software development processes
Provide sample practices, process tooling and a metamodel, that can be used as the foundation for a large variety of processes to address IT needs
Uses the Eclipse community to gain wide acceptance of the framework
6
EPF Ecosystem
TOOLING (Authoring, Publishing) TOOLING (Authoring, Publishing)
Free Process
Content
Plug-ins
Free Process
Content
Plug-ins
META MODEL (Unified Method Architecture)META MODEL (Unified Method Architecture)
ECLIPSEECLIPSE
Commercial
Process
Content
Plug-ins
Commercial
Process
Content
Plug-ins
Tool Extensions
Tool Extensions
Extensible, Customizable, FlexibleExtensible, Customizable, Flexible
Common Language & VocabularyCommon Language & Vocabulary
Open Source DevelopmentOpen Source Development
Inhouse
Content
Plug-ins
Inhouse
Content
Plug-ins
Basic Unified Process
Adapted from RUP
Basic Unified Process
Adapted from RUP ScrumScrum
TOOLING (Authoring, Publishing) TOOLING (Authoring, Publishing)
Free Process
Content
Plug-ins
Free Process
Content
Plug-ins
META MODEL (Unified Method Architecture)META MODEL (Unified Method Architecture)
ECLIPSEECLIPSE
Commercial
Process
Content
Plug-ins
Commercial
Process
Content
Plug-ins
Tool Extensions
Tool Extensions
Extensible, Customizable, FlexibleExtensible, Customizable, Flexible
Common Language & VocabularyCommon Language & Vocabulary
Open Source DevelopmentOpen Source Development
EXTENSIONS
• Project Mgmt.
• Oper. Mgmt.
• Systems Mgmt.
EXTENSIONS
• Project Mgmt.
• Oper. Mgmt.
• Systems Mgmt.
EXTENSIONS
• Project Mgmt.
• Oper. Mgmt.
• Systems Mgmt.
EXTENSIONS
• Project Mgmt.
• Oper. Mgmt.
• Systems Mgmt.
Inhouse
Content
Plug-ins
Inhouse
Content
Plug-ins
OpenUP/Basic
Scrum
Value-BasedSoftware Eng.Value-Based
Software Eng.Model-DrivenArchitecture
Model-DrivenArchitecture
Open Unified Process (OpenUP)
Consolidated Agile Framework
• XP
• Scrum
Other agile processes
• DSDM
• AMDD
7
What Is OpenUP/Basic?
An iterative software development process that is minimal, complete, and extensible.
• Minimal - only fundamental content is included • Complete - can be manifested as an entire process to build a system • Extensible - can be used as a foundation on which process content
can be added or tailored as needed
8
penUP
Analyst
Stakeholder
Project Manager
Architect
Developer
Tester
9
penUP
Analyst
Stakeholder
Project Manager
Architect
Developer
Tester
10
penUP
Analyst
Stakeholder
Project Manager
Architect
Developer
Tester
11
penUP
Analyst
Stakeholder
Project Manager
Architect
Developer
Tester
12
penUP
Analyst
Stakeholder
Project Manager
Architect
Developer
Tester
13
penUP
Analyst
Stakeholder
Project Manager
Architect
Developer
Tester
14
OpenUP is on a set of core principles:• Collaborate to align interests and share
understanding• Evolve to continuously obtain feedback and
improve • Balance competing priorities to maximize
stakeholder value• Focus on articulating the architecture
Principles
15
Demo
16
Agenda
• What is OpenUP?• Collaboration• Intent• Management• Solutions Development• Summary
17
Collaboration: Some key practices• Maintain a common understanding
– Key artifacts: Vision, requirements, architecture, iteration plan
• Foster a high-trust environment– Manage by intent, tear down walls, understand the perspectives
of others
• Share responsibility– Everybody owns the product, help each other
• Learn continuously– Develop technical and interpersonal skills, be a student and a
teacher
• Organize around the architecture– As teams grow in size, have teams of small component teams
18
Agenda
• What is OpenUP?• Collaboration• Intent• Management• Solutions Development• Summary
19
Forms of Requirements
• Vision defines stakeholder’s view of product• Use Cases define user scenarios
– Any scenario-based requirements would do
• Supporting Requirements cover technical and other non-usage issues
• Work Items reference requirement work products for more detail
20
Iterative Requirements Definition
• Vision defines product• Use-case identification scopes release• Use-case detail drives work in an iteration• Supporting requirements are managed across
the lifecycle
21
Test Cases as Intent
• Test Case– Aligned with requirements and bugs– Specifies the conditions to be validated– Outlines necessary data
• Contrasted with Test Script (from Solution sub-process)– Aligned with Test Cases– Explicit step-by-step instructions– Supplemented by test data– Best if automated
• Test Cases are a form of Test First Design (TFD)
22
Roles Relevant to Intent
• Analyst– Captures, organizes, and prioritizes requirements
• Stakeholder– Drives Intent; needs must be satisfied by the project
• Tester– Defines criteria for acceptance of solution
• The Project Manager will update the Work Items List with prioritized, grouped items
• The Architect and Developer will produce a solution that meets the intent
23
Agenda
• What is OpenUP?• Collaboration• Intent• Management• Solutions Development• Summary
24
Stakeholder Satisfaction Space
Project Starting Point
Identify End Goal
Your goal is to find a Path fromHere to There
25
Stakeholder Satisfaction Space
Divide One Big Problem into a Series of Smaller Problems
1 2 3 4 5 6
Initial
Project Plan
Planned Planned CompletionCompletion
Planned Planned CompletionCompletion
Planned Path
26
Stakeholder Satisfaction Space
Define When Key Management Can Be Achieved
1 2 3 4 5 6
Do we understand
the problem?
Do we understand
the solution?Feature
complete?
Release ready?
Planned Planned CompletionCompletion
Planned Planned CompletionCompletion
Planned Path
Inception Elaboration ConstructionTransition
27
Prioritize and Manage Work: Work Items List
Work Item List
High Priority
Low Priority
New work items can be added at any time
Work items can be removed at any time
Work items can be reprioritized at any time
High-priority work itemsshould be well-defined
Low-priority work itemscan be vague
Each iteration implements thehighest-priority work items
28
Key Concepts: Agile Estimation
• Size (points): – For each work item, we estimate how big it is. We
focus on relative size, so key is to be consistent within your work items list.
• Velocity– A measurement of how many points are delivered in
each iteration
• Effort (days or hours):– Estimate of actual effort.
29
Plan Your Iteration
• Specify target velocity and outline iteration objectives in iteration plan
• Analyze top priority Work Item – Estimate effort in hours– If too big to fit within iteration, break down into smaller work items– Add to Iteration Plan– Analyze next work item in priority order until Iteration Plan is “full”
• Specify test and other assessment criteria
Work Item List
•Iteration objectives•Iteration Work Item List•Measure / test results
Estimate and add to iteration plan
Iteration Plan
30
Planned Path
Use Iteration Assessments to Change Direction
Actual Path
1 2 3 4 5 6
1 2 34
5 67Updated
Project Plan
Planned Planned CompletionCompletion
Planned Planned CompletionCompletion
Stakeholder Satisfaction Space
31
Agenda
• What is OpenUP?• Collaboration• Intent• Management• Solutions Development• Summary
32
The Role of Architecture
• Provides context to design and implementation• Provides risk mitigation• Improves predictability of plan• Setup early, improve and evolve
33
Architecture and the Principles
• Collaborate– Maintain a common technical understanding with architecture
• Balance– The decisions of architecture are part of balancing to achieve
maximum stakeholder benefits within constraints
• Focus– Emphasize essential technical decisions via architecture
• Evolve– Early evolutions ensure product feasibility and attack risk
34
• We are going to use the Chain of Responsibility Pattern to blah
• We have selected Oracle because it will meet the performance requirements and the customer already has licenses and trained DBAs
• We are going to apply a network architecture like this.• We are applying these J2EE Blueprints• We are going to distribute the components across the
layers this way.
Representing Architecture
• No thick document required• Much of the architecture can be
– Selected instead of designed– Referenced instead of described
35
Designing
• Steps– Understand requirements, identify a scenario– Identify elements– Determine how elements collaborate– Refine decisions, design internals– Communicate
• Do an analysis pass? If appropriate.• Visually design? If appropriate.• Use a design tool? If appropriate.• Long-lived design? If appropriate.
36
Creating a Solution for a Work Item
• Select a work item assigned to the current iteration
• Collaborate with team if it needs breakdown• Identify requirements closure
– Attachments: use case, supporting requirement, bug information, test case
– Gather additional information
• Repeat until complete– Build a small solution verified with developer tests
• Verify completion with system tests
37
Test-first Design
• Design solution– Defines interface to be tested
• Create test for solution– Completed test should run and fail
• Implement solution– Test should run and pass
• In as small of increments as possible
38
Inserting Test-first Design
• Developer testing straddles the implementation of the solution
• The tight back-looping is not shown here
Refinethe ArchitectureRefinethe Architecture
Designthe SolutionDesignthe Solution
ImplementDeveloper TestsImplementDeveloper Tests
Implementthe SolutionImplementthe Solution
RunDeveloper TestsRunDeveloper Tests
39
Roles Relevant to Solution
• Developer– Designs and implements solution
• Architect– Makes key technical decisions and structures the
solution
• Tester– Implements and conducts tests to verify solution
• The Project Manager monitors the development
• The Stakeholder participates in verification of solution
• The Analyst provides additional information
40
Agenda
• What is OpenUP?• Collaboration• Intent• Management• Solutions Development• Summary
41
Adopting the Process
• To browse– Download published process from eclipse
• To configure and customize– Download source library and EPF Composer tool
• Use EPF Composer tool to author extensions– Replace existing templates– Add guidelines on specific techniques– Add tool mentors for usage of your tools– Extend or add roles, tasks, work products, examples, etc.
• Publish your custom configuration
http://www.eclipse.org/epf/downloads/downloads.php
42
Questions?
??
?
?
?
?
?
?
43
44
Example: Iterations in Practice
• Let’s assume ~6 week iteration length:– 1 wk planning, analysis & design– 3-4 wks design and coding– 1-2 weeks testing/shutdown
• Many team members may do design and coding also the first week• Weekly Integration builds used to prove progress; nightly builds used to
inject discipline and repeatability• High level themes and target artifacts for each iterations decided by Dev
Leads based on business and use case scenarios• Detailed iteration plans provided by component teams (linking line items to
use cases and scenarios)• Iteration builds get assessed against use cases and are published for
broader visibility• Content matters - inject cool stuff into each planned iteration to ensure
adoption of, and progression through each iteration build• Dates matter – revisit following each iteration delivery. • Iterations are timeboxed. (Phases are not.)
This, and next two slides borrows content from development leads for IBM Rational Software Architect / Julian Jones
45
Practical Lessons
• It is easy, even tempting to slip function from iteration to iteration; this inevitably results in a crunch as one nears release
• Taking shortcuts on the 1-2 week shutdown period will lead to poor stability• Adoption rate is significantly affected by the stability of the iteration and by
ease of download• There’s a tendency not to properly document new functions going into each
iteration; this makes it difficult to establish what is new and exciting• To grow a community of adopters it’s essential to have good iterations early
on which are exciting so that people jump on them and provide active feedback; only with attractive iterations can one get more than one feedback cycle per release
• In order to foster direct interactions with early adopters one needs open source style communication channels. Tech support firewalls are a bane
• The iteration assessment planning needs to be done carefully to allow proper scaffolding of code to prevent gridlock
• As function falls out of the release (not that this every happens), product teams need to be re-engaged so that schedule slippage is dealt with realistically