Project Development Lifecycle for OBIEE

Given the RUP, there are four life cycle phases of a project: start, elaboration, construction and transition. As an OBIEE developer you mainly work during the design, development, test and implementation phase. Sometimes there is involvement in requirements collection, but it is more likely to work on refining requirements.

You can define the OBIEE project lifecycle as follows:

The initiation / initial phase: Business case making, Project planning and feasibility study

The elaboration / planning phase: resource planning, requirements collection and analysis

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

The transition / closing phase: implementation, operations and maintenance.

The normal Software Development Lifecycle is also very similar.

These are the standard steps in SDLC:

• System study

• System design

• Software development

• System implementation

System design:

• The system design is known as the “How” phase and determines how to implement the system study solutions. This implies:

Output requirements:

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

Entry Requirements:

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

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

Storage requirements:

Define the databases.

Records and fields

System controls and backup:

Determine “What can go wrong scenarios”.

Unauthorized access, determine security measures for software and hardware.

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

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

• Develop system specifications for the programmers.

Software development:

• Build software programs according to design specifications.

Make or by decision.

Write the programs internally or buy software packages.

Purchase Considerations:

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

Extensive customization should be avoided for two reasons. First, it is expensive and time consuming. Second, implementing software package revisions requires custom adaptations to be reapplied, which in some cases is not easily retrofitted.

Re-Engineering: An alternative to customization because the company changes its procedures to meet the specifications of the software package.

Note: The SDLC must be completed regardless of writing or purchasing decision.

System implementation:

• Test the system.

Alpha testing until the system stabilizes.

Beta testing by system users.

What if testing by the system analyst.

• Fill the databases.

• Develop user procedures.

• Train the users.

• Some approaches to arm the system:

Immediately: Turn off the old system and start the new system.

Parallel: Use the old and new systems side by side until the new system has proven reliable. Should be avoided if there are not enough users to keep both systems running.

Phased: parts of the new system will be phased in separately.

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

Source by Charan Sri