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



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.



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



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



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.



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



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



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.



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.



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).



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.



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



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



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.



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



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



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.



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



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



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).



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.



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.



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).



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



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.