The document discusses agile methodology for cloud computing. It first covers software engineering challenges in cloud environments like requirements gathering, architecture, testing, quality assurance and development methods. It then introduces agile methodology and popular agile methods like Scrum and Extreme Programming. The document proposes a requirements engineering methodology for agile cloud development consisting of 8 phases: inception, feature identification, grouping, prioritization, identifying non-functional requirements, architecture envisioning, task identification and development. It aims to bring more structure to agile requirements process while maintaining agility.

1. Agile methodology in
cloud computing
Saleem M. shoublaq & ahmed M. abed

2. Main points
• Software Engineering in Cloud
• Agile Introduction
• Agile Methodologies
• Agile cloud development
• Requirement in agile
• Proposed methodology
• Proposed methodology phases

3. Software Engineering in Cloud
• Cloud computing benefits such as agility, elasticity, availability, and cost efficiency require
software 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. Software Engineering in Cloud
• Requirements:
• Gathering requirements for cloud services is a rich research area that hasn’t yet received
much attention.
• Besides the traditional requirements engineering challenges, this task has unique
challenges in cloud projects.
• How does an organization engineer its service requirements in terms of security,
privacy, and performance dimensions?

5. Software Engineering in Cloud
• Software architecting:
• One of the key values of the cloud infrastructure is its ability to serve many millions of
customers around the world at any point in time.
• Typical cloud platforms exhibit several unique features, including large-scale replication
strategies, highly parallel queries, geographically distributed components, and disaster
recovery.
• Cloud platforms also provide services for mobile device integration and hybrid cloud
coupling.

6. Software Engineering in Cloud
• Testing:
• Cloud computing platforms are largely opaque entities, meaning that there’s little
visibility into how runtime components work.
• Virtualization/virtual machine layers, middleware, multitenancy, and high-availability
support further complicate this picture.

7. Software Engineering in Cloud
• Quality:
• In using cloud services, consumers cede control—they have less visibility into what
happens at runtime and less ability to fix things themselves should anything go wrong.
• Performance measurements, security conformance evaluations, and assessment
reliability determinations are much more difficult in the cloud.

8. Software Engineering in Cloud
• Development Methods
• In reality, developers must understand both worlds (IaaS and PaaS) in order to figure
out the best layered design.
• different platforms provide their own development environment and tools for
engineering services in their specific cloud.

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 from
scratch.
• Typically, cloud platforms need to establish ecosystems of collaborating services, some
existent and some new.

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 business
architecture, especially when delivering SaaS; it will also alter the roles and
responsibilities of various IT professionals.

11. Software Engineering in Cloud
• Cloud Deployment Strategy
• Deploying and migrating software applications to the cloud involves many
combinations of options that vary widely in their characteristics and performances.
• First, it’s often impossible to acquire all the infrastructure resources required to evaluate
the performance and cost implications.
• Second, cloud computing applications are specific to certain computing environments
and subject to different deployment models, such as IaaS, PaaS, and SaaS.

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. Agile Introduction
• Verification occurs much earlier in the development process than it would
with waterfall.
• The agile process follows the software development life cycle.
• includes requirements gathering, analysis, design, coding, testing and delivers
partially implemented software and waits for the customer feedback.

15. 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 the
methodology.

16. Extreme Programming
• XP development:
• XP projects start with a release planning phase, followed by several iterations, each of
which concludes with user acceptance testing.
• When the product has enough features to satisfy users, the team terminates iteration
and releases the software.

17. Extreme Programming
• XP Rules and Concepts:
• Integrate often.
• Project velocity.
• Pair programming.
• User story.

18. 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 backlog
item.
• 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.

19. Scrum
• Scrum concepts:
• Burndown chart.
• Product backlog.
• ScrumMaster.
• Sprint backlog.

20. Agile Methodologies
• Feature Driven Development :
• The key advantage of this method is to design the domain of the software to be
produced before development.
• The method starts with collecting the requirements from the users and building up the
overall 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

21. Agile VS Other Methodology

22. Agile VS Other Methodology

23. Agile Cloud Computing
• The topics at the intersection of agile development and cloud computing are
unique for a few reasons:
• Cloud is an Agile Accelerator
• Enables Business Agility
• Reducing IT Costs
• Improving Customer Experiences
• Growing the Economy

24. Agile Cloud Computing
• Characteristics of agile:
• Iterative.
• Modularity.
• Time Boxing.
• Parsimony.
• Incremental.
• Adaptive.
• Convergent.
• Collaborative.
• People Oriented.

25. Agile Cloud Computing
Advantages:
• Adaptive to the changing
environment.
• Ensures customer satisfaction
• Least documentation
• Reduces risks of development
Disadvantages:
• Customer interaction is the key factor of
developing successful software.
• Lack of documentation
• Time consuming and wastage of resources
• More helpful for management than
developer

26. Requirement in agile
• The conventional approach to the RE process focuses on gathering all the
requirements.
• Requirements gathering and specification efforts consume long time and
leave no room to accommodate changing requirements later in the
development cycle.

27. Requirement in agile
• Some of the issues faced by organizations involved in up front requirements
gathering 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 before
project completion.
• Clear specification of activities in the agile requirements engineering process is missing
• This approach toward requirements usually results in several architecture-related issues

28. Requirement in agile
• The requirements issues when using agile approaches:
• Missing Requirements Engineering Activities
• Missing Requirements Interface
• Non-Functional Requirements Elicitation

29. Requirement in agile
• The most commonly observed architecture-related difficulties when using
agile approaches:
• Incomplete Requirements Elicitation
• Incorrect Prioritization of User Stories
• Lack of Focus on Non Functional Requirements

30. Proposed Methodology
• The methodology was motivated by the lack of structure to the agile
requirements engineering process with minimal impact on agility.
• It describes in detail the phases in the agile requirements engineering process
and suggests techniques that can be used to perform these phases.
• The methodology describes not only the requirements engineering process
activities but the complete development process as well

31. Proposed Methodology Phases
• The methodology consists of eight phases. The first six phases (Inception,
Feature List Identification, Feature Grouping, Group Prioritization, NFRs
Identification, and Architecture Envisioning) cover the requirements and
architecture envisioning part while the two remaining phases (Task
Identification and Task Development) cover the requirements development
part.

32. Proposed Methodology Phases

33. Proposed Methodology Phases
• First Phase: Inspection:
• The inception phase is the first phase of the proposed methodology and is designed to help
the 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 main
phases, activities, and techniques.
• Goals for the project are formed and a vision statement is created that defines the entire
project
• The project team is assembled and the team members are empowered by having roles and
responsibilities assigned to them.

34. Inspection Activities
• Assign Roles and Define Responsibilities
• System Users Identification
• Proposed Methodology Explanation
• Establish Product Concept Statement

35. 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 list
identification phase. The stakeholders determine the expected functionality
of the system from this statement.

36. Proposed Methodology Phases
• Second Phase: Feature List Identification:
• The feature list identification is the second phase of the proposed methodology where
the system features are identified.
• A feature can be defined as the smallest set of functionality that provides business value
to the customer.
• The stakeholders identify the expected functionality from the high level product
mission statement.
• Features should be identified upfront in order to be informed about the scope of the
project and plan for the release cycles.

37. Feature List Identification Activities
• Preparation
• Elicitation
• Validation and Estimation
• Prioritization

38. Feature List Identification Output
• The output of the feature list identification is a prioritized feature list which
contains the prioritized features ordered by their priorities.
• The output of this phase will be the input to the feature grouping phase.

39. 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 a
release.

40. 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 group
prioritization phase.

41. Proposed Methodology Phases
• Fourth Phase: Group prioritization:
• The team determines the dependencies if any among the groups identified in the
feature 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 to
implement the groups.
• If there is a conflict, the customer is given preference.

42. Group prioritization
• Group prioritization Activities:
• Preparation
• Prioritization
• Group prioritization Output
• The output of this phase is prioritized stack list

43. 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 as
the input to the non functional requirements identification phase.
• The stakeholders with the team identify the NFRs from the high level product mission
statement.
• The identified NFRs are validated and prioritized based on their value to the customer
and stored in a prioritized NFRs list stack

44. 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 list
which contains the prioritized NFRs ordered by their priorities.
• The output of this phase will be the input to the architecture envisioning phase.

45. Proposed Methodology Phases
• Sixth Phase: Architecture Envisioning:
• The list of features identified in the feature list identification phase, the user stories
identified in the task development phase, and the list of non-functional requirements
identified in the non-functional requirements identification phase serve as the input to
the architecture envisioning.
• The goal of the architecture envisioning phase is to try to identify an architecture that
has a good chance of working.
• The envisioned architecture presents the system technical infrastructure and the major
business entities and their relationships to explore potential architecture-level
requirements.

46. Architecture Envisioning
• The technology stack diagram or deployment diagram are useful when doing
initial architectural modeling because they depict the major software and
hardware components and how they interact at a high level.

47. Proposed Methodology Phases
• Seventh Phase: Task Identification:
• The prioritized groups identified in the group prioritization phase serve as the input to
the 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.

48. Task Identification
• Task Identification Activities:
• Preparation
• Stories Identification
• Stories Prioritization
• Tasks Identification
• Validation and Estimation

49. 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 using
TDD and Customer Acceptance Testing as activities during this phase.
• The customers and developers then test the available system against the acceptance
criteria created previously.

50. Task Development
• TDD is a combination of Test First development and refactoring.
• Test First Development is a development technique where developers create
a unit test first for a story or task before writing code.
• Refactoring is an agile practice which deals with changing the design or
structure of the code without changing its result.
• Refactoring involves rewriting the code to improve its structure, while
explicitly preserving its behavior.

51. Task Development
• Using TDD, developers, create tests first, then write code and then refactor
the code in order to improve its structure.
• After refactoring, errors if any in the code are corrected. The developers do
not write code before a test fails.
• Task Development Activities:
• Test Driven Development (TDD)
• Customer Acceptance Tests

52. Real Example
• Salesforce use agile methodology in cloud computing.
• Reference:
• Agile Development Meets Cloud Computing for Extraordinary Results at
Salesforce.com
• In the paper Salesforce discus why use agile in cloud with details.
• We talk about this in last lecture.

53. Conclusion
• In this report we have discussed the software development life cycle models with
cloud.
• Characteristics of agile process, and spiral model, methodologies of agile process,
advantages and disadvantages.
• Agile methods in cloud, does requirements engineering in iterations: the
requirements are defined in detail only when they are implemented.
• Agile methods, however, have a lack of focus on certain parts of what is considered
as important in requirements engineering.
• Proposed Methodology to solve this problem.

54. References
• Grundy J., Kaefer G., Keong J., Liu A. (2012), Software Engineering for the Cloud. The IEEE
Computer 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 Agile
Environment. International Journal of Computer Science Issues, Vol. 9, Issue 5, No 3.
• Sales Force Company . (2012), Agile Development Meets Cloud Computing for Extraordinary
Results at Salesforce.com.
• Serena.com (2007), An Introduction to Agile Software Development
• Alistair Cockburn. (2001), Agile Software Development, (3rd ed.)