There are activities that transcend individual phases, or define actions that must be integrated into a particular phase. These activities exist in various forms in each life cycle phase. The importance of these activities is embodied in the fact they transcend individual phases. To develop a focus on best practices we should review what can/should be done in each of these areas.
A search for best practices encounters the SEI Capability Maturity Model (CMM). In defining the CMM, the researchers at the SEI defined first the notion of a maturity levels, where moving up the levels was indicative of a increasingly mature software process. A maturity level describes a level of process capability, and, therefore, expectations in terms of the results one could expect from a given process at that level. This clearly gives the impression that given an organization at a particular level one can predict likely outcomes from a particular software project.
A maturity level is defined by the key process areas (KPA) that are considered important to achieve that level of process maturity. Such a definition allows project managers to focus on the key process areas as a way to identify areas that need to be addressed to improve their project's capability.
| Each key process area identifies a cluster of related activities that, when performed collectively, achieve a set of goals considered important for enhancing process capability. (The Capability Maturity Model: Guidelines for Improving the Software Process. Addison-Wesley. p. 32.) |
The structure elaborated by the SEI researchers was predicated on presenting a structure that would allow managers a sufficiently deep understanding of practices and activities that would allow them to assess their project's process and determine actions that could result in improved project performance. In preparing the CMM, the authors identified for each KPA a set of common features that support the implementation and institutionalization of a KPA. The key practices are divided among five Common Features sections: Commitment to Perform, Ability to Perform, Activities Performed, Measurement and Analysis, and Verifying Implementation. The Activities Performed describes activities that should exist within the software process. The other common features are intended as institutionalization factors, those that make an activity part of the organization infrastructure.
At level 2 of the CMM there are six KPAs that focus on those aspects of the project required to establish management controls. The goals for each of the KPAs at level 2 are given. Each heading below provides access to the key practices identified for that particular KPA through the hypertext link mechanism.
Establishing a clear line of communication between the developers and the customers is essential. A common understanding of the product's requirements is necessary if the project is to maintain control over an evolving product. Clearly, to establish control over the project requirements is important in insuring control and coordination over project resources, including project plans and personnel resources applied to aspects of the project, and provides the basis for project planning. As part of gaining control over requirements involves the implementation of a change control process (see Software Configuration Management).
Without realistic plans, grounded in a firm understanding of work required and the resources available, project management cannot be implemented. The purpose of Software Project Planning is to establish plans, reasonable and reasoned, for performing the project activities, engineering the product, and for managing and controlling the project. These plans are the necessary foundation for managing the software project, required for the KPA of software project tracking and oversight.
Software Project Tracking and Oversight establishes visibility into actual process and progress, so that effective actions are taken if, and when, the software project's performance deviates from the plans.
The purpose of Software Quality Assurance is to make the process being used by the software project and of the products being built visible to management and project personnel.
The purpose of Software Configuration Management is to establish and maintain the integrity of the products of the software project throughout the project's software life cycle.
[Practices Top]Counter-intuitive, effective practices are ignored in favor of the latest perceived "silver bullet." The Software Program Manager's Network (SPMN) encourages software organizations to move from a reliance upon silver bullets, fads, and checklist mentality to the use of proven practices. The focus must become support for bottom line productivity, product and process quality, timeliness and increased levels of user satisfaction. Process improvement efforts should address and these fundamentals. The SPMN is intent on helping software managers by putting useful/usable tools, concepts, strategies, and tactics to use of their projects by providing these individuals with the support needed to adopt said practices.
The Airlie Software Council, formed by the DOD and consisting of a rather prestigious group, produced list of nine "principal" best practices.
Discussed in detail in
Initially this item was discounted in judging its potential import. Perhaps some form of risk assessment can be presented by students. If students are introduced to planning (at least informal) then they may be able to characterize the situation in terms of "what resources must be in place and available to meet this schedule?" From a personal software process view an early introduction to the notion of risk may be in the form of "what happened to prevent your meeting the schedule you had developed?" See Boehm, B. (January 1991) Software Risk Management: Principles and Practices. IEEE Software. p. 32-41.
This practice clearly indicates the problem of identifying the correct set of requirements. The strategy is to keep development from starting until you know what is needed. This fits well with the prototyping paradigm in that prototyping and user manuals can be used as a method for ascertaining the legitimacy of the requirements. Brown expresses this practice as "Agreement on Interfaces" claiming system interfaces must be defined before analysis and design. "The user interface should be fully identified and baselined before beginning development." and "Only the actual operational user can define and accurately verify the user interface's correctness."
The literature clearly indicates the importance of these activities for defect detection (see defect detection). Artifacts produced during the project should be subjected to informal or formal reviews. There are a number of artifacts that seem susceptible to review. The Airlie council indicated detailed designs, code and test plans as good candidates. Further recommended was identifying small milestones (referred to as "inch pebbles"), and perhaps reviews frequently over these artifacts in an attempt to catch the little mistake before it becomes a huge error.
Experience over years, and attempts this last year to implement review activities in coursework, indicate the need for instructional support to develop student skills and strategies in this area. The literature on code reading indicates a large novice/expert differential which leads me to believe that there is a learning curve associated with the activity and the different strategic approaches by these groups is a result of skill acquisition on the part of the expert (see program comprehension). There are existing support materials that may provide some assistance in developing training activities (see Reviews and Inspections).
The key to project management is control of resources. To adequately control resources and apply those resources effectively, management needs to provide a plan which includes a schedule. To manage then there must metrics that ascertain the actual progress against the schedule. Providing this practice encourage the early identification of problems which can, hopefully, be remedied. Part of the success of this practice is the accumulation of a baseline of context specific data from which plans can be constructed.
The project staff is an essential ingredient in a successful project. It is the project staff that is responsible for identifying problems and risks. This is the group that should be kept aware of project status. Furthermore, this practice recommends the use of "anonymous" communications to report problems.
There should be a formal mechanism that track defects. The defect trace should include complete information through defect removal. You need to know where defects are injected, when they are identified and removed, what technique catches which type of defect, and the average and maximum time to close a defect report. Such tracking should cover the development time as well as the product first year in the field.
"high correlation between organizations that invest in timely training and their developmental success, and a high percentage of software professionals do not keep up with technology advancement." The manager's job is staffing project with qualified personnel. This is a two-pronged issued: 1) keeping competent staff and 2) keep the staff competent. Part of issue one is morale while issue two speaks to training.
Considerable attention is paid to defect identification and removal. Such attention is driven by a notion of software quality based on low defect levels. This view does not, however, consider defect characteristics. Under an assumption that some defects are worse/better than others, a strategic shift is undertaken when you focus on identifying those defects that are critical from the perspective of system operation (or the user's view). This alternative perspective is found in the literature under the notion of "just good enough software".
Bach, J. (October 1995) The Challenge of "Good Enough" Software. American Programmer.
Yourdon, E. (1996) Good-Enough Software (chapter 7 in Rise & Resurrection of the American Programmer).
Bach, J. (August 1997) Good Enough Quality: Beyond the Buzzword. IEEE Computer, p. 96-98.
[Practices Top]Postmortems may provide a strategy for increasing the reflective activity regarding project development and an individual's, or group's, process (See B. Collier, T. DeMarco, & P. Fearey (July 1996) A Defined Process for Project Postmortem Review. IEEE Software. p. 65-71.).
Another strategy that should be reviewed is that of the design notebook. See
It would seem the postmortem and design notebooks provide similar opportunity that may not be disjoint. The design notebook is a way of systematically collecting material during the course of a project. The design notebook provides the structure for one collecting the information during the course of the design activity, then the material is available for postmortem review.
Another avenue worth exploring is that of self-explanations. The self-explanation effect has been demonstrated by a number of researchers (refs) in learning problem solving and declarative knowledge. These researchers suggest three characteristics suggesting why self-explaining is an effective learning activity:
New declarative or procedural knowledge is constructed. In the realm of procedural learning, self-explanation facilitates the construction of missing rules.
This is a critical component of the theory, and perhaps one of the more difficult to assimilate. Since the self-explanation activity is constructive, there is an ongoing process of reconciling existing "knowledge" with information or knowledge being acquired. Eliciting self-explanations encourages the identification of those conflicts, forcing the student to look for the needed reconciliation. From a mental models perspective this appears to be a very robust issue.
Self-explaining provides multiple and repeated opportunities to confound student intuitions and understandings with veridical information and knowledge that may be provided in the instructional material.
This is not an exclusive issue. Postmortems and design notebooks are mechanisms that can be used in support of helping students engage in activities that could support reflective practice, i.e., collect the needed data for reflection. Eliciting self-explanations provides the needed foundations to explain what types of activities are needed and how to construct portions of the activity. Additionally, the self-explanation activity seems to benefit students at all levels equally. The complement to self-explaining is self-regulation which capture strategies that assist students in assessing their achievement of comprehension. Notes on Self-explanation and Self-Regulation.
[Practices Top]
[Bibliographies] [Process Ed] [Standards] [Research] [Resources]