When | What |
---|---|
February 6, 2016 | Updated BibTeX |
December 2, 2003 | Donated by TimMenzies |
This is one of the reuse data sets donated by TimMenzies.
This data set represents an interesting SE problem: how to make sense of software development when very little data (only 23 instances) is availabe for generalization {{{ Number of instances in the data : 24 Number of attributes in the data : 29 }}}
Here are the “high-level control variables” i.e. key high-level management decisions about a reuse program.
{{{
Attribute Value # Notes
—————————— ————– —— ———————————–
Project id 1 .. infinity
—————————— ————– —— ———————————–
Top management ommitment yes 20 top management reuse committed
no 4
—————————— ————– —— ———————————–
Key reuse roles introduced yes 19 >=1 reuse role
no 4 no reuse roles were introduced
—————————— ————– —— ———————————–
Reuse process introduced yes 15 >=1 reuse process was introduced
no 8 no reuse process was introduced
—————————— ————– —— ———————————–
Nonreuse process modified yes 16 >=1 nonreuse processes modified
no 7 no nonreuse processes modified
—————————— ————– —— ———————————–
Human factors yes 16 human factors handled; e.g. via awareness,
training, and motivation programs
no 8
—————————— ————– —— ———————————–
Repository yes 23 assets in repository tool
no 0
}}}
Note that all 23 projects seen in this data set used a repository; i.e. this data set could never be used to refute claims that a repository is useless. Nevertheless, like Morisio et.al., we believe that reuse products have to be kept in some sort of repository to enable reuse.
Here are the “state variables”; i.e. attributes over which a company has no control.
{{{
Attribute Value # Notes
—————————— ————– —— ———————————–
Project id 1 .. infinity
—————————— ————– —— ———————————–
Software staff L 6 >201 people on the project.
M 9 51 .. 200 people on the project.
S 9 1 .. 50 people on the project.
—————————— ————– —— ———————————–
Overall Staff X 10 >501 people.
L 7 201 .. 500 people.
M 5 51 .. 200 people.
S 2 1 .. 50 people.
—————————— ————– —— ———————————–
Production Type product-family 20 projects related; evolve over time
isolated 4 projects have little in common
—————————— ————– —— ———————————–
Software and product product 17 software is embedded in a product
alone 4 software is standalone product
process 2 software embedded in a process
—————————— ————– —— ———————————–
SP maturity high 6 CMM level 3 or higher
medium 13 ISO 9001 certification or CMM level 2
low 5 not high or medium
—————————— ————– —— ———————————–
Application domain TLC 7 telecommunications
FMS 4 flight management systems
ATC 1 air traffic control
TS 1 train simulation
TTC 7 train traffic control
Bank 1 bank
Book-keeping 1 book-keeping
Measurement 1 management, control of measurements
Space 1 aerospace applications
Manufacturing 3 manufacturing
SE-Tools 2 software tools
—————————— ————– —— ———————————–
Type of software Embedded-RT 6 embedded, real-time
Non-Embedded-RT 2 non-embedded, real-time
Technical 12 non-embedded, non-real-time, small DBMS,
important control part
Business 4 non-embedded, non-real-time, important
DBMS, limited control part
—————————— ————– —— ———————————–
Size of baseline L 8 100 … 500 KLOC; >100$ person months
M 13 10 … 100 KLOC; 10 .. 100$ person months
S 2 <10 KLOC; <10 person months
—————————— ————– —— ———————————–
Development approach OO 15 object oriented
proc 8 procedural
—————————— ————– —— ———————————–
Staff experience high 7 >5 years average
medium 15 2 .. 4 years average
low 1 <=1 year average
}}}
Here are the “low-level conrol variables”; i.e. specific approaches to the implementation of reuse.
{{{
Attribute Value # Notes
—————————— ————– —— ———————————–
Project id 1 .. infinity
—————————— ————– —— ———————————–
Reuse approach loose 12 assets loosely coupled
tight 11 assets coupled, used in groups
—————————— ————– —— ———————————–
Domain Analysis yes 9 domain analysis was performed
no 14
—————————— ————– —— ———————————–
Origin ex-novo 4 assets are developed from scratch
reeng 15 assets via reengineering old work
as-is 4 old products used without change
—————————— ————– —— ———————————–
Independent team yes 2 independent team makes assets
no 21 development projects makes assets
—————————— ————– —— ———————————–
When assets built before 7 well before they are reused
just-in-time 16 just before they are reused
—————————— ————– —— ———————————–
Qualification yes 14 assets undergo a qualification process
no 9 no defined qualification process
—————————— ————– —— ———————————–
Configuration management yes 16 configuration management used
no 7
—————————— ————– —— ———————————–
Rewards policy yes 3 a rewards policy for reuse in place
no 21 no rewards policy in place
—————————— ————– —— ———————————–
21 to 50 3
51 to 100 8
100+ 7 ------------------------------ -------------- ------ ----------------------------------- Work-products C code
D design
R requirements \}\}\}
Note that in the last entry, “work products”, the number of values is counted differently to the above. Specifically, C=10; D+C=4; R+D+C=9
More success and failure factors in software reuse
@ARTICLE{1199076,
author={Menzies, T. and Di Stefano, J.S.},
journal={Software Engineering, IEEE Transactions on},
title={More success and failure factors in software reuse},
year={2003},
volume={29},
number={5},
pages={474-477},
keywords={software reusability;machine learning;software organizations;software reuse;Association rules;Data analysis;Data mining;Decision trees;Failure analysis;Machine learning;Project management;Stress;Web sites},
doi={10.1109/TSE.2003.1199076},
ISSN={0098-5589},
month={May},}
Success and failure factors in software reuse
@article{10.1109/TSE.2002.995420,
author = {M. Morisio and M. Ezran and C. Tully},
title = {Success and Failure Factors in Software Reuse},
journal ={IEEE Transactions on Software Engineering},
volume = {28},
number = {4},
issn = {0098-5589},
year = {2002},
pages = {340-357},
doi = {http://doi.ieeecomputersociety.org/10.1109/TSE.2002.995420},
publisher = {IEEE Computer Society},
address = {Los Alamitos, CA, USA},
}