1 / 27

IT 450 - Introduction

IT 450 - Introduction. Unit 4. School of Information Systems and Technology (IST ). Agenda. Administrivia Software Development Software Development Process Software Development Best Practices. Administrivia. My name - Imroz Khan My email - ikhan@kaplan.edu My AIM handle - imr 0 zkhan

gaurav
Download Presentation

IT 450 - Introduction

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

More Related