This Document Contains Chapters 22 to 32 Chapter 22 Software Configuration Management CHAPTER OVERVIEW AND COMMENTS This chapter presents an introduction to the issues associated with change management and SCM. Version control and change control are emphasized. It will not be easy to convince students of the importance of these topics, unless your course happens to include a term long project that involves interaction with a real customer. Most introductory software engineering courses are not set up this way. One way to reinforce the importance of configuration management (without a real customer) would be to change the project requirements sometime after students have begun its implementation. However, to help students maintain their sanity (these courses do tend to be a lot of work!), I can’t recommend this in good conscience. 22.1 Software Configuration Management Section 22.1.1 presents a useful SCM scenario that will help students to understand the elements of change management. Be certain to discuss it in class. The elements of a configuration management system are discussed in Section 22.1.2. If time permits, you might consider expanding the discussion to provide detailed examples of each element. Baselines and software configuration items are presented in Sections 22.1.3 and 22.1.4, respectively. Students need to be aware that changes can occur to any SCI during the course of a project and the degree of rigor applied to change control is tied to whether or not an SCI has been baselined. The impact of changes can have a negative ripple affect throughout a project, if they are not controlled properly. The concept of a baseline configuration item as being something that has very tightly defined change procedures is important for students to understand. 22.2 The SCM Repository The characteristics of the SCM repository are discussed in this section. Key points to emphasize are: (1) that the repository is a database; (2) that it must be integrated with tools and with the SCM process; (3) that it should possess or be integrated with tools to provide the features noted in Section 22.2.3. 22.3 The SCM Process It is important for students to be able to distinguish between the terms version and variant. It is also important for students to get in the habit of incorporating the version number in the naming scheme used for their SCI's. Section 22.3.1 advocates the use of an object-oriented approach to managing the software configuration items once they are identified. Students who are unfamiliar with the concepts of object-oriented programming and/or the use of ERDs may struggle with the concepts introduced here. It may be desirable to review some of the concepts from Chapter 6 while covering this section. Version control (Section 22.3.2) is arguably the most important SCM function for software product builders. Be certain to discuss the mechanics of version control. If time permits, have your students research one of the tools noted in the sidebar in this section and present their findings to the class. Change control (Section 22.3.3) is the SCM task that helps to avoid chaos within a software project. The details of processing and controlling a change request for an SCI are discussed. Students need to be familiar with each of the major steps. Having students write change requests and engineering change orders (ECO) are worthwhile assignments. The process of item check-in and check-out from the project data base might be illustrated by having students use a Unix tool like SCCS or an MS Windows tool like Visual SourceSafe. It is important for students to understand the distinction between informal change control and the formal change control required for a baseline SCI. Section 22.3.4 contains a list of questions that need to be answered during a configuration audit. Students might profit from the experience of doing (or observing) a configuration audit using these questions following an assignment involving a required change to one of their projects. Section 22.3.5 suggests that software engineers develop a need to know list for every SCI and keep them up to date. This is probably the easiest and most reliable way to deal with the configuration status reporting task. If time permits, have your students research one of the tools noted in the sidebar in Section 22.3.5 and present their findings to the class. 22.4 Configuration Management for Web Engineering It’s important to note that most CM functions remain unchanged for WebE. However, the issues noted in Section 22.4.1 are emphasized and should be discussed. Content management (Section 22.4.4) is introduced here for the first time in this chapter. If your emphasis in this course is on the development of WebApps, this section should be emphasized and supplemented with additional materials. If time permits, have your students research one of the tools noted in the sidebar in this section and present their findings to the class. A wide array of military and ANSI/IEEE software configuration management standards are listed in the sidebar in section 22.4.6. It may be worthwhile to have students do library or web research to locate the details for one of them. Chapter 23 Product Metrics CHAPTER OVERVIEW AND COMMENTS This chapter discusses the use of software measurement and metrics as a means of helping to assess the quality of software engineering work products. Most of the metrics discussed in this chapter are not difficult to compute. Students can be encouraged to compute several of them for them own work products. What will be difficult for students is trying to interpret their meaning, since they will not have any historic data to use in their analyses of the metrics. Discussing case studies based on commercial products may help students to understand the use of metrics in improving the quality of software engineering work products. 23.1 A Framework for Technical Software Metrics General principles for selecting product measures and metrics are discussed in this section. The generic measurement process activities parallel the scientific method taught in natural science classes (formulation, collection, analysis, interpretation, feedback). A key point to get across to students is that effective measures need to be easy for developers to collect. If the measurement process is too time consuming, no data will ever be collected during the development process. Metrics should be easy to compute or developers will not take the time to compute them. The tricky part is that in addition to being easy compute, the metrics need to be perceived as being important to predicting whether product quality can be improved or not. The GQM paradigm (Section 23.1.4) should be used whenever someone wants to develop a software metric. To help your students better understand its intent, have them use the GQM approach to create a metric for a product other than software. 23.2 Metrics for the Requirements Model This section discusses metrics that may be useful in assessing the quality of the requirements model. Students need to understand that it is important to begin assessing product quality long before the first line of code is written. Most managers want the quality effort to be rewarded in the current project, not the next one. The metrics presented in this section are presented in sufficient detail to allow students to compute them for their own projects. It may be interesting to have students compute the same metrics for their term projects before and after implementation. If similar student projects are assigned each semester, it may be worthwhile to collect historic product measures and allow future student development teams to make use of this data to interpret their own metrics. 23.3 Metrics for the Design Model Representative design model metrics are discussed for architectural design, component-level design, and interface design. Students may benefit from seeing examples of each computed from real design work products. The computations are not too difficult and after seeing some examples students should be able to compute them for their own work products. Design is where measurement is a ‘must.’ Be sure to emphasize that a software engineer should use these metrics as he/she is doing design work. Section 23.4.2 describes nine measurable characteristics of an OO design. The details of the data that need to be collected and the metrics that can be computed are discussed later in the chapter. Students may benefit from seeing examples of actual measures and metrics computed for each of the nine characteristics. A variety of different class-oriented, component level, and operation-oriented metrics are discussed in Sections 23.4.3 through 23.4.7. Enough detail is presented to allow student to compute most of these metrics for their own software projects. Students would benefit from seeing how to compute and interpret these metrics for a real OO design (which requires access to some historical project information). A potential project activity might be the development of one or more "tiny tools" to automatically (or semi-automatically) compute the metrics presented in this section. 23.4 Design Metrics for WebApps It’s important to emphasize that metrics for WebApps are still in their formative stages and relatively little literature has been developed. The metrics presented in this section represent a good “first cut” and can be used to assess a WebApp design in a preliminary way. If time permits, you might consider having your students apply some of these metrics to an existing website. 23.5 Metrics for Source Code The only source code metrics mentioned in this section are associated with Halstead’s software science. It may be a good idea to show students how to compute them for a real program and then have them compute these for one of their own programs. Again students may benefit from seeing examples of how to use these metrics to improve a developing software product. 23.6 Metrics for Testing This section discusses the role of metrics in assessing the quality of the tests themselves. The majority of testing metrics focus on the quality of the testing process, not on the test work products. In general, testers rely on analysis, design, and coding metrics to guide the construction and execution of test cases. The point to get across to students is that good test metrics need to either predict the number of tests required at various testing levels or focus on test coverage for particular software components. Six new metrics that may be useful in determining the testability of OO systems are described in Section 23.6.2. Students may benefit from seeing how the metrics may be used in measuring the testability of an actual system (in terms of threads, scenarios, and clusters). Ultimately, students will want to find some relationship between these metrics and the number of test cases that need to be generated to test a system. 23.7 Metrics for Maintenance Students should be reminded that all the metrics discussed in this chapter can be used for both the development and maintenance of existing software. The IEEE software maturity index (SMI) is specifically designed to assist developers in assessing the stability of a product undergoing changes. An example of how to compute SMI for a real product might be helpful to students. Part 4 Managing Software Projects Chapter 24 Project Management Concepts CHAPTER OVERVIEW AND COMMENTS This chapter discusses project management at a fairly general level. The important point to get across is that all software engineers are responsible for managing some portion of the projects they work on. Modern software development is a very complex undertaking that involves many people working over long periods of time. The key to successful project management is to focus on the four P's (people, product, process, and project). Effective communication among all stakeholders is essential. The software process selected must be appropriate for the people and the product. The project must be planned if the goal is to deliver high quality software, on time and under budget. 24.1 The Management Spectrum This section provides an overview of the four P's of project management. The point to emphasize is that each the P's is important and it is the synergy of all four working together that yields the successful management of software products. This also the time to remind students that it is customer and the end-user for whom the product is being developed. Process framework activities are populated with tasks, milestones, work products, and quality assurance checkpoints regardless of the project size. To avoid project failure developers need react to warning signs and focus their attention on practices that are associated with good project management. 24.2 People Companies that manage their people wisely prosper in the long run. To be effective the project team must be organized in a way that maximizes each person's skills and abilities. Effective managers focus on problem solving and insist on high product quality. Software teams may be organized in many different ways. Two keys factors in selecting a team organizational model are desired level of communication among its members and difficulty level of the problems to be solved. Hierarchically organized teams can develop routine software applications without much communication among the team members. Teams having a more democratic style organization often develop novel applications more efficiently. It is important for students to understand that the larger the team, the greater the effort required to ensure effective communication and coordination of team member efforts. If you’re teaching a graduate course or an undergraduate course populated by industry professions, I’d recommend assigning readings from DeMarco and Lister’s classic text, Peopleware and from Weinberg’s On Becoming a Technical Leader. 24.3 The Product The first project management activity is the determination of software scope. This is essential to ensure the product developed is the product requested by the customer. It is sometimes helpful to remind students that unless developers and customers agree on the scope of the project there is no way to determine when it ends (or when they will get paid). Regardless of the process model followed, a problem should be decomposed along functional lines into smaller, more easily managed subproblems. 24.4 The Process Once a process model is chosen, it needs to be populated with the minimum set of work tasks and work products. Avoid process overkill. It is important to remind students that framework activities are applied on every project, no matter how small. Work tasks may vary, but not the common process framework. Process decomposition can occur simultaneously with product decomposition as the project plan evolves. If time permits, you might review some of the content of Chapters 2 and3, emphasizing the process model (s) that are most appropriate to the work done by your students. 24.5 The Project The text lists 10 warning signs that indicate when a software project is failing. Software engineers need to be on the watch for them and take corrective action before failure occurs. Most failures can be avoided by doing things right the first time and avoiding the temptation to cut corners to try to shorten the development cycle. Skipping process steps often has the effect of lengthening the development time since the amount of work usually increases. Taking time to reflect on how things went once a project is over, is a good habit to develop in students (who should be striving to avoid repeating their past mistakes on future projects). 24.6 The W5HH Principle Boehm's W5HH principle is a simple organizing tool that can help both novice and experienced software engineers focus on what is really important to include in a project management plan. Boehm's questions are applicable to all software projects, regardless of their size or complexity. As a classroom exercise, select a well know software product and have students answer each of Boehm’s W5HH questions. 3.7 Critical Practices The Airlie Council list of project integrity critical practices provides a good baseline for assessing how well a project team understands its practices. Most of the items in this list will be discussed in later chapters of the text. It may be helpful to have students begin thinking about this list in the context of developing their own project management plans. While this is difficult undertaking for students early in the course, it does get them thinking about the big picture without worrying about the details of software implementation. Chapter 25 Software Process and Project Metrics CHAPTER OVERVIEW AND COMMENTS This chapter provides an introduction to the use of metrics as a mechanism for improving the software development process and managing software projects. The concepts discussed in this chapter will be difficult for the students to relate to prior to working on a large software project. It is important to expose them to the reasons for using metrics and so that they can appreciate their potential in monitoring development costs and schedules on future projects. 25.1 Metrics in the Process and Project Domains Measurement is not used in software engineering work as often as it is in other branches of engineering. Software engineers have trouble agreeing on what to measure and have trouble evaluating the measures that are collected. The point to get across to the students is that the only rational way to improve a process is to make strategic decisions based on metrics and indicators developed from measurements of process attributes. Students also need to understand the differences between process metrics and project metrics. Process metrics are used to make strategic decisions about how to complete the common process framework activities. Project metrics are used to monitor progress during software development and to control product quality. 25.2 Software Measurement In this section the metrics that can help in the management, tracking and control of software projects are introduced. Size-oriented metrics are derived by normalizing quality or productivity measures over the product size (typically LOC or KLOC). Students need to appreciate some weaknesses of LOC as a measure (like language dependency). Some discussion about what to count in LOC (e.g. executable statements) and what not to count (e.g. comments) might be wise here. Function points are presented as an example of a method of indirectly measuring functionality using other direct measures. Function points can be used to normalize software. Function point values (FP) are easier for students to compute (prior to implementation) than LOC for their projects (see Chapter 15 for details). The table presented in Section 25.2.3 should be discussed during class. The points to make are: (1) the data are empirical, not absolute; (2) the data are based on a database of 6,000+ projects; (3) most important, the data provide an indication of which languages provide the most functionality per LOC. The OO metrics presented in Section 25.2.4 provide a means for assessing the “size” of an OO project. If time permits, it would be worthwhile to present an example based on Lorenz and Kidd’s metrics. Stress that metrics for Web engineering projects (Section 25.2.6) are in their infancy but they can provide an indication of overall project “size.” If time permits, it’s worth having your students examine one or more of the tools suggested in the sidebar in this section. 25.3 Metrics for Software Quality This discussion should be considered within the context of information presented in Chapter 23 and general quality management information presented in Part 3 of this book. I believe the most important topic to emphasize here is DRE (Section 25.3.3)—a measure that provides substantial benefit at both the project and process levels. 25.4 Integrating Metrics within the Software Engineering Process The fact that many software developers resist the use of measurement to guide their work will make it hard to convince students of its importance. However, the fact remains if developers do not measure they have no means of determining whether they are improving or not. Students need to understand that many current practitioners are still self-trained and may not be following the best development practices. Current thinking among experienced software developers is that process improvement is essential to remain competitive economically. This cannot happen without means of repeating past successes and avoiding inefficient development practices. 25.5 Metrics for Small Organizations The important point in this section is that small projects and small organizations can also benefit economically from the intelligent use of software metrics. The key is to select metrics to compute carefully and to ensure that the data collection process is not to burdensome for the software developers. 25.6 Establishing a Software Metrics Program This section discusses the steps needed to establish a goal-driven software metrics program. The important points are to choose your business goals and to determine what you expect to learn from the metrics program. The measures and derived indicators used will need to answer questions related to the attainment of these goals. It is also important to keep in mind that the modern view of software quality assurance includes customer satisfaction goals as well as product quality and process improvement goals. Chapter 26 Estimation for Software Projects CHAPTER OVERVIEW AND COMMENTS This chapter provides students with basic information on estimating for software projects. The estimating task involves estimating how much time, effort, and resources are required to build a software product. In most cases, there is enough information provided in the text to allow students to estimate their own projects and write their own planning documents. Students should be assigned the task of using the planning document template on the SEPA web site to write a planning document as part of their coursework early in the semester. 26.1 Observations on Estimating The point to get across in this section is that project estimation is a difficult task to do without historical data and a fair amount of experience with the proposed application. Nonetheless, it is a task that is required for virtually all projects. Project complexity, project size, and structural uncertainties affect the reliability of the estimate. 26.2 The Project Planning Process The objective of software project planning is providing a framework that allows managers to make reasonable estimates of the resources and time required to build a software product. It is important to point out to the students that the more information an estimator has, the better his or her estimates will be. This is an important reason to update all estimates, as the actual project costs and schedule become known as the project unfolds. The task set presented in this section should be discussed during lecture. Students may be unfamiliar with many steps, if they do not have actual project experience. 26.3 Software Scope and Feasibility Determining the scope of a software project is the first project planning activity. Students need to understand that until the developer and customer agree on the scope of the project it is impossible to determine what the project will cost and when the project will end. The best software practices call for the customer and developer to work together to identify the problem areas to be addressed and to negotiate different approaches to their solutions. Once the project scope is established, feasibility is the next issue to address. It is sometimes hard for young software developers to recognize that having the resources and capabilities needed to build a system, does not always justify building it. The best interests of the customer must come first, even if it means advising against the creation of a new software product. 26.4 Resources For software project work the resources used involve people, reusable software components, the development environment (hardware and software). The number of people required for software projects can only be determined after an estimate of development (e.g. person months) effort is computed. Students may have a tough time relating to software reuse. Student are either anxious to build their own software or naively believe that all they need to do is browse the Internet for some code to download. A more detailed discussion of component-based software design and software reengineering appears later in the text. In modern software development, people and hardware may be shared among several projects. Time windows for resource availability must be prescribed and planned for. I would suggest using Figure 26.1 for your talking points as you discuss this topic during lecture. 26.5 Software Project Estimation Software is now the most costly element of virtually every computer-based system. Cost and effort estimates may determine whether an organization can realistically undertake the development of software product or not. Software estimating can never be an exact science, but even students can be taught the steps needed to make estimates having acceptable risks associated with them. It is important to get students used to the idea or using 2 or more methods for making an estimate and then using the results to cross check one another. Students should be encouraged to reconcile the differences between multiple estimates to improve their confidence in the values computed. 26.6 Decomposition Techniques This section compares two methods of performing software sizing (directly by estimating LOC or indirectly using FP). The function point method seems to be a little easier for students to work with during the planing phase of their projects. The text suggests using the expected value (3 point) method of adjusting their software size estimates (either LOC or FP). It will be easier for students to develop meaningful LOC or FP estimates if they attempt to decompose their projects along functional lines and then estimate the size of each subfunction individually. This approach is called problem-based estimation. Process-based estimation is also discussed in this section. Students often prefer process-based estimation since they are estimating the amount of time they plan spend on the tasks that make up each phase of their process model after they have determined the work products for each phase (several low cost PC scheduling tools support this method, like MS Project). It may be wise to have the students reconcile the results obtained from a problem-based method like FP with their process-based estimates. It is important to point out that without some historical data to give these estimates a context LOC and FP values may not be very useful for estimating cost or effort. Sections 26.6.7 and 26.6.8 discuss estimation using use-cases. It’s important to emphasize that this approach is still in its infancy and is likely to result in somewhat less reliable estimates. 26.7 Empirical Estimation Models This section describes the general process of creating and using empirical cost estimation models. It may be wise to work through an example showing how a simple linear regression model is created from raw data and used to predict the value of dependent variables from new data points. Most students have not seen linear regression prior to this course and may not appreciate how these models are built. The equations in these models still require inputs like LOC or FP but users do not need local project data to compute their estimates. Model users only need to be confident that their project is similar to those used to create the model in the first place. The complete details of COCOMO II are not given in text and will need to be found on the COCOMO II Web site. Similarly, the details of the Software Equation will need to be located on the Web. 26.8 Estimation for Object-Oriented Projects You should examine the similarities and differences between the model presented for conventional and OO project estimation. Lines of code (LOC) and function point (FP) techniques are not always relevant to estimating object-oriented projects. Students should be encouraged to use the OO estimating and scheduling approach presented in this section on one of their own projects. Examining predicted versus actual time and project size for a completed project (using the text values) may be a worthwhile activity. 26.9 Specialized Estimation Techniques Estimation for agile software development and Web engineering projects is presented in this section. The steps outlines for agile projects make heavy use of scenarios (a mini-use-case) as the independent estimation variable. You should note that the “modified” FP measure suggested for WebE projects must be calibrated locally before it can be used at the project level. 26.10 The Make-Buy Decision The make-buy decision is an important concern these days. Many customers will not have a good feel for when an application may be bought off the shelf and when it needs to be developed. The software engineer needs to perform a cost benefit analysis in order to give the customer a realistic picture of the true costs of the proposed development options. The use of a decision tree is a reasonable way to organize this information. Outsourcing is a popular idea for many companies these days. The decision is usually motivated by the promise of reducing costs. This promise may or may not prove to be true, if the outside contractor handles the project management. Chapter 27 Project Scheduling CHAPTER OVERVIEW AND COMMENTS This chapter describes many of the issues associated with building and monitoring schedules for software projects. Students will need to be shown the process of building a schedule for a case study to really understand how it's done. They should be required to build a schedule for one of their own projects early in the semester. Ideally, all scheduling work should be performed using a scheduling tool. 27.1 Basic Concepts This section is intended to motivate the student's interest in project scheduling by describing several reasons why software projects are not completed on time. There is also a description of a proactive way to deal with unrealistic customer deadlines (based on detailed estimates and use of incremental development to deliver critical functionality on time). Scheduling is no longer a seat of the pants activity. There are many excellent tools that can be used to make the process easier. The basic idea to get across to the students is to break the software project into well-defined tasks, determine the interdependencies among the tasks, determine the time duration for each task, and assign the tasks to project team members. Each task must have defined outcomes and be associated a meaningful project milestone. 27.2 Project Scheduling Section 27.2.1 introduces a set of basic principles that guide software project scheduling. Each should be discussed during lecture. The most important point to get across in Section 27.2.2 is that adding people to a project in an arbitrary manner does not reduce the project completion time (and may in fact lengthen the completion time). There are times when a project schedule has slipped so badly that adding people can not save it and the only option a manager has is to renegotiate the completion date with the customer. The effort distribution model presented in this section is a good guideline for students to follow when they build their first project schedules. Be certain that your students understand that the 40-20-40 rule is a rule of thumb, not a concrete “rule” that must be applied for every project. 27.3 Defining a Task Set for the Software Project A "task set" is a collection of engineering tasks, milestones, and deliverables. The software process model selected for project provides much guidance in determining the task set. Task set is also dependent on the project type and degree of rigor desired. Students should be familiar with the five project types described in this section. The method used for determining degree of rigor should be demonstrated for case study. Scheduling involves taking the software engineering task set and distributing it on the project time line. The details of how to do this will depend on whether the software process model is linear, iterative, or evolutionary. The example discussed in this section describes the major tasks for a concept development project. It may be worthwhile to show students the task sets from the adaptable process model available through the SEPA Web site. Section 27.3.2 contains an example of refining a major scheduling task (concept scoping) into the smaller activities needed to create a detailed project schedule. Students may need to see additional examples of task refinement. 27.4 Defining a Task Network Building a task graph or activity network is the key to building a feasible schedule. The task graph represents inter-task dependencies very clearly. This allows managers to determine which tasks may be done in parallel and which tasks need to be done first. 27.5 Scheduling This section recommends the use of project scheduling tools for any non-trivial project. The PERT (program evaluation and review technique) and CPM (critical path method) are mentioned in the section, but no examples are given. It may be a good idea to show students a simple project activity graph and then show them how to use CPM to determine the critical path and compute minimum project completion time. Timeline (Gantt) charts are fairly easy for students to understand and are often available as output from scheduling tools like Microsoft Project. The time-boxing procedure described at the end of this section is a time management strategy that students should made aware of. 27.6 Earned Value Analysis Earned value analysis is an example of a quantitative technique for monitoring project completion to date. If students are able to estimate total project completion time they should be able to compute the percentage of the total project time associated with each project task. The progress indicators discussed in this section are fairly easy for students to compute and interpret. Chapter 28 Risk Management CHAPTER OVERVIEW AND COMMENTS This chapter defines the process of risk management and explains why it is an important part of the planning process for any software project. The text contains practical advice on how to perform risk analysis and how to build risk mitigation, monitoring, and management (RMMM) plans. Students will have a hard time relating to this material without seeing lots of examples of software risks and techniques for managing them. Having students write RMMM plans or risk information (RSI) sheets for projects of their own design is an important part of their learning process. 28.1 Reactive vs. Proactive Risk Strategies This section distinguishes between reactive and proactive risk strategies. It is important for students to understand that reactive strategies are usually not successful as a means of avoiding serious project problem. You might use the tragic events of 9/11 or the (considerably less serious, but still important) blackout of Summer, 2003 as examples of reactive as opposed to proactive approaches to risk. 28.2 Software Risks Risks involve areas of uncertainty in the software development process that have the potential to result in nontrivial losses to the project. Most computing students will need help in recognizing that software risks go beyond technical concerns and also include the economic uncertainties that come with marketing a piece of software. Students also need to be aware that while most software risks can be identified prior to beginning a project, some cannot. The fact remains that even if it is impossible to manage all risks any planning is better than no planning. 28.3 Risk Identification This section discusses the differences between identifying generic risks and product-specific risks. Generic risks can be listed on a checklist to examine for every software product. Examining the project plan and the software statement of scope identifies product-specific risks. Students may need to be shown examples of software project risk checklists. The risk assessment table shown in this section provides students with a good to begin quantifying the impact of many types of risk. 28.4 Risk Projection Risk projection (estimation) attempts to associate with each risk the likelihood (probability) of its occurrence and the consequences of the resulting problems if the risk should occur. The students should go though the process of creating risk tables for projects of their own. Determining the probabilities and quantitative impact measures will be very hard for them. It may be wise to give them some heuristics for converting qualitative statements into measures. If it is easier for them to estimate costs to fix problems, then Halstead's risk exposure (RE) might be helpful to use. 28.5 Risk Refinement Risk refinement is the process of decomposing risks into more detailed risks that will be easier to manage. Using the CTC (condition-transition-consequence) format may be helpful to students as they refine their own risks. 28.6 Risk Mitigation, Monitoring and Management When teaching this section, it will be helpful to give students examples of several types of risks and have the class discuss detailed strategies for mitigation, monitoring, and management. Contingency plans often benefit from brain storming activities. This section also provides a chance to pitch the importance of metrics as a source of indicators that can assist managers in risk monitoring. It is important to note that risk monitoring also includes tracing problems back to their points of origin (to do a better job of mitigating this risk in the future). 28.7 The RMMM Plan The template RMMM plan appears on the SEPA Web site. Students should be encouraged to examine its headings. Chapter 29 Maintenance and Reengineering CHAPTER OVERVIEW AND COMMENTS In this chapter I discuss two loosely related concepts: software maintenance and software reengineering. The discussion of software reengineering begins with the “maintenance iceberg.” Even after almost 50 years, this metaphor rings true, and yet, many students have virtually no appreciation of the burden that maintenance places on the software community. The steps of the software reengineering process model are considered in some detail. A model for assessing the economics of software reengineering is presented at the conclusion of the chapter. Reengineering became ‘corporate chic’ during the 1990s. At the corporate level, entire business processes were reengineered to make them more efficient and more competitive (at least in theory!). These changes had a trickle down effect on information systems. As business processes changed, the information technology that supported them also had to change. 29.1 Software Maintenance The key point to emphasize as you discuss software maintenance is that most of what a software team does as it engineers a system sets the stage for the maintenance activity. If design is sloppy, maintenance will be quite difficult. If testing is incomplete, maintainer will struggle when regression tests must be run … and so on. But also note that even with the best software engineering approach, maintenance remains a challenge. Discuss why that is. If time permits discuss Lehman’s Laws. Try to illustrate each law with a real world example. Finally, discussion software maintenance as it will be performed during the second decade of this century. How does, say, cloud computing change the maintenance landscape? How does the proliferation of hand-held devices effect software maintenance? 29.2 Software Supportability Because supportability involves software maintenance, it’s important to make a clear distinction between supportability and maintenance. Use a real life example to illustrate the logistics associated with the supportability of an actual software product. 29.3 Reengineering Spend some time discussing the history of the reengineering movement, addressing both pros and cons, and successes and failures. 29.4 Business Process Reengineering This section presents an overview of BPR with an emphasis on its impact, basic BPR principles and the tasks that define the BPR model. There has been significant hype associated with BPR and the ramifications of this should be discussed for your students. If time permits you might have the student conduct a BPR exercise by reengineering some process (e.g., registration) at your university. 29.5 Software Reengineering The classroom discussion should focus on why software needs to be reengineered. Have your students develop a set of criteria that will help to determine when a system needs reengineering and when it needs on-going maintenance. 29.6 Reverse Engineering This section considers reverse engineering activities and identifies key concepts that must be understood as information is extracted from an existing program. Reverse engineering techniques for processing, data, and user interfaces are all discussed. If time permits, distribute two undocumented pieces of code, one well structures and designed, the other a kludge. Have your students attempt to reverse engineer each and then draw conclusions from their experience. 29.7 Restructuring This section presents a brief overview of restructuring techniques for code and data. If time permits have students research one or more restructuring tools (see the sidebar in this section) and then discuss how they work on existing code. Provide an example of data restructuring so that students will appreciate that it can be as or more important than code restructuring. 29.8 Forward Engineering This section presents an overview of forward engineering approaches for client/server systems, OO systems, and user interfaces. If time permits, it would be useful to provide a forward engineering example. 29.9 The Economics of Reengineering This section presents a simple cost-benefit model for reengineering. Not every application should be reengineered. The model presented in this section enables your students to compute the projected cost benefit of a reengineering activity. Part 5 Advanced Topics Chapter 30 Software Process Improvement CHAPTER OVERVIEW AND COMMENTS In this chapter I discuss software process improvement—a topic that is vitally important for industry practitioners, but may be a bit over the head of undergraduate students. If you’re teaching an undergraduate course and your student demographic has little real-life software experience, I would recommend presenting the material in overview fashion, emphasizing the importance of SPI, the reasons it is conducted, and the basic concepts and process that is applied. On the other hand, if your class is composed on working professionals, I would recommend a much more indepth treatment, with a lengthy discussion of the reasons so many SPI efforts fail and what software organizations can do about it. 30.1 What is SPI? Spend a reasonable amount of time discussing Figure 30.1. It identifies all of the major relationships in the SPI domain. As time permits, delve into the maturity models that are used for SPI. The SEI website is an excellent source of supplementary information. For a broader look, the SEPA website provides many pointers that can be used. The discussion in section 30.1.3 is important but may be over the head of undergraduates. If your class demographic includes professionals, spend some time on this topic. 30.2 The SPI Process The process model presented in this section was originally proposed in a book I wrote in 1988, long before SPI was a watchword. It has been applied at dozens of companies and has worked reasonably well. It is not, however, the SEI “gospel” and you might choose the SEI’s version as an alternative. The key is to emphasize that the SPI process must not be ponderous, must be incremental, must identify process strengths and weaknesses, and must derive a workable, common sense play for improvement. If your class is composed of professionals, I would spend time discussing section 30.2.6. There is substantial risk when SPI efforts are undertaken, and mitigating this risk is a major concern. 30.3 The CMMI Entire courses are dedicated to the CMMI and the degree to which you present this material is a function of your class demographic and the time you have. As a minimum, be sure you provide a brief history, the reasons why the CMM and CMMI were developed, and a basic overview of the model. 30.4 The People CMM Most software problems are people problems, at least when large projects are concerned P-CMM and the degree to which you present this material is a function of your class demographic and the time you have. As a minimum, be sure you provide a brief history, the reasons why the P -CMM was developed, and a basic overview of the model. 30.5 Other SPI Frameworks This section provides the briefest of overviews of a number of important SPI frameworks. If you intent to expand upon one or more of these, you’ll need to supplement information presented in SEPA with web-based information sources. 30.6 SPI Return on Investment This is an advanced topic and was inspired by a book-length discussion by David Rico. If you intend to present this topic in depth, I would strongly recommend getting a copy of Rico’s book, ROI of Software Process Improvement, J. Ross Publishing, 2004. 30.7 SPI Trends It would be useful to scan on-line industry periodicals and web sources and find a recent summary of SPI-related success/failure stories. Chapter 31 Emerging Trends in Software Engineering CHAPTER OVERVIEW AND COMMENTS In this chapter I discuss three interrelated subjects. First, the overall nature technology trends and how they affect the manner in which we predict the futures and how technologies tend to evolve. Second, overall “soft trends” and technology directions. And third, specific technology trends and their indirect impact on software engineering. By the time you present this material, there may be newer, more exciting trends that you’ll want to introduce. In every instance, however, try to define how these trends will change the manner in which software engineering is performed. 31.1 Technology Evolution Spend time on Figure 31.1, but be sure to note that it’s an idealized curve. If you have time and want to initiate a lively classroom discussion (guaranteed!), introduce Kurweil’s ideas about the coming “singularity” and it’s impact on virtually everything in our lives. In this context, be sure to ask how strong AI will affect what we now know as software engineering. Will it disappear? 31.2 Observing Software Engineering Trends The Gartner “hype cycle” is a realistic view of technology evolution. Use examples of real world products to illustrate it. 31.3 Identifying “Soft Trends” The thrust of this section is that people- and culturally-oriented trends may have as much or more to do with changes in software engineering approaches as hard technology directions. Be sure your students appreciate the impact of complexity and how it will present increasingly more difficult challenges in the years ahead. As them how they would handle a truly complex system. I classroom discussion of open-world software will be lively, because we’re rapidly moving toward that world as I write this. Discuss “augmented reality” and other related subject. If you so inclined, suggest Vernor Vinge’s Rainbow’s End as a SciFi version that’s becoming all too real. 31.4 Technology Directions The trends discussed in the subsections that follow are the most closely aligned to overall software engineering trends. If your class has strong interest in a particular topic presented in subsection 31.4.1 – 31.4. 7, be sure to emphasize it. The “grand challenge” presented in section 31.4.2 is worthy of classroom discussion. Consider each of the characteristics and provide real life examples that illustrate it. 31.5 Tools-Related Trends It’s likely that the material presented in this section will be outdated by the time you arrive. Augment the presentation with the latest tools that have software engineering relevance. Chapter 32 Concluding Comments CHAPTER OVERVIEW AND COMMENTS The intent of this chapter is to provide a peek into the future of software engineering practice. Like any attempt at crystal ball gazing, my projections may be off the mark, but the general trends outlined in this final chapter of SEPA are likely to emerge as in the years ahead. In addition to prognostication, this chapter presents a brief discussion of software engineering ethics. You may choose to cover this material very early in a software engineering course, although I think it’s best to wait until a student has substantial knowledge of just what software engineering is. In any event, this is a very important topic and should be covered, even if time is short. 32.1 The Importance of Software—Revisited This section revisits the importance of computer software. The key aspect of this discussion is "software as differentiator." It is interesting to have your students come up with examples of software as a differentiator for products and services. 32.2 People and the Way They Build Systems People and cultures change very slowly. In this section, I make the argument that ad evolving software engineering environment may have as much or more to do with people issues (in software engineering) than the people themselves. As tools, interaction mechanisms, and methodology mature, the culture for building software may change accordingly. 32.3 New Modes of Representing Information Students spend much time thinking about data and program architectures, algorithms and the like. They spend very little time considering the intent of the data that is processed. This section considers the relationship between data, information, knowledge and wisdom. You might relate some of this discussion to data mining in general and specific applications that span multiple data bases. 32.4 The Long View As I mentioned in my discussion of Chapter 31, if you have time, spent it discussing Kurweil’s view of the “singularity.” Note that there are utopian and distopian views (read Joy’s classic “The Future Doesn’t Need Us”). It’s very likely that you and your students will live through the times that Kurweil predicts and the impact on your world will be profound. 32.5 The Software Engineering Responsibility Software engineers should abide by a code of ethics that guides the work that they do and the products that they produce. The Software Engineering Code of Ethics and Professional Practices is well worth discussing with your students. To make the discussion more meaningful, you should pose specific business or personal situations and have your students indicate how they would react to them. Instructor Manual for Software Engineering: A Practitioner's Approach Roger S. Pressman 9780071267823, 9789355325044
Download
Close
Close
