1 / 125

Systems Development Life Cycle & Applications System

Systems Development Life Cycle & Applications System. Chapter 1. Business Application Development Framework. Learning Goals. The need for structured system development The various phases of Software Development Life Cycle - SDLC and their interrelationship in brief Feasibility Study

Télécharger la présentation

Systems Development Life Cycle & Applications System

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.


Presentation Transcript

  1. Systems Development Life Cycle & Applications System Distributed by AGASS (http://www.agass.org)

  2. Chapter 1 Business Application Development Framework Distributed by AGASS (http://www.agass.org)

  3. Learning Goals • The need for structured system development • The various phases of Software Development Life Cycle - SDLC and their interrelationship in brief • Feasibility Study • System Requirement Analysis • Hardware and software acquisition Distributed by AGASS (http://www.agass.org)

  4. Introduction • Logical starting point in the entire life cycle of a computerized system. • Activities starts when : • decides to go for computerization • migrate from existing computerized system to a new one • Understanding of why and how systems are deployed Distributed by AGASS (http://www.agass.org)

  5. Introduction… • A System can be defined as “a collection of inter-related components or sub-systems”. E.g. our solar system – consisting of Sun and planets, our body can be considered as a system of collection of organs, bones, tissues, blood etc. • Business - collection of systems such as manufacturing, stores, purchase, administration, accounts and so on. • Systems have a life span after which they will be replaced. Systems will become obsolete due to.. • Technology may become outdated • People using the system may change • Government or other regulatory change may render the systems obsolete. • Business needs are expanded due to expansion of business, mergers, take-overs etc. • With the increased use of computers, it is necessary to have more organized ways of developing systems and procedures Distributed by AGASS (http://www.agass.org)

  6. Introduction … • SDLC gives way to all other activities covered in other modules such as : • protection of IT assets • business continuity • IS Audit Process etc. Distributed by AGASS (http://www.agass.org)

  7. Characteristics of a System • Each system consists of inter-related sub-systems or components • System has an identifiable boundary and works within it’s boundary • Each system will have Purpose of existence • Environment of the system – external to the system • Interface to the system – for interaction with environment • Inputs to the system – e.g. data • Outputs generated by the system - information • Constraints or business rules for the system Distributed by AGASS (http://www.agass.org)

  8. Business Application Development • Developing or acquiring and maintaining application systems which will be used for various day-to-day business activities. • The effective management and control of this development. • The SDLC involves defined phases,the phases may be undertaken in a serial manner or in a parallel manner. Distributed by AGASS (http://www.agass.org)

  9. Need for Structured Systems Development Methodology • Software is not a tangible product which can be put to use immediately • Software products are not manufactured but are developed by developers. Therefore, their quality heavily depends on the quality of people carrying out system development. • Developing software products in an organized manner means : • software development should be treated as a Project • Schedules of completion and deliverables in a time line for various phases • Resources and cost estimation for all the phases • Quality standards for comparing products of every phase Distributed by AGASS (http://www.agass.org)

  10. Risks associated with SDLC • Necessary to know these risks prior to undertaking SDLC projects. • The objective is to : • Identify risks • Discovering methods to eliminate or mitigate them • Accepting residual risk and going ahead with the project • Some of the Risks : • Cumbersome for the development team due to lot of documentation • The users may find that the end product is not visible for a long time. • Due to formal structured methodology, duration of project may be longer, thus it may not be suitable for small and medium sized organizations. Distributed by AGASS (http://www.agass.org)

  11. Software development : distinct processes • Identifying the need or problem for the development - Project Initiation, Feasibility Studies • Specifying the system - Requirements Analysis • The potential benefits from new system - Feasibility Study • Identification and evaluation of factors which affect business - Project Initiation, Feasibility Studies • Designing of the system - System Design • Programming - Developing source code • Program testing • Implementation Distributed by AGASS (http://www.agass.org)

  12. Project Initiation • Whenever a business entity decides (i.e. stakeholders in the business or senior management) to undertake computerization, a Project will have to be initiated. This process is called as Project Initiation. • E.g. A new business application is required to be developed to address a new or existing business process e.g. a billing system • The outcome of Project Initiation is a formal Project Initiation Report which is presented to senior management or BOD. • This will be accepted with or without modifications and then the next phases of SDLC will be rolled out. • In case of SMEs or very small organizations, a formal Project Initiation Report may not be prepared. Distributed by AGASS (http://www.agass.org)

  13. Phases in SDLC • Feasibility Study • Requirements Analysis • Systems Design • Programming / Construction • Testing • Implementation • Post-Implementation Distributed by AGASS (http://www.agass.org)

  14. Phase 1 - Feasibility Study • Organizations cannot give unlimited resources, unlimited budgets and unlimited time-frames for projects. • Therefore this requires a Feasibility Study covering the following aspects of a project.. • Economic • Time • Technical • Operational • Resources • Behaviroural • Legal • It is done by identification of problem, identification of objectives, delineation of scope, conducting feasibility study Distributed by AGASS (http://www.agass.org)

  15. Phase 2 – Requirements Analysis • Understanding Requirements • Study of history, structure and culture • Study of Information flows • Eliciting user requirements • Structured Analysis • Context and Data Flow Diagrams (DFD) • Entity-Relationship diagram • Data dictionaries • Decision Table / Decision Tree / Structured English • State Transition diagram Distributed by AGASS (http://www.agass.org)

  16. Phase 2 – Requirements Analysis… • System charts / program flow charts • Interface in form of data entry screens and dialogue boxes • Report layouts • In the industry, the Requirement Analysis is known by different names such as • Systems Requirements Specifications (SRS), • Business Requirements Specifications (BRS), • Users Requirements Specifications (URS) or Users Requirement Document (URD). • Strictly speaking, all these will give different aspects of requirements Distributed by AGASS (http://www.agass.org)

  17. Software Acquisition • Software acquisition is not considered as a standard phase in SDLC • Requirements analysis should be carried out even if software acquisition is planned • Request for Proposal – RFP should be prepared which should give at a minimum : • Product vs System requirements • Customer References • Vendor viability and financial stability • Availability of complete and reliable documentation about the new software • Vendor support • Response time • Source code availability • Vendor’s experience • A list of recent or planned enhancements to the product with dates • List of current custom¬ers • Acceptance testing of product Distributed by AGASS (http://www.agass.org)

  18. Roles involved in SDLC • Steering Committee • Project Manager • Systems Analyst • Team Leader • Programmer • DBA • Quality Assurance • Tester • Domain Specialist • Technology Specialist • Documentation Specialist • IS Auditor Distributed by AGASS (http://www.agass.org)

  19. Chapter 2 Phases in Software Development Distributed by AGASS (http://www.agass.org)

  20. Learning Goals • A clear understanding of all the phases of SDLC except the phase involving feasibility study and system requirement analysis, which we have seen in Chapter 1. • This chapter will cover the phases of Programming, Testing, Implementation and Post implementation Distributed by AGASS (http://www.agass.org)

  21. System Design Phase • Based on the requirements analysis done by development team, a system will be designed. • As explained in Chapter 1, if Software Acquisition is planned, then the next 2 phases viz Systems Design and Programming will not be undertaken. • In the last chapter, we have seen how Requirements Analysis is carried out by using Structured Analysis technique. • The same technique is used for describing the Design of the system. • We will now study some other aspects of Systems Design Distributed by AGASS (http://www.agass.org)

  22. Systems Design • Developing system flowcharts to illustrate how the information shall flow through the system. E.g. DFDs. • Defining the applications through a series of data or process flow diagrams, showing various relationships from the top level down to the detail. E.g. E-R diagrams, data dictionaries etc. • Describing inputs and outputs, such as screen design and reports. We shall describe this later. • Determining the processing steps and computation rules for the new solution. E.g. Decision Tables / trees and Structured English • Determining data file or database system file design. E-R diagram and data dictionaries will lead to design of the table • Preparing the program specifications for the various types of requirements or information criteria defined. This topic is also beyond our current scope. Distributed by AGASS (http://www.agass.org)

  23. Systems Design … • Thus, this phase deals with the way the proposed system can be transformed into a working model. • The steps involved in this phase are: • Architectural design • Design of data / Information flow • Design of database • Design of user interface • Physical design • Selection of appropriate hardware and software Distributed by AGASS (http://www.agass.org)

  24. Architectural design • Architectural design deals with the organisation of applications in terms of hierarchy of modules and sub-modules. • It is necessary to identify : • Major modules e.g. Masters, Transactions, Reports etc • Function and scope of each module • Interface features of each module • Modules that each module can call directly or indirectly • Data received from / sent to / modified in other modules • The architectural design is made with the help of a technique called as functional decomposition wherein top level functions are decomposed (i.e. broken into) and inner-level functions are discovered. This process is continued till our context is met with. Distributed by AGASS (http://www.agass.org)

  25. Design of data / Information flow • We have already seen this in the last chapter thru Context and DFDs Distributed by AGASS (http://www.agass.org)

  26. Design of database • We have seen what are entities and E-R diagrams in the last chapter. • In designing database, entities are described in detail, with their structure. • E.g. an Employee entity, obvious structure elements (also called as attributes, fields, columns) would be Employee ID, Name, Address, Date of Birth etc. • Only those attributes which are of current interest w.r.t. the current system (or system module) are only considered. • When design of all entities is over, they can be put in a repository to form a Data Dictionary so that, common entities across the system can be used by other development team members. Distributed by AGASS (http://www.agass.org)

  27. Design of database… • The design of database consists of 4 major activities • Conceptual modeling – E-R digrams giving relationship between entities • Data modeling – describing data types, length • Storage structure design – how to store data on a physical device e.g. hard disk • Physical layout design – hard disk track level design is done Distributed by AGASS (http://www.agass.org)

  28. Design of user interface • This is nothing but designing of data entry screens, dialogue boxes • Important aspects are... • Menu navigation should be easy and promote the users to use the software • Screens with soothing foreground and background colours should be designed • Place for company logos, dates etc should be uniform throughout the screens • For multipage screen layout, it is better to have tabs with page numbers indicating on which page the user is • Mandatory fields should be indicated explicitly • If system is going to take time for processing after a user action, it should be clearly displayed intermittently on screen • Developers should design screen by keeping in mind computer awareness level of users. Distributed by AGASS (http://www.agass.org)

  29. Physical Design • The logical design needs to be ultimately mapped or implemented on a Physical Design. • E.g.hardware, operating system, database management system and any other software needed. • Generally, following types of components need to be selected and finalized. • Hardware – e.g. hardware for servers, desktops etc. • Power Systems – such as UPS, generators, line conditioners etc. • Networking and telecommunication equipment – such as hubs, switches, routers, repeaters etc • Operating system – e.g. Windows (XP, Windows 2003 etc), Unix or Linux • RDBMS – such as Oracle or Microsoft SQL Server or MySQL etc. • Web server software – for web based systems server will have this software which will interact with database and application software which are loaded on servers (called as database and application servers). E.g. Internet Information Server (IIS), Apache etc. Distributed by AGASS (http://www.agass.org)

  30. Physical Design… Types of components … • Transactions processing software and message queuing software – These are classified under Middleware since they are neither near user (client or front-end) nor near machine (such as OS or RDBMS). Their main function is to process a transaction and/or queue up transactions for further processing. • Client software – This software will reside on desktop or client machine. Depending upon type of system, a client software may have to be separately installed The client software will be connected to Application software when user invokes it. Distributed by AGASS (http://www.agass.org)

  31. Development Phase: Programming Methods, Techniques And Languages • The Development Phase takes the detailed design developed in the Design Phase and begins with coding by using a programming language. • The responsibility of this phase is primarily that of the Programmers. • The following are the key activities performed during this phase. • Coding and developing programs and system level documents • Testing and debugging continuously for improvements in program developed • Developing programs for conversion of the data in the legacy system to new system • Formulating the procedures for the transition of the software by the various users • Training the selected users on the new system • In case of vendor supplied software, documenting the modifications carried out to ensure that future updated versions of the vendor's code can be applied. Distributed by AGASS (http://www.agass.org)

  32. Programming Methods & Techniques • For effective and efficient software product, following techniques should be used… • Adoption of the Program Coding Standards • Structured programming • Online Programming Facilities • Use of suitable Programming Language and method • Procedural programming – past trend • Object Oriented Programming Technique – current trend Distributed by AGASS (http://www.agass.org)

  33. Program Debugging • Debugging is the most primitive form of testing activity. • Programmers usually debug their programs while developing their source codes by activating the compiler and searching for implementation defects at the source code level. • The need for extensive debugging is often an indication of poor workmanship. • Debugging software tools assist the programmer in fine tuning, fixing and debugging the program under development. Distributed by AGASS (http://www.agass.org)

  34. Program Debugging… • Debugging tools help programmers in debugging activity • These tools fall in the following three categories… • Logic Path Monitors: provide logic errors by reporting on the sequence of events achieved by the program • Trace: This lists the changes in selected variables at different stages of the program. • Memory Dumps: provides a picture of the internal memory content at the point where the program has abruptly ended, providing the clues to the programmer on the inconsistencies in data and parameter values. • Output Analyzer: checks the accuracy of the output which is the result of processing the input through that program by comparing the ac­tual results with the expected results. Distributed by AGASS (http://www.agass.org)

  35. Software Testing Phase • Software testing is the process of testing software in a controlled manner to ensure it meets the specifications. • During testing, the developer should give up preconceived notions of the correctness of the software developed. • Testing is carried out in the Test Environment. • For some large and complex systems, development and testing environment may be separate. • Objectives of testing • Testing is a process of executing a program to identify an error. • Agood test case is one that has high probability of finding an error. • A successful test is one that uncovers an error. Distributed by AGASS (http://www.agass.org)

  36. Levels of testing • Every software normally goes through the following levels of tests: • Unit testing • System testing Distributed by AGASS (http://www.agass.org)

  37. Unit testing • Unit testing is the process of testing individual units (i.e. individual programs or functions or objects) of software in isolation. • A program unit is usually small and the programmer who de­veloped it can test it in a great detail. • There are four categories of tests that a programmer typically performs on a program unit: • Functional tests - These tests check whether programs do what they are supposed to do. • Performance tests - These should be designed to verify the response time, the execution time, the throughput, primary and secondary memory utilisation and the traffic rates on data channels and communication links • Stress tests - These are designed to overload a program in various ways. The purpose of a stress test is to determine the limitations of the program. • Structural tests - These are concerned with examining the internal processing logic of a software system. • Parallel Tests - By using the same test data in the new and old system, the output results are compared. Distributed by AGASS (http://www.agass.org)

  38. Types of unit tests • Static analysis tests • Desk Check: This is done by the programmer himself. He checks for logical syntax errors, and deviation from coding standards. • Structured walk-through: The application developer leads other programmers through the text of the program and explanation • Code inspection: The program is reviewed by a formal committee. Review is done with formal checklists. The procedure is more formal than a walk-through. • Dynamic analysis tests • Black Box Test: Assumes no knowledge of internal logic of programs • White Box Test: Assumes knowledge of internal logic of programs Distributed by AGASS (http://www.agass.org)

  39. Integration / Interface testing • The objective is to evaluate the connection of two or more components that pass information from one area to another. • This is carried out in the following manner. • Bottom-up integration: • Bottom-up integration is the traditional strategy used to integrate the components of a software system into a functioning whole. • It consists of unit testing, followed by sub-sys­tem testing, and then testing of the entire system. • Top-down integration: • Top-down integration starts with the main rou­tine, and stubs are substituted, for the modules directly subordinate to the main module. • An incomplete portion of a program code that is put under a function in order to allow the function and the program to be compiled and tested, is referred to as a stub. • Regression tests: • Each time a new module is added as part of integration testing, the software changes. • These changes may cause problems with functions that previously worked flawlessly. • In the context of the integration testing, the regression tests ensure that changes or corrections have not introduced new errors. • The data used for the regression tests should be the same as the data used in the original test. Distributed by AGASS (http://www.agass.org)

  40. System testing • System testing is a process in which software and other system elements are tested as a whole. • System testing begins either when the software as a whole is operational or when the well defined subsets of the software's functionality have been implemented. • The purpose of system testing is to ensure that the new or modified system functions properly. • These test procedures are often performed in a non- production test en­vironment. • The following types of testing might be carried out. • Recovery Testing : Checking the ability of recovery of the system after the failure of hardware or software. • Security Testing: Ensuring the existence and proper execution of ac­cess controls in the new system. • Stress or Volume Testing: Testing the application with large quantity of data during peak hours to test its performance. • Performance Testing: Comparing the new system's performance with that of similar systems using well defined benchmarks. Distributed by AGASS (http://www.agass.org)

  41. Final Acceptance Testing or Users Acceptance Testing • Final Acceptance testing is conducted when the system is just ready for implementation. • During this testing, it is ensured that the new system satisfies the quality standards adopted by the business and the system satisfies the users. • Thus the final acceptance testing has two major parts: • Quality Assurance Testing: ensures that the new systems satisfies the prescribed quality standards and the development process is as per the organisation's quality assurance methodology. • User Acceptance Testing: ensures that the functional aspects expected by the users has been well addressed in the new system. • There are two types of the user acceptance testing. • Alpha Testing: is the first stage, often performed by the users within the organization • Beta Testing : is the second stage, generally performed by the external users. This is the last stage of testing, and normally involves sending the product outside the development environment for real world exposure. Distributed by AGASS (http://www.agass.org)

  42. Implementation of Software • Planning of the implementation should be commenced much before actual date of the implementation • The implementation plan as developed in the Design Phase should be used with the modifications if required. • There are four types of implementation strategies: • Direct implementation / Abrupt change-over : The old system is suspended on a specific day and the new system is tried out. • Parallel implementation : Both the old and new systems are run in parallel to verify if their output is the same. Then the old system is suspended. • Phased implementation : The new system is implemented in parts. This makes implementation more manageable. • Pilot implementation : The new systems is first implemented in a small, non-critical unit and then moved to larger unit. Distributed by AGASS (http://www.agass.org)

  43. Activities during Implementation Stage • Major activities during implementation are: • Installation of new hardware / software • Data conversion: Following steps are necessary. • Determining what data can be converted through software and what data manually. • Performing data cleansing before data conversion • Identifying the methods to access the accuracy of conversion like record counts and control totals • Designing exception reports showing the data which could not be converted through software. • Establishing responsibility for verifying and signing off and accepting overall conversion by the system owner • Actual conversion • User Final Acceptance testing • User training • Manager's training on overview and MIS • Operational user training on how to use the software, enter the data, generate the output • IT department’s training on the technical aspects Distributed by AGASS (http://www.agass.org)

  44. Post Implementation Review • In PIR, after the system stabilizes, a check should be done to ensure that the system has fulfilled the objectives. Otherwise, move back to the appro­priate stage of the development cycle. • The PIR should be performed … • jointly by the project development team and the appropriate end users • an independent group not associated with the development process, either internal or external • Audit should be conducted to meet the following objectives: • Whether the system met management's objectives and user requirements • Whether the access controls have been adequately implemented and actually working • Evaluation and comparison of the actual Cost Benefit or ROI as against the same projected in the feasibility study phase. • Recommend on the system's inadequacies and deficiencies • Develop a plan for implementing the accepted recommendations • Evaluate the system development project process Distributed by AGASS (http://www.agass.org)

  45. Post Implementation Review… • Maintenance is also part of the post implementation review. It can be categorized into four types: • Corrective maintenance : Correcting errors that may surface during the running of the applica­tion. • Adaptive maintenance : Rapid changes in technology may cause an application to be run in a new technical environment in the user site. Web enabling a legacy application would fall in this category. • Perfective maintenance : Perfective maintenance is required when the user wants additional functionalities. Extending the purchase order system to cover service orders will fall in this category. • Preventive maintenance : When the software is changed to suit future maintainability, it is called preventive maintenance. Distributed by AGASS (http://www.agass.org)

  46. Chapter 3 Alternative Methodologies of Software Development Distributed by AGASS (http://www.agass.org)

  47. Learning Goals • To provide an understanding of: • Different approaches to system development - advantages, problems encountered and selection criteria • Different aspects involved in maintenance of information systems Distributed by AGASS (http://www.agass.org)

  48. Traditional SDLC Models • Waterfall Model • Spiral Model • Today’s trend of OOP and web-based systems demands that Alternative Development methodologies be adopted instead of traditional methods. Distributed by AGASS (http://www.agass.org)

  49. Data Oriented Systems Development • Data oriented system development focuses on data structure and not data flow while processing. • Systems that optimize data usage are classified as data-oriented systems. • This approach considers data independently of the processing that transforms the data. • Management Information Systems (MIS) and Data Warehousing applications fall in this category. • Process-oriented approach specifies how data is moved and / or changed in the system Distributed by AGASS (http://www.agass.org)

  50. Object Oriented Systems Development • In this method, the system is analyzed in terms of objects and classes and the relationship between objects and their interaction. • Objects are defined as entities that have both data structure and some behaviour. • E.g. employee record is an object having properties : employee name, employee ID etc. and behaviour such as AddEMployee, RemoveEmployee, TransferEmployee etc. • Major advantages of this approach are: • Ability to manage a variety of data types • Ability to manage complex relationships • Capacity to meet demands of a changing environment • Reusability of logical elements • Data Security • Object Oriented technology is widely used in: • Computer Aided Engineering (CAE) • Systems software Distributed by AGASS (http://www.agass.org)

More Related