Post on 24-Apr-2015
description
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.)
Methodology Framework - May 2013 MethodOptimal confidential – © MethodOptimal
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.
Methodology Framework - May 2013 MethodOptimal confidential – © MethodOptimal
5
SDLC Methodology Framework
Methodology Framework - May 2013 MethodOptimal confidential – © MethodOptimal
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.
Methodology Framework - May 2013 MethodOptimal confidential – © MethodOptimal
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
Methodology Framework - May 2013 MethodOptimal confidential – © MethodOptimal
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).
Methodology Framework - May 2013 MethodOptimal confidential – © MethodOptimal
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,
Methodology Framework - May 2013 MethodOptimal confidential – © MethodOptimal
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
Methodology Framework - May 2013 MethodOptimal confidential – © MethodOptimal
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.
Methodology Framework - May 2013 MethodOptimal confidential – © MethodOptimal
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
Methodology Framework - May 2013 MethodOptimal confidential – © MethodOptimal
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
Methodology Framework - May 2013 MethodOptimal confidential – © MethodOptimal
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.
Methodology Framework - May 2013 MethodOptimal confidential – © MethodOptimal
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)
Methodology Framework - May 2013 MethodOptimal confidential – © MethodOptimal
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
Methodology Framework - May 2013 MethodOptimal confidential – © MethodOptimal
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.
Methodology Framework - May 2013 MethodOptimal confidential – © MethodOptimal
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.
Methodology Framework - May 2013 MethodOptimal confidential – © MethodOptimal
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.
Methodology Framework - May 2013 MethodOptimal confidential – © MethodOptimal
Contact