AF factory develops software

IT will be key element in Air
Force’s deployment of expeditionary forces.


MONTGOMERY, Ala.—A 9-month-old software factory at the Air Force’s Standard
Systems Group is helping the service cut the time and money it spends developing and
maintaining software.


SSG’s factory at Gunter Annex has about 700 employees and develops, tests and
maintains Air Force combat support applications.


It also runs an Air Force network operations center to track communications links
servicewide, and it provides around-the-clock technical support to Air Force users.


The Gunter factory has earned a Level 3 Capability Maturity Model rating from the
Software Engineering Institute at Carnegie Mellon University for its software development
work.


The factory is a fee-for-service operation. This year’s rate for software
development is about $52 per hour. Next year that rate will likely rise to about $60 per
hour, SSG officials said.


In January, as part of a commandwide reorganization, Lt. Gen. Ronald Kadish, commander
of the Electronic Systems Center at Hanscom Air Force Base, Mass., established software
factories at Gunter and the Materiel Systems Group at Wright-Patterson Air Force Base,
Ohio.


When he created the centers, Kadish directed ESC to adopt the computer industry’s
18-month acquisition cycle for the Air Force’s combat support systems and to reduce
development time to 12 months for new software and major modifications.


To adhere to those schedules, the Gunter software factory relies heavily on commercial
products and by designing and implementing highly integrated systems that comply with the
Defense Information Infrastructure’s Common Operating Environment, said Kenneth
Heitkamp, SSG’s technical director and director of the software factory.


“Our work is primarily focused on combat support systems, such as supply line,
maintenance, personnel and payroll systems, but we do have some command and control
systems,” he said.


The software-intensive systems are critical to the Air Force’s mission of
supporting more than 200 active and Air Force Reserve bases in the United States and
overseas, Heitkamp said.


A recent survey of ESC’s programs found that 42 percent of its software uses
commercial components.


“We provide the Air Force with standard systems that are developed here once and
then reused across the service,” he said. “It doesn’t matter what base you
go to, you’ll find that these software applications are reused as-is because we
don’t release source code.”


Creating the software factories is part of an effort by the Air Force to standardize
its systems and eliminate the software “hobby shops” that have sprung up
servicewide, Heitkamp said. Previously, program managers developed applications on their
own without direction from SSG, he said.


The Gunter factory, which includes a small contractor staff, has six functions:
software development, software engineering, customer support, configuration management,
operations control, and test and evaluation.


The factory’s software development division, in turn, is divided into branches for
Unisys Corp. mainframe, Unix and Microsoft Windows NT applications.


“This is a big change from the way we were previously organized here at SSG, when
we had all these programmers and analysts arranged around functional areas such as
logistics, medical or whatever,” said Col. Bruce Paterson, head of the factory’s
Software Development Division.


The Unisys branch handles code for maintenance, supply and finance systems running on
mainframes. The Unix branch works on apps for midtier systems, servers running at Defense
Department megacenters and desktop PCs. The NT branch deals with applications running
under NT, Windows 95, Windows 3.1 and MS-DOS on desktop systems.


The approach also lets the factory use standardized tools and processes to develop
apps, he said. The factory now has a manageable tool kit, he said.


“As we put together all these people in the factory, we realized we had too many
tools,” Heitkamp said. “Fools with tools are still fools and still worse are
fools with tools without a process.”


The Gunter factory uses a sequential standard engineering process (SEP): requirements,
evaluation and proposal; project planning; analysis; design; construction; testing;
implementation; customer support and completion.


The On-Line Vehicle Interactive Management System, for instance, is currently in the
requirements phase, which will likely last seven months. More than 375 active, Guard and
Reserve units use OLVIMS to manage and maintain the Air Force’s fleet of 110,000
vehicles.


The standalone PC application was written in Cobol in the early 1980s, but the service
wants to run OLVIMS in a client-server environment.


The factory is converting it to an Oracle Corp. relational database management system
running under NT on servers at DOD megacenters.


As part of the re-engineering, the factory is developing a new graphical user interface
and using modern programming tools, SSG officials said.


When writing code, the software factory primarily uses Cobol and C++. Less than 5
percent of the factory’s apps are written in Ada, SSG officials said.


The software factory’s OLVIMS development team is using a suite of tools from
Oracle that includes Developer 2000, Designer 2000 and Discover 2000, said Capt. Keith
Kocan, team leader for the OLVIMS effort.


The development team used Microsoft Word and Excel 97 to create a baseline of
OLVIMS’ more than 400 requirements, Kocan said.


“Our biggest challenge in this phase of the SEP is how we track and manage changes
to the requirements,” Kocan said. “Word and Excel are good for the first part of
the process but later on they fall short.”


The factory has started to import OLVIMS requirements data from Word and Excel into
RequisitePro from Rational Software Corp. of Cupertino, Calif., a requirements management
tool that runs under Windows.


Another application, the Transmission Monitor and Control System, is in the design
phase. TRAMCON is a remote site alarm system developed in 1981. It resides on
minicomputers and supports the service’s Digital European Backbone, monitoring radio
equipment alarms and measuring network performance.


Originally, the application was written in Pascal and Fortran. To rewrite the TRAMCON
code in C++, the factory is using Rational Software’s Rational Rose, a visual
modeling tool, said Lt. James Swanner, a software design engineer.

inside gcn

  • pollution (Shutterstock.com)

    Machine learning improves contamination monitoring

Reader Comments

Please post your comments here. Comments are moderated, so they may not appear immediately after submitting. We will not post comments that we consider abusive or off-topic.

Please type the letters/numbers you see above