12 - software development Flashcards
library routines
are pretested functions/procedures ready for use
program development lifecycle
the process of developing a program
analysis, design, coding, testing, maintenance
analysis
investigation as to whagt is needed to be done and specification of what required
design
uses spec to show hwo it shoudl develop
waterfall model
each stage is completed and signed off before the next begins
+ easy to manage/ use
+ stages do not overlap and are completed one at a time
+ each stage has specific deliverables
difficult to change the requirements at a later stage
- not suitable for programs where the requirements could be subject to change
- working program is produced late in the lifecycle
- not suitable for long, complex projects
iterative model
first develop a subset of the requirements then then the cycle again until the full system is developed - repeats waterfalls
+ quick to develop early stage
+ easier to debug smaller programs
+ more flexible
+ customers involved in each iteration
- need to define whole system to break it down
- needs to be good planning
- not for short projects
RAD - Rapid Application Development
- develops different parts in parallel using prototyping to provide early involvement with the user
+ shorter time
+ frequent feedback
+ flexible
+ modification is easier as parts work separately - need to be a modular system
- not for short projects
structure chart
used to decompose a problem into sub tasks
shows a hierarchy of different modules and how they connect via oupits / input
each module is a box and parameters are arrows
finite state machine
can be one of a fixed set of possibile states - states are changes by input
state transition diagram
states are circles
transitions are arrows
events are labelled
conditions can be specified in []
initial state is an arrow with a black dot
the final state is a double cirle
locating errors
- most IDEs flag syntax errors
- logic errors are found in testing
- can single step to find errors or manual work through a trace table
run time errors
happen in the execution of the program
may halt unexpectedly or infinitely loop
test plan
shows all stages of testing and how and when it should be tested
once tested add results to the test plan to show progress
dry run
developer works through program manually wiht a trace table eg though pseudocode
walkthrough
used predefined test cases where another member dry runs the pseudocode to check specific areas eg to test the calc use 20 + 10 = 30
types of test data
normal data - acceptable
abnormal data - rejected
extreme data - on the limit
boundary data - within or just outside limits
white box testing
involves testing the structure and logic of every path through a program
black box testing
test inputs and outputs
integrations
tests seperately written modules work together
stub testing
used dummy modules to test whole code while certain modules aren’t finished yet
eg run whole code and once the add module is called it will output run add module
alpha testing
the completed program is tested in house by the development team
beta testing
tested by a small group of users
acceptance testing
used for the completed program to prove to the customer it works in the required environment
corrective maintenance
correct any errors that appear during use eg run time error missed in testing
perfective maintenance
improve the performance of a program in its use eg improving speed
adaptive maintenance
alter program so it can perform new tasks required by the user eg adding the ability for voice commands as well as text
