Zusammenfassung der Ressource
Systems Development Lifecycle
- What is the need for it?
Anmerkungen:
- The SDLC gives the developer a specific set of steps to follow when creating a piece of software. Without the SDLC the developer may miss stages out and make unfair assumptions which may mean their program does not solve the problem that it was created to solve.
- STAGE 1: Problem Definiton
- Defines the
aims of the
system.
- Systems analyst is used to
decide how a computer
system could be used to help
solve the problem.
- Systems analyst's job is
to plan and oversee the
installation of a
computer system.
- In order to make sure the the analyst solves the
problem correctly a list of objectives for the
program should be written up. These objectives
are then agreed upon by all of the people
involved in the creation of the system.
- STAGE 2: Feasibility Study
- Once the problem has been defined it must
be decided by the systems analyst as to
whether it is worth making a computer
based solution.
- There are multiple reasons that a
project may not be feasible (not
worth making).
- Solution may not be
technically possible.
- A robotic flying unicorn is
not technically possible.
- The solution may not be
economically possible to create
- If someone working on
minimum wage wanted to buy
a mansion, it would not be
economically possible.
- The solution may not be
economically possible to run.
- If someone working on minimum wage was given
a mansion for free but had to spend hundreds of
thousands of pounds a year for upkeep costs, it
wouldn't be economically possible to run.
- It may not be ethically possible.
- If you have to club 5 baby seals
everytime you want the program to run
it would not be ethically possible.
- The available workforce may not be
skilled enough.
- If McDonalds till software requires the cashier
to solve differential equations then the software
would not be feasible with the skill of the
workforce.
- The software may not make any
noticeable difference to the user's
experience.
- If I wanted to make software that works exactly like
Microsoft Word then would it be worth the time and
money as it would have no noticeable difference?
- The software may not create any tangible
financial benefits for the clients.
- If Facebook add a new feature, is it likely to make them
any more money than if the system wasn't implemented. If
not then is it worth making the changes?
- STAGE 3: Requirements
- Once a problem has been defined and it has
been decided that the problem is feasible the
systems analyst must collect as much
information about the process that they are
designing their software for as possible.
- This information is information the
the analyst needs to understand the
problem that they are trying to solve.
- In order to gain information it is important to question
the employees that will be using the software. Whilst it
might not be possible to question all of them a
representative sample should be chosen.
- There are three main ways that a system analyst may
try and find people's views on the problem that they
have been tasked to solve.
- 1: Interviews
- PROS
- Allows interviewees to talk at
length.
- Allows the interviewer to deviate from the script to ask
follow-up questions about unexpected responses.
- CONS
- Time consuming
- Can't reach as many
people as other
methods can.
- 2: Questionnaires
- PROS
- Gives you views of a
large number of people
very quickly.
- CONS
- Person answering the
question may not be able to
put their full point of view
across..
- Very difficult to design
well.
- Can be difficult to complete questionnaires
if the instructions are not very clear.
- 3: Group meetings
- PROS
- Allows number of people to
discuss points and make their
views known.
- Cuts down on time spent in interviews
getting similar answers from multiple
people.
- CONS
- One or two people tend to dominate
meetings, not allowing everyone to voice their
opinion.
- Some people may not want to announce their
view-points publicly.
- It is important to gain first hand knowledge of
pre-existing software. This can be done in two main
ways.
- 1: By observing the current system in action.
- It has to be taken into account that under observation
the workers are not likely to behave
normally.
- 2: By collecting printed documentation to find
what data is required and in what form the
information is outputted.
- Requirements Specification
- Why is it important?
Anmerkungen:
- Before we go on to the next stage of the SDLC it is important that we know exactly what the requirements of the system is. Whilst this should have been determined by the systems analyst by doing things like meetings and questionnaires (as previously mentioned) it should be written out into a document to make it clear exactly what the system needs. This is what the requirements specification is and aims to do.
- What does it contain?
Anmerkungen:
- It largely contains a list of criteria that there should be in the finished system. This document will be checked to see if the program that is made is the program that was agreed to be designed.
- During this stage one of the things we
should have decided is whether the program needs to
handle data. However there are also several decisions
about how the data in a program should be handled that
should also be discussed.
The main three are:
- 1: The type of data to be held by the program. This
determines the form the data is stored in and the
space that it will require. Knowledge of the specifics
of the data is not necessarily required.
- 2: Calculations of the number of sets of data that are
going to be held will have to be made. This effects the
volume of storage needed which affects the type of
storage that will need to be used to store the
program on.
- 3: How should the data be accessed? Does the data
need to be accessed individually or can it be accessed
all at once. Will the data be changed frequently, if so
when showing the data should the data automatically
refresh? Such decision will again affect the type of
storage device used,
- STAGE 4: Design
- Design Specification
- Before we start considering how the program
looks we should create 3 main documents
- TASK MODEL: List of tasks that will be
needed to complete the system
- DATA FLOW DIAGRAMS: Used to describe systems, and
where the data goes to/from and where it is stored.
Doesn't deal with programming logic just the data.
- SYSTEMS FLOWCHARTS: