Systems Development Life Cycle

1. Systems Development Life Cycle SDLC: A simplified introduction

2. Stages of the Cycle • Problem definition • Feasibility study • Analysis • Design • Implementation • Maintenance

3. Why do we need the SDLC? • The software crisis of the late ‘60s and early ‘70s • Systems were delivered years late • They were over budget • Unreliable • Difficult to maintain • Did not do what was required

4. What does the SDLC do? • Systems Development Life Cycle was an attempt to establish a structured approach to systems development. • For management, each stage of the life cycle was a milestone with an associated date and set of deliverables.

5. Deliverables • Each stage has an associated set of deliverables • Sets of documents produced at each stage in the life cycle

6. 1. Problem Definition • The problem definition forms the basis of the problems and requirements list (see later) • It records all problems and requirements mentioned by clients in interviews, or which are subsequently discovered during analysis of the system.

7. Problem Definition Report – the purpose • To provide a written statement of the user's current problems and requirements; to get agreement with the user. • To ensure that the right problem is being tackled • To force the user to become involved • To define the current state of the system and the required end state

8. Problem Definition Report – the sections • Problem • Objectives • Scope • Preliminary ideas • Recommended action

9. 2. Feasibility Study • Feasibility study - is there a practical solution to the problem outlined in the initial problem definition. • In particular, the feasibility study examines the technical, financial and organisational feasibility of the project: • Can it be done? • Can we afford it? • Will the proposed new system fit in with existing procedures? • Feasibility study report • Presented by the system developer to the user • Decision is made whether or not to proceed.

10. 3. Analysis • Deliverable from the analysis stage is the ‘Specification of requirements’ • Logical model of the required system • States WHAT the system is to do • Says nothing about HOW to implement it • Includes • Data flow diagrams • Data dictionary • Process definitions • E/R model • Entity life histories or state diagrams

11. 4. Design This has two stages: • Provides several different solutions to the problem • Selects one solution and specifies it in detail

12. Design – Alternative solutions • A very cheap solution which does the job and no more. • A medium price solution which does the job well and is convenient for the user; • A high cost, all-singing, all dancing solution

13. How solutions may differ • System boundaries; • Automation boundaries; could remain manual. • Hardware • Software • Design strategies • User interface • Costs

14. Design – Selecting a solution Specification may include: • Program design (e.g. structure charts) and specification • Specification of the user man/machine interface • Specification of the layout of reports and other system outputs • File and record specifications • Hardware specifications, including costs • Implementation schedule

15. 5. Implementation • Program listings, test plans and supporting documentation • Manual of operating procedures • Manual of clerical procedures • User manual • Hardware on which the system will run • The system must be installed at the clients' site on their equipment • Changeover from the old to the new system supervised • Often a hand-holding period

16. 6. Maintenance • Starts as soon as the system is handed over • Term maintenance often euphemism for finding and correcting errors • True maintenance is modifying the system to meet evolving client requirements • System developer must start again at the beginning of the cycle

17. An example, simplified system

18. The System Requirements

19. Background • Errors in requirements may account for approximately 50 per cent of the total cost of debugging a software system. • Many of the traditional system development methods merely pay lip service to identifying, describing and validating the client’s requirements for the system. • Today requirements engineering is recognised as a crucial stage in the development of software.

20. Requirements – what are they? No consensus of opinion as to what is meant by requirements • System requirements - the client’s needs and wishes. • Software requirements - constraints put on the system development, such as hardware, software and design methods.

21. Requirements Engineering Covers three phases: • elicitation (identifying requirements) • specification (describing them in an appropriate language or notation) • validation (checking with the client that the description accurately records his or her needs and wishes).

22. Different types of requirements • Functional requirements: what the system has to do what its inputs and outputs are and how these are linked. • Non-functional requirements: the attributes of the system as it performs its job; can be divided into 1. non-functional requirements of the system and 2. non-functional requirements arising from external sources.

23. Non-functional System Requirements • Usability • Performance • Reliability • Security

24. Elicitation This covers several different activities: • Observation of the users at work • Study of relevant documents • User questionnaires • Talking to the people involved in the system

25. The Requirements Specification • A cornerstone of a system development project • Encapsulates the shared understanding and intentions of all the stakeholders • May be used as a vehicle for communication between developers, users and other stakeholders

26. The Requirements Specification • May form the basis of a legal contract between developer and client • Guides the programmers in their implementation of the system • Desirable qualities of a requirements specification can be found in the IEEE Recommended Practice for Software Requirements Specifications from the IEEE Standard 831–1993.

27. Requirements Validation • Technically feasible to confirm that the requirements specification document is of the desired quality • Not easy to ascertain whether the requirements expressed in the specification are really what the client wants and needs • The client may not know what he or she wants

28. Requirements Validation • Prototyping allows the client and users to get some feeling for how their ideas would work once implemented in a computer system. • Talk through the requirement specification with the client and users.

29. Summary

30. Tasks • Using one or two A4 sides, list each stage of the SDLC, using illustrations and diagrams where appropriate • Present your work in a professional manner, using headers and footers and other advanced formatting options