F
Frank Mcgarry
Researcher at Goddard Space Flight Center
Publications - 28
Citations - 813
Frank Mcgarry is an academic researcher from Goddard Space Flight Center. The author has contributed to research in topics: Software development & Software construction. The author has an hindex of 12, co-authored 28 publications receiving 809 citations. Previous affiliations of Frank Mcgarry include Computer Sciences Corporation & University of Maryland, College Park.
Papers
More filters
Proceedings ArticleDOI
The software engineering laboratory: an operational software experience factory
Victor R. Basili,Gianluigi Caldiera,Frank Mcgarry,Rose Pajerski,Gerald T. Page,Sharon Waligora +5 more
TL;DR: The SEL is discussed as a functioning example of an operational software experience factory and the characteristics of and major lessons learned from 15 years of SEL operations are summarized.
Proceedings ArticleDOI
Lessons learned from 25 years of process improvement: the rise and fall of the NASA software engineering laboratory
TL;DR: The history of the SEL is described, the research that was conducted, how the understanding of software process improvement evolved, and a set of lessons learned and hypotheses that should enable future groups to learn from and improve on their quarter century of experiences are described.
Journal ArticleDOI
SEL's software process improvement program
TL;DR: It is necessary to select candidates for process change on the basis of quantified Software Engineering Laboratory (SEL) experiences and clearly defined goals for the software to adopt, discard, or revise the process.
Software Process Improvement in the NASA Software Engineering Laboratory
Frank Mcgarry,Rose Pajerski,Gerald T. Page,Sharon Waligora,Victor R. Basili,Marvin V. Zelkowitz +5 more
TL;DR: The concept of process improvement within the SEL focuses on the continual understanding of both process and product as well as goal-driven experimentation and analysis of process change within a production environment.
Proceedings ArticleDOI
Criteria for software modularization
TL;DR: The results indicated that module strength is a good criterion with respect to fault rate, whereas arbitrary module size limitations inhibit programmer productivity.