SEI Annual Report FY07
Publications |
SEI in the Community |
The 2007 SEI Annual Report describes the accomplishments of the SEI during FY07
(October 1, 2006 through September 30, 2007).
Articles
Baskerville, R., Ramesh, B, Levine, L., and Pries-Heje, J.
"High-Speed Software Development Practices: What Works, What Doesn’t" [login required]
IT Professional 8, 4 (July – August): 29-36
Increasingly short software development cycles have forced software companies and engineers to strike a balance between informal development--in Internet-time--and more traditional agile and plan-driven methods. The authors review six common practices and how they are blended to maximize time-sensitive development.
Callison, R. & Beck, D.
“Becoming a Science Librarian: Accident, Serendipity or Purposeful Plan?” [article available for purchase]
Science & Technology Libraries 27, 1/2 (Spring 2007)
Increasing concern has been expressed in the literature regarding the recruitment and retention of qualified librarians within the profession. Science and Technology Libraries share equally in considering the consequences of this trend. Two Science Librarians, neither possessing a degree in the sciences, will discuss the skills, competencies, and experiences that enable them to thrive in a challenging and dynamic work environment. Descriptive statistics from a survey of other newly hired science librarians, regardless of their science background, will also be incorporated. In addition to exploring perceived strengths, this paper will address the possible disadvantages that the lack of a science “background” may present. Science background will be discussed in terms of having previously obtained a degree in the sciences. The approach to the topic is from the perspective of the new hire (not necessarily a “new” librarian), rather than that of the hiring institution; however, strategies and methods that are useful to both groups will be offered.
Clements, P., Jones, L., McGregor, J., & Northrop, L.
“Getting From There to Here: A Product Line Adoption Roadmap”
Communications of the ACM (December 2006)
The authors outline steps to take and technical and business activities to perform in order to facilitate the successful organizational adoption of a software product line. An SPL organization embodies a trio of mutually supportive operations, namely core asset development, product development, and management. Core assets (plans, requirements, designs, documentation, tests, and code) are used throughout the entire SPL as common resources and can be customized in a predefined way to fulfill the requirements of individual products, while feedback about the assets' quality and usability is generated by product creation. What products to include in the product line is a management decision founded on the existing core assets' capabilities and the market's needs, and managerial oversight is needed to guarantee that the assets are applicable to product development. The Software Engineering Institute's (SEI) Framework for Software Product Line Practice lists many practices for successfully fielding a SPL, and the combination and coordination of practice areas to yield useful outcomes is detailed by product line practice patterns such as Adoption Factory. The process of executing the product line strategy by blending technical and business activities is mapped out by Adoption Factory, which positions an organization to establish a product line context prior to code development and set up real production capability before trying to operate the product line. Time to market and cost can be reduced, while agility, quality, and productivity can be raised by following the SPL strategy.
Donnellan, B., Larsen, T., and Levine, L. (editors)
"Transfer and Diffusion of Information Technology for Organizational Resilience," Journal of Information Technology, 22:1 (March 2007).
This special issue of the Journal of Information Technology is focused on how IT innovation can contribute to making organizations more resilient. Commercial organizations are trying to make sense of the competitive environment and quickly generate new strategic options. Public organizations are struggling to meet societal needs for innovative information services. IT staff have spent much of their energy improving transactional efficiency. IT now needs to be seen as a positive force for making business innovation resilient. Issues such as IT organizational design, social networking, diversity, improvisation, and rich media are all likely to advance our understanding of resilience in this context, and account for an organization’s need to sustain innovation.
Ferguson, R.
"An Empirical Study on the Impact of Automation on the Requirements Analysis Process"
Journal of Computer Science and Technology 22, 3 (May 2007)
Adopting new tools and technologies on a development process can be a risky endeavor. Will the project accept the new technology? What will be the impact? Far too often the project is asked to adopt the new technology without planning how it will be applied on the project or evaluating the technology’s potential impact. In this paper we provide a case study evaluating one new technology. Specifically we assess the merits of an automated requirements analysis tool. First, we provide a background on automated requirements analysis tool technology. Then, using process simulation, we find situations where the use of this new technology is useful and situations where the use of this new technology is useless for large-scale NASA projects that utilize a process similar to the IEEE 12207 systems development lifecycle. The method can be applied to assessing the impact (including Return on Investment), break even point and the overall value of applying any tool on a project.
Firesmith, D. & Capell, P.
“Quality Assessment of Systems Architectures and Their Requirements” [article available for purchase]
Journal of Integrated Design and Process Science 11, 2 (June 2007): 15–31
The quality of a software-intensive system is largely determined by the quality of its architecture and the quality of the architecturally significant requirements that drive its development. Unfortunately, although quality requirements typically have critical architectural ramifications, requirements engineers using such popular techniques as use case modelling tend to emphasize functional requirements over non-functional quality requirements, with the result that the quality requirements are often poorly specified or not specified at all. Similarly, system architects tend to emphasize a system’s logical decomposition structure into major functions and subfunctions and the corresponding static physical decomposition structure into a hierarchy of subsystems. The system architects often do not adequately document how (or even if) these subsystems and subsubsystems collaborate to sufficiently support the achievement of their derived and allocated quality requirements. To address these two problem areas, the SEI QUality Assessment of software-intensive System Architectures and their Requirements (QUASAR) method was created to provide acquisition organizations with a proven and efficient means to determine if quality requirements have been properly engineered and if system architectures sufficiently meet these requirements.
Goldenson, D.
“Tech Views: Performance Results from Process Improvement.” DACS Software Tech News 10, 1 (March 2007).
Goldenson, D. (with Ho-Won, J.)
“The Internal Consistency and Precedence of Key Process Areas in the Capability Maturity Model for Software,” Empirical Software Engineering (August 2007).
Evaluating the reliability of maturity level (ML) ratings is crucial for providing confidence in the results of software process assessments. This study investigates the dimensions underlying the maturity construct in the Capability Maturity Model (CMM) for Software (SW-CMM) and estimates the internal consistency of each dimension. The results suggest that SW-CMM maturity is a three-dimensional construct, with “Project Implementation” representing the ML 2 key process areas (KPAs), “Organization Implementation” representing the ML 3 KPAs, and “Quantitative Process Implementation” representing the KPAs at MLs 4 and 5. The internal consistency for each of the three dimensions as estimated by Cronbach’s alpha exceeds the recommended value of 0.9. Based on those results, this study builds and tests a theoretical model which posits that the achievement of lower ML KPAs sustains the implementation of higher ML KPAs. Results of path analysis using partial least squares (PLS) support the theoretical model and provide detailed understanding of the process improvement path. The analysis is based on 676 CMM-Based Appraisal for Internal Process Improvement (CBA IPI) assessments.
Goldenson, D. (with Rout, T., El-Emam, K., Fusani, M., & Ho-Won, J.)
“SPICE in Retrospect,” Journal of Systems and Software 80, 9 (September 2007).
The SPICE Project was established in 1993 to support the development, validation and transition into use of an International Standard for software process assessment. Its efforts have resulted in the publication of a five-part Standard for Process Assessment, ISO/IEC 15504. This paper reviews the evolution of the Standard, and reflects on the parallel achievements of the SPICE Project and the standardisation effort in advancing the state of the art in process assessment and improvement.
Hofmeister, C., Kruchten, P., Nord, R., Obbink, H., Ran, A., & America, P.
"A General Model of Software Architecture Design Derived from Five Industrial Approaches," Software Architecture Section, Journal of Systems and Software, 2007.
We compare five industrial software architecture design methods and we extract from their commonalities a general software architecture design approach. Using this general approach, we compare across the five methods the artifacts and activities they use or recommend, and we pinpoint similarities and differences. Once we get beyond the great variance in terminology and description, we find that the five approaches have a lot in common and match more or less the “ideal” pattern we introduced. From the ideal pattern we derive an evaluation grid that can be used for further method comparisons.
Humphrey, W.
“Acquiring Quality Software,” Journal of Quality Assurance Institute 21, 2 (April 2007).
If you do not insist on getting quality software, you probably will not get it! That is the first principle of software quality. To get quality software at reasonable costs and on predictable schedules, you must follow the six principles of software quality. This article describes these principles and discusses how to apply them in software acquisition.
“Focus on Watts Humphrey: A Computer Aid, Inc (CAI) State of the Practice Interview," Special edition of the IT Metrics and Productivity Journal (October 2006).
This interview between Watts Humphrey and Michael Milutis, Executive Director of the IT Metrics and Productivity Institute, took place in the Spring of 2006.
“Software Process Improvement—A Personal View: How it Started and Where it is Going,” Software Process: Improvement and Practice.
While the software process improvement movement is relatively recent, the need for improvement is not new. In this paper, the author reviews his personal experiences with software process improvement and describes some of the key events that led to such current widely-used methods as the CMMI, the PSP, and the TSP. He summarizes the principles behind these methods and explains the principal reasons that these highly effective development methods have not been adopted more rapidly. In closing, he notes that their ultimate adoption is inevitable. Copyright © 2007 John Wiley & Sons, Ltd.
“Why Don’t We Practice (What Watts Humphrey Preaches), " Metrics and Productivity Journal (March 2007).
Watts Humphrey looks at the problem of the software community being slow to use data to measure software quality. He discusses the reasons for this problem and describes a way to use process measurements to assess product quality.
“The World Is Getting Soft.” Guest editor, Frontier Journal 3, 12 (December 2006).
Humphrey, W. (with Konrad, M., Over, J., & Peterson, W.)
“Future Directions in Process Improvement,” CrossTalk, The Journal of Defense Software Engineering (February 2007): 17-22.
As systems become larger and more complex, and as increasing numbers of development programs are integrated and distributed, development processes, methods, and management must change. To keep pace with these changes, the directions of process improvement must also change. This article describes the likely future directions of process improvement evolution.
Lewis, G. & Smith, D.
"Four Pillars of Service-Oriented Architecture," CrossTalk 20, 9 (September 2007).
Among current technologies, Service-Oriented Architecture (SOA) has the greatest potential for implementing the vision of migration to net-centric operations. While SOA has been successful in many cases, it has also been marked by a number of expensive failures. This article outlines four pillars to SOA success that include the following: developing an appropriate SOA strategy, implementing effective SOA governance, making sound technology assessments, and accounting for the fact that SOA requires a different mindset. As a result, the article proposes how a Department of Defense (DoD) organization can develop and implement an effective strategy for SOA implementation.
Mead, N. (with Caulkins, J., Hough, E., & Osman, H.)
"Optimizing Investments in Security Countermeasures: A Practical Tool for Fixed Budgets," IEEE Security & Privacy (September/October 2007).
As a software engineer or client, how much of your budget should you spend on software security mitigation for the applications and networks on which you depend? The authors introduce a novel way to optimize a combination of security countermeasures under fixed resources.
Mead, N.
"Experiences in Eliciting Security Requirements," CrossTalk 19, 12 (December 2006): 14-19.
There are many requirements elicitation methods, but we seldom see elicitation performed specifically for security requirements. One reason for this is that there are few elicitation methods specifically directed at security requirements. Another factor is that organizations seldom address security requirements elicitation specifically but instead lump them in with other traditional requirements elicitation methods. This paper describes an approach for doing tradeoff analysis among requirements elicitation methods. Several case studies were conducted in security requirements elicitation. In this paper, the detailed results of one case study and brief results of two other case studies are presented.
An area that is largely neglected in requirements engineering is that of elicitation methods for security requirements. Many organizations, if they use an elicitation method at all for security requirements, use one that they have previously used for ordinary functional (end user) requirements. Alternatively they may decide to use a brainstorming approach. Such methods are usually not oriented towards security requirements and do not result in a consistent and complete set of security requirements.
Carnegie Mellon graduate students, working with me, selected and applied several elicitation methods in a series of case studies . In this paper I describe a tradeoff analysis that we used to select a suitable requirements elicitation method and present results from a case study of one method. While results may vary from one organization to another, the discussion of our selection process and the example results should apply to all.
Mead, N. & Shoemaker, D.
“Producing Alignment-Savvy CIOs,” [article available for purchase]
Cutter IT Journal 20, 2 (February 2007): 29-33.
What mix of skills and expertise makes for a good CIO? Over the years, there have been many lively arguments on the subject. While some believe that a CIO with no formal training or long-term experience in IT is not a "real" CIO, others contend that companies are looking first and foremost for executive leadership. In this issue, we consider the makings of a successful CIO. Hear how CIOs must be able to reason about IT and think strategically—and how these abilities will get you nowhere without the political instincts and skills to survive. Discover how one company healed the business/IT breach through a coaching program that produced the business technology leadership it so desperately needed. And learn how 21st-century CIOs will succeed only if they learn to "de-massify" their investments and embrace "forever learning." Join us as we search for the dream CIO: someone who can keep the lights on and use them to illuminate new paths for the business.
Mead, N., Shoemaker, D., & Drommi, A.
"Maintaining IT’s Corporate Impact Through a Governance Framework," Cutter IT Journal 20, 7 (July 2007): 30-35.
This paper summarizes the relationship between the specifications of the Software Assurance Common Body of Knowledge (CBK) and the curricula of software engineering, computer science, and information systems. It identifies where various CBK elements fit within each curriculum and it provides recommendations for additional study based on those findings.
Medvidovic, N., Krikhaar, R., Nord, R., & Stafford., J.
"Understanding the Past, Improving the Present, and Mapping out the Future of Software Architecture," (Editorial), Journal of Systems and Software, 2006.
"It's been 10 years since David Garlan and Mary Shaw wrote their seminal book Software Architecture Perspective on an Emerging Discipline, since Maarten Boasson edited a special issue of IEEE Software on software architecture, and since the first International Software Architecture Workshop took place. What has happened over these 10 years? What have we learned? Where do we look for information? What's the community around this discipline? And where are we going from here? In this article we review the past, report the present, and describe a future to see Software Architecture through another successful decade."
Nidiffer, K.
"Addressing Software Engineering Challenges Over the Years and Into the Future," Software Tech, 10:3, Department of Defense Information Analysis Center (October 2007).
The tar pit of software engineering will continue to be sticky for a long time to come. One can expect the human race to continue attempting systems just within or just beyond our reach; and software systems are perhaps the most intricate and complex of man’s handiworks – F.P. Brooks
Ozkaya, I. & Akin, O.
“Tool Support for Computer-Aided Requirement Traceability in Architectural Design: The Case of DesignTrack,” Automation in Construction 16, 5 (August 2007): 674-684.
Requirement traceability is the commonly used term to refer to the management of the relationships that exist between design requirements and solutions throughout the design life-cycle. Enabling traceability within computer-aided design assists improving change management, consistency checking, and design compliance verification. DesignTrack is a prototype tool providing an integrated design environment for requirement specification and form exploration in the same design session. DesignTrack provides a navigation environment for complex design information spaces via enabling requirement traceability. This paper describes the design and functionalities of DesignTrack. It evaluates the applicability, power, and drawbacks of requirement traceability enabled computer-aided design by structuring the Leadership in Energy and Environmental Design (LEED) standard requirements with DesignTrack as a case study.
Slaughter, S., Levine, L., Baskerville, R., Pries-Heje, J., Ramesh, B.
"Aligning Software Processes With Strategy," [article available for purchase]
Management Information Systems Quarterly 30, 4 (2006): 891- 918.
Although increasing evidence suggests that superior performance requires alignment between firms’ strategies and production processes, it is not known if such alignment is relevant for software development processes. This study breaks new ground by examining how firms align their software processes, products, and strategies in Internet application development. Drawing upon the literatures in strategy, operations management, and information systems, we identify four dimensions that influence alignment: the business unit strategy, the level of product customization, the level of process customization, and the volume of customers. To examine how these dimensions are synchronized, we conducted detailed case studies of Internet application development
in nine varied firms including both start-ups and established “brick and mortar” companies. Our analyses reveal that the firms in our study do use differing processes for Internet application development, and that many of the firms match their software process choices to product characteristics, customer volume, and business unit strategies. We develop concept maps for the firms that are in alignment to illustrate how managers configure specific product and process dimensions. We also offer potential explanations for why some firms are misaligned, such as attempting to execute incompatible strategies, the lack of coordination between marketing and production strategies, the too rapid expansion of process scope, and inflexible barriers to rapid adaptation of process. Our study contributes detailed insights into how software processes are customized to complement different types of product requirements and strategies.
Woody, C. & Alberts, C.
"Considering Operational Security Risk During System Development," IEEE Security & Privacy
The operational security of software-intensive systems is closely
linked to the practices and techniques used during design and
development of those systems. Many decisions made during development
have an impact on the options for security at implementation. Reducing
software defects is not sufficient for effective operational security.
Development processes must also incorporate mechanisms to consider the
security-related risks inherent in the operational environments where
these systems will be implemented. Increased consideration of the
operational context earlier in the development process provides an
opportunity to adjust development decisions to reduce security risk of
the implemented system.
Zubrow, D. (with Barnard, J., & Emam, K.)
"Using Capture-Recapture Models for the Reinspection Decision," [login required]
CrossTalk 5, 2 (March 2003).
Capture-recapture (CR) models have been proposed as an objective method for improving the effectiveness of software inspections. CR models were originally developed to estimate the size of animal populations. In software, they have been used to estimate the number of defects in an inspected artifact. This estimate can be another source of information for deciding whether the artifact requires a
reinspection to improve the phase containment of defects. This article describes a research project that produced a decision model for the reinspection decision. The resulting decision model yielded significant improvement in determining whether an artifact should be reinspected.