New requirement after start of cycle - ensuring that there is a proper process followed ...

From the outset, let me make clear that I am not talking about a development process which is Agile or Scrum based (in the Scrum based methodology, features are taken up on the basis of a Sprint cycle, which means that features are taken up from cycle to cycle). Let us take the typical case on which a number of teams work, the Waterfall based development methodology. In this methodology, teams follow a sequential process whereby they start out with a requirements process, which is followed by a design process, which in turn is followed by a coding process mixed with a testing process. The process ensures that a phase is only started once the previous phase has been completed. So, if you consider this entire methodology, the requirements phase needs to come to an end before the design phase starts.
The direct implication of this is that once the requirements phase is completed, it is not expected that there will be a change in requirements. This is now considered to be a weakness in those situations where the requirements are in flux, but if you consider the industry where a software organization does projects for clients, the completion of the requirements phase is a critical stage. The clients typically use the entire requirements phase as a milestone which certifies that their business workflows have been captured accurately and increases the confidence level in the clients that the software mapping their business requirements will be designed accurately.
Now, look at software projects, and consider the case where after the completion of the requirements phase, there is a modification in some requirements or a new requirement that has been added. This new requirement could come in because some change in business workflows has happened, or a customer has added some new feature that is critical for success, or any other valid reason. Once such a change needs to happen, there needs to be a process to be followed to ensure that the team does not increase the level of risk beyond what has already been incurring. Typically, with a change in requirements, there is a risk of the schedule slipping, or the quality level suffering. It is better to take a hard look at the impact of such a change rather than do such a change under pressure, and then find that the software team comes under pressure later.
So what needs to be done ? Well, the group should do an impact analysis of the change before going ahead with the change. This is a process by itself that the team needs to do:
- Have a team of requirements folks to do a review of the change and estimate the change to the requirements already in place
- Work out the design changes or new design needed for this change / addition and the effort estimate
- Do the same estimation for the development or testing phase
Once you have these estimation in total, you know the approximate change to the schedule because of this change. Based on this estimation, the team needs to figure out whether there needs to be a reduction in the feature set to accommodate this change, or whether the number of resources deployed in the team need to be increased for taking this change. However, keep in mind that there will be a point in the schedule where such a change cannot be take just by increasing the number of resources; there will be an impact on the schedule.

What are the guidelines to be remembered if In House Web Engineering strategy is chosen for web application development?

Due to the increasing complexity, the web application project becomes like a software engineering project management. It is important to recognize that the guidelines recommended for small and moderately sized WebE projects can be performed quickly. In no case, should WebE planning for projects of this size take more than 5 percent of overall project effort :

- One should understand the scope, the dimensions of change, and project constraints. For an effective WebApp planning, requirements gathering and customer communication are essential precursors.
- An incremental project strategy should be developed so that evolution is not uncontrolled and chaotic.
- Risk analysis should be performed. All risk management tasks are performed for web engineering projects but the approach is abbreviated. Schedule and technology risk is the most important concern for most web engineers.
- The overall project estimate should be developed which focuses on macroscopic rather than microscopic issues.
- A set of web engineering tasks is selected which is appropriate for characteristics of problem, product, project, people on web engineering team.
- A schedule is established in which web engineering tasks are distributed along project timeline for increment to be developed.
- Regardless of project size, it is important to establish project milestones so that progress can be assessed.
- A change management is facilitated by incremental development strategy recommended for web applications. There is a possibility to delay change until next increment which in turn reduces the delay effects that are associated with changes.

What is a software process? What are different types of software process models?

A strategy that a software development team employs in order to build quality software is called software process. A software process is chosen based on:
- nature of the project and application.
- methods and tools to be used.
- management and work products that are required.

A software process consists of:
- Framework activities: People who are involved in the development process perform these activities. They are alsoknown as phases of the software development process.
- Tasks sets: The activities in the process framework defines a set of tasks. These tasks would have milestones, deliverables or work products and software quality assurance (SQA) points.
- Umbrella activities: These are the activities that supports the framework of activities as the software development project progresses such as software project management, change management, requirements management, risk management, formal technical reviews.

Types of Software Process Models
- Linear Sequential Model
- Prototyping Model
- Rapid Application Development (RAD) Model
- Evolutionary Process Models which includes Incremental Model, Spiral Model and
Component-based Assembly Model.
- Concurrent Development Model
- Formal Methods

Factors that Affect the Choice of Process Model
- Type of the Project
- Methods and Tools to be Used
- Requirements of the Stakeholders
- Common Sense and Judgment

Introduction to Grid Computing

Grid Computing can be defined as applying resources from many computers in a network to a single problem, usually one that requires a large number of processing cycles or access to large amounts of data.
- Grid computing is the act of sharing tasks over multiple computers.
- These computers join together to create a virtual supercomputer. Networked computers can work on the same problems, traditionally reserved for supercomputers, and yet this network of computers are more powerful.
- The idea of grid computing originated with Ian Foster, Carl Kesselman and Steve Tuecke.
- Grid computing techniques can be used to create very different types of grids, adding flexibility as well as power by using the resources of multiple machines.
- Grid computing is similar to cluster computing, but there are a number of distinct differences. In a grid, there is no centralized management; computers in the grid are independently controlled, and can perform tasks unrelated to the grid at the operator's discretion.
- The computers in a grid are not required to have the same operating system or hardware.
- At its core, Grid Computing enables devices-regardless of their operating characteristics-to be virtually shared, managed and accessed across an enterprise, industry or workgroup.

Benefits of Grid Computing

When you deploy a grid, it will be to meet a set of business requirements. To
better match grid computing capabilities to those requirements, it is useful to
keep in mind some common motivations for using grid computing.
- Exploiting under utilized resources
One of the basic uses of grid computing is to run an existing application on a
different machine. The machine on which the application is normally run might be
unusually busy due to a peak in activity. The job in question could be run on an
idle machine elsewhere on the grid.
- Parallel CPU capacity
The potential for massive parallel CPU capacity is one of the most common
visions and attractive features of a grid. A CPU-intensive grid application can be thought of as many smaller sub-jobs, each executing on a different machine in the grid.
- Virtual resources and virtual organizations for collaboration
Another capability enabled by grid computing is to provide an environment for
collaboration among a wider audience. Grid computing can take these capabilities to an even wider audience, while offering important standards that enable very heterogeneous systems to work together to form the image of a large virtual computing system offering a variety of resources.
- Access to additional resources
In addition to CPU and storage resources, a grid can provide
access to other resources as well. The additional resources can be provided in
additional numbers and/or capacity.
- Resource balancing
A grid federates a large number of resources contributed by individual machines
into a large single-system image. For applications that are grid-enabled, the grid
can offer a resource balancing effect by scheduling grid jobs on machines with
low utilization.
- Reliability
High-end conventional computing systems use expensive hardware to increase
reliability. They are built using chips with redundant circuits that vote on results,
and contain logic to achieve graceful recovery from an assortment of hardware
failures.
- Management
The goal to virtualize the resources on the grid and more uniformly handle
heterogeneous systems will create new opportunities to better manage a larger,
more distributed IT infrastructure. It will be easier to visualize capacity and
utilization, making it easier for IT departments to control expenditures for
computing resources over a larger organization.

Overview of Change Management - Software configuration management

Software configuration management is an umbrella activity that is applied throughout the software process. SCM identifies, controls, audits, and reports modifications that invariably occur while software is being developed and after it has been released to a customer. All information produced as part of software engineering becomes part of a software configuration. The configuration is organized in a manner that enables orderly management of change.

The software configuration is composed of a set of interrelated objects, also called software configuration items, that are produced as a result of some software engineering activity. In addition to documents, programs, and data, the development environment that is used to create software can also be placed under configuration control. All SCIs are stored within a repository that implements mechanisms and data structures to ensure data integrity, provides integration support for other software tools, supports information sharing among all members of the software team, and implements functions in support of version and change control.

Once a configuration object has been developed and reviewed, it becomes a baseline. Changes to a baselined object result in the creation of a new version of that object. The evolution of a program can be tracked by examining the revision history of all configuration objects. Basic and composite objects form an object pool from which versions are created. Version control is the set of procedures and tools for managing the use of these objects.

Change control is a procedural activity that ensures quality and consistency as changes are made to a configuration object. The change control process begins with a change request, leads to a decision to make or reject the request for change, and culminates with a controlled update of the SCI that is to be changed.

The configuration audit is a SQA activity that helps to ensure that quality is maintained as changes are made. Status reporting provides information about each change to those with a need to know. Configuration management for Web engineering is similar in most respects to SCM for conventional software. However, each of the core SCM tasks should be streamlined to make it as lean as possible, and special provisions for content management must be implemented.