OLE Development Cycle

 See OLE Spec Writing & Requirements Analysis and related team pages for implementation of below model.

The following and linked document represent the project development cycle as set forth by Tim McGeary, former FC Chair, and previous Project Manager, Brad Skiles. More information and details will be forthcoming on the roles and responsibilities of Core Team and SMEs in the overall process. See also OLE Spec Writing & Requirements Analysis for an overview and training for SMEs in the unique swimlane tasks.

(click to view or download full-size PDF)

Development Process Overview & Assignments

(see most current in linked version above)

last revised: February 3, 2012
Kuali OLE Development Cycle

Introduction

The Kuali OLE development cycle has lacked strong definition to support necessary accountability and efficiency of resources (Partners, Core Team, and HTC).  In order to relieve bottlenecks and create better efficiencies, the Kuali OLE development cycle has been re-organized into three major sections, each with a primary owner:
Functional Design (Partnership)
Technical Design (Core Team)
Coding (HTC Global Services)

The narrative below will guide you through the development cycle diagram.  The goal of separating the development cycle into three phases, each with a different primary owner, is to create processes that co-exist independently, each building up inventories that will be cyclically re-prioritized.

Functional Design - Kuali OLE Partners

Starting Point: Kuali OLE Roadmap

Ending Point: Handoff Functional Specifications
The Kuali OLE Partners are wholly accountable for the Functional Design phase. This phase will begin with the established Roadmap and end with a handoff of functional specifications to the Core Team. During this phase, the SME Teams and Spec Writing Teams will work independent from the Core Team to document functional requirements. If needed, a member(s) of the Core and HTC On-shore teams will be available to consult on documentation.

Scope/Roadmap

The functional design phase starts from the Kuali OLE Roadmap (#1), which is an organic document being revised regularly to meet the requirements, constraints, and dependencies of the project. The Roadmap team will regularly present revisions to the Functional Council and Board for approval.

SME Teams

Each SME Team is made up of a FC Member, TC Member, and Systems Analyst (SA). The SME Team SA is committed to Kuali OLE for 50% FTE or 20 hours per week. Based on the Roadmap, each SME Team will assign and prioritize the appropriate user stories for each release point (#2 and #3) with appropriate deadlines. Based on these priorities, the SME Team will assign user stories to one or more Spec Writing Teams in their functional area (#4). Each SME Team will then review and approve all completed functional specifications (#8). SME Teams will coordinate activities weekly through the Functional Council to ensure overlap and intra-related specifications are addressed.

Spec Writing Teams

The Spec Writing Teams are comprised of the SME Team SA, Lead SMEs that are committed to Kuali OLE for 25% FTE or 10 hours per week, and non-Lead SMEs. Using templates provided by the Core Team (#5), the goal of each Spec Writing Team is to document the following (#6):

• functional requirements of assigned user stories
• pre-conditions
• post-conditions
• acceptance criteria
• detailed lists of data elements

Spec Teams will work independently to document the functional requirements necessary for the Project Team to produce and code a technical solution. By focusing on the functional requirements, Spec Teams can build an inventory of functional specifications from which the Project Team can review and prioritize for efficient production of code. The SME Team SA will represent the Spec Team in the technical specification phase described below. It is expected Spec Teams will be able to complete these specifications with little, if any, assistance from the Project Team, but consultation is available (#7).

SME Team and Project Management

The SME Team approves functional specifications (#8), at which time Project Management adds completed functional specs into inventory (#9). Project Management will add/update the functional specifications in JIRA and assess complexity and prioritization (#10).

Technical Design - Core Team

Starting Point: Receipt of Functional Specification

Ending Point: Handoff Technical Specifications

Core Team / Systems Analyst

The Core Team Business Analysts and SME Team SA will collaborate in translating the functional specifications into technical requirements by designing wire frames (UI design), documenting the appropriate Kuali Rice requirements, and translating functional details into technical details (#11). At this stage the functional specification becomes a Codeable specification. HTC Onsite will be available to facilitate the process of making a functional specification into a codeable specification. HTC Onsite will also be available for carving out the Stories into manageable tasks which would facilitate coding.

Once the codeable specifications are ready, Core Team would formally handoff the specification for development (#12). After this handoff, HTC Onshore and HTC Offshore complete development analysis to delegate tasks into sub tasks to be assigned to individual developers.

HTC, Technical Architecture

Based on hand off and development analysis (#12), HTC Offshore will create technical specification document (#13) in coordination with HTC Onshore. The Technical Architect will review and approve Technical Specification document created by HTC (#14).

Data Modeling and Quality Assurance

The Data Modeling Team completes data modeling and creates data description language (#15) throughout the Technical Design Phase (#11-17). In parallel, the Quality Assurance Manager will produce test scripts (#16) based on the code-able specifications delivered in (#11) and revise them if necessary throughout the Technical Design Phase (#11-17).

Hand Off # 2

Once the hand off #1 & development analysis is complete, HTC Leads (Onshore and Offshore) will complete Hand off #2. Here HTC Leads will explain their understanding of the requirements and will explain to the core of how the development will be done (#17). At this stage, there is an opportunity for a final Q&A session. Gaps, if any, would be ascertained and either accepted by HTC for coding change or moved onto Spec Team for further analysis/decisions (#6) and will complete another iteration of the development process. Once complete, HTC will then provide effort estimates for the work. Based on availability of developers, HTC would provide Planned Start & Planned Finish dates for every sub task.

Coding - HTC

Starting Point: Receipt of Technical Specifications

Ending Point: Implementation of Completed and Tested Code

Coding and Unit Testing

Based on the Hand Off #2 (#17) and availability of developers, HTC will commence coding (#18). In this step, at appropriate intervals, HTC will schedule preview sessions to demonstrate the work in progress. The Project Team will take relevant actions depending on the outcome of the preview sessions.

Acceptance Testing (#23 & #25)

Once coding is completed and unit tested by HTC Offshore, the sub-tasks would be passed over to HTC Onsite for their testing (#19). If HTC Onsite fails the sub-tasks, the developer picks it up for correction. If HTC Onsite passes the same, then it moves over to QA for Testing (#23).

QA would wait for all sub-tasks to be completely coded & tested by HTC Onsite and then they would pick up the parent tasks for testing by themselves (#23) / Spec Team (#25). At this stage, the tasks could either be passed or failed for coding errors or failed for gaps.

• If the task is passed, then the task moves to the SME Team for acceptance.
• If the task is failed for coding errors, the task moves back to Coding (#18) and then will move again through the development process from that stage.
• If the task is failed for gaps, then the task goes back to (#6) and will then move again through the development process.