services methodology
When a custom solution is warranted, we cost and deliver this within the structure of a project. Every project is then defined as having a certain scope which we handle in a practical way. Although we all would like a finite, static scope in order to define costs and delivery dates, it really is impossible to predict, at the outset of a project, exactly what is required and exactly how a solution will be delivered. The scope cannot be nailed down precisely this way. Scope is dynamic in a real-world application and a successful methodology must include - not ignore - this fact.

Initially, a static view of scope is necessary in order to estimate and bound the problem in the context of a solution. This anchors us in the beginning of a project by allowing us to define the entire project very broadly with high-level problem and solution statements.

From these statements, we break out high-level requirements (use cases), as these are the things a user (or another system) should receive (or give) to the system. A solution can then be considered, which will be based on many factors such as, the complexity of the problem, the development and production environments, resource availability and skillset, subject matter expertise, equipment, technology, and budget.

An initial set of high-level requirements serve as functional scope and give us an idea of what the system should do. However, because these requirements lack the necessary detail to be mapped directly into a solution, scope cannot be addressed at this point and never be evaluated again. We see the broadening and narrowing of scope as an ongoing, realistic - and necessary - challenge. Indeed, scope change is often necessary to build a system that can actually be used while making complete business sense.

We work to solve the on going "scope creep" problem by producing detailed use cases. These detailed requirements clear up exactly what the system will do. Analysis and design solutions and sometimes technology choices become clear after this step. Estimates can then be made for what the system will do, how long it will take to build and what the cost will be. However, scope remains a constant challenge because of the desires to add more functionality and to perhaps build a better solution. We meet this challenge by dealing with scope practically, through on-going team and management meetings where we broaden or narrow functionality for precise reasons, which are agreed upon and clearly communicated among the team.

Once the lifecycle is underway, we track development progress and costs by relating actual work hours and deliverables back to planned estimates. We have regular team meetings according to the plan, which are managed through our Project Control Methodology. This methodology keeps management and the rest of the team up-to-date. At these meetings we can make course corrections as required and if necessary tune the Project Plan.

All requirements are gathered through interactive sessions with users and/or stakeholders of the project. Requirements are formatted into high-level use cases and then broken down into detailed use cases. If the functionality is still within the initial scope of the project, then we proceed forward to analyzing the requirements. Uses cases deemed outside the scope of the system (or "on the line") are saved for and discussed in a team meeting with the project manager to determine if the scope should be changed.

Our methodology is incremental, object-oriented and component-based. We begin with a framework methodology that can be adapted to fit most project life cycles. In any form, our methodology supports the following software development goals:

reduce development time decrease system defects
increase component and system quality unify management and developers as one team
increase system reliability, maintainability, usability and scalability manage system complexity
manage costs, resources, time, risk and expectations keep stakeholders involved and excited


user: not logged in
ver:
copyright 2000
T3 Software Builders Inc.