1 / 29

COMR Process and Policy Overview

COMR Process and Policy Overview. A Few Ground Rules. Process and policy has evolved over time. Yes, it is confusing…but not by design. Please don’t shoot the messenger!. The documentation. Two CMS documents govern COMR Process and Policy:

binta
Download Presentation

COMR Process and Policy Overview

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. COMR Process and Policy Overview

  2. A Few Ground Rules • Process and policy has evolved over time. • Yes, it is confusing…but not by design. • Please don’t shoot the messenger!

  3. The documentation Two CMS documents govern COMR Process and Policy: • CMS Central/Campus Development Responsibilities (DEVEL) • Campus Object Migration Request (COMR) Process Guide (COMR)

  4. CMS Central/Campus Development Responsibilities The policy document. Defines what campuses can and cannot do with campus-specific modifications. Defines how campus-specific modifications should be developed.

  5. Campus Object Migration Request (COMR) Process Guide The process document. Defines how campuses can get modifications approved (if necessary) and into production.

  6. The Basic Policy If a campus follows these rules, they can just follow the COMR Process Guide to get modification into production

  7. Campuses Can Develop modifications to meet campus specific needs associated with reports, interfaces, workflow, self-service, and other campus-specific functionality added to the application (“bolt-ons”) - DEVEL pg. 1

  8. Campuses Can Submit Crystal, nVision and SQR file objects. Any type of PeopleTools object. Workflow objects (worklist records, wf maps, wf panels, wf PeopleCode) - DEVEL pg. 2

  9. Campuses Cannot Modify COBOL Programs and stored statements. Modify Database-level triggers Modify Baseline (CMS or PeopleSoft) objects. - DEVEL pg. 2

  10. Campuses Must Submit objects that are prefixed with campus development designations. - DEVEL pg. 2

  11. Except… Campus can directly modify: Message catalog entries Self-Service Launch Pages Workflow PeopleCode. Modify a component or page definition to enable expert entry or deferred processing. - DEVEL pg. 3-4

  12. Except… (reworded) All campus modified objects must be prefixed with the campus development designation with the specific exception of those items listed in the CMS Central/Campus Development Responsibilities (pg 3-4). This INCLUDES self-service pages.

  13. Except… (reworded v2) Campuses needing to modify a delivered object MUST clone and prefix objects with the campus development designation with the specific exception of those items listed in the CMS Central/Campus Development Responsibilities (pg 3-4). This INCLUDES self-service pages.

  14. The “Exception” Policy You can’t have a policy in the CSU without having exceptions!

  15. Campuses Can Pretty much modify anything, but they must obtain CMS Senior Director approval. - COMR pg. 5

  16. Campuses Must Request exception approval prior to submitting development. Submit initial request through application team project director. Agree to fully support modification. Agree to remove modification when/if PeopleSoft or CMS addresses issue. - COMR pg. 5 (but mostly not documented)

  17. Campuses Must Obtain exception approval for any modification that will include an object that is not prefixed with the campus development designation. … and yes, this does include self-service.

  18. CMS Must Inventory the exception and review periodically. CMS will also review exception list and manage support responsibilities accordingly.

  19. The Process How campuses move to production.

  20. Process overview Campus begins to document business requirements that will lead to a modification. At design/requirement time campus needs to answer a few basic questions.

  21. Modification to baseline? First, campuses must determine if modification will require a change to a baseline object (as defined in DEVEL pg2). If yes, campus project director must submit a request for exception through the CMS application PDs to the CMS Senior PD for approval. (COMR pg 5)

  22. Impact to Infrastructure? Secondly, campuses must assess if modification will the agreed upon impact thresholds (COMR pg 6).

  23. Impact to Infrastructure? If modification will NOT exceed threshold, then campus PD approves modification on COMR Impact Analysis form. Approved COMR Impact Analysis must be submitted along with COMR package when production migration is requested. - DEVEL pg 6

  24. Impact to Infrastructure? If modification WILL exceed threshold, then campus PD recommends to the CSU COMR Impact Analysis committee for review and approval. When/If approved COMR Impact Analysis must be submitted along with COMR package when production migration is requested. - DEVEL pg 6

  25. Move to production An approved COMR can be submitted to CMS for final review and migration to production.

  26. Approved COMR? Adheres to all policies outlined in DEVEL AND Contains only campus prefixed items or items that are predefined as exceptions to cloning process AND COMR Impact Analysis approved by campus PD or committee.

  27. OR… Contains objects not prefixed with campus development designation and those items are not predefined as exceptions to cloning process and CMS Senior Director exception approval given. AND COMR Impact Analysis approved by campus PD or committee.

  28. CMS Process Help Desk ensures that documentation attached to all COMRs (Impact & Migration Request form). Application Teams review to ensure items comply with policy. Technical Services schedules and then migrates modification to production.

  29. Campus Access to Production Campus direct access to production is limited. In general CMS “owns” the SYSADM account and via our Change Control Policy is responsible for production application migrations.

More Related