IT 450 - Introduction

1. IT 450 - Introduction Unit 4 School of Information Systems and Technology (IST) School of Information Systems & Technology

2. Agenda • Administrivia • Software Development • Software Development Process • Software Development Best Practices School of Information Systems & Technology

3. Administrivia • My name - Imroz Khan • My email - ikhan@kaplan.edu • My AIM handle - imr0zkhan • My office hours: • TBD • TBD • Any other time via appointment School of Information Systems & Technology

4. Seminar Guidelines • Please Stay On Topic • Answer my questions anytime by typing in your comment. • Please do NOT interject “I agree” or “Good point” as this clutters the seminar. We assume you agree and think the point is good! • Raise your hand to interrupt • // means “I have a question” • I will respond with your name ?? which means “go ahead and ask” • Please, No Side Conversations • If I type BREAK everyone stops typing • Use good chat etiquette • Don’t worry about typos. Be as clear as you can and refrain from smileys/emoticons and slang –use proper English. • Respect others. School of Information Systems & Technology

5. Software Development • Software Development in theory • Requirements • Analysis • Design • Implementation • Software Development reality School of Information Systems & Technology

6. Software Development Process Models • Software Development Life Cycle Model • The cost of constructing most software occurs during development and not during production • Process is a series of predictable steps, a roadmap School of Information Systems & Technology

7. GSDP • Garage Software Development Process • Code and Fix, Code and Fix • Done School of Information Systems & Technology

8. Analysis Design Coding Testing Integration Waterfall Model School of Information Systems & Technology

9. Waterfall Model • Quality Gates (Service Gates) • Base lining • Requirements Specification • Test Plan • Design Specification • Code • Test Results report School of Information Systems & Technology

10. Waterfall Model • Change intolerant • Document-driven • Customer must state all requirements upfront • Features unavailable until implementation phase • Strong distinction between Development and Maintenance School of Information Systems & Technology

11. Waterfall Model • Easy to understand • Familiar to customers, steps make intuitive sense • ‘Natural’ Structure for new staff or teams • Tight control by project management • Requirements are stable • Forces documentation School of Information Systems & Technology

12. Prototyping • Opposite of the waterfall model • Gets code out very quickly • An elementary version of the system operational earlier School of Information Systems & Technology

13. Prototyping • Evolutionary versus throwaway prototypes • Prototyping takes advantage of high level languages, sacrifices efficiency for speed • Great when few initial requirements • Danger of feature creep • Documentation, performance of final system may suffer - perceived lack of discipline • Customer and management may think it is done • Quality can go either way • Requires experienced developers School of Information Systems & Technology

14. Incremental • Functionality of system is delivered in small increments • “prototyping + waterfall” • Useful with small staff • Not good when delivery is expensive School of Information Systems & Technology

15. Rapid Application Development (RAD) • Incremental development • Focus is on time to market • JRPs (Joint Requirements Planning) • JADs (Joint Application Design) • Product developers are SWAT (Skilled with Advanced Tools) team School of Information Systems & Technology

16. Rapid Application Development (RAD) • Customer involvement • Tools reduce cycle time • Rapid Development of product • Requires highly skilled developers School of Information Systems & Technology

17. Agile (SCRUM) • Key concept in agile methodologies Agility is a way of life in a constantly emerging and changing response to business turbulence – Improvise – Trusting in one’s ability to respond rather than trusting in one’s ability to plan – Focus on individuals and self adapting their own processes – Collaborative values and principles - human dynamics, may be the “soft” sciences but they are the hardest! – Barely sufficient methodology - programming usually adds value, process management usually adds overhead School of Information Systems & Technology

18. Agile (SCRUM) • Scrum is not an acronym • Backlog • A dynamic set of product features • Sprints • A set of backlog items that can be done in a predefined timebox (30 days) School of Information Systems & Technology

19. Agile (SCRUM) • Step #1: Get Your Backlog In Order • Create the Product Backlog • Prioritize the Backlog • Step #2: estimate your product backlog • Estimate Product Backlog in Points -High level estimate using a point system such as Fibonacci number • Step #3: Sprint Planning/clarify requirements • Call a Sprint Planning meeting • Decide Your Sprint Duration • Select Target Backlog for Sprint • Clarify Sprint Requirements School of Information Systems & Technology

20. Agile (SCRUM) • Step #4: Sprint Planning/estimate tasks • Breaking the requirements into tasks and estimating the hours required to complete them • Step #5: Create a collaborative workspace • High level plans/roadmaps, key dates, design discussions, sketches of functionality, issues log, ideas, stats, status reports, topical posters, etc, etc. • Step #6: Sprint! • the team Sprints to achieve the Sprint Goal they committed to during the planning stages • The timeframe - in this case the Sprint Duration - is fixed. Done means done. School of Information Systems & Technology

21. Agile (SCRUM) • Step #7: Stand up and be counted! • Daily scrum. Scrum daily meetings • 15 minutes of status report • What did you do since the last meeting? • What obstacles are you encountering? • What do you plan to accomplish by the next team meeting? • Step #8: Track progress with a daily burndown chart • The burn down chart is a publicly displayed chart showing the number of tasks remaining for the current sprint or the number of items on the sprint backlog. School of Information Systems & Technology

22. Agile (SCRUM) • Step #9: Finish when you said you would • Time waits for no man! • All changes must be reversible to ensure your software is always in a shippable state, even when you have multiple streams of development (e.g. live bug fixes alongside major project) on the go at the same time. • Finish when you said you would • Step #10: Review, reflect, repeat... School of Information Systems & Technology

23. Development Planning • Who will do what? • What will be done and what do you depend on? • When will it be done? • Where will it be done? • Why will you do it? • How will you do it? School of Information Systems & Technology

24. Development Planning • Who will do what? • What will be done and what do you depend on? • When will it be done? • Where will it be done? • Why will you do it? • How will you do it? School of Information Systems & Technology

25. Maintenance • Fix bugs • Add features • Improve structure and maintainability School of Information Systems & Technology

26. Development Best Practices • Limit use of COTS • Don’t use new, untested software or technology • Reuse, Reuse, Reuse • Self Documenting Code • Intention Revealing Interfaces • Adhering to Object Orientation Priciples School of Information Systems & Technology

27. Questions? Questions? School of Information Systems & Technology