|
|
CIS 251 -
System Development Methods
Chapter 1: Introduction to Systems Analysis and Design
Objectives:
This lesson discusses material from chapter 1. Objectives important to
this lesson:
- Systems analysis
- IT system components
- Business information systems
- Three development method types
- Guidelines, independent of method
- Role of the systems analyst
- Communication tools
- Assignments for the week
Concepts:
In the introduction to chapter 1, the authors seem to thrash around for a bit, attempting to sell us the idea that information technology is important, and because it is, we should learn something about how information systems are built. I would hope that students taking this class would be aware of such ideas already, but let's give them the benefit of the doubt and review some concepts you may know well for a bit.
On page 4, the text describes systems analysis and design
as "a step-by-step process for developing high-quality information
systems". That can be true, but even a good process can produce a
bad system if the people using it mess up at any critical
stage. Further in the chapter, the text discusses some of the risks
involved in developing a system by a method that puts more focus on how
it should work than on what it should do. It is a time
honored principle of systems design that if you determine what you want
the system to give you first, you can more easily determine what
data or information the system needs to be given to produce that
output. Another way of saying that would be that you should state your
desired outputs to determine the required inputs,
and the processes that must take place to produce those outputs.
The text continues on page 5 with a list of five components
of an information system:
- hardware - This course is about computer based information systems, but we should recall that companies used information before computers existed.
The text quotes Moore's Law, created by Gordon Moore
when he worked for the Intel corporation. It is often misquoted. As
the book states, Moore actually said the complexity of chips, measured
by the number of transistors on them, would double every 24 months,
not every 18 months. This axiom has been true since the mid-sixties,
and may be one reason that people seem to think that computers become
obsolete after a year and half to two years.
- software - The text lists several categories that can be used to classify software, based on its purpose or use.
- System software refers to operating systems, such as Windows, iOS, Android, and UNIX.
The text includes driver software in this category, which is typically an interface between specific hardware and the system or application software.
The text includes security software in this category. Most IT people would place security software in its own category, regardless of the way it is implemented. Some versions of Windows, for example, include BitLocker, which is software that can encrypt all writeable drives on a computer. It is included with those versions of Windows, but it should not be considered part of the operating system because it performs no system services, and the Windows OS would be missing nothing if it were not there.
- The text discusses application software, but provides a strange definition. An application does something in particular, such as word processing, or web browsing. Some applications are for particular purposes, like design or animation, making the book's statement that applications "provide users with the information they require" seem rather silly. It is correct when it says that enterprise applications are those that an enterprise (company, department, state) provides to all its users.
- The terms horizontal and vertical systems are seldom used. Legacy system and legacy software, however, are terms you should know. They refer to older systems or software that are still used in some way in your environment.
- data - The text differentiates between data and
information, as most texts do. Data usually refe rs
to raw numbers, measurements, or facts that are not necessarily useful
in themselves. Information refers to the meaningful facts, figures,
or comparisons that become available once data processing occurs.
- processes - The text means the actual business
activities that collect, use, and interpret data to create
information. This term can also mean the activities that are carried
out by any employee of an enterprise for any business purpose,
or the computing functions carried out by a system. An information
system may support any action of an employee, not just those that seem
to use data and information.
- people - We seem to have developed a trend here, explaining terms after we use them. I hope this is not a pattern for the text. The text explains that stakeholders are all the people with an interest in a system, including the users, the developers, and any kind of support staff. End users (users) are defined as those who use a system once it is in place. Obviously, stakeholder is a wider concept, and one that should be used when planning a working group to create or update a system.
In order to build a system that will be of any use to
anyone, the builders need to understand what the system
will be required to do. The text presents two terms on page 10 that are
useful in understanding the business that is requesting the system:
- business profile - This should be a document that describes the structure and functions of an organization, lists the products and services it provides, and describes the entities whose data will be included in the system. Those entities include the customers, the employees, and the business units of the company.
- business process - The actions that take place as a company conducts its business. For example, taking a phone call may require logging information from the call in a database, taking action based on the information, or passing the information to another business unit for action or processing. That series of actions can be stored in a decision tree as a documented business process.
Process documentation is used as a guide when designing and building a system. Good documentation of business processes leads to systems that support those processes better. Bad documentation of processes leads to systems that are of little or negative value.
On page 11, the text moves on to discuss some broad categories that systems
can fall into. It is worth skimming over this section if you have not
heard of the concepts:
- enterprise computing - This is about applications that support running a whole company. Don't confuse it with enterprise applications, defined above.
- transaction processing - Typically, systems that process all tasks that are required for a transaction, whatever the company means by that. For an online sale, the system might have to query a database, update inventory, trigger shipping and handling, and bill the customer, among other things, as separate parts of the same transaction.
- business support - This phrase is too generic to mean anything. It seems to be the text's catch all category for any application that supports the concerns of the business that uses it.
On page 16, the text mentions some tools that may be used to develop
a system.
- modeling - In the early stages of a system project, several kinds of models may be created to show the business as it is, or as someone desires it to be; the requirements the customer is making; the data being used or being requested; the objects that will be needed (if using an Object Oriented Language for development); the network changes being requested, and more. The model being constructed is typically a version of a flow chart, although the other chart versions listed on page 19 may also be used.
- prototyping - This refers to building a system through many iterations, building on the older versions each time, making adjustments from user feedback to approach an acceptable system, little by little.
- CASE tools - An integrated development environment that can be used to model, document, and create a system.
Starting on page 17, the text describes three development methods that
are not necessarily mutually exclusive. All analyze data, processes, the
company, and provide some means of looping back to a previous phase when
necessary.
- structured analysis - data and processes are the main entities that are modeled; the waterfall method was often used, each tier of the waterfall producing outputs that are the inputs for the next stage; typically follows some form of the SDLC cycle
- SDLC - Systems Development Life Cycle, a sequence of phases for the creation of information systems; typical phases: plan, analyze, design, implement, support
- object oriented analysis - this approach stresses
the features of an object-oriented programming language being used for
development, stressing the relationships between objects, properties,
and processes
- agile/adaptive methods - stresses prototyping
of each logical unit of the system, and iterating the development
process until the prototype is accepted by the customer
The text mentions three models that are not well depicted. Look at the
PowerPoint
slides on this page from Riantsoft, which show better depictions of
the waterfall model and a spiral model.
This version of the text has left out a chart of guidelines that apply to a project regardless of the method used. It was presented here previously and it has value here.
- Develop a plan
- Involve users, and listen to their input
- Use project management tools
- Determine the costs and benefits of the current and new systems
- Remain flexible
On page 24, the text presents some common divisions
of IT departments, to make it clear that IT professionals within an organization
often specialize in one kind of service.
- application development - staff in this area develop and service programs that are made within the company
- systems support - installation and maintenance services are provided for hardware and infrastructure
- security - the text lumps this in with systems support, but it is often a separate division
- user support - may be separated into help desk, desktop support, and other specialties
- database administration - staff specialize in running the databases used to store company data
- network administration - staff run the logical network, create and remove user accounts, grant and remove user access
- web support - staff maintain the web sites of the company, internal and external
- quality assurance - this can mean many things in different companies, but the general idea is to make sure your product is up to or exceeding your standards
On page 26, the text begins a discussion of the skills and abilities
that a successful systems analyst should have. You should review this
discussion, and determine which skills you need to build up the most.
We will look at several in the section of the book called The
System Analyst's Toolkit. This week we will consider Part
A, Communication Tools.
On page 465, the text begins with a series of questions you might ask
yourself when you are trying to communicate clearly. In my opinion, the
text leaves out an important word that is typically presented in this
set. Consider using each of Rudyard Kipling's six
honest serving men to describe your project:
I keep six honest serving-men
(They taught me all I knew);
Their names are What and Why and When
And How and Where and Who.
(The rest of the poem is not important in this context. It is more important to a discussion of Kipling. We can leave that for later.)
What are you writing about? Who are you writing for? Why are you writing it and why will they read it? How will you create your work, and how will it be delivered? When and where will your output be used?
The text's advice for when is different, but also useful: know when to speak, when to listen, and when to pause.
Knowing that will improve your presentation, and also improve your efforts to gather user requirements for a system. In the next paragraph, the text cautions you to consider several contexts that affect how the reader/listener/viewer perceives your message. Within the framework of customer service, we should always take care to make sure we can be understood. It is not possible to ensure that we are understood without some feedback from the audience. When you give a speech, read the room. Look for visuals cues like expressions and body language to tell you whether the audience is listening or lost.
Don't know what to look for? Practice talking to people, look at them, and ask them what they are getting from your message. Learn about the people and groups near you this way. People who are different from you in significant ways (language, culture, education) may give different cues, so make it a point to get feedback that will let you make corrections in their understanding of your message.
Another message in this section puzzles me, because I have never understood why people would make this mistake. The text cautions us not to make up an answer when we face a question whose answer we do not know. Preparation before a speech, a sales pitch, or any other communication is essential. You can't talk convincingly about a subject you don't know well. One of the lessons of the Dale Carnegie classes is to know ten times as much as you mean to say about a subject, and to choose the ten percent you will talk about carefully. I tend to agree, especially when you mean to give a short talk and to take questions. Different audiences will ask different questions after the same speech, so you have to prepare as best you can with information that may or may not be called for. I do not understand, however, why someone talking about a subject they care about would make up an answer, instead of saying "I don't know right now, but I will find out and get back to you". Business, social, or other communications are not like a debate. You don't often have to have all the answers at the snap of a finger in real life, and you will look worse later for pretending and being wrong than you will for admitting that you don't know something yet.
On page 466, the text turns to written communications. You should review
the ten guidelines in this section. Each has some value
to apply to your work. In this section, the text cautions you to apply
the same care to grammar and spelling in email that you apply to more
formal communications. This is a good idea. Let me take it a step further.
I was cautioned many years ago by an English teacher to never write down
anything that I did not wish my worst enemy to read. This advice is still
good, and it applies to all communications that leave your control, especially
email and text messages.
Review the rest of the sections in this toolkit. We will discuss some of them from time to time.
|
