Upload
cori-james
View
214
Download
0
Tags:
Embed Size (px)
Citation preview
Systems Development Systems Development Life Cycle Life Cycle A simplified introduction
You will need to take notes throughout the presentation
Stages of the CycleStages of the Cycle
1. Problem definition2. Feasibility study3. Analysis4. Design5. Implementation6. Maintenance
Why do we need the Why do we need the SDLC?SDLC?The software crisis of the late
‘60s and early ‘70s Systems were delivered years
lateThey were over budgetUnreliableDifficult to maintainDid not do what was required
What does the SDLC do?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.
DeliverablesDeliverablesEach stage has an associated set
of deliverablesSets of documents produced at
each stage in the life cycle
1. Problem Definition1. Problem DefinitionThe 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.
Problem Definition Report – Problem Definition Report – the purposethe purposeTo 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
Problem Definition Report – Problem Definition Report – the sectionsthe sectionsProblemObjectivesScopePreliminary ideasRecommended action
2. Feasibility Study2. 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.
3. Analysis3. AnalysisDeliverable from the analysis stage is the
‘Specification of requirements’Logical model of the required systemStates WHAT the system is to doSays nothing about HOW to implement it Includes
◦ Data flow diagrams◦ Data dictionary◦ Process definitions◦ E/R model◦ Entity life histories or state diagrams
4. Design4. Design
This has two stages:Provides several different
solutions to the problemSelects one solution and specifies
it in detail
Design – Alternative Design – Alternative solutionssolutionsA 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
How solutions may differHow solutions may differSystem boundaries; Automation boundaries; could
remain manual.HardwareSoftwareDesign strategiesUser interfaceCosts
Design – Selecting a Design – Selecting a solutionsolutionSpecification may include:Program design (e.g. structure
charts) and specificationSpecification of the user
man/machine interface Specification of the layout of
reports and other system outputs File and record specificationsHardware specifications,
including costsImplementation schedule
5. Implementation5. ImplementationProgram listings, test plans and
supporting documentationManual of operating proceduresManual of clerical proceduresUser manualHardware on which the system will
runThe 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
6. Maintenance6. MaintenanceStarts as soon as the system is
handed overTerm 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
An example, simplified An example, simplified systemsystem
The System RequirementsThe System Requirements
BackgroundBackgroundErrors 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.
Requirements – what are Requirements – what are they?they?No consensus of opinion as to what
is meant by requirementsSystem requirements - the
client’s needs and wishes. Software requirements -
constraints put on the system development, such as hardware, software and design methods.
Requirements EngineeringRequirements 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).
Different types of Different types of requirementsrequirementsFunctional 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
and2. non-functional requirements arising from
external sources.
Non-functional System Non-functional System RequirementsRequirementsUsabilityPerformanceReliability Security
ElicitationElicitation
This covers several different activities:
Observation of the users at workStudy of relevant documentsUser questionnairesTalking to the people involved in
the system
The Requirements The Requirements SpecificationSpecificationA cornerstone of a system
development projectEncapsulates the shared
understanding and intentions of all the stakeholders
May be used as a vehicle for communication between developers, users and other stakeholders
The Requirements The Requirements SpecificationSpecificationMay 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.
Requirements ValidationRequirements ValidationTechnically 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
Requirements ValidationRequirements ValidationPrototyping 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.
SummarySummaryStage Stage ContentContent DeliverableDeliverable
1.1. Problem DefinitionProblem Definition What is the problem?What is the problem? Problem Definition Report - statement of Problem Definition Report - statement of problems, scope and objectives problems, scope and objectives
objectives of new systemobjectives of new system
2.2. Feasibility Study Feasibility Study Is there a feasible Is there a feasible solution – quick look solution – quick look ahead to see if you can ahead to see if you can do something about the do something about the
problemproblem
Feasibility Study Report - rough cost benefit Feasibility Study Report - rough cost benefit analysisanalysis
- system scope and objectives cost benefit - system scope and objectives cost benefit analysisanalysis
3. Analysis3. Analysis What What must be done to must be done to solve the problemsolve the problem
Specification of Requirements –logical Specification of Requirements –logical model of required systemmodel of required system
4.4. DesignDesign HowHow should the problem should the problem be solvedbe solved
Technical Design Specification –includes Technical Design Specification –includes program specifications, hardware program specifications, hardware specifications, cost estimates and an specifications, cost estimates and an implementation scheduleimplementation schedule
5.5. ImplementationImplementation Do itDo it Working system, includes program listings and Working system, includes program listings and documentation, test plan, hardware, operating documentation, test plan, hardware, operating procedures, clerical proceduresprocedures, clerical procedures
6.6. MaintenanceMaintenance Modify system as Modify system as necessarynecessary
Working system - Operational system, modified Working system - Operational system, modified and documented as requiredand documented as required
TasksTasksUsing 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