- 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. For instance, EPF provides the OpenUP/Basic, an agile software development process optimized for small projects.
How does it work ?Edit
By using EPF Composer you can create your own Software development process by structuring it in one specific way using a predefined schema. This schema is an evolution of the SPEM 1.1 OMG specification referred to as the Unified Method Architecture (UMA). Major parts of UMA went into the recently adopted revision of SPEM, SPEM 2.014. EPF is aiming to fully support the final SPEM 2.0 in the near future. The UMA and SPEM schemata support the organization of large amounts of descriptions for development methods and processes. Such method content and processes do not have to be limited to software engineering, but can also cover other design and engineering disciplines, such as mechanical engineering, business transformation, sales cycles, and so on.
Issues to ResolveEdit
The tool is now relatively mature (except for some usability issues, typical of open source projects sans human factors) but the generation of open sourced process plug-ins remains problematic as adoption of the tool still requires substantial work in process authoring. The cost of process authoring is the major component of the true-cost-of-ownership of process assets, that and the training costs. Many key organizations already have key process assets drafted in navigable html or pdf that, and because of their maturity, would not see an return on investment - moving to EPF - even where the tool is 'free'. One notable example is the V-Modell.
IBM has some proprietary plug-ins available for its Rational Method Composer but they are based upon the proprietary RUP process model. The small open source agile models available don't scale well to large programs. Many IEEE/ISO/SAE/CMMI and other standards models have not been modeled. The potential here is vast if IBM markets EPF/RMC to the standards organizations who already sell representations of their standards.
Static page generation is useful, as a reference site, but additional effort has to occur 1) to move towards process orchestration (based upon SPEM models) and 2) provision of training resources (potentially by including SCORM/IMS modes for export). Process training, within organizations, is of paramount concern and the amount of rework to push EPF output into SCORM/IMS ready structures for presentation in an eLearning environments (on top of the initial process authoring effort) is prohibitive. Model transformation technology may help here.
The usability concerns wont be addressed until there is large scale adoption of the approach and interoperability issues around plug-ins drive the design to its optimum. The proposal is that process orchestration support (Wilos etc) and interoperability with elearning standards (to support migration of process data into training domain) would/might accelerate adoption.