Designing an ALM Process

Application management processes are as unique as the application being managed. However, there are certain features that a complete ALM process should have. Specifically, decisions governing requirements, versioning, testing, and change management need to be documented and communicated to the organization. The roles and responsibilities associated with each phase of the process will vary based on the size and culture of the organization.

In this section, we will describe general ALM steps and discuss the pros and cons of different approaches to designing a process that fits an organization and its applications.

Establishing Standards

Prior to beginning development, it is important to establish a set of expectations for each part of the organization involved. A common way to do this is to create a flowchart for the development process. Figure 14-1 shows an example of how such a process might be structured.

Figure 14-1. Sample ALM process flow

We will describe each of these steps in more detail in the next section. For now, notice that the steps in the application lifecycle form a cycle. This is a common property of any realistic ALM process. It is not reasonable to expect that an application can be created and deployed and never need to be updated in the future. Even if an application could be created that contained no bugs and satisfied its requirements perfectly, the business would eventually undergo changes that would require it to be updated.

The design of an effective ALM process will depend on the habits and needs of the organization, but there are some common types of processes that have been used widely over time.

The waterfall approach is the oldest of the processes and dates back to the 1960s or even earlier. In a waterfall process, a software development project is divided into phases such as Requirements, Design, Coding, Testing, and Deployment. The entire application is created and perfected in a single initial delivery. For this reason, the waterfall is often referred to as the “Big Bang” approach. This approach works well for very small applications but it does not scale well. Generally, larger applications cannot have complete requirements prior to the beginning of design. The application's design may need to adjust based on information gained during the coding phase. In general, the problem with the waterfall approach is that it does not allow for the flexibility needed to learn and adapt as a project progresses.

To overcome the shortcomings of the waterfall approach, the iterative waterfall was invented. The iterative waterfall uses the same phases as the waterfall approach but the project is planned as a series of incremental releases instead of one giant Big Bang. For example, when building a multi-tiered application, it may make sense to build one tier of the application in each iteration. Alternatively, it may be more appropriate to design the iterations as to complete a set of distinct use cases with each iteration. Once all of the iterations are complete, the application is fully implemented. The advantage of this approach is to allow lessons learned in one iteration to be applied to later iterations.

The most recent type of ALM methodology to be introduced is the Agile philosophy. The Agile movement was started in 2001 and is based on a set of principles that can be found at http://www.agilemanifesto.org. The idea of Agile development is to make the development of software more responsive to the end user by creating more opportunities to interact with and get feedback from the customer. There are many other concepts and terms that have been created around Agile projects, such as backlogs, stories, sprints, burn-down charts, pair-programming, and “extreme” programming. You can find several good books and tools available for use with Agile projects. For example, for guidance relevant to .NET development, take a look at Pro Agile .NET Development with SCRUM (Apress, 2011) by Jerrel Blankenship.

The most important difference in these approaches is the frequency of their development cycles and the amount of feedback that the different phases and cycles can get from each other. Whereas a waterfall project might consist of a single cycle lasting 2–3 years, an iterative waterfall plan for the same project could consist of several cycles lasting 2–3 months each. With Agile projects, cycles (known as sprints) are often as short as 2–3 weeks.

Phases of the ALM Process

Regardless of the style of ALM process adopted by the organization, there are certain steps that will always need to occur. In order to establish effective governance, these steps, and the deliverables from each, should be well defined and understood by everyone involved.

A project's deliverables will generally include more than just deliverable executables. They will include requirements and design documentation, work items, release and testing plans, along with the project's source code. Refer to Figure 14-1 as we define the steps of a typical ALM process.

Planning Phase

In the planning phase, the governance team will be directly involved in defining what is to be built and what the application needs to do.

Project Initiation

Project initiation is the step where the organization decides that a new solution is required. This step often involves creating a business case to justify the expense of creating and maintaining such a solution. Once the business has signed off on the project, a team must be established to begin creating the plan for development.

Requirements Gathering

Requirements are gathered from the business team or end users to determine what features are needed in the application. This may include business processes, data definitions, simple user interface prototypes, and so on. These requirements are usually captured in a set of documents that are reviewed and approved by the project's sponsor.

One approach to managing requirements is to enter each requirement into a tool such as Microsoft's Team Foundation Server (TFS). A requirement then becomes a distinct data element that can be associated with other items such as source code, bug reports and development work items. This allows each requirement to be connected to the entire set of related activities in the project. This is known as requirement traceability and can significantly enhance a project’s manageability.

Solution Design

Also known as solution architecture, the design phase translates the requirements into a set of application components that need to be built or modified. The components should be assigned to features and solution packages in SharePoint. Each of the development tasks should be broken out and given estimates. These tasks form a Work Breakdown Structure (WBS) for the functionality to be implemented.

Release Planning

Once the solution has been designed and the WBS is complete, the tasks can be broken down into releases. A release represents a piece of functionality that will be released to the end users. The release plan defines the order and contents of each release.

Development Phase

The development phase occurs primarily within the IT development groups. In this phase the application is created or updated in a series of iterations, or sprints. Once the release is ready it is delivered to the production phase.

Solution Development

The application development teams examine the release plan and the development tasks and create a plan for organizing the functionality into one or more iterations of internal deliverables. As application components are completed, they are checked in to the source control system for testing.

Application Builds

Building an application refers to the process of compiling the source code and other project components into a deployable set of files. In a SharePoint environment, this usually involves compiling source code into a set of executable DLLs and packaging them with other artifacts into a set of solution package (WSP) files.

Performing application builds consistently is critical to ensuring that the process is error-free and repeatable. Modern development systems, such as TFS, often contain features that allow for automated builds and deployments to occur on a regular basis. For example, each night at a certain time, the source control system can be accessed to retrieve the most current versions of each source file. The automated process will then compile and package these components into WSP files. These packages can then be automatically deployed to a central SharePoint farm within the development group for testing.

Functional Testing

Functional testing is performed to ensure that the application is performing as expected by the developers. There are two levels of functional testing that should be addressed within the development group: unit testing and integration testing.

Unit testing is a process where a developer creates both the code to be tested and a set of code designed to exercise that code. This testing is done at the component level and is intended to ensure that the component works as expected. By creating one set of code to test another, these tests can easily be rerun whenever the code changes. If a test that used to work fails, the developer knows that they need to examine the situation being tested for errors. Either the code changes are incorrect or the unit test needs to be updated. Rerunning unit tests each time the system is built is another good use for automation. A developer who checks in a set of code changes one day could find an e-mail waiting for them the next morning detailing a set of unit tests that have failed due to their changes.

One popular technique for unit testing is called Test-Driven Development (TDD). Advocates of TDD suggest that the unit test code for a component should be written before the component itself. This essentially gives the developer an executable set of requirements to write against. There are a number of good tools and resources available on test-driven development including Test-Driven Development by Example (Addison-Wesley, 2003) by Kent Beck.

Once component-level testing is complete, the development team should perform integration testing. Integration testing involves loading the completed solution onto a central SharePoint server farm to ensure that all of the components work together. These tests can sometimes be automated but some may need to be run by hand.

Production Phase

The production phase is where the rubber meets the road (or the application meets the end users, anyway): the application goes through its final testing and deployment to production. This phase provides the feedback needed to guide and plan the future releases of the product.

Acceptance Testing

Acceptance testing is where the solution packages delivered from development are tested independently to ensure that they meet requirements. This testing is often performed by a separate Quality Assurance (QA) department. Acceptance testing should include a well-documented plan for what is to be tested and by whom. Regression testing should also be performed to ensure that no functionality has been lost from previous releases unintentionally.

See “Testing Environments” later in this chapter for a discussion of common SharePoint farm configurations used for acceptance testing.

Deployment

After acceptance testing is completed, the application changes are deployed to production. This process can be quite complex if updates are being deployed for an existing application.

The deployment procedure is just as important as any other part of the application and needs to be designed, tested, and documented just as carefully. A failed SharePoint deployment has the potential to corrupt data within the SharePoint farm. Therefore, the first step in any deployment plan should read “Back up all configuration and content databases in the server farm!”

Feedback

Perhaps the most important step in providing maximum value from an application in SharePoint is the collection of feedback from end users. This provides the governance team with the information needed to prioritize changes and plan future releases. Here are some common techniques for obtaining feedback from end users:

• Help Desk tickets
• Bug reports
• Feature requests
• System outage reports

Some additional ideas for collecting feedback take advantage of SharePoint's collaboration functionality:

• Add a “Send Us Your Feedback” link to the master page for your site, making it available on all pages.
• Turn on SharePoint's content rating feature and enable content rating for lists and libraries on your site.
• Use SharePoint's social features such as Social Tagging to collect information about how users access and organize information.
• Use features like Wikis and Discussion Groups to exchange ideas and tips with end users.