Wednesday, February 3, 2010

Analysis of Information System: Juan vs. Pedro


THE SCENARIO
The following is a dialogue between a systems professional, John Juan, and a manager of a department targeted for a new information system, Peter Pedro:

Juan: The way to go about the analysis is to first examine the old system, such as reviewing key documents and observing the workers perform their tasks. Then we can determine which aspects are working well and which should be preserved.

Pedro: We have been through these types of projects before and what always ends up happening is that we do not get the new system we are promised; we get a modified version of the old system.
Juan: Well, I can assure you that will not happen this time. We just want a thorough understanding of what is working well and what isn’t.
Pedro: I would feel much more comfortable if we first started with a list of our requirements. We should spend some time up-front determining exactly what we want the system to do for my department. Then you systems people can come in and determine what portions to salvage if you wish. Just don’t constrain us to the old system.
Required:
a.Obviously these two workers have different views on how the systems analysis phase should be conducted. Comment on whose position you sympathize with the most.
b.What method would you propose they take? Why?
For me, both methods are essential in creating and implementing new information system. But in the dialogue, the two personnel have their own ideas which would result to conflicts. Two have their own points on choosing one over the other. These ideas would convince you to choose one and then again, at some point to the other. Anyways, for me to decide to whom between the two I should share my sympathy with if it’s needed, I have to understand the points the two parties are implying.

JUAN'S POINT
Let us start with John Juan, who is said to be systems professional. As the title suggests, he has claimed an expertise in the field of systems development. So probably, his ideas are better for the department.
He points out that in analyzing the problem, it is better if they have to first examine the old system first. By reviewing the key documents and observing the workers perform their tasks and a lot of things pertaining to the old system. By that, they could determine the strengths and weaknesses of the existing system. By assessing it, they could provide solutions for the weaknesses and improvements for the strengths.
An organization planning to have anew information system starts with the analysis of the capacity and status of existing information system. Current status, system performance, different functionalities, advantages, disadvantages, risks and opportunities are being considered in the analysis process of developing the system. These data are needed to capture the current situation of the business process with regard to the existing system. It also helps explore the possibilities of expansion, revision or renewal of the current system involved. By that, the actual needs of the people involved will be answered. Information systems are big help in an organization to carry out their business processes. .
Assessing current information system is believed to be of considerable benefit when planning new information systems. The development of Information Systems Strategies is often performed through the support of frameworks. Some of these frameworks include the documentation of the existing practice regarding the existing system, while others are the merely result of theory development. Some are tried and trusted, while the other are unsuccessfully unused (in case of Peter Pedro’s department).
PEDRO'S POINT
At this end, we have to discuss the ideas of Peter Pedro, he said that assessing the strengths and weaknesses of an old system is not a successful method in getting new system. They have made different types of projects with the use of such method, and what they found out is just the modified version of the old system whose outcome doesn’t satisfy him.
With that idea, he stresses the need to identify the requirements which is the first phase of creating a new system rather than specifying the old system. He wants to evaluate the true needs of his department to come up with the system that suffice their wants.
A requirement is defined as a state or capacity needed by a user to solve a problem or achieve certain goals. It is “a must ” in the system. (IEEE Standard Glossary of Software Engineering Terminology). It is the basis for the succeeding development and verification processes of producing a system.
A successful system depends on the specification of the requirements. Even if you have lot of requirements gathered but it is insignificant to the system, then your system could be considered as incomplete and inconsistent. However, there are no systems ever created that is considered complete yet. That is why we have this systems evolution. But the goal here is to have at least “close to perfect system.”
Requirements engineering as a process involving requirements, helps earlier detection of errors which are much expensive if discovered later, forces clients study their requirements, and others.
Having captured significant requirements in the system is important in the agreement among the stakeholders involved. It is a good source for resource estimation. It improves the system’s quality.
There are two classifications of requirements: the Functional and the Nonfunctional Requirements. Functional requirements talks about the specific behavior of the system. It is the focus of acquiring requirements. On the other hand, Non-Functional Requirements cites the constraints on the over all quality of the system. Moreover, the classifications of the NON-functional requirements include Safety requirements, Security requirements, Interface requirements, Human engineering requirements Qualification requirements, Operational requirements, Maintenance requirements, Design constraints. Both requirements are important considerations in the system.
Requirements can be acquired through the following sources such as the customers or end-users for the user requirements and other stakeholders that are involved in the system such as the marketing experts, regulators and developer. Requirements can also be gotten through non-human source such as the other devices or systems in the environment.
Since Requirement Engineering is a systematic approach to acquire, analyze, validate, document and manage requirements, it includes a set of activities as in Requirements elicitation, Requirements analysis, Requirements specification and documentation, Requirements validation and Requirements management.
In the RE process, there are tow considered domains: the problem which tells about something that the organization want to solve by developing a system and the solution which speaks of the “system” that will be developed based on the requirements.
In the process of developing the system, the first to note is to understand the problem which comprises the elicitation and analysis activities. After which is to specify the solution which is in the form of specification and documentation activity. After the solution has been provided and then validated through the validation activity, is then implemented and managed in the management activity.
The ones who are responsible for preparing the requirements specification are the primary users itself, in this case, is the department. Another is the developer organisation in which the said process is considered as the first step in overall development contract, in this case, Juan’s and company or the systems people as Pedro cited. It can also be in the third party organisation .
MY POINT
After considering each point, my stand would be on the side of Peter Pedro, provided that the point of John Juan is also considered.
New system is created because of the imperfections found in the old system or because people in the organization cited a need to have a system which may answer their problems. Understanding the real problems is the aim of requirements elicitation which is said to be the main point of the department manager.
The problem can only be clearly understood by discovering who or what is really affected by the problem. In this case, the department manager knows what his department really needs. And so, he is able to identify the problems in his department. Even though the systems people are able to identify these by conducting an interview or company visit on the actual business process of the company, if he has a different way of establishing a new system, the definitely, it wouldn’t align with the actual needs of the organization.
In analyzing the problem, one has to establish their goals on why they develop a system. Goals are considered as requirements in themselves, particularly high level. Goals speak of the domains.
However, in providing the solutions to problems in the department, the point of the systems analyst should also be considered because of the constraints which are to have an existing system look-and-feel. In short, it is also a need to study the old system including its functionalities, the benefits and the weaknesses. By that, they can retain the comfort and the acceptance of the people in the department.
Therefore, in developing a new system for the department, the first step is to understand the problem by identifying the needs and requirements of the company. In addition, it is also a need to have knowledge with similar systems.
It is because identifying the requirements and understanding the functionalities of the system main factors for having a success in developing the project.
As to what method should they take, it is up to both parties on what method really suits in the type of system they are going to implement in the department.
THE METHOD
Choosing the type of methods require the considerations of the different factors. The department manager so as the systems analyst should consider a lot of things pertaining to the project such as the system scope, budget, the stakeholders, the time frame and other constraints. It also depends on what type of methodology they are comfortable with which is proven to bring success in the development of their system.
But for me, thinking that the system is planned to be implemented in a certain department of the company, I would consider Agile Methodologies. It is because developers won’t strive to have new methodologies if they are contented in the existing methodologies such as the waterfall, or traditional sequential development. However, each methodology is advantageous over the other in its own way.
But for this particular scenario, I introduce Agile methodogy simply because it offers the assessment to the direction of the project throughout the SDLC or Software development lifecycle. It is in the form of iterative process which implies the thorough inspection of each iterations. Unlike in Waterfall model (which inspired the Agile methodolgy), the developers using the said methodology will have many chances to acquire the acceptable requirements and to correct the errors until the system is finally implemented.
Agile Methodolgy is said to have “inspect-and-adapt” approach which can benefit the department in terms of financial budget and time allocations. As a result, the said methodology helps the organization to develop a system that will really answer their problem and can satisfy the head and the members.

REFERENCES:
http://f1.grp.yahoofs.com/v1/8B5pS1b6JbAzeFmbfZpSrg3aOA3qzkgewjVEz44kiuc9Y3p3xWo6gqvgXRwf2Ri0SCqmsro5PhdG8_QfVw2VDcYQciAmn7S6yw/Requirements%20Engineering.pdf
http://f1.grp.yahoofs.com/v1/8B5pSyHE4iMzeFmbto9-V6eivXHgrbcWmstA4r3T8a8w0F7fsMcN1KLk2wQqpFDsbXrJLVdJfiUqpte-k9syRWCIwDPpqD5Q_g/Requirements%20Elicitation.pdf
http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6VD0-3XNT1WB-2&_user=10&_coverDate=11%2F30%2F1999&_rdoc=1&_fmt=high&_orig=search&_sort=d&_docanchor=&view=c&_searchStrId=1191562378&_rerunOrigin=google&_acct=C000050221&_version=1&_urlVersion=0&_userid=10&md5=f7fb0e87de26c31fe33d7c0d88f383c9
http://agilemethodology.org/

No comments:

Post a Comment