symposia

Week 1

The first two weeks of FIT2001 entailed the nature and contexts of Systems Analysis and Design. The role of the systems analyst was discussed, as well as the methologies and tools used in the analysis of systems.

One thing that I had reinforced was the distinct definitions between a system, an information system and information technology. The terms information system and information technology get muddled up too easily, even though there is a difference, albeit subtle, between the two. A system is an interconnected chain of processes that can have inputs and outputs. There are several rules governing the nature of a system: in that it is greater than the sum of its parts, it can be divided into autonomous sub-systems, it interacts with the surrounding environment and it needs management and control protocols in place. Information Systems are IT-based systems that process some kind of input into usable information as output. These systems do not need to be exclusively composed of information technologies, but often do form a part of it (for example, the nature of the legal system means that a large amount of paper work still needs to fit within the processes of the information system).

This subject looks at the first two stages of what is known as the SDLC (Systems Development Life Cycle) - that is, the Analysis and Design of the (information) system. It is useful to think that each of the points on the life cycle represent processes - each with input and output leading from each other in sequence. Thus, there is usable output from each point in the life cycle. This is known as a ‘deliverable’, the final deliverable being the finished information system.

With the scope (no pun intended) of the unit established, the next thing that was raised was the role of the systems analyst. A quote from from Whitten succinctly defines this:

“A Systems Analyst studies the problems and needs of an organisation to determine how people, methods, tasks, and computer technology can best accomplish improvements for the business. When computer technology is used, the systems analyst is responsible for the efficient capture of data from its business source, the flow of that data to the computer, the processing and storage of that data by the computer, and the flow of useful and timely information back to the business and its people.”

Often, the ‘problems’ and ‘needs’ of the organisation are addressed in the form of projects. This consequently means that the systems analyst forms an integral part of the project team. Also, the nature of the systems analyst’s job - that is, how s/he needs to consider multiple angles to bring improvement to the business as a whole - means that the system analyst needs to be in communication from many different groups of people (sometimes with conflicting views).

Next, was models used in the analysis of systems. Models are an abstraction - that is, a simplifed representation - of a real world thing. There are multilude of models that can be used to abstract systems, these include (but are not limited to):

• flowcharts
• data flow diagrams (DFDs)
• entity relationship diagram (ERDs)
• structure charts
• use case diagrams
• class diagrams (similar to unified modelling language, UML)
• sequence diagrams

Other models can be used to aid in the development of systems:

• program/project evalulation and review technique (PERT) charts
• Gantt charts
• organisational hierarchy charts
• financial analysis models - Net Present Values (NPVs), Return on Investment (ROIs)

From here, there are tools that we can use to aid us in the development of such models such as MS Visio, MS Project, Visual Paradigm et cetera.

But what is the purpose of the information system? After all, what’s the point in designing something that we do not even know the use for? We hear of the many information system development faliures in government, which seems to suggest that the development is complicated and prone to failure. What people do not realise is that it revolves around one single tenet - to process, maintain and deliver information to the users.

A new term I came across was the state variable. This is to give the user an idea of the current status of the organisation (within scope of the information system). This can include employee counts, total salary throught the organisation and so forth.

Week 2

This week extends upon the introductory material of Week 1, placing the nature of Systems Analysis and Design into context. The concept of the deliverable was discussed in the last week, and this week extends upon it with the concept of quality. What am ambiguous word! What is this word meant to mean? Obviously, you and I will have different takes on this idea - so where does this put the organisation? It has been backed into a corner, forced to make compromises to appease everyone for mitigating risk of losing disgruntled customers. There is a rule I recall:

“A happy customer may tell one or two of their friends. But an unhappy customer tells, on average, 11 others.”

It is obviously in the organisation’s interest to keep customers happy by suppling quality products. But, again, what is quality? It is a very hard concept to objectively quantify, but it revolves around these three points:

• timeliness
• within budget, or over only by a reasonable amount
• easy / intuitive to use

Failure has many causes, and can also be easily prevented if the correct precautions are taken. That said, one of the causes of faliure is due to the external environment (that is, the market) and this is unavoidable apart from a risk assessment.

The Systems Development Life Cycle

Project Definition / Scoping > Analysis > Design > Implementation > Support

I have to note that the funny thing about the SDLC is that how it is not standardised and that there are various forms floating around. I experienced a different one at my high school leaver year IT subjects (Analysis, Design, Development, Implementation, Evalulation) and another one during FIT1003. However, this is well acknowledged - given that all versions of the SDLC are more or less similar to each other.

This can be extended into a matrix, as suggested by Fertuck. Based around the SDLC, it is a matrix between the entities : {people, procedures, data, hardware, sofware} and the methods : {requirements gathering, alternative analyses, design specification, design implementation}.

There are also other variations of the SDLC (or more accurately, interpretations). A brief summary follows:

• the traditional waterfall method
  • sequential stepping through the SDLC, return to previous steps possible but difficult
  • not suitable for larger systems as problems detected later will be costly to fix
• prototyping
  • a working model developed early
  • involves uses into development of system
  • is an iterative process
  • good for determining user needs for hard to visualise concepts
  • prototypes may need to be discarded when user requirements are finalised
• rapid application development (RAD)
  • based on prototypes
  • complete product also based on a prototype
  • is an iterative process
• joint application development (JAD)
  • uses intensive meetings to between multiple disciplines to create system specification
• vendor CASE tools

These still, however, follow the same flow of the SDLC. They may, however, have certain steps skipped or somewhat abbreviated.

Evaluating Project Feasibility
There are five types of feasibilities that can affect the possible of a project continuing. These are technical, operational, legal, schedule and economic feasibilities.

Technical feasibilities simply mean ‘is the system developable with current technologies?’. However, this raises another question: ’should we be using bleeding edge technologies or stable matured technologies?’. On one hand, you have a known to work and stable platform in which to develop your system. This lends weight to the economics argument - off the shelf parts will be cheaper as there are more manufacturers in the market (and as we know, competition inversely correlates with prices). However, the technology could be dated when the system is complete.

Operation feasibilities are whether the system will fit into the place of the organisation. This is often a source of failure of projects. Resistance to change is strong in a lot of people. In addition to the long timeframes of systems development it is also quite possible that by the time a system is completed, it will be no longer relevant to the organisation (due to external or internal forces changing the nature of the organisation).
Legal feasibilities are the restrictions and considerations that need to be applied to the software whilst in development. The legality of the system as a whole and of its individual processes need to be considered.

Schedule feasibilities are the suitability of the assigned time to complete the project.

Economic feasibilities mean whether the project is cost-effective and whether it will bring value to the organisation. Other considerations that may need to be taken into account are the funding of the system, the net present values (particuarly important in long duration projects) and various depreciations. It is essentially a cost-benefit analysis.

More on Economics
I touched upon on some of the more complex concepts in determining whether a project is feasible in an economic sense. While it may be simply a cost vs. benefits analysis, what exactly is the cost to the organisation? What exactly are the benefits to the organisation? Do they cancel out? Does the organisation eventually recoup its losses?

Consider this: what did $50 buy you 10 years ago? What does it buy you now? It is obvious, due to inflation, that our dollar is losing value each year. So what we spend today may be ‘worth’ more in future, and what we spend in future may have an ‘inflated’ figure in comparision to today. A way of equating this is to take all future spending and calculate the net present value of it (the current value of all future cash outflows). This gives all spending a level playing field, and subsequently forms a central part of any credible economic analysis.

What about benefits? Can you simply say that a new system ‘will improve sales’ ? The answer is no, you can’t. In order to be a proper analysis, you need to quantitatively determine the benefit to the organisation. That means that ‘the new system will create 10% more sales’ would be suitable. This, however, only applies to tangible benefits. There are going to be intangible benefits which cannot be quantified. These, too, have a value attached to them - and how much this is worth is completely up to the company treasures them (these benefits include improved customer relations, staff retention, streamlined decision making, improved public image and so on).

A project is considered to be economically feasible if it can be shown that the value of tangible and intangible benefits exceed the costs (note Net Present Value). Two things that can be used are the break-even analysis and the pay-back analysis. These are very much self-explanatory. Another type of analysis that can be used is the cash flow analysis. Again, the analyses need to be discounted (that is, have a present value factored into it - refer NPV).