AWI TechNet - Best Practices in Practice - Develop software iteratively, manage requirements, use component-based architectures, and visually model software.

Best Practices in Practice
By Andrea Casselton, Analyst and Project Manager

Software designers and programmers will often describe a project in terms of particular tools. "This is a Visual Basic project," or "We want to be on the cutting edge, so we are using Java." Business Analysts and Project Managers often describe their approach entirely in terms of a "brand-name" methodology. "This is a Booch project," or "We debated using the Rational Unified Process, but we decided to go with Extreme Programming’s (XP) approach all the way."

What these developers are forgetting is that they have an underlying set of assumptions and ways of doing things that dictates how they implement a technology or method. These underlying principles can be called “Best Practices.” Most organizations have a set of Best Practices but they are rarely articulated (conversely, most organizations also have an unspoken set of Worst Practices)

Best Practices

The term "best practices" is roughly equivalent to the collection of guidelines and advice that a seasoned professional would give a novice about how to develop good, reliable software. Anthropologists writing an ethnography would discover Best Practices by visiting a software development team in its natural environment: observing behavior, documenting practices, and identifying which practices have been observed to produce good results (e.g., higher levels of quality).

Best practices are continually evolving as business needs change and as technology changes. The approaches that worked well for mainframe applications may well be the worst possible approach for today's GUI-oriented, client-server projects. Best practices are concerned with invention and creation rather then being edicts set in stone.

Within the software industry there are differing opinions on what constitutes best practice. ArchWing has chosen to adopt the Best Practices published by the Rational Corporation (tm) because of the extensive research Rational has done in the area.

The Rational Corporation sets forth the following six practices as those needed to predictably and effectively build reliable software:
1. Develop software iteratively
2. Manage requirements
3. Use component-based architectures
4. Visually model software
5. Verify software quality
6. Control changes to software

1. Develop Software Iteratively
Since businesses are required to make many rapid changes to compete, software development has to adapt. Developers need to embrace a development cycle that allows for continuous change and rapid, smaller releases. Gone are the days when the waterfall process of:
1) Define the entire problem
2) Design the entire solution
3) Build all the software needed
4) Testing the product at the end

Iterative development focuses on defining, building, and testing smaller slices of a problem. Testing starts early and involves the end user; the focus is on ending each iteration with an executable release. Future iterations incorporate refinements and tactical business changes.

2. Manage Requirements
How to elicit, organize, and document required functionality and constraints is always a challenge in software development. Creating agreement on what the software needs to accomplish and then communicating that to a wide variety of audiences (end user, programmers, managers, etc) is essential if a project is to be successful.

Use cases and scenarios can be an excellent way to capture functional requirements and to ensure that these drive the design, implementation and testing of software, making it more likely that the final system fulfills the end user needs.

3. Use Component-Based Architectures
Properly implemented component-based architectures are resilient, flexible, accommodate change, are intuitively understandable, and promote more effective software reuse. Components are non-trivial modules subsystems that fulfill a clear function.

4. Visually Model Software
Visually modeling software captures the structure and behavior of architectures and components. Visual abstractions help communicate different aspects of the software to team members. Visual models let team members:

	See how the elements of the system fit together
	Make sure that the code maintains consistency between the design and its implementation
	Promotes unambiguous communication

One of the most popular ways to model software is using Unified Modeling Language (UML). The actual tool or language used is less important then how well the team members understand the model.

5. Verify Software Quality
Poor application performance and poor reliability are common factors that dramatically inhibit the acceptability of software applications. Hence, quality should be reviewed with respect to the requirements based on reliability, functionality, application performance and system performance. To develop high quality software the developer must:

	Build quality assessment into the development process
	Test at all stages of development
	Involve all stakeholders in testing
	Use objective measurements and criteria
	Not treat testing as an afterthought or a separate activity performed by a separate group

6. Control Changes to Software
The ability to manage change--making certain that each change is acceptable, and being able to track changes--is essential in an environment in which change is inevitable.

Worst Practices

Another approach to identifying what does and doesn’t work in developing software, is to create a “Worst Practices” list. The Airlie Software Council (Foot Note 1) identified nine worst-practices that its members had observed in projects; they're listed below. As with the Best Practices list, the Worst Practices list is not without controversy.

1.	Don't use schedule compression to justify usage of new technology on any time critical project
2.	Don't specify implementation technology in the RFP
3.	Don't advocate use of unproven "Silver Bullet" approaches.
4.	Don't expect to recover from any substantial schedule slip (10% or more) without making more than corresponding reductions in functionality to be delivered
5.	Don't put items out of project control on the critical path
6.	Don't expect to achieve large positive improvements (10% or more) over past observed performance
7.	Don't bury all project complexity in the software (as opposed to the hardware).
8.	Don't conduct the critical system engineering tasks (particularly the hardware/software partitioning) without sufficient software expertise
9.	Don't believe that formal reviews provide an accurate picture of the project. Expect usefulness of formal reviews to be inversely proportional to the number of people attending beyond five

Foot Notes
1. The Airlie Software Council was commissioned by the Under Secretary of Defense for Acquisition and Technology, and the Assistant Secretary of Defense for Command, Control, Communications, and Intelligence as part of the DOD-wide Software Acquisition Best Practices initiative. The Council was charged with identifying fundamental processes and proven solutions that are essential to successfully managing large-scale software development and maintenance projects. The Council was comprised of highly successful managers of large-scale software projects, internationally recognized authors, prominent consultants, and executives responsible for software development at major companies.

Sources
The Concept of Software Best Practices. Copyright 1996 by Computerworld. Originally published in the September 1996 issue of Computerworld Italia.

Rational Unified Process: Best Practices for Software Development Teams (White Paper ), Copyright © 2000 Rational Software Corporation.

AWI TechNet Index | AWI Corporate Site