|
The extensive and flexible framework provided by EPF let ILOG structure its methodology along several dimensions
April 04, 2008
URL:http://www.drdobbs.com/open-source/isis-and-the-eclipse-process-framework/207001868
Pierre Berlandier is a Principal Consultant at ILOG, where he has designed and developed numerous rules-based applications. These applications include expert systems for configuration and design of manufactured artifacts, real-time intelligent agents for the telecommunication industry, and business rules applications for the financial services and insurance industry.
A software development methodology describes who does what, how, and when to produce a software product. In this regard, the Eclipse Process Framework (EPF) provides a general formalism to:
EPF also provides a clean separation between the definition of the methodology elements and their presentation to the methodology users.
EPF encapsulates meaningful and related method and process contents in method plug-ins. The contents of plug-ins can then be extended or modified by other plug-ins. EPF provides a set of exemplary processes, the main one being OpenUP.
Figure 1 is a simplified view of the key EPF method elements and their relationships. The framework provides many more artifacts and relationships flavors and nuances:
The design of a methodology in EPF starts by creating the above elements and their relationships (a.k.a. "associations") within a method library using the EPF Composer, an integrated development environment (IDE) built on top of the Eclipse platform.
A set of attributes, taking the form of pure textual information or Rich Text, describe each element:
The above elements come together in an organized way through the definition of Processes (Capability Patterns or Delivery Processes), which provide the concepts of Work Breakdown Structure, Team Allocation, and Work Product Usage.
EPF then allows grouping the different elements by categories: Standard and custom categories. Standard categories are split into the pre-defined software methodology concepts of Disciplines, Domains, Work Product Kinds, Role Sets, and Tools. For example, you can create a "Project Data" category under the Work Product Kinds standard category and use it to qualify work products such as test results, problem reports, weekly status reports, and the like.
In contrast, custom categories are unconstrained hierarchical, ordered collections of method elements. Their main use is to compose configurations that are published as final methodology content. A standard use of a custom category is to present the different methodology elements according to different chosen points of view. Figure 2 shows an example of a custom category which presents the components of a process by grouping an introduction, a set of concepts, the set of disciplines, roles, delivery processes and work product kinds.
Plug-in entities bring together EPF method elements packages and processes. A plug-in can reference another plug-in so that its element definitions can reuse and extend the content of the referenced plug-in. This mechanism allows customizing the standard OpenUP content and tailoring it to the specific needs of an organization.
Method elements have a Content Variability section where the user can define how an element relates to another one, either from the same plug-in or, more often, from one of the referenced plug-ins. The variability definition can have different semantics, that can be roughly described as follows:
The concept of variability with its various semantics has been key in allowing the ISIS (ILOG Solution Implementation Standard) methodology to:
Configurations define which previously created elements should be published to the methodology users. A simple way to think about a configuration is as a set of views, each being materialized as a tab in the methodology web portal and presenting the contents of a custom category.
Configurations allow for some filtering on what to publish by selecting in each plug-in, which categories (standard or custom) should participate or should be removed from the published material. The concept of configuration allows the flexibility of building different, targeted instances of a methodology, based on the same compendium of material, with minimal investment.
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:
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.
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:
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.
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.
As part of ISIS, ILOG developed the Agile Business Rule Development process, an iterative methodology that leverages agile software development approaches to successfully manage the short deployment cycles associated with business rules applications. This subset of ISIS is tool-agnostic and can be applied regardless of the BRMS platform used for development.
It was thus an obvious candidate for a separate plug-in within ISIS, and was later contributed to the Eclipse Foundation as the OpenUP/ABRD plug-in.
As a general purpose plug-in, OpenUP/ABRD uses the "extends" variability on the OpenUP elements so that it leaves the OpenUP elements untouched. Within ISIS, the ISIS/BRMS plug-in references OpenUP/ABRD and its elements use the "extends and replace" variability so that the more generic concepts of OpenUP/ABRD are instantiated with ILOG-specific contents.
The last operation performed during the development of an EPF library is to publish the desired method elements configuration. The result of the publication is either organized as a collection of static HTML pages or as a web archive, deployable on a servlet container such as Tomcat.
While the static publish can easily be packaged as a web archive, the standard EPF web application publish offers the option to add a search feature to the deployable application, based on Apache Lucene's text search engine.
A static publish offers the convenience of installing the methodology contents locally, on the user's hard drive. This means quick and safe access to the contents on the user's desktop or laptop, regardless of the availability of an Internet connection.
The obvious downside is that whenever the methodology is expanded or updated, users need to update their local copy accordingly. The danger is that different users might, over time, use different versions of the contents, in particular different templates, resulting in inconsistencies in the projects work products.
By contrast, a centralized access to the published methodology through a corporate web application ensures the immediate user access to the latest contents, as well as the simplicity in making frequent updates. However, it leaves users at the mercy of Internet availability.
ISIS is dedicated to ILOG consultants and PS project managers who spend most of their time at a customer's site, often with limited or no access to the Internet. Because of that, they need a local copy of the contents. At the same time, we want to be able to publish new or refined contents frequently, in order to reflect the experience that is regularly gathered from new customer's engagements.
Because of this specific situation, ISIS actually uses both publish methods:
An RSS feed advertises the regular updates to the contents of the publication (minor updates are published on a weekly basis). With information from the feed, consultants can decide for themselves whether the changes are relevant enough for them to warrant a new download, which can take time, given the overall size of the ISIS body of knowledge.
Some tooling is required to complement the EPF Composer in customizing its output and managing contents that evolves and that is updated and republished on a weekly basis.
EPF supports basic customization of the published pages by letting the user select the contents of the about window, and the banner image.
Additional branding and customization of the published pages can be easily achieved by substituting some of the standard HTML files produced by EPF. Typically, the top navigation frame of the screen (which contents are implemented by the topnav.htm file) can be rewritten to introduce more elaborate branding, additional functionality and additional links. Figure 5 shows the standard top navigation frame generated by EPF. Figure 6 shows the ISIS custom top navigation frame with added buttons for methodology RSS feed subscription, offline-version download, and portal logout.
When the EPF library becomes large enough (which is the case for ISIS, with close to 2000 method elements), it becomes quite easy to overlook some of the method elements in the EPF publish, either because these elements are not directly included in a published custom category, or because they are not transitively referenced by a published element.
To avoid these oversights, ISIS uses a script that compares the set of elements contained in the published EPF plug-ins and the elements produced in the published pages. As a result of its execution, the script flags all the elements that are present in the library but absent from the publication.
To keep internal consistency and conventions, ILOG developed some content checking scripts that verify that the attached document names and the method element names follow the established naming conventions.
Once the methodology is published, there should be some standard mechanisms in place to ensure that the users are informed in a timely and non-intrusive manner of the updates and that they can provide some feedback on the artifacts.
The EPF published pages provide out-of-the-box a mechanism to submit feedback (e.g., on a specific page) through email. In ISIS, these emails go to a mailing list backed by an issue tracking system. Upon publication of a new ISIS update, there is an automatic harvest and a report generation of the comments associated to the resolution of these issues, into a "What's New" page added to the published pages. This way, the users are regularly kept informed of the fixes and updates that go into each specific release.
We found RSS to be a good medium to communicate significant updates and improvements to the methodology material. The portal thus points to an RSS feed to which the users can subscribe to.
The ISIS Workbook Generator supports the implementation of the ISIS methodology for ILOG customers by allowing the automatic creation of customer project workbooks which are tailored to a type of project.
A project workbook is an organized collection of deliverables (mostly document templates) that should be produced while executing a specific type of project (for example, an Assessment Report template for an Application Assessment engagement).
The Workbook Generator is a standalone Java Swing GUI application that is made available as part of the ISIS package installer.
It takes in a few parameters such as the name of the customer, his project name and the nature of the engagement. Using this information, it fetches the necessary documents from the ISIS publish, customize the templates and the file names with the given parameters, and organizes them into a hierarchy of folders.
This gives a standard layout to start up a project. Then, as the nature of the project evolves (for example, from an assessment type of engagement to a full-fledged project), the workbook can be extended by the Workbook Generator by incrementally adding the relevant document and templates.
ISIS currently has a regular user base of more than 300 consultants. The extensive and flexible framework provided by EPF allowed ILOG to structure its methodology along several dimensions, and easily support the extensions to the ISIS body of knowledge as it gains experience in new application domains.
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.