|
Booklet:
Development
and Acquisition Section: Development Procedures Subsection: Software Development Techniques |
|||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||
OBJECT-ORIENTED
PROGRAMMING
Traditionally, programmers wrote programs using sequential lines of code
in a high-level, procedural language such as COBOL
.
Programmers also write object-oriented programs in high-level languages
such as C++ and Java; however, the programs are written less sequentially.
Object-oriented programming centers on the development of small, reusable
program routines (modules) that are linked together and to other objects
to form a program. A key component of object-oriented programming involves
the classification (modeling) of related data types (numbers, letters,
dollars, etc.) and structures (records, files, tables, etc.). Modeling
allows programmers to link reusable program modules to modeled data classes.
Linking pre-developed program modules to defined data classes reduces
development times and makes programs easier to modify.
Programmers use various methods to define and link reusable objects. Initially,
structured programming techniques were developed that focused on the arrangement
of lines of procedural code. The ad hoc techniques enhanced the layout
of a program’s modules and overall design, making it easier to integrate
and reuse program modules. Object-oriented programming employs a form
of structured programming and adds methods for defining the data classes
that are linked to structured program routines.
A drawback to the use of structured programming, and consequently, methods
such as object-oriented programming, which use structured programming
techniques, has been a lack of standardized coding procedures. The lack
of standardized procedures restricts the interoperability of proprietary
products, including automated design and development products sometimes
referred to as computer-aided software engineering (CASE) tools. However,
the software industry is moving towards acceptance of standardized object-oriented
modeling protocols.
COMPUTER-AIDED SOFTWARE ENGINEERING
CASE tools are a class of software that automates many of the activities
involved in various life cycle phases. For example, when establishing
the functional requirements of a proposed application, prototyping tools
can be used to develop graphic models of application screens to assist
end users to visualize how an application will look after development.
Subsequently, system designers can use automated design tools to transform
the prototyped functional requirements into detailed design documents.
Programmers can then use automated code generators to convert the design
documents into code. Automated tools can be used collectively, as mentioned,
or individually. For example, prototyping tools could be used to define
application requirements that get passed to design technicians who convert
the requirements into detailed designs in a traditional manner using flowcharts
and narrative documents, without the assistance of automated design software.
Automated tools can also facilitate the coordination of software development
activities through the use of data warehouses or repositories. Repositories
provide a means to store and access information relating to a project,
such as project plans, functional requirements, design documents, program
libraries, test banks, etc.
Organizations generally implement automated development tools to increase
productivity, decrease costs, enhance project controls, and increase product
quality. However, only by managing the various risks associated with automated
technologies will organizations ensure they develop systems with appropriate
functionality, security, integrity, and reliability.
Common CASE risks and associated controls include:
|
|
Inadequate Standardization – Linking CASE tools from different vendors (design tool from Company X, programming tool from Company Y) may be difficult if the products do not use standardized code structures and data classifications. File formats can be converted, but usually not economically. Controls include using tools from the same vendor, or using tools based on standard protocols and insisting on demonstrated compatibility. Additionally, if organizations obtain tools for only a portion of the development process, they should consider acquiring them from a vendor that has a full line of products to ensure future compatibility if they add more tools. |
|
|
Unrealistic Expectations – Organizations often implement CASE technologies to reduce development costs. Implementing CASE strategies usually involves high start-up costs. Generally, management must be willing to accept a long-term payback period. Controls include requiring senior managers to define their purpose and strategies for implementing CASE technologies. |
|
|
Quick Implementation – Implementing CASE technologies can involve a significant change from traditional development environments. Typically, organizations should not use CASE tools the first time on critical projects or projects with short deadlines because of the lengthy training process. Additionally, organizations should consider using the tools on smaller, less complex projects and gradually implementing the tools to allow more training time. |
|
|
Weak Repository Controls – Failure to adequately control access to CASE repositories may result in security breaches or damage to the work documents, system designs, or code modules stored in the repository. Controls include protecting the repositories with appropriate access, version, and backup controls. |
RAPID
APPLICATION DEVELOPMENT
Rapid application development (RAD) is a software development technique
that emphasizes short development times (30-90 days). The technique is
inappropriate for developing complex applications or applications that
quickly process significant volumes of transactions, such as batch processing
environments. Organizations may appropriately use the technique to develop
or redesign lower-risk applications, or less complex applications such
as transactional websites that do not involve a high degree of throughput.
Additionally, depending on an organization’s risk tolerance and
the mission-critical designation of an application, organizations may
use RAD techniques during the design and development phases within a structured
development methodology.
Management
should consider the functional complexity and security risks of an application
when selecting a development methodology. Management should ensure that
the development technique selected is appropriate for managing the complexity
and risks of the application being developed.
The RAD process may involve only three phases: initiation, development,
and implementation. The short duration of RAD projects necessitates the
quick identification of functional requirements, which should remain largely
unchanged during the development process. Typically, managers assign end
users full time to a project and empower them to make key design decisions.
However, they normally consult project specialists such as database administrators,
network technicians, and system programmers, when they make key decisions.
End users and RAD team members usually create functional designs using
prototyping tools in an iterative process. They create, review, and revise
the prototypes as needed until they approve a final design.
RAD methodologies often employ object-oriented programming techniques
that take advantage of reusable program objects. In the case of redesigned
applications, designers and developers select objects based on the function
they perform and re-link them to other reusable or newly created objects
to form a new application.
Testing often occurs concurrently with the development of functional features.
Organizations may conduct testing and implementation procedures quickly
or in a structured process similar to SDLC testing and implementation
phases. The speed and structure of testing and implementation procedures
depends on an organization’s risk tolerance, an application’s
mission-critical designation, and a project’s established deadlines.
Developers are increasingly creating web applications using RAD techniques.
Numerous CASE-type products (for example, application program interfaces)
are available that developers can use to combine pre-designed object-oriented
functions to form unified applications.
Appropriate standards and controls should be in place to ensure:
|
|
Organizations only use RAD techniques when appropriate; |
|
|
Management includes adequate security and control features in all developed applications; |
|
|
Quality assurance personnel verify that security and control features (commensurate with risk levels) exist and function as intended; |
|
|
End users are appropriately involved throughout RAD projects; and |
|
|
Project managers closely monitor project activities. |