Agile methodology in cloud computing


Published on

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Agile methodology in cloud computing

  1. 1. Agile methodology incloud computingSaleem M. shoublaq & ahmed M. abed
  2. 2. Main points• Software Engineering in Cloud• Agile Introduction• Agile Methodologies• Agile cloud development• Requirement in agile• Proposed methodology• Proposed methodology phases
  3. 3. Software Engineering in Cloud• Cloud computing benefits such as agility, elasticity, availability, and cost efficiency requiresoftware engineered for cloud platforms.• Many open issues surround the use of software services from the cloud:• Software requirements engineering for cloud services• Software architecting and design for cloud services• testing cloud services• ensuring quality attributes• Development methods and tools• Service platforms and composition approaches• Project management approaches• Cloud deployment options and justifications
  4. 4. Software Engineering in Cloud• Requirements:• Gathering requirements for cloud services is a rich research area that hasn’t yet receivedmuch attention.• Besides the traditional requirements engineering challenges, this task has uniquechallenges in cloud projects.• How does an organization engineer its service requirements in terms of security,privacy, and performance dimensions?
  5. 5. Software Engineering in Cloud• Software architecting:• One of the key values of the cloud infrastructure is its ability to serve many millions ofcustomers around the world at any point in time.• Typical cloud platforms exhibit several unique features, including large-scale replicationstrategies, highly parallel queries, geographically distributed components, and disasterrecovery.• Cloud platforms also provide services for mobile device integration and hybrid cloudcoupling.
  6. 6. Software Engineering in Cloud• Testing:• Cloud computing platforms are largely opaque entities, meaning that there’s littlevisibility into how runtime components work.• Virtualization/virtual machine layers, middleware, multitenancy, and high-availabilitysupport further complicate this picture.
  7. 7. Software Engineering in Cloud• Quality:• In using cloud services, consumers cede control—they have less visibility into whathappens at runtime and less ability to fix things themselves should anything go wrong.• Performance measurements, security conformance evaluations, and assessmentreliability determinations are much more difficult in the cloud.
  8. 8. Software Engineering in Cloud• Development Methods• In reality, developers must understand both worlds (IaaS and PaaS) in order to figureout the best layered design.• different platforms provide their own development environment and tools forengineering services in their specific cloud.
  9. 9. Software Engineering in Cloud• Composition Approaches• Not all traditional SOA techniques are applicable to the cloud environment.• A major difference is that a SOA design for the cloud generally can’t start entirely fromscratch.• Typically, cloud platforms need to establish ecosystems of collaborating services, someexistent and some new.
  10. 10. Software Engineering in Cloud• Project Management• How is SLA managed?• How much visibility is there into the running of a business service inside a cloud?• The use of cloud computing could have a major impact on an enterprise’s businessarchitecture, especially when delivering SaaS; it will also alter the roles andresponsibilities of various IT professionals.
  11. 11. Software Engineering in Cloud• Cloud Deployment Strategy• Deploying and migrating software applications to the cloud involves manycombinations of options that vary widely in their characteristics and performances.• First, it’s often impossible to acquire all the infrastructure resources required to evaluatethe performance and cost implications.• Second, cloud computing applications are specific to certain computing environmentsand subject to different deployment models, such as IaaS, PaaS, and SaaS.
  12. 12. Agile Introduction• Agile software development is a philosophy.• Agile methodology based on iteration.• Small teams work together with stakeholders to define quick prototypes.• Teams define requirements for the iteration.• Team develops the code, and defines and runs integrated test scripts.• The users verify the results.
  13. 13. Agile Introduction• Verification occurs much earlier in the development process than it wouldwith waterfall.• The agile process follows the software development life cycle.• includes requirements gathering, analysis, design, coding, testing and deliverspartially implemented software and waits for the customer feedback.
  14. 14. Agile Methodologies• XP (Extreme Programming):• It concentrates on the development rather than managerial aspects of software projects.• XP was designed so that organizations would be free to adopt all or part of themethodology.
  15. 15. Extreme Programming• XP development:• XP projects start with a release planning phase, followed by several iterations, each ofwhich concludes with user acceptance testing.• When the product has enough features to satisfy users, the team terminates iterationand releases the software.
  16. 16. Extreme Programming• XP Rules and Concepts:• Integrate often.• Project velocity.• Pair programming.• User story.
  17. 17. Agile Methodologies• Scrum:• Scrum for software development came out of the rapid prototyping community.• Scrum methodology includes both managerial and development processes.• The Scrum development process concentrates on managing sprints.• During development, the team determines the changes necessary to implement a backlogitem.• The team then writes the code, tests it, and documents the changes.• Finally, the team consolidates data from the review to update the changes as necessary.
  18. 18. Scrum• Scrum concepts:• Burndown chart.• Product backlog.• ScrumMaster.• Sprint backlog.
  19. 19. Agile Methodologies• Feature Driven Development :• The key advantage of this method is to design the domain of the software to beproduced before development.• The method starts with collecting the requirements from the users and building up theoverall model of the project.• Next step is to make a list of features which are the client-valued functions.• Next step is to make a plan for developing the features.• Last step is modeling iteration in which first UML modeling is done for each feature
  20. 20. Agile VS Other Methodology
  21. 21. Agile VS Other Methodology
  22. 22. Agile Cloud Computing• The topics at the intersection of agile development and cloud computing areunique for a few reasons:• Cloud is an Agile Accelerator• Enables Business Agility• Reducing IT Costs• Improving Customer Experiences• Growing the Economy
  23. 23. Agile Cloud Computing• Characteristics of agile:• Iterative.• Modularity.• Time Boxing.• Parsimony.• Incremental.• Adaptive.• Convergent.• Collaborative.• People Oriented.
  24. 24. Agile Cloud ComputingAdvantages:• Adaptive to the changingenvironment.• Ensures customer satisfaction• Least documentation• Reduces risks of developmentDisadvantages:• Customer interaction is the key factor ofdeveloping successful software.• Lack of documentation• Time consuming and wastage of resources• More helpful for management thandeveloper
  25. 25. Requirement in agile• The conventional approach to the RE process focuses on gathering all therequirements.• Requirements gathering and specification efforts consume long time andleave no room to accommodate changing requirements later in thedevelopment cycle.
  26. 26. Requirement in agile• Some of the issues faced by organizations involved in up front requirementsgathering and specification efforts are:• Requirements change over a period of time due to changes in customer and user needs.• Rapidly changing business environments can cause requirements to become obsolete beforeproject completion.• Clear specification of activities in the agile requirements engineering process is missing• This approach toward requirements usually results in several architecture-related issues
  27. 27. Requirement in agile• The requirements issues when using agile approaches:• Missing Requirements Engineering Activities• Missing Requirements Interface• Non-Functional Requirements Elicitation
  28. 28. Requirement in agile• The most commonly observed architecture-related difficulties when usingagile approaches:• Incomplete Requirements Elicitation• Incorrect Prioritization of User Stories• Lack of Focus on Non Functional Requirements
  29. 29. Proposed Methodology• The methodology was motivated by the lack of structure to the agilerequirements engineering process with minimal impact on agility.• It describes in detail the phases in the agile requirements engineering processand suggests techniques that can be used to perform these phases.• The methodology describes not only the requirements engineering processactivities but the complete development process as well
  30. 30. Proposed Methodology Phases• The methodology consists of eight phases. The first six phases (Inception,Feature List Identification, Feature Grouping, Group Prioritization, NFRsIdentification, and Architecture Envisioning) cover the requirements andarchitecture envisioning part while the two remaining phases (TaskIdentification and Task Development) cover the requirements developmentpart.
  31. 31. Proposed Methodology Phases
  32. 32. Proposed Methodology Phases• First Phase: Inspection:• The inception phase is the first phase of the proposed methodology and is designed to helpthe stakeholders establish relationship.• It is essentially a meeting or a series of meetings where all the stakeholders participate.• During this phase, the customer is informed about the proposed methodology mainphases, activities, and techniques.• Goals for the project are formed and a vision statement is created that defines the entireproject• The project team is assembled and the team members are empowered by having roles andresponsibilities assigned to them.
  33. 33. Inspection Activities• Assign Roles and Define Responsibilities• System Users Identification• Proposed Methodology Explanation• Establish Product Concept Statement
  34. 34. Inspection Output• It would answer the following questions:• Who are the product users?• What will the product do?• What problem(s) will the product solve?• The high-level mission statement serves as the input to the features listidentification phase. The stakeholders determine the expected functionalityof the system from this statement.
  35. 35. Proposed Methodology Phases• Second Phase: Feature List Identification:• The feature list identification is the second phase of the proposed methodology wherethe system features are identified.• A feature can be defined as the smallest set of functionality that provides business valueto the customer.• The stakeholders identify the expected functionality from the high level productmission statement.• Features should be identified upfront in order to be informed about the scope of theproject and plan for the release cycles.
  36. 36. Feature List Identification Activities• Preparation• Elicitation• Validation and Estimation• Prioritization
  37. 37. Feature List Identification Output• The output of the feature list identification is a prioritized feature list whichcontains the prioritized features ordered by their priorities.• The output of this phase will be the input to the feature grouping phase.
  38. 38. Proposed Methodology Phases• Third Phase: Feature Grouping:• The identified features in the feature list identification phase are collected into groups.The groups are set of related features that serve a business area.• The groups are validated and the time of their completion is initially estimated.• Only one group or a subset of the identified groups is chosen for development during arelease.
  39. 39. Feature Grouping• Feature Grouping Activities• Preparation• Grouping• Validation and Estimation• Feature Grouping Output:• The output of this phase is feature groups that serve as the input to the groupprioritization phase.
  40. 40. Proposed Methodology Phases• Fourth Phase: Group prioritization:• The team determines the dependencies if any among the groups identified in thefeature grouping phase and prioritize the groups accordingly.• The team also considers the customer and user preferences• The team and customers may have different sequences in which they would like toimplement the groups.• If there is a conflict, the customer is given preference.
  41. 41. Group prioritization• Group prioritization Activities:• Preparation• Prioritization• Group prioritization Output• The output of this phase is prioritized stack list
  42. 42. Proposed Methodology Phases• Fifth Phase: Non-functional Requirement Identification:• The phase aims to identify the system non functional requirements (NFRs).• The high level product mission statement created during the inception phase serves asthe input to the non functional requirements identification phase.• The stakeholders with the team identify the NFRs from the high level product missionstatement.• The identified NFRs are validated and prioritized based on their value to the customerand stored in a prioritized NFRs list stack
  43. 43. Non-functional Requirement Identification• Non-functional Requirement Identification Activities:• Elicitation• Validation• Prioritization• Non-functional Requirement Identification Output:• The output of the non functional requirements identification is a prioritized NFRs listwhich contains the prioritized NFRs ordered by their priorities.• The output of this phase will be the input to the architecture envisioning phase.
  44. 44. Proposed Methodology Phases• Sixth Phase: Architecture Envisioning:• The list of features identified in the feature list identification phase, the user storiesidentified in the task development phase, and the list of non-functional requirementsidentified in the non-functional requirements identification phase serve as the input tothe architecture envisioning.• The goal of the architecture envisioning phase is to try to identify an architecture thathas a good chance of working.• The envisioned architecture presents the system technical infrastructure and the majorbusiness entities and their relationships to explore potential architecture-levelrequirements.
  45. 45. Architecture Envisioning• The technology stack diagram or deployment diagram are useful when doinginitial architectural modeling because they depict the major software andhardware components and how they interact at a high level.
  46. 46. Proposed Methodology Phases• Seventh Phase: Task Identification:• The prioritized groups identified in the group prioritization phase serve as the input tothe task identification phase.• Each feature in the selected group is decomposed into stories.• Stories are descriptions of user- or customer valued functionality.• Stories are defined at a lower level of abstraction when compared to the features.• Each story then is decomposed into tasks by the development team.
  47. 47. Task Identification• Task Identification Activities:• Preparation• Stories Identification• Stories Prioritization• Tasks Identification• Validation and Estimation
  48. 48. Proposed Methodology Phases• Eighth Phase: Task Development:• The tasks created during the tasks identification phase are developed in this phase.• TDD is an agile practice and is a widely used approach to writing code.• The proposed methodology reflects the agile philosophy and hence, we suggest usingTDD and Customer Acceptance Testing as activities during this phase.• The customers and developers then test the available system against the acceptancecriteria created previously.
  49. 49. Task Development• TDD is a combination of Test First development and refactoring.• Test First Development is a development technique where developers createa unit test first for a story or task before writing code.• Refactoring is an agile practice which deals with changing the design orstructure of the code without changing its result.• Refactoring involves rewriting the code to improve its structure, whileexplicitly preserving its behavior.
  50. 50. Task Development• Using TDD, developers, create tests first, then write code and then refactorthe code in order to improve its structure.• After refactoring, errors if any in the code are corrected. The developers donot write code before a test fails.• Task Development Activities:• Test Driven Development (TDD)• Customer Acceptance Tests
  51. 51. Real Example• Salesforce use agile methodology in cloud computing.• Reference:• Agile Development Meets Cloud Computing for Extraordinary Results• In the paper Salesforce discus why use agile in cloud with details.• We talk about this in last lecture.
  52. 52. Conclusion• In this report we have discussed the software development life cycle models withcloud.• Characteristics of agile process, and spiral model, methodologies of agile process,advantages and disadvantages.• Agile methods in cloud, does requirements engineering in iterations: therequirements are defined in detail only when they are implemented.• Agile methods, however, have a lack of focus on certain parts of what is consideredas important in requirements engineering.• Proposed Methodology to solve this problem.
  53. 53. References• Grundy J., Kaefer G., Keong J., Liu A. (2012), Software Engineering for the Cloud. The IEEEComputer Society• Sharma S., Sarkar D., Gupta D. (2012), Agile Processes and Methodologies: A Conceptual Study.International Journal on Computer Science and Engineering , Vol. 4 No. 05• Helmy W., Kamel A. and Hegazy O. (2012), Requirements Engineering Methodology in AgileEnvironment. International Journal of Computer Science Issues, Vol. 9, Issue 5, No 3.• Sales Force Company . (2012), Agile Development Meets Cloud Computing for ExtraordinaryResults at• (2007), An Introduction to Agile Software Development• Alistair Cockburn. (2001), Agile Software Development, (3rd ed.)