Create a single BPMN diagram using the Camunda Modeler of the below process narrative. Feature appropriate pools and lanes to represent the different entities/participants and the message flows between these entities/participants. Please label all flows (sequences, messages). Do not use sub-processes.

Canvas is a leading provider of LMS (Learning Management Software) software. Canvas is used by many colleges as a teaching course portal.

Canvas has an active user community made up of Professors from many colleges. Many Professors within the Canvas community post comments on the Canvas Community Portal (CCP) as well as attend Canvas training events. Canvas has designated a small number of these Professors to be Canvas Power Users (CPUs). CPUs are usually Professors who have exhibited a high level of engagement with the Canvas platform, such as attending training events and being active on the CCP (making posts, etc.).

CPUs occasionally submit to Canvas a request for a new software feature (henceforth, called a feature request). Ideas for new features typically reflect a need or issue that has arisen within the Canvas user community (e.g., through CCP discussion boards), or ideas CPUs have heard from talking to other Professors at Canvas training events.

Feature requests from CPUs are usually emailed directly to the secretary of the internal customer relationship team (CRT) and the CRT secretary will then create a Slack channel so the CRT can discuss the new feature request.

After discussing the new feature request on Slack, if the CRT considers it to be promising and wants to move forward, details of the feature request are posted on the dedicated Design Ideas webpage of the CCP and opened up for comments (posts) by members of the Canvas user community. To determine whether CRT will move forward with the feature request a poll is taken on Slack – and if the majority of CRT personnel do not endorse the feature request it is shelved and the CPU who submitted the feature request is emailed that it has been shelved.

In addition, members of the Canvas user community are allowed to ‘endorse’ the feature request by voting to give it a thumbs up. Once 200 members of the Canvas user community have given their endorsement (thumbs up), the CRT will create a formal internal feature design proposal (FDP) for the feature request. Details of the FDP are stored in Canvas’ Design Document Management System (DDMS).

The Technical Design Department (TDD) at Canvas has the responsibility of developing the next version of the Canvas platform. Consequently, TDD employs most of Canvas’ software engineers. TDD’s management meets at the middle of each month to discuss any new FDPs that have been added to the DDMS during the previous month.

During this meeting, issues with the FDP may be raised. For example, a software engineer may foresee a technical conflict between the proposed feature and an existing feature. Another issue that sometimes arises is a lack of skilled employees available to implement certain types of features. For example, right now Canvas has trouble recruiting software engineers skilled in AI and therefore TDD has been hesitant to undertake such feature requests.

At this stage, if the FDP is rejected by TDD management, the TDD will post a summary of those reasons on the CCP Design Ideas webpage to inform the Canvas user community. On the other hand, if TDD management wants to move forward with the FDP, TDD’s accountant will prepare a report to estimate the costs associated with implementing the feature, including projected salary costs.

At the same time the costing report is being prepared, TDD will request Canvas’s Legal Department (CLD) to review the FDP to ensure that either it will not violate any existing patents or to inquire whether a patent can be prepared for the new feature to protect any intellectual property (IP) that may be created. If the CLD fails to clear the FDP with respect to potential violation with existing patents then CLD will shelve the FDP. CLD will also update the FDP in the DDMS to reflect their review.

Once the costing report and legal review have been completed, the TDD’s Chief Technology Officer (CTO) will write a memo to the Canvas Product Manager (CPM) requesting a review and approval of the new FDP.

The success and responsibility of the Canvas platform ultimately rest with Canvas CPM. The CPM takes a strategic perspective and has responsibility for Canvas’ product Road Map. The CPM will review the FDP and still may veto it completely if she feels the feature request does not align with the future direction of the Canvas platform.

The CPM will then review all the information so far collected about the feature request with the objective of classifying the FDP into one of four categories within the Canvas platform roadmap: Current (to be included in the next release), Near Term (to be included in planned releases over the next 18 months, but not the next release), Future (longer term than Near Term, but no longer than 3 years), and Wish List (under consideration but the timing is indeterminate). Once the FDP has been classified, the official Canvas platform roadmap is updated within the DDMS.

There is also a special Canvas RoadMap webpage on the CCP and any additions or changes to the roadmap that impact the planned released cycles over the next 18 months will be updated to reflect those changes.

Answer rating: 100% (QA)

The CPM will then make a recommendation to the Canvas Product Governance Board CPGB for approval The ... View the full answer