• Permalink

    The use of Kanban to support a well defined Software Development Life Cycle

The use of Kanban to support a well defined Software Development Life Cycle

In our last blog I discussed how the Scrum process supported the Software Development Life Cycle. Partnet uses two different proven Agile development methodologies for development: Scrum and Kanban. A specific method is chosen based on the nature of the work.

Scrum: Used for complex projects where increments of work can be flexibly managed and assigned into sprints. Work assigned within a sprint can be completed without disruption.
Kanban: Used for less-complicated projects (e.g., Problem Reports) where priorities frequently change.

Kanban is a backlog-pull model that emphasizes just-in-time delivery of work and avoids process bottlenecks by limiting in-progress work. Kanban also allows for customer-driven prioritization as tasks are regularly prioritized to match their current needs. This means that if an emerging requirement suddenly takes precedence over existing priorities, the team can flexibly respond without affecting project goals or progress. Kanban uses the same Delivery Team roles and responsibilities employed in Partnet’s Scrum process. Partnet employs Kanban for Problem Report work since this work is often subject to shifting priorities.

Partnet’s Kanban process pulls new requirements from a Customer prioritized backlog. Tasks are created and assigned to release versions based on these priorities. The process defines a series of work queues that simultaneously identify the current status of a given development task, and the assigned resource.

Together, the work queues establish a linear workflow for completion of assigned development tasks, as shown below.

 Work Queues and Linear Workflows

Work Queue
Status

    Assigned Resource

To do
Backlog task; not actively being worked on by any project team member
   Backlog

Needs Requirements
Undergoing requirements analysis to define new functional requirements; assess impact to existing functionality
    Requirements Manager

Ready for Development
Requirements analysis complete or not needed

    Developer

Development in Progress
Development and integration underway; includes unit testing and code reviews
  […]

  • Permalink

    Part 5: System Development Life Cycle – Release Planning and Deployment

Part 5: System Development Life Cycle – Release Planning and Deployment

The Release Planning and Deployment stage begins upon completion of software testing. During this time, no changes to the software are permitted excepting those explicitly directed by the Customer. Release Planning and Deployment is performed in three phases: Pre-deployment, Deployment, and Post-deployment

Pre-Deployment

The Pre-Deployment Phase addresses three major tasks simultaneously:

Release Planning
Training and Documentation
User Acceptance Testing (UAT)

In most cases, software deployments to the System Users will be transparent to end users.

However, careful release planning and coordination is essential for ensuring that the Customer is consulted on all new or altered code and the decision to release it. Release planning also includes identification of active and standby resources, as well as specification of a roll-back strategy in the event it becomes necessary to revert or roll back the deployed code.

Partnet will collaborate with the Customer and any associated Change Control Board (CCB) representatives to create a release deployment plan, to include:

A cutover schedule, identifying the date and time for the release.
A listing of the features and/or problem reports that will be contained in the release.
Identification of a release coordinator.
A release impact assessment, including impacts to integration partners.
A roll-back plan, outlining a contingency process for removing new changes should it become necessary.

The following tasks can then be performed as part of the pre-deployment phase:

Identify the deployment team, including: Release Project Manager, Change/Configuration Manager, Database Administrator, Technical Lead, Software Test Engineer, End User Tester
Prepare a draft deployment schedule which:

Chronologically outlines required deployment tasks and estimates, including tasks to be performed by external third parties.
Identifies the complexity, timeframe, and task owner of each deployment task.

Execute a mock deployment on the Staging environment, which allows the team to rehearse deployment tasks and validate estimates.
Execute the roll-back plan on the Staging environment […]

  • Permalink

    Part 4: Software Development Life Cycle – Software Development, Testing, and Quality Assurance

Part 4: Software Development Life Cycle – Software Development, Testing, and Quality Assurance

Agile best practices recommend overlapping development and testing cycles. This helps identify and resolve software defects early, while minimizing scenarios where developers are simultaneously trying to fix old bugs and build new features.

Overlapping development and testing cycles also promotes the incremental delivery of working code. This process allows new features and bug fixes to be rapidly promoted, while allowing the Customer to review new features as they are developed, and make decisions about when specific features are ultimately deployed to Production.

Partnet’s software development process is enhanced by the incorporation of continuous delivery methodologies. Continuous delivery is a collection of techniques designed to improve and automate software delivery. These techniques include:

Continuous delivery pipeline
Automated testing
Mainline development
Continuous integration

Continuous delivery allows software to be developed to a high standard, easily packaged, and rapidly deployed to the various environments. Additionally, new features and bug fixes can be rapidly promoted to the Production environment with minimal risk and overhead.

Our developers use a continuous delivery pipeline to implement continuous delivery principles.

The deployment pipeline is like an automated assembly line which the code passes through to ensure it is ready for Production. This assembly line includes:

Building the software
Running unit tests
Building the application deployment
Running automated User-Interface (UI) tests

This method allows functional software to be rapidly promoted to non-Production environments for Customer inspection; or promoted directly to Production in cases where a feature or bug fix is immediately required.  For projects employing the Scrum process, this cycle repeats within each sprint until the Product Owner signifies all requirements have been met and the feature is Production-ready

Automated Testing

Automated testing requires close interaction between software developers and test engineers. The following process is employed within each development cycle (Scrum or Kanban):

Test engineers write test outline(s) for […]

  • Permalink Gallery

    Partnet Proudly Introduces SeAuto: Test Automation Framework

Partnet Proudly Introduces SeAuto: Test Automation Framework

Partnet Enters the Automated Testing Market with their Open Source Automated Testing Software, SeAuto
Create a robust, browser-based test automation framework with a single command.

SALT LAKE CITY – March 31, 2015

Partnet, Inc. announced today the worldwide release of SeAuto (http://se-auto.com), a robust, open source software testing tool that integrates Selenium’s browser automation with test frameworks. SeAuto combines the best in pre-built and configuration ease to automate testing on multiple browsers and operating systems, including Windows, Mac OS, and Linux to bring users to the next level in automated testing.

Partnet CEO, Don Brown is pleased with the offering and with the results that they’ve seen thus far.

“Our pre-built Selenium Auto Test Framework can save years of effort by avoiding framework development and costly ‘trial-and-error’ in selecting products and creating tests,” said Brown.

Doug Erickson, Director of Software Development at Partnet agrees, noting that “Partnet developed SeAuto to help our testers focus on creating tests, rather than running the tests.” Erickson added, “SeAuto makes it easy to include browser-based testing in a continuous integration (CI) pipeline and enables developers to run these tests before checking in code; that gives better, faster results. It’s our hope that others will find the same value in this effort to bridge the gap between their favorite test framework and Selenium.”
Customization and Integration
SeAuto was created for software testers looking for a pre-built, automated test tool that’s ready-to-go with little setup required (http://www.partnet.com/seauto). Partnet equipped SeAuto to be easily integrated with any CI and with the ability to test on any major browser and operating system.

“SeAuto takes the guesswork and experimentation time out of building a test automation framework, has lower maintenance overhead, and is far more robust than GUI-based, “point-and-click” automation tools,” […]

  • Permalink

    Part 3: Software Development Life Cycle — The Solution Design

Part 3: Software Development Life Cycle — The Solution Design

The Solution Design stage begins upon Customer and stakeholder approval of the System Requirements Review (SRR) and its associated artifacts. Solution Design is specific to Scrum projects only. Design is not typically required for Kanban process cycles involving Problem Reports and smaller “break-fix” tasks. Partnet’s Solution Design stage consists of two elements: functional design and technical design.

Functional Design: User stories form the basis for functional design and planning. User stories are short, textual statements corresponding to a specific feature or business need that the software solution must fulfill. Requirement Managers write user stories based on the approved solution requirements. During functional design, user-story reviews are convened with members of the Delivery Team to formally discuss each user story in detail and specify its acceptance criteria. All outstanding questions and assumptions are documented for follow-up with the Customer and other external stakeholders. User stories are then allocated into specific development tasks and subtasks that constitute the Product Backlog.

Technical Design: In parallel with user-story reviews, our development and engineering group prepares the technical design solution. Aspects of the technical design include:

Analysis of necessary changes to the general solution architecture.
Review new interfaces for third parties.
Protection of system security posture.
Identification of required hardware components, operating systems, and network architecture.
Research supporting software technologies and libraries.
Determination of necessary changes to the data model(s).

Partnet convenes an internal design review to collect and incorporate final feedback on the designed solution from Software Developers, Test Engineers, Configuration Managers, Project Managers, security specialists, and support staff. This review focuses on specific items affecting the solution design, such as:

Ensuring the design minimizes development and maintenance costs.
Identifying opportunities for business-user configuration (i.e., administrative utilities that allow the Customer to configure and manage the software without new […]

  • Permalink

    Part 2: Software Development Life Cycle — Incorporating New and Emerging Requirements

Part 2: Software Development Life Cycle — Incorporating New and Emerging Requirements

Partnet’s development team understands that requirements are volatile by nature and are inevitably subject to change during the course of development. New and emerging requirements often occur as the result of unforeseen constraints, capability gaps, user implications, or newly-identified stakeholders. Our Agile methodologies provide the flexibility required to quickly and responsibly react to such changes without putting other priorities at risk.

New and emerging requirements should be presented to the Partnet development team by the customer in the form of a new or updated functional specification. Our Requirement Managers follow industry best practices to thoroughly assess all new requirements. Careful business analysis is performed to:

Determine any impacts to the existing system.
Identify the best implementation approach.
Mitigate risk to the customer and end users.

Upon identification of a new requirement, Partnet will work with the customer to define business objectives and desired outcomes. Requirement Managers will carefully assess the new requirement against the deployed defined or existing solution to:

Identify capability gaps.
Assess impact to current functionality.
Identify affected stakeholders.
Identify transition requirements.
Document risks and constraints.

Partnet Requirement Managers will present this assessment in the System Requirements Review (SRR). The SRR will document the stated, unapproved requirements along with a recommended implementation approach. Also, the Partnet Project Manager will identify the estimated cost and time necessary to implement the new requirement. Once the additional cost and time are approved by the customer, Partnet will follow its standard requirement procedures elicit, refine, and formalize the solution requirements. Requirement Managers thoroughly maintain requirements traceability to ensure that substantive changes are documented and versioned as new requirements are incorporated into the designed solution.

Partnet expects the customer to be a key stakeholder in the gathering and approval of all requirements—including new and emerging requirements. Consequently, the customer […]

Google+