Business Object Approach for Rapid Application Development
(BOARD PIE - 24050)
Manolis Tsagias
Technical Director
Sunsoft Ltd.
Abstract
The purpose of project BOARD is to evaluate the efficiency
of the Business Objects approach in the development of software
for business applications. This evaluation consists of experiences
and answers gathered during the development of two projects using
this approach. The driving factor of this experiment is strategic
decisions of Sunsoft's management, that require fast and cost
effective penetration into vertical software markets for small
to medium sized enterprises. The prime requirements for the development
of this kind of software are minimal initial development time
without sacrificing product quality, low maintenance and extensibility
costs, product robustness and the ability to keep up with the
technology innovations in the user interface and database areas.
The idea of Business Objects is, that one can build a repository
of "business objects" that will be enriched with the
experience and effort spent on each project and will feed future
projects with all the common parts they may have.
Business motivation
Sunsoft is a software production and consulting company. Its
main line of business is software development of business applications
covering all aspects of a company' s activities. Most applications
use database systems and have a graphical user interface.
The goals that motivated Sunsoft to commence this experiment
are:
- To increase its cross-project reusability, thus enabling
the company to be more productive and more effective in addressing
new vertical markets, without sacrificing product quality and
reliability. This will also result in reducing the maintenance
costs of the new products.
- To achieve the production of modular software, thus increasing
the flexibility to incorporate new technologies in user interface
and database management systems, which will keep Sunsoft in the
edge of technology.
- To improve it's testing procedures by introducing test plans
for the whole product and automating the test phase, thus increasing
software reliability and robustness and reducing maintenance
costs.
Approaching business objects
In order to have sufficient information to measure the effectiveness
of this development approach, this experiment uses two projects
that are developed consecutively. The selection of the projects
was on the grounds that they should target similar areas, but
for different customer areas, which is a typical need for reuse.
The project team with the help of consultants decided that they
should use UML as the analysis and design documentation notation.
The same team received extensive training in OO approaches in
general and in UML, as well as in component architecture, distributed
objects and interface design concepts.
The first task of the project team was to define the term
"Business Component" as it would be used in the Sunsoft
environment. The definition includes clarification of terms like
what is a business object, a business component, the documentation
that is included in each and the rules that components must comply
with, in a system wide manner. This definition paper is revised
whenever issues arise that require additions or modifications.
The business component idea is based on the fact that our customer
needs are quite similar among them and are relatively stable
over time. This led the project team to build an analysis repository
comprised of low level use cases and business models, which is
reused in each new project by the analysis team.
This also led to a design that clearly separates the business
layer from the user interface and the database layers. This design
allowed us to introduce the concept of multiple tiers in the
implementation of the applications. At the same time, it allows
replacement of the user interface or the database system, or
additions to them. We can for example attach Internet aware modules
to a system, or create legacy system wrappers, without affecting
the business layer.
Building test plans and test cases for each use case, that
evolve throughout the analysis, design and implementation phases,
down to automated test scripts, reduces significantly the effort
required for test and the expected errors of the first beta releases.
The results and the experience gained
The metrical evaluation of the experiment results is done
in two ways. First by comparing the first with the second application
and second by comparing both applications against a baseline
project built using no particular method.
Comparing the first with the second application we found that
there was a 48% of reuse. The first application showed a 75%
improvement in quality compared to the baseline project. The
second application had a 17% improvement in productivity compared
to the baseline project.
One very important issue is that there is extensive analysis
and design documentation for both the first and second application
whereas the volume of documentation of the baseline project is
quite limited. This is expected to have a significant improvement
in the maintenance effort of the two applications. It also captures
the experience gained in past projects so that it can be reused
effectively even by less experienced staff.
The multi-tiered architecture that is now possible with the new
design approach, allows the construction of scalable applications
and can address clients with needs for distributed systems or
a high expansion rate. It is also possible to use multiple user
interfaces with low cost and low risk, since all the business
logic is encapsulated and isolated in an application server.
Future plans and actions taken
The whole project received a high degree of acceptance throughout
the company, as the problems that it addresses affect most of
the company's departments. A new concept emerged for the company
that incorporates the new development technologies, tools, methods
and experience. This concept was named ALEXANDROS and is currently
being adopted by the company and marketed in the wider public. |
