SUSE Unified Delivery Process

Similar documents
Introduction of RUP - The Rational Unified Process

Software Development Life Cycle:

Rational Software White Paper TP 174

7. Model based software architecture

Passit4Sure.OG Questions. TOGAF 9 Combined Part 1 and Part 2

Enterprise Data Strategy and Governance

IBM Software Rational. Five tips for improving the ROI of your software investments

[Name] [ ID] [Contact Number]

Test Workflow. Michael Fourman Cs2 Software Engineering

Development Environment Definition

SOFTWARE ENGINEERING SOFTWARE-LIFE CYCLE AND PROCESS MODELS. Saulius Ragaišis.

Enterprise Monitoring Management

Actionable enterprise architecture management

Oracle Unified Method (OUM) The OUM Implement Core Workflow The Key to Understanding and Applying OUM. An Oracle White Paper April 2012

Quantifying the Value of Investments in Micro Focus Quality Center Solutions

How mature is my test organization: STDM, an assessment tool

The good news. 34% of software projects succeed. Standish Group, CHAOS Report, 2003

Software Engineering and Software Engineers

An Overview of the AWS Cloud Adoption Framework

Information Technology Services Project Management Office Operations Guide

Harnessing the power of agile development

CHAPTER 2: IMPLEMENTATION PHASES AND OFFERINGS

Lecture 1. In practice, most large systems are developed using a. A software process model is an abstract representation

Effective SOA governance.

ADM The Architecture Development Method

Program Lifecycle Methodology Version 1.7

A New Divide & Conquer Software Process Model

1.0 PART THREE: Work Plan and IV&V Methodology

Federal Segment Architecture Methodology Overview

The Role of Architecture in Enterprise Processes

IBM Software Services for Lotus To support your business objectives. Maximize your portal solution through a rapid, low-risk deployment.

Testing. CxOne Standard

QUALITY ASSURANCE PLAN OKLAHOMA DEPARTMENT OF HUMAN SERVICES ENTERPRISE SYSTEM (MOSAIC PROJECT)

Project Planning and Management (PPM) V2.0. WBS Dictionary

An Oracle White Paper February Oracle Unified Method (OUM) Oracle s Full Lifecycle Method for Deploying Oracle-Based Business Solutions

The Systems Development Lifecycle

Data Warehousing provides easy access

VMware Cloud Automation Design and Deploy IaaS Service

TOGAF 9.1 in Pictures

APPENDIX O CONTRACTOR ROLES, RESPONSIBILITIES AND MINIMUM QUALIFICATIONS

Planning the Work How to Create a Manageable Enterprise GIS Project Plan

Rational Unified Process (RUP) in e-business Development

Software Engineering

Process, Models, Methods, Diagrams Software Development Life Cyles. Part - II

Requirements Analysis and Design Definition. Chapter Study Group Learning Materials

Advantages and Disadvantages of. Independent Tests. Advantages. Disadvantages

Software Modeling & Analysis. - Fundamentals of Software Engineering - Software Process Model. Lecturer: JUNBEOM YOO

Software Processes. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1

JOB DESCRIPTION. Senior Business Analyst.docx. Proposed band

Introduction to Systems Analysis and Design

Chapter 2: Project Methodologies and Processes

TOGAF Foundation Exam

PART 1: INTRODUCTION. Purpose of the BIZBOK Guide. What is Business Architecture?

Chapter 8. Systems Development. Ralph M. Stair George W. Reynolds

Ingegneria del Software Corso di Laurea in Informatica per il Management

PART THREE: Work Plan and IV&V Methodology (RFP 5.3.3)

Address system-on-chip development challenges with enterprise verification management.

Chapter 3 Prescriptive Process Models

Business Case for Value Realization During Implementation Delivering Projects on Time, on Budget, and on Value

Risk Mitigation in a Core Banking Conversion

Project Management CSC 310 Spring 2018 Howard Rosenthal

Software Processes. Objectives. Topics covered. The software process. Waterfall model. Generic software process models

Exam Questions OG0-091

The software process

Objectives. The software process. Topics covered. Waterfall model. Generic software process models. Software Processes

ORACLE SOA GOVERNANCE SOLUTION

Major attributes of the Lifecycle. The Systems Development Lifecycle. Project phases. Planning. Design. Analysis

Introduction to Software Engineering

How Business Analysis Can Improve Sales and Marketing Outcomes

Child Welfare Services New System Project. Requirements Management Plan

Program Management Effectiveness

Fueled with ALM Octane

M3 Playbook Guidance. 1.1 Establish Initial Customer PMO and Processes. Human Resources (HR)/Staffing Plan

Planning the Work How to Create a Manageable Enterprise GIS Project Plan

AVEPOINT CLIENT SERVICES

Software Process. Overview

Evaluating Treasury Management Systems

Enterprise Architecture: an ideal discipline for use in Supply Chain Management

WORKSOFT AUTOMATED BUSINESS PROCESS DISCOVERY & VALIDATION

Business Architecture Fundamentals

Toolbox for Architecture Framework Discussions at The Open Group. SKF Group, February 2018

What Is the Rational Unified Process?

IT Service Management for DevOps

Fixed Scope Offering for Implementation of Oracle Fusion CRM in Cloud

CORROSION MANAGEMENT MATURITY MODEL

Project Management Knowledge Areas SECTION III

Chapter 3. Information Systems Development. McGraw-Hill/Irwin. Copyright 2007 by The McGraw-Hill Companies, Inc. All rights reserved.

The Unified Software Development Process

A Freshwater Partners White Paper

2009 Spring. Software Modeling & Analysis. - Software Process Model. Lecturer: JUNBEOM YOO

Manage Projects Effectively

2 Why is systems development difficult and risky? 3 How do businesses use the systems development life cycle (SDLC) process?

Business Analysis Essentials

Job Family Matrix. Core Duties Core Duties Core Duties

Introduction to Agile Software Development

Large Federal Agency Leverages IV&V to Achieve Quality Delivery for Critical Modernization Initiative

Topics covered. Software process models Process iteration Process activities The Rational Unified Process Computer-aided software engineering

By: Ronny Trefftzs CSCI 5828: Foundations of Software Engineering Spring 2012 Professor: Kenneth Anderson

Transcription:

Guide www.suse.com SUSE Unified Delivery Process

What Is the SUSE Unified Delivery Process? The SUSE Unified Delivery Process is a solution delivery process based on the IBM* Rational Unified Process* (RUP*). RUP is a software engineering process; SUSE Unified Delivery Process takes the core principles and vocabulary from RUP and applies them to a broader solution space where the effort goes beyond pure application development. We use the SUSE Unified Delivery Process to assign tasks and responsibilities to a solution team to help your organization produce high-quality solutions that meet your needs within a predictable schedule and budget. SUSE Services develops and maintains the SUSE Unified Delivery Process, and works closely with customers, partners and other groups within SUSE to continuously update and improve the process to reflect recent experiences and proven best practices. The SUSE Unified Delivery Process enhances team productivity by providing every team member with easy access to a consistent view of solution delivery, with guidelines, templates, sample deliverables and tools for all critical development activities. As a result, all team members share a common language, process and view of how to deliver the solution, whether they work with requirements, design, test, or provide project management. The SUSE Unified Delivery Process meets the needs of small project teams as well as large delivery structures. It is founded on a simple and clear process flow that is common across a family of engagement types, but we can also adjust it to accommodate different situations. The process flow itself is based on several solution-delivery principles that incorporate many of today s solutiondelivery best practices for ensuring success, in a form that suits SUSE customer engagements of all sizes. The best practices are as follows: Engage in iterative solution development. Manage requirements. Use clearly defined architectures based on proven solution reference architecture. Verify solution quality. Control changes to the solution. Engage in Iterative Solution Development With today s sophisticated environments and complex solutions, it is impossible to define the entire problem, design the entire solution, build it and test the product at the end. Businesses require an iterative approach that enables them to understand the problem fully through successive refinements, and allows them to build an effective solution incrementally over multiple iterations. The SUSE Unified Delivery Process supports an iterative approach to solution delivery that addresses the highest-risk items at every stage in the lifecycle, significantly reducing a project s risk profile. We attack risk by progressing through frequent, executable releases that enable continuous end-user involvement and feedback. Because each iteration ends with an executable release, the project team stays focused on producing results. Frequent status checks help ensure that the project stays on schedule. An iterative approach also makes it easier to accommodate tactical changes in requirements, features or schedule. p. 2

Manage Requirements The SUSE Unified Delivery Process describes how to elicit, organize and document required functionality and constraints, track and document tradeoffs and decisions, and easily capture and communicate business requirements. The use cases and scenarios we explore in the process are an excellent way to capture functional requirements and ensure that these drive solution design, implementation and testing, making it more likely that the final solution fulfills the customer s needs. Use Clearly Defined Architectures Based on Proven Solution Reference Architecture The process prescribes early solution architecture development and baselining prior to full-scale solution construction. It describes how to design a resilient architecture that is flexible, intuitively understandable, accommodates change and promotes a more effective solution. The SUSE Unified Delivery Process is built on proven reference architecture models, ensuring that we always incorporate the most up-to-date technology and process best practices in our solutions Verify Software Quality Poor performance and poor reliability are common factors that make solutions unacceptable for today s business users. You should review the reliability, functionality, performance and availability of your solution. The SUSE Unified Delivery Process helps us plan, design, implement, execute and evaluate quality assessment. The assessment uses objective measurements and criteria, and is not treated as an afterthought or a separate activity that a separate group performs. Control Changes to the Solution To manage change in an environment where change is inevitable, you must track these changes and make certain that each is acceptable. The SUSE Unified Delivery Process describes how to control, track and monitor changes for successful iterative solution development. SUSE Unified Delivery Process Overview The SUSE Unified Delivery Process defines a flexible framework for delivering complex, business-driven projects. Using the process, we will create a project plan that matches your organization s specific needs while aligning with delivery best practices. The combination of dynamic and static constructs enables us to adapt the SUSE Unified Delivery Process to the specific needs of each engagement. Figure 1 illustrates the process: The horizontal axis presents time and the dynamic aspect of the process. It displays all project iterations, phases, and milestones. The vertical axis presents the static aspect of the process in terms of activities, workers, deliverables and tools. p. 3

Figure 1: SUSE Unified Delivery Process Overview The Dynamic: Iterations, Phases and Milestones As Figure 1 illustrates, the SUSE Unified Delivery Process divides the solution lifecycle into five phases. Discovery Inception Elaboration Construction Transition We conclude each phase with a well-defined milestone a point in time at which we must make certain critical decisions in order to reach key goals. We define each milestone during a Delivery Excellence review. Figure 2: SUSE Unified Delivery Process Phases and Milestones p. 4

Figure 2 shows the five phases of the SUSE Unified Delivery Process along with the milestone occurring at the completion of each phase. Most solutions will require multiple iterations of these phases, and the SUSE Unified Delivery Process supports this kind of flexibility. In addition, the arrow connecting the end of the Transition phase and the beginning of the Discovery phase indicates that our process includes a consistent feedback loop, enabling future iterations to benefit from the wisdom and knowledge gained during the preceding iteration. Discovery Phase Figure 3: Discovery Phase During the Discovery phase we establish the business needs the solution must address and define the high-level project scope by identifying your organization s business needs and drivers. We also define initial project management artifacts (such as a project plan providing major milestones, risk assessment, and a staffing model) based on the solution structure. The deliverables of the Discovery phase are: A functional definition for the engagement, which includes the solution definition, key features, main constraints and success criteria A business definition for the engagement, which includes the financial plan (estimates for effort and pricing) and a risk assessment and mitigation plan An initial project plan showing phases and iterations An internal SUSE deal-review presentation A statement of work defining the customer and SUSE contractual agreement for the engagement Discovery Phase Delivery Excellence Review The evaluation criteria for the Discovery phase delivery excellence review are: Customer stakeholder concurrence on the business definition, business value and customer resource investment Agreement on scope definition and cost and schedule estimates Agreement on project risks and mitigation plans A Go Ahead from customer stakeholders and SUSE delivery management Inception Phase Figure 4: Inception Phase During the Inception phase we launch the project, and we develop a deeper understanding of your business environment and the architectural make-up of the solution. The Inception phase brings together a broader set of p. 5

organizational stakeholders and SUSE participants, including all parties who play a significant role in the engagement. To accomplish this we will conduct direction-setting and architecture-definition activities as required. This includes kickoff activities that align stakeholders and SUSE participants in terms of project schedule, milestones and assumptions as well as your organization s responsibilities. We also refine the initial project management artifacts we all agreed upon during the Discovery phase. The deliverables of the Inception phase are: Refined project management artifacts, including a detailed project plan, a risk assessment and mitigation plan, status reporting and a change control process definition Direction-setting materials, including current state assessment, future state recommendations, initiative prioritization, road mapping and business value justification (if needed) Solution architecture design Completed project kickoff meeting Inception Phase Delivery Excellence Review The evaluation criteria for the Inception phase delivery excellence review are: Assessment of the project risk and mitigation plans Assessment of the customer s readiness and the availability of resources (both people and computing) Review of the deliverables created during the direction-setting and architecture-definition activities Review of any issues or to-do items based on the project kickoff activities Assessment of any changes to future phases (schedule, effort and cost) Elaboration Phase Figure 5: Elaboration Phase In the Elaboration phase we deeply analyze the problem domain, extend the high-level architecture definition and establish a sound, detailed design for the solution. By the end of this phase the difficult engineering is done. Although the process must always accommodate changes, in this phase we ensure that the architecture, requirements and plans are stable enough and the risks are sufficiently mitigated so you can predictably move ahead and complete the solution. In addition to requirements gathering and detailed design, the Elaboration phase activities include mapping business processes to the solution and documenting testing criteria. In this phase we will also work with you to complete a training and support assessment and training plan for your organization. The deliverables of the Elaboration phase are: A requirements-definition document, which includes solution use cases, business process maps, data flows and technical requirements p. 6

A detailed design document As needed, an updated architecture definition Test criteria As needed, updated project management artifacts The Elaboration Phase Delivery Excellence Review At this point we will examine the detailed system objectives and scope, architecture and design choices, and resolution of the major risks. The evaluation criteria for the Elaboration phase delivery excellence review are: Review of solution scope and requirements priorities Review of the detailed design for solution correctness and technical complexity Validation of product placement and usage Review of technical risks and mitigation plans Review of actual versus planned engagement expenditures Review of and revision to plans for next phase (as needed) Review of support risks and mitigation plans Construction Phase Figure 6: Construction Phase During the Construction phase, we construct the solution defined in the Elaboration phase, managing resources and controlling operations to optimize costs, schedules and quality. When we conclude the phase, you will have a fully implemented and tested solution ready to put in the hands of your end users. Some projects are large enough that one Elaboration phase can spawn parallel construction phases. These parallel activities can significantly decrease the time to deployable releases. The deliverables of the Construction phase are: An implemented and fully tested instance of the solution An integration testing report A deployment/migration plan Delivered training As needed, updated project management artifacts As needed, an updated architecture and solution design The Construction Phase Delivery Excellence Review At this point we will review the results of the Construction phase to make sure the solution is ready for final testing and deployment. The evaluation criteria for the Construction phase delivery excellence review are: Review of solution testing and defect resolution results Determination of the solution s readiness for deployment p. 7

Determination of your organization s readiness for solution deployment Review of actual versus planned engagement expenditures Review of and revisions to plans for next phase (as needed) Assessment of customer supportability risks and mitigation As needed, review of updated solution design Transition Phase Figure 7: Transition Phase In the Transition phase we turn the solution over to you. We also help you complete user acceptance testing and deploy the solution in the target production environment. And we activate support processes and resources you will leverage post deployment. Finally, the Transition phase includes all remaining training and knowledge transfer. The deliverables of the Transition phase are: User acceptance testing results and a known defect list A solution deployed in the target production environment Fully trained users, administrators and operations staff Any installation or operations documentation agreed to in the statement of work (SOW) we drafted during the Discovery or Inception phases Transition Phase Delivery Excellence Review At this point we will review the overall success of the project and look ahead to future iterations and phases. The evaluation criteria for the Transition phase delivery excellence review are: Assessment of user acceptance of the deployed solution Review of operations characteristics of the solution in production Review of actual versus planned engagement expenditures Final sign-off of project deliverables Iterations Most of the solutions we implement using the SUSE Unified Delivery Process span multiple iterations. An iteration is a complete solution implementation loop resulting in a release (internal or external) of the solution. The releases grow incrementally from iteration to iteration to become the final solution. It is neither pragmatic nor reasonable to tackle an entire enterprise-class solution in one waterfall process. These projects are always subject to delays, scope changes and other issues, leading to missed deadlines and overextended budgets. By using iterations of our process, we are able to deliver frequent, tangible results while keeping costs down and demonstrating alignment with your core business drivers and business requirements. Compared to the traditional waterfall process, the iterative process has the following characteristics: p. 8

It requires that we set forth clear objectives for each iteration: for example, all architectural risks mitigated or all features required to support the Human Resources onboarding process built and tested. The iteration is not over until the objectives are met. It supports a just-in-time mentality. For example, using this process, we would not produce the detailed requirements for a feature until we are ready to design, build and test that feature. It is founded on the understanding that a deliverable is never finished, but rather meets the objectives of the iteration. Solution requirements and design deliverables are living, breathing documents that evolve as the solution does in future iterations. It requires that we use the risk and mitigation plan to decide what to do in early iterations. For example, if the requirements for a feature are difficult to pin down (a risk), we must detail the requirements of that feature and design, build and test it in an early iteration. Customer stakeholders can then see the feature; and, based on their feedback, we can revise the requirements. Iterations can overlap slightly. We can maximize the use of resources for everyone involved in the solution by focusing on future iterations as we finish the current one. It requires a dedicated project manager to perform the detailed scheduling of iterations. The overall project plan is just a set of milestones and dates. We do not detail the plan for each iteration until we start that iteration. However, the risk and mitigation plan drives the detailed planning. The Static:, Workers, and The static aspect of the SUSE Unified Delivery Process defines the activity threads that contain the work effort within each of the phases and iterations. These activity threads contain the activities to be completed, the workers who will complete these activities, the deliverables they will produce, and the tools they will use to produce them. We will describe the activity threads in detail, but first we need to describe the elements used as building blocks for each activity thread. There are four major elements within each activity thread: (the how ) Workers (the who ) (the what ) The activities that we define during an engagement have a clear purpose, usually to create or update one or more deliverables, such as a document, product configuration or plan. Each activity typically involves one worker, takes a few hours to a few days to complete, and affects one or only a small number of deliverables. An activity is an element of planning and progress and must be the right size to fill that role. If an activity is too small it will be neglected, and if it is too large we would need to express progress in terms of the activity s parts. Example of activities: Plan an iteration: project manager Capture business requirements for the worker: business analyst, strategist, architect or senior technology specialist Review the design for the worker: architect or principal technology specialist Execute performance test for the worker: senior technical specialist or project manager p. 9

Workers In the SUSE Unified Delivery Process each worker performs a certain set of activities and owns a set of deliverables. Workers typical of our engagements include the following: Senior project manager: overall project lead and owner Senior or principal architect: project technical lead Senior technical specialist: SUSE product specialists Senior consultant: implementation lead Senior strategists: business planning and analysis specialists are the tangible products of the engagement that which workers produce while working toward the final product. Workers use these as input to perform an activity, and deliverables are also the result or output of such activities. typical of our engagements include the following: A presentation slide deck, such as a solution roadmap or solution architecture definition A document, such as a requirements definition or a detailed design document. A spreadsheet, such as a business value justification, an initiative prioritization or a physical environment definition A configured product or configuration scripts Source code Executables A tool is information, a technology or a technique that workers use while creating the deliverables and final product(s) for the engagement. typically used within our engagements include the following: Templates, for maintaining consistency from engagement to engagement Testing harness, for automating as much of the testing process as possible Estimation model, for accurate, systematic and explainable estimates on complex solution engagements Architecture and design patterns, for applying the right architecture and design constructs to the solution Product playbooks, for applying the appropriate product implementation best practices Product management tools, for maintaining a consistent, high quality approach to project management from engagement to engagement As we continue defining the static elements of the SUSE Unified Delivery Process, you should keep the definitions of these four elements in mind. Each activity thread will be defined in the context of these four elements. p. 10

Activity Threads The aggregate of all activities, workers, deliverables and tools is not quite a working process. We need a way to describe meaningful sequences of activities that produce some valuable result, and we need a way to show interactions between workers. It is not always possible or practical to represent all of the dependencies between activities. Often two activities are more tightly interwoven than shown, especially when they involve the same worker, tools or deliverables. People are not machines, and we cannot interpret the activity threads literally as a program for people, to be followed exactly and mechanically. The SUSE Unified Delivery Process contains ten primary activity threads and two supporting activity threads, which represent all workers and activities partitioned into logical groupings Figure 8: Primary Activity Threads Figure 8 displays both the primary activity threads and the supporting activity threads in a conceptual sequential mode. We say this is conceptual because during an actual engagement some of the activity threads will overlap and some may repeat, depending on the circumstances. The primary activity threads are: Scope Direction Setting Architecture Design Requirements Assessment Detailed Design Build, Configure and Develop Integration Testing User Acceptance Testing Deployment Support In addition, there are two supporting activity threads that continue throughout the life of an engagement: Project Management Knowledge Transfer Together, these twelve activity threads provide the fabric for delivering solutions based on the SUSE Unified Delivery Process. Although the names of the activity threads may remind you of the sequential phases in a traditional waterfall process, keep in mind that the phases of an iterative process are different, and that stakeholders revisit these activity threads again and again throughout the lifecycle. Every engagement interleaves the activity threads and repeats them with various emphasis and intensity during each iteration. p. 11

Primary Activity Threads The ten primary activity threads are defined in terms of the activities, workers, deliverables and tools associated with the thread. Scope The primary goal of the Scope thread is for all parties involved (SUSE, customer or partner) to agree on what the solution will include and the key assumptions. The activities include customer stakeholders defining and capturing the solution objectives. In turn we define and capture the solution boundaries, including the organizational areas, users and systems involved, and determine and communicate the SUSE products the engagement requires. Review business statements and dimensions Determine the involved systems, processes and people/identities Define delivered capabilities Review the budget Create a plan to address dependencies, risks, sponsors, and communication Workers Services principal Project manager Architect Strategist Practice lead Proposal deck Deal review template (DRT) Objectives/introductory section in statement of work (SOW) Free-standing statement of scope/project charter Customer interviews Statement of work and pricing tool templates Direction Setting p. 12

In the Direction Setting thread we establish a clear, business-driven direction for your organization within the technology area the engagement targets. We work with your business leaders to create consensus on the business and technical initiatives that will benefit from SUSE technology. In order to create this consensus, we define a future-state architecture along with an implementation roadmap illustrating the major activities required to move to the recommended future state. If needed, we also create financial justification for the project so that it receives the necessary approvals. And throughout this phase we continue to educate your organization about the business value and technical merit of the SUSE solution. Validate business drivers Validate solution goals and objectives Assess current-state technology, processes and skills. Develop future-state recommendations Perform a current-state architecture assessment Define a conceptual future-state solution architecture Identify and prioritize initiatives Create a business value justification Create a gap analysis (current state versus. future state) Develop a recommended solution roadmap Develop a resource plan Workers Architect Strategist Technical specialist (as needed) Initiative portfolio and prioritization Solution area roadmap and resource plan Future-state solution architecture Business value justification assessment Customer technical, business, organization, and audit documentation Customer interviews Business and technology questionnaire response(s) Initiative prioritization method and worksheets Business value justification worksheets Architecture Design x p. 13

The Architecture Design thread creates the technical foundation for the solution. In this thread we define the solution architecture based on the business context gathered during the Direction Setting and Scope threads. We also gather additional requirements (both business and technical) as necessary. The architecture design consists of a number of architectural views. These views capture the major structural design decisions. At their core, architectural views are abstractions or simplifications of the entire design. We make important characteristics more visible by leaving details to a later time. The architecture is an important vehicle for creating an accurate, detailed design and increasing the quality of the solution build. The Architecture Design thread also communicates the gaps between current-state and futurestate architectures. Review current architecture and existing technologies within the solution area Review current IT strategy and planned technical initiatives Review business strategy for future-state architecture impact (acquisitions, divestitures and so forth) Conduct interviews with key stakeholders having both technical and business responsibilities Define future-state architecture Assess gaps between the current-state and the defined future-state architecture Workers Project manager Architect Architect Technical specialist (as needed) Future-state architecture definition, including: Conceptual architecture Data model and architecture Logical architecture Physical and security architecture Deployment architecture Gap analysis Interview and session notes Customer interviews Reference architectures Architecture design patterns Business and technology questionnaire response(s) p. 14

Requirements Assessment The goal of the Requirements Assessment thread is for all parties to agree on what the solution should do. We define the solution use cases, business constraints and technical requirements, and we capture, structure and document required functionality and constraints. We also document the trade-offs and decisions that define the solution. The requirements we gather determine how we construct and test the solution and support it after implementation. To this end we will seek to understand your organizational structure, behavior, and support and operational processes. Validate solution goals and objectives Conduct customer interviews and review available customer documentation Define resource requirements (hardware, software and people) Create the requirements assessment report Prioritize requirements (in relative order) Create acceptance criteria documents Map business processes to the solution Assess customer support and training requirements Workers Project manager Architect Strategist Technical specialist Requirements assessment report Business process maps Acceptance criteria documents Support and training recommendations Interview and session notes Customer interviews Requirements assessment report templates Skills evaluation tools Detailed Design p. 15

The goal of the Detailed Design thread is to illustrate how we will create the system during the following phases. We want to make sure we build a system that meets all the defined requirements and performs the tasks and functions in the specified production environment. We base the detailed design on the architectural blueprint created in an earlier thread. The production and validation of the architecture is a prime focus of the Detailed Design thread. It is during the Detailed Design that we validate the hardware and software specifications for all labs and production environments. We also start to execute the training plan created in the Requirements Assessment thread. Conduct customer interviews and review available customer documentation Validate and update resource requirements (hardware, software, people) for all labs and production environments Create the detailed design document Conduct customer training classed (as needed) Workers Project manager Architect Technical specialist (as needed) Solution architecture update (as needed) Detailed technical design for the solution Training materials (as needed) Customer interviews Solution architecture definition Detailed design template Acceptance criteria template Build, Configure and Develop As its name implies, the goal of this thread is to build, configure and develop the solution. A more general software development lifecycle definition would refer to this thread as implementation or development, but because of the product-centric nature of the SUSE Unified Delivery Process, we use a thread name that is more descriptive of the activities contained within. In this thread we: Build the solution environments required to deliver the solution defined in the previous threads p. 16

Configure the products (SUSE, open source, and third party) required to deliver the solution defined in the previous threads Develop any custom code or scripts required to deliver the solution defined in the previous threads This thread also includes a robust unit testing process. Build configuration environment Load and configure an appropriate automated testing harness Install and configure solution functionality in development and test labs Perform any development activities (as needed) Perform unit tests Validate test results Create code fixes and retest Build deployment and migration process; test data and scripts Write integration test cases Support you in defining user acceptance test cases Workers Project manager Architect Technical specialist (as needed) Integration and user acceptance test cases Installation and configuration of lab environments Unit-tested solution components Known defect list Deployment plan, processes and test data Engagement scope definition (to establish boundary conditions for building test cases) Solution architecture definition Detailed design document Production, testing and development lab specifications Acceptance criteria documents Integration Testing The Integration Testing thread ensures that all the individually developed and unit-tested solution components work well together, contain the required functionality and meet the technical demands of the solution. Integration testing: p. 17

Verifies proper software component integration Verifies that all requirements have been correctly implemented Identifies and ensures we address defects before you deploy the solution As discussed earlier, the SUSE Unified Delivery Process dictates an iterative approach. This means, in part, that we test throughout the solution creation lifeycle. Doing so enables us to find defects as early as possible, which radically reduces the cost of fixing the defect. We test reliability, functionality and performance. For each of these quality dimensions, the process prescribes that we go through the test lifecycle of planning, design, implementation, execution and evaluation. Our approach to testing also includes automated testing wherever possible. Automated testing is especially important when you use an iterative approach. It enables regression testing at the end of each iteration and with each new version of the solution. Load and configure the test harness (as needed) Update and test the lab environment (as needed) Perform integration tests Validate test results Update the solution and retest Create a known defect list Update deployment and migration processes; test data and scripts (as needed) Create an integration testing results report Workers Project manager Technical specialists (as needed) Integration tested solution components Known defect list Integration testing report Integration test cases Acceptance criteria documents Data cleanliness evaluation report Test harness (as needed) Integration test results dashboard User Acceptance Testing p. 18

User Acceptance Testing begins the transition of a specific iteration from our hands to yours. During this thread you will validate that the pre-defined business scenarios function properly within the solution. We will transfer our knowledge to your workers who will perform the user acceptance testing. They will identify any final defects in the solution prior to deployment. Update test labs (as needed) Perform user acceptance tests Validate test results Update the solution and retest Update the known defect list Update deployment and migration processes; test data and scripts (as needed) Create a user acceptance testing results report Workers Project manager Architect Strategist Technical specialist Practice lead User acceptance tested solution components Known defect list User acceptance testing report User acceptance test cases Test harness (as needed) User acceptance test results dashboard Deployment The purpose of the Deployment thread is to produce a successful release of the solution and deliver that to your end users. We install the solution into your production environment, perform all necessary migration and validation tasks, and transfer knowledge to your end users and operations teams. Although deployment activities are mostly centered on the Transition phase, many are included in earlier phases to prepare for deployment when the project plan dictates. Promote solution functionality in your target environment according to the go-live process p. 19

Deploy live Execute the production migration plan Monitor and resolve any post-production issues Perform final knowledge transfer Workers Project manager Architect Technical specialists Production solution deployment Final solution knowledge transfer Production deployment documentation Successful integration and user acceptance test results Solution rollback plan Deployable solution components and source code Go-live process and deployment plan Known defect list Data cleanliness assessment report Support Unlike the other activity threads, the Support thread continues on after the completion of the engagement for a length of time determined by your support contract with SUSE. It is common for support to continue as we deliver additional iterations or new engagements. The goal of the Support thread is to ensure that the solution meets your uptime service level agreement (SLA) and availability demands, and to limit and resolve product issues as they arise. We will also continue to educate you about the solution and how you can best use SUSE technology to resolve business problems as they arise. The workers delivering the Support thread often become your trusted advisors. Support the deployed solution to your purchased level of support Resolve and limit product issues Transition product defects and enhancements identified during the project lifecycle Proactively maintain the health of the solution Workers Field support engineer p. 20

Services executive Support activity reports (weekly, monthly, and so forth) Product issue reports Customer satisfaction results (surveys, interviews, and so forth) Additional opportunity definition (new solutions, additional phases on existing solution, and so forth) Known defect list Debugging and troubleshooting tools SUSE solution best practices knowledgebase Supporting Activity Threads Project Management Project management is the art of balancing competing objectives, managing risk and overcoming constraints to successfully deliver a solution that meets the needs of both customers (solution owners and administrators) and the end users who use the solution to complete their daily work assignments. This is not a task to be considered lightly. The fact that so few projects are unarguably successful is comment enough on the difficulty of the task. This activity thread cuts across all of the other activity threads and phases to provide a consistent, agile, flexible approach to managing complex solutions. Create and manage project schedules Create and manage risk assessment and mitigation plans Create a quality management approach (identify the types of project reviews and walkthroughs that will be conducted,both internal and external) Provide change management As needed, oversee and direct customer tasks that affect project completion Create baseline and manage project financials Produce regular project-status communications Lead communication with the customer and SUSE on the overall status of the project and the resolution of specific project issues. Close project (project evaluation, signoff, team reviews, archive) Workers Project manager p. 21

Practice lead Accurate, updated project plan(s) Risk and mitigation plans Communication plans Known issue list and tracking sheet Engagement status reports Project management software Project management templates and guidelines Knowledge Transfer SUSE believes that educating our customers during the course of our engagements is a critical part of a successful project, and critical to our long-term relationships with our customers as well. This activity thread is shown as a supporting thread, covering the full lifecycle of the methodology, because we include knowledge transfer activities in almost every primary activity thread. Knowledge transfer continues during the Support activity thread for as long as you engage with us. Mentor your organization s resources on SUSE technology Communicate SUSE solution best practices Communicate SUSE product enhancements Workers Field support engineer Services Account Manager (SAM) Architect Project manager Technical specialist Strategist Verbal mentoring of your personnel Brown bag learning sessions Documented best practices SUSE solution best practices knowledgebase SUSE product roadmaps p. 22

Delivery Excellence Reviews We use the Delivery Excellence process to maintain quality and consistency across our solutions. The Delivery Excellence reviews are comprehensive reviews occurring after each phase in the project lifecycle. Figure 9: Delivery Excellence Reviews The length and method (face to face, conference call, and so forth) of the Delivery Excellence review varies based on project complexity and the project phase we are reviewing, and each Delivery Excellence review has a slightly different focus and different deliverables. (as spelled out in detail in The Dynamic: Iterations, Phases and Milestones section of this paper, which discusses project phases.) That said, all projects adhere to the review cadence that the SUSE Unified Delivery Process defines. To provide a common, accepted view of solution delivery and support, a cross section of SUSE resources conduct the Delivery Excellence reviews, including the following: The full SUSE services team involved with the customer engagement including resources from consulting and support (the SUSE Premium Support Engineer or Dedicated Support Engineer [PSE/DSE]), and partners who are involved in the project. A full SUSE services team for peer review including representatives of the SUSE services architecture, project leadership and business-unit solution practices teams SUSE engineering resources from the appropriate business unit(s) Field sales representatives that are active with the engagement or account (as needed) We aggregate all Delivery Excellence review results into a set of action items for the project manager to track and address. This review is available to all SUSE, partner and customer management. Summary We created the SUSE Unified Delivery Process to ensure successful delivery of client engagements using SUSE products and associated technologies. In this paper we discussed how the strength and flexibility of the process are due to the two distinct axes of defined activities: p. 23

The dynamic axis is composed of the engagement phases. We can structure these phases in different ways depending on customer and engagement requirements. They are organized into increments, enabling us to deliver the working parts of the solution as frequently as feasible and desired. The phases are: Discovery Inception Elaboration Construction Transition The static axis is composed of the primary and supporting activity threads. These activity threads provide the detailed activities that must occur within each phase for the project to be successful. The activity threads are: Scope Direction Setting Architecture Design Requirements Assessment Detailed Design Build, Configure and Develop Integration Testing User Acceptance Testing Deployment Support Project Management Knowledge Transfer The SUSE Unified Delivery Process enables us to provide priority-driven, goal-focused, and change-controlmanaged engagements. It allows for proofs of concept, pilots (production or tests), prototypes, alpha and beta releases, and full production releases. When combined with architectural, design and product configuration best practices, this process limits risk and ensures the success of engagements with our customers and partners. 2012 SUSE. All rights reserved. SUSE and the SUSE logo are registered trademarks of Novell, Inc. in the United States and other countries. All third-party trademarks are the property of their respective owners. p. 24