Hanscom team helps 'forge' new path for software development, testing

  • Published
  • By Chuck Paone
  • 66th Air Base Group Public Affairs
Acquisition by its nature is a fairly rigid business, governed by established rules and procedures designed to ensure integrity, fairness and programmatic oversight.

This creates a vexing problem for those trying to increase acquisition speed and agility. It's particularly challenging when dealing with information technology, and software specifically, where the rate of innovation is very fast.

"Commercial IT and software development advances occur so rapidly that the only hope we have of keeping pace is to embark on a completely different and open path," said Dr. Tim Rudolph, the Electronic Systems Center chief technology officer.

That's why he and many senior leaders throughout the Department of Defense have embraced a new approach and destination for software development.

That place is Forge.mil, a Defense Information Services Agency-led effort being worked, in part, out of the Air Force Electronic Systems Center here. Forge.mil picks up on the globally popular software development community, Source Forge, where developers have collaborated for years in an open environment, said Ray Smith of Jackpine Technologies, a contractor working within ESC's Capabilities Integration Directorate.

"With Forge.mil, the push is for the DOD to adopt some of the same tools and methods that industry uses to rapidly design, develop, test and field software," Mr. Smith said. "We're trying to go toward small, incremental, functioning software deliveries rather than a single monolithic one at the end of a contract."

Forge.mil is less open than Source Forge; a Common Access Card or External Certificate Authority login is required. However, it's still a radical departure from old ways of doing business in that it enables developers to collaborate with other developers, users, mission assurance specialists and testers while developing.

Testers have always been a welcome part of the Forge.mil community, but until recently there hadn't been a component designed specifically for testing. The Hanscom team is working to change that.

Originally called Test Forge, and now referred to as Forge.mil Testing Services, this new segment being developed here provides tools for continuous testing of software being developed.

"This is a huge leap forward," said Peter Walsh, a contractor with NPLACE Inc., who is working on the effort here. "Now for instance, the Joint Interoperability Test Command can place its test procedures out there, and the developers can run them as they go. That way, they'll know right away, long before going into an official testing phase, if there are any problems, and can address them before getting too far along."

Users also can automate the testing process, so that regression tests will run at pre-established times each day.

"Any new source code added that day is automatically tested that night," Mr. Walsh said.

The team developing these new testing services knows how they work because they're using the features themselves as they continue to refine them.

"We're one of the 478 projects ongoing within Forge.mil right now," Mr. Smith said. "We're doing what we're doing completely within the Forge.mil environment." Forge.mil itself has about 8,700 registered users.

The great benefit of working in this collaborative environment is that it makes development truly iterative.

"Under the old model, software systems were developed and then thrown over the fence (to testers or users). And then when we wanted to modify something, we'd have to come up with an engineering change proposal and negotiate that and spend more money and more time," Mr. Smith said. "Now we can develop, share, test and refine throughout the process."

Another key benefit is the use of virtualization, which enables users to "call up" the tools they need rather than having to buy them and configure them on independent servers. This saves resources and adds consistency.

"Now you no longer run into a situation where something works in one environment but, because of some slightly different configuration, doesn't work in another environment," Mr. Walsh said. "Here, everyone's working with exactly the same tools."

Dr. Rudolph agrees that this new paradigm is vastly superior.

"You can't realistically become more agile in a critical area like software development any other way," he said. "You have to be willing to work in a relatively open, collaborative environment and improve and fix things as you go. This is one of the few ways to kick the tires of software in a larger environment for transition to the live network."

Like any big change, its success depends on people feeling at ease with it. That includes the contractors paid to develop the software-based systems DOD relies on.

Rather than having the government wait for the final product, an open process where program managers, operators, testers and others can see what is being built might make developers uncomfortable, said William Cook, the Joint Command and Control Air Force liaison, who works out of the center's Command, Control, Intelligence, Surveillance and Reconnaissance Directorate.

"I'm a huge proponent of the Forge.mil operating model," he said. "It allows us to attain efficiencies in software testing. We want our contractors and, by extension, our programs to get all the benefits of developing while using agile testing practices, too, and we want them to feel comfortable doing it. That's why we're looking at creating workgroup versions for individual contractors to use."

With those workgroup "editions," contractors would have access to all the development tools and all the testing procedures, so they know what the enterprise environment will be when they load their software up into Forge.mil.

That's really what's at stake here, Mr. Walsh said, noting that as a contractor, even he had to make a mental adjustment to working this way.

"Once we started doing it, though, we could see right away that the benefits were far greater than the risks," he said.