An Experience-Based Approach to Software Process Adaptation and Refinement

1. An Experience-Based Approach to Software Process Adaptation and Refinement Dr. Scott Henninger Associate Professor, Computer Science and Engineering University of Nebraska-Lincoln President, Adaptive Process Technologies

2. Omaha Spin 2 Overview Process-based knowledge management process tailoring and refinement rules define when processes and tasks are applicable collective ownership of the process BORE: a methodology generator Multiple views of a project integrating documentation, process, schedule, and tasks focus on design, development, testing, etc. tasks tools for managers and developers Conclusions and future work current evaluation settings combining design patterns and the Semantic Web

3. Omaha Spin 3 Development Methodologies Standard methodology frameworks and and standards produced to reach a wide audience therefore aim at the least common denominator not always sufficient information to accomplish a task quickly become outdated fast pace of business and technology changes The reality followed for auditing purposes it’s just paperwork, pure overhead level of abstraction too abstract to inform developers even so, the information can be copious not everything is appropriate for every project basis for determining project-specific criteria is lacking

4. Omaha Spin 4 Heavyweight and Lightweight Processes Heavyweight methodologies normally document and management-driven normally set up to achieve consistency but consistency in the face if change can be dysfunctional Lightweight process minimize document and design burden designed to change quickly often confused with the term “agile” too much change can lead to chaos IT experience with teams “adapting” CSC processes more difficult to achieve process improvement Every project has elements of both need means to migrate gradually criteria for which process is applicable for a given project

5. Omaha Spin 5 Overall Research Objectives Turn defined process into a repository of best practices use process to show how others have performed the tasks building an organization-specific knowledge base Collective ownership of the methodology process modified through practice experiences collected while executing process …and developing software collecting and disseminating lessons learned

6. Omaha Spin 6 BORE Building a Organizational Repository of Experiences using process to organize, extend, and refine knowledge capturing the context for using different techniques Framework for building methodologies process represented at the task level multiple tasks and dependencies represent a process model each methodology represented by: tasks and dependencies rules for when the tasks apply projects create instances of the methodology differ in the options chosen and documentation

7. Overall Approach Process tailoring (project level) define applicability rules for tasks “if there are significant technical risks” “document the risks, perform prototyping tasks” deliver development resources “when performing client-side database access, use the mediator pattern to encapsulate calls to the database server” Flexible software process (organization level) using process to disseminate best practices more detailed knowledge than process standards capture more than the least common denominator supporting process diversity tailor process to specific project needs document project-specific issues

8. Omaha Spin 8 BORE Methodology-Based Projects

9. Omaha Spin 9 Tailoring the Methodology Each project creates an instance of the methodology

10. Omaha Spin 10 Tailoring Rules Tailoring to specific project needs capture context in rules under these conditions, assign this task can be high-level, or very detailed really capturing project decisions, requirements rules used for capturing context …not constraining developers, managers, other stakeholders Rule-based engine preconditions: question/answer pairs actions: assign tasks, other actions

11. Omaha Spin 11 Process Evolution

12. Omaha Spin 12 Organization-Level Process Refinement Methodology will never cover all projects … I.e. can never assume perfect knowledge must evolve with the changing business domain each project will extend the repository Teams can deviate from the process when current rules/tasks don’t apply provide deviation rationale review the deviation Extending the expert system paradigm rules as a resource for human action collaborative creation of rules continues to learn through use

13. Omaha Spin 13 Deviation Process Ways to deviate from the methodology in a methodology-based project… add a new task anywhere delete a project task System opens the case to a “deviation rationale” tab record reasons why you need to add/delete the task if user cancels, task is not added/deleted Case is marked as “Provisional” case can be edited by project immediately don’t have to wait for approval

14. Omaha Spin 14 Deviating from the Methodology Red square indicates provisional delete Green square indicates provisional add

15. Omaha Spin 15 SEPG Group (or Person) Methodology manager sees list of process deviations can approve or reject deviations if rejected, case marked for deletion/undeleted looks for “trailblazer” projects to create new processes i.e. new parts of the methodology Manager can be anyone with proper privileges as lightweight or heavyweight as needed project manager, organization-wide process manager even developers, if desirable

16. Omaha Spin 16 Approval Process Manager sees methodology, projects chooses project can go back and forth between deviation list and project

17. Omaha Spin 17 Accepting and Analyzing Deviations View all deviations for methodology in projects …other views are needed

18. Omaha Spin 18 Deviation Rationale Idea is to set the context for the deviation process custodian can choose to turn rationale into rules Example of good deviation rationale “Because there was considerable risk in requirements volatility, we added tasks for working with the user to resolve and document requirements issues” if risk in requirements = high then add tasks for negotiating and documenting requirements may even want to be more specific… Use deviations as an “opportunity for learning” can view all deviations for a methodology look for trends, gaps, etc.

19. Omaha Spin 19 Three Project Views in BORE Task, Timeline, and Documents all generated from same integrated database

20. Omaha Spin 20 Keeping Methodology Current Methodology embedded in hierarchy change in BORE Methodology Task changes assigned tasks versioning policies being created

21. Omaha Spin 21 Document Generation Templates to generate documents from tasks canned templates for project to use and adapt smart incorporation of iterations i.e. use task from most recent iteration documentation largely a matter of choosing which tasks to include and where (some of this is in the works – next 2-3 weeks) Custom views of document create document and save project or individual viewable put all “success model” tasks in one document all sections with database implications, etc.

22. Omaha Spin 22 Project Schedules Tasks have dependencies, start and end dates use to convert to a Gantt chart MS Project interface export data to Project edit in Project, import into BORE (working soon) other interfaces possible Workbench, etc. General idea is to center information in BORE use other tools for display purposes (and some editing capabilities as well)

23. Omaha Spin 23 BORE Task Dependency Tab

24. Omaha Spin 24 Attaching Templates Templates placed in methodology tasks copied to projects filled out by projects

25. Omaha Spin 25 Other Features Embedded CM – Change Task Manager used to build BORE front-end to automate aspects of CVS integration with defect reports & enhancements is next Roles and task owners rules can assign tasks to roles project enactment maps people to roles Task Finder displays current open tasks (& general queries) Personal Space (Bookmarks) create links to tasks also create tasks (information holders) private to user

26. Omaha Spin 26 BORE Evaluation Have developed about 10 methodologies most in part – most comprehensive is USC CS 577 MBASE (MBASE – Model-Based System Architecting and SE) (Boehm & Port, http://sunset.usc.edu/research/MBASE/mbase_main.html#papers) Current academic users Univ. Southern California (USC) year-long course taught by Dr. Barry Boehm develop digital library projects, some others have implemented their methodology (MBASE) in BORE are running various research projects in BORE (NASA, DoD, etc.) Software Design Studio at UNL JD Edwards Honors program 7 teams developing software for industry clients emphasis on business software

27. Omaha Spin 27 Software Design Studio Process Combination of Agile, MBASE and RUP MBASE and RUP closely related 3 week risk-based iterations assess risks, plan next 3 weeks in detail, etc. keep current task and backlog lists prototype early, keep working version of system available 4 major milestones (anchor points) Project Initiation Elaboration/Requirements Construction Transition (no Support, etc.) Use Case-driven design documents developed via task list

28. Omaha Spin 28 Example SDS Team Task breakdown tasks and subtasks Status indicated by colored icon blue: resolved green: active open green:open red: open/critical

29. Omaha Spin 29 BORE Evaluation (con’t) Industry users Gallup – pilot project starting this week Jet Propulsion Laboratory process for using land rover framework Mutual of Omaha (very interested, but a maybe) Overall assessment framework is flexible enough to implement a wide range of processes knowledge management potential is high all project information in one place (not separate databases) need to incorporate more development knowledge (patterns, etc.) some questions on documentation burden seems to reduce burden overall by focusing on tasks, not documents still just an advanced prototype…

30. Omaha Spin 30 Current System Status BORE prototype http://cse-ferg41.unl.edu/bore.html log in as ‘guest’ (no password) Currently being evaluated at Gallup Labs small IT shop very intolerant of quality breakdowns Academic settings USC CS577 course – implemented MBASE in BORE UNL Software Design Studio both develop for external clients interface and functionality feedback have been invaluable

31. Omaha Spin 31 Future Research Directions Pattern languages deliver pattern choices as knowledge structures I.e. point people to the most applicable patterns base design choices on pattern choices initial concentration on usability patterns Semantic Web use as representational medium for tasks, reusable process models representation of relationships, constraints create an interconnected pattern “language” inferencing capabilities WWW dissemination and reuse

32. Omaha Spin 32 Future Research (con’t) Augmenting rules with Case-Based Reasoning i.e. find processes meeting current criteria rules are used as a representation of requirements find projects with similar characteristics, use and adapt the process used need metrics to measure “success”

33. Omaha Spin 33 Next Steps Assessment of CMMI compliance I.e. how was is it to implement CMMI PAs largely an empirical question – will implement some templates work begins in earnest once Process Models implemented use rules, inference mechanisms, to fit PA instances to projects Further validation of the tool difficult to do artificially – need more pilot projects have learned much from USC, Design Studio, Gallup can easily work with partially completed projects embed current artifacts (including schedule) in BORE use BORE to manage project & deliver information to developers continue to refine BORE to meet project needs bottom-up capture of effective work practice

34. Omaha Spin 34 Adaptive Process Technologies UNL spin-off http://www.AdaptiveProcessTechnology.com focus on adaptive process models i.e. methodologies that adapt to project and organizational needs more than templates – organization evolves the process Business Models continued University research patterns, Semantic Web, case-based reasoning partnerships for system refinement Small Business Innovative Research (SBIR) grant from NSF, starting Jan 1 2003 may migrate to J2EE (.NET??) environment

35. Omaha Spin 35 APT Business Model Currently developing business model and case research need, feasibility, competitors, price points, etc. Provide BORE tool and training provide tool (with templates) and train to evolve process -or- contract to provide process oversight BORE ASP BORE can support multiple independent methodologies access control at organizational, methodology, and task levels Adaptive process consulting help organizations adapt methodologies to meet their needs process evolution and improvement

36. Omaha Spin 36 BORE and CMMI Supports either staged or continuous models BORE works at Process Area level can therefore define by capability or maturity each Process Area represented by a “Process Model” Process Model is a set of tasks and relationships incorporated in BORE soon (including rule scoping) can support many models conforming to PA specs rules help choose which model to use to meet a PA Example: quantitative project management handled by rules if task overruns by x% …add additional risk mitigation tasks and/or corrective analysis tasks

37. Omaha Spin 37 BORE and CMMI (con’t) Provides two levels of process specification Process Areas: sets of standard tasks Tasks: specific tasks to be enacted can be more specific than PAs for ex: “Requirements Development using Use Cases” even “Use Cases for data-intensive applications” rules guard against information overload do not need to know entire process to use it just what is necessary for your project! Specific goals and practices represented in tasks each project is then a “case” of the practice/goal for example, ProjectX’s Use Cases for “Requirements Development using Use Cases” opportunity for reusing (an improving) best practices

38. Omaha Spin 38 Software Development Resources Document management attach documents to tasks templates and other standard documents ancillary resources guidelines, design pattern, etc. Context-specific information delivery information alerting cannot assume people always know what information exists need to know something exists before people will search for it search engines are still valuable but should be the tool of last resort takes people out of their normal workflow

39. Omaha Spin 39 Institutionalizing a Tool Like BORE Collective ownership of the process Institutional overhead process expertise (already in most organizations) process repository librarian (a CMM Level 3 requirement) Project reviews (already practiced) added burden of reviewing tool effectiveness formal means of reviewing project requirements

40. Omaha Spin 40 task View

41. Omaha Spin 41 Take Aways Integration of Process and Knowledge Delivery flexible process to meet diverse project needs knowledge attached to tasks across projects capture best practices and the applicability context push model for best practices Collective ownership of process initial seed by process group process group oversees disciplined evolution and specialization Integration of tasks, process, project management, and documentation all within the context of developing the software/system