The Future of Software Development and Its Impact on APL

• Published in: Johns Hopkins APL technical digest 2005-01, Vol.26 (4), p.421-429
• Main Authors: Hanke, Paul A, Hershey, Hilary L, Smith, Pamela A
• Format: Article
• Language: English
• ISSN: 0270-5214

On a cold morning in January 2015, Kendall McNeill, an APL Service Ecosystem Software Developer, arrives at her office and her hand-sized, personal/business computer/phone is automatically connected into the desktop peripheral support station with high-speed, secure network connections, additional storage, several large touch screen displays, etc. A verbal command validates her identity and connects her to the peripherals. One of Kendall's large displays is dedicated to the online team interaction management space where team members working at home and located physically throughout APL and its field offices interact via managed collaboration processes in which development artifacts are tracked and shared. On a second screen, she brings up the graphical palette through which she does all 'programming' and begins work on an interface ontology that will permit the semantic middleware to expose an aging system as a collection of user-specified services within the user's next-generation service ecosystem. She drags a 'web service adapter' component onto the workspace and sets the underlying communications as SOAP 3.1. The semantic agent in the adapter displays its best guess at an interface ontology to map the aging system's interface to the user's service interface specifications; Kendall starts correcting and fine-tuning the agent's initial guesswork and takes note of the semantic gaps that will have to be filled by external sources. Meanwhile, a Requirements Change process workspace appears on her team display, and the voice of the systems engineer on the project, Liam Franks, speaks: 'I just reviewed the latest User Process Execution Language software submitted by our client and it introduces a new service abstraction to their ecosystem-I think we can implement this new service via the system you are currently abstracting. As you can see from the user's simulation results, the nonfunctional constraints for this new service are. . . .' Kendall views the new service specification in real time and tells Liam she needs to pull in Jacob. She drags Jacob's picture into the Requirements Change process workspace, where they discuss the viability of the change as well as potential impacts and rework. Their discussion session is recorded within the context of the Requirements Change process instance and will be stored in the project archive for future reference. The group estimates that the change is realizable within project constraints, and Liam accepts the change.