INTERNATIONAL JOURNAL OF COMPUTER ENGINEERING ... · International Journal of Computer Engineering...
Transcript of INTERNATIONAL JOURNAL OF COMPUTER ENGINEERING ... · International Journal of Computer Engineering...
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 –
6367(Print), ISSN 0976 – 6375(Online) Volume 3, Issue 3, October-December (2012), © IAEME
459
AN INTEGRATED FRAMEWORK FOR INTEROPERABLE AND
SERVICE ORIENTED MANAGEMENT OF LARGE SCALE
SOFTWARE
Tanmaya Kumar Das
1 , Dillip Kumar Mahapatra
2, Gopakrishna Pradhan
3
1 (Department of Computer Science & Engineering, C.V. Raman College of Engineering,
Bhubaneswar, Odisha, India / Biju Pattanaik University of Technology, Rourkela, Odisha,
India, E-mail : [email protected])
2(Department of Information Technology, Krupajal Engineering College, Bhubaneswar,
Odisha, India / Biju Pattanaik University of Technology, Rourkela, Odisha, India,
E-mail : [email protected]) 3 (Ex- Professor, Deptt. Of Computer Science and Engineering, SOA University,
Bhubaneswar, Odisha/ India, E-mail : [email protected]
ABSTRACT
In current scenario, business enterprises are required to deliver improved functionality
and provide on-demand services, while leveraging existing IT infrastructure and investment.
They are expected to be agile and dynamic. It is the globalization, tighter economies,
business process outsourcing and ever increasing regulatory environments that are forcing
businesses to transform the way they provide their business and services. As the scales of the
projects get larger, the complexities involved in managing projects increase and the
likelihood of failures. In this context, some highlighted architectures like; Service Oriented
Architecture (SOA) ,Agile and open source architectures are proving be an attractive
approaches , promise better alignment of IT with business vision, more effective reuse, better
interoperability and most importantly management of large software projects, reduced costs
of development and more efficient operation of business applications. However, these
approaches have limitations and inherent issues. This paper proposes an integrated
framework to introduce interoperable and service oriented management of large scale
software projects by addressing the limitations of previous architectures.
Key words: Large Scale Software (LSS), Agile methodology, Open Source Development,
SOA, Interoperability, Integration, SAS.
INTERNATIONAL JOURNAL OF COMPUTER ENGINEERING
& TECHNOLOGY (IJCET) ISSN 0976 – 6367(Print) ISSN 0976 – 6375(Online) Volume 3, Issue 3, October - December (2012), pp. 459-483 © IAEME: www.iaeme.com/ijcet.asp Journal Impact Factor (2012): 3.9580 (Calculated by GISI) www.jifactor.com
IJCET
© I A E M E
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 –
6367(Print), ISSN 0976 – 6375(Online) Volume 3, Issue 3, October-December (2012), © IAEME
460
I. INTRODUCTION
Many large scale projects carried out by government are failures, even though they
may eventually deliver what was expected. The failure is often in terms of timescale, costs or
system errors. These factors may be internal to the project, such as the skills of the team
working on the project, or external, such as the business changing in such a way that the
project becomes irrelevant to the current needs(Ref.03).
Government and commercial organizations have been placing increasing reliance on
interoperability among large numbers of systems for achieving important mission goals. One
mechanism for both achieving interoperability and for leveraging the value of legacy systems
is for organizations to expose all or parts of their legacy systems as services. A service is a
coarse-grained, discoverable, and self-contained software entity that interacts with
applications and other services through a loosely coupled, often asynchronous, message-
based communication model.
In order to build quality software faster and cheaper companies in industrialized
countries are turning to Globally Software Development Projects. A number of economical
and technical trends are likely to further accelerate the growth of distributed software
development. Economical trends include globalization of the industry in general. Multi-
national companies often require software systems to be developed for geographically
dispersed locations. Moving parts of the development process to emerging countries can
decrease development cost . Another perceived advantage of global distribution is the
reduction in project life-cycle times by using time zone differences to organize “round-the-
clock” development .On the technological side, ongoing innovations in Web-Technology, by
eliminating the perception of distance, create new possibilities to cooperate in software
development projects in a distributed mode. Moreover, software industry has recently started
to adopt a more modular component-based architecture that further facilitates distributed
development of software products. Traditionally, component-based architectures have been
successfully used in industries such as aircraft, automotive, electronics, computers, for
setting-up globally distributed design and production. Within the software industry,
component-based development by reducing interdependencies between components, holds
the promise that software components may be developed largely independently at dispersed
sites.
Given the increasing importance of GDSD, it is more important to give stress on the
management activities of conducting large scale software projects under time, governance,
infrastructure, and culture gaps, associated with the geographical dispersion of work, make it
more difficult to manage inter-site work dependencies and to coordinate and control the
distributed work.
Furthermore, few commercially well accepted architectures have been used in the field
of Global software development, but with some well distinct limitations especially people
management technical management and in process management.
In the following sections, we have drawn some key limitations of existing frameworks
in a comparative way and attempted to propose an integrated framework to overcome these
limitations.
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 –
6367(Print), ISSN 0976 – 6375(Online) Volume 3, Issue 3, October-December (2012), © IAEME
461
II. SOFTWARE PROJECT SUCCESS FACTORS
For the success of carrying out any software project always reach at a win-win
situation where, both the developers and users/stakeholders finally meet. We outlined some
of the major factors to drive projects towards the objectives(Ref.02).
User involvement: When the user is involved from the beginning of the project the project
team will be getting input from the people who are going to be most affected by the system
that is being built. The project team can use their experience and knowledge to help in setting
out what is expected, what is useful and can use their feedback as the project progresses to
find out whether what is wanted is being delivered. Without user involvement people are
likely to be hostile to the project because people fear change.
Management support: Support from the management is essential if a project is to succeed.
The management has to agree with the project and they have to support it with money and
personal commitment. Managers are often busy people and unless they support a project it is
unlikely that they will put the time and effort in to make it succeeds or that their staff will.
Skilled experienced project managers and staff : A successful project needs project
managers who can manage the project well. It also needs to have staff that has the right mix
of skills to do all the jobs that are needed.
Clear expectations: Everybody involved in the project needs to know exactly what they will
get out of the project, what needs to be put into the project, which will be doing what, when it
will happen, how much it's going to cost and so on. These clear expectations about everyone
involved to matter whether the project is going to be successful or not.
Well defined scope: This is one of the most important factors in a successful project. The
scope of the project shows exactly what will be done and what the boundaries of the project
are. It will also show what other systems the project has to communicate with. Many
government projects which are subject to project ‘creep’ fail in the end because the scope has
not been successfully defined. For example, a system that is designed to hold customer
records is being developed. During development is decided it will also deal with customer’s
bills that these will be dealt with over the Internet etc. The functionality for this has to be
built and this will affect timescales.
Clear statement of requirements: A clear statement of requirements is part of
understanding what the expectations are. The statement of requirements says this is what the
client wants and tells everybody what should be produced. Without a clear statement the
developer is working in a fog, building what they hope the user wants. When it's developed
the user is likely to say that's not what I wanted.
Prototyping: Prototyping is used in developing systems. It shows the user at an early stage
what the system will look like and what it will do. If the user does not like what is being
shown on the prototype can be thrown away or adapted very quickly. This means that lots of
feedback can be gathered from the user of the system at an early stage and throughout the
development of the project. Sound methodology used some methods the developing systems
are easier to manage than others and some more likely to succeed, particularly in large-scale
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 –
6367(Print), ISSN 0976 – 6375(Online) Volume 3, Issue 3, October-December (2012), © IAEME
462
projects. Using a sound methodology that is understood by all involved will help the project
to succeed.
Extensive testing: During the development stage of software project the soft, testing needs to
take place at every stage. The requirements need to be checked with all involved; the designs
need to be tested; prototype's need to be tested by the user and others involved; each part of
the system needs to be tested and the whole system tested. There is statistic that says that
80% of the effort should go into testing and only 20% into development. The more testing
that takes place the more likely it is that the project will finally be successful. Testing will
also involve adequately training users so that they can do user testing. Time must be built in
to do this.
Comprehensive planning: A well planned project that has been broken down into all the
parts that are needed and all the tasks that are required will make it clear what are the critical
path is. The critical Path shows deadline is that must be met if the project is to be delivered
on time. It will also show any dependencies, were one task is dependent upon another task
being completed. This makes it clear what resources are needed and when. Clear milestones
should be set out at checkpoints for progress on the project. Contingencies should be built in
to allow for unexpected problems.
Expectation mismatch: Where all the people involved in the project are not agreed on what
can be expected then there is little chance that the project will be successful. One person
might be expecting a Rolls-Royce and another person might be expecting a Mini. But what
the developer gives them is a Mondeo. In the end none of them will be satisfied.
Poor communication: Poor communication between people involved in the project is similar
to the expectation mismatch; unless people are kept up to date with what's going on it is
likely that they'll be pulling in different directions. It can also cause bad feeling among the
project team and between users and developers all users and management or developers and
client.
Assigning staff with lack of skills: If the staff assigned to the project doesn’t have the right
skills to carry out the tasks that are needed or to do the jobs that are needed then the project
won't succeed. You have to have the right staff doing the right things at the right time. One
people factor involved here could be people who can't say no. This often means that the
project team promises something they can't deliver and stores up problems for later on.
Inflexibility in delivery dates: Complex projects can be very difficult to predict and manage.
With the best will in the world it's not always possible to meet deadlines. If there is complete
inflexibility in delivery dates for parts in the project or the project overall then it is likely that
either things will be rushed to meet the deadline and will fail in other parts, or that too much
effort will be put into meeting the deadlines and calls cost overruns, or any one of a number
of reasons.
III. LARGE SCALE SOFTWARE PROJECTS: ADVANTAGES, RISKS AND
CHALLENGES
Large Scale Software Projects especially carried out globally has a number of
potential benefits, including shortening time-to-market cycles by using time-zone differences
and improving the ability to quickly respond to local customer needs. Globally distributed
software engineering also allows organizations to benefit from access to a larger qualified
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 –
6367(Print), ISSN 0976 – 6375(Online) Volume 3, Issue 3, October-December (2012), © IAEME
463
resource pool with the promise of reduced development costs. Another potentially positive
impact of globally distributed engineering is innovation, as the mix of developers with
different cultural backgrounds may trigger new ideas(Ref.02).
According to the industrial practice, the most common reasons for collaboration were
to reduce development costs, to acquire competence (technology competence or knowledge
of a specific market) and to avoid investing in a company’s non-core competence areas.
Further reasons included potential timesaving, the establishment of new business
opportunities with new partners, flexibility with respect to the number of in-house resources
and overcoming problems of availability of in-house resources. In some cases the company’s
whole business can be based on collaboration; for example, if the company is developing a
component that is meant to be used as part of another product such as a COTS (commercial-
off-the-shelf) product, or if it is offering human resources, i.e., developers (expertise
providers and consulting companies).
There are also several risks involved in Large Scale Software Projects. The general
risks associated is the openness of communication between partners; for example, problem-
hiding may be an issue in customer–supplier relations. Furthermore, unclear assignments,
lack of trust between partners, difficulties in agreeing on intellectual property rights and the
unreliability of the partners’ development schedule were seen as risk factors for any mode of
collaboration. From the supplier’s or licensor’s viewpoint, the risks mentioned concerned the
continuation of the collaboration in the future and predicting the most saleable product
features correctly during road-mapping. On the other hand, from the customer’s point of
view, the quality of the acquired product (e.g., reliability and performance) and becoming too
dependent on one partner were seen as risks. Finally, competence issues, such as the
competence of new partners and a weakening of one’s own competence were also mentioned
as risks.
These are not specific to particular industries or company sizes, but rather to the underlying
life-cycle processes and management practices. The risk list is as follows:
1. Project-delivery failures, the risk of being late or over budget amplifies in probability
and impact due to the difficulties of managing a global development team.
2. Insufficient quality, in GSE, many work products are moved across places and teams
with the risk of insufficient quality due to that, the teams suppose that there will still
be sufficient validation “downstream” so that quality deficiencies accumulate.
3. Distance and culture clashes: GSE are highly impacted by work organization and
effective work split. GSE causes overheads for planning and managing people, e.g.,
due to language and cultural barriers.
4. Staff turnover (mostly for captive centres), is a specific risk especially in Asian
countries due to abundant job opportunities in the respective economies. High turnover
requires more investment in training and monitoring of the work.
5. Poor supplier services (only for outsourced GSE), a frequent risk with third party
suppliers is not meeting the expectations in terms of quality and delivery schedule.
6. Instability with overly high change rates, often being present in different markets with
individual engineering teams means that each of the teams first of all looks to needs of
the local market. When products and features are assembled, inconsistencies appear
which cause late requirements changes.
7. Insufficient competences is amplified in GSE by the bigger dependencies given the
globally distributed team combined with less visibility on resource planning and skills
availability.
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 –
6367(Print), ISSN 0976 – 6375(Online) Volume 3, Issue 3, October-December (2012), © IAEME
464
8. Wage and cost inflation, the global fight for software engineering talent creates a major
risk of wage inflation, causing it more expensive to keep the required competences
working in the project. 9. Lock-in (only for outsourced GSE), with GSE supplier competition on a global market,
external suppliers often start with rather low rates and once the projects are sufficiently large
clients might be forced to lock-in with them due to progress of product development and
knowledge transition. In the least we may have to face increasing cost inflation
10. Inadequate IPR management, software is not patented and copyrights are not enforced equally
in all regions of the world. Further risks are related to improper use of external software (e.g.,
OSS) and careless handling of confidential information.
Some major challenges of conducting large scale software projects are effective communication,
cultural differences, coordination, time-zone differences and trust. Similar to these findings and a
commonly referenced classification for challenges caused by globally distributed development.
• Communication breakdown (loss of communication richness)
• Coordination breakdown
• Control breakdown (geographical dispersion)
• Cohesion barriers (loss of “teamness”)
• Culture clash (cultural differences).
Communication breakdown (loss of communication richness): Human beings communicate best
when they are communicating face-to-face. A software engineer would usually prefer to conduct a
difficult design session face-to-face because people communicate with more than mere words
(e.g., drawings on whiteboards, body language etc.). Communication over distance frequently
leads to misinterpretation and that often leads to errors in development. In a distributed project,
people cannot communicate well due to language barriers and the unavailability of resources.
Coordination breakdown: Software development is a complex task that requires on-going
adjustment and coordination of shared tasks. In geographically distributed projects, the small
adjustments usually made in face-to-face contact do not take place or it is not easy to make
adjustments. Thus, problem solving gets delayed or the project goes down the wrong track until it
becomes very expensive. GSE also sets additional requirements for planning; for example, the
need for coordination between teams and the procedures and contacts for how to work with
partners need to be defined: in addition to project manager, also the project members such as
testers, technical leader, and developers also need to be kept informed and notified for certain
information and events which are relevant to their roles’ objectives in timely manner and provide
basis for in-time decision making. Coordination breakdown can also cause a number of specific
problems due to a large number of independent teams.
Control breakdown (geographical dispersion): Management by walking around the development
team is not feasible and, instead, telephones, E-mail and other communication means (e.g., chat
servers) have to be used. This kind of communication is less effective and cannot always give a
clear and correct status of the development site. Also, dividing the tasks and work across
development sites, and managing the dependencies between sites is difficult due to the restraints
of the available resources, the level of expertise and the infrastructure. Despite flexible working
hours and communication technologies that enable asynchronous communication, creating the
overlap in time between different sites is challenging. Lack of overlap leads to a delay in responses with a feeling of “being behind”, “missing out” and even losing track of the overall
work process.
Cohesion barriers (loss of “teamness”: In working groups that are composed of dispersed
individuals, the team is unlikely to form tight social bonds, which are a key to a project success.
Lack of informal communication, different processes and practices have a negative impact on
teamness outlined that fear (e.g., of losing one’s job to the other site) directly impacted negatively
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 –
6367(Print), ISSN 0976 – 6375(Online) Volume 3, Issue 3, October-December (2012), © IAEME
465
on trust, teambuilding co-operation and knowledge transfer, even where good relationships
existed beforehand. They also stated that fear and lack of trust negatively impacted on the building of effective distributed teams, resulting in clear examples of not wanting to
cooperate and share knowledge with remote colleagues. It is found that tools can promote
trust by sharing information derived from each developer’s activities and their
interdependencies, leading to a greater likelihood that team members will rely on each
other and thus leading to a more effective collaboration. Establishing and maintaining
teamness in a distributed development environment is difficult: while websites with
photos and individual profiles serve a purpose, the common solution still seems to be
travelling between sites.
Culture clash (cultural differences:. Each culture has different communication norms.
The result of these differences is that in any cross-cultural communication the receiver is
more likely to misinterpret messages or cues. Hence, the miscommunication across
cultures is always present. The cultural indexes, power distance (degree of inequality of
managers vs. subordinates), uncertainty avoidance (tolerance for uncertainty about the
future) and individualism (strength of the relationship between an individual and their
societal group), were found to be relevant from the software engineering viewpoint. Here,
the inherent challenge of creating a mutual understanding between people from different
backgrounds. Often, general understanding in terms of English is considered as good, but
more subtle issues, such as political or religious values, cause misunderstandings and
conflicts during projects.
People Process and Technology (PPT): More importantly, for large scale software projects,
there are three major factors, need to be entertained carefully like; people management,
process management and technology management to deal with Intercultural diversity,
dispersed development teams and Inefficient technologies.
IV. CAUSES OF LARGE SCALE SOFTWARE PROJECT CHALLENGES
In order to gain a more comprehensive view on the Large Scale Software (LSS)
challenges in general, a structure to depict the problem and challenge area is needed. Root
causes are the fundamental reasons behind the challenges in LSS, i.e., they cause challenges
that can be addressed via specific solutions (e.g., practices)(Ref.04).
Fig 1.Causes of Large Scale Software Project challenges
General LSS Causes Time differences
and distance
Multiple
Stakeholders
Consequent LSS Causes
Lack of
teamness and trust
Derived LSS Causes Diversified
Backgrounds
Lack of
Communication Coordination
Breakdown
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 –
6367(Print), ISSN 0976 – 6375(Online) Volume 3, Issue 3, October-December (2012), © IAEME
466
Some of them are not necessarily LSS specific, such as multiple parties/stakeholders, but they
are causes that are present in every LSS project. Root causes are things that cause multiple
challenges in LSS, challenges can be addressed by solutions and if they are not properly
addressed, problems appear. These root causes are derived from two sources: 1. literature, by
analysing what other researchers have proposed as causes and their relations, and 2. from
challenges expressed by industry and the causes behind them.
The root causes are taken into consideration from three aspects – people, processes
and technology – in order to gain a comprehensive understanding of the causes. However,
they have not been connected to the industrial problems and challenges; that is, industry faces
problems caused by these issues, not from these issues themselves. For example, a company
does not state as a problem that there is a challenge of differences in backgrounds or
coordination breakdown, but that they get bad quality deliveries from the other sites.
Moreover, the root causes are interconnected and the relations are marked with lines in
Figure 2. In summary, time difference and distance can lead to a lack of communication and
coordination breakdown, multiple partners may cause a lack of communication and
coordination breakdown, and the people involved have different backgrounds and, thus,
different tacit knowledge. These causes together – if not properly addressed – lead to a lack
of “teamness” and trust.
4.1 General LSS Causes
It includes matters that are an intrinsic natural part of large scale software. They directly
complicate LSS as well as cause further challenges. The basic circumstances are:
Multiple parties: When two or more different teams and sites (locations)of an organisation or
no. of organizations (or parties) are involved, different working cultures and backgrounds
usually play an important role.
Time difference and distance: It is caused by the geographical distribution of the parties.
Distance is always present in LSS and the extent of the distance seems to be less relevant, as
research has shown that a team separated by as little as 100 meters can have communication
reduced by as much as 95% (Simons, 2006). However, time difference may not always be
present in distributed development if the parties are in the same or in nearby time zones .They
are directly caused by these basic circumstances include issues such as unclear roles and
responsibilities for the different stakeholders in different parties/locations, knowing the
contact persons (responsibilities, authorities and knowledge) from different locations and
establishing and ensuring a common understanding across distance. The basic circumstances
can also cause poor transparency and control of remote activities, difficulties in managing
dependencies over distance, problems in coordination and control of the distributed work and
integration problems. Basic circumstances may also cause problems in terms of accessing
remote databases and tools, they may generate data-transfer problems caused by the various
data formats between the tools or different versions of the tools used by the different teams
and the basic circumstances may also cause problems with data security and access to
databases or another organisation's resources. Although these issues are directly caused by
the basic circumstances, they may be amplified by the derivative causes.
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 –
6367(Print), ISSN 0976 – 6375(Online) Volume 3, Issue 3, October-December (2012), © IAEME
467
4.2 Derived LSS Causes
These are causes that may not be present in every LSS situation and their effects can often be
avoided with proper practices and ways of working. These are because of:
Lack of communication: Communication is difficult in geographically distributed
development. For example, if there is a lack of overlapping working hours due to the time-
zone differences, arranging face-to-face meetings is complicated and expensive. Distribution
may also hinder informal or unplanned communication as all this has to be managed and
supported through communication tools, and still the richness of communication (e.g., due to
body language not being visible) may suffer. The loss of communication richness also creates
miscommunication. Additionally, the problems in distributed development are not solved as
effectively as in co-located development because of the communication related issues.
Coordination breakdown: Dividing and coordinating the tasks and work across development
sites is difficult due to the restraints in the available resources, differences in levels of
expertise and infrastructure,
Diversified Background: It May imply that the ways in which teams work are not the same as
are assumed and this can cause problems. Different backgrounds also involve differences in
tacit knowledge causing misunderstandings and wrong assumptions. For example, ineffective
use of resources as competences are not known from other sites, obstacles in resolving
seemingly small problems and faulty work products due to a lack of competence or
background information. These causes can also lead to a lack of transparency in the other
parties’ work, misunderstood assignments and, thus, faulty deliveries from parties, delays
caused by waiting for the other parties’ input and duplicate work or uncovered areas. Further
problems that can be caused by these issues include differences in tool use or practices in
storing information, misplaced restrictions on the access to data and unsuitable infrastructure
for the distributed setting. If these issues are not addressed well, the appearance of
consequent problems is more likely.
4.3 Consequent LSS Causes There are the causes that are not always present in LSS, but if they are they have a major
impact on the distributed software development project. The basic circumstances and
derivative causes increase the chance of these problems being present. By addressing the
derivative causes well, these problems may be avoided. Consequent causes include:
Lack of teamness It :Refers to a lack in the creation and maintenance of a common bond and
identity in a team. Teamness helps a team to work better together as it improves co-operation
and commitment to the team’s goals. Different processes, practices and cultures tend to
diminish teamness.
Lack of trust :It Refers to mistrusting partners, manifesting as an unwillingness to help each
other and the placing of blame instead of working together towards a common target. The
role of trust is always significant in collaboration as it is very difficult, if not impossible, to
make “perfect “contracts, covering all aspects of a relationship. This include hiding problems
and an unwillingness to ask for clarification from others, expending a lot of effort in trying to
find that the cause of problems (defects) has occurred in the other parties’ workplace, an
unwillingness to help others and an unwillingness to share information and work products
until specifically requested to do so. These causes may also appear as difficulties in agreeing
about the practices to be used and then not following the process and practices as agreed, for
example. Further problems caused by these issues include the use of other tools than those
agreed to for the project and plentiful technical issues that hinder communication and use of
the tools, as agreed.
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 –
6367(Print), ISSN 0976 – 6375(Online) Volume 3, Issue 3, October-December (2012), © IAEME
468
V. PRE-USED METHODOLOGIES FOR LARGE SCALE SOFTWARE
DEVELOPMENT
A software development methodology is a framework that is used to structure, plan,
and control the process of developing software products, include the pre-definition of specific
deliverables and artifacts that are created and completed by a project team to develop or
maintain an application(Ref.09).
Fig 2. Basic approaches for software development methodology frameworks.
A wide variety of frameworks have evolved over the years, each with its own recognized
strengths and weaknesses. One software development methodology framework is not
necessarily suitable for use by all large scale software projects. Each of the available
methodology frameworks are best suited to specific kinds of projects, based on various
technical, organizational, project and team considerations.
These software development frameworks are often bound to some kind of organization,
which further develops, supports the use, and promotes the methodology framework. The
methodology framework is often defined in some kind of formal documentation. Specific
software development methodology frameworks include; Agile Software methodology, Open
Source, SOA framework etc.
5.1 AGILE SOFTWARE DEVELOPMENT Agile Software Development is a concept, a philosophy and a methodology which evolved in
the 90's as an answer to the long-growing frustrations of the waterfall SDLC concepts. The
term promotes an iterative approach to software development using shorter and lightweight
development cycles and some different deliverables. Agile is not a specific methodology, but
a higher concept representing and Iterative approach with newly defined underlying
principles. It is with each approach you can see the specific deliverables and concepts for
how to work the process. Under this broad term of 'Agile Software Development' there are
other approaches such as Extreme Programming, Scrum, Lean Development, and RUP. Each
of these more particular approaches has its own ideas, communities and leaders(Ref.01).
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 –
6367(Print), ISSN 0976 – 6375(Online) Volume 3, Issue 3, October-December (2012), © IAEME
469
XP (Extreme Programming): Extreme Programming (XP) is actually a deliberate and
disciplined approach to Agile software development. One of the first approaches to gain
main-stream success, Extreme was found to be most successful at smaller companies
especially in the dot-com boom.
XP is successful because it stresses customer satisfaction. The methodology aims to deliver
the software to the customer needs on time. XP allows the software developers to confidently
respond to changing software requirements, even late in the life cycle.
\
This methodology additionally focuses on team work. Managers, customers, and developers
are all part of a team dedicated to delivering quality software. XP implements a simple and
effective way to enable groupware style development.
XP improves a software project in four essential methods; communication, simplicity,
feedback, and courage. XP programmers communicate with their customers and
programmers. The design should be simple and clean. They get feedback by testing their
software starting on day one and deliver the system to the customers as early as possible and
implement changes as suggested.
Agile Development with Scrum: Agile and Scrum development methodologies aim to
correct the problem of projects not having an end in site most likely from out of control
software requirements. Scrum solves this by applying what will appear to be common sense
after you engage in the methodology for a few projects. This Agile software development
method has some very key principles.
1. Deliver products based on need from high-priority down.
2. Deliver the absolute minimum that the customer wants.
3. Eliminate waste from your projects wherever possible.
4. Deliver projects in short bursts, called iterations.
Scrum is a rugby offensive term where a team pushes forward to score as a single unit. Scrum
is a communication methodology more than a development methodology and because of that,
it can be applied to almost any type of project. Scrum consists of the following core believes:
1. The customer lists all the features they want in priority order.
2. Development efforts are broken into 30 day iterations called sprints.
3. Scrum teams are multi-functional teams that contain all the facets of the team that is
needed to complete the projects.
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 –
6367(Print), ISSN 0976 – 6375(Online) Volume 3, Issue 3, October-December (2012), © IAEME
470
Fig.3: Agile development framework
The Agile (Rational) Unified Process Framework: Another well-known process to have
come out of the object-oriented community is the Rational Unified Process (sometimes just
referred to as the Unified Process). The original idea was that like the UML unified modeling
languages the RUP could unify software processes.
RUP is a large collection of methods and is a process framework rather than a process. Rather
than give a single process for software development it seeks to provide a common set of
concepts for teams to choose from for an individual project. As a result a team's first step
using RUP should be to define their individual process, or as RUP calls it, a development
case. The key common aspects of RUP is that it is Use Case Driven (development is driven
through user-visible features), iterative, and architecture centric (there's a priority to building
a architecture early on that will last the project through).
5.1.1 Agile Software Development myths
Agile development was a movement that started more than a decade ago and now is a
commonplace discussion for software development teams. Prior to the signing of the Agile
the world was using a phased methodology called “Waterfall,” introduced, ironically trying to
explain why that methodology was a bad idea. The methodology forced the completion of a
phase in order to continue with the next one. That caused some problems since, no matter
how hard the developers tried to gather all requirements and create a full system design, there
was always the need in the following phases to go back and change things. Those regressions
had a big impact on cost.
The Agile principles tried to eliminate all the rigidity of Waterfall by focusing on more
productive tasks, like working code over comprehensive documentation, adding more
customer collaboration, enforcing individual interactions instead of tools and being agile by
responding to change instead of following a static plan . Those ideas took the world by storm
and suddenly many software development teams were adopting one of the different
methodologies that claimed to be Agile in order to deliver better products at a lower cost, on
time. But that did not always happen and began to appear document Agile failures and due to
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 –
6367(Print), ISSN 0976 – 6375(Online) Volume 3, Issue 3, October-December (2012), © IAEME
471
that misunderstanding, a set of myths emerged, misconceptions that further made people fail
to achieve the promised business value. Let’s review some of those myths.
Myth 1: Agile means no phased development: Even worse: phased development means
Waterfall which, in turn, means having design up front, and anything up front is not Agile. It
is true that sometimes you can go on following agile methods and still have Waterfall
underneath, but there is also the underlying thinking of phased development as a synonym for
Waterfall.
Problem of large development by means of an example where the entire process divided the
development tasks (gathering requirements, designing, coding, and testing) in strict
sequential phases. The problem, he explains, is related to the distance from where the
requirement is defined to where the actual achievement is verified (testing).
Still, the phases became a forbidden word in the growing Agile world, and teams started to
try to do all the tasks at the same time or execute smaller phased cycles. Reducing the time
for tasks causes an accompanying reduction in the result quality. Having too little or no time
at all for designing (just jump into coding) generates a product that will probably need
refactoring later; or even more, it may not integrate well or will not deliver the needed
business value. The same will happen for poorly analyzed requirements or inadequate testing.
Also, this leads to the next myth.
Myth 2: Agile needs no architect or project management: This is an interesting myth, based
on the principles of favoring the response to changes over following a plan and favoring
working code over comprehensive documentation. To many, project managers are directors
that only dictate to software developers, draining precious time from development with
useless meetings, reports and control. The architects are seen as bureaucrats, large document
generators focused on up-front modeling.
So, in order to avoid following a plan and generating documents, Agile teams removed the
architect and project manager roles. The problem is much of the project management and
architecture tasks are required for successful development, especially in large systems. Many
of the actual problems in development are due to the freedom the developers experience in
the agile process. While freedom is good, having no one to watch over in order to assure
everything is working correctly can lead to a software product, large-scale Web, or mobile
app that is not able to integrate correctly. The result can be time lost in refactoring and feature
fixing.
Being able to take a look at the whole system in higher views (architect) and control and help
with resources (project manager) is necessary for some more challenging and large projects
to succeed. And of course, having these two roles in the team, working following solid Agile
principles, will not break the Agile outcome desired.
Myth 3: Documentation is bad: Despite several attempts to make documentation fit the Agile
world the ideal in the Agile movement is to have documents whose cost of production is
lower than the benefit. That is, at least someone has to read the documents and use that
knowledge. Documentation should then be created when necessary and at the correct time,
not up front.
The documentation should be replaced by face to face communication per Agile principles.
The problem here arises when there are multiple teams, separated by distance, or changing
over time in a long-lasting software development project. In any case, some knowledge has to
be captured in documents for others to read in case there is no chance of face-to-face
communication.
Documents are also commonly associated with models, diagrams and manuals. There are
other types of information that can be forgotten. The lack of documentation about decisions
and the rationale behind them generates rework when team members start repeating the same
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 –
6367(Print), ISSN 0976 – 6375(Online) Volume 3, Issue 3, October-December (2012), © IAEME
472
mistakes or going the same path that was proven unsuccessful in previous projects. The lack
of models also condemns the project managers and product owners to read code or ask
developers directly if they want to know what is going on. This generates costs and there is a
risk of poor quality information institutionalized to support future decisions.
Myth 4: Agile means no planning: This myth somehow relates to Myth 2 (we need no project
manager controlling us with a static plan). The sins of a predictive plan are the risk of the
actual prediction (requirements and time estimates) and the cost of changing the tasks in the
plan to incorporate requirement changes.
But in Agile we still need to estimate work, albeit not to define the project length and cost,
but at least to accommodate the work in a sprint and see if all the backlog of tasks are still
executable under the timeframe and budget. Also, we still need to know what is going to be
done in the near future to assign resources and check dependencies. So, we cannot get rid of
planning that easy. The actual meaning of “responding to change over following a plan” is
related to awareness and feedback. Static plans are made using predictions and not allowing
space for changes and decisions introduced by late-arriving information. In that case, a plan
should be the one that defines the development principles and provides a guide for decisions
along the path.
It must be structured to stop development at precise moments to incorporate all the
knowledge gathered up to that point (feedback) and make the changes to the plan accordingly
(no predictability, but adjustability). So, plans are important to provide a guide, but they
should always be open to change.
Myth 5: Follow the methodology and you have Agile: The common answer to why Agile
projects fail is simply because you are not doing Agile the correct way. Isn’t following Agile
methodologies good enough to be agile? Actually no.
Agility principles try to improve the development cycle by making developers more
collaborative, and including clients in that collaboration. It also tries to improve productivity
by reducing non-beneficial tasks. Still, there are a lot of decisions that should be taken using
information gathered from all stakeholders and coming from traditional development tasks
like requirement analysis and system design.
The common outcome is, for large companies with large software systems using traditional
processes, the change of methodology only happens at software team level, meaning the
client stakeholders are not actively included on the team. With that we have lost most of the
information that should come from the client. Then, by following the methodology only,
there are other tasks that are not performed, hurting the second part of the information (peer
reviews is an example). Agile methodologies are a guide, but they are not the whole solution,
and should be adjusted to the project characteristics. This also introduces our last myth.
Myth 6: Agile is good for any project: This myth may not be totally wrong but should be
taken with caution. Agile has been proven as a good paradigm for small teams working on
small projects or even large projects in small stages.
The main point here is there may be ways to apply the agile principles to large projects and
large/distributed teams, but all require modifications and special care. We cannot take the
methodologies as they are and expect to have successful results without taking care of
information volume, team and sub-teaming, collocation, etc. All these myths can be found in
discussions, blog posts, even books. Being aware of them helps managers and developers to
adopt strategies in order to avoid them and also helps to understand more about Agile and
how it can help deliver the desired outcomes.
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 –
6367(Print), ISSN 0976 – 6375(Online) Volume 3, Issue 3, October-December (2012), © IAEME
473
5.1.2 Management practices in Agile Methodology
While the engineering practices present real limitations for Agile, the management practices
don't look so negative a first glance. After all, stand-up meetings and short iterations don't
need technology.
Without tool support it is hard to know when a piece of work is completely done. Unless
work can be completely done, it is impossible to keep meaningful fixed-length iterations.
Carrying work from iteration-to-iteration, again-and-again, reemployments the code-test-fix-
test cycle and there is no certainty when work will actually be completed. This in turn leads
to pressure to increase the iteration length, jeopardizing the short cycles and frequent
feedback.
Multi-disciplined, cross-functional, teams are another management practice in Agile. Having
people work on what is required next rather than only in that area in which they specialize
ensures the highest priority work is done and evens the workflow. Yet this too is difficult
with many legacy systems.
While staff who have been with the system for a long time may well be keen to learn new
techniques - or in some cases resurrect lost ones - the same is not true of younger staff who
may be reluctant to work on old technology. Even when the technologies in question are
close, like C and Java, I have seen staff refuse to work with the older language for fear of
being drawn in.
The legacy nature of much COBOL and C doesn't help either. To be proficient in a large
system may require months, even years, of experience. It may be unrealistic to expect an
experienced COBOL developer to jump in and start making changes overnight to part of the
system they don't know.
With SAP the situation is more complicated still. While SAP markets their systems as
common, the reality is that different SAP modules require different skills to implement them.
SAP HR is different to SAP Financial, which is different to SAP Logistics, and all of these
are different to ABAP, the underlying COBOL-like language.
Another complication with SAP is the business model operated by the eco-system. SAP
implementation projects are not normally a core competency for a corporate IT department,
so they bring in consultants from multiple consultancies to implement different parts of the
system. The consultants and their employers expect them to work with their core, named,
SAP skills and not venture into other modules.
Thus, for a collection of reasons multi-functional teams are more difficult to create than may
be the case on a Java project were developers have grown up with SQL, HTML, Python and
UNIX too.
In an effort to reduce wages many legacy shops have distributed their maintenance operations
both geographically and organizationally. SAP consultants can be in short supply, with the
result that they clock up lots of frequent flyer miles and regularly miss days or half days.
Finding a convenient slot for a stand-up meeting can be hard, and when they do happen they
may well be sitting-down with a telephone handset.
As if that weren't enough, the cost obsessed nature of many big organizations means the
question "What have you achieved?" is most honestly answered with "Clocked another eight
hours of billable time." Such cultures lead people to focus on inputs and costs, not output and
achievements.
Another characteristic of large legacy system is the degree to which the teams are cut off
from real customers. Mainframe system may well be hidden from end customers behind more
modern front-end systems intended to shield users from the green screen.
With layers of technology insulating the legacy system, the team too is hidden from the
business and the business hidden from the developers. It becomes very difficult to know
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 –
6367(Print), ISSN 0976 – 6375(Online) Volume 3, Issue 3, October-December (2012), © IAEME
474
where the value is, what the business wants and just what is the simplest thing that could
possibly work.
5.1.3 Limitations of Agile Software Development Agile was created in large part in reaction to the predominant – and now infamous waterfall
model, and to a lesser extent to all "traditional" methodologies. But did we question the
assumption that Agile was indeed superior to traditional methodologies? Although many
projects using traditional methodologies failed, many others were successful.
Agile methodologies are more successful than traditional methodologies such as IBM RUP,
CMMI, Prince2, or RAD? The truth is we don't.
Here the questions are; 1. When does Agile make sense compared to traditional
methodologies?
2.How can we combine Agile with traditional processes to better address a specific situation?
For answering these questions, we have to look at the limitations of Agile.
1. A team of experts: Agile has been designed by experienced, smart, and high-achieving
people. A friend wisely pointed out to me recently that they naturally designed agile for
people just like them: stars. Not everybody's a Martin Fowler, a Ron Jeffries, or a Jeff
Sutherland. You could have given them any project, with waterfall method or even no
method at all, and they would probably have succeeded. Indeed, not every group can be
motivated, experienced, and skilled enough to self-organize into an efficient team, come up
with lightweight processes, and collaborate seamlessly to achieve that great agile teamwork.
Take average individuals in the workplace and imagine what would be the outcome if we
trusted them to self-organize and to choose the best way (at micro-level) to reach the desired
result, without any close supervision. It might be quite disappointed that individuals are not
qualified, here some questions arise; does your team have the agile potential? Do you have
the agile potential? Do you have the raw individuals to form an agile team in your
organization?
If the answer is “no” to some of these questions, It means that there might be some
intermediate steps to take before getting there. These steps typically involve adapting the
work culture by progressively empowering teams and individuals, training, and hiring the
right people.
2. Fit with organizational culture: Enabling agile behavior requires a great dose of individual
and team freedom. It translates into cross-functional, constantly adapting work, and switching
roles as needed. It also entails adjusting processes continuously to reflect the current
situation. More than anything, it means that processes are secondary to people.
Companies that traditionally emphasize narrow responsibilities, policies, processes, and one-
size-fits-all methodologies, are particularly at odds with agility. These characteristics form
the organizational culture, which pervasively influences all work and behavior throughout the
organization. Unfortunately many companies still apply these industrial-era principles. To
make things worse, changing the culture might be the one most difficult thing to do for an
organization (after all, the culture is the people who are part of the organization).
Nonetheless, some rigid organizations can still benefit from agile. They succeed by "spinning
off" groups of people who are in theory working within the organization but who can work in
relative independence. This is also how large, rigid companies enable innovation. Indeed
innovation and agility are deeply intertwined. Successful organizations are ambidextrous.
What can be done if agile doesn't suit your organization culture? The easiest solution would
be to set up a team that can work independently from the rest, and is not subject to the same
rules. People in this team should be fresh hires or should not fit well within the traditional
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 –
6367(Print), ISSN 0976 – 6375(Online) Volume 3, Issue 3, October-December (2012), © IAEME
475
organizational culture. But on the long term, changing the culture implies changing
leadership, assuming that people can change only to some extent.
3. Small team: Agile teams are restricted in size for several reasons:
• The team has to self-organize, implying an efficient order emerging from temporary
chaos. Obviously this process would be too long for larger teams.
• Team members have to be able to communicate spontaneously with each other and
with other stakeholders (i.e. without setting up meetings, sending emails, etc.).
• All team members participate in the day-to-day management (tasks, changes,
impediments, etc.).
• Team members need to understand what others are doing (cross-functional
perspective, team ownership), help each other with ease, and collaborate without
centralized control.
• The team has to be co-located .
Agile is a highly participative style of software development. Therefore, the number of
participants significantly affects the efficiency of the process.
Assuming that large projects tend to require large teams, this restriction naturally extends to
project size. Fortunately, there are solutions to somewhat alleviate this limitation. If a large
project can be divided into a number of relatively independent smaller subprojects then each
part can be implemented by an agile team. However, this solution is not without its own
quirks:
• There has to be a "higher-level" project management to coordinate the teams. This
higher-level can be managed with a more "traditional" methodology. Note that we see
here a situation where combining agile and traditional methodologies makes sense.
• When dividing the project into agile-manageable subprojects, we minimize
dependencies through architecture. However, agile measures progress based on
working software, i.e. delivering features. Dividing a complex project based on
architecture yields a very different result than dividing it according to features.
4. Collocated team: Agile emphasizes that face-to-face, spontaneous conversation is the best
form of communication. While we can certainly agree on the benefits of this form of
communication, it severely limits agile applicability. Moreover, this agile principle extends
beyond the development team since other stakeholders such as business analysts are required
to be collocated.
We can easily think of a number of situations where this limitation prevents using agile:
• Office space organized by departments: In most organizations, offices are organized
by departments such as IT, marketing, accounting, sales, and so on. Moving people
around according to agile projects is unrealistic. Even if it was possible, it would
negatively affects other parts of the business.
• Distributed environment: Developers are often distributed throughout the
organization, whether in the same branch or in different branches (or working from
home). Just like for the previous point, moving these people is unrealistic.
• Subcontracting: Many organizations partly or completely outsource software
development. Assuming that some roles such as business analysts or key users would
be located at the company, this situation doesn't comply with the agile collocation
principle.
It is very clear that there is no substitute for face-to-face, spontaneous communication.
Consequently, the best solution is to restrict the agile team to people working at the same
location, knowing that even if it were possible it would constitute a less-than-ideal team.
Alternatively, we can try to make the better of it by managing a "virtual" agile team:
• Collocate as many team members and stakeholders as possible.
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 –
6367(Print), ISSN 0976 – 6375(Online) Volume 3, Issue 3, October-December (2012), © IAEME
476
• Set up an "open phone line / video chat / IM" policy to make sure that spontaneous
communication is still possible between distant stakeholders.
• Leverage collaborative software
• Schedule frequent in-person meetings with distant stakeholders.
• Start the project with everyone at the same location for a few days in order to build
team spirit.
5. Where's the methodology?: Software development methodologies include several
processes, such as analysis, architecture, implementation, project management, configuration
management, and so on. However, most agile methodologies, such as Scrum for example, do
not define processes. In particular, most agile methodologies do not define any project
management processes. Whether we're agile or not, we need to manage changes, risks,
budget, and so on. As lightweight processes doesn't mean no processes at all! And not
everything can be stuffed in short daily meetings without written records.
As a consequence, most agile software development processes are not methodologies, they
are no more (and no less) than sound principles and practices to manage the day- to-day
operations of small projects. This is great, but hardly enough to manage projects. Similarly,
the person managing agile teams is more a team leader than a project manager, the main
differences being that a team leader doesn't manage budget, scope, planning, and reporting
for example.
Unless we choose an agile methodology that encompasses all needed processes, we combine
it with a methodology that define these processes and rely on agile for day-to-day team
management. Moreover, keep in mind that you need to remain credible with upper
management and other stakeholders, are likely to judge the competence based on processes
such as scope, risk management, planning and reporting.
6. Team ownership vs. individual accountability: Agile development stresses the importance
of team ownership in order to improve teamwork and therefore overall results. Team
ownership is a very appealing concept, but how can we implement it since an organization's
performance-reward system assesses individual performance and rewards individuals, not
teams?
If we rely exclusively on individual accountability, we tend to generate selfish behavior that
can affect teamwork. If we rely exclusively on team assessment, we overlook that individuals
perform differently in a given team, creating opportunities for underperforming team
members to get away with it and lessening incentives to perform in a superior way.
Obviously we have to find a way to take both these perspectives into account.
Actually this problem can be solved elegantly by defining two levels of performance reward:
• Team level: The team is perceived as a single entity from management's point of
view. Management assesses teams' performance and allocates rewards to teams in the
form of points.
• Individual level: Team leaders evaluate team’s members rewarding them with points.
We can aggregate all the above as;
1. In case of some software deliverables, especially the large ones, it is difficult to
assess the effort required at the beginning of the software development life cycle.
2. There is lack of emphasis on necessary designing and documentation.
3. The project can easily get taken off track if the customer representative is not clear
what final outcome that they want.
4. Only senior programmers are capable of taking the kind of decisions required
during the development process. Hence it has no place for newbie programmers,
unless combined with experienced resources
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 –
6367(Print), ISSN 0976 – 6375(Online) Volume 3, Issue 3, October-December (2012), © IAEME
477
5.2 OPEN SOURCE METHODOLOGY
Open source development-which allows free access to software source code to allow anyone
to make improvements-is revolutionizing the way software is created, improved, and used.
The open source software movement is inherently transparent, participatory, and
collaborative. Open source provides the public direct and ongoing access to available
technology. Although open source release has already provided numerous benefits to
business organization and the public, the full benefits of open source can only be achieved
when we establish the processes, policies, and corporate culture to favor open source
development. This would shift our open source activities from its one-way direction of giving
the public access to finalized software products, to allowing two-way collaboration as part of
the development process. The benefits of allowing the public to assist in development of
large scale include increased software quality, accelerated software development, and a
higher rate of technology transfer both to and from organization(Ref.11).
The rapid growth of the Internet has changed how we use computers. For software developers
this has led to new forms of collaboration and code reuse. Perhaps the most exciting
development has been the growth of open source software. Open source involves the joint
production, release, and distribution of software that is freely and widely available. The
number of open source projects and amount of open source code is growing at an exponential
rate and in some cases, allows work created for one project to be applied to another.
Fig.4 (a): Open Source Project phases (b) activities and services
5.2.1 Limitations of Open Source Development Taking a comprehensive and critical view of open source should raise some questions as
well, regarding drawbacks. There have been several criticisms by detractors of open source,
but most of these can be mitigated or relegated to myth status. Here’s a short list of possible
concerns (each of which are discussed in subsequent sections):
Open source isn’t really free: "Free, as in a free puppy" is the adage meaning no up-front
costs, but plenty (often unseen or unanticipated) afterward. Implementation, administration,
and support costs—particularly with Novell solutions—can be minimized and the reality is
that there are still no licensing fees.
There’s no service and support: For some companies, support is mandatory. More on this
later, but open source support equal to that available for proprietary software is available for
the same price or less.
Development resources are scarce: Linux and open source resources are actually abundant—
the developers can use the same tools, languages, and code management processes. In reality,
the universe of developers is the largest of any segment. And, with the evolution of Mono
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 –
6367(Print), ISSN 0976 – 6375(Online) Volume 3, Issue 3, October-December (2012), © IAEME
478
(the open source equivalent to .NET), all of those Windows/.NET developers become an
added development resource for Linux.
Open source is not secure:It might seem to be a simple deduction of logic to think that the
code is available, so anyone can figure out how to break it. That’s not quite true with the
momentum of the community (especially Linux). Also, the modularity required for
distributed development of Linux and open source also contributes to security with tight,
function-specific, and isolated code segments.
Training is not available: This used to be true, but not anymore. Available Linux training, for
example, has ballooned with certification courses coming from every major training vendor.
Novell has created multiple levels of Linux certification and integrated training programs.
Check your local bookstore and you’ll see a whole section on Linux and open source.
All open sources are work-in-progress: True for some, but not for all. The key components
like Linux, Apache, MySQL, and Tomcat are dominating prime-time Internet with stable,
secure, and production-quality solutions. Some open source offerings are maturing, but they
are still workable, and for the companies that use them (with access to source code), the
software is good enough.
In abstract, Just as development is free and encouraged in open source, it is also not
compulsory. Closed source software companies pay salaries to people to develop the software
and therefore development is pretty much guaranteed.
Quite a large disadvantage to open source software is that as so many developments are going
on at the same time it is hard to keep track of which version is the most up to date. This is
also due to the fact that advertising is not as prominent in the open source industry, mainly
because most developers are non-profit making. This lack of advertising and frequency of
developments can sometimes cause confusion of which product is the most up to date.
There is an issue where the line between open and closed source blurs. Many open source
projects are developed from many different peoples codes and this can make it a struggle to
effectively sort out who's is who's. It also increases the risk that a bit of closed source code
might find itself in there and therefore render the project illegal. However, the open source
licensing is geared up to help the contributor.
Many businesses opt for a closed source alternative when it comes to their server. Some of
their issues are outlined at the Microsoft Compare website. This presentation however is from
a closed source software company and they may be slightly favorable to their product. They
claim that Microsoft offer increased reliability, security, choice, manageability and
interoperability.
5.3 SERVICE ORIENTED METHODOLOGY A collection of services with well-defined interfaces and a shared communications model is
called a service-oriented architecture (SOA). A system or application is designed and
implemented as a set of interactions among these services. SOAs allow legacy systems to
expose their functionality, sometimes without making significant changes to the legacy
systems.
Service-Oriented Architecture (SOA) is a style of information systems architecture that
enables the creation of applications that are built by combining loosely-coupled and
interoperable services. These services inter-operate based on a contract that is independent of
the underlying platform and programming language. However, constructing services from
existing systems to obtain the benefits of an SOA is neither easy nor automatic. In fact, such
a migration can represent a complex engineering task, particularly when the services are
expected to execute within a tightly constrained environment(Ref.07).
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 –
6367(Print), ISSN 0976 – 6375(Online) Volume 3, Issue 3, October-December (2012), © IAEME
479
Fig. 5 : Basic SOA Architecture
5.3.1 Service Oriented Architecture Limitations & Applicability Service Oriented Architecture may not always be the best architectural choice because
optimal utilization of SOA requires additional development and design attempts as well as
infrastructure which translate into costs escalation.
SOA reduces the complexity associated with integrating applications and processes by
standardizing the way IT assets are used with common components and processes. By
focusing on delivery of integrated business services rather than single unit performance, SOA
can provide real-time benefits to customers and stakeholders, but SOA is not without its
challenges. Here we outline some of the highlighted challenges adopting SOA in Large Scale
software Development.
• Misunderstanding SOA :SOA is not a magic bullet; nor is it a new idea. However, it
is a way to improve service to business users and speed delivery time to market. SOA
allows for more effective process change with less complexity than other approaches,
as shared services streamline business processes. Unfortunately, many companies are
not structured to easily adopt or implement SOA. The hype in the marketplace as to
what SOA can do - the magic bullet syndrome - is not providing enough guidance for
companies to capitalize on its prospects. SOA initiatives must follow a "think big,
start small" approach. To effectively accomplish this, an SOA governance model is a
must. SOA governance depends on integrated management to join business units and
IT together.
• Isolated Implementation of SOA :Too often, service teams build SOA isolated or
disconnected from the work that the approach is designed to impact. A centralized
team builds what they think developers should use, rather than design an approach
that is both appropriate and integrated. Many companies procure software packages
and embark on large SOA initiatives without defining their SOA strategy or
understanding what SOA will deliver. The cross-functional integration of business
processes is necessary to support a value-generating activity chain. To achieve greater
effectiveness, SOA implementation teams should consider executing a demonstration
approach: start small with a low risk/high value proposition, demonstrate positive
results from the solution and replicate on a larger scale.
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 –
6367(Print), ISSN 0976 – 6375(Online) Volume 3, Issue 3, October-December (2012), © IAEME
480
• No Culture of Reuse :For SOA to be successful, companies must foster a culture of
reuse, where developers and line managers use the same services toward a common
goal. In some situations, developers do not see the value of using SOA. If they are not
required to use available services, they will frequently want to build their own custom
applications or continue to use existing applications, rather than using another's
creation. Corporate culture must promote cross-functional communication to break
down barriers and demonstrate the importance of SOA. Without collaboration and
interaction, companies will have a difficult time realizing the full potential and
reaping the benefits of SOA.
• Lack of Strategic Alignment: Many IT initiatives have not been fully linked to a
company's strategic goals and objectives. IT services often focus on a specific
application to solve finite problems or satisfy the needs of a particular business unit.
The nature of the SOA approach dictates horizontal integration of business processes
across business unit boundaries. To support an organization's critical success factors,
SOA must align people, process and technology.
• Inability to Anticipate and Capitalize on Change: It is no longer enough for
business and IT to respond to change; instead, they must move in lockstep to
anticipate and capitalize on change. Companies are now focusing their service
strategies on a business approach tied to the customer. Understanding customers -
who they are, what they want and how to sell to them - is vitally important if
companies want to effectively capitalize on changes in the global marketplace.
Companies must closely monitor customer preferences and profiles and quickly
incorporate solutions to satisfy change throughout the company.
• Traditional Business Structure is Not Conducive to SOA: Consider how your
company is structured when formulating a strategy to implement SOA. In a traditional
functional organization, the design of the reporting relationships and ownership of
business activities and outputs are based upon functional expertise, such as
manufacturing, marketing, customer service and order management. Individual
organizational functions support each of the vertical business units of the company.
However, if SOA is to be effective, a company requires a value-chain process based
on contributing activities that level silos and deliver services horizontally as well as
vertically.
• Organizational Barriers: For SOA to be successful, you must coordinate and align
business functions with IT. Companies may be hindered by an inability or reluctance
to integrate systems across departmental or functional lines. They may also discover
duplication in delivery of services or conflict in policies and procedures. Other
internal barriers may stem from lack of understanding about how SOA provides
benefit or applies to discrete departmental functions, as well as to overall company
goals. Multilateral buy-in is necessary to overcome these organizational barriers and
to break down silos.
• Resistance to Standardization: Defining technology standards, usage guidelines and
overall principles of adoption is a complex task for companies. However, a robust
SOA must be scalable, manageable and reusable. To successfully implement and
govern SOA, a governance model must be put in place to manage and control the
lifecycle of a service from its inception to its expiration. The model also needs to
protect shared services development through ownership of information and
guidelines. The development community is often reluctant and resistant to this
standardization for fear of losing control or oversight in design and delivery of custom
technology.
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 –
6367(Print), ISSN 0976 – 6375(Online) Volume 3, Issue 3, October-December (2012), © IAEME
481
• Lack of Integrated Technology: SOA is all about using open standard technology
and requires technical interfaces that can be applied consistently and compatibly
across business processes. By providing the guiding principles and introducing new
competency standards, SOA helps companies proactively address the technology and
vendor products that exist within the company at a granular level. This standards-
based compatibility also protects shared services development and prevents or
minimizes proprietary product ownership by vendors, eliminating vendor lock-in.
In addition to the above challenges, when it comes to applications, Web Services and Service
Oriented Architecture is not recommending for the following:
• Stand alone, non distributed applications that do not necessitate application or
component integration; that would include, for instance, a word processing
application that does not require request and response based calls. .
• Short lived applications or applications that are in any way limited in scope. This
would include, for instance, an application that has been built as an interim
solution that is not intended to provide full functionality or reuse for future
applications.
• Applications in which one way asynchronous communication is necessary, and
where loose coupling is considered undesirable and unnecessary.
• Homogenous application environments, like, for instance, an environment
wherein all applications were built utilizing J2EE components. In these instances,
it is not a good idea to introduce XML over HTTP for inter-component
communications rather than utilizing Java remote method invocation.
• Applications that need GUI based functionality. Like, for instance, a map
manipulation application that has lots of geographical data manipulation. Such an
application is not suited for heavy data exchange that is service based.
Of course, vast majority of these scenarios do not even apply to enterprise
applications. Service Oriented Architecture is a network centric approach that requires
complex service auditing and monitoring. Owing to the fact that service reuse and
sharing tend to be the main features of Service Oriented Architecture, the quantity of
service consumers will be rather high. This gives raise to issues, as well as versioning
and change management problems.
VI. PROPOSED INTEGRATED FRAMEWORK FOR INTEROPERABLE AND
SERVICE ORIENTED MANAGEMENT OF LSS
Analyzing and comparing the existing frameworks for the management of Large Scale
software Projects and the challenges , we propose an integrated framework using knowledge
scouts and the policies of people, process and technology management on SOA that will address
the challenges in managing LSS project. Here out attempt is to represent a homogeneous,
interoperable and service oriented Architecture which will support large scale software
development, operation and its management universally. In this respect some of the tools,
technologies along with the predefined methods have been used precisely(Ref.12).
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 –
6367(Print), ISSN 0976 – 6375(Online) Volume 3, Issue 3, October-December (2012), © IAEME
482
Fig.6: Proposed Integrated Framework for Interoperable and Service
Oriented Management of Large Scale Software
MANAGE SECURE
ACCESS
SERVICE DIRECTORY
People management solution
Cultural
difference and
poor knowledge
RM
tools
Project
Management
tools
Process Oriented Solution
Multiple
Parties/
Stakehold
ers
Coordina
tion
Brake
down
Lack of
teamness
and trust
D
DSD
Proces
s
Mngt.
tools
Mod
eling
tools
Metr
ic
tools
Req.
Mngt.
tools
Prog
.
tools
Test
mngt.
tools
Technological solution
Time
difference
and distance
Communicat
ion
SERVICE CONSUMER SERVICE PROVIDER
L
O
C
A
T
E
P
U
B
L
I
S
H
S A S
International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 –
6367(Print), ISSN 0976 – 6375(Online) Volume 3, Issue 3, October-December (2012), © IAEME
483
VII. CONCLUSION
It can be conclude that the proposed solution model will be reliable one to manage the
large scale software development and its management where location, platform,
environment and application process are variant. Here it is clamed that this proposed
model must be beneficial as compare to the pre used methodologies such as agile,
open source and service oriented architecture (SOA). One of the major short coming
in the technical background of the proposed frame work would be, it is knowledge
management based and hopefully it will be service oriented and interoperable when it
can be deployed over real life. It can be voted that this frame work must reduced, the
integration and communication barriers as compare to service oriented architecture.
REFERENCES
[1] K. B. et. al, “Agile Manifesto,” [Online]. Available: http://agilemanifesto.org/.
[2] W. W. Royce, “Mananging the Development of Large Software Systems,” Proceedings
IEEE WESCON, pp. 1-9, 1970.
[3] M. Levison, “Agile Failures,” [Online]. Available:
http://scrumcommunity.pbworks.com/w/page/10148885/Agile%20Failures.
[4] S. Lambla, “Agile and Scrum Failure Stories,” [Online]. Available:
http://serialseb.blogspot.com/2009/02/agile-and-scrum-failure-stories.html.
[5] R. Revis, “All About Agile| Agile Project Management: Avoiding The Waterfall,”
[Online]. Available: http://www.allaboutagile.com/agile-project-management-avoiding-the-
waterfall-by-richard-revis/.
[6] A. Johnston, “Agile Architecture,” [Online]. Available:
http://www.agilearchitect.org/agile/index.asp.
[7] J. Highsmith, Agile Project Management, Addison-Wesley Professional, 2004.
[8] A. Rueping, Agile Documentation: A Pattern Guide to Producing Lightweight Documents
[9] S. Larsen, “Evaluation of Software Modeling Tools for Agile and Industrial Process,”
Dept. Computer and Information Science, Norwegian Univ. Science and Technology, 2006;
www.idi.ntnu.no/grupper/su/fordypningsprosjekt-2006/larsen-fordyp06.pdf.
[10] J. Portillo Rodríguez, C. Ebert, and A. Vizcaíno, “Tools and Technologies for
Distributed Teams,” IEEE Software, vol. 27, no. 4, 2010, pp. 10–14.
[11] C. Ebert, Global Software Engineering: Distributed Development, Outsourcing, and
Supplier Management, Wiley/IEEE CS Press, to be published in 2011.
[12] “Software & Systems Process Engineering Meta-Model Specification (SPEM), Version
2.0,” Object Management Group, 2008; www.omg.org/spec/SPEM/2.0/PDF.
[13] “Business Process Model and Notation (BPMN), Version 2.0, Beta 2,” Object Man-
agement Group, 2010; www.omg.org/cgi-bin/doc?dtc/10-06-04.pdf.
[14] V. Nikulsins and O. Nikiforova, “Tool Integration to Support SPEM Transformations in
Eclipse,” Scientific J. Riga Tech. Univ., vol. 45, 2010, pp. 60–67;
https://ortus.rtu.lv/science/en/publications/8640/fulltext.