Artifact Flashcards
Software engineering
Idea of applying engineering principles to the building of big software products
Software crisis
Phenomenon whereby all too often software is delivered with faults,late,over/or not meeting all the users requirements
Positive testing
Testing that what you intended to change was changed in the desired way
Moving target problem
Occurs when requirements change while the software is still being developed
Scope creep
Succession of small almost tribal requests for additions to requirements
Regression fault
Occurs when a change in one part of the software product induces a fault in an apparently unrelated part of the software product
Regression test
Provides evidence that we have not unintentionally changed something that we did not intend to change
Millers law
At any one time a human is only able to concentrate on 7 chunks of information
Stepwise refinement
Breaking methods down into smaller methods so that you are not working on more than 7 components at a time
Software development
Process of developing software
Separation of concerns
It is broken down into components that overlap as little as possible with respect to their functionality
Divide and conquer
Break a large problem down into sub problems which are easier to solve
Brookes law
Adding a programmer to an already late project makes the project later
Inception phase
Initial version
Elaboration phase
Completed version
Construction phase
Final version
Transition phase
Ready for deployment
Data dictionary
Provides a centralized list of every data item defined in the software product. Helps with consistency and clarity as well as helping with avoiding duplication of the same data item. This then results in fewer faults
Utility
Is the software easy to use?
Reliability
Mean time between failures is long means it’s more reliable
Robustness
A robust product has a wide range of operating conditions including some outside its specifications
Performance
It is crucial to verify that a software product meets its time and space constraints
Correctness
Satisfies output specification without regard for computing resources consumed when operated under permissible conditions
Common for all reviews
Non execution based testing, centred around a meeting of key stakeholders, chaired by SQA representations, meeting is to identify faults not to fix faults in the document
Participants for review meeting
SQA chair
Manager responsible for previous, current, and next workflow
Client representative
Another SQA member
