System Design


Published on

  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

System Design

  1. 1. SYSTEMS ANALYSIS AND DESIGN Cutajar & Cutajar
  2. 2. INTRODUCTIONSystem analysis and design covers the activities involvedin developing a new system.It is the process of analysing particular systems (scientific, businessor control), to see if replacement (or upgrading) would yield a moreuseful, productive and profitable way of performing the businessoperations.System analysis and design involves System Analysts.System Analysts are deeply involved:- Analyse the data processing requirements of an organisation, in whole or in part; Decide what, in consequence, the computing system should do; Specify the tasks of the computing system in detail, so that the technical specialists (programmers) can do their work; Ensure that the developed computing system works efficiently. SYSTEM ANALYSIS 2
  3. 3. WHAT IS A SYSTEM?A system is a collection of interrelated components that work togetherto achieve some objectiveDifferent components making up a system include: Hardware Software Collection of data Work of a number of people.Different components making up the software component of a systeminclude: inputs processes stored data outputs human communication interface (HCI) SYSTEM ANALYSIS 3
  4. 4. SYSTEM ELEMENTSA commercial or industrial enterprise can be defined interms of system elements: Physical e.g. Buildings, raw materials, finished product; Procedural e.g. Order processing routines, credit checking procedures; Conceptual e.g. Statement of policy, material for products; Social e.g. Workers, departments. SYSTEM ANALYSIS 4
  5. 5. SYSTEM ENVIRONMENTThe system operates in an environment and relates tothat environment, which itself includes various elements.Elements relating to the environment include: Physical e.g. transport routes; Procedural e.g. codes of practice, legal requirements; Conceptual e.g. monetary system, political ideologies; Social e.g. trade unions, suppliers, customers. SYSTEM ANALYSIS 5
  6. 6. SUB-SYSTEMSAn enterprise can be divided into a number ofSUBSYSTEMS defining the functional areas. Theseinclude: Those dealing with the environment: marketing and purchasing subsystems; Those dealing with transformation functions: the production subsystem; Those acting in a supportive role: accounting, personnel, and management services subsystems. SYSTEM ANALYSIS 6
  7. 7. BUSINESS SUBSYSTEMSThese subsystems are all interconnected. The diagram shown is a‘simple’ model of business subsystems:This diagram Invoices Customersillustrates the Accounting OrdersINTERFACES within Payments Marketingthe business, and Financial analysis Budgets Budgetshence the type of Management and plans Deliveries Manpower Controldifficulty that can analysis Budgets Schedules Staffingarise in defining required Personnel Productionboundaries. Goods OrdersHenceforth the Purchasingdifficulties of the Purchases Orders Goodssystem analyst to Paymentsanalyse, design, Suppliershelp implement Deliveriesand review. SYSTEM ANALYSIS 7
  8. 8. OBJECTIVES OF COMPUTERISATIONTo reduce costsTake advantages of the facilities offered by computersTo increase volume of businessBetter management of informationEnable long-term forecastsEnable better planning. SYSTEM ANALYSIS 8
  9. 9. TYPES OF DATA PROCESSING SYSTEMS1. Systems where processing is done periodically (Batch Systems or File Processing Systems) Large volume of data coming in at regular intervals but where processing does not have to be done immediately. e.g. Payroll System, Gas billing system, …2. Database systems (On-Line Systems) An on-line system is one in which information is available to all users at their own terminals, although they may not be able to update the information. Independent of any individual application Store of information to support other data processing systems. Remark: In many instances, the above types then use a data communication system to transmit data from one place to another. SYSTEM ANALYSIS 9
  10. 10. TYPES OF DATA PROCESSING SYSTEMS (cont…)3. Real time systems The computer has to keep pace with some external operation, processing the received data more or less instantaneously and producing results immediately. a. Process control e.g. oil refining process which is computer controlled b. Information storage and retrieval e.g. medical records system Though shared data files, by nature of application, a single record is not accessed by more than one user at the same time c. Transaction processing e.g. online reservation system By nature of application, the same record may be accessed by different users at the same time; hence need of data locking SYSTEM ANALYSIS 10
  11. 11. THE SYSTEM LIFE CYCLE (SLC)The development and maintenance of a new softwaresystem involves a series of stages - the SYSTEMDEVELOPMENT LIFE CYCLE (SDLC) or simply theSYSTEM LIFE CYCLE (SLC).The term ‘life-cycle’ indicates that the process ofdevelopment and maintenance never ends.The development of a system may take from a few weeksto a few years.The SLC is a model which tries to maximize the chance ofsuccessful project development. ‘7 out of 10 IT projects “fail” in some respect’ (OASIG study) SYSTEM ANALYSIS 11
  12. 12. THE WATERFALL MODELProject Definition This SLC model consists of a number of stages The stages may be Feasibility Study characterized and divided in different ways System study and analysis System Design Implementation (Coding) Testing & Integration Control & Review SYSTEM ANALYSIS 12
  13. 13. THE WATERFALL MODELThe waterfall model is a very rigid model – “a sequence ofstages where the output of each stage becomes the inputto the next”.In a rapidly changing environment and where up-to-datesoftware systems are required, this model does not workThe model assumes that all system requirements can beidentified in advance - in practice, most often, this is notthe case.This model assumes that users are only to be involved inorder to specify system requirements SYSTEM ANALYSIS 13
  14. 14. THE SPIRAL MODELThis method allows the development team to progressivelycomplete a project by repeatedly going through the stagesof analysis, design and implementation. Analysis Analysis Analysis Design Design Design Implementation Implementation Implementation SYSTEM ANALYSIS 14
  15. 15. THE INCREMENTAL-ITERATIVE MODEL Analysis Design ImplementationComponent A Component B Component C Analysis Analysis Analysis Design Design Design Implementation Implementation Implementation SYSTEM ANALYSIS 15
  16. 16. THE INCREMENTAL-ITERATIVE MODELThe project is divided into subprojects and then the waterfall methodis performed on each subproject. Instead of completing functionalityof the entire application with each pass, the incremental-iterativemethod completes components.Each component does not necessarily become a deliverable that isusable by a client (though at milestones the components are joinedtogether to create a usable product).This approach to project development promotes the development ofreusable code. It promotes the separation of functionality requiredinto different components (e.g. GUI controls, data access …) and ithelps clarify exact functionalities required. SYSTEM ANALYSIS 16
  17. 17. THROW-AWAY PROTOTYPINGThe objective is to understand the customer’s requirements and hence develop a better requirements definition for the system Mock-up A ‘mock-up of the proposed system is produced for demonstration purposes. Prototype has appearance of the final system but lacks any real processing or storage capabilities. Trial Prototyping A simplified working model of proposed system serves for demonstration purposes and also provides an opportunity to try out ideas and investigate specific points of interest. SYSTEM ANALYSIS 17
  18. 18. RAPID PROTOTYPINGAlso known as Evolutionary PrototypingThe objective is to work with the customer to explore their requirements and deliver the final system. The development starts with the parts of the system which are understood . The system evolves by adding new features as they are proposed by the customer.Rapid prototyping is particularly suitable for: For small scale systems which are required urgently and which have a limited life. When it is difficult to establish a detailed system specification. E.g. AI systems which attempt to emulate human capabilities. SYSTEM ANALYSIS 18
  19. 19. RAPID PROTOTYPINGEvolutionary development: Concurrent activities Specification Initial version Outline project Intermediate description development versions validation Final version SYSTEM ANALYSIS 19
  20. 20. COMPARISON OF PROTOTYPING STRATEGIESRemarks re prototyping: Throw-away methods aid work done in analysis and design by being incorporated into the development life- cycle Evolutionary methods provide short term gains – rapid results but, on long term can become costly, difficult to maintain and tend to be less reliable SYSTEM ANALYSIS 20
  21. 21. PROJECT DEFINITIONThis initial stage of project development is an attemptto formulate project requirements in broad terms byidentifying exact reasons for project selection.A steering committee is set up to monitor projectprogressTop management and all users are involved to gaintheir support and participation.Output: An assignment brief i.e. clear definition ofproblem and objectives SYSTEM ANALYSIS 21
  22. 22. FEASIBILITY STUDYPreliminary survey to determine whether a project shouldproceed.The feasibility study should be conducted quickly and inbroad terms but must be sufficiently detailed formanagement to draw proper conclusions.Feasibility study must include consideration of: TECHNICAL aspects ECONOMICAL aspects (incl. COST-BENEFIT ANALYSIS) OPERATIONAL (incl. LEGAL) aspects SOCIAL aspectsHence the main aim at this stage is to rule out bad ideasExample: Proposed project technically possible but tooexpensive to implement. SYSTEM ANALYSIS 22
  23. 23. FEASIBILITY REPORTThe resultant feasibility report should include: Recommendations Options considered Economic justification for the choice (cost-benefit analysis) Resource implications on staff, premises, etc… Development plans and time-table for introductionIf, on the basis of the feasibility report, the project isacceptable to the steering committee, a written go-aheadis given to proceed to next stage. SYSTEM ANALYSIS 23
  24. 24. SYSTEM STUDY AND ANALYSIS – PART IThis stage covers a review of the existing system leading to a designspecification for a new system. (Can help develop ideas for new system)It is a detailed study of current practices, files, documents, workingmethods, etc.Tasks falling within this stage:1. Define and identify the objectives of the current system2. Establish sources and types of information3. Decide on method and collection of data a. Interviews, b. Questionnaires, c. Observation, d. Documentation study4. Record, store and retrieve information - collection of current system data. SYSTEM ANALYSIS 24
  25. 25. SYSTEM STUDY AND ANALYSIS – PART II5. Process, adapt and present information - Documenting the existing system (if any,) involves the use of charts and other techniques to help understanding and presentation6. Analyze information (Who What Why When Where How) a. Are current system objectives valid? And are they being met? b. Identification of key activities and interrelationships within the current system c. Identification of strengths and weaknesses of the current system d. Opportunities and constraints of the current system e. Establishing the resource use of the current system SYSTEM ANALYSIS 25
  26. 26. SYSTEM STUDY AND ANALYSIS – PART III7. Statement of requirements: This is the output report from the current stage of the system life cycle. Ideally, it should be prepared jointly by the users and analysts for management approval. The SOR should include: a. criticisms of the existing system b. the findings of the analysis stage and how the system can be improved c. the objectives of the proposed system d. a design specification including main interfaces with other systems e. constraints and sample outputs f. user responsibilities g. an update of costs and development plan, and time-tables for introduction SYSTEM ANALYSIS 26
  27. 27. SYSTEM DESIGNThis stage is essentially a process of moving from ageneral outline to a detailed final product. System designleads to a SYSTEM SPECIFICATION that should: Provide a basis of agreement and a source of reference between management, users and analysts. Serve as a specification of software programs, dialogues and manual procedures within the system. The system specification should be presented to the steering committee for approval. Structure of system specification: SYSTEM ANALYSIS 27
  28. 28. CODING STAGEMost time-consuming stage of system development life-cycle.Program development stage involves programmingtechniques.Modules coded are tested, during coding, according to thetest plan designed earlier (during the design stage)This stage is complete when all code is written,documented and successfully compiled. SYSTEM ANALYSIS 28
  29. 29. CODINGMost time-consuming stageRequires a lot of effort (hence expensive)Choice of programming language is importantAids to save time and money Use of higher level languages, visual languages … Facilitative IDEs (Integrated Development Environments) Code reuse - existing library subroutines or classes, existing modules, … other RAD (Rapid Application Development) tools such as o screen painting software, o report generators, o application generators … SYSTEM ANALYSIS 29
  30. 30. SELECTION OF PROGRAMMING LANGUAGEWhen a program needs to be written for a particular application, selection of the language may be based on: Which languages have special features most appropriate to the application area Whether the choice of a particular language would substantially reduce development time Whether the programmers have the time and/or expertise to master a new language Whether a suitable compiler exists for the hardware the system being developed is intended to use SYSTEM ANALYSIS 30
  31. 31. PROGRAM ERRORSProgram Errors : A program may have any or all of four types oferrors: Syntax Errors: A statement in the program violates a rule of the language, Semantic Errors: Violating rules of language, semantic errors are concerned with the meaning of language statements (semantics). Logical Errors: The program runs to completion but gives wrong results or performs wrongly in some way. Runtime Errors: Program crashes during execution.The translator detects syntax and semantic errors but the translatordoes NOT detect Logical and Run-time errors. These require rigoroustesting for detection and correction possibly with the aid of adebugger. SYSTEM ANALYSIS 31
  32. 32. PROGRAM TESTINGThere are two ways of approaching testing : Functional Testing (Black box testing) Based on typical, extreme and invalid data values that are representative of those covered by the specification. Logical Testing (White box testing) Based on examining the internal structure of the program and selecting data which gives rise to the alternative cases of control flow.Remarks: Functional testing is not adequate by itself. Logical testing by the programmer during program development is most effective. SYSTEM ANALYSIS 32
  33. 33. TEST DATA AND TEST CASESTest data must include: Valid values, Invalid values limit valuesSelect test cases such that: Every statement in the program is executed at least once. The effectiveness of all sections of code that detects invalid input is tested. The accuracy of all processing is verified. The program operates according to its original design specifications. SYSTEM ANALYSIS 33
  34. 34. THE TESTING PROCESS Except for small programs, systems should not be tested as a single unit. Large systems are built out of sub-systems, which are built out of modules, which are composed of object classes (or procedures and functions – depending on the design (and language) paradigm adopted. The testing process should therefore proceed in stages where testing is carried out incrementally in conjunction with system implementation. In general, the sequence of activities is:COMPONENT TESTING INTEGRATION TESTING USER TESTING SYSTEM ANALYSIS 34
  35. 35. TESTING STAGES Unittesting Module testing Sub-system testing System testing Acceptance testing Component Integration User Testing Testing TestingAs defects are discovered at any one stage, they require programmodifications to correct them and this may require other stages, inthe testing process to be repeated. (regression testing) SYSTEM ANALYSIS 35
  36. 36. UNIT AND MODULE TESTINGUnit testing Individual components are tested to ensurethat they operate correctly. Each component is testedindependently, without other system components.Module testing A module is a collection of dependentcomponents such as an object class, an abstract data typeor some looser collection of procedures and functions. Amodule encapsulates related components and so can betested without other system modules. SYSTEM ANALYSIS 36
  37. 37. SYSTEM TESTINGSub-system testing : This phase involves testing collections ofmodules which have been integrated into sub-systems. Sub-systemsmay be independently designed and implemented. The most commonproblems which arise in large software systems are sub-systeminterface mismatches. The sub-system test process should thereforeconcentrate on the detection of interface errors by rigorouslyexercising these interfaces.System testing: The sub-systems are integrated to make up theentire system. The testing process is concerned with finding errorswhich result from un-anticipated interactions between sub-systemsand system components. It is also concerned with validating that thesystem meets its requirements. SYSTEM ANALYSIS 37
  38. 38. ACCEPTANCE TESTINGAcceptance testing the final stage in the testing process before the system isaccepted for operational use. The system is tested with data supplied by thesystem client rather than simulated test data.Acceptance testing may reveal errors and omissions in the system requirementsdefinition because the real data may ‘exercise’ the system in different ways fromthe test data. Acceptance testing may also reveal that the system facilitiesprovided do not meet the exact users’ needs or the system performance isunacceptable.Acceptance testing is sometimes called alpha testing. Bespoke systems aredeveloped for a single client. The alpha testing process continues until thesystem developer and the client agrees that the delivered system is anacceptable implementation of the system requirements.When a system is to be marketed as a software product, a testing process calledbeta testing is often used. Beta testing involves delivering a system to anumber of potential customers who agree to use that system. They reportproblems to the system developers. This exposes the product to real use anddetects errors that may not have been anticipated by the developers. After thisfeedback, the system is modified and either released for further beta testing orfor general sale. SYSTEM ANALYSIS 38
  39. 39. TEST PLANNINGCareful test planning is needed to get the most out of testing and to control testing costs.Test planning is concerned with setting out standards for the testing process.The major components of a test plan are as follows: The testing process. A description of the major phases of the testing process. (maybe as described earlier) Requirements traceability. Users are most interested in the system meeting its requirements and testing should be planned so that all requirements are individually tested. Test Items. The products of the software process which are to be tested should be specified. Testing Schedule. An overall testing schedule and resource allocation for this schedule. This, obviously, is linked to the more general project development schedule. Test recording procedures. It is not enough simply to run tests. The results of the tests must be systematically recorded. It must be possible to audit the testing process to check that it has been carried out correctly. Hardware and software requirements. This section should set out software tools required and estimated hardware utilisation. Constraints. Constraints affecting the testing process such as staff shortages should be anticipated in this section. SYSTEM ANALYSIS 39
  40. 40. TESTING STRATEGIESA testing strategy outlines the general approach to the testingprocess. Different testing strategies may be adopted depending onthe type of system to be tested and the development process used.Some types of testing strategies:1. Top-down testing where testing starts with the most abstract components and works downwards.2. Bottom-up testing where testing starts with the fundamental components and works upwards3. Thread testing which is used for systems (usually real-time) with multiple processes where the processing of a transaction threads its way through these processes4. Stress testing which relies on stressing the system by going beyond its specified limits and hence testing how well the system can cope with over-load situations.5. Back-to-back testing which is used when versions of a system are available. The systems are tested together and their outputs compared. SYSTEM ANALYSIS 40
  41. 41. IMPLEMENTATION : CROSS-OVER TECHNIQUES Straight (Direct) Changeover New System Old SystemA complete replacement at one go usually taking placeduring a slack period.It is cheap, simple, clear-cut method but risky becausethere is no fallback position.Used when Users have previous experience of computerisation The new system is not directly comparable with the old The time scale is tight Resources are limited e.g. no extra staff The system is small SYSTEM ANALYSIS 41
  42. 42. IMPLEMENTATION STAGEProject ManagementThe planning and scheduling of resources, staff, equipment, …Staff training and educationWithout interrupting flow of work, good courses and manualsFile conversionReformatting files for the new systemDocumentation checkEnsuring comprehensive and up-to-date systemsDeciding on method of changeoverSwitching over from the old system to the new systemHandover SYSTEM ANALYSIS 42
  43. 43. IMPLEMENTATION : CROSS-OVER TECHNIQUESParallel Changeover New System Old SystemIncludes a period when the old and the new system run inparallel until everyone is satisfied that the new system isrunning successfully and then the old system is dropped.Expensive changeover – involves more workDifficult to make comparisons between the resultsobtained by both systemsLess risky – standby facilities, useful cross check, gradualchangeover. SYSTEM ANALYSIS 43
  44. 44. IMPLEMENTATION : CROSS-OVER TECHNIQUESPhased (Incremental) Changeover Old System New SystemThe changeover is in a number of stages rather than all at once.The division may be based on: Location – say, one branch of a retail group each month Subsystem –say, sales order processing system, then payroll system, then accounting system, … Subfile – say, in a customer account file, names beginning A – F, then G-L, …Spreads the burden of the workload over timePresents an opportunity to learn from problems of a previous phaseTakes longer than other changeover methodsDifficult to control a system working in two modes SYSTEM ANALYSIS 44
  45. 45. IMPLEMENTATION : CROSS-OVER TECHNIQUES New New Old Old PilotSometimes a part of the system which can be treated asan entity is upgraded. E.g. the stock control system of asingle shop which forms part of a whole retail chain.The changeover of the entity is done using direct orparallel changeover.When the pilot implementation is satisfactory, the projectto upgrade the whole system is undertaken. SYSTEM ANALYSIS 45
  46. 46. CONTROL AND REVIEW STAGEControl Setting and redefining standards against which performance can be compared. Measuring planned against actual performance Taking corrective action where necessary so that system meets its objectivesReview At predefined intervals of time, system should be reviewed to give overall picture of progress made Findings help any subsequent system analysis SYSTEM ANALYSIS 46
  47. 47. SYSTEM MAINTENANCESystem maintenance implies another system life cycle.MAINTENANCE may be: Adaptive maintenance due to identified new requirements Corrective maintenance due to identified errors Perfective maintenance due to identified improvements to the existing set up.Aids to maintenance: Modular design Use of structured system development techniques 17% Readable Code Good Documentation 18% 65% Corrective Adaptive Perfective SYSTEM ANALYSIS 47
  48. 48. DOCUMENTATIONDocumentation may be presented in different forms: Manuals Online helpDocumentation types: User Manual Operations Manual Technical Manual (program listing includes inline documentation) SYSTEM ANALYSIS 48
  49. 49. USER MANUALTypical information: Overview of options available Guidance on the sequence of operations to follow Screen shots showing screen input forms Instructions on how to enter data Sample report layouts Error messages that may be displayed and what action to take SYSTEM ANALYSIS 49
  50. 50. OPERATIONS MANUALThe operations manual includes all the procedures necessary to run the system.Typical information: System setup procedures, including details for each application of the files required and consumables requirements Security procedures Recovery procedures in the event of system failure A list of system messages that might appear on the operator’s console and what action to take SYSTEM ANALYSIS 50
  51. 51. TECHNICAL MANUALTypical information included in the technical manual: Overall system plan Data organisation and flow Full annotated listing Details of test data and results SYSTEM ANALYSIS 51
  52. 52. DECISION TABLESA DECISION TABLE is a tabularrepresentation of expressingprocess (decision) logic. CONDITIONS CONDITION (Questions) ENTRIESDecision tables are used to (Outcome)analyze problems.Conditions applying to theparticular problem are identified; ACTIONS ACTIONand the actions to be taken as a ENTRIESresult of any combination of theconditions arising are set out. SYSTEM ANALYSIS 52
  53. 53. DECISION TABLES - EXAMPLEExample: RulesDiscounts allowed on customers’order are required to comply with Conditions 1 2 3 4the following policy: Is order €500 or Y Y N N“Any order from a credit-worthy more?customer attracts a discount of 5%if the order amounts to €500 or Is credit-worthy Y N Y Nmore, and a discount of 3% if the customer?order amounts to less than €500. ActionsOther circumstances must bereferred to the supervisor for a Allow discount of Xdecision. 3% Allow discount of X 5% Refer to X X supervisor SYSTEM ANALYSIS 53
  54. 54. DECISION TABLES - EXERCISEUse a decision table to represent the following system logic:A credit union pays interest to its depositors at the rate of 6% per year. A number of constraints to this policy are: Accounts of less than €100 are not paid interest. Accounts of less than €1,000 are paid the normal 6%, Accounts of €1,000 or more that have been with the union for more than one year get paid the normal 6%, plus a bonus of 1%. SYSTEM ANALYSIS 54
  55. 55. MODULARITY Input PROCESSING Output ONE entry point ONE exit pointA module is a self-contained subprogram, which performs independently one specific task.Advantages in using modules Re-usability Easier to read, debug and maintain (update) Natural division of workRemarks Modules can be compiled separately Driver program is required to further test modules SYSTEM ANALYSIS 55
  56. 56. TOP-DOWN MODULAR APPROACHProblem is broken down into a number of componentsmodules. Each component is progressively decomposedinto smaller, more manageable components until eachcomponent (or module) can be easily comprehended. Problem Module A Module BModule A [1] … Module A [n] Module B [1] … Module B [n]Module A1 [1] … Module B1 [1] … SYSTEM ANALYSIS 56
  57. 57. BOTTOM-UP MODULAR APPROACHIndividual manageable modules are initially identified; progressivelythese are combined to form larger modules until the original problemis fully addressed.Method recommendable only in the case of experienced programmersand the existence of a library of previously developed modules Module A[1] Module A[2] Module B[1] Module B[2] Module A Module B Original Problem SYSTEM ANALYSIS 57
  58. 58. STRUCTURE CHARTSStructure charts are used to represent the high level modular designof a programming project.Consider the following structure chart for solving a teacher’sexamination results processing problem: Process Examination Results Input Details Process Details Output Details Input Validate Determine Determine Print Print Results input Grade Grade Individual Statistical Category Counts Results Summary Print Exercise: Draw a structure chart to representing the issuing of reminder Error letters for borrowers in a book library system Listing SYSTEM ANALYSIS 58
  59. 59. DATA FLOW DIAGRAMSData Flow Diagrams (DFDs) provide a pictorialrepresentation for recording: o Where the data originates o What processing is performed on it (data) and by whom o Who uses the data o What data is stored and where o What output is produced and who receives it. SYSTEM ANALYSIS 59
  60. 60. DFD SYMBOLS A data source or destination which is extended toSource/destination the system. E.g. people/departments who provide data or receive output An operation performed on the data.Process A process will use or alter the data in some way E.g. sorting, using data to print a report. Data store denotes object where the data is Data store stored. E.g. data file, transaction file, input document, report The arrow represents the movement of data between entities, processes or data stores. Arrows should be clearly labelled to show whatData flow data is being transferred. Do not draw data flow directly between data stores and external entities - there should be a process box between them to show the operation performed SYSTEM ANALYSIS 60
  61. 61. LEVELLED DFDsSince it is often impossible to represent a completesystem in a single diagram, two or three levels of dataflows may be used each showing progressively moredetail.Consider the following example:The payroll system of ABC LTD:-At the end of each week, time sheets are collected andsent to the salaries department. Here, the payroll data isentered via a key-to-disk system, verified and validated,producing a new valid transaction file on disc and anerror report. This file is used to update the employeesmaster file , issue payslips and electronically transferpayment to employees’ bank accounts. SYSTEM ANALYSIS 61
  62. 62. PAYROLL SYSTEM:- TOP-LEVEL DFDTop level showing a single process: Cheque and payslip data Employees Time sheets Process Employees Payroll Payroll summary data Accounts Department SYSTEM ANALYSIS 62
  63. 63. PAYROLL SYSTEM :- SECOND LEVEL DFD Time sheets Batch Time sheet data and time Employee batch control totals sheets Employee number, hours worked, batch control total Invalid data batch Verify and control totals and Valid weekly Error validated data transaction file validateReport Employee number, hours worked Rate of pay, tax code…Employee Prepare Employee number, total file Year-to-date pay… payroll pay, deductions… for all employees Employee Employee number, total Cheques and Print and number, name, Print pay, deductions… for all payslips distribute total pay, Payroll employees cheques deductions… Summary and Accounts Employee payslips Department SYSTEM ANALYSIS 63
  64. 64. STOCK CONTROL SYSTEM QUERY:- TOP-LEVEL DFDIn relation to this query, the user provides the stocknumber and the system outputs the item’s description andquantity of item in stock.Top-level DFD to this query: Query Stock Number request inputEnd User Stock Report Stock file Request Stock description Unformatted and query request quantity in stock output SYSTEM ANALYSIS 64
  65. 65. STOCK CONTROL SYSTEM QUERY:- SECOND LEVEL DFD Stock number ValidationUser process Stock file Valid Stock Data Stock file Description processing of stock report Stock Description Select report Stored output output formats format SYSTEM ANALYSIS 65
  66. 66. DFD EXERCISE A student can register by mail for a college course by submitting a registration form with their name, ID number and the number of courses they wish to take. The system verifies that the course is not full and enrolls the student on each course for which a place is still free. The course file and student master files are updated and a confirmation letter is sent to the student to notify them of their acceptance or rejection for each requested course. Draw a DFD diagram illustrating how data flows through this student registration system.Second level DFD Solution: Heathcote & Langfield, “‘A’ level Computing”, 5th ed. p.319 SYSTEM ANALYSIS 66
  67. 67. FLOW CHARTSA FLOWCHART is a graphical representation of thesequence of operations in a system or program.A SYSTEM FLOWCHART is used to show how data flowsfrom source documents through the computer (system)to final output distribution – it gives a complete overviewof a system. E.g. Sequential file processing diagramA PROGRAM FLOWCHART shows the sequence ofinstructions to achieve a particular task (algorithm). SYSTEM ANALYSIS 67
  68. 68. FLOW CHARTS SYMBOLS Communications Data Manual Off-pagePrinted output connector links preparation operation Direct Access Tape/sequential Manual Sort process Disk storage access medium Input Start/end Process Pre-defined Input/Output Decision Process Connector Flow SYSTEM ANALYSIS 68
  69. 69. SYSTEM FLOWCHARTSExample 1: MF Update New Process MF Old MF SEQUENTIAL FILE UPDATE PROCESS Display Example 2: input data Error Data Entry Data validation Report Collection of Documents Transaction KEY-TO-DISK File INPUT SYSTEM SYSTEM ANALYSIS 69
  70. 70. PROGRAM FLOWCHART Start Read input EXAMINATION RESULTS Name,index, PROCESS Mark Is YMark = -1? N PrintIndex number Is Is N Mark<40? Mark<70? Total Count Y N Y T = F+P+C Print “FAIL” Print “PASS” Print “CREDIT” Print F/T*100% Increment Increment Increment P/T*100% Fail count Pass count Credit count C/T*100% F=F+1 P=P+1 C=C+1 End SYSTEM ANALYSIS 70
  71. 71. PROGRAM FLOWCHART (Another Example) Start COMPUTINGFACTORIAL N (N!) Input NN! = 1*2*3* … *N F=1 M=1 Exercise M=M+1 F=F*M Draw the flowchart for the algorithm which generates the first N M=N? terms of the fibonacci sequence where N is specified by the user. Print F Fibonacci Sequence 0 1 1 2358… End SYSTEM ANALYSIS 71
  72. 72. PSEUDOCODE PSEUDOCODE represents a way how we can express the sequence of instructions to achieve a particular task (algorithm) independently of any programming language. Pseudocode consists of English-like statements very close to the target programming language to be used for developing the software. CHECK WHETHER AN INTEGERExamples: VARIABLE IS EVEN OR ODD SWAP TWO INTEGER VARIABLES Assume Integer variable X Assume swap integer variables X, Y if (X modulo 2 == 0) Declare integer Temp output message “even” Temp = X else output message “odd” X=Y Y = Temp EXERCISE: Use pseudocode for expressing the algorithm which generates factorial n (n!) SYSTEM ANALYSIS 72
  73. 73. ENTITY-EVENT MODELLINGAn ENTITY-EVENT MODEL is an abstract representation ofhow the entities of a system are effected by businessevents - business events trigger processes which in turnaffect entities.An Entity-Event Model identifies business events anddefines the effects which these events have on thesystem’s entities. It also defines the order in which theseevents take place.Entity-event modeling (similar to Jackson SystemDevelopment techniques), is a technique used in relationto the SSADM standard. SYSTEM ANALYSIS 73
  74. 74. ENTITY-EVENT MODELAn entity-event model consists of A set of entity life histories (ELH), A set of effect correspondence diagrams (ECD)An Entity Life History shows the sequence of effectswhich business events cause on a particular entity type.An Effect Correspondence Diagram shows the effectsof business events from the event’s point of view – showswhich entities are effected by a particular event. SYSTEM ANALYSIS 74
  75. 75. ENTITY LIFE HISTORIES Entity life histories are drawn using the structured design (orprogramming) constructs of sequence, selection, iteration and parallelism SELECTION SEQUENCE A is a structural component which A is a structural component A shows that either effect B takes A which shows that effect B is place or effect C but not both followed by effect C B° C° B C PARALLELISM A A is a structural component ITERATION which shows that either, both (in any order and any number A of times), or neither of effects B C D and E may occur A is a structural component which shows that effect B takes place 0 or more times B* D* E* SYSTEM ANALYSIS 75
  76. 76. ELH EXAMPLEThe top node represents the entity, the next level nodes denote the organization ofevents, the next level nodes denote the individual events which change the entity,and the lowest level nodes denote the tasks which achieve the higher level nodes. BOOK New Book Acquisition Library Book Life Book Discarded Book details changes Book available changes Book details change* Book available change* Book State° Book Borrowed° Book Returned° SYSTEM ANALYSIS 76
  77. 77. EFFECT CORRESPONDENCE DIAGRAMS Effect Correspondence Diagram are drawn in relation to ELH. All entities effected by an event are listed. Place order Book Booking borrowed Booking Orderline Loan Order Set of orderline Book Provisional° Confirmed° occurrences*The event ‘book borrowed’ The event ‘booking’ can The event ‘place order’ effects effects the LOAN and effect the booking entity in several occurrences of the BOOK entities different ways ORDER entity SYSTEM ANALYSIS 77
  78. 78. ELH – Another ExampleDraw the EHL diagram for the entity Borrower in thecontext of a book library system BORROWER New Membership Library Member Life End Membership Borrower detail changes Borrower detail change* Borrower’s address° Borrower’s Tel.No.° SYSTEM ANALYSIS 78
  79. 79. USE CASE DIAGRAMS The USE CASE diagram is used to give a high level view of the system, depicting who will use the system and what they will be able to do with it. There are four basic components to USE CASE diagrams: update inventory Use case actor Prepare report administrator View report manager relationship update inventory systemadministrator SYSTEM ANALYSIS 79
  80. 80. USE CASE DIAGRAMS : GENERALISATION GENERALIZATION is a technique used to indicate inheritance of an item. Generalization can be applied to both actors and use cases to indicate inheritance of functionality from parents. sale generalized actor generic actor phone order walk-in saleThe generalized actor plays amore specific role in thesystem phone order sale telephone sales person operator SYSTEM ANALYSIS 80
  81. 81. USE CASE DIAGRAMS : RELATIONSHIPSINCLUDE and EXTEND are two ways of relating use caseswhich are highly related to each other.These relationships help you to identify where you canreuse functionality during system design. load inventory <<include>> update verify sale inventory credit card <<extend>> <<include>> save inventory The EXTEND relationship is used to identify when a use case can optionally be extended by functionality in another use case SYSTEM ANALYSIS 81
  82. 82. CREATING USE CASE DIAGRAMSSteps to follow in creating USE CASE diagrams: identify the actors and use cases in the system Prioritize the use cases Detail each use case Structure the case model Prototype user interfacesExample:A system is required to: Allow teachers to record and update students’ results; and notify guardians if individual students’ results are not satisfactory Allow teachers, students and the administrator to view results recorded Enable the administrator to generate students’ reports SYSTEM ANALYSIS 82
  83. 83. “STUDENTS’ RESULTS” USE CASE DIAGRAMRecording students’ results: record grades <<include>> save grades notify guardian <<include>> <<extend>> update grades teacher <<include>> load grades generate <<include>> reports view grades student administrator SYSTEM ANALYSIS 83
  84. 84. EXERCISECreate a use case diagram for the following businessrequirements of a point-of-sale (POS) system: The system will allow the administrator to run inventory reports by loading inventory data from disk The administrator can update the inventory by loading and saving the inventory data to and from a disk A sales clerk records walk-in sales A telephone operator is a special type of sales clerk who handles phone orders Any kind of sale must update the inventory A sale may need to verify a credit card if the purchase is a credit card purchase A sale may need to verify a check if the purchase is a check purchase. SYSTEM ANALYSIS 84
  85. 85. SOLUTION <<include>> run inventory reports load inventory <<include>> Update inventory <<include>>administrator save inventory <<include>> verify <<extend>> credit card <<extend>> sale verify check phone-in walk-in sale sale telephone operator sales clerk SYSTEM ANALYSIS 85
  86. 86. CLASS DIAGRAMSA CLASS DIAGRAM consists of classes and their relationships to eachother.The main components of a class are attributes and operations.Formal notation of a class: Visibility: ClassName plus (+) signifies that the member is visible. minus (-) signifies that the member is private. - attribute 1 - attribute 2 hash (#) signifies that the member is visible only - attribute 3 to classes of the same system – protected. + operation 1 () Remarks: + operation 2 () •Depending on the detail you want to communicate, + operation 3 () only the first compartment is a must. •Note the difference between a hidden compartment and an empty compartment SYSTEM ANALYSIS 86
  87. 87. RELATIONSHIPS Two classes can relate to each other with a line and an association name: teaches > Teacher Class Multiplicity allows us to indicate how many objects of one class relate to one object of another class. teaches > Teacher Class 1 1..*Exercise: Extend the above class diagram to include another class named “Student” where a given student may take from four to six classes at any one time and a class includes fifteen or thirty students. SYSTEM ANALYSIS 87
  88. 88. INHERITANCE Inheritance is a way of allowing one class to gain the functionality of another class Say, classes LION and TIGER, in Animal turn, inherit the functionality of the class FELINE - inheritance hierarchiesFeline Bird Vehicle Weapon Classes can be derived from more than one superclass – multiple inheritance Tank SYSTEM ANALYSIS 88
  89. 89. POLYMORPHISMPolymorphism is the ability of two or more abstractclasses to have the same interface but operate on theirdata differently because each has its own section of code. Animal NumberOfEyes Say, we use polymorphism to NumberOfLegs model the fact that each animal +Eat() sleeps differently – felines sleep +Sleep() lying down while birds sleep standing up Feline Bird +Run() +Fly() +Sleep() +Sleep() SYSTEM ANALYSIS 89
  90. 90. EXERCISECreate a Class Diagram using the following information: A student can be an undergraduate or a graduate student An undergraduate student can be a type of tutor A tutor tutors a student A teacher and a professor are two types of instructors A teacher assistant can assist a teacher and a professor, but a teacher can be assisted by only one assistant, while a professor can be assisted by up to five assistants A teacher assistant is a type of graduate student SYSTEM ANALYSIS 90
  91. 91. SOLUTION Tutor tutors> Instructor StudentUndergraduate Graduate Teacher Professor 1 <a 1 ss s> is t s ist s as 0..1 0..5 Teacher Assistant SYSTEM ANALYSIS 91
  92. 92. SOME SDLC STANDARDS: UML & SSADMBoth UML and SSADM are standards within the SDLCstudy field.Each has its own strengths and weaknessesA comprehensive overview SSADMA comprehensive UML tutorial (overview)A comparison of SSADM and UML SYSTEM ANALYSIS 92