A Process Research Framework - Software Engineering Institute ...

More documents

Recommendations

Info

3In an ideal future state,the use of processesis part of acceptedpractice to ensure thatacceptable levels ofproduct qualities are inplace during all stagesof the software andsystem developmentlife cycle.Overall, progress in predicting quality characteristics (and thus validatingquality requirements) early in the development process is mixed.An approach based on measuring internal software metrics was firstproposed in the 1970s [Boehm 1978] and has been the object of manyresearch projects (e.g., the method reported by Boegh et al. [Boegh1999]). However, no effort based on measuring internal software metricshas delivered any major benefits. It is time to recognize that thisapproach does not work. Recent advances in quantitative performanceand reliability prediction are extremely promising. They confirm thevalue of reusing architectures and component-based software development.However, other characteristics such as usability, maintainability,security, and safety can only be measured and predicted qualitatively.Tradeoffs between qualities are only possible using qualitative models.The challenge remains to construct quantitative tradeoff models incorporatingmost (if not all) qualities along with cost (affordability) andschedule (timeliness), as does the need to model and predict qualitycharacteristics of complex systems of systems.3.4 Characterizing the Desired State of thePracticeIn this section, we describe the desired state of practice with respect toproduct qualities when all questions posed in this core roadmap segmenthave been satisfactorily addressed and solutions adopted.In this ideal future state, processes are accepted as one means by whichspecified levels of product qualities can be demonstrated and achieved.The use of processes is part of accepted practice to ensure that acceptablelevels of product qualities are in place during all stages of the softwareand system development life cycle. The relationship between processand specific product qualities is known and can be quantitatively orqualitatively demonstrated (based on the nature of the product quality).Further, processes are effectively used to elicit and capture productquality requirements including their specified levels for given products,markets, types of systems, and the like. The process disciplines andmethods are sufficiently mature to provide confidence that expressingproduct quality requirements using process methods will produce thedesired result in the deployed product.Processes are also effectively used to assist in analyzing and makinginformed tradeoff decisions among all product quality attributes and betweengiven product qualities and business requirements (such as cost,schedule, team competence, risk). Some business requirements can beconsidered as product qualities, such as affordability as an expressionof cost and timeliness as an expression of schedule. Modeling methodsexist for guiding these tradeoff analyses.24 Theme Q | IPRC Framework
In addition, processes are effectively used to test, verify, and validatethat product quality acceptance criteria and acceptance cases are met.Processes exist to assess and audit systems for aiding in making this determination.Measurement processes and defined measures are regularlyused to demonstrate that product qualities continue to be present at therequired level throughout the product life cycle, and in the face of productchanges. (See Bollinger, Voas, and Boasson on persistent software attributes[Bollinger 2004].)3All categories of process described in this section have automated supportto ensure their continued use and ease of use. In the state of the practicetomorrow, we fully expect that the relationship of process to some productqualities will be more mature than for others.3.5 Description of the Research Nodes3.5.1 Research Node Q.1: Eliciting and SpecifyingProduct Quality RequirementsThe objective of this research node is to determine how best to elicitquality requirements (criteria) for a product and how to properly specifythese.Research questions associated with this node include 5Q-1 How can a consumer with limited expertise be facilitated toexpress their needs in a sufficiently prescriptive way?Q-2 How do we specify product quality requirements in general andsuch that they reflect business requirements?Q-3 What levels of product quality are required for specific types ofproducts? For specific markets? How are levels expressed?Q-4 How do we specify product quality requirements in a quantifiable,measurable manner? (How will we know it when we see it?)Q-5 Does the level of need for each ‘–ility’ vary by business domain?If so, how?5 We’ve given each research theme a letter identifier so that the questions associated witheach theme can be more readily identified. We’ve identified this theme on the relationshipsbetween processes and product qualities with the letter Q. Other themes on process engineering(identified with E), managing project processes (P), and process deployment (D)feature the same treatment. In addition, questions associated with the effects of emergingtrends are identified with a T and those in the example instantiation for security with an S.IPRC Framework | Theme Q 25
Page 1: A ProcessResearchFrameworkThe Inter
Page 4: This report was prepared for theSEI
Page 8: viIPRC Framework
Page 11 and 12: Executive SummaryThe discipline of
Page 13 and 14: Forces Driving Process Research Fra
Page 15 and 16: Process Research FrameworkThis docu
Page 17 and 18: MembersTwenty-seven leaders in indu
Page 19 and 20: A colleague from SAIC, Ms. Mary Ann
Page 21 and 22: 1Introductionto the Framework
Page 23 and 24: As the work of the IPRC developed,
Page 25 and 26: 1. The Relationships Between Proces
Page 27 and 28: 2Architecture of theResearch Themes
Page 29 and 30: Managing Project Processes (Section
Page 31 and 32: 2.2 Instantiating the Core ProcessR
Page 33 and 34: The product, process, people, and p
Page 35 and 36: 2. These advances will be followed
Page 37 and 38: 2.4 How Each Theme Presentation isS
Page 39 and 40: 3Theme Q:The RelationshipsBetween P
Page 41 and 42: • security• usability (human-ma
Page 43: plan to address the underlying issu
Page 47 and 48: Q-13 How do we make well-informed d
Page 49 and 50: 4Theme E: ProcessEngineeringThis th
Page 51 and 52: create defined 8 processes for spec
Page 53 and 54: Mechanisms for SpecificationE-5 How
Page 55 and 56: Research questions associated with
Page 59 and 60: 5Theme P: ManagingProject Processes
Page 61 and 62: Developing software across borders
Page 63 and 64: Where higher levels of integration
Page 65 and 66: 5.5.1 Research Node P.1: Operating
Page 67 and 68: P-6 How do we capture and share exp
Page 69 and 70: 5.5.2 Research Node P.2: Managing T
Page 71 and 72: P-27 Do locations need a primary an
Page 73 and 74: 6Theme D:Process DeploymentThis the
Page 75 and 76: Readers need to recognize the criti
Page 77 and 78: Accordingly, processes will be depl
Page 79 and 80: D-6 What is the quantitative relati
Page 81 and 82: The “assess” activity identifie
Page 85 and 86: The objective of process research u
Page 87 and 88: 7 Process Effects ofEmerging Techno
Page 89 and 90: If this sounds like Fred Brooks Jr.
Page 91 and 92: Figure 5 provides a framing of thre
Page 93 and 94: Process ChallengesIntegrated OrHete
Page 95 and 96:
and management of stakeholder expec
Page 97 and 98:
T-18 What replaces “quality = con
Page 99 and 100:
have a comfort level with uncertain
Page 101 and 102:
When trying to integrate in a conte
Page 103 and 104:
T-49 How do we analyze the communic
Page 105 and 106:
8Scenarios
Page 107 and 108:
Jurassic Park(Reconfigurable packs
Page 109 and 110:
Pandemic Triggers Global Instabilit
Page 111 and 112:
Embedded Software Rules(Rapid co-de
Page 113 and 114:
9Sponsor Statements
Page 115 and 116:
We also monitor and evaluate the bu
Page 117 and 118:
Lockheed Martin Corporation IS&S(Pr
Page 119 and 120:
The SEI, with its reputation as a
Page 121 and 122:
As a sponsor, TCS has introduced th
Page 123 and 124:
A passion for innovation lies at th
Page 125 and 126:
Appendix
Page 127 and 128:
Research Node S.2: Establishing the
Page 129 and 130:
Research Node S.6: Usable SecurityT
Page 131 and 132:
Q-16 When composing systems of indi
Page 133 and 134:
E-22 How can we define the scope of
Page 135 and 136:
E-55 What level of statistical anal
Page 137 and 138:
P-10 How do we handle different tim
Page 139 and 140:
P-24 How do we identify suitable pa
Page 141 and 142:
D-16 What organization-based confid
Page 143 and 144:
D-43 What lessons can be learned fr
Page 145 and 146:
T-14 How do you sustain and evolve
Page 147 and 148:
T-46 How do you analyze data collec
Page 149 and 150:
Further Readingand References
Page 151 and 152:
[Boegh 1999]Boegh, J.; Depanfilis,
Page 153 and 154:
[Wang 1999]Wang, W.; Pan, D.; & Che
Page 155 and 156:
[Yoon 2001]Yoon, I.-C.; Min, S.-Y.;
Page 157 and 158:
[Kaba 1995]Kaba, A. B. & Derniame,
Page 159 and 160:
[Becker-Kornstaedt 2002]Becker-Korn
Page 161 and 162:
[Prikladnicki 2003]Prikladnicki, R.
Page 163 and 164:
[Smite 2004]Smite, D. “Global Sof
Page 165 and 166:
[Smith 1996]Smith, M. A.; Mitra, S.
Page 167 and 168:
[Weisbord 1987]Weisbord, M. Product
Page 169 and 170:
Appendix[Beznosov 2005]Beznosov, K.
Page 172:
Julia AllenVic BasiliBarry BoehmGon
show all

A Process Research Framework - Software Engineering Institute ...

Create successful ePaper yourself

Delete template?

Save as template?