chapter 12 Flashcards
software development life cycle (SDLC)
a process of developing a program, set out in defined stages. the five stages are analysis, design, coding, testing, and maintenance.
analysis
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)
design
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
coding
you choose a suitable high-level language and create code and programs for each module.
testing
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
maintenance
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
three development models
waterfall, iterative, RAD
waterfall
linear, sequential model of development. Each stage is completed and signed off before the next stage begins. Fully documented at each stage.
iterative
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.
rapid application development (RAD)
developing different parts of the program in parallel by teams of programmers. uses prototyping and high customer involvement
finite state machine
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.
state transition diagram
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
accepting state
state a system reaches when input is valid
event
something that can happen in a system that may trigger the transition to another state
guard
condition a condition that must be met for a transition to occur
state
value/position of a system at a given point
transition
change from one state to another
structure chart
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
how to derive the pseudocode from a structure chart:
- create an identifier table
- declare constants & variables in pseudocode
- create the pseudocode for each module. include the answers to all calculations.
syntax error
an error in which a program statement does not follow the rules or grammar of a programming language
logic error
error in the logic of a solution that causes it not to behave as intended
run-time
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
ways to minimise errors
- 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
stub testing
a stub is a simple module, which is written to replace each sub-routine. stub testing is used before the code is fully completed.
integration testing
individually tested modules are joined to one program and tested to ensure modules interact correctly.
black-box testing
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.
white-box testing
tests every path and every line of code using suitable test data. tester views the code
alpha testing
software is tested in-house by dedicated testers (programmers pretend to be users)
acceptance testing
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.
beta testing
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.
corrective maintenance
correcting identified errors, usually due to a logic or run-time error. earlier corrective maintenance may introduce errors
adaptive maintenance
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
perfective maintenance
modifying a program to improve performance or maintainability - streamlining it. the program runs satisfactorily, but there is still room for improvement
