Implementation

The below Build, Test and Review cycles fall within a given milestone.

Note: a version can have multiple milestones.

Build

The build cycle within a milestone focuses on executing the development tasks associated with achieving the scope outlined for this milestone. This commonly equates to using K2 tooling to design workflows, forms, SmartObjects etc… as well as non-K2 tools such as Visual Studio, SharePoint and SQL Server to design additional elements within the solution.

Common roles that participate within this phase are outlined below.

Note: keep in mind that exact roles can change based upon specific project needs. Additionally, it is common for individual people to be responsible for more than one role.

ROLE
DESCRIPTION
Project Manager
Ensures that tasks for this build cycle are tracking to the work breakdown for the targeted milestone. Manages overall project risk and deliverable.
Solution Architect
Responsible for technical oversight on all of the various component developers and ensures they are tracking to design.
Business Analyst
Available to clarify any business / functional questions that come out of the build team.
Workflow Developer
Focuses on K2 workflow / process development.
UI Developer
Develops solution user experience (forms / reports) with appropriate forms design tool (e.g. K2 SmartForms).
.NET Developer
If needed, handles code-based extensions and or integrations.
SharePoint Developer
If needed, creates any SharePoint artifacts (lists, libraries, sites, branding, content types…).
Database Architect
If needed, creates the application/solution database (typically in SQL Server).
Quality Assurance Lead
Leads all testing.
Quality Assurance Tester
Executes tests, reports to stakeholders.
Release Manager
Leads deployment planning.

It is a K2 and general software development best practice to ensure that all development artifacts are protected from inadvertent loss or editing. Standard source control conventions recommend the usage of a source code control system such as Microsoft’s Team Foundation Server (TFS).

The implementation team is responsible not just for building the components needed by the milestone, but also for performing developer unit and integration testing. Unit testing is where an individual developer tests the components they create. Integration testing focuses on confirming that all the various components from the team are deployable and functioning as a unit. Once these implementation team based testing is completed, this milestone can be promoted to the more formal test cycle.

Below outlines available supporting content for this section:

Template
DESCRIPTION
This document provides guidance on how source code control can be leveraged for K2 design time artifacts.

Test

This phase handles non-development testing tasks such as quality assurance (QA) testing and user acceptance testing (UAT). QA testing is performed by a testing team that is not the implementation team but is also not the end users either. It is important to distinguish the testers from the developers in order to force a division of responsibility and separation of concern in order to achieve more thorough test exposure before turning a solution over to the users. User acceptance testing (UAT) is performed by key resources from the end user community and is used to validate the deliverable has met specification and usability. The release management team should be tasked with moving the solution to the appropriate test environment(s).

In order to create consistent and repeatable tests, time should be spent by the testing team(s) to formulate test cases that outline the functionality and supporting execution steps needed. These test cases should be granular with a system user focus. This allows a tester to know exactly what he/she needs to execute within the solution to perform that test as well as what constitutes a pass or fail. It is important that these test plans be structured to ensure they are repeatable across versions and testers. Please refer to the Supporting Content table at the end of this section for an example test plan.

Each respective test cycle should be disciplined enough to capture issues as they occur during a test. These issues should be stored in a centralized location (such as Microsoft’s Team Foundation Server (TFS), if organization has TFS, or minimally within a common data store like a SharePoint list). This data will be leveraged during the next Review phase. In the event a common repository for QA issue tracking is not available there is an example spreadsheet within the COE supporting content that can be leveraged.

Common roles that participate within this phase are outlined below.

Note: keep in mind that exact roles can change based upon specific project needs. Additionally, it is common for individual people to be responsible for more than one role.

Role
DESCRIPTION
Test Lead
Individual responsible for constructing test cases and organizing a structured test plan and feedback capture across the testing team.
Tester
Person tasked with performing the individual test cases and gathering feedback.
Release Management
Person responsible for deploying the solution into new environments. In some organizations this is a team completely independent from the implementation / development team.
Implementation Lead
The lead from the implementation that is on hand to assist with general solution questions during the test cycles. They can leverage other implementation team members on an as needed basis.

Below outlines available supporting content for this section:

Template
Description
This document provides the methodology of testing K2 artifacts.
This document explains the process of QA including the documentation (proof) of execution.

Review

Upon completion of a test cycle, the Test Lead should work with the Project Manager and Implementation Lead to review all items to determine the category, severity and priority of each individual item.

  • Categorization: determines if this is a bug or enhancement request
  • Severity: assesses the impact on operations; typically as:
    • Low: cosmetic issue or no significant impact on operations
    • Medium: impacts business in a way that warrants near term attention
    • High: effects operations in a critical way; either through in ability to operate correctly (in the event of a bug) or potentially provides improvement to operations (in the case of an enhancement request)
  • Priority: outlines the order in which items should be addressed

The ability to address feedback items needs to be factored into milestone and versioning planning. Generally Medium and High priority bugs are deemed necessary to be resolved before closing out a milestone. Any items that are enhancement requests or scope changes should be factored into a new milestone at and then versions should be reassessed. Once the milestone and version roadmap is agreed upon the project plan should be updated to reflect the current thinking. It is extremely important to have a structured review and change management process in order to avoid confusion around builds, releases and to keep costs under control. Failure to appropriately document, review and handle the feedback and resulting changes can have significant impact on project timelines and costs.

Common roles that participate within this phase are outlined below.

Note: keep in mind that exact roles can change based upon specific project needs. Additionally, it is common for individual people to be responsible for more than one role.

Role
Description
Test Lead
Individual responsible for constructing test cases, organizing a structured test plan and feedback capture across the testing team. They will leverage this background to explain the findings to the stakeholders within this phase.
Project Manager
Responsible for driving the review phase to determine new milestones, versions and updating project plan accordingly.
Implementation Lead
The lead from the implementation that is on hand to assist with general solution questions and impact assessments. They can leverage other implementation team members on an as needed basis.

Initial Discovery

This phase focuses on understanding the high-level goals, needs and timelines for the potential project. This is typically less than a couple of hours of conversation where the key stakeholders of the solution, such as business subject matter experts (SME), technical leads and project manager have a conversation with the leads from the potential implementation team (referred to as Business Architect and Technical Architect).

Solution Analysis and Planning

The Solution Analysis and Planning phase is the entry point into solution functional scoping and project planning. The goals of this phase are to identify project critical success factors, as well as to discover initial functional scope, business requirements, technical drivers and integrations. This phase is typically lead by the Business Architect and the Technical Architect leveraged during the Initial Discovery phase. Once the functional and technical factors are determined, a high-level solution vision and reference architecture can be formulated to articulate how the key components of the proposed solution can be aligned and leveraged to achieve the functional requirements. Additionally, initial infrastructure planning can be formulated to support the project needs. With this reference architecture in place, initial estimates can be formulated and work breakdown structures generated to allow for initial project costing; allowing for more detailed budgeting and planning discussions.

Elaboration and Design

Upon completion of the SA&P phase there should be a foundational understanding of the goals, scope and vision of the proposed solution. The Elaboration and Design phase expands the prior work by delving deeper into identifying and documenting the business and technical requirements in order to drive to derive at a target solution architecture, technical design and implementation plan. This phase can be of a short duration depending on the size of the project.

Roll Out

The rollout phase is when a version is deployed to the Production environment and becomes operational within the business unit. This requires planning and coordination across multiple units.