suse unified delivery process€¦ · p. 5 figure 2 shows the five phases of the suse unified...

24
www.suse.com Guide SUSE® Unified Delivery Process

Upload: doanlien

Post on 06-Aug-2018

215 views

Category:

Documents


0 download

TRANSCRIPT

www.suse.com Guide

SUSE® Unified Delivery Process

p. 2

W h a t I s t h e S U S E ® U n i f i e d D e l i v e r y P r o c e s s ?

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 solution-

delivery 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. 3

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.

S U S E U n i f i e d D e l i v e r y P r o c e s s O v e r v i e w

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. 4

Figure 1: SUSE Unified Delivery Process Overview

T h e D y n a m i c : I t e r a t i o n s , P h a s e s a n d M i l e s t o n e s

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. 5

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. 6

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. 7

• 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. 8

• 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. 9

• 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.

T h e S t a t i c : A c t i v i t i e s , W o r k e r s , D e l i v e r a b l e s a n d T o o l s

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:

• Activities (the “how”)

• Workers (the “who”)

• Deliverables (the “what”)

• Tools

Activities 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. 10

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

Deliverables Deliverables 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.

Deliverables 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

Tools A tool is information, a technology or a technique that workers use while creating the deliverables and final

product(s) for the engagement.

Tools 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. 11

A c t i v i t y T h r e a d s

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 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.

Figure 8: Primary Activity Threads

p. 12

P r i m a r y A c t i v i t y T h r e a d s

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.

Activities • 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

Deliverables • Proposal deck

• Deal review template (DRT)

• Objectives/introductory section in statement of work (SOW)

• Free-standing statement of scope/project charter

Tools • Customer interviews

• Statement of work and pricing tool templates

Direction Setting

p. 13

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.

Activities • 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)

Deliverables • Initiative portfolio and prioritization

• Solution area roadmap and resource plan

• Future-state solution architecture

• Business value justification assessment

Tools • 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. 14

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 future-

state architectures.

Activities • 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)

Deliverables • 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

Tools • Customer interviews

• Reference architectures

• Architecture design patterns

• Business and technology questionnaire response(s)

p. 15

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.

Activities • 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

Deliverables • Requirements assessment report

• Business process maps

• Acceptance criteria documents

• Support and training recommendations

• Interview and session notes

Tools • Customer interviews

• Requirements assessment report templates

• Skills evaluation tools

Detailed Design

p. 16

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.

Activities • 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)

Deliverables • Solution architecture update (as needed)

• Detailed technical design for the solution

• Training materials (as needed)

Tools • 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. 17

• 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.

Activities • 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)

Deliverables • 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

Tools • 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. 18

• 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.

Activities • 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)

Deliverables • Integration tested solution components

• Known defect list

• Integration testing report

Tools • Integration test cases

• Acceptance criteria documents

• Data cleanliness evaluation report

• Test harness (as needed)

• Integration test results dashboard

User Acceptance Testing

p. 19

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.

Activities • 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

Deliverables • User acceptance tested solution components

• Known defect list

• User acceptance testing report

Tools • 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.

Activities • Promote solution functionality in your target environment according to the go-live process

p. 20

• Deploy live

• Execute the production migration plan

• Monitor and resolve any post-production issues

• Perform final knowledge transfer

Workers • Project manager

• Architect

• Technical specialists

Deliverables • Production solution deployment

• Final solution knowledge transfer

• Production deployment documentation

Tools • 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.

Activities • 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. 21

• Services executive

Deliverables • 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)

Tools • Known defect list

• Debugging and troubleshooting tools

• SUSE solution best practices knowledgebase

S u p p o r t i n g A c t i v i t y T h r e a d s

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.

Activities • 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. 22

• Practice lead

Deliverables • Accurate, updated project plan(s)

• Risk and mitigation plans

• Communication plans

• Known issue list and tracking sheet

• Engagement status reports

Tools • 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.

Activities • 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

Deliverables • Verbal mentoring of your personnel

• Brown bag learning sessions

• Documented best practices

Tools • SUSE solution best practices knowledgebase

• SUSE product roadmaps

p. 23

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.

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.

S u m m a r y

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:

Figure 9: Delivery Excellence Reviews

p. 24

• 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-control-

managed 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.