1

Ch 1 - An Overview of System Analysis and Design

Software Development
● Computer application (app) pat of information system – a computer software program that executes
on a computing device to carry out a specific set of functions (its a software written in programing
language & instructions to perform curtain functions or tasks)
○ Modest scope → limited task, ex. In talabat or Crave application you can’t book a flight
● Information system – a set of interrelated components that collects, processes, stores, and
provides as output the information needed to complete business tasks (its connected components
working together to collect\gather data
○ Broader in scope than “app”
○ Includes database and related manual processes
● Systems analysis (what) – those activities that enable a person to understand and specify what
an information system should accomplish or needs (it includes tasks/activities for the system analyst in
order to identify requirements that the system would need to perform its task and achieve its goals
Ex. QU registration system, when we try to develop it first we need data so we should ask what data is needed
for students to create their schedules, for instance, they would need their QU ID and etc. next comes SYSTEM DESIGN this is
when we think about the layout and how we’ll do it for the students, how will it perform the task, how will we deliver it

● Systems design (how) – those activities that enable a person to define and describe in detail the
system that solves the need
System Development Life Cycle (SDLC)
● The process consists of all activities required to build, launch, and maintain an information
system. Six core processes are:
1. Identify the problem or need and obtain approval
● identify the solution objective;
● obtain project approval
2. Plan and monitor the project
● Determining team members
● Assigning responsibilities
3. Discover and understand the details of the problem or need (analysis phase)
● Performing in-depth fact finding to understand details
4. Design the system components that solve the problem (design phase)
● Designing the database
5. Build, test, and integrate system components (creating the system using softwares or coding)
● Programming
6. Complete system tests and then deploy the solution
● Overall functional testing
Why do they call it System Development Life Cycle? Because once we develop the system and put it in
operation, and after a period of time the system ethier needs more enhancements or it doesn’t work well
so we have to start the process again. So it's a nonstop cycle
Activities and Tasks in the SDLC

Iterations: this means cycle (agile method)

The shape and size of mountain represents the time of focus,
effort & planning also it indicates how much time is needed
So the bigger/ higher the mountain the more the focus, effort
& planning
 2

Ch 1 - Case Study
Note: for any case study we either have a problem or opportunity (growth) or we have new rules by government agents we have
to apply
There is a company named Ridgeline Mountain Outfitters (RMO), they organize Trade Show System
(exhibitions), so they do exhibitions for other companies and those companies sell the products bought for
exhibitions to other individuals
Background about the company:
● Large retail Company
○ Outdoor and sporting clothing and accessories
○ Skiing, mountain biking, water sports
○ Hiking, camping, mountain climbing
● Rocky Mountain and Western States
○ Started mail order and phone order
○ Added retail stores
○ Added extensive E-business component

● Problem: purchasing agents attend apparel and fabric trade shows around the world to order new
products from suppliers
● Need: information system (app) to collect and track information about suppliers and new
products while at tradeshows
● Tradeshow Project: is proposed
○ Supplier information subsystem
○ Product information subsystem
Requirement: They need to develop two systems online in order for the purchase manager to be able to
search during the exhibition for the suppliers available and products + to be able to purchase directly from
the system

Plan to have 6 iteration and each iteration in a day because it's a small system (two sub systems) and they
divide the time of each activity using hours (regularly any other project would be divided in days and the
iterations take more than two week)

Initial Activities - pre-project

● Identify the problem and document the objective of the system (core process 1)
○ Preliminary investigation
○ System Vision Document
● Obtain approval to commence the project (core process 1)
○ Meet with key stakeholders, including executive management
○ Decision reached, approved plan and budget
To obtain approval we use System Vision Document, which consists of 3 sections, problem description,
system capabilities, business benefits to the stakeholders and executive managers (1 - 2 pages)
Day 1 Activities
● Core process 2: Plan the Project
○ Determine the major components (functional areas)
that are needed
■ Supplier information subsystem
■ Product information subsystem
○ Define the iterations and assign each function to an
iteration
■ Decide to do Supplier subsystem first
 3

■ Plan one iteration as it is small and straight forward

○ Determine team members and responsibilities
So create a Work Breakdown Structure for iterations, describe the work and cover Core Processes 3, 4,
5, and 6. You could create it by making a step by step sequence for iterations
Day 2 Activities
● Core Process 3: Discover and Understand Details
○ Do preliminary fact finding to understand requirements
○ Develop a preliminary list of use cases (describing scenario) and use case diagram
○ Develop a preliminary list of classes and a class diagram
●

Day 3 Activities
● Core Process 3: Discover and
Understand Details
○ Do in-depth fact-finding
to understand
requirements
○ Understand and document
the detailed workflow of
each use case
● Core Process 4: Design System
Components
○ Define the user experience
with screens and report
sketches
○ Draft screen layout
Day 4 Activites
● Core Process 4: Design System Components
○ Design the database (schema)
○ Design the system’s high level structure
■ Browser, Windows, or Smart phone
■ Architectural configuration (components)
■ Design class diagram
■ Subsystem architectural design
Day 5 Activities
● Core Process 4: Design System Components
○ Continue with design details
○ Proceed use case by use case
 4

● Core Process 5: Buld, Test and Integrate System Components

○ Continue programming (build)
○ Build use case by use case
○ Perform unit and integration test
Day 6 Activities
● Core Process 6: Complete System Testing and Deploy the system
○ Perform system functional testing
○ Perform user acceptance testing
○ Possibly deploy part system
First Iteration Recap
● This project was a 6 day iteration of small project
○ Most iterations are longer (2 to 4 weeks)
○ This project might be 2 iterations
○ Most projects have many more iterations
● End user need to be involved, particularly in day 1,2,3 and 6
● Days 4 and 5 involved design and programming concurrently
Ch 10 - Approaches to System Development
The System Development Life Cycle (SDLC)
● There are two general approaches to the SDLC
● Predictive Approach (methodology) to the SDLC
○ Waterfall model
○ Assumes the project can be planned in advance and that the information system can be
developed according to the plan
○ Requirements are well understood and/or low technical risk
● Adaptive Approach to the SDLC
○ Iterative model
○ Assumes the project must be more flexible and adapt to changing needs as the project
progresses
○ Requirements and needs are uncertain and/or high technical risk
● Most projects fall on a continuum between Predictive and Adaptive

Traditional Predictive SDLC

We could use predictive SDLC and adaptive SDLC both at same time so we shouldn’t choose one
methodology
Adaptive SDLC ex is my banner (uncertain and high technical risk) always lagging
● Have sequential Phases
○ Phases are related groups of development activities, such as planning, analysis, design,
implementation, and deployment these are the 5 main phases and it could be more than 5 + you could
work at two phases at same time or you could go back and adjust or edit
● Waterfall model
○ SDLC that assumes phases can be completed sequentially with no overlap or iteration
 5

○ Once one phase is completed, you fall over the waterfall to the next phase, no going back

Tradition IS Development Phases

Waterfall Predictive SDLC

Modified Waterfall with Overlapping Phases

● More flexibility, but still assumes predictive planning and sequential phases

Diamond is the decision point, this means here we stop and evaluate whether we are sure if we’re done or should we go back and
finalize. As you can see design started during working on analysis, this means you can work at both phase at same time
“overlapping phases”
Newer Adaptive SDLC
● Emerged in response to increasingly complex requirements and uncertain technological
environments
 6

● Always includes iterations where some of design and implementation is done from the beginning
● Many developers claim it is the only way to develop information systems
● Incremental development
● Completes portions of the system in small increments and integrated as the project progresses

A Generic Adaptive Approach

● Six Core Processes go across iterations
● Multiple Iterations as required

Methodologies
A Methodology includes a collection of techniques
that are used to complete activities and tasks,
including modeling, for every aspect of the project.
It guides us through phases & provides us every iteration in
SDLC

Methodologies, Models, Tools, and Techniques

● Model
○ An abstraction of an important aspect of the real world.
○ Makes it possible to understand a complex concept by focusing
only on a relevant part
○ Each model shows a different aspect of the concept
○ Crucial for communicating project information
Graphical models represents “input —> process —> output” in order to communicate between analyst and programmer so it
helps in communication between both
● In IS, some models are of system components that will be developed
● Other models are used to manage the
development process

● Tools —> models are created using tools, tools are

softwares
○ Software applications that assists
developers in creating models or
other components required for a
project (examples: Microsoft
Project, Visio, Access, Excel)
● Integrated Development Environment (IDE)
○ set of tools (more than one) that work
together to provide a comprehensive
development environment (Visual
Studio)
 7

Technique
A collection of guidelines that help an analyst complete an activity or task
Learning techniques is the key to having expertise in a field
It’s a concept/strategy/ principles that guides the system analyst activities/tasks

Agile Modeling Principles

● Agile Modeling (AM) – 12 Principles —> each methodology has some principle components
○ Agile means ‘ability to move quickly and easily’ and responding swiftly to change (being
able to respond fast to any changes in the system requirements)
○ A philosophy – build only necessary models that are useful and at the right level of detail

Agile Principles
● Develop software as the primary goal —> focus on system
○ Don’t get distracted by documentation or models
● Enable the next effort as your secondary goal
○ Be aware of next step versions or revisions
● Minimize your modeling activity —> use whatever you need, so don’t use what doesn’t add anything
○ Only build what helps move the project forward
● Embrace change and change incrementally —> small changes at a time
○ Take small steps that keep you on-track and that can be reversed if necessary
● Model with a purpose —> don’t use any graph that doesn’t add value
○ Model to understand
○ Model to communicate
● Build multiple models —> to look at systems from different point of views
○ Look at problems from different perspectives (user perspective, owner perspective)
● Build high-quality models and get feedback —> get feedback on every iteration & make modifications
● Focus on content rather than representation
○ Informal hand-drawn models are sometimes okay
○ Always focus on stakeholder needs
● Learn from each other with open communication
● Know your models and how to use them
● Adapt to specific project needs
● Maximize stakeholder ROI —> so we need to design the system in most efficient way to minimize cost &
maximize return
Example
 8

● A company is working on a project to come up with a competing product for MS Word, that
provides all the features provided by MS Word and any other features requested by the marketing
team. The final product needs to be ready in 10 months of time.

Traditional Waterfall Methodology (relying on planning)

● At a high level, the project teams would spend 15% of their time on gathering
requirements and analysis (1.5 months)
● 20% of their time on design (2 months)
● 40% on coding (4 months) and unit testing
● 20% on System and Integration testing (2 months).
● At the end of this cycle, the project may also have 2 weeks of User Acceptance testing by
marketing teams.
● In this approach, the customer does not get to see the end product until the end of the
project, when it becomes too late to make significant changes + giving feedback
We divide 10 months among phases (multiple the % by number of months)

Agile methodology
● In the Agile approach, each project is broken up into several ‘Iterations’. (cycles)
● All Iterations should be of the same time duration (between 2 to 8 weeks).
● At the end of each iteration, a working product should be delivered.
● In simple terms, in the Agile approach the project will be broken up into 10 releases (assuming
each iteration is set to last 4 weeks). (10 iterations/columns)
● Rather than spending 1.5 months on requirements gathering, in Agile software development, the
team will decide the basic core features that are required in the product and decide which of these
features can be developed in the first iteration.
○ Usually in the first iteration they start with the basic core features then move on with the rest
iterations
● Any remaining features that cannot be delivered in the first iteration will be taken up in the next
iteration or subsequent iterations, based on priority.
● At the end of the first iterations, the team will deliver a working software with the features that
were finalized for that iteration.
● There will be 10 iterations and at the end of each iteration the customer is delivered a working
software that is incrementally enhanced and updated with the features that were shortlisted for
that iteration.

traditional Waterfall model

“Beck, Beedle, Van Bennekum, Cockburn, et al.
(2001) defined the agile philosophy as follows:
We are uncovering better ways of developing software
by doing it and helping others do it. Through this
work we have come to value:
1. Individuals and interactions over processes
and tools
2. Working software over comprehensive
documentation
3. Customer collaboration over contract
negotiation
4. Responding to change over following a plan
 9

5. That is, while there is value in the items on the right, we value the items on the left more.”

Agile Method

In every iteration we add more features but we work at all six

processes at once and build up. Where on the other hands the
traditional waterfall model works at one by one and doesn’t
move on to the next step until they’re fully done with what
they’re working on and they can’t go back to adjust

Example of agile method

 10

agile is flexible non agile is not flexible and can’t make changes
Agile size is small non agile is large
Agile adapt is flexible non agile is less flexible
Agile importance could share with other people and it is relying on involvement of people
Agile team size is small not more than 10
If requirement are not clear and certain we use agile
Agile developers are more plan oriented more technical oriented and outcome oriented.
 11

Advantages of Agile Methodology

● The customers are satisfied because after every cycle the working feature of the software is
delivered to them. So they could see every step their working on and changes could occur
● Customers can have a look of the working feature which fulfilled their expectations.
● If the customer has any feedback or any change in the feature then it can be accommodated in the
current release of the product. Edits and changes could easily happen
● In Agile methodology the daily interactions are required between the business people and the
developers.
● Changes in the requirements are accepted even in the later stages of the development.

Disadvantages of the Agile Methodology

● In Agile methodology the documentation is less.
● Sometimes in Agile methodology the requirement is not very clear hence it’s difficult to predict
the expected result.
● In few of the projects at the starting of the software development life cycle it’s difficult to
estimate the actual effort required.
● The projects following the Agile methodology may have to face some unknown risks which can
affect the development of the project.

The Unified Process (UP)

● The UP was the early leader in adaptive approaches
● UP and UML (Unified Modeling Language) were developed together
● UP Phases organize iterations into four primary areas of focus during a project
○ Inception phase – getting the project started
 12

○ Elaboration – understanding the system requirements

○ Construction – building the system (process 5)
○ Transitions – preparing for and moving to deploying the new system (process 6)
Unified Process (UP) – Phases
Objectives of each phase

Extreme Programming (XP)

● Takes the best practices of software development and extends them “to the extreme”
○ Focus intensely on proven industry practices
○ Combine them in unique ways to get better results
● XP Core Values
○ Communication
○ Simplicity
○ Feedback
○ Courage
● XP Practices
○ Planning – based on user stories
○ Testing – thorough testing at every step
○ Simple Designs – Agile modeling principles
○ Refactoring – redo and cleanup as you go
○ Small releases – turn over to user frequently
○ Forty-hour work week – don’t overload the developers
 13

Chapter A - the role of the Systems Analyst

Online Chapter A Outline

● The Analyst as a Business Problem Solver

● Systems That Solve Business Problems
● Required Skills of the Systems Analyst
● Analysis-Related Careers

Learning Objectives
● Explain the key role of a systems analyst in business
● Describe the various types of systems and technologies an analyst might use
● Explain the importance of technical skills, people skills, and business skills for an analyst
● Explain why ethical behavior is crucial for a systems analyst’s career
● Describe various job titles in the field and places of employment where analysis and design work
is done

Overview
● People today are attracted to information systems careers because information technology (IT)
can have a dramatic impact on productivity and profits. it is part of our life (daily basis) ex. Covid situation
and online studying
● It is the people who develop information system solutions that harness the power of the
technology that makes these benefits possible it has a positive impact on productivity and profit
● The key to successful system development is thorough systems analysis and design to understand
what the business requires from the information system. System analysis role is to understand the system
problem or enhance and expand business
● Systems analysis – the process of understanding and specifying in detail what the information
system should accomplish
● Systems design – the process of specifying in detail how the many components of the information
system should be physically implemented
● Systems analyst –a business professional who uses analysis and design techniques to solve
business problems by using information technology
● This course is about the tools and techniques used by a systems analyst to develop information
systems

Problems to be Solved
● Customers want to order products any time of the day or night. So, the problem is how to process
those orders around the clock without adding to the selling cost. Ex. if you order at 1am is it immediately
processed or you’ll wait for the next day until they see it, therefore, we need to come with a solution so the order would
be processed immediately when it's received, therefore they need to use an expert system. Another example for
production is the need to develop a mathematical model to minimize the factor of production, so many companies and
suppliers try to minimize their inventories because it's costly to store, this is a business problem. Also in marketing they
need to analyze customers behaviour, therefore anytime you visit a website they always keep a record of customers
data. Another example is that top managers always keep track of financial data and competitors so in this case as a
system analyst you could suggest a Decision Support System inorder to collect data and analyze it. All these examples
are examples of business analytics
● Production needs to plan very carefully the amount of each type of product to produce each week.
So, the problem is how to estimate the dozens of parameters that affect production and then allow
planners to explore different scenarios before committing to a specific plan.
 14

● Suppliers want to minimize their inventory holding costs by shipping parts used in the
manufacturing process in smaller daily batches. So, the problem is how to order in smaller lots
and accept daily shipments to take advantage of supplier discounts.
● Marketing wants to better anticipate customer needs by tracking purchasing patterns and buyer
trends. So, the problem is how to collect and analyze information on customer behavior that
marketing can put to use.
● Management continually wants to know the current financial picture of the company, including
profit and loss, cash flow, and stock market forecasts. So, the problem is how to collect, analyze,
and present all the financial information management wants
● Employees demand more flexibility in their benefits programs, and management wants to build
loyalty and morale. So, the problem is how to process transactions for flexible health plans,
wellness programs, employee investment options, retirement accounts, and other benefit
programs offered to employees.

Analyst’s Approach to Problem Solving

The main role is to solve and provide solutions using information

technology or information systems
This is general approaches to any problems:
Step 1: research and understand the problem
Very important to know the causes of the problem in order to solve the problem
ex. If the time of processing customers application takes too long, so what might
be the reason, maybe they have a lot of applications or the system is slow. In this
step its important to ask your self the 5 why inorder to reach to the root causes
Step 2: verify that the benefits of solving the problem outweigh
the costs
Solving the problem is more beneficial then the cost we spend if yes we continue
if no then there is no benefits to solve the problem
Step 3: define the requirements for solving the problem ex.Fishbone
Step 4: develop a set of possible solutions (alternatives) ex. PEICES
And choose the best solution, feasibility analysis is done to know what to choose
best
Step 5: decide which solution is best and make a recommendation
Step 6: define the details of the chosen solution
Step 7: implement the solution
Step 8: monitor

Systems Concepts
● System – a collection of interrelated components that function together to achieve some outcome
● Information system – a collection of interrelated components that collect, process, store, and
provide as output the information needed to complete business tasks
● Subsystem – a system that is part of a larger system any system could be divided to subsystems
● Functional decomposition – dividing a system into components based on subsystems that are
further divided into smaller subsystems
● System boundary – the separation between a system and its environment that inputs and outputs
must cross
 15

System Components
Any system has: input → processing → output
Ex. customer support system ... input is data and
its in databases form and output is information
All these components work together

Information Systems and Subsystems

Customer relationship management

system is divided into subsystems
Each system has a specific
boundaries and whatever is outside
the boundaries is considered as
environment

System Concepts
 16

Types of Information Systems

● Customer relationship management (CRM) system – a
system that supports marketing, sales, and service
operations involving direct and indirect customer
interaction
● Supply chain management (SCM) system – a system that
seamlessly integrates product development, product
acquisition, manufacturing, and inventory management
● Accounting and financial management (AFM) system – a
system that records accounting information needed to
produce financial statements and other reports used by
investors and creditors
● Human resource management (HRM) system – a system
that supports such employee-related tasks as payroll,
benefits, hiring, and training
● Manufacturing management system – a system that
controls internal production processes that turn raw
materials into finished goods
● Knowledge management system (KMS) – a system that supports the storage of and access to
documents from all parts of the organization
● Collaboration support system (CSS) – a system that enables geographically distributed personnel
to collaborate on projects and tasks
● Business intelligence system – a system that supports strategic planning and executive decision
making
● Enterprise resource planning (ERP) – a process in which an organization commits to using an
integrated set of software packages for key information systems

Principles of System Development

● Get the system users involved. Get users involved within the process inorder to provide you with answers of
what should the system do and what are the requirements +if you involve them from day 1 they’ll feel that they’re part
of it and they’ll accept it and use it. We indicate the system is successful by the use of user, if they use it more and
constantly then its successful
● Use a problem-solving approach. .understand the root causes → generate solutions → evaluate them →
conduct conclusions. It's important to have a systematic approach of problem solving
● Establish phases and activities. .dividing the entire system development life cycle into phases or stages and for
each phase they’ll be list of tasks to be completed
● Document through development. .the agile method doesn’t emphasize a lot of documentation while the
traditional does so they need to write down everything and document the difficulties and challenges so they can avoid it
next time and documentation is done while developing the system and not after.
● Establish standards. .especially for quality measurement for whether we met the deadline or if we met the users
spectation
● Manage the process and projects . ex. Creating graphs to monitor the process and progress of project
● Justify systems as capital investments (equipment/machines). .these equipments helps us in generating
revenue and reduce cost
● Don’t be afraid to cancel or revise scope. .can the company continue with the plan or cancel it or adjust
● Divide and conquer. .
● Design systems for growth and change. .
 17

Knowledge and Skills - Required of a systems analyst

There are three type of skills that a

system analyst should have:
- Technical skill
- Business skill
- People skill
You would focus on a specific skill
depending on what your system is
oriented on , business oriented or
technical oriented and etc.

Knowledge and Skills - Tools and techniques

● Tools – a software application that assists developers in creating models or other components
required for a project
● Techniques –strategies for completing specific system development activities
○ Project planning techniques
○ Cost/benefit analysis techniques
○ Interviewing techniques
○ Requirements modeling techniques
○ Architectural design techniques
○ Network configuration techniques
○ Database design techniques
Technical Knowledge and Skills (related to hardware and software)
● Computers and how they work
● File, database, and storage hardware and software
● Input and output hardware and software
● Computer networks and protocols
● Programming languages, operating systems, and utilities
● Communication and collaboration technology such as digital telephones, videoconferencing, and
Web-based document management systems
Business Knowledge and Skills
● What business functions do organizations perform?
● How are organizations structured?
● Consumer behavior
● How are organizations managed?
● What type of work goes on in organizations (finance, manufacturing, marketing, customer
service, etc)?
● What the specific organization does
● What makes it successful
● What its strategies and plans are
● What its traditions and values are
 18

People Knowledge and Skills (soft skill)

● Interpersonal skills are perhaps the analyst’s most important skills because analysts rely on others,
including managers, users, programmers, technical specialists, customers, and vendors, to take a
system from initial idea to final implementation
● The analyst must develop rapport with users who may be resistant to change, negotiate with
management for such resources as budget, time, and personnel, and manage development
personnel with many different skills, capabilities, and attitudes
● The analyst must be an effective teacher, mentor, confidant, collaborator, manager, and leader,
shifting easily among those roles many times over the course of a typical work day
How to understand people and manage? How to lead? How to communicate? How to coordinate all team members?
Analysis Related Careers
● Employment in the fields of information systems and computer technology spans a wide variety
of skills, organizations, and roles
● In-house development, including analysis and design, is especially common in security-sensitive
industries, national defense, and research and development in national laboratories
● Changes in software development, technology, and business practices have created many new
career opportunities for analysts, including sales and support of ERP software; business analysts
for user organizations; auditing, compliance, and security; and Web development
A Variety of Job Titles
● Programmer analyst
● Business systems analyst
● End-user analyst
● Business consultant
● Systems consultant
● Systems support analyst
● Systems designer
● Software engineer
● System architect
● Web architect
ETHICS and Systems Analysts
● Ethics – the principles and standards that guide our behavior toward other people
● Ethics are rooted in history, culture, and religion
They have to have high standard ethics because they might not be aware of any technology or systems and they’ll try to solve any
problem with no guides + you have to be honest in advising your customer with the most suitable system and not advise them
with the most financial benefit for you
● Factors that Determine How You Decide Ethical Issues (Actions in ethical dilemmas (a result of
a clash between competing goals, responsibilities, and loyalties) determined by):
● Your basic ethical structure that you developed as you grew up. You can not teach others ethics but its by
seeing how others behave
● The circumstances of the situation.
● Your basic ethical structure determines what you consider to be → when we consider a situation we
might have different opinions about it whether its ethical or not based on our ethical structure and our values + how
we were raised at home + there are some factors that could impact our behavior which is our ethical structure and the
circumstances. Ex. an employee uses the computer at work to play online games, some people would find it a minor
ethical violation or serious or very serious.
○ Minor ethical violations
○ Serious ethical violations
○ Very serious ethical violations
● Ethical decisions are complex judgments that balance rewards for yourself and others against
responsibilities to yourself and others.
 19

Basic Ethical Structure

All these factors might influence or
decision when we evaluate a
situation or consider taking action
Likelihood of Effect: What's the
probability that my behaviour would
impact others either good way or
bad way
Reach of result: how many people
will be affected
Consequences: taking action or not
Relatedness: who are the people
affected, relative or you don’t know
them
Time to Consequences: time form
action until consequence/ impact will
happen, is immediately or after one
month or a year
Circumstances of the Situation
1.Consequences of the action or inaction:
- How much little benefit or harm will come from your decision?
2.Society’s opinion of the action or inaction:
- What is your perception of what society really thinks of your intended action?
3.Likelihood of effect of action or inaction:
- What is the probability of the harm or benefit that will occur if you take the action?
4.Time to consequences of action or inaction:
- How long will it take for the benefit or harm to take effect?
5.Relatedness of people who will be affected by action or inaction
- How much you identify with the persons who will receive the benefit or suffer the harm.
6.Reach of result of action or inaction:
- How many people will be affected by your action?
When it comes to classifying actions whether its illegal or legal its based on
rules and when someone is breaking the rules then the action is illegal

Ethical and unethical are according to common standards and common ethics
and in some cases there is no sold rules

We should have our actions according to law and according to social standard

Ethical dilemma → it's not clear if its ethical or not

Ex. sharing a pilot health situations as he might have a heart attack anytime

legal/unethical: watching news in library or movie

illegal/ethical: exceeding speed limit for an urgent case
legal/ethical: going to work on time
illegal/unethical: sharing patient information
 20

The Ten Commandments of Computer Ethics

1. Thou shalt not use a computer to harm other people.
2. Thou shalt not interfere with other people’s computer work.
3. Thou shalt not snoop around in other people’s computer files.
4. Thou shalt not use a computer to steal.
5. Thou shalt not use a computer to bear false witness.
6. Thou shalt not copy or use proprietary software for which you have not paid.
7. Thou shalt not use other people’s computer resources without authorization or proper compensation.
8. Thou shalt not appropriate other people’s intellectual output.
9. Thou shalt think about the social consequences of the program you are writing or the system you are
designing.
10. Thou shalt always use a computer in ways that insure consideration and respect for your fellow human
Ch 11 - Project Planning & Project Management
Principles of Project Management:
The Need for Project Management → it increase rate of success of project
● Categories of project success
○ Successful projects – on time, within budget, meeting the scope of the project
○ Challenged projects – failure in one area
○ Failed projects – cancelled or not used
● Recent years have seen some improvement, but still 1/3 to 1/2 of projects are challenged or fail

The Need for Project Management

● Reasons for failure
○ Undefined project management practices .if we don’t have a good plan, no good team members, not
good in communication + no good tools + no good top management support
○ Poor IT management and poor IT procedures
○ Inadequate executive support for the project
○ Inexperienced project managers
○ Unclear business needs and project objectives
○ Inadequate user involvement
The Role of the Project Manager
● Project Management
○ Organizing and directing other people to achieve a planned result within a predetermined
schedule and budget
○ The processes used to plan the project and then to monitor and control it.
● Project Manager Responsibilities
○ Internal Responsibilities
■ Developing the project schedule
■ Recruiting and training team members
 21

■ Assigning work to teams and team members

■ Assessing project risks
■ Monitoring and controlling project deliverables and milestones
○ External Responsibilities
■ Reporting the project’s status and progress
■ Working directly with the client (the project’s sponsor) and other stakeholders
■ Identifying resource needs and obtaining resources
Project Manager & Project Stakeholders

Project Management Body of Knowledge (PMBOK)

Project Management Institute: www.PMI.org
PMBOK is organized into 10 knowledge areas:
● Project Integration Management—Integrating all the other knowledge areas into one seamless
whole (together)
● Project Scope Management—Defining and controlling the functions that are to be included in
the system as well as the scope of the work to be done by the project team what goal, what tool to use
what templates
● Project Time Management—Creating a detailed schedule of all project tasks and then
monitoring the progress of the project against defined milestones
● Project Cost Management—Calculating the initial cost/benefit analysis and its later updates and
monitoring expenditures as the project progresses
● Project Quality Management—Establishing a comprehensive plan for ensuring quality, which
includes quality control activities for every phase of a project establishing standards
● Project Human Resource Management—Recruiting and hiring project team members; training,
motivating, and team building; and implementing related activities to ensure a happy, productive
team
● Project Communications Management—Identifying all stakeholders and the key
communications to each; also establishing all communications mechanisms and schedules
 22

● Project Risk Management—Identifying and reviewing throughout the project all potential risks
for failure and developing plans to reduce these risks
● Project Procurement Management—Developing requests for proposals, evaluating bids,
writing contracts, and then monitoring vendor performance
● Project Stakeholder Management—Identifying and communicating with the stakeholders of the
new system as they affect and influence the project
Activities of Core Process 1:
● Identify the Problem and Obtain
Approval
Identify the Problem (Preliminary
investigation):
● IS Development Projects usually:
○ Respond to an opportunity
■ Strategic initiative
■ Something that
provides competitive
advantage
○ Resolve a problem
■ Operational issues keep coming up
■ User needs aren’t being met
○ Respond to an external directive (rules)
■ Legislation requires new form of reporting
■ Changes in tax laws or regulations
Steps in Problem Identification (Preliminary Investigation) and get approval we have to create a
case to represent it to to management so they can approve it
● Step 1: Understand the Problem or Opportunity. If we have a problem we need to understand it
and analyze it and look at cause
● Step 2: Define the project scope and constraints. What the main objective what are the limitations
● Step 3: Quantify Project Approval Factors : Project justification estimate cost of project estimate
the time, so we can have solid numbers that we can present to top management
● Step 4: Determine Project Risk and Feasibility we should consider risk, the factors that may
influence the success of project
● Step 5: Review with Client and Obtain Approval (Present Results and Recommendations to
Management)
Steps in Problem Identification (Preliminary Investigation)
● Step 1: Understand the Problem or Opportunity.
○ You cannot solve a problem until you understand it
and you cannot understand it until you analyze it. This means identifying the causes, the
main reasons behind the problem so we can come up with a solution

● Techniques used for Problem Analysis:

1. 5-Whys and So What? Asking yourself why this problem what is the reasons
Ex. You have a small company to print poster an flyers and one customer didn’t
pay, then you ask yourself why they didn’t pay, answer is we were late, why we were late because
printer was late, why the printer is late, the problem is caused from the ink
2. A fishbone diagram, or Ishikawa diagram: a popular technique for investigating
causes and effects
Fishbone diagram, it provides us with the causes of the problem
3. Pareto chart
4. PIECES framework
 23

System constraint —> limitations

To be able to come up with a chart like this we need to
identify the problem and causes and effects

Ishikawa Diagram
● Graphical model used to identify, explore, and depict problems and the causes and effects of those
problems. It is often referred to as a cause-and-effect diagram or a fishbone diagram.
○ Problem at right (fish head)
○ Possible causes drawn as "bones" off main backbone
○ Brainstorm for 3-6 main categories of possible causes
We have members
contract default, the
problem is that many
customers they break
contract before end of
term, and on the left
are all possible causes

A sample of Cause-and-Effect Diagram

Problem on right “can not login” and on the

left they used the 5 why technique to get to the
root cause
 24

Pareto Charts:

● A Pareto chart is a histogram that can help you

identify and prioritize problem areas.
● Pareto analysis is also called the 80-20 rule,
meaning that 80 percent of problems are often due
to 20 percent of the causes.
It’s a bar chart with a line chart (combined). We create a
cumulative % for each problem, so we take the total
number and we divide each frequency by the total number.
The second point in the line chart represents the
cumulative of first to problems.
The manager would focus on most frequent problem

The PIECES Problem-Solving Framework

P: the need to improve performance (system performance “output or response time”
I: the need to improve information (and data) “input”
E: the need to improve economics, control costs, or increase profits “cost of system”
C: the need to improve efficiency of people and processes
S: the need to improve service to customers, suppliers, partners, employees, etc.
Steps in Problem identification (Preliminary Investigation)
● Step 2: Define the Project Scope and Constraints
○ Project scope: defining specific boundaries of the project. For example “payroll is not
being produced accurately versus overtime pay is not being calculated correctly for
production workers on the second shift at Doha plant” another example, the project scope
is to modify the account receivable system versus the project scope is to allow customers
to inquire online about account balance and recent transactions
■ You may define the project scope by creating a list of:
■ What it Must do? Should do? Could do? Won’t do? These questions will help
us to know the scope of the project
■ The list could be reviewed later in the analysis phase (e.g., system requirement
identification)
■ Project creep: increase in project scope without authorization.
Once we determine the scope we need to determine the requirements
● Constraint: a requirement, condition, or outcome that the system must satisfy or achieve.
● Three characteristics for constraints should be examined:
○ Present versus future. (e.g., must met as soon as the system is developed?)
○ Internal versus external (is it due internal requirements or external forces?)
○ Mandatory versus desirable (essential or desirable?).
○ Regardless of the type, all constraints should be identified as early as possible to avoid
future problems and surprises.

For example if we have urgent requirements coming from

government then its external and mandatory
A manager needs a certain export in certain format, they have the
report ready but they’ll like to see it in another format then its
internal and desirable
● System Vision Document: a document to help define the
scope of the new system
 25

○ Problem Description
■ What is the problem and idea for the solution?
○ System Capabilities
■ What are the capabilities the new system will have?
■ Helps define the scope
○ Business Benefits
■ The benefits that accrue to the organization
■ Tangible (in dollars) and intangible benefits
Business case
Example if you'd like to take a loan, you need to provide them with a
case “background info of your project”. This is more detailed than the
vision document
3. Quantify Project Approval Factors : Project justification
● Estimated Time for Completion
● Estimate cost for the project
● The anticipated benefits
● Estimated Cost for Development
● Anticipated Benefits from New System
○ Opening up new markets with new
services, products, or locations
○ Increasing market share in existing
markets
○ Enhancing cross-sales capabilities with
existing customers
○ Reducing staff by automating manual functions or increasing efficiency
○ Decreasing operating expenses, such as shipping charges for “emergency shipments”
○ Reducing error rates through automated editing or validation
○ Reducing bad accounts or bad credit losses
○ Reducing inventory or merchandise losses through tighter controls
○ Collecting receivables (accounts receivable) more rapidly
● Tangible “Dollar” Benefits
○ Used for Cost/Benefit Analysis--process of comparing costs and benefits to see whether
investing in a new system will be beneficial-- ex. Reducing costs
Cost\Benefit Analysis (very important in any project)
● Cost/benefit analysis
○ comparing costs and benefits to see if the net result is plus or minus
● Net Present Value (NPV)
○ the present value of dollar benefits and dollar costs of a particular investment
● Break-even Point
○ point in time at which benefits (revenue) and costs are equal
● Payback Period
○ the time period after which the dollar benefits have offset the dollar costs (period of payback
period to break-even point, the shorter the better)
● Tangible Benefit
○ a benefit that can be measured or estimated in terms of dollars
● Intangible Benefit
○ a benefit that accrues to an organization but that can’t be measured quantitatively or estimated
accurately
Examples of Intangible Benefits
● Increased levels of service (in ways that can’t be measured in dollars)
● Increased customer satisfaction (not measurable in dollars)
● Survival—need to do it to compete
● Need to develop in-house expertise (such as a pilot program with new technology)

Cost\Benefit Analysis
 26

● Use present value (after discount factor) for all dollar values
● Estimate the useful life of the system
● The NPV after 5 years is $1,713,097
● Payback Period is 2 years and 128 days
4. Determine Project Risk and Feasibility
● Determine the organizational risks and feasibility
○ How well does the new system fit the
organizational culture? Risk of negative impacts?
● Evaluate the technological risks and feasibility
○ Can the system be built by the team using technology needed? Training available?
● Assess the resource risks and feasibility
○ Are the needed resources available? Skilled people?
● Identify the schedule risks and feasibility
○ Can the system be built in the amount of time available? Fixed Deadline?
How much training is needed? Are we expecting them to use the system in most efficient way? Do we need experts?
Evaluate Feasibility
● Operational feasibility (user needs, requirements, expectations).
○ Will the solution fulfill the users’ requirements? To what degree? How will the
solution change the users’ work environment? How do users feel about such a
solution?
● Technical feasibility (hardware, software, technical resources)
○ Is the solution technically practical? Does our staff have the technical expertise to
design and build this solution?
● Economic feasibility (financial analysis tools)
○ Is the solution cost-effective?
● Schedule feasibility (acceptable completion date)
○ Can the solution be designed and implemented within an acceptable time period?
Feasibility Matrix

According to their
importance we assign
weights, just like
homework and exams.
We assign more weight
to the more important
task or feasibility
Based on experience
we assign scores for
every candidate
Ranking = .3*60
+.3*50+.3*95 = 60.5

We rank to find the best

solution to solve the
problem
 27

5. Review with Client and Obtain Approval

● Executive committee reviews and approves
● Board must review and approve for very large projects
● Involved stakeholders need to understand what is expected of them
● IS department needs to know what to do for staffing and support
● Whole organization should be made aware of the project and its importance
Activities of Core Process 2:
Plan and Monitor the Project (5 activities)
1. Establish the Project Environment
● Project manager must establish project
parameters (determine environment) and
the work environment:
○ Recording and
communicating—internal and
external
■ Who, what, when, and
how
○ Work environment
■ Workstations, software development tools (IDE), servers and repositories, office
and meeting space, support staff (you have to decide on the technical
enviornment and what methodology “waterfall or agile)
○ Process and procedures followed
■ Reporting and documentation, programming approach, testing, deliverables, code
and version control
● In other words, tailor and operationalize the
methodology being used
2. Schedule the Work
● Project manager must establish initial project schedule
and keep adjusting
○ Project Iteration Schedule (identify tasks)
■ The list of iterations and use cases or
user stories assigned to each iteration
(we use work breakdown structure)
○ Detailed Work Schedule
■ Within an iteration, the schedule that
lists, organizes, and describes the
dependencies of the detailed work tasks
■ As each iteration is finished, a detailed
work schedule is prepared for the next
iteration
■ The next detailed work schedule takes into account the changes necessary based
on feedback/progress
Use cases are scenarios ex. When you draw money, first we insert card then we put the pin…
● Developing Detailed Work Schedule takes three steps:
○ Develop a Work Breakdown Structure (WBS)
■ The list or hierarchy of activities and tasks used to estimate the work to be done
in a project or iteration
Under each phase we list the task, heading is phase, and the numbered subheadings are tasks
○ Estimate effort and identify dependencies
■ Task times
■ Tasks that must be completed before another task begins
■ Critical path--a sequence of tasks that can’t be delayed without causing the entire
project to be delayed
 28

There are different methods to estimate time, we take 3 estimates, then we ask experts about each task how long would it take
from there own experience. There are two types of people, optimistic who gives the nearest time, minimum period, and there are
people who worry a lot and give the max time
○
Create a schedule using a Gantt chart
■ Bar chart that portrays the schedule by the length of horizontal bars
superimposed on a calendar
○ Tasks for the Work Breakdown Schedule
○ There should be a way to recognize when the task is complete.
○ The definition of the task should be clear enough so you can estimate the amount of effort
required.
○ As a general rule for software projects, the effort should take one to five working days.
Schedule the Work:
Work Breakdown Structure (WBS) with Time Estimates and Notes

Breakdown tasks -> assign relationship-> assign duration

Under each phase we list the task, heading is phase, and the numbered
subheadings are tasks
Once we have the tasks and durations then we need the third piece of info
which is the relationship among these tasks, which is when we finish what
we start next

We need 3 information
- task name
- Duration
- Relationship

● Gantt Chart and PERT chart for

first iteration
○ Shows task, duration,
start date, predecessors,
and resources
○ Generates chart
graphically showing
dates, predecessors, tasks,
and critical path
Grantt chart is a bar chart (horizontal) against the
table. Predecessor is the task that comes before a
task you want to do. Meeting with marketing
depends on meeting with sales so after finishing
cell 2 we can start the meeting with market
Parallel activities don’t depend on each other we
could work on them at the same time (ex.activities
7,8,9)
 29

3. Staff and Allocate Resources

● Staffing activity tasks consists of 5 tasks:
○ Developing a resource plan for the project
○ Identifying and requesting specific technical staff
○ Identifying and requesting specific user staff
○ Organizing the project team into work groups
○ Conducting preliminary training and team-building exercises
Staffing and allocating resources is important after you create your plan/schedule
4. Evaluate Work Processes:
Retrospective
● Are our communication procedures adequate? How can they be improved?
● Are our working relationships with the user effective?
● Did we hit our deadlines? Why or why not?
● Did we miss any major issues? How can we avoid this in the future?
● What things went especially well? How can we ensure it continues?
● What were the bottlenecks or problem areas? How can we eliminate them?
You have to always monitor and evaluate the process. Any failure in meeting the project constraint this
means our project is not succcessful
5. Monitor Project Progress and Make Corrections
● Process to monitor and control project execution

To make up any delay we need to create this flow chart for it (solving the problem)
Monitor Project Progress and Make Corrections
● Sample Issues-Tracking Log

Or you could use the tracking log to monitor with details

Ch C - Project Management Techniques
● Chapter 11 focused on project management principles, which are a major portion of each of the first two core
processes: Identify the problem and obtain approval, and Plan and monitor the project
● This online chapter will extend the coverage of project management principles and will provide additional explanations
on several of the important project management techniques, including the use of Microsoft Project software
 30

● This chapter will explain cost/benefit analysis in more depth as well as explain two other financial measures: breakeven
point and return on investment

Calculating Financial Returns - Net Present Value

● The two basic concepts of net present value are (1) that all benefits and costs are calculated in
terms of today’s dollars (that is, present value) and (2) that benefits and costs are combined to
give a net value—hence, the name net present value
● Discount rate – the annual percentage rate that an amount of money is discounted to bring it to a
present value
● Discount factor – the accumulation of yearly discounts based on the discount rate

● NPV Calculation Example

n
● Discount factors F are usually looked up in tables rather than calculated
We need to calculate/find discount factor first
I: discount rate, n: number of years
● For RMO CSMS Project:

Calculating Financial Returns - Payback Period

● Payback period – the amount of time the system has to operate to repay the costs of building and
operating it
● In the example in Figure C-1, we use the time value of money (that is, the discount rate) and use
net benefits (that is, benefits minus operating costs)
● The year when the cumulative value becomes positive is the year in which payback occurs.

Calculating Financial Returns - Return on Investment (ROI)

● Return on investment – calculates a percentage return (like an interest rate) on the initial
investment
● Sometimes, ROI calculations are done by using values that include the discount factor
● At other times, ROI is done on purely a cash basis without considering the organization’s
assigned discount rate
 31

PERT/CPM Charts
● PERT/CPM chart is a network diagram with boxes that represent the tasks or activities of the
project and with connecting arrows that represent the sequence and dependencies between tasks
● PERT, which stands for Project Evaluation and Review Technique developed by the U.S.
Department of Defense to organize, monitor, and control very large, complex defense projects
● CPM, which stands for Critical Path Method, was developed independently
● In practice, the two techniques are combined
Microsoft Project is used to create this diagram

Title: Create Work Breakdown Structure (WBS) Work Breakdown Structure (WBS)
First Iteration of CSMS Project With Predecessor Information added

predecessor is the number of the task that should be complete before

the current task, ex. We couldn’t start task 5,6,7 until we finish 3,4.
Additionally this indicates that we can start 5,6,7 all at the same time

PERT/CPM chart - After identifying task dependencies

each task is a box and the arrows represents the relationships

PERT/CPM chart - Critical Path

● Early start time – the earliest time that a task can begin due to predecessor durations
● Late start time – the latest time that a task can start to maintain the schedule
● Slack time – the amount of time a task or leg of sequential tasks can be delayed without
impacting the project schedule
● Earliest finish - earliest time we finish a task
● Latest finish - delaying the finishing date if we have slack time