Rapid Application development (RAD) Processes



TABLE OF CONTENT TOC \o "1-1" \h \z \u Rapid Application development (RAD) Processes PAGEREF _Toc242957950 \h 1Various RAD (Rapid Application Development) Methodologies PAGEREF _Toc242957951 \h 41.Agile Software Development PAGEREF _Toc242957952 \h 52.Joint Application Development (JAD) PAGEREF _Toc242957953 \h 83.EXTREME PROGRAMMING (XP) PAGEREF _Toc242957954 \h 114.Scrum Development Process PAGEREF _Toc242957955 \h 185.Lean software development (LD) PAGEREF _Toc242957958 \h 22References PAGEREF _Toc242957959 \h 26Rapid Application development (RAD) Processes TA \l "Rapid Application development (RAD) Processes" \s "Rapid Application development (RAD) Processes" \c 1 Today, business moves faster, and clients tend to change their minds more frequently over the course of a project’s development life cycle. Of course, they expect the development team to adapt to their needs and modify the structure of an application quickly. Fortunately, the use of scripting languages like Perl and PHP makes it easy to apply other programming strategies, such as rapid application development (RAD).Rapid Application Development process deals with Software engineering/management field. It refers to the type of Software development process which minimizes the pre planning phase, and results in more rapid software development lifecycle. RAD is a methodology for compressing the analysis, design, build, and test phases into a series of short, iterative development cycles. The idea behind this methodology is to start developing as early as possible so that clients can review a working prototype and offer additional direction. The application then gets built in an iterative process, releasing rich versions in short development cycles. RAD calls for the interactive use of structured techniques and prototyping to define user's requirements and design the final system. Using structured techniques, the developer first builds preliminary data models and business process models of the business requirements. Prototyping then helps the analyst and users to verify those requirements and to formally refine the data and process models. This results in a combined business requirements and technical design statement to be used for constructing new systems.Figure1. Showing two different development processProblem with Traditional style (Structure System Design and Analysis style)RAD has a number of distinct advantages over the traditional sequential development model Figure1.Some of the difficulties faced by the team member using traditional style of development are Applications took so long to build that requirements got changed before the system was complete. Resulting in inadequate or even unusable systems.Another problem was the assumption that a methodical requirements analysis phase alone would identify all the critical requirements, which is not very true.The cause of the problem was identified in the strict adherence to completion of one lifecycle stage before moving on to the next lifecycle stage. Specifically, building an application based on requirements that have been frozen at a point in time means that the longer development takes, the more likely that business needs will change and invalidate the requirements that the system being developed is based upon.Factors for Rapid Development Fast development does not mean a "quick and dirty" process. There should be no compromise between speed of development and quality. Several factors contribute to the success of rapid development by improving both the quality of the delivered system and the speed of delivery. Factors important for rapid development include: * Intensive involvement of the end user in the design of the system.* Use of prototyping, which helps users visualize and make adjustments to the system. * Use of an integrated CASE toolset to enforce technical integrity in modeling and designing the system. * Use of a CASE repository to facilitate the re-use of proven templates, components and systems. * Use of an integrated CASE toolset to generate bug-free code from a fully validated design. * User involvement in the Construction stage, allowing the details to be adjusted if necessary.* Development of a task structure that encourages parallel project activities. Various Stages of RADRequirements Planning The Requirements Planning stage consists of a review of the areas immediately associated with the proposed system. This review produces a broad definition of the system requirements in terms of the functions the system will support. The deliverables from the Requirements Planning stage include an outline system area model (entity and process models) of the area under study, a definition of the system's scope, and a cost justification for the new system. User Design The User Design stage consists of a detailed analysis of the business activities related to the proposed system. Key users, meeting in workshops, decompose business functions and define entity types associated with the system. They complete the analysis by creating action diagrams defining the interactions between processes and data. Following the analysis, the design of the system is outlined. System procedures are designed, and preliminary layouts of screens are developed. Prototypes of critical procedures are built and reviewed. A plan for implementing the system is prepared. Construction In the Construction stage, a small team of developers, working directly with users, finalizes the design and builds the system. The software construction process consists of a series of "design-and-build" steps in which the users have the opportunity to fine-tune the requirements and review the resulting software implementation. This stage also includes preparing for the cutover to production. In addition to the tested software, Construction stage deliverables include documentation and instructions necessary to operate the new application, and routines and procedures needed to put the system into operation. Implementation The implementation stage involves implementing the new system and managing the change from the old system environment to the new one. This may include implementing bridges between existing and new systems, converting data, and training users. User acceptance is the end point of the implementation stage. Core Elements of Rapid Application DevelopmentRAD has many core elements that make it a unique methodology including prototyping, iterative development, time boxing, team members, management approach, and RAD tools.PrototypingA key aspect of RAD is the construction of a prototype for the purpose of jumpstarting design and flushing out user requirements. The objective is to build a feature light version of the finished product in as short an amount of time as possible, preferably days. The initial prototype serves as a proof of concept for the client, but more importantly serves as a talking point and tool for refining requirements. Developing prototypes quickly is accomplished with Computer Aided Software Engineering CASE tools that focus on capturing requirements, converting them to a data model, converting the data model to a database, and generating code all in one tool Iterative DevelopmentIterative development means creating increasingly functional versions of a system in short development cycles. Each version is reviewed with the client to produce requirements that feed the next version. The process is repeated until all functionality has been developed. The ideal length of iterations is between one day (which is closer to Agile Methodologies) and three weeks. Each development cycle provides the user an opportunity to provide feedback, refine requirements, and view progress (in focus group session meetings). It is ultimately the iterative development that solves the problems inherent in the inflexible methodologies created in the 1970's. Time BoxingTime boxing is the process of putting off features to future application versions in order to complete the current version in as short amount of time as possible. Strict time boxing is an important aspect of RAD, because without it scope creep can threaten to lengthen development iterations, thus limiting client feedback, minimizing the benefits of iterative development, and potentially reverting the process back to a waterfall methodology approach. Team MembersThe RAD methodology recommends the use of small teams that consist of experienced, versatile, and motivated members that are able to perform multiple roles. As the client plays a vital role in the development process, dedicated client resources must be available during the initial Joint Application Development (JAD) sessions as well as Focus Group Sessions conducted at the end of development cycles. Development teams should ideally have experience in Rapid Application Development and should have experience with the Computer Aided Software Engineering tools. Management ApproachActive and involved management is vital to mitigate the risks of lengthened development cycles, client misunderstandings, and missed deadlines. Above all management must be stalwart and consistent in their desire to use the Rapid Application Development methodology. In addition to enforcing a strict timeline, management must focus on team member selection, team motivation, and on clearing bureaucratic or political obstacles. RAD ToolsOne of the primary objectives of the Rapid Application Development methodology developed by James Martin in the late 1980's was to take advantage of the latest technology available to speed development. Clearly the technology of the 1980's is obsolete today, but RAD's focus of the latest tools is as important today as it was when the methodology was initially created. This article has a section dedicated to tools following the process section. AdvantagesIncreased Speed, As the name suggests, Rapid Application Development's primary advantage lies in an application's increased development speed and decreased time to delivery. The goal of delivering applications quickly is addressed through the use of Computer Aided Software Engineering or CASE tools, which focus on converting requirements to code as quickly as possible, as well as Time Boxing, in which features are pushed out to future releases in order to complete a feature light version quickly.Increased Quality, Increased quality is a primary focus of the Rapid Application Development methodology, but the term has a different meaning than is traditionally associated with Custom Application Development. Prior to RAD, and perhaps more intuitively, quality in development was both the degree to which an application conforms to specifications and a lack of defects once the application is delivered. According to RAD, quality is defined as both the degree to which a delivered application meets the needs of users as well as the degree to which a delivered system has low maintenance costs. Rapid Application Development attempts to deliver on quality through the heavy involving of users in the analysis and particularly the design stages.DisadvantagesReduced Scalability, Because RAD focuses on development of a prototype that is iteratively developed into a full system, the delivered solution may lack the scalability of a solution that was designed as a full application from the start.Reduced Feature, Due to time boxing, where features are pushed off to later versions in favor of delivering an application in a short time frame, RAD may produce applications that are less full featured than traditionally developed applications. This concern should be addressed as soon as possible through clear communication with the client as to what will be delivered and when.Various RAD (Rapid Application Development) Methodologies TA \l "Various RAD (Rapid Application Development) Methodologies" \s "Various RAD (Rapid Application Development) Methodologies" \c 1 Different types of RAD development methodologies and utilize a selected method for a small project life cycle.Agile Software Development TA \l "Agile Software Development" \s "Agile Software Development" \c 1 Agile software development methods attempt to offer once again an answer to the eager business community asking for lighter weight along with faster and nimbler software development processes. This is especially the case with the rapidly growing and volatile Interact software industry as well as with the emerging mobile application environment application. Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. Agile methods break tasks into small increments with minimal planning, and do not directly involve long-term planning. Iterations are short time frames ("time boxes") that typically last from one to four weeks. All iterations involves a team working through a full software development cycle including planning, requirements analysis, design, coding, unit testing, and acceptance testing when a working product is demonstrated to stakeholders. This helps minimize overall risk, and lets the project adapt to changes quickly. Stakeholders produce documentation as required. Iteration may not add enough functionality to warrant a market release, but the goal is to have an available release (with minimal bugs) at the end of iteration. An agile software project intends to be capable of releasing new software at the end of iteration. At the end of iteration, the team reevaluates project priorities. Multiple iterations may be required to release a product or new features. Team composition in an agile project is usually cross functional and self-organizing without consideration for any existing corporate hierarchy or the corporate roles of team members. Team members normally take responsibility for tasks that deliver the functionality iteration requires. Agile methods emphasize real-time communication, preferably face-to-face, over written documents. Most agile teams are located in a bullpen and include all the people necessary to finish the software. At a minimum, this includes programmers and the people who define the product such as product managers, business analysts, or actual customers. The bullpen may also include testers, interface designers, technical writers, and management. Agile methods also emphasize working software as the primary measure of progress. An Introduction to Agile Software development ProcessStudies have shown that traditional plan driven software development methodologies are not used in practice. It has been argued that traditional methodologies are too mechanistic to be used in detail. As a result, industrial software developers have become skeptical about new solutions that are difficult to grasp and thus remain unused. Agile software development methods, “officially” started with publication of the agile manifesto, make an attempt to bring about a paradigm shift in the field of software engineering. Agile methods claim to place more emphasis on people, interaction, working software, customer collaboration, and change, rather than on processes, tool, contract and plans. A number of promising new methodologies claiming conformance to these agile principles have been introduced. Yet, no systematic review of the agile methods has been attempted [1].Agile methods: Embracing ChangeAgile methods stress productivity and values over heavyweight process overhead and artifacts. The Agile Manifesto [3], a concise summary of agile values, was written and signed in 2001 although agile methods have existed since the early 90s. Agile methods promote an iterative mechanism for producing software, and they further increase the iterative nature of the software lifecycle by tightening design-code-test loop to at least once a day (if not much more frequently) as opposed to once per iteration [2].Real Life Examples of Agile Development processA man was hanging Christmas lights and found a way to incorporate test driven development (TDD) and continuous integration (CI) into putting up the lights.? He put up his lights, then turned them on and found he had a problem. Here he had broken the first rule of agile development - Test First! Of course, any reasonably competent handyman would have known to try plugging in each strand of lights before beginning the life-threatening task of suspending them from the roof - right?Case study on Agile Development MethodsBased on industrial data from one company (Bitonic Solutions Inc. ), a comparison in the productivity of agile methods with more conventional approaches have been done. Bitonic was using ad-hoc OO software development practices (use cases, UML design, etc.) before adopting agile development techniques. Besides switching to lightweight approaches in 2001, the company context stayed more or less stable over the timeframe providing the data for investigation: the data was gathered from work for the same client on the same product and the team was stable over the time when agile approaches were introduced [9].Results5 releases were developed using agile practices, 9 releases followed their original process, 2 releases were in the transition phase and were excluded when we computed the average results below.The results indicate strong productivity increases after adopting agile practices. If productivity is defined based on number of features delivered to the customer, productivity decreases are visible after adopting agile development methods. The summary of the discussion is that Bitonic is now addressing much more complicated features than in the beginning of the project and, hence, would argue that a 4.96% decrease in the number of features delivered to the customer per hour in fact is an increase of their development productivity.Advantages of Agile Software Development ProcessThere are lot of advantages which come along Agile Software Development, following are list of some of them [4].One huge advantage of Agile Development over all other processes is that it emphasizes on testing as early as possible and as thorough as possible. Revenue, The iterative nature of agile development means features are delivered incrementally, enabling some benefits to be realized early as the product continues to develop.Speed-to-market, Research suggests about 80% of all market leaders were first to market. As well as the higher revenue from incremental delivery, agile development philosophy also supports the notion of early and regular releases, and 'perpetual beta. Quality, A key principle of agile development is that testing is integrated throughout the lifecycle, enabling regular inspection of the working product as it develops. This allows the product owner to make adjustments if necessary and gives the product team early sight of any quality issues.Visibility, Agile development principles encourage active 'user' involvement throughout the product's development and a very cooperative collaborative approach. This provides excellent visibility for key stakeholders, both of the project's progress and of the product itself, which in turn helps to ensure that expectations are effectively managed.Risk Management, Small incremental releases made visible to the product owner and product team through its development help to identify any issues early and make it easier to respond to change. The clear visibility in agile development helps to ensure that any necessary decisions can be taken at the earliest possible opportunity, while there's still time to make a material difference to the outcome.Flexibility / Agility, In traditional development projects, we write a big spec up-front and then tell business owners how expensive it is to change anything, particularly as the project goes on. In fear of scope creep and a never-ending project, we resist changes and put people through a change control committee to keep them to the essential minimum. Agile development principles are different. In agile development, change is accepted. In fact, it's expected. Because the one thing that's certain in life is change. Instead the timescale is fixed and requirements emerge and evolve as the product is developed. Of course for this to work, it's imperative to have an actively involved stakeholder who understands this concept and makes the necessary trade-off decisions, trading existing scope for new. Cost Control, The above approach of fixed timescales and evolving requirements enables a fixed budget. The scope of the product and its features are variable, rather than the cost.Business Engagement/Customer Satisfaction, The active involvement of a user representative and/or product owner, the high visibility of the product and progress, and the flexibility to change when change is needed, creates much better business engagement and customer satisfaction. This is an important benefit that can create much more positive and enduring working relationships.Right Product, Above all other points, the ability for agile development requirements to emerge and evolve, and the ability to embrace change (with the appropriate trade-offs), the team builds the right product. It's all too common in more traditional projects to deliver a "successful" project in IT terms and find that the product is not what was expected, needed or hoped for. In agile development, the emphasis is absolutely on building the right product. More Enjoyable, Active involvement, cooperation and collaboration make agile development team, a much more enjoyable place for most people. Instead of big specs, we discuss requirements in workshops. Instead of lengthy status reports, we collaborate around a task-board discussing progress. Instead of long project plans and change management committees, we discuss what's right for the product and project and the team is empowered to make decisions. In my experience this makes it a much more rewarding approach for everyone. In turn this helps to create highly motivated, high performance teams that are highly cooperative.Disadvantages of Agile Software Development ProcessThere are several advantages and disadvantages for any development process. Here are some of the disadvantages behind Agile software development process [4].Active user involvement and close collaboration are required throughout the development cycle. This is very engaging, rewarding and ensures delivery of the right product. It's the fundamental principle in agile that ensures expectations are well managed. And since the definition of failure is not meeting expectations, these are critical success factors for any project. However these principles are very demanding on the user representative's time and require a big commitment for the duration of the project.Requirements emerge and evolve throughout the development. This creates the very meaning of agile - flexibility. Flexibility to change course as needed and to ensure delivery of the right product. There are two big flip sides to this principle though. One is the potential for scope creep, which we all know can create the risk of ever-lasting projects. The other is that there is much less predictability, at the start of the project and during, about what the project is actually going to deliver. This can make it harder to define a business case for the project, and harder to negotiate fixed price projects. Without the maturity of a strong and clear vision, and the discipline of fixing timescales and trading scope, this is potentially very dangerous.Agile requirements are barely sufficient. This eliminates wasted effort on deliverables that don't last (i.e. aren't part of the finished product), which saves time and therefore money. Requirements are clarified just in time for development and can be documented in much less detail due to the timeliness of conversations. However this can mean less information available to new starters in the team about features and how they should work. It can also create potential misunderstandings if the teamwork and communication aren't at their best, and difficulties for team members (especially testers) that are used to everything being defined up front. The belief in agile is that it's quicker to refractor the product along the way than to try to define everything completely up front, which arguably is impossible. And this risk is managed closely through the incremental approach to development and frequent delivery of product.Testing is integrated throughout the lifecycle. This helps to ensure quality throughout the project without the need for a lengthy and unpredictable test phase at the end of the project. However it does imply that testers are needed throughout the project and this effectively increases the cost of resources on the project. This does have the effect of reducing some very significant risks that have proven through research to cause many projects to fail. The cost of a long and unpredictable test phase can, in my experience of waterfall, cause huge unexpected costs when a project over-runs. However there is an additional cost to the project to adopt continuous testing throughout.Frequent delivery of product and the need to sign off each feature as done before moving on to the next makes UAT (user acceptance testing) continuous and therefore potentially quite onerous. The users or product owner needs to be ready and available for prompt testing of the features as they are delivered and throughout the entire duration of the project. This can be quite time-consuming but helps drastically to ensure a quality product that meets user expectations.Finally, common feedback is that agile development is rather intense for developers. The need to really complete each feature 100% within iteration, and the relentlessness of iterations, can be mentally quite tiring so it's important to find a sustainable pace for the team.Joint Application Development (JAD) TA \l "Joint Application Development (JAD)" \s "Joint Application Development (JAD)" \c 1 JAD (Joint Application Development) is a methodology that involves the client or end user in the design and development of an application, through a succession of collaborative workshops called JAD sessions. The JAD approach, in comparison with the more traditional practice, is thought to lead to faster development times and greater client satisfaction, because the client is involved throughout the development process. In comparison, in the traditional approach to systems development, the developer investigates the system requirements and develops an application, with client input consisting of a series of interviews. Joint Application Development (JAD) is a process used in the Systems Development Life Cycle (SDLC) to collect business requirements while developing new information systems for a company. "The JAD process also includes approaches for enhancing user participation, expediting development, and improving the quality of specifications." It consists of a workshop where “knowledge workers and IT specialists meet, sometimes for several days, to define and review the business requirements for the system [5].” The attendees include high level management officials who will ensure the product provides the needed reports and information at the end. This acts as “a management process, which allows Corporate Information Services (IS) departments to work more effectively with users in a shorter time frame [6].”Basic Components of JAD sessionFigure 2, shows various components of JAD session. The descriptions of these basic components of JAD session are listed below [8]: Executive Sponsor: The executive who charters the project, the system owner. They must be high enough in the organization to be able to make decisions and provide the necessary resources and support for the project. They might attend the opening and closing session.PROJECT Leader/manager: Generally the leader of the application development team answers questions about the project regarding scope, time, coordination issues and resources. They may contribute to the sessions as long as they do not inhibit the participants.FACILITATOR/SESSION LEADER: Chairs the meeting and directs traffic by keeping the group on the meeting agenda. The facilitator is responsible for identifying those issues that can be solved as part of the meeting and those which need to be assigned at the end of the meeting for follow-up investigation and resolution. The facilitator serves the participants and does not contribute information to the meeting.Scribe/Modeler/Recorder/Documentation Expert: Records and publish the proceedings of the meeting and does not contribute information to the meeting.PARTICIPANTS: Customers in the business area directly or indirectly being affected by this project, who are experts in their field and can make decisions about their work. They are the source of the input to the session.OBSERVERS: Generally members of the application development team assigned to the project. They are to sit behind the participants and are to silently observe the proceedings.Figure 2: A typical JAD meeting roomSteps in Performing JADThere are 9 key steps in performing JAD process [7] 1. Identify project objectives and limitations it is vital to have clear objectives for the workshop and for the project as a whole. The pre-workshop activities, the planning and scoping, set the expectations of the workshop sponsors and participants. Scoping identifies the business functions that are within the scope of the project. It also tries to assess both the project design and implementation complexity. The political sensitivity of the project should be assessed. Has this been tried in the past? How many false starts were there? How many implementation failures were there? Sizing is important. For best results, systems projects should be sized so that a complete design - right down to screens and menus - can be designed in 8 to 10 workshop days. 2. Identify critical success factors, it is important to identify the critical success factors for both the development project and the business function being studied. How will we know that the planned changes have been effective? How will success be measured? Planning for outcomes assessment helps us judge the effectiveness and the quality of the implemented system over its entire operational life. 3. Define project deliverables, in general, the deliverables from a workshop are documentation and a design. It is important to define the form and level of detail of the workshop documentation. What types of diagrams will be provided? What type or form of narrative will be supplied? It is a good idea to start using a CASE tool for diagramming support right from the start. Most of the available tools have well to great diagramming capabilities but their narrative support is generally weak. The narrative is best produced with your standard word processing software. 4. Define the schedule of workshop activities, Workshops vary in length from one to five days. The initial workshop for a project should not be less than three days. It takes the participants most of the first day to get comfortable with their roles, with each other, and with the environment. The second day is spent learning to understand each other and developing a common language with which to communicate issues and concerns. By the third day, everyone is working together on the problem and real productivity is achieved. After the initial workshop, the team building has been done. Shorter workshops can be scheduled for subsequent phases of the project, for instance, to verify a prototype. However, it will take the participants from one to three hours to re-establish the team psychology of the initial workshop. 5. Select the participants these are the business users, the IS professionals, and the outside experts that will be needed for a successful workshop. These are the true "back bones" of the meeting who will drive the changes. 6. Prepare the workshop material before the workshop, the project manager and the facilitator perform an analysis and build a preliminary design or straw man to focus the workshop. The workshop material consists of documentation, worksheets, diagrams, and even props that will help the participants understand the business function under investigation. 7. Organize workshop activities and exercises, Facilitator must design workshop exercises and activities to provide interim deliverables that build towards the final output of the workshop. The pre-workshop activities help design those workshop exercises. 8. Prepare, inform, and educate the workshop participants, all of the participants in the workshop must be made aware of the objectives and limitations of the project and the expected deliverables of the workshop. Briefing of participants should take place 1 to 5 days before the workshop. This briefing may be teleconferenced if participants are widely dispersed. The briefing document might be called the Familiarization Guide, Briefing Guide, Project Scope Definition, or the Management Definition Guide - or anything else that seems appropriate. It is a document of eight to twelve pages, and it provides a clear definition of the scope of the project for the participants. The briefing itself lasts two to four hours. It provides the psychological preparation everyone needs to move forward into the workshop. 9. Coordinate workshop logistics, Workshops should be held off-site to avoid interruptions. Projectors, screens, PCS, tables, markers, masking tape, Post-It notes, and lots of other props should be prepared. What specific facilities and props are needed is up to the facilitator. They can vary from simple flip charts to electronic white boards. In any case, the layout of the room must promote the communication and interaction of the participants.Example of JAD processFor example, for a Business Area Analysis, what is appropriate? A decomposition diagram, a high-level entity-relationship diagram, A normalized data model, A state transition diagram, A dependency diagram, All of the above, None of the above. It is important to define the level of technical diagramming that is appropriate to the environment. The most important thing about a diagram is that the users must understand it. Once the diagram choice is made, the facilitator designs exercises into the workshop agenda to get the group to develop those diagrams. A workshop combines exercises that are serially oriented to build on one another, and parallel exercises, with each sub-team working on a piece of the problem or working on the same thing for a different functional area. High-intensity exercises led by the facilitator energize the group and direct it towards a specific goal. Low-intensity exercises allow for detailed discussions before decisions. The discussions can involve the total group or teams can work out the issues and present a limited number of suggestions for the whole group to consider. To integrate the participants, the facilitator can match people with similar expertise from different departments. To help participants learn from each other, he can mix the expertise. It's up to the facilitator to mix and match the sub-team members to accomplish the organizational, cultural, and political objectives of the workshop. A workshop operates on both the technical level and the political level. It is the facilitator's job to build consensus and communications, to force issues out early in the process. There is no need to worry about the technical implementation of a system if the underlying business issues cannot be resolved [7].Advantages of JADIf the above guidelines are followed closely, chances are, the JAD will be successful. A successful JAD session should provide these benefits [8]:Reduced system development time, In JAD, information can be obtained and validated in a shorter time frame by involving all participants (or at least a representative set of participants) who have a stake in the outcome of the session. JAD eliminates process delays and has been shown to reduce application development time between 20% to 50%. Improved system quality and productivity, much of the system’s quality depends on the requirements gathered. JAD involves users in the development life cycle, lets users define their requirements, thus ensures that the system developed satisfies the actual activities of the business JAD is quoted the best method for collecting requirements from the users, customers, or customer advocates. Reduced system cost, much of the system development cost is in terms of man-hours of both system developers and business users involved. Reduced development time reduces the labor cost for developers, as well as users. Important process like requirement gathering requires the involvement and commitment of business area experts. The cost of taking them away from their daily operation is very high. JAD can reduce the involvement time of these business experts and hence reduce the cost further. Cost is also reduced by catching errors, misunderstandings and mistakes early in the development phrase. Studies have found that a majority of system errors result from early analysis errors, and the earlier these errors are corrected, the much less they will cost. The JAD sessions let designers and users work together in the very early of the development cycle, defining the scope, requirements of projects, resolving conflicts among different user groups. It put many efforts early in the life cycle in order to improve the quality and increase productivity and to reduce cost. Enhanced communication and relationship, JAD helps in building good relationships between business end-users and IT personnel.Cultivate ownership, Easier acceptance (buy-in) and stronger commitment by users. The involvement of business end-users is no longer on advisory or consultation spectrum. It is the participation and contribution in the project development life cycle. The more users contribute to the system, the easier for them to accept it and commit to it.Reduced function creep, is one of the best ways to reduce function creep, most of which results from poor initial requirements.Enhanced education for participants and observers, By participating in JAD and be the medium between other users and IT, the business end-users will be kept fully informed about the progress of the system development.Disadvantages of JADJAD is very useful development process, but it also has some negative point like as follows:It opens up a lot of scope for inter-personal conflict.More expensive and can be cumbersome.EXTREME PROGRAMMING (XP) TA \l "EXTREME PROGRAMMING (XP)" \s "EXTREME PROGRAMMING (XP)" \c 1 Extreme Programming (XP), the methodology takes its name from the idea that the beneficial elements of traditional software engineering practices are taken to "extreme" levels, on the theory that if some is good, more is better. It is unrelated to "cowboy coding", which is more free-form and unplanned. It does not advocate "death march" work schedules, but instead working at a sustainable pace. XP is a software engineering methodology which is intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development (discuss above), it advocates frequent "releases" in short development cycles (time boxing), which is intended to improve productivity and introduce checkpoints where new customer requirements can be adopted. Other elements of Extreme Programming include: programming in pairs or doing extensive code review, unit testing of all code, avoiding programming of features until they are actually needed, a flat management structure, simplicity and clarity in code, expecting changes in the customer's requirements as time passes and the problem is better understood, and frequent communication with the customer and among programmers. Extreme Programming is successful because it stresses customer satisfaction. Instead of delivering everything you could possibly want on some date far in the future this process delivers the software you need as you need it. Extreme Programming empowers your developers to confidently respond to changing customer requirements, even late in the life cycle. Extreme Programming emphasizes teamwork. Managers, customers, and developers are all equal partners in a collaborative team. Extreme Programming implements a simple, yet effective environment enabling teams to become highly productive. The team self-organizes around the problem to solve it as efficiently as possible. Contrary to what many think, extreme programming has nothing to do with large, difficult, or complex projects. Extreme Programming, or XP, is a lightweight discipline of software development based on principles of simplicity, communication, feedback, and courage. XP is designed for use with small teams who need to develop software quickly in an environment of rapidly-changing requirements. XP PracticesXP can be summed up in twelve “practices” [10], they are described as followThe Planning Process, The XP planning process allows the XP “customer" to define the business value of desired features, and uses cost estimates provided by the programmers, to choose what needs to be done and what needs to be deferred. The effect of XP's planning process is that it is easy to steer the project to success.Small Releases, XP teams put a simple system into production early, and update it frequently on a very short cycle. Every release should be as small as possible containing the most valuable business requirements. Small releases provide the sense of accomplishment that is often missing in big projects.Metaphor, XP teams use a common “system of names" and a common system description that guides development and communication. Metaphors help in making the technology more understandable in human terms, especially to clients. At one level metaphor and architecture are synonyms – they are both intended to provide a broad view of project’s goal. XP uses metaphors in an attempt to define an overall coherent theme to which both developers and business clients can relate.Simple Design, A program built with XP should be the simplest program that meets the current requirements. There is not much building for the “future". Instead, the focus is on providing business value. Of course it is necessary to ensure that you have a good design, and in XP this is brought about through “refactoring”. Simple design has two parts: One, design for the functionality that has been defined; Second, to create a best design that can deliver that functionality.Testing, XP teams focus on validation of the software at all times. Programmers develop software by writing tests first, and then software that fulfills the requirements reflected in the tests. Customers provide acceptance tests that enable them to be certain that the features they need are provided. XP uses two types of testing: unit & functional. Unit testing determine whether a given feature works as intended. A programmer writes as many automated tests as they can think of that might "break" the code; if all tests run successfully, then the coding is complete. Every piece of code that is written is tested before moving on to the next feature. Refactoring, XP teams improve the design of the system throughout the entire development. This is done by keeping the software clean: without duplication, with high communication, simple, yet complete. It is ongoing redesign of software to improve its responsiveness to change.Pair Programming, XP programmers write all production code in pairs, two programmers working together at one machine. Pair programming has been shown by many experiments to produce better software at similar or lower cost than programmers working alone. Pair programming is a software development technique in which two programmers work together at one work station. One types in code while the other reviews each line of code as it is typed in. The person typing is called the driver. The person reviewing the code is called the observer or navigator. The two programmers switch roles frequently (possibly every 30 minutes or less).While reviewing, the observer also considers the strategic direction of the work, coming up with ideas for improvements and likely future problems to address. This frees the driver to focus all of his or her attention on the "tactical" aspects of completing the current task, using the observer as a safety net and guide.Collective Ownership, All the code belongs to all the programmers. This lets the team go at full speed, because when something needs changing, it can be changed without delay. XP provides collective ownership as practice that anyone on the project can change any of the code at any time.Continuous Integration, XP teams integrate and build the software system multiple times per day. This keeps all the programmers on the same page, and enables very rapid progress. Perhaps surprisingly, integrating more frequently tends to eliminate integration problems that plague teams who integrate less often.40-hour Week, Tired programmers make more mistakes. XP teams do not work excessive overtime, keeping them fresh, healthy, and effective. Programmers go home on time. In crunch mode, up to one week of overtime is allowed. But multiple consecutive weeks of overtime are treated as a sign that something is very wrong with the process.On-site Customer, An XP project is steered by a dedicated individual who is empowered to determine requirements, set priorities, and answer questions as the programmers have them. The effect of being there is that communication improves, with less hard-copy documentation - often one of the most expensive parts of a software project. Development team has continuous access to a real live customer, that is, someone who will actually be using the system. For commercial software with lots of customers, a customer proxy (usually the product manager) is used instead.Coding Standard, for a team to work effectively in pairs, and to share ownership of all the code, all the programmers need to write the code in the same way, with rules that make sure the code communicates clearly. XP practices are supportive of each other. For example if you do pair programming and let anyone modify the communal code, then coding standards would need to be necessity.XP Principles Basic Principles, describe below [11]:Rapid Feedback, Extreme Programming sees feedback as most useful if it is done rapidly and expresses that the time between an action and its feedback is critical to learning and making changes. Unlike traditional system development methods, contact with the customer occurs in more frequent iterations. The customer has clear insight into the system that is being developed. He or she can give feedback and steer the development as needed. So whether it’s hourly builds or frequent functionality testing with the customer, XP embraces change by frequent feedback. Whether it’s a fixing an object that failed a test case or refactoring a design that is resisting a change, high change environment requires a much different understanding of feedback. Unit tests also contribute to the rapid feedback principle. When writing code, the unit test provides direct feedback as to how the system reacts to the changes one has made. If, for instance, the changes affect a part of the system that is not in the scope of the programmer who made them, that programmer will not notice the flaw. There is a large chance that this bug will appear when the system is in production.Assume simplicity, XP ask each team member, “What is the simplest thing that could possibly work”. XP believes in making it simple today and create an environment in which the cost of change tomorrow is low. This is about treating every problem as if its solution were "extremely simple". Traditional system development methods say to plan for the future and to code for reusability. Extreme programming rejects these ideas. The advocates of Extreme Programming say that making big changes all at once does not work. Extreme Programming applies incremental changes: for example, a system might have small releases every three weeks. When many little steps are made, the customer has more control over the development process and the system that is being developed.Embracing Change, The principle of embracing change is about not working against changes but embracing them. For instance, if at one of the iterative meetings it appears that the customer's requirements have changed dramatically, programmers are to embrace this and plan the new requirements for the next iteration.XP ValuesCommunication, XP focuses on building person to person, mutual understanding of the problem environment through minimal formal documentation and maximum face to face interaction. Everyone is part of the team and we communicate face - face daily. We will work together on everything from requirements to code. We will create the best solution to our problem that we can together. Building software systems requires communicating system requirements to the developers of the system. In formal software development methodologies, this task is accomplished through documentation. Extreme programming techniques can be viewed as methods for rapidly building and disseminating institutional knowledge among members of a development team. The goal is to give all developers a shared view of the system, which matches the view held by the users of the system. To this end, Extreme Programming favors simple designs, common metaphors, collaboration of users and programmers, frequent verbal communication, and feedback [12].Simplicity, Extreme programming encourages starting with the simplest solution. Extra functionality can then be added later. The difference between this approach and more conventional system development methods is the focus on designing and coding for the needs of today instead of those of tomorrow, next week. This is sometimes summed up as the "you're not going to need it" approach. Proponents of XP acknowledge the disadvantage that this can sometimes entail more effort tomorrow to change the system; their claim is that this is more than compensated for by the advantage of not investing in possible future requirements that might change before they become relevant. Coding and designing for uncertain future requirements implies the risk of spending resources on something that might not be needed. Related to the "communication" value, simplicity in design and coding should improve the quality of communication. Most programmers in the team could easily understand a simple design with very simple code [12]. Feedback?Within Extreme Programming, feedback relates to different dimensions of the system development:Feedback from the system: by writing unit tests, or running periodic integration tests, the programmers have direct feedback from the state of the system after implementing changes. Feedback from the customer: The functional tests (aka acceptance tests) are written by the customer and the testers. They will get concrete feedback about the current state of their system. This review is planned once in every two or three weeks so the customer can easily steer the development. Feedback from the team: When customers come up with new requirements in the planning game the team directly gives an estimation of the time that it will take to implement. Feedback is closely related to communication and simplicity. Flaws in the system are easily communicated by writing a unit test that proves a certain piece of code will break. The direct feedback from the system tells programmers to recode this part. A customer is able to test the system periodically according to the functional requirements, known as user stories [12]. CourageSeveral practices embody courage. One is the commandment to always design and code for today and not for tomorrow. This is an effort to avoid getting bogged down in design and requiring a lot of effort to implement anything else. Courage enables developers to feel comfortable with refactoring their code when necessary. This means reviewing the existing system and modifying it so that future changes can be implemented more easily. Another example of courage knows when to throw code away: courage to remove source code that is obsolete, no matter how much effort was used to create that source code. Also, courage means persistence: A programmer might be stuck on a complex problem for an entire day, then solve the problem quickly the next day, if only they are persistent.RespectThe respect value manifests in several ways. In Extreme Programming, team members respect each other because programmers should never commit changes that break compilation, that make existing unit-tests fail, or that otherwise delay the work of their peers. Members respect their work by always striving for high quality and seeking for the best design for the solution at hand through refactoring. Adopting the four earlier values leads to respect gained from others in the team. Nobody on the team should feel unappreciated or ignored. This ensures high level of motivation and encourages loyalty toward the team, and the goal of the project. This value is very dependent upon the other values, and is very much oriented toward people in a team [12].XP ActivitiesThe four basic activities of Extreme Programming are:Coding, You code because if you don't code, at the end of the day you haven't done anything. XP says that the only truly important product of the system development process is code. Without code you have nothing. Coding can be drawing diagrams that will generate code, scripting a web-based system or coding a program that needs to be compile d. Coding can also be used to figure out the most suitable solution. For instance, XP would advocate that faced with several alternatives for a programming problem, one should simply code all solutions and determine with automated tests (see below) which solution is most suitable. Coding can also help to communicate thoughts about programming problems. A programmer dealing with a complex programming problem and finding it hard to explain the solution to fellow programmers might code it and use the code to demonstrate what he or she means.Testing, You test because if you don't test, you don't know when you are done coding. One cannot be certain of anything unless one has tested it. Testing is not a perceived, primary need for the customer. A lot of software is shipped without proper testing and still works (more or less). In software development, XP says this means that one cannot be certain that a function works unless one tests it. You can be uncertain whether what you coded is what you meant. To test this uncertainty, XP uses Unit Tests. These are automated tests that test the code. The programmer will try to write as many tests he or she can think of that might break the code he or she is writing; if all tests run successfully then the coding is complete. You can be uncertain whether what you meant is what you should have meant. To test this uncertainty, XP uses acceptance tests based on the requirements given by the customer in the exploration phase of release planning.Listening, You listen because if you don't listen you don't know what to code or what to test. Programmers do not necessarily know anything about the business side of the system under development. The business side determines the function of the system. For the programmers to find what the functionality of the system should be, they have to listen to business. Programmers have to listen to what the customer needs. Also, they have to try to understand the business problem, and to give the customer feedback about his or her problem, to improve the customer's own understanding of his or her problem. Communication between the customer and programmer is further addressed in The Planning Game.Designing, and you design so you can keep coding and testing and listening indefinitely (good design allows extension of the system with changes in only one place). From the point of view of simplicity, one could say that system development doesn't need more than coding, testing and listening. If those activities are performed well, the result should always be a system that works. In practice, this will not work. One can come a long way without designing but at a given time one will get stuck. The system becomes too complex and the dependencies within the system cease to be clear. One can avoid this by creating a design structure that organizes the logic in the system. Good design will avoid lots of dependencies within a system; this means that changing one part of the system will not affect other parts of the system. Figure 3 Describes flow chart of XPFigure 3 shows how Extreme Programming's rules work together. Customers enjoy being partners in the software process, developers actively contribute regardless of experience level, and managers concentrate on communication and relationships. Unproductive activities have been trimmed to reduce costs and frustration of everyone involved.Examples on Extreme ProgrammingA longitudinal case study evaluating the effects of adopting the Extreme Programming (XP) methodology was performed at Sabre Airline Solutions?. The Sabre team was a characteristically agile team in that they had no need to scale or re-scope XP for their project parameters and organizational environment. The case study compares two releases of the same product. One release was completed just prior to the team’s adoption of the XP methodology, and the other was completed after approximately two years of XP use [13]. ResultsComparisons of the new release project results to the old release project results show a 50% increase in productivity, a 65% improvement in pre-release quality, and a 35% improvement in post-release quality. These findings suggest that, over time, adopting the XP process can result in increased productivity and quality [13].Advantages of XP (Extreme Programming)Customer focus, Customer focus increase the chance that the software produced will actually meet the needs of the usersDecrease Risk, The focus on small, incremental release decreases the risk on your project: by showing that your approach works and by putting functionality in the hands of your users, enabling them to provide timely feedback regarding your work. Testing, Continuous testing and integration helps to increase the quality of work.NO Process, XP is attractive to programmers who normally are unwilling to adopt a software process, enabling your organization to manage its software efforts better.For developers, XP allows you to focus on coding and avoid needless paperwork and meetings. It provides a more social atmosphere, more opportunities to learn new skills, and a chance to go home at a decent time each night. It gives you very frequent feelings of achievement, and generally allows you to produce code that you feel good about.For the Customer, XP creates working software faster, and that software tends to have very few defects. It allows you to change your mind whenever you need to, with minimal cost and almost no complaining from the developers. It produces reliable estimates so you can coordinate your schedule easier.For management, XP delivers working software for less money, and the software is more likely to do what the end users actually want. It cuts risk in a couple ways: 1) It allows you to "pull the plug" on development at almost any time, and still have highly valuable code, and probably even a valuable working (if incomplete) application. 2) It reduces your dependence on individual superstars, and at the same time can improve employee satisfaction and retention.Disadvantages (XP Extreme Programming)XP is geared toward a single project, developed and maintained by a single team.XP will not work in an environment where a customer or manager insists on a complete specification or design before they begin programming.XP will not work in an environment where programmers are separated geographically. XP has not been proven to work with systems that have scalability issues (new applications must integrate into existing systems).The biggest disadvantage: Extreme Programming is hard to do. It's difficult to get many developers to accept the practices, and it takes a lot of discipline to keep doing them all. Customers may not like the idea of having to be so involved. Management may have trouble adapting to a process that, itself, adapts to the changing needs of the business.XP calls for a family of new management methods but does not provide the management training and guidance needed for these methods to be accepted and effectively practiced.Scrum Development Process TA \l "Scrum Development Process" \s "Scrum Development Process" \c 1 Scrum is an iterative incremental framework for managing complex work (such as new product development) commonly used with agile software development. Although Scrum was intended for management of software development projects, it can be used to run software maintenance teams, or as a general project/program management approach. The stated, accepted philosophy for systems development is that the development process is a well-understood approach that can be planned, estimated, and successfully completed. This has proven incorrect in practice. SCRUM assumes that the systems development process is an unpredictable, complicated process that can only be roughly described as an overall progression. SCRUM defines the systems development process as a loose set of activities that combines known, workable tools and techniques with the best that a development team can devise to build systems. Since these activities are loose, controls to manage the process and inherent risk are used. SCRUM is an enhancement of the commonly used iterative/incremental object-oriented development cycle [14].Figure 4 Scrum developments ProcessArtifacts of Scrum Process Product backlog (Figure 4), the product backlog is a high-level document for the entire project. It contains backlog items: broad descriptions of all required features, wish-list items, etc. prioritized by business value. It is the "What" that will be built. It is open and editable by anyone and contains rough estimates of both business value and development effort. Those estimates help the Product Owner to gauge the timeline and, to a limited extent, priority. For example, if the "add spell-check" and "add table support" features have the same business value, the one with the smallest development effort will probably have higher priority, because the Rate of interest (ROI) is higher. The product backlog is property of the Product Owner. The Product Owner sets business value. Development effort is set by the Team [15].Sprint backlog (Figure 4), the sprint backlog is a document containing information about how the team is going to implement the features for the upcoming sprint. Features are broken down into tasks; as a best practice, tasks are normally estimated between four and sixteen hours of work. With this level of detail the whole team understands exactly what to do and anyone can potentially pick a task from the list. Tasks on the sprint backlog are never assigned; rather, tasks are signed up for by the team members as needed, according to the set priority and the team member skills. The sprint backlog is property of the Team. Estimations are set by the Team. Burn down, the Sprint burn down chart is a publicly displayed chart showing remaining work in the sprint backlog. Updated every day, it gives a simple view of the sprint progress. It also provides quick visualizations for reference. There are also other types of burn down, for example the Release Burn down Chart that shows the amount of work left to complete the target commitment for a Product Release (normally spanning through multiple iterations) and the Alternative Release Burn down Chart, which basically does the same, but allows to show clearly scope changes into a Release Content, by resetting the baseline.RolesThe Scrum team performs the actual work of problem solvers and designers. The team normally consists of 5-9 people – a group size that experience and research has shown to be best for this type of work. T he team members decide how the work is arranged and how assignments are distributed. There are no set project roles – everyone should be able to swap tasks with another member. Naturally, this does not prevent individual members from being experts in a field [15].Product owner represents the voice of the customer and ensures that the Scrum Team works with the right things from a business perspective. The Product Owner administers a Product Backlog – a current to-do list where all the specifications for a product are listed according to how profitable they are deemed to be. The document is visible to the entire organization so that everyone is aware of what to expect in future releases of the product. The Product Owner is often a customer, but can also be part of the internal organization. The task requires comprehensive knowledge about engineering, marketing and business processes.Scrum master is a combination of coach, fixer and gatekeeper. The Scrum Master meets with the team every day in brief meetings, Daily Scrums. When someone outside the project has an important issue to discuss with the team, the Scrum Master tries to ensure that the designers are disturbed as little as possible in their work. The Scrum Master always adopts a here and-now perspective to the work. The focus is always on providing the team with the best possible circumstances for realizing the goals fixed for the Sprint. After each Sprint, the Scrum Master holds an Evaluation Meeting with the Scrum team – a Sprint Retrospective – during which experiences and conclusions are reviewed. The purpose is to elevate the team’s level of knowledge and heighten motivation prior to the next Sprint.PROCESSCreating a backlogThe Product Owner compiles all the requests and specifications that are the basis of the changes of the product, such as new functions and bug fixes. After the goals have been defined, the entirety is broken down into segments. Each such segment should in part create business value and in part be sub-deliverable. A prioritized list is made at the same time – the Product Owner personally makes the decisions at this point. In what order should the changes be made and delivered? The result is a to-do list arranged according to how the market’s demands and customer’s requests change over time. When it is time to start a new Sprint, the Product Owner “freezes” the foremost items on the to-do list and summons the Scrum Team to a meeting [15].The sprint phaseOf the Sprint’s 30 calendar days, the first are set aside to create a Sprint Backlog. When the tasks and required time has been determined, the Product Owner lets go. As of now the Scrum Team works under its own responsibility. If the group has been properly composed, the work will be self organizing.Daily ScrumEvery day, at the same time, the Scrum Master and the Scrum Team have a brief meeting. The purpose is to eliminate all speed impediments for the group. Each of the participants should in some way answer three questions [15]:? What have you done since the last meeting?? What will you do between now and the next meeting?? Is there anything preventing you from doing what you have planned?The first two questions give the meeting participants full insight into how the project is progressing. The third question provides a basis for problem solving – ranging from a new computer mouse to organizational changes at the company. Anyone may attend and listen at the meeting, but only the Scrum Master and the team members may speak.Scrum CharacteristicsSCRUM projects have the following characteristics [14]:Flexible deliverable, the content of the deliverable is dictated by the environment.Flexible schedule, the deliverable may be required sooner or later than initially planned.Small teams, each team has no more than 6 members. There may be multiple teams within a project.Frequent reviews, team progress is reviewed as frequently as environmental complexity and risk dictates (usually 1 to 4 week cycles). A functional executable must be prepared by each team for each review.Collaboration, intra and inter-collaboration is expected during the project.Object Oriented, each team will address a set of related objects, with clear interfaces and behavior.SCRUM MethodologyThe system development process is complicated and complex. Therefore maximum flexibility and appropriate control is required. Evolution favors those that operate with maximum exposure to environmental change and have optimized for flexible adaptation to change. Evolution deselects those who have insulated themselves from environmental change and have minimized chaos and complexity in their environment. An approach is needed that enables development teams to operate adaptively within a complex environment using imprecise processes. Complex system development occurs under rapidly changing circumstances. Producing orderly systems under chaotic circumstances requires maximum flexibility. The closer the development team operates to the edge of chaos, while still maintaining order, the more competitive and useful the resulting system will be. Langton has modeled this effect in computer simulations and his work has provided this as a fundamental theorem in complexity theory. Methodology may well be the most important factor in determining the probability of success [14]. Methodologies that encourage and support flexibility have a high degree of tolerance for changes in other variables. With these methodologies, the development process is regarded as unpredictable at the onset, and control mechanisms are put in place to manage the unpredictability.Figure5. SCRUM Methodology [14]Characteristics of SCRUM Methodology are: ? First and last phases (Planning and Closure) consist of defined processes, where all processes, inputs and outputs are well defined. The knowledge of how to do these processes is explicit. The flow is linear, with some iteration in the planning phase. ? The Sprint phase is an empirical process. Many of the processes in the sprint phase are unidentified or uncontrolled. It is treated as a black box that requires external controls. Accordingly, controls, including risk management, are put on iteration of the Sprint phase to avoid chaos while maximizing flexibility. ? Sprints are nonlinear and flexible. Where available, explicit process knowledge is used; otherwise tacit knowledge and trial and error is used to build process knowledge. Sprints are used to evolve the final product. ? Project is open to the environment until the Closure phase. The deliverable can be changed at any time during the Planning and Sprint phases of the project. The project remains open to environmental complexity, including competitive, time, quality, and financial pressures, throughout these phases.? Deliverable is determined during the project based on the environment. Case StudyIn July 2007, a Senior Engineer from the then new Events 2.0 project team recommended implementing development using the Scrum approach. Although we were enthusiastic, we were not prepared. As is typical for XING, we quickly sought out an available Scrum Master and began our Scrum experiment.ResultsOur conclusion so far: Introducing Scrum is not easy and requires substantial modifications to the organization and product development processes. For us, it has already paid off because of the capability to react quickly and adeptly to dynamic requirements on our platform and better usage of our skill potentials. We feel well prepared as we look to the future.AdvantagesThere many advantages of using Scrum in an organization some of them are listed below [14]:Traditional development methodologies are designed only to respond to the unpredictability of the external and development environments at the start of an enhancement cycle. Such newer approaches as the Boehm spiral methodology and its variants are still limited in their ability to respond to changing requirements once the project has started. The SCRUM methodology, on the other hand, is designed to be quite flexible throughout. It provides control mechanisms for planning a product release and then managing variables as the project progresses. This enables organizations to change the project and deliverables at any point in time, delivering the most appropriate release.The SCRUM methodology frees developers to devise the most ingenious solutions throughout the project, as learning occurs and the environment changes.Small, collaborative teams of developers are able to share tacit knowledge about development processes. An excellent training environment for all parties is provided.Object oriented technology provides the basis for the SCRUM methodology. Objects, or product features, offer a discrete and manageable environment. Procedural code, with its many and intertwined interfaces, is inappropriate for the SCRUM methodology. SCRUM may be selectively applied to procedural systems with clean interfaces and strong data orientation.DisadvantagesEvery development process has some advantages and some disadvantages, so here we are mentioning some of the downside of using Scrum:Scrum is not effective for small projectsExpensive to implementTraining is requiredScrum also means you have to be in close contact with your external stakeholders so all-important things are on your backlog. This is not always feasible and may delay or upset them.Lean software development (LD) TA \l "Lean software development (LD)" \s "Lean software development (LD)" \c 1 “Lean technology is a philosophy of making a conscious choice to radically redefine and dynamically optimize strategy, systems, processes and services and add value to clients, employees and shareholders”. Lean software development is a translation of lean manufacturing principles and practices to the software development domain. . Adapted from the Toyota Production System, a pro-lean subculture is emerging from within the agile Software development community. Lean manufacturing or lean production, which is often known simply as "Lean", is a production practice that considers the expenditure of resources for any goal other than the creation of value for the end customer to be wasteful, and thus a target for elimination. They may be clearly identified, but are poorly acknowledged. The problems of the software development planet are responsible for most of the project failures that force managements worldwide to put more rigid processes in place to ensure compliance. More stringent processes at each stage are making the whole process a “Concrete-Life jacket”. By using Lean Production/Manufacturing principles not only quality concerns and other issues can be resolved, but also a continuous improvement cycle can be built in to the process. This can help in improving the quality of the software solutions/products each time a new software solution/product is built [17]. In software industry, developers often say, “Life would be so much easier if customers would just stop changing their minds”. In fact, there is a very easy way to keep customers from changing their minds – give them what they ask for so fast that they don’t have the time to change their minds. The idea behind lean thinking is exactly this, let customers delay their decisions about exactly what they want as long as possible, and when they ask for something, give it to them so fast they don’t have time to change their minds. The way to deliver things rapidly is to deliver them in small packages. The bigger the increment of functionality you try to deliver, the longer it takes to decide what is needed and then get it developed, tested, and deployed. Maintenance programmers have known this for years. When a piece of production code breaks, they find the cause, create a patch, test it rigorously, and release it to production – usually in the space of a few hours or days [16].Principles of Lean Software Development ProcessThere are seven principles of Lean Software Development, drawn from the seven principles of Lean Thinking. These principles are not cookbook recipes for software development, but guideposts for devising appropriate practices for your environment.Eliminate waste The first step in lean thinking is to understand what “value” is and what activities and resources are absolutely necessary to create the value. Since no one wants to consider what they do as waste, the job of determining what value is and what adds value is something that needs to be done at a fairly high level. All lean thinking starts with a re-examination of what waste is and an aggressive campaign to eliminate it. Quite simply, anything you do that does not add value from the customer perspective is waste. The seven wastes of software development are [16]: → Partially Done Work (the “inventory” of a development process) → Extra Processes (easy to find in documentation-centric development) → Extra Features (develop only what customers want right now) → Task Switching (everyone should do one thing at a time) → waiting (for instructions, for information) → Handoffs (tons of tacit knowledge gets lost) → Defects (at least defects that are not quickly caught by a test) Amplify learningSoftware development is a continuous learning process with the additional challenge of development teams and end product sizes. The best approach for improving a software development environment is to amplify learning. Running tests as soon as the code is written should prevent the accumulation of defects. Instead of adding more documentation or detailed planning, different ideas could be tried by writing code and building. Presenting screens to the end-users and getting their input could simplify the process of user requirements gathering. The learning process is sped up by usage of short iteration cycles – each one coupled with refactoring and integration testing. Increasing feedback via short feedback sessions with Customers helps when determining the current phase of development and adjusting efforts for future improvements. During those short sessions both Customer representatives and the development team learn more about the domain problem and figure out possible solutions for further development. Thus the Customers better understand their needs, based on the existing result of development efforts, and the developers learn how to better satisfy those needs. Another idea in the communication and learning process with a Customer is set-based development – this concentrates on communicating the constraints of the future solution and not the possible solutions, thus promoting the birth of the solution via dialog with the Customer.Empower those who add value A basic principle of Lean Production is to drive decisions down to the lowest possible level, delegating decision-making tools and authority to the people "on the floor." Often when software development environments under-perform, the instinctive reaction is to impose more rigid processes, specifying in greater detail how people should do their jobs. Lean Production principles suggest exactly the opposite approach. When there are problems in manufacturing, a team of outside experts is not sent in to document in more detail how the process should be run. Instead, people on the manufacturing floor are given tools to evaluate and improve their own areas. They work in collaborative teams with the charter to improve their own processes and the links to nearby processes for which they are suppliers or customers. Their supervisors are trained in methods of forming and encouraging work teams to solve their own. Another mistaken belief has been the consideration of people as resources. People might be resources from the point of view of a statistical data sheet, but in software development, as well as any organizational business, people do need something more than just the list of tasks and the assurance that they will not be disturbed during the completion of the tasks. People need motivation and a higher purpose to work for – purpose within the reachable reality, with the assurance that the team might choose its own commitments. The developers should be given access to Customer; the team leader should provide support and help in difficult situations, as well as make sure that skepticism does not ruin the team’s spirit [17]. Build Integrity InThere are two kinds of integrity – perceived integrity and conceptual integrity. Software with perceived integrity delights the customer – it’s exactly what they want even though they didn’t know how to ask for it. Conceptual integrity means that all of the parts of a software system work together to achieve a smooth, well functioning whole. Software with conceptual integrity presents the user with a single metaphor of how a task is to be done. You don’t have one way of buying airline tickets if you are paying with cash and a totally different way if you are using frequent flier miles. You don’t use kilometers in one module and miles in another. Conceptual integrity is achieved through continuous, detailed information flow between various technical people working on a system. There is only one way to achieve this, people have to talk to each other, early and often. There can be no throwing things over the wall, no lines between supplier, development team, support team, customer. Everyone should be involved in detailed discussions of the design as it develops, from the earliest days of the program [17].Deliver as fast as possibleThe goal is to let your customer take an options-based approach to making decisions, letting them delay their decisions a long as possible so they can make decisions based on the best possible information. Once your customers decide what they want, your goal should be to create that value just as fast as possible. This means no delay in deciding what requests to approve, no delay in staffing, immediate clarification of requirements, no time-consuming handoffs, no delay in testing, no delay for integration, no delay in deployment. In a mature software development organization, all of this happens in one smooth, rapid flow in response to a customer need.Maximizing flowIn lean software development, the idea is to maximize the flow of information and delivered value. In lean production, Maximizing flow does not mean automation. Instead it means limiting what has to be transferred, and transferring that as few times as possible over the shortest distance with the widest communication bandwidth. Similarly in software development the idea is to eliminate as many documents and handoffs as possible. In the lean software development emphasis is to pair a skilled development team with a skilled customer team and to give them the responsibility and authority to develop the system in small, rapid increments, driven by the customer priority and feedback.Delay CommitmentDelaying commitment means keeping your options open as long as possible. The fundamental lean concept is to delay irreversible decisions until they can be made based on known events, rather than forecasts. Economic markets develop options as a way to deal with uncertainty.See the WholeWhen you look at them closely, most theories of how to manage software projects are based on a theory of disaggregation: break the whole into individual parts and optimize each one. Lean thinking suggests that optimizing individual parts almost always leads to sub-optimized overall system. The best way to avoid sub-optimization and encourage collaboration is to make people accountable for what they can influence, not just what they can control. This means measuring performance one level higher than you would expect. Measure the team’s defect count, not that of individuals. Make testing as accountable for defect- free code as developers. To some it seems unfair to hold a team accountable for individual performance, but lean organizations have found that individuals are rarely able to change the system which influences their performance. However a team, working together and responsible for its own processes, can and will make dramatic improvements. Case studyDevelop a small business loan processing system in twelve months with minimum initial investment. Factors such as meeting international requirements, a technology base that was new to the company, and utilizing an internationally dispersed work force added to the complexity of the project. This company abandoned the time tested waterfall development approach and embraced new Lean Software Development principles. Small cross functional teams including end-users were created, trained and empowered to deliver the end product in incremental phases called iterations. Adopting new techniques necessitated changes to the traditional project management, tracking and reporting [19]. ResultsWithin three months the team delivered the first functional system for user acceptance testing. Thereafter monthly iterations were delivered to expand the features and capabilities of the system. The full feature set was delivered within the twelve-month period and maintained the original budget. Development time and initial investment was reduced by over 50% compared to similar products [19].AdvantagesOrganizations that understood and applied lean values, principles, and processes have experienced very significant benefits such as the following: Lead time reduction of up to 75% On time delivery rate up to 100% Productivity improvements of over 80% Scrap reductions of up to 95% Space utilization improvements of over 25% Set-up time reductions of over 85% Machine down time reductions of 70% Total project time reduced by 70-90% Project rework reduced by 60-90% Project costs reduced by 50-70% Customer Focus, Waste is anything that does not provide timely customer value.? Have you identified who your customers are?? Do you know what these customers really want?? Do you know how long it takes to deliver that value?? To find out how well your organization delivers customer value, Lean development process takes care of all of these by starting analyzing the value stream.Process Flow, An agile software development team can add features in any order and can release a working version of the software at the end of any iteration. When manufacturing plants learned how to make any product in any order, Just-in-Time manufacturing became practical.? Now that software developers have learned to add any feature in any order, and deliver working software in two-weeks or thereabouts, Just-in-Time software development is possible with Lean development process.?Local Responsibility,?In Lean development developers and domain experts who jointly develop a deep understanding of the domain design the best software.Data Based Decisions, When the goal is to hit a moving target, learning-based software development is the approach to use.? Experienced development teams can implement individual features in any order and deliver deployable code in less than a month.? Learning-based software development deploys small feature sets in priority order, providing both rapid feedback and immediate business value. ?Successful software companies have used this approach for many years.Lean Thinking, for Software Development is all about driving down this risky inventory and putting it to work providing customer value as quickly as possible.DisadvantagesThe Lean model ignores the social part of complex systems.The main drawback of using Lean alone as a process improvement methodology is lack of strategic supply chain direction. Lean efforts will certainly yield results but can lead to islands of excellence within an organization if used alone and the time from effort to any significant results can be longReferences[1] Agile Software Development Methods Review and Analysis.Pekka Abrahamsson, Outi Salo & Jussi Ronkainen; University of OuluVTT Electronics, VTT Publication 478.[2] An Introduction to Agile Software Development;Victor Szalvay, co-founderDanube Technologies, Bellevue, WA 98005[3] The Agile Manifesto; [4] Agile Software Development made easy[5] Haag, Stephen; Maeve Cummings, Donald J. McCubbrey, Pinsonneult, and Donovan (2006). "Phase 2: Analysis". Information Management Systems for the Information Age. McGraw-Hill Ryerson. ISBN 978-0072819472.[6] Jennerich, Bill (November 1990). "Joint Application Design: Business Requirements Analysis for Successful Re-Engineering". . Retrieved 2009-02-06.[7] Joint Application Design; Wikipedia[8] Mei C.Yatco. “Joint Application Design/Development”[9] Frank Maurer & Sebastien MartelAgile Software Development: An Industrial Case StudyUniversity of CalgaryDepartment of Computer Science[10] Mike Grant: Introduction to extreme Programming[11] Jim Highsmith: Extreme programming[12] Extreme Programming: Wikipedia [13] Lucas Layman , Laurie Williams, Lynn CunninghamNorth Carolina University, Computer Science Department[14] Ken Schwaber ; SCRUM Development Process[15] Scrum in five minutes[16] Mary Poppendieck: Lean Software Development (left)[17] Desari Ravi Kumar: Lean Software Development ( right)[18] Lean Software Institute: Introduction to Lean Software Development[19] Case study| Lean Software development ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download