System Analysis and Design PDF
Document Details
Uploaded by KnowledgeableTabla3412
Bahrain Polytechnic
Tags
Summary
This document provides an overview of system analysis and design, covering various concepts including information systems development, types of information systems, system development methodologies, and classic project phases. It includes details on project management functions and touches on practical applications in business settings. The document highlights key concepts that are important in the field of information systems.
Full Transcript
System Analysis and Design Information Systems development. A system is a set of interacting components that work together to achieve a common goal. It has a boundary, structure, behavior (process) They can be natural or man-made. Information system is an arraig...
System Analysis and Design Information Systems development. A system is a set of interacting components that work together to achieve a common goal. It has a boundary, structure, behavior (process) They can be natural or man-made. Information system is an arraignment of data, people, processes, and information technology that work together to achieve needs. Information technology is a combination of hardware and software. Types of information systems “METE OCD” Transaction processing: Captures, stores, and processes data about businesses. Management Information: Provides results based on information from transaction processing. Decision Support: provides information for decision-making. Expert System: Captures Knowledge of experts and simulates it. O ce Automation: Supports o ce activities e.g. word processing. Communications and collaboration: Allows it between external and (internal users (e.g.; e-mail). Executive Information: Helps in planning and assessing the plans against the strategy. A stakeholder is a person who has an interest in an information system. System owners allocate funds for the operation and maintenance phase. System users use information systems regularly, E.g.: -Internal users: workers, sta , managers. - External users: Customers, suppliers, partners. System designers translate business requirements into technical solutions. Eg:- Database designers, Network architecture. System builders construct information systems based on designs from system designers. Eg:- Application /system/database programmers. System analysts analyze business problems and produce logical models. Skills needed: - Programming - Problem solving Skills. etc. External Service Providers (ESP): Professionals who sell expertise and experience to other businesses. ffi ffi ff The system development methodology is a development process that provides guidelines for completing the phases of systems development It includes: -Technique: to complete 1 or more system phases. E.g: Data modeling - Models: representation of something complex, Improves communication between systems; -Diagrams: Part of a model, Used to communicate, generate, test ideas. e.g: ow chart -Tools: Helps with creating models e.g.: project management app. System development lifecycle techniques: Waterfall model: It’s predictive and a xed outcome. Spiral model: adaptive and the outcome can change anytime. fl fi System development projects come from: 1. Problem: a situation that prevents the organization from achieving a goal. 2. Opportunity: a chance to improve. 3. Directive: new requirements imposed by the government. Classic project phases:- “SPRLD PCIS” 1. Scope de nition - contains a problem statement, constraint, scope creep, and Project charter. 2. Problem analysis - Understanding, analyzing, nding causes of the problem. - Establishing improvement objectives. 3. Requirements analysis - Identifying and prioritizing the requirements (functional/non-functional). 4. Logical decision - User e requirements —> system model. 5. Decision analysis - Solution evaluated in terms of: Technical: are sta experienced? Cultural: it is excepted? Operational: is it ful lled? Economic: is it cost-e ective? Schedule: within time? Legal. Risk: probability of being successful? 6. Physical design and integration - Physical models designed by speci cations or prototyping. 7. Construction and testing - Build and test the design; database, application programmers. fi ff fi ff fi fi 8. Installation and delivery. 9. System operating and maintenance. Project Management A Project is activitues that has one goal which must be completed within the scheduled time, budget, and speci cations. The project is successful when: 1. The result satis es the customer's needs. 2. System delivered on time within the budget. The project is a failure when: 1. Incomplete/changing requirements. 2. lack of executive/technical support. 3. poor project planning. Project management functions: “SPESO DCC” - Scoping: Setting the boundaries of the project (cost, deadlines, etc). - Planning: Identifying the tasks requirements to complete the project. - Estimating: Identifying the resources required. (people, skills, etc). - Scheduling: Developing the plan. - Organizing: Making sure members understand their roles. - Directing: coordinating the project (advise, motivate). - Controlling: monitoring the progress. - Closing: assessing success and failures at the end of the project. PERT chart: a model used to present the dependencies between tasks. Grant chart: a bar chart to present tasks against a calendar. To estimate expected duration: - E ciency: no one performs 100%. Most people are between 75–85%. - Interruptions: calls, visitors, etc. Consume time between 10–50%. Example: A task can be completed in 20 hours with e ciency of 100% and without interruptions. Assuming a project member e ciency of 80% and interruptions of 25%, the estimated time should be: 20 HOURS/0.8 EFFICIENCY = 25 HOURS 25 HOURS/0.75 INTERRUPTIONS = 33.33 HOURS ffi fi fi ffi ffi ESTIMATED TIME = 33.33 HOURS To estimate task duration: Optimistic Duration (OD): Minimum amount of time. Pessimistic Duration (PD): Maximum amount of time. Expected Duration (ED): Expected amount of time. Calculation of the most likely Duration (D). D = (1 * OD) + (4 * ED) + (1 * PD)/6 Task dependencies 1. Finish to Start (FS): Finish o one task triggers the Start of another. 2. Start to Start (SS): The start of one task triggers the start of another. 3. Finish to Finish (FF): Finish of one task triggers Finish of another. (must nish at the same time ) 4. Start to Finish (SF): Start of one task signi es the nish of another. Resource leveling is a strategy for correcting resource over allocations. There are 2 techniques for resource leveling; 1. Task delaying - Slack time is the amount of delay tolerated between the starting and completion time of a task without a delay to the project - Tasks that have slack time can be delayed to achieve resource 2. Task splitting - The critical path is the dependent tasks which determine the earliest possible completion date of the project. - Those tasks can't be delayed without delaying the whole project. To achieve improvement leveling, these tasks are split ff fi. fi fi Problem Analysis The goal of problem analysis is to determine the system improvement objective by understanding its problems. A request for system services is a document that is an input into the ‘Scope’ phase. Usually comes from a business team requesting a project. A problem statement comes from the ‘Scope’ phase and it’s an input into problem analysis. The cause and e ect Analysis is a technique system analysts use to study the system problems and know their causes and e ects. Ishikawa diagram is a tool used for problem analysis that will (identify, analyze, document). The 6M’s template is used to categorize the causes. ff ff Introduction to Information Gathering Information gathering is a technique used to solve identi ed problems and requirements. System requirements are a property that the information system must have. There are functional and non-functional requirements. Functional Non-Functional Functional requirements help to understand the They help to understand the system's functions of the system. performance. Functional requirements are mandatory. While non-functional requirements are not mandatory, but desirable. They are easy to de ne. They are hard to de ne. They describe what the product does. They describe the working of product. It concentrates on the user's requirement. It concentrates on the expectation and experience of the user. It helps us to verify the software's functionality. It helps us to verify the software's performance. These requirements are speci ed by the user. These requirements are speci ed by the software developers, architects, and technical persons. Fact- nding brings system analysts with sensitive information. e.g: Company plans, employees salaries. There are 7 fact- nding methods:- 1. Sampling: the process of collection of samples of documents forms and records. E.g.: organizing organizational charts, samples of database, completed forms. 2. Research and site visits. 3. Observation: a technique of watching people performing their activities to learn more about the system. guidelines: determine, take notes, permission. 4. Questionnaires: Allows Analysis to collect information and opinions from respondents. fi fi fi fi fi fi fi There are free-format questionnaires and xed-format questionnaires. 5. Interviews: a technique of collecting facts based on face-to-face meetings. There is unstructured interview and structured interview. 6. Prototyping: building a working model of the system requirements to discover or verify those requirements. 7. Joint application development (JAD): a technique used to expedite the discovery of system requirements in group meetings. The JAD participants can be the sponsors, IT sta , managers, etc. Brainstorming is important in JAD sessions. fi ff Modeling System with Use Case Use case modeling models business processes in terms of events, triggers, responses. Origins and object oriented modeling. Accepted by non-object oriented modeling as a good communication tool with end users. Collect and analyze requirements free of implementation details. Bene ts of use case modeling:- - Tool for functional requirements. - Decomposes a system scope into more manageable pieces. - Estimate a Project scope, tasks, and schedule. Use-case diagram: graphically depicts the interactions and functionality between the system and its actors, de ning the system's boundaries. Actor: a person, object that interacts with a system to exchange information. Use-case: behavior of the system that describes a business task from an actor’s POV. - A function provided by the system as a set of events that result to the actor. uc Use Case View Login to ATM Bank Customer Bank Database Types of events: - External: Outside the system (customer placed an order). - Temporal: triggered by time (monthly payroll report). - State: inside the system triggers processing needs (Stock Item Level falls below ‘Reorder point’). Use-case modeling steps: 1. Identify business actors (actor glossary). 2. Identify business use case (use case glossary). 3. Construct a use case model diagram. 4. Produce use case narrative. Abstract use case - Common steps in two or more use cases are extracted and put into a new use case. fi fi - The relationship between the use case and abstract use cases is called / or. - /: the use case is mandatory and part of the base use case. - : the use case is optional and comes after the base use case. Inheritance Relationship - Use case relationship that connects actors to an abstract use case. All those relationships reduce redundancy.