Design approaches the Waterfall Model. COSC345 Software Engineering

Transcription

1 Design approaches the Waterfall Model COSC345 Software Engineering

2 Outline Why software development models Previous manufacturing models Defining waterfall Redefining waterfall Top down versus bottom up design!2

3 Software development models Software developed in teams needs management Discussed in the earlier project planning lecture Initial plans will not be perfect they face missing information Resource allocation e.g., people; infrastructure Timeline estimation informs resource allocation Risk management Separation of concerns between actual coding and project management Skill sets are different!3

4 Previous manufacturing models Most forms of engineering consume physical resources Civil engineers build bridges that don t collapse often Staff of different types are scheduled into construction plans When industrial-scale software development began made sense to try to employ manufacturing models Well better than having no idea what to do Seeking homogeneity for project plans Although software is very heterogeneous by nature!4

5 Waterfall model Five stages progress in order within project Named due to progress from stage to stage appearing to operate like a waterfall The stages are not to scale in terms of time taken on each May be worth considering that waterfalls can be rather destructive, in practice Image from Wikipedia by Peter Kemp / Paul Smith CC BY 3.0!5

6 Stage 1: Requirements capture We will discuss requirements capture in a future lecture Crucially important for any engineering project Almost certainly the first stage of any project Ideally involves internal planning and discussion with clients Dilbert cartoons critique software development models Teams refusing to progress from requirements stage or A system with requirements too complex for users to be able to understand it? Just add an easy to use requirement!6

7 Stage 2: Design Take concepts relating to software behaviour and begin to frame them relevant to software engineering effort Models of software functionality: e.g., components, OO, Schemas of data: e.g., database ER, or OO again Business logic: e.g., database triggers, business rules UML diagrams can model many aspects of software Class diagrams methods, fields, inheritance, composition Sequence diagrams how do components interact? Many others!7

8 Stage 3: Implementation Dev. teams are tasked with writing various software components based on provided specifications Software components need to be integrated (CI?) Documentation is created ideally this is integrated into the code itself In contrast to implementation needs within CS papers, it is likely that coding is only a third of project timeline!8

9 Stage 4: Verification Removing defects from the system debugging At first this may be done between the project teams May relate to problems with component integration Eventually bug reports will come from end users Very likely that there will be requirements mismatch Software will be tested in possibly unforeseen ways What about test-driven development? Unit test engineering allows debugging during implementation!9

10 Stage 5: Maintenance Why? Almost all code projects evolve features This is one reason that software has a version number ( but what version is Google Docs? What does this imply?) Repeat small-scale version of software development model e.g., can probably have a shorter requirements gathering stage Software and hardware dependencies can change e.g., library or operating system upgrades (Recall the Go language s solution to library versioning.)!10

11 Waterfall model for software development Really, it now seems that it s more of an anti-model A model against which improved models are advertised but also a model you are likely to be assumed to know about! The forward-only flow of the process causes inflexibility Can make sense when reworking earlier stages is expensive but that s not the case for software engineering Risk needing to make each linear stage very expensive + slow!11

12 Many software components already exist Earlier software development models from past era more likely that a software project would be self-contained Reliance on frameworks and other components can speed development time however problems may emerge at integration time e.g., design phase may have misunderstood aspects of API!12

13 Augmented Waterfall Models Try to address obvious failings of the Waterfall Model: overlap the five phases of the original model; apply phases to sub-projects of the main project; Winston W. Royce often credited for Waterfall Model but his model understood the value of feedback; suggested that the phases should be passed over twice; and was explicit in the value of prototypes to effective engineering prototyping tools can be extremely rich and powerful!13

14 Top-down versus bottom-up design Top-down design considers abstract components first refine design into subcomponents progressively eventually reach the level of code components e.g., procedural PLs: use stub modules; later implement stubs Bottom-up design writes lower-level components first progressively create overall system e.g., object-oriented PLs: can make classes independently Neither works entirely on its own though!14

15 Top-down versus bottom-up design Applying either design process rigidly has risks: Top-down design can cause reimplementation when decomposition is not steered toward existing components Bottom-up design can lead to components that do not interface cleanly with other (unforeseen) parts of a system GUI programming often requires a hybrid approach Interface implementation is often top-down in GUI builder Application s persistence of state through bottom-up objects!15