System complex hole made up of connected parts arranged to work together for a common purpose Logical design defining

system, not building it Physical design convert logical to reality

Phases in development cycle (waterfall model):

1. Problem definition establishing objectives before beginning before beginning project Terms of reference document produced by client and analyst defining limitations, resources available/required, objectives (basis of a contract)

2. Feasibility (preliminary investigation) investigate project in sufficient depth to determining if new system required and if financially worthwhile - Benefits + effects on organisation - Options, adv + dis - Main functions

- Aspects: o Technical not feasible, now possibility due to advances o Social effects on employees + customers o Economic cost affected (development + running {maintenance + consumable} costs) - Software options package may not do exactly what required therefore written - Hardware options only what is needed, not selecte d - Effects on organisation redundancies, new methods of working, people s job change, restructure

- Recommendations options rejected due to too costly, unsuitable for needs, long to implement, disruption - Costs software, hardware, installations, training - Schedule to plan ahead 3. Systems analysis:

Requirements analysis activity of translating information collected during analysis into a document defining a set of requirements reflecting customer wants define, trace, complete, prioritise

Decision analysis identify, analyse, compare, recommend solutions

Methods of fact finding: - Observations spending time seeing at first hand Adv highly reliable, inexpensive Dis alter behaviour, interruptions - Reading documentation - Questionnaires: o Precise/unambiguous questions for accurate responses o Lack of personal contact respondent at ease o Used when only small amount of info required to collect facts Adv cheap, answered quickly Dis simple questions (if wrong answers difficult to clarify info), good questionnaire difficult to prepare - Interviews most common, most useful, who?, when?, what?, where? Adv motivation, probe for more info Dis time consuming, costly, good communication skills Requirements report I/O + data stored, computer + business

procedures required, costs + benefits Documenting results of analysis: - system flowcharts overview of complete system (tasks, devices, media, files) - data flow diagrams (DFD) graphical representation of systems and system components, show functional relationship o external entity data to/from system (square) o data flow movement of data (arrows) o data store data not moving, physical files o process activity/transformation, must have I/O (square with round corners)

Context diagram highest level of DFD, no data stores, used to show the interaction between a system and outside entities + internal data flows

Level 0 DFD

represents a system s major processes, data flows, data stores

Entity relationship diagrams major data modelling tool, help organise data into entities and define their relationship Entity anything abstract to store data Relationship association between 1 or more entities - one-to-one single occurrence of an entity related to just 1 occurrence of a second entity - one-to-many single occurrence of an entity related to many occurrence of a second entity - many-to-many many occurrences of an entity related to many occurrence of a second entity Attribute characteristic common to all or most instances, uniquely identifies 1 instance of an entity (primary key)

4. Systems design developing system specifications (what system should do to meet user needs/how it will work) input, output, storage, processing, security, testing, hardware described by pseudocodes/flowcharts Pseudocode expressing algorithms, no syntax If-then-else Case-of For-do Repeat-until While-do User interface who is using system (experienced users, children), environment, technologically feasible WIMP interface necessary skills easy to grasp, multiple windows Menu systems options displayed possible options for selection, minimal typing; Dis extended hierarchy difficult to follow Screen design title, size, format, colour, default settings, logical sequence, not too cluttered Top-down structured programming breaking down a problem into major tasks, each task further broken down into sub-tasks Adv easy to write (take less time to write + usability), easy to debug (finding + correcting errors), easy to understand (meaningful names + clear documentation), easy to change (easy to read, test and correct) UML (unified modelling language) diagrams show object oriented systems, language independent Class diagrams show classes within a module (class, attribute, operations compartments) Variables visibility name : type ( +:public, -:private, #:protected, <blank>)

Methods visibility name (parameters) : returntypes Inheritance diagram hierarchy

Class relationships 2 classes related by a line and association name Class multiplicity indicate how many objects of one class relate to one object of another class (* - unlimited number of objects, 1..* - one-tomany) Objects diagram object name : class name Instance diagram shows state of one object USE CASE diagram (stick characters) roles of different users (actors), USE case = services, behaviour specifications Structure charts hierarchical tree, show program modules, their purpose + relationships, each module numbered (more easily referred to) Nassi Schneiderman (NS) diagram graphical method of stating algorithms (process, decision, until, while) Jackson structure programming (JSP) divides problem into simple logical symbols of steps, top-down technique, components: Elementary (not subdivided) Sequence (statement follows another) Selection choice available from several alternative (small circle) Iteration repeated 0 or more times (asterisk)

Advantages module programming: Module small unit of code, easier to understand and debug Program maintenance easier, effected modules quickly identified Modules tested independently Program leaves, easier to take over Large project easier to monitor

Hipo chart?

Decision table table of conditions to be considered in analysis of a problem , action to be taken for each condition, contents: - Condition stubs - Action stubs - Rules actions to be taken under a specific combination of conditions Decision trees graphical representation of decision table

Proto-type building working model of a system to evaluate /test it Adv misunderstandings identified (missing functions detected), see what to expect, quickly available to demonstrate feasibility and usefulness of system Dis not ready to use, changes at design stage no actual screen/report

5. Software development - Acquire software (not off-the-shelf written program specifications); test, document and convert system;

Test plan knowledge on what program is supposed to do, what ought to be tested, expected results Test data every statement executed once, every section detecting invalid input verified, every route tried, program operates according to original design specifications

Testing during design stage (dry run), modules, complete system, live data Bottom-up testing each individual module tested using test data (normal, extreme, invalid data)

Top-down testing skeleton of complete system tested with individual modules Unit testing testing each part of the system Black-box testing carried out of the code used in program looking at program specifications (I/O, functions) White-box testing dependant on code logic (do not detect missing functions) Alpha testing In-house Beta testing customers trying out software Integration testing work together when all modules individually tested to ensure they

Data validation

data accepted checked for limits

Data verification checking if data entered correct, re-inputting data twice (check digit)

6. Systems implementation and review install hardware, file conversion, staff training - Making sure new system meets customer specifications - Test system in environment to be run - Major changes in operating procedures needed?

Methods of converging: - Direct changeover stop using old system, start new system at once; adv - fast, minimum duplication of work dis normal operations disrupted due to new system errors - Parallel changeover old system continues alongside new one for weeks/months

adv results checked against known ones dis duplication of effort to keep both systems running - Phased conversion individual modules implemented separately at different times - Plot conversion new system used first by a portion of organisation

User Manual: Guidance of sequence of operations to follow Overview of options available Screen shots of input forms Instructions how to enter data Error messages display and what action to take

Computer operations manual: - System set up - System procedures - Recovering procedures in system failure

7. Systems maintenance and evaluation monitor, evaluate, modify system to continue meeting user needs - Perfective maintenance while system runs satisfactory, improvements - Adaptive maintenance changing needs eg. new gov laws - Corrective maintenance part of system not in function

Maintenance -

greatest costs incurred in system s lifecycle

Good program design Well structured program written Right high-level languages Good system + program documentation When, why, who records of maintenance