Archive | February, 2013

Systems Analyst Challenges

28 Feb

As outlined by my group members and myself we can clearly see that the systems analyst faces a lot of challenges in his/her role in building an IS for an organization. However these challenegs are not insurmountable. Often a finished IS is well executed by the systems analyst but does not meet the specific needs of the end users and it is the systems analyst that often gets the finger pointed at by the users for this problem no matter how well constructed the IS is. The systems analyst is the person who has to meet all the eventual users of the IS and find out exactly what it is they want to get from the finished system. Challenges can start to arise here such as if users want differing functions with the IS. This can give the analyst a headache in so far as the analyst will have to disappoint one if not more end users by going with one idea over another or perhaps coming up with one solution that incorpoates parts of the ideas from all the end users. Some end users may be difficult to deal with within an organization in that it can be hard to find out what it is they want from the system because of communication problems and unwillingness to participate in the requirements gathering stage. As the systems analyst has this huge amount of responsibility and the fact that there is a huge amount of money invested in these systems such as the $400 million Ford pumped into their purhasing system, the systems analyst is usually the one that gets blamed for problems with the IS unless of course it is a simple programming error. As well as not meeting all the end users requirements, the system could also be the vistim of a cyber attack and thus the systems analyst may also come under scrutiny if the correct system security architecture was not put in place by the analyst. These are just some of the challenges the system analyst faces in their role.2198664tov5o3v8

References:

http://www.techrepublic.com/blog/10things/10-things-you-should-know-about-hiring-a-business-or-systems-analyst/2360

http://www.cathaldoyle.com

 

Causes of I.S Failure

28 Feb

Many I.S systems fail because systems analysts try to build wonderful systems without even understanding the organistion. A common reason for I.S failures is the fact that companies buy a commercial off the shelf (COTS) package and customize it. The only way for a business to be successful with a (COTS) package, is that they must decide from the very outset that their going to reengineer their business to the limitations of the (COTS) package.

Heres just some famous examples of I.S failures with a costly effect:

– Ford motors in 2004 had their purchasing system abandoned after deployment costing approx $400 million.

-AT&T also in 2004 had problems with their customer relations management systems which led to costing them a $100 million loss.

http://www.hks.harvard.edu/…/…

The roles of teams in IS

28 Feb

Teams in information systems have an important role. They must identify the needs of the company and what they are looking to achieve with their information system before they go out and purchase a system they must ensure that it will be useful and beneficial to the company otherwise it will be a waste of finances that could have been used elsewhere. A lot of the time businesses find the information system they have purchased and installed does not meet their needs and expectations. Teams are put in place to carry out extensive research in order for this not to happen. This is largely the responsibility of the system analyst who reviews specifications, tests and documents the findings. An analyst will however have a team around them in order to carry this out in the most efficient manner. A well organised support team with clearly defined roles is important to the success of any information system. With the team carrying out extensive research into which system would be the best for the company it allows them to iron out problems before they occur. Also it enables the team to start work immediately once the system has been installed.

V-Model

28 Feb

According to Andrew Ratcliffe SAS Software Development with the V-Model:

 

Making sure it does what customers’ needs and in an appropriate way

The creation of the V-model seems to be a happy coincidence of events in the US and in Germany. Around the end of the 1980s, two separate software development teams happened upon the same fundamental idea and produced it as the V-model.

The V-model is now in wide use around the world, providing structure and focus to numerous projects.

The V-Model shows System Testing opposing the system requirements. System testing is about checking the system as a whole, not about checking the individual parts of the design. It treats the whole system as one big unit.

System testing can involve a number of specialist types of test to see if all the functional and non-functional requirements have been met. In addition to functional requirements these may include the following types of testing for the non-functional requirements:

• Performance – Are the performance criteria met?

• Volume – Can large volumes of information be handled?

• Stress – Can peak volumes of information be handled?

• Documentation – Is the documentation usable for the system?

• Robustness – Does the system remain stable under adverse circumstances?

Finally, User Acceptance Testing (UAT) is an opportunity for the customer to check that the system does what they need. It may sound like system testing but there’s a key difference: Systems testing checks that the system that was specified has been delivered, UAT checks that the system delivers what was requested. As its name implies, UAT is done by the users. The users should check that the system fits into the business processes that they choose to employ, and they should check that the documentation and training is adequate and fit for purpose.

It is not necessary to produce eight documents for each separate project (stages of the v-model).

It is quite common to deliver one document for the left-side of the V, and another for the right-side. These documents can be known as the Project Specification and the Test Specification, but names and terminology vary.

One of the most common concerns is “how much detail do I need to put into each document”. It can be answered without being clear on what the purpose of the document is. Each document typically has two purposes, i.e. to inform the next stage of verification/elucidation and to inform the associated stage of validation/testing. A third audience is the maintenance programmer (who has to fix bugs or add features six months down the line after moving to a new project, or employer, or retired). And having established those facts, the documents can be filled with the appropriate amount of detail.

The information that the V-Model framework specifies can be collected and stored in a variety of different ways and means.

Each of the stages (such as Business requirements and Design Specification) has to be a separate document. That doesn’t mean that any of this has to be typed into a Word Processor. If the code comments are prepared properly (and if coding guidelines permit) then it may not need to produce any documents for elucidation/verification.

It’s less easy to see how it can be avoided describing what intended to do for tests outside of a document, and there’s usually a demand to keep evidence of successful test runs, but each site is different so it must be judged each case on its merits.

 

Source: http://www.google.ie/url?sa=t&rct=j&q=&esrc=s&frm=1&source=web&cd=10&sqi=2&ved=0CGIQFjAJ&url=http%3A%2F%2Fsupport.sas.com%2Fresources%2Fpapers%2Fproceedings11%2F124-2011.pdf&ei=FEcvUaCHF4imhAe8jYBQ&usg=AFQjCNEe6TmplH37W6RbjhtSnFQpyapqeQ

 

Stage 4: Implementation

28 Feb

The fourth phase in SDLC is Implementation

It entails converting physical system specifications into a working system. The system is developed, tested and implemented.

This is a crucial step which involves converting from the old system to the new system. There are four types of conversions:

  1. Parallel [the old system + the new system are used while the new system is being tested, when the new system is working, the organization stops using the old system]
  2. Pilot [a small group of people use the new system while the rest of the organization continue to use the old system. when the new system is fully working for the pilot group, then the rest of the organization switch over and use the new system too]
  3. Phased [the organization switches from the old system to the new system one component/step at a time until the whole new system is fully in place]
  4. Plunge [this involves switching from the old system to the new system in one go]

Essentially what this phase entails is the construction and installation of the new system.

Some of the activities that occur in this stage include:

  • Coding {physical design specifications converted into a working computer code}
  • Integration and Testing {create a testing environment to bring all the components together, this could be done using one of the four conversion phases as mentioned above}
  • Installation {the new system is having the new system fully in place with all parts of the organization using it

An outcome of this phase is, obviously enough, a fully installed system across the organization. But the system will not operate properly unless users are fully trained to use the system which is a vital element of implementing the system. And another outcome is user and operational documentation.

The next phase in the SDLC is Maintenance. I will discuss this in my next blog post along with a quick overview/summary of the SDLC!

Sources:
http://databasemanagement.wikia.com/wiki/SDLC

http://www.youtube.com/watch?v=TjkUGA512CU

www.cathaldoyle.com

Upskilling Staff To Get Maximum Benefit From An Information System

28 Feb

The modern day manager of a business not only has to insure an adequate information system is installed but also has to ensure that the companies employees have the necessary skills and knowlege in order to get the maximum benefit from the information system. An information system can be wasted and underutilized  if the staff who use this system are not well equipped to use the information system, in order to ensure this problem doesn’t arise the manager must up skill his/her employees. Upskilling staff in the workplace is a fundamental strategy for personal and professional growth.

When a company introduces a new information system it is of vital importance that employees understand and can operate the information system in order to gain the maximum benefit that the information system can bring to the company. If staff members are not able to understand or operate the system they will became frustrated and disillusined with the system and this will damage employee productivity and staff moral.

The manager of the company must create an environment within the company that encourages constant learning and development of staff skills. Managers must allow for employee feedback to ensure all members of staff are well equipped to manage and understand the information system. Training of all staff members should commence before and during the introduction of the new system while constant feedback should be given by staff members.

Sources: http://www.magazinestoday.co.nz/Features/Tools++Tactics/Upskilling+Staff.html

The Waterfall Model – A Traditional Method of Software Design

28 Feb

The Waterfall Model is one of the most used SDLC Models. In this model, the software development process is in a linear sequential flow. This means that any phase in the development process begins only if the previous phase is complete. A review takes place at the end of each stage and when this is completed, the next stage can begin.

The waterfall approach is the earliest approach that was used for software development, originating in the manufacturing and construction industries – highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development. Initially, most projects followed the waterfall approach because they did not focus on changing requirements.

The Waterfall Model :

File:Waterfall model (1).svg

As previously outlined, the Waterfall Model is composed of various stages. The stages of a Waterfall Model are similar to thosE of a traditional SDLC :

1. Planning

2.Analysis

3. Logical Design

4. Physical Design

5. Implementation

6. Maintenance

These stages will be further discussed in later posts.

%d bloggers like this: