System an Chap-1

System an Chap-1
please give me answer simply like use easy sentence words so that i can easily understand okay-
when i need to answer give you something to know something any topic
Got it! I’ll keep answers clear and simple for you. Let me know anytime if you'd like me to simplify
further.
Need for Systems Analysis and Design

Systems analysis and design, as performed by systems analysts, seeks to understand what humans
need to analyze data input or data flow systematically, process or transform data, store data, and
out
put information in the context of a particular organization or enterprise. By doing thorough
analysis,
analysts seek to identify and solve the right problems. Furthermore, systems analysis and design is
used to analyze, design, and implement improvements in the support of users and the functioning
of
businesses that can be accomplished through the use of computerized information systems.
Installing a system without proper planning leads to great user dissatisfaction and frequently
causes the system to fall into disuse. Systems analysis and design lends structure to the analy
sis and design of information systems, a costly endeavor that might otherwise have been done
in a haphazard way. It can be thought of as a series of processes systematically undertaken to
improve a business through the use of computerized information systems. Systems analysis and
design involves working with current and eventual users of information systems to support them
in working with technologies in an organizational setting.
User involvement throughout a systems project is critical to the successful development of
computerized information systems. Systems analysts, whose roles in the organization are dis
cussed next, are the other essential component in developing useful information systems.
Users are moving to the forefront as software development teams become more interna
tional in their composition. This means that there is more emphasis on working with software
users; on performing analysis of their business, problems, and objectives; and on communicating
the analysis and design of the planned system to all involved.
New technologies also are driving the need for systems analysis. Ajax (Asynchronous
JavaScript and XML) is not a new programming language but a technique that uses existing lan
guages to make web pages function more like a traditional desktop application program. Systems
analysts will increasingly need to build and redesign web pages that utilize Ajax technologies.
New programming languages, such as the open source Web framework Ruby on Rails (“Rails”
for short), which is a combination programming language and code generator for creating Web
applications, will require more analysis.
Printed using Save ChatGPT as PDF, powered by PDFCrowd HTML to PDF API. 1/18
Need for Systems Analysis and Design (Simplified)
Systems analysis and design is the process of understanding what people in an organization need to
handle data. It helps make sure data flows smoothly, is processed properly, stored securely, and turned
into useful information. This process is done by systems analysts, who study and improve how a
business or organization uses information systems.
Key points:
1. Purpose: Systems analysis and design aim to understand problems and find the best solutions. It
improves user support and business operations through information systems.
2. Importance of Planning: Installing a system without good planning can lead to user
dissatisfaction and cause the system to fail. Proper analysis and design provide structure and
prevent mistakes that can happen if things are done randomly.
3. User Involvement: Users are very important throughout the project. They give feedback and help
make sure the system meets their needs. As development teams become more international,
working closely with users has become even more crucial.
4. Role of Systems Analysts: Systems analysts are responsible for studying the business, identifying
problems, understanding goals, and creating the design of the system.
5. Adapting to New Technologies: New web technologies like Ajax and Ruby on Rails are changing
how web pages and applications work. Systems analysts must keep up with these technologies and
adjust designs to fit new trends.
In summary, systems analysis and design are necessary to create effective, user-friendly information
systems that support business goals, improve efficiency, and keep up with technology changes.
Roles of a Systems Analyst

A systems analyst systematically assesses how users interact with technology and how businesses
function by examining the inputting and processing of data and the outputting of information with
the intent of improving organizational processes. Many improvements involve better support of
users’ work tasks and business functions through the use of computerized information systems.
This
definition emphasizes a systematic, methodical approach to analyzing—and potentially improving—
what is occurring in the specific context experienced by users and created by a business.
Our definition of a systems analyst is necessarily broad. An analyst must be able to work
with people of all descriptions and be experienced in working with computers. An analyst plays
many roles, sometimes balancing several at the same time. The three primary roles of a systems
analyst are consultant, supporting expert, and agent of change.
Systems Analyst as Consultant
A systems analyst frequently acts as a systems consultant to humans and their businesses and,
thus, may be hired specifically to address information systems issues within a business. Such
hiring can be an advantage because outside consultants can bring with them a fresh perspective
that other people in an organization do not possess. It also means that outside analysts are at a
disadvantage because an outsider can never know the true organizational culture. As an outside
consultant, you will rely heavily on the systematic methods discussed throughout this text to
analyze and design appropriate information systems for users working in a particular business.
In addition, you will rely on information systems users to help you understand the organizational
culture from others’ viewpoints.
Systems Analyst as Supporting Expert
Another role that you may be required to play is that of supporting expert within a business for
which you are regularly employed in some systems capacity. In this role, an analyst draws on
professional expertise concerning computer hardware and software and their uses in the business
This work is often not a full-blown systems project, but rather it entails a small modification or
decision affecting a single department.
As the supporting expert, you are not managing the project; you are merely serving as a
resource for those who are. If you are a systems analyst employed by a manufacturing or service
organization, many of your daily activities may be encompassed by this role.
Systems Analyst as Agent of Change
The most comprehensive and responsible role that the systems analyst takes on is that of an agent
of change, whether internal or external to the business. As an analyst, you are an agent of change
whenever you perform any of the activities in the systems development life cycle (discussed in the
next section) and are present and interacting with users and the business for an extended period
(from two weeks to more than a year). An agent of change can be defined as a person who serves as
a catalyst for change, develops a plan for change, and works with others in facilitating that change.
Your presence in the business changes it. As a systems analyst, you must recognize this fact
and use it as a starting point for your analysis. Hence, you must interact with users and manage
ment (if they are not one and the same) from the very beginning of your project. Without their
help, you cannot understand what they need to support their work in the organization, and real
change cannot take place.
4
Part 1 • SyStemS analySiS FundamentalS
If change (that is, improvements to the business that can be realized through information
systems) seems warranted after analysis, the next step is to develop a plan for change along with
the people who must enact the change. Once a consensus is reached on the change that is to be
made, you must constantly interact with those who are changing.
As a systems analyst acting as an agent of change, you advocate a particular avenue of
change involving the use of information systems. You also teach users the process of change
because changes in the information system do not occur independently; rather, they cause
changes in the rest of the organization as well.
Qualities of a Systems Analyst
From the foregoing descriptions of the roles the systems analyst plays, it is easy to see that a suc
cessful systems analyst must possess a wide range of qualities. Many different kinds of people
are systems analysts, so any description is destined to fall short in some way. There are some
qualities, however, that most systems analysts seem to display.
Above all, an analyst is a problem solver. He or she is a person who views the analysis
of problems as a challenge and who enjoys devising workable solutions. When necessary, an
analyst must be able to systematically tackle the situation at hand through skillful applica
tion of tools, techniques, and experience. An analyst must also be a communicator capable of
relating meaningfully to other people over extended periods of time. Systems analysts need
to be able to understand humans’ needs in interacting with technology, and they need enough
computer experience to program, to understand the capabilities of computers, to glean infor
mation requirements from users, and to communicate what is needed to programmers. They
also need to possess strong personal and professional ethics to help them shape their client
relationships.
A systems analyst must be a self-disciplined, self-motivated individual who is able to man
age and coordinate other people, as well as innumerable project resources. Systems analysis is a
demanding career, but, in compensation, an ever-changing and always challenging one.
Roles and Qualities of a Systems Analyst (Simplified)
A systems analyst studies how people in a business use technology. Their goal is to improve processes,
make tasks easier, and help the organization work better by using information systems. Here’s a
breakdown of their main roles and qualities:
Key Roles of a Systems Analyst:
1. Consultant:
Acts as an outside advisor.
Hired to solve specific information system problems in a business.
Brings a fresh view but may not fully know the company’s culture.
2. Supporting Expert:
Provides advice based on technical knowledge.
Assists with small changes or decisions in the business.
Acts as a resource but does not manage projects directly.
3. Agent of Change:
Works to bring positive changes to the organization.
Helps design and implement changes in the business processes.
Engages with users and management to understand their needs and develop a change plan.
Teaches users about new systems and how they’ll impact other areas.
Qualities of a Successful Systems Analyst:
1. Problem Solver: Enjoys finding solutions to problems and applies tools and experience effectively.
2. Communicator: Can talk and relate well with others, understanding both people’s needs and
technical details.
3. Technically Skilled: Has enough computer knowledge to understand systems, gather
requirements, and convey needs to programmers.
4. Ethical: Practices strong ethics to build trustworthy relationships with clients.
5. Self-Disciplined: Stays motivated, manages people, and coordinates resources effectively.
In summary, a systems analyst plays multiple roles to help a business work more efficiently, adapts to
new challenges, and needs a mix of technical, interpersonal, and ethical qualities to succeed.
The Systems Development Life Cycle

Throughout this chapter we have referred to the systematic approach analysts take to the anal
ysis and design of information systems. Much of this is embodied in what is called the systems
development life cycle (SDLC). The SDLC is a phased approach to analysis and design which
holds that systems are best developed through the use of a specific cycle of analyst and user
activities.
Analysts disagree on exactly how many phases there are in the SDLC, but they generally
laud its organized approach. Here we have divided the cycle into seven phases, as shown in
Figure 1.1. Although each phase is presented discretely, it is never accomplished as a separate
step. Instead, several activities can occur simultaneously, and activities may be repeated.
1.Identifying problems,
opportunities, and
objectives -> 2.Determining human
information
requirements ->3.Analyzing
system needs ->4.Designing the
recommended
system ->5Developing and
documenting
software ->6.Testing and
maintaining
the system ->7mplementing
and evaluating
the system
The Systems Development Life Cycle (SDLC)

The Systems Development Life Cycle (SDLC) is a structured approach for developing information
systems in phases. It helps systems analysts and users to work through each step carefully to create the
best solution. Here, we break down the seven phases of the SDLC:
1. Identifying Problems, Opportunities, and Objectives:

Identify issues or areas for improvement in the current system.
Define goals and what the system should achieve.
2. Determining Human Information Requirements:
Understand the information needs of the users.
Gather input from users to know what they need from the system.
3. Analyzing System Needs:
Look into what the system needs to function well.
Analyze requirements to see if changes or new solutions are necessary.
4. Designing the Recommended System:
Create a detailed design for the new or improved system.
Plan out how the system will work and look.
5. Developing and Documenting Software:
Write the code for the system and document how it works.
This is where the actual system is built.
6. Testing and Maintaining the System:
Test the system for errors and fix any issues.
Ensure the system works smoothly and update it as needed.
7. Implementing and Evaluating the System:
Launch the system for users and evaluate its performance.
Make sure it meets users’ needs and improve it based on feedback.
These phases often overlap and repeat to ensure a thorough, successful system development.
Identifying Problems, Opportunities, and Objectives
In this first phase of the systems development life cycle, an analyst is concerned with correctly
identifying problems, opportunities, and objectives. This stage is critical to the success of the rest
of the project because no one wants to waste subsequent time addressing the wrong problem.
The first phase requires that the analyst look honestly at what is occurring in a business.
Then, together with other organizational members, the analyst pinpoints problems. Often oth
ers will bring up these problems, and they are the reason the analyst was initially called in.
Opportunities are situations that the analyst believes can be improved through the use of comput
erized information systems. Seizing opportunities may allow the business to gain a competitive
edge or set an industry standard.
Identifying objectives is also an important component of the first phase. The analyst must
f
irst discover what the business is trying to do. Then the analyst will be able to see whether some
aspect of information systems applications can help the business reach its objectives by address
ing specific problems or opportunities.
The people involved in the first phase are the users, analysts, and systems managers coordi
nating the project. Activities in this phase consist of interviewing user management, summarizing
6
the knowledge obtained, estimating the scope of the project, and documenting the results. The
output of this phase is a feasibility report that contains a problem definition and summarizes the
objectives. Management must then make a decision on whether to proceed with the proposed
project. If the user group does not have sufficient funds in its budget or if it wishes to tackle unre
lated problems, or if the problems do not require a computer system, a different solution may be
recommended, and the systems project does not proceed any further.
Determining Human Information Requirements
The next phase the analyst enters involves determining the human needs of the users involved,
using a variety of tools to understand how users interact in the work context with their current
information systems. The analyst will use interactive methods such as interviewing, sampling
and investigating hard data, and using questionnaires, along with unobtrusive methods, such as
observing decision makers’ behavior and their office environments, and all-encompassing meth
ods, such as prototyping.
The analyst will use these methods to pose and answer many questions concerning HCI,
including questions such as, “What are the users’ physical strengths and limitations?” In other
words, “What needs to be done to make the system audible, legible, and safe?” “How can the
new system be designed to be easy to use, learn, and remember?” “How can the system be made
pleasing or even fun to use?” “How can the system support a user’s individual work tasks and
make them more productive in new ways?”
In the information requirements phase of the SDLC, the analyst is striving to understand
what information users need to perform their jobs. At this point, the analyst is examining how
to make the system useful to the people involved. How can the system better support individual
tasks that need to be done? What new tasks are enabled by the new system that users were
unable to do without it? How can the new system be created to extend a user’s capabilities
beyond what the old system provided? How can the analyst create a system that is rewarding
for workers to use?
The people involved in this phase are the analysts and users, typically operations managers
and operations workers. The systems analyst needs to know the details of current system func
tions: the who (the people who are involved), what (the business activity), where (the environ
ment in which the work takes place), when (the timing), and how (how the current procedures
are performed) of the business under study. The analyst must then ask why the business uses the
current system. There may be good reasons for doing business using the current methods, and
these should be considered when designing any new system.
Agile development is an object-oriented approach (OOA) to systems development that
includes a method of development (including generating information requirements) as well as
software tools. In this text, it is paired with prototyping in Chapter 6. (There is more about
object-oriented approaches in Chapter 10.)
If the reason for current operations is that “it’s always been done that way,” however, the
analyst may wish to improve on the procedures. At the completion of this phase, the analyst
should understand how users accomplish their work when interacting with a computer and begin
to know how to make the new system more useful and usable. The analyst should also know how
the business functions and have complete information on the people, goals, data, and procedures
involved.
Analyzing System Needs
The next phase that the systems analyst undertakes involves analyzing system needs. Again,
special tools and techniques help the analyst make requirement determinations. Tools such
as data flow diagrams (DFDs) to chart the input, processes, and output of the business’s
functions, or activity diagrams or sequence diagrams to show the sequence of events, illus
trate systems in a structured, graphical form. From data flow, sequence, or other diagrams,
a data dictionary is developed that lists all the data items used in the system, as well as their
specifications.
During this phase the systems analyst also analyzes the structured decisions made. Structured
decisions are those for which the conditions, condition alternatives, actions, and action rules
can be determined. There are three major tools for analyzing structured decisions: structured
English, decision tables, and decision trees. At this point in the SDLC, the systems analyst prepares a
systems proposal that summarizes
what has been found out about the users, usability, and usefulness of current systems; provides
cost
benefit analyses of alternatives; and makes recommendations on what (if anything) should be done.
If one of the recommendations is acceptable to management, the analyst proceeds along that
course.
Each systems problem is unique, and there is never just one correct solution. The manner in which a
recommendation or solution is formulated depends on the individual qualities and professional
train
ing of each analyst and the analyst’s interaction with users in the context of their work environment.
Designing the Recommended System
In the design phase of the SDLC, the systems analyst uses the information collected earlier to
accomplish the logical design of the information system. The analyst designs procedures for
users to help them accurately enter data so that data going into the information system are cor
rect. In addition, the analyst provides for users to complete effective input to the information
system by using techniques of good form and web page or screen design.
Figure 1.MAC
Running Windows on a Mac using virtualization called VM Fusion. (Screenshot of Apple
Desktop. Reprinted with permission of Apple Inc.; Screenshot from YOJIMBO. Copyright
© 2012 by Bare Bones Software, Inc. Reprinted by permission; Screenshot from www
.thekendalls.org. Copyright © by Kenneth and Julie Kendall. Reprinted with permission.)
At home and in our visits to university campuses and businesses around the world, we’ve noticed
that students and organizations are increasingly showing an interest in Macs. Therefore, we thought
it would add a little bit of interest to show some of the Mac options available to a systems designer.
At the time we’re writing this book, about one out of seven personal computers purchased in the
United States is a Mac. Macs are quality Intel-based machines that run under a competent operating
system and can also run Windows, so in effect, everything that can be done on a PC can be done on
a Mac. One way to run Windows is to boot directly into Windows (once it’s installed); another is to
use virtualization, using software such as VM Fusion, which is shown in Figure 1.MAC.
Adopters of Macs have cited many reasons for using Macs, including better security built into
the Mac operating system, intelligent backup using the built-in Time Machine, the multitude of
applications already included, the reliability of setup and networking, and the ability to sync Macs
with other Macs and iPhones. The most compelling reason, we think, is the design itself.
MAC AppEAL
8
Part of the logical design of the information system is devising the HCI. The interface con
nects the user with the system and is thus extremely important. The user interface is designed with
the help of users to make sure that the system is audible, legible, and safe, as well as attractive and
enjoyable to use. Examples of physical user interfaces include a keyboard (to type in questions
and answers), onscreen menus (to elicit user commands), and a variety of graphical user interfaces
(GUIs) that use a mouse or touch screen.
The design phase also includes designing databases that will store much of the data needed
by decision makers in the organization. Users benefit from a well-organized database that is logi
cal to them and corresponds to the way they view their work. In this phase the analyst also works
with users to design output (either onscreen or printed) that meets their information needs.
Finally, the analyst must design controls and backup procedures to protect the system and
the data, and to produce program specification packets for programmers. Each packet should
contain input and output layouts, file specifications, and processing details; it may also include
decision trees or tables, Unified Modeling Language (UML) or data flow diagrams, and the
names and functions of any prewritten code that is either written in-house or using code or other
class libraries.
Developing and Documenting Software
In the fifth phase of the SDLC, the analyst works with programmers to develop any original
software that is needed. During this phase the analyst works with users to develop effective
documentation for software, including procedure manuals, online help, and websites featuring
frequently asked questions (FAQs) or Read Me files shipped with new software. Because users
are involved from the beginning, phase documentation should address the questions they have
raised and solved jointly with the analyst. Documentation tells users how to use software and
what to do if software problems occur.
Programmers have a key role in this phase because they design, code, and remove syntac
tical errors from computer programs. To ensure quality, a programmer may conduct either a
design or a code walkthrough, explaining complex portions of the program to a team of other
programmers.
Testing and Maintaining the System
Before an information system can be used, it must be tested. It is much less costly to catch prob
lems before the system is signed over to users than after. Some of the testing is completed by
programmers alone, some of it by systems analysts in conjunction with programmers. A series
of tests to pinpoint problems is run first with sample data and eventually with actual data from
the current system. Often test plans are created early in the SDLC and are refined as the project
progresses.
Maintenance of the system and its documentation begins in this phase and is carried out
routinely throughout the life of the information system. Much of the programmer’s routine work
consists of maintenance, and businesses spend a great deal of money on maintenance. Some
maintenance, such as program updates, can be done automatically via a vendor site on the Web.
Many of the systematic procedures the analyst employs throughout the SDLC can help ensure
that maintenance is kept to a minimum.
Implementing and Evaluating the System
In this last phase of systems development, the analyst helps implement the information system.
This phase involves training users to handle the system. Vendors do some training, but oversight
of training is the responsibility of the systems analyst. In addition, the analyst needs to plan for
a smooth conversion from the old system to the new one. This process includes converting files
from old formats to new ones or building a database, installing equipment, and bringing the new
system into production.
Evaluation is included as part of this final phase of the SDLC mostly for the sake of discus
sion. Actually, evaluation takes place during every phase. A key criterion that must be satisfied
is whether the intended users are indeed using the system.
It should be noted that systems work is often cyclical. When an analyst finishes one phase of
systems development and proceeds to the next, the discovery of a problem may force the analyst
to return to the previous phase and modify the work done there.
Here’s a summary of each phase in the Systems Development Life Cycle (SDLC):
1. Identifying Problems, Opportunities, and Objectives:

The systems analyst and organizational members pinpoint issues, recognize areas for
improvement, and define goals.
This phase includes interviewing management, summarizing findings, estimating project
scope, and creating a feasibility report. Management decides whether to proceed based on
this report.
2. Determining Human Information Requirements:
Analysts gather data on user needs through interviews, questionnaires, and observation to
understand how users interact with current systems.
The goal is to design a system that supports tasks effectively, meets usability needs, and
provides new capabilities.
3. Analyzing System Needs:
Using tools like data flow diagrams (DFDs) and sequence diagrams, the analyst maps out the
system's requirements, structured decisions, and data definitions.
A systems proposal is created, summarizing current system functionality, cost-benefit
analyses, and recommendations for improvements.
4. Designing the Recommended System:
The analyst creates a logical design for the system, focusing on user-friendly interfaces,
accurate data entry procedures, and output that meets information needs.
Database design, controls, backup procedures, and program specifications are also defined in
this phase.
5. Developing and Documenting Software:
The analyst and programmers work to develop original software, if necessary, and create
comprehensive documentation, including FAQs and user guides.
Program quality is assured through walkthroughs, where programmers present complex
code segments for review.
6. Testing and Maintaining the System:
The system is tested with sample and actual data to identify and resolve issues. Maintenance,
such as updates and bug fixes, becomes routine throughout the system's life.
Thorough testing early on helps reduce costly maintenance in the future.
7. Implementing and Evaluating the System:
The system is introduced to users, and training is provided. The analyst oversees conversion
from the old to the new system and addresses any file formatting changes.
Evaluation of the system occurs continuously, focusing on whether the system meets user
needs and expectations.
Each phase is interdependent, and changes in one phase can lead to adjustments in others, making
SDLC a flexible, iterative process.
The Agile Approach

Although this text tends to focus on SDLC, the most widely used approach in practice, at
times an analyst will recognize that his or her organization could benefit from an alternative
approach. Perhaps a systems project using a structured approach has recently failed, or per
haps the organizational subcultures, composed of several different user groups, seem more in
step with an alternative method. We cannot do justice to these methods in a small space; each
deserves and has inspired its own books and research. By mentioning these approaches here,
however, we hope to help you become aware that under certain circumstances, your organiza
tion may want to consider an alternative or a supplement to structured analysis and design and
to the SDLC.
The agile approach is a software development approach based on values, principles, and
core practices. The four values are communication, simplicity, feedback, and courage. We rec
ommend that systems analysts adopt these values in all projects they undertake, not just when
adopting the agile approach.
In order to finish a project, adjustments often need to be made in project management. In
Chapter 6 we will see that agile methods can ensure successful completion of a project by adjust
ing the important resources of time, cost, quality, and scope. When these four control variables
are properly included in the planning, there is a state of balance between the resources and the
activities needed to complete the project.
Taking development practices to the extreme is most noticeable when one pursues practices
that are unique to agile development. In Chapter 6 we discuss four core agile practices: short
releases, the 40-hour workweek, hosting an onsite customer, and using pair programming. At
f
irst glance these practices appear extreme, but as you will see, we can learn some important
lessons from incorporating many of the values and practices of the agile approach into systems
analysis and design projects.
Developmental Process for an Agile Project
Activities and behaviors shape the way development team members and customers act during
the development of an agile project. Two words that characterize a project done with an agile
approach are interactive and incremental. By examining Figure 1.5, we can see that there are
f
ive distinct stages: exploration, planning, iterations to the first release, productionizing, and
maintenance. Notice that the three red arrows that loop back into the “Iterations” box symbolize
incremental changes created through repeated testing and feedback that eventually lead to a sta
ble but evolving system. Also note that there are multiple looping arrows that feed back into the
productionizing phase. These symbolize that the pace of iterations is increased after a product
is released. The red arrow is shown leaving the maintenance stage and returning to the planning
stage, so that there is a continuous feedback loop involving customers and the development team
as they agree to alter the evolving system.
Exploration. During exploration, you will explore your environment, asserting your conviction
that the problem can and should be approached with agile development, assemble the team, and
assess team member skills. This stage will take anywhere from a few weeks (if you already know
your team members and technology) to a few months (if everything is new). You also will be
actively examining potential technologies needed to build the new system. During this stage you
should practice estimating the time needed for a variety of tasks. In exploration, customers also
are experimenting with writing user stories. The point is to get the customer to refine a story
enough so that you can competently estimate the amount of time it will take to build the solution
into the system you are planning. This stage is all about adopting a playful and curious attitude
toward the work environment, its problems, technologies, and people.
. . . and increase
the pace of
iterations after
the product is
released.
planning. The next stage of the agile development process is called planning. In contrast
to the first stage, planning may take only a few days to accomplish. In this stage you and
your customers agree on a date anywhere from two months to half a year from the current
date to deliver solutions to their most pressing business problems (you will be addressing
the smallest, most valuable set of stories). If your exploration activities were sufficient, this stage
should be very short.
The entire agile planning process has been characterized using the idea of a planning game,
as devised by Kent Beck, the father of Extreme Programming. The planning game spells out
rules that can help formulate the agile development team’s relationship with their business cus
tomers. Although the rules form an idea of how you want each party to act during development,
they are not meant as a replacement for a relationship. They are a basis for building and main
taining a relationship.
So, we use the metaphor of a game. To that end we talk in terms of the goal of the game,
the strategy to pursue, the pieces to move, and the players involved. The goal of the game is to
maximize the value of the system produced by the agile team. In order to figure the value, you
have to deduct costs of development, and the time, expense, and uncertainty taken on so that the
development project can go forward.
The strategy pursued by the agile development team is always one of limiting uncertainty
(downplaying risk). To do that they design the simplest solution possible, put the system into
production as soon as possible, get feedback from the business customer about what’s work
ing, and adapt their design from there. Story cards become the pieces in the planning game that
briefly describe the task, provide notes, and provide an area for task tracking.
There are two main players in the planning game: the development team and the business
customer. Deciding which business group in particular will be the business customer is not
ChaPter 1 • SyStemS, roleS, and develoPment methodologieS
13
always easy because the agile process is an unusually demanding role for the customer to play.
Customers decide what the development team should tackle first. Their decisions will set priori
ties and check functionalities throughout the process.
itErations to thE First rElEasE. The third stage in the agile development process is composed
of iterations to the first release. Typically these are iterations (cycles of testing, feedback, and
change) of about three weeks in duration. You will be pushing yourself to sketch out the entire
architecture of the system, even though it is just in outline or skeletal form. One goal is to run
customer-written functional tests at the end of each iteration. During the iterations stage you
should also question whether the schedule needs to be altered or whether you are tackling too
many stories. Make small rituals out of each successful iteration, involving customers as well as
developers. Always celebrate your progress, even if it is small, because this is part of the culture
of motivating everyone to work extremely hard on the project.
productionizing. Several activities occur during the productionizing phase. In this phase the
feedback cycle speeds up so that rather than receiving feedback for an iteration every three
weeks, software revisions are being turned around in one week. You may institute daily briefings
so everyone knows what everyone else is doing. The product is released in this phase, but it may
be improved by adding other features. Getting a system into production is an exciting event.
Make time to celebrate with your teammates and mark the occasion. One of the keys to the agile
approach, which we heartily embrace, is that it is supposed to be fun to develop systems!
MaintEnancE. Once a system has been released, it needs to be kept running smoothly. New
features may be added, riskier customer suggestions may be considered, and team members may
be rotated on or off the team. The attitude you take at this point in the developmental process is
more conservative than at any other time. You are now in a “keeper of the flame” mode rather
than the playful one you experienced during exploration.
The Agile approach to software development is distinct from the traditional System Development Life
Cycle (SDLC) in that it emphasizes adaptability and iterative progress. Agile projects are designed to be
interactive and incremental, with a strong focus on values like communication, simplicity, feedback, and
courage. Here's a breakdown of the Agile process:
1. Exploration: This initial phase involves building a team, assessing team skills, and experimenting
with user stories and potential technologies. The goal is to clarify and define the scope of the
project with a flexible, experimental mindset.
2. Planning: In this short phase, the team and customers agree on a timeline for delivering the first
set of solutions. Agile planning is likened to a "game" where the development team and business
customers collaborate to prioritize tasks and manage risk.
3. Iterations to the First Release: Development takes place in cycles, typically lasting about three
weeks. Each cycle includes testing, feedback, and refinement. Customer functional tests are often
run at the end of each iteration to ensure the project aligns with user needs.
4. Productionizing: The feedback loop intensifies, with updates occurring weekly. Daily briefings help
maintain synchronization across the team. The system is released, but further enhancements may
be added based on user feedback.
5. Maintenance: Once released, the system is kept operational and updated with new features as
needed. The team's role shifts to maintaining stability, addressing risks conservatively, and
managing ongoing customer requirements.
Agile's adaptive methodology suits projects that require frequent adjustments, prioritizing collaboration
and continual improvement.
Object-Oriented Systems Analysis and Design
Object-oriented (O-O) analysis and design is an approach that is intended to facilitate the devel
opment of systems that must change rapidly in response to dynamic business environments.
Chapter 10 helps you understand what object-oriented systems analysis and design is, how it
differs from the structured approach of the SDLC, and when it may be appropriate to use an
object-oriented approach.
Object-oriented techniques often work well in situations in which complicated informa
tion systems are undergoing continuous maintenance, adaptation, and redesign. Object-oriented
approaches use the industry standard for modeling object-oriented systems, called Unified
Modeling Language (UML), to break down a system into a use case model.
Object-oriented programming differs from traditional procedural programming in that it
examines objects that are part of a system. Each object is a computer representation of some
actual thing or event. Objects may be customers, items, orders, and so on. Objects are repre
sented by and grouped into classes that are optimal for reuse and maintainability. A class defines
the set of shared attributes and behaviors found in each object in the class.
The phases in UML are similar to those in the SDLC. Since those two methods share rigid
and exacting modeling, they happen in a slower, more deliberate pace than the phases of agile
modeling. An analyst goes through problem and identification phases, an analysis phase, and a
design phase, as shown in Figure 1.6.
Although much of the specifics are discussed in Chapters 2 and 10, the following steps give
a brief description of the UML process:
1. Define the use case model.
In this phase the analyst identifies the actors and the major events initiated by the
actors. Often the analyst will start by drawing a diagram with stick figures representing
the actors and arrows showing how the actors relate. This is called a use case diagram
(Chapter 2), and it represents the standard flow of events in the system. Then an analyst
typically writes up a use case scenario (Chapter 2), which describes in words the steps that
are normally performed. 2. During the systems analysis phase, begin drawing UML diagrams.
In the second phase (Chapter 10), the analyst draws activity diagrams, which illustrate
all the major activities in the use case. In addition, the analyst creates one or more sequence
diagrams for each use case, which show the sequence of activities and their timing. This is an
opportunity to go back and review the use cases, rethink them, and modify them if necessary.
3. Continuing in the analysis phase, develop class diagrams.
The nouns in the use cases are objects that can potentially be grouped into classes. For
example, every automobile is an object that shares characteristics with other automobiles.
Together they make up a class.
4. Still in the analysis phase, draw statechart diagrams.
The class diagrams are used to draw statechart diagrams, which help in understanding
complex processes that cannot be fully derived by the sequence diagrams. The statechart
diagrams are extremely useful in modifying class diagrams, so the iterative process of
UML modeling continues.
5. Begin systems design by modifying the UML diagrams. Then complete the specifications.
Systems design means modifying the existing system, and that implies modifying the
diagrams drawn in the previous phase. These diagrams can be used to derive classes, their
attributes, and methods (methods are simply operations). An analyst will need to write class
specifications for each class, including the attributes, methods, and their descriptions. The
analyst will also develop method specifications that detail the input and output requirements
for each method, along with a detailed description of the internal processing of the method.
6. Develop and document the system.
UML is, of course, a modeling language. An analyst may create wonderful models, but
if the system isn’t developed, there is not much point in building models. Documentation
is critical. The more complete the information you provide the development team through
documentation and UML diagrams, the faster the development and the more solid the final
production system.
ChaPter 1 • SyStemS, roleS, and develoPment methodologieS
15
Object-oriented methodologies often focus on small, quick iterations of development, some
times called the spiral model. Analysis is performed on a small part of the system, usually starting
with a high-priority item or perhaps the item that has the greatest risk. This is followed by design
and implementation. The cycle is repeated with analysis of the next part, design, and some
implementation, and this is repeated until the project is complete. Reworking diagrams and the
components themselves is normal. UML is a powerful modeling tool that can greatly improve
the quality of your systems analysis and design and the final product.
Object-Oriented (O-O) Systems Analysis and Design focuses on building adaptable systems that respond
well to changing business needs. This approach uses Unified Modeling Language (UML), an industry-
standard modeling language, to visually represent the components of a system and their relationships.
The steps of O-O systems analysis and design are structured similarly to SDLC but typically progress at a
more gradual pace than Agile, focusing on careful modeling and design.
Key Steps in the UML Process:
1. Define the Use Case Model:

Identify actors (users or other systems) and main events they initiate.
Create a Use Case Diagram to show actor interactions and describe each event in a Use Case
Scenario.
2. Systems Analysis Phase - Draw UML Diagrams:
Draw Activity Diagrams to capture major activities within each use case.
Create Sequence Diagrams for each use case to show activity flow and timing, allowing the
team to review and refine use cases.
3. Develop Class Diagrams:
Analyze nouns from use cases to identify objects and group them into Classes based on
shared characteristics (e.g., “automobile” as a class).
4. Draw Statechart Diagrams:
Statechart Diagrams complement class diagrams by visualizing complex processes not
captured in sequence diagrams, supporting iterative refinement.
5. Systems Design - Modify UML Diagrams:
Update UML diagrams to reflect refined requirements and finalize class specifications
(attributes and methods).
Develop Method Specifications for each method, detailing inputs, outputs, and internal
processing.
6. Develop and Document the System:
Complete comprehensive documentation alongside UML diagrams, providing the
development team with detailed guidance.
Iterative Development with the Spiral Model
O-O methodologies often incorporate a spiral model that tackles small portions of the system
incrementally, focusing on high-priority or high-risk items. This cycle of analysis, design, and
implementation repeats with modifications and refinements until the system is complete.
UML’s structured modeling provides a robust foundation for understanding complex systems,
supporting higher-quality analysis, design, and final production.
Choosing Which Systems Development Method to Use

The differences among the three approaches described earlier are not as big as they seem at the
outset. In all three approaches, the analyst needs to understand the organization first (Chapter 2).
Then the analyst or project team needs to budget time and resources and develop a project
proposal
(Chapter 3). Next, they need to interview organizational members and gather detailed data by using
questionnaires (Chapter 4) and sample data from existing reports and observe how business is cur
rently transacted (Chapter 5). The three approaches have all of these activities in common.
Even the methods themselves have similarities. The SDLC and object-oriented approaches both
require extensive planning and diagramming. The agile approach and the object-oriented approach
both allow subsystems to be built one at a time until the entire system is complete. The agile and
SDLC approaches are both concerned about the way data logically moves through the system.
So given a choice to develop a system using an SDLC approach, an agile approach, or an
object-oriented approach, which would you choose? Figure 1.7 provides a set of guidelines to
help you choose which method to use when developing your next system. #Developing Open
Source Software-
An alternative to traditional software development in which proprietary code is hidden from the
users is called open source software (OSS). With OSS, many users and programmers can study,
share, and modify the code, or computer instructions. Rules of this community include the idea
that any program modifications must be shared with all the people on the project.
Development of open source software has also been characterized as a philosophy rather
than simply as the process of creating new software. Often those involved in open source - Figure
1.7 -> Chose 1-The Systems Development
Life Cycle (SDLC) Approach -When- systems have been developed and documented using SDLC
• it is important to document each step of the way
• upper-level management feels more comfortable or safe
using SDLC
• there are adequate resources and time to complete the full
SDLC
• communication of how new systems work is important Chose-2.Agile Methodologies- When-•
there is a project champion of agile methods in the
organization
• applications need to be developed quickly in response to
a dynamic environment
• a rescue takes place (the system failed and there is no time
to figure out what went wrong)
• the customer is satisfied with incremental improvements
• executives and analysts agree with the principles of agile
methodologies Chose-3-Object-Oriented
Methodologies- When- • the problems modeled lend themselves to classes
• an organization supports the UML learning
• systems can be added gradually, one subsystem at a time
• reuse of previously written software is a possibility
How to decide which development

method to use.
• it is acceptable to tackle the difficult problems first
software communities view it as a way to help societies change. Widely known open source proj
ects include Apache for developing a Web server, the browser called Mozilla Firefox, and Linux,
which is a Unix-like open source operating system.
However, it would be an oversimplification to think of open source software as a monolithic
movement, and it does little to reveal what type of users or user analysts are developing open
source software projects and on what basis. To help us understand the open source movement,
researchers have recently categorized open source communities into four community types—ad
hoc, standardized, organized, and commercial—along six different dimensions—general struc
ture, environment, goals, methods, user community, and licensing. Some researchers argue that
open source software is at a crossroads and that the commercial and community open source
groups need to understand where they converge and where the potential for conflict exists.
Why Organizations Participate in Open Source Communities
Organizations participate in open source communities for a variety of reasons. One is the rapidity
with which new software can be developed and tested. It is faster to have a committed group of
expert developers develop, test, and debug code than it is to have one isolated team working on
software development. This cross-fertilization can also be a boon to creativity.
Another reason to participate is the benefit of having many good minds work with innova
tive applications. Yet another reason for participating in an open source community might be the
potential for keeping down development costs.
Organizations might also seek to participate in an open source community due to a desire
to bolster their own self-image and contribute something worthwhile to the larger software
development community; they may want to contribute generously or altruistically to a higher
good beyond developing profitable proprietary software, and doing so may make them appear as
“good guys” to the external public.
While organizations may ask or even require that their software developers become involved
in one or more open source projects or communities, individual developers must interact with the
community in a meaningful and knowledgeable way in order to first prove themselves worthy
members of the group, and then strike up and maintain relationships that are mutually beneficial.
Organizations and the design teams within them interact with open communities. Companies
are taking advantage of an entire range of options that help them strike a harmonious equilibrium
so that their contributions to the open community and their differentiation from the open com
munity become clear strategically. Reasons for contribution to and differentiation from include
cost, managing resources, and the time it takes to bring a new product to the market.
The Role of the Analyst in Open Source Software
As an analyst you may find yourself, at the request of your chief employer, participating in an
open source community. One widely known open source community is that surrounding the
Linux kernel. This is a large, mostly virtual community of developers who all have different
levels or types of participation and who all have different reasons for being involved. Other well
known open source projects include Mozilla Firefox, Android, Apache projects, and many more.
Even NASA, the U.S. National Aeronautics and Space Administration, has a lively open source
community (see http://ti.arc.nasa.gov/opensource/).
One reason your company may ask you to participate in an open source community is curi
osity about what the software benefits to the organization might be. This may be a result of a
sort of bandwagon effect, for when it becomes known that competitors are already participating,
your organization may want to get involved. With competitors actively participating in an open
community, an organization may calculate that it is something that should at least be investigated
seriously, not dismissed summarily. Another reason your company might ask you to participate
as a developer in an open community is to achieve what researchers have labeled “shared design.”
Shared design means that while you are participating in the open source community, you are at
the same time employed by an organization that wants to leverage your participation in the open
source community to incorporate open source software designs into proprietary products, pro
cesses, knowledge, and IT artifacts that it is developing and that it hopes to eventually sell as a
product that is differentiated from what the open source community has produced. Through a
process of shared design the IT artifact is imbued with both community and organizational struc
tures, knowledge, and practices
When choosing a systems development method, three main approaches are available: SDLC, Agile
methodologies, and Object-Oriented (O-O) approaches. Although each has unique aspects, they share
several common steps, such as understanding the organization, budgeting, gathering data, and
observing existing processes.
Key Differences and Guidelines for Choosing a Development Approach:
1. SDLC (Systems Development Life Cycle) Approach:

Use When:
The project requires detailed documentation.
Management prefers structured processes.
There are adequate resources and time.
Communication on system functionality is crucial.
SDLC is a traditional method that emphasizes rigorous planning and sequential stages,
suitable for projects with well-defined requirements and stable environments.
2. Agile Methodologies:
Use When:
A project champion supports Agile methods.
Rapid development is needed in a dynamic environment.
The project is a "rescue" (e.g., a failed system needing quick action).
Incremental improvement is acceptable.
Agile values flexibility, adaptability, and collaboration, making it suitable for projects
needing quick iterations and regular customer feedback.
3. Object-Oriented Methodologies:
Use When:
Problems can be effectively modeled with classes.
The organization supports learning UML (Unified Modeling Language).
Systems can be built gradually, one subsystem at a time.
There’s an opportunity to reuse previous software components.
Object-Oriented (O-O) methodologies are ideal for complex, component-based systems
where modularity and reuse are priorities. UML aids in visual modeling, supporting clearer
design and communication.
Open Source Software (OSS) Development

Open source software (OSS) differs from traditional proprietary development by allowing users and
developers to access, modify, and share the source code. OSS communities often view this approach as a
philosophy, emphasizing transparency, collaboration, and societal benefits. Popular OSS projects include
Linux, Mozilla Firefox, and Apache.
Reasons for Organizations to Participate in OSS:
1. Rapid Development: Contributions from a global community accelerate development and

debugging.
2. Innovation and Creativity: Collaboration brings diverse ideas and innovative solutions.
3. Cost Efficiency: Sharing resources reduces development expenses.
4. Reputation and Altruism: Engaging in OSS can improve public perception and support societal
contributions.
5. Competitive Advantage: Monitoring competitor involvement can encourage participation as a
strategic move.
The Role of the Analyst in OSS:
As an analyst, you might engage in OSS communities like Linux or Apache on behalf of your
organization. Reasons for participation include:
Investigative: To evaluate OSS benefits compared to competitors.

Shared Design: Combining community-driven designs with proprietary elements for unique
product development.
Open source offers organizations opportunities to balance community contributions with proprietary
differentiation, optimizing costs, resources, and market release timing.

System an Chap-1

Uploaded by

Copyright:

Available Formats

System an Chap-1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

System an Chap-1

Uploaded by

Copyright:

Available Formats

System an Chap-1

Need for Systems Analysis and Design

Roles of a Systems Analyst

Key Roles of a Systems Analyst:

Qualities of a Successful Systems Analyst:

5. Self-Disciplined: Stays motivated, manages people, and coordinates resources effectively.

The Systems Development Life Cycle

The Systems Development Life Cycle (SDLC)

1. Identifying Problems, Opportunities, and Objectives:

1. Identifying Problems, Opportunities, and Objectives:

The Agile Approach

Key Steps in the UML Process:

1. Define the Use Case Model:

Choosing Which Systems Development Method to Use

How to decide which development

Key Differences and Guidelines for Choosing a Development Approach:

1. SDLC (Systems Development Life Cycle) Approach:

Open Source Software (OSS) Development

Reasons for Organizations to Participate in OSS:

1. Rapid Development: Contributions from a global community accelerate development and

The Role of the Analyst in OSS:

Investigative: To evaluate OSS benefits compared to competitors.

You might also like