CHAPTER ONE
The systems development life cycle is a phased approach to solving business problem
The Seven Phases Of This Cycle Includes: —I.D.A.D.D.T.I—
Identifying Problems :This involves activities one takes to find faults with the system and once that is done they are able to make decisions.
Determining Human Information Requirements : This step involves the gathering of information on how users interact with the system to make a more user friendly system for the users.
Analyzing System Needs : The making of flowcharts and diagrams in order to make some recommendations to system
Designing the Recommended System : This involves the design entry and designing of the system interface to create the model of the system.
Developing and Documenting Software : The system analyst works with both programmers and users to develop the software and make some documentations with help and FAQs
Testing and Maintaining the System : This involves testing the system and find=ding out if there are any errors or doing maintenace.
Implementing and Evaluating the System : The system analyst trains individuals and for the system and ensures a smooth installation of the software as he switches from old to new
FUN FACT : ABOUT 60% OF TIME IS SPENT ON SYSTEM MAINTENANCE AND THE REMAINING 40 OF CREATING A NEW ONE.
CASE tools are productivity tools for systems analysts that have been created explicitly to improve their routine work through the use of automated support
Approaches to Structured Analysis and Design and to the Systems Development Life Cycle
The Agile Approach : It is based on Values • Principles • Core practices. Agile Values deal with communications, simplicity,Feedback and Courage. Which has some resources like
• Time • Cost • Quality • Scope. There are Five Stages of Agile Development
• Exploration • Planning • Iterations to the first release • Productionizing • Maintenance
—-EPIM—
Object-Oriented (O-O) Systems Analysis and Design
The cycle repeats with analysis, design, and implementation of the next part and this repeats until the project is complete. • Examines the objects of a system.
Unified Modeling Language (UML) Phases
• Define the use case model: • Use case diagram • Use case scenarios • Create UML diagrams • Develop class diagrams • Draw statechart diagrams • Modify the UML diagrams • Develop and document the system.
CHAPTER TWO
Interrelatedness and Interdependence of Systems
• All systems and subsystems are interrelated and interdependent
• All systems process inputs from their environments
• All systems are contained by boundaries separating them from their environments
• System feedback for planning and control
Organizational Environments
• Community • Physical location • Demographic profile (education, income)
• Economic • Market factors • Competition • Political
• State and local government • Legal • Federal, state, regional, local laws, and guidelines
Openness and Closedness Of Systems
Open • Free flow of information • Output from one system becomes input to another
Closed • Restricted access to information • Limited by numerous rules • Information only on a “need to know” basis
Depicting Systems Graphically
• Context-level data flow diagrams
• Focus is on the data flowing into and out of the system and the processing of the data
• Shows the scope of the system:
• What is to be included in the system
• The external entities are outside the scope of the system
The Basic Symbols of a Data Flow Diagram
Process is an action or a group of actions takes place
An entity is a person or anything that gives or receives information
Data-flow shows an information is being passed from or to a process
Entity-Relationship Model
• Focus is on the entities and their relationships within the organizational system
• Another way to show the scope of a system
• Relationships show how the entities are connected
• Three types of relationships: • One-to-one • One-to-many • Many-to-many
Entities
• Fundamental entity : Usually a person, place or a thing
• Associative entity : Used to join two entities
• Attributive entity : Used in describing attributes.
Use Case Modeling
• Describes what a system does without describing how the system does
• A logical model of the system
• Use case is a view of the system requirements
• Analyst works with business experts to develop requirements
Use Case Diagram
• Actor : Refers to a particular role of a user of the system
• Similar to external entities; they exist outside of the system
• Use case symbols : An oval indicating the task of the use case
• Connecting lines : Arrows and lines used to diagram behavioral relationships
A Use Case Always Provides Three Things
• An actor that initiates an event
• The event that triggers a use case
• The use case that performs the actions triggered by the event
Four Steps Used to Create Use Cases
• Use agile stories, problem definition objectives, user requirements, or a features list
• Ask about the tasks that must be done
• Determine if there are any iteration or looping actions
• The use case ends when the customer goal is complete
Management in Organizations
Exists on Three Horizontal Levels:
Operational Control:
• Make decisions using predetermined rules that have predictable outcomes
• Oversee the operating details of the organization
Managerial Planning and Control:
• Make short-term planning and control decisions about resources and organizational objectives • Decisions may be partly operational and partly strategic
Strategic Management:
• Look outward from the organization to the future
• Make decisions that will guide middle and operations managers
• Work in highly uncertain decision making environment
• Define the organization as a whole
CHAPTER 3
Project Management Fundamentals
Project Initiation
• Problems in the organization
• Problems that lend themselves to systems solutions
• Opportunities for improvement
• Caused through upgrading, altering, or installing new systems
Problem Definition
• Problem statement
• Paragraph or two stating the problem or opportunity
• Issues
• Independent pieces pertaining to the problem or opportunity
• Objectives
• Goals that match the issues point-by-point • Requirements
• The things that must be accomplished along with the possible solutions, and constraints, that limit the development of the system
• Use the problem definition to create a preliminary test plan
Selection Of Projects
• Backing from management
• Appropriate timing of project commitment
• Possibility of improving attainment of organizational goals
• Practical in terms of resources for the system analyst and organization
• Worthwhile project compared with other ways the organization could invest resource
Defining Objectives
Many possible objectives exist including:
• Speeding up a process
• Streamlining a process
• Combining processes
• Reducing errors in input
• Reducing redundant storage
• Reducing redundant output
• Improving system and subsystem integration
Determining Feasibility
• Defining objectives
• Determining resources : Operationally • Technically • Economically
The Three Key Elements of Feasibility Include Technical, Economic, and Operational Feasibility
Three Main Categories of Cloud Computing
• Software as a Service (SaaS) third party hosts application
• Infrastructure as a Service (IaaS) virtualized computing resources over the internet (data center)
• Platform as a Service (PaaS) delivers hardware and software tools – usually those needed for application development
Comparing Costs and Benefits
Break-Even Analysis
• The point at which the total cost of the current system and the proposed system intersect
• Useful when a business is growing and volume is a key variable in costs
• Advantage:
• Can determine how long it will take for the benefits of the system to pay back the costs of developing it
Cash-Flow Analysis
• Examines the direction, size, and pattern of cash flow that is associated with the proposed information system
• Determines when cash outlays and revenues will occur for both; not only for the initial purchase, but over the life of the information system
CHAPTER 4
Interactive Methods to Elicit Human Information Requirements
Interviewing
• Interviewing is an important method for collecting data on human and system information requirements
• Interviews reveal information about:
• Interviewee opinions
• Interviewee feelings
• Goals
• Key HCI concerns
Bipolar Questions
• Bipolar questions are those that may be answered with a “yes” or “no” or “agree” or “disagree”
• Bipolar questions should be used sparingly • A special kind of closed question
Probes
• Probing questions elicit more detail about previous questions
• The purpose of probing questions is:
• To get more meaning
• To clarify
• To draw out and expand on the interviewee’s point
• May be either open-ended or close
Arranging Questions
• Pyramid
• Starting with closed questions and working toward open-ended questions
• Funnel
• Starting with open-ended questions and working toward closed questions
• Diamond
• Starting with closed, moving toward open-ended, and ending with closed questions
Joint Application Design (JAD)
• Joint Application Design (JAD) can replace a series of interviews with the user community
• JAD is a technique that allows the analyst to accomplish requirements analysis and design the user interface with the users in a group setting
Questionnaires
Questionnaires are useful in gathering information from key organization members about:
• Attitudes • Beliefs • Behaviors • Characteristics
Measurement Scales
• The two different forms of measurement scales are:
• Nominal • Interval
Nominal Scales
• Nominal scales are used to classify things
• It is the weakest form of measurement
• Data may be totaled
Interval Scales
• An interval scale is used when the intervals are equal
• There is no absolute zero
• Examples of interval scales include the Fahrenheit or Centigrade scale
Central Tendency
Central tendency occurs when respondents rate everything as average
• Improve by making the differences smaller at the two ends
• Adjust the strength of the descriptors
• Create a scale with more points
CHAPTER 5
Information Gathering: Unobtrusive Methods
Sampling
• A process of systematically selecting representative elements of a population
• Involves two key decisions:
• What to examine • Which people to consider
Sampling Design
• To design a good sample, a systems analyst must follow four steps:
• Determining the data to be collected or described
• Determining the population to be sampled
• Choosing the type of sample
• Deciding on the sample size
Four Main Types of Samples
Convenience Samples
• Convenience samples are unrestricted, nonprobability samples.
• This sample is the easiest to arrange
• The most unreliable
Purposive Sample
• A purposive sample is based on judgment
• Choose a group of individuals who appear knowledgeable and are interested in the new information system
• A nonprobability sample
• Only moderately reliable
Complex Random Samples
• The complex random samples that are most appropriate for a systems analyst are
• Systematic sampling
• Stratified sampling
• Cluster sampling
Calculate the Standard Error of the Proportion
sp = i/z
i = interval estimate z = confidence coefficient found in the confidence level lookup table
Determine the Sample Size
n= (p(1-p)/σp^2)+1
σp = standard error ρ = the proportion of the population having the attribute
Investigation
• The act of discovery and analysis of data
• Hard data
• Quantitative
• Qualitative
Analyzing Quantitative Documents
• Reports used for decision making
• Performance reports
• Records
• Data capture forms
• Ecommerce and other transactions
Records
• Records provide periodic updates of what is occurring in the business
• There are several ways to inspect a record:
• Checking for errors in amounts and totals
• Looking for opportunities for improving the recording form design
• Observing the number and type of transactions
• Watching for instances in which the computer can simplify the work (calculations and other data manipulation)
Observation
• Observation provides insight on what organizational members actually do
• See firsthand the relationships that exist between decision makers and other organizational members
• Can also reveal important clues regarding HCI concerns
Analyst’s Playscript
• Involves observing the decision-makers behavior and recording their actions using a series of action verbs
• Examples:
• Talking • Sampling • Corresponding • Deciding
STROBE
STRuctured OBservation of the Environment—a technique for observing the decision-maker’s physical environment
Applying STROBE
• The five symbols used to evaluate how observation of the elements of STROBE compared with interview results are:
• A checkmark means the narrative is confirmed
• An “X” means the narrative is reversed
• An oval or eye-shaped symbol serves as a cue to look further
• A square means observation modifies the narrative
• A circle means narrative is supplemented by observation
CHAPTER 6
Agile Modeling and Prototyping
Agile Modeling, but First Prototyping
• Agile modeling is a collection of innovative, user-centered approaches to system development • Prototyping is an information-gathering technique useful in seeking
• User reactions
• Suggestions
• Innovations
• Revision plans
Patched-Up Prototype
• A system that works but is patched up or patched together
• A working model that has all the features but is inefficient
• Users can interact with the system
• Retrieval and storage of information may be inefficient
Nonoperational Scale Models
• A nonworking scale mode that is set up to test certain aspects of the design
• A nonworking scale model of an information system might be produced when the coding required by the application is too expensive to prototype but when a useful idea of the system can be gained through prototyping of the input and output only.
First-of-a-Series Prototype
• Creating a pilot
• Prototype is completely operational
• Useful when many installations of the same information system are planned
• A full-scale prototype is installed in one or two locations first, and if successful, duplicates are installed at all locations based on customer usage patterns and other key factors
Selected Features Prototype
• Building an operational model that includes some, but not all, of the features that the final system will have
• Some, but not all, essential features are included
• Built in modules
• Part of the actual system
CHAPTER 7
Using Data Flow Diagrams
Basic Symbols
• A double square for an external entity
• An arrow for movement of data from one point to another
• A rectangle with rounded corners for the occurrence of a transforming process
• An open-ended rectangle for a data store
Data Store
• A depository for data that allows examination, addition, and retrieval of data
• Named with a noun, describing the data
• Data stores are usually given a unique reference number, such as D1, D2, D3
• Represents a: • Database • Computerized file • Filing cabinet
Basic Rules
• The data flow diagram must have one process
• Must not be any free standing objects
• A process must have both an input and output data flow
• A data store must be connected to at least one process • External entities should not be connected to one another
• Processes that do not create a child diagram are called primitive
Creating Child Diagrams
• Each process on diagram 0 may be exploded to create a child diagram
• A child diagram cannot produce output or receive input that the parent process does not also produce or receive
• The child process is given the same number as the parent process
• Process 3 would explode to Diagram 3
Entities are usually not shown on the child diagrams below Diagram 0
• If the parent process has data flow connecting to a data store, the child diagram may include the data store as well
• When a process is not exploded, it is called a primitive process
CRUD Matrix
• The acronym CRUD is often used for
• Create
• Read
• Update
• Delete
• These are the activities that must be present in a system for each master file • A CRUD matrix is a tool to represent where each of these processes occurs in a system
Partitioning Data Flow Diagrams
• Partitioning is the process of examining a data flow diagram and determining how it should be divided into collections of manual procedures and computer programs
• A dashed line is drawn around a process or group of processes that should be placed in a single computer program
Reasons for Partitioning
• Different user groups
• Timing
• Similar tasks
• Efficiency
• Consistency of data
• Security
CHAPTER 8
Analyzing Systems Using Data Dictionaries
Cataloging
• Data flow diagrams can be used to catalog:
• Data processes
• Flows
• Stores
• Structures
• Elements
• Cataloging takes place with the data dictionary
The Data Dictionary
• A reference work of data about data (metadata)
• Collects and coordinates data terms, and confirms what each term means to different people in the organization
The Data Repository
• A data repository is a large collection of project information
• It includes:
• Information about the data maintained by the system
• Procedural logic and use cases
• Screen and report design
• Data relationships
• Project requirements and final system deliverables
• Project management information
Algebraic Notation
• Equal sign means “is composed of”
• Plus sign means “and”
• Braces {} mean repetitive elements
• Brackets [] for an either/or situation
• Parentheses () for an optional element
Logical and Physical Data Structures
• Logical:
• Show what data the business needs for its day-to-day operations
• Physical:
• Include additional elements necessary for implementing the system
The Name of the Element
• Should be: • Descriptive • Unique
• Based on what the element is commonly called in most programs or by the major user of the element
Element Is Base or Derived
• A base element is one that has been initially keyed into the system
• A derived element is one that is created by a process, usually as the result of a calculation or a series of decision making statements
Element Length
What should the element length be?
• Some elements have standard lengths, state abbreviations, zip codes, or telephone numbers. • For other elements, the length may vary and the analyst and user community must decide the final length.
Data Truncation
• If the element is too small, the data will be truncated
• The analyst must decide how this will affect the system outputs
• If a last name is truncated, mail would usually still be delivered
• A truncated email address or web address is not usable
