Software Engineering Methods Software Development Life Cycle SDLC

Software Engineering Methods Software Development Life Cycle (SDLC) Basics Lecturer: Dr. Ernest Cachia This document © 2003 Dr. Ernest Cachia (C) 2003 - Dr. Ernest Cachia

Some Fundamental Points to Bear in Mind Before We Start n n n SE only effects software development. SE is not one specific method or approach but rather a way of disciplining one's actions. SE is not a panacea. SE cannot be applied blindly and can actually hinder the development process if not used in the right way. n SE does incur substantial overheads in terms of human and organisational effort. n SE practices have been proven valid in many largescale projects (both governmental and private). n Sensible application of SE practices requires formal tuition and practical experience. n (C) 2003 - Dr. Ernest Cachia 2

Why Software Engineering? Maybe the answer can be deduced from some definitions of Software Engineering (SE) in the next slide… (C) 2003 - Dr. Ernest Cachia 3

Some Definitions n n Generic definition: “The building of software systems” (coined in the 1960 s) D. L. Parnas: “The multi-person construction of multi-version software” (conference 1987) q q Software engineering includes programming but is not programming. Therefore…good programmers are not necessarily good software engineers! (C) 2003 - Dr. Ernest Cachia 4

Fundamental Software Engineering Goals n n The final goal of SE has to be to build software systems of demonstrable high quality. In the light of modern software systems, to attain such pretentious aims SE must amongst other things, be able to effectively bring to focus the efforts of more than one individual. (C) 2003 - Dr. Ernest Cachia 5

A Few More SE Aspirations n n n Introduces elements of rigorous discipline to the software development process. Attempts to define software development techniques and guidelines which can then be standardised. Facilitates some of the more mechanical parts of software development. Strives to use software models which are portable over a wide range of environments/platforms. Offer a possible entry point and “common ground” for machine automation of software system development. So, what exactly is a software system? … (C) 2003 - Dr. Ernest Cachia 6

A Software System n n In general, a system is co-operating software and hardware providing a solution for a specific (business or otherwise) problem. Therefore, a software system can be viewed as a software solution to a specific real-world problem. q q n The focus of attention and effort. Generally viewed as one of the main product components of ICT development. So, what are the characteristics of a typical software system? … (C) 2003 - Dr. Ernest Cachia 7

Attributes of Sound Systems n n n They are sophisticated They are structured hierarchically The depth of the hierarchy is subjective (abstraction) The hierarchy is generally made up of recurring components in different arrangements They exhibit stronger cohesion than they do coupling A valid sophisticated system always evolves from a valid simpler version (C) 2003 - Dr. Ernest Cachia 8

Visual Representation of System Characteristics System environment System boundary Inputs The System (What it does) (How is it controlled) (C) 2003 - Dr. Ernest Cachia Feed-back Control Feed-forward System Control Outputs 9

An Unsustainable Situation n On one hand… q q q n People build software systems using no particular method People build fragile software systems People build inaccurate software systems Software system development is expensive Software system development requires considerable planning and effort On the other hand… q q Modern software systems are ever-increasing in sophistication Demands on software systems is always rising Software systems are what make a computing entity People consciously or unconsciously rely on software for most of their social activities (C) 2003 - Dr. Ernest Cachia 10

The Software Crisis n n n The tension created by the conflicting interests outlined in the previous slide gave rise to a software crisis peaking in the late 70 s / early 80 s. The software crisis threatened to cripple the progress of computing as a whole. Effects of the crisis still linger in the form of software development always playing “catchup” to hardware development. (C) 2003 - Dr. Ernest Cachia 11

The Wrongness of Our Ways n Monolithic development is not effective for modern system development. No process control q No product or process guarantees q No true management q No client confidence q No process visibility / traceability q No metrication q No communication => no quality! q (C) 2003 - Dr. Ernest Cachia 12

Breaking the Monolithic Model n n Done by introducing “steps” into the software development process. Steps in the development process are called “phases” (or “stages”). Phases must be self contained and predefined. Phases should decrease abstraction as they progress. (C) 2003 - Dr. Ernest Cachia 13

A Software Development Phase A software development phase: n is a delimited period of time within the process of development of a software system. n has a definite starting set of data and a definite set of results. n is based on the results set of earlier phases. (C) 2003 - Dr. Ernest Cachia 14

Some Advantages of Phased Development n Phased development q q q q Offers benchmarking Offers insight Offers mile-stoning niches Offers a documentation-building framework Offers a definite progression sequence Offers possibilities for prototyping Allows end-user and client participation Offers possibilities for better testing strategies (C) 2003 - Dr. Ernest Cachia 15

A Development Milestone n A software development milestone is a scheduled event… q q n for which some project member or manager is accountable. is used to measure progress. A milestone typically includes: q q q a formal review. the issuance of documents. the delivery of a (sometimes intermediate) product. (C) 2003 - Dr. Ernest Cachia 16

Typical Phases in Software Development Feasibility Requirements Analysis Design (C) 2003 - Dr. Ernest Cachia Feasibility study Strategy planning Implementation Component Elicitation Integration Statement Installation System Operations Detailed Support System Detailed Testing Maintenance Retirement 17

Phases are Neutral and Pliable Feasibility Requirements Maintenance Design Implementation The Life-Cycle Analysis Testing (C) 2003 - Dr. Ernest Cachia 18

Activities During Phases n n n n Requirements: establish the customer’s needs System Design: develop the system’s structure Detailed Design: develop module structures Implementation: code or otherwise Testing: check what’s been developed Installation: bring the system into production Maintenance: correct, adapt, improve (C) 2003 - Dr. Ernest Cachia 19

(C) 2003 - Dr. Ernest Cachia 20

The Development Life-Cycle (aka The Software Development Process) A project is a set of activities, interactions and results. n A life-cycle or a software process is the organisational framework for a project. n (C) 2003 - Dr. Ernest Cachia 21

Life Cycle ANSI / IEEE Standard 729 -1983 n A life-cycle… q q q n is a finite and definite period of time. starts when a software product is conceived. ends when the product is no longer available or effective for use. Any life-cycle is organised in (composed of) phases (C) 2003 - Dr. Ernest Cachia 22

Types of SDLC n n More than one possible life cycle can be adopted to attain a particular goal. The type of SDLC is defined by the way it links the development phases. In theory, any combination of phases is possible, however, in practice only ones that lead to a visible and controllable development process are useful. A type of SDLC is known as a Development Model. (C) 2003 - Dr. Ernest Cachia 23

The Nature of an Effective DM An effective DM is one that: n Effectively links the phases it includes n Focuses phases towards a definite goal n Provides mechanisms for the controlled decrease of system abstraction n Includes definite milestones n Is transparent n Is traceable between adjacent phases (C) 2003 - Dr. Ernest Cachia 24

Development Models n Development model definition (personal): A particular interaction configuration of development phases leading to a final software product. q q q q Waterfall (and Enhanced Waterfall) V-model Evolutionary Prototyping (aka Incremental) Throw-away Prototyping (aka Rapid) Rapid Application Development (RAD) Spiral Research independently Reuse-oriented Formal (aka Transformational) (C) 2003 - Dr. Ernest Cachia 25

The Waterfall Model is the root of all other models n still prevalent in general n exists in many versions n supported by many methods/techniques n Has many drawbacks! (C) 2003 - Dr. Ernest Cachia 26

Fundamental Waterfall Model Properties n Sequential nature q n Transformability q n All phases must happen in a predefined sequence. Any given phase can be directly attributed to the preceding one. Completeness q Any given phase must fully completed before the next phase can be started. (C) 2003 - Dr. Ernest Cachia 27

Waterfall Model Drawbacks n n sequential nature late tangible product maturity q q n late feedback to both customer and developer minimal risk management for both customer and developer late testing maturity (C) 2003 - Dr. Ernest Cachia 28

The V-Model Requirements System Design Detailed Design Acceptance Test Integration Test Module Test Implementation (C) 2003 - Dr. Ernest Cachia 29

Analysis of the V-Model n n Improves testing strategies Does not particularly improve: q q q sequential nature feedback developmental risk management (C) 2003 - Dr. Ernest Cachia 30

The Incremental Model Requirements Global System Design Detailed design Implementation Testing Maintenance (C) 2003 - Dr. Ernest Cachia 31

Analysis of The Incremental Model n n Assumes independent sub-systems. Improves (by delivering smaller units): q q n n feedback (in steps) testing Avoids the production of a monolithic product. Does not particularly improve: q q developmental risk management Sequential nature (still present in sub-systems) (C) 2003 - Dr. Ernest Cachia 32

The (Rapid) Prototyping Model n Goals: q q q to break away from the sequential nature. to speed up feedback. to minimise risks for both customer and developer q q to be incomplete but executable. to be cheap and fast. (C) 2003 - Dr. Ernest Cachia 33

What is Prototyping? n A definition (A. Davis): A prototype is a partial implementation of a system, constructed primarily to enable customer, end-user, or developer to learn about the problem and/or its solution. n Types: q q evolutionary / throw-away horizontal / vertical (C) 2003 - Dr. Ernest Cachia 34

Horizontal Prototyping func. 1 func. n abstract physical (C) 2003 - Dr. Ernest Cachia 35

Vertical Prototyping func. 1 func. n abstract physical (C) 2003 - Dr. Ernest Cachia 36

A Visual Representation of The Throwaway Prototyping Model Requirements specification not acceptable Some minimal development Decision The prototype acceptable Discard prototype Go on with normal system development (C) 2003 - Dr. Ernest Cachia 37

A Visual Representation of The Evolutionary Prototyping Model Requirements specification Some initial development Some more development etc. Prototype version 1 Prototype version 2 Continue till prototype is matured (C) 2003 - Dr. Ernest Cachia 38

Formal (Transformational) Model Transformation Requirements analysis & specification Formal specs Verification (C) 2003 - Dr. Ernest Cachia Integration & testing Optimisation Higher-level specs Tuning 39

Analysis of The Prototyping Model n Improves: q q q n breaks the sequential nature. supports fast feedback. offers an opportunity for risk management. Problems: q has no definite (i. e. strictly defined) organisational structure. (C) 2003 - Dr. Ernest Cachia 40

The Spiral Model This is left up to you to investigate. Use any printed or electronic sources as you deem necessary. However, please be reminded and warned that no amount of plagiarism, small as it may seem, will be tolerated. (C) 2003 - Dr. Ernest Cachia 41

Some Points to Ponder 1. 2. 3. 4. 5. 6. 7. What is Software Engineering? What are the attributes of a good software? What are the key challenges facing software engineering today? Give examples (one in each case) of physical and abstract systems. Explain why, in terms of modelling, physical and abstract systems are not differentiated. Outline the role of documentation as a system component. Why is communication so vital in SD? Give two concrete examples of what can happen in the case of communication breakdown. (C) 2003 - Dr. Ernest Cachia 42

Some More Points to Ponder 1. 2. 3. 4. 5. Differentiate between a software development life-cycle and a software development model. List the main advantages and disadvantages of the Waterfall Development Model. Why are most modern systems built according to one of the prototyping models? Why do you think formal development models are not as popular as other less formal ones? Can you propose a way to improve risk management in software development? (C) 2003 - Dr. Ernest Cachia 43