ABHISHEK K L Assist Prof, MCA-RIT MODULE-I Overview of Agile Software Development How do you define a project? Before we get into project management, we need to define what exactly a “project” is. Sure, you've probably been assigned countless “projects” in school or on the job, but what is the actual definition? The Project Management Institute defines a “project” as “a temporary endeavour undertaken to create a unique product, service or result.” There are a few key things to notice in this definition: » The word “temporary” means projects must have a defined beginning and end. This means every project must include a timeline, scope and resources. The fact that it is temporary with a beginning and an end also means that it is not part of ongoing operations. This brings us to the second point. > The purpose of a project must be “to create a unique product, service, or result.” This means a project will be started in order to accomplish a specific goal that is typically outside the realm of the typical day-to-day business operation. This means, the project team might include people who don't usually work together, and require resources that are typically outside the scope of day-to- day operations, However, dictionary.com defines a project in somewhat looser terms: “a large or major undertaking, especially one involving considerable money, personnel, and equipment.” Regardless, every project must have the following components: 1, Goal: What are you trying to achieve? 2. Timeline: When are you trying to achieve it by? 3. Budget: How much will it cost to achieve? 4. Stakeholders: Who are the major players who have an interest in this project? 5. Project manager: Who is going to make sure everything that needs to be completed gets completed? ‘A project is not something routine. Day-to-day operations or maintenance is not considered a project because it does not have a definitive start and end. What is project management? Project management is the practice of applying knowledge, skills, tools, and techniques to complete a project according to specific requirements. It comes down to identifying the problem, creating a plan to solve the problem, and then executing on that plan until the problem has been solved. That may sound simple, but there is a lot that goes into it at every stage of the process. The five project management process groups are: 1, Initiating: The goal for this phase is to define the project. 2. Planning: This phase includes developing a roadmap for everyone to follow. 3. Executing & Monitoring: In this stage, the project team is built and deliverables are created. Project managers will monitor and measure project performance to ensure it stays on track. 4. Closing: The project is completed, a post mortem is held, and the project is transferred to another team who will maintain it.ABHISHEK K L Assist.Prof, MCA-RIT The top project management methodologies Project management methodologies are essentially different ways to approach a project. Each one has a unique process and workflow. The top project management methodologies: 1. The traditional, sequential methodologies > Waterfall project management methodology > Critical path method (CPM) > Critical chain project management (CCPM) 2. The Agile family Agile project management methodology > Scrum > Kanban > Extreme Programming (XP) > Adaptive Project Framework (APF) 3. The change management methodologies > Event chain methodology (ECM) > Extreme Project Management (XPM) 4. The process-based methodologies > Lean > Six sigma > Lean six sigma v Rational Unified Process (RUP) RUP is a software development process for object-oriented models It is also known as the Unified Process Model. It is created by Rational corporation and is designed and documented using UML (Unified Modelling Language). This process is included in IBM Rational Method Composer (RMC) product. IBM (International Business Machine Corporation) allows us to customize, design, and personalize the unified process. RUP is proposed by Ivar Jacobson, Grady Bootch, and James Rambaugh. Some characteristics of RUP include use-case driven, Iterative (repetition of the process), and Incremental (increase in value) by nature, delivered online using web technology, can be customized or tailored in modular and electronic form, etc. RUP reduces unexpected development costs and prevents wastage of resources. Phases of RUP There are total five phases of life cycle of RUP: CommunicationABHISHEK K L Assist Prof, MCA-RIT Inception — Communication and planning are main. Identifies Scope of the project using use-case model allowing managers to estimate costs and time required. Customers’ requirements are identified and then it becomes easy to make a plan of the project. Project plan, Project goal, risks, use-case model, Project description, are made. Project is checked against the milestone criteria and if it couldn’t pass these criteria then project can be either cancelled or redesigned. Elaboration - Planning and modelling are main. Detailed evaluation, development plan is carried out and diminish the risks. Revise or redefine use-case model (approx. 80%), business case, risks. Again, checked against milestone criteria and if it couldn’t pass these criteria then again project can be cancelled or redesigned. Executable architecture baseline. Construction - Project is developed and completed System or source code is created and then testing is done. Coding takes place. 4. Transition - Final project is released to public. Transit the project from development into production. Update project documentation. Beta testing is conducted Defects are removed from project based on feedback from public. Production - Final phase of the model. Project is maintained and updated accordingly. What is Agile Methodology? Agile is a mind-set, a philosophy, more like a way of thinking, a movement focusing on communication, teamthinking, intrinsic motivation, innovative talks, flow, and value creation while developing a product. At its core, Agile is a set of principles for actions that keep a software development team organized and efficient. Agile started when in 2001, a team of software developers got together in Utah for a weekend of fun and discussion. They compiled their views and principles into a document that is easy to understand and apply. Which we refer to as Agile Manifesto.ABHISHEK K L Assist Prof, MCA-RIT Agile Methodology meaning a practice that promotes continuous iteration of development and testing throughout the software development lifecycle of the project. In the Agile model in software testing, both development and testing activities are concurrent, unlike the Waterfall model. What is Agile Software Development? The Agile software development methodology is one of the simplest and effective processes to turn a vision for a business need into software solutions. Agile is a term used to describe software development approaches that employ continual planning, learning, improvement, team collaboration, evolutionary development, and early delivery. It encourages flexible responses to change. Why do we need Agile methodology? Before Agile came into the picture, we had the Waterfall model of software development. The waterfall model can be defined as a sequential process in the development of a system or software that follows ‘a top-down approach. This model was a straight forward and linear model. The waterfall model had various phases such as Requirements Gathering, Software Design, Implementation, Testing, Deployment, and Maintenance. This model however suffered a few drawbacks such as follows: > This model was too time-consuming. Unless you complete a particular stage, you cannot proceed to the further stages. > This model was suitable only for projects where requirements are stable. » The working software is delivered only after completion of the final stage of the model.ABHISHEK K L Assist Prof, MCA-RIT > It is very difficult to go back to the previous stages and make some changes that you had not thought about in the initial phase. Due to the above-mentioned drawbacks of the Waterfall model, the leaders from the different development methodologies decided to meet to find a way forward through these problems. These leaders agreed upon a lightweight development method and they were also able to give wordings for the same in the form of a manifesto. It was called” The Manifesto for Agile Software Development”. The Manifesto describes 4 values and 12 supporting principles. The values set out in the Agile Manifesto are: 1. Individuals and interactions over processes and tools. 2. Working software over comprehensive documentation. 3. Customer collaboration over contract negotiation. 4, Responding to change over following a plan. 1. Individuals and interactions over processes and tools. People are the most important ingredient of success. A good process will not save the project from failure if the team doesn’t have strong players, but a bad pro- cess can make even the strongest of players ineffective. Even a group of strong players can fail badly if they don’t work as a team. A strong player is not necessarily an ace programmer. A strong player may be an average programmer, but someone who works well with others, Working well with others, communicating and interacting, is more important than raw programming talent. A team of average programmers who communicate well are more likely to succeed than a group of superstars who fail to interact asa team. The right tools can be very important to success. Compilers, IDEs, source-code control systems, etc. are all vital to the proper functioning of a team of developers. However, tools can be overemphasized. An overabundance of big, unwieldy tools is just as bad as a lack of tools. My advice is to start small. Don’t assume you've outgrown a tool until you've tried it and found you can't use it. Instead of buying the top-of-the-line, mega expensive, source-code control system, find a free one and use it until you can demonstrate that you've outgrown it. Before you buy team licenses for the best of all CASE tools, use white boards and graph paper until you can reasonably show that you need more. Before you commit to the top-shelf behemoth database system, try flat files. Don’t assume that bigger and better tools will automatically help you do better. Often they hinder more than they help. Remember, building the team is more important than building the environment. Many teams and managers make the mistake of building the environment first and expecting the team to gel ‘automatically. Instead, work to create the team, and then let the team configure the environment on the basis of need. 2. Working software over comprehensive documentation. Software without documentation is a disaster. Code is not the Ideal medium for communicating the rationale and structure of a system. Rather, the team needs to produce human-readable documents that describe the system and the rationale for their design decisions.ABHISHEK K L Assist Prof, MCA-RIT However, too much documentation is worse than too little. Huge software documents take a great deal of time to produce and even more time to keep in sync with the code. If they are not kept in sync, then they turn into large, complicated lies and become a significant source of misdirection. It is always a good idea for the team to write and maintain a rationale and structure document, but that document needs to be short and salient. By “short,” I mean one or two dozen pages at most. By “salient,” I mean it should discuss the overall design rationale and only the highest-level structures in the system. If all we have is a short rationale and structure document, how do we train new team members to work on the system? We work closely with them. We transfer our knowledge to them by sitting next to them and helping them. We make them part of the team through close training and interaction. The two documents that are the best at transferring information to new team members are the code and the team. The code does not lie about what it does. It may be hard to extract rationale and intent from the code, but the code is the only unambiguous source of information. The team members hold the ever- changing road map of the system in their heads. There is no faster and more efficient way to transfer that road map to others than human to-human interaction. Many teams have gotten hung up in the pursuit of documentation instead of software, This is often a fatal flaw. There is a simple rule called Martin’s first law of documentation that prevents it: Produce no document unless its need is immediate and significant. Customer collaboration over contract negotiation. Software cannot be ordered like a commodity. You cannot write a description of the software you want and then have someone develop it on a fixed schedule for a fixed price. Time and time again, attempts to treat software projects in this manner have failed. Sometimes the failures are spectacular. It is tempting for the managers of a company to tell their development staff what their needs are, and then expect that staff to go away for a while and return with a system that satisfies those needs. However, this mode of operation leads to poor quality and failure. Successful projects involve customer feedback on a regular and frequent basis. Rather than depending on a contract or a statement of work, the customer of the software works closely with the development team, providing frequent feedback on their efforts. A contract that specifies the requirements, schedule, and cost of a project is fundamentally flawed. In most cases, the terms it specifies become meaningless long before the project is complete.2 The best contracts are those that govern the way the development team and the customer will work together. ‘As an example of a successful contract, take one I negotiated in 1994 for a large, multiyear, half mmillion-line project. We, the development team, were paid a relatively low monthly rate. Large pay-outs were made to us when we delivered certain large blocks of functionality. Those blocks were not specified in detail by the contract. Rather, the contract stated that the pay-out would be made for a block when the block passed the customer's acceptance test. The details of those acceptance tests were not specified in the contract.ABHISHEK K L Assist.Prof, MCA-RIT During the course of this project, we worked very closely with the customer. We released the software to him almost every Friday. By Monday or Tuesday of the following week, he would have a list of changes for us to put into the software. We would prioritize those changes together and then schedule them into subsequent weeks. The customer worked so closely with us that acceptance tests were never an issue. He knew when a block of functionality satisfied his needs because he watched it evolve from week to week. The requirements for this project were in a constant state of flux. Major changes were not uncommon. There were whole blocks of functionality that were removed and others that were inserted. Yet the contract, and the project, survived and succeeded. The key to this success was the intense collaboration with the customer and a contract that governed that collaboration rather than trying to specify the details of scope and schedule for a fixed cost. Responding to change over following a plan. It is the ability to respond to change that often determines the success or failure of a software project. When we build plans, we need to make sure that our plans are flexible and ready to adapt to changes in the business and technology. The course of a software project cannot be planned very far into the future. First of all, the business environment is likely to change, causing the requirements to shift. Second, customers are likely to alter the requirements once they see the system start to function. Finally, even if we know the requirements, and we are sure they won't change, we are not very good at estimating how long it will take to develop them. It is tempting for novice managers to create a nice PERT or Gantt chart of the whole project and tape it to the wall. They may feel that this chart gives them control over the project. They can track the individual tasks and cross them off the chart as they are completed. They can compare the actual dates with the planned dates on the chart and react to any discrepancies. What really happens is that the structure of the chart degrades. As the team gains knowledge about the system, and as the customers gain knowledge about their needs, certain tasks on the chart become unnecessary. Other tasks will be discovered and will need to be added. In short, the plan will undergo changes in shape, not just changes in dates. A better planning strategy is to make detailed plans for the next two weeks, very rough plans for the next three months, and extremely crude plans beyond that. We should know the tasks we will be working on for the next two weeks. We should roughly know the requirements we will be working on for the next three months. And we should have only a vague idea what the system will do after a year. This decreasing resolution of the plan means that we are only investing in a detailed plan for those tasks that are immediate. Once the detailed plan is made, it is hard to change since the team will have a lot of momentum and commitment. However, since that plan only governs a few weeks’ worth of time, the rest of the plan remains flexible.ABHISHEK K L Assist Prof, MCA-RIT 12 Principles of Agile Manifesto The above values inspired the following 12 principles, which are the characteristics that differentiate a set of agile practices from a heavyweight process: 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. ‘The MIT Sloan Management Review published an analysis of software development practices that help companies build high-quality products. The article found a number of practices that had a significant impact on the quality of the final system. One practice was a strong correlation, between quality and the early delivery of a partially functioning system. The article reported that the less functional the initial delivery, the higher the quality in the final delivery. Another finding of this article is a strong correlation between final quality and frequent deliveries of increasing functionality. The more frequent the deliveries, the higher the final quality. An agile set of practices delivers early and often. We strive to deliver a rudimentary system within the first few weeks of the start of the project. Then, we strive to continue to deliver systems of increasing functionality every two weeks. Customers may choose to put these systems into production if they think that they are functional enough. Or they may choose simply to review the existing functionality and report on changes they want made. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. This is a statement of attitude. The participants in an agile process are not afraid of change. ‘They view changes to the requirements as good things, because those changes mean that the team has learned more about what it will take to satisfy the market. ‘An agile team works very hard to keep the structure of its software flexible so that when requirements change, the impact to the system is minimal. Later in this book we will learn the principles and patterns of object-oriented design that help us to maintain this kind of flexibility. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale. We deliver working software, and we delivery it early (after the first few weeks) and often (every few weeks thereafter). We are not content with delivering bundles of documents or plans. We don’t count those as true deliveries. Our eye is on the goal of delivering software that satisfies the customer's needs. 4. Business people and developers must work together daily throughout the project. In order for a project to be agile, there must be significant and frequent interaction between the customers, developers, and stakeholders. A software project is not like a fire-and-forget weapon. A software project must be continuously guided.ABHISHEK K L Assist Prof, MCA-RIT Build projects around mot environment and support they need, and trust them to get the job done. {An agile project is one in which people are considered the most important factor of success. All other factors—process, environment, management, etc.—are considered to be second order effects, and they are subject to change if they are having an adverse effect upon the people. For example, if the office environment is an obstacle to the team, the offifice environment must be changed. If certain process steps are an obstacle to the team, the process steps must be changed. The most efficient and effective method of conveying information to and within a development team is face to-face conversation, In an agile project, people talk to each other. The primary mode of communication is conversation. Documents may be created, but there is no attempt to capture all project information in writing. An agile project team does not demand written specs, written plans, or written designs. Team members may create them if they perceive an immediate and significant need, but they are not the default. The default is conversation. Working software is the primary measure of progress. Agile projects measure their progress by measuring the amount of software that is currently ‘meeting the customer's need. They don’t measure their progress in terms of the phase that they are in or by the volume of documentation that has been produced or by the amount of infrastructure code they have created. They are 30% done when 30% of the necessary functionality is working. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace An agile project is not run like a 50-yard dash; it is run like a marathon. The team does not take off at full speed and try to maintain that speed for the duration. Rather, they run at a fast, but sustainable, pace. Running too fast leads to burnout, shortcuts, and debacle. Agile teams pace themselves. They don't allow themselves to get too tired. They don’t borrow tomorrow's energy to get a bit more done today. They work at a rate that allows them to maintain the highest quality standards for the duration of the project. Continuous atten enhances agility. nto technical excellence and good design High quality is the key to high speed. The way to go fast is to keep the software as clean and robust as possible. Thus, all agile team members are committed to producing only the highest quality code they can. They do not make messes and then tell themselves they'll clean it up when they have more time. If they make a mess, they clean it up before they finish for the day.ABHISHEK K L Assist Prof, MCA-RIT g the amount of work not done—is Agile teams do not try to build the grand system in the sky. Rather, they always take the simplest path that is consistent with their goals. They don’t put a lot of importance on anticipating tomorrow's problems, nor do they try to defend against all of them today. Instead, they do the simplest and highest-quality work today, confident that it will be easy to change if and when tomorrow's problems arise. 11.The best architectures, requirements, and designs emerge from self- organizing teams. An agile team is a self-organizing team. Responsibilities are not handed to individual team members from the outside. Responsibilities are communicated to the team as a whole, and the team determines the best way to fulfil them. Agile team members work together on all aspects of the project. Each is allowed input into the whole. No single team member is responsible for the architecture or the requirements or the tests. The team shares those responsibilities, and each team member has influence over them, 12.At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly. An agile team continually adjusts its organization, rules, conventions, relationships, etc. An agile team knows that its environment is continuously changing and knows that they must change with that environment to remain agile. Agile Model Vs Waterfall Model Agile Model Waterfall Model ‘Agile methodology definition: Agile methodologies Waterfall Model: Development of the software flows propose incremental and iterative approach to software 4 sequentially from start point to end point. fesign The Agile process in software engineering is broken into | _ The design process is not broken into an individual individual models that designers work on models ‘The customer has early and frequent opportunities t0 look’ ‘The customer can only see the product at the end of the at the product and make decision and changes to the roject project aad [Small projects ean be implemented very quickly. For large| All sorts of project can be estimated and completed. projects, it i difficult to estimate the development time, ‘Only at the end, the whole product is tested. the Error can be fixed in the middle of the project. requirement error is found or any changes have to be ‘made, the project has to start from the beginningABHISHEK K L Assist Prof, MCA-RIT Development process is iterative, and the project is The development process is phased, and the phase is| executed in short (2-4) weeks iterations. Planning is very | much bigger than iteration. Every phase ends with the less. detailed description of the next phase. ‘Documentation attends less priority than software Documentation is a top priority and can even use for development training staff and upgrade the software with another team Every iteration has its own testing phase. It allows Only after the development phase, the testing phase is implementing regression testing every time new functions ‘executed because separate parts are not fully functional or logic are released Tn agile testing when an iteration end, shippable features of the product is delivered to the customer. New features |All features developed are delivered at once after the long are usable right after shipment. It is useful when you have implementation phase. good contact with customers. ‘Testers and developers work together ‘Testers work separately from developers ‘AL the end of every sprint, user acceptance is performed | User acceptance is performed at the end of the project. it requires close communication with developers vveloper does not involve in requirement and planning} jogether analyse requirements and planning fovess. Usually, time delays between tests and coding. PHASES OF AGILE METHODOLOGY Agile model (- Agile j REQUIREMENTS.ABHISHEK K L Assist Prof, MCA-RIT Phase 1: Requirements Before a Product Owner can even start designing a project, they need to create the it documentation that will ist the initial requirements. They are > The end result the project is going to achieve. For example, a text editor; > The features that it will support. For example, different font sizes; » The features that it will not initially support. For example, adding animations to the text or ability to embed video; ‘A general recommendation is to lower these initial requirements as hard as one can, adding only the definitely necessary features and ignoring ones that won't be used often. Developers can work on them later, once the app is deployed and the core features work well. On further iterations, the Client and the Product Owner review the requirements and make them more relevant. Phase 2: Design There are two ways to approach design in the software development — one is the visual design and the other is the architectural structure of the app. Software Design During the first iteration, the Product Owner assembles their development team and introduces the requirements created during the previous stage. The team then discusses how to tackle these requirements, and proposes the tools needed to achieve the best result. For example, the team defines the programming language, frameworks, and libraries that the project is going to be using. On further iterations, the developers discuss the feature implementation and the internal structure of the come. UI/UX Design During this SDLC stage, the designers create a rough mock-up of the UI. If the product is consumer-grade, the user interface and user experience are most important. So it’s generally a good idea to review the possible competitors to see what they are doing right — and especially what they are doing wrong. Further iterations are spent refining the initial design and/or reworking it to suit the new features. Phase 3. Development and Coding The development phase is about writing code and converting design documentation into the actual software within the software development process. This stage of SDLC is generally the longest as it’s the backbone of the whole process. There aren’t many changes between the iterations here. Phase 4. Integration and Testing This stage is spent on making sure that the software is bug-free and compatible with everything else that the developers have written before. The Quality Assurance team conducts a series of tests in order to ensure the code is clean and business goals of the solution are met. During the further iterations of this SDLC stage, the testing becomes more involved and accounts not only for functionality testing, but also for systems integration, interoperability, and user acceptance testing, etc.ABHISHEK K L Assist Prof, MCA-RIT Phase 5. Implementation and Deployment The application is deployed on the servers and provided to the customers — either for the demo or the actual use. Further iterations update the already installed software, introducing new features and resolving bugs. Phase 6. Re’ Ww Once all previous development phases are complete, the Product Owner gathers the Development Team once again and reviews the progress made towards completing the requirements. The team introduces their ideas toward resolving the problems that arose during the previous phases and the Product Owner takes their propositions into consideration Afterwards, the Agile software development lifecycle phases start anew — either with a new iteration or by moving toward the next stage and scaled Agile, Advantages of Agile methodology The various advantages offered by AGILE methodology are as follows: > Agile software development allows the team to work together more efficiently and effectively to develop complex projects. > It consists of practices that exercise iterative and incremental techniques that are easily adopted and display great results. > IM AGILE, the delivery of the software is persistent. > After every Sprint, working feature(s) is/are delivered to the customer. This increases the level of satisfaction in them. > Customers can have a look at the developed features and check if they meet their expectations. > If the customers have any feedback or they want any changes in the features, then it can be accommodated in the current or maybe the next release of the product. > Changes can be made even in the later stages of the development of the product. In AGILE, the business people and the developers of the product interact daily. > Asignificant amount of attention is paid to the design of the product. v How to implement Agile methodology? The AGILE methodology can be implemented with the help of various frameworks such as Scrum, Kanban, EXtreme Programming (XP), Lean, Crystal, Adaptive Project Framework (APF), Feature Driven Development (FDD), Dynamic Systems Development Method (DSDM), Agile Unified Process (AUP) and 50 on. What is Test Driven Development(TDD)? Test Driven Development (TDD) is software development approach in which test cases are developed to specify and validate what the code will do. In simple terms, test cases for each functionality are created and tested first and if the test fails then the new code is written in order to pass the test and making code simple and bug-free. Test-Driven Development starts with designing and developing tests for every small functionality of an application. TDD framework instructs developers to write new code only if an automated test has failed. This avoids duplication of code. The TDD full form is Test-driven development.Three phases of Test D: 1 ABHISHEK K L Assist.Prof, MCA-RIT en Development Create precise tests: Developers need to create precise unit tests to verify the functionality of specific features, They must ensure that the test compiles so that it can execute. In most cases, the test is bound to fail. This is a meaningful failure as developers are creating compact tests based on their assumptions of how the feature will behave. Correcting the Code: Once a test fails, developers need to make the minimal changes required to correct the code so that it can run successfully when re-executed, Refactor the Code: Once the test runs successfully, check for redundancy or any possible code optimizations to enhance overall performance. Ensure that refactoring does not affect the external behaviour of the program, How to perform TDD Test Following steps define how to perform TDD test, 1 2 3, 4 5, Add a test. Run all tests and see if any new test fails. Write some code. Run tests and Refactor code. Repeat. CCRC een e a d Refactoring neurons the Code Seca cera) Pass. Development StopsABHISHEK K L Assist Prof, MCA-RIT Agile Model Driven Development (AMDD) Agile Model Driven Development (AMDD) is, as implied by its name, an agile version of Model Driven Development (MDD), a process where models are generated before code is written. With AMDD, agile models are created where the models are good enough to start writing the code, instead of spending too much time creating general models with MDD. The lifecycle of AMDD 1. Iteration 0: En) Ina Requirements Ina Architactaral Envisioning Envisioning + loony the tigh evel scope ent iia requirements sta leony an architectural vision \eovs) ays) + Morin fe pt of tration planing oot 5 Nee model rcogh to give god extates erton Modeling {Hee plone wot rte traton (ours). a a Work trough spec issues ona IT mannor Stakeholders aciveypariopato Requternents orl foughout poict Model just enough for now, you can abays com ack ater ode! Storming | © loptionay ‘+ Develop working sotnare via @telrst poroach 1 Detae coptured inthe orm of exeetate specications There are two main sub-activates. % 2. 2. Iteration model Initial requirements envisioning. It may take several days to identify high-level requirements and scope of the system. For carrying out with this stage the developer may require some type of usage model, Initial domain model, and user interface model (UI). Initial Architectural envisioning. It also takes several days to identify architecture of the system. It allows setting technical directions for the project. Here team must plan the work that will be done for each iteration. > Agile process is used for each iteration, i.e. during each iteration, new work item will be added with priority. First higher prioritized work will be taken into consideration. Work items added may be reprioritized or removed from items stack any time. ‘The team discusses how they are going to implement each requirement. Modeling is used for this purpose. Modeling analysis and design is done for each requirement which is going to implement for that iteration.ABHISHEK K L Assist Prof, MCA-RIT 3. Model storming This is also known as Just in time Modeling * Here modelling session involves a team of 2/3 members who discuss issues on paper or whiteboard. . One team member will ask another to model with them. This modelling session will take approximately 5 to 10 minutes. Where team members gather together to share whiteboard/paper. > They explore issues until they don’t find the main cause of the problem. Just in time, if one team member identifies the issue which he/she wants to resolve then he/she will take quick help of other team members. > Other group members then explore the issue and then everyone continues on as before. It is also called as stand-up modelling or customer QA sessions. 4. Test Driven Development (TDD) > It promotes confirmatory testing of your application code and detailed specification. > Both acceptance test (detailed requirements) and developer tests (unit test) are inputs for TDD. > TDD makes the code simpler and clear. It allows the developer to maintain less documentation. 5. Reviews > This is optional. It includes code inspections and model reviews. > This can be done for each iteration or for the whole project. » This is a good option to give feedback for the project: What Is Extreme Programming (XP) Extreme Programming (XP) is an agile software development framework that aims to produce higher quality software, and higher quality of life for the development team XP is built upon values, principles, and practices, and its goal is to allow small to mid-sized teams to produce high-quality software and adapt to evolving and changing requirements. It is used to improve software quality and responsive to customer requirements. The extreme Programming model recommends taking the best practices that have worked well in the past in program development projects to extreme levels. The five values of XP 1. Communication Software development is inherently a team sport that relies on communication to transfer knowledge from one team member to everyone else on the team. XP stresses the importance of the appropriate kind of communication ~ face to face discussion with the aid of a white board or other drawing mechanism. 2. Simplici Simplicity means "what is the simplest thing that will work?” The purpose of this is to avoid waste and do only absolutely necessary things such as keep the design of the system as simple as Possible so that it is easier to maintain, support, and revise. Simplicity also means address only the requirements that you know about; don’t try to predict the future.eo ABHISHEK K L Assist Prof, MCA-RIT Feedback Through constant feedback about their previous efforts, teams can identify areas for improvement and revise their practices. Feedback also supports simple design. Your team bullds something, gathers feedback on your design and implementation, and then adjust your product going forward Courage Kent Beck defined courage as “effective action in the face of fear” (Extreme Programming Explained P. 20). This definition shows a preference for action based on other principles so that the results aren’t harmful to the team. You need courage to raise organizational issues that reduce your team’s effectiveness. You need courage to stop doing something that doesn’t work and try something else. You need courage to accept and act on feedback, even when it’s difficult to accept. Respect The members of your team need to respect each other in order to communicate with each other, provide and accept feedback that honours your relationship, and to work together to identify simple designs and solutions. Although practices used in XP are actually common practices which are shared by other methodologies, XP goes further by doing those practices to an extreme level (hence the “Extreme” Programing). Below is a table on how XP is extreme. Good Practices are Pushed to the Extreme. Code reviews Teview code all the time (pair programming) everybody will test all the time (unit testing) even the Testing customers (functional testing) Design make it part of everybody's daily business (refactoring) always leave the system with the simplest design that ‘supports current functionality (simplest thing that could possibly work) everybody will work defining and refining the ert a architecture all the time (metaphor) integrate and test several times a day (continuous Integration testing insraen make iterations really short-seconds, minutes, hours not belt) weeks, months, years (the planning game) Table 1. Why it’s called Extreme(XP)