Software Processes: Traditional CSCI102 - Systems ITCS905 - Systems MCS Systems

2 Overview Software development models and processes –Waterfall and V- models –Incremental Models and RAD –Evolutionary Models

3 References Bob Hughes & Mike Cotterell (2002) –Software Project Management (3 rd Edition) McGraw-Hill –Chapter 4 –ISBN: X Library Call No – /17

4 Why do we Need to Manage the Software Process? We could just start writing –That seems to work for small assignments What happens when the problem gets big? –More than one person writing code –You need to modify somebody else's code? What if the contact for the client changes –Why did certain decisions get made? –What did the client originally ask for? –What did you base your asking price on? –What did the client originally ask for?

5 What is a Project? One definition –‘a specific design or plan’ To plan, devise, or design to do something

6 What is a Project? Key elements –Non-routine –Specific objectives –Planned –Predetermined timespan –Constrained resources –Work carried out for a third party –Work involves several specialisms or phases –Size and complexity

7 Are Software Projects Really Different From Other Projects? Not really, but: –Invisibility –Complexity –Flexibility –Need to conform to human ideas All add to difficulties

8 What is hard about software? Define concept Implement concept “I believe the hard part of building software to be the specification, design and testing of this conceptual construct, not the labour of representing it and testing the fidelity of the representation”. Frederick Brooks No silver bullet IEEE Computer 20(4) 10-19, April 1987

9 Is software development an engineering activity? One definition of software engineering: –Creating cost-effective solutions to practical problems by applying scientific knowledge to building things in the service of mankind Mary Shaw –But how scientific is software development really?

10 Software engineering or software management? “Unfortunately, [software engineering] is now most often used to refer to life-cycle models, routine methodologies, cost estimation techniques, documentation frameworks, configuration-management tools, quality assurance techniques…. ‘software management’ would be a more appropriate term” Mary Shaw

11 General approach Look at the type of application being built e.g. –Information system? –Embedded system? –Criticality? –Differences between target and development environments? Clients’ own requirements –Need to use a particular method

12 Choice of process models ‘Waterfall’ also known as ‘one-shot’, ‘once-through’ Incremental delivery Evolutionary development

13 Waterfall feasibility study requirements analysis design build test install ‘the waterfall model’

14 Waterfall The ‘classical’ model Imposes structure on the project Every stage needs to be checked and signed off BUT –limited scope for change

15 v-process model feasibility study requirements analysis system design build unit test system test user acceptance software design review corrections Another way of looking at the waterfall model

16 Incremental delivery designbuild install evaluate designbuild install evaluate designbuild install evaluate increment 1 increment 2 increment 3 first incremental delivery second incremental delivery third incremental delivery delivered system

17 The Incremental Process set global objectives global open architecture open incremental plan design the step build the step install the step evaluate the results feedback

18 Incremental Approach: Benefits Feedback from early stages used in developing latter stages Shorter development thresholds –Important when requirements are likely to change

19 Incremental Approach: Benefits User gets some benefits earlier –May assist cash flow Project may be put aside temporarily –More urgent jobs may emerge Reduces ‘gold-plating’ i.e. features requested but not used

20 Possible Disadvantages of Incremental Delivery Loss of economy of scale –Some costs will be repeated ‘Software breakage’ –Later increments might change earlier increments

21 Evolutionary Delivery: Prototyping ‘An iterative process of creating quickly and inexpensively live and working models to test out requirements and assumptions’ Sprague and McNurlin

22 Evolutionary Delivery: Prototyping Main types –‘throw away’ prototypes –evolutionary prototypes What is being prototyped? –human-computer interface –functionality

23 Reasons for Prototyping Learning by doing –Useful where requirements are only partially known Improved communication –Users reluctant to read massive documents –When system is ‘live’ you get a better feeling for it Improved user involvement –User ideas and requests are quickly implemented

24 More Reasons for Prototyping A feedback loop is established –Ensures that the specification is correct Reduces the need for documentation –Debatable? Reduces maintenance costs i.e. changes after the application goes live Prototype can be used for producing expected results

25 Prototyping: Some Dangers Users may misunderstand the role of the prototype Lack of project control and standards possible Additional expense of building prototype Focus on user-friendly interface could be at expense of machine efficiency

26 Summary Approaches to the software process include: –Waterfall –Incremental (RAD) –Evolutionary prototyping

27 Summary A process should be selected after careful consideration of –Any risks and uncertainties –The type of application being built –The clients’ own requirements