Predictive methodologies, also known as heavyweights due to the sheer overhead that comes with using them, such as the Rational Unified Process (RUP), are full lifecycle methodologies which posses the following attributes:

1. They are tools-based, which means that a modeling tool is required to support the adoption of the methodology. As in the case of RUP, you can use either TogetherSoft's Control Center 5.5 product or Rational Rose 2001.

2. The methodologies are extremely well documented for the phases of a software development lifecycle.

3. They are either process- or architecture-driven.

4. The methodologies are template-driven, which means that document templates guide the use of the methodology. All you have to do is execute according to the guidelines, and fill in the blanks of the template. Hence, the project will produce a large set of documentation, all of which will need to be read, signed off, and managed.

TIP

Rational Rose 2001 has a plug-in template for developing BEA WebLogic applications. You can download it from Rational's Web site?http://www.rational.com. However, since it is a Rational product, it ultimately implies that you will use the Rational Unified Process.

1. They encourage knowledge collaboration within the project team, using a common vocabulary.

2. They are flexible and modular in nature, suiting small- to large-scale projects.

3. They are developed and supported by software houses.

4. The software development methodology will need to be purchased at a cost.

Agile methodologies, such as BEA Systems Accelerated Process and SteelThread, eXtreme Programming, SCRUM, Feature Driven Development (FDD), and Dynamic System Development Method (DSDM), possess the following attributes:

1. They are not bound to one specific modeling tool.

2. The project staff is not required to fill out specific templates.

3. Depending on the methodology, the software development guidelines can be documented anywhere from a very general to a detailed manner.

NOTE

Books dedicated to Agile methodologies are becoming more prevalent, such as Agile Software Development and Surviving Object-Oriented Projects (The Agile Series for Software Developers) by Alistair Cockburn and Agile Software Development Ecosystems by Jim Highsmith.

1. The methodologies promote Rapid Application Development (RAD) philosophies, focusing on a quick time-to-market approach for the solution.

2. They are supported by formal consortiums or public communities of practice, which provide revisions to the methodology for public appraisal.

3. The Agile software development methodologies are either typically free to use, or the supporting documentation may be purchased for a small nominal fee, as in the case of DSDM.

The following sections will outline the more popular methodologies that you may want to initially consider in your selection process. Since a detailed analysis of each methodology would be beyond the scope of this book, it is recommended that you first develop an overview of the methodologies discussed and if need be, investigate them further through the resource links provided at the end of each methodology section.

Since this book is focused on BEA Technologies, the BEA Systems methodologies will be discussed in some detail.

BEA Systems Accelerated Process (Project Initiation Phase)

The Project Initiation or Feasibility phase of a project validates the value proposition of developing a technical solution for a problem domain, and creates the environment for the project to be successful. The bottom line for this phase is to decide on whether the project is a "Go" or "No Go." If it is a Go, then you must consider what are the initial project plan, resource requirements, software development methodology, and the technology that will be applied toward the solution.

CAUTION

It is important to have an open mind when trying to derive a solution to a business domain. Not all problem domains require technical solutions. Forcing technology upon a solution as the answer may not only be costly proposition, it may be one that does not get accepted organizationally by its end-users.

There are two main problems in developing software today. First, sometimes this phase is completely omitted, causing the software development lifecycle to begin with the Requirements phase. The problem with this situation is that there is no substantial due diligence that the project delivers value or will be successful. Second, this phase often takes too long and the project goes over budget, suffers from poor morale, and then dies a slow death.

In order to validate the viability of a project and arrive at a point that decisions can be made, there will be some questions that need to be answered. Obviously, each organization will have their own set of questions before a project is initiated, but here is a sample of questions that should be answered:

1. What is the problem domain, in a clear uninterruptible format?for example, does it hold a value proposition for a solution?

2. What are the needs from the business or problem domain?for example, a vision or mission statement?

3. What are the constraints the project will have to operate within?for example the political, technical, and cultural environment?

4. What are the corporate or organizational rules that will apply to the project?for example policies on spending and technology?

5. What is the longevity of the solution, and what solution (operational or technical) will scale to the end?

6. At a high level, what are the technical and operational requirements for the project?for example scalability, availability, and scheduled usage time (24*7)?

In order to move forward with a stable footing on a project, it is extremely important how you execute this phase. Remember, you and your organization must enter a project with a high confidence level that it will be delivered successfully with a minimum number of surprises.

Most OO methodologies will concur that this phase is required; however they fail to explain how it should be conducted, and hence how the deliverables can be achieved. BEA Systems, cognizant of this void in systems development efforts, and in an effort to ensure projects utilize J2EE and their WebLogic application servers, have developed an approach called the "Accelerated Process" (AP), which is provided through their Professional Services Group.

The objective of the Accelerated Process is to execute the project initiation phase in the shortest and most feasible time frame possible, without sacrificing the quality of any of the following deliverables:

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 best suits the project.

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

NOTE

Even though this section briefly describes the Accelerated Process, it is advisable to contact BEA Systems Professional Services Group to get guidance on its full usage and practice.

The Accelerated Process is principally comprised of the following activities:

1. API Event?Accelerated Project Initiation

2. ARM Session?Accelerated Requirements Method

3. ATFA Session?Accelerated Technical Feasibility Assessment

4. CVM Event?Customer Validation Meeting

5. ARRP Session?Accelerated Risk Reduction Planning

6. RVM Event?Risk Validation Meeting

7. APP Session?Accelerated Project Planning

The sessions are highly structured and participatory activities. The events are informal meetings, all of which are conducted by an experienced facilitator, whose responsibility is to guide the sessions and events to ensure the outcome is delivered successfully.

The BEA Systems Accelerated Process is composed of highly structured and participatory events.

The Participators of the Accelerated Process

The participators of this process fall into two categories?Customers and Suppliers. Customers should be empowered people or Subject Matter Experts (SMEs) from cross-sections of your organization that will derive a direct benefit from the J2EE and BEA WebLogic solution.

CAUTION

Customers of the potential system should not include self-appointed proxies, as this can cause skewed or biased views that are not true to the real business domain under examination.

Alternatively, Suppliers are technical personnel or experts whose responsibility is to provide input into the technical decisions that need to be made during this phase, and potentially for all subsequent phases of the SDLC (analysis, design, development, test, documentation, and training). Examples of Suppliers include architects, lead developers, database architects, the project manager, and any external personnel representing the technical vendors for the project, for example BEA Systems, as in the case for BEA WebLogic Server.

Accelerated Project Initiation

The API is the first phase of the Accelerated Process. This is a very short event; typically in the context of a meeting, the executive sponsors, stakeholders, and project managers define the project in terms of its scope and vision. The result of this meeting leads to the development of the framework and a decision where emphasis will be placed in the subsequent sessions and events that comprise the Accelerated Process.

The outputs of the API event include

1. An identification of the project sponsors and other authoritative decision makers.

2. Establishing a vision, the objectives, and scope of the project.

3. Establishing the business and functional success metrics for the project.

4. An initial schedule of the required Accelerated Process events and sessions.

5. A preliminary list of project Customers and Suppliers with names and defined roles.

6. Identification of any related Customer documentation pertinent to the project.

As in all the events and sessions in the Accelerated Process, the outputs lead into the next phase.

Accelerated Requirements Method

The ARM is a very formal facilitator-based and documented session with the Customers of the project. It typically lasts anywhere from a few hours to a maximum of a few days, depending on the complexity of the project. The objective is to gain consensus and alignment at a high level on the business requirements for the project, without any emphasis on the technological feasibility of the solution. The goal here is to concisely, but accurately, state the problem that needs to be solved?the what is and the whys, not the how is. Even though requirements for the system are gathered at a high level from the Customers, this exercise is not a replacement for the Requirements phase. In this phase, the requirements will be gathered in a more formal and due diligent manner across the spectrum of the project's scope.

TIP

Suppliers are encouraged to observe, listen, and learn more about their Customers and their respective needs.

The output of this session is a real-time list of functional requirements, as proposed by the customers, with the following value-added descriptors:

The outputs of the ARM session become the inputs to the next AP event, the ATFA.

Accelerated Technical Feasibility Assessment

The ATFA is very similar to the ARM, except in ATFA the Suppliers are in the spotlight. Again, this is a very formal facilitator-based session with inputs directly from the ARM session. Ideally, the Accelerated Process facilitator will coordinate this session with a technology expert/architect or evangelist from BEA Systems or the J2EE technology world.

TIP

Customers are invited to observe, but the input comes directly from the Supplier team.

The objectives of this session are to solidify the scope of the project through discussing the technical feasibility concerns, technical requirements, overall project approaches, and key technical assumptions which stem from the business requirements that were proposed by Customers in the ARM session. Depending on the complexity of the project, the duration of this session could be anywhere from a couple hours to a few days.

The delivered outputs of the ATFA are consolidated with the API and ARM outputs to form a document formally known as the Combined Findings Document (CFD).

The outputs of the ATFA include the following: