Wednesday, March 24, 2010

SDLC Step 1: Problem Analysis

Before you start trying to solve a problem it's important to study the existing system before embarking on major changes.

Consider the Analysis phase like a visit to the doctor. You would be pretty worried if you told the doctor you had a headache and the doctor immediately started merrily injecting you with various things before even looking at you or asking you any questions. Such behaviour is likely to cause more problems than it solves, so doctors always analyse their patients - observing, questioning, testing - before beginning any treatment.

So also do problem solvers study the system they intend to change, and the organisation it's in, before they decide what needs to be done. By thoroughly understanding a system, its operation, its context, its strengths and weaknesses, one can better decide how to start improving it.

Why should the information system be changed?
Possible reasons for change:

new laws that force organisations to do new things, or do old things differently
changes in society, such as growing demand for better security over personal data
a desire to improve competitiveness in the fact of reducing profits and market share
changes in technology - e.g. a new operating system may force upgrades to computers
a need to increase productivity, quality or efficiency
concern that existing equipment is a health and safety menace
changes in work processes, expansion of the business, changes in business requirements or the environment in which the organisation operates may all lead to a reassessment of information system requirements.
ghe current system may be too inflexible or expensive to maintain, or may reduce the organisation's ability to respond quickly enough to customer's demands.
Reasons for change can come from within the organisation or from outside it .

Factors can be technological, economic, social, legal or political.

Changing something just for the sake of change is an expensive - and potentially destructive - hobby. There had better be a good reason for changing systems. Many good reasons stem from a desire to better achieve organisational goals, while some other reasons are imposed on the organisation from the outside and are beyond the organisation's control.

If there is no compelling reason to take action, why waste time, effort and money? The preliminary investigation should mount a case to answer these questions:

Questions that need to be asked during analysis
There's not much good getting heavily into a project if the whole thing is a silly idea to start with. The preliminary investigation is an early test of whether the project should even be started.

Is there really a problem?

Imagine a manager thinking his organisation was losing sales because customers could not shop online. He spends thousands of dollars and hundreds of man-hours to implement an online shopping system. After it's launched, no-one actually uses it because they were happy with the old system. A waste of time and money.

If there is a problem, is it worth fixing?

Assuming a valid problem has been identified, you must consider a "cost/benefit" analysis. In other words: is fixing the problem worth it?

A manager decides the company logo and letterhead looks old fashioned. He spends thousands on graphic design consultants, market research, psychological testing of consumer reactions; he recalls and destroys all existing stationery and company publications and reprints them with the new logo and letterheads; he has signwriters repaint all company vehicles and buildings. It cost millions, and it simply not worth it.

Determining whether a problem is worth fixing involves a feasibility study. The aim of the feasibility study is to understand the problem and to determine whether it is worth proceeding. There are five main factors to be considered:

Technical feasibility - investigating whether the technology exists to implement the proposed system, or whether this is a practical proposition.
Economic feasibility - has to do with establishing the cost-effectiveness of the proposed system - if the benefits do not outweigh the costs, then it is not worth going ahead.
Legal feasibility - determines whether there is any conflict between the proposed system and legal requirements - for example, will the system contravene the Information Privacy Act?
Operational feasibility - Operational feasibility is concerned with whether the current work practices and procedures are adequate to support the new system. It is also concerned with social factors - how the organisational change will affect the working lives of those affected by the system.
Schedule feasibility - looks at how long the system will take to develop, or whether it can be done in a desired time-frame.
To answer these questions, data has to be collected about the system. You might need to:

measure things, like how long different processes take, how much output is produced in a given time, how many staff are required.
count things, like the numbers of errors or system failures in an existing system.
survey or interview workers, management, customers, and corporate partners to discover what these people know about the system's requirements, strengths or weaknesses from their specialist perspectives
observe processes in action to see where problems lie and improvements can be made in work-flow, and consider how procedures should be changed to accommodate the new or changed system. If processes take place outside your organisation, be sure to include them too - you never know: the problem might not be in your organisation at all!
research similar systems elsewhere to see how similar problems have been addressed
test the existing system to determine whether suspected points of weakness are real or imagined
study the workers in the organisation and list the types of information the system needs to produce for each type of worker
Such operations often create more questions that also need to be answered. Analysis often turns up issues that need to be investigated with further analysis. By the time you are finished analysing the problem, you should have a clear idea of:

the context of the problem - how the system fits into its surroundings, which includes people (in your organisation and perhaps in other organisations) and other systems which interact with the system. You need to understand how input, processing and output data are managed in the organisation - including data and information destinations. An IPO chart and workflow diagram would be good to document these relationships.
the processes - you need to know how data is transformed into information. What tasks are performed? A top-down approach makes sense: identify major processes, and keep subdividing them up into smaller processes until individual tasks are listed.
When an existing system is well understood, and the needs of the new or changed system have been defined, a design for the solution is not far away.


No comments:


Related Posts Plugin for WordPress, Blogger...