This is studying the existing system to see how it works and see what the users need. It is an investigation where a relationship is established with the users. A plan is created of how to replace some or all of the system. It is necessary to see where the boundaries are of the system.
An analyst needs to have an understanding of the different elements within a software development life cycle but not necessarily expert at all stages.
Change can come from problems, needing new features and they can be both external and internal. External could be expanding business for example to compete against competition.
The analyst has to take into account not every employee will want change and may need reskilling. Its important that the analyst gets the users on their side.
An analyst need good written and oral communication skills and good analytical skills. Interviews will be carried and with presentations to the client and written reports. A training program will need to be developed. They need to coordinate with programmers, their own managers, system’s users, their managers and training providers. There may be some involvement with instalment of equipment.
Planning and design needs to be planned with help of the client organisation. All activities need to be scheduled.
- Preliminary investigation
Stage 1 – Feasibility Study (Preliminary investigation) – this defines the problem, what can be done about it. Its useful to get hold of an organisational chart to see how is in charge in the organisation. The problem is defined: its nature, its scope and its objectives.
Stage 2 – Systems Analysis – its important to find out how the existing system works. Perhaps send out surveys and do interviews to find how what people do with the existing system. Documents on the system can usually be collected from HR. Observations can be made to see how the users use their system.
Data Flow Diagrams can be made to see how data is passed around a system and see processes and data stores.
Decision tables show a number of IFs with rules, conditions and actions. It can look at the possibilities within a system.
System requirements need to be put together to see what the user needs and what the new system must do. This is documented. An agreement is made between the analyst and the client. If a report to management is agreed, we move to the next stage.
Stage 3 – Design – a preliminary design is made where we review systems requirements. Some off the shelf solutions could be considered or done in house or sourced out. A selection of solutions are given to the client to chose. Future needs to be considered.
Prototyping – a limited system could be made to see if it meets their expectations. A working model could be made. Its not going to work right first time! A detailed design is next made. Output and input requirements are decided and database systems.
Output requirements could be paper and/or on a computer screen. Reporting might be an output and sample screen shots might be seen by the client. Input requirements – it could keyed in from source documents or could be scanned from a EPOS terminal. The user input interface needs to be looked at so its easy to use and works well at peak periods. Validation and accuracy is needed.
Coordination is needed with the database admin if using the existing database.
system processing – a DFD is produced.
Security – data needs to be kept safe and ensure data integrity. Back up is essential so nothing is lost and off site back up is a very wise thing to have.
Stage 4 – Programming – Scheduling relates to creating Gantt charts to see the hours, days and weeks spent on a project. It can help work out money and man hours.
Other than the prototype, no programming wasn’t done until now.
Testing – the system can be tested in units and then testing to see how the units work together.
Stage 5 – Implementation – The system needs to have trained people using the system. It helps by creating a user manual. The way people use the system is paramount to how the system is operated.
Installation will need a schedule to install the new equipment with contractor workers doing the labour
File conversion may need to be done to change the old files into new ones onto the new system.
Conversion to the new system can be done parallel where both systems are working at the same time or phased where different user groups migrate bit by bit.
Evaluation is done at the end to see how the system is working. An independent evaluation team might need to be brought in.
Maintenance may be needed to sort out missed bugs and add new features. This is an on-going activity. Some code might need to be rewritten.
Each system is unique where no solution can fit all problems. Knowledge and skills requires programming skills, organising, preparing DFDs, problem solving, being pro-active, etc.
What is a system?
It has a purpose with a subsystem, e.g.. human body with digestive system and nervous system
Deterministic systems – It works to a redefined set of rules such as a computer program. Its behaviour can be predicted
Problistic systems – The factors can be guessed but are not determined and results can be random
Closed systems – There are no inputs or outputs and do is not triggered by an environment. An example of open systems: cars, economy, business. An example of a closed system: traffic light system.
Control systems – They are systems with feedbacks called closed loop systems, e.g. a credit card system to might limit bad debt through keeping credit card limit low.
negative feedback – actual tends towards standard
positive feedback – its no good for controlling credit.
there’s no feedback on the open loop system.
Vertical information flows – Information flows up and down the business hierarchy
Horizontal/external information flows – information flows across the same level
Reports – they show information from the past, the present system and predictions of future states. Information should be timely, accurate, the right information and sent to the right person.
Idea -> Initial Survey -> Feasibility Study -> Systems Analysis -> Systems Design -> Programming -> Testing Implementation -> Post Implementation Review
Positives – it provides a systematic way of designing systems. It is easy to control and monitor. It encourages planning and measurement. It allows tasks to be divided amounted people
Negatives – real projects don’t follow this sequential flow. It doesn’t take into account constant testing and at the end of the system, there maybe huge errors
You start in the middle with up to 6 phrases. Each section involves evaluating including resolving risks, developing, planning and determining objective at each phrase. It is a series of risk assessments and prototypes of high risk.
Analysis -> Design -> Implementation
Evaluation is at the centre of the model and extends the waterfall model with constant evaluation.
Other models: RAD – rapid
Create information models of the entire systems life cycle and its resources. We can ask what ifs.
PERT – Product, Evaluation and Review Technique
It is also called Critical Path Analysis. It is based on tasks involved in development and their dependencies. We need to have an idea of order of tasks. Resources are allocated to the tasks and how long they last. We can found out the critical path of tasks – showing tasks must happen at particular times for the project to occur.
Example – building a boat
- launch the boat
- raise the sails
- build the desk
- paint the keel
- sail away
- build the sides
We next give an estimation to each of the tasks of how long they take to be done.
These tasks need to be put into order.
From this, we can see how long it will take, and what tasks are critical to be done on time for the next task to be done on time. PERT allows this to be diagrammed.
If we discover one task takes longer than previously thought, it might effect the project completion date. This means that the critical path might change if a task makes a path take longer than another path.
Microsoft Project allows us to draw these diagrams a lot easier. We can say how long a task will occur and when and can allocate resources to the tasks, e.g. people. This helps to avoid clashes in people’s time.
Durations of tasks rely on estimates and therefore creates risks. Plans are made in times of disaster e.g. computers fails, power cut, large scale employee illness. They are all made in advance and save time if something does go wrong. We put together a risk analysis plan and look at the likelihood of something happens, its effects, the response and who is responsible for taking action for the problem. There are some risks we do not put onto a risk analysis since its chance of happening could be minimal. The earth being hit by an asteroid isn’t suitable. We list risks that are relevant to the project and very likely to occur. We should include things like a project missing a deadline and fire destroying the premise or a computer network failure.
Acceptable and unacceptable risk
Big risks can occur when the wrong people are causing high risk exposure. Should we delegate risk?
User Requirements – Informal
After gathering all user requirements, we need to produce a design to confirm the technical approach and critical system performance. Recommendations are made on resources and equipment with choice of suppliers. We should be able to justify the project and create an Outline Design Report to detail user management of the system. We need to be sure the project will work and if the costs and timescales are applicable to the business. We need to consider the functional requirements of the users if the project meets their needs.
A SWOT analysis is carried out to find the positives and negatives of the current system. If this is done properly, we can put together a correct list of requirements. Once the problem is understood, we adopt a methodology. Within the boundaries of the feasibility study, we define the current system. All assumptions and conclusions are validated.
Gathering data is done by:
- documents gathering and review
- statistical sampling
User agreements – Reporting of findings needs to be done to go back to the managers and check to see if the information given is correct through validating it.
Information systems is made up of processing (updating, reports and enquiries), data and the interface (user, telecoms, network). This should be documented in a requirements catalogue. There is one page per requirement. A video store has: updates – recording the ins and outs of the videos and deleting and adding videos, enquiries – find out if a video is available to rent, reports – reports of say how many videos are being rented, interface requirements and data requirements. We record the priority of the requirement and list non functional component range with a target value, etc
We also record the non-functional requirements such as backups to ensure security, availability of the system, etc
Its also called programming design language or pseudo code. We do not use “ands” and “buts” and do not use adjectives, adverbs and most punctuation. Its short sharp sentences. We use imperative english verbs, e.g. commands like put, take etc. Terms are defined in a data dictionary to explain what files and data is. It includes some syntax of the programming language. It includes sequences, decisions, repetition
Be careful though, structured english might scare the user off!
Gantt Charts – They are frequently used to represent business plans. They can be made in Microsoft Project. Its a way of showing how long a project will take. This can be good for waterfall and SSADM methodologies as its a linear.
A usual charge out rate for IT professionals are usually 3 times the salary of the employee. An analyist earns more than the programmer who earns more than the implementer.
- Personnel – inexperience, mistakes and staff turnover
- Scheudles and budgets – not enough time or money
- Functionality – user and developer understanding
- Interface – bad GUI
- Gold plating – unnecessary features
- excessive requirements change
- suppliers – late deliveries, goods unavailable, lack of supplier skills
- tools and equipment – failure of these
- technology – relying on untested new technologies, unachieveable requirements
- market – no demand for the product
- project cutting
- extra costs
- taking too long
A risk management model looks at inputs and how they are controlled and its outputs. We can access tisk exposure by lookiing at the risk likelihood and timing it with the loss value. We can look at risk leverage by dividing risk reduction by the cost of risk aversion. We can reduce risk by:
- training staff
- better project management
- support staff
- better testing
- looking at competitive goods
System Benefits of the Impact of IT
IT System Benefits come in four flavours:
- Cost Savings – most systems have already been computerised. The opportunities for cost savings are probably £0.
- Improved Productivity – Opportunities again are starting to fade away but better than 1 above.
- Better Information Quality:
- Faster – Computerised stock deals. – Reuters – overtaken by CNN, they spent £m’s to get the story out first albeit by only 10 seconds!
- More accurate – Computers were essential in developing the ‘A’ and ‘H’ bomb.
- Better presented – Any modern film with computer graphics – Jurassic Park.
- Organisational Enhancement – New business.
E.g. NORWEB – providing internet services over the domestic electricity supply.
First Direct – could not exist without computers
IT Systems Impact
Job Content – which may be broken down as follows:
- i) Task variety – May increase or decrease.
- Effort required – Will probably diminish since paper records will decrease.
- Personal autonomy and discretion – Personal autonomy will probably increase (more free time to carry out the work when they wish, therefore more freedom). Discretion will probably decrease (less freedom to modify the system).
- New skills to be gained and training needs – Staff suitability for training will have to be assessed. May have to replace all staff and acquire suitable trainees.
- Old skills to be lost – People with old skills will go.
- Work pace and deadlines unlikely to increase, but
- Workload – the remaining staff will believe they are carrying out the work of all their former colleagues.
- Monitoring & Measurement – No monitoring is envisaged.
Organisational Procedures and Structures – It is likely that a successful change will enhance the power and status of any remaining staff who are chosen to operate the new system.
Personnel Policies – Pay and other rewards will have to match the market for all staff taught new skills. Career prospects will improve for staff with newly acquired IT skills.
Cost Benefit Analysis
At the end of the feasibility study it is necessary to decide which, if any, of the alternative new system designs should be promoted to the full analysis and design stage.
This step in the Systems Development Life Cycle is sometimes referred to as the Systems Evaluation and Selection Phase. (Note in some methodologies this is delayed until after full investigation and preliminary systems design)
Decisions to replace the current systems with one of the proposed system design alternatives are difficult; we need clear comparative data in order to make informed decisions.
There are two sources of comparison for making decisions:
Cost/Benefit Analysis – CBA attempts to measure costs, tangible benefits, and intangible benefits of the system(s) under consideration.
Systems Value – This technique is intended to evaluate the qualitative value of systems. It is allows the analyst to assign quantifiable values to a set of feasibility, strategic and design factors. Aggregating the scores of these factors gives an estimate of the ‘value’ of a proposed system.
Cost Benefit Analysis
Each proposed systems design has specific financial costs and potential benefits – these will normally vary between design proposals.
The proposed systems design with the least cost’ is not necessarily the best design alternative, in fact in the long run it may turn out to be the most expensive.
To realistically compare proposed system alternatives we require, for each proposed system alternative, a detailed evaluation of the costs over the operating life of the system combined with supportable estimates of the financial value of the expected benefits of that system. This is called Cost-Benefit Analysis (CBA).
Examining the Costs of a Proposed System
Costs fall into two main groups:
Initial capital expenditure. – This is required to develop and implement the system, including Computing Resources Costs and Systems Development and Implementation Costs
Costs recurring over the life of the system – Namely Operating and Maintenance Costs
Computing Resources Costs
These include the systems hardware and any bought in software packages (operating systems, spreadsheets, etc.)
Systems Development and Implementation Costs
The process of systems development and implementation incurs the following costs:
- Systems Development Costs – These costs involve the systems investigation, analysis, planning and design functions performed by the systems professionals. In a large, complex system other development-type personnel may include system integrators, telecommunications experts and various special technicians.
- Equipment Installation Costs – This will include specialist installation staff, freight, special equipment hire e.g. cranes, etc.
- Programming Costs – these are the costs of bespoke/customised application programs written by in-house or independent programmers. Estimates will be based on the time to write (in man-hours) times the programmer’s rate per hour plus overhead.
- Training Costs – A variety of tests are run on all the system components before converting to the new information system. This task requires a great deal of planning and the preparation of effective test data. Costs can include consultants’ fees as well as in-house personnel.
- Conversion Costs – these will depend upon the scale of the project, how many applications in the current system are to be changed and how many are to continue to be handled in the current fashion. Several factors will effect the cost of conversion:
- preparing and editing records for completeness and accuracy.
- setting up file library procedures.
- preparing and running parallel operations
Operation and Maintenance Costs
Operations and maintenance costs include all the elements needed to keep the system functioning after it has been implemented. These costs may be broken down into:
- Staff Costs
- Telecommunications costs
- Building and Building Services Costs
- Security Costs
- Benefits can be both tangible and intangible.
- Tangible benefits are relatively easy to evaluate.
- Intangible benefits , are difficult to evaluate.
- However to be able to determine the value of a design proposal and objectively compare alternative design proposals, it is essential that a value is assigned to all benefits
Tangible Benefits – Tangible benefits (sometimes called direct benefits) are those, which can be traced directly to the system
Intangible Benefits – Intangible benefits are those benefits that cannot be easily traced to the proposed system. However an attempt must be made to evaluate those that can be identified.
Most new systems proposals include new, high quality, information for management purposes, which should improve the efficiency and effectiveness of management, thereby supporting management to increase revenue and/or decrease costs.
Accurate evaluation of the intangible benefits is likely to lack precision. However, to be able to proceed with any cost/benefit analysis we need methods to evaluate the intangible benefits as well as the tangible benefits. A suitable method for evaluating these intangible benefits is the expected value technique.
Evaluating and Selecting Systems
Although Cost/Benefit Analysis (CBA) is useful in helping management make investment decisions where costs and benefits are clearly identifiable it does not tell the full story for evaluating a proposed systems design. CBA will not evaluate systems in terms of their potential to: increase productivity, simplify management, avoid potential legal difficulties, ensure operational durability, etc. Nor does CBA take into consideration the design value of a proposed system.
We can, however, estimate the value of a system design by considering the three categories of qualitative factors:
- TELOS feasibility factors
- PDM strategic factors
- MURRE design factors
It is common to use a three-dimensional diagram to show these as different ‘sides’ of systems value.
Once the process of investigation and analysis has been completed it’s normal for systems professionals to produce several (albeit conceptual) design alternatives.
For any design alternative to be a serious candidate for development the five TELOS feasibility factors must be highly rated.
The TELOS feasibility score of each potential design alternative will be part of the calculation of Systems Value used in the selection of the preferred design alternative recommended for development.
0 – Not feasible
5 – Moderately feasible
10 – Totally feasible
TELOS stands for: Technical, Economic, Legal, Operational, Schedule
PDM Strategic Factors rate a proposed system design on its potential or increasing productivity, augmenting product and service differentiation, and improving management decision making.
Well designed information systems are a significant benefit to the organisation by providing value in these areas, hence evaluating and comparing alternate design proposals on this basis will be a major influence on systems selection.
As with TELOS a Factor Rating Worksheet may be used to support the rating process.
Scores are given to each of the three factors and simple averaging derives the final score:
PDM stands for: Productivity, Differentiation (of company’s products or services), Management (usually helps all employees – especially managers)
Systems design quality’ is difficult to quantify but does depend directly on the aggregation of the MURRE design factors, namely:
MURRE stands for: Maintainability, Usability, Reusability, Reliability, Extendability
- measuring someting is objective, not subjective
- mesauring is repeatable and can be recorded
- we can compare other measurements and make benchmarks
Without measurement, things are down to luck.
Software metrics – measuring software, e.g. assessing a system – if the project is on course, budgetting, picking a particular system to solve a problem, etc
MTTF – mean time to failure