Methodology Framework

Methodology Framework
IT Delivery Optimization
May 3, 2013
Robert Sanders

Benefits of a Common Methodology
 Increased production software reliability
By 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 successes
Adherence 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 maintainability
A 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
2 Methodology Framework - May 2013 MethodOptimal confidential – © MethodOptimal

 Higher productivity
Software 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 empowerment
An 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
levels
A 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.)

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.

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&Deliverables
Key Process Areas – Sequences of tasks performed by roles over time1
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
Roles
And
Disciplines
MethodologyComponents
Project Management
Requirements Management (Business, System, Subsystem, Unit)
Analysis and Design (Conceptual, Logical, Physical, Final)
Integration
with
Process
Tools
Metrics
Prj History
Estimation
Policies
and
Standards
Leading
Practices
Advice
Techniques
Project
Scenarios
Paths
Roadmaps
Construct and Evaluate (Coding, Integrating, Testing, Debugging)
Post-Project Analysis & Feedback into Knowledge Base
Methodology Repository
1
2
3

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 Methodology
Framework Example

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

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

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,

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

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.

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

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

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.

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)

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

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.

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.

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.

Methodology Framework

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (11)

Semelhante a Methodology Framework

Semelhante a Methodology Framework (20)

Último

Último (20)

Methodology Framework