Business Process Benchmarking - e-Journal of Practical Business

Transcrição

e-Journal of Practical Business Research
Business Process Benchmarking –
Band II Gesamtkonzeption:
BPB-Tool-Entwicklung
Christian Nagel, David Jäck
& Jörg Puchan
[email protected]
Erschienen im e-Journal of Practical Business Research
unter: http://www.e-journal-of-pbr.info
Dieser Teil des zweiten Sammelbandes beschäftigt sich mit der Erstellung und
Entwicklung von Anforderungen für eine passende Benchmarking-Software. Basis
dieser Entwicklung sind die Analyse des Status Quo existierender Software, welche
eventuell verwendet oder ausgebaut werden soll sowie die Anforderungen aus den
Teilprojekten. Ebenfalls wurde die am Markt befindliche Software analysiert und ein
Status-Quo zu diesem Thema erstellt.
Ziel der Arbeit ist es, einen Prototypen oder gar ein fertiges, kommerziell nutzbares
Programm zu erstellen, welches die Teilprojekte in ihrer Arbeit unterstützt, als auch die
Inhalte und Ergebnisse der Teilprojekte verinnerlicht hat und ebenfalls auch anwendet.
Der Fokus dabei liegt auf der Vorgehensweise nach der Benchmarking Method Munich
und dem Reference Process Model Munich, welche eigens für das Benchmarking, durch
das Forschungsprojekt, entwickelt wurden.
Die Ausarbeitung basiert auf Auswertungen von Fachliteratur, sowie die Befragung der
Modulteilnehmer, als auch weiteren Projektpartnern.
Zitation: Nagel, Christian; Jäck, David & Puchan, Jörg (2012): BPB-Tool-Entwicklung.
In: e-Journal of Practical Business Research, Sonderausgabe: Business Process
Benchmarking – Band II Gesamtkonzeption (Hrsg. Puchan) (07/2012), DOI:
10.3206/0000000052
Business Process Benchmarking –
Band II Gesamtkonzeption:
BPB-Tool-Entwicklung
Projekt Business Process Benchmarking (BPB)
Forschungs- und Entwicklungsprojekt
der Fakultät für Wirtschaftsingenieurwesen
Hochschule für angewandte Wissenschaften München
Wiss. Leitung:
Prof. Dr. Jörg Puchan
Thomas Gann, M. Eng.
Autoren:
Christian Nagel, David Jäck & Jörg Puchan
17.12.2012
Business Process Benchmarking – Band II Gesamtkonzeption: BPB-Tool-Entwicklung
Kurzfassung
Die vorliegende Arbeit beschäftigt sich, auf Grundlage des Forschungsprojektes
der Hochschule München im Themenbereich Business Process Benchmarking, mit
der Erstellung und Entwicklung von Anforderungen für eine passende
Benchmarking-Software. Basis dieser Entwicklung sind die Analyse des Status
Quo existierender Software, welche eventuell verwendet oder ausgebaut werden
soll sowie die Anforderungen aus den Teilprojekten. Ebenfalls wurde die am
Markt befindliche Software analysiert und ein Status-Quo zu diesem Thema
erstellt.
Ziel der Arbeit ist es, einen Prototypen oder gar ein fertiges, kommerziell
nutzbares Programm zu erstellen, welches die Teilprojekte in ihrer Arbeit
unterstützt, als auch die Inhalte und Ergebnisse der Teilprojekte verinnerlicht hat
und ebenfalls auch anwendet. Der Fokus dabei liegt auf der Vorgehensweise nach
der Benchmarking Method Munich und dem Reference Process Model Munich,
welche eigens für das Benchmarking, durch das Forschungsprojekt, entwickelt
wurden.
Die Ausarbeitung basiert auf Auswertungen von Fachliteratur, sowie die
Befragung der Modulteilnehmer, als auch weiteren Projektpartnern.
Projekt BPB; Nagel, Jäck, Puchan
Seite I
Index of Content
Kurzfassung .................................................................................................................. I Index of Content .......................................................................................................... II Abbildungsverzeichnis ............................................................................................... III List of Abbreviations...................................................................................................IV 1 Introduction, Motivation and Purpose............................................................ 1 2 Status Quo......................................................................................................... 2 2.1 Status Quo of Software Environment..........................................................................2 2.2 Process Metadata Model Munich..................................................................................4 3 Requirements Engineering............................................................................... 7 3.1 Procedure / Process Model...............................................................................................7 3.2 Stakeholder Analysis ..........................................................................................................7 3.3 Objectives Analysis .............................................................................................................7 3.4 3.4.1 3.4.2 3.4.3 3.4.4 Requirements Engineering Activities and Development ......................................8 Requirements Elicitation ..................................................................................................8 Requirements Analysis, Specification and Validation......................................... 13 Quality Requirements Management......................................................................... 15 Requirements Risk Management ............................................................................... 16 4 System Design and Technical Concept ..........................................................20 4.1 Technology Evaluation ................................................................................................... 20 4.2 4.2.1 4.2.2 4.2.3 Object-Oriented Analysis............................................................................................... 21 Mockups .............................................................................................................................. 21 System Analysis ................................................................................................................ 22 Documentation................................................................................................................. 23 5 Future Prospects and Conclusion / Discussion..............................................24 Literaturverzeichnis.....................................................................................................V Projekt BPB; Nagel, Jäck, Puchan
Seite II
Abbildungsverzeichnis
Figure 2-1: Process Metadata Model - PM³ .............................................................................5 Figure 3-1: Idealized Approach for refining requirements ................................................8 Figure 3-2: Complete requirement template with conditions.........................................9 Figure 3-3 : Notation elements of use cases........................................................................ 10 Figure 3-4: Notation relations and associations of use cases........................................ 11 Figure 3-5: Software systems and functions ....................................................................... 12 Figure 3-6: Kano model ............................................................................................................... 13 Figure 4-1: Mock-ups ................................................................................................................... 22 Figure 4-2: Example of an instance of a class in the PM³ ................................................ 23 Projekt BPB; Nagel, Jäck, Puchan
Seite III
List of Abbreviations
API
Application Programming Interface
BM²
Benchmarking Method Munich
BPB
Business Process Benchmarking
BPM
Business Process Management
BPMS
Business Process Management System
ERM
Entity-Relationship-Model
PM³
Process Metadata Model Munich
RE
Requirements Engineering
RPM²
Reference Process Model Munich
UML
Unified Modeling Language
Seite IV
1
Introduction, Motivation and Purpose
According to the definition and understanding of the research project Business
Process Benchmarking (BPB), Business Process Management (BPM) is a
management tool or procedure, based on processes in order to (re)structure,
model, organize or optimize enterprises or organizations. Benchmarking is
understood as a collective term for methods to measure and compare anything
towards an outstanding objective or target value. (Puchan, Gann, Konrad, Seifert,
Nagel & Jäck, 2012)
Schmieder (2011, pp. 6, 7) says in his benchmarking study that in the past the
focus was on material, process and human resources. But for the future he came
to the conclusion that process efficiency will be more in the focus than any other
part and that direct functions of the value chain will be considered.
In order to perform a benchmark, to measure or compare data, it is necessary that
this data is detectable and comparable. But like Doane and Brooks (2005) unveil in
their article: “finding key information about other companies can seem like
searching for the proverbial needle in the haystack.” They also say that most
information is kept in different types or formats (e.g. html-, pdf-, excel-files and so
on) and that there exists no common sense, type or language about how
information should be standardized as well as out of this the exchange of data
can be a problem. They go on and mention that companies might hesitate to
publish information about their own company due to the fact that it might be
used against them. The meaning of this leads to the reason of this elaboration,
namely to find or develop software which is able to compare data of different
companies without showing the participating companies data of others.
One of the aims of this elaboration is the fact that the method should be
adaptable for a large number of companies in the short as well as the long term.
In order to manage the number of information generated out of comparison
within a company or in combination with other partners, it is necessary to search
for or built up a software which is able to cope with this task as well as with the
problem Doane and Brooks revealed. To go into detail, the objective of this
elaboration is to develop, analyze and provide a tool (quality- and risk-oriented)
for (multi-client capable) documentation, visualization and diagnosis of data as
well as the processing of defined key figures.
Seite 1/25
2
Status Quo
2.1
Status Quo of Software Environment
The following paragraph shows the status quo of business management tools or
software which are used related to the topic of BPM as well as a critical reflection
of them. In order not to perform an own research about BPM systems already
existent comparisons and surveys of BPMS were searched and analyzed.
Therefore, the following research works were chosen: the Gartner research note
(Sinur & Hill, 2010), a research of Forrester (Richardson, Moore, Le Clair, & Vitti,
2010), especially for the German market, the research of the Fraunhofer IAO
(Drawehn, Kicherer, Kopperger & Zähringer, 2008). For the continuation of the
elaboration the focus will lie on the Gartner research note and the Forrester
Wave™.
To meet all various needs different sectors and clients could have, the tools are
available in several sizes, compositions and from many vendors. Most of these
software programs consist of several management tools as well as usage
scenarios (cf. Sinur & Hill, 2010, p. 1). According to the Gartner research note
(ibid.), the most important usage scenarios1 for investing into a BPMS are:
•
Support for continuous process improvement program
•
Implementation of an industry-specific or company-specific
process solution
•
Support for a business transformation initiative
•
Support for a process-based, service-oriented-architecture (SOA)
redesign (p. 1)
As the usage scenarios demonstrate and also other authors agree on, the
advantages of such BPMS are obvious. For Smith and Fingar (2007, p. 233)
companies will have a positive impact by adding a BPMS to their existing systems.
They will improve the management and control of their business processes and
therefore reach the business objectives much faster.
The advantage of the Reference Process Model Munich (RPM²) as a process model
is, that it is generic and adaptable to all kind of company process and even the
other way round. All different company process models are able to be integrated
in the RPM² and all company processes are detectable in the RPM². The future
1
These scenarios are clearly represented in the Gartner Research note (Sinur & Hill, 2010, p. 4) and
are not explained in more detail in this elaboration.
Seite 2/25
software or function, besides others, has to meet the requirements already shown
in the Gartner report. Two requirements which are amongst others important for
the buyers of
BPMS are cross-boundary coordination and interaction
management. The cross-boundary coordination means to achieve better
coordination that crosses multiple boundaries (organizational, international,
facility and so forth). The interaction management, for example, stands for the
support of technology in unstructured domains such as service industries (cf. ibid.,
pp. 5, 6).
Another advantage, according to Sinur and Hill (2010), is, that a shared language
among business professionals and IT professionals simplifies the communication
and “improves understanding and direct access […] to manipulate the assets” (p. 4).
They also say that “BPMS will have to assist in discovering better practices, and
guiding workers into more effective behaviors and desirable outcomes” (p. 4).
Critical reflection
Since the Gartner Magic Quadrant (Sinur & Hill, 2010) shows the market leaders
of BPMS, the elaboration also reveals hints of improvement or as the authors call
it: ‘cautions’ of each software.
The Gartner Magic Quadrant by itself shows some cautions or even crucial points.
Since there are many different vendors of BPMS, the authors were not able to
represent all of the vendors in the Magic Quadrant. This leads to the point that
there are many different ways of how to create, design and develop a BPMS. The
advantage of one vendor might be a disadvantage of another vendor.
With the purpose of showing the reader that there are more vendors available
who might better fit to the clients’ needs some of them are listed but are not part
of the Magic Quadrant. The authors even admit that the listed (or maybe also not
listed) vendors might match better to the process management requirements of
the client (ibid., pp. 7f.).
Because of the Gartner research note and the Forrester research reveal that many
BPMS vendors and even different BPMS within one vendor, it is important to not
only stick to one special vendor in order to create and develop software or a tool
for the benchmarking research project. A software which will be useful for a huge
kind of different BPMS will be much more effective than only for one vendor. The
advantage of this will be a broader range of clients and users and with this will
come more data, which will lead to better, more useful and more precise
statements about benchmarking.
Seite 3/25
2.2
Process Metadata Model Munich
In this segment, the first draft of a process metadata model is introduced, and it is
developed in this elaboration for the abstraction of business processes.
Due to the complexity of processes, especially for the business process
understanding in software, a holistic process metadata model is necessary.
Therefore, the Process Metadata Model Munich (PM³) is drafted based on the
results of the BPB project.
As already defined within the documentation and publication of the research
project the process metadata is the description of semantic properties of a
process (cf. Puchan et al., 2012, pp. 19f.).
Gadatsch (2010) says that ”models are used to analyze and design real-world
systems. They form an original object or system into a model system” (p. 72). A
model reflects the structure and behavior of an object system as faithfully as
possible. There are special requirements that are expected for their illustration.
Therefore, the formal specification of model systems allows it to accomplish the
meta-modeling (cf. ibid.).
A meta-model represents a whole class of model systems; each class element
represents an instance of the meta-model. It provides notation rules, which are
required for developing the model system. It allows the verification of the model
system for completeness and consistency of the objects in the system (cf. ibid., p.
73).
The metadata model is like the Entity-Relationship-Model (ERM) a picture of a
section of reality. Nowadays, ERMs conduct inter alia as a basis for the
development of databases. The representation of relations includes often only
relationships between data, which are processed in a database. The advantage of
the metadata model is thus the possibility of linking data with context
information (for example, the processing component) (cf. Furth, Dittman,
Ortmeier, & Feigenspan, 2008, p. 3).
For the PM³, the following key tasks have been revealed:
•
Mapping of all process components and components that could affect the
process (interfaces – key figures - environment) and their properties at the meta
level
•
A simpler view of the entire complex process through the meta view •
Support for the modeling of scenarios One objective of the PM³ is that it is supposed to be a generic process metamodel, which is universally applicable to all processes that ensure comparability.
Seite 4/25
In addition to that, it is influenced by the developed methods from the BPB
project. The RPM² thereby forms the basis of the metadata model and is extended
by the BM² and the key figure system. Secondly, the PM³ provides the basis for the
object-oriented programming. Based on the meta attributes and classes, Unified
Modeling Language (UML)2 diagrams can be created. The meta-model provides
here a scope for decision-making in the choice of the programming language.
Furthermore, metadata is a big support in case of information retrieval, for
example the search in large databases. Instead of browsing large data sets with
complex full-text search, it is more efficient and easier to understand, by creating
metadata, those are smaller and could be searched much faster. For example in
case of the BPB software, that would be the search for process input and outputs,
based on keywords (cf. Balzert, 2009, pp. 31-33, 83; Gadatsch, 2010, pp. 72f.).
Figure 2-1: Process Metadata Model - PM³
Source: Own representation based on Balzert (2009, pp. 32f.)
Figure 2-1 is a first draft of the PM³, which consists of all estimated elements of a
process of the RPM². It describes roughly all the components (classes) and their
properties (attributes) of a process.
2
Unified Modeling Language (UML) is the most known and standardized general-purpose
modeling language for object-oriented software engineering. UML includes a set of graphic
notation techniques to visualize object-oriented software models (cf. Pohl, 2008, p. 290).
Seite 5/25
Referring to Balzert (2009, pp. 31ff.) and Pohl (2008, pp. 291f.), the first model
level (M0) shows a process (grey box) as a realistic reflection of the reality, which
means a specific process for instance “recruiting of new employees”. The second
model level (M1) is a generic meta level of a process in which the process is
described with its properties. The boxes with the arrows are intended to illustrate
the data modeling approach. The blue boxes represent the classes and include
properties that are known as attributes. The arrows refer to respective subclasses
(light blue) and inherit their properties, resp. attributes to the superclass (dark
blue). The third model level (M2) is the meta meta level and is implemented by
using UML notations to describe the model elements and to create UML diagrams
like the class diagram.
In the second level, the generic meta level (M1), the superclass ‘Process’ is
itemized with its metadata. This superclass contains the essential characteristics
and conditions including their changes of any process. The metadata of the
‘Process’ are listed as attributes in the class. Because of the complexity of a few
attributes, they are referenced to new classes (subclass in light blue). For example,
the superclass ‘Process’ has the attributes ‘Key Figures’, ‘Hard-‘ and ‘Soft-Facts’.
Therefore, a subclass ‘Key Figure’ with the attribute ‘Type’ was instantiated and
inherits the data from their subclass ‘Hard-‘ and ‘Soft-Facts’. This data refers to
any process and is hinted as an attribute in the superclass.
Thus, with a developed metadata model, related to the PM³, the basis for an
operational database is defined. Now it can be deduced which tables, names and
structure the database should have. The idea is, based on the generic view of the
PM³, to enable stable data management and data architecture for the software.
Seite 6/25
3
Requirements Engineering
3.1
Procedure / Process Model
For the project BPB the procedure model of agile software development is
recommended. Not just because the software has to be adaptable to new
perceptions out of the research project and therefore to new requirements out of
the generic approaches, but also due to the reason that the Standish Group
(2012), to name one out of many researchers, discovered in their 2011 CHAOS
Manifesto (even if they do not reveal which and how many projects they have
analyzed) that an agile procedure model has three times the success rate of the
waterfall method. By choosing the agile procedure model, it was not taken into
account which person is going to develop the software in the end. Therefore, it
might be necessary to change the model because the people developing the
software might not feel comfortable by using the agile procedure (cf. Versteegen,
2002).
3.2
Stakeholder Analysis
Since there are many stakeholders involved in the RE process of the benchmarking
software, it is important to first elicit, analyze, and divide these characters into
different groups.
These groups were gathered in a picture, which is available within the project
documentation. This picture shows at this juncture the main stakeholder related
to the development of the software for the BPB project. The group members of
the research project did the elicitation, analysis, and classification in a workshop.
This overview of stakeholders is only a current depiction. For the future of the
project, it is important that the stakeholder analysis will be continued and carried
on in order to involve the right stakeholders at the right time.
3.3
Objectives Analysis
The purpose of the objective analysis is to find the appropriate and important
objectives for the software, which are deducible from the stakeholders, needs. It is
the basis of the requirement elicitation, analysis and validation. Without
objectives, it might be possible that engineers and developers will evolve software
that might not fit to the perception and vision of the client (cf. Rupp &
SOPHISTen, 2007, pp. 86ff.; Ebert, 2012, pp. 49ff.).
Another important aspect for the collection of objectives is to distinguish
between them and the requirements. Requirements represent the way one has to
Seite 7/25
go in order to reach the goal. An objective describes what the output is like, a goal
which should be met, it should be measurable and understandably defined.
The objectives were derived from the main stakeholders, especially from the
description of the research project and the different modules in Puchan et al.
(2012), as well as from conversations with the project partners and out of the
survey. Some additional objectives were added by the authors in order to get fully
integral and satisfying software and were divided into strategic and operative
objectives. These objectives are available within the project documentation.
3.4
Requirements Engineering Activities and Development
3.4.1 Requirements Elicitation
For the elicitation of requirements, it first was necessary to define how
requirements have to look like or how they have to be written. Therefore, all
stakeholders will be able to understand the same by the requirements. The
following idealized approach for refining requirements from stakeholders or
objectives was used:
Stakeholder Objectives
Stakeholder requirements
System requirements
Sub-system requirements
Component requirement
refine /
specify /
derive
refine /
specify /
derive
refine /
specify /
derive
refine /
specify /
derive
Figure 3-1: Idealized Approach for refining requirements
Source: Own representation
Another point of sharing the same requirements is to use a standard approach to
formulate them. Therefore the template based approach of Rupp and SOPHISTen
was used in order to create unambiguous, complete and testable requirements.
One comparative advantage of a template-based approach is a decreasing of
failures due to rules about the formulation of a requirement. Rupp and
SOPHISTen (2007, pp. 228-236) identify a six-step process of how to design
perfect requirements based on templates:
1. Define processes
2. Choose system activity
Seite 8/25
3. Determine legal liability
4. Add objects and additions
5. Prepend conditions and constraints
6. Perform inspection and testing
By doing so they create a template, which is highly useful and supports the
unambiguous comprehensibility of requirements (see Figure 4–3). In this
template and out of the six steps, they divide the system activities into three
types that are mostly relevant for the process (Rupp & SOPHISTen, 2007, p. 229):
•
Autonomous system activity (<process>)
The process is performed autonomous by the system
•
User interaction (provide <whom?> the ability to <process>)
The system provides the user the process functionality
•
Interface requirements
The system runs a process in dependency to one or more other parties (e.g. an
external system) is inherently passive and is waiting for external events.
After defining the system activities, the requirements have to be completed by
legal relevance. To strengthen the liability of the requirements, it is also possible
to prioritize or indicate them with a degree of liability, such as: compulsory,
request, proposal or intention. For a better and comprehensive understanding,
the requirements are commented (cf. Rupp & SOPHISTen, 2007, pp. 231ff.).
The requirements were determined during surveys and interviews with potential
customers, workshops with project members and also the analysis of scientific
literature.
The basic frame of a requirement is build out of these three steps. The other three
steps have to be performed in order to get complete requirements (see chapter
3.4.2).
<process>
SHALL
<When?>
<Under what
conditions>
THE
SOFTWARE
SHOULD
PROVIDE
<whom?> THE
ABILITY TO
<process>
<thing to be
processed>
<process detail>
WILL
BE ABLE TO
<process>
Figure 3-2: Complete requirement template with conditions
Source: Own representation based on Rupp and SOPHISTen (2007, p. 247)
Seite 9/25
Survey / Interview of Stakeholder
In order to get the right requirements, the current partners of the research project
as well as the modules were interviewed in the context of their needs and wishes
about the functionality of the software. Furthermore, an extensible
questionnaire3 was developed for the research project and future project partners
to easily get their needs and wishes and compare them with the existing ones.
Use Cases
A use case describes a sequence of interactions between a system and an external
actor. An actor is a person or user role that interacts with the system. The use case
combines all the possible scenarios that can occur when an actor tries, with the
help of the software, to reach a specific functional objective. It describes contentwise what can happen while trying to achieve objectives, and this can be
abstracted into concrete technical solutions (cf. Wiegers, 2003, p. 133; Pohl, 2008,
pp. 162f.; Ebert, 2012, p. 109).
The aim is to show, preferably simple, what the software system is able to do and
in which cases the application is going to react.
Figure 3-3 and Figure 3-4 show the notation elements that are used to describe
formal use case diagrams. These are necessary to make it understandable for
everyone and to minimize possible misunderstandings during the interpretation
and the software development (cf. Balzert, 2009, pp. 256ff.; Pohl, 2008, pp. 162f.).
Figure 3-3 : Notation elements of use cases
Source: Own representation based on Balzert (2009, pp. 256ff.)
Therefore, Figure 3-4 shows the described notations, which underlie the
developed use case diagrams in the BPB project.
3
The entire questionnaire is available within the project documentation of the BPB project.
Seite 10/25
Figure 3-4: Notation relations and associations of use cases
Source: Own representation based on Balzert (2009, pp. 256ff.)
1. Scenario illustrates the extends arrow, with a dashed line, which is drawn from a use
case X to a use case Y to indicate that the process X is a special case behavior of the
same type as the more general process Y.
2. The uses arrow, with a dashed line, is drawn from a use case X to a use case Y to
indicate that the process of doing X always involves doing Y at least once.
3. Scenario shows a solid line without arrows, which indicates an interaction resp.
communication between use, cases itself and actors.
4. The solid line with an arrow is drawn from a use case Y and / or Z to a use case X to
indicate that the process Y and Z specialize the process X. The use case X inherits
goals of Y and Z or may add more specific goals and steps to achieve process X.
From the restrictions of the actors and systems, the use cases were derived and
their relationship and association with each other were determined. Finally, the
identified requirements were assessed and prioritized according to their
functional necessity for the software4.
4
The fully described use cases are available in the documentation of the BPB project.
Seite 11/25
After a subsequent critical examination and a structured analysis, other actors
and use cases have been identified. Figure 3-5 shows the software overview and
their entire functionality based on the results of the use case workshop.
Front-End
BPB Tool
Dashboard
Data
Management
Report
Management
History
Forecast
Benchmarking
Back-End
Administrative Environment
Admin Environment
Data Management
Error Management
Client Management
Administrative Environment
Data
Management
Report
Management
Client Admin
Area
Test Area
Figure 3-5: Software systems and functions
Source: Own representation
Kano Model
For requirements elicitation, it is crucial to know the significance of the
requirements in order to satisfy its stakeholders (cf. Rupp & SOPHISTen, 2009, p.
81). Dr. Noriaki Kano developed a model to work out which stakeholder
requirements are mandatory, which ones are valuable for money, and which
requirements will delight the stakeholder.
Seite 12/25
Figure 3-6: Kano model
Source: Own representation based on (Rupp & SOPHISTen, 2009, p. 82)
In interviews and at a workshop with industry partners as well as the results from
the questionnaire, the requirements, which are imposed on the software, were
determined in terms of customer satisfaction and the degree of implementation.
The results are implemented in the Kano model shown in Figure 3-6.
3.4.2 Requirements Analysis, Specification and Validation
After the elicitation, the requirements need to be assorted. They are divided into
functional requirements and non-functional requirements. Those again are
distinguished into operational, quality and security requirements as well as
constraints. The requirements were deduced from the documentation of the
research project, conversations with the project partners, objectives of the final
software (chapter 3.3) and inner protocols as well as from presentations and
discussions within the research project. A last validation came from the advisors
and the project members.
Functional Requirements
Since almost 200 different requirements were defined, it goes beyond the scope
of this elaboration to show all requirements. They are written down and were
added by a category, description of the requirement, the priority and the type of
requirement (functional or non-functional requirement). The priority is defined as
follows:
Seite 13/25
•
Priority 1: has to be absolutely fulfilled (highest priority)
•
Priority 2: shall be fulfilled
•
Priority 3:should be fulfilled, but is not necessary for the software
•
Priority 4: should be fulfilled in future
•
Priority 5: is not important for the software (no implementation needed)
The following categories were determined in order to assort the requirements
and at least give an overview of existing requirements concerning the software.
•
Automation / Task Management
•
Business Process Reengineering /
Simulation
•
Design / Usability
•
Discovery / Analysis
•
Event Management
•
Implementations
•
Industry
•
Integration
•
Integration / Execution
•
Modeling / Design
•
Monitoring / Optimization
•
Patterns
•
Performance
•
Pricing / Support
•
Regulatory
•
Reliability
•
Reporting
•
Rules / Customization
•
Security
•
Transaction Control
Non-Functional Requirements
The non-functional requirements are divided into operational requirements
(performance, operating and environmental conditions), safety requirements
(which become very important in the case that the software is available via the
internet), quality requirements, and constraints (which mostly consist of
requirements describing contracts, agreements, rights and duties etc).
For the future, it is very important that all the requirements will be discussed with
the developer of the software in order to find a solution which meets the
legitimate interests of both parties, the principal and the developer.
Validation
Validation ensures that the requirements exhibit the desirable characteristics of
excellent requirement statements (complete, correct, feasible, necessary,
prioritized, unambiguous, and verifiable) and of excellent requirement
specifications (classified, consistent, modifiable, and traceable) (cf. Wiegers, 2003,
p. 261; Rupp & SOPHISTen, 2009, p. 24).
Requirements validation involves checking that the software provides all
functions that support the customers’ needs and ensures that there are no
requirements conflicts. For this purpose, the identified requirements were aligned
Seite 14/25
in consultation with the key stakeholders (BPB project members, project partners,
customers and independent developers) in form of interviews, workshops or
reviews. The validation activities were performed in the iterative elicitation,
analysis, and specification process for the requirements (cf. Pohl, 2008, p. 419;
Wiegers, 2003, p. 261). The validation of requirements caused extra effort, but is
going to reduce subsequent costs and risks in the later development phase (cf.
Pohl, 2008, p. 421).
Besides the validation, a first verification of the requirements is made in the
subsequent implementation within an early prototype, which is described in
chapter 4.
3.4.3 Quality Requirements Management
Besides quality conditions for software requirements, which were described in the
validation in the previous chapter, there are also quality requirements5 for the
software itself. A useful guide for identifying and dealing with quality
requirements is the standard ISO 9126 (ISO/IEC, 2001). This differs in the
following six quality requirements plus one (cf. Ebert, 2012, pp. 72-80).
1. Functionality: is the existence of functions with specified properties, which
enable the defined requirements. Among them, the correctness of functions
(accuracy), the interoperability (means the co-capability with other systems) and
security (confidentiality, integrity, legal liability – for example, separation of data
files, backup mechanisms, access controls, authentication and encryption) is
included.
2. Reliability: is the ability of software to achieve their level of performance under
specified conditions in a fixed period. Examples are error rate, fault tolerance,
availability, maturity and recoverability. 3. Usability: is the effort that is required to learn and to use software and the effort
for an individual assessment of the usability by a fixed or expected group.
Examples are understandability, learnability, operability and attractiveness. 4. Efficiency: is the ratio between the level of performance of the software and the
amount of equipment used under specified conditions, the time behavior and the
consumption of required resources. Examples are the number of users, load
response, data access, data communications, access frequency, network usage,
CPU usage, allowed reaction time, and duration.
5. Maintainability: is the effort that is required to perform a given change. Changes
may include corrections, improvements or adaptations to changes in the
5
A big amount of quality requirements are defined for the tool development and are available in
the project documentation.
Seite 15/25
environment, requirements and functional specifications. Likewise, it includes the
analyzability, changeability, testability, and stability.
6. Portability: is the ability of the software to be transferred from one environment
to another. Environment may include organizational environment, hardware or
software environment. For the components it also stands for the ability of
adaptability, installability, co-existence, and replaceability.
Each of these six categories has also a sub-category, namely compliance or
regularity, which means the adherence of application-specific standards and
norms, agreements, regulations and similar constraints.
3.4.4 Requirements Risk Management
This section presents the principles and techniques of scientific methods to
address risks. Within a software project, risk management is a central element to
ensure the success of software, concerning to its quality, time and budget
restrictions. "Only if the quality of the requirements is known, the risks for the
project's progress can properly be estimated and targeted” (Rupp & SOPHISTen,
2009, p. 313). Accordingly, risk management of requirements is equally an
evaluation like their validation. The approach in this elaboration is, to provide a
more intensive focus on the potential risks of the determined requirements and
less on IT-risk management in general.
Ebert (2012, p. 162) defines some benefits of RE risk management.
•
Requirements are prioritized due to their value
•
Relevant stakeholders are identified
•
Decision spaces are limited
•
Risks are assessed early and limited
•
Project and development processes are tailored on boundary conditions
For this elaboration the following four risk management approaches were
considered. First the risk identification to detect the possible risks in a software
project and its stakeholders (see chapter 3.2), secondly the risk analysis to
estimate the potential risks, thirdly the risk evaluation to control the risks and
finally the risk treatment in order to define measures for preventing or treating
risks. The risk documentation is not further discussed in this work.
Risk Identification
The risk identification is the first process of examining potential risks for the
requirement risk factors. “The outcome of this process should be a long list of
Seite 16/25
potential risks which could occur and which could affect the product, the process or
the business” (Sommerville, 2001, p. 86).
Possible requirement risks were identified during interviews with industry
partners, a brainstorming with BPB project members and reviews with software
developers. Likewise, the list has been verified by specific literature. (Cf. here
Ebert, 2012; Gaulke, 2002; Lamsweerde, 2009; Sommerville, 2001; Wallmüller,
2004; Wiegers, 2003)
The main groups of risks which were identified are:
•
Product development
•
Development environment
•
Project restrictions
•
Missing requirements
•
Wrong requirements
•
Wrong defined requirements
•
Changing requirements
•
Unsatisfactory involvement of user / stakeholder
The identified requirement risks are explained in the project related
documentation, includes further identified risks compared to the software
development project..
Risk Analysis
During risk analysis the potential consequences of specific requirements were
examined. “During the risk analysis process, each identified risk is considered in turn
and a judgment made about the probability and the seriousness of the risk”
(Sommerville, 2001, p. 86).
The result of this analysis process is a table of requirements, structured according
to the seriousness of the risk. Obviously the assessment of probability and
seriousness is selected arbitrary. Once the risks have been analyzed and ranked,
they were taken under judgment about the fact which are the most important
risks and were reviewed during the BPB project and experienced software
developers. These judgments depend on a combination of the probability of the
risk arising and the effects of that risk (impact) (cf. Sommerville, 2001, pp. 87f.).
Risk Evaluation
The next step is the prioritization and validation of the risks, to identify the top
ten risks, because the elimination of all risks is usually impractical or almost
impossible. With a least-cost approach the aim is to decrease the risks to an
Seite 17/25
acceptable level, with a minimal adverse to impact on the software and resources.
A validation of the risk has been based on checklists by Ebert (2012, pp. 166f.).
Through the results, the requirement risks were prioritized, based on the product
of their probability and impact (column ‘Product’). The top ten risks are:
1. Missing requirements management and escalation capabilities
2. Too many changes in the requirements
3. Missing Requirements
4. Changing requirements
5. Requirements cannot be fulfilled (timely)
6. Requirements cannot be fulfilled (financially)
7. Wrong (defined) requirements
8. Changed requirements are not validated / controlled
9. Constant stream of new requirements
10. Oversimplified and superficial specifications lead to missing or incorrect
functionality
The main risk is the “Missing requirements management and escalation
capabilities”. Requirements management affects all major decisions regarding to
requirements. With a proper requirements management, the requirements
traceability process is given, the error handling is minimized and
misunderstandings are eliminated. Thus, a missing requirements management
influences all requirement risks. Risk Treatment
This section describes all methods to treat requirement risks, known as risk
treatment or mitigation. The treatment of risk plans to address the risk either by
avoiding it or minimizing its effects on the software project.
The risk treatment possibilities according to Gaulke (2002, pp. 159-165) and
Wallmüller (2004, pp. 141-148) clustered in the following approaches:
•
Risk avoidance: Elimination of risks
•
Risk prevention, mitigation: Reduction of the probability •
Risk contingency: Minimize the impact •
Risk transference: Risk overlay on Third parties •
Risk acceptance Essential techniques of risk mitigation in and through the RE are given by Ebert
(2012, p. 166):
•
Evaluation and selection of the portfolio management techniques to separate
important and unimportant requirements (Prioritization).
Seite 18/25
•
Risks already assessed in the analysis and review. Scenarios: What is the
requirements’ change? How will it change the requirements?
•
Adapt the project management to deal with uncertainties and changes.
Examples: Integrated planning, regular and systematic performed risk
management. Implement rules and targets, in order to limit the scope for
decisions.
•
Customize the development process in order to deal with uncertainties and
changes. Examples: incremental, evolutionary, agile techniques, prototyping.
•
Adjust architecture and design in order to deal with uncertainties and changes.
Examples: Design for Change, expandability, modularity.
•
Strict and systematic change management. Changes and new requirements
follow the exact same process (identification, analysis, documentation,
treatment, etc.). Analysis of change: Value and benefits of requirements before
they are accepted. Impact analysis in order to communicate dependencies and
consequences of a change before the review. Traceability of requirements to
secure and maintain them.
Concluded to say, for safe and stable software, a continuous risk assessment is
necessary including a further risk monitoring. The risks are constantly assessed
and plans for the risk mitigation are revised.
Seite 19/25
4
System Design and Technical Concept
Out of the objectives and the requirements, module 4 developed and created a
first prototype in order to get to know what the software should look and feel like
and in order to get to know if the software is feasible and how much effort should
be made in order to develop the final software.
A prototype indicates which requirements are really necessary and which
requirements can be excluded from the future software. It also shows which
improvements and changes have to be made to develop the software. This has
the advantage of realizing improvement and changes in an early stage of the
development and therefore rectifies them in time. The third point is that with the
prototype, which is developed, module 5 of the research project will be able to
validate the results of the first iteration of the research project. Module 5 will be
able to use the prototype as a pre-version of the software and thus can find
improvements and errors that will be corrected and optimized in a future
iteration (cf. Sommerville, 2001, p. 172).
The prototype is based on the main requirements shown in chapter 3.4.2. Since a
prototype is a pre-version of a future product, it was not necessary to develop all
requirements. Therefore, the research project team agreed on developing the
main requirements. The prototype will not be a prototype, which will be thrown
away after the development. It will be more of an evolutionary prototype on
which one can continue to build future functions. (cf. Wiegers, 2003, pp. 236-240;
Sommerville, 2001, pp. 174-180)
The prototype consists on the basis of Microsoft Access and thus is not suitable
for a large number of partners, customers or companies to launch benchmark.
Nevertheless, the following paragraph is comprised of the realization and system
design, some Mockups, technology evaluation and the object oriented analysis of
the prototype and final software.
4.1
Technology Evaluation
The software, which will be developed, must have different technology features
and functions. One first main technology function is the ability of connecting
itself with different software vendors of BPMS and process modeling software.
Another criterion is the fact of being open source. Since the research project is a
project of the University of Applied Sciences Munich, the intention of the project
group and the persons in charge is, as already mentioned, to develop a software
Seite 20/25
which is able to help companies to benchmark their processes. Hence, the aim is
to build software, which is available for all kind of companies. One way to handle
this is to build the software on an open source basis. Another point for the open
source version of the software is that everybody, even customers, will be able to
extend the software. Consequently, such functions might be developed that the
BPB research group has not yet thought of.
Since the software should be open source, this leads to the next function, which is
a web application of the software. The main point of a web application might be
the security of data. Due to that, it must be granted that data, which is shared
over the internet, will be secured. Therefore, it is suggested to use security
mechanisms such as VPN and their security protocols But for the beginning an
installable application will be developed, or even only a version that will remain to
the members and partners of the research project.
For this installable and remaining prototype Microsoft Access was chosen. It was
chosen due to the reason that Microsoft Access is an environment on which it is
possible to set up a kind of database really fast. With this first prototype it will be
possible to perform the validation of the entire research project. In order to
develop a first prototype some requirements were left out in order not to expand
the prototype too much (cf. Wiegers, 2003, pp. 242ff.) But for the future software
it will be necessary to integrate the missing requirements. Therefore, it is
suggested not to use Microsoft Access as a basis but other environments.
Last but not least the existing software which were found and analyzed in
chapter 2.1 are also part of the ongoing technology evaluation because there
have to be built up API for exactly those BPMS or process modeling software.
4.2
Object-Oriented Analysis
4.2.1 Mockups
In order to provide some of the functionality or design features and functions, a
few mockup-pictures are shown. Since a mockup is a model or a scale, which is
showing either the design or some functionalities of the product, the pictures
show a part of the prototype in the way it exists at the moment. They also
describe how the design of the software is looking right now. They offer a view of
the functionality or the different parts the software should have in the end.
Seite 21/25
Figure 4-1: Mock-ups
Source: own representation
4.2.2 System Analysis
Basis for the system analysis will be the meta data model (see chapter 2.2) and
the current ERM of the prototype. This ERM displays the relations among the
databases and consists of the objects of the software.
For clarity, the following figure 4-2 demonstrates an example concerning the PM³
and the evolved ERM. On the right, an example of a real process, the ‘recruiting
process’, is shown, which is a snapshot of the class ‘Process’ (blue box). The
attributes of this class are listed with corresponding data types (e.g. int – integer
for only numbers or string for letters). The attributes with a reference to another
object or class are written in capital letters. This is highlighted in the process
snapshot with the {,} character sequence.
Seite 22/25
Figure 4-2: Example of an instance of a class in the PM³
Source: own representation
4.2.3 Documentation
Most of the documentation is already made within the visual basic code of the
prototype. Therefore, it is not necessary to fulfill a documentation of the
prototype within this elaboration. Further information about the programming or
the development of the prototype and additionally the requirements, the
objectives and all other objects which were developed and generated by module 4
of the research process are available within the documentation of the research
project and by contacting the responsible persons for the project.
Seite 23/25
5
Future Prospects and Conclusion / Discussion
As written in the introduction, the purpose of this elaboration and part of the
research project is to examine the actual state, find, create or develop software,
which fits to the needs of the research project and the partners. After it was
detected that there is no suitable software available in the market, the research
group decided to develop own software. Parts of the development of software are
covered within this elaboration and have to be seen as a starting point for the
future of the project. The foundation stone is laid, the first steps of the
requirements engineering process are accomplished, stakeholders are identified,
objectives defined, requirements derived and formulated. A first prototype is
developed and mockups for a visualization of the software were designed.
Further Steps
For the future it is obvious that the software has to be created based on the
results already figured out. Within the creation of the software, it is still
important that the iterative software development is preferred which means that
all the work done so far in this elaboration has to be continued and repeated
again in a rotating cycle and either improvements or adjustments have to be
done.
The software has to be tested and deployed either within a test environment and
test-data or even with original data. Further stakeholders have to be found or
other project partners who are able and willing to fill the database with company
data. The adjustments of the first three modules as well as the fifth module have
to be implemented within the software. As a result, new objectives and
requirements have to be defined.
The final intention of the project or the software was and still is to make it
available for a larger number of interested parties and stakeholders. One reason is
the allocation of the software as an open source product and therefore the
continuation and promotion of the improvement. Especially smaller and medium
sized companies could benefit from the research project.
One important aspect, which should be followed during the advancement of the
project as well as the software is to document everything; not only defects but
also positive outcomes. This leads to the point of knowledge management. With
knowledge management it is easier to learn from mistakes and it is also easier to
develop the product, customers want to have. This leads to the importance of the
Seite 24/25
benchmarking software with an integrated knowledge management and the
history of changing processes.
Seite 25/25
Literaturverzeichnis
Doane, D., & Brooks, M. (2005, Novemeber 1). Standardized Data: XBRLs Benefits
for BPM Benchmarking. Retrieved September 5, 2012, from Business Performance
Management: http://bpmmag.net/mag/bpm_article_nwarcarticle_14528/
Drawehn, J., Kicherer, F., Kopperger, D., & Zähringer, D. (2008). Business Process
Management Tools 2008: Eine evaluierende Marktstudie zu aktuellen Werkzeugen.
(D. Spath, A. Weisbecker, & FraunhoferIAO, Eds.) Stuttgart: Fraunhofer IRB Verlag.
Ebert, C. (2012). Systematisches Requirements Engineering - Anforderungen
ermitteln, spezifizieren, analysieren und verwalten. Heidelberg: dpunkt.
Gadatsch, A. (2010). Grundkurs Geschäftsprozess-Management - Methoden und
Werkzeuge für die IT-Praxis: Eine Einführung für Studenten und Praktiker (6.
Auflage ed.). Wiesbaden: Vieweg + Teubner Verlag.
Gaulke, M. (2002). Risikomanagement in IT-Projekten. München Wien: Oldenbourg
Verlag.
ISO/IEC. (2001). 9126:2001. Software Engineering - Product Quality. (ISO, Editor)
Retrieved from http://www.iso.org
Puchan, J., Gann, T., Konrad, T., Seifert, L., Nagel, C., & Jäck, D. (2012, Juli).
Projektstruktur und Begriffe. I(Sonderausgabe: Business Process Benchmarking –
Band I Grundlagen). (J. Puchan, & T. Gann, Eds.) München: e-Journal of Practical
Business Research.
Richardson, C., Moore, C., Le Clair, C., & Vitti, R. (2010, August 24). The Forrester
Wave™: Business Process Management Suites, Q3 2010. (F. Research, Ed.)
Rupp, C., & SOPHISTen, d. (2007). Requirements Engineering und Management:
Professionelle, iterative Anforderungsanalyse für die Praxis (4. Auflage ed.).
München: Carl Hanser Verlag.
Rupp, C., & SOPHISTen, d. (2009). Requirements-Engineering und - Management.
Professionelle, iterative Anforderungsanalyse für die Praxis (5. Auflage ed.).
München: Carl Hanser Verlag.
Sinur, J., & Hill, J. B. (2010, October 18). Magic Quadrant for Business Process
Management Suites. Gartner RAS Core Research Note G00205212 .
Smith, H., & Fingar, P. (2007). Business Process Management: The third wave (4th
anniversary ed.). Tampa, Florida: Meghan-Kiffer Press.
Seite V
Sommerville, I. (2001). Software Engineering (6th edition). Harlow: Pearson
Education Limited.
TheStandishGroup. (2012). The CHAOS Manifesto. Retrieved 09 11, 2012, from The
Standish Group: http://blog.standishgroup.com/
Wallmüller, E. (2004). Risikomanagement für IT- und Software-Projekte: Ein
Leitfaden für die Umsetzung in der Praxis. München Wien: Carl Hanser Verlag.
Seite VI

Business Process Benchmarking - e-Journal of Practical Business

Transcrição

Documentos relacionados

Faszinierend melancholisch, einzigartig stimmgewaltig

Ausgewählt und kommentiert vom Süddeutsche Zeitung Magazin

Horus - Referenzen Stand 04 2015

as a PDF

Setlist der Band the forellis

Liederliste pdf

DIY Folding Bounce

Unit 1: My home is my castle

ARPA Sutstainable Finance of Protected Area Systems

City Light Board Network price per week