I was asked by a customer to do a gap analysis of their current methodology and determine what is missing.
To determine what's missing, I need a standard to measure against. This means a list of solid generic features any methodology should have / contain. I started a list that includes things like RACI charts, Plug in knowledge bases, Roles with tasks with artifacts with templates and guidance for all. I'm looking for help from the community to help expand the list.
What would you think should be in a good methodology? This would be a product independent list.
I'd be happy to publish the final list here to repay the help in building it. Thanks.
RUP Mentor / Coach / Trainer
This topic has been locked.
5 replies Latest Post - 2011-05-17T14:35:14Z by SystemAdmin
Pinned topic What makes a good methodology?
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2011-05-17T14:35:14Z at 2011-05-17T14:35:14Z by SystemAdmin
SystemAdmin 110000D4XK3545 PostsACCEPTED ANSWER
Re: What makes a good methodology?2008-04-03T06:43:24Z in response to tomweinbergerBefore you begin a gap analysis, you should perform vulnerability and risk assessment to examine:
* The existence of policies, procedures, standards and supporting documentation
* Access control and user provisioning processes and tools
* Change control and configuration management processes
* Asset identification processes
* Vulnerability management processes
* Risk management processes
* Incident handling processes
* Business continuity documentation and readiness
* Software development lifecycle processes
* Perimeter defense strength
* Test the configurations of firewalls, remote access servers, IDS, antivirus, etc.
* Patching processes
* Physical security processes
* Personnel security processes
Once the vulnerability and risk assessment is complete, perform a gap analysis within each sector and include strategic steps regarding how to bring each area "up to corporate standards." A gap analysis compares what is currently there to what is required. The requirements are derived from federal and state laws, government regulations, industry standards and corporate governance requirements. The following are the common steps of a gap analysis:
1. Define a scope as it pertains to each previously listed item
2. Collect all current documentation within the environment (policies, procedures, configuration standards, etc.)
3. Identify all hardware and software assets with the scope that was established in step 2. (This can be done manually or through automated tools.)
4. Interview individuals and document how the processes listed previously are carried out.
5. Compare the current security practices, configurations and processes to the goals identified in step 1.
6. Prioritize the gaps that were identified and create implementation steps to get each area to the right level of compliance.
ceoneill 06000171261 PostACCEPTED ANSWER
Re: What makes a good methodology?2008-04-14T14:09:45Z in response to tomweinbergerHi Tom:
The Software Engineering Institute's Capability Maturity Model Integration (CMMI) is the de facto standard (see attached file) against which all software development methodologies are measured (including RUP). While formal process assessments are normally conducted by SEI-certified lead appraisers, process engineers like us can perform accurate informal gap analyses knowing that they've covered all the bases. This is because CMMI is defined as a set of 22 process areas (listed alphabetically below), which when aggregated, represent every aspect of a software development methodology:
• Causal Analysis and Resolution
• Configuration Management
• Decision Analysis and Resolution
• Integrated Project Management
• Measurement and Analysis
• Organizational Innovation and Deployment
• Organizational Process Definition
• Organizational Process Focus
• Organizational Process Performance
• Organizational Training
• Product Integration
• Project Monitoring and Control
• Project Planning
• Process and Product Quality Assurance
• Quantitative Project Management
• Requirements Development
• Requirements Management
• Risk Management
• Supplier Agreement Management
• Technical Solution
In fact, the fundamental purpose of a CMMI appraisal is to identify the gaps in an organization's process. So if you want a standard against which to measure, CMMI is a great place to start.
RUP/RMC Mentor & Coach
QA1-Skip 110000APC21 PostACCEPTED ANSWER
Re: What makes a good methodology?2011-05-16T16:54:12Z in response to ceoneillCMMI may describe the components of an SDLC, and one might perceive from the inclusion of additional practices through higher levels of maturity that bigger is better.
Don't really buy that.
So let me ask the question a different way and hope for a defined, proven set of criteria?
Instead of what makes a good methodology,
"What makes a 'methodology' good?"
jruehlin 120000GMDQ12 PostsACCEPTED ANSWER
Re: What makes a good methodology?2011-05-16T19:27:25Z in response to QA1-SkipA good methodology is one that increases the odds that you'll delver a product the customer needs, within time and budget constraints. It reduces risk and rework, and increases certainty.
CMMI, IBM Practice Library, EPF, Scrum, XP, etc, are all good tools. I don't think any of them makes a "good methodology" because that's measured by results. These tools shouldn't be used as-is. Groups of different sizes, experience levels, project novelty, organizational constraints, etc, all affect (or should affect) the specific method a team or organization uses to get their jobs done.
So an important part of a good methodology is to base it on the needs of the particular project, based as much as possible on organizational experience, and is regularly reviewed and adapted to the team and environment.
Jim Ruehlin, IBM Rational Software
Jazz Jumpstart Team
SystemAdmin 110000D4XK3545 PostsACCEPTED ANSWER
Re: What makes a good methodology?2011-05-17T14:35:14Z in response to jruehlinI could not agree with Jim more. What is a good method in one context could be bad in another context. Organizional culture (as Jim mentions as constraints and experience) is a big factor in this "context". See Ambler's position paper to SEMAT: Context, Context, Context. http://www.semat.org/bin/view/Main/WorkshopPositions
Check out the image in this article from my colleague Mark Kennaley. Here is a high level view of what SD practices work better in what organizational cultures. http://drdobbs.com/architecture-and-design/229401451?pgno=2