Systems Analysts Structured Analysis
Systems Analysts Structured Analysis
Object-Oriented Analysis
Agile Methods
Business Case
Analyzing the Business Case
The term business case refers to the reasons, or justification, for a proposal
You are a systems analyst working for Sally, the IT manager for a large hotel chain.
Sally is working with top management to develop a strategic plan, and she asked
you to assist her. The plan will guide future company goals and objectives, including
IT projects. Sally has experience with the Visible Analyst CASE tool, but she has
never used it for strategic planning, so she asked you to do some research. First,
you navigate to the strategic planning section, where you can enter planning
statements such as assumptions, goals, objectives, critical success factors, and
others. Planning statements also can document strengths, weaknesses,
opportunities, and threats, as shown in Figure 2-6. After you visit the Help section to
learn more about the strategic planning features, you feel confident that you can
work effectively with this powerful tool. When you present your results to Sally, she
seems pleased. Because the term is new to you, you ask her what critical success
factors are, and she replies that critical success factors are vital objectives that
must be achieved for the company to fulfill its mission.
Systems Request
Systems Request Concentrations
STRONGER CONTROLS A system must have effective controls to ensure that data is
secure and accurate. Some common security controls include passwords, various
levels of user access, and encryption, or coding of data to keep it safe from
unauthorized users. Hardware-based security controls include biometric devices
that can identify a person by a retina scan or by mapping a facial pattern. A new
biometric tool scans hands, rather than faces. The technology uses infrared
scanners that create images with thousands of measurements of hand and finger
characteristics, as shown in Figure 2-9. In addition to being secure, data also must
be accurate.
Controls should minimize data entry errors whenever possible. For example, if a
user enters an invalid customer number, the order processing system should reject
the entry immediately and prompt the user to enter a valid number. Data entry
controls must be effective without being excessive. If a system requires users to
confirm every item with an “Are you sure? Y/N” message, internal users and
customers might complain that the system is not user-friendly
PROJECT MANAGEMENT
EVALUATION OF SYSTEMS REQUESTS
1. Systems Request Forms
2. Systems Review Committee
3. OVERVIEW OF FEASIBILITY
1. Operational Feasibility
2. Technical Feasibility
3. Economic Feasibility
4. Schedule Feasibility
Factors that Affect Priority
When assessing a project’s priority, a systems analyst should consider the
following:
• Will the proposed system reduce costs? Where? When? How? How much?
• Will the system increase revenue for the company? Where? When? How? How
much?
• Will the systems project result in more information or produce better results?
How? Are the results measurable?
• Will the system serve customers better?
• Will the system serve the organization better?
• Can the project be implemented in a reasonable time period? How long will the
results last?
• Are the necessary financial, human, and technical resources available?
Some analysts find it helpful to define project scope by creating a list with
sections called Must Do, Should Do, Could Do, and Won’t Do.
“What else do
you think I should know about the system?” or “Is there any other relevant
information
that we have not discussed?”
Maintaining a Schedule
Maintaining a project schedule can be challenging, and most projects run into
at least some problems or delays. By monitoring and controlling the work, the
project manager tries to anticipate problems, avoid them or minimize their
impact, identify potential solutions, and select the best way to solve the
problem. The better the original plan, the easier it will be to control the
project. If clear, verifiable milestones exist, it will be simple to determine if
and when those targets are achieved. If enough milestones and frequent
checkpoints exist, problems will be detected rapidly. A project that is planned
and scheduled with PERT/CPM can be tracked and controlled using these
same techniques. As work continues, the project manager revises the plan to
record actual times for completed tasks and revises times for tasks that are
not yet finished. Project managers spend most of their time tracking the tasks
along the critical path, because delays in those tasks have the greatest
potential to delay or jeopardize the project. Other tasks cannot be ignored,
however. For example, suppose that a task not on the critical path takes too
long and depletes the allotted slack time. At that point, the task actually
becomes part of the critical path, and any further delay will push back the
overall project.
REPORTING
Project Status Meetings
Project Status Reports
A project is in trouble, but the project manager is reluctant to report the
problems.The case highlights important ethical issues that often arise in this
situation. A project manager must report regularly to his or her immediate
supervisor, upper management, and users. Although a progress report might
be given verbally to an immediate supervisor, reports to management and
users usually are written. Gantt charts often are included in progress reports
to show project status graphically. Deciding how to handle potential problems
can be difficult. At what point should you inform management about the
possibility of cost overruns, schedule delays, or technical problems? At one
extreme is the overly cautious project manager who alerts management to
every potential snag and slight delay. The danger here is that the manager
loses credibility over a period of time, and management might ignore
potentially serious situations. At the other extreme is the project manager
who tries to handle all situations single-handedly and does not alert
management until a problem is serious. By the time management learns of
the problem, little time might remain in which to react or devise a solution. A
project manager’s best course of action lies somewhere between the two
extremes, but is probably closer to the first. If you are unsure of the
consequences, you should be cautious and warn management about the
possibility of a problem. When you report the situation, you also should
explain what you are doing to handle and monitor the problem. If you believe
the situation is beyond your control, you might want to suggest possible
actions that management can take to resolve the situation. Most managers
recognize that problems do occur on most projects; it is better to alert
management sooner rather than later.
Budget Issues
Schedule Issues
JAD Model
JAD Advantages and Disadvantages
Compared with traditional methods, JAD is more expensive and can be cumbersome
if
the group is too large relative to the size of the project. Many companies find,
however,
that JAD allows key users to participate effectively in the requirements modeling
process.
When users participate in the systems development process, they are more likely to
feel a
sense of ownership in the results, and support for the new system. When properly
used,
JAD can result in a more accurate statement of system requirements, a better
understanding
of common goals, and a stronger commitment to the success of the new
system.
RAD Model
RAD relies heavily on prototyping and user involvement. The RAD process
allows
users to examine a working model as early as possible, determine if it meets their
needs,
and suggest necessary changes. Based on user input, the prototype is modified and
the
interactive process continues until the system is completely developed and users
are satisfied.
The project team uses CASE tools to build the prototypes and create a continuous
stream of documentation.
Cutover Tasks
• Data conversion
• Full-scale testing
• System changeover
• User training
CUTOVER The cutover phase resembles the final tasks in the SDLC
implementation
phase, including data conversion, testing, changeover to the new system, and user
training.
Compared with traditional methods, the entire process is compressed. As a result,
the new system is built, delivered, and placed in operation much sooner.
Agile Model
LOGICAL MODEL
DFD
Rules and Regulations to follow while developing DFD
1. Context Diagram
2. DFD
1. Diagram 1, 2 .. etc
Process
Functional Primitive Process
When you create a set of DFDs for a system, you break the
processing logic down into smaller units, called functional
primitives, that programmers will use to develop code. A
functional primitive is a process that consists of a single
function that is not exploded further.
Levelling
Levelling is also called as Exploding, Partitioning,
Decomposing
Balancing
External Entities
Data Links
Data Stores
Data Dictionary
LOGICAL MODEL
Cost Classifications
Benefit classifications
Request for Proposal OR Request for Quotation