ITEC 370 Lecture 25 Lifecycles. Review Questions? F give prototype demonstration –Testing plan for...

Post on 16-Dec-2015

212 views 0 download

Transcript of ITEC 370 Lecture 25 Lifecycles. Review Questions? F give prototype demonstration –Testing plan for...

ITEC 370

Lecture 25Lifecycles

Lifecycles

Review

• Questions?• F give prototype demonstration– Testing plan for your software

• Life cycles– Scrum (Roles, Meetings, Sprints)

Lifecycles

Objectives

• Life cycles–Waterfall, Scrum, now

Lifecycles

eXtreme Programming

• Method of developing software geared towards handling changing requirements

• Frequent releases• Testing from day 1• Communication• Courage

Lifecycles

Rules

• Planning– User stories / planning for iterations

• Managing– Communications / workplace / velocity

• Designing– Spiking, simplicity, refactoring

• Coding– Unit test first, customer on hand, pair programming

• Testing– All code must have a unit test– Code can only be added when it passes all tests– Find a bug? Add a unit test…

Lifecycles

Process

Lifecycles

Code

• Be a programmer or get out–Write requirements in code, design in

code, implement in code– Simplicity 101– Always write code with a partner

• In XP, code is the truly important product produced– Documentation (beyond what is

necessary for code), who needs it

Lifecycles

Testing

• If a little bit of testing can remove a majority of the flaws, what can a lot of testing do?

• Unit tests– How can I break the code?

• Acceptance tests– Customer specified

Lifecycles

CS paradise

• One caveat…you have to listen to the customer

• Every part of the process is driven by a customer’s goals

• Use CS coding skills, but hyper-focused on a specific set of problems

• Small fully functional releases– Command line prototypes, GUI

skeletons, etc…

Lifecycles

Requirements

• Before XP– Document with multiple sections– Clear method of communicating what is known– Customer Requirements team

• XP– Every developer must know what the system

is supposed to do– Interact with users on a daily basis– Need a common metaphor– Frequent communication and feedback

Lifecycles

Requirements

• Before you get started writing code, you need to write a story

• A story that explains the system at a high level

• Shared, mutual understanding of what the purpose of the system is

• Guide for the entire process

Lifecycles

Requirements

• Instead of a formal document you have user stories

• Description of what the system is going to do• User’s perspective• Can be simple– I want to be able to search songs based on name

and price

• Goal = To not need maintenance• Group several together and you have a goal

for your next cycle

Lifecycles

Designing

• Always take the simplest approach• No long term designs, planning for if

we want to add this later on we need this now…

• Refactor code– If there is a better way, redo it– If a requirement changed that affects

the code, change the code

Lifecycles

Coding

• Focus of XP• Always done with another developer• Add your code to the main branch

continually• No over-time

Lifecycles

Testing

• Unit tests• Must pass all tests before it can be

added• Only one pair adds code to a

repository at a time• Once code is added, it is considered

fully functional

Lifecycles

Criticisms

• A method is only as effective as the people involved, Agile does not solve this

• Often used as a means to bleed money from customers through lack of defining a deliverable

• Lack of structure and necessary documentation• Only works with senior-level developers• Incorporates insufficient software design• Requires meetings at frequent intervals at enormous expense to customers• Requires too much cultural change to adopt• Can lead to more difficult contractual negotiations• Can be very inefficient—if the requirements for one area of code change

through various iterations, the same programming may need to be done several times over. Whereas if a plan were there to be followed, a single area of code is expected to be written once.

• Impossible to develop realistic estimates of work effort needed to provide a quote, because at the beginning of the project no one knows the entire scope/requirements

• Can increase the risk of scope creep due to the lack of detailed requirements documentation

• Agile is feature driven; non-functional quality attributes are hard to be placed as user stories

Straight from wikipedia

Lifecycles

Review

• XP– Coder centric– Heavy on communication– Informal