unit 4 school of information systems & technology1 school of information systems and technology...

Unit 4

School of Information Systems & Technology 1

School of Information Systems and Technology (IST)

AgendaAdministriviaSoftware DevelopmentSoftware Development ProcessSoftware Development Best Practices


Administrivia


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.


Software DevelopmentSoftware Development in theory

RequirementsAnalysisDesignImplementation

Software Development reality


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


GSDP Garage Software Development Process

Code and Fix, Code and FixDone


Waterfall Model


Analysis

Design

Coding

Testing

Integration

Waterfall ModelQuality Gates (Service Gates)Base lining

Requirements SpecificationTest PlanDesign SpecificationCodeTest Results report


Waterfall ModelChange intolerantDocument-drivenCustomer must state all requirements

upfrontFeatures unavailable until implementation

phaseStrong distinction between Development

and Maintenance


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


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

operational earlier


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


IncrementalFunctionality of system is delivered in

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


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


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


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


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)


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


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.


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.


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


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?


MaintenanceFix bugsAdd featuresImprove structure and maintainability


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

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


Questions?


unit 4 school of information systems & technology1 school of information systems and technology...

Documents