Oracle ADF Enterprise Application Development Made Simple: Second Edition:

The first step is to gather the requirements to build the software. This can be done in many different ways depending on your organizational culture and environment, detailed as follows:

At the formal end of the spectrum, you need a complete list of all of the requirements that you can test against. If your organization is used to a more informal approach, you might only produce a fairly complete list of use cases or user stories. For a technology replacement project, where you replace a legacy application developed in, for example, Oracle Forms, the requirements might be simply, "it should work like the old system."

Once you know what you need to build, you need to decide how you want to build it. There are three major decisions that you need to take. They are as follows:

Once you have found out what you need to build and how much you want to build, you now have to choose your application architecture. The architecture determines how many workspaces you have and which components go into which workspace.

The ADF framework is very flexible and allows you to build applications in many different ways, so there is a large number of possible architectures. Three good ones are:

In a simple architecture, you build the entire application in one workspace. You saw an example of this approach in the Proof of Concept application in Chapter 1, The ADF Proof of Concept. Business components go into a model project in the workspace, and task flows and pages go into a view/controller project. This approach works well for small applications that will be built by one or two developers.

If your application is larger than 5-10 bounded task flows and/or more than two people need to work on it, a modular architecture is a good approach...

When you know the requirements and have a screen design for the most important screens, you can start designing the solution. This does not mean that you need to know every piece of code you're going to write, but you do need to be able to break down the work in manageable chunks.

This is typically done in the form of a hierarchical Work Breakdown Structure (WBS) that decomposes the entire application-development effort into a number of work packages. The following list contains the work packages you will probably need when building an enterprise ADF application. Many of the items listed here haven't been explained yet but will be covered in the subsequent chapters—they will make sense when you return to this chapter after reading the rest of the book.

Your WBS is likely to include:

With your Work Breakdown Structure in hand, you can start estimating the real work involved in each group of tasks. Estimate the effort needed to perform the task in hours or days (measured in ideal engineering hours, assuming concentrated, uninterrupted work on the task). Don't fall into the trap of estimating in duration—duration estimates will vary wildly depending on how much non-project work the person doing the estimate expects to be doing at the same time.

When you have gathered all of the detailed task estimates, you need to add up the details to a total estimate for the entire project.

As a starting point, you add up all of the expected task efforts. Remember that these are calculated based on your three-point estimates using the formula earlier in this chapter. This total is the total effort most likely needed to complete the project.

Once you add up all of your bottom-up estimates, you should arrive at a total close to the project manager's top-down estimate. If the estimates are not fairly close, your project contains some uncertainty that you need to examine.

The project manager might find that the bottom-up estimate is higher because it includes the tasks he or she did not consider in the top-down estimate. That's fine. However, if you have a major discrepancy and cannot find the reason, you need to revisit your estimates. As described earlier, you get better estimates if you let more people do the estimation and then calculate the averages. Do this for both your top-down and bottom-up estimates until the total bottom-up estimate is approximately the same as the top-down estimate.

Remember that we have been discussing effort in this chapter, calculating it in ideal engineering hours. You need to convert this into actual calendar time, taking into account vacation, illness, training, the support of the existing systems, tasks for other projects, company meetings, and many other things.

If you have already implemented detailed time tracking in your organization, you can get a good idea of the development efficiency of each developer from historical data. If you do not have this data, start your project plan assuming 50 percent efficiency for everyone. Then, follow up on how many hours are actually spent on development tasks for each person. This can be very different from person to person because of the varying other tasks each team member will have.

You gathered all of the requirements, decided how you will build the application, and decided on a modular architecture. You then created a Work Breakdown Structure for the XDM project, and together with the other developers in DMC Solutions, you created three-point estimates for each task in your project. Then, you calculated the total effort needed to build DMC Solutions' next-generation destination management.

Your boss was impressed with your detailed estimate and liked the fact that you had calculated a 95 percent probability worst-case value. He has now gone to the CEO for the funding—if he gets the go-ahead, your next task is to get the project team organized. That's the topic of Chapter 3, Getting Organized.