An ExperienceBased 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
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
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
• its 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
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
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
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
BORE Methodology-Based Projects
9
Tailoring the Methodology

• Each project creates an instance of the
  methodology

• holds specific project and process tailoring
  information
• choose options to document project requirements
• rules choose appropriate tasks

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
Process Evolution
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 dont 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
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
• dont have to wait for approval

14
Deviating from the Methodology

• Red square indicates provisional delete
• Green square indicates provisional add

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
Approval Process

• Manager sees methodology, projects
• chooses project
• can go back and forth between deviation list and
  project

17
Accepting and Analyzing Deviations

• View all deviations for methodology
• in projects
• other views are needed

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
Three Project Views in BORE

• Task, Timeline, and Documents
• all generated from same integrated database

20
Keeping Methodology Current

• Methodology embedded in hierarchy
• change in BORE Methodology Task changes assigned
  tasks
• versioning policies being created

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
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
BORE Task Dependency Tab
24
Attaching Templates

• Templates placed in methodology tasks
• copied to projects
• filled out by projects

• Related projects
• links to all projects using a given methodology
  task
• view solution examples

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
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/MBAS
  E/mbase_main.htmlpapers)
• 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
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
Example SDS Team

• Task breakdown
• tasks and subtasks
• Status
• indicated by colored icon
• blue resolved
• green active
• open greenopen
• red open/critical

29
BORE Evaluation (cont)

• 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
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
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
Future Research (cont)

• 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
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
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
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
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
BORE and CMMI (cont)

• 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, ProjectXs Use Cases for
  Requirements Development using Use Cases
• opportunity for reusing (an improving) best
  practices

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
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
task View
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