Methodology Framework

1,565 views
1,385 views

Published on

Ever wonder what a robust, well-formed and fully articulated methodology should look like? We've used our Methodology Framework to provide you an real-world (and free!) example.

Published in: Business, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,565
On SlideShare
0
From Embeds
0
Number of Embeds
26
Actions
Shares
0
Downloads
35
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Methodology Framework

  1. 1. Methodology Framework IT Delivery Optimization May 3, 2013 Robert Sanders
  2. 2. 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
  3. 3.  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.) 3 Methodology Framework - May 2013 MethodOptimal confidential – © MethodOptimal
  4. 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. 4 Methodology Framework - May 2013 MethodOptimal confidential – © MethodOptimal
  5. 5. SDLC Methodology Framework 5 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&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
  6. 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. 6 Methodology Framework - May 2013 MethodOptimal confidential – © MethodOptimal
  7. 7. SDLC Methodology Framework Example
  8. 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 8 Methodology Framework - May 2013 MethodOptimal confidential – © MethodOptimal
  9. 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). 9 Methodology Framework - May 2013 MethodOptimal confidential – © MethodOptimal
  10. 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, 10 Methodology Framework - May 2013 MethodOptimal confidential – © MethodOptimal
  11. 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 11 Methodology Framework - May 2013 MethodOptimal confidential – © MethodOptimal
  12. 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. 12 Methodology Framework - May 2013 MethodOptimal confidential – © MethodOptimal
  13. 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 13 Methodology Framework - May 2013 MethodOptimal confidential – © MethodOptimal
  14. 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 14 Methodology Framework - May 2013 MethodOptimal confidential – © MethodOptimal
  15. 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. 15 Methodology Framework - May 2013 MethodOptimal confidential – © MethodOptimal
  16. 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) 16 Methodology Framework - May 2013 MethodOptimal confidential – © MethodOptimal
  17. 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 17 Methodology Framework - May 2013 MethodOptimal confidential – © MethodOptimal
  18. 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. 18 Methodology Framework - May 2013 MethodOptimal confidential – © MethodOptimal
  19. 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. 19 Methodology Framework - May 2013 MethodOptimal confidential – © MethodOptimal
  20. 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. 20 Methodology Framework - May 2013 MethodOptimal confidential – © MethodOptimal
  21. 21. Contact

×