chapter 12 Flashcards

1
Q

software development life cycle (SDLC)

A

a process of developing a program, set out in defined stages. the five stages are analysis, design, coding, testing, and maintenance.

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

analysis

A

the problem is clearly defined, and a solution is planned. a program specification is produced. you decide on how to solve the program (top-down or bottom-up)

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

design

A

an identifier table is created, showing variable names, data types & explanations/descriptions. data structures are defined. the algorithm is planned using pseudocode, flowcharts and structure charts and the program is split into its modules

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

coding

A

you choose a suitable high-level language and create code and programs for each module.

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

testing

A

uses a variety of testing strategies to ensure the program works as stated in the specification. eliminates syntax, logic and run-time errors. dry runs, test plans and trace tables are created

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

maintenance

A

occurs once the program is in full operation i.e. during use and ensures it continues to work correctly. deals with software upgrades, bug fixes, and repairs. there are three types of maintenance: adaptive, corrective, and perfective

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

three development models

A

waterfall, iterative, RAD

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

waterfall

A

linear, sequential model of development. Each stage is completed and signed off before the next stage begins. Fully documented at each stage.

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

iterative

A

development starts with a small subset of program requirements, and repeated reviews are used to identify further requirements until a complete program is eventually made. stages 2-3 are repeated.

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

rapid application development (RAD)

A

developing different parts of the program in parallel by teams of programmers. uses prototyping and high customer involvement

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

finite state machine

A

A finite state machine (FSM) is a machine that consists of a fixed set of possible states, inputs to change the states, and a set of outputs.

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

state transition diagram

A

state-transition table gives information about inputs and events
* states are represented as circles
* transitions are represented as arrows
* events are represented as arrow labels
* stopped state is indicated by a double circle

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

accepting state

A

state a system reaches when input is valid

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

event

A

something that can happen in a system that may trigger the transition to another state

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

guard

A

condition a condition that must be met for a transition to occur

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

state

A

value/position of a system at a given point

17
Q

transition

A

change from one state to another

18
Q

structure chart

A

a structure chart is a graphical representation and modelling tool used to decompose a problem into smaller sub-tasks.
* module = one box
* conditional statement shown by a diamond
* parameters are shown by arrows pointing to the module receiving a parameter
* a filled-in arrow shows a boolean value
* repetition is shown by a curved arrow

19
Q

how to derive the pseudocode from a structure chart:

A
  1. create an identifier table
  2. declare constants & variables in pseudocode
  3. create the pseudocode for each module. include the answers to all calculations.
20
Q

syntax error

A

an error in which a program statement does not follow the rules or grammar of a programming language

21
Q

logic error

A

error in the logic of a solution that causes it not to behave as intended

22
Q

run-time

A

error an error that causes program execution to freeze or crash due to invalid operations and extreme conditions. includes:
* arithmetic errors e.g. division by zero, negative roots
* overflow errors (variable holds a value too large
* stack overflow (no more space on a stack)
* library

23
Q

ways to minimise errors

A
  • use extensively tried & tested library routines
  • use modular programming → breaks down a problem into sub-tasks
  • use good programming practice:
    1. sensible variable names
    2. white space
    3. indentation
    4. comments
  • IDE features such as type-checking, auto-complete, debugging(variables, expressions and report window, single stepping, breakpoints), dynamic syntax checks, context-sensitive prompts
24
Q

stub testing

A

a stub is a simple module, which is written to replace each sub-routine. stub testing is used before the code is fully completed.

25
Q

integration testing

A

individually tested modules are joined to one program and tested to ensure modules interact correctly.

26
Q

black-box testing

A

compares actual results when a program is run to the expected results, and tests if programs meet specific requirements. test data is devised - normal boundary and extreme.

27
Q

white-box testing

A

tests every path and every line of code using suitable test data. tester views the code

28
Q

alpha testing

A

software is tested in-house by dedicated testers (programmers pretend to be users)

29
Q

acceptance testing

A

checks if the program performs as needed by customers before sign-off. acceptance criteria is set and end-user feedback is used to ensure the criteria is met.

30
Q

beta testing

A

final stage of testing before release. Users test it under realistic conditions, and feedback is obtained. problems are reported to the developer and are addressed + corrected.

31
Q

corrective maintenance

A

correcting identified errors, usually due to a logic or run-time error. earlier corrective maintenance may introduce errors

32
Q

adaptive maintenance

A

amending a program to enhance functionality or in response to specification changes. the program may perform a function it was not originally designed to do

33
Q

perfective maintenance

A

modifying a program to improve performance or maintainability - streamlining it. the program runs satisfactorily, but there is still room for improvement