Top Banner
Unit 4 School of Information Systems & Technology 1 School of Information Systems and Technology (IST)
27

IT 450 - Introduction

Jan 09, 2016

Download

Documents

Gaurav ubale

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 - [email protected] My AIM handle - imr 0 zkhan - PowerPoint PPT Presentation
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: IT 450 - Introduction

Unit 4

School of Information Systems & Technology 1

School of Information Systems and Technology (IST)

Page 2: IT 450 - Introduction

AgendaAdministriviaSoftware DevelopmentSoftware Development ProcessSoftware Development Best Practices

School of Information Systems & Technology 2

Page 3: IT 450 - Introduction

Administrivia

School of Information Systems & Technology 3

Page 4: IT 450 - Introduction

Seminar GuidelinesPlease 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 typingUse 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 4

Page 5: IT 450 - Introduction

Software DevelopmentSoftware Development in theory

RequirementsAnalysisDesignImplementation

Software Development reality

School of Information Systems & Technology 5

Page 6: IT 450 - Introduction

Software Development Process ModelsSoftware 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 6

Page 7: IT 450 - Introduction

GSDP Garage Software Development Process

Code and Fix, Code and FixDone

School of Information Systems & Technology 7

Page 8: IT 450 - Introduction

Waterfall Model

School of Information Systems & Technology 8

Analysis

Design

Coding

Testing

Integration

Page 9: IT 450 - Introduction

Waterfall ModelQuality Gates (Service Gates)Base lining

Requirements SpecificationTest PlanDesign SpecificationCodeTest Results report

School of Information Systems & Technology 9

Page 10: IT 450 - Introduction

Waterfall ModelChange intolerantDocument-drivenCustomer must state all requirements

upfrontFeatures unavailable until implementation

phaseStrong distinction between Development

and Maintenance

School of Information Systems & Technology 10

Page 11: IT 450 - Introduction

Waterfall ModelEasy to understand Familiar to customers, steps make

intuitive sense‘Natural’ Structure for new staff or teamsTight control by project managementRequirements are stableForces documentation

School of Information Systems & Technology 11

Page 12: IT 450 - Introduction

PrototypingOpposite of the waterfall modelGets code out very quickly An elementary version of the system

operational earlier

School of Information Systems & Technology 12

Page 13: IT 450 - Introduction

PrototypingEvolutionary versus throwaway prototypesPrototyping takes advantage of high level

languages, sacrifices efficiency for speedGreat when few initial requirementsDanger of feature creepDocumentation, performance of final system

may suffer - perceived lack of disciplineCustomer and management may think it is

doneQuality can go either wayRequires experienced developers

School of Information Systems & Technology 13

Page 14: IT 450 - Introduction

IncrementalFunctionality of system is delivered in

small increments“prototyping + waterfall”Useful with small staffNot good when delivery is expensive

School of Information Systems & Technology 14

Page 15: IT 450 - Introduction

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 15

Page 16: IT 450 - Introduction

Rapid Application Development (RAD)Customer involvementTools reduce cycle timeRapid Development of product Requires highly skilled developers

School of Information Systems & Technology 16

Page 17: IT 450 - Introduction

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 abilityto 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 17

Page 18: IT 450 - Introduction

Agile (SCRUM)Scrum is not an acronymBacklog

A dynamic set of product features

SprintsA set of backlog items that can be done in a

predefined timebox (30 days)

School of Information Systems & Technology 18

Page 19: IT 450 - Introduction

Agile (SCRUM)Step #1: Get Your Backlog In Order

Create the Product Backlog Prioritize the Backlog

 Step #2: estimate your product backlogEstimate Product Backlog in Points -High level estimate

using a point system such as Fibonacci number  Step #3: Sprint Planning/clarify requirementsCall a Sprint Planning meetingDecide Your Sprint DurationSelect Target Backlog for SprintClarify Sprint Requirements

School of Information Systems & Technology 19

Page 20: IT 450 - Introduction

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 20

Page 21: IT 450 - Introduction

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 21

Page 22: IT 450 - Introduction

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 22

Page 23: IT 450 - Introduction

Development PlanningWho 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 23

Page 24: IT 450 - Introduction

Development PlanningWho 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

Page 25: IT 450 - Introduction

MaintenanceFix bugsAdd featuresImprove structure and maintainability

School of Information Systems & Technology 25

Page 26: IT 450 - Introduction

Development Best PracticesLimit use of COTSDon’t use new, untested software or

technologyReuse, Reuse, ReuseSelf Documenting CodeIntention Revealing InterfacesAdhering to Object Orientation Priciples

School of Information Systems & Technology 26

Page 27: IT 450 - Introduction

Questions?

School of Information Systems & Technology 27