Delivering the Agile/ICONIX Process via the Eclipse Process Framework

Dr. Charles Suscheck, ICONIX

Doug Rosenberg, ICONIX




Java developers using the Eclipse environment can have a "pre-fabricated development process" delivered to them using the Eclipse Process Framework (EPF). Until recently, process options available in this format were mostly limited to a Unified/RUP option, and an eXtreme Programming (XP) option. Historically, each of these options has presented some challenges; full blown RUP is large and complex, requires tailoring, and can be difficult to learn, while XP offers little in the areas of analysis, design, and requirements management, focusing mostly on the coding and testing phases of development.


With the release of Agile/ICONIX-EPF, developers now have an additional option, which offers the benefits of a minimalist, agile approach to development while retaining the benefits of a rigorous, robust, design-centric process.


Agile/ICONIX-EPF builds on the widely used "use case driven" ICONIX Process, and takes full advantage of the latest “agile extensions” to the process, including automated tool support for automatic generation of unit test stubs from design diagrams, and for keeping UML models and Java code in-synch over the lifetime of an Eclipse project.


What is EPF?


The Eclipse Process Framework (EPF), attempts to address the problems that process engineers face every day:


  • Huge, unmanageable processes that must be understood and then scaled down
  • Document-heavy non-graphical process descriptions
  • Inconsistent or poorly designed process documentation
  • Heavyweight, one size fits all methodologies
  • Sequential descriptions of non-sequential processes
  • Non-centralized process documentation that people access or find
  • Shelfware that is never used



EPF is an open source initiative to provide the community with a common root process and the tools to customize the root processes, manage, build, and deploy your own process in a consistent way. Not only is EPF providing the basic process and tools, it's an open source eclipse project and as such, encourages people to contribute their own customization of processes (or so-called best practices).


Process development can now moves from a proprietary tightly controlled activity to a community activity that fosters sharing of best practices using a common communication framework to describe them.


The EPF (see ) has two goals:


To provide an extensible framework and exemplary tools for software process engineering - method and process authoring, library management, configuring and publishing a process.


To provide exemplary and extensible process content for a range of software development and management processes supporting iterative, agile, and incremental development, and applicable to a broad set of development platforms and applications.

- - Reference June 16, 2006 .


These goals translate into a tool for customizing or creating processes and then deploying them in a standardized web-based medium (a la RUP webpages). The tool, called EPF Composer, makes it easy to create policies, processes, guidelines, tool support, and more in a format consistent across the software industry. The EPF also contains simplified basic process derived from RUP call OpenUP, another version based on SCRUM is also planned for the first release.


Why is the EPF Composer important? In a word: standardization. “A good process diagram can replace 20 – 25 pages of text” – Olson “defining short and usable processes” Crosstalk June 2006


The EPF and composer allow the software industry to capture best practices in a consistent way, using a tool which, when EPF is fully fleshed out, will integrate with commercial tools via open interfaces.


EPF is using a standard metamodel based on OMG SPEM to describe best practices, which is a huge leap forward. Now RUP, Iconix, FDD, XP, Scrum, and other processes can be expressed using the same framework.


As a leader in software process training and consulting, ICONIX (led by the efforts of Dr. Suscheck) has undertaken the task of expressing our streamlined, minimalist but rigorous process through the EPF. The results of this work are described in the remainder of this paper.




ICONIX Process, a minimalist yet rigorous approach that uses a UML core subset and reliably avoids analysis paralysis, has been in widespread use in industry for more than a decade, and is defined in several books, most recently Use Case Driven Object Modeling with UML – Theory and Practice (Apress 2007), by Doug Rosenberg and Matt Stephens. In the Theory/Practice book, we define the process in a set of activity diagrams, and provide additional guidance on topics such as use case modeling, domain modeling, and sequence diagramming in the form of Top-10 “to-do” lists. The EPF contains a roadmap of the ICONIX process with drill-down activities and Top-10 “to-do” lists.


In our previous work, Agile Development with ICONIX Process (Apress 2006), we proposed some extensions to the original version of ICONIX Process to better align it with agile development principles (e.g. getting to code quickly, small-increment, short-iteration development, and being more feedback-driven rather than purely plan-driven). These extensions have gained some automated support from tool vendors like Sparx Systems, (including some automated support for generation of unit test stubs, and particularly with the advent of the MDG Integration for Eclipse product, which provides outstanding facilities for keeping UML models and Java code in-synch over the lifespan of a project). These agile extensions are fully reflected in the ICONIX Process Roadmap, and further extensions in the testing arena are currently being contemplated.


How to use Agile/ICONIX-EPF


The Agile/ICONIX-EPF implementation is located on the ICONIX website as a zip file, and can be downloaded


Once you download the file, simply unzip the package and you will have a series of web pages that you can browse.

An individual or organization may incorporate all or part of the ICONIX process in their process /methodology for their internal use if they clearly delineate in all their textual and diagrammatic representations of their process /methodology exactly which portions of  it are incorporated from the ICONIX process and identify ICONIX by spelling our company name with all upper case letters as we do "ICONIX" and by giving a link to our web site    This no-charge permission for internal use specifically includes all or part of the available diagrammatic descriptions of the ICONIX process, including the ICONIX Process Road Map.

An individual or organization may NOT without separate and specific written permission from ICONIX incorporate all or  any part (s) of the ICONIX process in any process /methodology they develop for the use of other individual(s) or organization(s) and may NOT without separate and specific written permission from ICONIX incorporate all or any part(s) of the ICONIX process in any product(s) or work product(s) that they deliver, sell or give to anyone outside their organization in textual and/or in diagrammatic form.


Your directory structure should look something like Figure 1 , and will include an index.htm file.


Figure 1 Directory structure of Agile/ICONIX - EPF


Double clicking on the index.htm file will bring up your browser and point you to the ICONIX Process Roadmap ( Figure 2 ). For the purpose of this example we will use internet explorer.



Figure 2 Intial Agile/ICONIX - EPF view



The “Roadmap for the Iconix Process” will expand to show a picture of the roadmap. The “Initial Overview” folder in the left hand corner will open to the roadmap also. The “Top 10 Lists” will open to a browser that allows you to jump to a specific top 10 item. See Figure 3 .



Figure 3 Top 10 Lists in Browser Tree


Start with clicking the “roadmap for the Iconix Process”. The body of the browser will show the roadmap. You'll have to scroll around to see of the of roadmap but the following figure gives you an idea of what you'll view. The diagram consists of top level activities: “Requirements Analysis” “Analysis and Preliminary Design” “Detailed Design” “Implementation”



Figure 4 Top Level ICONIX Process Activity Diagram lets you drill deeper into the process



Opening the top level activity diagram gives you the option to “drill-down” by lifecycle phase, or to view the Top 10 lists.


For example, double-clicking on the “Requirements Analysis” lifecycle phase opens this detailed activity diagram ( Figure 5 ), which details an easy-to-follow sequence of steps for defining a domain model, a use case model, and for allocating functional requirements to your use cases.



Figure 5 Requirements Analysis Activity Diagram


Similarly, clicking on “Detailed Design” results in a detailed activity diagram ( Figure 6 ) for driving an object-oriented design from your use cases using sequence diagrams. This includes automatic generation of skeleton sequence diagrams (and test cases) using the “Agile/ICONIX Add-In” which can be found on the Enterprise Architect for Power Users multimedia tutorial.




Figure 6 Activity Diagram for Detailed Design




In addition to the detailed activity diagrams, you can also drill-down to view Top-10 guidance on any modeling activity. For example, Figure 7 shows the Top 10 Domain Modeling guidelines.



Figure 7 Top 10 list for Domain Modeling


The EPF contains 11 top 10 checklists, 4 top level activities, and detailed activity diagrams for each of the top level activities. Additionally the EPF contains a variety of ways to view the information, search capabilities, the ability to print the information, and an index. See Figure 8 and Figure 9 .



Figure 8 EPF Utilities



Figure 9 EPF built in view capabilities




If you're looking for a minimalist, lightweight, agile UML process , we hope you'll find that the availability of the ICONIX Process Roadmap in EPF will help everyone on your team to stay on the same page with your development effort.



© ICONIX Software Engineering, Inc. 2016
11301 W Olympic Blvd., Suite 559, Los Angeles, CA 90064
Tel (310) 474-8482