Presentation is loading. Please wait.

Presentation is loading. Please wait.

Chapter 5 System Analysis Sarah El Sehemawy Karim Elsabee Sherine Meshad Hakim Meshriky Ahmed Zaki Ismail Abou Hamda.

Similar presentations


Presentation on theme: "Chapter 5 System Analysis Sarah El Sehemawy Karim Elsabee Sherine Meshad Hakim Meshriky Ahmed Zaki Ismail Abou Hamda."— Presentation transcript:

1 Chapter 5 System Analysis Sarah El Sehemawy Karim Elsabee Sherine Meshad Hakim Meshriky Ahmed Zaki Ismail Abou Hamda

2 System Analysis It is a problem solving technique that decomposes a system into component pieces for the purpose of studying how well those components work and interact to accomplish their purpose. It primarily focuses on the business view, independent of any technology. System Design It is a complementary problem solving technique to system analysis that reassembles a system’s components pieces back into a complete system – hopefully an improved system. This may involve adding, deleting and changing pieces relative to the original system.

3 System Analysis Approaches Model-Driven Analysis Approaches Structured Analysis Information Engineering Object-Oriented Analysis Accelerated Analysis Approaches Discovery Prototyping Reverse Engineering

4 Model-Driven Analysis Approach Structured Analysis Definition: It is a model-Driven, Process-centered technique used to analyze an existing system, and propose a new one. Processes are the primary focus of that system model. Data and interface are also modeled. Output: Process models called Data Flow Diagrams (DFDs) Information Engineering (IE) Definition: Also model-Driven, but Data-centered. It intends to synchronize the system’s data, and then processes. It is data centered because it focuses on the data requirements of the system. Output: Data model called Entity Relationship Diagram (ERD). The two previous approaches differ only in the order of drawing the DFD, and the ERD. Object-Oriented Analysis (OOA) Definition: It is a model-driven technique that integrates Data and Processes concerns into constructs called Objects. OOA modes are pictures that illustrate the system’s objects. Output: Unified Modeling Language (UML) depicts the OOA models. Difference: No Database. Data and Processes are stored physically on the same layer.

5 Accelerated Analysis Approaches Definition: Accelerated approaches emphasize the construction of prototypes to more rapidly identify the business and user requirements for a new system. Prototype: Small-Scale, incomplete, but working sample of a desired system. Types: Discovery Prototyping: Identifies user’s business requirements by having to react to a quick implementation. Reverse Engineering: Reads the program code for an existing database, program, and automatically generates system model, which is edited, and improved.

6 Project Phases Preliminary Investigation Phase Problem Analysis Phase Requirement Analysis Phase Decision Analysis Phase Design Phase Construction Phase Implementation Phase Operation and Support Phase

7 Preliminary Investigation – Phase 1 The Preliminary Investigation phase First phase of the classic systems development process. Answers the question: “Is the project worth looking at?”. It is intended to be quick & should not exceed 2 or 3days for most projects. Most of the tasks in this phase are led by a senior systems analyst or a project manager and include system owners as participants.

8 Phase 1 - Preliminary Investigation Con’t 1. List problems,opportunities and directives 2. Negotiate preliminary scope 3. Assess project worth 4. Plan the project 5. Present the project and plan Preliminary Investigation Consists of the following 5 steps:

9 Phase 1 - Preliminary Investigation Con’t 1. List problems, opportunities and directives: Each problem, opportunity or directive is assessed with respect to urgency, visibility, benefits and priority. The key deliverable of this task is a preliminary problem statement. Primary techniques include fact-finding & meeting with system owners.

10 Phase 1 - Preliminary Investigation Con’t 2. Negotiate preliminary scope: Scope defines the boundary of the project. A project’s scope can be described in terms of: What types of data describe the system being studied? What business processes are included in the system being studied? How must the system interface with users, locations and other systems? This task deliverable is the preliminary problem statement with scope. Primary techniques to accomplish this task are also fact- finding &meetings.

11 3. Assess project worth This is where we answer the question: “ Will the development of the new system return enough value to offset the costs incurred?” There is no physical deliverable than the go or no-go decision. The remaining tasks are necessary only if the project is approved. Phase 1 - Preliminary Investigation Con’t

12 4. Plan the project: An initial project plan should consist of at least the following: A preliminary master plan that includes schedule and resource assignments for the entire project. A detailed plan and schedule for completing the next phase of the project. The deliverable of this task is the project plan. Phase 1 - Preliminary Investigation Con’t

13 5. Present the project and plan: Unless the project is predetermined to be of the highest priority, it must be presented to a steering body for approval. A steering body is a committee of executive business and system managers that studies and prioritize project proposals to determine which projects should be approved or continued. Deliverable of this task is the project charter, which is usually a document. The project charter defines the project in terms of participants, problems, opportunities and directives; methodology; statement of work to be completed; deliverables; quality standards and budget. If approved, the project can now proceed to the problem analysis phase. Phase 1 - Preliminary Investigation Con’t

14 Phase 2 : Problem Analysis Phase Answers the questions : Goal: “ Don ’ t try to fix it, unless you understand it! ” Final Deliverables : Are the problems really worth solving? Is a new system really worth building? Study and understand the problem domain well enough to thoroughly analyze its problems, opportunities and constraints. Produce System Improvement Objectives that address problems, opportunities and directives

15 The Problem Analysis Phase (6 Steps) Learn about the current system in which the bus problems opportunities, directives and constraints exist. Learn to truly analyze a problem before stating any possible solutions Analyze each perceived problem for cause and effect Appropriate only to business process redesign examine business process to measure value added or subtracted by each process as it relates to the total organization Analyze Problems and Opportunities Study the problem domain Analyze Business Processes (Optional)

16 The Problem Analysis Phase (6 Steps) Establish System Improvement Objectives Establish the criteria against which any improvement to the system will be measured and identifies any constraints that may limit flexibility in achieving these improvements. Update The Project Plan Reevaluating scope and update the project plan accordingly Present findings and recommendations Appropriate elements are combined into system improvement objectives, presented in a report or a verbal presentation Conclusion : Continue, adjust or cancel the project

17 Phase 3:Requirement Analysis Phase This phase defines the Business Requirements for a new system What do the users need and want from a new system? WHAT NOT HOW! The Requirement Analysis Phase includes the following tasks: 1- Define Requirements2- Analyze Functional Requirements 3- Trace and Complete Requirements4- Prioritize Requirements 5- Update the Project Plan Define Requirements: This task translate the system improvements objectives (established in the problem analysis phase) into an outline of Functional and Nonfunctional requirements that will be needed to meet the objectives

18 Analyze Functional Requirements: Functional Requirements are analyzed such that they can be verified and communicated to both: Users so they can prioritize the needs and justify the expenses Designers so they can transform them into appropriate technical solutions. There are 2 approaches to functional requirements documentation and validation SYSTEM MODELING & PROTOTYPING. Requirements are analyzed for accuracy, urgency, consistency, flexibility and feasibility. Trace and Complete Requirements: Tracing each system model and/or prototype back to the functional requirement that it fulfills and ensuring that all functional requirements are included in the system models or prototype. Phase 3:Requirement Analysis Phase

19 Prioritize Requirements: System Owners and Users should prioritize business because it may be useful to recognize which requirements are more important than others if a project gets behind schedule or over budget. Prioritization of business requirements enable TIMEBOXING, which is a technique that delivers system functionality and requirements through versioning. All MANDATORY REQURMENTS are included in Version 1.0 (the System is useless without it) All DESIRABLE REQUIRMENTS are included following version according to there ranking. Update the Project Plan: ScopeScheduleBudget Output of this phase is a business requirements statement. Phase 3:Requirement Analysis Phase

20 Project Phase 4: Decision Analysis Phase DECISION ANALYSIS PHASE Business requirements System Proposal

21 Project Phase 4: Decision Analysis Phase The decision analysis phase includes 5 tasks as follows 1. Identify Candidate Solutions (Sources :System Owners, Users, analysists, Desginers, technical consultants……) 2. Analyze Candidate Solution (Feasibility) Operational Economic Schedule Technical (done by system designers and builders)

22 Project Phase 4: Decision Analysis Phase 3. Compare Candidate Solutions (Feasibility analysis Matrix) Feasibility criteriaWeightCandidate 1 Candidate 2 Candidate3 1.Operational 2.Technical 3.Economic 4.Schedule Ranking100% % % %

23 Project Phase 4: Decision Analysis Phase 4. Update the project plan 5. Recommend a solution

24 Cross Life Cycle Activities Cross life cycle activities are activities that overlap many or all phases of the methodology. Fact Finding Formal process of using research, interviews, meetings, questionnaires, sampling. Also Called data collection. Documentation and Presentations Activity of recording facts and specifications for a system for current and future reference. Communicating Findings, recommendations, and documentation for review by interested managers

25 Cross Life Cycle Activities Feasibility Analysis Continuous Analysis of the development of the IS. Project Management Defining, planning, directing, monitoring, and controlling a project to develop an acceptable system within the specified time, and budget.


Download ppt "Chapter 5 System Analysis Sarah El Sehemawy Karim Elsabee Sherine Meshad Hakim Meshriky Ahmed Zaki Ismail Abou Hamda."

Similar presentations


Ads by Google