COMP 3521 CHAPTER 3

Rapid Software Development

• Rapid software development and delivery has become an important requirement for software systems
• Businesses operate in a fast-changing environment where stable software requirements are nearly impossible to create
• Software must evolve quickly to reflect changing business needs
• Plan-driven development is essential for some systems, but don't meet all the business needs
• Agile development methods emerged in the late 1990's with the aim to radically reduce delivery time for working software systems

Agile development

• Program specification, design, and implementation are interleaved in agile development
• The system is developed as a series of versions or increments with stakeholders involved in version specification and evaluation
• Agile development includes frequent delivery of new versions for evaluation
• Agile development uses extensive tool support like automated testing tools
• Agile development uses minimal documentation, focusing on working code

Plan-Driven Development

• The approach to software engineering has separate distinct development stages
• Outputs at each stage are planned ahead of time
• Plan-driven development is not necessarily a waterfall model, incremental development is possible
• Iteration occurs within activities.

Agile Development

• Agile development interleaves specification, design, implementation, and testing
• Outputs from the development process are decided through a negotiation during the software development process

Agile Methods

• Dissatisfaction with software design methods from the 1980's and 1990's led to the creation of agile methods
• These methods focus on code rather than design and are based on an iterative approach to software development
• Agile methods delivers working software quickly and its is intended to evolve to meet changing requirements
• The aim of these agile methods is to reduce software process overheads by limiting documentation
• The aim is also to be able to respond quickly to changing requirements, without rework

Agile Manifesto

• A value in developing software is favoring individuals and interactions over processes and tools
• A value in developing software is favoring working software over comprehensive documentation
• A value in developing software is favoring customer collaboration over contract negotiation
• A value in developing software is favoring responding to change over following a plan

Agile Method Principles

• Customer involvement means customers should be closely involved throughout the development process, and prioritize new system requirements
• Incremental delivery involves software developed in increments with the customer specifying the requirements to be included in each increment
• People, not process means the development team's skills should be recognized and used, allowing for team members to develop ways of working without prescriptive processes
• Embrace change by expecting changes and design the system to accommodate them
• Maintain simplicity by focusing on simplicity in both the software being developed and the development process and work to eliminate complexity

Agile Method Applicability

• Product development is applicable, where a software company is developing a small or medium-sized product for sale
• Virtually all software products and apps are now developed using an agile approach
• Custom system development within an organization is applicable, where there's a clear commitment from the customer to be involved in the development process
• Agile is applicable where there are few external rules and regulations

Extreme Programming

• Extreme programming is an influential agile method that was developed in the late 1990s
• It introduced agile development techniques
• Extreme Programming (XP) uses an "extreme" approach to iterative development
• New versions may be built several times per day
• Increments are delivered to customers every 2 weeks
• All tests must be run for every build with builds only accepted if tests run successfully

Extreme Programming - Incremental Planning

• Agile Principle/Practice where requirements are recorded on story cards
• Release stories are determined by time available and relative priority
• Developers break these stories into development 'Tasks'

Extreme Programming - Small Released

• Agile Principle/Practice where the minimal, most useful functionality set provides business value first
• Releases of the system are frequent and incrementally add functionality to the first release

Extreme Programming - Simple Design

• Agile Principle/Practice where only enough design is executed to meet current requirements

Extreme Programming - Test-First Development

• Agile Principle/Practice where an automated unit test framework is used to write new functionality tests before the functionality itself is implemented

Extreme Programming - Refactoring

• Agile Principle/Practice where developers are expected to refactor code and improve code continuously
• Refactoring keeps the code simple and maintainable

Extreme Programming - Pair Programming

• Developers work in pairs, check each other's work, and provide support

Extreme Programming - Collective Ownership

• Pairs of developers work on all areas of the system so there are no expertise islands
• All developers are responsible for all code and anyone can change anything

Extreme Programming - Continuous Integration

• Work is integrated into the whole system as soon as the work on a task is complete
• All unit tests in the system must pass after the integration

Extreme Programming - Sustainable Pace

• Large amount of overtime is not considered acceptable. The net effect is to often reduce code quality and medium term productivity.

Extreme Programming - On-Site Customer

• System end-user representatives (customers) must be available full-time
• In the XP Extreme Programming process, the customer is a development team member
• They bring system requirements to the team for implementation

XP and Agile Principles

• Incremental development supported though small and frequent releases
• Customer involvement means full-time customer involvement with the team
• People, not process, means pair programming, collective ownership and avoiding working long hours
• Change is supported through regular system releases
• Maintaining simplicity through constant code refactoring

Influential XP Practices

• Extreme programming has a technical focus, making it hard to integrate into management practice in most organizations
• Agile development utilizes many practices from XP but the method is not widely used in its originally defined form

XP Key Practices

• User stories for specification
• Refactoring
• Test-first development
• Pair Programming

User Stories

• In XP, customers or users are part of the XP team and are responsible for making decisions on requirements
• User requirements are expressed as user stories or scenarios
• User stories are written on cards and broken down into implementation tasks by the development team
• These tasks are the basis of schedule and cost estimations
• Customers choose stories for inclusion in the next release based on their priorities and schedule estimates

Refactoring

• Conventional wisdom in software engineering says design changes, spending time and effort reduces costs later.
• XP does not agree, as changes cannot be reliably anticipated
• A constant code improvement (refactoring) is proposed to make changes easier when they are implemented

Refactoring (cont.)

• Programming teams look for possible software improvements, even with no immediate need
• This improves software understanding, reducing the need for documentation
• Due to the code's well-structured setup, changes are easily implemented
• Some changes require architecture refactoring, which is more expensive

Refactoring Examples

• Example: Reorganization of a class hierarchy to remove duplicate code
• Example: Tidying up and renaming attributes and methods to improve understanding
• Example: Replacement of inline code with methods included in a program library

Test-First Development

• Testing is central to XP, where approaches require testing after every change is made

XP Testing Features

• Test-first development
• Incremental test development from scenarios
• User involvement in test development and validation
• Automated test harnesses run all component tests (each time a new release is built)

Test-Driven Development

• Writing tests before code clarifies the requirements
• Tests are written as programs, not data, allowing automatic execution, while including a check ensuring correct execution
• Test-Driven Development usually relies on a testing framework such as Junit
• All previous and new tests are run automatically when new functionality is added to check is new functionality introduced errors.

Customer Involvement

• Customers help the testing process by developing acceptance tests for the stories to be implemented in the system's next release
• The customer is part of the team and writes tests as development proceeds
• Any new code is validated to ensure it's what the customer needs
• People who are adopting customer roles in the testing process may feel hesitant to get involved, due to not working full-time with the team or thinking the providing the requirements is enough

Test automation

• Writing tests as executable components, simulate submission of input, and checking the result meets the output specification are test automation means
• An automated test framework (e.g. Junit) systems make it easy to write and execute tests sets

Test Automation Advantages

• A set of tests exist that can be run quickly
• Tests can be run whenever functionality is added to immediately catch problems with new code

Test-First Development Problems

• Programmers prefer programming over testing, leading to shortcuts like writing incomplete tests

Test-First Development Challenges

• Very difficult implementing incrementally, especially in complex user interface with implementing 'display logic" and workflow between screens
• It is difficult to write unit tests that implements them
• Tests completeness is hard to judge
• Having lots of tests doesn't guarantee complete coverage.

Pair Programming

• Involves programmers pair up, developing code together
• Helps develop common code ownership and spread knowledge amongst the team
• Serves as an informal review process by having every single line of code reviewed by more than 1 person
• Encourages refactoring because team members can benefit to improve the system code

Pair Programming

• Programmers sit together at the same computer
• Creates pairs dynamically so all team members work with each other during development
• Knowledge happens during which reduces risks if team members ends up leaving
• More efficient than 2 programmers working separately

Agile Project Management

• Principal responsibility of software project managers is to manage the project to deliver the software within budget and on time
• The standard approach to project management is plan-driven, and it draws up a plan for what should be delivered, when, and how
• Agile project management uses a different approach and adapted incremental development and agile methods

Scrum

• Scrum is an agile method which focuses on managing iterative development and specific agile practices
• Scrum has three phases:
• The initial phase involves outline planning to establish general objectives and design software architecture
• Followed by a series of sprints, each developing an increment of the system
• Project closure wraps up the project, completes documentation (help frames and user manuals) and review lessons learned

Development Team (Scrum Term)

• A self-organizing group of software developers, which should be no more than 7 people
• They are responsible for developing the software and other essential project documents

Potentially Shippable Product Increment (Scrum term)

• The software increment that is delivered from a sprint
• The term 'potentially shippable' means in finished state
• no further work, such as testing - needed to incorporate it into the final product
• In practice, this is not always achievable

Product Backlog (Scrum term)

• Lists of "to do" items which the Scrum team must tackle
• Feature definitions for the software, software requirements, user stories
• Descriptions of supplementary tasks needed, such as architecture definition/documentation

Product owner (Scrum Term)

• Identify development product tasks and requirements
• Continuously ensure requirements are being met
• Prioritize
• A customer, product manager, or stakeholder

Scrum (Scrum Term)

• Daily meeting of Scrum team, reviews progress and prioritizes daily tasks
• Face-to-face, includes whole team

Scrum Master (Scrum Term)

• Ensures Scrum process is followed, guides team in Scrum usage
• Responsible for the rest of company and for ensuring Scrum team is not affected by interference
• Scrum Master cannot is not a project manager

Sprint (Scrum Term)

• A development iteration that is typically 2-4 weeks long

Velocity (Scrum Term)

• How much product backlog effort a team can cover in a single sprint
• Helps to estimate future coverage
• Helps by measuring performance

Scrum Sprint Cycle

• Sprints are fixed length, normally 2 - 4 weeks
• The product backlog is the work to be done (tasks)
• The selection phase selects, in conjunction with the customer, what features and/or functions will be included in the sprint

The Sprint Cycle

• The team itself organizes the development itself
• Team is isolated from outside influences
• Scrum master protects team
• Stakeholders review product, and the next cycle begins

Teamwork in Scrum

• Scrum master facilitates the daily meetings, tracks backlog, and communicates with the customer
• Whole team attends short daily meetings/Scrums where each person shares information and progress since prior meeting, problems that have arisen, and plans
• Team understands going on and can re-plan if necessary

Scrum Benefits

• Breaking down large products into manageable, and understandable chunks
• Being unaffected by changing requirements
• Improve team communication
• Customers see on-time increments, and give feedback
• Trust, positive culture, expectations the project will succeed

Scaling Agile Methods

• Agile methods are proven to be successful for small and medium sized projects and teams
• It's argued team communications are improved, and therefore methods are successful when there is communication
• Agile methods can be scaled for larger/longer projects through changing to multiple development teams

‘Scaling Up’ is for Agile methods

• Developing large software systems where developing a small team is not possible

‘Scaling Out’ is for Agile methods

• Introduced across a large organization (lots of software development experience)
• When scaling agile, maintain the fundamentals:
  • Flexible planning, frequent releases, continuous Integration, team communication

Agile methods practical problems

• Agile development's informality is not compatible with existing legal frameworks for contract definitions, common in large companies
• Agile is better as new than maintenance, but most software costs come from maintenance
• Agile is made for smaller, collocated sites, but development is worldwide

Contractual Issues

• Most contracts are built around what is to be built
• Conflicts with agile and development in parallel
• Having contracts that pay for time and not feature is a problem

Agile Maintenance

• Organizations focus more on maintenance than developing new
• Agile doesn't address maintenance
• Two key issues
• Can the original approach be carried through
• Can those parts be effectively evolved

Agile Maintenance issues

• Problems: Lack of documentation, hard to keep customers involved, need to maintain continuity
• If they can't be maintained, problems arise.

Agile and Plan-Driven Methods

• Most projects contain elements of both
  • Importance? Strict? Need plan-driven
  • strategy to get constant feedback? Use Agile.
  • Is it large? Small= Agile, big= Plan-Driven

Agile Principles and Organizational Practice

• Customer Involvement- Customer must spend lots with the team so stakeholders must be able to spend good time, but often hard to do, not always possible to represent them

• Embrace Change- Prioritizing change is hard especially for multiple stakeholders

• Incremental Delivery- itierations and planning development does not mean it fits in the longer planning cycles for business, marketing managers may need to know features months ahead

• Maintain simplicity- schedules may not make team carry out simplications needed

• People not Process- team must have personallities appropriate for the intense method of Agile, and work well together

System Scale Issues

• Need informal communicators and co-located people for Agile
• Systems require Lots of Analysis before Implementation, there needs to be a Very Detailed Design
• Long-life Documentation for Intentions Developers in team for Support
• You need more docs for system safety if there is System Subject

People and Team Issues

• Agile needs more skill and approaches for programmers to transalate into a detailed detailed design
• If teams get distributed you need way more docs
• You need better technologies and such for design documentation if NOT there

Organization Issues

• Tradition = PLAN-BASED.
• IS THERE A SPEC?
• WILL CUSTOMERS SHOW??
• CAN CUSTOMERS WORK WITHIN THE ORG CUlTURES?

Agile Methods For Large Systems

• Large sysetems need comminications and separate teams
• They need to be working not too far away
• Some have interconnections that are not best for large sysitems
• System Configuration is more of the Fraction

Large Systems Development

• Large systems are constrained by external rules
• Need to maintain coherence to all the different pieces
• Too much at stake to possibly involve stakeholders

Large Scale factor review

• System of systems
• Brownfield Development
• Diverse Stakeholders
• Large Software System
• System confitguration
• Regulations

IBM Agility Model

• Agile at large
• Scaling factors at play for large teams
• Geo graphics of distribution
• Regulatory Compliances

Scaling up to Large Systems

• Improper requirements to have incremental systems
• One person can be just about responsible
• You often can not focus on the team

Multi-System Scrum

• Repilcate ROLE,

• EACH TEAM LEADS, Scrum MASTER

• Architects choose those and collaborate as the systems grow

• Release = release is complete and demonstrable

• There is often dailiy systems in Scrum

Organization across Agile

• There too much risks for Agile methods
• Standards don't correlate
• Can be a lot more skill if there are more teams/abilities
• Resistiance because it's too conviental

Key Points

• Minize documentations
• Involed stakeholders
• Constant releases
• Story
  • Teams

Extra Important key points

• System have to be well designed and planned ahead with more help

• The sprint can make the system a much more time effective process