Systems Analysis

Question 1

stages of system analysis

Answer 1

analysis, design, implementation, installation, evaluation, maintenance

Question 2

analysis

Answer 2

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)

Question 3

design

Answer 3

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)

Question 4

installation

Answer 4

install and more testing- so weaknesses and omissions arise

Question 5

implementation

Answer 5

coding, documentation (user, system and technical doc) testing and errors traced and corrected

Question 6

evaluation

Answer 6

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

Question 7

modular programming

Answer 7

program divided into separate self contained, specific well defined, tasks which can be WRITTEN and tested individually and subdivided further into smaller modules

Question 8

black box testing (functional testing)

Answer 8

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

Question 9

white box (structural testing)

Answer 9

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

Question 10

alpha testing

Answer 10

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

Question 11

why may programmers have missed something out

Answer 11

not specified carefully enough

developers overlooked/misunderstood

Question 12

beta testing

Answer 12

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

Question 13

what takes place in a post implementation review

Answer 13

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

Question 14

waterfall lifecycle model

Answer 14

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

Question 15

spiral model used for…

Answer 15

large scale projects that take years to deliver where REQUIREMENTS and tech may change

Question 16

spiral model

Answer 16

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

Question 17

agile modelling is used for…

Answer 17

smaller projects

Question 18

agile modelling

Answer 18

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

Question 19

success for agile modelling

Answer 19

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

Question 20

agile programming diagram

Answer 20

requirement gathering–> quick design –> build prototype
^ |
create final system customer eval

Question 21

extreme programming

Answer 21

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

Question 22

extreme programming principles

Answer 22

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

Question 23

rapid application development RAD

Answer 23

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

Question 24

what waterfall is good for and why bad

Answer 24

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

Question 25

spiral model/agile is good because and disadv

Answer 25

-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

Question 26

extreme programming/ RAD is good for and disadv

Answer 26

-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