This paper reports findings from a two-year study to identify Lean practices for deriving software requirements from aerospace system level requirements, with a goal towards improving the software upgrade value stream. / Lean Aerospace Initiative

Packaged software is widely adopted and has become an integral part of most organizations’ IT portfolios. Once packaged software is adopted, upgrades to subsequent versions appear to be inevitable. To date, research on packaged software upgrade has not received the attention that it warrants, as academic research continues to focus on initial technology adoption. To explore this understudied yet important area, three research questions were proposed: (1) What influences the decision to upgrade packaged software? (2) How do stakeholders cope with software upgrade? (3) How does a packaged software upgrade affect stakeholders? A qualitative research method was used to study the research questions. Two cases were conducted at a Fortune 500 company located in the Southeastern region of United States. The first case studied Windows 2000 upgrades and the second case studied SAP 4.6C upgrade. A theoretical model with six components was induced from the study; the components are decision, motivating forces, contingency forces, planned strategies, corrective actions, and impacts. Upgrade decisions are the outcome of interaction between motivating forces that can originate from internal and external environments, and contingency forces. A decision to upgrade will lead to both positive and negative impacts as experienced by users and IT groups. However, stakeholders’ experiences differ according to the types of software and also their roles in the company. Two types of strategies were observed in the study: planned strategies and corrective actions. Planned strategies were used to tackle anticipated issues, and corrective actions were adopted to solve ad hoc problems when negative impacts arose. Both strategies can affect the final outcome of impacts. Finally, in the event a corrective action was used, there is a chance that it will become a permanent planned strategy.

Evolutionary changes applied to a framework API may invalidate existing framework-based applications. While manually adapting applications is expensive and error-prone, automatic adaptation demands cumbersome specifications, which the developers are reluctant to write and maintain. Considering structural changes (so-called refactorings) of framework APIs, our adaptation technology supports backward-compatible framework upgrade. The technology is rigorous defining precisely the structure and automatic derivation of compensating adapters. It is also practical compensating for most application-breaking API changes automatically, while requiring neither manual adaptation nor recompilation of existing application code.

Evolutionary changes applied to a framework API may invalidate existing framework-based applications. While manually adapting applications is expensive and error-prone, automatic adaptation demands cumbersome specifications, which the developers are reluctant to write and maintain. Considering structural changes (so-called refactorings) of framework APIs, our adaptation technology supports backward-compatible framework upgrade. The technology is rigorous defining precisely the structure and automatic derivation of compensating adapters. It is also practical compensating for most application-breaking API changes automatically, while requiring neither manual adaptation nor recompilation of existing application code.