Aras PLM Software Implementation Methodology

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

A C E G E R M A N Y

BEDIFFERENT


ACE

Germany

Implementation Best Practices Scrum Methodology

Patrick Willemsen Senior Consultant

ARAS Software AG


Dilbert says

Slide 3


Agenda

Agile Methodology – An Overview

Agile Methodology – Applied

Questions

Slide 4


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

Slide 5


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

Slide 6


Agile Development

Slide 7

Product backlog Sprint backlog

Scrum

Product increment

Sprint

n days

Use Cases (Requirements)

UC001 UC003 UC015

…


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

Scrum master

Customer Process owner(s)

Consultant(s)

Architect(s)


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

Sprint n days

1

Sprint planning

Requirements definition 2

Sta

rt

3

Solution specification

4 Implementation

Part

Result presentation

Demo

Consultant(s) Customer representatives

Scrum master

Architect

Product owner

• Scrum

5 Product increment


Meetings (1)

Meeting Topics

Planning Select what work is to be done

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?

Do you have any problems preventing you from accomplishing your goal?

limit: 2h

limit: 15 min

At the beginning of a sprint cycle resp. daily


Meetings (2)

Meeting Topics

Review (demo) Present the completed work to the stakeholders (a.k.a. "the demo")

Incomplete work cannot be demonstrated

Review (sessions)

Review the work that was completed and not completed by the sprint team

Retrospective All team members reflect on the past sprint

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?

limit: 2h

limit: 2h

limit: 1h

At the end of a sprint cycle


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.




Now how does this apply to Aras Innovator?

OK, GREAT!


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

Slide 19

Starting Your Aras Implementation

ACE 2011 International

http://en.wikipedia.org/wiki/Agile_software_development


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

Slide 20


Discovery Workshop

Slide 21

SoW

Customer investigation

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

Business process analysis Business entity model definition Solution mockup

Customer workshop

order Result


UC001 UC003 UC015

…

Use Case Workshops

Slide 22

SoW

Detailed use cases Requirement definition System design

Product backlog

Discovery Workshop

Process description Solution description Solution proposal Brief use cases …

UC001

UC003 UC004

UCnnn

Customer project order

Use Case and Design Workshops


Sprint Plan

System Architecture

High Level Use Cases

Non-functional requirements

Sprint 1 Part & BOM Management

Implementation Test

Sprint 2 Part & BOM Management

Implementation Test

Sprint 3 Change Management

Implementation Test

Sprint 4 Program and

Project Management

Implementation Test

Slide 23

Product increment

Product increment

Product backlog

UC001 UC003 UC015

…

Requirements definition

Discovery Workshops

Requirements Requirements


Part & BOM Management Example

Topics

Requirements Definition

Use case definition

Data model

Numbering scheme

Life cycle

Workflow

Permissions

Revisioning and sequence

Relationships to other items (Part, CAD, documents, …)

System

Slide 24

Visual Prototypes


Implementation

Sprint

Develop product increment

Write agile documentation

Maintain product backlog

Result Presentation

Live Demo

Slide 25


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!

Slide 26


ACE Germany

Questions?

Patrick Willemsen Senior Consultant

ARAS Software AG


Project Management Scrum


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.

Slide 29


Use Cases Modeling Basics


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.

Slide 37


Fully-Dressed

Use case name

Brief description

Scope

Primary actor

Stakeholders and interests who cares about this use case, and

what do they want?

Preconditions what must be true on start?

Success guarantee (Post conditions) what must be true on successful

completion?

Main success scenario typical path, happy path

Extensions alternate scenarios of success and

failure

Frequency of occurrence Daily, Weekly, Monthly, Quarterly,

Yearly

Complexity Concerning logic which corresponds

to implementation effort

Easy (OOTB), Medium (small enhancements), Difficult (complex logic)

Miscellaneous

alistair.cockburn.us

http://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


Requirements Modeling Basics


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, not more than, not to exceed

Specify the minimum and maximum acceptable values.

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, superior

Quantify how much better or faster constitutes adequate improvement in a specific functional area.

including, including but not limited to, and so on, such as, etc.

The list of items should include all possibilities. Otherwise, it can't be used for design or testing.

maximize, minimize, optimize

State the maximum and minimum acceptable values 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 necessary, where appropriate

Explain how to make this judgment.

robust Define how the system is to handle exceptions and respond to unexpected operating conditions.

seamless, transparent, graceful

Translate the user's expectations into specific 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, easy

Describe system characteristics that will achieve the customer's usage needs and usability expectations

Date post:	10-May-2015
Category:	Technology
Upload:	aras
View:	578 times
Download:	3 times

Aras PLM Software Implementation Methodology

Technology