Kendrick Hang Narrative, code, and photos.

Software Safety: A Survey of Concepts and Techniques

I wrote this lit review-style survey after doing a research dig on software safety to get a sense of what the current research and practice is for safety-critical software systems. This paper really does not do justice to the significant amount of material that is out there, but I think it at least skims the surface for someone who might just be trying to find a place to start reading and learning more. At the same time, I think the structure of this paper (each section subsequently shorter in length) mirrors the literature that is out there. There’s a lot of folks writing about how important safety is, a few less people writing about safety requirements, even less on designing software for safety, and not much at all on testing safety-critical systems. I originally wrote this paper in July 2007 and I am now publishing it on the web now for the software community to read and refer to as needed.

Abstract
Although software is increasingly becoming a part of safety-critical systems that control aircraft, automobiles, heavy machinery, and medical devices, few software engineers are aware of the issues relating to safety-critical systems and the techniques that are currently available, along with their limitations. To effectively design a safety-critical software system one must consider safety throughout the software development lifecycle, and not as an afterthought. Safety requirements must be explicitly specified, an active approach is used to address safety in design and implementation, and the safety constraints of the software must be verified and tested properly before the software is deployed in a safety-critical situation. Instead of being an afterthought to software engineering, software safety is more of an extension of the software development methods of which software engineers are already familiar, with added emphasis on specific techniques to address safety-specific concerns.

Software Safety: A Survey of Concepts and Techniques
When software professionals think of software safety, the infamous Therac-25 incident comes to mind. The Therac-25 was a medical device designed to administer radiation therapy. However, flaws in the Therac-25 software resulted in some patients being seriously harmed by radiation overdoses and burns. Leveson and Turner’s (1993) case study is required reading in many undergraduate computer science programs, but beyond knowing that software safety is an issue, few software engineers know how to make software safer. Creating safer software involves using methods and techniques during all phases of the software development life cycle. From determining safety-related requirements to developing test cases for safety conditions, the notion of safety must embody the approach to software development for the resulting software to be considered safe.

Although emphasis is placed on making software safer, safety must be considered at the system level. Moray and Huey (1988) define the layers of a complex socio-technical system as:

1. the technical/engineering system,
2. the workers that operate the system,
3. the organizational/management infrastructure that governs the workers, and
4. the environmental context in which the organization operates.

Vicente (1999) states, “There is now a great deal of evidence to show that organizational factors play a very important role in system performance and safety.” This implies that the design of the technical system, including the software, should take factors external to itself into consideration when addressing safety issues. Since people use the software system, human factors need to be considered for safety to anticipate the potential actions a user might take in the software if certain scenarios arise. In addition, users may follow guidelines from their management and the software may need to address those guidelines to maintain safe conditions in the overall system.

Software safety is important in situations that have potential to cause harm to humans, but situations that pose hazards are equally important. It is natural to think that a scenario where software failure results in bodily harm or death as a safety-critical system, particularly since the Therac-25 is the most well-known case study on software safety. Knight (2002) defines safety-critical systems as “those systems whose failure could result in loss of life, significant property damage, or damage to the environment.” However, many accidents are not caused by a single error, but rather multiple errors that compound to create an unsafe condition in a system. Wickens (2000) classifies errors in terms of active failures and latent conditions. An active failure occurs when a specific action causes a error, while a latent condition is a scenario where an action introduces or contributes an error condition into the system, but the error itself does not occur until a later state when other conditions fall into place at the right time. Similar types of latent errors occur in software: the software may continue to function “normally” but an error may surface later or in another form, either within the software, or outside the software within the realm of the socio-technical system. Leveson (1995) notes that safety-critical systems are rarely defined in terms of the potential catastrophic consequence of an error, but rather the hazard conditions that can be introduced by software, which in turn may contribute to a safety-critical condition in the system.

Safety Requirements
In creating software for safety-critical system, the first step is to consider and determine the safety requirements. In their software safety standard, NASA (1997) stresses the importance of requirements by stating, “The successful development of safety requirements for the software requirements specification is essential to developing safe software and allows for safety to be built into the software early in the life cycle while it is relatively inexpensive.” In the requirements phase of a project, a hazard analysis (U.S. Department of Defense, 1984) should be performed to identify a list of potential hazards in the system, assess the hazards, and then translate the hazards into software requirements, specifically in the form of design constraints. For example, in a software-controlled building security system, the doors not being able to open during a fire might be a hazard. The resulting requirement (or constraint) generated from that hazard might be that the doors can only be locked when no fire alarm in the building has been pulled. In addition to performing a hazard analysis, an investigation of the conditions that cause a hazard to occur, through fault tree analysis, for example, may help to elicit additional safety-related requirements.

Most software engineers are familiar with using natural language (English) to describe requirements in a specification document, but more formal mechanisms can better express safety-related requirements. Formal mechanisms allow for better analysis and reasoning about the modes and states the software can be in, as well as the values that the software may encounter. A finite state machine is an example of a formal mechanism that describes a safety feature of a system or how the system reacts to hazard conditions. In the building security example, a finite state machine can describe the possible transitions between a normal operating state and an emergency (fire, evacutation) operating state, along with the resulting effects. That particular finite state machine can then be examined to see if any transitions were not considered or if any of the resulting effects can pose a hazard. Another means of stating safety requirements formally is through formal specification languages, such that formal analysis techniques can be used to later verify that the safety properties are satisfied (Lutz, 2000). The formal specification languages express safety requirements in mathematical terms such that the interpretation is definite, especially compared to natural language, which can be interpreted differently in varying contexts. Leveson (2004) developed a CASE tool, SpecTRM, to help software developers more formally state system and software requirements in a combination of graphics and text, and then allows users to run automated routines to check the models for inconsistencies and errors that may lead to hazard conditions.

Once the safety requirements have been analyzed and stated in the software requirements specification (SRS), it is necessary to validate the requirements for completeness. The IEEE (1998) lists the following as one of the criteria for completeness: “Definition of the responses of the software to all realizable classes of input data in all realizable classes of situations.” In addition to the broad statement, Leveson (1995) lists 60 specific criteria to examine for requirements completeness. A sample of these criteria includes: startup and shutdown, mode transitions, inputs and outputs, value and timing, load and capacity, failure states and transitions, and latency. Just as most software errors trace their source back to requirements, most software safety issues trace back to non-existent or insufficient safety requirements. Therefore, effective validation of the requirements specification, including the safety-related requirements, will result in fewer errors and hazards being introduced into the system and propagated into subsequent phases in the software development lifecycle.

Safety in Design and Implementation
The software requirements, including the safety requirements among them, are the basis in conceptualizing the software design and producing the software implementation. That is, every requirement should be traceable to an element in the design and to lines of code in the implementation. Several design elements exist to implement some of the safety requirements, including inhibits, traps, interlocks, and assertions to control, reduce, or eliminate hazard conditions. The underlying strategy behind these design elements is to actively check for failure or hazard conditions and handle them appropriately before they propagate to another part of the software. Various levels of checking can be designed into the software to stop the propagation of errors. Leveson (2002) details a hierarchy of software checking. The levels include:

• Hardware checks, where the software actively detects hardware failures and instruction errors.
• Code-level checks, where the software actively checks for invalid values, ranges, and states.
• Audit checks, where a separate process checks data and timing in the main process.
• Supervisory checks, where a separate system (human or computer) checks the main system. Lutz (2000) refers to this as runtime monitoring.

In addition to the safety-related design elements, the design of the non-safety-critical portions of the program needs to be considered as it may in turn affect safety. Parnas, van Schouwen, and Kwan (1990) state that in safety-critical systems, “the system must be structured in accordance with information hiding to make it easier to understand, review, and repair”—a hint that designing for safety starts with good general design practices. Integrating these design elements and strategies, one can explicitly design and code features to not only prevent hazards, but to detect and manage them as well, thus providing an end result of a safer software system.

Testing for Safety
Even if the software is designed with a safety strategy in mind and implemented with safety-related design elements, hazard conditions in the resulting software may still exist because of errors in the design and implementation. For this reason, verification of the code for correctness and validating the implementation against safety-related requirements is an important step in the process of developing safer software. Two primary strategies are static and dynamic analysis, where static analysis involves using tools or people to analyze or inspect the code, while dynamic analysis involves running tests and examining the results to ensure none of the safety requirements (constraints) are violated. Parnas, van Schouwen, and Kwan (1990) suggest that effective testing of safety-critical systems requires a basis of mathematical documentation to test against. That is, using the finite state machines to define the test cases. Although many testing strategies exist, many of which improve the effectiveness of checking safety requirements, a parable of testing still holds true: testing will not prove the non-existence of errors in a system, it will only show the presence of errors in a system. This implies that even if safety is taken into consideration throughout the entire software development lifecycle, there is no such thing as safe software, there is only safer software.

Conclusions
In analyzing the currently available techniques to develop safety-critical software systems, one notices that the principles of designing safer software are not independent from the fundamental principles of software engineering. Software safety is not a separate field and does not involve a different approach to developing safer software, but rather rooted in good software engineering. For instance, good software engineering principles call for investing sufficient time and effort into requirements analysis because that is where most errors in a system originate. Likewise, most safety issues in software originate because of insufficient requirements and safety constraints that need to be designed into the software. Software safety involves extending software engineering practices by supplementing it across the entire software development life cycle with analysis techniques, design strategies, and verification methods to emphasize safety by preventing hazards.

References
Dunn, W. R. (2003). Designing Safety-Critical Computer Systems. Computer, 36(11), 40-46.

Herrmann, D. S. (1999). Software safety and reliability: techniques, approaches, and standards of key industrial sectors. Washington, DC: IEEE Computer Society.

Heimdahl, M. (2007). Safety and Software Intensive Systems: Challenges Old and New. Proceedings of the Conference on The Future of Software Engineering, 137-152.

IEEE. (1998). “IEEE Std. 830: IEEE Recommended Practice for Software Requirements Specifications.” Software Engineering Standards Collection. New York, NY: The Institute of Electrical and Electronics Engineers.

Knight, J. C. (2002). Safety-critical systems: challenges and directions. Proceedings of the 24th International Conference on Software Engineering, 547-550.

Leveson, N. G. (2002). System Safety Engineering: Back to the Future. Unpublished manuscript, Massachusetts Institute of Technology. Retrieved on June 24, 2007, from http://sunnyday.mit.edu/book2.pdf.

Leveson, N. G. (2004). A Systems-Theoretic Approach to Safety in Software-Intensive Systems. IEEE Transactions on Dependable and Secure Computing, 1(1), 66-86.

Leveson, N. G. (1995). Safeware: System Safety and Computers. Boston, MA: Addison-Wesley Professional.

Leveson, N. G., & Turner, C. S. (1993). An Investigation of the Therac-25 Accidents. Computer, 26(7), 18-41.

Lutz, R. R. (2000). Software engineering for safety: a roadmap. Proceedings of the Conference on The Future of Software Engineering, 213-216.

Moray, N., & Huey, B. (1998). Human factors research and nuclear safety. Washington, DC: National Research Council, National Academy of Sciences.

McDermid, J. A., & Pumfrey, D. J. (2001). Software Safety: Why is there no Consensus? Proceedings of the 19th International System Safety Conference.

NASA. (1997). NASA-STD-8719.13A Software Safety Standard. Washington, DC. Retrieved on July 15, 2007, from http://satc.gsfc.nasa.gov/assure/nss8719_13.html

Parnas, D. L., van Schouwen, A. J., & Kwan, S. P. (1990). Evaluation of safety-critical software. Communications of the ACM, 33(6).

Storey, N. R. (1996). Safety Critical Computer Systems. Boston, MA: Addison-Wesley Longman.

U.S. Department of Defense. (1984). MIL-STD-882B System Safety Program Requirements (AMSC Number F3329 FSC SAFT). Washington, DC. Retrieved on June 24, 2007, from http://sunnyday.mit.edu/safety-club/882b.htm.

Vicente, K. J. (1999). Cognitive Work Analysis: Toward Safe, Productive, and Healthy Computer-Based Work. Lawrence Earlbaum: Mahwah, NJ.

Wickens, C. D., & Hollands, J. G. (2000). Engineering Psychology and Human Performance, 3rd ed. Prentice Hall: Upper Saddle River, NJ.

Function Points in Software Estimation

I originally wrote this article in October 2007 for a course in Software Maintenance, now making it available on the web. The intended audience is software engineers and software project managers who are faced with a task of estimating software size and cost.

Planning for a software development (or maintenance) project involves estimating the effort in terms of cost and time to establish a budget and a schedule. The estimated effort is directly proportional to the size of the project—larger projects require more time and money. Therefore, a size estimation (scope, or amount of work) must be made to serve as the basis for the effort estimation (cost and time).

In software projects, lines of code (LOC) immediately comes to mind as a measure of size. However, estimating in terms of lines of code can be problematic as there is no consistent definition of what a line of code is. Does whitespace count as a line of code? Is each line in an if-statement a line of code, or does the entire if statement count as one line of code? In addition, lines of code are dependent on the programming language being used: a 100-line program written in Perl may take 500 lines in C (Kernighan and Pike). Finally, if concise code is a design goal, a count of the lines of code may not reflect the necessary effort required to develop a concise design to satisfy a requirement. Instead of using lines of code as a metric, function points provide an alternative unit of size that addresses some of the shortcomings of using lines of code.

Function points are a measure of the functions—as in functionality—of a system, independent of how the software requirements are specified (natural language or formal notations), how the software is designed (structured or object-oriented), and how the software is implemented (programming language). The determination of the number of function points in a system depends on five parameters described by Albrecht (1983): external input types, external output types, logical internal file types, external interface file types, and external inquiry file types. In more modern terminology used by Futrell, Shafer, and Shafer (2002), these parameters can also be referred to as: inputs, outputs, data structures (files), interfaces, and inquiries. The following list provides brief definitions for each of the parameters.

• An external input is any object (data or control) that provided to the system, regardless of whether the source is a user or another system.
• An external output is any object that the system provides to an external recipient be it a user or another system. Reports produced for a user, messages displayed to a user, and messages sent to another system are examples of outputs.
• A data structure or internal file type is a structure maintained within the system to manage some logical grouping of information. A data structure may be some object in memory that maintains the data to be manipulated by the system.
• An interface is any data that crosses the system boundary: a file that resides outside the application or data structures received from or sent to other systems.
• An inquiry is an input-output pair where some request is made of the system and that request triggers a response by the system. One can think of an inquiry as an event triggered by a user (command) or another system (request) that results in an immediate response.

Upon identifying the parameters in the system, each parameter is classified as simple, average, or complex. For example, if the system has ten outputs, each of the ten outputs are individually classified as simple, average, or complex. The classifications are then used to determine the weight of each parameter. After counting and classifying the parameters in the system under consideration, a weighted sum of the parameters is taken to obtain the raw function point count.

The raw function point count serves as the basis for the final function point count, but it first must be adjusted for environmental factors that can affect the size of the system, up to 35 percent (Jalote, 1997), due to increased complexity. There are 11 environmental factors that are taken into consideration: data communications, distributed processing, performance objectives, operation configuration load, transaction rate, online data entry, end user efficiency, online update, complex processing logic, reusability, installation ease, operational ease, multiple sites, and desire to facilitate change (Jalote, 1997). Each of these environmental factors are evaluated and determine the complexity adjustment factor (CAF). The number of raw function points multiplied by the CAF results in the final function point count, also referred to as the number of adjusted function points or delivered function points. Futrell, Shafer, and Shafer (2002) provide a summary of the steps described above to determine the number of (adjusted) function points in a system.

1. Count the number of functions (parameters) in each category.
2. Apply complexity weighting factors.
3. Apply environmental factors.
4. Calculate the complexity adjustment factor.
5. Compute the adjusted function points.

As an optional last step, one can convert adjusted function points to lines of code. There are known conversion factors that help to estimate the number of lines of code in a particular programming language to implement one adjusted function point. Although it might seem counterintuitive to convert function points into lines of code after noting all of the deficiencies of size estimation by lines of code, this last step is often performed to provide additional insight into the software size estimate. An estimate in lines of code provide developers a sense of the size of the system as it is often easer to visualize scale in lines of code, rather than in function points. In addition, cost estimation models like the widely-known Constructive Cost Model (COCOMO) use lines of code as the estimation unit for its size input. Note however that there is distinct difference between estimating a system’s size directly in lines of code and estimating a system’s size by function points and then converting function points into lines of code. Estimating size in lines of code via function point analysis is less subjective than estimating size ad-hoc in lines of code.

Estimating software size through function point analysis provides a methodical and consistent means of gathering input for software project planning, particularly in determining an initial budget and schedule. Function point counts allows for tracking progress as the system is developed in terms of number of function points satisfied. Even during the maintenance phase of the software lifecycle, it can be an invaluable tool in understanding the scale of the system to be maintained and evaluating the impact of changes on the system to effectively plan for maintenance efforts.

Note to readers: Function point analysis is one, but not the only method of estimating software size. This article is meant as an introduction to the function point analysis, which is commonly mentioned in the literature and one of the more prevalent size estimation methods, used in conjunction with COCOMO to produce a cost estimate.

References
Albrecht, A. J., & Gaffney, J. E. (1983). Software function, source lines of code, and development effort prediction: A software science validation. IEEE Transactions on Software Engineering, 9(6), 639-648.

Futrell, R. T., Shafer, D. F., & Shafer, L. I. (2002). Quality Software Project Management. Upper Saddle River, NJ: Prentice Hall PTR.

Jalote, P. (1997). An Integrated Approach to Software Engineering (2nd ed.). New York, NY: Springer-Verlag.

Kernighan, B. W., & Pike, R. (1999). The Practice of Programming. Reading, MA: Addison Wesley.

Hosting WPF Content in an MFC App

I recently had to host a WPF control in an MFC application. These are my notes on how to do it, along with some extras near the end.

MSDN has an article, WPF and Win32 Interoperation Overview, that describes how to host a WPF control in a Win32 application. The instructions on Win32 hosting WPF are quite good, and there’s a code example in Walkthrough: Hosting WPF Content in a Win32 Application.

MFC is essentially a wrapper for part of the Win32 API. As a result, the procedure for hosting a WPF control in an MFC app is very similar to the procedure for hosting a WPF control in a pure Win32 app. The following is a mapping of the steps listed in the WPF-Win32 interop article to the steps I took in MFC.

1. Create WPF content.

2. Implement a Win32 application with C++/CLI.
Implement an MFC app. (I created a new one as a test app, dialog-based for simplicity.) Then, set the MFC app to compile with managed code (with /clr).

• Right click on the MFC project in the Solution Explorer.
• Configuration Properties → General
• Set Common Language Runtime support option to Common Language Runtime Support /clr.

With this option set, the MFC app now has access to the .NET Framework Library via C++/CLI syntax. In addition, add references in the MFC app (right click on the MFC app in the Solution Explorer, References) to the following four .NET assemblies for WPF support:

• WindowsBase
• PresentationCore
• PresentationFramework
• System

3. Set threading model to STA (single threaded apartment).
In project properties, go to Configuration Properties → Linker → Advanced → CLR Thread Attribute Property to STA threading attribute (/CLRTHREADATTRIBUTE:STA).

4. Handle the WM_CREATE notification in your window.
Using the IDE, add a handler for the WM_CREATE message. The IDE creates function OnCreate().

5. Within the handler

1. Create a new HwndSource object with the parent window HWND as its parent parameter.
2. Create an instance of your WPF content.
3. Assign a reference to the WPF content object to the HwndSource object RootVisual property.
4. The HwndSource object’s Handle property contains the window handle (HWND). To get an HWND that you can use in the unmanaged part of your application, cast Handle.ToPointer() to an HWND.

6. Implement a managed class that contains a static field that holds a reference to your WPF content object.

• Allows you to get a reference to the WPF content object from your Win32 code.
• Prevents your HwndSource from being inadvertently garbage collected.

7. Receive notifications from the WPF content object by attaching a handler to one or more of the WPF content object events.
There is a good example, with code, from Microsoft Support where they attach an MFC-style handler to the WPF control’s cut and paste events: Hosting a WPF Control in MFC and Enable Cut-and-Paste. I used this sample code as a model to implement steps 5, 6, and 7.

8. Communicate with the WPF content object by using the reference you stored in the static field to set properties, call methods, etc.

For the steps I took above, I used Visual Studio 2008 SP1, .NET Framework 3.5, and MFC 9.0. I also used a slide deck on WPF Interop from Jaime Rodriguez, who was one of the presenter/instructors in the WPF LOB Training Tour I attended a few months back. The following are some quick bullet notes I took in his “Tips and Tricks” session on WPF Interop. (These are my notes I took while Jaime was presenting, so it is a mix of what he presented and what I was thinking. They are not a direct transcription of what Jaime presented.)

• A Win32 app hosting a WPF control needs to be compiled with /clr.
• No nested hooks: can’t do something like host WPF in WinForms in Win32 or host WPF in Win32 in WPF. No guarantees.
• Issue: WinForms control dialogs always come up on top. Workaround: WPF popup (window) that shows over the WinForms control.
• Example of Win32 hosted in WPF: Microsoft Expression Design. The canvas is Win32, everything else is WPF.
• Obviously, hosting Win32 or WinForms in WPF allows for reuse of complex code that does not need to be rewritten.
• Another example of Win32 hosted in WPF: Blockbuster Video app. WPF app contains Windows Media Player, which is Win32. Rationale: Windows Media Player performance is currently better than WPF video player because Windows Media Player is more advanced—team has been developing it longer, it uses the hardware better.
• Although WinForms and WPF interoperate (via a mechanism like WinFormsHost in WPF), cannot directly convert WinForms designs to WPF designs because WinForms designs serialize to code, while WPF designs serialize to XAML.

Most of the examples and discussion out there addresses hosting Win32 components in WPF app shells because new apps from scratch are generally written in WPF, with reuse of Win32 components (likely drawing components written using GDI that does not need to be rewritten immediately to support DirectX). Hosting WPF in Win32/MFC is less common, but does provide a migration path toward WPF when has an existing application but wants to make use of some of the new GUI technology. One thing to take into consideration in both cases is planning the layout (and considering the “airspace”). Designate regions of the app (like a document/drawing canvas or a major control panel) to be Win32 while the remainder of the app is in WPF, rather than mixing and matching Win32 and WPF ad hoc, a Win32 button here, a WPF button there.

References
Microsoft. (n.d.). WPF and Win32 Interoperation Overview. Retrieved on July 7, 2009, from http://msdn.microsoft.com/en-us/library/ms742522.aspx#.

Microsoft. (n.d.). Walkthrough: Hosting Windows Presentation Foundation Content in a Win32 Application. Retrieved on July 7, 2009, from http://msdn.microsoft.com/en-us/library/ms744829.aspx.

Microsoft. (2008). Hosting a WPF Control in MFC and Enable Cut-and-Paste. Retrieved on July 7, 2009, from http://support.microsoft.com/kb/959082.

Miranda, T. (2009). WindowsClient.NET: Video Training – Host a WPF Control in a Win32 Application. Retrieved on July 7, 2009, from http://windowsclient.net/learn/video.aspx?v=13252.

Rodriguez, J. (2009). Jaime Rodriguez on .NET Client: Thanks Chicago. Here is the Content. Retrieved on July 9, 2009, from http://blogs.msdn.com/jaimer/archive/2009/06/16/thanks-chicago-here-is-the-content.aspx.

Sells, C., & Griffiths, I. (2007). Programming WPF: Building Windows UI with Windows Presentation Foundation (2nd ed.). Sebastopol, CA: O’Reilly Media.

Software Inspections: Literature Review with an Emphasis on Empirical Evidence of Effectiveness

I originally wrote this literature review on Software Inspections, with an emphasis on empirical evidence, in December 2007 for a course on Software Verification and Validation. I wanted to publish it on the web because a good portion of the literature that I reviewed is inaccessible to software practitioners and the general public. (One has to pay exorbitant fees to get access to the full-text journal articles and some of the articles that were previously published on the web have since disappeared.)

Abstract
The software engineering community, researchers and practitioners, accept software inspections as a basic and essential tool in conducting software verification and validation activities. In terms of untestable work products such as requirements specifications and design documents, inspections may be one of the few available tools to conduct an effective verification and validation of these work products. However, many in the community want to know how effective inspections actually are, in empirical terms, and how to make them both more effective and efficient in detecting the maximum number of errors with a minimal amount of effort or cost.

In this review of the literature on inspection technologies, the Fagan Inspection is used as a baseline for study and evaluation as it is the most well known inspection technique. Since Fagan (1976), others have noted problems and limitations of the Fagan Inspection technique and proposed their own inspection techniques. Two major variants include Active Reviews by Parnas and Weiss (1985) and Phased Inspections by Knight and Myers (1991). More recent inspection techniques focus on the changing nature of the software industry, in terms of how software teams work and the types of software being developed. Specifically, recent variations on inspections address the impact of globalization (distributed teams, outsourcing, offshoring) and the advent of the World Wide Web (distributed technologies, decentralized architectures). All variants attempt to address flaws in the Fagan Inspection technique with the hopes of making inspections more effective and efficient. Although publications describing the varying inspection techniques claim effectiveness through a case study of a single instance or application, few are able to show the improvement empirically.

Although there is a lack of empirical data that covers broad applications to prove the effectiveness of inspections and to calculate the return on investment of inspection activities, the varying inspection research and techniques still contribute to the larger verification and validation toolkit. Software engineers and software project managers are currently not able to use empirical data to make and justify their decisions on the varying inspection techniques, but they are able to pick and choose from a rich variety of options to suit their application. However, researchers are continuing to improve upon inspection techniques and study how to reliably measure and compare techniques to provide empirical data for decision making. There is no consensus on a “best” inspection technique, but rather the consensus among the research community is that there is still a lot of further study to be done to better understand inspections.

Software Inspections
Experienced software engineers and software project managers recognize that the earlier errors are detected in the software lifecycle, the less costly it will be to resolve the error. As a result, software engineers and project managers plan verification and validation activities into the development lifecycle to detect errors as early as possible in the lifecycle. One of the most well known verification and validation activities is the software inspection, a staple of many verification and validation toolkits and plans. The Software Engineering Institute (2001) defines software inspection as a disciplined engineering practice for detecting and correcting defects in software artifacts, and preventing their leakage into field operations. Where testing can only verify executable work products, software artifacts that can be inspected include requirements specifications, software designs, source code, test plans, and test procedures. The goal of this paper is to present software engineers and software project managers with a survey of available inspection techniques with an empirical evaluation of their effectiveness to allow for software engineers and project managers to not only identify inspection as a necessary activity in a verification and validation plan, but to choose the techniques that are most appropriate for their projects.

Fagan Inspection
The Fagan Inspection is the most commonly cited software inspection technique in software engineering literature. In a sense, the Fagan Inspection is a standard software inspection technique as its essence is included in the IEEE Standard for Software Reviews (1997). Developed by M. E. Fagan in 1972 at IBM, the Fagan Inspection consists of six steps: (1) Planning, (2) Overview, (3) Preparation, (4) Inspection, (5) Rework, and (6) Follow-Up. Compared with walkthroughs, which are informal and consist only of two steps, Preparation and Walkthrough, Fagan Inspections are a more formal alternative requiring an inspection team, with each member playing a role: moderator, designer, coder, or tester.

Fagan’s original work included an empirical evaluation of his documented inspection technique in finding errors. Fagan (1976) showed that inspections caught 82 percent of the errors in the application under case study. Although the findings proved successful for that particular case, Fagan later showed in follow-up work that the effectiveness of an inspection depends on how the inspection was conducted. Fagan (1986) noted that well-conducted inspections resulted in the discovery of 82 and 93 percent of all defects in two specific case studies. However, in cases where inspection moderators were not trained or inspection was conducted on a limited portion of the development lifecycle, defect discovery rates were slightly over 50 percent. Fagan (1986) considered these reduced rates to be a success given the shortcomings of the inspections performed with limitations, but the high rate of variation between moderately successful and highly successful inspections served as an indication to others that inspection techniques could be improved to provide more consistency in finding defects.

Active Reviews
Parnas and Weiss (1985) developed Active Reviews, an alternative inspection technique that addresses the limitations of Fagan Inspections. In describing the motivation behind Active Reviews, Parnas and Weiss (1985) detail the problems of traditional (Fagan) inspections, including: reviewers being overloaded with information and not having sufficient time to work with it, reviewers not being familiar with all of the requirements and constraints imposed on the artifact under inspection, and reviewers attempting to examine all of the artifact without focusing on the parts they might be most familiar with. In an attempt to address these shortcomings, the Active Review technique involves: inspectors working on a single technical area, inspectors working alone, authors of the artifact supplying questionnaires to the inspectors to check comprehension, all of which results in individual discussions between each inspector and the author to arrive at agreed-upon feedback that results in product rework.

Although Parnas and Weiss (1985) mention in their conclusions that they were convinced that Active Reviews achieved their review objectives and that the problems with Fagan Inspections had been addressed, there was no experimental study conducted. That is, there was no formal experiment that compared Active Reviews against a control or baseline method of Fagan Inspections. Despite no empirical evidence existing that shows the effectiveness of Active Reviews, a search of the literature today (in the ACM Digital Library, CiteSeer, or IEEE Computer Society Library) reveals many dozens of papers citing Parnas and Weiss (1985). In essence, the software engineering community generally accepts Active Reviews as an effective practice based on a logical and sensible rationale, even though no empirical evidence shows it to be more effective than Fagan Inspections.

Phased Inspections
Following on Fagan’s work, Knight and Myers (1991) developed an improved inspection technique, Phased Inspections. Knight and Myers recognized several shortcomings in the Fagan Inspection technique, many of them similar to what Parnas and Weiss (1985) found. Knight and Myers realized that there is generally too much material to check in a single inspection activity. Instead of having one inspection meeting as in the Fagan Inspection, the Phased Inspection technique involves conducting an inspection as series of tightly focused steps (phases) instead of in one inspection meeting.

Each inspection phase may involve either a single or multiple inspectors and each phase is concerned with inspecting only one specific quality goal. The inspector responsible for checking for a particular goal assumes that other quality goals either have been checked by other people in a previous inspection phase or that they will be checked in an upcoming inspection phase. This allows for inspectors, individual or group, to remain focused on reviewing one specific aspect of a work product instead of having to try to examine the entire product. For example, a Phased Inspection of source code may consist of four inspection phases: a source code format inspection, a documentation (code comment) inspection, a module-internal logic inspection, and a module-external interface inspection. In a Fagan Inspection, all of the concerns would be addressed in one meeting and source code formatting issues may end up distracting attention away from module-internal issues. The premise behind Phased Inspections is to provide more focus in each of the inspection phases to result in a more effective overall inspection effort.

Although Knight and Myers (1991) conclude that Phased Inspections are an improvement over the well-accepted Fagan Inspection, Knight and Myers only mention that preliminary data supports their conclusion. The preliminary data mentioned was the result of an experiment conducted for a masters thesis, but the data does not appear in a published peer-reviewed journal. As with Active Reviews, Phased Inspections have some level of acceptance in the software engineering community based on the number of citations in the literature on inspections, but no empirical evidence supports inspections, of any form being predictably effective.

Recent Trends in Inspections
Recognizing that major improvements could be made to the traditional Fagan Inspection technique, more recent literature presents both techniques specific for the domain of the system and techniques arising as a result of the evolving nature of software projects. In the last decade, the software industry has shifted from developing all applications in-house to either outsourcing part or most of their software development projects. In addition, software development teams within an organization may not be co-located, but rather be distributed across the country or around the world. The nature of the software applications themselves has evolved in the past decade as well: instead of having standalone applications that are completely self-contained, many applications now consist of multiple components and use services external to the application. For example, applications developed using rapid development frameworks and code generators (as in Microsoft Visual Studio), applications that use open-source components, applications that are developed for the World Wide Web. Each of these examples present cases where conducting a traditional inspection only makes sense if the inspection is tailored particularly for the application.

Stellman and Greene (2006) detail a variant of the Fagan Inspection technique for software development in situations that involve outsourcing as most inspection techniques described in the literature assume that all software is developed in house. Similarly, Tom Gilb, an author of a textbook on classical (Fagan) inspection techniques (Gilb, Graham, & Finzi, 1993), now has new material that describes inspection techniques for Agile software projects (Gilb & Gilb, 2007). Additional research in Agile Software Methods (Phongpaibul & Boehm, 2006) shows that a separate inspection activity may not be necessary, but may rather be counter to the objectives of the Agile Methodology. Some instances of the Agile Methodology call for Pair Programming (Cockburn & Williams, 2000), where programmers work together as a pair while they are coding. The rationale is that one person will be writing code, and the other will be both helping and checking as the code is being written. In essence, the second person of the pair acts as an inspector (as in Fagan Inspections) while the code is being written and asking questions (as in Active Reviews). Since these authors claim that Pair Programming is in effect combining the coding activity with the inspection activity, a separate inspection activity or process is not needed. Although this claim may be true for code, traditional inspections may still play a role in the Agile Methodology as only programming is done in pairs. That is, there are still other artifacts and work products developed in the Agile Methodology (artifacts that correspond to traditional requirements specifications, design documentation, and test plans) that still need to be verified and validated.

The Search for Empirical Evidence
Where the results of Fagan’s original study are often cited, where inspections can detect approximately 50 to 90 percent of software errors, few studies since then have been able to state conclusions based on empirical evidence, rather than on the results of a case study. This is likely due to the fact that most studies, including Fagan’s original study, are conducted on real-world production applications and that establishing the components necessary for a valid experimental design. For instance, in a production project, few organizations would have the resources allocated or the motivation to conduct a parallel inspection effort just to make comparisons. Likewise, an academic study of a theoretical application would not reflect the scale and issues involved in developing production software. In either case, results obtained from a case study, including Fagan’s original study, reflect the situation under study, including the software development process and the people employed on the project.

Given these limitations, there have been some recent studies that attempt to provide empirical data to help evaluate the effectiveness of inspections. Porter, Siy, Marcus, and Votta (1998) focus on creating an model not to evaluate inspections directly, but to rather identify the sources of variation in inspection activities. Identifying the sources of variation allows for software engineers to have a greater understanding of what specifically determines the effectiveness of a software inspection effort to both maximize the defect detection rate and to make the defect detection rate more consistent and predictable. Porter et al (1998) found that the inputs to the inspection activity created the most variation in an inspection effort, compared to the process by which the inspection was conducted and the structure of the inspection team.

In addition to evaluating inspections from a software engineering point of view, Biffl and Halling (2003) conducted a cost-benefit analysis on software inspections to provide more perspective from a software project management point of view. Although many software engineers would agree that inspections are an essential and beneficial tool in the verification and validation process, inspections are expensive activities in a project due to the number of people involved in an inspection team and the amount of time spent preparing and conducting the inspection activities. A cost benefit analysis views inspection activities as an investment in a software project. That is, Biffl and Halling (2003) sought to understand how to allocate sufficient resources to perform inspections that result in beneficial returns through effective and early defect detection, while not overspending effort and resources that result in diminishing returns. Although the authors did not explicitly state it in their conclusions, it is evident that the effectiveness-versus-cost relationship of software inspections follows the Pareto principle, better known as the 80-20 rule. This observation is supported by the Biffl and Halling’s (2003) conclusion that investing a moderate amount into a software inspection effort results in significant detection of defects while investing beyond that amount results in limited gains for the effort spent.

Conclusions
As versatile as software inspections are throughout the development lifecycle, the effectiveness of inspections in detecting errors is not necessarily guaranteed by their execution alone. The effectiveness of a software inspection depends on how the inspection is conducted. The majority of the literature on software inspections shows ways to improve how software inspections are performed, using the Fagan Inspection as the baseline. However, few facts about inspections have been proven empirically through solid experimental design.

Researchers and practitioners often cite Fagan’s original defect detection rates of 50-90 percent detection using inspections, or similarly state that inspections will find the majority of defects in work products. However, few have shown improvements in Fagan’s original results: either by increasing the percentage of errors detected or by narrowing the variance between moderately and highly effective inspections. Instead, improvements have been focused around matching inspection techniques to the current state of the software industry in terms of how software teams work together (processes) and the types of software they are working on (products). This may be discouraging for some as without solid empirical evidence, one wonders how one can make decisions on inspections in verification and validation activities.

There is no silver bullet when it comes to software inspections, and as of today, there is no “best” inspection technique and no easy formula to calculate the return on investment when it comes to conducting inspections. However, what software engineers and software project managers have at their disposal are a library of software inspection techniques they can add to their toolkit and many rules of thumb on when to conduct inspections and how much effort should be put into them. As with many other issues in software engineering, the software engineer and project manager should view inspections as a customizable tool they can use to achieve the objectives of detecting errors and detecting them early in the lifecycle to help reach the overall goals of delivering a high quality product at the lowest possible cost by first assessing the situation, knowing the inspection tools they have available, and choosing (or synthesizing) the right ones for the situation.

References
Biffl, S., & Halling, M. (2003). Investigating the Defect Detection Effectiveness and Cost Benefit of Nominal Inspection Teams. IEEE Transactions on Software Engineering, 29(5), 385-397.

CeBASE: NSF Center for Empirically Based Software Engineering. (2003). eWorkshop on Software Inspections and Pair Programming. Retrieved on December 1, 2007, from http://www.cebase.org/www/home/index.htm.

Cockburn, A., & Williams, L. (2000). The Costs and Benefits of Pair Programming. Proceedings of the First International Conference on Extreme Programming and Flexible Processes in Software Engineering.

Fagan, M. E. (1976). Design and Code Inspections to Reduce Errors in Program Development. IBM Systems Journal, 15(3).

Fagan, M. E. (1986). Advances in Software Inspections. IEEE Transactions on Software Engineering, 12(7).

Glib, T., Graham, D., & Finzi, S. (1993). Software Inspection. Boston, MA: Addison-Wesley.

Glib, T., & Gilb, K. (2007). Agile Inspection. Retreived on December 1, 2007, from

http://www.spipartners.nl/data/train_course/gilbinspect_agile_en.php.

Knight, J. C., & Myers, E. A. (1991). Phased Inspections and Their Implementation. ACM SIGSOFT Software Engineering Notes, 16(3), 29-35.

IEEE. (1998). IEEE Std 1028-1997: Standard for Software Reviews. Los Alamitos, CA: IEEE Computer Society Press.

Parnas, D. L., & Weiss, D. M. (1985). Active Design Reviews: Principles and Practices. Proceedings of the 8th International Conference on Software Engineering.

Phongpaibul, M., & Boehm, B. (2006). An Empirical Comparison Between Pair Development and Software Inspection in Thailand. Proceedings of the 2006 ACM/IEEE International Symposium on Empirical Software Engienering.

Porter, A., Siy, H., Mockus, A., & Votta, L. Understanding the Sources of Variation in Software Inspections. ACM Transactions on Software Engineering and Methodology, 7(1), 41-79.

Software Engineering Institute. (2001). Software Inspections. Retreived on December 1, 2007, from http://www.sei.cmu.edu/str/descriptions/inspections_body.html.

Stellman, A., & Greene, J. (2006). Applied Software Project Management. Sebastopol, CA: O’Reilly Media.

Setting up Apache Thrift

The following are my notes on setting up Apache Thrift (formerly Facebook Thrift) on a Ubuntu 9.04 (Jaunty Jackelope, Desktop Edition) with default configuration.

1. Download and install prerequisite packages.
Either go through the Synaptic Package Manager or do a sudo apt-get to download and install the following packages:

• g++
• libboost1.35-dev
• autoconf
• flex
• bison
• libtool
• subversion

2. Check out a working copy of Thrift using Subversion.
This will create a thrift directory underneath the current directory you are in.

• svn checkout http://svn.apache.org/repos/asf/incubator/thrift/trunk thrift
• cd thrift

3. Build and install libraries.
In the Thrift working copy folder, run the following commands:

• ./bootstrap.sh (only need to do this one time after checkout)
• ./configure
• make
• sudo make install (and make note of the directories that the various language libraries are installed in)

At this point, Thrift is ready for use, at least in Ubuntu.

References
Apache Software Foundation. (2009). Apache Thrift. Retrieved July 5, 2009, from http://incubator.apache.org/thrift/.

Apache Software Foundation. (2009). Thrift Wiki. Retrieved July 5, 2009, from http://wiki.apache.org/thrift/.

perspectives on rain

And now for a sharing moment from Ken…

I used to feel quite melancholy on rainy days. I’d have to begrudgingly wake up to dim gray skies, gripe in traffic about how people can’t drive when it’s raining, and considered my day a loss. But one day not long ago, the skies dumped down rain on me while I was dayhiking on North Seymour Island in the Galapagos. Being in a protected national park, there were no buildings to shelter me from the rain, and the boat was at least 30 minutes to an hour from coming to pick us up. But this time, uncharacteristic of me, I laughed and let the rain fall on me. While most everyone else was standing on water’s edge complaining to the tour guide about the boat not being here faster, I got into the water with Alicia to check out some of the marine iguanas and Sally Lawrence crabs that were climbing the rocks and tried taking some pictures with her new waterproof camera.

Moments before the storm:

Alicia on the beach:

Me on the dinghy after it picked us up (click on the photo for an interesting dialogue in the comments):

Upon getting back to the schooner and having an Ecuadorian Pilsener beer, I felt glad that I didn’t let the rain bring down my first day in the Galapagos. But surely, I was only happy because I was on vacation, right?

So that was this past March. A month later in April, I went downtown to the National Mall for the Earth Day celebration, camera in hand, ready to check out the exhibits and photowalk around the concert. Again, clouds rolled in and the downpour began. No umbrella on hand, no poncho in my backpack, and this time, I’m carrying my camera and lenses, which are not waterproof. My Crumpler camera bag is waterproof, but I figured when they say waterproof, they generally mean misty rain, not sheets of rain.

I stowed my camera and looked up to see a scene of chaos that no camera could capture. Some people sprinting full speed toward the museums, some opening their arms to the sky, some starting a game of football, and some just doubled-over laughing with their friends. And then there was me, by myself, fully soaked and getting even more so by the second, walking slowly and listening to the combined crunching and squishing noise the gravel was making at my feet, looking around, and laughing to myself, in that relieved, freeing laughter sort of way, knowing that rainy days don’t have to be bum days for me anymore. I was so glad to be out, even glad to be in the rain to witness the spectacle. The rain tapered off a little bit and I got my camera back out (carefully, with a plastic bag around it) to see if I could at least try to capture the notion that rain can even make the day more fun and in a sense, even can bring down inhibitions.

For example, these people probably wouldn’t have jumped into this fountain at the National Gallery of Art if it were just a regular sunny day:

Note the unused umbrellas in the lower left:

I recall these guys commenting that it’s probably drier in the fountain than it is in the torrent of rain:

Not shown are the people who offered me a beer from their cooler at the top of the steps at the National Gallery of Art, West Building. And the security guard who was kind enough to look the other way while I was drinking it.

I haven’t had a gloomy rainy day since. Now, when I see rain coming, I think of the two particular experiences above (and it’s nice having some pictures of them) and wonder what will be my next rainy day story. My more recent memories of rainy days include laughing with coworkers about how the rental car company wasn’t going to appreciate us bringing our car back after driving it through a hailstorm, looking at the flood of neat rainbow pictures in the DC flickr pool after one recent rainstorm, and today, writing this entry, recognizing that the rain itself has helped me find an element of peace in my life that I didn’t have before.

licensing versus certification of software engineers

The following is a short, informal piece I wrote for a class last year while we were debating whether or not software engineers should be licensed. The debate continues in real life as the software industry as a whole is trying to find agreement on the issue of whether or not software engineers should be licensed.

In casual English, licensing and certification have similar meanings. However, in the context of the debate on whether software engineers should be licensed like traditional Professional Engineers (PEs), licensing and certification have very distinct meanings.

The following are definitions from Knight and Leveson (2001), ACM Task Force on Licensing of Software Engineers Working on Safety-Critical Software. The notion of licensing is to have some authority grant permission to an individual to engage in an activity that is otherwise unlawful.

Similarly, certification assures that an individual meets a minimum set of requirements.

Licensing and certification differ primarily in the permission to act. Licensing is mandatory and is a state or federal activity (usually state) while certification is voluntary.

The local governments in Texas and provinces in Canada are licensing software engineers today as PEs with legal rights. Meanwhile, other professional organizations in industry are in the business of certification. For example, the IEEE has the Certified Software Development Professional (CSDP) program, the Project Management Institute has the Project Management Professional (PMP) program, and of course many are familiar with the gamut of technical certification programs like the Microsoft Certifications.

My point is, if we software engineers are going to discuss/debate this topic and be understood, we should aim to be precise in our wording. It’s the only way we can all understand what someone really is saying instead of making assumptions and implications. I know, this sounds like an advertisement for good requirements analysis and specification techniques.

Now for the alarming part. If one takes note of the Texas PE exam requirements one will find that their exam has little to do with software engineering as it is typically treated in academia and in industry. Searching around on their website, I found Texas Board of Professional Engineers meeting minutes (pdf) (2005) where they decided to use the IEEE CSDP certification exam for licensing software engineers as PEs in Texas until a better exam comes around. From the minutes, “IT WAS MOVED AND SECONDED (Frailey/Rodriguez) that the Board accept the CSDP examination as an interim substitute for a PE exam in software engineering, until such time as a national exam is provided by NCEES and reconsider the licensure of software engineers.”

To me, this is not a real confidence builder in their system of licensure — I just think Texas jumped the gun a little. Before we as a software community have understood what the implications of licensing are and before we decided on what the best means of licensing are, Texas already started issuing licenses to legally allow people to do things, while considering to use a minimum certification exam to allow them to do it. One would like to think that if licenses are being issued to people who are trusted to do something safety-critical like design software for an aircraft system or a medical device, they should know more than the minimum requirements. The Texas exam, and any exam really, determines a minimum level of knowledge, but it does not determine competence or mastery.

References
IEEE Certified Software Development Professional Program. Retrieved May 30, 2007, from http://www.computer.org/certification

Knight, J., Leveson, N. et al. (2001, August). ACM Task Force on Licensing of Software Engineers Working on Safety-Critical Software. Retrieved May 30, 2007, from http://www.acm.org/serving/se_policy/safety_critical.pdf

Microsoft. Microsoft Certifications Overview. Retrieved May 30, 2007, from http://www.microsoft.com/learning/mcp/default.mspx

Project Management Institute. Certification Project Management Professional Overview. Retrieved May 30, 2007, from http://www.pmi.org/info/PDC_PMP.asp

Texas Board of Professional Engineers. Examination Information. Retrieved May 30, 2007, from http://www.tbpe.state.tx.us/lic_exams.htm

Texas Board of Professional Engineers. (2005, August). Minutes, Industry Advisory Committee, August 16, 2005. Retrieved May 30, 2007, from http://www.tbpe.state.tx.us/minutes/ind_81605.pdf

washingtonpost.com redesign, round 3

Last April, I wrote a full-length post here on this blog on what I thought was wrong with the washingtonpost.com redesign. Two days later, I wrote a follow up on this blog containing my posted comment to washingtonpost.com editor Jim Brady. Shortly after that post, I wrote a short follow-up on Edward Tufte’s Ask E.T. forum topic on the redesign. The text of my post in the Ask E.T. forum appears below.

You might appreciate seeing this marketing piece on Apple’s website that profiles both Mr. Jim Brady, executive editor of washingtonpost.com and Ms. Jenn Crandall, the producer of OnBeing. It sheds a lot of insight as to why washingtonpost.com is the way it is today.

http://www.apple.com/pro/profiles/washingtonpost/

A couple of things to put into perspective… washingtonpost.com is an entity separate from The Washington Post newspaper, both part of Washington Post Newsweek Interactive (WPNI). Obviously, the web site draws from the work of the print newspaper as well as from its reporters, but from what I’ve read in the corporate information, washingtonpost.com is there to cull highlights from the paper for the web and provide web-only features. What I’m saying here is that the organizational hierarchy probably plays into the organization of the website. Hence, the washingtonpost.com logo is not the same as the masthead of the print paper and we see that the “print edition” or “today’s paper” as it’s labeled now has always seemed kind of detached from the remainder of the page.

Second, I’m sure we’re all aware of the pressures that traditional newspaper organizations face. Subscriptions are decreasing, ad revenue is decreasing, and as a result, newsrooms are shrinking. I get the feeling that washingtonpost.com has become the experimental proving grounds to find a new revenue source to make up for lost traditional revenue. In the words of one of my friends in the news industry, “we’re trying anything and everything to see what sticks.

Hence, they are trying to work all sorts of media into washingtonpost.com. Not all of it is bad, but of course, the problem is as Mr. Tufte stated, the Washington Post is a news organization — that is its reason for existence. The fanciest multimedia and the neatest interface can’t make up for a lack of depth in the content, which is going to be the trend if they continue to shrink the newsroom.

– Kendrick Hang (email), April 12, 2007

The marketing video has changed since then, but the spirit of it is still the same. And if you go to washingtonpost.com right now, you will still see two logos: one for washingtonpost.com and one for the Washington Post. I have a correction to my above post though: the parent company is not Washingtonpost.Newsweek Interactive (WPNI), but rather The Washington Post Company. WPNI is in charge of washingtonpost.com and newsweek.com, while The Washington Post Company is parent to The Washington Post, WPNI, Express, Newsweek, Slate, Arthur Frommer’s Budget Travel, and Kaplan (the educational services company), among other ventures.

Now, in this week’s Washington City Paper, a story on what I mentioned above: One Mission Two Newsrooms. In addition to the story, the City Paper made a video to show how geographically separated washingtonpost.com is from The Washington Post.

My point still remains the same: why should readers care and have to differentiate what the corporate organization of The Washington Post Company is? Why are there two navigation structures on their website: one for washingtonpost.com and an alternate structure for the print edition of Washington Post (under the link Today’s Paper)? To us, it’s all one single newspaper. If I spot an article in the Food section on Wednesday, I have to figure out if it appears in the Arts and Living section on the washingtonpost.com main page or if I have to go under the Today’s Paper link to find it the Food section under the print edition Washington Post.

Maybe this is just a classic problem in DC. Is the Washington Post just a reflection of the turf wars and bureaucratic infighting that is so common in so many workplaces around the region? This is definitely not the first time I’ve encountered multiple people or divisions in an organization vying for influence without regard for the greater organization. I will admit however that integration, within organizations and within the context of design is quite challenging. However, I still believe in the bottom line: people external to an organization, particularly customers and users, should not have to be exposed to the bureaucracy within the organization, especially in the form of design.

my photo policies

After several years of having an informal policy in my head regarding the rights to my photos, I decided to finally put it in writing. These policies apply to any photos I publish on the Web, particularly those appearing in my Flickr photostream. Each photo in my photostream will have a (c) or (cc) designation noted beneath it.

Photos designated as “(c) All Rights Reserved” are fully copyrighted. No reproduction or distribution without prior permission is allowed. However, if you appear in a photo, you are welcome to a copy of that photo for your personal use — my way of saying thanks for being in the photo — ask me if you would like an original full-resolution file or a print (my complements).

Photos designated as “(cc) Some Rights Reserved” are licensed as “Attribution Non-commercial No Derivatives” (English, legalese) through Creative Commons. Everyone is welcome to reproduce and distribute, without modification, for non-commercial purposes as long as attribution (name credit) is provided. This is my way of contributing to the spirit of the web and sharing some of my work for the world to use, for free.

After taking Pfaffenberger’s class in college I know this policy is not very enforceable on the Web, where copying is easy and rampant. Plus, I know that copyright laws were written in an era prior to the Internet and information age, so interpretations can sometimes get hazy. Theoretically, it should still hold up in court if someone out there steals one of my photos for their benefit. It’s amazing how one’s view of copyright changes when one shifts from being a consumer of intellectual property to becoming a producer of intellectual property (IP).

The thing is, I’m not really one of those people who defensively hoards their IP. I feel like if I’m posting something on the Web, I’m doing it because I want to share. This is why I never have and probably never will put watermarks on my photos. Watermarks put ugly clutter into the photo and it doesn’t really protect the photo because someone can just crop it off or work some photo editing magic on it. There is no way to prevent copying. If I really wanted to prevent people from copying something I created, I wouldn’t put it on the Web. What I don’t want to happen is someone taking my stuff and claiming it as their own and/or making a profit off of it.

Flickr Community Manager Heather Champ phrases this all a little more succinctly at the bottom of her About page.

minimizing losses on a late project

The following post is the text of a short paper I wrote for a course in Software Systems Development. The writing style is a little formal for a blog, but I wanted to share because I believe the advice is sound, not just in terms of the citations, but based on my real-world experiences as well. Sometimes it’s hard for me to believe that I’ve been working in software for over a decade…

Although software engineering practice focuses on establishing good project plans from the onset, sometimes it becomes necessary to consider what happens when a project becomes late and over budget. In the case where a project is nearing completion (and one has come too far to cancel the project), there are some project management strategies, specifically relating to project monitoring and control, to minimize the lost revenue for the project.

Monitoring and controlling the staffing level in the project is essential for stabilizing the development cost. Personnel shortfalls are common in projects, so common that Boehm (1991) considers it one of the top 10 risks on any software project. However, according to Brooks (1974), one must resist the temptation to add staff to the project or risk it becoming later, and as a result, more expensive. Adding staff generally increases the communication overhead between project team members and it takes time for new staff to familiarize themselves with the project (Brooks, 1974). The only case where adding staff might help accelerate the project towards completion is where new team members are already familiar with the tasks to be performed, thus reducing the learning curve to understand how the project operates (Glass, 1998).

With a stable development staff working on the project, it is also important to monitor and control the project’s requirements. Wallace and Keil (2004) consider “scope and requirements” to be one of four major risk categories on a project. Scope and feature creep needs to be controlled through the customer and controlled within the development team as well. Using a Requirements Traceability Matrix, the project manager should monitor the development team’s effort to ensure everything being done in the design, implementation, and testing activities is traceable to a stated requirement. Tracing work being performed by the development team back to requirements helps to limit any extra work beyond the stated requirements being done (Wallace and Keil, 2004), which would further delay the project and increase the cost. Glass (1998) also suggests reducing the initial project scope if it is possible with the customer – deferring or eliminating some requirements or features to make the task more feasible.

Despite the pressures of a project being late and over budget, the project manager should continue to monitor and control the project processes, particularly quality control. Glass (1998) suggests that projects often fall behind schedule because there was not enough time originally allocated in the schedule and that 85 percent of project managers extend the schedule as a result. Although extending the schedule may result in revenue loss, conducting the remainder of the project according to the planned processes may minimize the revenue loss. Effective quality management reduces the risk of introducing defects, which would adversely affect cost and schedule in terms of effort required to manage and rework the defects.

In a project that is late and over budget, project managers should reexamine what is known through project monitoring and readjust through project control. The project manager must address the fundamental questions in a project: Who is working on the project? What are they working on? How are they working on it? Finding stable answers to these questions will result in the project being completed with a minimal loss in revenue.

References
Boehm, B. (1991). Software Risk Management: Principles and Practices. IEEE Software, 8(1), pp. 32-41.

Brooks, F. P. (1974). The Mythical Man-Month. Datamation, December, 1974. pp. 44-52.

Glass, R. L. (1998). Short-Term and Long-Term Remedies for Runaway Projects. Communications of the ACM, 41(7), pp. 13-15.

Wallace, L. & Keil, M. (2004). Software Project Risks and their Effect On Outcomes. Communications of the ACM, 47(4), pp. 68-73.