Unit 4 School of Information Systems & Technology1 School of Information Systems and Technology (IST)

Agenda Administrivia Software Development Software Development Process Software Development Best Practices School of Information Systems & Technology2

Administrivia My name - Imroz Khan My - My AIM handle - imr 0 zkhan My office hours: TBD Any other time via appointment School of Information Systems & Technology3

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 & Technology4

Software Development Software Development in theory Requirements Analysis Design Implementation Software Development reality School of Information Systems & Technology5

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 & Technology6

GSDP Garage Software Development Process Code and Fix, Code and Fix Done School of Information Systems & Technology7

Waterfall Model School of Information Systems & Technology8 Analysis Design Coding Testing Integration

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

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 & Technology10

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 & Technology11

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

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 & Technology13

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 & Technology14

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 & Technology15

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

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 & Technology17

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 & Technology18

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 & Technology19

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 & Technology20

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 & Technology21

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 & Technology22

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 & Technology23

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 & Technology24

Maintenance Fix bugs Add features Improve structure and maintainability School of Information Systems & Technology25

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 & Technology26

Questions? School of Information Systems & Technology27