Systems Analysis Flashcards
stages of system analysis
analysis, design, implementation, installation, evaluation, maintenance
analysis
problem is defined and requirements are established.
data (origin, uses, characteristics, volume) procedures (how errors handled, what where when how), problems with current software, future (development plans and expected growth rates)
design
pseudocode, what will it look like:
inputs (frequency and methods), data structures (how data held and accessed), output (medium and sequence) hardware (appropriate configuration), security (against hacking and corruption, processing (algorithms and modular structure), UI (menus, screens, dialogues)
installation
install and more testing- so weaknesses and omissions arise
implementation
coding, documentation (user, system and technical doc) testing and errors traced and corrected
evaluation
on effectiveness, usability, maintainability: critical examination 3-6mo after, allows staff to learn, get used to and understand software. Air views and discuss improvements and shortcomings by users. Online queries discussed in month end period routine reports
modular programming
program divided into separate self contained, specific well defined, tasks which can be WRITTEN and tested individually and subdivided further into smaller modules
black box testing (functional testing)
carried out independently of PROGRAM CODE and how ALGORITHM works. looks at program SPECIFICATION and creates test data covering all inputs, outputs and program functions. test outputs against expected outputs
white box (structural testing)
dependent on CODE LOGIC and derived from program structure and source code. code is STUDIED and and tests are devised testing every possible path at least once using TRACE TABLES/dry running, but doesn’t detect missing functions. ensures all parts work as intended
alpha testing
testing done within the software company/software developers in-house testing team as the program is being developed, revealing omissions and errors in the SYSTEM REQUIREMENTS DEFINITION. May use emulators. they may take up the role of the users
why may programmers have missed something out
not specified carefully enough
developers overlooked/misunderstood
beta testing
giving package which is not yet finished to potential third party users, agreeing to use and report any problems, exposing it to normal, real use and detects problems and errors NOT ANTICIPATED by developers. sent out when confident after SEVERAL MODIFIED beta versions
what takes place in a post implementation review
assessment of every aspect against preset criteria
discuss errors made during system development
discuss unexpected benefits and problems
compare systems actual performance against anticipated performance
waterfall lifecycle model
input from users at very beginning and end
each step completed INDIVIDUALLY one at a time from beginning and end and each stage provides specific outputs which lead to next stage
can return to previous stage but have to work down in same order
adopted from manufacturing industry where any modification to hardware = cost implications so every stage has to be right before moving on
spiral model used for…
large scale projects that take years to deliver where REQUIREMENTS and tech may change
spiral model
same STRUCTURED steps (analysis, design, implementation, installation, eval, maintenance) but develop in iterative steps UNTIL system is satisfactory
requirements defined at beginning and work towards an initial prototype
each successive loop = refined prototype
agile modelling is used for…
smaller projects
agile modelling
stages aren’t in a linear sequences, different parts can be at different stages and can go back stages = flexible e.g. some parts x whilst others y
feedback from user throughout
enough modelling done at start by software developers to ensure understood by themselves and users well
iterative UNTIL reach what customer wants and changes are incremental IN RESPONSE to customer feedback as next part of system is built
each stage: prototype is built with user participation, ensure built in line with user’s wants
success for agile modelling
rapid feedback from user
kept simple so don’t incorporate features useful at a later date
understanding user’s wants may change during development as consider needs in detail
prepared to make incremental changes during development
agile programming diagram
requirement gathering–> quick design –> build prototype
^ |
create final system customer eval
extreme programming
a form of AGILE development focuses on RESPONSIVENESS to changing customer requirements and improving QUALITY
frequent releases in short development cycles
improve productivity and introduce checkpoints to adopt user requirements
extreme programming principles
only write what you’re doing right now
100% test pass of test produced before development
communication, simplicity e.g. delete iterations, feedback, courage, respect
rapid application development RAD
for very large projects to reduce impact of technological and user requirements changing (because leads to cancellation and restarting of projects at costs) so faster completion:
- workshops and focus groups gathering requirements rather than a formal requirement document
- prototyping continually refining system IN RESPONSE to user involvement and feedback: prototype design of reduced functionality is produced, tested and evaluated. it is refined to create the next prototype repeatedly until it is accepted and the final product is produced.
- producing within a strict time limit each part- not perfect but good enough
- reusing any software components already used elsewhere
what waterfall is good for and why bad
small projects with careful supervision e.g. trainees and students (bad that little user involvement)
quick, small, simple, well defined projects- requirements has to be clearly defined and understood before development and design
disadv: lack of user involvement and poorly understood REQUIREMENTS so finished system is not what is wanted
spiral model/agile is good because and disadv
-acknowledge users can’t specify requirements because don’t understand what is possible. Much easier to examine a working prototype and figure what needs to be done to it for it to be a useful system.
user involvement means both user and developers understand requirements better
-requirements analysed in more detail it allows for changes, more likely to be what user wants
disadv: if constantly making changes then never completed
extreme programming/ RAD is good for and disadv
-good for large projects where danger of getting bogged down or sidetracked by suggested improvements so that developers are continually chasing a moving target
-quicker
-better to examine a working prototype
-users more involved : final system more likely to be whats expected
RAD disadv: final system = compromise- not perfect but does job and created quickly
