Project development life cycle for OBIEE
Considering 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 implementation 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 life cycle of the OBIEE project as follows:
The startup / initiation phase: creation of a business case, project planning and feasibility study.
The development / planning phase: resource planning, requirements gathering and analysis
The execution / development phase: Design and development. This is where I worked the most as an OBIEE developer.
The transition / closure phase: implementation, operations and maintenance.
The normal software development life cycle is also very similar to this.
These are the default steps in SDLC:
• Study of the system
• System design
• Software development
• Implementation of the system
System design:
• Known as the “How” phase, the system design determines how to implement the system study solutions. This involves:
Exit requirements:
Determine the output medium, such as printed or soft output.
Entry requirements:
Exit is determined first as it dictates entry requirements.
Determine the input source, such as databases, data entry by keyboard, mouse or screens (monitors), data filtering, voice, data communications, etc.
Storage requirements:
Define the databases.
Records and fields
System controls and backup:
Determine “the scenarios that can go wrong.”
Unauthorized access, determine security measures for software and hardware.
Lost or damaged databases (bank vaults of information), determine the backup on the site.
Disasters, determine off-site database storage, computer processing, and communications network backups (AT&T, MCI, and Sprint).
• Develop system specifications for programmers.
Software development:
• Build software programs according to design specifications.
Make or by decision.
Write programs in-house or purchase software packages.
Purchase Considerations:
Customization – Programs you write will meet or exceed design specifications. On the other hand, software packages need to be customized to meet your specifications.
Extensive customization should be avoided for two reasons. First, it is expensive and time consuming. Second, implementing software package patches requires customization changes to be reapplied, which in some cases is 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 purchase or deed decision.
System implementation:
• Test the system.
Alpha tests until the system stabilizes.
Beta testing by system users.
“What if” tests by the system analyst.
• Fill in the databases.
• Develop procedures for the user.
• Train users.
• Some approaches to powering up the system:
Direct – Shut down the old system and start the new system.
Parallel – Run the old and new systems side by side until the new system has proven 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.