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:
•Known as the “How” phase, the system design determines how to implement the system study solutions. This involves:
Determine the output media, such as, hard or soft output.
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.
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.
•Build software programs according to design sepcifications.
Make or by decision.
Write the programs in-house or purchase software packages.
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.
•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.