1. SYSTEMS ANALYSIS ANDDESIGNCutajar & Cutajar
2. SYSTEM ANALYSIS 2INTRODUCTIONSystem 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 wholeor in part;Decide what, in consequence, the computing system should do;Specify the tasks of the computing system in detail, so that the technicalspecialists (programmers) can do their work;Ensure that the developed computing system works efficiently.
3. SYSTEM ANALYSIS 3WHAT IS A SYSTEM?A system is a collection of interrelated components that work togetherto achieve some objectiveDifferent components making up a system include:HardwareSoftwareCollection of dataWork of a number of people.Different components making up the software component of a systeminclude:inputsprocessesstored dataoutputshuman communication interface (HCI)
4. SYSTEM ANALYSIS 4SYSTEM ELEMENTSA commercial or industrial enterprise can be defined interms of system elements:Physicale.g. Buildings, raw materials, finished product;Procedurale.g. Order processing routines, credit checking procedures;Conceptuale.g. Statement of policy, material for products;Sociale.g. Workers, departments.
5. SYSTEM ANALYSIS 5SYSTEM ENVIRONMENTThe system operates in an environment and relates tothat environment, which itself includes various elements.Elements relating to the environment include:Physicale.g. transport routes;Procedurale.g. codes of practice, legal requirements;Conceptuale.g. monetary system, political ideologies;Sociale.g. trade unions, suppliers, customers.
6. SYSTEM ANALYSIS 6SUB-SYSTEMSAn enterprise can be divided into a number ofSUBSYSTEMS defining the functional areas. Theseinclude:Those dealing with the environment: marketing andpurchasing subsystems;Those dealing with transformation functions: theproduction subsystem;Those acting in a supportive role: accounting,personnel, and management services subsystems.
7. SYSTEM ANALYSIS 7BUSINESS SUBSYSTEMSThese subsystems are all interconnected. The diagram shown is a‘simple’ model of business subsystems:CustomersMarketingAccountingManagementControlProductionPersonnelPurchasingSuppliersGoodsOrdersPurchasesStaffingrequiredPaymentsOrdersGoodsDeliveriesDeliveriesSchedulesBudgetsand plansBudgetsFinancialanalysisBudgetsManpoweranalysisPaymentsInvoicesOrdersThis diagramillustrates theINTERFACES withinthe business, andhence the type ofdifficulty that canarise in definingboundaries.Henceforth thedifficulties of thesystem analyst toanalyse, design,help implementand review.
8. SYSTEM ANALYSIS 8OBJECTIVES OF COMPUTERISATIONTo reduce costsTake advantages of the facilities offered by computersTo increase volume of businessBetter management of informationEnable long-term forecastsEnable better planning.
9. SYSTEM ANALYSIS 9TYPES 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 whereprocessing 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 allusers at their own terminals, although they may not be able toupdate the information.Independent of any individual applicationStore of information to support other data processing systems.Remark: In many instances, the above types then use a datacommunication system to transmit data from one place toanother.
10. SYSTEM ANALYSIS 10TYPES OF DATA PROCESSING SYSTEMS (cont…)3. Real time systemsThe computer has to keep pace with some external operation,processing the received data more or less instantaneously andproducing results immediately.a. Process controle.g. oil refining process which is computer controlledb. Information storage and retrievale.g. medical records systemThough shared data files, by nature of application, a singlerecord is not accessed by more than one user at the sametimec. Transaction processinge.g. online reservation systemBy nature of application, the same record may be accessed bydifferent users at the same time; hence need of data locking
11. SYSTEM ANALYSIS 11THE 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)
12. SYSTEM ANALYSIS 12THE WATERFALL MODELThis SLC model consists of anumber of stagesThe stages may becharacterized and divided indifferent waysProject DefinitionSystem study and analysisFeasibility StudySystem DesignImplementation (Coding)Testing & IntegrationControl & Review
13. SYSTEM ANALYSIS 13THE 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
14. SYSTEM ANALYSIS 14THE SPIRAL MODELThis method allows the development team to progressivelycomplete a project by repeatedly going through the stagesof analysis, design and implementation.AnalysisImplementationDesignAnalysisImplementationDesignAnalysisImplementationDesign
15. SYSTEM ANALYSIS 15THE INCREMENTAL-ITERATIVE MODELAnalysis Design ImplementationComponent A Component CComponent BAnalysisImplementationDesignAnalysisImplementationDesignAnalysisImplementationDesign
16. SYSTEM ANALYSIS 16THE 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.
17. SYSTEM ANALYSIS 17THROW-AWAY PROTOTYPINGThe objective is to understand the customer’s requirements and hencedevelop a better requirements definition for the systemMock-upA ‘mock-up of the proposed system is produced for demonstrationpurposes. Prototype has appearance of the final system but lacks anyreal processing or storage capabilities.Trial PrototypingA simplified working model of proposed system serves fordemonstration purposes and also provides an opportunity to try outideas and investigate specific points of interest.
18. SYSTEM ANALYSIS 18RAPID PROTOTYPINGAlso known as Evolutionary PrototypingThe objective is to work with the customer to explore theirrequirements and deliver the final system. The development startswith the parts of the system which are understood . The systemevolves by adding new features as they are proposed by thecustomer.Rapid prototyping is particularly suitable for:For small scale systems which are required urgently and whichhave a limited life.When it is difficult to establish a detailed system specification. E.g.AI systems which attempt to emulate human capabilities.
19. SYSTEM ANALYSIS 19RAPID PROTOTYPINGEvolutionary development:SpecificationdevelopmentvalidationInitial versionIntermediateversionsFinal versionOutline projectdescriptionConcurrent activities
20. SYSTEM ANALYSIS 20COMPARISON OF PROTOTYPING STRATEGIESRemarks re prototyping:Throw-away methods aid work done in analysis anddesign by being incorporated into the development life-cycleEvolutionary methods provide short term gains – rapidresults but, on long term can become costly, difficult tomaintain and tend to be less reliable
21. SYSTEM ANALYSIS 21PROJECT 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
22. SYSTEM ANALYSIS 22FEASIBILITY 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 aspectsECONOMICAL aspects (incl. COST-BENEFIT ANALYSIS)OPERATIONAL (incl. LEGAL) aspectsSOCIAL aspectsHence the main aim at this stage is to rule out bad ideasExample: Proposed project technically possible but tooexpensive to implement.
23. SYSTEM ANALYSIS 23FEASIBILITY REPORTThe resultant feasibility report should include:RecommendationsOptions consideredEconomic 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.
24. SYSTEM ANALYSIS 24SYSTEM 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 dataa. Interviews,b. Questionnaires,c. Observation,d. Documentation study4. Record, store and retrieve information - collection of current systemdata.
25. SYSTEM ANALYSIS 25SYSTEM STUDY AND ANALYSIS – PART II5. Process, adapt and present information - Documenting the existingsystem (if any,) involves the use of charts and other techniques to helpunderstanding 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 thecurrent systemc. Identification of strengths and weaknesses of the currentsystemd. Opportunities and constraints of the current systeme. Establishing the resource use of the current system
26. SYSTEM ANALYSIS 26SYSTEM STUDY AND ANALYSIS – PART III7. Statement of requirements: This is the output report from thecurrent stage of the system life cycle. Ideally, it should be preparedjointly by the users and analysts for management approval. The SORshould include:a. criticisms of the existing systemb. the findings of the analysis stage and how the system can beimprovedc. the objectives of the proposed systemd. a design specification including main interfaces with othersystemse. constraints and sample outputsf. user responsibilitiesg. an update of costs and development plan, and time-tables forintroduction
27. SYSTEM ANALYSIS 27SYSTEM 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 betweenmanagement, users and analysts.Serve as a specification of software programs, dialogues andmanual procedures within the system.The system specification should be presented to the steeringcommittee for approval.Structure of system specification:
28. SYSTEM ANALYSIS 28CODING 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.
29. SYSTEM ANALYSIS 29CODINGMost time-consuming stageRequires a lot of effort (hence expensive)Choice of programming language is importantAids to save time and moneyUse of higher level languages, visual languages …Facilitative IDEs (Integrated Development Environments)Code reuse - existing library subroutines or classes, existingmodules, …other RAD (Rapid Application Development) tools such aso screen painting software,o report generators,o application generators …
30. SYSTEM ANALYSIS 30SELECTION OF PROGRAMMING LANGUAGEWhen a program needs to be written for a particularapplication, selection of the language may be based on:Which languages have special features most appropriateto the application areaWhether the choice of a particular language wouldsubstantially reduce development timeWhether the programmers have the time and/or expertiseto master a new languageWhether a suitable compiler exists for the hardware thesystem being developed is intended to use
31. SYSTEM ANALYSIS 31PROGRAM 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 concernedwith the meaning of language statements (semantics).Logical Errors: The program runs to completion but gives wrong results orperforms 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.
32. SYSTEM ANALYSIS 32PROGRAM TESTINGThere are two ways of approaching testing :Functional Testing (Black box testing)Based on typical, extreme and invalid data values thatare representative of those covered by the specification.Logical Testing (White box testing)Based on examining the internal structure of theprogram and selecting data which gives rise to thealternative cases of control flow.Remarks:Functional testing is not adequate by itself.Logical testing by the programmer during program development ismost effective.
33. SYSTEM ANALYSIS 33TEST DATA AND TEST CASESTest data must include:Valid values,Invalid valueslimit valuesSelect test cases such that:Every statement in the program is executed at least once.The effectiveness of all sections of code that detects invalidinput is tested.The accuracy of all processing is verified.The program operates according to its original designspecifications.
34. SYSTEM ANALYSIS 34THE TESTING PROCESSExcept for small programs, systems should not be tested asa single unit. Large systems are built out of sub-systems,which are built out of modules, which are composed ofobject classes (or procedures and functions – depending onthe design (and language) paradigm adopted. The testingprocess should therefore proceed in stages where testing iscarried out incrementally in conjunction with systemimplementation.In general, the sequence of activities is:COMPONENT TESTING INTEGRATION TESTING USER TESTING
35. SYSTEM ANALYSIS 35TESTING STAGESAs 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)UnittestingModuletestingSub-systemtestingSystemtestingAcceptancetestingComponentTestingIntegrationTestingUserTesting
36. SYSTEM ANALYSIS 36UNIT 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.
37. SYSTEM ANALYSIS 37SYSTEM 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.
38. SYSTEM ANALYSIS 38ACCEPTANCE 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.
39. SYSTEM ANALYSIS 39TEST 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 plannedso 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 tothe 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. Itmust 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 thissection.
40. SYSTEM ANALYSIS 40TESTING 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 componentsand works downwards.2. Bottom-up testing where testing starts with the fundamental componentsand works upwards3. Thread testing which is used for systems (usually real-time) with multipleprocesses where the processing of a transaction threads its way throughthese processes4. Stress testing which relies on stressing the system by going beyond itsspecified limits and hence testing how well the system can cope withover-load situations.5. Back-to-back testing which is used when versions of a system areavailable. The systems are tested together and their outputs compared.
41. SYSTEM ANALYSIS 41IMPLEMENTATION : CROSS-OVER TECHNIQUESA 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 whenUsers have previous experience of computerisationThe new system is not directly comparable with the oldThe time scale is tightResources are limited e.g. no extra staffThe system is smallOld SystemNew SystemStraight (Direct) Changeover
42. SYSTEM ANALYSIS 42IMPLEMENTATION 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
43. SYSTEM ANALYSIS 43IMPLEMENTATION : CROSS-OVER TECHNIQUESParallel ChangeoverIncludes 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.Old SystemNew System
44. SYSTEM ANALYSIS 44IMPLEMENTATION : CROSS-OVER TECHNIQUESPhased (Incremental) ChangeoverThe 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 monthSubsystem –say, sales order processing system, then payroll system, thenaccounting 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 modesNew SystemOld System
45. SYSTEM ANALYSIS 45IMPLEMENTATION : CROSS-OVER TECHNIQUESSometimes 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.OldNewOldNewPilot
46. SYSTEM ANALYSIS 46CONTROL AND REVIEW STAGEControlSetting and redefining standards against which performance canbe compared.Measuring planned against actual performanceTaking corrective action where necessary so that system meets itsobjectivesReviewAt predefined intervals of time, system should be reviewed to giveoverall picture of progress madeFindings help any subsequent system analysis
47. SYSTEM ANALYSIS 47SYSTEM MAINTENANCESystem maintenance implies another system life cycle.MAINTENANCE may be:Adaptive maintenance due to identified new requirementsCorrective maintenance due to identified errorsPerfective maintenance due to identified improvements to the existingset up.Aids to maintenance:Modular designUse of structured systemdevelopment techniquesReadable CodeGood Documentation17%18%65%Corrective Adaptive Perfective
48. SYSTEM ANALYSIS 48DOCUMENTATIONDocumentation may be presented in different forms:ManualsOnline helpDocumentation types:User ManualOperations ManualTechnical Manual(program listing includes inline documentation)
49. SYSTEM ANALYSIS 49USER MANUALTypical information:Overview of options availableGuidance on the sequence of operations to followScreen shots showing screen input formsInstructions on how to enter dataSample report layoutsError messages that may be displayed and whataction to take
50. SYSTEM ANALYSIS 50OPERATIONS MANUALThe operations manual includes all the proceduresnecessary to run the system.Typical information:System setup procedures, including details for eachapplication of the files required and consumablesrequirementsSecurity proceduresRecovery procedures in the event of system failureA list of system messages that might appear on theoperator’s console and what action to take
51. SYSTEM ANALYSIS 51TECHNICAL MANUALTypical information included in the technical manual:Overall system planData organisation and flowFull annotated listingDetails of test data and results
52. SYSTEM ANALYSIS 52DECISION TABLESA DECISION TABLE is a tabularrepresentation of expressingprocess (decision) logic.Decision tables are used toanalyze problems.Conditions applying to theparticular problem are identified;and the actions to be taken as aresult of any combination of theconditions arising are set out.ACTIONENTRIESACTIONSCONDITIONENTRIES(Outcome)CONDITIONS(Questions)
53. SYSTEM ANALYSIS 53DECISION TABLES - EXAMPLEExample:Discounts allowed on customers’order are required to comply withthe following policy:“Any order from a credit-worthycustomer attracts a discount of 5%if the order amounts to €500 ormore, and a discount of 3% if theorder amounts to less than €500.Other circumstances must bereferred to the supervisor for adecision.XXRefer tosupervisorXAllow discount of5%XAllow discount of3%ActionsNYNYIs credit-worthycustomer?NNYYIs order €500 ormore?4321ConditionsRules
54. SYSTEM ANALYSIS 54DECISION TABLES - EXERCISEUse a decision table to represent the following system logic:A credit union pays interest to its depositors at the rate of6% 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 theunion for more than one year get paid the normal 6%,plus a bonus of 1%.
55. SYSTEM ANALYSIS 55MODULARITYA module is a self-contained subprogram, which performsindependently one specific task.Advantages in using modulesRe-usabilityEasier to read, debug and maintain (update)Natural division of workRemarksModules can be compiled separatelyDriver program is required to further test modulesPROCESSINGInputONE entry pointOutputONE exit point
56. SYSTEM ANALYSIS 56TOP-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.ProblemModule AModule A  … Module A [n]Module BModule B  … Module B [n]Module A1  … Module B1  …
57. SYSTEM ANALYSIS 57BOTTOM-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 modulesModule A Module A Module B Module BModule A Module BOriginal Problem
58. SYSTEM ANALYSIS 58STRUCTURE 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 ResultsInput Details Process Details Output DetailsInputResultsValidateinputDetermineGradeCategoryDetermineGradeCountsPrintIndividualResultsPrintStatisticalSummaryPrintErrorListingExercise: Draw a structure chart to representing the issuing of reminderletters for borrowers in a book library system
59. SYSTEM ANALYSIS 59DATA FLOW DIAGRAMSData Flow Diagrams (DFDs) provide a pictorialrepresentation for recording:o Where the data originateso What processing is performed on it (data) and bywhomo Who uses the datao What data is stored and whereo What output is produced and who receives it.
60. SYSTEM ANALYSIS 60DFD SYMBOLSSource/destinationProcessData storeData flowAn operation performed on the data.A process will use or alter the data in some wayE.g. sorting, using data to print a report.A data source or destination which is extended tothe system. E.g. people/departments whoprovide data or receive outputData store denotes object where the data isstored. E.g. data file, transaction file, inputdocument, reportThe arrow represents the movement of databetween entities, processes or data stores.Arrows should be clearly labelled to show whatdata is being transferred.Do not draw data flow directly between datastores and external entities - there should be aprocess box between them to show theoperation performed
61. SYSTEM ANALYSIS 61LEVELLED 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.
62. SYSTEM ANALYSIS 62PAYROLL SYSTEM:- TOP-LEVEL DFDProcessPayrollTime sheetsPayrollsummary dataCheque andpayslip dataEmployeesEmployeesAccountsDepartmentTop level showing a single process:
63. SYSTEM ANALYSIS 63PAYROLL SYSTEM :- SECOND LEVEL DFDEmployee number, hoursworked, batch control totalEmployee number, totalpay, deductions… for allemployeesRate of pay, taxcode…BatchtimesheetsTime sheets Time sheet data andbatch control totalsVerifyandvalidateValid weeklytransaction fileInvalid data batchand control totalsPreparepayrollEmployeenumber, name,total pay,deductions…Cheques andpayslipsEmployee number, hours workedPrintPayrollSummaryPrint anddistributechequesandpayslipsEmployee number, totalpay, deductions… for allemployeesEmployeeAccountsDepartmentEmployeeErrorReportEmployeefile Year-to-date pay…validated data
64. SYSTEM ANALYSIS 64STOCK 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:Stock ReportRequestStock NumberStock descriptionandquantity in stockStock fileEnd UserQueryrequestinputUnformattedquery requestoutput
65. SYSTEM ANALYSIS 65STOCK CONTROL SYSTEM QUERY:-SECOND LEVEL DFDValidationprocess Stock fileDescriptionof stockreportStored outputformatsStock numberStock fileprocessingSelectreportoutputformatStock DescriptionValid StockDataUser
66. SYSTEM ANALYSIS 66DFD EXERCISEA student can register by mail for a college course bysubmitting a registration form with their name, ID numberand the number of courses they wish to take. The systemverifies that the course is not full and enrolls the studenton each course for which a place is still free. The coursefile and student master files are updated and aconfirmation letter is sent to the student to notify them oftheir acceptance or rejection for each requested course.Draw a DFD diagram illustrating how data flows throughthis student registration system.SecondlevelDFDSolution:Heathcote&Langfield,“‘A’levelComputing”,5thed.p.319
67. SYSTEM ANALYSIS 67FLOW 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).
68. SYSTEM ANALYSIS 68FLOW CHARTS SYMBOLSPrinted output CommunicationslinksDatapreparationManualoperationTape/sequentialaccess mediumSort processManualInputOff-pageconnectorDiskDirect AccessstorageStart/end Process Input/Output DecisionPre-definedProcessConnector Flow
71. SYSTEM ANALYSIS 71PROGRAM FLOWCHART (Another Example)StartInput NF = 1M = 1EndF = F * MM = N ?M = M + 1Print FCOMPUTINGFACTORIAL N (N!)N! = 1*2*3* … *NExerciseDraw the flowchart forthe algorithm whichgenerates the first Nterms of the fibonaccisequence where N isspecified by the user.Fibonacci Sequence 0 1 12 3 5 8 …
72. SYSTEM ANALYSIS 72PSEUDOCODEPSEUDOCODE represents a way how we can express thesequence of instructions to achieve a particular task(algorithm) independently of any programming language.Pseudocode consists of English-like statements very closeto the target programming language to be used fordeveloping the software.Examples:SWAP TWO INTEGER VARIABLESAssume swap integer variables X, YDeclare integer TempTemp = XX = YY = TempCHECK WHETHER AN INTEGERVARIABLE IS EVEN OR ODDAssume Integer variable Xif (X modulo 2 == 0)output message “even”else output message “odd”EXERCISE: Use pseudocode for expressing thealgorithm which generates factorial n (n!)
73. SYSTEM ANALYSIS 73ENTITY-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.
74. SYSTEM ANALYSIS 74ENTITY-EVENT MODELAn entity-event model consists ofA 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.
75. SYSTEM ANALYSIS 75ENTITY LIFE HISTORIESA is a structural componentwhich shows that effect B isfollowed by effect CAB CSEQUENCEAB° C°A is a structural component whichshows that either effect B takesplace or effect C but not bothSELECTIONAB*A is a structural component whichshows that effect B takes place 0or more timesITERATIONPARALLELISMABD*CE*A is a structural componentwhich shows that either, both(in any order and any numberof times), or neither of effectsD and E may occurEntity life histories are drawn using the structured design (orprogramming) constructs of sequence, selection, iteration and parallelism
76. SYSTEM ANALYSIS 76ELH EXAMPLEBOOKNew Book Acquisition Book DiscardedLibrary Book LifeBook details changesBook State°Book available changesBook details change* Book available change*Book Borrowed° Book Returned°The 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.
77. SYSTEM ANALYSIS 77EFFECT CORRESPONDENCE DIAGRAMSEffect Correspondence Diagram are drawn in relation toELH. All entities effected by an event are listed.BookborrowedLoanBookThe event ‘book borrowed’effects the LOAN andBOOK entitiesPlace orderOrderOrderlineSet of orderlineoccurrences*The event ‘place order’ effectsseveral occurrences of theORDER entityBookingBookingProvisional°The event ‘booking’ caneffect the booking entity indifferent waysConfirmed°
78. SYSTEM ANALYSIS 78ELH – Another ExampleDraw the EHL diagram for the entity Borrower in thecontext of a book library systemBORROWERNew Membership End MembershipLibrary Member LifeBorrower detail changesBorrower’s address°Borrower detail change*Borrower’s Tel.No.°
79. SYSTEM ANALYSIS 79USE CASE DIAGRAMSThe USE CASE diagram is used to give a high level view of thesystem, depicting who will use the system and what they will be ableto do with it.There are four basic components to USE CASE diagrams:actorUse caserelationshipupdateinventoryadministratorsystemPrepare reportadministrator managerupdateinventoryView report
80. SYSTEM ANALYSIS 80USE CASE DIAGRAMS : GENERALISATIONGENERALIZATION is a technique used to indicateinheritance of an item. Generalization can be applied toboth actors and use cases to indicate inheritance offunctionality from parents.The generalized actor plays amore specific role in thesystemphone order salegeneralized actor generic actor walk-in salesales persontelephoneoperatorsalephone order
81. SYSTEM ANALYSIS 81USE 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.updateinventoryloadinventorysaveinventory<<include>><<include>>verifycredit cardsale<<extend>>The EXTEND relationship is used toidentify when a use case canoptionally be extended byfunctionality in another use case
82. SYSTEM ANALYSIS 82CREATING USE CASE DIAGRAMSSteps to follow in creating USE CASE diagrams:identify the actors and use cases in the systemPrioritize the use casesDetail each use caseStructure the case modelPrototype user interfacesExample:A system is required to:Allow teachers to record and update students’ results; and notifyguardians if individual students’ results are not satisfactoryAllow teachers, students and the administrator to view resultsrecordedEnable the administrator to generate students’ reports
83. SYSTEM ANALYSIS 83“STUDENTS’ RESULTS” USE CASE DIAGRAMRecording students’ results:update gradesteacherstudentrecord gradesview gradessave grades notify guardian<<include>><<include>><<extend>>load grades<<include>>administratorgeneratereports<<include>>
84. SYSTEM ANALYSIS 84EXERCISECreate 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 byloading inventory data from diskThe administrator can update the inventory by loading and savingthe inventory data to and from a diskA sales clerk records walk-in salesA telephone operator is a special type of sales clerk who handlesphone ordersAny kind of sale must update the inventoryA sale may need to verify a credit card if the purchase is a creditcard purchaseA sale may need to verify a check if the purchase is a checkpurchase.
86. SYSTEM ANALYSIS 86CLASS 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:ClassName- attribute 1- attribute 2- attribute 3+ operation 1 ()+ operation 2 ()+ operation 3 ()Visibility:plus (+) signifies that the member is visible.minus (-) signifies that the member is private.hash (#) signifies that the member is visible onlyto classes of the same system – protected.Remarks:•Depending on the detail you want to communicate,only the first compartment is a must.•Note the difference between a hidden compartmentand an empty compartment
87. SYSTEM ANALYSIS 87RELATIONSHIPSTwo classes can relate to each other with a line and anassociation name:Teacher Classteaches >Multiplicity allows us to indicate how many objects of oneclass relate to one object of another class.Teacher Classteaches >1 1..*Exercise: Extend the above class diagram to includeanother class named “Student” where a given studentmay take from four to six classes at any one time and aclass includes fifteen or thirty students.
88. SYSTEM ANALYSIS 88INHERITANCEInheritance is a way of allowing one class to gain thefunctionality of another classAnimalFeline BirdVehicle WeaponTankSay, classes LION and TIGER, inturn, inherit the functionality ofthe class FELINE - inheritancehierarchiesClasses can be derived frommore than one superclass –multiple inheritance
89. SYSTEM ANALYSIS 89POLYMORPHISMPolymorphism 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.AnimalNumberOfEyesNumberOfLegs+Eat()+Sleep()Feline+Run()+Sleep()Bird+Fly()+Sleep()Say, we use polymorphism tomodel the fact that each animalsleeps differently – felines sleeplying down while birds sleepstanding up
90. SYSTEM ANALYSIS 90EXERCISECreate a Class Diagram using the following information:A student can be an undergraduate or a graduate studentAn undergraduate student can be a type of tutorA tutor tutors a studentA teacher and a professor are two types of instructorsA teacher assistant can assist a teacher and a professor,but a teacher can be assisted by only one assistant, whilea professor can be assisted by up to five assistantsA teacher assistant is a type of graduate student
91. SYSTEM ANALYSIS 91SOLUTIONTutor InstructorTeacherStudentUndergraduate Graduatetutors>ProfessorTeacher Assistant<assists assists>0..110..51
92. SYSTEM ANALYSIS 92SOME 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