Page 34 - GCN, May 2016
P. 34

The process of modern software development incorporates Agile development practices to more quickly deliver higher quality applications.
If government officials agree on one thing, it’s that their agencies suffer from legacy IT that:
Takes up nearly 80 percent of agency IT budgets to maintain
Threatens overall IT modernization plans Creates a drag on mission effectiveness
Done properly, agile software development promises a faster, more efficient and less costly way of delivering effective applications. It also emphasizes prioritization of features based on value to the end user as opposed to a rigid PWS executed until finished which potentially wastes time and energy on features that provide no value the end users.
Once the initial feature list is set, developers immediately start to code and share information. That requires several support systems:
An enterprise source code manager (SCM) to detect changes to the code as they are made; and in conjunction with Continuous Integration and build tools, automatically and continuously build the application to detect any problems as soon as possible
The application build process itself ensures the code compiles correctly and that one developers’s changes did not negatively affect another’s change.
External repositories of required and dependent software and script libraries either built locally by the development team or downloaded over the Internet from open source communities or from enterprise supported companies
An artifact or image repository to cache the external repository to
avoid continually downloading libraries, thereby speeding development. These repositories can also be configured to detect security violations
in any library, and check the source code to ensure it meets government standards and guidelines. This is especially important with the rise and use of community-supplied open source technologies that may contain, or have yet undetected, vulnerabilities.
When an agency decides a custom application/service
would be beneficial, it creates a budget,
issues a request for proposals, and selects a developer;
which then:
Derives a list of feature requirements that outline what
the application should accomplish
Prioritizes features with the goal of producing a viable product in a short, one- to two-week sprint that is both testable and deployable
The team can then refine and further develop the application over time. This contrasts the traditional waterfall method, where you wait until the application is completely (according to completed task*) finished before you see if it actually works.
* The tasks may not be “complete”
as they may contain defects or
design flaws when they are built and deployed as one or more services that constitute the application.

   32   33   34   35   36