Software Development Life Cycle

The evolution of software

Joey Freund, CSC301, Fall 2014

This Week’s Scope

• This week we will focus on how software development teams work.
• Their goal: Make management happy.
• How to achieve goal?
• Be efficient.
• Get things right.
• We will look at techniques that help teams be efficient and get things right.

Software Process

• Many definitions:
• A structured set of activities, used by a team to develop software systems.
• A team’s standards, practices, and conventions.
• Description of how a team performs its work.

Software Process

• Many synonyms:
• Software Development Process
• Software Development Methodology
• Software Development Life Cycle

Software Process

• In a nutshell, it is a structured description of how a Soft Dev team goes through:
• Deciding what to build.
• Building it.
• Deciding if they like what they built.

Software Process Models

• Over time, people develop new software process models.
• A model is a template/description of a process.
• Think of “Process vs. Model” like “Class vs. Interface” - Different processes can implement the same model.

Software Process Models

• Let’s go through some examples of models.
• We will look at some of the most popular models, in chronological order.

Waterfall

• A project is divided into a sequence of phases:
• Requirements
• Design
• Implementation
• Integration
• Verification
• Deployment
• Maintenance

Process vs. Model - Example

• Two different processes, implementing the Waterfall model:
• Process 1 - All phases are of even length.
• Process 2 - Spend 30% of the time on requirements and design, 50% on implementation, and 20% on all other phases.

Waterfall

• Originates in the Construction & Manufacturing industries.
• Suitable for projects where “reverting” is costly/impossible.
• Today it is considered as the “bad example” (in most software industries).
• Some more details

Waterfall

• Some arguments for it:
• By spending a long time on Requirements and Design early on, we discover problems/bugs early on.�The later a bug is found, the more costly it is.
• Requirements & design phases produce documentation, which preserves knowledge.

Waterfall

• Some arguments against it:
• Not suitable for changing requirements.
• Many decisions are hard to get right, especially if they must be made before you’ve written a single line of code.

Prototyping

• The project is done in “cycles”.
• In each cycle, the sequence of phases is:
• Basic requirements.
• Implement prototype (e.g. UI with all the functionality mocked/faked).
• Collect feedback from users.
• Adjust

Prototyping

• Arguments for it:
• At the end of each cycle, the team can assess their work, adjust to new requirements, and improve its work.
• More interaction with users help us ensure that we are building the right product.

Prototyping

• Arguments against it:
• Building a prototype is not the same as building a product. This model ignores a big chunk of the system, that is not trivial to implement.
• You don’t always have patient/forgiving users who will be willing to try your prototypes.

Iterative Incremental Process

• Build the product incrementally in short iterations.
• In each iteration, the sequence of phases is
• Plan
• Design & implement
• Test
• Review

Iterative Incremental Process

• Arguments for it:
• Shorter iterations = More opportunities to adjust and improve.
• “Fixes” one of the problems with Prototyping - We are developing a real product, not just prototypes.
• We can release at the end of an iteration. Therefore, we can collect feedback from users frequently.

Iterative Incremental Process

• Arguments against it:
• Unclear long term vision.
• There might be a better model for my specific industry (e.g. Prototyping for a company that makes physical controllers for gaming or music, Waterfall for a microprocessor manufacturer).

The Trend

• As our models evolve, they encourage Soft Dev teams to
• Be more flexible and adaptive to changing requirements.
• Collect feedback from users more frequently.
• Release code more frequently.
• And then came the term Agile ...

Agile

• Agile is neither a process nor a model.
• It is a term that describes a process, model, or a team.
• http://agilemanifesto.org/
• Essentially means “Flexible and adaptive process/team, suitable for projects with constantly changing requirements”.

Agile

• For most modern software companies, Agile simply means “doing things right”.
• In this course we will use and evaluate different practices and tools from various Agile processes.
• We’ll start with the concept of TDD ...

Test Driven Development

• A concept that started in the late 90’s.
• Used (to some extent) by many Agile teams.
• The idea is to write the tests, before you write the code.
• The tests are the requirements that drive the development.

Test Driven Development

• Traditionally, TDD means:
• Write a failing test.
• Write the (least amount of) code to pass the test.
• Repeat.
• Every now and then refactor/cleanup code.

Test Driven Development

• In practice, each team decides when and where it makes sense for tests to drive development.

Test Driven Development

• Most (good) teams borrow some of the concepts of TDD:
• Tests are used as specifications/documentation.
• Automate tests in fragile/crucial areas of your system.�For example: Legacy code is fragile, and deploying to live servers is a crucial.

Test Driven Development

• TDD makes sense for Agile teams:
• Agile is about “moving fast”.
• If your code is easy to test, it is usually also easy to build/deploy automatically.
• Being able to automate your tasks helps your team move fast.

TDD vs. Unit Testing

• Just to clarify the terminology:
• TDD - Cycles of write a failing test, then writing code to pass it.
• Unit Tests - The concept of testing “atomic units” individually. �Mock/fake functionality if needed (e.g. fake a web-server’s response when testing units of the client, fake “the engine” when testing units of the UI).

TDD

• Soft Dev teams can adopt TDD with different types of testings:
• Unit - Test “atomic units”.
• Integration - Test that all the different units in the system play nicely together.
• Acceptance - Specify a (customer’s) requirement.
• Regression - Verify we didn’t break anything that was working before (automated unit tests can be used as regression tests)

XP - Extreme Programming

• XP is a model that was getting a lot of hype in the late 90’s.
• XP is an Agile model, consisting of many rules/practices (one of them is TDD).
• A Gentle Introduction

XP - Extreme Programming

• Some highlights of XP:
• Iterative incremental model.
• Better teamwork.
• Customer’s decisions drive the project.
• Dev team works directly with a domain expert.
• Accept changing requirements (even near the deadline).
• Focus on delivering (working) software instead of documentation.

XP - Extreme Programming

• XP is a very detailed model.
• In practice, most teams adopt a subset of its rules.
• For your next exercise, you will adopt some of the XP rules.

Your Exercise

• Warm-up using Java, JUnit, Git & GitHub.
• You will work in teams of 6.
• You will be graded on:
• How you code runs against our tests.
• How your code runs against other teams’ test.
• How many bugs your tests find in other teams’ code.
• The process you develop and use.
• Individual components: Reflections & conclusion.

Your Exercise - IMPORTANT!

• Please register for a team on time.�If you do not register for a team on time:
• You might be assigned to a team arbitrarily.
• You will lose 25% of the mark for this exercise.

Your Exercise - Git Workflow

• We will use some form of Test Driven Development:
• User A creates branch X, and adds a failing unit test in that branch.
• User B changes the code in branch X to pass the test, and merges branch X.

Your Exercise - Git Workflow

• Notice:
• Before changing code in branch X, user B should get all recent changes from master.
• It is possible that the bug was already fixed, in which case, user B can merge/delete branch X (if the test is a duplicate, then delete. Otherwise, merge).

Your Exercise - Workflow

• You will use a GitHub issue/ticket for each branch you create:
• One of the goals of this exercise is to make you “implement a process” - Come up with an efficient way to use a given tool.
• Also, because we are grading you on the process (not just the end result), we will look at the issues as an “archive” of the process.

Your Exercise - Workflow

• It is up to you to decide on the details of how to use the issue management system.
• How to label things.
• What format to use in the body of the issue.

Your Exercise - Workflow

• You are encouraged to come up with your own standards/practices/conventions.
• Communication (e.g. email, in-person, shared docs, online hangouts).
• Schedule (e.g. How frequently to meet, milestones)
• Roles & assigning tasks (e.g. What needs to be done? Who is doing what?)