Planned Methodologies Vs. Agile Methodologies Under The .
JKAU: Eng. Sci., Vol. 21 No.1 pp: 19-35 (1431A.H./2010 A.D.)DOI: 10.4197 / Eng. 21-1.2Planned Methodologies vs. Agile Methodologiesunder the Pressure of Dynamic MarketM. Kamel, I. Bediwi and M. Al-RashoudFaculty of Computer Science and Information Systems,King Abdulaziz University, Jeddah, Saudi ArabiaAbstract. In the software development, the most challenging task is todevelop projects under the pressure of dynamic market, where TimeTo Market (TTM) and requirements instability could fail thedevelopment process. Therefore project management should choosethe development methodology that can control the problemsassociated with the dynamic market. Agile team argue that plannedmethodologies are heavy to cope with the rapid changes of thedynamic market, because the planned methodologies stronglyemphasize on the planning process , by incorporating a lot of detaileddesign techniques like UML. On the other hand agile team claim thatagile is the marvelous approach that has solutions for all problemsrelated to the dynamic market, because agile achieves higherflexibility, and better to satisfy actual customer requirements. Agileachieves this, by developing and delivering the software product in anincremental fashion. Agile methodologies try to avoid anydevelopment overheads, and minimize unnecessary effort. This paperpresents a comparative study that compares between plannedmethodologies -which have coupling relationship with UML analysisand design techniques – and the agile methodologies. The comparisoncompares between the two approaches in many respects, such asanalysis, design, human resources, cost of the changes of therequirements and communication. The comparison shows how thelightness of the agile methodologies gives better responses to thedifferent problems related to the dynamic market. Also the studyshows that agile minimizes the cost of the changes of requirementsduring the development process.1. IntroductionPlanned methodologies are invented to control and solve the problemsof "code and fix" development style, where the software is written withoutmuch of an underlying plan, and the design of the system is cobbled together19
20M. Kamel, I. Bediwi and M. Al-Rashoudfrom many short term decisions. As the system grows it becomesincreasingly difficult to add new features or to fix any bug [1]. Plannedmethodologies try to solve these problems by imposing a disciplined processupon software development, with the aim of making software developmentmore predictable and more efficient. To be more predictable, plannedmethodologies focus on creating a comprehensive up-front design, fromwhich detailed construction plans are formulated. "Waterfall andincremental models are the most two well known models of plannedapproach" [2]. As Fig. 1 shows "waterfall suggests a systematic sequentialapproach to software development that begins with customer specificationof requirements and progress through planning, modeling, construction anddeployment, culminating in on-going support of the complete software" [2] .Fig. 1. Waterfall model."The incremental model combines elements of the waterfall modelapplied in an iterative fashion" [2]. By referring to Fig.2, the incrementalmodel applies linear sequences in a staggered fashion as calendar timeprogress. Each linear sequence produces deliverable increment of thesoftware.Using incremental model, development team “can start working onthe known increments, and clarify the rest later. Other problems mayarise later if project is not well defined or if the definition changes muchlater. Rule of thumb is: 80% of the requirements should be known in thebeginning. Development team should make a project priority chart, and
Planned Methodologies vs. Agile Methodologies 21plan the increments accordingly” [3]. The trend of planned methodologiesdoes not serve projects that have a compelling need to get software tomarket quickly such as web applications . Such applications exhibit atime to market that can be a matter of a few days or weeks with givinghigh consideration to maximizing product values and customersatisfaction. For that reason more flexibility and more customerinvolvement in the development process are needed. Agilemethodologies are invented to be the super methodologies that achievethe needed flexibility. These methodologies aim to “satisfy the customerthrough early and continuous delivery of valuable software with highwelcoming changing of requirements, even late in the development.Agile processes harness change for the customer's competitiveadvantage. Deliver working software frequently, from a couple of weeksto a couple of months, with a preference to the shorter timescale.Business people and developers must work together daily throughout theproject” [4].Fig. 2. Incremental model.
22M. Kamel, I. Bediwi and M. Al-Rashoud2. Agile and Planned MethodologiesRequirements AnalysisWhen it is said requirements are predictable that means they areclear, well defined and well understood. The rate of changes in thepredictable requirements is very small. "However most of the businesssoftware requirements are not predictable. Figure 3 shows that for manyprojects, it would be extremely rare for requirements not to be alteredbefore the system is completed. In some applications the rate of changesis a matter of weeks or even days " [4] .Fig. 3. Nature of requirements.It is very important for project managers to know the properreasons that could alert their project requirements. Then they shouldcategorize the project under development, and specify if it is apredictable or a changeable project .Depending on this categorization thedevelopment methodology should be chosen. This obviously willminimize the risk of project failure.2.1 Planned Methodologies and Requirements AnalysisThe requirements in the planned methodologies are analyzed anddefined upfront, and then the specification document and the softwareproject management plan are produced". Once these documents areapproved by the customer, they become the basis for the design phasewhich produces architectural and detailed design specifications. The
Planned Methodologies vs. Agile Methodologies 23Object Oriented (OO) analysis employs a lot of UML analysis tools. TheUML structure diagrams are used to identify the main structure of thesystem. The main functionality and the behavior of the system areidentified using UML behavior diagrams. UML interaction diagrams areused to specify the flow of control and data among the components of thesystem" [5]. Consequently OO analysis is composed of three importantmodeling elements as Fig. 4 shows.Fig. 4. OO analysis modeling elementsAfter the requirements are analyzed and modeled, they are welldocumented according to a selected documentation standard (such asDefense System Software Development Dod-Std-2167). All requirementsare assumed to be static. The probability of changes is very little. Allrequirements are given the same priority. They are treated equally in theanalysis effort. As Fig. 5 shows, once the requirements are gathered andanalyzed, the customer pause his relation with the project until theproduct is finished. validations is accomplished by the customer onlywhen the project reached to acceptance phases "includes acceptancetests, deployment and delivering " [6-7].2.2 Agile Methodologies and Requirements AnalysisUnlike most of planned approaches, which deliver a monolithicsystem after a long development time , agile methodologies focus ongenerating early and small releases of working products, using mostlycollaborative techniques, (XP uses pair programming and refactoring).The requirements in agile methodologies are implemented in an iterativemanner. The most important requirements are implemented first. During
24M. Kamel, I. Bediwi and M. Al-Rashouddevelopment process, customers work on site as team members. Theycarry the responsibility of controlling the requirements. Therefore theyhave the right to define new requirements, change their minds aboutexisting requirements, and reprioritize requirements as they see fit (Fig.6). They must also be responsible for making decisions and providinginformation in a timely manner [8]. They supply a continuance feedbackabout the developers understanding of the requirements and the progressand the quality of product.Fig. 5. Customer validations in the planned methodologies.Fig. 6.Incremental fashion and customer validations in agile methodologies.
Planned Methodologies vs. Agile Methodologies 253. Design in Agile and Planned MethodologiesIn the software development there are three styles of design. "Firstis evolutionary design (or no design). Essentially evolutionary designmeans that the design of the system grows as the system is implemented.Design is part of the programming processes and as the program evolvesthe design changes. This style of design ends up with a bunch of ad-hoctactical decisions, which makes the product harder to alter, especially inthe late phases"[9]. The Second approach is the long-term design, where alot of complex and heavy design activities are done. This style of designis totally separated from coding activities; usually this kind of design isused by planned methodologies. Simple design (or design for today) isthe third approach of design. Simplicity is the major feature of this style.The design is only applied for currently needed requirements. Agilemethodologies use this style of design [1-2,9].3.1 Planned Methodologies and Design"Design in planned methodologies begins once the requirementshave been analyzed, modeled and documented"[12]. in the plannedmethodologies, design team (designer) is usually separated fromconstruction team (programmers). "Designers think out the big issues inadvance. They don't need to write code, because they do not build thesoftware, they design it. So they use a lot of UML design techniques thatget away from some of the details of programming, and allow thedesigners to work at a more abstract level. Once the design is done,designers can hand it off to the programmers to write the code. Since thedesigners are thinking on a larger scale, they can avoid the series oftactical decisions" [9]. By referring to the documents of analysis modelelements (Fig. 4); designers create four design models that are requiredfor a complete specification of design (Fig. 7). The architectural modelsuse information derived from the application domain, and analysis model(structural model) to derive a complete structural representation of thesoftware, its subsystems and, its components. Interface design modelsrepresent the external and the internal interfaces to other systems,devices, networks or other procedures or consumers of information.Interface design models also represent the internal interfaces betweenvarious design components. Another aspect of interface design models isto model the interface with system users. Component-level models defineeach of external and internal components that populate the architecture of
26M. Kamel, I. Bediwi and M. Al-Rashoudthe system. Deployment-level design models specify the elementsallocating the architecture, its components and the interfaces to thephysical configuration that will house the software [2] .Fig. 7. The design models.All design activities are well documented using a documentationstandard that has been selected in the analysis phases. These documentswill be the main source for the programmers to implement the system.3.2 Agile Methodologies and DesignAgile design rigorously follows the (keep it simple/ and design fortoday) principle. Agile methodologies assume that more design forfuture, results in more complex design, which lead to more unnecessarycosts as Fig. 8 & 9 shows. In addition to that, the design providesimplementation guidance for a unit of requirements (XP uses userstories) as it is written nothing less, nothing more. The design of extrafunctionality (because it will be needed later) is discarding. Agilemethodologies use simple tools to keep the simplicity. They do notelaborate in using complex and detailed tools. For example XP usesClass-Responsibility-Collaborator (CRC) model [10] .
Planned Methodologies vs. Agile Methodologies 27Fig. 8. The complexity of design for future.Fig. 9. The complexity of design for today.If a difficult design problem is encountered, agile methodologiesrecommend the immediate creation of an operational prototype of thatportion of the design (it is called in XP spike solution). The intent of thatis to lower risk when true implementation starts and to validate theoriginal unit of requirement. Agile encourages refactoring technique (Fig.10). Refactoring is a reorganization technique that improves, simplifiesand maximize the efficiency of the design (or code) of a componentwithout changing its function or behavior. When software is refactored,the existing design is examined for redundancy, unused design elements,inefficient or unnecessary algorithm, poorly constructed or inappropriatedata structures or any other design failure that can be corrected to yield abetter design [2,10-11].4. Agile / Planned Methodologies and Human ResourcesTwo main aspects should be taken in considerations, to investigatethe effect of development methodologies on the human resources:
M. Kamel, I. Bediwi and M. Al-Rashoud28 Are the development methodology people orientated or processorientated? Communications among the members of development team.Fig. 10. Refactoring.4.1 People Orientation or Process OrientationPlanned methodologies consider the people as replaceable parts,and available in various types (analysts, coders, test engineers,managers.). The individuals aren't so important; the concentration isonly on the processes and on the roles that will execute these processes[1]."However people are not static and predictable components. They arevery highly non-linear variable and the most important factor in softwaredevelopment. COCOMO Cost Model and COCOMO II cost model showthat 10:1 is the effects of personnel capability, experience, andcontinuity[12]. For that reason "agile development focuses on theindividuals and interactions over processes and tools" [4] "They mold theprocess to specific people and teams. That means the process molds theneeds of the people and team, not the other way around” [2]. Agile tries tobuild projects around motivated and high morale individuals, and givethem the environment, courage, respect, trust and support the need toget the job done [4,10]. Figure 11 shows how the agile has high orientationto the people, whilst the planned methodologies orient toward theprocesses [2,12].
Planned Methodologies vs. Agile Methodologies 29Fig. 11. People /process orientation in planned and agile methodologies.4.2 Communications Among the Members of Development TeamCommunication is very important value. It causes the success orfailure of a software project, if it is / or is not applied in an efficient way.Communication could be achieved formally, through documentation, orinformally through face to face meetings, and continuous discussionsamong the team members. Planned methodologies relay a lot on formalcommunication. A lot of work and efforts are consumed, to implement alot of heavy analysis, design, and quality and test documents. Forexample to start any stage of waterfall model, it is necessary to havebunch of documents that are implemented by previous stages as Fig. 12shows.Fig. 12. Formal communication in the planned methodologies.Agile methodologies rely heavily on communication through tacit,interpersonal knowledge. Knowledge is gathered through the teamreviews. It is shared across the organization as experienced people workon more tasks with different people [12]. Agile considers the customer animportant member of development team - on-site customer is one of XP
30M. Kamel, I. Bediwi and M. Al-Rashoud12 practices - the customer priorities, point of view and feedback are themain guider that drive the construction effort.5. Development under Dynamic MarketSoftware project is considered under the condition of dynamicmarket, if it is under time-to-market pressure, with the volatility ofrequirements. Time-to-market is defined as to deliver a product to amarket early. The sooner a market is penetrated, the earlier product salesand the revenues start [13]. The selection of development methodology isthe corner stone to avoid many problems associated with dynamicenvironment. Table 1 shows the failure factors that could face thedevelopment team when they develop under dynamic conditions; also itshows how XP (most popular agile method) and waterfall (most popularplanned method) react to these factors [3].From the Table 1, it could be noticed that XP has more practicalreactions to dynamic market factors. The reasons behind this are that"agile develops and deliver software in an incremental fashion, whichachieve higher flexibility and better satisfy actual customer requirements.Incremental approach has many advantages over the traditional plannedapproach. Firstly, requirements can be prioritized so that the mostimportant ones are delivered first and benefits of the new system gainedearlier. Consequently, less important requirements are left until later andso if the schedule or budget is not sufficient the least importantrequirements are the ones more likely to be omitted. Secondly, it meansthat customers receive part of the system early on and so are more likelyto support the system and to provide feedback on it. Thirdly, beingsmaller, the schedule/cost for each delivery stage is easier to estimate.The fourth advantage is that the user feedback can be obtained at eachstage and plans adjusted accordingly. Lastly, perhaps most importantly,an incremental approach allows for a much better reaction to changes oradditions to requirements" [1]. Also from Table1 it could be noticed thatmost failure factors centered on the rapid changes of requirements duringdevelopment process. The major effect of changes in requirement is thecost that is spent on fixing the defects. It is very expensive to fix achange in requirements especially in the late phases of planned methodsas it is seen in Fig. 13 [2]. Fixing errors increase exponentially the laterthey are detected in the development lifecycle because the artifactswithin a serial process build on each other [14].
Planned Methodologies vs. Agile Methodologies 31Table 1. Dynamic market problems and waterfall, XP reactions.Failure factorUnclear project Objectives (lackof a project mission)Underestimation of project size,complexity, novelty.Extreme project (high speed, highchange)Project execution incompleterequirements/ specs (poorlydefined parts), lack of user inputUnstable (volatile) requirementsPoor requirements managementProject redirected (profoundchanges of the schedule/functionality/ resources)New, immature softwaretechnologyProject cancelledUnattractive Software release(wrong, obsoleteor missing features)IntegrationdifficultiesWaterfall reactionWaterfall model does not tackleespecially this problem. The projectteam should stay on thespecification phase, until projectobjectives are clarifiedThe waterfall model does not tackleespecially this problem. The projectteam may need to replan the wholeproject.Waterfall does not have enoughflexibility to deal with suchsituations.Waterfall model does not tackleespecially this problem. The projectteam should stay on thespecification phase, until projectobjectives are clarifiedWaterfall model does not tackleespecially this problem. Frequentand/or late changes are not welcomeThere should not be many changesat all, since the uncertainties aresupposed to be resolved at the firststagesThe pure waterfall model cannotadapt well to major midcoursechanges. The lifecycle must usuallybe restartedThere is a high risk the project willbe cancelled. Waterfall assumes amature, stable environmentThe project cannot show any results(except documen
Planned Methodologies vs. Agile Methodologies 27 Fig. 8. The complexity of design for future. Fig. 9. The complexity of design for today. If a difficult design problem is encountered, agile methodologies recommend the immediate creation of an operational prototype of that portion of the d
1. The need for an agile way of working 6 2. The need for an agile way of working 9 3. Agile Core Values - Agile Project Management Vs. 10 Agile Event Management 4. Agile principles 12 _Agile Principles of Agile Project Management 13 _Agile Principles of VOK DAMS Agile Event Management 14 5. Agile Methods 16 _Scrum in Short 16 _Kanban in Short 18
1.1 Purpose of the Agile Extension to the BABOK Guide1 1.2 What is Agile Business Analysis?2 1.3 Structure6 Chapter 2:The Agile Mindset 2.1 What is an Agile Mindset?7 2.2 The Agile Mindset, Methodologies, and Frameworks8 2.3 Applying the Agile Mindset9 2.4 Agile Extension and the Agile Ma
Agile Estimating and Planning by Mike Cohn Agile Game Development with Scrum by Clinton Keith Agile Product Ownership by Roman Pichler Agile Project Management with Scrum by Ken Schwaber Agile Retrospectives by Esther Derby and Diana Larsen Agile Testing: A Practical Guide for Testers and Agile Teams by Lisa Crispin and .
Agile World View "Agility" has manydimensions other than IT It ranges from leadership to technological agility Today's focus is on organizational & enterprise agility Agile Leaders Agile Organization Change Agile Acquisition & Contracting Agile Strategic Planning Agile Capability Analysis Agile Program Management Agile Tech.
The most popular agile methodologies include: extreme programming (XP), Scrum, Crystal, Dynamic Sys-tems Development (DSDM), Lean Development, and Feature Driven Development (FDD). All Agile methods share a common vision and core values of the Agile Manifesto. Agile Methods: Some well-known agile software development methods include: Agile .
The research reflects that agile methodologies are sustainable solutions for software development practices and more and more companies are open to the transition despite the potential risks. Keywords: Agile methodologies transition, challenges in agile development transition, deployment of agile methodologies
1. Agile methods are undisciplined and not measurable. 2. Agile methods have no project management. 3. Agile methods apply only to software development. 4. Agile methods have no documentation. 5. Agile methods have no requirements. 6. Agile methods only work with small colocated teams.-7. Agile methods do not include planning. 8.
D. Writing Requirement and Waiver of Final Exam The University has a writing requirement for all graduate degrees. The M.E. degree requires the preparation and defense of a report, which might be from one of the classes on the degree plan or be the result of CVEN 685: Directed Studies.
