Free «System Requirements: Booking System for a Travel Agency» Essay

Introduction

Applying agile methodologies and practices within companies involved in software development, is now a reality that has been increasing in recent years around the world. Many people and companies involved in software development today are faced with the dilemma of being or not being agile. Either because their current development methodologies do not yield the expected results or because they wish to enter practices that are fashionable throughout development of communities around the world, the truth is that the rise of agile methodologies is a topic that excites and makes anyone think that is embedded within the software development process. This paper presents a practical approach to the choice and suitability of Agile software development to a real project: The development of a booking system for a travel agency using J2EE technology.

Project Justification

The sector of Travel Agents has experienced a crisis since the advent of the Internet. According to the International Tourism Forum, the online travel purchases have grown significantly to the point of bringing the crisis to traditional travel agencies. The trend comes as consolidated although this does not necessarily mean the disappearance of these agencies but a change in its original conception so that they can adapt to new times. The airlines and hotels reservation centers were among the first entities to use large networked systems to manage the reservation and sale of their products. These systems mainframe computers connected to the terminals of Travel Agencies. They in turn sold the product to the public after the end taking a commission on the management.

The incorporation of the network agencies has meant massive liberalization of the sector, and any competition in supply is beneficial for the customer since competitiveness leads to lower prices and improved product. With the emergence of Internet carriers and hotels reservation centers have expanded their networks of computers that previously only served to travel agencies. In many cases today's cheaper to buy a ticket online, in an Agency. And airlines increasingly cut their commissions to agents.

Travel companies (rail, air, car rental, etc.), hotels, guides and many other services that previously relied on an agency or tour operator can now bid on the network directly, without intermediaries and without monopolies limiting its business, so as to put in the hands of a good management to provide the best customer choice and marketing. Internet is where you buy, sell and hire the vast majority of travel, can make any connection with four clicks. Travel agencies are in crisis because they need reinventing, and cannot be intermediates in the ticket vendor. They need to compete in this new market of Internet sales.

The differentiated product offering travel agents is the package tour, that to be an alternative to individual product offerings of transport and accommodation should have an online booking system that exceeds that of airlines and central hotel, a reservation system that offers the public the products they produce agencies. The booking system will elaborate on this project will have a competitive advantage over large systems of traditional wholesalers. Our technology is based on Java and J2EE power and use agile methodologies supported by automated tests that can be more dynamic to changes that may arise in the future.

Objectives of the work. With this project we intend to explore both technical and methodological objectives.

Technical objectives. To compete in this new market of Internet travel sales, on the one hand we need to be extremely fast application in managing Touristic package bookings. To do this we must limit the maximum containment and transactions while ensuring correctness, or what is the same, to prevent interference with other transactions in progress for lack of locks.

On the other hand, it is also desirable that the application is easily testable, for it will build an architecture in which business objects can run both outside and within the J2EE container, so that it can be subjected to all necessary evidence without complication, and slowly added to boot a J2EE server. Another necessary characteristic derived from the former, is to build an architecture based on the paradigm of object orientation, known as Open / Closed principle. This principle postulates that the code is open for extension but closed for modification because every time we change code we risk damaging it. Therefore we use inheritance and composition techniques to add functionality to our programs.

Methodological objectives. We in this project, we will use agile development practices such as:Frequent feedback: it has been planned for use cases and as short as possible self-contained, meaning that no other parts need to be tested.Automated Testing: is starting to develop life begin testing. We will make unit testing and integration in a constant cycle as discussed in more detail below.

Methodological Approach

For this project we will explore how to apply the main practices what is known as "agile development". The traditional approach to application development inherited from other branches of engineering has been to make a comprehensive malaria survey of the problem, establish a plan and carry out the construction. Is the methodology known as waterfall development, with consecutive phases of analysis, design, coding, testing and deployment. But this approach is not always optimal for the development of software. Programming is not exactly comparable to other branches of engineering or construction. Software development is a purely creative process; similar to that in the construction of a home would be the development of the plans.

Unlike civil engineering, software development there is a building process, which follows mechanically, planes previously established by the architect or engineer. In each phase have to be creative and make decisions. In fact there is a process similar to the pure construction, which should not make decisions and apply only dictated by the architect. It is over the object source code, compiling. But its cost is negligible compared to the cost of the design. Just the opposite of what happens with the civil engineering design where cost is vastly less than that of the construction.

The aim of the methodologies of agile software development is the organization of a creative work, which is usually quite chaotic. It tries to give priority to the implementation of planning. As knowledge deepens problem plans are changed. When customers see our proposals, you will think of new ideas that will change the plans. When we deepen in the knowledge of new discoveries that will change technologies back plans.

Excessive planning is the usual problem of software development approaches cascade. Planning is excessive when unknown part or much of the problem we face and yet set targets and deadlines. In the best renounce the advantages to be gained by a better understanding of the problem. At worst, our plan will fail to find risks that we did not have.

Means agile, adaptable. From this premise, the changes are welcome, derived from a better understanding of the problem and are an opportunity to improve the software. This project will be fast because we have to deal with technological uncertainty by having to evaluate and J2EE technology manager PostgreSQL databases. It will also be flexible because we must be ready to adapt to find the best solution to the problem of achieving a high performance transaction travel reservations, which can affect the overall application approach. Agile development is not equivalent to chaos. To be able to conduct need based on two pillars: automatic testing and feedback (feedback) early, i.e. tangible short-term goals.

Agile manifesto. Since one of the main objectives of this project is to assess the use of agile development methodologies, introduce the agile manifesto, signed by renowned figures such as Martin Fowler and Alistair Cockburn among others. You can see the original manifest http://agilemanifesto.org/ following this link. Rate more individuals and their interaction with the processes and tools. This is possibly the most important principle of the manifesto. Of course help the work processes. They are a guide to operation. The tools improve efficiency, but people with technical knowledge and right attitude, do not produce results. Companies often preach very high that your employees are the most important, but the reality is that in the 90 theory-based production processes, process re-engineering has given them more relevant to the tasks that can be they owe much of their value to the knowledge and talent of the people who make them.

Processes should be a help and support to guide the work. They must adapt to the organization, equipment and people, and not vice versa. The stubborn defense processes to postulate that they can achieve extraordinary results with mediocre people, and the truth is that this principle is dangerous when jobs require creativity and innovation.Rate more software running that thorough documentation.Seeing ahead behave as expected functions on prototypes or parts already made the final system provides feedback (feedback) very stimulating and enriching that generates ideas impossible to conceive at first, it will be difficult to get a document containing requirements detailed before starting the project.The manifesto does not say that not needed. Documents are supporting documentation, allow the transfer of knowledge, historical information recorded, and many legal or regulatory issues are mandatory, but stresses that are less important than the products that work.

Documents cannot replace, or can offer wealth and value creation is achieved with direct communication between people and through interaction with the prototypes. So whenever possible should be preferred, and reduce to a minimum the use of documentation, which generates work that does not provide direct value to the product.If the organization and the computers communicate through documents, in addition to losing the wealth that gives the interaction with the product, just drifting to employ as barricades documents between departments or between people.

Rate more collaboration with the customer contract negotiation. Agile practices are especially suitable for difficult to define in detail in the beginning, or if you would define and ultimately less value than if they are enriched with continuous information feedback during development. Also for those cases when the requirements will be very unstable speed business environment.

For agile development the result value is not due to be controlled under an execution processes, but have been implemented directly on the product. A contract does not add value to the product. It is a formality that establishes boundaries between responsibilities, which sets benchmarks for potential contractual disputes between customer and supplier.In agile development the client is a member of the team, which integrates and collaborates in the work group. The work contract models do not fit.

Rate change response more than following a plan. For a development model that emerges from unstable environments, whose inherent factor change and rapid and continuous evolution is much more valuable than responsive monitoring and assurance of pre-established plans. The main values are agile anticipation and adaptation different from orthodox project management: planning and control to avoid deviations from the plan.

Applying agile methodology in our project. We tried to follow a methodology based on SCRUM, but the attempt to assume the roles of client, project manager and programmer in one person made this approach very artificial. Therefore we have focused on two aspects of agile methodology that we believe have the greatest importance: automated testing, and give more importance to the software documentation, i.e. documentation will be a tool for software and other product to add.

Automated test. Automated tests are the cornerstone of any agile development methodology, how if we will not allow us to change the characteristics of an application in the middle of development and be assured of not having anything spoiled?Despite the efforts of software engineering to maintain independence of the different components that make up a system. Inevitably application modules have to interact with each other creating interdependencies that are sometimes not evident.

By changing the functionality of some of these modules can have unintended consequences elsewhere in the system. These consequences can detect the running automated tests to check all parts of the system.The tests therefore allow us to cope with change more guarantees. Besides the fact that we can be automated repeat many times without increasing the cost of development.

Economic Justification of automated testing.This application has about 140 methods. Every time we have included or modified a method we have implemented a test suite that runs almost all methods.Suppose we run the suite about 500 times (I run the suite several times as development) If a developer were to hand debugging those tests take 140 * 500 * 2 minutes = 140,000 minutes per test, or what is the same 291 days job.The writing tests cost me 30 to 60 minutes per method, there are 56 methods in the test project, so I invested 56 * 45min = 40 hours or 5 days.Writing automated tests saved us 286 days of work.That's assuming that the programmer who execute the tests not to make a mistake and was never as perfect as automated tests.

Justification unit testing and integration. In a naive approach might think that a test could be limited to start the application, follow the user manual and see who does what he has to do, that is, what is an integration test. However, for instance, if a program has 6 controls with 4 possible input values to give a certain result, try one with an integration test would force us to write 4 * 4 * 4 * 4 * 4 * 4, evidence which are the different possibilities that would input the system, or what is the same 4 ^ 6 = 46 656 different tests.

With unit tests we can test these components individually, i.e. the first control would test for what we would write four tests for the four possible input values. We would do the same with the remaining 5 controls which would write four tests for each, in total 4 + 4 + 4 + 4 + 4 + 4 = 4 * 6 = 24 tests to test all controls compared to 46,656 tests we should do if we did only integration tests.

Unit testing. The goal of testing is not to prove that the system works, but to find errors. Empirically we have seen that most of the errors in the functions are at the entrance of null values, empty strings and limit values. For limit values mean that if a function accepts a range of values, the limits are the boundaries of these values.Normally in all tests the first step has been to try to do what you have to do with the expected values. Then usually tested with nulls, empty strings and limit values.We have not tested all the classes, only those with some complexity. It usually has a test method but in some cases have had to do more.The chosen framework for unit testing is JUnit.

Integration testing. For testing we used HttpUnit unit and manual tests. Http client HttpUnit is a fact that we can combine Java with JUnit for integration tests against http server.

Performance tests. To see the speed of transactions we used simple classes with stopwatch software, to measure performance, and that speed was a critical part of the system.

Documentation. As for the documentation, we have dispensed with it we have found that are useful use cases well documented with UML activity diagrams.We have been particularly useful in describing the behavior of the drivers of each of the use cases.

The diagrams have helped improve productivity and allowing focus on the functionality that is being developed and put aside the concerns of subsequent tasks. We have not yet found useful class diagrams, sequence and collaboration., And therefore we have not used. This is because we have always used the same patterns: MVC, Façade, Decorators, and DAO Factorys.