Project Development Lifecycle for OBIEE

Considering the RUP there are four life cycle phases of a project- inception, elaboration, construction, and transition. As an OBIEE developer you will be mostly working during the designing, developing, testing, and implementing phase. Sometimes there is involvement in requirements gathering phase but more chances are to work in the refining the requirements.

You can define the OBIEE project Life cycle as below:

The initiation/inception phase: Creating business case, Project planning and feasibility study.

The elaboration/planning phase: Resource Planning, Requirements gathering and analysis

The execution/development phase: Design and development. This is where as an OBIEE developer I worked the most.

The transition/closure phase: Deployment, operations and maintenance.

The normal Software Development Lifecycle is also very similar to this.

These are the default Steps in SDLC:

•System Study

•System Design

•Software Development

•System Implementation

System Design:

•Known as the “How” phase, the system design determines how to implement the system study solutions. This involves:

Output requirements:

Determine the output media, such as, hard or soft output.

Input requirements:

The output is determined first since it dictates the input requirements.

Determine the input source, such as, databases, data entry by keyboard, mouse or screens (monitors), data screening, voice, data communications, etc.

Storage requirements:

Define the databases.

Records and Fields

System controls and backup:

Determine “The what can go wrong scenarios”.

Unauthorized access, determine security measures for software & hardware.

Lost or corrupted databases (bank vaults of information), determine on-site backup.

Disasters, determine off-site database storage, computer processing and communication network back-ups (AT&T, MCI & Sprint).

•Develop system specifications for the programmers.

Software Development:

•Build software programs according to design sepcifications.

Make or by decision.

Write the programs in-house or purchase software packages.

Purchase Considerations:

Customization: Programs you write will meet or exceed design specifications. Software packages on-the-other-hand must be customized to meet your specifications.

Extensive customization should be avoided for two reasons. First, it is costly and time consuming. Second, implementing software package revisions, requires that customization changes be reapplied which in some cases does not retrofit easily.

Re-Engineering: An alternative to customization in that the company changes it’s procedures to comply with the software package specifications.

Note: The SDLC must be completed regardless of the write or buy decision.

System Implementation:

•Test the system.

Alpha testing until the system stabilizes.

Beta testing by the system users.

“What if” testing by the system analyst.

•Populate the databases.

•Develop user procedures.

•Train the users.

•Some approaches for turning-on the system:

Direct: Turn-off the old system and start-up the new system.

Parallel: Run the old & new system side by side until the new system has proven to be reliable. Should be avoided when there is not enough users to keep both systems running.

Phased: Parts of the new system are phased in separately.

Pilot: The system is used by a limited number of users like a department, or a district, or a region, etc.