Versioning and Change Management Policy. Report DRAFT

Size: px
Start display at page:

Download "Versioning and Change Management Policy. Report DRAFT"

Transcription

1 CEN WS/BII2 Page: 1 (19) CEN WS/BII2 Report DRAFT Version: 2.0 Released: Date of approval:

2 Page: 2 (19) Document Summary The purpose of this report is to define the versioning and change management policy for artefacts, delivered by the BII workshop. Author: - Anders Kingstedt Editors - Oriol Bausà Peris - Georg Birgisson - Fred van Blommestein - Arofan Gregory - Anders Kingstedt Contributors - Jostein Frømyr, EDISYS, NO (vice chair technical coordination) - Sven Rasmussen, Agency of Digitization, Ministry of Finance, Denmark

3 Page: 3 (19) Table of Contents 1 Preamble Versioning and change management policy introduction Background Goals and objectives Versioning Change management (ITSM) Relation to the BII 2 Governance Model Versioning and change management, details Backward compatibility Objects subject to versioning Business rules and information constraints Code lists New elements in a BII profile Name changes Cardinality Phases in a version Version levels numbering Major version numbers Minor version changes Revisions Outstanding issues and considerations Conclusions References and sources... 19

4 Page: 4 (19) 1 Preamble The objective of the CEN Workshop on Business Interoperability Interfaces for public procurement in Europe CEN ISSS WS/BII is to provide a framework for interoperability in pan-european electronic procurement transactions, expressed as a set of technical specifications that cross-refer to relevant activities, and in particular are compatible with UN/CEFACT - in order to ensure global interoperability. The workshop focuses on implementation facilitations and co-coordinating pilots implementing the technical specifications output. The requirements and final specifications are input into UN/CEFACT. The original CEN ISSS BII workshop was concluded in December 2009, and its results were issued as CWA 16073:2010. In early 2010, a second Workshop CEN ISSS WS/BII2 1 was initiated to follow up on and improve the work created in the first workshop. The purpose of the second phase of the workshop on Business Interoperability Interfaces for public procurement in Europe is to establish a forum for development and governance, by: - Providing technical support for adopters and implementers of the BII deliverables; - Providing a forum for governance, life cycle management and further refinements of the CWA published by CEN ISSS WS/BII; - Contributing to coordination and harmonization amongst European initiatives addressing various aspects of e-procurement; - Actively cooperating with the relevant organisations to ensure that European requirements are catered for in international standards and initiatives. Based on user input the CEN ISSS WS/BII2 have reviewed and updated a number of the profiles published as part of CWA 16073: If not otherwise specifically stated, all references to BII or BII2 or CEN WS/BII refers to the second workshop ( BII2 ) of the CEN WS/BII.

5 Page: 5 (19) 2 Versioning and change management policy - introduction 2.1 Background This document suggests a policy for versioning and change management. The use of policy is deliberate. This document presents recommendations that together form the policy for versioning and change management. As the solution for long term governance is to be decided (as of April 2012), it is simply not relevant to construct actual directives and check-lists. The policy document should therefore be regarded as a guiding document that has been put together to reflect the versioning and change management requirements captured during the CEN ISSS WS/BII2. Versioning can be challenging. It involves creating a reasonably comprehensive versioning-system that is not overly complex and that allows for making changes with full knowledge of the impact of any change. Versioning and change management go hand in hand. It is important to maintain full control over the implication of any change. Otherwise the consequences of might inadvertently create a negative result. This is of course especially true for changes affecting the major version level that will result in a breach of the backward compatibility. Another important aspect of change mgmt. is a fully functioning stakeholders communication mechanism. 2.2 Goals and objectives Versioning and the related process, change management, provide control of the BII deliverables within the Governance & Life Cycle management framework. One important objective is to ensure that only necessary changes are made to the elements subject to versioning. Another goal is to ensure that backward compatibility is retained if possible. Finally, all changes should be executed with full control and the changes should be communicated to all stakeholders in sufficient time before the changes are effectuated independent of whether the changes affect backward compatibility or not. The objective of the change management mechanism specifically is to capture faults and inconsistencies and correct these and to handle change requests if found appropriate after analysing the impact, time to correct / make change and business value. To the greatest possible extent, fault corrections and change requests should be coordinated with the users (stakeholders). 2.3 Versioning Versioning can be defined as follows: Software versioning is the process of assigning either unique version names or unique version numbers to unique states of computer software. Within a given version number category (major, minor), these numbers are generally assigned in increasing order and correspond to new developments in the software. At a fine-grained level, revision control is often used for keeping track of incrementally different versions of electronic information, whether or not this information is actually computer software (Source: Wikipedia). Or, alternatively: Versioning is the creation and management of multiple releases of a product, all of which have the same general function but are improved, upgraded or customized. The term applies especially to operating systems (OSs), software and Web services. Version control is the practice of ensuring collaborative data sharing and editing among users of systems that employ different versions of a product. The terms "versioning" and "version control" are sometimes used interchangeably even though their technical meanings are different.

6 Page: 6 (19) In software versioning, subsequent releases of a specific product receive numerical identifiers consisting of two or three numbers separated by periods. The first number, called the major number, is increased when there are significant improvements or changes in functionality. The second number, called the minor number, is incremented when there are minor feature changes or significant fixes. The third number, if it exists, is called the revision number. It is added or increased when minor bugs are eliminated. (Source: TechTarget). As pointed out in the section above (Versioning defined by TechTarget), versioning and version control are two different discipines. This document primarily targets versioning. Version control is sometimes regarded as key element of Configuration Management (CM). CM, when applied over the life cycle of a system, provides visibility and control of its performance, functional and physical attributes. CM verifies that a system performs as intended, and is identified and documented in sufficient detail to support its projected life cycle. The CM process facilitates orderly management of system information and system changes for such beneficial purposes as to revise capability; improve performance, reliability, or maintainability; extend life; reduce cost; reduce risk and liability; or correct defects. The relatively minimal cost of implementing CM is returned many fold in cost avoidance. The lack of CM, or its ineffectual implementation, can be very expensive and sometimes can have such catastrophic consequences as failure of equipment or loss of life. CM emphasizes the functional relation between parts, subsystems, and systems for effectively controlling system change. It helps to verify that proposed changes are systematically considered to minimize adverse effects. Changes to the system are proposed, evaluated, and implemented using a standardized, systematic approach that ensures consistency, and proposed changes are evaluated in terms of their anticipated impact on the entire system. CM verifies that changes are carried out as prescribed and that documentation of items and systems reflects their true configuration. A complete CM program includes provisions for the storing, tracking, and updating of all system information on a component, subsystem, and system basis. (Source: Wikipedia). With the above definition in mind, versioning is the actual classification system and version control is the framework of process descriptions, rules and tools necessary in order to ensure that the versioning is enforced in a correct way. Even though the artifacts subject to versioning are not software, the definition still applies to the BII artifacts. The objective of versioning is to maintain control over versions with respect to issues such as backward compatibility, dependencies and audit trails. These issues are described in more detail later in this document. 2.4 Change management (ITSM) Change management involves handling any changes that are proposed through the legitimate channels. Usually, change requests are initiated by the major stakeholder, either as formalized requests for changes or through incident reports forwarded by a helpdesk (or equivalent). A change requests that will create changes to elements on the major level is usually processed by a Change Control Board (CCB). Change management is an IT service management discipline. The objective of change management in this context is to ensure that standardized methods and procedures are used for efficient and prompt handling of all changes to control IT infrastructure, in order to minimize the number and impact of any related incidents upon service. Changes in the IT infrastructure may arise reactively in response to problems or externally imposed requirements, e.g. legislative changes, or proactively from seeking improved efficiency and effectiveness or to enable or reflect business initiatives, or from programs, projects or service improvement initiatives. Change Management can ensure standardized methods, processes and procedures which are used for all changes, facilitate efficient and prompt handling of all changes, and maintain the proper balance between the need for change and the potential detrimental impact of changes. (Source: Wikipedia) As with the definition of versioning, the above definition of change management doesn t apply to its entirety to the BII elements subject of change management. The basic principles however apply. The bottom line of change management is that any request for changes to the current version of a /BII/ element should be handled in a consistent, repetitive and controlled fashion.

7 Page: 7 (19) The basic process is: 1. Creating a change request (in run-time situations: usually a stakeholder; in production situation: usually by a project participant) 2. Processing the change requests. This might entail: filtering, storing (to a CR log), doing an initial impact analysis. 3. Assessing the change request. This might entail: further impact analysis (assessment of business value, cost, affected elements, activities necessary to act on the changes, time etc.). This activity is usually executed by a CCB or equivalent. 4. Executing the changes, which might entail: a. Modeling (architectural work) b. Updating or adding elements (both those affected by the change/correction and those secondary affected) 5. Verifying (quality assuring) the changes. 6. Communicating the changes (publication) A graphical representation of a suggested change request process is depicted below: Figure 1 the change management work flow

8 Page: 8 (19) 3 Relation to the BII 2 Governance Model The CEN ISSS BII2 Report on Long Term Governance Solution outlines possible elements of the BII governance model in section four (4) Governance BII specific considerations. At the core of suggested Governance model is version mgmt. (versioning) and change management. Some of the elements displayed in the model might be regarded as optional and restrictions might affect the ultimate composition of the model. These restrictions are for instance the final solution for long term governance itself; depending on resources and type of organization, context and possible other related factors, the model might be used as a whole or just partially. The below picture provides a high level presentation of the elements of the BII Governance model. Figure 2 - This picture illustrates how the BII 2 Governance model takes input from the requirements and other sources. The model is the foundation for the Governance organization selected to cater for long term governance. * - denotes elements that are included in the main elements of the model, shown to further explain the constituents. The overall goal of the Governance model is to provide guidance for how to govern the BII deliverables in a controlled and secure fashion, given the restrictions in effect and available resources. The Governance model as framework can be used as is or as boilerplate for the Governance structure used by the organization responsible for long term Governance. A more comprehensive description of the whole Governance eco system is depicted in the below mind map, which places versioning and change management in a context.

9 Page: 9 (19) Figure 3 an overview of the BII Governance eco system.

10 Page: 10 (19) 4 Versioning and change management, details This section outlines and suggests elements of the versioning framework for BII deliverables. As the final composition of the BII versioning framework is dependent on the final solution for BII Governance, long term, the versioning elements should be regarded as preliminary. In this section, some terms and elements of particular significance are also further explained. 4.1 Backward compatibility The term Backward compatible, is used to indicate how extensive changes made to an element are. If a version is backward compatible in relation to previous version(s), this means that an element instance of the previous version will validate without faults in the new version. This means that no limitations can be set in relation to the previous version, but only extensions. This means, for instance, that if the recipient of a BII information entity has implemented a version which is backward compatible with the one used by the sender, the recipient will validate the information entity without faults and be able to read the contents of the information entity. Versions on minor and revision level must be backward compatible. 4.2 Objects subject to versioning This section describes (suggests) the BII elements subject to versioning. Further BII elements might be added. The core BII elements subject to versioning are depicted the BII meta model. Figure 4 the BII Meta Model In addition to these elements, other elements used for validation (based on ISO Schematron), presentation (based on W3C XSD Style sheets) and bound syntax (based on UBL or UN/CEFACT XML messages) are also subject to versioning 2. 2 Please note that no consistent version number according to the proposed system exist for the BII elements currently. The suggestion is to add version numbers at the publication of the current CWA.

11 Page: 11 (19) Business rules and information constraints A business rule (previously called process rules ) describes the rules associated with business information. Business rules govern the overall business relationship between the partners that participate in the profile of which the relevant collaboration or transaction is a part. By agreeing on using the profile for trade the parties agree to these business rules. Business rules are normative and will be included in the validation of the BII entity concerned. Normally, adding further details to a business rule will result in the new version not being backward compatible with the previous one. Removing parts of business rule however typically means that it will remain compatible to the previous version. In addition to business rules, information constraints are used to govern how individual information elements are used by applying restrictions to the information entities. These are categorized into hard ( must be adhered to) and soft ( optional ) Code lists Code lists used in BII elements are referred to via their names. Thus a change in the name results in a new code list, including a change in spelling or a change from upper-case to lower-case letters. It is important to note that also the version number of the code list is included in the name, e.g. "<BII Ref>:codelist:taxtypecode-1.1". The addition of new values in an existing code list is regarded as backward compatible changes New elements in a BII profile If a new element is added to a BII profile element, e.g. address to an information model entity, the version will be backward compatible provided that the elements are placed at the end of the class and that they are not mandatory. If not, this calls for a major version change Name changes <This section should describe how name changes to BII elements affects versioning> Cardinality Cardinality determines the number of instances for a profile element. In case of a change of cardinality, the standard will be backward compatible as long as the requirement is being relaxed. If for example a cardinality is changed from 1 to 0..1, from 1..n to 0..n, from 0..1 to 0..n and from 1 to 1..n, backward compatibility will be retained.

12 Page: 12 (19) 4.3 Phases in a version A version of a BII version element will pass through the following phases in its lifetime 3 : Phase name Description Remarks Under development Under consultation Available Mandatory Authorised Under phase out Discontinued It has been notified that work on a new version has started. The version developed has been submitted for consultation and is awaiting comments. The consultation phase has ended, and a new version of the standard has been made available via the Internet. It has been made mandatory for a public authority to support the standard. When a standard is authorised (statutory), private suppliers are required to support the standard when exchanging e business documents with the public sector. It has been announced that the version will be withdrawn. It will not be possible for new enterprises to register support of a version under phase out. The version can only be supported via transformation. The version is being developed for instance on the basis of a known list of faults and preferences. Revisions (see below) are not submitted for consultation. A version may be available for a long time without being made mandatory. A version can remain mandatory without ever having been authorised. Usually, only parts of the BII element will be authorised. The authorisation date must be notified at least six months before the law comes into force. Phase out will typically be made in connection with the publication of a new version. The transformation must be paid for either by the sender or the recipient 3 This section has been copied in its entirety from the Danish OIOUBL versioning strategy guideline and has only been marginally altered. It is not entirely sure if it is applicable to the BII context and should therefore primarily be regarded as inspiration for the BII governance organization.

13 Page: 13 (19) The data diagram below shows the relationship between the various phases. Planned Notification Under development To be submitted for consultation (at the earliest 1 month after notification) Only revisions Under consultation Publication (at the earliest 3 months from start of consultation) Available At least 6-12 months Mandatory At least 3 months Authorized Under phase-out At least 6-12 months Discontinued

14 Page: 14 (19) 4.4 Version levels - numbering Three different version numbers levels - are suggested for the BII elements: - Major / version changes/ - Minor / version changes/ and - Revision Currently, only two major numbers exist: 1.N.N. (or just 1) which indicates an element created and published after CEN/WS BII (first workshop) and 2.N.N (or just 2) which indicates an element created and published 4 after CEN/WS BII2 (second workshop) Major version numbers A major version number can share the same number as a minor version number, but unlike a minor version change, a major version number change is not backward compatible with the previous version. A major version level change is typically triggered by change requests and the decision on whether a change request should be effectuated is taken in the CCB (or equivalent). A major version change is indicated by an adding an integer to the major level (e.g. from to 2.0.0). Notification A major version change must be notified at least <appropriate time frame, e.g. six months> before the release of a major version. The notification should include: - Element name specification - New and previous version number - Context - Rationale - Existing dependencies (affected elements, if any) - Contact information (responsible role) Communication Prior to the release, the version major change should have been published to the CEN BII s website (se previous section). Validity To ensure a smooth transition from a major version to another, it might be useful to establish a grace period during which two different major versions are allowed to run in parallel. This period should be time limited (e g: 12 months must pass from the date on which the new major version is published until it can be made mandatory). When a new major version is made mandatory, the old version may be transferred to a phase-out period. After having received a phase-out status, a given period of time (e g 12 months) will pass until the version is discontinued (i e not longer supported). Note: any decision to move a major version to phase-out status should obviously require a decision by the CCB (or equivalent). 4 Published in fact means to be published after the conclusion of the running WS.

15 Page: 15 (19) Minor version changes A minor version change is typically incurred by changes that do not affect and call for a major version change, e.g. the introduction of a new schema or minor changes made to an existing element. Changes to a minor version must always be backward compatible with the previous version. A minor version level change is typically triggered by change requests and the decision on whether a change request should be effectuated is taken in the CCB (or equivalent). A minor version change is reflected in an addition to the second level numbering, e.g. <Element> to Notification A minor version change must be notified at least <appropriate time frame, e.g. four months before release>. The notification should include: - Element name specification - New and previous version number - Context - Rationale - Existing dependencies (affected elements, if any) - Contact information (responsible role) Communication Prior to the release, the minor change should have been published to the CEN BII s website (se previous section). Validity As with a major version change, a minor version change might include a transition period where the new version is running in parallel to the existing (old) version. After a given period of time, the previous (old) is given phase-out status and the new, replacing version is made the current (mandatory) version Revisions Revisions are primarily done to elements with the purpose of rectifying those faults and defects that prevent the correct use of the standard. The revisions are typically initiated through 1 the expert working on the element subject to revision and/or 2 incidents reported through the helpdesk or other user communications channels in place. Revisions in BII elements can never contain schema changes, and they will always be backward compatible in relation to the previous version. A revision is indicated by a version change in the form of adding an integer at the third, e.g. from <element> to A revision will typically be triggered by changes to the documentation, code lists and Schematron validation of the BII elements. Notification A revision could be notified at least <appropriate time frame, e.g. one month before release> via the BII website. A list of changes in relation to the previous version could be posted to the BII website when the revision is notified. This list will be updated and issued together with the revision. Communication

16 Page: 16 (19) It is recommended that an aggregated list of revisions is published on the BII website on a regular basis, either successively or on a regular interval basis (see the above). Validity As with changes to the major and minor level, it is possible that a revision should be running in parallel with the previous revision for a specified number of days / months before the new revision replaces the previous (old) one. The old revision is the given phase out status.

17 Page: 17 (19) 5 Outstanding issues and considerations This document proposes some but far from all of the core features of versioning and change management. Further work and elaboration is required. This work includes (but is not limited to): 1. Triggers: a comprehensive list of triggers for fault / error corrections and change requests is required. This list should include initiating actor (role), classification directives, rules for handling different classes of triggers etc. 2. Workflows: different class of actions calls for different workflows, some of which might include multiple steps (such as analysis, CCB review, task executing, resource allocation and more) whereas other might involve simple steps. If possible, a few basic workflows serving as boiler plates for the more elaborate work flows should be established. 3. Audit trails / logging: in order to keep track of changes, it would be helpful to add an audit trail to the versioning and change management framework. This would facilitate tracing changes and provide better understanding as to why changes have been done and thus the evolution of an BII element. 4. Quality assurance management: a set of directives for ensuring quality of changes made to the BII elements should be established. 5. Tooling: the tools used for making changes, tracking changes, keeping track of dependencies should be documented and kept up to date. The tools should be referenced from the workflow description(s). 6. Governance model relationship: other elements of the Governance and Life Cycle model potentially affect the composition of the final versioning and change management policy (framework). Cross cutting concerns should be identified with the purpose of providing an appropriate level of support in terms of versioning and change management.

18 Page: 18 (19) 6 Conclusions As pointed out earlier in this document, the versioning and change management framework plays an important part in the Governance eco system. This policy document outlines recommendations that at a later point in time might be regarded as the basis for instructions for versioning and change management. However, since the solution for long term Governance and sustainability is not yet resolved, it is difficult to regard this document as anything than a guiding policy document. It must also be stressed that the BII deliverables are highly dependent on the stakeholders requests, thus far made implementations (of the BII specifications) and the standards to which elements are bound (currently OASIS UBL and UN/CEFACT XML messages). These facts add to the complexity and calls for care deliberation when composing the ultimate instructions.

19 Page: 19 (19) 7 References and sources Wikipedia Software Versioning TechTarget - NITA: Updating and Versioning Strategy for OIOUBL - common standard for e-business document Governance models / standards used as input: o o o o CobIT, ITIL, CMMI, PM3, o ISO o ISO (Quality management - Guidelines for configuration management)

Invoice Only PROFILE DESCRIPTION

Invoice Only PROFILE DESCRIPTION CEN/ISSS WS/BII04 Invoice Only PROFILE DESCRIPTION Business Domain: Post award procurement Business Process: Billing Document Identification: CEN/ISSS WS/Profile BII04 Version: 1.0 Release: 2009-11-05

More information

8. Master Test Plan (MTP)

8. Master Test Plan (MTP) 8. Master Test Plan (MTP) The purpose of the Master Test Plan (MTP) is to provide an overall test planning and test management document for multiple levels of test (either within one project or across

More information

Information Model Architecture. Version 2.0

Information Model Architecture. Version 2.0 Information Model Architecture Version 2.0 1 introduction...2 2 objectives...2 3 definition of terms...3 4 conformance...4 4.1 UBL conformance...4 4.2 NES conformance...4 4.3 NES profile conformance...4

More information

CHAPTER 7 Software Configuration Management

CHAPTER 7 Software Configuration Management CHAPTER 7 Software Configuration Management ACRONYMS CCB CM FCA MTBF PCA SCCB SCI SCM SCMP SCR SCSA SEI/CMMI SQA SRS USNRC INTRODUCTION Configuration Control Board Configuration Management Functional Configuration

More information

Software Configuration Management Plan

Software Configuration Management Plan For Database Applications Document ID: Version: 2.0c Planning Installation & Acceptance Integration & Test Requirements Definition Design Development 1 / 22 Copyright 2000-2005 Digital Publications LLC.

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

Software and Hardware Configuration Management

Software and Hardware Configuration Management DOWNLOADED AND/OR HARD COPY UNCONTROLLED Verify that this is the correct version before use. AUTHORITY DATE Jeffrey Northey (original signature on file) IMS Manager 07/09/2014 Doug Dorrer (original signature

More information

Maturity Model. March 2006. Version 1.0. P2MM Version 1.0 The OGC logo is a Registered Trade Mark of the Office of Government Commerce

Maturity Model. March 2006. Version 1.0. P2MM Version 1.0 The OGC logo is a Registered Trade Mark of the Office of Government Commerce Maturity Model March 2006 Version 1.0 P2MM Version 1.0 The OGC logo is a Registered Trade Mark of the Office of Government Commerce This is a Value Added product which is outside the scope of the HMSO

More information

ITIL Event Management in the Cloud

ITIL Event Management in the Cloud ITIL Event Management in the Cloud An AWS Cloud Adoption Framework Addendum July 2015 2015, Amazon Web Services, Inc. or its affiliates. All rights reserved. Notices This document is provided for informational

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

Configuration Management Practices

Configuration Management Practices Safety Critical Software Management Practices Linda Westfall Westfall Team, Inc. International Conference on Software Quality ICSQ 2011 Copyright 1999-2010 Westfall Team, Inc. All Rights Reserved. Management

More information

Service Support. 2005 Kasse Initiatives, LLC. ITIL Configuration Management - 1. version 2.0

Service Support. 2005 Kasse Initiatives, LLC. ITIL Configuration Management - 1. version 2.0 Service Support Configuration Management ITIL Configuration Management - 1 Goals of Configuration Management The goals of Configuration Management are to: Account for all the IT assets and configurations

More information

BMC Software Consulting Services. Fermilab Computing Division Service Catalog & Communications: Process and Procedures

BMC Software Consulting Services. Fermilab Computing Division Service Catalog & Communications: Process and Procedures BMC Software Consulting Services Service Catalog & Communications: Process and Procedures Policies, Client: Date : Version : Fermilab 02/12/2009 1.0 GENERAL Description Purpose This document establishes

More information

BEST PRACTICE GUIDE 6: ESTABLISHING CONTRACTS. RDTL MINISTRY OF FINANCE Procurement Service

BEST PRACTICE GUIDE 6: ESTABLISHING CONTRACTS. RDTL MINISTRY OF FINANCE Procurement Service RDTL MINISTRY OF FINANCE Procurement Service BEST PRACTICE GUIDE 6: ESTABLISHING CONTRACTS 1 RDTL Procurement Guidelines The Procurement Legal Regime Decree Law sets out new procurement processes which

More information

Configuration Management. Main issues: manage items during software life cycle usually supported by powerful tools

Configuration Management. Main issues: manage items during software life cycle usually supported by powerful tools Configuration Management Main issues: manage items during software life cycle usually supported by powerful tools Configuration management tasks identification and definition of configuration items, such

More information

Common platform for e- procurement NES. Sören Lennartsson SFTI secretariat SALAR

Common platform for e- procurement NES. Sören Lennartsson SFTI secretariat SALAR Common platform for e- procurement Sören Lennartsson SFTI secretariat SALAR 1 Agenda Who and what is? Our approach to using UBL 2.0 The deliverables Cooperation continues Further information Some opinions

More information

ISO 20000-1:2005 Requirements Summary

ISO 20000-1:2005 Requirements Summary Contents 3. Requirements for a Management System... 3 3.1 Management Responsibility... 3 3.2 Documentation Requirements... 3 3.3 Competence, Awareness, and Training... 4 4. Planning and Implementing Service

More information

Requirements Traceability. Mirka Palo

Requirements Traceability. Mirka Palo Requirements Traceability Mirka Palo Seminar Report Department of Computer Science University of Helsinki 30 th October 2003 Table of Contents 1 INTRODUCTION... 1 2 DEFINITION... 1 3 REASONS FOR REQUIREMENTS

More information

ETSO Modelling Methodology for the Automation of Data Interchange of Business Processes (EMM)

ETSO Modelling Methodology for the Automation of Data Interchange of Business Processes (EMM) ETSO Modelling Methodology for the Automation of Data Interchange of Business Processes (EMM) Version : 1 Release : 4 Version 1 Release 4 04 December 2003 Page 1/19 Revision History Version Release Date

More information

CMDB Essential to Service Management Strategy. All rights reserved 2007

CMDB Essential to Service Management Strategy. All rights reserved 2007 CMDB: Essential to the Service Management strategy Business Proposition: This white paper describes how the CMDB is an essential component of the IT Service Management Strategy, and why the FrontRange

More information

Service Delivery Module

Service Delivery Module Service Delivery Module Software Development Methodology -India follows international industry standards and has adopted the standard methodology in our Software Development Life Cycle (SDLC). It is a

More information

Software Quality Assurance Plan

Software Quality Assurance Plan Company Name Software Quality Assurance Plan Copyright 2012 Template.org Version: (n) Date: (mm/dd/yyyy) adapted from the IEEE Standard for Software Test Documentation Document History and Distribution

More information

Common platform for e- procurement. Jostein Frømyr, project coordinator Martin Forsberg, Single Face To Industry, Sweden

Common platform for e- procurement. Jostein Frømyr, project coordinator Martin Forsberg, Single Face To Industry, Sweden Common platform for e- procurement Jostein Frømyr, project coordinator Martin Forsberg, Single Face To Industry, Sweden Presentation at the UBL symposium November 16, 2006 1 Agenda Who and what is? Our

More information

Procurement Programmes & Projects P3M3 v2.1 Self-Assessment Instructions and Questionnaire. P3M3 Project Management Self-Assessment

Procurement Programmes & Projects P3M3 v2.1 Self-Assessment Instructions and Questionnaire. P3M3 Project Management Self-Assessment Procurement Programmes & Projects P3M3 v2.1 Self-Assessment Instructions and Questionnaire P3M3 Project Management Self-Assessment Contents Introduction 3 User Guidance 4 P3M3 Self-Assessment Questionnaire

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

MANAGED SERVICES FOR THE PROGRAM MANAGEMENT OFFICE

MANAGED SERVICES FOR THE PROGRAM MANAGEMENT OFFICE PMO Symposium MANAGED SERVICES FOR THE PROGRAM MANAGEMENT OFFICE INTRODUCTION As Program Management Offices (PMOs) continue to grow in an expanded role, it is increasingly more important that the integration

More information

Government of India Ministry of Communications & Information Technology Department of Electronics & Information Technology (DeitY)

Government of India Ministry of Communications & Information Technology Department of Electronics & Information Technology (DeitY) Government of India Ministry of Communications & Information Technology Department of Electronics & Information Technology (DeitY) Title of Policy: Policy on Open APIs for Government of India Preamble:

More information

UoD IT Job Description

UoD IT Job Description UoD IT Job Description Role: Projects Portfolio Manager HERA Grade: 8 Responsible to: Director of IT Accountable for: Day to day leadership of team members and assigned workload Key Relationships: Management

More information

Aerospace & Defense Publishing: How S1000D Changes the Game

Aerospace & Defense Publishing: How S1000D Changes the Game White Paper Aerospace & Defense Publishing: How S1000D Changes the Game If your organization produces equipment or components used in the Aerospace and Defense industry, compliance with S1000D is likely

More information

Clinical Risk Management: Agile Development Implementation Guidance

Clinical Risk Management: Agile Development Implementation Guidance Document filename: Directorate / Programme Document Reference NPFIT-FNT-TO-TOCLNSA-1306.02 CRM Agile Development Implementation Guidance v1.0 Solution Design Standards and Assurance Project Clinical Risk

More information

OpenPEPPOL. Status and Outlook 2014

OpenPEPPOL. Status and Outlook 2014 www.peppol.eu OpenPEPPOL Status and Outlook 2014 Sven Rasmussen Chief Advisor, Ministry of Finance (DK) Director OpenPEPPOL TICC svrra@digst.dk February 6 th 2014 ICEPRO PEPPOL is an EU co-funded project

More information

Maruleng Local Municipality ICT CHANGE MANAGEMENT POLICY

Maruleng Local Municipality ICT CHANGE MANAGEMENT POLICY Maruleng Local Municipality ICT CHANGE MANAGEMENT POLICY Contents ICT CHANGE MANAGEMENT...1 POLICY...1 1. Preamble...3 2. Terms and definitions...3 3. Purpose...4 4. Objective of this Policy...4 5. References

More information

The purpose of Capacity and Availability Management (CAM) is to plan and monitor the effective provision of resources to support service requirements.

The purpose of Capacity and Availability Management (CAM) is to plan and monitor the effective provision of resources to support service requirements. CAPACITY AND AVAILABILITY MANAGEMENT A Project Management Process Area at Maturity Level 3 Purpose The purpose of Capacity and Availability Management (CAM) is to plan and monitor the effective provision

More information

TOGAF 9 i to Essential Meta Model Concept Mapping

TOGAF 9 i to Essential Meta Model Concept Mapping 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,

More information

TfNSW Standard Requirements TSR T Technical Management

TfNSW Standard Requirements TSR T Technical Management Template Applicable to: Transport Projects Quality Management System Status: Division: Approved Transport Projects Version: 5.0 Desksite No.: 3455797_1 Date of issue: 1 July 2014 Effective date: 1 July

More information

ITIL Introducing service transition

ITIL Introducing service transition ITIL Introducing service transition The goals of service transition Aligning the new or changed service with the organisational requirements and organisational operations Plan and manage the capacity and

More information

ITIL v3 Service Manager Bridge

ITIL v3 Service Manager Bridge ITIL v3 Service Manager Bridge Course Length: 5 Days Course Overview This 5 day hands on, certification training program enables ITIL Version 2 certified Service Managers to upgrade their Service Manager

More information

The Project Management Plan will be used to guide, communicate and coordinate project efforts.

The Project Management Plan will be used to guide, communicate and coordinate project efforts. F.1 General Implementation Contractor Deliverables include critical system planning and development components. Sufficient deliverables have been identified at key steps in the project to guide the project

More information

QUALITY CONTROL PROCESS FOR TAXONOMY DEVELOPMENT

QUALITY CONTROL PROCESS FOR TAXONOMY DEVELOPMENT AUTHORED BY MAKOTO KOIZUMI, IAN HICKS AND ATSUSHI TAKEDA JULY 2013 FOR XBRL INTERNATIONAL, INC. QUALITY CONTROL PROCESS FOR TAXONOMY DEVELOPMENT Including Japan EDINET and UK HMRC Case Studies Copyright

More information

Architectural Design

Architectural Design Software Engineering Architectural Design 1 Software architecture The design process for identifying the sub-systems making up a system and the framework for sub-system control and communication is architectural

More information

Standard Registry Development and Publication Process

Standard Registry Development and Publication Process Document number: DSP4006 Date: 2007-12-12 Version: 1.1.0 Standard Registry Development and Publication Process Document type: Specification Document status: Informational Document language: E Copyright

More information

OpenPEPPOL. Effective eprocurement in Europe. Sven Rasmussen. February 7 th 2014 UT Messan

OpenPEPPOL. Effective eprocurement in Europe. Sven Rasmussen. February 7 th 2014 UT Messan www.peppol.eu OpenPEPPOL Effective eprocurement in Europe Sven Rasmussen Chief Advisor, Ministry of Finance (DK) Director OpenPEPPOL TICC svrra@digst.dk February 7 th 2014 UT Messan PEPPOL is an EU co-funded

More information

DOCUMENT TYPES AND NAMING CONVENTIONS

DOCUMENT TYPES AND NAMING CONVENTIONS CERN CH-1211 Geneva 23 Switzerland LHC Project Document No. CERN Div./Group or Supplier/Contractor Document No. the Large Hadron Collider project EDMS Document No. 103547 Date:2003-04-03 Quality Assurance

More information

Sound Transit Internal Audit Report - No. 2014-3

Sound Transit Internal Audit Report - No. 2014-3 Sound Transit Internal Audit Report - No. 2014-3 IT Project Management Report Date: Dec. 26, 2014 Table of Contents Page Background 2 Audit Approach and Methodology 2 Summary of Results 4 Findings & Management

More information

SOFTWARE CONFIGURATION MANAGEMENT GUIDEBOOK

SOFTWARE CONFIGURATION MANAGEMENT GUIDEBOOK Office of Safety and Mission Assurance NASA-GB-9503 SOFTWARE CONFIGURATION MANAGEMENT GUIDEBOOK AUGUST 1995 National Aeronautics and Space Administration Washington, D.C. 20546 PREFACE The growth in cost

More information

Data Management Maturity Model. Overview

Data Management Maturity Model. Overview Data Management Maturity Model Overview UPMC Center of Excellence Pittsburgh Jul 29, 2013 Data Management Maturity Model - Background A broad framework encompassing foundational data management capabilities,

More information

Information Governance Policy A council-wide information management policy. Version 1.0 June 2013

Information Governance Policy A council-wide information management policy. Version 1.0 June 2013 Information Governance Policy Version 1.0 June 2013 Copyright Notification Copyright London Borough of Islington 2012 This document is distributed under the Creative Commons Attribution 2.5 license. This

More information

Change Management Plan (CMP)

Change Management Plan (CMP) Change Management Plan (CMP) i Version/Change Record Revision Date Description ii Table of Contents 1.0 Introduction... 5 1.1 Purpose... 5 1.2 Plan Scope... 5 1.3 Document Overview... 7 1.4 Referenced

More information

Configuration Management Guide

Configuration Management Guide Guide Important Warning This document is one of a set of standards developed solely and specifically for use on Transport Assets (as defined in the Asset Standards Authority Charter). It is not suitable

More information

PROJECT MANAGEMENT PLAN CHECKLIST

PROJECT MANAGEMENT PLAN CHECKLIST PROJECT MANAGEMENT PLAN CHECKLIST The project management plan is a comprehensive document that defines each area of your project. The final document will contain all the required plans you need to manage,

More information

Development, Acquisition, Implementation, and Maintenance of Application Systems

Development, Acquisition, Implementation, and Maintenance of Application Systems Development, Acquisition, Implementation, and Maintenance of Application Systems Part of a series of notes to help Centers review their own Center internal management processes from the point of view of

More information

MWA Project. Configuration Management Plan

MWA Project. Configuration Management Plan Document No.: 46-01002 Revision: 0004 Date: 22-Oct-2009 MWA Project Configuration Management Plan MWA Project MWA Consortium Copyright 2009, MWA Consortium. All Rights Reserved. Control Status Document

More information

Camber Quality Assurance (QA) Approach

Camber Quality Assurance (QA) Approach Camber Quality Assurance (QA) Approach Camber s QA approach brings a tested, systematic methodology, ensuring that our customers receive the highest quality products and services, delivered via efficient

More information

IT Organisation in Change

IT Organisation in Change IT Organisation in Change ENTERPRISE SOFTWARE ENGINEERING & SOFTWARE ENGINEERING IN THE ENTERPRISE IT change Quality of IT s Costs of IT s change Future Now Perfect IT s Business Demands Can we deliver?

More information

Applying ITIL v3 Best Practices

Applying ITIL v3 Best Practices white paper Applying ITIL v3 Best Practices to improve IT processes Rocket bluezone.rocketsoftware.com Applying ITIL v. 3 Best Practices to Improve IT Processes A White Paper by Rocket Software Version

More information

General Platform Criterion Assessment Question

General Platform Criterion Assessment Question Purpose: [E]nsure that the assets required to deliver services are properly controlled, and that accurate and reliable information about those assets is available when and where it is needed. (ST 4.3.1)

More information

Configuration Management

Configuration Management Configuration Management Co Al Florence This presenter s affiliation with the MITRE Corporation is provided for identification purposes only and is not intended to convey or imply MITRE s concurrence with

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

PORTFOLIO, PROGRAMME & PROJECT MANAGEMENT MATURITY MODEL (P3M3)

PORTFOLIO, PROGRAMME & PROJECT MANAGEMENT MATURITY MODEL (P3M3) PORTFOLIO, PROGRAMME & PROJECT MANAGEMENT MATURITY MODEL (P3M3) 1st February 2006 Version 1.0 1 P3M3 Version 1.0 The OGC logo is a Registered Trade Mark of the Office of Government Commerce This is a Value

More information

Code of Practice on Electronic Invoicing in the EU

Code of Practice on Electronic Invoicing in the EU CEN/WS einvoicing Phase 3 Date: 2011-11 CEN Workshop AgreementTC WI Secretariat: NEN Code of Practice on Electronic Invoicing in the EU Status: for public review (23 November 2011-23 January 2012) ICS:

More information

EASYWAY ES5 RULES OF PROCEDURE FOR CHANGE CONTROL AND RELEASE MANAGEMENT OF DATEX II. Page 1 of 21. March 2011

EASYWAY ES5 RULES OF PROCEDURE FOR CHANGE CONTROL AND RELEASE MANAGEMENT OF DATEX II. Page 1 of 21. March 2011 EASYWAY ES5 RULES OF PROCEDURE FOR CHANGE CONTROL AND RELEASE MANAGEMENT OF DATEX II March 2011 European Commission Directorate General for Mobility and Transport Copyright 2011 Page 1 of 21 Document Control

More information

Stepping Through the Info Security Program. Jennifer Bayuk, CISA, CISM

Stepping Through the Info Security Program. Jennifer Bayuk, CISA, CISM Stepping Through the Info Security Program Jennifer Bayuk, CISA, CISM Infosec Program How to: compose an InfoSec Program cement a relationship between InfoSec program and IT Governance design roles and

More information

Department of Administration Portfolio Management System 1.3 June 30, 2010

Department of Administration Portfolio Management System 1.3 June 30, 2010 E 06/ 30/ 2010 EX AM PL 1. 3 06/ 28/ 2010 06/ 24/ 2010 06/ 23/ 2010 06/ 15/ 2010 06/ 18/ 2010 Portfolio System 1.3 June 30, 2010 Contents Section 1. Project Overview... 1 1.1 Project Description... 1 1.2

More information

PROJECT QUALITY MANAGEMENT

PROJECT QUALITY MANAGEMENT 8 PROJECT QUALITY MANAGEMENT Project Quality Management includes the processes required to ensure that the project will satisfy the needs for which it was undertaken. It includes all activities of the

More information

The purpose of Supplier Agreement Management (SAM) is to manage the acquisition of products from suppliers.

The purpose of Supplier Agreement Management (SAM) is to manage the acquisition of products from suppliers. SUPPLIER AGREEMENT MANAGEMENT A Project Management Process Area at Maturity Level 2 Purpose The purpose of Supplier Agreement Management (SAM) is to manage the acquisition of products from suppliers. Introductory

More information

The potential legal consequences of a personal data breach

The potential legal consequences of a personal data breach The potential legal consequences of a personal data breach Tue Goldschmieding, Partner 16 April 2015 The potential legal consequences of a personal data breach 15 April 2015 Contents 1. Definitions 2.

More information

December 21, 2012. The services being procured through the proposed amendment are Hosting Services, and Application Development and Support for CITSS.

December 21, 2012. The services being procured through the proposed amendment are Hosting Services, and Application Development and Support for CITSS. Justification for a Contract Amendment to Contract 2012-01: Interim Hosting and Jurisdiction Functionality for the Compliance Instrument Tracking System Service (CITSS) December 21, 2012 Introduction WCI,

More information

Configuration Management ISO 10007

Configuration Management ISO 10007 Configuration Management ISO 10007 Introduction Configuration Management Overview: What is Configuration Management? Collection of tools, techniques and experience designed to reduce costs and improve

More information

Certified Professional in Configuration Management Glossary of Terms

Certified Professional in Configuration Management Glossary of Terms Certified Professional in Configuration Management Glossary of terms used in Configuration Management Issue 2007.07 Association of the International Certified Configuration Manager e.v. Copyright 2007,

More information

Module 7 Study Guide

Module 7 Study Guide Module 7 Study Guide Change Evaluation Welcome to your Study Guide. This document is supplementary to the information available to you online, and should be used in conjunction with the videos, quizzes

More information

MNLARS Project Audit Checklist

MNLARS Project Audit Checklist Audit Checklist The following provides a detailed checklist to assist the audit team in reviewing the health of a project. Relevance (at this time) How relevant is this attribute to this project or audit?

More information

Computer programs (both source and executable) Documentation (both technical and user) Data (contained within the program or external to it)

Computer programs (both source and executable) Documentation (both technical and user) Data (contained within the program or external to it) CHAPTER 27 CHANGE MANAGEMENT Overview Changes are inevitable when software is built. A primary goal of software engineering is to improve the ease with which changes can be made to software. Configuration

More information

Achieving ITSM Excellence Through Availability Management

Achieving ITSM Excellence Through Availability Management Achieving ITSM Excellence Through Availability Management Technology Concepts and Business Considerations Abstract This white paper outlines the motivation behind Availability Management, and describes

More information

MCIS Aggregate Claim Editor User Guide. Core system users

MCIS Aggregate Claim Editor User Guide. Core system users MCIS Aggregate Claim Editor User Guide Core system users TABLE OF CONTENTS INTRODUCTION... 3 HOW TO USE THIS GUIDE... 3 ABOUT AGGREGATE CLAIM EDITORS... 3 AGGREGATE CLAIM EDITOR TEAM LEADERS... 3 THE CLAIMS

More information

Fermilab Computing Division Service Level Management Process & Procedures Document

Fermilab Computing Division Service Level Management Process & Procedures Document BMC Software Consulting Services Fermilab Computing Division Process & Procedures Document Client: Fermilab Date : 07/07/2009 Version : 1.0 1. GENERAL Description Purpose Applicable to Supersedes This

More information

SERVICE EXCELLENCE SUITE

SERVICE EXCELLENCE SUITE USERS GUIDE Release Management Service Management and ServiceNow SERVICE EXCELLENCE SUITE Table of Contents Introduction... 3 Overview, Objectives, and Current Scope... 4 Overview... 4 Objectives... 4

More information

Call for experts for INSPIRE maintenance & implementation

Call for experts for INSPIRE maintenance & implementation INSPIRE Infrastructure for Spatial Information in Europe Call for experts for INSPIRE maintenance & implementation Title Creator Call for experts for INSPIRE maintenance & implementation EC & EEA INSPIRE

More information

ITIL V3 Application Support Volume 1

ITIL V3 Application Support Volume 1 ITIL V3 Application Support Volume 1 Service Management For Application Support ITIL is a Registered Trade Mark and Community Trademark of the Office of Government and Commerce. This document may contain

More information

Code of Practice for Directors

Code of Practice for Directors Code of Practice for Directors This Code provides guidance to directors to assist them in carrying out their duties and responsibilities in accordance with the highest professional standards. 1.0 INTRODUCTION

More information

exist-db Subscriptions

exist-db Subscriptions !! exist-db Subscriptions Terms and Conditions exist Solutions GmbH Dr-Ludwig-Opel-Straße 50, 65428 Rüsselsheim, Germany 1. Definitions Software means the exist-db Open Source Native XML database, its

More information

Observing Data Quality Service Level Agreements: Inspection, Monitoring, and Tracking

Observing Data Quality Service Level Agreements: Inspection, Monitoring, and Tracking A DataFlux White Paper Prepared by: David Loshin Observing Data Quality Service Level Agreements: Inspection, Monitoring, and Tracking Leader in Data Quality and Data Integration www.dataflux.com 877 846

More information

Incorporate CMMI with Corporate Governance Using Enterprise Software Change Management Solutions

Incorporate CMMI with Corporate Governance Using Enterprise Software Change Management Solutions Incorporate CMMI with Corporate Governance Using Enterprise Software Change Management Solutions Tim Ruzbacki, Sr. Process Consultant MKS Software Inc. 4 th Annual CMMI Technology Conference, Denver CO

More information

Observing Data Quality Service Level Agreements: Inspection, Monitoring and Tracking WHITE PAPER

Observing Data Quality Service Level Agreements: Inspection, Monitoring and Tracking WHITE PAPER Observing Data Quality Service Level Agreements: Inspection, Monitoring and Tracking WHITE PAPER SAS White Paper Table of Contents Introduction.... 1 DQ SLAs.... 2 Dimensions of Data Quality.... 3 Accuracy...

More information

NSI Policy Supplement for XML Retail Accounting Reports Certification/Verification. May 7, 2007 Revision 1.1

NSI Policy Supplement for XML Retail Accounting Reports Certification/Verification. May 7, 2007 Revision 1.1 NSI Policy Supplement for XML Retail Accounting Reports Certification/Verification May 7, 2007 Revision 1.1 Table of Contents 1. Overview... 3 1.1 Introduction... 3 1.2 Scope... 3 1.2.1 Scope of certification

More information

Guide to Enterprise Life Cycle Processes, Artifacts, and Reviews

Guide to Enterprise Life Cycle Processes, Artifacts, and Reviews Department of Health and Human Services Centers for Medicare & Medicaid Services Center for Consumer Information and Insurance Oversight Guide to Enterprise Life Cycle Processes, Artifacts, and Reviews

More information

EVALUATION OF SOFTWARE

EVALUATION OF SOFTWARE [From: Translating and the Computer 14. Papers presented at a conference 10-11 November 1992 (London: Aslib 1992)] EVALUATION OF SOFTWARE J E Rowley, Principal Lecturer Crewe+Alsager College of Higher

More information

Federated, Generic Configuration Management for Engineering Data

Federated, Generic Configuration Management for Engineering Data Federated, Generic Configuration Management for Engineering Data Dr. Rainer Romatka Boeing GPDIS_2013.ppt 1 Presentation Outline I Summary Introduction Configuration Management Overview CM System Requirements

More information

CMS Policy for Configuration Management

CMS Policy for Configuration Management Chief Information Officer Centers for Medicare & Medicaid Services CMS Policy for Configuration April 2012 Document Number: CMS-CIO-POL-MGT01-01 TABLE OF CONTENTS 1. PURPOSE...1 2. BACKGROUND...1 3. CONFIGURATION

More information

IEMA Introduction to Environmental Management Systems

IEMA Introduction to Environmental Management Systems IEMA Introduction to Environmental Management Systems element 2: KEY COMPONENTS OF ISO 14001 Sample material (Material correct at 1/11/2011) RRC Training 27-37 St George s Road London SW19 4DS United Kingdom

More information

The Configuration Management process area involves the following:

The Configuration Management process area involves the following: CONFIGURATION MANAGEMENT A Support Process Area at Maturity Level 2 Purpose The purpose of is to establish and maintain the integrity of work products using configuration identification, configuration

More information

ORACLE IT SERVICE MANAGEMENT SUITE

ORACLE IT SERVICE MANAGEMENT SUITE ORACLE IT SERVICE MANAGEMENT SUITE ITIL COMPATIBLE PINKVERIFY ORACLE IT SERVICE MANAGEMENT SUITE HAS BEEN CERTIFIED BY PINK ELEPHANT THROUGH THE PINKVERIFY PROCESS TO BE ITIL COMPATIBLE IN SIX PROCESS

More information

Develop Project Charter. Develop Project Management Plan

Develop Project Charter. Develop Project Management Plan Develop Charter Develop Charter is the process of developing documentation that formally authorizes a project or a phase. The documentation includes initial requirements that satisfy stakeholder needs

More information

CONTRACT MANAGEMENT FRAMEWORK

CONTRACT MANAGEMENT FRAMEWORK CONTRACT MANAGEMENT FRAMEWORK August 2010 Page 1 of 20 Table of contents 1 Introduction to the CMF... 3 1.1 Purpose and scope of the CMF... 3 1.2 Importance of contract management... 4 1.3 Managing contracts...

More information

CCIT Change Management Procedures & Documentation

CCIT Change Management Procedures & Documentation CCIT Change Management Procedures & Documentation 1.0 Introduction A major challenge within any organization is the ability to manage change. This process is even more difficult within an IT organization.

More information

IHE IT Infrastructure Technical Framework Supplement 2007-2008

IHE IT Infrastructure Technical Framework Supplement 2007-2008 ACC, HIMSS and RSNA Integrating the Healthcare Enterprise 5 10 IHE IT Infrastructure Technical Framework Supplement 2007-2008 Template for XDS Affinity Domain Deployment Planning 15 20 Draft for Trial

More information

Newcastle University Information Security Procedures Version 3

Newcastle University Information Security Procedures Version 3 Newcastle University Information Security Procedures Version 3 A Information Security Procedures 2 B Business Continuity 3 C Compliance 4 D Outsourcing and Third Party Access 5 E Personnel 6 F Operations

More information

Public e-procurement in Europe

Public e-procurement in Europe Public e-procurement in Europe Tim McGrath Managing Director Document Engineering Services Washington April 25th 2008 Slide 1 Outline Setting the Scene The Danish Approach The Business Interoperabiliy

More information

The Enterprise Project Management Office

The Enterprise Project Management Office The Enterprise Project Management Office A Conceptual Review Dick Patterson dpatterson@intelcheck.ca 1 Report Overview Almost all enterprises are confronted by accelerating change. An effective, Enterprise

More information

Financial and Cash Management Task Force. Strategic Business Plan

Financial and Cash Management Task Force. Strategic Business Plan Financial and Cash Management Task Force January 30, 2009 Table Of Contents 1 Executive Summary... 4 2 Introduction... 6 2.1 External Reports on Project Aspire... 7 2.1.1 Council on Efficient Government

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