However I don't think this is the key point about agile
methods. Lack of documentation is a symptom of two much deeper
differences:
Agile methods are adaptive rather than predictive.
Engineering methods tend to try to plan out a large part of the software
process in great detail for a long span of time, this works well until
things change. So their nature is to resist change. The agile methods,
however, welcome change. They try to be processes that adapt and
thrive on change, even to the point of changing themselves.
Agile methods are people-oriented rather than
process-oriented. The goal of engineering methods is to define a
process that will work well whoever happens to be using it. Agile
methods assert that no process will ever make up the skill of the
development team, so the role of a process is to support the
development team in their work.In the following sections I'll explore these differences in
more detail, so that you can understand what an adaptive and
people-centered process is like, its benefits and drawbacks, and
whether it's something you should use: either as a developer or
customer of software.
It strikes me that many companies who think they have either a unique process or a lot of process variations actually do not - they have a standard set of activities that must be assembled dynamically based on the circumstances, customer etc. This leads to a rules-first approach to defining the process and much simpler processes. This is particularly useful when you start considering case management processes where using the rules to determine what state the case has reached and what, therefore, is the right next step is a clearly better approach.
OpenLexicon is an open-source business rules and process management tool that rapidly develops applications for transaction and process-based applications. OpenLexicon is known for providing high performance solutions and has been used in a number of enterprise-level applications. You can read about these here . You can use either product separately or in concert. There are two main components of OpenLexicon: the metadata repository and the business rules engine. Major components of OpenLexicon are released as open source software under the OpenLexicon OpenSource License. A good overview of the business rules approach is available here .OpenLexicon has a Wizard that is a web-form based collaborative tool for building business rules and business use cases. For a brief overview of the wizard, look at this link . We have designed the Wizard for non-developers and analysts with light technical skills. It features a richer experience for the users on the web, traditionally only offered by thick-client UIs. The collaboration team assembles groups of business rules into a business use case and published in a metadata file or the database. OpenLexicon provides solid support for web services. You can read about the OpenLexicon WSDL here . There is also an eclipse plug-in for web services here . You create complex application behavior with OpenLexicon’s process management. OpenLexicon can build an application reads data from a file, performs reference data lookups, validates the entire object, and then stores it in a database table. You can read about this here . Plus, you can build the application in the Wizard while writing no code! OpenLexicon also supports web services. A simple architecture diagram for OpenLexicon is included here .
In diesem Buch werden alle relevanten modernen Standards der Geschäftsprozessanalyse und -modellierung miteinander verbunden und ihre praktische Handhabung dargestellt.
Kern des Buches ist eine Geschäftsprozess-Methodik, die die verschiedenen Standards in praxisrelevanter und harmonischer Weise verbindet. Sie erfahren, welche Standards es gibt, wofür und wie diese eingesetzt werden können und welche Möglichkeiten aber auch möglichen Einschränkungen in der Praxis damit verbunden sind. Basis sind die BPMN (Business Process Modeling Notation), OSM (...), BMM (...), SBVR (..) und UML (...) - wobei diese Standards zielgerichtet nur soweit behandelt werden, wie es für die Auseinandersetzung mit Geschäftsprozessen notwendig ist.
Sie erfahren wie Strategien, Geschäftsregeln und Geschäftsprozesse dargestellt werden können und welche Strukturierungsmöglichkeiten es für Unternehmensarchitekten es gibt.
Das Buch richtet sich an Business-Analysten, Prozessdesigner, Betriebsorganisatoren und verwandte Rollen.
M. zur Muehlen, M. Indulska, and G. Kamp. EDOCW '07: Proceedings of the 2007 Eleventh International IEEE EDOC Conference Workshop, page 189--196. Washington, DC, USA, IEEE Computer Society, (2007)
M. zur Muehlen, M. Indulska, and G. Kamp. ER '07: Tutorials, posters, panels and industrial contributions at the 26th international conference on Conceptual modeling, page 127--132. Darlinghurst, Australia, Australia, Australian Computer Society, Inc., (2007)
C. Wild, K. Maly, C. Zhang, C. Roberts, D. Rosca, and T. Taylor. TENCON '94. IEEE Region 10's Ninth Annual International Conference. Theme: Frontiers of Computer Technology. Proceedings of 1994, (August 1994)
O. Marjanovic. HICSS '07: Proceedings of the 40th Annual Hawaii International Conference on System Sciences, page 215c. Washington, DC, USA, IEEE Computer Society, (2007)