Difference between revisions of "CNM Website Developer"

From CNM Wiki
Jump to: navigation, search
(Wiki-based prototype)
(Wiki-based prototype)
Line 93: Line 93:
  
 
===Wiki-based prototype===
 
===Wiki-based prototype===
: [[CNMCyber Team]] utilizes [[CNM Wiki]] to develop early functional websites. Separate wikipages serve as webpage prototypes. Internal site links shall be made manually. The landing page contents at [[CNM Wiki]] shall be titled using the <code>[Domain-name] content</code> format, for instance, [[Bskol.com content]]. Titles of non-landing contents at [[CNM Wiki]] shall have the page name between <code>[Domain-name]</code> and the word, <code>content</code>, for instance, [[Bskol.com About-us content]].
+
: [[CNMCyber Team]] utilizes [[CNM Wiki]] to develop early functional websites. Separate wikipages serve as webpage prototypes. Internal site links shall be made manually. The landing page contents at [[CNM Wiki]] shall be titled using the <code>[Domain-name] content</code> format, for instance, [[Bskol.com content]]. Titles of non-landing contents at [[CNM Wiki]] shall have the page name between <code>[Domain-name]</code> and the word, <code>content</code>, for instance, [[Bskol.com About-us content]]. The category for all of the content wikipages shall have the <code>[Domain-name] Contents</code> format and themselves belong to the [[:Category: Website Contents]].
  
 
===CMS-based prototype===
 
===CMS-based prototype===

Revision as of 20:11, 27 March 2023

A CNM Website Developer (hereinafter, the Dev) is an incumbent of the introductory-quarter CNM practice job (hereinafter, the Practice) that The Economic Group has developed to practically introduce CNM learners to website development. The Devs generally practice in website projects undertaken to develop CNMCyber websites, including their contents, designs, information architectures, SEO, software, and WWW records. The Devs may develop either:

  1. Those CNMCyber websites and other CNMCyber products that the Devs are able to produce, or
  2. Those requirements that would allow hiring Careerprise contractors to develop those CNMCyber websites that the Devs don't produce directly, on their own.

The Practice belongs to CNMCyber Bootcamp (hereinafter, the Bootcamp), which first quarter's lessons are designed to prepare the Devs to that Practice. The Practice is offered to those enrolled in the Bootcamp who successfully pass CNM Website Development Exam after taking the first quarter's classes. Successful completion of the website development practice qualifies the Residents as Certified Website Development Associates.


Position

The Devs undertake website projects in order to develop CNMCyber websites. To learn about benefits, competencies, history, supervision, and target audiences, please consult the CNM practice job wikipage.

Choice of practice

By default, the Devs choose Projects that suit them best. The Devs can choose between:
In addition, the Devs may be offered to develop CNMCyber products other than CNMCyber websites. CNM Cyber Project Managers may ask a Dev to take an urgent or specific project when they understand the Dev's professional capacity. Particularly, that means that the Devs have to choose their first project at least.

How to start

Are you interested in getting started as the Dev? Please follow a step-by-step instruction as follows:
  1. Until the first quarter lessons of the Bootcamp are developed, briefly review
    1. This very wikipage since it describes your website development Practice specifically,
    2. CNM practice job wikipage since it describes your Practice generally,
    3. CNMCyber website wikipage since it describes the websites you are about to develop,
    4. Website project wikipage since it describes those projects that could be undertaken to develop websites generally, not specifically to your Practice, but your Practice can correlate to them, and
    5. CNM Website Projects wikipage since it describes those projects that are authorized to practice with.
    Those wikipage contents are neither intuitive nor user-friendly yet; however, if you cannot read them, you cannot work.
  2. Ask questions. Questions are a huge part of your work; if you cannot ask, you cannot work. If you prefer videoconferences, attend any CNMCyber This Week event. You will have opportunities to ask questions and get responses in real time.
  3. Study this very and CNM practice job wikipages in details to be ready to discuss two topics: (a) what paragraph is intentionally left unclear and (b) what section can be taken out without big harm. You will be offered to discuss those topics during your job interview. Why? If you don't know your job, you cannot work.
  4. If you are willing to be paid, understand why the Cyber project is undertaken and what value is expected from the Dev. That's simple. If you cannot deliver what CNMCyber Customer pays for, you cannot work. Everything that CNMCyber Customer pays for is stated on this very wikipage.
  5. Wait for 2-3 months if you cannot understand what your objectives are. There is a chance that the course and/or videos will be developed out of this wikipage during that time. The introductory courses will be available at https://cert.cnmcyber.com after registering at https://opplet.net/user/register ; the videos will be published on CNM Tube and YouTube. Some of course wiki-materials are linked to WorldOpp Orientation, Employableu Foundation, and CNMCyber Bootcamp wikipages
  6. Pick up your first project at the CNM Website Projects wikipage when you understand what your objectives are. You may have no idea what that particular project is about. First of all, no project is fully clear and, secondly, to learn about one project is always simpler that to learn about many. When you really studied this very wikipage, you should know how to go about that project. If you cannot pick your project, you cannot start working as the Dev.
  7. Present your pick during a CNMCyber This Week event, while stating (a) the project you picked, (b) what you plan to deliver, and (c) how much time you expect to work in order to deliver what you plan to deliver.

Occupations

The Dev's Practice touches many occupations. They may include one or more of the following:
  • Architecture and design such as Human Factors Engineers and Ergonomists, Information Architects, as well as Web and Digital Interface Designers as long as the Devs design website contents, interfaces, and structures.
  • Content creation such as Producers and Directors, Proofreaders and Copy Markers, as well as Writers and Authors as long as the Devs create website contents such as graphics, multimedia, and texts.
  • Technology development such as Architectural and Engineering Managers, Software Developers, as well as Web Developers as long as the Devs work with the technologies behind the website.
  • Web-search marketing as Search Marketing Strategists as long as the Devs work on search engine optimization (SEO).

Tools

What Devs produce

To develop CNMCyber websites, the Devs produce five categories of their first-level results. They are (1) Public contents, (2) SEO efforts, (c) Website designs, (d) WWW records, and, finally, (e) System-based websites. For the Devs, those results represent measurable outputs of the Practice.

Public contents

For the purposes of this very wikipage, public contents refer to those audiovisuals, graphics, and texts that the website visitors shall be able to read, see, and/or hear. As work products of the Devs, texts shall be published at CNM Wiki, while audiovisuals and graphics shall be stored at CNM Repo.

SEO efforts

For the purposes of this very wikipage, SEO efforts refer to those action plans that shall improve website's search engine optimization (SEO). As work products of the Devs, action plans shall be published at CNM Wiki.

Website designs

For the purposes of this very wikipage, website designs refer to those depictions that represent current or future website's appearance, including single webpages and website IAs overall. As work products of the Devs, final depictions shall be stored at CNM Repo; their thumbs and sketches may emerge at CNM Wiki.

WWW records

For the purposes of this very wikipage, WWW records refer to those scripts of DNS record and lines of webserver code that are necessary for the website to be accessible on the World Wide Web (WWW). As work products of the Devs, scripts and lines shall be published at CNM Wiki.

System-based websites

For the purposes of this very wikipage, system-based websites refer to those websites that are powered by one or more content management systems (CMSs). The websites may represent prototypes, minimal viable products (MVPs), or marketables. As work products of the Devs, websites shall be hosted at CNM Cloud.

Projects

For the purposes of this very wikipage, projects refer to those website projects that are undertaken to create new CNMCyber websites or new features of existing websites. While working on projects, the Devs are engaged in the What Devs do activities.

Authorized projects

Those Projects that are authorized to practice with are listed on the CNM Website Projects wikipage.

DREPD patterns

Main wikipage: DREPD
Although no single straightforward pattern of project advancement efforts, some patterns can be seen in various developments. As an example, letters in the DREPD pattern represent five steps:
  1. D for "Discovering the wills". To initiate a project, the Devs shall identify the website need that they would like to satisfy. Outside of website development, we can compare this step with a situation in which someone realizes that he or she needs a better Internet access.
  2. R for "Researching the grounds". To start the initiated project, the Devs shall study the website needs and work environments. Outside of website development, we can compare this step with someone's search for available Internet service provider's offers after he or she realized that they need to improve their Internet access.
  3. E for "Envisioning the solutions". To plan the researched project, the Devs shall imagine what the solution should look like. Outside of website development, we can compare this step with someone's decision what Internet access they are willing to purchase.
  4. P for "Planning the production". To execute the project plan, the Devs shall decide how the imagined solution should be developed. Outside of website development, we can compare this step with someone's plans for how they purchase the needed Internet access and how they pay for it.
  5. D for "Doing to move forward". To start a new DREPD cycle, the Devs shall act on the plan, observe real situations, and re-identify the website need. Actually, the action verbs in that step starts with D; do what is planned, detect what hasn't been expected, and discover new wills. That new discovery may start a new cycle; new data shall emerge while doing and/or after getting something done. Outside of website development, we can compare this step with someone's purchase of Internet access and getting lessons learned in order to make the next purchase better.
This pattern can be found in the whole development, in every group of processes, every process and every part of processes where ever anything new is or is going to be developed.

Project documents

At CNM Wiki, Projects are documented using two types of wikipages:
  1. The progress on particular projects is reported on the CNM Website Projects wikipage.
  2. Project pages document everything, but progress reports. Those pages are listed at the "CNM website projects" category and include project documents such as project charter, asset register, competency register, stakeholder register, requirements traceability matrix, project scope baseline, project schedule baseline, project cost baseline, and acceptance criteria.

Project variety

Main wikipage: Website project
The website project wikipage presents a general, not specific to the Cyber, variety of website development endeavors.

Website-core projects

Websites are complex products, so are their production. For the purposes of this very wikipage, website-core projects refer to those website projects that are undertaken to develop the core of websites rather than their components such as Public contents, SEO efforts, and non-essential WWW records.

Among Website designs, CNMCyber Team classifies website IAs as the backbone of the website core, while graphic design and UX design as parts of website's marketables.

Website idea

Similarly to any work product, a new website starts with an idea; it should be imagined first to be developed further. The Devs may express that idea in words at CNM Wiki and/or one or more sketches uploaded there as files. Depictions of a future website as a whole, in fact, are drafts of website IA.

Wiki-based prototype

CNMCyber Team utilizes CNM Wiki to develop early functional websites. Separate wikipages serve as webpage prototypes. Internal site links shall be made manually. The landing page contents at CNM Wiki shall be titled using the [Domain-name] content format, for instance, Bskol.com content. Titles of non-landing contents at CNM Wiki shall have the page name between [Domain-name] and the word, content, for instance, Bskol.com About-us content. The category for all of the content wikipages shall have the [Domain-name] Contents format and themselves belong to the Category: Website Contents.

CMS-based prototype

Website MVP

   Website as a MVP. In cases of Cyber website development, a minimum viable product (MVP) is an early version of a future website that includes sufficient features to satisfy early adopters. To do so, the website shall have its hub webpages, IA that would be implemented on its software and located on WWW.

Website marketable

   Website as a marketable. To serve a part of The funnel, Cyber website shall possess those features that are developed in the Content, Design, SEO, Software, and WWW projects.

What Devs do

The Coords' work can be divided in nine Sets of processes. Every Endeavor shall start with Formalizing the project, go through at least Studying the backgrounds and Creating the deliverables, as well as end from the Managing the product activities.

Discovering the wills

For the purposes of this very wikipage, project formalization refers to the set of efforts that is undertaken to the extent necessary to start researching the backgrounds for envisioning of Project deliverables and their production. This formalization aims to setup the stage for Studying the backgrounds activities.
The formalization shall produce a project charter, which is a document that (a) formalizes a project out of undocumented change making or development and (b) authorizes the project administration. The charter contains CNMCyber Customer's business requirements or those product and/or project requirements of CNMCyber Customer that are not negotiable. These requirements shall address some business need; the terms business requirement and business need are synonims and often used interchangeably. At CNMCyber, they may be stated in one or more of the following:
  • Business case. A description of CNMCyber Customer's vision for what and/or how the project shall accomplish. The case may or may not state success criteria or those key performance indicators (PKIs) that would or would not constitute the project's success. Any successful project shall satisfy specific business needs. Generally speaking, the business case constitutes why the project exists.
  • Statement of work (SOW). A document that states hard requirements related to product and project scope, budget, as well as schedule. The statement lists "hard" deliverables and key factors that affect the project work. The statement may or may not indicate project tools, policies, regulatory and governance terms. The budget part of the statement may or may not describe milestones. The schedule part of the statement may or may not describe funds available, work authorization process, and/or constraints to the funds' availability. The statement is often employed as a part of a request for proposal (RFP).
On a slang, non-negotiable requirements are called "hard requirements". The charter contains all of the hard requirements that come from CNMCyber Customer. However, some of hard requirements derive from the laws, availability of workforce, and other environmental factors. They shall be added to a requirements traceability matrix (RTM) during the Studying the backgrounds activities.
To coordinate the project formalization, the responsible Coord:
  1. Collects data related to the business requirements from CNMCyber Customer.
  2. Analyses the collected data related to business needs while organizing that data on CNM Wiki.
  3. Drafts a project charter.
  4. Makes sure that the statement of work (SOW) in the drafted project charter addresses the business need and supports the business case.
  5. Submits the drafted project charter for CNMCyber Customer's approval.
  6. Publishes the project charter, after its approval, on CNM Wiki.
  7. Requests (a) assistance of the Administrators when additional resources are needed and/or (b) changes to the project charter when new data from existing and/or new sources of data prompt so.
  8. Reports on progress of the project formalization using the CNM Cloud Usable wikipage.
  9. Presents the progress, plans and possible concerns during CNMCyber This Week meetings.
The project formalization starts after the business need is identified and ends when the project charter is completed.

Researching the grounds

For the purposes of this very wikipage, endeavor studies refer to the set of efforts that is undertaken to the extent necessary to start envisioning, planning and managing for the project deliverables, their production and management. These studies aim to setup the stage for Specifying the deliverables, Planning the project, and Managing the product activities.
Endeavor studies shall produce data needed for (a) envisioning of the product, (b) planning its production, and (c) managing the produced product. At CNMCyber, the project studies shall produce the following outputs:
  • Asset register, which is a database of assets that can be used in the project. Particularly, those assets include non-human sources of data that are useful for production of project deliverables.
  • Competency register, which is a database of those competencies that can be valuable to Cyber efforts and their owners, potential and current Contractors and members of CNMCyber Team.
  • Product user group at CNM Social, which is a space for project stakeholders to receive project updates and contribute their questions and comments. The group shall be open 24/7 for asynchronous activities; a functioning group shall also meet simultaneously via video-conference on a weekly basis. The groups of COTS software users tend to be titled in the "CNM/Opplet COTS-name Users" format.
  • Product pages at CNM Wiki, which are wikipages on which the product is being developed. The pages that represent COTS software tend to be titled in the "CNM/Opplet COTS-name" format. They belong to the "CNMCyber products" category.
  • Endeavor pages at CNM Wiki, which are wikipages on which the endeavor is being developed. The pages that represent endeavors on COTS software tend to be titled in the "COTS-name for CNM Cyber/Cloud/Opplet/Farms" format. They belong to the "CNM Cyber endeavors" category.
  • Requirements traceability matrix, which is a grid that links requirements and their sources.
  • Stakeholder register, which is a database that lists stakeholders of the endeavor. Those stakeholders include the Administrators, CNMCyber Team, those Contractors that work on the endeavor, as well as regulatory bodies that define and/or constrain endeavor's efforts issuing applicable laws and binding requirements. The complete register contains analysis of stakeholders.
To coordinate the project studies, the responsible Coord:
  1. Identifies those available resources that should or can be used in project activities. Human resources include CNMCyber Team. Other resources include those presented in the initial WorldOpp Pipeline courses, on CNM Wiki, existing tools, materials, prototypes, and finished products available at CNMCyber, on the World Wide Web and other sources. For off-the-shelf products, developer websites and professional resources like https://stackoverflow.com/ are usually helpful.
  2. Analyses the identified resources with regard to their nature, usefulness, and potential impact while organizing that data on CNM Wiki.
  3. Selects those resources and those data that may be used in the project activities.
  4. Composes the asset register, competency register, and stakeholder register.
  5. Forms a product user group at CNM Social if this group hasn't formed yet; refreshes the group if it has already formed.
  6. Organizes weekly video conferences, as well as other meetings and activities of the user group. Topics of those events shall address the product, its production when the product is under development, work of its administrators, user feedback and market trends.
  7. Invites everyone who is interested in product's development to the user group.
  8. Offers those experts and specialists who have knowledge, skills, and abilities useful for product specifications or project planning to discuss the deliverable and/or project.
  9. Interviews those experts and specialists who agreed to discuss the deliverable and/or project.
  10. Collects data related to (a) the project deliverables and their production when this deliverable hasn't been deployed yet and (b) product performance when the deliverable has already been deployed, as well as its industry trends.
  11. Makes sure that all of the collected data sources are listed in the asset register, competency register, or stakeholder register.
  12. Publishes the collected data on CNM Wiki. Product data shall be published on the product pages; project data shall be published on the project pages. The published data shall refer to its sources; however, personal data publication requires permissions. From a legal point of view, we cannot publish the confidential information of our contractors, for instance.
  13. Creates a requirements traceability matrix to trace the product and project requirements from the selected sources to perspective project deliverables.
  14. Updates the asset register, competency register, stakeholder register, requirements traceability matrix, as well as project and product pages when ever new data from existing and/or new sources emerge.
  15. Requests assistance of the Administrators when additional resources are needed.
  16. Reports on progress of the project studies using the CNM Cloud Usable wikipage.
  17. Presents the progress, plans and possible concerns during CNMCyber This Week meetings.
The project studies start after the project charter is approved. Collection of requirements, product envisioning, project planning, production, as well as commissioning and management of a product always reveals new factors and data. That is why the studies end with the project closure.

Envisioning the solutions

The main goal of the product specification activities is to get the deliverable in a state of certainty, which is determined by the presence of a validated product specification. This specification is needed to compare the created deliverables against their requirements. To coordinate the product specification, the responsible Coord:
  1. Collects data related to stakeholder requirements for the project deliverables and product specifications using the asset register, competency register, and stakeholder register. This collection includes communications with stakeholders and review of documents and other assets that are registered.
  2. Examines available prototypes, unfinished and finished products against the collected data.
  3. Analyses the collected product data while organizing that data on CNM Wiki.
  4. Clarifies the collected data based on the examined prototypes and finished products.
  5. Identifies those target audiences who are supposed to use future deliverables.
  6. Creates imaginary personas that would represent each of the identified audience.
  7. Produces stakeholder requirements for each created persona using CNM Wiki.
  8. Composes product specifications based on the produced stakeholder requirements using CNM Wiki.
  9. Traces in a requirements traceability matrix the formalized stakeholder requirements from their sources to perspective project deliverables.
  10. Makes sure that (a) the product specification supports the stakeholder requirements and (b) all the deliverable data is published on CNM Wiki.
  11. Checks product specifications for completeness. This completeness shall be characterized by the presence of conditions for (a) functionality, (b) applicability, and (c) manageability of the deliverables. Conditions for functionality should include measures for product's performance. Conditions for applicability should include measures for product's deployment, testing, diagnostics, accessibility, serviceability, protection, and capacity to recover after disasters; these measures must be documented in product's standing operational procedure (SOP). Conditions for manageability should include measures for product's monitoring, periodic audits and revisions, as well as timely software updates for the COTS software products.
  12. Updates the stakeholder requirements and product specifications when ever new data from existing and/or new sources emerge.
  13. Requests assistance of the Administrators when additional resources are needed.
  14. Reports on progress of the product specification using the CNM Cloud Usable wikipage.
  15. Presents the progress, plans and possible concerns during CNMCyber This Week meetings.
The product specification opens when CNMCyber Customer approves the project charter and ends with the project closure.

Planning the production

The main goal of the project planning is to decide how the project deliverables will be developed. Those activities shall result in validated acceptance criteria. In other words, planning is getting a description of project activities that allows this development to be certain. To coordinate the project planning, the responsible Coord:
  1. Collects data related to project scope baseline, project schedule baseline, project cost baseline, and acceptance criteria using the asset register, competency register, and stakeholder register. This collection includes communications with stakeholders and review of documents and other assets that are registered.
  2. Examines the existing products that are going to be further developed if they are available.
  3. Analyses the collected project data while organizing that data on CNM Wiki.
  4. Formulates the difference between what actually is and what is needed to be. The existing products are what actually is, while the specified deliverable is what is needed to be. The project activities shall address this identified difference; they represent what needs to be done.
  5. Drafts a project scope baseline, project schedule baseline, project cost baseline, and acceptance criteria, based on the resources recorded in the registers.
  6. Makes sure that the acceptance criteria supports the project scope baseline and project schedule baseline.
  7. Submits the drafted project scope baseline, project schedule baseline, project cost baseline, and acceptance criteria for CNMCyber Customer's confirmation.
  8. Publishes the project scope baseline, project schedule baseline, and acceptance criteria, after their confirmation, on CNM Wiki. To make future negotiations successful, neither the project cost baseline nor other financial data should be available to the general public.
  9. Requests (a) assistance of the Administrators when additional resources are needed and/or (b) changes to the project scope baseline, project schedule baseline, project cost baseline, and/or acceptance criteria when new data from existing and/or new sources of data prompt so.
  10. Reports on progress of the project planning using the CNM Cloud Usable wikipage.
  11. Presents the progress, plans and possible concerns during CNMCyber This Week meetings.
Similarly to Specifying the deliverables, the project planning opens when CNMCyber Customer approves the project charter and ends with the project closure. However, the project plan not entirely, but depends on product specification, while the specification rarely does. The deliverable to be rules what needs to be done, not vice versa. Only impossibility of the specified deliverable production can initiate the change to its product specification.

Doing to move forward

Creating prototypes, producing components

The main goal of deliverable creation activities is to create rightly right deliverables. "Right" means that every deliverable shall be in a state of capability, which is determined by the fact that the deliverable meets all the product specifications that have been approved for this deliverable. "Rightly" means that the aggregate of creation activities match the agreed acceptance criteria.
At the Cyber, Contractors create Project deliverables. To coordinate the deliverable creation, the responsible Coord:
  1. Initiates hiring of development contractors.
  2. Plays roles of the product owner and/or project owner in the absence of other members of CNMCyber Team assigned to those roles. In that case, the Coord decides how, within the framework of the approved requirements, the deliverable and the project should be.
  3. Tests the deliverable and, if necessary, its parts.
  4. Collects data related to the deliverables under development and their production.
  5. Analyses the collected project data while organizing that data on CNM Wiki.
  6. Monitors the development and execution of the project, including compliance with the budget, schedule and scope of work.
  7. Inquiries about changes to the project charter, product specification, project scope baseline, project schedule baseline, project cost baseline, and/or acceptance criteria when new data from existing and/or new sources of data prompt so.
  8. Organizes a closed-from-the-public-view project space on CNM Repo for work on the deliverable in addition to the project wikipage on CNM Wiki.
  9. Invites the hired contractor to the project space.
  10. Reports to CNMCyber Customer on the status of the project, collecting, analyzing and summarizing information and trends.
  11. Treats creation of deliverables as primary source of data to revisit the Studying the backgrounds activities.
  12. Makes sure that the created deliverables (a) represent a complete bundle of products that are listed in the Careerprise contractor agreement and (b) satisfy their acceptance criteria.
  13. Recommends, after the contractor informs about the completion of project work, either (a) acceptance of the deliverables or (b) refusal to accept those deliverables while providing CNMCyber Customer with explanations for that refusal.
  14. Requests assistance of the Administrators when additional resources are needed.
  15. Revisits the Studying the backgrounds activities when new data or new sources of data emerges in order to revisit further the Specifying the deliverables and Planning the project activities.
  16. Reports on progress of the deliverable creation using the CNM Cloud Usable wikipage.
  17. Presents the progress, plans and possible concerns during CNMCyber This Week meetings.
The deliverable creation opens when CNMCyber Customer authorizes its financing and ends when the deliverables are accepted. To expedite the project, the creation may start before its acceptance criteria have developed.
The main goal of the product commissioning is to obtain the product in its state of applicability, which is determined by the fact that the deliverable is not only functional, but can also be sustainably used for the purpose for which it has been created. In simple words, the commissioning is a transfer of the accepted deliverables from the contractor into Cyber operations. To coordinate this commissioning, the responsible Coord:
  1. Clarifies with CNM Cyber Project Managers which members of CNMCyber Team will: (a) deploy the newly-deployed product if it hasn't been deployed yet, (b) test the newly-deployed product, (c) restrict access of the development contractors to the product and product's classified documentation, (d) access the classified documentation on CNM Repo, (e) establish new product operations based on its standing operating procedure (SOP), and (f) manage hiring of service contractors.
  2. Initiates (a) deployment of the newly-deployed product if it hasn't been deployed yet, (b) beta testing of the newly-deployed product, (c) restrictions of the development contractors' access to the product and product's classified documentation, (d) new administrator's access to the classified documentation on CNM Repo, (e) establishment of new product operations based on its standing operating procedure (SOP), and (f) hiring of service contractors.
  3. Collects data related to the product commissioning.
  4. Analyses the collected data related to product commissioning while organizing that data on CNM Wiki.
  5. Publishes the documentation received from the contractor on the Cloud resources. Internal, closed to the public, documentation, such as administrator access to installed software, is published on CNM Repo. The documentation that can be open to the public without restrictions is published on CNM Wiki.
  6. Requests assistance of the Administrators when additional resources are needed.
  7. Revisits the Studying the backgrounds activities when new data or new sources of data emerges in order to update the Managing the product activities.
  8. Reports on progress of the product commissioning using the CNM Cloud Usable wikipage.
  9. Presents the progress, plans and possible concerns during CNMCyber This Week meetings.
The product commissioning opens when the deliverables are accepted and ends when the product is ready to be used in Cyber operations.

See also

Related lectures