Methodology What It Is And How It Helps

Methodology, a word with multiple meanings, is often used carelessly to make some simple technique or approach sound more impressive than it is. A precise definition of the term is:

A methodology is a generic knowledge base about tasks, techniques, deliverables, roles, tools, and tool use for carrying out some complex class of projects such as system development, plus a mechanism for adapting a generic knowledge base to each specific project.

Methodology Tasks At minimum, a methodology is a description of tasks to be done in developing a system. The scope of a methodology might be wider than just development and cover planning, enhancement, and maintenance. Tasks can include designing the database and coding the programs. Each task typically has one or more recommended steps to be done in sequence.

Methodology Techniques Some methodologies provide a somewhat detailed description of how to do tasks. However, these descriptions usually apply to more than one task. For example, a description of how to do a data flow diagram applies to the task of defining the process model as well as to the task of designing the transaction flow. Especially when a methodology is stored in a knowledge base on disk, it is convenient to separate the technique descriptions from the tasks and to provide a way (e.g., hypertext) to display a technique for a relevant task only when needed.

Deliverables Each task should produce some tangible output, usually called a deliverable or work product. For example, designing a database should produce a deliverable — database design — and the methodology should specify what a database design may contain.

Roles A methodology should also deal with the skills for each task. The most flexible way of doing this is to define roles. On a given project, one person may play several roles, or one role may be played by several people. The methodology should specify the role responsible for each task, and the other roles that may contribute to the task. Thus, for the task of designing the database, the prima ry role might be the DBMS specialist and the contributing role, the modeling specialist. For each role, a methodology should define the skills, experience, and background that are relevant. Exhibit 1 shows an example of a task/deliverable description, with the names of the various roles and techniques associated with it.

Exhibit 1. A Simple Task/Deliverable Entry from the Knowledge Base

Task

Carry out Discovery Prototyping Task-ID A0540

Purpose

If users find it difficult to describe their requirements in terms of data and logic, discovery prototyping can help clarify their needs by getting their feedback on generic prototypes. The technique prototyping gives details of three types:

Task

Carry out Discovery Prototyping Task-ID A0540

Discovery prototyping Behavior prototyping Production prototyping

Discovery prototyping is used as an aid to uncover requirements when users do not relate well to modeling techniques. It may consist of screen mockups, visits to other computerized offices, and product demonstrations. The prime purpose is neither to build a system nor to determine in detail how the system will work; rather it is to determine what, exactly, are the requirements that users have.

Responsible

Development Team Member (Hypertext to Role Descriptions)

Contributors

User Team Members

Need to start

Development Project Manager Decision

Other inputs

Any available data model or data requirements

Steps in task

If the development project manager decides that this task is relevant, then:

An assigned development team member develops generic screen or report layouts and exercises them with selected user team members. Development team members must emphasize that what they are seeing is only a false front with no necessary similarity to the eventual system or interface. See Technique: Prototyping (Hypertext to Technique Description)

The development team member revises the generic layouts based on user feedback and exercises them iteratively with user team members until no more requirements are identified.

The development team member revises the data model on the basis of the discovery prototype findings.

This Task Produces:

Deliverable

Discovery Prototype ID 1.40.05

Contents

Screens, screen-to-screen flow diagrams, or pointers to files where actual discovery prototypes can be found.

Exhibit 2. Methodology Metamodel

The relationships shown between these methodology objects are:

A task must result in only one deliverable. A deliverable must be produced by only one task,

A phase may group together one or more tasks. A task may be grouped in only one phase.

A task may be a predecessor to one or more other tasks. A task may have as predecessor one or more other tasks.

A phase may produce one or more deliverable packages. A deliverable package may be associated with only one phase,

A deliverable package must be made up of one or more deliverables, A deliverable must be part of only one deliverable package.

A tool may be associated with one or more tool usages. A tool usage must be for only one tool,

A tool usage must relate to only one task. A task may have detailed guidance in one or more tool usages.

A task may require background knowledge in one or more techniques. A technique may apply to one or more tasks,

A task may involve one or more roles, A role may be involved in one or more tasks.

Roles are an important way to involve the right businesspeople in the project in the right way. Just as one of the principles of business process reengineering is to consider how the process adds value for its ultimate customer,[3] so the definition of roles that need to be played by various members of the business community helps to ensure that the application adds value to the business.

Task Dependencies If a methodology is to be useful for project planning, it should contain information about which tasks must be completed before other tasks can be started. For example, a methodology can stipulate that the task of designing the database is a predecessor to the task of specifying data security constraints.

Tools and Their Use Increasingly, deliverables are produced with software tools that often run on workstations. A methodology must describe each relevant tool and enable tools to be linked to tasks so that developers know which tools are recommended for which tasks. In many cases, a methodology also lists tips, tricks, and traps that are associated with using a specific tool to do a specific task.

It is convenient to store tool usage descriptions separately from the tool description itself. For example, in addition to a description of a spreadsheet tool, the tool usage of a methodology for the task define the users at various locations might read, "Always list the locations down the /-axis of the spreadsheet and the types of user across the top."

Phases and Deliverable Packages Tasks are usually grouped in phases, primarily for management control purposes. As development projects become more iterative, phases have less and less meaning, because the same tasks are being repeated for each iteration of the prototype or each version of the development application. It is often clearer to focus on packages of deliverables that may be grouped for management or user review. These deliverable packages may have such names as requirements package, discover/ protot/pe package, and outline design package.

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Post a comment