Together. Free your energies The Capgemini Approach to Sizing Non-Custom Software Development Projects/Project Elements



Similar documents
Introduction to Service-Oriented Architecture for Business Analysts

The ESB and Microsoft BI

Enterprise Application Designs In Relation to ERP and SOA

ESB solutions Title. BWUG & GSE Subtitle guy.crets@i8c.be. xx.yy@i8c.be

VALLIAMMAI ENGNIEERING COLLEGE SRM Nagar, Kattankulathur

Enterprise Application Integration (EAI) Architectures, Technologies, and Best Practices

Tomáš Müller IT Architekt 21/04/2010 ČVUT FEL: SOA & Enterprise Service Bus IBM Corporation

Managing Data in Motion

1.1 Why this guide is important

Redbook Overview Patterns: SOA Design with WebSphere Message Broker and WebSphere ESB

Approach to Service Management

Emerging Technologies Shaping the Future of Data Warehouses & Business Intelligence

Technical Track Session Service-Oriented Architecture

SOA Standards - Patterns

Enterprise Service Bus Defined. Wikipedia says (07/19/06)

Estimating the Size of Software Package Implementations using Package Points. Atul Chaturvedi, Ram Prasad Vadde, Rajeev Ranjan and Mani Munikrishnan

How To Build A Financial Messaging And Enterprise Service Bus (Esb)

The Way to SOA Concept, Architectural Components and Organization

Getting Started with Service- Oriented Architecture (SOA) Terminology

Business Process Management Tampereen Teknillinen Yliopisto

Service Oriented Architecture

Part 2: The Neuron ESB

Government's Adoption of SOA and SOA Examples

Enterprise Application Integration (EAI) Architectures, Technologies, and Best Practices

Guideline. Enterprise Architecture Guide. 1. Purpose. 2. Scope. 3. Related documents. 4. Enterprise Architecture Guide

Event based Enterprise Service Bus (ESB)

Oracle SOA Suite: The Evaluation from 10g to 11g

SOA and Cloud in practice - An Example Case Study

RS MDMCenter. Integration. Riversand

The four (five) Sensors

Service Oriented Architecture (SOA) Architecture, Governance, Standards and Technologies

Enterprise IT Architectures SOA Part 2

Spring 2011 Conference Sandanski, May 13th 15th 2011 Oracle SOA Suite 11g Rapid service integration and process automation with a no-coding approach

XML Signatures in an Enterprise Service Bus Environment

Air Force SOA Enterprise Service Bus Study Using Business Process Management Workflow Orchestration for C4I Systems Integration

Service Oriented Architecture Case: IBM SOA Reference Architecture

Service-Oriented Architectures

SCA-based Enterprise Service Bus WebSphere ESB

Salesforce integration with Enterprise Open Source. Mischa de Vries László van den Hoek SFDC Consultant OS Consultant

SERVICE ORIENTED ARCHITECTURE

Extending SOA Infrastructure for Semantic Interoperability

EAI OVERVIEW OF ENTERPRISE APPLICATION INTEGRATION CONCEPTS AND ARCHITECTURES. Enterprise Application Integration. Peter R. Egli INDIGOO.

IBM WebSphere ESB V6.0.1 Technical Product Overview

Enterprise Reference Architecture

Service Oriented Architecture 1 COMPILED BY BJ

Motivation Definitions EAI Architectures Elements Integration Technologies. Part I. EAI: Foundations, Concepts, and Architectures

Federal Enterprise Architecture and Service-Oriented Architecture

SOMA, RUP and RMC: the right combination for Service Oriented Architecture

Presentation Outline. Key Business Imperatives Service Oriented Architecture Defined Oracle SOA Platform SOA Maturity/Adoption Model Demo Q&A

3-Tier Architecture. 3-Tier Architecture. Prepared By. Channu Kambalyal. Page 1 of 19

SOA Planning Guide The Value Enablement Group, LLC. All rights reserved.

Customer Information Management. Amanda McIntyre, Vice President, Product Manager Glenn Sonsalla, Vice President, Enterprise Strategy & Governance

INTEGRATING ESB / BPM / SOA / AJAX TECHNOLOGIES

Sadržaj seminara: SOA Architecture. - SOA Business Challenges s: Billion Dollar Lock-In. - Integration Tools. - Point-to-Point Approach

Reporting component for templates, reports and documents. Formerly XML Publisher.

Chapter 15. Web services development lifecycle

Introduction to WebSphere Process Server and WebSphere Enterprise Service Bus

A Distributed Approach to Business Intelligence Systems Synchronization

White Paper. TIA Architecture Overview

Implementation of Information Integration Platform in Chinese Tobacco Industry Enterprise Based on SOA. Hong-lv Wang, Yong Cen

G-Cloud Framework Service Definition. Master Data Management and Identity Resolution Service

Myths About Service-Oriented Architecture Demystifying SOA. producers can coexist, and still have no dependence on each other.

Establish and maintain Center of Excellence (CoE) around Data Architecture

"An infrastructure that a company uses for integrating services in the application landscape."

Service Mediation. The Role of an Enterprise Service Bus in an SOA

Oracle Business Activity Monitoring 11g New Features

Business Process Management Enabled by SOA

AquaLogic Service Bus

SAP NetWeaver & Enterprise Services Architecture

Enterprise Integration Architectures for the Financial Services and Insurance Industries

Architectuur hulpmiddelen TechnoVision & CORA. Maarten Engels Nieuwegein, 9 februari 2012

SOA Success is Not a Matter of Luck

Service-Oriented Architecture and Software Engineering

WHITE PAPER. Enabling predictive analysis in service oriented BPM solutions.

Federated Service Oriented Architecture for Effects-Based Operations

RED HAT JBOSS FUSE SERVICE WORKS 6 COMPARED WITH MULE ESB ENTERPRISE 3.4

Service Oriented Architecture (SOA) Architecture, Governance, Standards and Technologies

Principles and Foundations of Web Services: An Holistic View (Technologies, Business Drivers, Models, Architectures and Standards)

Developing SOA solutions using IBM SOA Foundation

SOA and SaaS - new challenges

A Practical Perspective on the Design and Implementation of Enterprise Integration Solution to improve QoS using SAP NetWeaver Platform

End-To-End Invoice Processing Automation at Land O Lakes. Session #705. Natalie Hawley, Applications Developer

ATHABASCA UNIVERSITY. Enterprise Integration with Messaging

Oracle SOA Suite/B2B as a Critical Mission Hub for a High Volume Message Use Case

Bridging the Digital Divide with Net-Centric Tactical Services

Service Oriented Architecture (SOA) An Introduction

SONIC ESB: AN ARCHITECTURE AND LIFECYCLE DEFINITION

Avoiding Web Services Chaos with WebSphere Service Registry and Repository

Table of Contents. 1 Executive Summary SOA Overview Technology Processes and Governance... 8

The Synergy of SOA, Event-Driven Architecture (EDA), and Complex Event Processing (CEP)

AquaLogic ESB Design and Integration (3 Days)

A SOA Based Framework for the Palestinian e-government Integrated Central Database

Transcription:

Together. Free your energies The Capgemini Approach to Sizing Non-Custom Software Development Projects/Project Elements Carl Bideau 14 th October 2010

CONTENTS 1. Recap on sizing of custom software development projects 2. How to size non-csd projects (e.g. Application Integration)? 3. The challenge of hybrid projects including non-csd elements 4. Key principles 5. Questions & Discussion 2

1. Recap on Sizing of CSD Projects: Options for CSD Sizing Measures (Why not FP?) Industry-standard measure (e.g. Function Points) versus In-house-developed measure (e.g. Capgemini Use Case Points) Function Points Count Capgemini Use Case Points Count Advantages An industry standard Available early in project Relatively cheap & easy to use Fits in with Use Case method for requirements capture Has meaning throughout lifecycle Disadvantages Requires expertise in FP counting Expensive to count (2-3% of budget) Non-intuitive empirical measure that has no meaning & some odd rules Not easy to use at bid stage Terminology & concepts do not map well on to modern tools & methods No industry guidelines so cannot be used for productivity benchmarking (but could translate to FP) Measure functional size only (but non-funcs are a productivity factor!) Mark I FPs are fairly common within the industry & some industry metrics available In Capgemini we have found that Capgemini Use Case Points work best for us 3

1. Recap on Sizing of CSD Projects: Capgemini Use Case Points (UCPs) What are Capgemini use case points? In software engineering, use cases are just a structured way of capturing the user requirements Capgemini use case points (UCP) are a means by which the functional content of an application s use cases can be quantified / sized in points UCPs are an abstract size measure calculated by: Quantifying the number & complexity of Use Case components: Flows, Boundary Classes & Business Rules Associating each measure total with their own points scale Applying an average across the individual measured totals to arrive at an overall points total for the Use Case A typical small use case equates to approximately 1 UCP! Problem: FP & UCP measures only work for sizing Custom Software Development! You can find a copy of the Capgemini Use Case Sizing Guidelines template on the UKSMA website at: http://www.uksma.co.uk/capgeminiucp.asp 4

CONTENTS 1. Recap on sizing of custom software development projects 2. How to size non-csd projects (e.g. Application Integration)? 3. The challenge of hybrid projects including non-csd elements 4. Key principles 5. Questions & Discussion 5

2. How to Size Non-CSD Projects (e.g. Application Integration)? Use of Application Integration as an Example The sizing of Application Integration elements in a project requires a different sizing approach to that used for custom software development. In this presentation Application Integration is used as an example of how Capgemini has sized project types other than custom software development. Definition: In this context: Application Integration refers to the technical mechanisms for transmitting data/messages from one application to another but excludes the business logic for generating and processing the message in each of the end point systems. 6

2. How to Size Non-CSD Projects (e.g. Application Integration)? Capgemini Application Integration Sizing Method In Capgemini we do not model the technical detail i.e. Ignore the (many & changing!) particular toolsets & packages to be used Instead we capture the AI scope i.e. Consider the Integration patterns to be delivered We do this by quantifying & defining the complexity of the following building blocks: Service / Adapter the technology to connect the Endpoint to the Integration environment to send / receive data. Not the business logic of the application/service itself Transport the physical means of sending and receiving data from one end point to another e.g. TCP/IP, FTP over TCP/IP, Message queues & channels, VPNs, leased lines. Dataflow / Mediation mediation product intervention. 7

2. How to Size Non-CSD Projects (e.g. Application Integration)? Integration Stack Elements/Building Blocks Business Process Management Short-lived, fully automated process orchestration through to longer lived, partial human-interaction work flow This shows the diagrammatic conventions! For large-scale BPM, estimate this as a separate project - do not use the AI sizing approach. For smaller-scale process orchestration, specify additional Dataflows to represent processes. Dataflow / Mediation This represents all activity relating to the mediation of data, i.e. all processing applied to data from the point it leaves its source to the point it reaches its target. This includes Data Transformation, small scale Process Orchestration, Routing rules, Service Registry access, cross reference lookups as well as message format definitions XML / XSD structures - SOAP, canonical message formats etc Transport This is the physical means by which data gets to or from the Service / Adapter to the rest of the Integration environment. Examples include Message Queue channels, VPN tunnels, <tag>d atadata data</ For ad hoc small scale process orchestration, include additional Dataflows. Mediation, e.g. ESB layer, broker, process orchestration or any intervening component Message type / format <tag>datadata data</tag> <tag>datadata </tag> <tag>dat A Dataflow = a Message sent from one Endpoint system to another in one direction Service / Adapter The term Service/Adapter means the technology responsible for getting data into or out of an Endpoint System. This may be a Web Service definition (WSDL), a file based mechanism, database connectivity, a put or get operation on a queue etc. It is not the business logic of the application or service itself: it is the interfacing code only. Endpoint Systems / Applications the Applications to be Integrated, including the CSD development itself, if applicable 8

2. How to Size Non-CSD Projects (e.g. Application Integration)? Example Application Integration Patterns Request / Reply a b Federated ESB / Brokers EAI style Hub & Spoke Environment Coarse Grained SOA services, comprised of Fine Grained internal services 9

2. How to Size Non-CSD Projects (e.g. Application Integration)? Building Block Complexity List the endpoint systems together with their associated Adaptors & Transport requirements. Separately list the required dataflows. Use complexity factors to adjust the size of each of the identified building blocks: Service / Adapter Increase the complexity to: o Represent additional tooling and therefore effort in what is done to get an application sending or receiving data o No adapter work = 100% reuse, but still select the complexity for documentation Transport Increase complexity to acknowledge (e.g.): o Message queuing effort o Network layer work e.g. firewalls, ISP config Dataflow / Mediation Increase complexity to acknowledge that the following products are being used (e.g.): o Message Brokers o ESB central components o Service Registries o Process Orchestration (Simple to medium) o Effort includes definition of message formats 10

AI Points Calculation 2. How to Size Non-CSD Projects (e.g. Application Integration)? Summary of Capgemini AI Points Calculation Activity Customise adapters: Total Adaptor Points = Σ of points for each Adaptor Activity - Develop / configure transport mechanism: Total Transport Points = Σ of points for each Transport Activity - Maintain Interface catalogue + Produce common data formats (Canonical): Total Dataflow Points = Σ of points for each Dataflow Total AI Points = Adaptor Points + Transport Points + Dataflow points Design/Implementation/Testing Size in AI points Adaptors Transport Dataflows Simple 3.5 0.7 2.5 Medium 7.0 1.4 5.0 Complex 14.0 2.7 10.0 Very Complex 28.0 5.4 20.0 e.g. a medium complexity Dataflow is 5 Capgemini AI points Add 20% to points for Adaptor if Adaptor is external to client LAN Add 20% to points for Transport or Dataflow if Transport or Dataflow traverses the Internet or a WAN. Function Points Approximation To convert to Function Point Equivalents multiply AI Points by gearing factor of 3.87 11

2. How to Size Non-CSD Projects (e.g. Application Integration)? Example of Publish / Subscribe AI Pattern Sizing Endpoint system a publishes data to a publish/subscribe engine, which six other endpoint systems subscribe to: For the example shown, configure: 7 Endpoint systems, each with 1 Service / Adapter 1 Dataflow in total, which is Endpoint a publishing the data

2. How to Size Non-CSD Projects (e.g. Application Integration)? Example of Publish / Subscribe AI Pattern Sizing The complexities of the Service / Adapter and Transport of the 6 subscribers account for their subscription calls

2. How to Size Non-CSD Projects (e.g. Application Integration)? Requirements Size for Adapters & Transport The size of Requirements work may not be the same as the size of Design/Implementation/Test since non-technical factors can make it simple/difficult to ascertain the requirements For Adapters & Transport: Requirements size = (Requirements Complexity) x (Adapter or Transport size) Requirements complexity: Extent to which it is straightforward/complex to work with endpoint system owner to get info. & authorization needed to establish a connection with their system. Simple E.g. System owner is internal to client organization & has experience with interfacing their system. Medium E.g. Private sector client who is motivated to co-operate. Complex E.g. Workshops will be required to agree the interface definitions - no other regular contact is feasible. Very Complex E.g. External system itself is being changed to support another project's requirements. Requirements Complexity Simple 3.5 Medium 7.0 Complex 14.0 Very Complex 28.0 See slide notes for further examples 14

2. How to Size Non-CSD Projects (e.g. Application Integration)? Integration Scenarios (Patterns) Using the building blocks approach it is possible to model most Integration scenarios (patterns): Request / Reply Publish / Subscribe Batch File Transfer Web Services Coarse Grained SOA Services EAI style Hub and Spoke Environment Services Registry / Repository / Adaptive Composite Services Federated ESB / Brokers Canonical Message Formats Includes legacy approaches through to contemporary & strategic approaches! The more the estimator knows about the proposed implementation, the more accurate the estimate 15

CONTENTS 1. Recap on sizing of custom software development projects 2. How to size non-csd projects (e.g. Application Integration)? 3. The challenge of hybrid projects including non-csd elements 4. Key principles 5. Questions & Discussion 16

3. The Challenge of Hybrid Projects Sizing Units: Horses for Courses There is no single sizing unit that works well for all types of project: Use Case Points or Function Points are fine for measuring custom software development but no one would dream of using them for a large scale SAP implementation! We have seen that Capgemini Use Case Points work well for CSD projects but they don t measure the right characteristics to be useful for AI projects Solution: We use Capgemini AI points instead! There is currently no single sizing method that will work for all project types - Each type of project requires its own specific sizing measure! 17

3. The Challenge of Hybrid Projects Sizing of Hybrid Projects Hybrid projects contain >1 project type such as CSD+AI (or SAP+CSD+BI etc.) CSD element sized in Capgemini Use Case Points (UCPs) or sometimes in FPs Application Integration part is sized in Capgemini AI points BUT: We need a single measure of size for the total project SOLUTION: Size each project type using units applicable to that type Use gearing factors to translate each into a common sizing unit (FP equivalents): Project Size = CSD Functional Size + AI Functional Size Note: Non-functional requirements size is addressed via productivity factors 18

NESMA FP Count 3. The Challenge of Hybrid Projects Work Still to Do 1 Continue to analyse current relationship between UCPs & FPs and update/derive accurate UCP to FP gearing factors: 1,800 1,600 1,400 1,200 1,000 800 600 400 200 0 Function Points versus UCP Gearing R² = 0.9828 0 20 40 60 80 100 Capgemini UCP Count The chart above plots the relationship between NESMA Function Points and Capgemini Use Case Points using 2008 Capgemini Dutch data. The chart shows that here is a good correlation between the Capgemini use case sizing and Function Points giving confidence that the UCP method works. 19

3. The Challenge of Hybrid Projects Work Still to Do 2 Define reliable SLOC to FP gearing factors So that we can size existing applications easily using a SLOC count Some challenges with reliability of published SLOC to FP gearings! Finalise sizing measures for the following project types: (including gearing factors to convert to FP equivalents) RUP CSD Capgemini UCP - complete Application Integration Capgemini AI points - complete SAP Implementation Capgemini SAP points - early draft Oracle Implementation Capgemini Oracle points - early draft Business Intelligence Capgemini BI points - nearly complete Data Migration Capgemini DM points - complete Information Management Capgemini IM points - SharePoint element complete 20

3. The Challenge of Hybrid Projects Example of Another Project Type: SharePoint Taking the Capgemini CSD Use Case Sizing Guidelines as a model an Excel spreadsheet was developed for sizing SharePoint This takes data from 7 core input areas & generates an overall sizing in SharePoint Points (SP) 21

CONTENTS 1. Recap on sizing of custom software development projects 2. How to size non-csd projects (e.g. Application Integration)? 3. The challenge of hybrid projects including non-csd elements 4. Key principles 5. Questions & Discussion 22

4. Key principles Sizing Units for Productivity Measurement Using gearing factors to translate between sizing units compromises accuracy it is only ever an approximation! To estimate project effort it is safest to use the most appropriate sizing unit for that project type Sometimes we cannot avoid converting into common sizing units to calculate a total size for the project For retrospective productivity measurement the same issue applies: it will be most accurate to calculate productivity in terms sizing units that are most relevant for that project type In any case why would you want to compare the productivity of a CSD project with an AI one? This is like comparing apples with oranges! Hybrid projects (e.g. CSD + AI) are a problem: the only options are: Convert the sizes to common sizing units (e.g. FP equivalents) Group projects: e.g. into Pure CSD, Pure AI, Hybrid for comparison purposes 23

CONTENTS 1. Recap on sizing of custom software development projects 2. How to size non-csd projects (e.g. Application Integration)? 3. The challenge of hybrid projects including non-csd elements 4. Key principles 5. Questions & Discussion 24

5. Questions & Discussion 25

Together. Free your energies www.capgemini.com The information contained in this presentation is proprietary. 2010 Capgemini. All rights reserved