Structured development in BMC Remedy AR System

© 2011 World Wide Remedy Users Group. All Rights Reserved. 1
1

STRUCTURED
DEVELOPMENT
IN AR SYSTEM
ANDERS WILHELM
© 2011 World Wide Remedy Users Group. All Rights Reserved.

Anders Wilhelm
2

© 2010 World Wide Remedy Users Group. All Rights Reserved.

Objectives and Results
3

 Objectives
 Why structured development is important
 Project management models which suits AR
System development
 AR System coding
- tips and tricks

© 2011 World Wide Remedy Users Group. All Rights
Reserved.

Part 1
4

 WHY has structured development in AR
System become important?

Reserved.

The AR System development
5
platform-the good stuff
 A true rapid applications development
platform
 You can build big things with small teams

 Focus on functions rather than coding

 Build applications with *a lot* of

functionality in a short time
 Easy to deploy changes

 Feature set getting close to traditional

programming languages
Reserved.

Things used to be simple
6

 In the early days

Help desk
Categorization People Equipment
Case

< 20 forms
< 100 filters
< 100 active links

Reserved.

Now AR System applications
7
are huge

>50 forms
> 5000 filters
> 10000 active links

Reserved.

AR System weaknesses?
8

 Isolated objects – the object soup - understanding
the code
 No modeling support – poor form design =
problematictic foundation (card houses)
 Poor/sloppy naming may cause a debugging/
maintenance nightmare
 A field is a field – no difference between data fields,
temporary variables, gui fields etc (well… it is also a
*good* thing)

 RAD with high code quality?
Reserved.

What makes a sound
9
application?
 What is a sound application in terms of AR System?

 Built on a good and solid foundation
 Adherence to naming and numbering conventions
 Code re-use
 Experienced developers

Reserved.

Part 2 - Development stages
10

 Stages in AR System development
 Where to start

 Getting user acceptance/commitment

Reserved.

What we got from RADD
11
Requirements
gathering

Design
Prototyping

Implementation

Test

Deployment

Maintenance

Reserved.

Requirements gathering
12

 The Workshop
 RADD documentation
principle
 Use-cases
 Informal functional
speciﬁcations
 User-usage centric

 Pitfalls

Reserved.

Requirements gathering
13

 Protocol analysis – The users describe each step
 Observation – watch how a task is performed
 Scenario analysis – trace a task from initial business
trigger to sucessful outcome
 Activity sampling – track how users spend their time
on tasks

Reserved.

Requirement gathering
14

 Most CASE-tools are focused towards
traditional coding

 Xuse
 Mantis

 UFO

 Pivotal Tracker

Reserved.

Modelling/Designing a
15
system
 Often a step which is rushed through
 More important now than before as

applications become larger

Reserved.

Why is the data model
16
important?
 The forms ARE the data model
 We build all functionality on the ﬁelds and

the forms

Reserved.

Challenges with AR System
17
database modeling
 Normalized – de-normalized
 Some typical data model ”tricks” cannot be

done with AR System forms/functionality
 No concept of objects eg. Customer

information ﬁelds - ﬁeld groups

Reserved.

Prototyping
18

 Goals for a prototype
 Verifying process coverage

 User acceptance

 Prototyping in AR System is different

compared to traditional prototyping

Reserved.

Prototyping - purpose
19

 Using the prototype as development base?

Reserved.

Prototyping
20

 Don’t overdo the prototype
 Don’t get too attached to it

 Listen to your users

 Cost is low to change the prototype

compared to last minute changes

Reserved.

Iterative development
21

 AR System is well suited for iterative
development
 The iterations can be very short compared

to traditional programming
 Agood way to get user acceptance for

functionality (building just enough)

 Informal testing

Reserved.

Testing
22

 Use the use-cases as base for test-cases

 Who should do the testing
 What to test?

 Load testing?

Reserved.

Deployment
23

 Checklists
 Knowing what to roll out and how

 Back-out plans

 Resource availability

Reserved.

Managing a system in
24
production
 Maintenance / changes

 Data-driven approaches

 Tracking user requests

 Proﬁling / benchmarking

Reserved.

Part 3 - Projects
25

 Sizing the team
 Which project management model to

choose?
 Which development model to choose?

Reserved.

Different types of projects
26

 One man
 Small teams

 Large teams

Reserved.

The lone ranger- The Admin
27

Developer System admin

Report designer

DBA Trainer

Process guru
GUI-expert
Integration-
Analyst specialist

Application admin Web developer

Reserved.

Small teams – 3—9 people
28

Architect - Project manager

Integration Trainer/
Lead developer Tool smith specialist Documentor

Reserved.

Large teams – 10>
29

Project manager

Implementation architect Implementation architect

Lead developers Lead developers

Developers Developers

Team 1 Team 2

Reserved.

Project/Development
30
management methods
 What is the difference?

Reserved.

Project management
31
methods
 PROPS
 PPS

 Prince2

 SPICE

 V-model

 Barashi

 Administrative/budget/risk management

Reserved.

My current favorite PM-
32
method - Barashi

Reserved.

Development methodology
33

 RADD
 RUP

 Agile methodology; SCRUM, XP etc

 Any takers for JSP?

Reserved.

RADD
34

 Requirement gathering
 Usability

 No formal methodology – best practices

Reserved.

RUP
35

 Iterative development
 Manage requirements

 Component based architecture

 Visual software modelling

 Continuous veriﬁcation of quality

 Change management

Reserved.

RUP brought us
36

 Use-cases
 Prototyping

 Actor driven approach to usability

 Iterative approach

 Not 100% suited for AR System
development
 Ess-UP

Reserved.

Why is Scrum a good match
37
for AR System development?
 Less focus on long-termtime plans, instead
delivering business value
 Concensus on what to build

 Quickly adjust to changes

 Get the development team commited

Reserved.

Scrum
38

 Product owner
 Scrum master

 Team

Reserved.

Scrum
39

 Product backlog
 Sprint backlog

 Sprint

 Daily scrum

 Sprint review

Reserved.

Scrum – Pigs and chickens
40

Reserved.

Scrum
41

“Pig” roles
 Scrum Master
 The team
 Product Owner

“Chicken” roles
 Stakeholders (customers, vendors
 Managers
 .

Reserved.

Scrum - weaknesses
42

 Not well suited for outsourcing
 Requires *strong* developers
 Not well suited for HUGE projects
 Always moving forward, not looking back (lack of
sprint reviews)

Reserved.

Scrum - planning
43

Reserved.

Scrum - planning
44

Reserved.

Scrum
45

Reserved.

Part 4 - Good code
46

 Some suggestions on how to build
 Some suggestions on how to name

 Some suggestions on modules

Reserved.

Birds of a feather session?
47

 Why is there no Dev handbook?

Reserved.

The sound remedy
48
application revisited
 Structure and consistency
- Naming conventions
- Modular functionality
- Field id numbering conventions

 Normalized / Non-normalized database
models

Reserved.

Data modeling
49

Reserved.

Normalized/De-normalized
50

 De-normalized by default
 How/What should be normalized

 Techniques - pros/cons

Reserved.

Relationships
51

 Foreign key ﬁelds
 Association tables

 Joins

 Populate-on-fetch (GE-ﬁlters)

Reserved.

During modeling - objects
52

 Try to group ﬁelds together into objects

 Use ﬁeld id series for different object
groups

 Code re-use
 Extendability

Reserved.

Data modeling tools
53

 Visio
 Sybase DataArchitect

 ERWin

 AR*Evolution

 ER/Studio

 MySQL Workbench

Reserved.

Strategies for development
54

 Modular code
 Code re-use

 Guides
 Common objects

 Naming conventions

 Services

- re-using code
Reserved.

Common objects - form
55

 Use a standard set of fields you use on
every form (deletion flag, ”Admin” flag, etc)

 Functionality for deletion, user profiles,
admin-control

Reserved.

Common objects -
56
application
 Common notiﬁcation rule engine

 Field control based on conﬁguration

 Metrics

Reserved.

Structure your code-
57
execution order
 0-200
 201-400

 401-600

 900->

 By using guides you’ve got plenty of leg-
room

Reserved.

Structure your code-guides
58

 Guides are your friend
 Filter paths (admin, data cleansing)

 Standard guides

 Guides for complex search/ﬁltering

Reserved.

Structure your code-services
59

 Validation
 Complex functions



Reserved.

Field numbering
60

 Field IDs - ”Ristat i runa” - that is...
”Written in stone” for non-swedes

 Form-Object centered approach

Reserved.

Field naming
61

 Complex fields
 Temporary fields / variables

 Data fields

 GUI-fields (like buttons, labels etc)

Reserved.

Form-Workﬂow naming
62

 Any standard is good as long you have one
here is mine

 ph_MainHolder_Info



Reserved.

Common pitfalls
63

 Many small changes – messy system
 Too quick, too sloppy

 How to keep track of everything

Reserved.

Documentation
64

 System documentation?
 Change tracking

 What to document – obejcts

 Tools of the trade

Reserved.

Documentation tools
65

 BMC Developer studio 7.6.04
 Arsdoc

 AR System Developer + (Master

documenter)
 3rd party tools

Reserved.

Questions/Discussions
66

Reserved.

67
61 Thank You
wilhelm@erwe.se

http://www.erwe.se/awilhelm

Reserved.

Example used in this tutorial
68

 Ongoing project
 Application for Complaints management

 Barashi methodology

 Scrum

 Validation / Strict change management
 21 CFR part 11

Reserved.

Structured development in BMC Remedy AR System

Recommended

Recommended

More Related Content

What's hot

What's hot (18)

Viewers also liked

Viewers also liked (20)

Similar to Structured development in BMC Remedy AR System

Similar to Structured development in BMC Remedy AR System (20)

Recently uploaded

Recently uploaded (20)

Structured development in BMC Remedy AR System

Editor's Notes