e-journal of Practical Business Research Business Process Benchmarking Band II Gesamtkonzeption:

Size: px
Start display at page:

Download "e-journal of Practical Business Research Business Process Benchmarking Band II Gesamtkonzeption:"

Transcription

1 e-journal of Practical Business Research Business Process Benchmarking Band II Gesamtkonzeption: BPB-Tool-Entwicklung Christian Nagel, David Jäck & Jörg Puchan Erschienen im e-journal of Practical Business Research unter: 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: /

2 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

3 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

4 Index of Content Kurzfassung... I Index of Content... II Abbildungsverzeichnis... III List of Abbreviations...IV 1 Introduction, Motivation and Purpose Status Quo Status Quo of Software Environment Process Metadata Model Munich Requirements Engineering Procedure / Process Model Stakeholder Analysis Objectives Analysis Requirements Engineering Activities and Development Requirements Elicitation Requirements Analysis, Specification and Validation Quality Requirements Management Requirements Risk Management System Design and Technical Concept Technology Evaluation Object-Oriented Analysis Mockups System Analysis Documentation Future Prospects and Conclusion / Discussion...24 Literaturverzeichnis...V Projekt BPB; Nagel, Jäck, Puchan Seite II

5 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

6 List of Abbreviations API BM² BPB BPM BPMS ERM PM³ RE RPM² UML Application Programming Interface Benchmarking Method Munich Business Process Benchmarking Business Process Management Business Process Management System Entity-Relationship-Model Process Metadata Model Munich Requirements Engineering Reference Process Model Munich Unified Modeling Language Projekt BPB; Nagel, Jäck, Puchan Seite IV

7 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. Projekt BPB; Nagel, Jäck, Puchan Seite 1/25

8 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 scenarios 1 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. Projekt BPB; Nagel, Jäck, Puchan Seite 2/25

9 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. Projekt BPB; Nagel, Jäck, Puchan Seite 3/25

10 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. Projekt BPB; Nagel, Jäck, Puchan Seite 4/25

11 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 , 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). Projekt BPB; Nagel, Jäck, Puchan Seite 5/25

12 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. Projekt BPB; Nagel, Jäck, Puchan Seite 6/25

13 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 Projekt BPB; Nagel, Jäck, Puchan Seite 7/25

14 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 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 ) identify a six-step process of how to design perfect requirements based on templates: 1. Define processes 2. Choose system activity Projekt BPB; Nagel, Jäck, Puchan Seite 8/25

15 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) Projekt BPB; Nagel, Jäck, Puchan Seite 9/25

16 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 questionnaire 3 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. Projekt BPB; Nagel, Jäck, Puchan Seite 10/25

17 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 software 4. 4 The fully described use cases are available in the documentation of the BPB project. Projekt BPB; Nagel, Jäck, Puchan Seite 11/25

18 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 Dashboard BPB Tool Back-End Administrative Environment Data Management History Report Management Forecast Admin Environment Data Management Benchmarking Error Management Client Management Administrative Environment Data Management Client Admin Area Report Management 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. Projekt BPB; Nagel, Jäck, Puchan Seite 12/25

19 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 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: Projekt BPB; Nagel, Jäck, Puchan Seite 13/25

20 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 Monitoring / Optimization Business Process Reengineering / Patterns Simulation Performance Design / Usability Pricing / Support Discovery / Analysis Regulatory Event Management Reliability Implementations Reporting Industry Rules / Customization Integration Security Integration / Execution Transaction Control Modeling / Design 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 Projekt BPB; Nagel, Jäck, Puchan Seite 14/25

e-journal of Practical Business Research Business Process Benchmarking Implementierung

e-journal of Practical Business Research Business Process Benchmarking Implementierung e-journal of Practical Business Research Business Process Benchmarking Implementierung Jörg Puchan, Sophia Zapf, Fee Schubert-Stöcklein, Christian Willige puchan@hm.edu Erschienen im e-journal of Practical

More information

e-journal of Practical Business Research Business Process Benchmarking Band II Gesamtkonzeption:

e-journal of Practical Business Research Business Process Benchmarking Band II Gesamtkonzeption: e-journal of Practical Business Research Business Process Benchmarking Band II Gesamtkonzeption: Benchmarking Method Munich: Quick Reference Guide Werner Lugauer, Thomas Gann, Sophia Zapf David Jäck &

More information

Requirements engineering

Requirements engineering Learning Unit 2 Requirements engineering Contents Introduction............................................... 21 2.1 Important concepts........................................ 21 2.1.1 Stakeholders and

More information

A Study into the Critical Success Factors when Implementing Business Process Management Systems

A Study into the Critical Success Factors when Implementing Business Process Management Systems A Study into the Critical Success Factors when Implementing Business Process Management Systems Pascal Ravesteyn 1 1 University for Applied Science Utrecht, Institute for Process Innovation, Nijenoord

More information

Software Engineering. Software Processes. Based on Software Engineering, 7 th Edition by Ian Sommerville

Software Engineering. Software Processes. Based on Software Engineering, 7 th Edition by Ian Sommerville Software Engineering Software Processes Based on Software Engineering, 7 th Edition by Ian Sommerville Objectives To introduce software process models To describe three generic process models and when

More information

The Role of Information Technology Studies in Software Product Quality Improvement

The Role of Information Technology Studies in Software Product Quality Improvement The Role of Information Technology Studies in Software Product Quality Improvement RUDITE CEVERE, Dr.sc.comp., Professor Faculty of Information Technologies SANDRA SPROGE, Dr.sc.ing., Head of Department

More information

Software Development Life Cycle (SDLC)

Software Development Life Cycle (SDLC) Software Development Life Cycle (SDLC) Supriyo Bhattacharjee MOF Capability Maturity Model (CMM) A bench-mark for measuring the maturity of an organization s software process CMM defines 5 levels of process

More information

Kapitel 2 Unternehmensarchitektur III

Kapitel 2 Unternehmensarchitektur III Kapitel 2 Unternehmensarchitektur III Software Architecture, Quality, and Testing FS 2015 Prof. Dr. Jana Köhler jana.koehler@hslu.ch IT Strategie Entwicklung "Foundation for Execution" "Because experts

More information

(Refer Slide Time: 01:52)

(Refer Slide Time: 01:52) Software Engineering Prof. N. L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture - 2 Introduction to Software Engineering Challenges, Process Models etc (Part 2) This

More information

DEVELOPING REQUIREMENTS FOR DATA WAREHOUSE SYSTEMS WITH USE CASES

DEVELOPING REQUIREMENTS FOR DATA WAREHOUSE SYSTEMS WITH USE CASES DEVELOPING REQUIREMENTS FOR DATA WAREHOUSE SYSTEMS WITH USE CASES Robert M. Bruckner Vienna University of Technology bruckner@ifs.tuwien.ac.at Beate List Vienna University of Technology list@ifs.tuwien.ac.at

More information

Questions? Assignment. Techniques for Gathering Requirements. Gathering and Analysing Requirements

Questions? Assignment. Techniques for Gathering Requirements. Gathering and Analysing Requirements Questions? Assignment Why is proper project management important? What is goal of domain analysis? What is the difference between functional and non- functional requirements? Why is it important for requirements

More information

Lecture 8 About Quality and Quality Management Systems

Lecture 8 About Quality and Quality Management Systems Lecture 8 About Quality and Quality Management Systems Kari Systä 10.03.2014 10.03.2014 TIE-21100/21106; K.Systä 1 Content of today s lecture Two weeks ago we discussed about testing and inspections, that

More information

11 Tips to make the requirements definition process more effective and results more usable

11 Tips to make the requirements definition process more effective and results more usable 1 11 Tips to make the s definition process more effective and results more usable This article discusses what I believe are the key techniques for making s definition process repeatable from project to

More information

Lecture Softwareengineering-Vertiefung

Lecture Softwareengineering-Vertiefung Lecture Softwareengineering-Vertiefung 1 Introduction Summer term 2014 TU Chemnitz Department of Computer Science Dr. Dirk Müller Overview Introduction Organizational issues Process of software inspection,

More information

Requirements Engineering Process

Requirements Engineering Process Software Engineering Requirements Engineering Process Based on Software Engineering, 7 th Edition by Ian Sommerville Objectives To describe the principal requirements engineering activities and d their

More information

To introduce software process models To describe three generic process models and when they may be used

To introduce software process models To describe three generic process models and when they may be used Software Processes Objectives To introduce software process models To describe three generic process models and when they may be used To describe outline process models for requirements engineering, software

More information

1.1 The Nature of Software... Object-Oriented Software Engineering Practical Software Development using UML and Java. The Nature of Software...

1.1 The Nature of Software... Object-Oriented Software Engineering Practical Software Development using UML and Java. The Nature of Software... 1.1 The Nature of Software... Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering Software is intangible Hard to understand

More information

Surveying and evaluating tools for managing processes for software intensive systems

Surveying and evaluating tools for managing processes for software intensive systems Master Thesis in Software Engineering 30 Credits, Advanced Level Surveying and evaluating tools for managing processes for software intensive systems Anuradha Suryadevara IDT Mälardalen University, ABB

More information

What is a life cycle model?

What is a life cycle model? What is a life cycle model? Framework under which a software product is going to be developed. Defines the phases that the product under development will go through. Identifies activities involved in each

More information

1 Business Modeling. 1.1 Event-driven Process Chain (EPC) Seite 2

1 Business Modeling. 1.1 Event-driven Process Chain (EPC) Seite 2 Business Process Modeling with EPC and UML Transformation or Integration? Dr. Markus Nüttgens, Dipl.-Inform. Thomas Feld, Dipl.-Kfm. Volker Zimmermann Institut für Wirtschaftsinformatik (IWi), Universität

More information

SPICE auf der Überholspur. Vergleich von ISO (TR) 15504 und Automotive SPICE

SPICE auf der Überholspur. Vergleich von ISO (TR) 15504 und Automotive SPICE SPICE auf der Überholspur Vergleich von ISO (TR) 15504 und Automotive SPICE Historie Software Process Improvement and Capability determination 1994 1995 ISO 15504 Draft SPICE wird als Projekt der ISO zur

More information

VALLIAMMAI ENGINEERING COLLEGE S.R.M. Nagar, Kattankulathur DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

VALLIAMMAI ENGINEERING COLLEGE S.R.M. Nagar, Kattankulathur DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING VALLIAMMAI ENGINEERING COLLEGE S.R.M. Nagar, Kattankulathur DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING Sub Code : CP7007 Sub Name: SOFTWARE REQUIREMENTS ENGINEERING Branch / Year : ME CSE / I Year

More information

Applying Agile Methods in Rapidly Changing Environments

Applying Agile Methods in Rapidly Changing Environments Applying Agile Methods in Changing Environments 7/23/2002 1 Applying Agile Methods in Rapidly Changing Environments Peter Kutschera IBM Unternehmensberatung GmbH Am Fichtenberg 1, D-71803 Herrenberg Steffen

More information

2. Analysis, Design and Implementation

2. Analysis, Design and Implementation 2. Subject/Topic/Focus: Software Production Process Summary: Software Crisis Software as a Product: From Individual Programs to Complete Application Systems Software Development: Goals, Tasks, Actors,

More information

PROCESS OF MOVING FROM WATERFALL TO AGILE PROJECT MANAGEMENT MODEL

PROCESS OF MOVING FROM WATERFALL TO AGILE PROJECT MANAGEMENT MODEL PROCESS OF MOVING FROM WATERFALL TO AGILE PROJECT MANAGEMENT MODEL Sanja Vukićević 1, Dražen Drašković 2 1 Faculty of Organizational Sciences, University of Belgrade, vukicevicsanja@yahoo.com 2 Faculty

More information

Syllabus. REQB Certified Professional for Requirements Engineering. Foundation Level

Syllabus. REQB Certified Professional for Requirements Engineering. Foundation Level Syllabus REQB Certified Professional for Requirements Engineering Version 2.1 2014 The copyright to this edition of the syllabus in all languages is held by the Global Association for Software Quality,

More information

CS 389 Software Engineering. Lecture 2 Chapter 2 Software Processes. Adapted from: Chap 1. Sommerville 9 th ed. Chap 1. Pressman 6 th ed.

CS 389 Software Engineering. Lecture 2 Chapter 2 Software Processes. Adapted from: Chap 1. Sommerville 9 th ed. Chap 1. Pressman 6 th ed. CS 389 Software Engineering Lecture 2 Chapter 2 Software Processes Adapted from: Chap 1. Sommerville 9 th ed. Chap 1. Pressman 6 th ed. Topics covered Software process models Process activities Coping

More information

Assuming the Role of Systems Analyst & Analysis Alternatives

Assuming the Role of Systems Analyst & Analysis Alternatives Assuming the Role of Systems Analyst & Analysis Alternatives Nature of Analysis Systems analysis and design is a systematic approach to identifying problems, opportunities, and objectives; analyzing the

More information

4.1 Domain Analysis. Object-Oriented Software Engineering Practical Software Development using UML and Java

4.1 Domain Analysis. Object-Oriented Software Engineering Practical Software Development using UML and Java 4.1 Domain Analysis Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 4: Developing The process by which a software engineer learns about the domain to better

More information

BPM and Simulation. A White Paper. Signavio, Inc. Nov 2013. Katharina Clauberg, William Thomas

BPM and Simulation. A White Paper. Signavio, Inc. Nov 2013. Katharina Clauberg, William Thomas BPM and Simulation A White Paper Signavio, Inc. Nov 2013 Katharina Clauberg, William Thomas Table of Contents 1. Executive Summary... 3 2. Setting the Scene for Process Change... 4 3. Identifying the Goals

More information

Introduction to SOA governance and service lifecycle management.

Introduction to SOA governance and service lifecycle management. -oriented architecture White paper March 2009 Introduction to SOA governance and Best practices for development and deployment Bill Brown, executive IT architect, worldwide SOA governance SGMM lead, SOA

More information

Better processes by sprint: Agile process improvement. Timo Karasch, Method Park

Better processes by sprint: Agile process improvement. Timo Karasch, Method Park Better processes by sprint: Agile process improvement Timo Karasch, Method Park Seite 1 / 14 Abstract The conventional process improvement is more and more unable to cope with its excessive objectives

More information

Software Engineering and Scientific Computing

Software Engineering and Scientific Computing Software Engineering and Scientific Computing Barbara Paech, Hanna Valtokari Institute of Computer Science Im Neuenheimer Feld 326 69120 Heidelberg, Germany http://se.ifi.uni-heidelberg.de paech@informatik.uni-heidelberg.de

More information

Title: Topic 3 Software process models (Topic03 Slide 1).

Title: Topic 3 Software process models (Topic03 Slide 1). Title: Topic 3 Software process models (Topic03 Slide 1). Topic 3: Lecture Notes (instructions for the lecturer) Author of the topic: Klaus Bothe (Berlin) English version: Katerina Zdravkova, Vangel Ajanovski

More information

Swirl. Multiplayer Gaming Simplified. CS4512 Systems Analysis and Design. Assignment 1 2010. Marque Browne 0814547. Manuel Honegger - 0837997

Swirl. Multiplayer Gaming Simplified. CS4512 Systems Analysis and Design. Assignment 1 2010. Marque Browne 0814547. Manuel Honegger - 0837997 1 Swirl Multiplayer Gaming Simplified CS4512 Systems Analysis and Design Assignment 1 2010 Marque Browne 0814547 Manuel Honegger - 0837997 Kieran O' Brien 0866946 2 BLANK MARKING SCHEME 3 TABLE OF CONTENTS

More information

Open S-BPM: Goals and Architecture

Open S-BPM: Goals and Architecture Open S-BPM: Goals and Architecture Albert Fleischmann Werner Schmidt Table of Content 1 Introduction... 2 2 Mission, Vision and Objectives... 2 3 Research and Development Areas... 3 4 Open S-BPM Architecture...

More information

ISO/IEC 9126-1 Software Product Quality Model

ISO/IEC 9126-1 Software Product Quality Model Why do current systems fail? Standish Group found that 51% of projects failed 31% were partially successful Main causes were poor user requirements: 13.1% Incomplete requirements 12.4% Lack of user involvement

More information

Meta-Model specification V2 D602.012

Meta-Model specification V2 D602.012 PROPRIETARY RIGHTS STATEMENT THIS DOCUMENT CONTAINS INFORMATION, WHICH IS PROPRIETARY TO THE CRYSTAL CONSORTIUM. NEITHER THIS DOCUMENT NOR THE INFORMATION CONTAINED HEREIN SHALL BE USED, DUPLICATED OR

More information

Requirements engineering and quality attributes

Requirements engineering and quality attributes Open Learning Universiteit Unit 2 Learning Unit 2 Requirements engineering and quality attributes Contents Introduction............................................... 21 2.1 Important concepts........................................

More information

An Automated Workflow System Geared Towards Consumer Goods and Services Companies

An Automated Workflow System Geared Towards Consumer Goods and Services Companies Proceedings of the 2014 International Conference on Industrial Engineering and Operations Management Bali, Indonesia, January 7 9, 2014 An Automated Workflow System Geared Towards Consumer Goods and Services

More information

ERNW Newsletter 29 / November 2009

ERNW Newsletter 29 / November 2009 ERNW Newsletter 29 / November 2009 Dear Partners and Colleagues, Welcome to the ERNW Newsletter no. 29 covering the topic: Data Leakage Prevention A Practical Evaluation Version 1.0 from 19th of november

More information

Software Requirements, Third Edition

Software Requirements, Third Edition j Microsoft Software Requirements, Third Edition Karl Wiegers and Joy Beatty Contents Introduction Acknowledgments xxv xxxi PART I SOFTWARE REQUIREMENTS: WHAT, WHY, AND WHO Chapter 1 The essential software

More information

Semantic Business Process Management Lectuer 1 - Introduction

Semantic Business Process Management Lectuer 1 - Introduction Arbeitsgruppe Semantic Business Process Management Lectuer 1 - Introduction Prof. Dr. Adrian Paschke Corporate Semantic Web (AG-CSW) Institute for Computer Science, Freie Universitaet Berlin paschke@inf.fu-berlin.de

More information

Do you know? "7 Practices" for a Reliable Requirements Management. by Software Process Engineering Inc. translated by Sparx Systems Japan Co., Ltd.

Do you know? 7 Practices for a Reliable Requirements Management. by Software Process Engineering Inc. translated by Sparx Systems Japan Co., Ltd. Do you know? "7 Practices" for a Reliable Requirements Management by Software Process Engineering Inc. translated by Sparx Systems Japan Co., Ltd. In this white paper, we focus on the "Requirements Management,"

More information

The Usability Engineering Repository (UsER)

The Usability Engineering Repository (UsER) The Usability Engineering Repository (UsER) Marc Paul, Amelie Roenspieß, Tilo Mentler, Michael Herczeg Institut für Multimediale und Interaktive Systeme (IMIS) Universität zu Lübeck Ratzeburger Allee 160

More information

Module 2. Software Life Cycle Model. Version 2 CSE IIT, Kharagpur

Module 2. Software Life Cycle Model. Version 2 CSE IIT, Kharagpur Module 2 Software Life Cycle Model Lesson 4 Prototyping and Spiral Life Cycle Models Specific Instructional Objectives At the end of this lesson the student will be able to: Explain what a prototype is.

More information

Towards Collaborative Requirements Engineering Tool for ERP product customization

Towards Collaborative Requirements Engineering Tool for ERP product customization Towards Collaborative Requirements Engineering Tool for ERP product customization Boban Celebic, Ruth Breu, Michael Felderer, Florian Häser Institute of Computer Science, University of Innsbruck 6020 Innsbruck,

More information

2. Analysis, Design and Implementation

2. Analysis, Design and Implementation 2. Analysis, Design and Implementation Subject/Topic/Focus: Software Production Process Summary: Software Crisis Software as a Product: From Programs to Application Systems Products Software Development:

More information

Towards an Integration of Process Modeling and Project Planning

Towards an Integration of Process Modeling and Project Planning Towards an Integration of Process Modeling and Project Planning Michael Gnatz, Martin Deubler, Michael Meisinger Technische Universität München Institut für Informatik Boltzmannstr. 3, 85748 Garching (gnatzm

More information

Best-Practice Software Engineering: Software Processes to Support Project Success. Dietmar Winkler

Best-Practice Software Engineering: Software Processes to Support Project Success. Dietmar Winkler Best-Practice Software Engineering: Software Processes to Support Project Success Dietmar Winkler Vienna University of Technology Institute of Software Technology and Interactive Systems Dietmar.Winkler@qse.ifs.tuwien.ac.at

More information

Quality Management. Managing the quality of the software process and products

Quality Management. Managing the quality of the software process and products Quality Management Managing the quality of the software process and products Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 24 Slide 1 Objectives To introduce the quality management process

More information

Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II)

Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II) Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II) We studied the problem definition phase, with which

More information

An Integrated Quality Assurance Framework for Specifying Business Information Systems

An Integrated Quality Assurance Framework for Specifying Business Information Systems An Integrated Quality Assurance Framework for Specifying Business Information Systems Frank Salger 1, Stefan Sauer 2, Gregor Engels 1,2 1 Capgemini sd&m AG, Carl-Wery-Str. 42, D-81739 München, Germany

More information

Governance, Risk and Compliance in BPM - A Survey of Software Tools

Governance, Risk and Compliance in BPM - A Survey of Software Tools Governance, Risk and Compliance in BPM - A Survey of Software Tools Falko Koetter, Monika Kochanowski, Jens Drawehn Fraunhofer Institute for Industrial Engineering IAO and University of Stuttgart IAT Stuttgart,

More information

What makes a good process?

What makes a good process? Rob Davis Everyone wants a good process. Our businesses would be more profitable if we had them. But do we know what a good process is? Would we recognized one if we saw it? And how do we ensure we can

More information

CASSANDRA: Version: 1.1.0 / 1. November 2001

CASSANDRA: Version: 1.1.0 / 1. November 2001 CASSANDRA: An Automated Software Engineering Coach Markus Schacher KnowGravity Inc. Badenerstrasse 808 8048 Zürich Switzerland Phone: ++41-(0)1/434'20'00 Fax: ++41-(0)1/434'20'09 Email: markus.schacher@knowgravity.com

More information

Fundamentals of Information Systems, Fifth Edition. Chapter 8 Systems Development

Fundamentals of Information Systems, Fifth Edition. Chapter 8 Systems Development Fundamentals of Information Systems, Fifth Edition Chapter 8 Systems Development Principles and Learning Objectives Effective systems development requires a team effort of stakeholders, users, managers,

More information

Bidirectional Tracing of Requirements in Embedded Software Development

Bidirectional Tracing of Requirements in Embedded Software Development Bidirectional Tracing of Requirements in Embedded Software Development Barbara Draxler Fachbereich Informatik Universität Salzburg Abstract Nowadays, the increased complexity of embedded systems applications

More information

Foundations for Systems Development

Foundations for Systems Development Foundations for Systems Development ASSIGNMENT 1 Read this assignment introduction. Then, read Chapter 1, The Systems Development Environment, on pages 2 25 in your textbook. What Is Systems Analysis and

More information

What is BPM? Software tools enabling BPM

What is BPM? Software tools enabling BPM What is BPM? BPM, or Business Process Management, is a technology, but it is also more than that. Broadly speaking, one can consider BPM as a management discipline in which processes are valued as assets

More information

Information system for production and mounting of plastic windows

Information system for production and mounting of plastic windows Information system for production and mounting of plastic windows MARCEL, MELIŠ Slovak University of Technology - Faculty of Material Sciences and Technology in Trnava, Paulínska 16 street, Trnava, 917

More information

IT3205: Fundamentals of Software Engineering (Compulsory)

IT3205: Fundamentals of Software Engineering (Compulsory) INTRODUCTION : Fundamentals of Software Engineering (Compulsory) This course is designed to provide the students with the basic competencies required to identify requirements, document the system design

More information

Business Analyst Work Plan. Presented by: Billie Johnson, CBAP CSM

Business Analyst Work Plan. Presented by: Billie Johnson, CBAP CSM Business Analyst Work Plan Presented by: Billie Johnson, CBAP CSM Agenda Topic Introduction Overview of a Business Analysis Work Plan Initiating a Business Analysis Effort Components of the Business Analysis

More information

Partnering for Project Success: Project Manager and Business Analyst Collaboration

Partnering for Project Success: Project Manager and Business Analyst Collaboration Partnering for Project Success: Project Manager and Business Analyst Collaboration By Barbara Carkenord, CBAP, Chris Cartwright, PMP, Robin Grace, CBAP, Larry Goldsmith, PMP, Elizabeth Larson, PMP, CBAP,

More information

Syllabus Agile Management Foundation

Syllabus Agile Management Foundation AGILE LEADERSHIP EUROPE Das Netzwerk für Projekt-, Prozess- und Qualitätsmanager ZVR 948545369 Schriftführung Christian Vesely email christian.vesely@aon.at, Mobil +43 664 2604227 http://www.agile-leadership-europe.com/

More information

SOFTWARE DEVELOPMENT STANDARD FOR SPACECRAFT

SOFTWARE DEVELOPMENT STANDARD FOR SPACECRAFT SOFTWARE DEVELOPMENT STANDARD FOR SPACECRAFT Mar 31, 2014 Japan Aerospace Exploration Agency This is an English translation of JERG-2-610. Whenever there is anything ambiguous in this document, the original

More information

A Comparison of SOA Methodologies Analysis & Design Phases

A Comparison of SOA Methodologies Analysis & Design Phases 202 A Comparison of SOA Methodologies Analysis & Design Phases Sandra SVANIDZAITĖ Institute of Mathematics and Informatics, Vilnius University Abstract. Service oriented computing is a new software engineering

More information

Story Card Based Agile Software Development

Story Card Based Agile Software Development Story Card Based Agile Software Development Chetankumar Patel, and Muthu Ramachandran Leeds Metropolitan University, UK c.patel@leedsmet.ac.uk Abstract The use of story cards for user stories in many Extreme

More information

Plan-Driven Methodologies

Plan-Driven Methodologies Plan-Driven Methodologies The traditional way to develop software Based on system engineering and quality disciplines (process improvement) Standards developed from DoD & industry to make process fit a

More information

Your Software Quality is Our Business. INDEPENDENT VERIFICATION AND VALIDATION (IV&V) WHITE PAPER Prepared by Adnet, Inc.

Your Software Quality is Our Business. INDEPENDENT VERIFICATION AND VALIDATION (IV&V) WHITE PAPER Prepared by Adnet, Inc. INDEPENDENT VERIFICATION AND VALIDATION (IV&V) WHITE PAPER Prepared by Adnet, Inc. February 2013 1 Executive Summary Adnet is pleased to provide this white paper, describing our approach to performing

More information

Requirements Engineering for Web Applications

Requirements Engineering for Web Applications Web Engineering Requirements Engineering for Web Applications Copyright 2013 Ioan Toma & Srdjan Komazec 1 What is the course structure? # Date Title 1 5 th March Web Engineering Introduction and Overview

More information

Business Modeling with UML

Business Modeling with UML Business Modeling with UML Hans-Erik Eriksson and Magnus Penker, Open Training Hans-Erik In order to keep up and be competitive, all companies Ericsson is and enterprises must assess the quality of their

More information

Software Engineering. Objectives. Designing, building and maintaining large software systems

Software Engineering. Objectives. Designing, building and maintaining large software systems Software Engineering Objectives Designing, building and maintaining large software systems To define software engineering and explain its importance To discuss the concepts of software products and software

More information

Component-based Development Process and Component Lifecycle Ivica Crnkovic 1, Stig Larsson 2, Michel Chaudron 3

Component-based Development Process and Component Lifecycle Ivica Crnkovic 1, Stig Larsson 2, Michel Chaudron 3 Component-based Development Process and Component Lifecycle Ivica Crnkovic 1, Stig Larsson 2, Michel Chaudron 3 1 Mälardalen University, Västerås, Sweden, ivica.crnkovic@mdh.se 2 ABB Corporate Research,

More information

System Development Life Cycle Guide

System Development Life Cycle Guide TEXAS DEPARTMENT OF INFORMATION RESOURCES System Development Life Cycle Guide Version 1.1 30 MAY 2008 Version History This and other Framework Extension tools are available on Framework Web site. Release

More information

Writing a Requirements Document For Multimedia and Software Projects

Writing a Requirements Document For Multimedia and Software Projects Writing a Requirements Document For Multimedia and Software Projects Rachel S. Smith, Senior Interface Designer, CSU Center for Distributed Learning Introduction This guide explains what a requirements

More information

Testing of safety-critical software some principles

Testing of safety-critical software some principles 1(60) Testing of safety-critical software some principles Emerging Trends in Software Testing: autumn 2012 Matti Vuori, Tampere University of Technology 27.11.2012 Contents 1/4 Topics of this lecture 6

More information

CDC UNIFIED PROCESS PRACTICES GUIDE

CDC UNIFIED PROCESS PRACTICES GUIDE Document Purpose The purpose of this document is to provide guidance on the practice of Requirements Definition and to describe the practice overview, requirements, best practices, activities, and key

More information

Modeling the User Interface of Web Applications with UML

Modeling the User Interface of Web Applications with UML Modeling the User Interface of Web Applications with UML Rolf Hennicker,Nora Koch,2 Institute of Computer Science Ludwig-Maximilians-University Munich Oettingenstr. 67 80538 München, Germany {kochn,hennicke}@informatik.uni-muenchen.de

More information

Menouer Boubekeur, Gregory Provan

Menouer Boubekeur, Gregory Provan Software Requirements Menouer Boubekeur, Gregory Provan Lectures Introduction to UML Introduction to Requirements Analysis Advanced techniques for Requirement Analysis M. Boubekeur, CSL, University College

More information

Big Data Vendor Benchmark 2015 A Comparison of Hardware Vendors, Software Vendors and Service Providers

Big Data Vendor Benchmark 2015 A Comparison of Hardware Vendors, Software Vendors and Service Providers A Comparison of Hardware Vendors, Software Vendors and Service Providers The digital world is becoming a reality. Mit jedem Tag ein bisschen mehr. ECommerce, Online- Werbung, mobile Applikationen und soziale

More information

Rapid software development. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 17 Slide 1

Rapid software development. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 17 Slide 1 Rapid software development Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 17 Slide 1 Objectives To explain how an iterative, incremental development process leads to faster delivery of

More information

Software Metrics & Software Metrology. Alain Abran. Chapter 4 Quantification and Measurement are Not the Same!

Software Metrics & Software Metrology. Alain Abran. Chapter 4 Quantification and Measurement are Not the Same! Software Metrics & Software Metrology Alain Abran Chapter 4 Quantification and Measurement are Not the Same! 1 Agenda This chapter covers: The difference between a number & an analysis model. The Measurement

More information

Business Process Technology

Business Process Technology Business Process Technology A Unified View on Business Processes, Workflows and Enterprise Applications Bearbeitet von Dirk Draheim, Colin Atkinson 1. Auflage 2010. Buch. xvii, 306 S. Hardcover ISBN 978

More information

Basic Testing Concepts and Terminology

Basic Testing Concepts and Terminology T-76.5613 Software Testing and Quality Assurance Lecture 2, 13.9.2006 Basic Testing Concepts and Terminology Juha Itkonen SoberIT Contents Realities and principles of Testing terminology and basic concepts

More information

Software Project Management Plan

<name of project> Software Project Management Plan The document in this file is adapted from the IEEE standards for Software Project Management Plans, 1058-1998, which conforms to the requirements of ISO standard 12207 Software Life Cycle Processes. Tailor

More information

Software development life cycle. Software Engineering - II ITNP92 - Object Oriented Software Design. Requirements. Requirements. Dr Andrea Bracciali

Software development life cycle. Software Engineering - II ITNP92 - Object Oriented Software Design. Requirements. Requirements. Dr Andrea Bracciali Software development life cycle Software life cycle: Software Engineering - II ITNP92 - Object Oriented Software Design Dr Andrea Bracciali Module Co-ordinator 4B86 abb@cs.stir.ac.uk Spring 2014 (elicitation)

More information

Object-Oriented Systems Analysis and Design

Object-Oriented Systems Analysis and Design Object-Oriented Systems Analysis and Design Noushin Ashrafi Professor of Information System University of Massachusetts-Boston Hessam Ashrafi Software Architect Pearson Education International CONTENTS

More information

Domain 1 The Process of Auditing Information Systems

Domain 1 The Process of Auditing Information Systems Certified Information Systems Auditor (CISA ) Certification Course Description Our 5-day ISACA Certified Information Systems Auditor (CISA) training course equips information professionals with the knowledge

More information

Data analytics Delivering intelligence in the moment

Data analytics Delivering intelligence in the moment www.pwc.co.uk Data analytics Delivering intelligence in the moment January 2014 Our point of view Extracting insight from an organisation s data and applying it to business decisions has long been a necessary

More information

D6.1: Service management tools implementation and maturity baseline assessment framework

D6.1: Service management tools implementation and maturity baseline assessment framework D6.1: Service management tools implementation and maturity baseline assessment framework Deliverable Document ID Status Version Author(s) Due FedSM- D6.1 Final 1.1 Tomasz Szepieniec, All M10 (31 June 2013)

More information

Information Systems Development Process (Software Development Life Cycle)

Information Systems Development Process (Software Development Life Cycle) Information Systems Development Process (Software Development Life Cycle) Phase 1 Feasibility Study Concerned with analyzing the benefits and solutions for the identified problem area Includes development

More information

A system is a set of integrated components interacting with each other to serve a common purpose.

A system is a set of integrated components interacting with each other to serve a common purpose. SYSTEM DEVELOPMENT AND THE WATERFALL MODEL What is a System? (Ch. 18) A system is a set of integrated components interacting with each other to serve a common purpose. A computer-based system is a system

More information

Methods Commission CLUB DE LA SECURITE DE L INFORMATION FRANÇAIS. 30, rue Pierre Semard, 75009 PARIS

Methods Commission CLUB DE LA SECURITE DE L INFORMATION FRANÇAIS. 30, rue Pierre Semard, 75009 PARIS MEHARI 2007 Overview Methods Commission Mehari is a trademark registered by the Clusif CLUB DE LA SECURITE DE L INFORMATION FRANÇAIS 30, rue Pierre Semard, 75009 PARIS Tél.: +33 153 25 08 80 - Fax: +33

More information

OPTIMUS SBR. Optimizing Results with Business Intelligence Governance CHOICE TOOLS. PRECISION AIM. BOLD ATTITUDE.

OPTIMUS SBR. Optimizing Results with Business Intelligence Governance CHOICE TOOLS. PRECISION AIM. BOLD ATTITUDE. OPTIMUS SBR CHOICE TOOLS. PRECISION AIM. BOLD ATTITUDE. Optimizing Results with Business Intelligence Governance This paper investigates the importance of establishing a robust Business Intelligence (BI)

More information

Engineering Process Software Qualities Software Architectural Design

Engineering Process Software Qualities Software Architectural Design Engineering Process We need to understand the steps that take us from an idea to a product. What do we do? In what order do we do it? How do we know when we re finished each step? Production process Typical

More information

Management-Forum Strategic MDM

Management-Forum Strategic MDM Management-Forum Strategic MDM Frankfurt / Hilton Frankfurt Airport Value Chain Excellence. Strategy to Results. Master Data Management Strategy Agenda 1 Survey MDM: Strategic Master Data Management (Extract)

More information

IT3203 Fundamentals of Software Engineering (Compulsory) BIT 2 nd YEAR SEMESTER 3

IT3203 Fundamentals of Software Engineering (Compulsory) BIT 2 nd YEAR SEMESTER 3 Fundamentals of Software Engineering (Compulsory) BIT 2 nd YEAR SEMESTER 3 INTRODUCTION This course is designed to provide the students with the basic competencies required to identify requirements, document

More information

CS4507 Advanced Software Engineering

CS4507 Advanced Software Engineering CS4507 Advanced Software Engineering Lectures 2 & 3: Software Development Lifecycle Models A O Riordan, 2015 Some diagrams from Sommerville, some notes from Maciaszek/Liong Lifecycle Model Software development

More information

BAL2-1 Professional Skills for the Business Analyst

BAL2-1 Professional Skills for the Business Analyst 1 BAL2-1 Professional Skills for the Business Analyst OVERVIEW This course trains participants to help business clients articulate their needs and wants, and to document them clearly, concisely, and completely.

More information