Computer Systems Engineering/CSE205 Unit I

ORGANIZATIONS AS SYSTEMS
• Organizations are complex systems composed of interrelated and interdependent subsystems
(departments, units, divisions, etc.) serving specialized functions.
• System and subsystem boundaries and environments impact on information system analysis
and design.
• The subsystems are influenced by three broad levels of management decision makers:
Operations, Middle management and Strategic management.
• Typical functions include accounting, marketing, production, data processing, and
management.
• The significance of conceptualizing organizations as complex systems is that systems
principles allow insight into how organizations work.
Interrelatedness and Interdependence of Systems
• All systems and subsystems are interrelated and interdependent. When any element of a
system is changed or eliminated, the rest of the system’s elements and subsystems are also
significantly affected. Example: Replacing a personal secretary’s functions with networked
PCs.
• Another aspect of organizations as systems is that all systems are contained by boundaries
separating them from their environments. The organizations must be able to first input
(people, raw materials and information) and then to output (finished products, services or
information with the outside world).

V.Thiruppathy Kesavan, AP/CSE Kalasalingam University 1

Computer Systems Engineering/CSE205 Unit I

• Feedback is one form of system control. As systems, all organizations use planning and

Goals

System

control to manage their resources effectively. Example: A manufacturing company that

produces various colored products that are most liked by the customers.
• Systems are described as either open, with free-flowing information, or closed with restricted
access to information.
• Openness refers to the free flow of information within the organization. Example: An art
department is characterized as open. A defense department maintains the planning as top-
secret.

Virtual Organizations and Virtual Teams

• A virtual organization is one that has parts of the organization in different physical locations.
They use computer networks and communications technology to work on projects.
Advantages of a virtual organization are:
o Reduced costs of physical facilities.
o More rapid response to customer needs.
o Flexibility for employees to care for children or aging parents
• Some applications permit analysts who are providing technical assistance over the Web to
“see” the software and hardware configuration of the user requesting help, in this way
creating an ad hoc virtual team composed of the analyst and user.

V.Thiruppathy Kesavan, AP/CSE Kalasalingam University 2

Computer Systems Engineering/CSE205 Unit I

Taking a Systems perspective

• Taking a systems perspective is important that members of subsystems realize that their work
is interrelated.
o Example: The outputs from the production subsystems serve as inputs for marketing
and the outputs of marketing serve as new inputs for production. Neither subsystem
can properly accomplish its goal without the other.

Marketing

Production

Enterprise Resource planning: Viewing the Organization as a System

• Enterprise Resource Planning (ERP) describes an integrated organizational information
system. The software helps the flow of information between the functional areas within the
organization.
• ERP evolved from materials requirements planning (MRP) , then manufacturing, assembling,
sales and operations planning, distribution, procurement, and managing the supply chain.
• It therefore significantly affects all areas in the organization, including accounting, finance,
management, marketing, and information systems.
• Implementing an ERP solution may be frustrating because it is difficult to analyze a system
currently in use and then fit the ERP model to that system. It needs extended implementation
time, higher costs and often the loss of user confidence.
DEPICTING SYSTEMS GRAPHICALLY
A System or subsystem that exists in an organization may be graphically depicted in several ways
as: Data flow diagram and Entity-relationship model.
Systems and the context-level data flow diagram
• A context level data flow diagram (also called environmental model) is an important tool for
showing data used and information produced by a system.
• It provides an overview of the setting or environment the system exists within; which entities
supply and receive data/information.
• It employs three symbols:

V.Thiruppathy Kesavan, AP/CSE Kalasalingam University 3

Computer Systems Engineering/CSE205 Unit I

(1) a rectangle with rounded corners called process which means that some action or group
of actions take place
(2) a square with shaded edges called entity which is a person, group, department or any
system that either receives or originates information or data and
(3) an arrow that shows the data flow of the information is being passed from or to a process.

A process

An entity

A data flow

V.Thiruppathy Kesavan, AP/CSE Kalasalingam University 4

Computer Systems Engineering/CSE205 Unit I

Preferences and
Available Flights
Travel
Passenger Agent

0
Travel Request Ticketing information
Airline
Reservation
System

Passenger
Reservation

Airline

V.Thiruppathy Kesavan, AP/CSE Kalasalingam University 5

Computer Systems Engineering/CSE205 Unit I

USE CASE MODELING

A Use Case Model describes what a system does without describing how the system does it; that
is, it is a logical model of the system. It reflects the view of the system form the perspective of a
user outside of the system (i.e., the system requirements).
An analyst develops use cases in a cooperative effort with the business experts who help define
the requirements of the system.
What is a Use Case?
– describes how the system should respond under various conditions to a request from
one of the stakeholders (who have an interest in the delivery of the goal of a use case)
to deliver a specific goal.
– Represents a discrete unit of interaction between a user (human or machine) and the
system. This interaction is a single unit of meaningful work, such as Create Account
or View Account Details.
Actors
- is a person who will use the system. For example, may be an employee, but also may be a
customer at the company store. Usually an actor initiates some operation, although sometimes the
actor may act in other ways, such as receiving information or assisting in an operation. An actor
may interact with one or more use cases, and a use case may involve one or more actors.
- Divided into two groups
• Primary actors
• Supply data or receive information from the system
• Provide details on what the use case should do
• Supporting actors
• Help to keep the system running or provide help
• The people who run the help desk, the analysts, programmers, and so on
Sometimes a table is created with actor profiles that list the actors, their background, and their
skills. These profiles can be useful to understand how the actor interacts with the system.
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
A use case documents a single transaction or event. An event is an input to the system that
happens at a specific time and place and causes the system to do something.
Use Case symbols

- Actor

- Use Case

V.Thiruppathy Kesavan, AP/CSE Kalasalingam University 6

Computer Systems Engineering/CSE205 Unit I

Relationships
Relationship Symbol Meaning
Communicates An actor is connected to a use case using a line
with no arrowheads. The task of the use case is to
give some sort of result that is beneficial to the
actor in the system.
Includes <<include>> A use case contains a behavior that is common to
more that one other use case. When a use case is
depicted as using the functionality of another use
case in a diagram.
Extends <<extend>> A different use case handles exceptions from the
basic use case. The arrow points from the
extended to the basic use case. It describes the
situation in which one use case possesses the
behavior that allows the new use case to handle a
variation or exception from the basic use case.
Generalizes One UML “thing” is more general than another
“thing”. The arrow points to the general “thing”.
It is also a parent-child relationship between use
cases.

Enroll in
Course
Enroll in
Course
Pay Student
Fees
Student
Arrange
Housing

Communications
Includes Relationship
Relationship

Pay Student Pay Student

Fees Student states Fees
amount of coverage
Part-time Student
Student
Generalizes
Relationship Extends Relationship

Fig: Examples of use cases and behavioral relationships for student enrollment.

V.Thiruppathy Kesavan, AP/CSE Kalasalingam University 7

Computer Systems Engineering/CSE205 Unit I

Developing Use Case Diagrams

• The primary use case consists of a standard flow of events in the system that describes a
standard system behavior.
• First the users should list everything the system should do for them.
• Then list down who is involved with each use case and the responsibilities or services the use
case must provide to actors or other systems.
• Use the following guidelines:
1. Review the business specifications and identify the actors involved.
2. Identify the high-level events and develop the primary use cases that describe those
events and how the actors initiate them.
3. Review each primary use case to determine the possible variants of the flow through the
use case and if necessary establish the alternative paths.
• The context-level data flow diagram can be a starting point for creating a use case. From this
the external entities are the potential actors.
• The following diagram representing a system used to plan a conference.

V.Thiruppathy Kesavan, AP/CSE Kalasalingam University 8

Computer Systems Engineering/CSE205 Unit I

Developing the Use Case Scenarios

• Each use case has a description referred to as the use case scenario.
• A use case scenario has three main areas which are:
1. Use case identifiers and initiators
2. Steps performed
3. Conditions, assumptions, and questions
(First area)
Use case identifiers and initiators – orients the reader and contains:
1. The use case name and a unique ID
2. The application area or system that this use case belongs to
3. The actors involved in the use case
4. A brief description of what the use case accomplishes
5. The triggering event
6. Type of trigger - external or temporal
external – those started by an actor
temporal – triggered or started by time
7. May list stakeholders
(Second area)
Includes the steps performed, and the information required for each of the steps.
(Third area)
• Preconditions
• Post conditions
• Assumptions
• Outstanding issues
• optional statement of priority
• optional statement of risk

V.Thiruppathy Kesavan, AP/CSE Kalasalingam University 9

Computer Systems Engineering/CSE205 Unit I

Why Use Case Diagrams Are Helpful?

• Identify all the actors in the problem domain – the systems analyst can concentrate on what
humans want and need to use the system, extent their capabilities, and enjoy their interaction
with technology.
• Actions that need to be completed are also clearly shown on the use case diagram – this
makes it easy for the analyst to identify processes and aids in communication with other
analysts on the team and business executives
• The use case scenario is also worthwhile – since a lot of the information the users impart to
the analysts are in story form, it is easy to capture on the use case scenario form.
• Simplicity and lack of technical detail – used to show the scope of a system, along with the
major features of the system and the actors that work with those major features.
The main reasons for writing use cases are their effectiveness in communicating with users and
their capturing of user stories

V.Thiruppathy Kesavan, AP/CSE Kalasalingam University 10

Computer Systems Engineering/CSE205 Unit I

LEVELS OF MANAGEMENT
Management in organizations exists on three broad, horizontal levels. Each level carries its own
responsibilities, and all work toward achieving organizational goals and objectives in their own
ways.

Operations Control - Forms the bottom tier of the three-tiered model.

• Make decisions using predetermined rules that have predictable outcomes
• Oversee the operating details of the organization
Example: Inventory Control, Shipping
Managerial Planning and Control - Forms the second or intermediate tier of the three-tiered
model.
• Make short-term planning and control decisions about resources and organizational
objectives
• Decisions may be partly operational and partly strategic
Example: Forecasting future resource requirements to solve employee problems.
Strategic Management - Third level of the three-tiered model.
• 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
Example: Introducing new products, acquire other compatible companies, etc.
Managerial Levels
• Different organization structure
• Leadership style
• Technological considerations
• Organization culture

V.Thiruppathy Kesavan, AP/CSE Kalasalingam University 11

Computer Systems Engineering/CSE205 Unit I

• Human interaction
Implications for the analysis and design of information systems
Operations managers:
• need internal information that is of a repetitive, low-level nature.
• highly dependent on information that captures current performance
• large users of online, real-time information resources
• need for past performance information and periodic information is moderate
• have little use for external information that allows future projections
Middle management:
• in need of both short and longer-term information
• need for information in real time
• need current information on performance as measured against set standards
• highly dependent on internal information
• need for historical information, along with information that allows prediction of future
events
Strategic management:
• highly dependent on information from external sources that supply news of market trends
and the strategies of competing corporations.
• high need for information of a predictive nature
• need for periodically reported information
Organizational Culture
• Organizations have cultures and subcultures
• Learn from verbal and nonverbal symbolism
We need to think of organizations as hosts to multiple, often competing subcultures.
 Competing subcultures may be in conflict, attempting to gain adherents to their vision of
what the organization should be.
• Verbal symbolism – includes shared language used to construct, convey, and
preserve subculture myths, metaphors, visions, and humor.
• Nonverbal symbolism – includes shared artifacts, rites, and ceremonies.
 Understanding and recognizing predominant organizational subcultures may help the systems
analyst overcome the resistance to change that arises when a new information system is
installed.

V.Thiruppathy Kesavan, AP/CSE Kalasalingam University 12

Computer Systems Engineering/CSE205 Unit I

PROJECT MANAGEMENT FUNDAMENTALS

Project initiation – begins with problems or with opportunities for improvement in a business as
the organization adapts to change.
Determining project feasibility – need to work with decision makers to determine if it is feasible.
Project scheduling – project activities are scheduled through the use of tools such as Gantt charts
and PERT diagrams.
Planning and managing activities and team members – part of assuring the productivity of
systems analysis team members is effectively managing scheduled activities.
Project Initiation
• Problems in the organization
• Problems that lend themselves to systems solutions
• Opportunities for improvement
• Caused through upgrading, altering, or installing new systems
Both problems and opportunities can arise as the organization adapts to and copes with natural,
evolutionary change.

Figure 3.1 Checking output, observing employee behavior, and listening to feedback are all ways
to help the analyst pinpoint systems problems and opportunities
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

V.Thiruppathy Kesavan, AP/CSE Kalasalingam University 13

Computer Systems Engineering/CSE205 Unit I

1. Issues are the current situation, objectives are the desired situation.
2. Requirements may include security, usability, government requirements and so on.
3. Constraints might be budget restrictions or time limitations.
Problem Definition Steps
• Find a number of points that may be included in one issue - Before the problem definition is
produced information is gathered from interviews, observations, and document analysis with
the users. Major points are then identified as issues.
• State the objective - Once the issues are identified (current situation), objectives are stated
(desired situation). Sometimes this may require follow-up interviews.
• Determine the relative importance of the issues or objectives - After the objectives are stated
the relative importance of the issues or objectives is determined.
• Identify which objectives are most critical - Due to constraints it is generally necessary to
order the objectives to determine which are most critical.
Selection of Projects
Backing from management – absolutely nothing can be accomplished without the endorsement of
the people who eventually will foot the bill.
Appropriate timing of project commitment – can a time commitment be made for installation of
new systems or improvement to existing ones?
Possibility of improving attainment of organizational goals – the project should put the
organization on target, not deter it from its goals.
Practical in terms of resources for the system analyst and organization – is there expertise and
resources to carry out the project.
Worthwhile project compared with other ways the organization could invest resources – when a
business commits to one project it is committing resources that are unavailable for other projects.
DETERMINING FEASIBILITY
• Defining objectives
• Determining resources
• Operationally
• Technically
• Economically
The feasibility study must be highly time compressed, encompassing several activities in a short
span of time.
Defining Objectives
Many possible objectives exist including:
• Speeding up a process
• Streamlining a process
• Combining processes
• Reducing errors in input

V.Thiruppathy Kesavan, AP/CSE Kalasalingam University 14

Computer Systems Engineering/CSE205 Unit I

• Reducing redundant storage

• Reducing redundant output
• Improving system and subsystem integration
Improvements to systems can be defined as changes that will result in incremental but worthwhile
benefits.
Feasibility Impact Grid (FIG)
• A feasibility impact grid (FIG) is used to assess the impact of any improvements to the
existing system
• It can increase awareness of the impacts made on the achievement of corporate objectives
FIG’s can be used for both process and corporate objectives analysis

• Current or proposed
systems are listed on the
left.

• Objectives are listed on

the top.

• Red arrows indicate a

positive impact.

• Green arrows indicate

Figure 3.3 An analyst can use a feasibility impact grid to show how each system component
affects process objectives

V.Thiruppathy Kesavan, AP/CSE Kalasalingam University 15

Computer Systems Engineering/CSE205 Unit I

Figure 3.4 An analyst can use a feasibility impact grid to show how each system component
affects corporate objectives
By understanding process and corporate objectives, an analyst realizes why he or she is building
systems and comprehends what the importance of designing efficient and effective systems might
be.

Figure 3.5 The three key elements

of feasibility include technical,
economic, and operational
feasibility
A project must be feasible in all
three ways to merit further
development.

V.Thiruppathy Kesavan, AP/CSE Kalasalingam University 16

Computer Systems Engineering/CSE205 Unit I

Technical Feasibility
• Can current technical resources be upgraded or added to in a manner that fulfills the request
under consideration
• If not, is there technology in existence that meets the specifications
Sometimes add-0ns are costly and not worthwhile, because they meet needs inefficiently.
Economic Feasibility
• Economic feasibility determines whether value of the investment exceeds the time and cost
• Includes:
• Analyst and analyst team time
• Business employee time
• Hardware
• Software
• Software development
If short-term costs are not overshadowed by long-term gains or produce no immediate reduction
in operating costs, the system is not economically feasible.
Operational Feasibility
• Operational feasibility determines if the human resources are available to operate the system
once it has been installed
• Users that do not want a new system may prevent it from becoming operationally feasible
• If users are satisfied with current system resistance to implementing a new system will be
strong.
• If users are dissatisfied with the current system and have expressed a need for change chances
are that the new system will be used.
ACTIVITY PLANNING AND CONTROL
• Planning includes:
• Selecting a systems analysis team
• Estimating time required to complete each task
• Scheduling the project
• Control includes:
• Comparing the plan for the project with its actual evolution
• Taking appropriate action to expedite or reschedule activities
Estimating Time
• Project is broken down into phases
• Further project is broken down into tasks or activities
• Finally project is broken down into steps or even smaller units
• Time is estimated for each task or activity

V.Thiruppathy Kesavan, AP/CSE Kalasalingam University 17

Computer Systems Engineering/CSE205 Unit I

• Most likely, pessimistic, and optimistic estimates for time may be used
Estimating Time
• Project is broken down into phases
• Further project is broken down into tasks or activities
• Finally project is broken down into steps or even smaller units
• Time is estimated for each task or activity
• Most likely, pessimistic, and optimistic estimates for time may be used
Phase Activity
Analysis Data gathering
Data flow and decision analysis
Proposal preparation
Design Data entry design
Input design
Output design
Data organization
Implementation Implementation
Evaluation
Figure 3.6 Beginning to plan a project by breaking it into three major activities
Activity Detailed Activity Weeks Required
Data gathering Conduct interviews 3
Administer questionnaires 4
Read company reports 4
Introduce prototype 5
Observe reactions to prototype 3
Data flow and decision analysis Analyze data flow 8
Proposal preparation Perform cost/benefit analysis 3
Prepare proposal 2
Present proposal 2
Figure 3.7 Refining the planning and scheduling of analysis activities by adding detailed tasks
and establishing the time required to complete the tasks
Project Scheduling
• Gantt Charts
• Simple
• Lends itself to end user communication
• Drawn to scale
• PERT diagrams
• Useful when activities can be done in parallel

V.Thiruppathy Kesavan, AP/CSE Kalasalingam University 18

Computer Systems Engineering/CSE205 Unit I

Figure 3.8 Using a two-dimensional Gantt chart for planning activities that can be accomplished
in parallel
PERT Diagram

Figure 3.12 A completed PERT diagram for the analysis phase of a systems project
PERT Diagram Advantages
• Easy identification of the order of precedence
• Easy identification of the critical path and thus critical activities
• Easy determination of slack time

V.Thiruppathy Kesavan, AP/CSE Kalasalingam University 19

Computer Systems Engineering/CSE205 Unit I

Timeboxing
• Timeboxing sets an absolute due date for project delivery
• The most critical features are developed first and implemented by the due date
• Other features are added later
FUNCTION POINT ANALYSIS
• Count components
• Rate each component’s complexity
• Assign complexity numbers
• Arrive at a subtotal
• Multiply by adjustment factor
Based on Five Main Components of Computer Systems
External input – can be data from another application or even data entered on an input screen
External output – usually derived variables, calculated within the system that transfer to another
system or prepare a report.
External queries – actions that retrieve data from internal files or databases but not change them.
Internal logical files – clusters of logically identifiable data that are stored entirely within the
system.
External interface files – groups of logically related data maintained by applications outside the
system and are used for reference purposes only.
Staffing Requirements
• Choice of software can influence the amount of effort that goes into system development
• It is not true that the more people assigned to a task, the faster it will get done
A rule of thumb to estimate person-months:
Number of person months = 1.4 x (number of lines of code/1,000)
A rule of thumb to calculate months scheduled:
Scheduled months = 3 * (person months) 1/3
Managing Risk
• 30 percent of all projects succeed
• 20 percent fail
• 50 percent finish, but are either late, over budget, or offer fewer features than originally
promised
If the project manager carefully things about scenarios that would cause potential problems and
calculates the expected value of all delays, they would be able to add additional time as a buffer
to protect against the entire project failing.

V.Thiruppathy Kesavan, AP/CSE Kalasalingam University 20

Computer Systems Engineering/CSE205 Unit I

Figure 3.16 Calculating the extra time required to ensure that a project is completed on time

Figure 3.15 Function point counts can be accomplished in five steps

V.Thiruppathy Kesavan, AP/CSE Kalasalingam University 21