Academic Paper Writing Service http://StudyHub.vip/A-Methodology-For-Large-Scale-E-Busines 👈

1. A METHODOLOGY FOR LARGE-SCALE E-BUSINESS
PROJECT MANAGEMENT
Virgilio Gilart-Iglesias, Francisco Maciá-Pérez, Diego Marcos-Jorquera,
Alfonso Capella-D’alton, José Vicente Berna-Martínez
Departamento de Tecnología informática y Computación, Universidad de Alicante
AP. 99, 03080, Alicante, España
{vgilart, pmacia, dmarcos, acapella, jvberna}@dtic.ua.es
ABSTRACT
The development of powerful and robust applications in the field of e-commerce in which a great many —human,
technological and economical— resources take part require the elaboration of complex projects to not only coherently
manage their life cycle in its entirety but also satisfy deadline criteria, and most importantly, adjust themselves to the
ever-restricting economic criteria. In this article, we propose a methodology based on working environments in order to
systematize the whole project management in accordance with the particular needs and resources —human or
technological— any corporation may have. The methodology we propose will also integrate the different roles and
working practices proposed by the manufacturers of the current development platforms based on distributed software.
KEYWORDS
e-business, working environment, J2EE, infrastructures, middleware platforms
1. INTRODUCTION
The Internet has become a different way of understanding business. In this environment, the different
enterprises are facing new models of competition which, for the exceedingly high cost, were restricted to
powerful enterprises not so long ago [8]. This revolution involves the presence of new requirements which
have not been traditionally contemplated by the existing software models and forces the need to provide
business process reengineering, that is, new strategies to adapt the existing business processes and software
systems [17].
Most of the organizations are reluctant to move with the times, which, in some cases, can become
traumatic, basically but not merely motivated by the effort required to depart from the already established
way of doing business [8]. They also perceive the complexity involved in integrating their inherited systems
containing vital information for the corporation, which normally deal with important investment projects
[22]. Moreover, changes motivate alterations in fixed infrastructures, and the personnel must also undertake
the task of learning and mastering the new ways [17]. Notwithstanding the difficulties faced by the
enterprises, new corporations crop up, rapidly adapting themselves to the new situation, forcing the rest to
evolve in this new direction [8].
Conventional architectures fail in providing a global solution to the needs created by the new business
models because many of the requirements set in this new context were not contemplated in their design. In
order to fill this gap, a new generation of software models and platforms based on components on distributed
architectures (n-levels) has been born. This new generation supplies a comprehensive solution from which to
tackle these new business models, and at the same time, takes advantage of the technological context the
Internet provides.
For some time now, the Chief eBusiness Officer (CeO) is not expected to act as a magician nor as a
perfect strategist, an expert in new technologies, capable of transmitting the importance of e-business to the
corporation. He is not even supposed to lead the transition to the new economy. He is a professional. He is a
professional capable of designing high-level TI infrastructure, of providing value for invested money and of
understanding business key features [21].
IADIS International Conference e-Commerce 2005
289

2. However, the management of this type of projects is, if anything, extremely complex. It ranges from
multidisciplinary resources, new information and communication technologies (ICT), to new development
models in a way that it meets deadlines and budgets [17]. Because of its magnitude, any deviation in any of
the parameters of the project can result in a total fiasco [18].
Doubts concerning the design of the project in terms of precise requirements and at the same time flexible
enough to accommodate any alteration that may be due during its execution presupposes serious dilemmas in
the CeO to carry out such projects [16].
Our goal in this paper is to propose a methodology that will systematize the whole life cycle involved in
large-scale e-business projects, following the roles and working methods proposed by the new development
platforms so as to suggest different working contexts and new interaction approaches from clearly established
policies, facilitating not only the development and vertical and horizontal scalability of the environments but
also human resources and necessary infrastructures.
2. BACKGROUND
The processes of software development define organisational activities and procedures used in the generation
of software applications and their maintenance [12].
With the advent of entrepreneurial platforms introduced by the new business models [8], a change has
come about in the models of software development process. An evolution has occurred from a time when the
processes evolved in a linear mode —a series of sequential steps were applied to obtain a final result [16]—,
towards specification of new paradigms founded upon parallel and cooperative activities.
Among the models for software development, we find the Unified Process for Software Development [2]
from IBM Rational that came about after three decades’ research with the final aim of obtaining robust,
flexible and scalable applications.
Another model meeting the needs of developing e-business applications is the one developed by OMG
named Model Driven Architecture, MDA [13]. MDA aims at providing a working frame to generate
applications based on specificity, and guided by models [1].
Métrica v.3 is a working methodology for the design of software by the Spanish Public Administration
Ministry which is founded upon standards to improve the design of software applications [14].
All the mentioned models are built from support standards to achieve their aims as it is the case of the
modeled languages. These methodologies mentioned above make use of the Unified Modeling Language
[20]. UML is a notational specification oriented towards objects. It consists of a series of diagrams which
account for all the modeling requirements in the different steps of the development of software applications:
ranging from the functional design resting in particular cases of use to the deployment diagram design [9].
These methodologies are used in order to guide the development of eBusiness applications in our
organization; however they do not provide working policies, cooperative schemes, real scenarios and
integration throughout software’s several phases.
The paradigms on top of which eBusiness applications are based, as is the case of the Model-View-
Controller pattern, together with the enterprise platforms foundations have led to new models and tightly-
uncoupled architectures which guide the design of such applications [11][7] and distribute the required tasks
in well-defined roles, thus allowing these tasks to be performed in parallel [17].
This feature introduces the need to acquire project management tools like version control systems which
solve the problems derived from the cooperative development of applications [15].
Such systems can track the software in development so as to retrieve its current state —or previous
ones—, while facilitating group work in a centralized fashion and optimizing resources [19].
In the following section we propose a project management model which is not only based in the above
discussed methodologies, but also provides the CeO with a set of infrastructures and working policies so as
to systematize the software developing process. Our model is aimed to guide the CeO through this complex,
decision-making process and to minimize the project’s impact on the overall project.
ISBN: 972-8924-06-2 © 2005 IADIS
290

3. 3. ENVIRONMENT-BASED MODEL
The purpose of this model is to offer a working frame which will serve as a guide in the development of e-
business applications pivoting on entrepreneurial platforms all along its lifecycle to take advantage of the
properties and benefits which these new architectural methods and the ICT are able to provide.
The model has been sub-divided into a set of logic entities called environments which suggest a partition
over the set of states of lifecycle in the development of the application. Each environment defines a set of
properties and methods over the development of the application.
Concurrently, the model establishes a relationship among the different environments, which means an
ordering of the set from the lower to the highest stability of the product generated.
Figure 1. Working environment model.
According to the model defined in Fig.1, a software product experiences an increasing evolution towards
stability and at a give time, it can be located at any of the states shown in Fig.2. We are going to analyze each
of the environments proposed.
Figure 2. Relationship between application state and application stability
3.1 Development Environment
This development environment combines the wider area of tasks, and encompasses them from the beginning
of the software lifecycle ―sampling requirements― to the actual obtaining of a version of the application
―or of a subset of it― with a minimum of stability.
The main tasks managed in this environment are: sampling requirements and the establishing of
specifications of the application in documents to enable the involved personnel to have a general view of the
application; the analysis of the architecture and technical design so as to be able to define the most adequate
technology and establish a robust base from which to view the possible errors in the project before its
implementation; the implementation proper pivoting on the previous task, which will reduce the complexity
of the process; and finally, the unit tests which each component of the project will pass on its modules and
components in its local working environment.
3.2 Integration Environment
Tasks related to combining the different elements which make up the application together with the
integration tests to validate the general performance will be considered in this integration environment.
Development environment Integration environment
Preproduction environment Demonstration environment
Production environment
Software Repository
Distributed file system
Version control system
Tagging policy Deployment document
Policies for management incidents
Development, Integration, Demonstration, Preproduction, Production
- Stability + Stability
IADIS International Conference e-Commerce 2005
291

4. In this process the source code of the modules which have been created and validated (unit tests) is
assembled in the development environment. Next, the application is put at work so as to carry out the
integration tests. The deployment of the application is performed according to the documents generated in the
project.
Once the application has been integrated and activated, a series of tests are carried out. The aim of these
tests is to ensure that the performance of the application follows the specifications stated in the stage of
sampling of requirements.
If the application satisfies the integration tests, it is ready to move onto the pre-production environment
where it will undergo quality tests and then to the demostration environment so as to allow the client access.
Should an error occur, an incident note must be generated via a policy of incident management previously
defined to send it to the person responsible for the development of the module in which the error was
detected.
3.3 Pre-production Environment
The tests performed in the previous phases are restricted to an environment and loads which do not really
reflect the actual needs and are centred in spotting mistakes generated by the specificities of the project.
The development of real tests directly related to the production environment poses serious drawbacks
which may in the end not render indispensable services for the economy of the organization.
So as to fill this gap and perform thorough tests to guarantee the output of the product to the real
environment, we have built a mock-up model most closely adjusted to such an environment.
3.4 Production Environment
The production environment contains the active version of the application at any given moment. Since the
end users have access to the implanted application in this environment, it is absolutely essential to plan and
adopt the precise security cautions in accordance with the information handled by the system.
On the other hand, this environment also contains the real data, information which is vital to protect from
possible mishandlings by means of a systematic application of backup copies.
The application is deployed in the production environment from the existing version in the pre-production
stage. The deployment of the application is performed automatically to prevent mistakes being introduced as
far as possible. At this stage the documents must be transferred into this environment and checked against the
deploy ones carried out in the process of application development.
3.5 Demonstration Environment
The customers that hired our company in order to develop the application, and other potential customers, are
often interested in having access to the system’s functionalities so as to experience its interface and
capabilities, and also to detect any divergence from the specified requirements.
In order to provide this access, a minimum operative platform must be set up. Although the application is
fully operative in the preproduction and production environments, these are not suitable in order to offer a
test mode access for customers, and therefore we propose to set up a scaled model of the production
environment, built with the minimum necessary infrastructure and services required in order to provide a
running, stable enough application which can be experienced by our customers.
3.6 Software Repository
The environment model comprises an additional logic entity called software repository. This software
repository centralises the information necessary for the development of the applications and facilitates the
management of the project.
The repository software is made up of:
• A set of distributed files which stores the information handled by the project: third party
documentation, software applications together with any other resource that has been contemplated.
ISBN: 972-8924-06-2 © 2005 IADIS
292

5. • A version control system that manages the concurrent access and the different versions of the
information generated all along the project; a control system of the source code and of the general
working policies. This system behaves as a central communication node among the different
environments making it possible for the information to move from one to another point in an easy,
uniform and controlled way.
3.7 Environments Migration Strategy
The environment migration strategy describes, for each element and environment, the preconditions required
in order to transfer that element, its target environment, and how this transference should be performed. This
strategy consists of a set of policies, protocols and procedures that define a univocal relationship between
different environments, thus providing coverage for the software’s life-cycle and enabling extra checks to
ensure its correctness.
Figure 1 shows the most relevant relationships between the system’s elements, which will be described in
detail in the next sections.
3.7.1 Development and Integration
This is the first migration process to be carried out; although it is not the most critical one, it is tedious
because of the large number of elements and resources involved: developers, deploying documents, control
version systems, etc.
In order to perform the migration, developers are in charge of committing the application modules into
the version control system. They are also asked to carefully tag the committed modules according to the
chosen policy.
Besides, the development manager maintains a set of deploying documents which are very useful in order
to detect technological mistakes or incorrect tag policy uses.
The version control system is the key for this transference, as it is used in the integration environment so
as to retrieve the files required in order to build the application.
To accomplish this task, the integration manager exports the committed modules from the version control
system into the integration environment.
Summarizing, the steps required in order to migrate our application from the development environment to
the integration one are:
• Developers commit their modules to the control version system.
• They also tag the modules according to the chosen policy.
• The integration manager exports the committed modules, which were previously selected by their
corresponding tag, into the integration environment.
• The integration team builds the application from the exported modules, following the deployment
document.
3.7.2 Integration and Pre-production
The preproduction is the stage where the application is deployed and tested preceding its transfer to the
production environment. Because it is a testing environment, the migration from the integration environment
is not critical; however, if we need to take it back to the previous environments —in order to correct errors—,
we must carefully follow the deployment documents so as to avoid any interferences between the different
environments’ configurations.
As in the latter case, a team member is assigned as preproduction manager, who is in charge of deploying
the application following the corresponding deployment document —which lists the implied modules and
their location.
3.7.3 Pre-production and Production
The migration from the preproduction stage to the production environment is the most critical phase, because
the latter one holds the real world application that supports the organization’s business processes, and
therefore has a direct impact on its economy. Thus, an erroneous management at this stage may imply a
considerable loss for enterprises.
IADIS International Conference e-Commerce 2005
293

6. Internet
Development environment
Development PC’s
Data
storage
LDAP
CVS
mySQL
Tomcat +
Apache
JBoss
Pre-production environment
Production environment
(JBoss)
Application
server
Web
server
(Tomcat +
Apache)
Tomcat +
Apache +
JBoss
mySQL
mySQL
mySQL
Storage environment
Integration environment
For this reason, to avoid introducing human errors, it is necessary to automate the application transfer
process base on deployment document.
After the migration, the assigned team checks if the application has been successfully transferred to the
production environment; if the transference failed, the team will apply a pre-established contention policy.
4. CASE OF STUDY: A CONCRETE INSTANCE OF OUR MODEL
The authors of this paper, as ICT consultants, have acquired a valuable experience in large distributed
applications —specially aimed at network management. We have also improved our knowledge through
research for models and architectures that specifically support eBusiness applications and facilitate their
development and maintenance. We have been using these methodologies for two years and, finally, we have
materialized and refined a concretion of our model for our own applications.
The general scenario for the model’s concretion is represented in figure 3, which shows the different
environments and infrastructures, IT equipment and software. Although it is a concrete technological
instance, the fact that it follows a generic model makes our IT instance flexible enough in order to allow the
replacement of its components or the addition of new ones, and therefore it can be easily integrated with
different technologies and adapted to changing business schemes.
In this section we introduce the materialization of our model, which is based on open-source, free code
and built on top of the J2EE platform.
4.1 Software Repository
The software repository provides two services: the version control system and the distributed file system.
Figure 3. Infrastructures scenario for eBusiness projects’ life-cycle management.
For the first service we analyzed several version control systems, and finally decided to use CVS [4]
because of its maturity and also because it is licensed as open-source code and supported by a wide
community. CVS is a client/server system based on an open protocol that allows remote access to the
projects’ files such source code, deployment instructions and other important documents. In addition, CVS
supports version tagging and file locking in order to avoid conflicts in concurrent work projects. At client
side, we use GUI programs (WinCVS and Cervisia) to access the CVS repository, in order to facilitate the
different operations with the projects’ files (commits, checkouts, tags and exports operations). Besides, CVS
can operate over secure transport protocols (SSL), which encode the information exchanged between client
and server, therefore avoiding possible security gaps. Finally, this version control system can be managed
under a role basis, where each role has its own rights in order to operate with the projects’ files.
On the other hand, the software repository also provides a file sharing service for files that do not require
version control —like third-party software or external documentation. This service is provided by a network
ISBN: 972-8924-06-2 © 2005 IADIS
294

7. file system based on the SMB protocol [5], which offers high interoperability through heterogeneous
networks.
The control version system and the network file service are both installed on optimized Linux servers
within our working environment [6].
Last, but not least, it is indispensable to safeguard the repository’s information through a suitable backup
policy. In order to complement the backup system, we use a network node regeneration system named GAIA
[10].
4.2 Tagging Policy
Software traverses several states throughout the entire development process used in the methodology that we
propose in this paper. In order to ensure the software’s proper operation, it is necessary to identify which
version is installed in each environment, and its maturity grade. In order to provide this identification, we
propose a nomenclature (see table 1) that associates each version tag’s name with the software’s state and
maturity for that particular version.
Table 1. Nomenclature proposed in the tagging policy for our model’s instance.
Environment Label syntax Prefix meaning
Development DR_ProjectName_ProjectVersion Development Release
Integration IR_ ProjectName _ ProjectVersion Integration Release
Pre-production PR_ ProjectName _ ProjectVersion Preproduction Release
Demonstration SR_ ProjectName _ ProjectVersion Show Release
Production FR_ ProjectName _ ProjectVersion Final Release
4.3 Development Environment
The development environment’s setup has been guided by a local work philosophy, where each developer
uses a workstation endowed with the tools and services required in order to the assigned tasks, thus providing
autonomous IT equipment so as to develop and test the application modules without interfering with other
members’ work.
However, some services can be shared without conflicts in concurrent development works, and thus they
can be provided by a centralized server and used safely by the entire team. This is the case of the LDAP [3]
directory service, where changes are introduced very seldom and they are so small that they do not interfere
with each user’s work; therefore, it is shared among all the users in the development and integration
environments,
Finally, a GUI CVS client is installed in each developer’s workstation in order to provide access to the
control version system in a secure, easy way.
4.4 Integration Environment
The main task carried out at this stage is the integration of the modules committed by developers, in order to
build the application. In addition, an integration test is performed so as to check the application’s integrity.
After that, the integrated application is submitted to a basic operating test.
For this environment to operate smoothly and efficiently, we will need the following services: A system
which automatically retrieves the files required in order to build the application, based on the established
tagging policy, a system that automates the application’s building process, thus performing every necessary
step (compilation, link, archive…) in order to obtain the application’s operative files (Apache ANT) and the
external applications and services required so as to run the application (Java Virtual Machine) [6].
In order to perform the operating tests, the application must be up and running, and therefore these tests
require the above mentioned external applications and services, such as the Java Virtual Machine, the LDAP
directory service, the database service, the application server together with the Web server, etc. However,
these applications and services can be downsized —it is not required that they suit the real world demands
[6].
IADIS International Conference e-Commerce 2005
295

8. 4.5 Pre-production and Production Environment
Because it is the real world environment, the production environment’s implementation is guided by the
business’ demands. This environment requires the necessary infrastructures in order to ensure the quality and
availability of the provided services, avoiding system offline periods that may damage our organization’s
economy. For this reason, we have concreted an instance of this environment which introduces replicated
servers so as to guarantee the system’s continuous operation and also in order to provide scalability attending
to service demand levels [6].
The reliability of the applications deployed in the real world environment is measured through a set of
tests performed in the previous stage —the preproduction environment. Therefore, the preproduction
environment should be an exact replica of the production environment, thus ensuring the application’s quality
before reaching its final stage. However, the economic cost of this replica has a strong impact and hence it is
sometimes downsized to match the organization’s budget [6].
Summarizing, the preproduction environment is implemented in order to perform exhaustive tests on the
application before it reaches the real world environment, thus ensuring its quality and availability. To achieve
this goal, we will build a replica of the production environment, scaled to match our organization’s budget —
although it should ideally be an exact replica.
4.6 Demonstration Environment
In many traditional markets, customers often feel the need to touch what they are buying. Because software is
an intangible, ethereal product, software market’s customers must satisfy this need in other ways: by
accessing a prototype, functional version of the application in development. In this way, they can follow the
development’s progress and also check that the application meets their requirements.
Therefore, we should always have an operative version of the application running, which could be
accessed by our customers. This is the demo environment’s goal.
Although the application is completely functional only in the preproduction and production environments,
none of these are appropriate in order to offer a test mode access for our customers. For this reason, we build
a scale model of the production environment, downsized in IT equipment and data collections. It is also
important to keep only dummy data in the demo environment, in order to ensure the privacy and security of
our application.
Finally, the choice of which version of our application must be deployed in the demo environment should
be guided by stability and maturity criteria —and not by the most recent’s one.
5. CONCLUSIONS
In this work we have analyzed the impact of the new enterprise models and IT technologies on the
development of large Internet applications; we have remarked the complexity derived from the specification
and management tasks in projects of such dimensions —which often results in colossal work for the
company’s CeO. Due to the time and resources demanded by these projects, they require well-defined
working models that support the software process’ different stages and incorporate the technologies and tools
used throughout this process.
Starting from these premises, we have proposed a working methodology based on several environments
that facilitate the complex tasks involved in the software’s process. Our proposal has been developed from its
initial, most generic conception to a concrete instance based on our group’s experience in the development of
large distributed applications. This implementation is sustained by free, open-source software and provides a
global environment which can be easily adapted to any project’s needs.
Besides, the proposed methodology follows several standards and platform guidelines which are widely
used in the software market. It also provides the means to adapt each environment to the specific needs for
each of the applications’ life-cycle stage, without diverting from the global project’s goals.
The presented case of use is the current framework of our groups’ activities and we are decided to
continue its development so as to improve its qualities and introduce new features which further automate the
software process.
ISBN: 972-8924-06-2 © 2005 IADIS
296

9. REFERENCES
[1] Atkinson, C. and Kühne, T., 2003. Model-Driven Development: A Metamodeling Foundation. IEEE Software, Vol.
20, No. 5, pp. 36-41.
[2] Booch, G. et al, 1999. El proceso unificado de desarrollo del software. Addison-Wesley.
[3] Carter, G., 2003. Ldap System Administration. O’Reilly.
[4] CVS, 1999. Concurrent Versions System. Available from : http://www.cvshome.org.
[5] Eckstein, R. et al, 1999. Using Samba. O’Reilly.
[6] Gilart Iglesias, V. and Capella D’alton, A., 2004. Entorno para el desarrollo de grandes aplicaciones de gestión de
redes. Desarrollo de grandes aplicaciones distribuidas sobre Internet, pp. 187-213. Universidad de Alicante.
[7] Gilart-Iglesias, V. et al, 2005. A model for developing J2EE applications based on design patterns. Proceedings of the
IADIS International Conference. Applied Computing 2005. Volumen I, Pág. 352-360, IADIS Press.
[8] Harmon, P. et al, 2001. Developing E-business Systems and Architectures: A Manager’s Guide. Morgan Kaufmann
Publishers.
[9] Jacobson, I. et al, 1999. El Lenguaje Unificado de Modelado. Addison-Wesley.
[10] Maciá Pérez, F., 2001. Modelos de Administración de Redes Heterogéneas de Computadores. Sistema de
Regeneración de Nodos de Red. Tesis Doctoral. Universidad de Alicante.
[11] Maciá-Pérez, F. et al, 2005. Decoupling MVC: J2EE Design Pattern Integration. Proceedings of the 7th
International Conference on Enterprise Information Systems, ICEIS 2005. Volumen III, Pág. 280-287, INSTICC
Press.
[12] Maciaszek, L.A., 2004. Requirements, analysis and system design. Addison-Wesley.
[13] MDA, 2003. Model Driven Architecture Guide. OMG. Available from: http://www.omg.org
[14] Métrica3, 2000. Metodología de Planificación, Desarrollo y Mantenimiento de sistemas de información. Ministerio
de Administraciones Públicas Español. Disponible en http://www.csi.map.es/csi/metrica3/index.html.
[15] Ochimizu, K. et al, 2000. Sharing Instability of a Distributed Cooperative Work. International Symposium on
Principles of Software Evolution ISPSE2000,IEEE Press, pp.36-45
[16] Pressman, R.S., 2003. Ingeniería del software: un enfoque práctico, quinta edición. McGraw-Hill.
[17] Sing, I. et al, 2002. Design Enterprise Applications with J2EE Plantaform, Second Edition. Addison-Wesley.
[18]Sommerville, I., 2001. Software Engineering. Addison-Wesley.
[19] Thomas, D. and Hunt, A., 2003. Pragmatic Version Control Using CVS. The Pragmatic Programmers.
[20] UML, 1997. The unified modeling language home page. Available from: http://www.uml.org.
[21] Vering, M. et al, 2001. The E-Business Workplace: Discovering the power of enterprise portals. Wiley & Sons.
[22] Yee, A. and Apte, A., 2001. Integrating your e-Business enterprise. SAMS Publishing.
IADIS International Conference e-Commerce 2005
297