Business modeling in process-oriented organizations for RUP-based software development

Several organizations are nowadays not particularly comfortable with their internal structuring based on a hierarchical arrangement (sub-divided in departments), where collaborators with a limited view of the overall organization perform their activities. Those organizations recognize the need to move to a model where multi-skilled teams run horizontal business processes that cross the organization, and impact suppliers and clients. To develop software systems for any organization, the development process must always be appropriate and controlled. Additionally for organizations who want to migrate to a horizontal business processes view, it is required to model the organizational platform where the organizational processes will run. This necessity is also true when the organization under consideration is a software house. In this chapter, a proposal of a generic framework for process-oriented software houses is presented. The way of managing the process model and the instantiation of their processes with the Rational Unified Process (RUP) disciplines, whenever they are available, or with other kind of processes is recommended as a way to control and define the software development process. To illustrate the usefulness of the proposal, it is presented how the generic reference framework was executed in a real project called “Premium Wage” and shown, in some detail, the created artifacts (which include several UML models) during the development phases following the RUP disciplines, especially the artifacts produced for business modeling.(undefined

Process Management in Practice - Applying the FUNSOFT Net Approach to Large-Scale Processes

Abstract. Management of business and software processes are areas of increasing interest, which evolved nearly independently from each other. In this article we present an approach to process management that has been applied to business and software processes and which, thereby, enabled cross-fertilization between both areas. The goal of this article is to report lessons learned in industrial as well as academic business and software process management projects

Semantics and Verification of UML Activity Diagrams for Workflow Modelling

This thesis defines a formal semantics for UML activity diagrams that is suitable for workflow modelling. The semantics allows verification of functional requirements using model checking. Since a workflow specification prescribes how a workflow system behaves, the semantics is defined and motivated in terms of workflow systems. As workflow systems are reactive and coordinate activities, the defined semantics reflects these aspects. In fact, two formal semantics are defined, which are completely different. Both semantics are defined directly in terms of activity diagrams and not by a mapping of activity diagrams to some existing formal notation. The requirements-level semantics, based on the Statemate semantics of statecharts, assumes that workflow systems are infinitely fast w.r.t. their environment and react immediately to input events (this assumption is called the perfect synchrony hypothesis). The implementation-level semantics, based on the UML semantics of statecharts, does not make this assumption. Due to the perfect synchrony hypothesis, the requirements-level semantics is unrealistic, but easy to use for verification. On the other hand, the implementation-level semantics is realistic, but difficult to use for verification. A class of activity diagrams and a class of functional requirements is identified for which the outcome of the verification does not depend upon the particular semantics being used, i.e., both semantics give the same result. For such activity diagrams and such functional requirements, the requirements-level semantics is as realistic as the implementation-level semantics, even though the requirements-level semantics makes the perfect synchrony hypothesis. The requirements-level semantics has been implemented in a verification tool. The tool interfaces with a model checker by translating an activity diagram into an input for a model checker according to the requirements-level semantics. The model checker checks the desired functional requirement against the input model. If the model checker returns a counterexample, the tool translates this counterexample back into the activity diagram by highlighting a path corresponding to the counterexample. The tool supports verification of workflow models that have event-driven behaviour, data, real time, and loops. Only model checkers supporting strong fairness model checking turn out to be useful. The feasibility of the approach is demonstrated by using the tool to verify some real-life workflow models