1 / 17

ITEC 370

ITEC 370. Lecture 25 Lifecycles. Review. Questions? F give prototype demonstration Testing plan for your software Life cycles Scrum (Roles, Meetings, Sprints). Objectives. Life cycles Waterfall, Scrum, now . eXtreme Programming.

hali
Télécharger la présentation

ITEC 370

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

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. Objectives • Life cycles • Waterfall, Scrum, now

  4. eXtreme Programming • Method of developing software geared towards handling changing requirements • Frequent releases • Testing from day 1 • Communication • Courage

  5. 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. Process

  7. 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. 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. 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. 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

  11. 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

  12. 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

  13. 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. Coding • Focus of XP • Always done with another developer • Add your code to the main branch continually • No over-time

  15. 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. 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

  17. Review • XP • Coder centric • Heavy on communication • Informal

More Related