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


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 ValuesPrinciplesCore 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 


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.


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 


• 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 


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


Interactive Methods to Elicit Human Information Requirements


• 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 


• 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 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 


Information Gathering: Unobtrusive Methods 


• 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 


• 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 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 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 


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 


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 


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


Analyzing Systems Using Data Dictionaries 


• 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 

Leave a Reply

Your email address will not be published. Required fields are marked *