Custom Software Development Lifecycle Management

At the outset of any software development initiative it is important to define how the project will be managed. One of the significant benefits The Integrated Solution Group (ISG) provides for its clients is substantial experience using defined management processes for developing software solutions. Rather than take on the additional burden of selecting and implementing a project management process themselves, or incurring the substantial business risks associated with an improvised process (or no process), ISG’s clients can participate in ISG’s process with the confidence that it is an industry standard methodology being executed by experienced professionals.

Reasons for Using Application Lifecycle Management

Developing a reliable software solution within a predictable timeframe using a specific set of resources requires a proven approach. Both the product and the work required to implement it are complex. The effectiveness of the product and the process can both be made more reliable by using a defined set of principles, models, disciplines, concepts, guidelines and practices that have been demonstrated to work.

In addition to providing a framework in which to manage the process, a lifecycle methodology also reduces business risk by providing a method of improving the likelihood that all necessary business requirements are identified and addressed appropriately in the application. Business risk is further reduced through the use of a defined management process through its provision of a consistent mechanism for estimating the scope and complexity of specific development tasks.

Complete application lifecycle management systems also provide a mechanism for reliably maintaining, modifying, and improving the software solution as the enterprise grows and its business processes change and evolve. A key portion of managing this evolution is creating business requirements documentation that clearly defines the business processes the application must support. As the business requirements change and are documented, the application can change accordingly. Software applications that are designed with evolution and expansion in mind are substantially more valuable to the enterprise than those that are not well prepared to evolve with the business.

It is the responsiveness to the cyclical nature of software solutions that distinguishes application lifecycle management methodologies from the more traditional view of the software development lifecycle (SDLC). For historical reasons, the general concept of the SDLC is usually conflated with the traditional waterfall methodologies associated with the origination of SDLC concept.

A major disadvantage of the traditional SDLC approach is that it ends with system deployment; the methodology does not consider what happens after the application goes into production, nor is it designed to address the reality of business requirements that change in response to changing markets. By ending the development lifecycle with the deployment of an application the methodology fails to address the important transition in business requirements between the initial release of the solution and subsequent revisions necessary to address accommodate increasing business process maturity and changing market requirements.

Custom software development lifecycle management extends the useful life of software while reducing the risk associated with developing it.

Legacy methodologies, particularly those that are waterfall derivatives, have proven themselves to be unsuitable to most software projects. This is particularly true of projects where business requirements are poorly understood, largely undocumented, or subject to frequent changes. There are two significant business risks associated with software development projects undertaken with risky methodologies:

1) the application, when implemented, will not address key business requirements;

2) modifying the completed application to meet unfulfilled business requirements will require substantially more time and money.

Why ISG uses the Microsoft Solutions Framework for Software Development

Use of the Microsoft Solutions Framework (MSF) provides ISG and its clients with one principal strategic advantage: Microsoft’s vast resources are behind the development and refinement of the framework. Because of that, MSF has gained widespread adoption, thereby providing the additional benefit of the support of a large user community that contributes additional experience, expertise, and resources to the effectiveness of the process.

In addition to using Microsoft technologies to implement software solutions, ISG also uses Microsoft technologies to manage the software lifecycle process; Microsoft Enterprise Project Management (EPM) is ISG’s system for creating project plans and tracking time, tasks, issues and risks. The Microsoft SharePoint web sites that form a part of the EPM solution are used to store and distribute project documentation. MSF is implemented using these tools and ISG makes use of a variety of resources provided by Microsoft.

Overview of the MSF in Custom Software Development

The MSF process model is based on phases and milestones. The closure of each phase is represented by a set of approved deliverables. The tangible outputs of each phase form the inputs of the next phase and are necessary precursors to the successful execution of the subsequent phase.

Envisioning

The initial phase of the process model defines the application at the highest level of the business solution. The fundamental objectives are defined and key assumptions regarding the requirements are documented.

The overall scope of the project is also documented, both from the standpoint of the enterprise business process and with respect to the development of the application. Scope definition addresses not only the business processes the solution will address, but also the timeline and resource constraints within which the project will be executed.

It is also during the envisioning phase that key assumptions regarding the solution’s functionality are identified and assessed with respect to their impact on the whole solution. These assumptions are the principle project guidance from the enterprise leadership and it is correspondingly essential that they are documented and understood clearly at the outset of the project.

Planning

Planning is the key to a software development process that is reliable and repeatable. As various industry standards indicate, it is the execution of a formal requirements process within the context of a lifecycle methodology that separates successful software development initiatives from unreliable seat-of-the-pants efforts.

ISG follows a requirements definition management (RDM) process that uses defined activities and documentation types in a consistent process. In the MSF the requirements definition management process is conducted as part of the planning phase, as part of the requirements analysis and functional specification sub-phase.

Requirements definition

Quality business requirements, the kind that produce effective software solutions, have a number of essential characteristics. In each case they are:

Complete – No information necessary to build an effective solution should be omitted from the documented requirements.

Consistent – Individual requirements should not conflict with other requirements or within themselves.

Correct – The requirements should be accurate to as to the needs of the stakeholders in the solution and approved by them.

Feasible – Resource (financial, timeline, etc.) constraints should be considered in defining and prioritizing requirements.

Modifiable – Requirements, and their documents, should be easily changeable to reflect business conditions that may change rapidly.

Necessary – The functionality specified must be useful and needed.

Prioritized – The criticality of individual requirements should be classified based on their importance to business operations.

Traceable – Each requirement should be uniquely identified so it can be tied to the functionality built to provide the solution (e.g., in source code) and tracked in a change management process.

Unambiguous – The definition of a requirement should have one possible meaning.

Verifiable – Each requirement should provide sufficient empirical information for a set of test cases to be written to validate all the required functionality.

The process of producing documented requirements that meet these criteria consist of four steps.

Elicitation

In many enterprises, customers believe there is a problem with a particular system or process, but they have difficulty communicating requirements to engineering. Elicitation is the skill of working collaboratively with customer representatives to uncover their actual business needs and agree on the vision and goals of proposed projects. Since the people who will interact with the proposed system exist in various departments throughout the enterprise, the elicitation process includes early identification of the different classes of users, such as expert or novice, and their characteristics.

ISG conducts a standard set of elicitation activities, including of interviews and focus groups, to produce documentation that forms the inputs to the analysis and specification phase. The documents used in this and other phases of the requirements definition process conform to the Unified Modeling Language 2.0 specification and include use case, interaction, and activity diagrams.

Analysis and Specification

Ambiguity is the root cause of most issues surrounding understanding and documenting requirements. The more time an enterprise spends ensuring that requirements are defined at an appropriate level of granularity, the more effective the end result. As a general rule, functional requirements-those that describe what the system and software must do-should be separated from non-functional requirements-which are typically quality attributes specified by the business, such as reliable, secure and scalable.

As a best practice, each requirement should be ‘discretely testable.’ Since stakeholders may not be able to think about all of the scenarios the system must accommodate today and in the future, it is helpful to review requirements from a test perspective as a proactive way to gain more complete requirements. In cases where there is still uncertainty, many organizations elect to build system prototypes to test desired software behavior against known requirements.

Once appropriately defined, requirements should receive a unique label or tag. This is essential to assisting traceability as requirements are managed throughout the project lifecycle (also see Step 4: Management). Labels are also important as they provide a unique tag to which associated artifacts may be linked.

Validation

Validation is critical to surfacing disparities in stakeholder perspectives and hidden assumptions. Product champions often play a significant role here by helping to surface issues and keep stakeholders and the software development team focused on what is important and feasible as they resolve conflicting requirements.

The goal is to get agreement and prioritization of requirements with sign-off on related use-cases and prototypes. Since requirements can be approved without full recognition of what has been committed, it is vital during this phase that scope, system limitations, external boundaries and interfaces are clear and considered achievable in the minds of all stakeholders.

Management

Before executing on requirements, software development teams must first estimate the overall effort required for successful project completion. The success of this exercise is highly dependent on the quality of requirements specified for the project.

Requirements-based estimation helps enterprises realistically assess costs, duration and risks for software initiatives early in the software delivery process, as well as calibrate and re-evaluate initial estimations if requirements change. Estimation and planning can also optimize requirements prioritization, and can be an additional collaborative step with stakeholders during the validation process.

Other planning steps

The ISG/MSF ALM methodology progresses through a number of other phases and sub-phases as the software application moves from concept to development. The planning phase itself has a number of other sub-phases, described briefly below:

Test Plan

The test plan, the origin of which lies in the testable aspects of the business requirements, is begun as early as possible in the planning phase. As the data elements of the application are defined in the data dictionary,

Logistics Plan (deployment and implementation)

Having made a considerable investment in the development of the software solution, the enterprise should safeguard its investment by developing a detailed plan for deployment of the application in its information technology environment. There are frequently additional business processes associated with such deployments, particularly in organizations that are complex or geographically diverse.

User Education Plan

Even the best applications are of limited value if stakeholders do not know how to use them effectively. This means more than understanding the user interface; it also means understanding how the new system affects business processes. In large or geographically diverse enterprises a user education plan which utilizes a train-the-trainer approach to education.

Product and Program Management Plans

Enterprise applications commonly have regular maintenance and performance tuning activities associated with them, as well as administrative tasks. The product management plan addresses these things. The program management plan addresses the next iteration of the application lifecycle.

Further application lifecycle phases

The subsequent application lifecycle management phases are discussed in more detail in a separate document. That document also includes a fuller description of the milestones and responsibilities associated with the conclusion of each phase.

The following is a brief summary of the phases themselves:

Development

Once the technical design and development plan have been completed and communicated to the developers, the programming and testing tasks can be executed. Reliable software is developed by dividing it into components and further dividing it into objects that have data elements and can respond to or trigger events (for example, a user object is created when a user logs into a system, it contains a unique identifier for the user and information about what information in the system they are allowed to access. When the user attempts to open a dialog box containing financial information, the component managing that information checks the credentials in the user object to see if they have the appropriate rights and the user object itself triggers the access logging component, passing it the unique user identifier and the identity of the module being accessed). A variety of software development standards help ensure the application is reliable and can be maintained efficiently.

As components are developed they are tested according to the test plan developed during the planning phase. Component testing focuses on the specific behavior of individual portions of the application.

Integration (or system) testing focuses on ensuring the components work properly together. The emphasis in this portion of testing is in validating that all the pieces work correctly together to fulfill the business requirements for the application.

Release Candidate

During the release candidate phase end users, the stakeholders in the enterprise have the opportunity to evaluate the application against the requirements. This is commonly known as a beta test deployment. Release candidates are often evaluated as part of a pilot implementation.

Stabilizing

Bugs and gaps in the business requirements are addressed in the stabilization phase if the release candidate has exposure in these areas.

Deployment

Deployment is the point where the application gets into the hands of users for production work. The execution of deployment is often complex, particularly in environments where the application needs to be slip streamed in existing business processes or where deployment represents a point at which business processes change. Legacy data also needs to be considered. To adequately address these considerations, a deployment plan is essential.