System Acquisition and Development PDF
Document Details
Uploaded by HeartwarmingHydrogen
Universitas Brawijaya
Aryo Pinandito
Tags
Related
Summary
This document provides a comprehensive overview of System Acquisition and Development, focusing on information technology infrastructure. It explores different software development methodologies, including the waterfall model, agile methodologies (like Scrum), and extreme programming (XP). The document also discusses the decision of choosing a solution, "buy vs build", for software system development.
Full Transcript
System Acquisition and Development Information Technology Infrastructure Aryo Pinandito, ST, M.MT, Ph.D. Learning Outcomes Understand the concept of buying or building software of an organization Understand the process of software development Understand about agile software development...
System Acquisition and Development Information Technology Infrastructure Aryo Pinandito, ST, M.MT, Ph.D. Learning Outcomes Understand the concept of buying or building software of an organization Understand the process of software development Understand about agile software development process, the benefits and the drawbacks of each process type. Buy vs Build Buy or Build? Organizations can obtain software using one of two basic approaches: buy or build. Buying off-the-shelf software is less risky and leads to quicker deployment; maintenance and support costs may become expensive with this approach, and the software may not be an exact match to the needs and work processes of the organization. Building custom software can provide a better match to the current work processes and provide a potential competitive advantage; software development can be extremely costly, and it can take months or even years to develop custom software. Pros and Cons: Buy vs Build Strategy Pros Cons Buy A software solution can be Unmodified, the software acquired and deployed may not be a good match to relatively quickly. an organization’s needs. An organization can “test drive” Maintenance and support software before acquiring it. costs can become excessive. Build Customized software is more The cost to build a system likely to be a good match to an can be quite high compared organization’s needs. to the cost of purchasing off- A custom application provides the-shelf software. the potential to achieve Customized software can competitive advantage. take months or even years to deploy. Waterfall System Development Process A sequential, multistage system development process in which work on the next stage cannot begin until the results of the current stage are reviewed and approved or modified as necessary. Waterfall: Advantages and Disadvantages Advantages Disadvantages Formal review at the end of each Users get a system that meets the phase allows maximum needs as understood by the management control. developers; however, this might not be what the users really needed. This approach requires creation Often, user needs go unstated or are of considerable system miscommunicated or misunderstood. documentation so that system requirements can be traced back to stated business needs. Approach produces many Users can’t easily review intermediate intermediate products that can be products and evaluate whether a reviewed to measure progress particular product (e.g., a data-flow toward developing the system. diagram) will lead to a system that meets their business requirements. System Investigation The initial phase in the development of a new or modified business information system whose purpose is to gain a clear understanding of the specifics of the problem to solve or the opportunity to address. System Investigation 1. Review system investigation request. 2. Identify and recruit team leader and team members. 3. Develop budget and schedule for investigation. 4. Perform investigation. 5. Perform preliminary feasibility analysis. 6. Prepare draft of investigation report. 7. Review results of investigation with steering team. Joint Application Development JAD: A structured meeting process that can accelerate and improve the efficiency and effectiveness of the investigation, analysis, and design phases of a system development project. JAD Participants and Their Role Facilitator Determines JAD session objectives Plans JAD session to meet objectives Leads JAD session Encourages everyone to participate Decision makers Resolve conflicts Avoid gridlock JAD Participants and Their Role Users Describe business as it is and as it should be Provide business expertise Define problems, identify potential benefits, analyze existing system, define requirements, and propose and evaluate possible solutions System developers Observe carefully Offer technical opinion on cost or feasibility Gain deep understanding of customers’ needs JAD Participants and Their Role Scribe Participate in discussion to clarify points and capture them accurately Document key points, issues, next steps, and decisions throughout the JAD session Publish results of JAD session and solicit feedback Feasibility Analysis An assessment of the technical, economic, legal, operational, and schedule feasibility of a project. Technical feasibility: The process of determining whether a project is feasible within the current limits of available technology. Feasibility Analysis Economic feasibility: The process of determining whether the project makes financial sense and whether predicted benefits offset the cost and time needed to obtain them. Legal feasibility: The process of determining whether laws or regulations may prevent or limit a system development project. Feasibility Analysis Operational feasibility: The process of determining how a system will be accepted by people and how well it will meet various system performance expectations. Schedule feasibility: The process of determining whether the project can be completed within a desired time frame. Prepare Draft of Investigation Report System investigation report: A summary of the results of the system investigation, with a recommendation of a course of action. Review Results of Investigation with Steering Team The system investigation report is reviewed with the steering team to gain their input and counsel. Typically, the written report is shared in advance and then the project manager and selected members of the team meet with the steering team to present their recommendations. System Analysis The phase of system development that focuses on gathering data on the existing system, determining the requirements for the new system, considering alternatives within identified constraints, and investigating the feasibility of alternative solutions. System Analysis 1. Identify and recruit team leader and team members. 2. Develop budget and schedule for system analysis activities. 3. Study existing system. 4. Develop prioritized set of requirements. Critical, Medium, and Low priority Defining System Requirements System requirements must be checked for consistency so that they all fit together. Processes The functional decomposition performed during the investigation phase identifies the majority of the processes to be included within the scope of a new system. be further defined so that they will be practical, efficient, economical, accurate, and timely to avoid project delays. Processes Data-Flow Diagram A data-flow diagram (DFD) is a diagram used during both the analysis and design phases to document the processes of the current system or to provide a model of a proposed new system. The data-flow lines, processes, entities, and data store symbols Data-flow diagram A data-flow diagram documents the processes of the current system or provides a model of a proposed new system. Databases Data modeling is the process of defining the databases that a system will draw data from as well as any new databases that it will create. The Entity-Relationship (ER) diagrams is one technique that is frequently used for this critical step. Databases Entity-relationship (ER) diagram for a customer order database Development of ER diagrams helps ensure that the logical structure of application programs is consistent with the data relationships in the database. Security and Control Security and control considerations need to be an integral part of the entire system development process. Access controls Encryption Dual control procedures, segregation of duties, and employee background checks Monitoring systems and procedures Measures to protect against destruction, loss, or damage Business resumption procedures Context for new system security and control requirements New system security and control requirements must be developed within the organization’s existing policies, standards, and guidelines. System Performance How well a system performs can be measured through its performance requirements. Timeliness of output. Ease of use Scalability System response time Availability Reliability System Analysis 5. Identify and evaluate alternative solutions. 6. Perform feasibility analysis. 7. Prepare draft of system analysis report. 8. Review results of system analysis with steering team. System Design The stage of system development that answers the question, “How will the information system solve a problem?” System design creates a complete set of technical specifications that can be used to construct the information system. System Design 1. Identify and recruit team leader and team members. 2. Develop schedule and budget for system design activities. 3. Design user interface. 4. Design system security and controls. 5. Design disaster recovery plan. 6. Design database. 7. Perform feasibility analysis. 8. Prepare draft of system design report. 9. Review results of system design with steering team. Construction The phase of system development that converts the system design into an operational system by acquiring and installing hardware and software, coding and testing software programs, creating and loading data into databases, and performing initial program testing. Construction 1. Code software components. 2. Create and load data. 3. Perform unit testing. Construction Technical documentation: Written details used by computer operators to execute the program and by analysts and programmers to solve problems or modify the program. User documentation: Written descriptions developed for people who use a program; in easy-to-understand language, it shows how the program can and should be used to meet the needs of its various users. Integration and Testing Several types of testing must be conducted before a new or modified information system is ready to be put into production Integration testing System testing Volume testing User acceptance testing Integration and Testing Integration testing: Testing that involves linking all of the individual components together and testing them as a group to uncover any defects in the interfaces between individual components. System testing: Testing the complete, integrated system (hardware, software, databases, people, and procedures) to validate that the information system meets all specified requirements. Integration and Testing Volume testing: Testing to evaluate the performance of the information system under varying yet realistic work volume and operating conditions to determine the work load at which system performance begins to degrade and to identify and eliminate any issues that prevent the system from reaching its required service-level performance. Integration and Testing User acceptance testing (UAT): Testing performed by trained system users to verify that the system can complete required tasks in a real-world operating environment and perform according to the system design specifications. User acceptance document: A formal agreement that the organization signs stating that a phase of the installation or the complete system is approved. Implementation 1. User preparation, the process of readying managers, decision makers, employees, other users, and stakeholders to accept and use the new system. 2. Site preparation, preparation of the location of a new system. 3. Installation, the process of physically placing the computer equipment on the site and making it operational. 4. Cutover, the process of switching from an old information system to a replacement system. System cutover strategies Cutover can be through direct conversion, phase-in approach, pilot start-up, or parallel start-up. Cutover Direct conversion (also called plunge or direct cutover) involves stopping the old system and starting the new system on a given date. Phase-in approach: A cutover strategy that involves slowly replacing components of the old system with those of the new one; this process is repeated for each application until the new system is running every application and performing as expected; also called a piecemeal approach. Cutover Pilot start-up: A cutover strategy that involves running the complete new system for one group of users rather than for all users. Parallel start-up: A cutover strategy that involves running both the old and new systems for a period of time and closely comparing the output of the new system with the output of the old system; any differences are reconciled. When users are comfortable that the new system is working correctly, the old system is eliminated. System Operation and Maintenance System operation involves the use of a new or modified system under all kinds of operating conditions. Monitoring is the process of measuring system performance by tracking the number of errors encountered, the amount of memory required, the amount of processing or CPU time needed, and other performance indicators. System Operation and Maintenance System review is the process of analyzing a system to make sure it is operating as intended. System review often compares the performance and benefits of the system as it was designed with the actual performance and benefits of the system in operation. System Operation and Maintenance System maintenance is a stage of system development that involves changing and enhancing the system to make it more useful in achieving user and organizational goals. Operation and Maintenance Slipstream upgrade: A minor system upgrade-typically a code adjustment or minor bug fix; it usually requires recompiling all the code, and in so doing, it can create entirely new bugs. Patch: A minor system change to correct a problem or make a small enhancement; it is usually an addition to an existing program. Operation and Maintenance Release: A significant program change that often requires changes in the documentation of the software. Version: A major program change, typically encompassing many new features. Operation and Maintenance System disposal: A stage of system development that involves those activities that ensure the orderly dissolution of the system, including disposing of all equipment in an environmentally friendly manner, closing out contracts, and safely migrating information from the system to another system or archiving it in accordance with applicable records management policies. Agile Development Agile Development An iterative system development process that develops the system in “sprint” increments lasting from two weeks to two months. Scrum Scrum is an agile development framework that uses a team-based approach in order to keep the development effort focused and moving quickly. Scrum master: The person who coordinates all the scrum activities of a team. Product owner: A person who represents the project stakeholders and is responsible for communicating and aligning project priorities between the stakeholders and development team. The Scrum The Scrum agile approach develops a system in sprint increments lasting from two weeks to two months. Advantages and Disadvantages of Agile Development Advantages Disadvantages For appropriate projects, this It is an intense process that approach puts an application can burn out system into production sooner than developers and other project any other approach. participants. Documentation is produced This approach requires as a by-product of system analysts and users to completing project tasks. be skilled in agile system development tools and agile Agile forces teamwork and techniques. lots of interaction between users and stakeholders. Agile requires a larger percentage of stakeholders’ and users’ time than other approaches. Extreme Programming (XP) A form of agile software development that promotes incremental development of a system using short development cycles to improve productivity and to accommodate new customer requirements. include programming in pairs, performing extensive code review, unit testing of all code, putting off the programming of system features until they are actually needed, use of a flat project management structure, simplicity and clarity in code, expecting changes in system requirements as the project progresses and the desired solution is better understood, and frequent communication with the customer and among programmers. DevOps DevOps is the practice of blending the tasks performed by the development staff and IT operations group to enable faster and more reliable software releases Development staff, who are typically responsible for design, coding, and testing IT operations groups, who typically handle operational deployment tasks, such as server provisioning and job scheduling DevOps DevOps is part of a continuous deployment strategy in which releases can be launched daily DevOps blends tasks performed by development staff and IT operations groups. Software Development Approach Comparison Characteristic Agile Waterfall Description An iterative process that A sequential multistage develops the system in sprint process where work on increments lasting 2–8 weeks; the next stage cannot each increment focuses on begin until the results of implementing the highest the previous stage are priority requirements that can reviewed and approved be completed in the allotted or modified as necessary time Basic System requirements cannot All critical system assumption be fully defined at start of requirements must be project fully defined before any coding begins Software Development Approach Comparison Characteristic Agile Waterfall Requirements Users interacting with Users interacting with and design system analysts and system analysts and definition working software system documentation and/or models Associated Scrum Structured system processes analysis and design Buying Off-the-Shelf Software Software Application A software application can vary from an unmodified, commercial off-the-shelf (COTS) software package at one extreme to a custom, written-from-scratch program at the other extreme. Software Development Approach Comparison Factor Develop (Make) Off-the-Shelf (Buy) Cost The cost to build the The full cost to implement an system can be difficult off-the-shelf solution is also to estimate accurately difficult to estimate accurately and is frequently higher but is likely to be less than a than off-the-shelf custom software solution Needs Custom software is Might not get exactly what you more likely to satisfy need your needs Process Tend to automate Adoption of a package may improvement existing business simplify or streamline a poor processes even if they existing business process are poor Software Development Approach Comparison Factor Develop (Make) Off-the-Shelf (Buy) Quality Quality can vary Can assess the quality before depending on the buying programming team Speed Can take years to develop Can acquire it right now Staffing and Requires in-house skilled Requires paying the vendor support resources to build and for support support a custom-built solution Competitive Can develop a competitive Other organizations can have advantage advantage with good the same software and same software advantage Package Evaluation Phase Purchasing off-the-shelf software requires that an organization go through several steps to ensure that it purchases the software that best meets its needs and then implements it effectively. Package Evaluation Phase 1. Identify potential solutions. 2. Select top contenders. 3. Research top contenders. 4. Perform final evaluation of leading solutions. 5. Make selection. 6. Finalize contract. Software package implementation process Software package implementation eliminates several of the phases of the waterfall approach. Finalize Contract Once a selection is made, a contract with the vendor must be negotiated and finalized. Integration and Testing Several types of testing must be conducted before a software package is ready to be put into production. Integration testing System testing Volume testing User acceptance testing Key Implementation Tasks Use DFD to map current business processes and requirements to the software, Install the software, configure all of its capabilities and options, and customize any aspects of the solution. Integrate existing software with the new software. Key Implementation Tasks Train end users and provide for ongoing end-user support. Test the software Convert historical data from the old software. Roll out the new software to users in a live work environment. Questions?