methodology framework

Methodology FrameworkIT Delivery Optimization

May 3, 2013

Robert Sanders

2

Benefits of a Common Methodology

Increased production software reliabilityBy following a disciplined process in designing, constructing, and testing software, a development organization can create applications with the level of reliability required in a production environment

Repeatable development project successesAdherence to a common methodology increases consistency across projects which

Facilitates movement of staff across projects Decreases project startup time Enables more reliable project planning estimates

Earlier identification of project risks and potential failures

Easier software maintainabilityA methodology encourages robust application documentation, change control, and quality control, which results in lower maintenance costs and lower risk when changes are made to production software

Methodology Framework - May 2013 MethodOptimal confidential – © MethodOptimal

3

Higher productivitySoftware development efforts become more productive as a result of

Adhering to better project planning and control practices Adhering to a consistent set of software development processes Using better tools to facilitate SDLC processes

Increased employee empowermentAn common methodology includes management commitment to a program of on-going software improvements. Development staff are encouraged to identify and help implement software process improvements.

Helps achieve adherence to industry standards and certification levelsA methodology provides a foundation for performing assessments of an organization’s software processes. Such assessments are central to the certification process for industry groups such as Software Engineering Institute (SEI).

Benefits of a Common Methodology (cont.)


4

Value of a Common Framework

A methodology is fundamentally a set of well-supported processes. The Software Engineering Institute defines a software process as “a set of activities, methods, practices and transformations that people employ to develop and maintain software and the associated products, including project plans, design documents, code, test cases and user manuals.”

An SDLC methodology is a combination of the textual description of the activities needed to perform a step of the SDLC, and, the supporting tools, role descriptions, deliverable/artifact definitions, templates, procedures, standards, guidelines and examples.


5

SDLC Methodology Framework


An SDLC Methodology has a complex structure that must be viewed from multiple dimensions. MethodOptimal has developed the framework below to represent the three aspects of:

Activities &

Deliverab

les

Key Process Areas – Sequences of tasks performed by roles over time 1

Activities & Deliverables – Process Components and Work Objects produced2

Methodology Components – Detailed characteristics of Processes, Activities, Deliverables and other methodology elements.

3

Relationship between

Process and Artifacts

RolesAnd

Disciplines

Met

ho

do

log

y C

om

po

nen

ts

Key Process Areas

Project Management

Requirements Management (Business, System, Subsystem, Unit)

Analysis and Design (Conceptual, Logical, Physical, Final)

Integration with

Process Tools

Metrics

Prj History

Estimation

Policiesand

StandardsDeliv

erables Definitio

n

• WBS

• Templates / Outlin

es

• Samples

Process Definitio

n

• WBS

• Sub process Definitio

ns

• Procedures

Leading Practices

Advice

Techniques

Project Scenarios

Paths

Roadmaps

Construct and Evaluate (Coding, Integrating, Testing, Debugging)

Post-Project Analysis & Feedback into Knowledge Base

Methodology Repository

Quality1

2

3

6

A Methodology Framework

Methodology Activities and Deliverables At the heart of the methodology is a definition of its activities and deliverables produced Activities or the “Process Definition” should be organized by the Work Breakdown Structure (WBS) which is a

multilevel outline of all activities Each activity should be detailed, including the objectives for the activity and the actions that must be performed In many cases an activity may also be supported by a specific procedure that outlines the steps involved (e.g.,

what commands to type)

Key Process Areas The methodology addresses the full spectrum of processes required for end-to-end execution of a solution

development project. Different methodology products will cover different sets of key processes. For example, most SDLC

methodologies address system analysis and design but don’t always include deployment activities (e.g., selecting a pilot site) in their scope.

Components In addition to the textual description of activities and deliverables, methodology components provide additional

support to a development organization in planning and executing its projects. These components are described in detail in this document.

Repository The methodology repository stores all components of the methodology and provides a user interface for easy

identification of the activities and supporting components for each process.


SDLC MethodologyFramework Example

8

Methodology Framework Examples

The pages that follow provide examples taken from the Open Unified Process. Various screen shots are provided to illustrate the framework elements numbered below:

2

35 1087 9 116

1 Process Coverage

4

OpenUP is a software engineering methodology family. Part of the Eclipse Process Framework it embraces a pragmatic and agile philosophy, meaning that the creators have preserved the essential characteristics of the RUP/Unified Process


http://en.wikipedia.org/wiki/OpenUP

9

1. Process Coverage

A process defines sequences of tasks performed by roles and work products produced over time.

Processes are typically expressed as workflows or breakdown structures. Defining a strict sequence as in a waterfall model is as much a process as defining semi-ordered sequences in iterations of parallel work. They just represent different development approaches. Hence, for defining a process, one can take method content and combine it into structures that specify how the work shall be organized over time, to meet the needs of a particular type of development project (such as software for a online system versus software and hardware for an embedded system).


10

2. Process Definition

The heart of any methodology is the definition of its processes, namely, the activities that must be performed.

In this example, Inception Phase is the high-level process while Initiate Project is a sub-process.

Note that this repository supports:

• Description• WBS• Team Allocation• Work Product Usage

Another essential process attribute is what roles are involved – described in OpenUP as Team Allocation,


11

3. Deliverables Definition

Just as important as the activities performed in a process are the deliverables that are used by or resulting from it. The methodology needs to fully define the deliverables which need to be created and to provide materials to support the development of these deliverables.

Drilling into a process provides access to specific deliverables. For each deliverable, OpenUP provides sub-sections for:• Purpose• Relationships• Main Description• Properties• Illustrations• Key Considerations• Tailoring• More Information

Clicking on an Example the user is routed to additional details from the Guidance section of the repository


12

4. Methodology Repository

The methodology product must include a “methodology repository” which contains the methodology content. This application is used not only to view the methodology content but also to maintain the content.

The Eclipse Process Framework and associated Composer tool takes content such as that described by the Methodology Framework, and structures it in a specific schema of roles, work products, tasks, and guidance.

This schema supports the organization of large amounts of descriptions for development methods and processes. Such method content and processes do not have to be limited to software engineering, but can also cover other design and engineering disciplines such as mechanical engineering, business transformation, sales cycles, and so on.


13

5. Relationship Between Process and Deliverable Definitions

The methodology must provide a strong and consistent relationship between its process definitions and the deliverables which are created, reviewed, and updated as directed by the process definition.

Roles

Activities

OpenUP uses the Workflow element within the WBS Element of a Process Description to depict relationships.

Images in the flow are user selectable and route users to the detailed methodology content for the item selected.

Deliverables


14

6. Roles & Disciplines

The methodology should describe the roles that project members assume when performing the activities defined in the methodology.

Both the Role and Discipline objects are supported within OpenUP.

Both are specialized views into, across and/or around the methodology content.

Some methodologies call Disciplines “Threads”

The Role specification provides both process (activity) and deliverable responsibilities.

OpenUP uses Discipline-specific task objects for process guidance relative to a given area.

Some Methodologies refer to Disciplines as “Competencies”.

OpenUP has articulated the 5 Disciplines of:• Architecture• Development• Project Management• Requirements• Test


15

7. Policies and Standards

Policies are “official communiqués specifying organizational support for the process/sub-process area in terms of organizational needs, expectations, and general principles that all business, project, and engineering operations are expected to observe”*.

* “Software Capability Evaluation, Version 1.5, Method Description,” SEI Technical Report CMU/SEI-93-TR-17

Policies and Standards can be represented in many ways within a Methodology. Depending on the nature of the policy or standard, it can be documented at the process, activity, task, role or other levels.

OpenUP has chosen to embed most of their “standard-like” content into the Process Guidance section and employing an object of type Concept.


16

8. Best Practices / Advice / Techniques

The methodology should incorporate advice, tips, and best practices gleaned from previous projects. This information is often difficult to fully incorporate into the core process description but should be associated with the relevant processes in some way.

Examples

Checklists Concepts Guidelines

OpenUP has a “robust, well-formed and fully articulated” knowledge base comprising 9 object types:• Checklists• Concepts• Examples• Guidelines• Practices• References• Reports• Roadmaps• Templates

(not all shown here)


17

8. Best Practices / Advice / Techniques

The methodology should incorporate advice, tips, and best practices gleaned from previous projects. This information is often difficult to fully incorporate into the core process description but should be associated with the relevant processes in some way.

This example depicts how the Report Guidance Object type of Iteration Burndown cross-references the specific artifact Iteration Plan


18

9. Metrics

“The goal of applied software measurement is to give software managers and professionals a set of useful, tangible data points for sizing, estimating, managing, and controlling software projects with rigor and precision.”* The methodology should facilitate the collection, application, and refinement of metrics for applicable processes.

OpenUP is has minimal content on Metrics.

This has been a traditionally underserved subject within methodologies.

The original Method/1 provided an extensive set of sizing metrics.

Coopers & Lybrand’s legacy SUMMIT-D methodology provided “Quantitative Influencing Factors” for the same purpose.


19

10. Project Roadmaps

The methodology should be able to address the various types of projects of the client. One acceptable strategy is for the methodology to define one or more paths (aka “roadmaps”) for each project scenario.

Roadmaps can be simple guidelines or entire lifecycles within the methodology. OpenUP has both such instances.

In the figure, the “How to…” roadmaps are mostly guidelines whereas the “OpenUP Roadmap” is the OpenUP Lifecycle itself.

Roadmaps are often synonymous with Paths and/or Route Maps in other methodologies.


20

11. Integration with Process-Specific Tools

The methodology should integrate well with the vendor tools as well as with existing client tools.

A Tools Object Type has been defined within OpenUP. This is a classic example of a methodology element that is well-formed, but neither robust or fully articulated.

Only one tools object is persisted within the current version (Method Composer).

Some methodologies are able to import / export certain elements for use by external tools. A useful example is the ability to export the WBS of a lifecycle to MS-Project.


Contact