Chapter 2 : Software - Life Cycle Flashcards

(54 cards)

0
Q

Define problem

A

If problem not defined accurately then the wrong

problem will be solved

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
1
Q

The stage of the system life cycle

A

Problem—Feasibility study—Analysis—design—implementation—testing—installation—maintenance

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

The importance of defining a problem accurately

A

Poor defined problem lead to poor solution, unhappy customers don’t get what they want, and unhappy developers won’t get paid.
Correctly defined problem can produce a correct and appropriate solution.
Misunderstanding arise between client and developer. Client understand his business so is unlikely to understand technology as the developer who in turn is unlikely to understand client’s business

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Define feasibility study

A

Decision made as to whether the problem an be solved

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Define information collection

A

Questionnaires, observation, structured interviews and documents

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Define information collection

A

Formulation of requirements specification

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Define solution

A

Design specification created

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

The function of a feasibility study

A

A feasility study should precede any extensive work on a project and is intended to determine whether the problem is actually worth undertaking.
Technical, economic, social, skill level required, legal and time

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Define Technical feasibility

A

Can the problem be solved , can software be written or hardware designed to actual solve the problem

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Define Time feasibility

A

Can the problem be solved in an acceptable time frame

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Define legal feasibility

A

Does the solution infringe any patent or perhaps involve criminal activity

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Define social feasibility

A

Are an unacceptably large number of people are likely to lose their job

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Define Economic feasibility

A

Can the problem be solved at an acceptable price

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Define operational feasibility

A

Is there enough skill in the workforce

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

The importance of determining the information requirements

A

Determining the information requirements of a problem is to provide an acceptable working solution
Questionnaires, observation, structured interviews
Documents

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Advantages of questionnaire

A

It can target quickly a large number of potential users , are relatively simple to create and can cover a variety of topics simultaneously

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Disadvantages of questionnaire

A

Many people dont bother to fill them in , they have a restricted set of questions and these are usually fairly limited in scope

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Advantages of observation

A

To see what actually happens rather than what one is told

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Disadvantage of observation

A

People often behave dart when they are being observed and it can take a long time

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Structured interviews

A

Structured interviews are useful in deciding details of the problem.
If the are one on one they can be very illuminating, but can take a long time
If they are in a group meetings, a lot of data can be gathered quickly, but members can easily dominate discussions

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

Advantages of Documentation

A

Documents can be collected and analysed if well maintained.

Documentation can be invaluable in deciding how the system currently operates

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Disadvantage of documentation

A

Documentation may be incorrect and not up to date thus not accurately reflecting the current state of the system

22
Q

Two different types of documentation

A

Technical documentation

User documentation

23
Q

Importance of documentation

A

Documentation on the new system will have been produced throughout the design process .
Users will need their own documentation which will provide an account of :
how to use the new system
how to handle errors
how to back up the system
how to get further help

24
Example of user documentation
``` Input/output procedures How to operate the system Backing up and archiving FAQ Help available Glossary Contents ```
25
Examples of technical documentation
DFD - shows flow of data through system ERD - shows how data tables relate to each other Flowchart - shows the operations the algorithm System flow chart - shows how parts of system interrelate
26
The maintenance programmers will need a technical manual detailing all of the data structures
``` algorithms flowcharts data flow diagrams entity relationship diagrams code used in the new system ```
27
Define Analysis
Once the information has been collected the information it must be analysed to decide what is relevant to the problem. The analyst will analyse all of the information and create a requirements specification. This details all of the things which the solution is intended to produce. It is important to ensure that the client agrees with this and whether or not it satisfies the problem.
28
Contents of design specification
``` Input design Output design Data design System flow chart Data flow diagram ```
29
Content of requirements specification
``` Input requirements Output requirements Processing requirements Hardware Software ```
30
Requirements Specification
``` A description of what the system does Problem Specification: identifies the existing problems User Manual Technical Manual ```
31
Purpose of user manual
Gives instructions to software users to allow them to successfully explain error messages
32
Purpose of technical manual
Describes how the system works
33
Define design specification
When the analysts finally begins to look at the ideas for a new system. This will include the content, the order and the relationships between the parts of the intended system. Diagrams will be used to represent data flow throughout the new system.
34
Define Data Flow diagrams
It show source of data, data processes, data flows into/out of processes, data stores
35
Define System flowcharts
It show processes to be carried out, hardware and media to be used for storage or IO (input/output), also master and transaction files.
36
Define Jackson Structure Diagram
Top-down design. Break system into components. Shows links between components.
37
Define Implementation
The analyst will now give the designs to a specialist who will produce a solution based on the designs. The specialist may be an expert in a particular data handling methods but they will only follow the instructions of the analyst. If there is a particularly large system to implement more than one specialist may be used. This could have both positive and negative effects.
38
Define evaluation
Once a solution has been produced it must be evaluated to decide whether or not the problem was solved. This could be achieved by testing the aim to show the client that the system works.
39
Define installation
``` The analyst must decide how to install the system into the business. The analyst will need to consider: Purchase of hardware Creation of data files Training of staff Change over from the old system Future maintenance of the system ```
40
Define direct changeover
Old system is stopped new one started usually at a convenient time
41
Define parallel changeover
Old and new run alongside for a period of time results compared
43
Define pilot changeover
New system could be used in a few places initially the results can be compared between new and old system two systems could be compared before "roll-out".
44
Define phased changeover
Each part of the system is changed over separately each part is tested separately may take a long time to changeover the whole system
45
Changeover techniques
Direct changeover Parallel changeover Pilot changeover Phased changeover
46
Example of maintenance
Corrective Adaptive Perfective
47
Define Adaptive
One of the parameters used to set up system has changed eg. the VAT rate changes
48
Define Perfective
During use it is found that one element of the system is not performing as well as it could
49
Define Corrective
Must be corrected to make software usable
50
Define maintenance
All systems need maintenance
53
Define Prototyping
Prototyping is where more than one solution is produced a different stages throughout the software development. This can then be used to redo previous stages or can help with following stages.
54
How prototyping can be used for design progress
Used to research new ideas Used to define prototype Allow manager to be part of the design process
55
Describe the spiral model
Analyst begins by collecting data followed by each of the other stages leading to evaluation Which will lead to a return to data collection to modify The Important point is the different stages are refined each time the spiral is worked through
55
Describe the Waterfall model
Idea of passing from one stage to the next in order Each stage in the life cycle feeds information to the next stage At each stage it may be necessary to return to one or more previous stages either to collect more data to check that it is collected After returning, all the intervening steps must be revisited