system development life cycle


Published on

Published in: Education, Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

system development life cycle

  1. 1. Chapter 2: Systems Development Life Cycle
  2. 2. Traditional Systems Development Life Cycle (SDLC) • These early systems were implemented primarily by computer programmers who neither were not necessarily good communicators nor understood the user’s requirements. Their main expertise lay in the technological aspects of the systems. Standard practices and techniques were not in general use leading to an ad hoc approach to each project.
  3. 3. Traditional Systems Development Life Cycle (SDLC) • Problems associated with these developments were: • Difficulties in the communication of user needs to system developers • Developments were frequently delivered late, over cost and did not meet the users needs
  4. 4. Traditional Systems Development Life Cycle (SDLC) • Projects were viewed as short term solutions rather than long-term, well-planned implementation strategies for new applications. • Changing the system was problematic and generally introduced new problems into the system. Therefore it appeared to take an inordinately long time to make relatively trivial changes.
  5. 5. 2.2 Software Development Life Cycle • It is the series of steps used to manage the phases of development for an information system. Phases are not necessarily sequential. Usually each phase/step has a specific outcome and deliverable.
  6. 6. Software Development Life Cycle – There are six phases under this model. • Requirements Definition • Feasibility Study • System Analysis • System Design • Implementation • Review & Maintenance
  7. 7. Business Problem Definition • 1. Business Problem Definition. (Sometimes known as Requirements Definition) is the job of identifying and describing what is required of the new information system i.e. it provides the terms of reference for the development process. Techniques used in this stage include interviews and questionnaires.
  8. 8. Business Problem Definition Specify Terms of Reference - giving a brief outline of: -What areas the system is to cover -What will be included -What will NOT be included Propose a Feasibility Study, indicating: -How long it will it take to produce -Who will produce it -A deadline (i.e.: the date by which it is expected)
  9. 9. Feasibility Study • 2. Feasibility Study is an investigation of alternative solutions to the business problem with a recommended solution chosen out of the alternatives. The technique of cost benefit analysis is used in this stage.
  10. 10. Feasibility Study – The purpose is to decide whether the proposed system is feasible usually in terms of economics (since most things are now technically feasible). To give estimates of: • Development costs • Development timescale • Running costs
  11. 11. Feasibility Study – The methods used during phase are Observation; Interviews and Professional judgment. The deliverables at this stage are: • Feasibility Report to sponsor • Project Plan • Costs and Benefits • The go-ahead or otherwise.
  12. 12. Systems Analysis 3. Systems Analysis is the detailed investigation and analysis of the requirements of a system to fulfill a given business problem. The techniques used in this stage include: • Dataflow diagrams • Entity modeling
  13. 13. Systems Analysis • The deliverables at this stage are: • Requirements Report • Revised Project Plan • Revised Costs and Benefits
  14. 14. Systems Design 4. Systems Design is the process of constructing a design for a system to fulfill a given business requirement. The techniques used in this stage include: • Dataflow diagrams • Entity modeling
  15. 15. Systems Design • The deliverables are: – System/software Specification – Database Definition – Training Manuals – Hardware Specifications (if relevant) – Revised Project Plan – Revised Costs and Benefits
  16. 16. Testing. Testing. There are 6 types of testing that are performed. a) Unit testing - testing of individual modules b) Link testing - testing of communications between modules c) System testing - testing of the system as a whole d) Volume testing - testing that the system can cope with the anticipated volumes of data. e) User-acceptance testing - letting the users try the system. f) Regression testing - used during the maintenance phase to ensure that changes do not corrupt other parts of the system.
  17. 17. Implementation Implementation. Actually implementing the live system. There are four methods of implementing a system a) Direct changeover - scrap the old system and start using the new system immediately. b) Parallel running - running both the old system and the new system until the new system has ‘proved itself’. c) Pilot - implementing the whole system in just a part of the organization or part of the system in the whole organization. d) Phased implementation - implementing the system in stages. E.g. for an integrated ledger package we might implement just the sales ledger first, then at a later date implement the purchase ledger and then later still the nominal ledger.
  18. 18. Post-implementation Review • Post-implementation Review. After 6 months or 12 months the implementation and performance of the system is reviewed to determine how successful the exercise has been.
  19. 19. Maintenance. • Maintenance. Enhancements, error corrections and minor changes are made to the system until we reach the point where the system becomes obsolete and then we start the whole systems lifecycle again with a new business problem definition.
  20. 20. Potential weakness of Traditional SDLC – Although this approach represents a significant improvement over earlier more ad hoc approaches there are, at least potentially, some serious limitations to the SDLC. These criticisms can be summarized as follows:- • Failure to meet the needs of management • Instability • Inflexibility • User dissatisfaction • Problems with documentation • Lack of control • Incomplete systems • Maintenance workload
  21. 21. Approaches to Systems Development (Alternatives to SDLC) The traditional SDLC has been used, and is still being used, as the basis of development process models. There are a number of suggested general models (or development process paradigms). Other models which are used include: • PROTOTYPING. • Rapid Application Development (RAD) • Joint Application Design • 4th Generation Techniques
  22. 22. Prototyping Prototyping in systems development is the process of creating a 'cut-down' version, or part, of a system so that users can: • Get an idea of what the system will offer; and • Provide feedback on whether the system is what is required. Prototyping helps to identify misunderstandings between 'users' and software developers; and may detect missing (i.e.: not yet specified) user requirements.
  23. 23. Prototyping A prototype is: 1. An original or model after which anything is formed; 2. The first thing or being of its kind;
  24. 24. Advantages of prototyping stage • Identification of misunderstandings between 'users' and software developers; • Detection of missing user services • Identification of difficult-to-use or confusing user services • Requirements validation aid (discovering inconsistencies) • Early availability of a working (limited) system • May serve as basis for specification for a 'production quality' system
  25. 25. Possible 'dangers' of prototypes • prototype may become basis of implementation (but lacks safety- critical features) • May be used as basis for contract with s/w engineer (s) e.g.: 'build one like this' - no legal standing. • non-functional requirements cannot be adequately expressed • omission of functions in prototype may mean prototype not used in same way as fully operational system • AND may encourage inadequate problem analysis Prototyping is seen sometimes as representing 'unacceptably large proportion of system development costs
  26. 26. Rapid Application Development (RAD) A new (in 1997) development strategy called Rapid Applications Development (RAD) is already being used. RAD makes use of: • Well organized and structured group meetings which must have representatives of the Client and Users (see the triangle diagram below). The user representatives must be authorized to make decisions; • Small teams using Computer Aided Software Engineering tools (CASE). The team usually includes user representatives (or works with ready access to users.) • Similar to waterfall but uses a very short development cycle than, for example, the traditional lifecycle process.
  27. 27. Rapid Application Development (RAD)
  28. 28. Rapid Application Development (RAD) – • Uses component based construction and emphasis reuse and code generation – • Use multiple teams on scaleable projects – • Requires heavy resources – • Require developers and customers who are heavily committed – • Performance can be a problem – • Difficult to use with new technology – • Utilizes prototyping to delay producing system design until after user requirements are clear
  29. 29. Joint Application Design (JAD) • Users, Managers and Analysts work together for several days • System requirements are reviewed • Structured meetings
  30. 30. Consideration in choosing a Methodology i. Nature of the project development – whether it is a software maintenance project or an embedded product development. ii. Size of your organization, the project and the team. iii. Structure of your team – whether it is in house or geographically distributed.
  31. 31. Cont….. iv. Alignment with your organization’s stage of business and its business strategy – whether your organization is a startup with a new product launch or an established enterprise that is releasing a new product feature v. The industry of your business, as different industries may have very different software development needs and objectives
  32. 32. Cont….. vi. Culture of your organization – whether the teams are used to the collaborative work culture or not, as adopting some SDLC methodologies demands collaborative work culture vii. Engineering capabilities of your developers. viii. Complexity of project.