NOTE

Depending on the complexities of the project, the duration of the ARRP can be anywhere from a few hours to a few days.

The output from this session is a documented list of risks in the Combined Findings Document, their associated consequences if not managed, any plans of mitigation, and any proposed containment strategies. These outputs then feed directly into the next AP event, the Risk Validation Meeting (RVM).

Risk Validation Meeting

The output of this meeting, which typically lasts a day, is documented in the Combined Findings Document. It is used as a basis to develop the initial project plan.

Accelerated Project Planning

Their objective is to identify the project requirements with their associated technical metrics for realization, and begin to formularize the following:

1. Project Structure?Project tasks and their estimated start and end dates, and any milestones.

2. The Software Development Process?A methodology, which should embrace the following activities:

3. Implementation of best practices or standards for consistent development

4. Architecture modeling

5. Object and code reuse

6. Code inspections

7. Software change management

8. Production support

9. The project management approach.

10. Augmentation to the project using consultants.

11. Any training that will need to be conducted to educate the project staff.

By determining the estimated project tasks, and associated start and end dates, an overall project duration can be developed.

The outputs from this event are as follows:

1. A Feature Set Document (FSD), where system requirements are defined into categories in terms of their respective release schedules.

2. A Project Strategy, which describes how the project should be conducted and what software development methodology would be best suited to deliver a rapid time-to-market solution.

3. A Project Plan to develop the solution, which includes the project phases, schedules, resource requirements, and other associated costs.

The two factors that will greatly influence the success of the APP event fall on how well the project plans and strategies have adapted themselves for component-based development. It is imperative that the touchpoints described in the following sections exist quite prominently in the project plan and strategy.

Refactoring the Project Plan into Binary Deliverables The project plan should be refactored into smaller incremental and iterative phases with milestones or binary deliverables.

TIP

Since it can be quite difficult to measure the progress of a project continuously, you must measure it using the concept of milestones.

A binary deliverable is an executable deliverable that has one of two states?done or not done. Since Analysis and Design can never be shown to be complete, they should not be considered binary deliverables. Ideally, a binary deliverable should be some software code which demonstrates a requirement the end-user (Customer) can relate to. For a J2EE system, this will include the presentation, server-side, and even data tiers of the system.

Every organization is different, so it is up to the project manager to define the duration between milestones that is acceptable to the end-users, without giving the impression too much time has passed without anything to show for it.

NOTE

Perception plays a key factor in software development efforts. As long as milestones are being met and showcased, the project appears to be moving in the right direction regardless of the challenges and risks that it may be hiding.

Iterative and Incremental Software Development Practices These two philosophies will stand the test of time in the development of component-based systems. First, you must acknowledge that you will not always get things right the first time around in developing software. Therefore, you will have to return to certain activities, but knowing more than you did initially enables you to be closer to getting it right. This is the concept of iterative development, which recognizes a single return to an activity is unlikely to result in complete success. As a result, each activity is repeated many times to refine the deliverables.

NOTE

Iterative development will span across the Requirements, Analysis, Design, Development, and Testing phases of the SDLC.

A software development process should never attempt to build an entire system in one monolithic effort. It should be partitioned into binary deliverables, each with its own independent, parallel streamlined effort?individual sub-project plan. The process involves each binary deliverable being developed, unit tested independently, and then integrated into the full system. This concept is known as incremental development.

Iterative and incremental software development practices should not blind the project members to the overall software development objective. This is quite common, as people are so consumed in what they need to deliver that they forget about the rest of the world. Hence, it is important to keep people connected in how the project is progressing as a group, not only so they understand there are other aspects of the project, but also to promote knowledge transfer from anything learned, positive or negative.

Continuous Project Control Through Feedback In order to control a software development effort, you need a natural feedback communication mechanism. The term natural is used because if it is not natural, there will be resistance in providing feedback over time.

The project manager is the person solely responsible for managing the project, and will consistently need to measure its progress; identify new risks and provide counter measures; compare that progress against the plan; and then fine-tune the development parameters to correct any deviations from the plan.

There is no given rule to what the feedback communication must be; for example, meetings, presentations, or artifacts such as status reports are normal means to provide feedback. The bottom line is that it must be acceptable to the people that will provide it; otherwise it will not work.

NOTE

Most methodologies provide a choice of feedback mechanisms.

Realistic Deadlines on Milestones Unrealistic deadlines can cause unnecessary stress to everyone involved in the project, especially the development staff that has to produce a tangible product to show the user at the end of each milestone. This inevitably renders poor quality in the work and morale of the software development effort.

To prevent such environments, it is important to assess the iterative cycles of development, and reflect the true measures of effort for the delivery of each milestone into the project plan. In addition, during times of stress, it is important to keep people focused and involved in their domains of expertise, thus gaining the maximum return on their time. For example, developers should not be gathering requirements in times of stress; that should be the role of the business analysts.

TIP

In order to foster a good working environment for the people involved in a project, deadlines and milestones must be realistic and achievable, and not strain the cultural bounds that people are prepared to sacrifice toward a project. When milestones are aggressive, clear communication surrounding the justification for the schedule and some form of reward system on meeting the milestone work well. In an increasingly health conscious work environment, serving food, such as donuts and pizza, is losing its appeal!

The outputs of the APP become the inputs to the next AP event, the Project Commitment Meeting (PCM).

Project Commitment Meeting

CAUTION

This meeting has to be couched entirely in the vocabulary of the business. Even though a decision to move forward with a project may be implied, the plan has to be clear and concise, and address a balanced perspective of the value proposition as well as the risks to ensure acceptance.

During this meeting, the Customers will provide challenges by asking qualifying questions of the Supplier team, in order to make a decision on whether the project will be given the "Green Light" to proceed. Once agreed, the Project Plan, Feature Set Document, and the Project Strategy are all leveraged into the actual software development effort, thus providing a high confidence level for success to the overall project.

NOTE

For more specific details of the Accelerated Process, please contact BEA Systems or visit their Web site (http://www.bea.com).

BEA Systems SteelThread (Architectural Prototyping)

One of the key architectural risks you will encounter in today's J2EE system development efforts is the question of integration with other systems.

If your integration is going to occur inside WebLogic Server, it is going to be Java-based, and more than likely it will be successful, given that it is on the same platform and all you will need to do is tap into the appropriate interface with the right information and do some through testing. Tuning BEA WebLogic Server will take care of the performance and scalability issues.

However, if you are developing a distributed architecture which will include legacy, database, and vendor-based solutions outside the realm of WebLogic Server, the immediate question is the feasibility, scalability, and performance of the distributed architecture. It is imperative you validate all distributed architectures up front before any concentrated development efforts occur.

A BEA Systems SteelThread, rendered as a service through their Professional Services Group, is a prototyping methodology that embraces the concept of quickly developing an end-to-end "thread" of technical and procedural functionality the distributed architecture will need to support.

SteelThread promotes the idea of developing a single end-to-end "thread" or functionality the distributed architecture will need to support.

Ideally a SteelThread should be a single requirement that spans the complexities of your distributed architecture. Metaphorically, a requirement should be an inch wide and be proofed a mile deep.

In the SteelThread prototyping approach the thread should be a single requirement that spans your entire distributed architecture.

For example, a thread may include the presentation layer (JSP, HTML), server-side Java (Servlets, Beans, EJBs), and span all the way to the legacy and data layers.

An important aspect of the SteelThread prototype is that it is built with a mindset that it will serve first as a system design framework, and second as a foundation for future development. A SteelThread is not a throw-away, as the prototype term can sometimes imply. If the SteelThread is not successful in its objectives, it will at least serve as an excellent early proofing method for the design of a system. At the same time, another approach for the distributed architecture will need to be devised and executed using the SteelThread method.

The benefits of using a SteelThread are