Evolution of Software Development

Methodologies - Appendix
Gundimeda Venugopal
Appendix
Evolution of Build Tools
Evolution of Testing
Joint Architecture Design and Architecture Review Board
❖ Enterprises usually create an Enterprise Architecture Blueprint for their organization and the Architecture
Review Board provides the necessary governance.
❖ Architecture Review Board is usually made up of CIO, Enterprise Architect, Security Architect, Infra
Architect, Senior Architects and Product Owners.
❖ Joint Architecture Design collaborative design process wherein all engineering personnel necessary to
develop some new major functionality work together to define a design consistent with the architectural
principles of the organization.
❖ JAD is required whenever an IT project requires an architectural change or to address a new challenge
through proposed system.
❖ Projects go to the Architecture Review Board (ARB) for approval after approved through JAD.
 BUILDING BETTER UX/SYSTEMS
Design Thinking
SAFe BETTER ANALYSIS & DESIGN
CONTINOUS IMPROVEMENT

Example:
Customer Centric UX Design for mobile (Android/ios)
devices and web. Concept demonstration through
power point slide prototypes.
 COMPLEX PROJECTS
Empirical Process Control Agile (Scrum)
An empirical process is implemented where progress is based on observation and Large Scalable Scrum - LeSS
experimentation instead of detailed, upfront planning and defined processes.
The Empirical Process Control has the following characteristics:
• Learn as we progress
• Expect and embrace change
• Inspect and adapt using short development cycles
• Estimates are indicative only and may not be accurate
 AGILE MINDSET
Pair Programming INCREASED PRODUCTIVITY

Pair programmers: Keep each other on task. Brainstorm

refinements to the system. Clarify ideas. Take initiative when
their partner is stuck, thus lowering frustration. Hold each other
accountable to the team’s practices. Pairing" - Kent Beck

NAVIGATOR Pairing allows developers to ...

• Produce better solutions
• Share knowledge and context on the fly
• Mutual learning and skill development

Kinder Garden Lessons (for Pair Programming)

❖ Share everything. (Collective code ownership)
❖ Play fair. (Pair programming—navigator must not be passive)
❖ Don’t hit people. (Give and receive feedback. Stay on track.)
❖ Clean up your own mess. (Unit testing.)
❖ Wash your hands before you eat. (Wash your hands of
skepticism: buy-in is crucial to pair programming.)
❖ Flush. (Test-driven development, refactoring.)
❖ Take a nap every afternoon. (40-hour week.)
❖ Be aware of wonder. (Ego-less programming, metaphor.)
Cross Functional Teams CONTINOUS IMPROVEMENT
COLLECTIVE OWNERSHIP
INCREASED PRODUCTIVITY

Cross-functional collaboration ―
bringing people from various spheres,
bringing together their knowledge,
expertise, and experience
 AGILE MINDSET & LEAN THINKING
Communication Effectiveness CONTINOUS IMPROVEMENT
INCREASED PRODUCTIVITY

Communication Effectiveness Video/Audio Communication Costs have come

down drastically.

Better Communication with Customers/ Partners/

Employees means
2 people on a Video ❖Better relationships with Customers/ Partners/
Conference Employees with limited documentation (Agile
Methodology Mindset / Lean Thinking)
❖ Agile Projects can work without Collocated
teams
❖Improved Customer Focus/Agility - Respond to
customer needs faster.
❖ IT Employees Can work from Anywhere (with
Video/Audio conferences and Email)
Software Methodologies
 Waterfall methodology
• Waterfall approach essentially refers to a linear sequence of stages to develop a system from planning to analysis to design to implementation.
• Progress is seen as flowing steadily downwards (like a waterfall) through SDLC
• Stages are followed from beginning to end. Revisiting prior stages is not permitted.

❖ PROs
• Detailed early analysis cause huge advantages at later
phases
• If a bug found earlier, it is much cheaper (and more
effective) to fix than bugs found in a later phase
• Requirement should be set before design starts
• Points to importance of documentation (minimized
“broken leg” issue)
• Disciplined and well-structured approach
• Effective for stable software projects
• Easy to plan from project management point of view

❖ CONs
• Changes are expensive
• Client does not explicitly know what he or she wants
• Client does not explicitly know what is possible to have
• Need to finish every phase fully
• Long projects, difficult to keep the plan
• Designers may not know in advance how complex a
feature’s implementation
• “Measure twice, cut once”
 Systems structured analysis and design methodology (SSADM)
SSADM is a group of standards for both system analysis and
application design.

SSADM sets out a waterfall view of systems development,

in which there are a series of steps, each of which leads to
the next step.

SSADM divides an application development project into

modules, stages, steps, and tasks, and provides a
framework for managing the project.

SSADM provides a rigorous document-led approach to

system design, and contrasts with more contemporary agile
methods such as Scrum.
Verification & Validation
 Object Oriented Methodology
❖ The object-oriented methodology starts with the formulation and analysis of the business
problem.
• Modeling the functions/use cases of the system.
• Finding and identifying the business objects
• Organizing the objects and identifying their relationships.
• Modeling the behavior of the objects.
❖ The design phase involves design of OO classes ( class data and methods), OO class
hierarchies and relationships and the interactions with one OO classes to meet the use
cases objectives.
❖ The design phase is followed by a survey of the component library to see if any of the
components can be re-used in the system development.
❖ If the component is not available in the library then a new component must be developed,
involving formulation, analysis, coding and testing of the module. The new component is
added to the library and used to construct the new application.
❖ Object-oriented methodology is based on re-use of development modules and
components. (e.g., Windows MFC,, Java Collection, Swing, JSF, Hibernate, LDAP, Spring)
❖ The Object-oriented design model aims to reduce costs by integrating existing modules
into development. These modules are usually of a higher quality as they have been tested
in the field by other clients and should have been debugged. The development time using
this model should be lower as there is less code to write.
❖ The object-oriented model should provide advantages over the other models as the
library of components grows over time.
Prototyping
❖ Building a scaled-down working version of the system
❖ A prototype typically simulates only a few aspects of, and may be completely different from, the final product.
❖ Prototype types
• Reusable Incremental Prototype
• Throwaway Prototype
❖ Advantages:
• Feasibility of Critical components
• Users are involved in design / quick review to make course corrections (e.g., GUI interfaces)
 Agile Software Methodologies
❖ Agile Software Development is or a set of methods and practices ( Agile Manifesto 2001)
❖ Agile methodologies focus on iterative and incremental development with rapid and frequent deliverables of partial solutions that can be
evaluated and used to determine next steps.
❖ Agile Manifesto for Agile Software Development

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Key Agile Phrases

Agile Manifesto Principles
❖ Self-organizing, cross-functional teams
❖ Adaptive planning
❖ Evolutionary development and delivery
❖ A time-boxed iterative approach
❖ Rapid and flexible response to change.
Typical Agile Project Development Life cycle – Scrum Model
❖ Scrum is an iterative and incremental agile software development framework
❖ A flexible, holistic product development strategy
❖ Development team works as an atomic unit
Agile Methodologies Evolution

Scaled Agile Framework (SAFe)

(Dean Leffingwell)
2011

2005
Large Scale Scrum (LeSS)
(Bas Vodde, Craig Larman)

Scrum of Scrums
Behavior Driven Development

User Behavior → Scenarios

(A set of pre-conditions) (When an event occurs) (Outcome is achieved)

eXtreme Programming Methodology (XP)
The Extreme Programming Release Cycle
• Extreme Programming (XP) takes an ‘extreme’ approach to iterative
development.
• Incremental development is supported through small, frequent system releases.
• New versions may be built several times per day and Increments are delivered to
customers approx. every 2 weeks;

• Customer involvement means full-time customer engagement with the team.

• Write unit tests before programming; keeping all tests running all times.
• Integrating and testing the whole system--several times a day.
• All tests must be run for every build and the build is only accepted if tests run
successfully. (TDD)
Why it is called “Extreme Programming”?

• Producing all software in pairs, two programmers at one screen.

• People not process through pair programming, collective ownership and a process
that avoids long working hours.

• Starting projects with simple design. Simple design can evolve.

• Putting a minimal system into production quickly and growing it in whatever
directions prove most valuable.
• Maintaining simplicity through constant refactoring of code and continuous
integration and testing
 Lean software Development
Eliminate Wastes: To maximize value, We must minimize Waste. For software systems, Waste can
Lean Software Development (LSD) is a set of take the form of partially done work, delays, hand-offs, unnecessary features etc.
principles that have been taken from Lean
Develop ways to identify and then remove waste to increase the value we are getting from projects.
manufacturing approaches & applied to
software development. Empower the team: Respect team members superior knowledge of the technical steps required on
the project and let them make local decisions to be productive and successful.
Lean & Agile values are closely aligned. These
core principles focus on the following 7 core Deliver Fast: We can maximize the project Return on investment (ROI) by quickly delivering valuable
concepts: software through the Rapid Evolution of options.

Optimize the Whole: We aim to see the system as more than the sum of its parts. We go beyond the
pieces of the project and look for how it aligns with the organization.

Build quality in: Lean development doesn’t try to “test-in” quality at the end; instead, we build
quality into the product and continually assure quality throughout the development process, using
techniques like refactoring, continuous integration and unit testing.

Defer Decisions: We balance early planning with making decisions and committing to things as late as
possible. For example, this may mean re-prioritizing the backlog right up until it is time to plan an
iteration, or avoiding being tide to an early technology-bounded solution.

Amplify Learning: Facilitate communication early and often, getting feedback as soon as possible, and
building on what we learn.
Software projects are business and technology learning experiences, so we should start soon and
keep learning.
 Rapid Application Development (RAD)
❖Rapid Application Development (RAD) is a form of agile
software development methodology that prioritizes
rapid prototype releases and iterations.
❖Unlike the Waterfall method, RAD emphasizes the use of
software and user feedback over strict planning and
requirements recording
❖RAD is a people-centered and incremental development
approach. Active user involvement, as well as
collaboration and co-operation between all stakeholders
are imperative.
❖The key objectives of RAD are: High Speed, High Quality
and Low Cost.
❖RAD and the agile methodologies share similar values,
with regards to flexibility, shorter delivery time, and high
customer interaction and satisfaction, RAD is primarily
focused on prototypes while agile is mostly focused on
breaking down the project into features which are then
delivered in various sprints.
❖RAD is especially well suited for (although not limited to)
developing software that is driven by user interface
requirements. Rapid code generation and CI/CD tools
should be used for RAD projects.
 Business Model:
Rational Unified Process Current State, Business Processes/
Components, Roles, Responsibilities

Requirements:
Usecases with Usecase and Activity diagrams.
Functional/Non-functional Requirements

Analysis & Design

High level and low level architecture and
design documents
OO Design and Data Model design

Implementation
Code, Unit Tests and Results

Testing
Integration/Systems Testing approach, test
cases, testing and results
Acceptance test cases and results

Deployment
Deployment Diagrams, Deployment scripts

• An iterative software development process framework created by the Rational Software Corporation (IBM)
• Not a concrete prescriptive process, but an adaptable framework, intended to be tailored by the development
organizations. Expected to select elements of the process that are appropriate
 Scrum of Scrums
Typical Scrum of Scrums daily sync:
Each representative of a scrum team answers these three questions:

• What have we done since the last sync, and how does it impact the
other teams?
• What are we going to do, and what is the impact going to be?
• What are the obstacles we’re facing, or anticipate we’ll be facing?

The meeting takes longer, typically 45 to 60 minutes.

Reporting on done/plans is secondary and shouldn’t be focused on too

much. The key of this meeting is to define and address touchpoints
between teams and potential obstacles they may be facing.

Pros of Scrum of Scrums Cons of Scrum of Scrums

•Very easy to implement for teams already working in Scrum. • More difficult (but not impossible) in larger organizations
with many teams involved.
•Doesn’t impact most of the team members in any way (as
they’re not involved). •Doesn’t specify how to approach artifacts of Scrum –
product/team backlog, planning meetings, etc.
•Works well for up to 25-30 people involved within a few
teams.
SAFe (Scaled Agile Framework)
SAFe Agile delivery for an Enterprise
 LeSS – Large Scale Scrum
❖ LeSS is a lightweight framework that’s meant to help you scale Scrum to more than one team in a large-scale context.
❖ LeSS is suitable for 2 to 8 teams, while its twin brother, LeSS Huge, can cater for even thousands of participants.
❖ LeSS puts less focus on the enforcement of rules, rituals or processes than SAFe. It also specifies fewer roles, and the ones it does are very well
known from regular Scrum practices.

LeSS Ten Core Principles Large Scale Scrum Execution Model

Thank You