Aras PLM Software Implementation Methodology

BEDIFFERENT ACE GERMANY

Copyright © 2012 Aras. All Rights Reserved. aras.com

ACE
Germany

Implementation Best Practices
Scrum Methodology

Patrick Willemsen
Senior Consultant
ARAS Software AG


Dilbert says

Copyright © 2012 Aras. All Rights Reserved. Slide 3 aras.com

Agenda

 Agile Methodology – An Overview
 Agile Methodology – Applied
 Questions


What is Agile?

 Agile is an iterative software development
methodology that promotes open collaboration and
process adaptability through the life cycle of the
project
 Is beneficial on projects with many unknowns
 Scrum is a framework within Agile methodology


What Characterizes the Agile
Process?
 Collaboration and communication
 High level of participation and transparency to the
users
 Dedicated, cross-functional team(s)
 Self-organized, where everyone participates in
decision making
 Development is planned in stages by team members
 Testing and documentation are done as you go
 Users see working product sooner


Agile Development

Scrum

Use Cases (Requirements)
Product
Product backlog Sprint backlog increment
n days

UC001
UC003
UC015
…

Sprint


Product Backlog

 High-level document for the entire project
 Contains backlog items:
 brief use case descriptions
 wish-list items
 prioritized/ranked by business value
 The product backlog is property of the Product
Owner
 Business value is set by the Product Owner

http://en.wikipedia.org/wiki/Scrum_(development)


Product Owner

 Represents the voice of the customer and ensures
that the Scrum Team works with the "right things"
from a business perspective
 The Product Owner collects use cases,
requirements, prioritizes them, then places them in
the product backlog

Business Perspective


Sprint Team

Product owner

Sprint team

Customer Consultant(s)
Process owner(s)

Architect(s) Scrum master


Scrum Master

 Primary job is to remove obstacles to the ability of
the team to deliver the sprint goal
 Is not the leader of the team (as the team is self-
organizing) but acts as a buffer between the team
and any distracting influences
 Ensures that the Scrum process is used as intended.
The Scrum Master is the enforcer of rules
 A key part of the Scrum Masters role is to protect
the team and keep them focused on the
tasks at hand


The Team

 Has responsibility to deliver the product increment
 All team members are responsible to deliver a
complete and consistent sprint result
 Team is self-organizing in terms of
 Task assignment
 Task order
 Availability
 With sprint planning it commits itself to deliver the
communicated results
 A team is typically made up of up to 6 people

SCRUM Detailed

• Product backlog • Sprint backlog Scrum master

Start
• Scrum

Part 1
Sprint planning
Product owner Requirements definition 2 Consultant(s)
Customer representatives

Product
5 Result presentation
increment
Demo

4 Implementation
Solution
specification
Sprint
3 n days

Architect

Meetings (1)
At the beginning of a sprint cycle resp. daily

Meeting Topics
Planning  Select what work is to be done
limit: 2h  Prepare the sprint backlog that details the time it
will take to do that work, with the entire team
 Identify and communicate how much of the work is
likely to be done during the current sprint

 Input: Product Backlog
 Result: Sprint Backlog
Scrum (Daily)  What have you done since yesterday?
 What are you planning to do by today?
limit: 15 min  Do you have any problems preventing you from
accomplishing your goal?


Meetings (2)
At the end of a sprint cycle

Meeting Topics
Review (demo)  Present the completed work to the stakeholders
(a.k.a. "the demo")
limit: 2h
 Incomplete work cannot be demonstrated
Review (sessions)  Review the work that was completed and not
completed by the sprint team
limit: 2h

Retrospective  All team members reflect on the past sprint
limit: 1h  Make continuous process improvement
 Two main questions are asked in the sprint
retrospective: What went well during the sprint?
What could be improved in the next sprint?


Sprint Backlog

 Detailed document containing information about how the team is going
to implement the use cases / requirements for the upcoming sprint.
 The document contains the availability of the team members during the
sprint period.
 Work list broken down into doable tasks (between 2 and 8 hours of
work). With this level of detail the whole team understands exactly what
to do, and anyone can potentially pick a task from the list.
 Tasks on the sprint backlog are never assigned by a team lead; rather,
tasks are signed up for by the team members as needed, according to
the set priority and the team member skills (Self organizing team).
 The sprint backlog is property of the Team. Estimations are set by the
Team.



Burn Down Chart

 The burn down chart is a publicly displayed chart showing remaining
work in the sprint backlog. Updated every day, it gives a simple view of
the sprint progress. It also provides quick visualizations for reference.

 It should not be confused with an earned value chart.



OK, GREAT!

Now how does this apply to Aras
Innovator?


Implementation Methodology

 Aras Innovator is ideally suited for an iterative approach:
 Rational Unified Process
• Best Practice Presentation ACE 2010 International
• Starting Your Aras Implementation ACE 2011 International
 Agile / Scrum Software Development
• Aras Innovator Deployment Methodology ACE 2012 Germany
• wikipedia http://en.wikipedia.org/wiki/Agile_software_development

Starting Your Aras
Implementation
ACE 2011 International


Aras Methodology Overview

 Designed to use the “Small Win” approach
 Take a well defined problem(s) and implement with
less risk and a higher degree of confidence
 Implement a series of product increments
(production) releases that comprise the complete
solution
 Each product increment provides value to the
business
 Scope each increment to be completed in a defined
number of sprints


Discovery Workshop

Customer investigation

SoW

Customer
workshop Result
order

Business process analysis Process description
Business entity model definition Solution description
Solution mockup Solution proposal
Main Requirements
Brief use cases
Data model (high level)
System architecture
Scope of work
Project definition


Use Case Workshops

Discovery Workshop Use Case and Design Workshops

Product
UC001
Customer backlog
SoW project
order UC001
UC004 UC003 UC003
UC015
…

UCnnn

Process description Detailed use cases
Solution description Requirement definition
Solution proposal System design
Brief use cases
…


Sprint Plan
Discovery Workshops Product backlog

System Requirements High Level Use Non-functional UC001
UC003

Architecture definition Cases requirements UC015
…

Part & BOM
Sprint 1 Management
Implementation Test

Requirements Requirements
Product
increment
Part & BOM
Sprint 2 Management
Implementation Test

Product
increment
Change
Sprint 3 Management
Implementation Test

Program and
Sprint 4 Project Implementation Test
Management


Part & BOM Management
Example
Topics System
 Requirements Definition  Visual Prototypes
 Use case definition
 Data model
 Numbering scheme
 Life cycle
 Workflow
 Permissions
 Revisioning and sequence
 Relationships to other items
(Part, CAD, documents, …)


Implementation

Sprint Result Presentation
 Develop product increment  Live Demo
 Write agile documentation
 Maintain product backlog


Final Thoughts

 DO
 Develop accurate Use Cases and keep them up to date as you go
 Prioritize use cases and requirements
 Look for “Small Wins” that provide business value
 Create visual prototypes and get user validation before developing
any method code
 Take result presentations seriously: prepare well, show and discuss
product increments
 DON’T
 Spend a significant amount of time developing specifications without
prototyping the solution
 Worry about not getting 100% of the detailed requirements up front:
Iterate!


ACE Germany

Questions ?
Patrick Willemsen
Senior Consultant
ARAS Software AG


Scrum

Project Management


Project Management
Agile Project Management with Scrum
 Scrum has not only reinforced the interest in software project management, but also
challenged the conventional ideas about such management.
 Scrum focuses on project management institutions where it is difficult to plan ahead with
mechanisms for empirical process control, such as where feedback loops constitute the
core element of product development compared to traditional command-and-control-
oriented management.
 It represents a radically new approach for planning and managing software projects,
bringing decision-making authority to the level of operation properties and certainties.
 Scrum reduces defects and makes the development process more efficient, as well as
reducing long-term maintenance costs.


Modeling Basics

Use Cases


Definition (1)

 A use case is the specification of a set of actions
performed by a system which yields an observable
result that is of value to one or more actors or
other stakeholders of the system
UML 2.0 Specification


Definition (2)
 Use Cases
 Use cases are a documentation technique
 Use case is a story of using a system to fulfill a goal
 Use cases capture functional requirements
 Use cases are not diagrams, they are text
 Use cases are requirements
 Use cases define a contract how the system will behave
 Use case model is the set of all use cases

 Use cases emphasize the user goals and perspectives

 Use Cases do not
 Specify user interface design. They specify the intent, not the action detail
 Specify implementation detail (unless it is of particular importance to the actor to be
assured that the goal is properly met)


Definition (3)
 Name starts with a verb
 Create Part
 Search on Classification Attributes
 Release Part
 Assign Review Participants


Definition (4)
 Find the right use case level
“A task performed by one person in one place at one time, in response to a business
event, which adds measurable business value and leaves the data in a consistent state.”

 Known as Elementary Business Process (EBP, also known as user-level goal use cases)
 An EBP-level use case usually is composed of several steps, not just one or two


“Boss Test”

 The "boss test" is a naïve approach for determining whether an activity
qualifies as an elementary business process.
 For example, consider this dialog:
 Boss: "What did you do all day today?“
 Employee: "I logged in.“

 Is the boss happy?
 In general, an EBP-level use case usually involves many steps, not just
one or two.


Level of Detail

Casual use case
 Consists of a few paragraphs of text, summarizing the use case.
Brief use case (Cloud level)
 Consists of a few sentences summarizing the use case. It can be easily inserted in a
spreadsheet cell, and allows the other columns in the spreadsheet to record priority,
technical complexity, release number, and so on.
Fully dressed use case (Sea level)
 Is a formal document based on a detailed template with fields for various sections; and it is
the most common understanding of the meaning of a use case.


Brief Use Case Example

 Use Case Name:
 Release CAD Drawing
 Actors:
 Designated User (CMII)
 System
 Use Case Description:
The user selects one or more drawings to be released and then releases the items. The
system checks if all release mandatory information – meta data as well as CAD files – has
been entered by the user and verifies that all related CAD models have been released. The
system shows success or failure to the user. After the release, the system shall create a
neutral file format.


Fully-Dressed
 Use case name  Extensions
 Brief description  alternate scenarios of success and
failure
 Scope
 Frequency of occurrence
 Primary actor
 Daily, Weekly, Monthly, Quarterly,
 Stakeholders and interests Yearly
 who cares about this use case, and  Complexity
what do they want?
 Concerning logic which corresponds
 Preconditions to implementation effort
 what must be true on start?  Easy (OOTB), Medium (small
 Success guarantee enhancements), Difficult (complex
logic)
(Post conditions)
 what must be true on successful  Miscellaneous
completion?
 Main success scenario
 typical path, happy path

alistair.cockburn.us


Diagrams (1)

 UML has use case diagrams
 Use cases are text, not diagrams
 Use case analysis is a writing effort, not drawing
 But a short time drawing a use case diagram provides a context for:
 identifying use cases by name
 creating a “context diagram”


Tips & Tricks

 Write in an essential UI-free style
 Write simple
 Write black-box use cases (write what the system must do without
deciding how it will be done)
 Take an actor and actor-goal perspective
 Define use cases properly (name, etc.)
 Define more useful use cases first


Common Problems
 The following is a list of the most common problems in writing
requirements:
 Making bad assumptions
 Writing implementation (HOW) instead of requirements (WHAT)
 Describing operations instead of writing requirements
 Using incorrect terms
 Using incorrect sentence structure or bad grammar
 Missing requirements
 Over-specifying


Modeling Basics

Requirements


Definition
 User Requirements
 Statements of fact and assumptions that define the expectations of the system in terms
of mission objectives, environment, constraints, and measures of effectiveness and
suitability (MOE/MOS)

 Functional Requirements
 Functional requirements explain what has to be done by identifying the necessary task,
action or activity that must be accomplished

 Non-Functional Requirements
 Specify criteria that can be used to judge the operation of a system, rather than specific
behaviors. Non-functional requirements are often called qualities of a system.

http://en.wikipedia.org/wiki/Non-functional_requirement


Terminology (1)

 In a specification, there are terms to be avoided and terms that must be
used in a very specific manner. Authors need to understand the use of
shall, will, and should:
 Requirements use shall
 Statements of fact use will
 Goals use should

 Terms such as are, is, and was do not belong in a requirement. The term
must shall be handled consciously. Are, is and was may be used in a
descriptive section or in the lead-in to a requirements section of the
specification.


Terminology (2)

 There are a number of terms to be avoided in writing requirements,
because they confuse the issue and can cost you money, e.g.
 Support
 But not limited to
 Etc.
 And/or


Terminology (3)

 Requirements should be easy to read and understand. The requirements
in a system specification are either for the system or its next level, e.g.
subsystem. Each requirement can usually be written in the format:
 The System shall provide ........
 The System shall be capable of ........
 The System shall weigh ........
 The Subsystem #1 shall provide ........
 The Subsystem #2 shall interface with .....
 It is required that …


Terminology (4)

Ambiguous Terms Ways to Improve Them
acceptable, adequate Define what constitutes acceptability and how the
system can judge this.
as much as practicable Don't leave it up to the developers to determine
what's practicable. Make it a TBD and set a date to
find out.
at least, at a minimum, Specify the minimum and maximum acceptable
not more than, not to values.
exceed
between Define whether the end points are included in the
range.
depends on Describe the nature of the dependency. Does another
system provide input to this system, must other
software be installed before your software can run, or
does your system rely on another one to perform
some calculations or services?


Terminology (5)

efficient Define how efficiently the system uses resources, how
quickly it performs specific operations, or how easy it
is for people to use.
flexible Describe the ways in which the system must change in
response to changing conditions or business needs.
improved, better, faster, Quantify how much better or faster constitutes
superior adequate improvement in a specific functional area.
including, including but The list of items should include all possibilities.
not limited to, and so Otherwise, it can't be used for design or testing.
on, such as, etc.
maximize, minimize, State the maximum and minimum acceptable values
optimize of some parameter.
normally, ideally Also describe the system's behavior under abnormal
or non-ideal conditions.


Terminology (6)

optionally Clarify whether this means a system choice, a user
choice, or a developer choice.
reasonable, when Explain how to make this judgment.
necessary, where
appropriate
robust Define how the system is to handle exceptions and
respond to unexpected operating conditions.
seamless, transparent, Translate the user's expectations into specific
graceful observable product characteristics.
several State how many, or provide the minimum and
maximum bounds of a range.
shouldn't Try to state requirements as positives, describing
what the system will do.
state-of-the-art Define what this means.


Terminology (7)

sufficient Specify how much of something constitutes
sufficiency.
support, enable Define exactly what functions the system will perform
that constitute supporting some capability.
user-friendly, simple, Describe system characteristics that will achieve the
easy customer's usage needs and usability expectations


Aras PLM Software Implementation Methodology

More Related Content

What's hot (20)

Similar to Aras PLM Software Implementation Methodology (20)

More from Aras (20)

Recently uploaded (20)

Aras PLM Software Implementation Methodology