Your SlideShare is downloading. ×
Structured development in BMC Remedy AR System
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Structured development in BMC Remedy AR System

2,048
views

Published on

Published in: Technology, Business

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,048
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
84
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Presentation slide for courses, classes, lectures et al. \n
  • Beginning course details and/or books/materials needed for a class/project.\n
  • Objectives for instruction and expected results and/or skills developed from learning. \n
  • Beginning course details and/or books/materials needed for a class/project.\n
  • Beginning course details and/or books/materials needed for a class/project.\n
  • Beginning course details and/or books/materials needed for a class/project.\n
  • \n
  • Often we have to turn to ”printf debugging” to understand the code. Guides, execution order… \n
  • Often we have to turn to ”printf debugging” to understand the code. Guides, execution order… \n
  • Beginning course details and/or books/materials needed for a class/project.\n
  • Beginning course details and/or books/materials needed for a class/project.\n
  • Beginning course details and/or books/materials needed for a class/project.\n
  • Beginning course details and/or books/materials needed for a class/project.\n
  • Pitfalls – workshop – getting the right people to attend\n
  • Often we have to turn to ”printf debugging” to understand the code. Guides, execution order… \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Beginning course details and/or books/materials needed for a class/project.\n
  • \n
  • \n
  • \n
  • Management becomes a problem. Ericsson / Telia / Scania\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Beginning course details and/or books/materials needed for a class/project.\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • An opportunity for questions and discussions.\n
  • \n
  • Beginning course details and/or books/materials needed for a class/project.\n
  • Transcript

    • 1. © 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.
    • 2. Anders Wilhelm2 © 2010 World Wide Remedy Users Group. All Rights Reserved.
    • 3. Objectives and Results3  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.
    • 4. Part 14  WHY has structured development in AR System become important? © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 5. The AR System development5 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 © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 6. Things used to be simple6  In the early days Help desk Categorization People Equipment Case < 20 forms < 100 filters < 100 active links © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 7. Now AR System applications7 are huge >50 forms > 5000 filters > 10000 active links © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 8. 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? © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 9. What makes a sound9 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 © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 10. Part 2 - Development stages10  Stages in AR System development  Where to start  Getting user acceptance/commitment © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 11. What we got from RADD11 Requirements gathering Design Prototyping Implementation Test Deployment Maintenance © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 12. What we got from RADD11 Requirements gathering Design Prototyping Implementation Test Deployment Maintenance © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 13. What we got from RADD11 Requirements gathering Design Prototyping Implementation Test Deployment Maintenance © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 14. What we got from RADD11 Requirements gathering Design Prototyping Implementation Test Deployment Maintenance © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 15. Requirements gathering12  The Workshop  RADD documentation principle  Use-cases  Informal functional specifications  User-usage centric  Pitfalls © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 16. Requirements gathering13  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 © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 17. Requirement gathering14  Most CASE-tools are focused towards traditional coding  Xuse  Mantis  UFO  Pivotal Tracker © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 18. Modelling/Designing a15 system  Often a step which is rushed through  More important now than before as applications become larger © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 19. Why is the data model16 important?  The forms ARE the data model  We build all functionality on the fields and the forms © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 20. Challenges with AR System17 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 fields - field groups © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 21. Prototyping18  Goals for a prototype  Verifying process coverage  User acceptance  Prototyping in AR System is different compared to traditional prototyping © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 22. Prototyping - purpose19  Using the prototype as development base? © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 23. Prototyping20  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 © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 24. Iterative development21  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 © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 25. Testing22  Use the use-cases as base for test-cases  Who should do the testing  What to test?  Load testing? © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 26. Deployment23  Checklists  Knowing what to roll out and how  Back-out plans  Resource availability © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 27. Managing a system in24 production  Maintenance / changes  Data-driven approaches  Tracking user requests  Profiling / benchmarking © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 28. Part 3 - Projects25  Sizing the team  Which project management model to choose?  Which development model to choose? © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 29. Different types of projects26  One man  Small teams  Large teams © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 30. The lone ranger- The Admin27 Developer System admin Report designer DBA Trainer Process guru GUI-expert Integration- Analyst specialist Application admin Web developer © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 31. Small teams – 3—9 people28 Architect - Project manager Integration Trainer/ Lead developer Tool smith specialist Documentor © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 32. Large teams – 10>29 Project manager Implementation architect Implementation architect Lead developers Lead developers Developers Developers Team 1 Team 2 © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 33. Project/Development30 management methods  What is the difference? © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 34. Project management31 methods  PROPS  PPS  Prince2  SPICE  V-model  Barashi  Administrative/budget/risk management © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 35. My current favorite PM-32 method - Barashi © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 36. Development methodology33  RADD  RUP  Agile methodology; SCRUM, XP etc  Any takers for JSP? © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 37. RADD34  Requirement gathering  Usability  No formal methodology – best practices © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 38. RUP35  Iterative development  Manage requirements  Component based architecture  Visual software modelling  Continuous verification of quality  Change management © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 39. RUP brought us36  Use-cases  Prototyping  Actor driven approach to usability  Iterative approach  Not 100% suited for AR System development  Ess-UP © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 40. Why is Scrum a good match37 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 © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 41. Scrum38  Product owner  Scrum master  Team © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 42. Scrum39  Product backlog  Sprint backlog  Sprint  Daily scrum  Sprint review © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 43. Scrum – Pigs and chickens40 © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 44. Scrum41 “Pig” roles  Scrum Master  The team  Product Owner “Chicken” roles  Stakeholders (customers, vendors  Managers  . © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 45. Scrum - weaknesses42  Not well suited for outsourcing  Requires *strong* developers  Not well suited for HUGE projects  Always moving forward, not looking back (lack of sprint reviews) © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 46. Scrum - planning43 © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 47. Scrum - planning44 © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 48. Scrum45 © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 49. Part 4 - Good code46  Some suggestions on how to build  Some suggestions on how to name  Some suggestions on modules © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 50. Birds of a feather session?47  Why is there no Dev handbook? © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 51. The sound remedy48 application revisited  Structure and consistency - Naming conventions - Modular functionality - Field id numbering conventions  Normalized / Non-normalized database models © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 52. Data modeling49 © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 53. Normalized/De-normalized50  De-normalized by default  How/What should be normalized  Techniques - pros/cons © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 54. Relationships51  Foreign key fields  Association tables  Joins  Populate-on-fetch (GE-filters) © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 55. During modeling - objects52  Try to group fields together into objects  Use field id series for different object groups  Code re-use  Extendability © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 56. Data modeling tools53  Visio  Sybase DataArchitect  ERWin  AR*Evolution  ER/Studio  MySQL Workbench © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 57. Strategies for development54  Modular code  Code re-use  Guides  Common objects  Naming conventions  Services - re-using code © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 58. Common objects - form55  Use a standard set of fields you use on every form (deletion flag, ”Admin” flag, etc)  Functionality for deletion, user profiles, admin-control © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 59. Common objects -56 application  Common notification rule engine  Field control based on configuration  Metrics © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 60. Structure your code-57 execution order  0-200  201-400  401-600  900->  By using guides you’ve got plenty of leg- room © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 61. Structure your code-guides58  Guides are your friend  Filter paths (admin, data cleansing)  Standard guides  Guides for complex search/filtering © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 62. Structure your code-services59  Validation  Complex functions  © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 63. Field numbering60  Field IDs - ”Ristat i runa” - that is... ”Written in stone” for non-swedes  Form-Object centered approach © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 64. Field naming61  Complex fields  Temporary fields / variables  Data fields  GUI-fields (like buttons, labels etc) © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 65. Form-Workflow naming62  Any standard is good as long you have one here is mine  ph_MainHolder_Info  © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 66. Common pitfalls63  Many small changes – messy system  Too quick, too sloppy  How to keep track of everything © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 67. Documentation64  System documentation?  Change tracking  What to document – obejcts  Tools of the trade © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 68. Documentation tools65  BMC Developer studio 7.6.04  Arsdoc  AR System Developer + (Master documenter)  3rd party tools © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 69. Questions/Discussions66 © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 70. 6761 Thank You wilhelm@erwe.se http://www.erwe.se/awilhelm © 2011 World Wide Remedy Users Group. All Rights Reserved.
    • 71. Example used in this tutorial68  Ongoing project  Application for Complaints management  Barashi methodology  Scrum  Validation / Strict change management  21 CFR part 11 © 2011 World Wide Remedy Users Group. All Rights Reserved.