Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink
	TABLE OF CONTENTS Introduction ISIS Methodology Design Agile Business Rules Development

ISIS Methodology Design

The ISIS methodology differs from the standard software development methodology because it is designed for use by consulting personnel, in a software company that produces components that often are only part of a final application. This is in contrast to methodologies that are used by an IT department, controlling the development of the application for its own company, from inception to retirement.

In particular, it means that:

• The duration of ILOG's professional services engagement seldom spans the entire customer project lifecycle. In particular, it is rare for ILOG to be involved during the customer's inception phase.
• The standard lifecycle should be enriched with additional processes that involve pre-sales, assessment and maintenance activities specific to a software vendor.
• The relatively short involvement of ILOG's professional services emphasizes the need for best-practices and how-to guides both from a technical perspective (i.e., on the ILOG products), and from a domain-knowledge perspective, to help the consultant quickly ramp-up on a project with specific problems and dealing with a specific industry.

OpenUP Foundation

An agile and iterative approach is critical to the successful development of business centric decision-support systems that involve business rules or optimization technology.

At the core of these systems is a direct reflection of the company's business policy as captured by the business analysts. The need for rapid update and deployment of new business processes, requires a short cycle of capture, implementation, and test of the business policies. It also requires that both IT and business knowledge owners be closely involved, to work on a shared and coordinated understanding of the system.

OpenUP is a software development methodology that embraces the agile principles presented in the Agile Manifesto and incorporates them into the proven characteristics of the Unified Process. This is specifically visible in project planning, through iterations and structured lifecycle with the successive project phases.

OpenUP was thus an obvious fit as the foundation for the ISIS methodology, promoting a healthy balance between agility and organization, through project phases and iterations.

The OpenUP methodology contents come as a standard part of the EPF platform distribution. Besides its contents, it provides a good template on how to structure the elements of an EPF plug-in and the published configurations.

Method Content Architecture

ISIS is designed as a set of interrelated EPF plug-ins, as in Figure 3.

The foundation plug-ins of ISIS are built on top of the standard OpenUP plug-in:

• ISIS/Common, which defines roles, tasks and work-products that are common to all the ILOG consulting processes.
• OpenUP/ABRD (Agile Business Rules Development), a tool-agnostic plug-in presenting an agile approach to the development of business rules applications.

The ISIS/BRMS plug-in is built on the ISIS/Common and OpenUP/ABRD plug-ins. It addresses the specific technical and project management aspects associated to the development of business rules projects based on ILOG's BRMS products. Similarly, the ISIS/Opti plug-in is dedicated to the specific of projects that use ILOG's linear and constraint based optimization technologies.

Finally, additional plug-ins address the methodology aspects linked to ILOG's most common application domains. Currently, these are Financial Services and Insurance (FSI) and Supply Chain Management (SCM). The vertical plug-ins extend the horizontal, technology oriented plug-ins, adding domain specific information to the generic technical contents of the horizontal plug-in.

Devising a Common Ground

The ISIS/Common plug-in represents the common foundation of the methodology. It introduces new ILOG-specific methodology elements that are required to model consulting-specific processes (such as additional roles, project phases, and disciplines) as well as customizations to the existing OpenUP elements.

Some of the new methodology elements are introduced as part of the existing OpenUP lifecycle. For example, ILOG, as a software vendor, sees pre-sales engagements such as application discovery workshops or application assessments as part of the Inception phase of a project. Parts of the tasks and work-products related to these engagements are independent of the application domain and the ILOG technology employed (business rules or optimization). These generic parts are thus described in the ISIS/Common plug-in and are further tailored and refined as necessary in the product specific BRMS and Optimization plug-ins to add the relevant details and the variations on the tasks' steps and on the work-products contents. Also, new roles that fit the ILOG PS practice, such as the Technical Account Manager role are introduced in ISIS/Common to participate to the pre-sales tasks.

Other elements need to extend the context of OpenUP. For example, ISIS includes a Production phase and an Operations and Support discipline, similar to the ones Scott Ambler introduced in the Enterprise Unified Process to support processes where ILOG consultants provide application maintenance services to its customer.

For the ISIS/Common method elements related to an existing OpenUP element, we use a Replaces or Extends and Replaces variability type. This is the case in particular for the roles defined in ISIS/Common that relate to OpenUP roles. This allows for the propagation of ILOG specific role definitions to the generic OpenUP elements. Also, by defining these variability relationships, we implicitly associate all the relevant elements from OpenUP (in particular the guidance elements) to the ILOG specific roles, tasks, and so on, thus taking full advantage of EPF's plug-in and variability concepts. Figure 4 shows the example of the ILOG "plan project" task from the ISIS/Common plug-in extending and replacing the OpenUP "plan project" task. After the relationship is established, the ILOG "plan project" task appears everywhere the OpenUP plan project task used to appear, with the Statement Of Work (sow) guideline element attached to it.

Previous Page | 1 Introduction | 2 ISIS Methodology Design | 3 Agile Business Rules Development Next Page

RELATED ARTICLES ZigBee Alliance, DLMS User Assoc Collaborate on Metering Data Compatibility Cloud Computing: Detecting Scalability Problems Logging In C++ : Part 2 OutSystems Updates Agile Platform SDK, .NET Controls Released for Communications Enabling Web Pages		TOP 5 ARTICLES No Top Articles.