CHAPTER II Information Systems Development Project

2.1. Managing Information System Project Project

management is an important aspect of the development
of information systems and a critical skill for a system
analyst. The focus of project management is to assure that
system development projects meet customer expectations
and are delivered within budget and time constraints.
The manager of an Information Systems department may
have a direct role in the systems development process if
the organization is small or that is the manager’s style.
Information Systems managers are more involved in
allocating resources to and overseeing approved system
development projects rather than in the actual project
development process
There are several IS mangers in any medium to large IS
department.
 The manager of an entire IS department may have the title
Chief Information Officer and may report to the president or
chairman of the firm. – Each division of the IS department will
also have a manager.
 Director of IS development, IS operation manger, IS
programmer director, etc. The customer, or the recipient of the
Information system project's deliverables, expects a certain
level of functionality and quality from the IS project. These
expectations can be self-imposed, such as the specification of the
project completion date, or customer-specified, such as producing
the sales report on a weekly basis.
Five constraints operate on every project:
Scope, Quality, Cost, Time and Resources These
constraints are an interdependent set; a change in one
can cause a change in another constraint to restore the
equilibrium of the project. In this context, the set of five
limitations form a system that must remain in balance for
the project to be in balance. The Project Manager is a
system analyst with a divers set of skills – management,
leadership, technical, conflict management, and customer
relationship – who is responsible for initiating, planning,
executing, and closing down the project.
The project manager should be care the project parameters and
focus on the project management concepts.
To ensure that information system projects meet customer
expectations: - Delivered in a timely manner and meet
constraints and requirements
 To lead individual who is responsible for specific tasks in the
project
  May be a person who is around throughout the entire
lifecycle
 Project manager is often an executive or group manager
  Follows projects either there is an effective utilization of
resources or not.  Planned undertakings of related activities to
reach an objective that has a beginning and an end.
Project: a planned undertaking of related activities to reach an
objective that has a beginning and an end. To successfully
coordinate the construction of a complex information system,
a project manager must have interpersonal, leadership, and
technical skills
Activity Description Skill
Leadership Influencing the Communication, liaison
activities of others between management,
toward the users, and developers,
attainment of a
common goal
through the
use of intelligence,
personality and
abilities.
Management Getting projects Defining and sequencing
completed through activities, communicating
the effective expectations, assigning
utilization of resources to activities,
resources monitoring outcome
Customer Working closely with Interpreting system requests
Relation customers to assure and specifications, site
project deliverables preparation and user training,
meet expectations. contact point for customer

Technical Designing and Interpreting system requests

Problem sequencing activities and specifications, defining
to attain project goals. activities and their sequence,
Solving making trade-offs between
alternative solutions,
designing solutions to
problems.
Conflict Managing Problem solving:
Managem conflict with in a smoothing out
ent project team to personality differences,
assure that compromising, and
conflict is not goal setting.
too high or too
low
Team Managing the Communication within and
Managemen project team for between teams, peer
t effective team evaluations, conflict resolution,
performance. team building, self-management
Risk and Identifying, Environmental scanning, risk and
Change assessing, and opportunities identification and
managing the assessment, forecasting, resource
Managemen risks and day-to- redeployment
t day changes that
occur during a
project
Information Systems Project Phase
The first step is to identify the need for a system, which can be the result
of: -
Problems in existing system or process
New feature required in an existing system
A new idea for which in Information System is required
A requirement to improve efficiency in the organization
Compulsory standards or bench marks by an external organization
Ex. Government
The need to keep up with competitors
The requests for developing information system can come from three
key sources
Managers and business units who want to replace or extend and
existing system in order to gain needed information or to provide a new
service to customers.
Information Systems managers who want to make a system more
efficient, less costly to operate or want to move a system to a new
operating environment.
Formal planning group that want to improve an existing system in
order to help the organization meet its corporate objectives, such as
providing better customer service.
The factors must be considered when selecting a project are
•Perceived needs of the organization
•Existing systems and ongoing projects
•Resource availability
•Evaluation criteria
•Current business conditions
•Perspective of the decision makers
Process of Information System development project consists of four
activities:
Initiating the project
Planning the Project
Executing the Project
Closing down the Project
Initiating the Project
During project initiation, the project manger performs several activities
that asses, the size, scope and complexity of the project and establishes
procedures to support subsequent activities. Depending on the project,
some initiation activities may be unnecessary and some may be very
involved. The following are the types of activities that you will perform
when initiating the project.
•Establishing the project initiation team. This activity involves
organizing an initial core of project team members to assist in
accomplishing the project initiation activities.
•Establishing a relationship with the customer. A thorough understanding
of your customer builds stronger partnerships and a higher level of trust.
Establishing the project initiation plan. This step defines the activities
required to organize the initiation team while it is working to define the
scope of the project.
This step eventually will lead to the creation of the System Service
Request (SSR) form.
System Service Request: is a standard form used for requesting systems
development work.
Establishing management procedure. Successful projects require the
development of effective management procedure. When establishing
procedures, you are concerned with developing team communication and
reporting procedure, job assignments and determining how project
funding and billing will be handled.
Establishing the project management environment and project
workbook. The focus of this activity is to collect and organize the tools
that you will use while managing the project and to construct the
workbook.
Project Workbook: an online or hard copy repository for all project
correspondence, inputs, outputs, deliverables, procedures and standards,
that is used for performing project audits, orienting new team members,
communicating with management and customers, identifying future
projects, and performing post project reviews.
Planning the Project
The second phase of the project management process, which focuses on
defining clear, discrete activities and the work needed to complete each
activity within a single project. It often requires you to make numerous
assumptions about the availability of resources such as hardware,
software, and personnel. As with the project initiation process, varied
and numerous activities must be performed during project planning.
•Describing project scope, alternatives, and feasibility. The purpose of
this activity is to understand the content and complexity of the project.
• Dividing the project into manageable tasks. This is a critical activity
during the project planning process. Here you must divide the entire
project into manageable tasks and then logically order them to ensure a
smooth evaluation between tasks. The definition of tasks and their
sequence is referred to as the work break down structure.
•Estimating resources and creating a resource plan. The goal of this
activity is to estimate resource requirements for each project activity and
use this information to create a project resource plan. This resource plan
helps assemble and deploy resources in the most effective manner.
•Developing preliminary schedule. During this activity, you use the
information on tasks and resource availability to assign time estimates to
each activity in the work break down structure. The schedule may be
represented as a Gantt chart or as a Network Diagram.
Gantt Chart: is a graphical representation of a project that shows each
task as a horizontal bar whose length is proportional to its time for
completion.
Network Diagram: is a diagram that depicts project tasks and their
interrelationship.
•Developing a communication plans. The goal of this activity is to
outline the communication procedures among management, project team
members, and the customer.
•Determining project standards and procedures. During this activity,
you specify how various deliverables are produced and tested by you and
your project team.
•Identifying and assessing risks. The goal of this activity is to identify
sources of project risk and to estimate the consequences of those risks.
•Creating a preliminary budget. During this phase, you need to create a
preliminary budget that outlines the planned expenses and revenues
associated with your project.
•Developing a statement of work. An important activity that occurs near
the end of the project-planning phase is the development of the statement
of work. This document outlines the work that will be done and clearly
describes what the project will deliver.
•Setting a base line project plan. Once all the prior project-planning
activities have been completed, you will be able to develop a baseline
project plan. This baseline plan provides an estimate of the project tasks
and resource requirements and is used to guide the next project phase –
execution.
Executing the Project
The third phase of the project management process, in which the plans
created in the prior phase (project initiation and planning) are put into
action. Within the context of the SDLC, project execution occurs
primarily during the analysis, design, and implementation phase. The
following are list of activities performed during project execution.
•Executing the baseline project plan. As project manager, you oversee
the execution of the baseline plan. This means that you initiate the
execution of project activities, acquire and assign resources; orient and
train new team members, keep the project on schedule, and assure the
quality of project deliverables.
•Monitoring the baseline project plan. While you execute the baseline
project plan, you should monitor your progress. If the project gets ahead
of (or behind) schedule, you may have to adjust resources, activities, and
budgets.
•Managing changes to the baseline project plan. You will encounter
pressure to make changes to the baseline plan. In addition to changes
occurring through formal request, changes may also occur from events
•Maintaining the project workbook. As in all project phases,
maintaining complete records of all project events is necessary. The
workbook provides the documentation, new team members require to
assimilate project tasks quickly.
•Communicating the project status. The project manger is responsible
for keeping all team members – system developers, managers, and
customers – a breast of the project status.
Closing down the Project
This is the final phase of the project management process which
focuses on bringing a project to an end. Project can conclude with a
natural or unnatural termination. A natural termination occurs when the
requirements of the project have been met – the project has been
completed and is success. An unnatural termination occurs when the
project is stopped before completion. The following are the activities
performed during project close down
•Close down the project. During close down, you perform several
diverse activities. For example, if you have several team members
working with you, project completion may signify job and assignment
changes for some members.
•Conducting post project reviews. Once you closed down the project,
final reviews of the project should be conducted with management and
customers. The objective this reviews is to determine the strengths and
weaknesses of project deliverables, the processes used to create them
and the project management process.
•Close the customer contract. The focus of this final activity is to insure
that all contractual terms of the project have been met.
Close down is a very important activity. A project is not complete
until it is closed, and it is at close down that projects are deemed a
success or failure
Representing and Scheduling Project plans
The activity of project planning takes place throughout the life cycle. It
involves tracking the project progress as well as revising the plan to take
account of events as they occur. In many organisations, there is a specific
job role for project planning for the Project Manager.
In this phase, it is not possible to produce a detailed project plan –
because there is not yet enough detailed information about
requirements.. It is difficult to estimate the times required if you have not
got experience of carrying out each activity.
•Dates for starting each activity can be assigned, to show when the
project is likely to be completed – note that some activities must finish
before the next one begins, while others can begin before the previous
one has finished. This is because there are dependencies between
activities.
Task Estimated Begin Responsibl
Days Date e
1.Planning &
Selection
Define the problem 2 days Nov 17
Generate alternative 4 days Nov 19
conceptual solutions
Feasibility Study 3 days Nov 20
Project Planning 1 day
1.Analysis
Describe current system 4 days
Define Business Rules 2 days
Detailed Requirements for 4 days
new system
Initial design 3 days
1.Design
Logical Design 4 days
Physical Design 1.day
s
4. Implementation&
Operation
Build database 5 days
Write Code 20 days
Integration 2 days
Testing 10 days
Documentation 3 days
Total 1. Days
The document may also be called a Baseline Project Plan or a
Statement of Work or a Statement of Requirements. The exact content
and amount of detail in the document depends on the organization and
the participating parties.
The document also includes project-planning information, such as:
•Schedule, at a high level (approximate timings for each of the
subsequent phases)
•Estimated time of completion
•Resources required (people and equipment)
The Proposal document will usually have sections for the following:
•Introduction – an overview of the project, and its objective.
•Scope & Constraints – describe the scope of the project, in words
and/or with diagrams, and what constraints have been identified.
•Proposed Solution – describe the proposed solution at a conceptual
level; if a feasibility study was carried out, the rejected solutions can be
mentioned also, along with reasons for rejecting them.
•Schedule – indicate the estimated schedule for the project, showing also
the estimated resources required to achieve the completion date.
Chapter III
The System Development Life Cycle
The Traditional SDLC
As is expected of any profession that is still relatively young, IT has
evolved — and is still continuing to evolve — from highly individual
seat of- the-pants techniques for developing and maintaining systems to
formal, well-documented methodologies. In the early days, when what is
now called information technology (IT) was referred to as data
processing, there were no methodologies or formal guidelines for
developing systems. Systems were developed under what IT now knows
was the mistaken belief that their life span would never exceed five
years, and thus long-term maintainability was not considered a major
concern.
In its simplest form, an SDLC divides the software
development process into a number of clearly defined phases,
each of which is further divided into steps. Progress through the
steps is measured by the completion of forms and checklists.
Because the phases were viewed as sequential steps, with the
output from one phase becoming the input to the next, a
traditional SDLC was often called “a waterfall.” And, like water
flowing over a precipice, the underlying premise of the waterfall
approach to system development was that all motion was
forward. Once a phase was completed, there was no returning
to it.
System System Design
nitiation
I
Analysis

Testing and Quality

Assurance
Constructio
n
mplement
I

ation
Advantages of the Traditional SDLC
Although sometimes criticized for its rigidity, a traditional SDLC
provided and continues to provide benefits for many organizations. In
addition to the reason it was initiated — namely, adding structure to a
previously unstructured process — the waterfall approach to system
development has two primary advantages:
•The explicit guidelines allow the use of less-experienced staff for
system development, as all steps are clearly outlined.
•The methodology promotes consistency among projects, which can
reduce the cost of ongoing support and allow staff to be transferred from
one project to another.
Disadvantages of the Traditional SDLC
•If followed slavishly, it can result in the generation of unnecessary
documents. Many methodologies have forms for every possible scenario.
Inexperienced staff may believe that all are required and may, for
example, insist on three levels of customer sign-off when only one is
needed.
•It is difficult for the customer to identify all requirements early in the
project; however, the sequential “river of no return” approach dictates
this. The philosophy of the SDLC means that there are no easy ways to
mitigate this problem and still remain true to the methodology.
The customer is involved only periodically, rather than being an active
participant throughout the project. This can result in misunderstandings
on both sides: IT and the customer
The Generic System Development Model
Systems Development Life Cycle – SDLC
SDLC is the series of steps used to mark the phases of development for
an information system. It is a common methodology for systems
development.
A.Systems Planning and Selection
It is the first phase of the SDLC in which an organization’s total
information system needs are analyzed and arranged and in which a
potential argument for continuing or not continuing with the project is
presented. The system planning and selection phase has two primary
activities.
•Identifying the need for a new or enhanced system
Information needs of the organization are examined and projects to meet
these needs are identified from
Requests to deal with problems in current procedures
The desire to perform additional tasks
The realization that information technology could be used to
improve the organization
The Systems analyst prioritizes and translates the needs into a written
plan including a schedule for developing new systems.
The organization may decide whether or not the resources devoted for
the project and a careful feasibility study is conducted to determine the
economic and organizational impact of the system
•The second task is investigating the system and determining the
proposed system’s scope. Then a specific plan for the proposed project
for the team to follow is produced. This Baseline Project Plan
customizes the standardized SDLC and specifies the time and resources
needed for its execution
B.Systems Analysis
During this phase, the analyst thoroughly studies the organizations
current procedures and the information systems used to perform tasks.
It has three sub phases,
First sub phase involves the systems analyst to determine the
requirements of the system, i.e., what the users want from a proposed
system
Next, the requirements gathered are structured (DFD, ERD) according to
their interrelationships, eliminating the redundancies
Third, system analyst has to generate alternative initial designs to match
the requirements, best suited design is selected for the development
after the comparison of all alternative designs
C. Systems Design
The system analyst converts the description of recommended solution
into logical and physical designs. Logical design involves in designing
the user interface, databases and compute processes, irrespective of the
programming languages (Algorithms, input and output forms, reports,
table normalization)
During the Physical design, the analyst team decides the programming
language, database systems to be used, hardware platform, operating
systems and network environment.
D.Systems Implementation and operation
•In this phase the information system is coded, tested and installed in the
organization, and in which the information system is systematically
repaired and improved
•Planning for both testing and installation is to be done as early as the
project planning and selection phase, because they both require extensive
analysis in order to develop exactly the right approach.
•This phase also includes the initial training to the users and
documentation of the system documented throughout the life cycle.
•During operation part, the problems faced by the users should be
solved, and changes and enhancements (new versions) are to be made as
per the users’ desire to reflect changing business conditions.
There inevitably comes a time, when an information system is no longer
performing as desired, when the costs of keeping a system running
become prohibitive, or when an organization’s needs have changed
substantially
Phase Products, out puts, or Deliverables
- priorities for systems and projects
System Planning - architecture of data, networks, hardware, and IS management
& - detailed work plan for selected project
Selection - specification of system scope - system justification or business case
- description of current system- general recommendation on how to fix,
System Analysis enhance or replace current system -- explanation of alternative systems,
and justification for chosen alternative
System - detailed specification of all system elements
Design - acquisition plan for new technology
System - code - documentation - training procedures and support capabilities
Implementation
- new versions or releases of software with associated updates to
& documentation, training and support
Operation
System Development Guideline
As you gain experience as a system analyst, you will develop your own
style and techniques. Although each project is different, you should
consider some basic guide lines as you build an information system.
•Sick to an overall development plan.
•Ensure that users are involved in the development process especially
when identifying and modeling system requirements.
•Identify major milestones for project review and assessment.
•Establish interim check points between major mile stones to ensure that
the project remains on schedule.
•Be flexible within the frame work of your plan.
Provide accurate and reliable cost, and benefit information
Approaches to System Analysis and Design
There are two approaches to Information system development:
1.Process-oriented and
2.Data-oriented
•Process-oriented approach
•Traditionally, Systems Analysts designed an Information System
based on what the system was meant to do, such as billing or
inventory control or, in our example, producing results statements.
•This meant that the focus was on outputs and processing logic – or,
in other words, on the flow, use and transformation of data.
•The data used as inputs were seen as important also, but secondary to
(not as important as) the application.
•Each system would contain its own files and data storage areas (e.g. a
payroll system and a system for scheduling classes & who will teach
them would each have their own sets of data for teachers in the
university)
•The data in each system would match the specifications for that system
only.
•Each system was considered (looked at) separately.
The analysis involved creating drawings/diagrams that show how the
data moves around the system and where it is stored in between flows
•Data-oriented approach
•Over time, the approach changed to being a more data-oriented. This
was a response to the problems above.
•This approach tends to focus on how the data should be represented or
organized, independently of where and how data are used in the system.
•A data model is produced – this describes the data and relationships
between the data. Business rules define how the organization deals with
the data.
•With this approach, databases are designed around subjects – such as
customers, suppliers, parts (or, in our university example, teachers,
students, and courses). This lets us use the same databases for many
different applications.
This led to the modern approach that usually includes a database for
storing data and applications that deal with getting and retrieving the
data from this one central location. This means that the application is
independent of data and data definitions – we can call this application
independence
Approach to System Development
Prototyping, rapid application development (RAD), Joint application design (JAD) and
Participatory design (PD) are four approaches that streamline and improve the systems
analysis and design process.
Rapid Application Development (RAD)
RAD refers to a type of software development approach which uses minimal planning
in favor of rapid prototyping. The "planning" of software developed using RAD is
interleaved with writing the software itself.
Key objective is fast development and high quality system at a relatively low
investment cost.
Breaking a project into smaller segments.
Aims to produce high quality systems quickly, through the use of
computerized development tools like Graphical User Interface (GUI)
builders, Computer Aided Software Engineering (CASE) tools, Database
Management Systems (DBMS), Fourth generation languages, etc.
Key emphasis is on fulfilling the business need while technological or
engineering excellence is of lesser importance.
Project control involves prioritizing development and defining
delivery deadlines or time boxes. The emphasis is on reducing
requirements, not in increasing the deadline.
It includes Joint Application Development (JAD), where users are
intensely involved in design.
Active user involvement is very important.
Produces documentation necessary to facilitate future development and
maintenance
Prototyping
Prototyping is an evolutionary development approach. Instead of
spending a lot of time producing very detailed specifications, the
developers find out only generally what the users want. The developers
do not develop the complete system all at once. Instead they quickly
create a prototype, which either contains portions of the system of most
interest to the users, or is a small-scale working model of the entire
system. After reviewing the prototype with the users, the developers
refine and extend it. This process is continued until the final
specifications
•Designing and building a scaled-down version of the desired
information system with the help of CASE tools
•Prototyping is a key tool that supports rapid application development.
RAD involves gaining user acceptance of the interface and developing
key system capabilities as quickly as possible.
•In this approach a small version or prototype of the system is prepared
and implemented.
•User while working with prototype makes suggestions.
Suggestions are incorporated to make it fully operational system
Joint Application Design
A structured process in which users, managers and analysts work
together for several days in a series of intensive meetings to specify or
review system requirements.
JAD is a group-based method for collecting user requirements and
creating system designs. It is used within the systems analysis and design
stages of the SDLC. Unlike the traditional SDLC, where the analysts
interview individual users of the new information system to understand
their needs JAD has a meeting in which all users meet simultaneously
with analysts. During the meeting, all users jointly define and agree upon
systems requirements.
Participatory design
•PD involves users in the development process; they have an equal voice
in determining system requirements and in approving system design.
Software Engineering Process
Software Engineering is the science and art of building significant
software systems that are: 1) on time 2) on budget 3) with acceptable
performance 4) with correct operation.
Software engineering is concerned with theories, methods and tools for
professional software development. For example, Software engineering
expenditure represents a
significant fraction of the GNP of developed countries.
Software costs often dominate system costs. The costs of software on a
PC are often greater than the hardware cost. Software costs more to
maintain than it does to develop.
Software engineering is concerned with cost-effective software
development.
Software product may:-
Generic products: Stand-alone systems which are produced by a
development organization and sold on the open market to any
customer.
Generic products: Stand-alone systems which are produced by a
development organization and sold on the open market to any
customer.
Customized products: Systems which are commissioned by a specific
customer and developed specially by some contractor.
The Software Process is structured set of activities required to develop
a
software system with:
Specification- defining what the system should do;
Design- defining the organization of the system and implementing the
system;
Validation- checking that it does what the customer wants;
Evolution- changing the system in response to changing customer
needs.
Activities vary depending on the organization and the type of system
being developed.
•Specification: Set out the requirements and
constraints on the system.
1.Design: Produce a model of the system.
2.Manufacture: Build the system.
3.Test: Check the system meets the required
specifications.
4.Install: Deliver the system to the customer and
ensure it is operational.
•Maintain: Repair faults in the system as they
are discovered
Professional Responsibility: - Software engineers should not just be concerned with
technical considerations. They have wider ethical, social and professional
responsibilities.
Ethical Issues: - Confidentiality, Competence, Intellectual property rights and
Computer misuse.
CHAPTER IV
SYSTEM SELECTION AND PLANNING

Identification of Projects
System selection and planning is the primary phase of SDLC deals
with the process of identifying, selecting, initiating, planning projects
and assessing project feasibility. And, identifying and selecting projects
one of its tasks which is performed by a key member of top
management, or a steering committee composed of cross section
managers, or user departments, or the development group.
Projects identified by top management have a strategic
organizational focus, by the steering committees have a cross
functional focus, by the individual departments have a narrow,
tactical focus. The development group identifies projects based on
the ease with existing hardware and software systems.
Hence, projects may be identified by both top-down and
bottom-up initiatives. The systems analyst should support
these groups, to describe their information needs.
Classifying and ranking Information System development projects
is the second task under system selection and planning of SDLC.
This task is done by top managers, a steering committee, business units
or the IS development group. The criteria commonly used to evaluate
projects are
•Value chain analysis: Extent to which activities add greatest benefits
•Strategic alignment: Extent the projects achieves the long term goals
•Potential benefits: Extent to which the project helps to improve
profits, Customer service, etc and the duration of the benefits
•Resource availability: Amount and type of resources required for the
Project
•Project size / duration: Number of individuals and duration to
complete
•Technical difficulty / risk: Level of technical difficult to complete.
The factors must be considered when selecting a project are
•Perceived needs of the organization
•Existing systems and ongoing projects
•Resource availability
•Evaluation criteria
•Current business conditions
•Perspective of the decision makers

Deliverables and outcomes

•The primary deliverable or end product form the project identification
and selection phase is a schedule of specific IS development projects.
•These projects may come from both top down and bottom up sources
The selected project move into the second activity called Project
initiation and planning
Initiating and Planning System Development Project
•The objective of project initiation and planning is to
transform a vague system requirements into a
tangible project description
•Proper project initiation and planning can reduce the
time consumption of further phases
•Activities performed in this phase could also be
completed during the next phase, System analysis
•A rule of thumb is that 10 – 20 % of the entire effort
should be expended in this phase
The general Process of Initiating and Planning Systems
development Projects are:
•Project Initiation: - Focuses on activities that will help to
organize a team to conduct project planning. During initiation,
one or more analysts are assigned to work with a customer to
establish work standards and communication procedures.
•Project Planning: - Focuses on defining clear, discrete tasks
and the work needed to complete each task. The objective of the
project planning is to produce two documents: a Baseline
Project Plan (BPP) and the Statement of Work (SOW) or a
Statement of Requirements. The exact content and amount of
detail in the document depends on the organization and the
participating parties. The document also includes project-
planning information, such as:
•Requirements. The exact content and amount of detail in
the document depends on the organization and the
participating parties. The document also includes project-
planning information, such as:
•Schedule, at a high level (approximate timings for each of
the subsequent phases)
•Estimated time of completion
Resources required (people and equipment
The BPP is an internal document used by the development team
but not shared with customers
The BPP contains all information collected and analyzed during
the project initiation and planning activity. The BPP reflects the
best estimate of the project’s scope, benefits, costs, risks and
resource requirements. The BPP specifies detailed project
activities for the next life cycle phase- Systems analysis and less
detail for subsequent phases.
The SOW is a short document prepared for the customers that
describe what the project will deliver and outlines all work
required to complete the project. The SOW is a useful
communication tool that assures that both system analysts and
customers have a common understanding of the project.
Assessing Project Feasibility
Most Information System projects have budgets and deadlines;
the analysis of factors for feasibility forms the business case
(analysis of the assumptions like resource availability and
potential problems and system cost and benefits) that justifies the
expenditure of the resources on the project. The feasibility factors
are in six categories
•Economic Feasibility
It is a measure of the cost-effectiveness of a project or
solution. This is often called a cost-benefit analysis.
Concerned with assessing the financial benefits and
costs associated with the project. To do this, it is necessary
to quantify the monetary value of the costs and benefits of
the project. This is also called a cost-benefit analysis.
Benefits and costs can be tangible or intangible.
Tangibles are items which can be quantified in monetary
terms and with certainty. Ex. equipment costs, staff/personnel
costs, materials costs, conversion costs, training costs.
Intangibles are items for which a value cannot be precisely
determined, and where the value may be the result of
subjective judgment. Ex. Customer goodwill, employee
morale. Operational efficiency
The sum value of all costs identified for the project gives the
cost of the system
The sum value of all the benefits identified for the project
gives the benefit of the systems
These are then used to determine if the project is
economically feasible. There are two methods for doing this are
work sheet method and present value method
Operational Feasibility
Operational feasibility is a measure of how well a specific solution
will work in the organization. It is also a measure of how people feel
and willing about the system/project.
-Does management support the system?
-How do the end-users feel about their role in the new system?
-What end-users or managers may resist or not use the system?
Can this problem be overcome? If so, how?
-Usability analysis: - Ease of use, Ease of learning, User
satisfaction
This process examines whether the new project will attain its
desired objectives.
The goal of this study is to understand the degree to which the
proposed system will likely solve the business problems or take
advantage of the opportunities specified in the Systems requirement
documents
Technical Feasibility
It is a measure of the practicality of a specific technical solution and
the availability of technical resources and expertise.
-Is the proposed technology or solution practical? Is the
technology mature?
-Do we currently possess the necessary technology? Is it at
hand?
-Do we possess the necessary technical expertise?
The goal of this study is to understand the organization’s ability to
construct the proposed system. This analysis also includes an
assessment of the development group’s understanding of the possible
target hardware, software and operating environments as well as the
size, complexity and the group’s experience with similar systems
•Schedule Feasibility
The process of assessing the degree to which the potential
time frame and completion dates for all major activities
within a project meet organizational deadlines and constraints
for affecting change.
•Legal and Contractual Feasibility
The process of assessing potential legal and contractual
ramification due to the construction of a system.
Considerations may include copyright or nondisclosure
violation, labor laws, antitrust legislation, foreign trade
regulations and financial reporting standards as well as current
or pending contractual obligations.
•Political Feasibility
The process of evaluating how key stakeholders within the
organization View the proposed system
Building the Baseline Project Plan
•All the information collected during project initiation and
planning is collected and organized into a document called
the Baseline Project Plan.
•Once the BPP is completed, a formal review of the project
can be conducted with customers.
•BPP contains four major sections
1.Introduction
2.System Description
3.Feasibility assessment
4.Management issues
Introduction section: - provides a brief overview of the entire
document and outlines a recommended course of action for the
project.
•It provides an executive summary that specifies the project’s scope,
feasibility, justification, resource requirements and schedules.
Additionally, a brief statement of the problem, the environment in
which the system is to be implemented and constraints that affect the
project are provided.
Recommendation provides a summary of important findings from
the planning process and recommendations for subsequent activities
System Description section provides a list of alternatives system
configuration.
It provides a description of the selected configuration and a narrative
of input information, tasks performed and resultant information
Feasibility Assessment outlines project costs and benefits and
technical difficulties. High level project schedules are specified using
PERT and Gantt charts. The greatest amount of project planning effort
is typically expended on feasibility assessment activities.
Management Issues
1.Team Configuration and Management: Provides a
description of the team member roles and reporting relationships
2.Communication plan: Provides a description of the
communication procedures to be followed by management, team
members and the customer
3.Project standards and procedures: Provides a description of
how deliverables will be evaluated and accepted by the customer
4.Other project-specific topics: Provides a description of any
other relevant issues related to the project uncovered during
planning.
Reviewing the Baseline Project Plan
Before submitting the BPP to some project approval body, it is
to be reviewed by the users, management and development
groups.
The objectives of this review is to assure that the proposed
system conforms to organizational standards and to make sure that
all relevant parties understand and agree with the information
contained in the BPP.
A common method for performing this review is called a
structured walkthrough, a peer group review of any product
created during the systems development process.
The walkthrough may have specific agenda that highlights what
is to be covered and the expected completion time.
Individuals attending the meeting have specific roles
Coordinator
Presenter
User
Secretary
Standard-bearer
Maintenance oracle
In addition to reviewing the BPP, the walkthrough can
be used for the following activities
System specifications
Logical and physical designs
Code or program segments
Test procedures and results
Manuals and documentation
Electronic Commerce Application: System Planning and Selection
Electronic commerce, commonly known as e-commerce or
eCommerce, is a type of industry where the buying and selling of
products or services is conducted over electronic systems such as the
Internet and other computer networks. Electronic commerce draws on
technologies such as mobile commerce, electronic funds transfer,
supply chain management, Internet marketing,
online transaction processing, electronic data interchange (EDI),
inventory management systems, and automated data collection
systems.
Modern electronic commerce typically uses the World Wide Web at
least at one point in the transaction's life-cycle, although it may
encompass a wider range of technologies such as e-mail,
mobile devices, social media, and telephones as well. Therefore, the
type of ecommerce and the project or information system should
determine under the system selection and system selection phase.
Electronic commerce is generally considered to be the sales aspect of
e-business. It also consists of the exchange of data to facilitate the
financing and payment aspects of business transactions. This is an
effective and efficient way of communicating within of the project of
an organization and one of the most effective and useful ways of
conducting business.
Some common applications related to electronic
commerce are the following:
Domestic and international Payment systems
Enterprise content management
•Group buying
•Automated online assistants
•Instant messaging
•Newsgroups
•Online shopping and order tracking
•Online banking
•Online office suites
•Shopping cart software
•Teleconferencing
•Electronic tickets
Social-networking
Types of e-commerce
Business-to-Business (B2B): B2B e-commerce is simply
defined as e-commerce between companies. This is the type
of e-commerce that deals with relationships between and
among businesses. About 80% of e-commerce is of this type,
and most experts predict that B2B e-commerce will continue
to grow faster than the B2C segment
Business-to-Consumer (B2C): Business-to-consumer
e-commerce, or commerce between companies and
consumers, involves customers gathering information;
purchasing physical goods (i.e., tangibles such as
books or consumer products) or information goods (or
goods of electronic material or digitized content, such
as software, or e-books); and, for information goods,
receiving products over an electronic network. It is the
second largest and the earliest form of e-commerce
Business-to-Government (B2G): Business-to-government e-commerce
or B2G is generally defined as commerce between companies and the
public sector. It refers to the use of the Internet for public
procurement, licensing procedures, and other government-related
operations. This kind of e-commerce has two features: first, the public
sector assumes a pilot/leading role in establishing e-commerce; and
second, it is assumed that the public sector has the greatest need for
making its procurement system more effective.
Consumer-to-Consumer (C2C): Consumer-to-consumer e-
commerce or C2C is simply commerce between private individuals
or consumers. This type of e-commerce is characterized by the
growth of electronic marketplaces and online auctions, particularly
in vertical industries where firms/businesses can bid for what they
want from among multiple suppliers. It perhaps has the greatest
potential for developing new markets.
Mobile Commerce (m-commerce): M-commerce (mobile
commerce) is the buying and selling of goods and services through
wireless technology-i.e., handheld devices such as cellular
telephones and personal digital assistants (PDAs). Japan is seen as a
global leader in m-commerce. As content delivery over wireless
devices becomes faster, more secure, and scalable, some believe
that m-commerce will surpass wire line e-commerce as the method
of choice for digital commerce transactions. This may well be true
for the Asia-Pacific where there are more mobile phone users than
there are Internet users.
CHAPTER V
SYSTEM ANALYSIS
5.1. Determining System Requirement
System analysis is the study of a business problem for the
purpose of recommending improvements and specifying the
business requirements for the solution. Systems analysis is the
part of the systems development life cycle in which you
determine how a current information system in an organization
functions. Then you assess what users would like to see in a
new system. There are three parts to system analysis:
determining requirements, structuring requirements, and
selecting the best alternative design strategy.
The characteristics of a good systems analyst in determining the requirements
are:
Impertinence: You should question about each and every aspects
involved in the system.
Impartiality: The role of a SA is to find the best solution to a business
problem or opportunity. Not to justify the purchase of new hardware or to
insist some requirements. The issues raised by all parties must be
considered and to find the best organizational solution.
Relaxing of Constraints: Assume that anything is possible and
eliminate the infeasible and traditions. Traditions are different from rules
and policies; it may be good but as the organization and its environments
changes, the traditions not to be appreciated.
Attention to details: Every fact must fit with every other fact. One
element out of place means that the ultimate system will fail at some time.
Reframing: Analysis is, in part, a creative process; the organization must be
viewed in new ways. Not to jump to this conclusion that “I worked on a system
like that once - this new system must work the same way as the one I built
before
Types of Deliverables

Information collected from

conversations with users

Interview transcripts

Questionnaire responses
Notes from observations
Meeting notes
Existing documents and
files
Business mission & strategy statement

Sample business forms & reports

& computer displays
Procedure manuals

Job descriptions

Training manuals

Flowcharts & documentations of

existing documents
Consultant
reports
Computer-based information

Results from JAD session

CASE repository contents &
reports of existing systems

Displays and reports from system

prototypes
1deliverables for requirements determination
•Traditional Methods for Determining requirements
•The traditional way of requirement determination
includes interviews, questionnaires, and direct
observation.
These traditional methods of collecting system
requirements are listed in table.
Traditional Method Activities Involved
Interviews with Interview individuals informed about the operation and issue of the
individuals current
System and needs for the systems in future organizational activities.

Questionnaire Survey people via questionnaire to discover issues and requirements.

Observe workers at selected times to see how data are handled and
On job observation what information people need to do their jobs.

Study business documents to discover reported issues, policies, rules,

and directions as well as concrete examples of the use of data and
Business documents information in the organization.
Joint Application Design (JAD)
The primary purpose of using JAD in the analysis phase is to collect systems
requirements simultaneously from the key people involved with the system. The
result is an intense and structured, but highly effective process. Having all the
people together in one place at one time allows analysts to see the areas of
agreement and the areas of conflict. The following is the list of typical JAD
participants:
JAD Session Leader: the JAD leader organizes and runs the JAD.
User: the key users of the system under consideration are vital participants in
JAD.
Managers: managers of the work groups who use the system in question
provide insight into new organizational directions, motivations for and
organizational impacts of systems, and support for requirements during the JAD.
Sponsor: due to its expense, someone a relatively high level in the company
such as a vice president or chief executive officer must sponsor a JAD.
System analysts: members of the system analysis team attend the JAD although
their actual participation may be limited.
Scribe: the scribe takes notes during the JAD session, usually on a personal
computer or laptop.
IS staff: beside system analysts, other IS staff such as programmers, database
analysts, IS planners, and data center personnel may attend the session.
Structuring System Requirements
During requirement structuring you study the requirements and structure them
according to their interrelationships, eliminating the redundancy. There are three
primary activities performed during requirement structuring.

Process modeling
Logic modeling
Conceptual Data Modeling
Process modeling
It involves graphically representing the process, or actions, that capture, manipulate,
store, and distribute data between a system and its environment among components
with in a system. A common form of a process model is a Data Flow Diagram (DFD).
A Data Flow Diagram is a graphic that illustrates the movement of data between
external entities and the process and data stores within a system.
Modeling System Process
The analysis team begins the process of structuring requirements with an abundance
of information gathered during requirements determination. In structured analysis,
the primary deliverables from process modeling are a set of coherent, interrelated
data flow diagrams. Deliverables of the process modeling are:
Context DFD
DFDs of current physical system
DFDs of new logical system
Through description of each DFD component
 Another organization or organizational unit that sends
data to or receives information from the system you are
analyzing.
 A person inside or outside the business unit supported by
the system you are analyzing and who interacts with the
system.
 Another information system with which the system you
are analyzing exchanges information
 Developing DFDs
 First, the boundary or scope of the system, and the systems interrelation ship
to its environment is represented by data flow diagram called a context
diagram.
 Context Diagram a DFD of the scope of an organizational system that shows
the system boundaries, external entities that interact with the system and the
major information flows between the entities the system. All context
diagrams have only process labeled “0”.
 Second, a context diagram is a DFD that provides a general overview of a
system. Other DFDs can used to focus on the details of a context diagram. A
Level-0 diagram is an example of such a DFD. A level-0 diagram represents
the primary individual processes in the system at the highest possible level of
detail.
Data Flow Diagramming Rules
You must follow a set of rules when drawing data flow diagrams. These rules
listed below, allow you to evaluate DFDs for correctness.
Rules governing Data Flow Diagramming
Process
No process can have only outputs. It is making data from nothing (a miracle). If
an object has only outputs, then it must be a source.
No process can have only inputs ( a black hole). If an object has only inputs, then
it must be a sink.
A process has a verb phrase label.