Agile: The Necessitate Of Contemporary
Software Developers
HARSIMARJEET KHURANA
ASSISTANT PROFESSOR
Gurunanak Institute of Management and Technology Gujarkhan Campus, Model Town
Ludhiana, Punjab, India
DR. J.S. SOHAL
DIRECTOR
Ludhiana College of Engineering and Technology Katanikalan
Ludhiana, Punjab, India Abstract:
This paper focuses on the comparative analysis of traditional and agile techniques. It also discusses about how agile model architectural design can be more helpful for increasing the quality of the software and their completion within time limit.
Keywords
Traditional, Model, Agile, Architectural design
Introduction
Since the late 60s, different traditional software development methods have been developed and widely used by the software engineers. Over the years software developers have invested lot of time in to improve the development process. Lots of effort done by the developers on traditional methods has not turned out to be fruitful and have become quite mature and have reached at saturation level. Among the traditional methods waterfall method is the oldest method of the software development. This model has been widely use in both large and small software projects. It has been a successful development for large and complex projects. This model has drawbacks like linearity, inflexible etc.; such drawbacks can be found in other traditional models. However agile methods have been to find the solution to the drawback of waterfall. Agile methods deal with unstable and volatile requirements by using a number of techniques of which are very important are- simple planning, short iteration, earlier release, frequent customer feedback. These characteristics enable agile methods to deliver product releases in a much short period of time compared to waterfall model.
Comparison between Traditional Technique and Agile Technique
S. No. Feature Traditional Method Agile Method
1 Plan Driven Traditional are referred to as plan driven approach
Agile is also a plan driven approach but it involves more planning activities.
2 Documentation Traditional methods uses heavy and more use of documentation for capturing knowledge gained in the activities of the software development life cycle.
Agile methods most of the written documentation has been replaced by the enhanced informal communications among the team members internally and between the team and the customers with the stronger emphasis on implicit rather than explicit knowledge .
Project projects projects that are localized and hence can survive without documentation.
4 Necessities and
Subject information
This method donot suggest any specific practices that support active stakeholder and user participation, some of the practices described in agile techniques were also used in traditional models like RAD model. In this technique all the information are captured before any design and development. The drawback of this is that the developer hardly interacts with the customers to gain any feedback and on their understanding of the system
requirements. This technique is efficient as long
as system requirement remain stable till the project ends. In traditional world where the customers declare the large set of features presented at the end for not satisfying their needs. This happens because of disconnect between the development team and customers.
4 Training Formal training sessions are commonly use in traditional approach. One advantage of formal training sessions is that the training content and practices can be standardized and be applied consistently across multiple teams in a large organization but these training are expensive as they mean loss of valuable development time for both the trainers and trainees.
It recommends informal practices like pair programming and pair rotation in case of XP. Since these are informal practices so it requires no training and is not expensive. Informal training approaches like pair programming, is not problem free. Training content may vary, or worse, conflict across different pairs. Assigning two works cooperatively as a pair is also extremely difficult task. But I as an author believe that if pairs are made sensibly by using good pairing techniques then the conflict between the pairs can be reduced to a great extent.
5 Proficient Management
To identify what your staff knows or does not know is proficiency management the traditional technique does not mandate any such practice to deal with this issue, a common practice is to identify experts based on document authorship.
For this problem agile technique suggest stand up meeting in which the pair who is developing needs to present the work to the fellow developers and project managers. Everyone in the team knows who has worked on or is knowledgeable about which part of the system. Team knows whom to contact when they need to work on parts of the system that they are unfamiliar with. 6 Belief and
Concern
There is no doubt that in traditional technique faith was there but it was not to a great extent because the interaction between user and developer was not so much. The meeting of both parties was held twice one at the starting and finally at the time of last stage of the development process.
Through collective code ownership, stand up meetings, onsite customer, and in case of XP, pair programming, agile methods promote and encourage mutual trust, respect and care among developers themselves and with respect to the customer. The key knowledge about sharing here are interactions among members of the team which happens voluntarily and not by order from the head. 7 Team Sonata In traditional method
different roles are grouped together as a number of roles based teams each of which contain members of the same role.
should be used to facilitate better knowledge transfer.
8 Unremitting knowledge
Traditional approach supports unremitting knowledge not only at the project team but also at the organization levels.
Agile approach the knowledge is shared through separate process group that analyzes experiences from different project teams and refines the standard development process which all project teams in the organization need to conform to. This is in conflict with the agile principles.
9 Changing Requirements
It will be only in the starting phase of software development life cycle and not in between the phases.
It is adaptable throughout the development process.
10 Testing To see the errors an
performance of the software it is done at the second last stage of the model
Testing and getting confirmation from customer after every phase.
Traditional model have lot of documentation whereas agile have less documentation but some agile methods endorse modeling as a standard for documentation. A modeling technique which focuses on defining a collection of values, principles practices for modeling and documentation on software development projects is Agile Model Driven Development (AMDD). Agile lifecycle began to coalesce in 2003 on projects such an architectural envisioning and requirements envisioning at the beginning of a project or model storming on a just-in-time (JIT) basis throughout the project.
Practices of AMDD
Stakeholders should provide information in a timely manner, make decisions in a timely manner, and be as actively involved in the development process through the use of inclusive tools and techniques.
1. At the beginning of an agile project the requirements will be some initial, high-level architectural modeling to identify a viable technical strategy for the solution.
2. Write documentation as late as possible, avoiding speculative ideas that are likely to change in favor of stable information.
3. Specify requirements in the form of executable "customer tests", and your design as executable developer tests, instead of non-executable "static" documentation.
4. At the beginning of each iteration bit of modeling as part of the iteration planning activities will be done.
5. A model or document needs to be sufficient for the situation at hand and no more.
6. Sometimes requirements that are nearing the top of the priority stack are fairly complex, and motivating to invest some effort to explore them before they're popped off the top of the work item stack so as to reduce overall risk. Throughout iteration the model will be stormed on a just-in-time (JIT) basis for a few minutes to explore the details behind a requirement or to think through a design issue.
7. Each type of model has its strengths and weaknesses. An effective developer will need a range of models in their intellectual toolkit enabling them to apply the right model in the most appropriate manner for the situation at hand.
9. At the beginning of an agile project it will be required to invest some time to identify the scope of the project and to create the initial prioritized stack of requirements.
10. Strive to capture information in one place and one place only.
11. Write a single test, either at the requirements or design level, and then just enough code to fulfill that test. TDD is a JIT approach to detailed requirements specification and a confirmatory approach to testing.
Agile Architectural design
1. Towards Agile Architectural design
Agile Architectural design technique start will team effort keeping in view the project and requirements from that project. An architectural team is required in day-to-day development activities of the project team(s) and they may develop sometimes ivory tower architectural design. However these are often unproven, incomplete and there is a significant risk to the project until they actually work through the concrete feedback provided by a technical prototype. Ivory tower architectural designs may promote overbuilding of software because they typically reflect every feature ever required by any system that the architects were ever involved with and not just the features that the system actually needs. Agile architectural design also enables us to address the scaling issues, which mostly include team size, regulatory compliance, distributed teams, system complexity, and so on.
2. Architectural Design through the Lifecycle
Figure 1 depicts the lifecycle of Agile Model Driven Development (AMDD). During "iteration 0", the first iteration of an agile project, you need to get your project organized and going in the right direction. Part of that effort is the initial envisioning of the requirements and the architectural design so that you are able to answer critical questions about the scope, cost, schedule, and technical strategy of the project. From an architectural point of view, during iteration 0 the goal is identify a potential technical direction for the team as well as any technical risks which will potentially face the risks which should be addressed by proving it with code. Understanding and knowledge of the development team is also very important. The model follows the practice in small increments and reduces the technical risk of the project .An iterative and incremental approach addresses the risk of an inappropriate architectural design by developing immediately at the time, and only when it is actually required.
3. Have an "Architectural design Owner" Role
The senior most person of the team is responsible for facilitating the architectural modeling and evolution efforts. Architectural design owner is different than the traditional role of architect. In the past the architect would often be the primary creator of the architectural design and would be one of the few people who would be working on it. They would often develop the architectural design and then present it to, or more accurately force it upon, the development team. But in agile a architectural design owner collaboratively works with the team to develop and evolve the architectural design. Although they have the final decision-making authority when it comes to the architectural design, those decisions should be made in a collaborative manner with the team.
4. Choose the Architectural design Team
design team. This helps to increase the chance that each sub team learns and follows the architectural design as well as increases the chance that the core architectural design team will not ignore portions of the system. The responsibility from the starting stage till the feedback is of the core architectural design team. To avoid ivory tower architectural design the members of the core architectural design team will take active roles on the various sub teams on the project, communicating the architectural design to the sub teams and working with them to prove portions of the architectural design via concrete experiments. Frequent meetings will be held from starting of the project till the end. These meetings can be called twice that is starting of the day and ending of the day to discuss about the progress of the project to accomplish it timely.
5. Requirements-Determined Architectural Design
The architectural design requirement is the responsibility of the Stakeholder not the developers. Good sources for technical architectural design requirements will include the users and their direct management, as they will often have some insight into technical requirements and constraints. Operations staff will definitely have requirements focusing on architectural design. Senior management within the organization will have insights that may lead to potential change cases for the system. A common mistake that architectural design teams will make is to ignore existing and pertinent artifacts, such as network diagrams that describe the organizations existing technical infrastructure, enterprise-level business models (use case models, process diagrams, workflow diagrams, corporate business rules, and so on), or corporate deployment standards (for workstations, branch offices, etc.) that the system is expected to conform to. The existing artifacts may be out of date, but an effort should be made to examine them and take advantage of the existing work wherever possible.
6. Representation of the Architectural design
. All software project teams need to invest some time for modeling the architectural design of the system, and that this is true even of XP teams that rely on a metaphor to guide their development efforts. In case of agile methods the architectural design is represented in diagrammatical form. Navigation diagrams are the instantiation of your system’s architectural views. Different projects, different architectural views, hence different types of navigation diagram(s). A common mistake that organizations will make is to base their architectural efforts on their organization structure an important point to be made is that navigation diagrams are typically sufficient to describe the architectural design when all the communication is face-to-face. When the diagrams are not understandable by the developers then they are to be supplemented with the documentation. This happens when the architects does not work closely with the developers. At the beginning of a project the architectural design teams together are in a single room for an initial envisioning session. Ideally this session will last for no more than several hours but on some larger projects it may last for a few days. If the modeling session is longer then there is greater the chance of going out of track due to lack of feedback. The goal of this modeling session will be to come to an initial agreement as to the landscape of the system that we are building, perhaps not consensus but sufficient agreement so the can start moving forward as a team.
7. Move Light
8. Prove the Architectural Design
The practice Prove it With Code points out that a model is merely an abstraction, one that may appear to be very good but may not actually be so in practice, that the only way to know for sure is to validate the model through implementation. The implication is that it should prove that the Architectural design works, something that XP calls spikes and RUP calls architectural prototypes. When the architectural design calls out for something that is new, perhaps we are using two or more products together for the first time; we should invest the time to explore whether or not this approach will work as well as how it works in accordance to the principle Rapid Feedback. Here the permission of stakeholders is considered, as they will be the ones who spend money for the project. The development of an architectural prototype helps to reduce risk to the project because we can quickly discover whether the approach is feasible and simply ivory tower architectural design is not produced. 9. Communicate the Architectural design
There are two primary audiences for which communication of the architectural design is important: the development team and the project stakeholders. To promote communication within the development team, the practice to be followed should be Display Models Publicly for all architectural diagrams. We would also allow anyone who wanted to add comments or suggestions to the diagrams, along the lines of the principle Open and Honest Communication and the practice Collective Ownership, because we would require the feedback on our work. At the start of a project, the diagrams prepared are presented to the project stakeholders so that they can get a good idea as to what approach is intended so that they can judge that their resources are being invested wisely. To remain as agile as possible the principle Model with a Purpose should be implemented which tells that the stakeholders and focus should do the modeling exactly as desired should also be on the fact that for what purpose they will be used. Presentations should be given to stakeholders, to garner their support, participation and also to obtain needed resources
10. Think about the Future but Don’t Overbuild
Agile architectural modeling says that future changes should be considered but not be acted upon until actually required. In other words, don’t overbuild the system but at the same time be smart about it. The XP community is fairly blunt about the concept of overbuilding software with their belief that “You Ain’t Gonna Need It Anyway” (YAGNI). The basic idea is that accurate prediction of the future is not possible and therefore shouldn’t attempt to build for future possibilities. Instead focus should be on building what is required today and building it cleanly so that the software is easy to change when needed. Later on, when it is discovered that change is needed in software to fulfill new requirements then change it at that time. When the software is overbuilt and made general, to fulfill future potential requirements, we may actually make very serious trade-offs. First, we are not focusing on meeting today’s needs, resulting in something that may not be of immediate value to the users. Second, we don’t really know if we will even need whatever it is that we’re building – and a Porche may be build when a Volkswagon would have been sufficient. Third, anything that is over build today will need to be tested and maintained throughout the life of the project, violating the principle Travel Light. Fourth, when we overbuild something the only way to accurately validate it is via imaginary feedback, which may or may not be accurate. Thus it is better to model initial architectural design and change cases are modeled to describe new potential requirements for a system or modifications to existing requirements. Change cases are designed and modeled after feedback and discussions with the project stakeholders and also as per new upcoming technologies. Furthermore, change cases typically describe requirements that are reasonably divergent from what currently is being worked upon, requirements that would potentially cause major rework to fulfill. As per requirement relevant change cases can be brought into the decision making process.
11. Take a Multi-View Approach
Usage/business process User interface System interface Network Deployment Hardware Data storage Data transmission Events
Code/component distribution Function/logic/services
To borrow the language of aspect oriented programming (AOP), there are also "cross-cutting concerns" which the architectural design may also need to take into account. These concerns should also be addressed by the architectural views and in some cases may be specific views in themselves. These concerns are:
Layering/partitioning Reuse
Quality and validation Accuracy and timeliness
Reliability, Availability, Serviceability, and Performance Environment (green computing issues)
Customization points Consumability Security
Internationalization Regulations
Maintenance, operations, and support issues
The implication is that anyone in the role of architect needs to have a wide range of skills to be effective, that they need to move away from the traditional philosophy of over specialization and be more of a generalizing specialist. Minimally they should move away from being simply a data architect, or security architect, or network architect towards being an architect. Being just an architect is arguably too specialized as well, but that will vary depending on the situation
12. How Does This Work?
The architectural approach has been described is markedly different that what a lot of organizations are currently doing today. Table 1 compares and contrasts the architectural practices that are commonly found in many organizations with their agile counterparts. Clearly, there’s a big difference. The agile approach works because of its focus on people working together effectively as a team. Agile Modeling recognizes that people are fallible, that they aren’t likely to get the architectural design right to begin with and therefore need the opportunity for acting on feedback from implementation efforts. When agile architects are productive members of the development team, and when the development team has been involved with the architectural efforts to begin with, then they don’t need comprehensive documentation, the navigation diagrams are sufficient (granted, when this is not the case documentation, hopefully minimal, may be required). Architectural design reviews aren’t needed because the architectural design is being proved through the concrete feedback of architectural prototyping/spikes and because people can see the architectural design evolve because your models are displayed publicly for everyone to see. Agile architects have the courage to focus on solving today’s problem today and trusting that they can solve tomorrow’s problem tomorrow and the humility to recognize that they cannot accurately predict the future and therefore choose not to overbuild their architectural designs.
Comparing Common and Agile Architectural Practices
S. No. Common Architectural Practice Agile Architectural Practice 1 Architects are held in high esteem
and are often placed, or even worse place themselves, on pedestals
Agile architects have the humility to admit that they don’t walk on water
2 Architects are too busy to get their hands dirty with development
Agile architects are active members of development teams, developing software where appropriate and acting as architectural consultants to the team
3 Architectural design models are robust to enable them to fulfill future requirements
Agile architects have the humility to admit that they can’t predict the future and instead have the courage to trust they can solve tomorrow’s problem tomorrow
4 The goal is to develop a
comprehensive Architectural design early in a project
You evolve your Architectural design incrementally and iteratively, allowing it to emerge over time
5 Well-documented Architectural design model(s) are required
Travel light and focus on navigation diagrams that overview your Architectural design, documenting just enough to communicate to your intended audience 6 Architectural design model(s) are
communicated only when they are “suitable for public consumption”
Architectural design model(s) are displayed publicly, even when they are a work in progress, to promote feedback from others 7 Architectural design reviews are
held to validate your model(s) before being put into use
Architectural designs are proved through concrete experiments
Conclusion
Traditional method support information sharing mainly by explicit information externalized in the documents and concept of reusing the previous project experiences and a centralized knowledge management organization provides the infrastructure necessary in supporting unremitting knowledge. On the other hand, its main drawbacks are that it does not address issues of how well users internalize explicit information and the sharing of the implicit information that is not externalized. Agile development method relies heavily on socialization through communication and collaboration to access and share implicit information within the project team. When externalization and internalization are used for information transfer, all agile methods suggest that they should supported by close communication and collaboration. All agile methods involve the customer directly in acquiring requirements and sphere information. An interactive development approach is used to provide rapid feedback and unremitting knowledge between the customers and the development team at a project team level. An agile method emphasizes on people, practices, communication, and collaboration excels in facilitating the practice of sharing implicit knowledge at team level. They also foster a team culture of knowledge sharing, mutual trust and care.
REFERENCE
