Investigating and Improving a COTS-based Software Development Process Morisio, Seaman, Parra, Basili, Kraft, Condon icse 2000 This paper develops a process model for cots-based software development by investigation among 15 COTS projects performed at FDD.

Outline Background Study design Results of the study SEL and Strawman process Study design Strutured interview Results of the study Differences between COTS projects and traditional projects Disadvatage of COTS projects New proposed process model Conclusion

Background Software Engineering Laboratory (SEL), known for empirical study of software development practice, provides guides to NASA/GSFC projects. SEL developed a process for COTS-based development for FDD – Strawman process 15 COTS projects are studied to evaluate and improve the process model SEI provides guides to NASA more than 20 years. In 80s and 90s there is trends to reuse and cots-based developemnt in FDD, SEI decided to provide guildelines gor this process. In 1995, initial strawman process defined according to experience from the outside. Then are reviewed by the software engineers in FDD and modified, the resulting strawman process is like this: At the same time as this strawman process is devloped, several cots project are done at fdd. So SEI decided to perform a observational study for these projects, look at what are done in practice, is it same as the strawman process, and how improve the process.

Strawman process Phase Major Activities Products Management Check-points Requirements Analysis and COTS Identification Requirements analysis COTS survey and preliminary evaluation Requirements Strawman high-level architecture Candidate COTS System requirements review Architecture definition and COTS Selection COTS evaluation Requirements modification to use existing COTS Prototyping Modified requirements System architecture Final COTS System design review System Integration and test Use-case implementation Independent testing Delivered system Uer demonstrations Operational readiness review Tchnology Update and System Maintenance Evaluation of new products and technology Enhanced system User demonstrations

3 Types of COTS-based Systems Defined by Carney: Turnkey systems: Build around a suite of commercial products such as Microsoft Office. Customization does not change the nature of the initial product. Intermediate systems: Built around one COTS but integrate other (also developed in-house) Other: Built on several COTS with same importance.

Study of the Actual Process Structured interviews using the GQM approach 25 representatives from 15 projects in 2. and 3.category of Carney definition. Two study teams: Interviewer Scribe Analysis by constant comparison method

Differences between COTS projects and traditional projects More effort on requirements, test and integration, less on design and coding. 3 types of differences: New activities: COTS selection, COTS familiarization, vendor interaction Reduced activities: coding, debugging, unit testing. Modified activities: design, architecture issues (compatibility, configurability) The result of the analysis found cots projects must follow a process that is quite different from traditional projects In design, focus is on how to fit pieces tigether rather than the internal structure of the modules.

Disadvantage of COTS projects Dependence on vendor: functionality available, the schedule for release, the reliability level, documentation… Flexibility in requirements: COTS drives the requirements at least to some extent A trade-off between disadvantage and the benefits of COTS The study also found the ad and disad of cots project, ad ie everyone know, reduced time to market, cost, effort, but not all the project can use cots, because cots project must consider some issues,

New COTS Process Main phases are: Requirement Design Coding Integration

New process model Vendor Requirements Design Coding Integration COTS specific activities Package Identification Evaluation/ Selection Identify Glueware and Integration Requirements Write Glueware And Interfaces Integration and Test Target system Installation and Acceptance Test Requirements Review Design Review Requirements Analysis Non-COTS Design Non-COTS Coding The difference with strawman is mainly on requirements and design phase, so This paper only give more description to these two phases. Customer

Requirement Make versus buy decision I Requirement definition Consider trade-off between non-technical issues and disadvantages of COTS project Requirement definition COTS identification and selection COTS familiarization: learn about COTS Feasibility study describe the product on a high level, an effort estimation, a risk assessment model. Both for COTS and non-COTS. Make versus buy decision II The result is the product variant that will be developed Requirements Review Requirements phase includes these activities, they are in a logical order, in practice, they may be performed concurrently or iterative. I only get all the possible situations, not final desicion. The goal of requirement definition is to guide identification og COTS. COTS are identified and evaluated by vendor documentation, reviews, previous experience. Reduce the number of candidates to two or three. Feasibility study is the futher evaluation of COTS, it also evaluate non-cots solution. One such description shoud be given to each product variant with COTS and without COTS.

Design Definition of architecture and integration issues at lower level of details Decision on glueware Design Review Some high level design in requirement phase, in desiogn phase activities go more deeper, more detailed. All the effort should be concentrated on the product variant selected by requirements phase. Define the integration of cots and new developed componets, shoud make decision on glueware.

New Roles COTS Team Interface with vendors At the organization level A repository about COTS Interface with vendors At the project level Build partnership with vendors

Conclusion COTS-based processes differ considerably from traditional software development New activities Reduced activities Modified activities Disadvantage of COTS projects: Dependence on vendors Flxibility in requirements The new process is defined Requirements and design phases are most challenging