system development life cycle
TRANSCRIPT
![Page 1: system development life cycle](https://reader035.vdocument.in/reader035/viewer/2022070314/554cbbb5b4c905aa608b5229/html5/thumbnails/1.jpg)
Chapter 2:
Systems Development Life Cycle
![Page 2: system development life cycle](https://reader035.vdocument.in/reader035/viewer/2022070314/554cbbb5b4c905aa608b5229/html5/thumbnails/2.jpg)
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.
![Page 3: system development life cycle](https://reader035.vdocument.in/reader035/viewer/2022070314/554cbbb5b4c905aa608b5229/html5/thumbnails/3.jpg)
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
![Page 4: system development life cycle](https://reader035.vdocument.in/reader035/viewer/2022070314/554cbbb5b4c905aa608b5229/html5/thumbnails/4.jpg)
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.
![Page 5: system development life cycle](https://reader035.vdocument.in/reader035/viewer/2022070314/554cbbb5b4c905aa608b5229/html5/thumbnails/5.jpg)
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.
![Page 6: system development life cycle](https://reader035.vdocument.in/reader035/viewer/2022070314/554cbbb5b4c905aa608b5229/html5/thumbnails/6.jpg)
Software Development Life Cycle
– There are six phases under this model. • Requirements Definition • Feasibility Study • System Analysis • System Design • Implementation • Review & Maintenance
![Page 7: system development life cycle](https://reader035.vdocument.in/reader035/viewer/2022070314/554cbbb5b4c905aa608b5229/html5/thumbnails/7.jpg)
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.
![Page 8: system development life cycle](https://reader035.vdocument.in/reader035/viewer/2022070314/554cbbb5b4c905aa608b5229/html5/thumbnails/8.jpg)
Business Problem DefinitionSpecify 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)
![Page 9: system development life cycle](https://reader035.vdocument.in/reader035/viewer/2022070314/554cbbb5b4c905aa608b5229/html5/thumbnails/9.jpg)
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.
![Page 10: system development life cycle](https://reader035.vdocument.in/reader035/viewer/2022070314/554cbbb5b4c905aa608b5229/html5/thumbnails/10.jpg)
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
![Page 11: system development life cycle](https://reader035.vdocument.in/reader035/viewer/2022070314/554cbbb5b4c905aa608b5229/html5/thumbnails/11.jpg)
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.
![Page 12: system development life cycle](https://reader035.vdocument.in/reader035/viewer/2022070314/554cbbb5b4c905aa608b5229/html5/thumbnails/12.jpg)
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
![Page 13: system development life cycle](https://reader035.vdocument.in/reader035/viewer/2022070314/554cbbb5b4c905aa608b5229/html5/thumbnails/13.jpg)
Systems Analysis
• The deliverables at this stage are: • Requirements Report • Revised Project Plan • Revised Costs and Benefits
![Page 14: system development life cycle](https://reader035.vdocument.in/reader035/viewer/2022070314/554cbbb5b4c905aa608b5229/html5/thumbnails/14.jpg)
Systems Design4. 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
![Page 15: system development life cycle](https://reader035.vdocument.in/reader035/viewer/2022070314/554cbbb5b4c905aa608b5229/html5/thumbnails/15.jpg)
Systems Design
• The deliverables are: – System/software Specification – Database Definition – Training Manuals – Hardware Specifications (if relevant) – Revised Project Plan – Revised Costs and Benefits
![Page 16: system development life cycle](https://reader035.vdocument.in/reader035/viewer/2022070314/554cbbb5b4c905aa608b5229/html5/thumbnails/16.jpg)
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.
![Page 17: system development life cycle](https://reader035.vdocument.in/reader035/viewer/2022070314/554cbbb5b4c905aa608b5229/html5/thumbnails/17.jpg)
ImplementationImplementation. 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.
![Page 18: system development life cycle](https://reader035.vdocument.in/reader035/viewer/2022070314/554cbbb5b4c905aa608b5229/html5/thumbnails/18.jpg)
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.
![Page 19: system development life cycle](https://reader035.vdocument.in/reader035/viewer/2022070314/554cbbb5b4c905aa608b5229/html5/thumbnails/19.jpg)
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.
![Page 20: system development life cycle](https://reader035.vdocument.in/reader035/viewer/2022070314/554cbbb5b4c905aa608b5229/html5/thumbnails/20.jpg)
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
![Page 21: system development life cycle](https://reader035.vdocument.in/reader035/viewer/2022070314/554cbbb5b4c905aa608b5229/html5/thumbnails/21.jpg)
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
![Page 22: system development life cycle](https://reader035.vdocument.in/reader035/viewer/2022070314/554cbbb5b4c905aa608b5229/html5/thumbnails/22.jpg)
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.
![Page 23: system development life cycle](https://reader035.vdocument.in/reader035/viewer/2022070314/554cbbb5b4c905aa608b5229/html5/thumbnails/23.jpg)
Prototyping
A prototype is: 1. An original or model after which anything is
formed; 2. The first thing or being of its kind;
![Page 24: system development life cycle](https://reader035.vdocument.in/reader035/viewer/2022070314/554cbbb5b4c905aa608b5229/html5/thumbnails/24.jpg)
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
![Page 25: system development life cycle](https://reader035.vdocument.in/reader035/viewer/2022070314/554cbbb5b4c905aa608b5229/html5/thumbnails/25.jpg)
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
![Page 26: system development life cycle](https://reader035.vdocument.in/reader035/viewer/2022070314/554cbbb5b4c905aa608b5229/html5/thumbnails/26.jpg)
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.
![Page 27: system development life cycle](https://reader035.vdocument.in/reader035/viewer/2022070314/554cbbb5b4c905aa608b5229/html5/thumbnails/27.jpg)
Rapid Application Development (RAD)
![Page 28: system development life cycle](https://reader035.vdocument.in/reader035/viewer/2022070314/554cbbb5b4c905aa608b5229/html5/thumbnails/28.jpg)
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
![Page 29: system development life cycle](https://reader035.vdocument.in/reader035/viewer/2022070314/554cbbb5b4c905aa608b5229/html5/thumbnails/29.jpg)
Joint Application Design (JAD)
• Users, Managers and Analysts work together for several days
• System requirements are reviewed • Structured meetings
![Page 30: system development life cycle](https://reader035.vdocument.in/reader035/viewer/2022070314/554cbbb5b4c905aa608b5229/html5/thumbnails/30.jpg)
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.
![Page 31: system development life cycle](https://reader035.vdocument.in/reader035/viewer/2022070314/554cbbb5b4c905aa608b5229/html5/thumbnails/31.jpg)
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
![Page 32: system development life cycle](https://reader035.vdocument.in/reader035/viewer/2022070314/554cbbb5b4c905aa608b5229/html5/thumbnails/32.jpg)
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.