Policy Guides

Requirements

Applications are born to solve problems. The moment of conception occurs when a problem is expressed as a request--"Is it possible to have this do that?"--and it becomes a concept that can be weighed and evaluated against specific criteria.

In the first stage of the application life cycle, requests become authorized, prioritized IT requirements. Policies that define how requirements are gathered, aligned with the organization's business objectives, prioritized, and authorized constitute the first important area of IT governance. Requirements policies are critical to the success of the IT organization and the applications it supports.

Introduction to Requirements (PDF)

The Teamstudio Policy Guidebook lays out four policies within the Requirements phase:

• Request Management (REQ 10)

  Request Management is the process that determines which products, applications, and projects get the green light for development. It evaluates each on how well it supports key corporate objectives, such as business alignment, efficiency and effectiveness, risk management, and regulatory compliance. An effective Request Management Policy ensures that products, applications, and projects are prioritized and funded based on their ultimate value to the organization.

  The key components of Request Management as defined in Teamstudio's Policy Guide include defining the business strategy; taking an inventory of all requests across the organization; evaluating a request's alignment with strategic objectives; assessing impacts and likelihood of success; and prioritizing requests.

  REQ 10 - Request Management

• Requirements Gathering (REQ 20)

  Most software defects can be traced back to the requirements-gathering stage. Implementing a Requirements Gathering policy that accurately defines what the customer needs to address a particular business issue can therefore have an enormous financial impact when calculated across the life of an application.

  Teamstudio's Policy Guide identifies three key steps to the requirements-gathering process:

  • Identifying the key stakeholders;
  • establishing the aims of the process; and,
  • collecting the requirements.

  REQ 20 - Requirements Gathering

• Requirements Alignment (REQ 30)

  The policy governing Requirements Alignment ensures that each requirement is properly aligned with the application's stated business objectives. This is a collaborative process through which the key stakeholders come to a final agreement on the project's requirements. Requirements are validated when they are shown to conform with the application's Statement of Intent; the application's specific business objective; the SMART (Specific, Measurable, Agreed, Realistic, Time-bounded) principle; and the "what not how" rule.

  REQ 30 - Requirements Alignment

• Requirements Prioritization (REQ 40)

  After the initial requirements are validated they must be prioritized. The policy on Requirements Prioritization outlines a collaborative process for rating each requirement based on the trade-offs between business needs and development costs each presents. The final result of this process is a project plan that groups the requirements into one or more phases.

  The ultimate purpose of the Requirements Prioritization policy is to ensure that the requirements deliver the maximum business value within the scope of the project's schedule and budget.

  REQ 40 - Requirements Prioritization

Design

The design phase of the application lifecycle begins once the question of "what?" has been answered and attention has turned to the question of "how?" The Design section of the Teamstudio Policy Guide provides a road map for taking requirements through the design phase and into development.

Introduction to Design (PDF)

The policies within this section are:

• Design Specification (DES 10)

  The application's eventual form begins to emerge during the Design Specification phase. Output from the Requirements phase guides the task of mapping out a precise design specification. Teamstudio's Design Specification policy helps to ensure that a project's requirements and constraints are well-established in advance of development, improving the project's likelihood of success and reducing the risk that the finished product will miss the mark in some way.

  The Design Specification should incorporate an overview of the project; its architecture, functional specifications, and detailed component design; and the constraints the project may need to anticipate such as performance and reliability requirements.

  DES 10 - Design Specifications

• Test Planning (DES 20)

  Planning appropriate tests helps ensure that development stays focused on what's important and takes special care to avoid errors in the areas of highest risk. Driven by the functional and non-functional specifications, test design often sheds light on the accuracy of requirements and the application's architecture.

  The Test Planning policy outlines a process for developing appropriate tests; highlights factors to consider while developing the tests; and describes several types of tests and the scenarios for which they are best suited.

  DES 20 - Test Planning

• Design Authorization (DES 30)

  Design authorization presents a final opportunity to catch and correct any flawed assumptions regarding the project's design, cost, anticipated return on investment, architecture, resourcing implications, and standards compliance. Needless to say, it is far less costly to redesign functionality at this point in the application lifecycle than it is further down the road.

  The Design Authorization policy recommends several key deliverables be part of the final review:

  • A brief overview of the application's goals and purposes
  • The application's functional specifications
  • The application's non-functional specifications or "constraints" that will impact system design
  • Acceptance testing and functional testing plans
  • Budgeting and scheduling information

  DES 30 - Design Authorization

Development

Approvals in place, blueprint in hand, we're finally at the point in the application lifecycle where we actually build something. The development phase brings to life the solution that was carefully designed and planned to address a problem, meet a business requirement, or otherwise answer a defined need.

Sensible development policies ensure that applications are built efficiently and built well. They guarantee that development resources are prudently allocated based on project priorities. And they serve as an IT governance roadmap that takes the project from square one to the threshold of production.

Introduction to Development (PDF)

• Coding Practices (DEV 10)

  Standardized coding practices ensure that an application's code--and the original developer's intent--is easily understood by every developer who must work with it. This is especially important for Notes development, which has a habit of fermenting a mix of coding conventions as an application matures and grows more complex. Good, clean, documented coding practices discourage the use of non-standard tools and habits and make it easier to fix and maintain an application. Ultimately, the coding standards themselves are less important than the degree to which they're observed.

  The Coding Practices policy guide will help development teams define and follow a set of practices and conventions that will improve the quality and efficiency of application development and maintenance. The guide provides an overview of the conventions, practices, and strategies that should be part of every development project.

  DEV 10 - Coding Practices

• Source Code Management (DEV 20)

  By their very nature, Notes applications are prone to change--continually adapting, expanding, and evolving to meet new requirements. That characteristic makes source code management (SCM) a critical part of application development.

  As described in the policy guide, proper source code management consists of a set of policies that facilitate application development while preventing inadvertent changes. The topics these policies cover include access control; source code protection through check-in/check-out procedures; and change reporting.

  DEV 20 - Source Code Management

• Version Management (DEV 30)

  A strong version management policy will take on two of the biggest challenges in Notes development: how to properly manage concurrent development, and how to promote design changes into other environments such as test or production. The Teamstudio Policy Guide describes a process for concurrent development that employs branches, version numbers, build processes, and server directory structures.

  Proper version management brings order and clarity to the development effort, making it easy to ensure that everyone is working on the correct versions of applications and that they know where to go to find previous versions.

  DEV 30 - Version Management

• Unit Testing (DEV 40)

  It's an unfortunate paradox that, as applications become more complex and the time and effort required to test them grows, the amount of time dedicated to testing frequently doesn't grow at all. Unit testing provides a way to monitor the health of the application as a whole through regular, automatic tests of individual units of code.

  Establishing a unit testing policy is a big step toward producing better, more easily reused code. By requiring that the units be defined, a unit testing policy promotes good coding habits. Unit testing also reveals bugs early in the development process--when they are easier and less costly to fix than they would be at the QA stage.

  DEV 40 - Unit Testing

Testing

Testing determines whether an application is ready for prime time. Does it work as promised? Does it meet the requirements that guided its development? Test policies check to confirm that the application delivers the requested functionality and is ready to be released into production.

The Testing policy guide describes two types of testing designed to verify that the application works as specified in the original requirements and that the application owner or and/or appropriate subject matter experts confirm that it does so.

Introduction to Test (PDF)

• Application Testing (TES 10)

  All software has bugs. The goal of application testing is to ensure that the number and severity of those bugs falls within acceptable limits.

  The Application Testing policy outlines the process for measuring the quality of developed applications, assessing such factors as completeness, correctness of the functionality, security, reliability, efficiency, and maintainability. The policy defines types of testing; test cases; testing methods; areas to test; and the testing environment.

  TES 10 - Application Testing

• User Acceptance Testing (TES 20)

  User acceptance testing (UAT) is the most critical level of testing because it is the last opportunity to spot problems before the application is released into production. User acceptance testing validates that the application meets the stated business need and the customer/end user's expectations as expressed in the specification. Test cases are "black box" type tests that reveal nothing about the application's inner workings, only whether it works or not. The UAT acceptance criteria should be defined during the design phase.

  If the application designers, developers, and testers have done their job, the UAT phase should be relatively painless. It concludes with the client signing off on the application.

  TES 20 - User Acceptance Testing

Production

After a project has moved through the application lifecycle and the end product is released to the user community, the principles of "just enough governance" really come into play. For all the thought and testing that went into its development, applications newly in production are vulnerable to the unpredictable influences of "the real world." Policies that protect and monitor the application, manage user interaction, and govern how it coexists within the Domino infrastructure are vital to the long-term health of the application.

Introduction to Production (PDF)

Policies that promote a healthy production environment for typical Domino installations are:

• Application Delivery (PRO 10)

  One of the most error-prone stages of the application lifecycle occurs when the application is deployed to the end user community. Failure to define and adhere to a comprehensive deployment process can allow an unstable application into production and trigger a flood of support calls.

  An Application Delivery policy focuses the development and administration teams' efforts to deliver a stable application each time a new release is built by employing a repeatable, documented, potentially automated and effective build process.

  PRO 10 - Application Delivery

• Security Management (PRO 20)

  Recent highly-publicized failures by IT organizations to protect sensitive customer data have highlighted the importance of data security. The Security Management policy guide provides guidelines for protecting the system from threats and responding when breaches occur. The policy identifies the six areas that require strict security management policies with measurable criteria: physical security, network security, operating system security, Domino server security, application security, and document security.

  PRO 20 - Security Management

• User Management (PRO 30)

  The User Management policy guide outlines a framework for managing how different types of users are allowed to interact with an application. It provides recommendations for managing user access throughout the three phases of the "user lifecycle": User Creation, User Management, and User Account Deletion.

  PRO 30 - User Management

• Application Management and Monitoring (PRO 40)

  An effective Application and Usage Management policy prevents applications and databases from spreading and growing beyond control. It documents a clear process by which applications are requested and deployed. The Application and Usage Management policy also identifies the data points that should be monitored to ensure applications are functioning properly--and how to flag those that aren't for replacement, overhauling, or retirement.

  PRO 40 - Application and Usage Management

• Data Management (PRO 50)

  Your company's data, especially its customer data, is its most valuable asset (aside from you, of course). The consequences of data corruption can be profound and far-reaching, so a conscientious approach to data management is mission-critical.

  Teamstudio's Policy Guide for Data Management prescribes measures that balance prevention, detection, and monitoring to safeguard data integrity in the Lotus Domino environment.

  PRO 50 - Data Management

• Agent Management (PRO 60)

  Agents enhance the functionality of Notes applications, but, through neglect and sloppy management, they can effectively become "double agents" that undermine an application's performance, bog down server resources, and jeopardize system security. An active Agent Management policy minimizes the risks to the Notes environment by ensuring all agents are tested for programmatic stability, scheduled to minimize server drag, and analyzed for potential security risks.

  PRO 60 - Agent Management

• Infrastructure Management (PRO 70)

  The Infrastructure Management policy is designed to minimize the unhealthy consequences of a poorly-defined, poorly-managed architecture. It outlines an architecture scheme that is easily analyzed for anomalies and is conducive to developer productivity. It also provides guidelines for how to set the server documents in the Domino directory to allow creation of databases, templates, and replicas on any of the servers in the domain.

  PRO 70 - Infrastructure Management

• Domino Upgrades (PRO 80)

  Updating your IBM Lotus Notes Domino applications can be a daunting task. The Domino Upgrades policy guide assists the planning and execution of an upgrade by defining the steps involved, including the creation of a test environment, review of the infrastructure and Notes application usage, and the upgrade implementation.

  PRO 80 - Domino Upgrades