Project Development Life Cycle for OBIEE

Taking into account the RUP, there are four phases of the life cycle of a project: initiation, elaboration, construction and transition. As an OBIEE developer, you will work primarily during the design, development, testing, and deployment phase. Sometimes there is participation in the requirements gathering phase, but there is more scope to work on refining the requirements.

You can define the OBIEE project life cycle as follows:

The initiation/inception phase: creation of a business case, project planning and feasibility study.

The Build/Plan 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 life cycle 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, system design determines how to implement the system study solutions. This involves:

Exit requirements:

Determine the means of egress, such as hard or soft egress.

Entry requirements:

The exit is determined first, as it dictates the entry requirements.

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

Storage requirements:

Define the databases.

Records and Fields

System Controls and Backup:

Determine “The scenarios of what can go wrong.”

Unauthorized access, determine security measures for software and hardware.

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

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

•Develop system specifications for programmers.

Software development:

•Build software programs according to design specifications.

Do or by decision.

Write the programs in-house or buy software packages.

Purchase considerations:

Customization: The 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 expensive and time consuming. Second, deploying software package patches requires reapplying customization changes that, in some cases, are not easily accommodated.

Reengineering: An alternative to customization in which the company changes its procedures to meet the specifications of the software package.

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

System Implementation:

•Test the system.

Alpha test until system stabilizes.

Beta testing by system users.

“What if” testing by the system analyst.

•Populate the databases.

• Develop user procedures.

•Train users.

•Some approaches to power on the system:

Direct: Shut down the old system and start up the new system.

Parallel: Run the old and new systems side by side until the new system proves to be reliable. It should be avoided when there are 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 such as a department, a district, a region, etc.