Presentation is loading. Please wait.

Presentation is loading. Please wait.

ITEC 370 Lecture 25 Lifecycles. Review Questions? F give prototype demonstration –Testing plan for your software Life cycles –Scrum (Roles, Meetings,

Similar presentations


Presentation on theme: "ITEC 370 Lecture 25 Lifecycles. Review Questions? F give prototype demonstration –Testing plan for your software Life cycles –Scrum (Roles, Meetings,"— Presentation transcript:

1 ITEC 370 Lecture 25 Lifecycles

2 Review Questions? F give prototype demonstration –Testing plan for your software Life cycles –Scrum (Roles, Meetings, Sprints)

3 Lifecycles Objectives Life cycles –Waterfall, Scrum, now

4 Lifecycles eXtreme Programmin g Method of developing software geared towards handling changing requirements Frequent releases Testing from day 1 Communication Courage

5 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…

6 Lifecycles Process

7 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

8 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

9 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…

10 Lifecycles Requirement s 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

11 Lifecycles Requirement s 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

12 Lifecycles Requirement s 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

13 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

14 Lifecycles Coding Focus of XP Always done with another developer Add your code to the main branch continually No over-time

15 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

16 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 documentationscope creep Agile is feature driven; non-functional quality attributes are hard to be placed as user storiesuser stories Straight from wikipedia

17 Lifecycles Review XP –Coder centric –Heavy on communication –Informal


Download ppt "ITEC 370 Lecture 25 Lifecycles. Review Questions? F give prototype demonstration –Testing plan for your software Life cycles –Scrum (Roles, Meetings,"

Similar presentations


Ads by Google