Logo en.artbmxmagazine.com

Idef an alternative for business modeling with rup

Table of contents:

Anonim

Summary

Many software development projects fail or the end result is not what was expected, for the customer or end user, or for the developers themselves. For the customer, a software development project may be unsuccessful because it took longer than expected or worse, because the resulting software does not solve the problems for which it was commissioned.

There are several factors that can lead to the failure of a software development project. Business modeling in the conception stage of a software development project is one of the most important activities, and that many times it is not carried out with the necessary depth, causing this that there is not a full understanding of the processes involved. computerization and a false sense of understanding between customers (or users) and the development team regarding the work to be done.

The Business Modeling discipline of RUP (Rational Unified Process) proposes a set of artifacts to model the processes of an organization, the development of all these artifacts can be slow and cumbersome, contributing negatively to an effective passage through this discipline. The present work proposes an alternative to the artifacts of the Business Modeling discipline of the RUP methodology: IDEF, it is a system modeling technique using a specific graphic structure. It ranges from information modeling to object-oriented analysis and design.

Keywords

IDEF, Business Process, Business Modeling, Software Development, RUP

Introduction

Despite the importance of knowledge of the business processes that will support a computer system, it is common practice to demerit the stage at which this information is captured during the development cycle of a software. Development teams, based on customer demands for how quickly they need to get the software product up and running, typically devote little attention to a full understanding of the business. If it is taken into account that the vast majority of organizations do not represent schematically what their processes are like and that some of the most used software development methodologies, such as the Unified Development Process (RUP, for its acronym in English),propose a large number of artifacts for this modeling whose construction can become slow and cumbersome, then all the conditions are created so that the business is not modeled with the rigor it deserves.

The result of this practice are software products focused on the needs or requirements raised by a client, who is sometimes not able to determine exactly how a software system can improve its line of products or services. In addition, it is common for software products to be obtained with extremely high implementation costs and far from the objective reality of the entity that intends to use it. Developers tend to be creative seeking their professional fulfillment in creating ideal computer systems, while distancing themselves from the reality of business and customers.

The technological capacity and the economic situation of the organization to be automated are not the fundamental objective of the business modeling proposed by RUP. However, taking these elements into account, trying to influence them favorably, if it should be the objective of the software product to be made, hence, during this initial stage it is considered extremely important that the development team appropriate this additional knowledge.

This article proposes the integration of some IDEF techniques (Integrated Definition Methods) with the RUP methodology, with the aim of using these techniques as an alternative to the artifacts proposed by the Business Modeling discipline of this methodology. It is necessary to point out that the information presented on the IDEF modeling techniques is not enough to apply the ideas presented here, later it will be necessary to study them in depth. This proposal is based on the experience of the authors during the production of custom software for the Bolivarian Republic of Venezuela, product of the Cuba-Venezuela agreements in the light of ALBA.

Development

IDEF

During the 1970s, US air forces developed a program for Integrated Computer Aided Manufacturing (ICAM). The ICAM program identified the needs for improvements in communication techniques and analysis for personnel involved in production. The result of the ICAM project is a series of techniques known as IDEF (Integrated Definition Methods). The initial conception included:

  1. IDEF0: Used to represent activities or processes IDEF1: Used as a model for the representation and structuring of information IDEF2: Used to represent models that vary over time.

In 1983, the United States Air Force programmed an integrated information support system based on IDEF1, creating the IDEF1X (expanded IDEF1).

As the years passed and the use of these techniques, IDEF continued its development and new versions appeared: IDEF3, IDEF4 and IDEF5. Currently there are several tools that facilitate modeling with these techniques.

IDEF0

IDEF0 is a modeling technique conceived to represent in a structured and hierarchical way the activities that make up a system or company, and the objects or data that support the interaction of those activities. An IDEF0 model is made up of a hierarchical series of diagrams that allow, through levels of detail, to describe the functions specified at the top level. In the top views of the model, the interaction between the activities represented allows to visualize the fundamental processes that sustain the organization. The graphic elements used for the construction of the IDEF0 diagrams are tables and arrows.

The semantics of use of these graphic elements is the following:

Activity: represented by a box, indicates a function, process or transformation.

Entry: represented by an arrow entering from the left side of the activity, it indicates the materials or information that will be transformed into the activity to obtain the exit.

Output: it is represented by an arrow coming out of the right side of the activity, it indicates the objects or information produced by the occurrence of the activity.

Control: represented by an arrow entering from the top, it indicates the regulations that determine whether an activity is carried out or not. Eg: standards, guides, rules, policies, etc.

Subject: represented by an arrow entering from the bottom, it indicates the resources that execute an activity. Eg: people, machinery, etc.

Advantages of IDEF0 for modeling business processes

  • It allows to represent the process chronologically. The end-customer-oriented flow of that business is described, crossing all the activities of the organization that fulfill the request for a product or service made by the customer, thus representing the company's "value chain" (a process is modeled for each type of product or service that the company provides) It is a simple notation (based on boxes and arrows) that any employee can use to describe what they do in the business. Involving the employees of the organization in the modeling of the business saves time by simultaneously working in several areas, as well as obtaining a more faithful model since it has been developed by its protagonists. It allows incorporating in the flow the data that enters and leaves the activities, as well as the business rules and the actors,all in the same view. It allows to decompose an activity as a process in turn. It allows to discover organizational problems in the business that must be fixed, in order to "not computerize the chaos" but to organize the business and then computerize it.

IDEF3

IDEF3 is a modeling technique to represent the workflow of a process, as well as its participating objects from the description given by an expert. It allows documenting a process at a detailed level, facilitating its analysis through the identification and capture of critical knowledge of it.

The fundamental components used by IDEF3 in its representation are: unit of work, links, connections and references.

Unit of Work: represents an activity, it always has a unique identifier and can have a reference associated with an IDEF0 activity.

Leagues: represent restrictive relationships between activities, are unidirectional, can start and end in any part of the activity ("box"), must be labeled.

There are three types of leagues:

Temporal precedence

The source process must shut down before the target process can start.

Object flow

It emphasizes the participation of an object between two processes, indicating temporal precedence, the source process must terminate before the destination process can terminate.

Relational

Existence of a relationship between the linked processes. The source process will start before the target process ends.

Connections: they serve to represent:

  • The points at which a process branches into multiple threads. The points at which multiple processes converge into a single process. ŸThe temporality (synchrony / asynchrony) in the flow of activities of a process.

Types of branches:

Divergence (Fan-out): Distributes the flow of the process, the termination of an activity causes the activation of multiple activities.

  • Convergence (Fan-in): The completion of multiple activities consolidates the start of an activity.

References: represent special symbols to direct the reader's attention to other important parts of the model.

Some of the different types of references that exist are:

  • Object: Describes the participation of an important object in an activity GOTO: Constructs cycles (repeat sequence of activities) UOB (UnitOfBehavior): Includes an activity already described without involving a cycle Note: Documents any important general information from any graph (activity, connection) ELAB (Elaboration): Document in detail some graph.

Advantages of IDEF3

  • It allows to document processes for standardization or as guides for new members of the process and thus reduce the learning curve. It provides a mechanism to capture the time sequence of a process and the decision logic that affects it. It serves as a tool to analyze existing processes. It allows you to design and test new processes before initiating actual changes that can be very expensive.

A simple comparison between both techniques makes it possible to illustrate how they complement each other, impacting differently on the same aspects, which allows them to be addressed in their entirety.

IDEF in the RUP methodology to model the business

Description of activities

Model Global Processes:

  • Involved: Clients and Development Team Objective: Identify the organization's business processes, its objectives, resources involved, etc. Technique: IDEF0 Description: In this activity, the organization's business processes are identified through meetings with the managers and workers involved. The graphic elements that make up the IDEF0 technique are explained to all managers and workers involved and the Process Model corresponding to the AS - IS of this technique is jointly developed. The AS - IS is nothing more than the modeling of how the processes of the organization occur in a global way in its current situation.

Identify Superfluous Activities:

  • Involved: Development Team Objective: Identify superfluous activities that may exist in the organization's processes Technique: Analysis Description: In this activity the Process Model carried out by the organization is analyzed to identify activities that may be considered superfluous. A superfluous activity is one that can be dispensed with without affecting the final result of the modeled process, either because it does not generate any result or because the result obtained can be part of another activity, thus eliminating a subject from the process.

Model Enhanced Global Processes:

  • Involved: Development Team Objective: Update the Process Model with the identified improvements Technique: IDEF0 Description: In this activity the Process Model carried out by the organization is updated, eliminating the identified superfluous activities. A brief description of how each activity is carried out is added to the model. At this point, the changes that imply a proposal for improvement in the processes are made in the model. These changes should be based on the study of the art carried out prior to the business modeling stage, by the development team on similar business processes at the national and international level. This new model corresponds to the IDEF0 TO - BE Process Model.

Validate Proposed Improvements with the Client:

  • Involved: Clients and Development Team Objective: Establish an agreement between clients and the development team about how the organization's processes should be, before moving to computerization Technique: Meeting Description: In this activity the team The development team presents the Enhanced Global Processes Model to the client, so that they can indicate their agreement with the proposal or make the pertinent observations.

Detail Complex Activities:

  • Involved: Development Team Objective: Model in detail the activities of greater complexity, necessary for the automation of the organization Technique: IDEF3 Description: In this activity the Process Model carried out by the organization is updated, eliminating the identified superfluous activities. At this point, other changes can be made in the model that imply a proposal to improve the customer's processes. These proposals for additional improvements should be based on the art study carried out by the development team on similar processes at the national and international level, prior to the business modeling stage.

Validate Detailed Description with the Client:

  • Involved: Clients and Development Team Objective: Establish an agreement between clients and the development team about how the complex activities of the organization that must be automated are carried out in detail Technique: Meeting Description: In this activity the team of development presents the detailed description of the complex activities selected to the client, so that he indicates his agreement with the proposal or makes the pertinent indications.

Establish Project Boundaries:

  • Involved: Clients and Development Team Objective: Establish an agreement between clients and the development team about which processes of the organization will be computerized Technique: Meeting Description: This activity is defined by means of a discussion between clients and the development team what will be the processes to be computerized. For this, the Improved Global Processes Model is taken as a basis.

References

Álvarez Romero, Eduardo; Pueyo, Daniel. Integration Definition For Function Modeling (IDEF0) taken from

García, Ana M. Business process modeling. Course notes.

Process Modeling, Systems Theory, Universidad de Valparaíso taken from

Bibliography

IDEFØ IDEF Family of Methods A Structure Approach to Enterprise Modeling and Analysis

Idef an alternative for business modeling with rup