December 2008, Geneva Dr Alexander Samarin Business Process Management (BPM) Context for testing.

Slides:



Advertisements
Similar presentations
Integrated Platform version 5.2
Advertisements

Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
Crucial Patterns in Service- Oriented Architecture Jaroslav Král, Michal Žemlička Charles University, Prague.
Workpackage 2: Norms
360 Process Engine Automagic ECM
BPMN 2.0 Interchange: W5 Denis Gagné, CEO & CTO Trisotech BPMN 2.0 FTF Member XPDL 2.2 and 3.0 Co-Editor.
ARCH-01: Introduction to the OpenEdge™ Reference Architecture Don Sorcinelli Applied Technology Group.
1 Introduction to modeling Process modelling. 2 Where are we? #TitleDate 1Introduction ORM modeling Relational modeling
T-FLEX DOCs PLM, Document and Workflow Management.
4.1 Blended approaches: Information Engineering IMS Information Systems Development Practices.
Object-Oriented Analysis and Design
Use-case Modeling.
L4-1-S1 UML Overview © M.E. Fayad SJSU -- CmpE Software Architectures Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I.
Lesson-10 Information System Building Blocks(2)
Discovering Computers Fundamentals, 2011 Edition Living in a Digital World.
1 Objectives To introduces the concept of software Design. To introduce the concept of Object- Oriented Design (OOD). To Define various aspects about object.
Creating Architectural Descriptions. Outline Standardizing architectural descriptions: The IEEE has published, “Recommended Practice for Architectural.
The Role of Modeling in Systems Integration and Business Process Analysis © Sparx Systems Pty Ltd 2011 Ben Constable Sparx Systems.
Business Process Management with Activiti João Silva (CERN, GS-AIS) 21st of October, 2014 BUSINESS PROCESS MANAGEMENT WITH ACTIVITI.
David Harrison Senior Consultant, Popkin Software 22 April 2004
Tool support for Enterprise Architecture in System Architect Architecture Practitioners Conference, Brussels David Harrison Senior Consultant, Popkin.
Enterprise Architecture
Process-oriented System Automation Executable Process Modeling & Process Automation.
From agile development to agile evolution of enterprise systems 1 From agile development to agile evolution of enterprise systems Dr Alexander.
Introduction to Systems Analysis and Design Trisha Cummings.
The Database Development Process
LAYING OUT THE FOUNDATIONS. OUTLINE Analyze the project from a technical point of view Analyze and choose the architecture for your application Decide.
SWE 316: Software Design and Architecture – Dr. Khalid Aljasser Objectives Lecture 11 : Frameworks SWE 316: Software Design and Architecture  To understand.
ITEC224 Database Programming
Aug 8, a|EA-DC Forumaeaassociation.org 1 Serve Actionable Knowledge Empower Agile Architects Tyson Brooks, BAE Systems Haiping Luo, Government Printing.
CONTENTS Arrival Characters Definition Merits Chararterstics Workflows Wfms Workflow engine Workflows levels & categories.
11 Using SPIRIT for describing systems to debuggers DSDP meeting February 2006 Hobson Bullman – Engineering Manager Anthony Berent – Debugger Architect.
Chapter 10 Information Systems Analysis and Design
1 The Software Development Process  Systems analysis  Systems design  Implementation  Testing  Documentation  Evaluation  Maintenance.
OOI CI LCA REVIEW August 2010 Ocean Observatories Initiative OOI Cyberinfrastructure Architecture Overview Michael Meisinger Life Cycle Architecture Review.
Approaching a Problem Where do we start? How do we proceed?
Chapter 7 Software Engineering Introduction to CS 1 st Semester, 2015 Sanghyun Park.
Software Construction Lecture 18 Software Testing.
Slide 12.1 Chapter 12 Implementation. Slide 12.2 Learning outcomes Produce a plan to minimize the risks involved with the launch phase of an e-business.
Unified Modeling Language* Keng Siau University of Nebraska-Lincoln *Adapted from “Software Architecture and the UML” by Grady Booch.
Lyra – A service-oriented and component-based method for the development of communicating systems (by Sari Leppänen, Nokia/NRC) Traditionally, the design,
L6-S1 UML Overview 2003 SJSU -- CmpE Advanced Object-Oriented Analysis & Design Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College.
Chapter 10 Software Engineering. Understand the software life cycle. Describe the development process models. Understand the concept of modularity in.
Requirements Engineering Southern Methodist University CSE 7316 – Chapter 3.
Agile SOA Agile EAI How do we achieve agility in Enterprise Integration?
Requirements Management with Use Cases Module 10: Requirements Across the Product Lifecycle Requirements Management with Use Cases Module 10: Requirements.
PROGRAM DEVELOPMENT CYCLE. Problem Statement: Problem Statement help diagnose the situation so that your focus is on the problem, helpful tools at this.
1 SOA Across Business and IT How do I optimize my business processes? Business Models Identify Process Tasks I/T Components exposed as SOA Services How.
Chapter 8 Testing. Principles of Object-Oriented Testing Å Object-oriented systems are built out of two or more interrelated objects Å Determining the.
Topic 4 - Database Design Unit 1 – Database Analysis and Design Advanced Higher Information Systems St Kentigern’s Academy.
CIS 4910 Information Systems Development Project Project Documentation.
Winter 2011SEG Chapter 11 Chapter 1 (Part 1) Review from previous courses Subject 1: The Software Development Process.
Software Requirements Specification (SRS)
1 The Software Development Process ► Systems analysis ► Systems design ► Implementation ► Testing ► Documentation ► Evaluation ► Maintenance.
21/1/ Analysis - Model of real-world situation - What ? System Design - Overall architecture (sub-systems) Object Design - Refinement of Design.
CMSC 2021 Software Development. CMSC 2022 Software Development Life Cycle Five phases: –Analysis –Design –Implementation –Testing –Maintenance.
Viewpoint Modeling and Model-Based Media Generation for Systems Engineers Automatic View and Document Generation for Scalable Model- Based Engineering.
® IBM Software Group © 2009 IBM Corporation Viewpoints and Views in SysML Dr Graham Bleakley
CTMS Coordination Team CTMS Coordination Team: Model and Documentation Management John Koisch Paul Boyes
ECA 2010, Geneva, Switzerland Creating a synergy between BPM
Roberta Roth, Alan Dennis, and Barbara Haley Wixom
Architecture Concept Documents
Computer Aided Software Engineering (CASE)
Component Based Software Engineering
Dokumentasi Perubahan Proses: Pengantar BPM
Chapter 10: Process Implementation with Executable Models
Enterprise Data Model Enterprise Architecture approach Insights on application for through-life collaboration 2018 – E. Jesson.
Applying Use Cases (Chapters 25,26)
Applying Use Cases (Chapters 25,26)
Dr. Jiacun Wang Department of Software Engineering Monmouth University
Presentation transcript:

December 2008, Geneva Dr Alexander Samarin Business Process Management (BPM) Context for testing

About me An enterprise solutions architect –From a programmer to a systems architect –Experience in scientific, international, governmental and industry environments: CERN, ISO, IOC, BUPA, Groupe Mutuel, State of Geneva, EDQM, Bund ISB –Have created systems which work without me –Current specialisation is improving business process management systems –How to use together BPM, SOA, EA, ECM and IT governance BPM: Context for testing 2

BPM as a tool for enterprise performance management Enterprise business performance improvement Service- and process-centric enterprise Continual process improvement BPM discipline –model, automate, control, execute, measure, optimise Enterprise BPM system –set of business processes as well as practices and tools for governing its design, execution and evolution BPM suite or Business Process Platform (BPP) –coherent set of software tools for facilitating the implementation of a BPM system BPM: Context for testing 3

The goal – easy evolution of a BPM system Experience shows that business wants separate requests for change to be implemented quickly These changes are typically small (from the point of view of the business) and unpredictable (from the point of view of IT) To carry out these changes easily and in a managed way, BPM systems must be properly architected & implemented & engineered BPM: Context for testing 4

Too many stakeholders of BPM Strategy –top manager Business –manager –process owner –super-user –user Project –manager –business analyst IT –manager –enterprise architect –architect –developer –operator 5 BPM: Context for testing

Modelling of business processes is communication between people Architecture (global) principles –Versionable artefacts –Digital, external, and virtual artefacts –All relationships are modelled explicitly –All models are made to be executable Diagramming style in BPMN A dozen practical patterns Structuring for better “executability” Modelling procedure Use a common tool for prototyping (e.g. Intalio) BPM: Context for testing 6

Service as white box Process Service as black box Processes and services 7 BPM: Context for testing

BPMN is a victim of its success Typical Internet age “standard” – a draft proposal with a collection of features already implemented by participants –Too many shapes Deliberate absence of execution semantic in version 1.x –Too simples to draw Each tool interprets BPMN in its own way (e.g. Intalio does it via BPEL) Battle around BPMN 2.0 is a fight between vendors BPM: Context for testing 8

Diagramming style in BPMN Pools –One or more explicit coordination pools –Human –Services –DISPATCH Naming convention Use of colours –Task meaning –Task performers 9 BPM: Context for testing

Practical patterns Automated, Human, Automated Man & Machine Decoupled Business Logic Initial Process Skeleton Error Recovery Loop Structure Your Process Decide, Execute, Control BPM: Context for testing 10

The modelling procedure Its purpose is –to analyse a building block (what it is supposed to do) –to synthesise its implementation (how it does this) as the explicit coordination of other building blocks (processes or activities) It is iterative – we can apply it until we have left only indivisible building blocks (i.e. activities) Artefacts are constructed recursively, like Russian dolls BPM: Context for testing 11

Four phases BPM: Context for testing 12

Testing in Intalio BPMN -> BPEL proprietary interpretation, but with explicit use of events Each process is a service (for unit testing) Manual trace for flow test (many clicks) Support for XSD and XML instances (good enough to define different test scenarios) BPM: Context for testing 13

Unstructured vs structured diagramming Unstructured Structured + explicit use of events for sync Actually, 2 pools for coordination BPM: Context for testing 14 Executed twice!

Ideal situation – BPMN for users, but for vendors Direct interpretation of BPMN –Standard and validatable execution semantic –Hide use of intermediate formats Different levels of BPMN Better understanding of BPMN events Extra standards maybe necessary, as for HTML –XHTML (structure and content) –CSS (presentation) –DOM-based API (dynamic modification) Vendors compete in compliance and performance BPM: Context for testing 15

Thanks Dr Alexander Samarin 16 BPM: Context for testing