Systems Analysis and Design (c) Addison Wesley Chapter 1 Systems Analysis and Design System Development MACIASZEK (2001): Req Analysis & Syst Design

Topics System Development System Development Life Cycle (c) Addison Wesley Topics Chapter 1 System Development System Development Life Cycle Scheduling of Project Phases Systems Analysis and Design Project Team and Management Project Initiation Project Planning Lecture 2 MACIASZEK (2001): Req Analysis & Syst Design

System Development Project is a planned undertaking that has a beginning, an end, and which produces a predetermined result or product usually specified in terms of cost, schedule and performance requirements System development project is a planned undertaking that produces an IS Activities in development of any new system: Analysis – to understand information needs Design – define the system architecture (based on needs) Implementation – the actual construction of the system Lecture 2

System Development Life Cycle (SDLC) The systems development life cycle (SDLC) is a general term used to describe the method and process of developing a new information system Without the structure and organization provided by SDLC approach projects are at risk for missed deadline, low quality etc SDLC provides Structure Methods Controls Checklist Needed for successful development Lecture 2

Development Life Cycle Guide Initiation Development Life Cycle Guide Planning Analysis Design Construction Integration & Test Implementa- tion Steady State Lecture 2

System Development Life Cycle (SDLC) Lecture 2

System Development Life Cycle S D L C 1 Request 2 Problem Definition 3 Feasibility Study 4 Alternatives 5 Optimal Solution 6 Analysis 7 Design 8 Coding 9 Testing 10 Implementation 11 Maintenance analyst Software Engineer Lecture 2

SYSTEMS ANALYSIS AND DESIGN: A Complete (Formal) Perspective (c) Addison Wesley SYSTEMS ANALYSIS AND DESIGN: A Complete (Formal) Perspective Chapter 1 Systems Planning Systems Analysis Systems Design Feasibility study Implementation Systems Evolution Planning Evolution Analysis Implementation Design 6 Lecture 2 MACIASZEK (2001): Req Analysis & Syst Design 6

Phases in the SDLC Sets of related activities are organized into phases: Project planning phase Analysis phase Design phase Implementation phase Support phase In “classical” life cycle these phases are sequential, but there are variations Lecture 2

The Planning Phase Primary objectives are to: identify the scope of the new system, ensure that project is feasible, develop a schedule, allocate resources, and budget for the remainder of the project. The project planning phase includes five activities: Define the problem. Confirm project feasibility. Produce the project schedule. Staff the project. Launch the project. Lecture 2

The Analysis Phase The primary objective is to understand and document the business needs and the processing requirements of the new system The analysis phase includes six activities: Gather information (e.g. interview, read, observe etc.) Define system requirements (reports, diagrams etc.) Build prototypes for discovery of requirements Prioritize requirements Generate and evaluate alternative solutions Review recommendations with management Lecture 2

SYSTEMS ANALYSIS AND DESIGN (c) Addison Wesley Chapter 1 SYSTEMS ANALYSIS AND DESIGN 1 MACIASZEK (2001): Req Analysis & Syst Design 1

(c) Addison Wesley Chapter 1 Systems Analysis and Design is the process people use to create (automated) information systems Systems Analysis & Design Information System 2 Lecture 2 MACIASZEK (2001): Req Analysis & Syst Design 2

Is there an “official” name? (c) Addison Wesley Chapter 1 Is there an “official” name? Systems Analysis and Design! Software Engineering! Information Systems Engineering! Systems Engineering! Information Systems Development! Other names...! Which one? 3 MACIASZEK (2001): Req Analysis & Syst Design 3

Systems Analysis Requirement Objectives Problems Output Input Processes H / W S / W People D Base . D B M S . Documents& Procedure . Lecture 2

External Environment Req's Non –s Function Req's ( Requirement) Non – Functional Req`s Product ( S / W ) Req`s Organization Req's External Environment Req's Portability Efficiency Reliability Usability Delivery Req's Implementation Req's Standards Req's Interoperability Req's Ethical Req's Safety Req's Legislative Req's Space Req's Performance Req's Time Locations Lecture 2

(c) Addison Wesley Chapter 1 Systems Analyst A title given to a person who studies the problems and needs of an organization looking for improvement opportunities. Other names: Software Engineer Systems Engineer Software Developer Programmer/Analyst Nerd or Hacker! (joking!) 4 Lecture 2 MACIASZEK (2001): Req Analysis & Syst Design 4

SYSTEMS ANALYSIS AND DESIGN: A Condensed (Informal) Perspective (c) Addison Wesley Chapter 1 SYSTEMS ANALYSIS AND DESIGN: A Condensed (Informal) Perspective Completed Information System An idea Analysis Design and Implementation Time 5 MACIASZEK (2001): Req Analysis & Syst Design 5

Examples: Business “problems” come in all sizes and shapes! (c) Addison Wesley Chapter 1 Business “problems” come in all sizes and shapes! Name & Address Book CD Collection Course Registration Reservations Student Grades Payroll ATM machine & Banking in General Check-Out Counters at Retail Stores Order Fulfillment - Mail or Web Ordering Manufacturing Securities Portfolio Management Space Shuttle Flight Election Results Video Games (Arcade and Home) Examples: 8 Lecture 2 MACIASZEK (2001): Req Analysis & Syst Design 8

System A SYSTEM is a set of: interrelated components working together (c) Addison Wesley System Chapter 1 A SYSTEM is a set of: interrelated components working together for a common purpose 9 Lecture 2 MACIASZEK (2001): Req Analysis & Syst Design 9

A Generic System Model (with Six Components) (c) Addison Wesley Chapter 1 A Generic System Model (with Six Components) SYSTEM boundary inputs outputs processing controls feedback Examples: Automobile Student Registration System Others... 10 Lecture 2 MACIASZEK (2001): Req Analysis & Syst Design 10

System Model Hierarchy (c) Addison Wesley Chapter 1 System Model Hierarchy Template Example Suprasystem System Subsystem Water Vehicles Cruise Ship Staterooms “bigger” “smaller” 11 Lecture 2 MACIASZEK (2001): Req Analysis & Syst Design 11

An INFORMATION SYSTEM is: a type of fabricated system (c) Addison Wesley Chapter 1 An INFORMATION SYSTEM is: a type of fabricated system used by one or more persons to help them accomplish some task or assignment they have An Information System: supports policies & procedures has three components - data, people, procedures - in addition to the six general system components data people procedures (input, output, processing, control, feedback and boundary) 12 Lecture 2 MACIASZEK (2001): Req Analysis & Syst Design 12

An AUTOMATED INFORMATION SYSTEM IS: a type of fabricated system (c) Addison Wesley An AUTOMATED INFORMATION SYSTEM IS: a type of fabricated system used by one or more persons to help them accomplish some task or assignment they have utilizes hardware and software Chapter 1 data people software procedures hardware 13 Lecture 2 MACIASZEK (2001): Req Analysis & Syst Design 13

DATA - input, output, or already stored electronically (c) Addison Wesley An AUTOMATED INFORMATION SYSTEM has three basic characteristics to consider: Chapter 1 DATA FUNCTIONS BEHAVIOR DATA - input, output, or already stored electronically FUNCTIONS - transformations or actions taken BEHAVIOR - the observable effects from interaction (Plus the six system components: input, output, processing, control, feedback and boundary) 14 Lecture 2 MACIASZEK (2001): Req Analysis & Syst Design 14

(c) Addison Wesley Chapter 1 Systems Analysis and Design is the process people use to create (automated) information systems data people SA&D software procedures hardware 15 Lecture 2 MACIASZEK (2001): Req Analysis & Syst Design 15

used internally within the organization (c) Addison Wesley Chapter 1 The people who do SYSTEMS ANALYSIS and DESIGN produce information systems that are: used internally within the organization sold commercially via mail/web order or retail store imbedded in products 16 Lecture 2 MACIASZEK (2001): Req Analysis & Syst Design 16

What makes Systems Analysis and Design a difficult activity? (c) Addison Wesley What makes Systems Analysis and Design a difficult activity? Chapter 1 Initially, problem domains (areas) tend to have poorly defined BOUNDARIES Problem domain SOLUTIONS are artificial Problem domains are DYNAMIC Problem domain solutions usually require INTERDISCIPLINARY knowledge and skills Systems Analyst’s KNOWLEDGEBASE is continually expanding Systems Analysis and Design is a highly COGNITIVE activity Working with PEOPLE 17 Lecture 2 MACIASZEK (2001): Req Analysis & Syst Design 17

Systems Analyst’s interactions with people during (c) Addison Wesley Systems Analyst’s interactions with people during Systems Analysis & Design Chapter 1 Steering Committee* Users* SYSTEMS ANALYST Managers* Vendors Database Administrators Programmers & Tech. Staff Systems Analyst may be acting as a Project Manager for some of these interactions. * = Stakeholders 18 Lecture 2 MACIASZEK (2001): Req Analysis & Syst Design 18

What does a Systems Analyst do? (c) Addison Wesley Chapter 1 What does a Systems Analyst do? Studies the problems and needs of an organization looking for improvement opportunities for: increasing revenue/profit decreasing costs improving quality of service 19 Lecture 2 MACIASZEK (2001): Req Analysis & Syst Design 19

What is a Systems Analyst responsible for? (c) Addison Wesley Chapter 1 What is a Systems Analyst responsible for? Effective and efficient: CAPTURE of input data PROCESSING & STORAGE of data DELIVERY of timely and accurate information 20 Lecture 2 MACIASZEK (2001): Req Analysis & Syst Design 20

Skills and Competencies (c) Addison Wesley Chapter 1 Skills and Competencies of a Systems Analyst Concepts & Principles Environments/Tools Problem Solving & People Skills Methods & Techniques Methodologies PLUS: Functional Business Knowledge Verbal & written communication skills Systems Analysis and Design work experience 21 Lecture 2 MACIASZEK (2001): Req Analysis & Syst Design 21

Requirements Specification (c) Addison Wesley Chapter 1 General Model of Information Systems Development (“Partnership”) Stakeholder Requirements (1) Information System (6) Continued Involvement (5) Design and Implementation Requirements Specification (3) Analysis Problem Definition Skills (2) Problem Solution Skills (4) Information Technology Staff 22 Lecture 2 MACIASZEK (2001): Req Analysis & Syst Design 22

Systems Analysis and Design Activities and Deliverables (c) Addison Wesley Chapter 1 Systems Analysis and Design Activities and Deliverables DESIGN ANALYSIS Activities: Activities: Physical Design Prototyping (optional) Software Construction/Purchase User Documentation - “Deliverable” Testing Training User Acceptance Conversion Implementing the system Systems Planning Feasibility Study (optional) Requirements Determination User Acceptance Prototyping (optional) Deliverables: Requirements Specification Prototype (optional) Deliverable: Information System Project Management Project Documentation - “Scaffolding” Two (2) additional on-going activities: 23 Lecture 2 MACIASZEK (2001): Req Analysis & Syst Design 23

Systems Analysis and Design Project Observations (c) Addison Wesley Systems Analysis and Design Project Observations Chapter 1 Labor intensive Smallest team = you Next smallest team = you and one other (user) Average team = several systems analysts and users Articulation of the business problem is difficult Users and systems analysts come in all sizes and shapes 24 Lecture 2 MACIASZEK (2001): Req Analysis & Syst Design 24

Where Do Systems Analysis and Design Projects Come From? (c) Addison Wesley Chapter 1 Where Do Systems Analysis and Design Projects Come From? Problems - “something needs to be fixed” Opportunities - “good deals” Directives - “do it…or else…” ... and are bounded by Constraints 25 Lecture 2 MACIASZEK (2001): Req Analysis & Syst Design 25

SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC) (c) Addison Wesley Chapter 1 SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC) Planning Feasibility Study (optional) Requirements Determination Conceptual Design Physical Design Construction and/or Purchase (prototype) Conversion - old to new Training Implementation Evolution - maintenance & enhancements Analysis Design 26 Lecture 2 MACIASZEK (2001): Req Analysis & Syst Design 26

Sequential or Traditional SDLC (c) Addison Wesley Chapter 1 Sequential or Traditional SDLC “Begin” “End” 1. Planning for an information system 2. Feasibility Study (optional) 3. Requirements Determination (gathering) 4. Conceptual design 5. Physical design and/or purchase and/or prototyping 6. Conversion from current system to new/changed system 7. Training 8. Implementation 9. Evolution for enhancements and maintenance Waterfall or Staircase SDLC “Begin” “End” Planning Feasibility Study Requirements Determination Conceptual Design Physical Design Conversion Training Implementation Evolution 27 Lecture 2 MACIASZEK (2001): Req Analysis & Syst Design 27

Spiral SDLC Iterative SDLC SDLC Activities Risk Analysis (c) Addison Wesley Chapter 1 Iterative SDLC Spiral SDLC SDLC Activities Planning Feasibility Study Requirements Determination Conceptual Design Physical Design Conversion Training Implementation Evolution Risk Analysis Verification/Test 28 Lecture 2 MACIASZEK (2001): Req Analysis & Syst Design 28

Principles to Guide Systems Analysis & Design (c) Addison Wesley Chapter 1 Principles to Guide Systems Analysis & Design The system is for the user A Work Breakdown Structure should be used (ie., SDLC) Systems analysis and design is iterative and overlapping Information systems are capital investments for the business Project manager may have the authority to cancel a project Project documentation is important all along the way Senior management approval/support is very important 30 Lecture 2 MACIASZEK (2001): Req Analysis & Syst Design 30

The Design Phase The primary objective is to convert the description of the recommended alternative solution into system specification High-level (architectural) design consists of developing an architectural structure for software programs, databases, the user interface, and the operating environment Low-level (detailed) design entails developing the detailed algorithms and data structures that are required for program development Lecture 2

The Design Phase (cont.) The design phase includes seven activities: Design and integrate the network Design the application network Design the user interfaces Design the system interfaces Design and integrate the database Prototype for design details Design and integrate the system controls Lecture 2

The Implementation Phase Primary objectives are to ensure that: System is built, tested and installed (actual programming of the system) The users are all trained The business is benefiting The implementation phase includes six activities: Construct software components Verify and test Develop prototypes for tuning Convert data Train and document Install the system Lecture 2

The Support Phase Primary objective is to to keep the system running after its installation The support phase includes two activities: Provide support to end users Help desks Training programs Maintain and enhance the computer system Simple program error correction Comprehensive enhancements Upgrades Lecture 2

Scheduling of Project Phases Traditional approach ( “Waterfall method”) – only when one phase is finished does the project team drop down (fall) to the next phase Fairly rigid approach Can’t easily go back to previous phases (each phase would get “signed off”) Good for traditional type of projects, e.g. payroll system or system with clearly definable requirements Not as good for many of the new types of interactive and highly complex applications Lecture 2

Scheduling of Project Phases (cont.) Newer Approaches: The waterfall approach is less used now The phases are still planning, analysis, design and implementation However, many activities are done now in an overlapping or concurrent manner Done for efficiency – when activities are not dependent on the outcome of others they can also be carried out (but dependency limits overlap) Iteration: the process of looping through the same development activities multiple times, sometimes at increasing levels of detail or accuracy Example: Iterative design and development of user interfaces – can cycle iteratively through the following Design interface Test with users early on (video-based usability testing) Redesign, based on results of testing with users Lecture 2

Scheduling of Project Phases (cont.) FIGURE 2-1 Overlap of systems development activities Lecture 2

The “Classic” Waterfall Life Cycle Analysis Design Implementation Support Lecture 2

The Project Team Like a “surgical team” – each member of the team performs a specialized task critical to the whole Project team varies over duration of the project (as does project leadership) During planning team consists of only a few members (e.g. project manager and a couple of analysts) During analysis phase the team adds systems analysts, business analysts During design other experts may come in with technical expertise (e.g. database or network design) During implementation, programmers and quality control people are added Lecture 2

The Project Team (cont.) FIGURE 2-4 Staffing levels of a typical project Lecture 2

Project Management Project Management – organizing and directing of other people to achieve a planned result within a predetermined schedule and budget Project Manager – has primary responsibility for the functioning of the team Good manager knows: how to plan execute the plan anticipate problems adjust for variances Lecture 2

Project Management (cont.) A project manager reports to and works with several groups of people: Client – person or group who funds the project Oversight committee – clients and managers who review and direct the project User – the person or group who will use the system Lecture 2

Tasks of a Project Manager Planning and Organization Identify scope of the project Develop a plan, with detailed task list and schedule Directing Responsible for directing the execution of the project Responsible for monitoring the project - make sure that milestones (key events in a project) are met Overall control of the project Plan and organize project Define milestones and deliverables Monitor progress Allocate resources and determine roles Define methodologies Anticipate problems and manage staff Lecture 2

Project Initiation Projects may be initiated as part of the long-term strategic plan (top-down) based on mission or objective statement come up with some competitive business strategy- usually involves IT e.g. to be more competitive store wants to improve customer support – so moves towards Internet based re-development of systems Projects may proceed bottom up To fill some immediate need that comes up Projects may also be initiated due to some outside force E.g. change in tax structure may affect billing system Lecture 2

The Project Planning Phase FIGURE 2-5 Activities of the project planning phase. Lecture 2

The Project Planning Phase (cont.) Defining the Problem Review the business needs and benefits (a brief paragraph describing the business problems) Identify the expected capabilities of the new system (define the scope of the project) May involve developing a context diagram to explain the scope of the project Confirming Project Feasibility Economic feasibility – cost-benefit analysis Organizational and cultural feasibility E.g. low level of computer literacy, fear of employment loss Technological feasibility Proposed technological requirements and available expertise Schedule feasibility How well can do in fixed time or deadline (e.g. Y2K projects) Resource feasibility Availability of team, computer resources, support staff Lecture 2

The Project Planning Phase (cont.) Economic Feasibility The analysis to compare costs and benefits to see whether the investment in the development of the system will be more beneficial than costly Costs Development costs : salaries and wages, equipment and installation, software and licenses, consulting fees and payments to third parties, training, facilities, utilities and tools, support staff, travel and miscellaneous Sources of Ongoing Costs of Operations: connectivity, equipment maintenance, computer operations, programming support, amortization of equipment, training and ongoing assistance (help desk), supplies Lecture 2

The Project Planning Phase (cont.) Benefits Tangible benefits – examples Reducing staff (due to automation) Maintaining constant staff Decreasing operating expenses Reducing error rates (due to automation) Ensuring quicker processing and turnabout Capturing lost discounts Reducing bad accounts or bad credit losses Reducing inventory or merchandise loss Collecting accounts receivable more quickly Capturing income lost due to “stock outs” Reducing the cost of goods with volume discounts Reducing paperwork costs Lecture 2

The Project Planning Phase (cont.) Benefits Intangible benefits – examples Increased level of service (in ways that can’t be measured) Increased customer satisfaction Survival The need to develop in-house expertise Note - also can have intangible costs for a project reduced employee moral lost productivity lost customer or sales Lecture 2