| |
| The IrisLogic Implementation Process is generic enough to be customized to a wide-range of software products and projects, both in size and application domain. Using specific tools and methods, it is based upon the following artifacts: |
 |
Iterative and incremental |
|
Object-oriented |
|
Managed and controlled |
|
Highly automated |
|
| The Implementation Process may be approached from two different, yet integrated approaches: a Management Perspective, which deals with the financial, strategic, commercial, and human aspects or a Technical Perspective, which deals with quality, engineering, and design method aspects. |
|
| Management Perspective |
| From the management perspective (the business and economics point of view), the software lifecycle at IrisLogic is organized along four main stages that indicate the progress of the project. These stages are outlined in the Iris Project Execution Framework in the Introduction to e-Business section: |
 |
Inception- The idea that defines the end-product vision, its business case, and the project scope. |
|
Architect- The planning of the necessary activities, required resources, along with specifying the features and designing the architecture. |
|
Construct- The building of the product and modifying the vision, the architecture, and the plans until the final product is ready for release. |
|
Transact- The transfer of the final product to its user's community, which involves manufacturing, delivering, training, supporting, and maintaining the product until the stakeholders are satisfied. |
|
| |
|
| |
| The 4 stages complete one development cycle and produce a software generation. Unless the life of the product ceases, any existing product can evolve into its next generation by repeating the same stages with a different emphasis on any of the various stages. |
IrisLogic calls this period "evolution" as the process eventually produces new generations. Evolution cycles may be triggered by user-suggested enhancements, changes in the context or underlying technology, or reactions to a competitor.
|
|
| |
| In practice, cycles may sometimes overlap. For example, the inception and architect phase may start during the trailing part of the transact phase of the previous cycle. |
| Technical Perspective |
| From a technical perspective the software development process is seen as a succession of iterations, through which the software develops incrementally. Each iteration is concluded by the release of an executable product, which may be a subset of the complete vision that is useful from an engineering or user perspective. Each release is accompanied by supporting artifacts including plans, release notes, and user documentation. |
|
|
| An iteration consists of the activities of planning, analysis, design, implementation, and testing in various proportions depending on the location of the iteration in the development process. The end of each stage, regardless of perspective, is synchronized with the end of iterations. |
| |
|
| |
| However, both perspectives achieve more than just synchronize on several well-identified milestones. They both contribute to a common set of products and artifacts that evolve over time; some of which are more under the control of the technical side, while others are more under the control of the management side. |
| |
| The 4 Stages of the IrisLogic Implementation Process |
| 1. Inception |
| This stage reveals a vision for a potential product and transforms it into an actual project. The purpose is to provide the scope and establish the business case for a new product or a major update to an existing product. |
| For the development of a new product, the main outcome of this stage is a "go" or "no go" decision to safely move into the next stage and invest the necessary time and capital to further analyze in detail the feasibility of proceeding to the construction stage. |
| For the evolution of an existing product, this may be decided quickly, based on users' or customers' requests, on problem reports, or on technological innovations. |
| In the event of a contractual development, the decision to proceed is based upon market experience and on the competitiveness of the development organization. In this case the inception stage may be concluded by a decision to bid or by the bid itself. |
| Entry criteria: |
| The expression of a need, which can take any of the following forms: |
|
An original vision |
|
A legacy system |
|
An RFP (request for proposal) |
|
The previous generation and a list of enhancements |
|
Some assets (software, know-how, financial assets) |
|
A conceptual prototype, or a mock-up |
|
| Exit criteria: |
| An initial business case containing at least: |
|
A clear formulation of the product vision--the core requirements-- in terms of functionality, scope, performance, capacity, technology base |
|
Success criteria (for instance revenue projection) |
|
An initial risk assessment |
|
An estimate of the resources required to complete the elaboration phase |
|
| The end of the inception stage may also include: |
|
An initial domain analysis model (~10%-20% complete), identifying the top key use cases, and sufficient to drive the architecture effort |
|
An under-developed architectural prototype |
|
| 2. Architect |
| The goal of this stage is to more thoroughly analyze the problem domain by defining and stabilizing the architecture, and addressing the highest risk elements of the project. The architecture stage will generate: |
|
A baseline product vision based on an analysis model |
|
Evaluation criteria for at least the first construction iteration |
|
A baseline software architecture |
|
The resources necessary to develop and deploy the product |
|
A schedule |
|
A resolution of the risks sufficient enough to make cost, schedule, and quality estimate of the construction stage |
|
| An executable architectural prototype is built, along with one or several iterations, depending on the scope, size, risk, and novelty of the project. At a minimum, the prototype addresses the top key use cases identified in the previous stage and the top technical risks of the project. Preferably, it is an evolutionary prototype of production quality code that becomes the architectural baseline and does not preclude the development of one or more exploratory, throw-away prototypes to mitigate specific risks. |
| At the end of this stage, there is another "go" or "no go" decision to proceed with construction based on a comprehensive plan produced for the subsequent stages. The plan produced must sufficiently detailed and the risks sufficiently mitigated to be able to accurately determine the cost and schedule for the completion of the development. |
| Entry criteria: |
|
The products and artifacts described in the exit criteria of the first stage |
|
Plan approval by the project management |
|
Allocation of the requisite funding and resources |
|
| Exit criteria: |
| A detailed software development plan that contains: |
|
An updated risk assessment |
|
Management and staffing plans |
|
An iteration plan that details the next iteration |
|
A phase plan that shows the number and contents of the iteration |
|
The development environment and other tools required |
|
A test plan and baseline vision in the form of a set of evaluation criteria for the final product
Objective and measurable evaluation criteria for assessing the results of the initial iteration for the next stage |
|
A domain analysis model (80% complete) sufficient to determine that the corresponding architecture is complete |
|
A software architecture description that outlines constraints and limitations |
|
An executable architecture baseline |
|
| 3. Construct |
| The construction stage is broken down into several iterations. At each iteration, the various artifacts prepared earlier are expanded and revised until they ultimately stabilize. New artifacts are produced during this stage besides the software itself to support the next stage, such as documentation, test beds & test suites, and deployment collateral. |
| By evolving the architecture baseline in incremental steps, the final product is produced. For each iteration there are the products and artifacts from the previous iteration that address specific goals. |
| Entry criteria: |
|
The development of additional capabilities using cases or scenarios |
|
The mitigation of risks during the iteration |
|
The repair of defects during the iteration |
|
| Exit criteria: |
|
Updated products and artifacts |
|
A release description document detailing the results of an iteration |
|
Product test cases |
|
An iteration plan for each iteration |
|
Objective evaluation criteria for the subsequent iteration |
|
| After the final iteration, at the end of the construction stage, a deployment plan is required that specifies (as necessary): |
|
Packaging |
|
Pricing |
|
Roll out |
|
Support |
|
Training |
|
Transition strategy (e.g., an or upgrade plan from an existing system) |
|
Production (e.g., making floppies and manuals) |
|
User documentation |
|
| 4. Transact |
| The transition stage places the product in the hands of the end users. Issues involved include marketing, packaging, installing, configuring, supporting the user-community, and making adjustments. Iterations continue with one or more deliveries of the following: general use releases, beta releases, enhancement releases, or bug fixes. |
| The stage is completed when the stakeholders are satisfied with the product, its formal acceptance, or when all activities on this product are terminated. In some cases, accumulated assets can be re-used for the next cycle or for other projects.
|
| Entry criteria: |
| The product and artifacts of the previous iteration, and in particular, a completed software product for the end users |
| Exit criteria: |
|
An update of some of the previous documents, as necessary, and the plan being replaced by a retroactive analysis of the performance of the project relative to its original and revised success criteria |
|
A brief inventory of the organization's new asset as a result of this cycle |
|
| Evolution Cycles |
| For substantial product evolution, the entire process is applied recursively, re-starting at the inception stage for a new cycle. Since a product has already been constructed, the inception stage will likely be considerably reduced. The architecture stage also may also be more limited and focused primarily on the planning aspects, rather than evolving the analysis or the architecture. |
Minor evolutions occur extending the transaction stage by adding one or more iterations. Alternatively, this stage may be concluded by a termination process (i.e. the product no longer evolves, but specific actions are taken in order to end or retire it).
|
| Activities in the IrisLogic Implementation Process |
The names of the stages in the IrisLogic Implementation Process purposely avoid terms that describe an intellectual activity, such as analyze, design, or assess, in order to prevent forming the belief that any single term is strictly confined to a particular stage. In addition, IrisLogic avoids using terms employed by other authors, standards, and domain-specific jargon. However, these activities do indeed occur, but in varying degree in each stage and iteration. The following figure illustrates how the emphasis and effort changes focus and evolves over time.
|
| |
|
| |
| The figure also shows that the beginning of an activity is not bound by the completion of another. For example, design does not start when analysis ends, but the various artifacts associated with the activities are revised as the problem or the requirements are better understood. Finally, in an iterative process, the activities of planning, integration, and testing are spread incrementally throughout the cycle, within each iteration. These activities are not simply lumped together at the beginning and at the end, nor do they appear as separate steps or stages in the process. |
Although the figures in the table below will vary considerably depending on the project discriminants, a typical initial development cycle for an average project should expect the following ratios for the activities listed:
|
| |
|
|
|
|
| Planning and Management |
15% |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Implementation/Functional tests |
30% |
|
|
|
|
|
|
| Measurement/assessment/acceptance test |
15% |
|
|
|
|
|
|
| Tools/Environment/Change Management |
|
|
|
|
10% |
|
|
|
|
|
|
| Maintenance(Fixes during development |
5% |
|
|
|
|
|
|
| |
| Conclusion |
| The IrisLogic Implementation Process addresses high risk areas early in the project by developing an initial version of the system that helps define its architecture. It does not assume a fixed set of firm requirements at the inception of the project, but allows to refine the requirements as the project evolves. The process expects and accommodates changes and lends itself to the automation of many of the tedious tasks associated with software development. |
| IrisLogic's primary focus is constructing a quality software product. Its success is measured by the degree in which the product satisfies all stakeholders and meets its established objectives.
|
| |
|
