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

Like this? Share it with your network

Share

Structured development in BMC Remedy AR System

on

  • 2,208 views

 

Statistics

Views

Total Views
2,208
Views on SlideShare
2,208
Embed Views
0

Actions

Likes
1
Downloads
72
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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

Structured development in BMC Remedy AR System Presentation 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.