What perspectives of software development best capture the nature of the activity?
What are the characteristics of software that make it both vital and problematic?
What are the characteristics of software engineering as a discipline?
Year | 1960s | 1970s | 1980s | 1990s |
| Style | Programming-any which-way | Programming in-the-small | Programming in-the-large | Megaprogramming |
| Characteristic Problems | Small Programs | Algorithms and programming | Interfaces, management system structures | distributed information systems |
| Data Issues | Representing structure and symbolic information | Data Structures and Types | Long-lived data bases, symbolic as well as numeric | multimedia databases |
| Control Issues | Elementary Understanding of control flows | Programs execute once and terminate | Program assemblies execute continually | Concurrency and Distribution |
| Specification Issues | Mnemonics, precise use of prose | Simple input output specifications | Systems with Complex specifications | Safety critical Systems |
| State Space | State not well understood apart from control | Small, simple state space | Large, structured state space | enormous |
| Management Focus | None | Individual Effort | Team efforts, system maintenance | software quality process improvement |
| Tools, Methods | Assemblers, core dumps | Programming Language, compilers, linker | Environments integrated tools, documents | OO frameworks |
Notice that we need to put in interaction between current practice and attempts to apply that practice to new problems. The observation that current practice fails in certain instances is part of what must drive the evolution of new and improved practice. A portion of the content under models and theories in this diagram is a theory of practice.
Who is involved? What roles do individuals have?
How many individuals are involved?
What are the tasks?
How are tasks allocated to people?
What are the characteristics of those engaged in a given
task?
Is the a match between the characteristics of the individual
and the demands of the task?
How is the process managed, coordinated, controlled?
What are the work products produced during development?
How long do the various tasks take?
How do we know a task is complete?
Are there tasks that can be performed concurrently?
What communications support is required to facilitate people working together?
What is the functionality provided?
What are the intended use(s) of the product in the customer's
environment?
What expectations does the customer have for the product?
Is the product operating reasonably in the use environment?
What considerations are there for system reliability?
How will the product be maintained over time?
What performance characteristics do the various functions need?
How does the system interface with the users?
Are the resources involved with system use being used wisely?
How many defects are present in the product?
What quality attributes have been assigned to this product and how should they be
quantified?
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.
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.
Go To Lecture [Outline] [Overview]
Go To [311 Course Outline] [CIS Department Page]
Brooks, F. (April 1987) No Silver Bullet. IEEE Computer. p.10-19
S. Pfleeger (1987) Software Engineering. New York: Macmillan.
Schach (1996) Classical and Object-Oriented Software Engineering.