1 / 19

Curriculum Release and Bug Reporting Processes

Curriculum Release and Bug Reporting Processes. November 2007. Curriculum Release Process Objectives. Provide a framework that is: Structured agreed classifications and numbering scheme Predictable fewer surprises about “what’s next” Transparent

Download Presentation

Curriculum Release and Bug Reporting Processes

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Curriculum Release and Bug Reporting Processes November 2007

  2. Curriculum Release Process Objectives Provide a framework that is: • Structured agreed classifications and numbering scheme • Predictable • fewer surprises about “what’s next” • Transparent • provide visibility into release decisions • Proven • based on industry best practices • Appropriate • for both curriculum lifecycle and portfolio planning

  3. Reasons for a Release • Entirely new course • Major framework change; e.g. CCNA 3.0 > CCNA Discovery 4.0 & CCNA Exploration 4.0 • Refresh of course content without significant changes to framework • Collection of error fixes • Immediate error fix • Adaptations of existing release; e.g. translations, accessible versions, etc.

  4. Release Types and Versioning • Initial release – version 1.0 • Major release – version X.0 • Major framework or platform changes • May occur every 3 to 5 years • Minor release - version X.y • Minor content or framework changes • May occur every 1 to 2 years • Maintenance release - version X.y (z) • Minor content improvements and error fixes • May occur frequently after a major release, then tapers off • Emergency release – version X.y (z) • Only if a P1 bug requires immediate response • Adaptations – same version as adapted release

  5. Example Product Roadmap Q1 Q2 Q3 Q4 Q1 Q2 Q3 Intro Course Intro Course 3.0 Intro Course 3.0 (1) Intro Course 3.0 (2) Intro Course 3.1 Advanced Course Adv. Course 5.0 Adv. Course 5.0 (1) Specialty Course Specialty Course 3.2 Specialty Course 4.0 Etc… Major Minor Maint.

  6. Example Product Roadmap – 1 Curriculum Q2 Q3 Q4 Q1 Q2 Q3 Q1 English version Initial Release 1.0 2nd Maint Release 1.0 (2) Minor Release 1.1 1st Maint Relelase 1.0 (1) Spanish Initial Release Spanish 1.0 Minor Release Spanish 1.1 1st Maint Release Spanish 1.0 (1) Accessible Initial Release Accessible 1.0 1st Maint Release Accessible 1.0 (1) Etc… Initial Release 1.0 Major Minor Maint.

  7. Major Release Example • Changes in the certification, the age of the existing curriculum (>3 years), and a desire to take advantage of new delivery technology drive significant changes to the course • Major changes to chapters • deletion of old chapters • inclusion of new chapters • changing order of material • Change in the GUI • Major X.0 release

  8. Minor Release Example • Certification requirements have changed, so numerous chapters need revision in order to stay current. An additional chapter needs to be added as well, but the overall flow of the course, the GUI, and the delivery mechanism remains unchanged. • Minor X.y release

  9. Maintenance Release Example • Numerous minor changes have been made to the curriculum and assessments in response to requests from internal and external sources • Numerous bugs fixed • Maintenance X.y (z) release

  10. Emergency Release Example • Despite careful QA procedures and testing, a Priority 1 bug is found after release and the error could potentially affect the delivery of the course. • Emergency release X.y (z)

  11. Adaptation Release Example • Translation into Spanish has been completed on the 4.2(1) release of a course • Released as 4.2 Spanish

  12. Errata / Bug reporting process • Maintenance releases are determined by the number and severity of reported bugs • We encourage all instructors to report bugs in the curriculum and assessments as they are discovered • View existing errata and report new bugs using Academy Connection • The Global Support Team responds to all new bug reports within 24 hours

  13. Bug Reporting Process – Step 1 • Log into Academy Connection and access the Curriculum and Assessment Quality Support page • Click Help and select Curriculum and Assessment Quality Support • OR • Click Contacts and Feedback on the Instructor Home page, click Academy Community Support,then select Curriculum and Assessment Quality Support

  14. Bug Reporting Process – Step 1 (cont’d) • OR • Select Report Curriculum and Assessment Quality Issues on the Instructor Class Home page

  15. Bug Reporting Process – Step 2 • Check the errata to see if the bug has already been reported using the Answers tab • Select the errata or error list for the appropriate course and category (curriculum or assessment) from the list displayed

  16. Bug Reporting Process– Step 2 (cont’d) • Download the errata spreadsheet listed in File Attachments • Open and review the errata spreadsheet to determine if the problem you’ve found has already been reported

  17. Bug Reporting Process – Step 3 • If your bug has not been reported, please report it! • Select Contact Curriculum Team or Contact Assessment Team tab, as appropriate • Fill out form and submit – you’ll get a response within 24 hours

  18. Conclusion • All curriculum releases will follow a standard and easily understood numbering convention • Maintenance releases will be based on the quantity and severity of reported bugs • Instructors can access errata and report bugs using the Curriculum and Assessment Quality Support Tool on Academy Connection

More Related