Wednesday, 18 May 2011

How can shared applications be maintained and updated? Who are the owners of shared information?

INFORMATION SHARING

Data, information and knowledge are usually inter-woven by people trying to achieve a balance into their definitions. It is however important to distinguish between knowledge and information [1], by stating what gets transmitted electronically to be either data or information. For information to be transformed to knowledge, it must be acquired by someone who can give it meaning and context, and used within the specific time span of its relevance and currency [2].
Data is raw, which has no meaning beyond itself. It can be in any form which could be used or not, and it is in a discrete form. Information on the other hand is a processed form of data that has meaning behind it. It answers the W’s question of what, where, who and when. It could also be seen as a form of related data which gives an actual meaning that can be used on linked elements. Knowledge in the literal way is what we know and answers the question “how”. It is the collection of information for a useful means. It is a process with an example of it being the act of memorizing information.
Information sharing is the passing or exchange of information between two or more parties. According to Drucker, Information sharing is a very important element of total quality management and new organisation. Improved information sharing is very beneficial to organisations, by improving their efficiency, productivity, innovation, learning and understanding their goals and targets. This gives rise to the question of whether or not employees would share information across their organisation.
Information technology has empowered organisation by allowing easy means of sharing and collaboration. It has removed the boundaries through the provision of systems such as databases, blogs, social networking sites, information systems, knowledge managements systems, and so on. An example of a social network site is Facebook, which allows information sharing, communication such as chatting, sending of messages, uploading pictures and in general allows for interconnectivity with people all around the globe. These collaborative systems provide the promise of much increased information sharing within and across organizations and also encourage sharing of ideas in a free-owing method as well as in a form of structured repositories. These systems aid the exchange of both knowledge and information [4].
According to Bentley et al.'s, “Despite several years of research in the field of CSCW
(Computer Supported Cooperative Work), email and ftp remain the state-of-the-art in supporting collaboration within widely-distributed work-groups. Although such tools facilitate information exchange, but they provide little support for information sharing, whereby details of users’ changes, annotations and so on are made visible and available to all other participants”.

To Lauwers and Lantz, the ideal approach towards building systems that support real-time sharing of work would have to recognize each participant’s existence and his or her role in the collaboration.  Such system is called “Collaboration Aware”. Leland et al gave an example where, “A groupware applied to document collaboration could: Recognize the roles of the primary writers, reviewers, and readers; adjust access permissions to reflect these roles; keep track of version differences; and enhance communications between the various collaborators”. These bring about the essentiality in maintaining or updating a shared application.

A number of design decisions must be considered when building or maintaining a comprehensive sharing system. The responsibilities of the system fall into four major roles [11]:

A.      The View Manager: The distributed view of the running application should follow (more or less) the “what you see is what I see” (WYSIWIS) abstraction, in which everyone sees the same image on their screen or window. The View Manager is responsible for synchronizing and transmitting these views, such that participants merely have to tap into the application’s output stream and send a copy of that stream to each of the other terminals. Assuming  that all  connected participants  are running  compatible  terminal  types with  the same initial  terminal  and screen configuration,  each screen would  then show the same image (Figure  1). For instance, accessing a “facebook” application on the phone (i.e. a terminal) is different from accessing from the computer (another terminal).

B.      The Chair Manager: All participants should be able to interact with the application in a reasonable manner. Since the application  is built  to handle only  one input stream, a floor-control  mechanism that gives control  to only  one person at a time is usually  desirable, thereby setting a queue of information or data that comes in. Imagine a set of participants trying to type at the same time in a chat-room; the queue of entry needs to be in place to control the flow of simultaneous insertion. The Chair Manager is however responsible for setting or changing the floor control policy, also for coordinating and enforcing turn-taking between participants and sending the selected input stream to the application.
                Figure 1: A simple view-sharing system for homogenous computing environment [11].

C.      The Registrar: Conference “registration” by the Registrar addresses four issues: conference set up and tears down; entry and departure of participants while the conference is in progress; access control; and feedback of the conference’s current status. An instance of this is when a set of people are involved in discussions in a forum; the registrar must be able to keep track of when people join and leave the discussions, and also synchronise old discussions with new entrants. The registrar also must be able to handle roles and permissions on the shared application.

D.      The Meta Manager:  Participants should be allowed to talk “around” the application through gestures and annotations without actually affecting the application. People will often talk around a shared view without interacting directly with the displayed application. Some of these “meta”  actions involve:

·         Directing the group’s attention  to some aspect of the view (referring,  retracing, emphasising);
·         Allowing  more than one person to gesture around the view at the same time (pointing);
·         Providing  feedback on the attentiveness of other participants;
·         Augmenting verbal dialogue; and
·         Leaving marks on top of the view that are transparent to the application.
The Meta Manager is responsible for separating and controlling these meta-interactions and handling these meta- level interactions between participants.

Suggestions have been made in recent years concerning communication participants being enabled to maintain and update shared application. With the amount of high technicalities involved in updating and maintaining shared applications; for instance on facebook, such suggestions do not only bring about the complexity in the shared application, but it also increases and creates more ambiguity into the understanding of technical terms. This does not also exclude the fact that the developers of the application would want to withhold such rights to them as it poses a great threat of losing their jobs. Though participants are major stakeholders in the development of shared applications, their involvement should be limited to influencing factors which determine and affect the updating and maintenance of shared artefact in order to enable sharing either in a social or organisational context. Among others, these factors include:
·         Look at what people do together, not just their tasks but also their various activities and what they are trying to achieve.
·         Consider how people communicate with one another (i.e. formal or informal), not just the communication channel.
·         Evaluate the usability of the existing application, and see the fit between the user and the system.
·         Make sure the system is easy to find and easy to use.
·         Recognise the participants or users feedback.
·         Also recognise that the shared application is not a project but a process that would keep updating with external factors put into consideration.

While the theory of information sharing builds on the interdependence notions of social exchange theory, the original social exchange theory did not consider information exchange [5]. People in organizations treat information sharing like other means of communication or substitution which is greatly influenced by their social and organizational factors [6]. “The context is important because it differentiates information sharing from those simple exchanges where individuals act simply from rational self-interest (“I help you if you help me“). The interdependence notion in social exchange theory implies that organizational context causes people to rise above their self-interest rational impulses to consider the long-term impacts of their actions. That is, the social and organizational context regulates information exchange via concerns people have for maintaining future relationships, the balance of power, image, and so on. The stronger the influence of the social and organizational context, the less likely people's behaviour is driven strictly by task or personal determinants of information sharing and more by social and organizational determinants” [4]. This also denotes the fact that people are more likely to share information when they feel obligated to engage in pro-social transformations, i.e., when they wish for good outcomes not only for themselves, but also for those working with them or the organisation in which they work. It shows that people are more willing to share information when they are happier with the people or organisation they work or within the context of information sharing, not neglecting the fact that voluntary help or out-of-role help is positively linked with organisational commitment and closeness to colleagues [7]. It is important to recognise that sharing of information requires trust, which is informal friendship or relationship and also realises the benefits that can be derived from it.

Collaborative Information is Dual Ownership

These are mutually owned information, which allows both parties the right to make use of the information.  Considering facebook, the stream of information posted with photos and videos uploads, it is argued by some that they own the information and articles they upload on Facebook and therefore have the right to control the use of it. This is however untrue as Facebook also owns the information and control on their sites. We do not own the URL, Facebook does. In every instance where two or more parties interact or collaborate, both parties are co-creating that information, making both parties owners of the information. This is however easy to fault when we claim control ownership because Facebook which is the service provider has solid claims to the information stored in their database, just as we also do own the information we input or upload. The information we create on various sites we visit is co-created and co-owned by both us the visitor and the website owner.  Every form of collaboration on the internet or web creates at least two owners on the information or data. This is supported legally by the courts, which gives the right to email providers to read the email of users as long as the email is stored on the provider’s server for a period of time.

Yours, Mine and Ours

When individuals collaborate to one course to produce a result, each brings along his own data which is exchanged. Taking the instance of buying a phone from e-bay (an e-commerce website for buy and selling various items), we can state that this involves three different layers of data:
·         My data;
·         Your data;
·         Our data.
“My data” is the data that is unquestionably only within the province of an individual. Data that I have and it is directly related to me only. It is usually related to privacy of personal data. It is the data individual inputs on e-bay to search for a phone. This data include, brand, model, budget range and year.
 “Your data” is the data owned by another person or organisation. It is the data that e-bay has knowledge of, which includes the cost of the phones, available number in the inventory, the available sellers.
 “Our Data” is the data jointly available to both parties involved. It could be shared information that is as a result of the transaction to be performed. It is uniquely identified to both parties for a particular transaction.
It is usually easy to identify which data belongs to both parties, but when identifying “our data”, this brings about a major challenge. It could also become complex and complicated when we start associating every aspect of “my data” to “your data”. This occurs more when the other party is an individual and I bring “my data”, you bring “your data” and together we create “our” data. Both parties tend to mix up the data as theirs while the other party sees it as both of them. This therefore requires a broad approach that covers all aspects of data which belongs to me, you, ours and everybody. Regardless of this, the need to control the use of this data and protect the interest of the owners of the information from being copied over the internet is essential.

Conclusion

According to Constant et al theory which complements that there are “more economic perspectives to information sharing that deal with the logic of economic self-interest. Social exchanges of information and knowledge are similar to economic exchanges in the sense that there is an expectation of some future return for sharing, but unlike economic exchanges, there is no understanding of the value of what has been shared and no clear expectation of exact future return”.
However, it is essential to move from the context of information ownership to authority, responsibilities and rights over such information rather than building a framework for ownership of information shared. Though this brings about the issue of information protection but it also helps to address the issue of sole ownership. For instance, a university learning management system (by which lecture materials are uploaded, communication between students and lecturers are allowed) gives the institution an exploitation right over every material produced by the lecturers in the course of their employment, not also neglecting the fact that the institution owns the platform by which the lecturers upload their lecture notes. This gives the university joint ownership and rights to the information and recognises the author to be the lecturer. The university also possesses the responsibility of making these notes available to the students who enrolled in the course, with the lecturer, though the author having no right to make this available to students outside the institution. This helps to create a control that is of value to everyone, which aids participation from all parties. Also looking at the information by service providers of various networks, there are a lot of complexities as regard the privacy of Information Sharing. This remains a critical aspect to look at but it would require lots of investment in legal, moral, political above others to resolve. Sharing our personal information can be effective and begin once workable guidelines and rules are stated which help to control the sharing of information. It would help increase the ease of individuals revealing and sharing information and help control the abuse of information. Individuals want to share information but at their own terms to protect their interest.

Tuesday, 5 April 2011

Tuesday, 22 March 2011

There must be higher love

I have loved and I've been love, but what is Love, if it can't stand the test of time.


Do we still have true love? Do the memories of your loved ones ever leave your heart?
How can we stop this feeling? They say:

To melt and be like a running brook 
That sings its melody to the night. 
To know the pain of too much tenderness. 
To be wounded by your own understanding of love; 
And to bleed willingly and joyfully. 
To wake at dawn with a winged heart 
And give thanks for another day of loving; 
To rest at the noon hour and meditate love's ecstasy; 
To return home at eventide with gratitude; 
And then to sleep with a prayer 
For the beloved in your heart 
And a song of praise upon your lips. 

We say it, but hardly feel it. We think it, but its with fear we show it.
Sometimes we let affection go unspoken, 
Sometimes we let our love go unexpressed, 
Sometimes we can't find words to tell our feelings, 
Especially towards those we love the best. 

If given another chance, would you still love? What changes would you make? 
What places would you go? What words would you say and what feeling would you express?

It knows no reasons, It knows no lies. 
It defies all reasons, IT has no eyes. 
But love is not blind, love sees but doesn't just mind. 


Love is sometimes denied, sometimes lost, 
sometimes unrecognized, but in the end, 
always found with no regrets, forever valued and kept treasured. 

Love means to commit oneself without guarantee, to give oneself completely in the hope that our love will produce love in the loved person. Love is an act of faith, and whoever is of little faith is also of little love. 

Agile Development

INTRODUCTION
Software Development has become a very significant aspect in most business area, and in-turn requires high skilled project management to help effectively and efficiently organise the development process. Software Development methodologies are constantly developing due to frequent advancements in technologies and also software requirements from users. Software Development process can be achieved using different models, but the most eminent one used for small or medium software development is Agile Development because of its flexible and ability to adjust to changes in user requirements at any point in the development process.

Agile Development process focuses on providing high customer satisfaction by ensuring quick delivery of quality software, active participation of concerned stakeholders, and creating a platform that allows change at any point in the process. As against other Traditional Development process, Agile Development process is people-oriented and is a very adaptive process that allows continuous design improvements, which helps to appreciate the values and determine the quality approach of the system to be developed.
To what extent is the impact of Agile Development to Software Development and its implication to Service Oriented Architecture?

AIMS AND OBJECTIVES
The aim of this essay is to present the problems faced in Traditional Development and see how Agile Development has addressed these problems, also stating the relevance of Agile Development to Software Development in general and to Service Oriented Architecture. In trying to fulfil these aims and showing the application of Agile Development in modern organisations, this essay breaks the problem into specific objectives. These specific objectives are given below:
·         Give an overview definition of Agile Development, its brief history and architecture;
·         Extreme Programming (XP) as a method of Agile Development Framework;
·         Outline a detailed comparison between Traditional and Agile Development methodologies;
·         Outline the advantages and disadvantages of Agile Development process;
·         Identify the implication of Agile Development to Service Oriented Service;


WHAT IS AGILE SOFTWARE DEVELOPMENT?
Agile Development is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. Agile Development methods are people-oriented, which recognise the value competent people and the relationships they bring to software development, and also a very adaptive method which create influence for change in user requirements and continuous improvements in designs. They also foster quick delivery of quality software and allow concerned stakeholders to be involved in the development process; thereby focusing on providing high customer satisfaction.

BRIEF HISTORY
Agile Software Development emerged in mid‐1990s to solve the weaknesses of Traditional Development methods such as the Waterfall Process Model, which follow a sequential process of development and do not allow flexibility and ability to embrace change. Agile Development is called a “light weight” software development process [1]. The methods were not widely practised or accepted until February 2001, when a group of advocators met at Snowbird, Utah and agreed to the name "Agile Methodologies" and created the Agile Manifesto and the principle [1].

The manifesto states that [2]:

  1. Individuals and interactions over process and tools;
  2. Working software over comprehensive documentation;
  3. Customer collaboration over contract negotiation;
  4. Responding to change over following a plan.

Twelve supporting statements give guidance on achieving the fore core values of Agile Development. They are [2]:

    1. Our highest priority is to satisfy the customer through early and frequent delivery of software;
    2. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale;
    3. Working software is the primary measure of progress;
    4. Welcome changing requirements, even late in development ;
    5. Business people and developers must work together daily throughout the project;
    6. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done;
    7. The most efficient and effective method of conveying information to and within a development team is face‐to‐face conversation;
    8. The best architectures, requirements, and designs emerge from self‐organizing teams;
    9. Continuous attention to technical excellence and good design enhance agility;
    10. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely;
    11. Simplicity‐‐the art of maximizing the amount of work not done‐‐is essential;
    12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

After the Manifesto for Agile Software Development was established, a team of people came together to see how project management and Agile Mindset products can be achieved through management principles. They came up with what is called the “Declaration of Inter-dependence” for modern product and project management through which they outlined six rules of operations  which include: Value; Individuals; Teams; Uncertainty; Situations (or Context); and Customers [3]. They came up with a hex ring logo as shown in Figure 1 and explained each role stating [3]:


Figure 1. Declaration of Inter-dependence [3]
  • “Increase return on investment by -- making continuous flow of value our focus;
  • Deliver reliable results by -- engaging customers in frequent interactions and shared ownership;
  • Expect uncertainty and manage for it through -- iterations, anticipation and adaptation;
  • Unleash creativity and innovation by -- recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference;
  • Boost performance through -- group accountability for results and shared responsibility for team effectiveness;
  • Improve effectiveness and reliability through -- situationally specific strategies, processes and practices.”

 AGILE ARCHITECTURE
To begin a project using Agile Model Driven Development, you will need to get the initial “requirements envisioning” and also the “architecture envisioning”, which helps to determine the feasibility of the project. This helps to know the scope, cost, risks and required skills and technology to take on the project, thereby managing the project effectively and giving it a good direction.
Details of the project are identified at the start of each iteration on a just-in-time (JIT) basis during iterations using the initial “iteration modelling” or using the modelling storming” with is done throughout the iteration.  This need to be clearly stated as it helps the project in form of speed due to the fact that there is a clear understanding and knowledge by the development team at the beginning and also while the iteration continues. This reduces the risks that could affect the project by supporting the practice of modelling in small increments.
Figure 2 shows the lifecycle of Agile Model Driven Development for Software projects


Figure 2: Agile Model Driven Development lifecycle for software projects [4]




 METHODS OF AGILE DEVELOPMENT FRAMEWORK

Agile methodologies include Scrum, Crystal Clear, Extreme Programming, Adaptive Software Development, Feature Driven Development, and Dynamic Systems Development Method (DSDM) [5]. These methods existed earlier before been referred to as Agile Methodologies after the Agile Manifesto in 2001. Extreme programming is the best known and most widely used of these methods.

Extreme Programming (XP)

It is an Incremental development that supports small, frequent system releases. It recognises people and not process through pair programming, collective ownership and avoids long working hours. It also puts into consideration, the fact that customer requirement changes continuously, therefore it embraces these changes. Extreme programming is based on four clearly articulated values [2]:
  • Communication;
  • Simplicity;
  • Feedback;
  • Courage.
Communication between development team, the customer and members of a team is a very essential aspect in any project. XP has therefore embraced this by exploiting it both as a principle and in practice. It also realizes that achieving simplicity is not easy as software with a simple structure is always better than that of a complex one.
Feedback is about obtaining frequently reliable information about the state of the software as it is being developed, so that any problem can be accommodated and requests customers ask for can be well understood with the implications being reverted.
The concept of courage is also embraced, such that developer must have courage to throw away code or even re-design the architecture if the need arises.

XP and Refactoring

In software engineering, it is best to design for change, thereby spending time and effort to anticipate possible changes. This helps to reduce costs in development process. As a result, XP maintains that changes cannot be anticipated, but rather, it proposes constant code improvement (refactoring) which allows for changes to be made easily when implemented. Programming team always seek for possible software improvements, even where there is no immediate need for them. This however improves the ability to understand the software and reduction in the need for documentation. Changes that require architecture refactoring could very expensive to bear, but it is easier to make changes in code that is well-structured and clear.


XP Testing and its Difficulties
Testing is important to XP as every other method, but it has developed an approach where the program is tested after every change has been made. XP testing features include [5]:
  •  Test-first development.
  •  Incremental test development from scenarios.
  •  User involvement in test development and validation.
  •  Automated test are used to run all component tests each time there is a new release.

Customer involvement in the development team also helps in the testing process by developing acceptance tests for the requirements to be implemented in the next release of the system. However, this could be a challenge in cases where some customers cannot work full time with the development team.

Programmers take short cuts when writing test code especially when writing incremental test in complex applications, this as a result hinders a complete and accurate testing process in development as these programmers prefer programming. It is always difficult to know the absolute state of a set of tests, as there could be lot of system test to be carried out; thereby leading to incomplete coverage of the test.


TRADITIONAL vs. AGILE SOFTWARE DEVELOPMENT

Examples of Traditional Software Development are waterfall model, the spiral model, and some others close to these. These models break the process into phases thereby specifying the tasks to be performed and the desired outcomes, and also assign roles to individuals who will perform these tasks. This approach lays a high demand on documentation of every part of the code which makes the knowledge transferrable to whoever is of interest or has access to the code after it has been developed. Communication is always through documents between project members. Customers participate minimally in the process but they are given important roles during specification development. These approaches are appropriate both for Object-Oriented and non Object-Oriented technologies [6].

Agile Development on the other hand is an iterative, incremental, and collaborative approach for software development projects, which revolves around its flexibility for requirement changes in planning, requirements, analysis and design, implementation, deployment, testing, and evaluation before a final closure to the project [1]. Agile Development requires projects to be divided into sub-project, with each sub-project involved in planning, development, integration, testing, and delivery and the developers in the team having to work closely with the customers who play active roles in the teams (representing the system users) [6].

Table 1 shows a detailed comparison between the Traditional and Agile Development methodology.


Table 1. Traditional Vs Agile Software Development [6]



ADVANTAGES AND DISADVANTAGES OF AGILE DEVELOPMENT

Advantages of Agile Development
  • It is flexible.
  • Adaptable to user requirement changes.
  • It supports fast delivery of projects.
  • Documentation is minimal and saves time.
  • Face to face communication and continuous inputs from customer help projects to meet business needs. User is carried along in the project.
  • The end result is high quality software in the least possible time which meets customer’s satisfaction.

Disadvantages of Agile Development
  • Lack of emphasis on important documentation and designs.
  • It is difficult to determine all that would be required to carry out a large project at the beginning.


IMPLICATION TO SERVICE ORIENTED ARCHITECTURE

According to Krogdah, Luef, and Steindl (2005), service model is one central aspect in a Service Oriented Architecture that drives agile development. It consists of the model of services, their dependencies, choreography, and flows. Service model and the definition of the service interfaces keep changing over time. The current version of service model being used by most companies would be recognised to have weaknesses, because responsibilities of the services are not well-defined. This would therefore require a change in service interfaces and cause a shift in responsibilities from one service (or one version of a service) to another.

As Agile Development embraces continuous refactoring, the service model would also have to adapt to this process in other to meet the changing needs and address its existing weaknesses. These changes would be easy if the services are well-structured and clear.


IMPLICATION TO BUSINESS TO BUSINESS

Businesses today have strongly adopted the methodology behind Agile Development. The ability for the organisations to see the speed at which projects are developed and being engaged on a day to day basis, with a detailed knowledge of the cost implication and other factors that could affect the project while allowing changes in the requirements, even in short timelines. It has helped to reduce project risks through continuous communication between the development team and the business people, and has highly motivated the business to see functional prototypes while development is in place and changes are invoked, which places high confidence on the success of the projects.

The objective of every organisation is to see that every project succeeds at the fastest rate as possible. This is what Agile Development delivers and therefore helps organisations know they are on the right path to succeed.


 SUMMARY

According to Chen (2009), delivery of working software is the most important factor to lead to a successful software development. In the Agile Development’s view, metrics such as cost variance, schedule variance, requirements variance and task variance is virtually meaningless. Agile Development is becoming a trend adopted by most software development companies due to high success rates of projects.

Agile Development brings software projects a great success because of daily meeting for frequent feedback and delivery, which helps defects to be detected early and thus saves cost whereas, in Traditional Development, defects are usually found late since they rely on a predictive plan.

Service-Oriented Architecture has a challenge of the architecture adapting to the changes that can occur in the future. Agility has therefore helped to manage the possible changes in the business process through refactoring.




REFERENCES


  1. Yi-Len Chen. 2009. "Analysis of the Agile Deployment: A thesis work based on the literature study and empirical experience." [Online], Available at: http://74.125.155.132/scholar?q=cache:I-sGXz5p1oIJ:scholar.google.com/+Analysis+of+the+Agile+Deployment+A+thesis+work+based+on+the+literature+study+and+empirical+experience.&hl=en&as_sdt=2000 [Accessed 9 October 2010]

  1. Douglas Bell. 2005. "Software Engineering for Students: A Programming approach", 4th ed. S.L.: Pearson Education Limited.

  1. Alistair Cockburn. 1970-2010. “The declaration of interdependence for modern management or DOI”  [Online], Available at: http://alistair.cockburn.us/The+declaration+of+interdependence+for+modern+management+or+DOI [Accessed 12 October 2010]

  1. Scott W. Amber. 2010. “Agile Architecture: Strategies for Scaling Agile Development” [Online], Available at: http://www.agilemodeling.com/essays/agileArchitecture.htm#Lifecycle [Accessed 23 November 2010]

  1. Sommerville, Ian. 2004. “Software Engineering”, 7th ed. Harlow: Pearson/Addison Wesley.

  1. Sridhar Nerur, RadhaKanta Mahapatra, George Mangalaraj. 2005. "Challenges of migrating to agile methodologies" [Online], Available at: http://delivery.acm.org/10.1145/1070000/1060712/p72-nerur.html?key1=1060712&key2=1733086821&coll=GUIDE&dl=GUIDE&CFID=105283553&CFTOKEN=55000374 [Accessed 9 October 2010]

  1. Pål Krogdah, Gottfried Luef, Christoph Steindl. 2005. “Service-oriented agility: Methods for successful Service-Oriented Architecture (SOA) development, Part 1: Basics of SOA and agile methods” [Online], Available at: http://www.ibm.com/developerworks/webservices/library/ws-agile1/ [Accessed 11 October 2010]