Example Work Breakdown Structure
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:
- Technical design: This is a detailed design document providing any information that the programmer will need that is not already in the requirements.
- Server setup: This requires the following aspects:
- You need both a development and test environment with a WebLogic application server and a database.
- You need a source control repository (Subversion, Git, and so on) if you don't already have one.
- You need an issue tracking tool (for example, Jira) if you don't already have one.
- You need a development Wiki if you don't already have one.
- Development workstation setup: This involves getting each development workstation set up with JDeveloper and a local database + connection for source control and issue tracking.
- Development standards: These cover the following aspects:
- Everything a new developer needs to know to work on your project—they include how to structure workspaces and projects, how to work with the database, how you intend to do version control, build management, configuration management, and issue management. They also include naming conventions, security strategy, test strategy, UI guidelines, and HOWTOs for any common development tasks (for example, how to display an error, how to create an ADF Library, and how to write localizable strings).
- Place this information in the development Wiki—development standards written in a word processor tend to languish unread on a network drive somewhere.
- Prototyping: This means creating standard ways of handling common functionalities to be documented in the HOWTO sections on the development Wiki, possibly multiple work packages for prototyping different things.
- Framework extension classes: These are your own base classes that all your ADF Business Components should be based on. If you decide on the enterprise architecture and this project is the first in the organization, remember that you will be building both enterprise framework extension classes and project-specific ones.
- Data model: If you don't already have a data model, you need to create tables and other database objects.
- Entity objects for all tables: If you are working directly with relational tables, this should be a small task. Include any special data access coding if you are not working directly with relational tables.
- View objects for common queries (for value lists): These are used for including a common application module.
- Graphical design: If you are designing a public-facing application, you might have very strict graphical-design guidelines. This is likely to take less effort for internal applications. Output from the graphical design should be example HTML pages.
- Skinning and templates: These help in creating page templates and a "skin" for your application, thus defining its visual identity.
- Usability testing: A developer can't guess what a user finds easy. Usability testing is a specialty of its own and requires trained professionals.
- One work package per subsystem, subdivided into the following steps:
- Task flows (typically one for each use case)
- Data model for each screen (view objects and view links)
- Screens (JSF page fragments)
- Test cases
- Technical documentation
Tip
How much testing?
How you plan to test your use cases will make a big difference to your estimates. An explorative test where the developer plays around with the screen following a short checklist doesn't take much time, but recording a replayable user interface test does. Decide on this before you estimate. We'll return to testing in a later chapter.
- Business logic package: This can be anything from one small work package to a collection of large ones, depending on your requirements.
- Integration package: This is typically one work package per interface (web service, file load, and so on) depending on your integration needs.
- Master application: This work package will collect all of the bounded task flows from the subsystems into the final application.
- Automated build procedure: This is used to set up Ant, Maven, or a similar tool to automatically build your completed application directly from the source in your version control repository. It might possibly include setting up a continuous integration server.
- System integration testing: This tests the whole application—testing individual components should happen in the use case work packages. Reserve at least 10 percent of your total development time for integration testing.
- Coordination and project management: For example, 5 percent of the total development effort is spent in coordination time—remember that a two-hour project meeting is already 5 percent of a workweek. For project management, use, for example, 20 percent of the total development effort (but typically not more than one full-time resource).