Process Engineering for Internet Solutions	2.0/5.0 (1 votes total) Rate: Select 1 - Terrible 2 - Poor 3 - Average 4 - Good 5 - Outstanding
Arbia Siddique April 05, 2007

Introduction
Conventional process models fail to scale up to rapidly changing, time-to-market requirements of internet product development. The ability to deliver good quality products in short time frames mandates a deviation from the conventional model.

Reasons for process change
Existing technologies are continuously being enhanced and newer technologies are being developed to tap into the vast potential that the Internet provides. Products have to adapt to these changes to provide better quality of service.
Shrinking time-to-market where business success and market leadership is governed by the ability to deliver quality products quickly
A changing market where product requirements evolve as new models get introduced by competition, the need to adapt these models and respond to market feedback, competition and/or diversification

Impact
Internet-based product development needs a process model, tailored to support development of quality products at Internet clock speed, while contributing to the Organizational software process improvement. It is quite possible that a demonstration release and a product release may have different features. This necessitates rapid development and ability to manage quick and frequent releases of the product.

The Approach
In these projects, the following approach is of great help:
An understanding of the overall business context by the software development teams so that detailed product specifications and tradeoffs with respect to product features can be easily made. Also, an understanding of the underlying business strategy (including marketing strategy, revenue strategy, development strategy, deployment strategy, etc.) helps in better orienting the team and in prioritizing the right set of features for a particular release

Tight monitoring and control of projects with easy-to-use tracking tools that make tracking the project closely more manageable.

Process Features

All team members initially go through a "business-product-orientation" phase, during which the product development teams are oriented towards the overall business strategy. This helps the teams to contribute to the product specifications and their evolution (based on market understanding). It also familiarizes the team with the business constraints and allows team members to adapt to, and possibly, even predict changes in specifications due to changing market or technology.

The lifecycle tends to follow an "incremental" development model. Apart from the usual waterfall model, a variant is also used, and is designed to address frequent changes to product specifications. This model ensures incremental progress, lessens the impact of change and allows tracking of diverse activities.

A spectrum of review and testing activities is defined rather than a single review or testing procedure. The process enables an optimal selection of quality assurance activity that is suitable for given time-to-deliver quality goals.

At the end of significant milestones, project teams go through a lessons-learning phase, which ensures that the entire team is oriented towards the product vision. This process also ensures that innovative ideas and lessons learnt are uniformly disseminated across the team.

Development Model
In Internet-based development, customers wish to test their ideas early by piloting an early version of the product versions with few features, demonstration capabilities, etc. However, since new markets are being targeted, there may be changes to requirements or customer priorities during development of a particular version of the product. In several cases, the delivery schedule tends to be fixed. For instance, functioning software is absolutely desired for a trade show, or by some other immovable date. Here a "staged delivery" approach is followed where it is critical to prioritize all features and plan the stages so that the early stages contain the highest priority features.

This approach works well especially when the market uncertainties and technology changes mandate modifications to requirements and feature priorities. Whenever such changes occur, these priorities are revisited, and any possible changes to the plan are reviewed, keeping in mind the schedule. Also, for each stage, the emphasis on the visible aspects of the product as well as the product core is specified. For instance, a demonstration version of the product may require the visible aspects to be absolutely completed, most important features demonstrable but not necessarily implemented fully, whereas a version that is piloted may require the visible aspects and the core functionality completed for a subset of prioritized features. The primary advantage of this approach is that signs of progress are visible earlier in the project, which helps in managing the schedule pressure

In this model, at the end of first increment the user may be offered some basic features and subsequent increments may improve or expand the first one providing additional features with a much high sophistication and so on. In Internet based development, this cycle also called as iterative or evolutionary development is treated as an excuse for uncontrolled development, due to the very nature of such applications. The main essence of evolutionary development is the development stage that is done as a series of increments and can be defined as a full lifecycle of analysis, design, coding, testing, and integration. The reason why it is considered very much suitable in Internet based product development is that the customer gets a base product quickly. Also there is reduced risk by defining and developing a small part of the system at a time which allows usability of the software much earlier than either the waterfall or v-shaped model.

Process Engineering
The aspects of processes suited for developing products in the Internet realm are detailed below.

Product orientation & specification phase
Product Orientation and Specification is introduced at the initial project phases, where the development team works with the customer to understand the business strategy as well as the high-level specifications and scope of the product. The project manager and technical leads are also expected to understand the expected variations and uncertainties of the market, so that planning accounts for the uncertainties and, at a later stage, it becomes easy to make the tradeoffs in prioritizing product features. In this stage, the customer could provide inputs by sharing the business strategy in the form of documents, presentations, slides, discussions, etc. The development team’s involvement in refining product specifications (with review sessions) is important. In certain cases, brainstorming sessions are scheduled for the product teams to come up with a list of miniature features required for the product.

Requirements management phase
Requirements Management is the process of collecting requirements from various sources, recording them in some form, dissemination to product teams, tracking the design/code against them and managing changes to them for the rest of the project. In an environment where product scope is not definite and requirements change at various levels, it becomes quite difficult to manage requirements.
For Internet-based products, requirements have to be broken down and captured at various levels. In this process, requirements are captured at three levels. Initially, customer requirements are captured in some form, which includes priorities assigned to them by the marketing/business teams. Once this is reviewed and possibly refined by the product team, the requirements are mapped to use cases or features for each product. The detailed requirements for the products are specified in a Product Requirements Specification (e.g. in the form use cases, feature specifications, etc.). The customer requirement specification and a detailed understanding of the product are used as an input to the PRS. A "Feature List" is then derived from the PRS, which includes a list of high-level (and possibly low-level) features that are categorized on a per-release basis with priorities assigned. Requirement keys can be derived and utilized in mapping features (and micro-features) to detailed specifications in the feature lists.
Changes to requirements come in the form of revised task priorities or new functionality/feature requests. The new requests (with customer priorities) are updated in the customer requirement specification, and cascaded down to the feature list. The feature list revision automatically triggers a change to the plan. The PRS correspondingly documents details on the particular requirement. The feature list provides a mechanism to easily manage and track changes to requirements. A record of the changed priorities is also available, if necessary. From a requirements management viewpoint, it is important to meaningfully specify as minimal information for a feature/function as possible to avoid huge documentation that may reduce efficacy, waste effort and render certain specifications invalid as the requirements changes. At the end of the specification, requirements scrubbing effort might be undertaken to revisit the specification and remove any unwanted or unrealistic specifications.

Project planning & tracking phase
One of the philosophies underlying this process is the ability to make good tradeoff decisions at different phases of product development (planning, quality assurance, etc.). An incremental development approach works well only with careful planning at the management and technical levels. At the management level, each stage should be planned according to customer expectations of the product. At the technical level, all technical dependencies should be resolved, and the subset of features chosen for implementation appropriately scoped and estimated.
In any product development, three factors govern the management of the project: cost, schedule and product (which include product features, quality, usability, maintainability, modifiability, defect-rate, etc.). In general, the customer has to make the decision as to which of the above factors are fixed or variable, a minimum requirement being that at least one corner should be variable. With Internet-based product development, typically schedules tend to be fixed. Cost and product attributes can be altered. In projects involving new technologies and markets, the product factor tends to get varied.

From a planning perspective, the process goes through feature prioritization, estimation (work-breakdown-structure method has been commonly used) and other phases of planning such as resource planning, configuration management, quality plans, test plans, etc. At the end of the planning phase, an easy-to-use tracking tool is arrived at. This document captures various tasks and deliverables, their priorities, status and due dates. This helps track the project progress, understand the priorities and status at any given point in time, and allows easy revision of priorities. The rationale here is to minimize the overhead of project documentation and reviews. At all points of change, the feature lists get updated; priorities revisited and plan revised.

Quality assurance phase
Usually software product quality tends to be judged by the software’s defect rate. The other quality attributes of a product include usability, efficiency, robustness, performance, scalability, and completeness. In most cases, when tradeoffs are necessary, the defect-rate aspect of quality is not compromised on since low defect rates and short development times go together. The other quality attributes, however, tend to lengthen development schedules and hence are vulnerable to tradeoffs. In an Internet-based development environment, a product released for a demonstration, for instance, will not be functionally complete, robust, scalable or efficient. However, its usability is expected to be very high. Hence, quality measures are chosen considering the end goals that a particular release will have to achieve.

To meet fixed schedules, at times, review of all work-products is not possible. However, knowing this prior to project start helps in assigning good quality resources, prioritizing the set of work-products that get reviewed and selecting the kind of reviews per work-product. Importantly, the measurement of output in these cases is made against customer expectations instead of the process, and the assigned resources are alerted to this fact. This provides a development environment that can be expected to result in fewer defects. To meet different project needs a series of quality procedures and guidelines are specified rather than a high-level framework or a single procedure. An appropriate procedure is applied to a particular work request within the project.

Conclusion

The ability to deliver good quality products in short timeframes requires one to deviate from the conventional waterfall model and adapt different process models. Getting tuned to this kind of development may take time for one seeped in conventional development. This paper analyses the required practices to manage work requests