1 / 30

Systems Development Life Cycle

Systems Development Life Cycle. A simplified introduction You will need to take notes throughout the presentation. Stages of the Cycle. Problem definition Feasibility study Analysis Design Implementation Maintenance. Why do we need the SDLC?.

armandom
Download Presentation

Systems Development Life Cycle

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Systems Development Life Cycle A simplified introduction You will need to take notes throughout the presentation

  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

More Related