The Art and Science of Software Construction: Agile Software Development

Waterfall Development

  • Requirements: During this initial phase, the potential requirements of the application are methodically analyzed and written down in a specification document that serves as the basis for all future development. The result is typically a requirements document that defines what the application should do, but not how it should do it.
  • Analysis: During this second stage, the system is analyzed in order to properly generate the models and business logic that will be used in the application.
  • Design: This stage largely covers technical design requirements, such as programming language, data layers, services, etc. A design specification will typically be created that outlines how exactly the business logic covered in analysis will be technically implemented.
  • Coding: The actual source code is finally written in this fourth stage, implementing all models, business logic, and service integrations that were specified in the prior stages.
  • Testing: During this stage, QA, beta testers, and all other testers systematically discover and report issues within the application that need to be resolved. It is not uncommon for this phase to cause a “necessary repeat” of the previous coding phase, in order for revealed bugs to be properly squashed.
  • Operations: Finally, the application is ready for deployment to a live environment. The operations stage entails not just the deployment of the application, but also subsequent support and maintenance that may be required to keep it functional and up-to-date.

From Agile Software Development:

Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it.  Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Principles Behind the Agile Manifesto
We follow these principles:

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  • Business people and developers must work together daily throughout the project.
  • Build projects around motivated individuals.
  • Give them the environment and support they need, and trust them to get the job done.
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • Working software is the primary measure of progress.
  • Agile processes promote sustainable development.
  • The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  • Continuous attention to technical excellence and good design enhances agility.
  • Simplicity–the art of maximizing the amount of work not done–is essential.
  • The best architectures, requirements, and designs emerge from self-organizing teams.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Overview of Extreme Programming

  • The Practices of Extreme Programming 
    • Customer Team Member 
    • User Stories 
    • Short Cycles 
    • Acceptance Tests 
    • Pair Programming 
    • Test-Driven Development 
    • Collective Ownership 
    • Continuous Integration 
    • Sustainable Pace 
    • Open Workspace 
    • The Planning Game 
    • Simple Design 
    • Refactoring 
    • Metaphor

Planning

  • Initial Exploration 
    • Spiking, Splitting, and Velocity 
    • Release Planning 
    • Iteration Planning
  • Task Planning 
    • The Halfway Point

Scrum

 Refactoring

  • Generating Primes: A Simple Example of Refactoring 
    • The Final Reread

Section 2 Agile Design

  • Symptoms of Poor Design 
  • Principles 
  • Smells and Principles


Chapter 7 – What Is Agile Design?

  • What Goes Wrong with Software?
  • Design Smells—The Odors of Rotting Software 
    • You know that the software is rotting when it starts to exhibit any of the following odors:
    1. Rigidity—The system is hard to change because every change forces many other changes to other parts of the system.
    2. Fragility—Changes cause the system to break in places that have no conceptual relationship to the part that was changed.
    3. Immobility—It is hard to disentangle the system into components that can be reused in other systems.
    4. Viscosity—Doing things right is harder than doing things wrong.
    5. Needless Complexity—The design contains infrastructure that adds no direct benefit.
    6. Needless Repetition—The design contains repeating structures that could be unified under a single abstrac- tion.
    7. Opacity—It is hard to read and understand. It does not express its intent well.
    • What Stimulates the Software to Rot? 
    • Agile Teams Don’t Allow the Software to Rot

SRP: The Single-Responsibility Principle 

  • A CLASS SHOULD ONLY HAVE ONE REASON TO CHANGE.

OCP: The Open—Closed Principle 

  • SOFTWARE ENTITIES (CLASSES, MODULES, FUNCTIONS, ETC.) SHOULD BE OPEN FOR EXTENSION. BUT CLOSED FOR MODIFICATION. 

Chapter 10 LSP: The Liskov Substitution Principle 

  • SUBTYPES MUST BE SUBSTITUTABLE FOR THEIR BASE TYPES.

Chapter 11 – DIP: The Dependency-Inversion Principle

  • A. HIGH-LEVEL MODULES SHOULD NOT DEFEND UPON LOW-LEVEL MODULES. BOTH SHOULD DEFEND ON ABSTRACTIONS.
  • B. ABSTRACTIONS SHOULD NOT DEPEND 0N DETAILS. DETAILS SHOULD DEPEND 0N ABSTRACTIONS.

Chapter 12 – ISP: The Interface-Segregation Principle

  • Interface Pollution 
  • Separate Clients Mean Separate Interfaces 
  • Class Interfaces v. Object Interfaces 

Waterfall vs Agile

References:
Agile Software Development: