CDC UNIFIED PROCESS PRACTICES GUIDE

Transcription

1 Purpose The purpose of this document is to provide guidance on the practice of Modeling and to describe the practice overview, requirements, best practices, activities, and key terms related to these requirements. In addition, templates relevant to this practice are provided at the end of this guide. Practice Overview Models are used to simplify complex ideas usually into a pictorial form. In an effort to identify opportunities to simplify processes and unify work across federal agencies OMB has created the Federal Enterprise Architecture (FEA) Business Process Model (BPM). HHS has expanded upon OMB s model by further sub-dividing it into the HHS Enterprise Architecture (EA) Framework. This document provides an overview of these, and other, models and approaches to modeling. At the highest of levels, Business Process Modeling and Data Modeling are recognized as integral parts of a project s design phase because efficient organization of information contributes to good system design and development. Models are used to outline the entire system, define screens, reports, and processes needed to capture, update, retrieve, and delete system data. How modeling is used and managed has consequences that can ripple throughout the life of the system as well as other systems that may access its data. A process model is a representation of a process describing the current or intended future state of that process. Business processes are the structures by which an organization physically does what is necessary to produce value for customers. Business Processes define the specific order of activities across time and document and inputs and outputs. Every system and/or database is specified by a data model, even if only implicitly. A data model describes how data is represented in the system and/or database and any relationships between entities and attributes, usually in the form of a diagram. Well designed models make programming a system simpler, cheaper, faster, and improve quality. Poorlydesigned models can have the opposite effect. However, when designing a model more often than not there are several ways to organize and work with the same type of data. As a result Business Analysts often generate multiple candidate data models by analyzing business models and functional requirements. Asking the right questions early in the project s life and using the answers to design the best possible models requires an understanding of data modeling, business processes, and the system s requirements. Defining the most appropriate and accurate model early is essential because even a small change later in the project s life cycle often has an expensive impact on the overall system. Some factors that contribute to a good data model may include: Completeness Non-redundancy Enforcement of business rules Stability and flexibility Federal Enterprise Architecture Business Process Model In an effort to identify opportunities to simplify processes and unify work across federal agencies OMB has created the Federal Enterprise Architecture (FEA) Business Process Model (BPM) to maximize technology investment success. All systems must demonstrate traceability to the Federal Enterprise Architecture (FEA). The FEA is an initiative led by OMB to identify opportunities to simplify processes and unify work across agencies. The FEA is designed using a collection of interrelated reference models to facilitate cross-agency analysis and the identification of duplicative investments, gaps, and opportunities. Its foundation is the Business Reference Model, which is made up of the following five reference models: UP Version: 12/31/07 Page 1 of 5

2 Performance Reference Model - is a standardized framework to measure the performance of major IT investments and their contributions to program performance. This model helps produce enhanced performance information to improve strategic and daily decision-making; improves the alignment and better articulates the contribution of inputs to outputs and outcomes; and identifies performance improvement opportunities that span traditional organizational structures and boundaries. Business Reference Model - is a function driven framework that describes the Lines of Business and Internal Functions performed by the Federal Government independent of the agencies that perform them. All IT investments (including non-major) are mapped to the BRM to identify collaboration opportunities. Service Component Reference Model - provides a common framework and vocabulary for characterizing the IT and business components that collectively comprise an IT investment. The SRM will help agencies rapidly assemble IT solutions through the sharing and reuse of business and IT components. A component is a self contained process, service, or IT capability with predetermined functionality that may be exposed through a business or technology interface. Data Reference Model - describes, at an aggregate level, the data, and information that supports government program and business line operations. This model enables agencies to describe the types of interaction and exchanges that occur between the Federal Government and citizens. Technical Reference Model - provides a framework to describe the standards, specifications, and technologies supporting the delivery, exchange, and construction of business (or service) components and egov solutions. The Federal TRM unifies existing Department TRMs and electronic Government guidance by providing a foundation to advance the reuse of technology and component services from a government wide perspective. Department of Health and Human Services Enterprise Architecture Framework The HHS EA Framework has been organized hierarchically into an eight-layer model where the initial layers represent higher levels of abstraction identifying business and strategic concerns, while subsequent layers focus on more detailed aspects of the architecture typically more technical or detailed in nature. The layers of the HHS EA Framework map directly to layers within the FEABPM. For more information on the HHS EA Framework visit the HHS Office of Enterprise Architecture at: Data Modeling In addition to the FEA there are a number of industry recognized modeling standards and variations of those standards, each having their own terminologies not always consistent with each other. However, regardless of which modeling approach is used, there are three primary overarching approaches that are used as the project progresses from defining business requirements and system specification to design (refer to the CDC UP Requirements Practices Guide for information on gathering and managing requirements). The exact level of detail that should be produced using each of these approaches will vary depending on the experience of the project team, the development environment, the complexity of the system being developed, and the detail to which the system requirements have been specified. Conceptual Data Model - Models the underlying business irrelevant of technology. The conceptual design can be divided into three sub-models that attempt to identify high-level relationships among system entities. These models include: Data Model - Identifies and defines data entities and any relationships between them UP Version: 12/31/07 Page 2 of 5

3 Business Function Model - Identifies and defines component business functions Communication Model - Maps interactions between business functions and data Logical Data Model - Translates the conceptual model into a structure that can be implemented, by describing the data in as much detail as possible, without regard to how it may be physically implemented. It models all entities and any relationships among them, defines attributes, and normalizes data. Normalization of data is the process of organizing data and breaking it into smaller tables that are easier to manage. The primary reason to normalize data is to prevent redundancy. Some steps for creating a logical data model may include: Identifying all entities Specifying primary keys for all entities Identifying the relationships between different entities Finding all attributes for each entity Resolving many-to-many relationships Normalizing data (Normalization) Physical Data Model - Specifies how to physically implement the logical design by specifying items such as tables, columns, formal relationships between data and tables, etc. Some steps for creating a physical data model may include: Converting entities into tables Converting relationships into foreign keys Converting attributes into columns Modifying physical data models based on physical constraints and requirements Business process models serve as the basis for analyzing, understanding, and building a system that support business processes. Some well-known modeling approaches include: Context Diagram - A graphical representation of the highest levels of a system illustrating data sources and how data flow between them Data Flow Diagram - A detailed graphical representation of how data flows through the system and how that system stores and processes that data Decision Tables Are used to clarify complex decision making situations they lay out, in tabular form, all possible situations which a business decision may encounter and specify what action the system should take in response to each of those situations When actually illustrating how data will be physically stored in a system a three layer architecture schema may be appropriate. This three-layer approach insulates users from any potential changes to the physical data, database tables, columns, fields, relationships, etc. The three-layer schema approach includes: Conceptual Schema - Describes the organization of data into tables and columns Internal Schema - Describes how data will stored and accessed External Schema - Describes views that enable users to see the data in different ways Models should document business functions separate from the technology used to implement them. The business and technical aspects of a system can then each evolve as needed responding to changing business needs and technology advancements. Systems are designed to implement business process models that outline the business functions that the system is to perform. System databases are specified using a data model that describes what data will be stored and how it will be organized. Some established modeling standards include: Federal Enterprise Architecture (FEA) Business Reference Model (BRM) Department of Health and Human Services Enterprise Architecture Framework (HHS EA Framework) Unified Modeling Language (UML) Meta-Object Facility (MOF) Common Warehouse Meta-model (CWM) Model Driven Architecture (MDA) Integrated Definition (IDEF) UP Version: 12/31/07 Page 3 of 5

4 Some of the individuals involved in the modeling process may include: Business/System Analysts (Modelers) - Design and develop models and ensuring that stakeholders understand the implications of any changes Subject Matter Experts - Verify the accuracy and stability of the models Designers - Assess whether or not the physical data model needs to differ from the logical data model to achieve adequate performance Sponsors/Users - Verify that models conform with the functional requirements as expected Best Practices The following best practices are recommended for Modeling: Active Stakeholder Participation - Access is needed for users that have the authority and ability to provide information regarding the system being built Team Modeling - Modeling is a group activity that requires input from several people Prove It - A model is an abstract that should accurately reflect the business requirements. But will it work? Prove the model with code Small Increments - Build models incrementally by organizing larger pieces of effort into smaller portions of manageable work Several Models - More often than not there are several ways to organize and work with the same data. Often multiple candidate data models are developed Simple - Keep model content, requirements, analysis, design, etc as simple as possible Review and Approve - Review all models to ensure they fulfill the functional requirements Traceability - Models should be directly traceable to satisfy defined requirements Assumptions/Constraints - Record and address all assumptions, constraints, issues, etc Notation - Models should be recorded using an appropriate design notation Practice Activities For software development projects the following practice activities are appropriate: Guidelines - Define and document modeling guidelines such as recording of assumptions, constraints, issues, approaches, documentation, templates, and notations Business Process Specification - Define the intended future state of business processes Functional Specification - Define the functional part(s) of the system being developed, external relationships, interaction with the user and other system elements Logical Specification - Define the internal logic of the system explaining how it operates Conceptual Data Model - Models the underlying business irrelevant of technology Logical Data Model - Translates the conceptual model into a structure that can be implemented, by describing the data in as much detail as possible, without regard to how it may be physically implemented Physical Data Model - Specifies how to physically implement the logical design by specifying items such as tables, columns, formal relationships between data and tables, etc Evaluation - Validates the effectiveness of the models that were developed. This is usually accomplished via user feedback Verification - Verify each step within each model to ensure traceability to requirements that delivers the expected system functionality Practice Attributes This section provides a list of practice attributes to help project teams determine when and how Modeling impacts a project. Practice Owner Criteria CDC UP Project Office NCPHI All projects regardless of type or size should document system design and UP Version: 12/31/07 Page 4 of 5

5 Estimated Level of Effort Prerequisites Practice Dependencies Practice Timing in Project Life Cycle Templates/Tools Additional Information design efforts and how they are performed and managed through the system life cycle. Significant Requirements analysis Requirements Management Practices Guide Modeling fits between the requirements phase and development phase of a project s life cycle Modeling Checklist OMB Business Reference Model HHS Enterprise Architecture Framework Business Process Modeling Notation Key Terms Follow the link below to for definitions of project management terms and acronyms used in this document. Related Templates/Tools Below is a list of template(s) related to this practice. Follow the link below to download the document(s). Modeling Checklist UP Version: 12/31/07 Page 5 of 5

Document Purpose The purpose of this document is to provide guidance on the practice of Quality Management and to describe the practice overview, requirements, best practices, activities, and key terms

U.S. Department of the Treasury Treasury IT Performance Measures Guide Office of the Chief Information Officer (OCIO) Enterprise Architecture Program June 2007 Revision History June 13, 2007 (Version 1.1)

SOA + BPM = Agile Integrated Tax Systems Hemant Sharma CTO, State and Local Government Nothing Endures But Change 2 Defining Agility It is the ability of an organization to recognize change and respond

Enterprise Architecture and Portfolio Management: The Need for IT Governance By Kavita Kalatur In a federal environment characterized by shrinking budgets and increasing regulation, CIOs are under constant

Data governance is a means to define the policies, standards, and data management services to be employed by the organization. Information Management & Data Governance OVERVIEW A thorough Data Governance

Purpose The purpose of this document is to provide guidance on the practice of Release Strategy and to describe the practice overview, requirements, best practices, activities, and key terms related to

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

THE UNITED REPUBLIC OF TANZANIA PRESIDENT S OFFICE PUBLIC SERVICE MANAGEMENT Enterprise Architecture A Step-by-step Guidebook for Formulating and Governing Enterprise Architecture Version 1.0 Date Release

Business Process Management In An Application Development Environment Overview Today, many core business processes are embedded within applications, such that it s no longer possible to make changes to

SOA: The missing link between Enterprise Architecture and Solution Architecture Jaidip Banerjee and Sohel Aziz Enterprise Architecture (EA) is increasingly being acknowledged as the way to maximize existing

Business Business Services Services and Enterprise and Enterprise This Workshop Two parts Background: Business Value of Enterprise TOGAF s and the Business Services We will use the key steps, methods and

Foundation of Business Analysis Course BA30: 4 days Instructor Led Prerequisites: No prerequisites - This course is suitable for both beginner and intermediate Business Analysts who would like to increase

D6 INFORMATION SYSTEMS DEVELOPMENT. SOLUTIONS & MARKING SCHEME. June 2013 The purpose of these questions is to establish that the students understand the basic ideas that underpin the course. The answers

Business Process Modeling with Structured Scenarios Doug Rosenberg ICONIX Software Engineering, Inc. In 2008, based on our experience with a number of business process engineering projects over the last

Business Process Modeling Information Systems in Industry (372-1-4207 ) Arnon Sturm The material of this presentation is adopted from various people including:, Pnina Soffer, Iris Reinhartz-Berger 1 Outline

SLCM 2003.1 Artifacts in a Nutshell ( as of 01/21/2005) Project Development Phases Pension Benefit Guaranty Corporation s (PBGC) System Life Cycle Methodology (SLCM) is comprised of five project development

UML TUTORIALS THE USE CASE MODEL www.sparxsystems.com.au Sparx Systems 2004 Page 1/5 describes the proposed functionality of the new system. A Use Case represents a discrete unit of interaction between

C H A P T E R 3 A Design Technique: Integration ing This chapter focuses on a new design technique for the analysis and design of data integration processes. This technique uses a graphical process modeling

9 i to Essential Meta Model Mapping Phase Preliminary Phase Assumption Constraint A statement of probable fact that has not been fully validated at this stage, due to external constraints. For example,

Technical Brief April 2011 The National Consortium for Justice Information and Statistics Model-driven Development of NIEM Information Exchange Package Documentation By Andrew Owen and Scott Came Since

A Business Analysis Perspective on Business Process Management October 2013 Discussion Points! Why have Roles?! What is Business Analysis?! Who is the Business Analyst?! Business Analysis & Business Process

Document: Our ref Secretariat of ISO/TC 176/SC 2 Date: 4 December 2003 ISO 9000 Introduction and Support Package: Guidance on the Concept and Use of the Process Approach for management systems In conjunction

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

Copyright Notice This work is copyright and owned by the Commonwealth of Australia. With the exception of the Commonwealth Coat of Arms, this work is licensed under a Creative Commons Attribution 3.0 Australia

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,"

Bringing agility to Business Intelligence Metadata as key to Agile Data Warehousing 1 P a g e Table of Contents What is the key to agility in Data Warehousing?... 3 The need to address requirements completely....

SAP PowerDesigner Building a Better Data Dictionary with SAP PowerDesigner Achieving Consistency and Reusability Table of Contents 3 How Modeling Adds Value to a Data Dictionary Best Practices to Consider

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

Re-design an Operational Database Introduction In today s world it is seen that lot of organizations go for a complete re-design of there database. Let s have a look why do we need to technically re-design

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

Red River College Course Learning Outcome Alignment with BABOK Version 2 This alignment chart was designed specifically for the use of Red River College. These alignments have not been verified or endorsed

Published in www.modernanalyst.com January 26, 2014 By Steven Worsham and Kenneth von Halle Steven Worsham, a Senior Business Analyst at Sapiens, uses The Decision Model in a variety of different project

UNIT-1 Ques 1. Define dbms and file management system? Ans- Database management system (DBMS) is a collection of interrelated data and a set of programs to access those data. Some of the very well known