COSC 310: So*ware Engineering. Dr. Bowen Hui University of Bri>sh Columbia Okanagan

Transcription

1 COSC 310: So*ware Engineering Dr. Bowen Hui University of Bri>sh Columbia Okanagan 1

2 Admin A2 is up Don t forget to keep doing peer evalua>ons Deadline can be extended but shortens A3 >meframe Labs This week: set up team repo Next week: prac>ce choosing SDLC 2

3 So*ware Process Is a set of ac>vi>es that produce so*ware product A structured way of carrying out ac>vi>es E.g., Course registra>on process Course credit transfer process Online payment process 3

4 Fundamental So*ware Ac>vi>es Planning resource alloca>on and management Requirements Specifica>on iden>fies necessary features Design architecture, modules, interfaces Development implementa>on Tes>ng valida>on of correctness Documenta>on describes product Maintenance ongoing error correc>on Evolu>on ongoing requirements changes 4

5 Goals of So*ware Ac>vi>es Clarify steps to be performed Produce tangible work products Enable others to review work products Specify next steps 5

6 Typical Stages of So*ware Development 6

7 So*ware Development Cost 7

8 Scenario 1 Assume: Cost of maintenance is 75% of total cost Cost of development is 25% of total cost If development cost is $250K, what is the maintenance cost? 8

9 Scenario 2 Client asks for accoun>ng informa>on system to be built in order to support 20 users Users all need new computers Client requires so*ware to be completed in 4 weeks Budget is $50K for hardware and so*ware Is this a good deal? 9

10 Scenario 3 Rela>ve cost of fixing errors at various stages are: Specifica>on (3) Design (5) Implementa>on (50) Maintenance a*er deploy (300) If cost to find and fix an error in design is $100, what are the costs for other stages? 10

11 Simple So*ware Process (School work) Read ques>on on assignment Think about it for a few minutes (design?) Start coding compile when done coding Compile get 100+ errors Ditch assignment Resume coding next day can t understand it so restart coding Compile get 50+ errors Ditch assignment again Night before due date: marathon coding Program mostly works submit + never see it again 11

12 Simple So*ware Process (School work) Read ques>on on assignment Think about it for a few minutes (design?) Start coding compile when done coding Compile get 100+ errors Ditch assignment Resume coding next day can t understand it so restart coding Compile get 50+ errors Ditch assignment again Night before due date: marathon coding Program mostly works submit + never see it again 12

13 Simple So*ware Process (School work) Read ques>on on assignment Think about it for a few minutes (design?) Start coding compile when done coding Compile get 100+ errors Ditch assignment Resume coding next day can t understand it so restart coding Compile get 50+ errors Ditch assignment again Night before due date: marathon coding Program mostly works submit + never see it again 13

14 Simple So*ware Process (School work) Read ques>on on assignment Think about it for a few minutes (design?) Start coding compile when done coding Compile get 100+ errors Ditch assignment Resume coding next day can t understand it so restart coding Compile get 50+ errors Ditch assignment again Night before due date: marathon coding Program mostly works submit + never see it again 14

15 Simple So*ware Process (School work) Read ques>on on assignment Think about it for a few minutes (design?) Start coding compile when done coding Compile get 100+ errors Ditch assignment Resume coding next day can t understand it so restart coding Compile get 50+ errors Ditch assignment again Night before due date: marathon coding Program mostly works submit + never see it again 15

16 How to Improve Process? 16

17 How to Improve Process? Ask clarifica>on ques>ons if specs aren t clear Design different solu>ons, consider the best one Repeat: code + test a bit at a >me Clean up code as you go 17

18 Managing Big Projects Complexity grows quickly for large projects Different teams working on different ac>vi>es Necessary to facilitate communica>on Need standardiza>ons and careful management in order to stay within budget and >me Helpful to use CASE tools to support large projects 18

19 Produc>vity Work Analysis (McConnell) Lille alen>on paid to process 19

20 Produc>vity Work Analysis (McConnell) Early alen>on paid to process 20

21 Why Should You Care? As a programmer: Know the lingo Understand the big picture Understand your role Feel less frustrated As a project leader: 21

22 Why Should You Care? As a programmer: As a project leader: Assess risks Choose appropriate process model Have successful project 22

23 Process Management So*ware lifecycle (SDLC) describes the process of so*ware development ac>vi>es Discipline of defining, implemen>ng, maintaining process in a project Adopted/created by PM Measures project progress Ensures correct execu>on of organiza>on s procedures and policies 23

24 Starter SDLC Models Do- un>l- Done Waterfall V- Shaped Rapid Prototyping Rapid applica>on development (RAD) Incremental Spiral Agile Development Scrum XP 24

25 Do- Un>l- Done 25

26 Waterfall (several variants) 26

27 Waterfall (several variants) Need: well understood and stable requirements upfront Easy to plan and staff Itera>ons are costly 27

28 V- Shaped Need: well understood and stable requirements upfront Easy to plan and staff Itera>ons are costly 28

29 V- Shaped Need: well understood and stable requirements upfront Strong emphasis on verifica>on and valida>on Good for systems requiring high reliability 29

30 Rapid Prototyping Models Single hardest part of building so*ware is deciding what to build Challenge for team Devise process that will discover, define, develop real requirements Central idea Create a prototype of so*ware that may require us to throw away at the next itera>on Prototype = easy to build, readily modifiable/extensible, par>ally specified working model of overall system Good approach if system is something new 30

31 Rapid Prototyping Model 31

32 Just a Proof- of- Concept Prototype has limited func>onality Limited func>onality Limited platorm interoperability Need to manage client expecta>ons Non- func>onal requirements not considered Reliability? Performance? Usability? 32

33 When to use Rapid Prototyping? When requirements are ill- understood Too complex Always evolving requirements Medium or high risk projects When only proof- of- concept is needed Suitable for UI intensive systems and research projects O*en used in combina>on with other SDLC 33

34 Three Types of Rapid Prototyping Rapid applica>on development (RAD) Incremental Spiral 34

35 RAD Created by IBM 1980s Quick turnaround >me: ~60 days Users involved in ALL phases Heavy dependence on: Code generators Screen generators Other produc>vity tools More work for users in planning and design 35

36 RAD Model 36

37 When to use RAD Requirements are well- understood Low risk projects where performance and reliability are not an issue Short development >mes High end- user involvement Automated tools available Ex: informa>on system 37

38 Incremental 38

39 Main features of Incremental Does not allow itera>ons Complete system defini>on required in order to create meaningful chunks Divide- and- conquer approach Priori>zes important func>onality 39

40 Spiral Focuses on risk analysis and management Cost Life High- profile missions Takes advantage of strengths from: Waterfall Prototyping Incremental 40

41 Main features of Spiral Reviews (requirements, design, product) Specific deliverables Coding is de- emphasized waterfall Allows users to see system early on Splits large effort into chunks Implement high risk func>ons first prototyping incremental 41

42 42

43 Simplified View of Spiral 43

44 When to use Spiral? Requirements are too complex or evolving Medium to high risk projects New technology or proof of concept only See system early on How many loops? Ex: aerospace (Mars rover), defense apps, engineering projects 44

45 Agile Development Lightweight approach Adapt quickly and painlessly to evolving requirements Use short, frequent itera>ons (~15 days) Highly collabora>ve Does not require PM Self- organizing teams Minimal management Some s>ll use a PM for communica>on purposes Well- known methods: Scrum Extreme programming (XP) 45

46 Major Disadvantages Examples? 46

47 Major Disadvantages Difficult to integrate inexperienced programmers May fall back to cowboy coding Hard to es>mate schedule comple>on Increases risk of scope creep How many itera>ons? Can be inefficient No authority to make decisions 47

48 Scrum 48

49 XP Prac>ces common sense principles to the extreme Follows SE prac>ces that support high quality so*ware Code for today, not for tomorrow Just- in- >me design Emphasize customer involvement Test- driven development Write test stubs first then fill in code Con>nuous integra>on tes>ng Pair programming environment Short itera>ons with fact delivery 49

50 How to choose an SDLC Requirements Defined and stable early on? Is early func>onality a requirement? Project team User involvement Project type/risk 50

51 How to choose an SDLC Requirements Project team Training available? Likely to have changing team members? User involvement Project type/risk 51

52 How to choose an SDLC Requirements Project team User involvement Do they want to be involved? How much? Does client want to track progress? Project type/risk 52

53 How to choose an SDLC Requirements Project team User involvement Project type/risk Funding stable through lifecycle? Reusable components available? 53

54 54

55 55

56 56

57 57