1 / 61

SYSTEMS ANALYSIS AND DESIGN

SYSTEMS ANALYSIS AND DESIGN. Presentation by: Walter Onditi Perpetua Mugereki Eunice Ngunjiri Sammy Nyambu William Turi. Topics Covered. Software Acquisition Installation Implementation Activities Post Implementation Software Support and Maintenance. SOFTWARE AND ACQUISITION.

Download Presentation

SYSTEMS ANALYSIS AND DESIGN

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. SYSTEMS ANALYSIS AND DESIGN Presentation by: Walter Onditi Perpetua Mugereki Eunice Ngunjiri Sammy Nyambu William Turi

  2. Topics Covered Software Acquisition Installation Implementation Activities Post Implementation Software Support and Maintenance

  3. SOFTWARE AND ACQUISITION

  4. Evaluating and Purchasing Software Packages Examine software alternatives and select an overall strategy for the proposed System to prepare for the transition to the systems design phase. Process • Step 1: Planning the acquisition eg Assigning Key Roles • Step 2: Defining the software product’s requirements i.ethe software requirements are elicited, analyzed, specified and validated . • Step 3: Determining the acquisition approach • Step 4: Identifying and evaluating potential suppliers (and their software products) eg Formal Request-For-Proposal (RFP) • Step 5: Defining the contract requirements eg Fixed-Price Contracts, Cost reimbursable contract • Step 6: Selecting a supplier eg Cost/Benefit Analysis, • Step 7: Negotiating and awarding the contract eg Risk Sharing:

  5. Process Cont--- Define the Software Product Build Determine Acquisition Approach Plan the Acquisition Software development Buy Negotiate & Award Contract Identify & Evaluate Potential Supplier Select a Supplier Manager Supplier Accept Product & close Contract Define Contract Requirement

  6. METHODS OF ACQUIRING SOFTWARE Custom Developed Software • In-house Development. • Contract an External Software – Advantages of Custom Developed Software • Resultant program will exactly fulfill the processing requirements. Disadvantages of Custom Developed Software • Higher Cost eg Cost borne by one organization than being shared • Software Defect

  7. In-House Developing Companies choose in-house development to: Satisfy Unique Business Requirements Minimize Changes in Business Procedures and Policies Meet Existing Technology Develop Internal Resources and Capabilities

  8. Package Purchasing – Off-the self Packages A commercially available software package could satisfy system requirements. Advantages • Lower Cost • Less Time to Implement • Proven Reliability and Performance Benchmarks • Less Technical Development Staff • Future Upgrades Proved by the Vendor • Other Companies as Resources • Better Documentation • Training Easily Available • Disadvantages of Packaged Software • May not meet all requirements • Less efficient

  9. Customizing Software Packages Acquire a package that can be customized to meet the needs of an organization. -Purchase a basic package that vendor will customized to suit your needs Negotiate directly with the software vendor to make enhancements to meet your needs by paying extra charge Purchase the package and make your own modification.

  10. In-House developed vs Purchased Package

  11. Other Software Alternatives Other possibilities include using : • An application service provider - An ASP delivers applications, or access to applications, by charging a usage or subscription fee , license (Application Hosting) • Outsourcing - is the use of outside companies Called Service Providers to handle a portion of a company’s IT workload on a temporary or long- term basis. • Developing end-user applications - utilize standard business software, such as Microsoft Office, which has been configured in a specific manner to enhance user productivity.

  12. Disadvantages of Outsourcing • Could lose control over the software, risk is high due to competition • Do not build internal competence • Development costs could exceed the budget • Time schedule could be overrun • The outcome might not meet expectations • Some projects could be canceled before end of development period • Customer might not take active part in development

  13. Recommended Software Acquisition Best Practices

  14. System Installation

  15. Installation is the setup or making the system ready for execution and available for users. Systems often come with a specialized program for installation referred to as installer Systems can be installed from a storage media (CD/DVD or flash drive), or from a network.

  16. Types of installation Attended installation An installation process that needs a user who attends to it in order to make choices, such as accepting or declining EULA (end-user license agreement ) and installation location Often uses wizard-based interface installers may ask users to help mitigate the errorsE.g. if the installation disk chosen is full, the user is asked to specify another target path.

  17. Unattended installation Installation that is performed without user interaction during its progress It does not require the user to supply any information They use an answer file, a file that contains all the necessary parameters prior to the start of installation. There is no user to help mitigate errors so if the installation medium was faulty, the installer stops the installation and may record errors in a computer log for later review Silent installation Installation that does not display messages or windows during its progress. Done for convenience or subterfuge (Deceit) E.g. Malware is always installed silently when a user plugs in an infected device

  18. Scheduled or automated installation An installation process that runs on a preset time or when a predefined condition is met E.g. installations of updates when the machine is idle or weekly antivirus updates Clean installation Done in the absence of any interfering elements such as old versions of the computer program being installed or leftovers from a previous installation.

  19. Activities during Installation Recommended system requirements: certain hardware components or other software resources that have to be present on a computer Checking for existing versions of the software Creation of Shortcuts or links; Making the software accessible to user with minimum clicks Performing product activation

  20. Before implementing, it is necessary to Develop a test System that fulfils business and design requirements • This test system implements the interfaces between the new system and existing systems. • This is referred to as Construction phase

  21. Activities Involved • If system calls for new network functionality, then it must be built and tested first • The Network designer – designs LANS and WANS and tests the connectivity • The Network administrator – takes care of the network security • Systems analyst Ensures that business requirements are not compromised i.e. ensures that Standards are met

  22. Creationand Testing of databases Test with sample data • System users • Provide test data • Database designer/programmer • Build tables, views, stored procedures (if relational database) • Database administrator • Manipulate the database for optimum performance • Deals with Security • Backup and recovery

  23. Installation of New Software Packages Some Systems solutionmay require purchase or lease of software packages Involves System users, analysts, designers, builders, vendors and consultants

  24. Testing New Packages • An investigation conducted on a system to evaluate the its compliance with its specified requirements. • Its is done to confirm that all modules work as specified, and as a system as a whole . • Testing is done after entire program is written

  25. Testing levels • Stub test - done on individual events or modules of program to simulate the behaviors of software components • Unit test - This is done on modules coded & stub tested for a program and tested as integrated unit. • Systems test -This ensures that separately developed and tested modules can properly when integrated into total system

  26. IMPLEMENTATION ACTIVITIES

  27. INTRODUCTION • Once a new system has been designed, it must be implemented as a working system and maintained to keep it operating properly. • Many implementation activities should be undertaken in parallel to reduce implementation time. Training of personnel and preparation of software may be in parallel with each other and with other implementation activities.

  28. Implementation

  29. Planning the implementation Phase 1: Preparation • Identify project manager, administration & other key team members • Review technical requirements with IT • Training for Administrators Phase 2: Set Up • Configure general site information • Customise branding • Set Session defaults • Customise email templates • Add users

  30. Planning the implementation Phase 3: Roll Out • Training session leaders • Activate all user accounts • Users to create/conduct private sessions • General Question & Answer Sessions • User start conducting live sessions Phase 4: Follow up • Monitor usage-Ongoing • Hold follow up meetings-Ongoing

  31. Implementation phase

  32. System conversion Strategies Once the design has been completed, there are four basic methods for implementing the information system. Parallel conversion Old & new system run simultaneously until end users and project coordinator are satisfied that the new system is functioning correctly. It can be effected by using; • a single cut over (predetermined date) or • phased cut over (predetermined method). Outputs are compared from both systems for convergence and accuracy. It has low risk but high cost. .

  33. System conversion Strategies Direct Conversion/Slam dunk/cold turkey strategy/abrupt cut over Here, old system/method is switched off; new method is switched on. It has the least costs but has high risk of failure. It’s the only viable solution in activating new systems where two systems cannot co-exist Pilot/Locational Conversion The new system is installed in multiple locations such as branches from geographic perspective. It allows for direct or parallel methods to be used at a single location. It offers the best representation of organization. It is less risky and allows for evaluations before rolling out to different locations.

  34. System conversion Strategies Phased/Staged Conversion This is an increamental approach. The new system is brought as a series of functional components that are logically ordered to minimize disruption to end users and flow of business. It takes a lot of time, less risky and is the most disruptions to organizations over time. Small parts or subsystems are substituted for the old. In the case of upgrading old systems, this may be a very desirable method.

  35. Implementation Tasks

  36. Implementation Tasks

  37. Implementation Tasks

  38. Implementation Tasks

  39. Implementation Tasks

  40. Implementation Tasks

  41. Implementation Tasks

  42. Implementation Tasks

  43. Implementation Tasks

  44. Implementation Tasks

  45. Post Implementation

  46. What is Post Implementation Review [PIR] • A Post-Implementation Review (PIR) is an assessment and review of the completed working solution. • It will be performed after a period of live running, some time after the project is completed. • Why conduct a PIR? • To ascertain the degree of success from the project, in particular, • the extent to which it met its objectives, • delivered planned levels of benefit, and • addressed the specific requirements as originally defined. • To examine the efficacy of all elements of the working business solution to see if further improvements can be made to optimize the benefit delivered. • To learn lessons from this project, lessons which can be used by the team members and by the organization to improve future project work and solutions.

  47. Post-ImplementationReview • When to conduct the PIR? • A Post-Implementation Review should be scheduled some time after the solution has been deployed. • Typical periods range from 6 weeks to 6 months, depending on the type of solution and its environment. • The PIR is intended to be an assessment and review of the final working solution. There should have been at least one full processing and reporting cycle completed. • It should not be performed while the initial snags are still being dealt with or while users are still being trained, coached and generally getting used to its operation. Issues Note: The PIR should be timed to allow the final improvements to be made in order to generate optimum benefit from the solution. There is no point in waiting too long as the results are intended to generate that final benefit for the organisation and team Initial Trouble- shooting Settling Down PIR Fine Tuning Final Improvements Go Live Time

  48. PostImplementation • Who should conduct the Post Implementation Review [PIR] • Under normal circumstances, members of the project team will want to complete the review as a natural extension of their responsibility to deliver optimum benefit from the solution. • The argument is that they understand • what was required, • what was changed, • how it was achieved, • how things are supposed to work, • how to fix problems, • However another school of thought will argue that that the review should be performed by an independent team. • This reduces the risk that any errors or omissions of the project team might equally be overlooked in their review. What Do you think?????? • A solution is to do both. An independent audit team, working in consultation with the business users and project team, could examine whether the results are satisfactory. • The project team might then reconvene to consider that input and also to examine how to generate further value from the solution.

  49. How to conduct the PIR • A list of points should be drawn up to cover all elements of the operational solution including:- • Current situation • Is the required functionality available? • Have users received adequate training and coaching to take advantage of the new facilities? • Are staffing levels and skillsets appropriate for the actual workloads? • Are third parties such as customers and suppliers satisfied with the service? • Are faults handled at an acceptable speed and with satisfactory results? • Is data integrity being maintained within the system and in relation to other integrated or interfaced systems? • Does the system and its usage meet current legal and regulatory requirements? • Does the system have the capacity to deal with the actual peak loadings as encountered and foreseen? • Benefits • What were the final costs of the project? • What is the actual operating cost of the new solution? • What is the actual benefit being delivered by the new solution? • How does that compare to the original project definition? • Future improvements • Could further training or coaching improve the degree of benefit being generated? • Are there further functional improvements or changes that would deliver greater benefit? • Are specific improvements required in procedures, documentation, support, etc? • What learning points are there for future projects? • These questions will be investigated through a combination of investigative techniques including • interviews, • examination of documentation, • performance statistics, • hands-on tests and checks, • Implications and potential remedial options would then be assessed and evaluated. • The findings and recommended actions would be prepared, normally in the form of a report or presentation.

More Related