software design and architecture

1. Samra Siddiqui

2.  Agile Development
 Agile SDLC
 Phases of Agile Development
 Top 10 Agile Practices

3.  Requirements :
 The first step in the Agile Software Development Process is to
identify some high-level requirements as well as the scope of
the release
 While the requirements developed within a Waterfall Software
Development Process are considered ‘law’, requirements within
an agile process are more or less ‘suggestions’, and are open to
more conversation by the team during other phases.
 Architecture and Design:
 The architecture is often defined using free-form diagrams
which explore the technical infrastructure, and the major
business entities and their relationships.
 The design is derived in a modeling session, in which issues
are explored, until the team is satisfied that they understand
what needs to be delivered.

4.  Development
 The development phase uses an evolutionary method that is an
iterative and incremental approach to software development.
 The system is delivered incrementally over time, in small modules
that have immediate business value, rather than building and then
delivering a system in a single “big bang” release.
 By focusing development on smaller modules, agile projects are able
to control costs despite the seeming lack of planning.
 Test & Feedback
 One of the key principles of the Agile Methodology is to conduct the
testing of the software as it is being developed.
 The software development is test driven.
 The unit testing is achieved from the developer’s perspective and
the acceptance testing is conducted from the customer’s perspective

5. 1) Daily stand up Meetings
2) ContinuousIntegration
3) Retrospectives
4) IterationDemo
5) Iterationplanning
6) Burn downTracking
7) Pair Programming
8) Release Planning
9) ProductBacklog
10)Code Refactoring

7. A stand-up meeting (or simply "stand-up") is a daily team meeting
held to provide a status update to the team members.
The 'semi-real-time' status allows participants to know about
potential challenges as well as coordinate efforts to resolve difficult
and/or time-consuming issues.
It has particular value in Agile software development processes,
such as Scrum, but can be utilized in any development
methodology.
The term "stand-up" derives from the practice of having the
attendees stand at the meeting, as the discomfort of standing for
long periods helps to keep the meetings short.
The meetings are usually time boxed to 5–15 minutes.

9. Continuous Integration (CI) involves producing a clean build of the
system several times per day.
The idea is not to try to solve every issue up front but, instead, to
focus on what you already know. So the team designs, builds, and
tests what they know about the desired functionality.
This creates a working product based on a subset of the complete
product's requirements. Then the team moves on to the next-
highest priority set of requirements and repeats the process.
Of course, this is a very simplified view, and there are many
variants of this process, but that's the core: Build your product
incrementally, and try to improve things as you go.

11. •Retrospective (from Latin retrospectare, "look back") generally
means to take a look back at events that already have taken place.
•Retrospectives play a crucial role in software teams.
•They are the time specifically put aside to reflect on how the team
is performing and what can be done to improve.
•Formally speaking, meeting held by a project team at the end of a project
or process (often after a certain number of iterations) to discuss what was
successful aboutthe project or time period covered by that retrospective
what could beimproved, and how to incorporate the successes and
improvementsin future iterations or projects."

12. At the end of an iteration, the entire team comes together to reflect on the
iteration.
Attendees include:
 the Scrum Master, who facilitates the meeting,
 the ProductOwner,
 the developers,
 the testers,
 any other contributors, and
 any interested stakeholders.
The goal of the meeting is to create visibility around what occurred in the course
of the iteration and to amplify learning about what could then be planned for the
next iteration.

13. The meeting also invites inspection of the metrics that show
what occurred in accepting (or not accepting) items.The attendees
evaluate:
 how many items were not completed
 what risks arose
 what items were more complex than originally planned
 what tests were run, passed, or failed
 how many defects were logged
 any other measurements the team has chosen to track in an
effort to continually improve how it prioritizes, estimates,
and commits to value delivery in every iteration

14. Iteration Planning
Iteration lengths typically range between 1 and 6 weeks
The team holds a planning meeting at the beginning of each
iteration to break down each of the features scheduled for the
iteration into specific technical tasks.
Iteration planning meetings generally last from 2-4 hours - any
more than that and you may be spending too much time in
unnecessary planning; less time than that and you may not be
doing enough planning and collaborating.

15. Burn DownTracking
 A burn down chart is a graphical representation of work left to do versus
time.
 The outstanding work (or backlog) is often on the vertical axis, with time along
the horizontal. That is, it is a run chart of outstanding work. It is useful for
predicting when all of the work will be completed.

16. Pair Programming
Pair programming is an agile software development technique
in which two programmers work together at one workstation.
One, the driver, writes code while the other, the observer (or
navigator), reviews each line of code as it is typed in. The two
programmers switch roles frequently.
While reviewing, the observer also considers the strategic
direction of the work, coming up with ideas for improvements
and likely future problems to address.

17. Release Planning
The goal of initial release planning is to estimate roughly which
features will be delivered by the release deadline.
We use this information to decide whether or not the project
will produce enough ROI (Return on Investment ) to at least pay
for itself, and therefore whether or not we should proceed.

18. Product Backlog
 The product backlog is an ordered list of "requirements" that is maintained
for a product. It contains Product Backlog Items that are ordered by the
Product Owner based on considerations like risk, business value,
dependencies, date needed, etc.
 For example, if the “add spellcheck” and “add table support” features have
the same business value, the one with the smallest development effort will
probably have higher priority, because the ROI (Return on Investment) is
higher.

19. Code Refactoring
Refactoring is the process of clarifying and simplifying the
design of existing code, without changing its behavior.
This is because un-refactored code tends to rot. Rot takes
several forms: unhealthy dependencies between classes or
packages, bad allocation of class responsibilities, way too many
responsibilities per method or class, duplicate code, and many
other varieties of confusion.

20. Principles of Agile Methods
Principle Description
Customer Involvement The customer should be closely involved throughout the
development process.
Their role is to provide and prioritise new system requirements
and to evaluate the iterations of the system.
Incremental Delivery The software is developed in increments with the customer
specifying the requirements to be included in each increment.
People Not Process The skills of the development team should be recognised.
The team should be left to develop their own ways of working
without prescriptive processes.
Embrace Change Expect the system requirements to change and design the system
so that it can accommodate these changes.
Maintain Simplicity Focus on simplicity in both the software being developed and in
the development process used.