Friday, November 05, 2004

The Six Best Practices of a Software Engineer

Six best practices framework

The six best practices presented below are the result of Rational’s learning experiences in the software engineering field. They represent focus areas that help understand how to master the complexities of software engineering:

  1. Develop iteratively. To effectively mitigate risks, teams should develop software incrementally, in an iterative fashion. Each iteration results in an executable release. Architecture is validated and baselined in early iterations. The assessment should explore needs to gain control of risks and plans, for which a solution is to introduce iterative development.
  2. Manage requirements. Requirements will change along the way, so teams should use methods that allow them to effectively facilitate and communicate changing requirements to your stakeholders and maintain agreement with the customer. The assessment should explore things such as whether requirements are perceived to be under control, correct, of good quality, and testable. Solutions to such needs might include an introduction to use cases as a technique to facilitate requirements.
  3. Use component architectures. In an architecture-focused process, the goal is to produce, in early phases, an architecture that is resilient in the face of changing requirements. The assessment should explore how architecture is visible and present in the development work, how architecture is represented, and how stable it is perceived to be. Issues regarding architecture often have to do with how explicitly architecture is described and used, and to what extent the architecture is verified early in the development lifecycle.
  4. Model visually. Visual modeling raises the level of abstraction and makes it easier to communicate specification, architecture, and design. The assessment should explore any organizational communication issues, which often can be remedied by introducing more effective visual modeling techniques.
  5. Continuously verify quality. Software problems are 100 to 1000 times more costly to find and repair after deployment. Verifying and managing quality throughout the project lifecycle is essential to achieving the right objectives at the right time. Use techniques that make software progress and quality tangible to your stakeholders. The assessment should explore, for example, whether there’s a definition of what quality means within the development organization under assessment, and whether there is a strategy to verify it; how well testing activities are integrated with the rest of the development activities; and whether testers and analysts are collaborating to ensure requirements are testable.
  6. Manage change. Use techniques that allow you to be in control and manage ownership, status, and consistency between the assets of the project. Controlling changes is more than just check-in and checkout of files. It includes management of change requests, workspaces, parallel development, and integration, as well as builds. The assessment should, for example, explore the extent to which the organization has common change and configuration management guidelines. For example, there should be well understood change request procedures in place, as well as good control over the assets of a project --their status as well as relationships -- and not simply the appearance of good control. Suggested solutions in this area typically include defining change request procedures, or implementing organization-wide change and configuration management plans.


Post a Comment

<< Home