A Technical History of the SEI

More documents

Recommendations

Info

[Barbacci 1995] Barbacci, Mario; Klein, Mark; Longstaff, Thomas; & Weinstock, Charles. Quality Attributes (CMU/SEI-95-TR-021). Software Engineering Institute, Carnegie Mellon University, 1995. http://resources.sei.cmu.edu/library/asset-view.cfm?AssetID=12433 [Barbacci 2003a] Barbacci, Mario; Ellison, Robert; Lattanze, Anthony; Stafford, Judith; Weinstock, Charles; & Wood, William. Quality Attribute Workshops (QAWs), 3rd Edition (CMU/SEI- 2003-TR-016). Software Engineering Institute, Carnegie Mellon University, 2003. http://resources.sei.cmu.edu/library/asset-view.cfm?AssetID=6687 [Barbacci 2003b] Barbacci, Mario; Clements, Paul; Lattanze, Anthony; Northrop, Linda; & Wood, William. Using the Architecture Tradeoff Analysis Method (ATAM) to Evaluate the Software Architecture for a Product Line of Avionics Systems: A Case Study (CMU/SEI-2003-TN- 012). Software Engineering Institute, Carnegie Mellon University, 2003. http://resources.sei.cmu.edu/library/asset-view.cfm?AssetID=6447 [Boehm 1978] Boehm, B.; Brown, J. R.; Kaspar, J. R.; Lipow, M. L.; & MacCleod, G. Characteristics of Software Quality. American Elsevier, 1978 (ISBN 0444851054). [Clements 2005] Clements, Paul; Bergey, John; & Mason, David. Using the SEI Architecture Tradeoff Analysis Method to Evaluate WIN-T: A Case Study (CMU/SEI-2005-TN-027). Software Engineering Institute, Carnegie Mellon University, 2005. http://resources.sei.cmu.edu/library/asset-view.cfm?AssetID=7467 [Gallagher 2000] Gallagher, Brian. Using the Architecture Tradeoff Analysis Method to Evaluate a Reference Architecture: A Case Study (CMU/SEI-2000-TN-007). Software Engineering Institute, Carnegie Mellon University, 2000. http://resources.sei.cmu.edu/library/asset-view.cfm?AssetID=5109 [Jones 2001] Jones, Lawrence & Lattanze, Anthony. Using the Architecture Tradeoff Analysis Method to Evaluate a Wargame Simulation System: A Case Study (CMU/SEI-2001-TN-022). Software Engineering Institute, Carnegie Mellon University, 2001. http://resources.sei.cmu.edu/library/asset-view.cfm?AssetID=5535 [Kazman 1994] Kazman, Rick; Bass, Leonard J.; & Webb, Mike. “SAAM: A Method for Analyzing the Properties of Software Architectures,” 81-90. Proceedings of the 16th International Conference on Software Engineering. ICSE, Sorrento, Italy, May 16–21, 1994. IEEE Computer Society Press, 1994 [Kazman 1996] Kazman, R.; Abowd, G.; Bass, L.; & Clements, P. “Scenario-Based Analysis of Software Architecture.” IEEE Software 13, 6 (November 1996): 47-55. [SEI 2008] SEI News Items. “Fourth Annual SATURN Workshop Attracts International Software Architecture Practitioners.” June 6, 2008. http://www.sei.cmu.edu/newsitems/saturn08post.cfm [SEI 2009a] Software Engineering Institute. “Army Commitment to Strategic Software Improvement Grows,” 17. 2008 Year in Review. Software Engineering Institute, Carnegie Mellon University, 2009. [SEI 2009b] SEI Monitor, January 2009. Software Engineering Institute, Carnegie Mellon University, 2009. http://www.sei.cmu.edu/saturn/2009/Monitor_Jan_09_Small2.pdf CMU/SEI-2016-SR-027 | SOFTWARE ENGINEERING INSTITUTE | CARNEGIE MELLON UNIVERSITY 257 Distribution Statement A: Approved for Public Release; Distribution is Unlimited.
Architecture Tradeoff Analysis Method The Challenge: Determining the Best Architectural Design for Defense Systems Most complex software systems are required to be modifiable and have good performance. They may also need to be secure, interoperable, portable, and reliable. But for any particular system, what precisely do these quality attributes mean—modifiability, security, performance, reliability? The achievement of quality attributes such as these in a software system depends more on the software architecture than on code-related issues: language choice, fine-grained design, algorithms, data structures, testing, and so forth. Software architectures are complex and involve many design tradeoffs. Without undertaking a formal analysis process, an organization developing a system cannot ensure that the architectural decisions made—particularly those that affect the achievement of particular quality attributes—are advisable ones that appropriately mitigate risks. In the early 1990s, there was not a structured and repeatable way of analyzing tradeoffs among quality attributes. Analysis of tradeoffs in quality attributes was ad hoc and intuitive, and there was not a way for architects to explain to other stakeholders in their organizations why they thought their proposed architectures were appropriate or superior to other possible architectures. A Solution: The Architecture Tradeoff Analysis Method In an earlier effort, the SEI developed the Software Architecture Analysis Method (SAAM) as a way of looking at modifiability [Kazman 1994, 1996]. In considering modifiability, SEI researchers realized that there were other quality attributes that were important, and that there are tradeoffs among them. The Architecture Tradeoff Analysis Method (ATAM) emerged from the SAAM as a way of analyzing these other quality attributes [Kazman 2000]. The purpose of the ATAM is to assess the consequences of architectural decisions in light of quality attribute requirements and business goals. An ATAM is an early lifecycle analysis method that is designed to discover risks in decisions that might create future problems in some quality attribute and to discover tradeoffs in decisions affecting more than one quality attribute. Discovered risks can then be made the focus of mitigation activities (further design, further analysis, or prototyping), and surfaced tradeoffs can be explicitly identified and documented. An evaluation using the ATAM typically takes three to four days and gathers together a trained evaluation team, architects, and representatives of the architecture’s various stakeholders. The ATAM consists of nine steps, which include a discussion of business drivers and architecture, and architectural approaches, among other topics. The output of an ATAM is a presentation and/or a written report that includes the major findings of the evaluation. These are typically a set of architectural approaches identified; a “utility tree”—a hierarchic model of the driving architectural requirements; the set of scenarios generated and the subset that were mapped onto the architecture; quality-attribute-specific questions that were applied to the architecture and the responses to these questions; a set of identified risks; a set of identified non-risks; and synthesis of the risks into risk themes that threaten to undermine the business goals for the system. The most important results are improved architectures. CMU/SEI-2016-SR-027 | SOFTWARE ENGINEERING INSTITUTE | CARNEGIE MELLON UNIVERSITY 258 Distribution Statement A: Approved for Public Release; Distribution is Unlimited.
Page 1 and 2:
A Technical History of the SEI Larr
Page 3 and 4:
Table of Contents Foreword Preface
Page 5 and 6:
The Consequence: Undergraduate Soft
Page 7 and 8:
References 131 Expanding the CMMI P
Page 9 and 10:
The Challenge: Configuration Suppor
Page 11 and 12:
References 275 Operational Support
Page 13 and 14:
Foreword Angel Jordan University Pr
Page 15 and 16:
to the SEI on a part-time basis as
Page 17 and 18:
Blaise Durante Deputy Assistant Sec
Page 19 and 20:
synergy between the TRA team’s ob
Page 21 and 22:
Preface This report chronicles the
Page 23 and 24:
Abstract This report chronicles the
Page 25 and 26:
1 Introduction CMU/SEI-2016-SR-027
Page 27 and 28:
Introduction In December 1984, the
Page 29 and 30:
promulgate use of modern techniques
Page 31 and 32:
Interpreting the Charter In creatin
Page 33 and 34:
of Defense and flag officers from t
Page 35 and 36:
(CRADA) funding is available to exp
Page 37 and 38:
Another effective mechanism has bee
Page 39 and 40:
2 Real-Time Embedded Systems Engine
Page 41:
Figure 3: Real-Time Embedded System
Page 44 and 45:
Introduction to Real-Time Embedded
Page 46 and 47:
in those developments. The SEI was,
Page 48 and 49:
general-purpose techniques but with
Page 50 and 51:
Summary DoD systems have traditiona
Page 52 and 53:
Ada/Real-Time Embedded Systems Test
Page 54 and 55:
enchmark. Results of testbed experi
Page 56 and 57:
Distributed Ada Real-Time Kernel Th
Page 58 and 59:
Ada Adoption Handbook The Challenge
Page 60 and 61:
[Hefley 1992] Hefley, William; Fore
Page 62 and 63:
processor utilization. The sample a
Page 64 and 65:
References [AFSAB 1988] Air Force S
Page 66 and 67:
also known as using simplicity to c
Page 68 and 69:
Software for Heterogeneous Machines
Page 70 and 71:
[Barbacci 1986b] Barbacci, Mario &
Page 72 and 73:
The increase in processing capacity
Page 74 and 75:
[Lakshmanan 2011] Lakshmanan, Karth
Page 76 and 77:
analysis as well as model tuning fo
Page 78 and 79:
References [Hansen 2004] Hansen, J.
Page 80 and 81:
or asynchronous networked computer
Page 82 and 83:
3 Education and Training CMU/SEI-20
Page 84:
Figure 4: Education and Training Ti
Page 87 and 88:
making materials available to allow
Page 89 and 90:
course offering, while at other uni
Page 91 and 92:
[DoD 1984] Statement of Work for Im
Page 93 and 94:
The curriculum guidelines also sugg
Page 95 and 96:
Undergraduate Software Engineering
Page 97 and 98:
SEI adapted the Personal Software P
Page 99 and 100:
Software Assurance Curriculum for C
Page 101 and 102:
how they relate to business needs.
Page 103 and 104:
Survivability and Information Assur
Page 105 and 106:
The SEI curriculum and others’ co
Page 107 and 108:
The CSEE conference series also bro
Page 109 and 110:
CMU Master of Software Engineering
Page 111 and 112:
Executive Education Program The Cha
Page 113 and 114:
Professional Training The Challenge
Page 115 and 116:
Education and Training Delivery Pla
Page 117 and 118:
[Ardis 2005] Ardis, Mark. “An Inc
Page 119 and 120:
practical for keeping content curre
Page 121 and 122:
[Johnson 2012] Johnson, Col. Rivers
Page 123 and 124:
4 Management CMU/SEI-2016-SR-027 |
Page 125:
Figure 5: Management Timeline CMU/S
Page 128 and 129:
Introduction to Management When the
Page 130 and 131:
neering CMM [SEI 1995] to describe
Page 132 and 133:
under SEI stewardship in 2009. Deve
Page 134 and 135:
References [Averill 1993] Averill,
Page 136 and 137:
[SEI 1995] A Systems Engineering Ca
Page 138 and 139:
The SEI developed a more explicit m
Page 140 and 141:
[Humphrey 1988] Humphrey, Watts; Sw
Page 142 and 143:
opinion leaders and senior managers
Page 144 and 145:
[Hayes 1995] Hayes, William & Zubro
Page 146 and 147:
move from maturity level to maturit
Page 148 and 149:
The People Capability Maturity Mode
Page 150 and 151:
The SEI Contribution As is the case
Page 152 and 153:
and security process improvement. T
Page 154 and 155:
[Caralli 2004] Caralli, Richard. Ma
Page 156 and 157:
4.6.2.1 CMMI Constellations For CMM
Page 158 and 159:
ity and widespread use of the CMMI
Page 160 and 161:
Expanding the CMMI Product Suite to
Page 162 and 163:
key leaders within that organizatio
Page 164 and 165:
The Smart Grid The Challenge: The N
Page 166 and 167:
ecoming more widespread. As utiliti
Page 168 and 169:
Continuous Risk Management training
Page 170 and 171:
[Alberts 2009] Alberts, Christopher
Page 172 and 173:
The principal motivator for the dev
Page 174 and 175:
References [Carleton 2010] Carleton
Page 176 and 177:
Measurement and Analysis The Challe
Page 178 and 179:
Carnegie Mellon University, 2002. h
Page 180 and 181:
activities. The final set of activi
Page 182 and 183:
[Rombach 1989] Rombach, H. Dieter &
Page 184 and 185:
5 Security CMU/SEI-2016-SR-027 | SO
Page 186:
Figure 6: Security Timeline CMU/SEI
Page 189 and 190:
Introduction to Security In the ear
Page 191 and 192:
The CERT/CC helps guard against dev
Page 193 and 194:
The SEI concern about risks posed t
Page 195 and 196:
Teams (FIRST), which was formed in
Page 197 and 198:
[Killcrece 2008] Killcrece, Georgia
Page 199 and 200:
The CERT/CC built on its vast colle
Page 201 and 202:
Malicious Code Analysis The Challen
Page 203 and 204:
have put advanced tools in the hand
Page 205 and 206:
Secure Coding The Challenge: Preven
Page 207 and 208:
end, the SEI has developed training
Page 209 and 210:
Network Situational Awareness The C
Page 211 and 212:
In 2007, the Comprehensive National
Page 213 and 214:
study. In 2011, the DoD began fundi
Page 215 and 216:
[CSO 2004] CSO Magazine, in coopera
Page 217 and 218:
People who work in small organizati
Page 219 and 220:
[Violino 2010] Violino, Bob. “IT
Page 221 and 222:
Since its initial development in 20
Page 223 and 224:
References [Alberts 2005] Alberts,
Page 225 and 226:
6 Software Engineering Methods CMU/
Page 227 and 228:
Introduction to Software Engineerin
Page 229 and 230:
were delivered to Army and Air Forc
Page 231 and 232:
Configuration Management The Challe
Page 233 and 234:
The SEI Contribution The SEI recogn
Page 235 and 236: CASE Environments The Challenge: Ma
Page 237 and 238: The SEI Contribution The CASE work
Page 239 and 240: Software Technology Reference Guide
Page 241 and 242: Reengineering The Challenge: Legacy
Page 243 and 244: [Bergey 1999] Bergey, John; Smith,
Page 245 and 246: 2. Influence is more important than
Page 247 and 248: [Brownsword 2004] Brownsword, Lisa;
Page 249 and 250: Developing Systems with Commercial
Page 251 and 252: The SEI Contribution When the SEI s
Page 253 and 254: [Tyson 2003] Tyson, Barbara; Albert
Page 255 and 256: system is safe); (2) evidence suppo
Page 257 and 258: 7 Architecture CMU/SEI-2016-SR-027
Page 259: 1984 1986 1988 1990 1992 1994 1996
Page 262 and 263: Introduction to Software Architectu
Page 264 and 265: cation description language, in the
Page 266 and 267: AFSC/ESD conducted a source selecti
Page 268 and 269: [Brown 1995] Brown, Alan; Carney, D
Page 270 and 271: Structural Modeling The Challenge:
Page 272 and 273: The SEI Contribution As a result of
Page 274 and 275: Federal Aviation Administration Stu
Page 276 and 277: evolving understanding of software
Page 278 and 279: The basic features of Serpent were
Page 280 and 281: Software Architecture Analysis Meth
Page 282 and 283: A survey of software architecture e
Page 284 and 285: Quality Attributes The Challenge: M
Page 288 and 289: The Consequence: Effective Evaluati
Page 290 and 291: [Gallagher 2000] Gallagher, Brian.
Page 292 and 293: design with some variation built in
Page 294 and 295: Software Product Lines The Challeng
Page 296 and 297: A software product line curriculum.
Page 298 and 299: 8 Forensics CMU/SEI-2016-SR-027 | S
Page 300: Figure 8: Forensics Timeline CMU/SE
Page 303 and 304: Introduction to Computer Forensics:
Page 305 and 306: ultimate contribution of SEI digita
Page 307 and 308: The SEI’s experience with cases s
Page 309 and 310: Digital Intelligence and Investigat
Page 311 and 312: that not only apply to the specific
Page 313 and 314: 9 The Future of Software Engineerin
Page 315 and 316: A Vision of the Future of Software
Page 317 and 318: In each case, impact is achieved th
Page 319 and 320: e-estimation as a means to assess p
Page 321 and 322: and complexity of these systems are
Page 323 and 324: 10 Conclusion CMU/SEI-2016-SR-027 |
Page 325 and 326: Highlighting 30 Years of Contributi
Page 327 and 328: developed network situational aware
Page 329 and 330: Direct Support to Government System
Page 331 and 332: In the course of these reviews, the
Page 333 and 334: Appendix Authors Contributing to th
Page 335: REPORT DOCUMENTATION PAGE Form Appr
show all

A Technical History of the SEI

Create successful ePaper yourself

Delete template?

Save as template?