Iteration Workflow

Meeting Format

The recommended and optional meeting format is as follows.

Recommended Meetings

Two meetings should be standard for all development efforts.

• Iteration Planning Meeting – This is where the two week sprint is planned out and requirements are converted into units of work performed by developers. On large projects it is recommended that this meeting be split up into a technical planning meeting and a business planning meeting.
• Stand Up – This is a daily accounting of work that is to be done, work that has been completed and any barriers to the current development tasks. The engineering team should shoot for 15 minutes maximum for this meeting. If it is a preference of the Engineering Technical Lead this meeting can be held virtually with the help of Jira or other task management software and processes.

Additional Meetings

The following meetings can be folded into the Iteration Planning Meeting or optionally held as a separate meeting as needed.

• Iteration Retrospective – Meeting to review and improve on the previous iteration. This may include code or process reviews. Ideas for improvement with the implementation of the SDLC should be communicated to the Engineering Leadership Team for consideration.
• Release Planning Meeting – Determine the state of the project in relation to a proposed artifact release to the business. May include test case readiness and/or other reviews. This meeting will likely include the Release Management Engineer.
• Technical Design Review –These meetings may focus on end user interaction or may dive into more technical code review topics. See the checklist at 12.2 for a schedule of required design reviews. Also see 12.4 for the actual design review checklist.

Iteration 0 (Pre-development)

Once a project has been approved and the engineering team has been assembled the requirements of the system are gathered and documented. This documentation process is performed by the engineering team in conjunction with the business owners. Various tools should be utilized including the following:

• Rapid Prototyping - Create a visual representation of the project proposal that the business owner can see and provide feedback on. This type of communication medium has proven to be more successful than traditional design methodologies as it engages the business owners and helps to remove misunderstandings about the use of the application artifacts that are to be created. It also provides a platform that anticipates and welcomes change as it happens over the course of the iteration.
• Contextual Inquiry - This is a specific set of techniques used in conjunction with visual observation of the user process. Giving the engineering team the opportunity to observe the users current process allows for a better understanding of the requirements and also encourages innovation.
• Traditional Requirements Gathering – More traditional methods may also be used but are encouraged only as a supplement to the above more effective methods.

Requirements should be a high level and non-technical representation of the core elements of the requested system. They should not contain specific technical details unless they are business related and/or appropriate to the project.

Once the requirements have been gathered they are placed inside the requirements management system (Integrity) by the business analyst.

Iteration Process

The engineering team should organize all changes to the codebase using an iterative process. The beginning of an iteration should be executed against a stable trunk. All changes to the iteration and their respective tests should result in a codebase that has been brought back to a stable and potentially releasable state.

Iteration Testing Process

The Software Engineer and Quality Engineer should work together to produce the following test types as part of the iteration process.

• Unit Tests – Tests that do not have any external dependencies outside the class that is under test.
• Integration Tests – Tests that involve combining different modules of the system and testing them as a group.
• System Tests – Tests that involve determining the compliance of a system to specific requirements as a whole. This can be used to validate an external dependency of the system under development
• Functional Tests – Black Box or end user simulation testing.

Other specific tests may be designed and executed as the need arises.

At the completion of the iteration the only additional QA requirement should be a validation.

Iteration Artifact Generation

The following artifacts are generated as part of the iteration process.

• Requirements – Placed in the requirements repository.
• Source Code – Checked in to SVN.
• Test Cases – Compiled and placed in the requirements repository.
• Technical Documentation – Checked into SVN and published to the project site.
• Installation Instructions – Published to Nexus.
• End User Documentation – This is handled by the Technical Analysts.
• Release Artifacts – Published to Nexus

Iteration Diagram

Diagram that shows a typical iteration workflow of an engineering team.

Project Checkpoint Events

During the course of the project the following checkpoints are required to be met.

• Project Kickoff and SDLC Training - This meeting is to ensure the project team has an understanding of the project goals and is aware of the SDLC process.
• Initial Design Review - This meeting is to review the Iteration 0 findings and approve the start of development. Create Initial Design Review
• Mid Design Review - This meeting is to review the progress of the project and provide feedback and direction. Create Mid Design Review
• Critical Design Review - This meeting is to approve the go live of the application into a production environment.Create Critical Design Review

Project Build Standards

A definition of the types of required and optional builds and the standard tools and process around configuring the builds.

Build Tool Standards

The standard platform for scripting automated project builds is Maven (see tools). All builds should be reproducible and should never rely on configuration on an engineer's personal machine.

The standard build server is Jenkins (see tools). Each project is entitled to the usage of a dedicated build server during the active development phase of the project.

Source Repository Standard

All projects should be located in the https://subversion.co.ihc.com/ repository. To create a new repository send an email request to the Unix Middle Tier team (WEB). They also handle all rights requests to the repository. When choosing a name for your repository try to avoid specific brands or names as they tend to change during the development phase.

Maven Naming Standard

The standard maven groupId naming convention is com.skyviewsoftware. .* This naming convention should be used on all projects and modules. There is not a standard artifactId convention however it is recommended that the name of the project or any other branding not be specifically referenced as they frequently change.

Nexus Artifacts

Situations where it is required to alter or fork a public project should result in the creation of a new groupId to reflect the change to Sky View Software maintenance of the code. For example patching the xstream project should include changing the groupId to com.skyviewsoftware.*.

Required Standard Builds

There are three types of builds that are required for each active project.

Continuous Integration Build

The first is a continuous integration (CI) build. This build should be executed on each change to the project source code. The build is executed by the project Jenkins build server against the main trunk of source code and is responsible for executing any unit tests that are attached to the project. The goal of this build is to provide rapid feedback to the project engineering team and alert them if there are any test failures. Typically this alert is an email to the necessary individuals but it can also include any communication that notifies the team in a timely fashion. The CI build and accompanying unit tests should not take an exceptionally long time to complete as this would defeat the purpose of the continuous feedback loop that it creates. An average project might take a maximum of 15 minutes to complete a CI build.

Nightly Build

The second standard project build is a nightly build. This build is also executed by the projects Jenkins server and is a scheduled build that is run after hours against the main trunk of source code. This build is responsible for executing unit tests, integration tests, system tests, functional tests and any other long running tests that are contained in the project. This build can include complex setup processes including:

• Creating virtual environments and deploying code to those environments.
• Controlling virtual client nodes to simulate user interaction.
• Executing complex load tests to determine system response time.

The build can be distributed across many different Jenkins nodes and could take a significant amount of time. The goal of the nightly build is to provide a deeper level of feedback to the engineering team as to the current stability of the project source.

Release Build

A project team should configure a build that automates the steps needed to perform a release. This build should perform the following tasks.

• Clean checkout of code from source control trunk.
• Run all automation tests with Test Case integration for documentation purposes.
• Tag the source code with the release version.
• Publish the artifacts to the Nexus repository.
• Update the pom to start the next development cycle.

The automation of these steps will ensure a consistent handoff process for release management.

Optional Builds

Depending on the project size there are various other build types that the engineering team may configure.

Load/Stress Test Build

Because of the long running nature of some stress/load tests it may be preferable to create a separate job for these or other long running tests.

System Test Build

A special build test may be necessary to execute tests against dependent systems as a validation that required functionality has not been changed by the remote system without the project teams knowledge.

Standard Build Diagram