Characteristics of System Analyst in Choosing/Defining Deployment Environment

(Note: This is a reply to Mr. G.'s thread in USeP-IC Web Forum - Assignment 11: You were tasked by the IC-dean to evaluate the enrollment system of the university, list and briefly describe the characteristics that an anlayst(you) examines when choosing or defining deployment environment.)

 

 

The enrollment system of our university has always been under the bird’s-eye view of us, students and faculty as well from the Institute of Computing. It is one (or shall I say the most conspicuous part of the university) that it is constantly mentioned in most discussions especially when we talk of information systems. And now that we are undertaking system analysis and design and software engineering subjects, we investigate more of the systems and subsystems that have been developed, being executed and running, and those that need to be built and / or improved. That was quite reasonable, folks, of course where else could we first take a look upon except our own, right?

Our professor (allow me to acknowledge thou, Sir) has been encouraging us to feel and not just visualize the concrete view of information systems and experience the reality in the information technology industry, and a way of that is simply to study the systems and subsystems inside the university. Frankly speaking, there is a lot more that has to be examined, brought up to the administration’s attention, systems inside the campus which needs improvement. As a student and part of the university, I am one of the recipients of the services of the school; I am one of those who are affected by its functions; and I am also one responsible for its development and progress. Since we are all part of it, we are accountable for its degeneration and advancement for the simple reason that we fuel the university’s business.

If I were to evaluate (supposed the IC dean tapped me to do so), the status of the enrollment system of the university is running as to its functions. But I can not say that the system is up for its promptness, orderliness, and efficiency. We have experienced tapping the support of an outsource company in the operation of the enrollment system. Later on the administration withdrew because of the financial aspect – the university is spending much on the outsourcing part. So they tapped our able and competent faculty members who later on developed an information system which is now being used in the enrollment process. Furthermore, this system is still ongoing its enhancement as business continues. As I have said, there is still a lot more to improve in the current system. We have to cope up with the fast pace of technology, and taking into account the growing population of students enrolling, the university business has to meet the demands of its constituents and the industry in the present day.

Anyone may be able to point out where in particular the system needs boosting up. As long as he/she knows in detail the components that make up the system and its running procedure, he/she can target and list down the possible crucial points within the information system. For me, a system analyst has to have fundamental nature of curiosity. It is important to be curious about your environment, for this will give you the drive to examine deeper the things and events occurring within your surroundings. In the enrollment system, as an analyst I have to get to know what is happening in the procedures so I may know the problems and the causes of such. From which, I can use logical methods in solving these problems. That includes researching and understanding the systems and related subsystems. Choosing and defining the deployment environment needs a keen eye for details. One cannot easily lay out the structure of the system without specifying in details the necessary requirements. Of course an analyst has to clearly identify the outline of the expected system and without being able to target the appropriate elements he/she will not be able to address the problems eventually not making a well-defined output. Aiming for accuracy and completeness must also be possessed by a system analyst. When you intend to do something, you aspire to achieve the best solution you could ever give which meets the difficulty or hindrance. You have to define the functionalities of your system once deployed in an environment. In determining these, your goal in mind is to maximize its performance to its functions. Moreover, an analyst should anticipate possible changes that may take place in the future so he/she should be open and able to adapt to these changes. This will also reflect in the flexibility of system or deployment environment the analyst is choosing or defining.


Acknowledgment:

Microsoft Encarta Dictionary and Thesaurus

Characteristics of System Analyst in Evaluating Data Flow Diagram (DFD)

(Note: This is a reply to Mr. G.'s thread in USeP-IC Web Forum - Assignment 10: With reference to assignments 8 and 9, what characteristics does an analyst(you) examine when evalauating DFD quality?)

 

 

As a review, assignments 8 and 9 illustrate the activity diagram and data flow diagram of the university’s pre-enrollment system. These diagrams describe more or less the flow of the system based on the real and actual scenario in the school. Since there is a need to thoroughly understand the concepts of what is happening in the structure of the organization, the system analyst have to use these modeling techniques which will aid him or her in determining which components are lacking and needs attention. This is vital especially if the organization is aiming for progress and expansion.


Basically, when you are evaluating a particular system, you have to review the things and events that are involved in the processes. Requirements must be modeled out so to have a better representation and understanding. Apart from mathematical models which represent series of formulas and descriptive models which are narrative in forms, most models used in system analysis and design are graphical models being characterized by diagrams and schematic representations of some aspects of the system. Mainly, these models describe the details of what the system does when an event occurs. They are created to activities of information systems and interactions between computer processes and data.

There are however traditional (system is a collection of processes) and object-oriented (system is a collection of interacting objects) approaches to modeling system requirements. The data flow diagram (DFD) is one of the traditional approaches. Symbols that are used in data flow diagram comprise of the following:



Data flow diagrams (DFDs) are decomposed into additional diagrams to provide multiple levels of detail (System Analysis and Design in a Changing World, Satzinger et al). There are two classifications of the views in data flow diagrams: the higher – level diagrams and lower – level diagrams. Higher – level diagrams provide the general views of the system while the lower – level provide the detailed views of the system. Such differing views are termed as levels of abstractions. In a particular system, there could be many representations of data flow diagrams. The highest level or the most abstract view of the system is represented by context diagram. It is here where the data flow diagram summarizes the processing activity for the system or subsystem. The system scope in a context diagram is said to be represented by a single process, external agents, and all data which flows into and out of the system. DFD fragments are also created and represent the response of the system to an event within a single process symbol. These decomposed fragments also take the form of a lower – level diagram (sometimes called as diagram 0), which composed of detailed flow or just combined DFD fragments to model a specified view of the system.



Data flow diagrams are just one of the basic models being used by systems analysts in representing important and vital aspects of the system. As mentioned, DFDs alone have differing characteristics and these facets are not that easy to point out and visualize if the system analyst has not studied the procedures of the system in bird’s eye. Being very keen to detail is number one behavior for me that has to be possessed by a system analyst. You can just imagine the complexity that a single simple process of a system or subsystem can have that an analyst has to figure out and studied. Secondly, due to complexity of the system, an analyst needs to aim for accuracy and completeness. He/she must be able to define every event and thing involved and occurring within the activities of the system to be able to find out the components of the data flow diagram. He/she must be able to capture the overview of the running system, and make out a high-level DFD where the general view of the system is modeled out. Apart from being familiar of the system in whole, a system analyst now has to be familiar with the specific processes, expanding more of the general view into a more detailed data flow diagram combining DFD fragments into processes. As to my technique, I have yet to identify the overall course of action in the system and draft it as a context diagram. Then based on each major process, I examined each and expanded the diagram into a more specific diagram involving the fragments.



Furthermore, one quality of a data flow diagram that a system analyst has to make sure is that it should be readable. There might be individuals (probably clients) who are not into information systems and may not have knowledge about these matters. But it is important to know that they must also be able to comprehend the flow of the actual system as what and how the model describes it. Secondly, it has to be internally consistent and balanced. A data flow diagram model would not be able to explain a well-defined structure and process of the system if it is not balanced. Thus it should be internally coherent. Finally, and the most crucial, is that a data flow diagram must accurately represent the system requirements, for its goal is to characterize the procedure and the in and out flow of data in the running system. That’s what I’ve been stressing in the previous statements.




Many thanks to the resources I have used as my references and aid:

Chapter 4 Investigating System Requirements
Chapter 5 Modeling System Requirements
Chapter 6 Traditional Approach to Requirements
from System Analysis and Design in a Changing World by Satzinger, Jackson, and Burd

Microsoft Encarta Dictionaries and Thesaurus

Data Flow Diagrams of USEP Pre-enrollment System

(Note: This is a reply to Mr. G.'s thread in USeP-IC Web Forum - Assignment 9: Create at least 3 different types of Data flow diagram of USEP's pre-enrollment system)

 

Data Flow Diagram of USEP Pre-enrollment system

a.) Context Diagram -


-first type

b.) Exploded Diagram 1



-second type

c.) Exploded Diagram 2



-third type



Acknowledgment:
Edraw UML Diagram software


Feel free to drop by my blog, it's a soul's reflections
and write some comments... tnx!

Activity Diagram of USEP Pre-enrollment

(Note: This is a reply to Mr. G.'s thread in USeP-IC Web Forum - Assignment 8: Using the same narrative as refelcted in your assignment 4, develop an activity diagram and a fully developed description for a use case.)

I am not so sure if this is to be based upon assignment 4 (it discusses about system development models)... I presume this talks about USEP Pre-enrollment system again, so I based my activity diagrams on my assignment 7 (use cases)... :-)





General Description for Pre-enrollment Process

An applicant submits the needed requirements to the UGTO, and secure payment slip. Then he/she will pay the USEPAT fee at the cashier. The applicant will then show the official receipt to UGTO (proof/confirmation of payment) which will give the schedule for the exam. Next, the applicant gets the schedule and returns on the said date for the USEPAT. The UGTO takes charge of facilitating the entrance exam to the student applicant. The UGTO personnel also check the answer sheets and release the test results for the students to view. If a student applicant passes the exam, he/she can proceed to the interview process in the respective college/department where he/she applied for his/her chosen course. The faculty conducts the interview. If the student applicant passes the interview, he/she can continue on the medical examination and further to enrolment. If in case the student applicant fails in the English proficiency test, he/she is advised to take the English bridge class before proceeding to the enrollment process.



Acknowledgment:
Edraw UML Diagram software


Feel free to drop by my blog, it's a soul's reflections and write some comments... tnx!

Use Case of USEP Pre-enrollment System

(Note: This is a reply to Mr. G.'s thread in USeP-IC Web Forum - Assignment 7: Consider USEP's pre-enrollment system, develop a use case diagram and write a brief use case description.)

 A freshman who aspires to be a USEPIAN undergoes many processes before being officially enrolled in the university. Such pre-enrollment process covers the following described in the

USE CASE DIAGRAM




General Descriptions for USEP Pre-enrollment system

Use Case: Application
Actors: student applicant, UGTO
Scenario: The student submits all the necessary requirements for enrollment at the University Guidance and Testing Office (UGTO). This may include filling up the registration form, submit photos, etc. Applicant will now secure a payment order slip (POS) issued by UGTO…

Use Case: Payment of Test Fee
Actors: student applicant, cashier
Scenario: Student applicant now presents the POS to the cashier and pays the examination fee. In return, the cashier will issue official receipt…

Use Case: Examination schedule
Actors: student applicant, UGTO
Scenario: The student presents the receipt to UGTO and asks for the examination schedule. He/she will take the entrance exam on the said date in which the UGTO personnel shall administer the testing process. After a few days, the applicant gets the results of the exam, and after verifying the results, pass the results to the college…

Use Case: Interview process
Actors: student applicant, college dean/faculty
Scenario: If the student applicant passes the exam, he/she presents the result to the dean/faculty of the respective college of his/her chosen course. The student applicant shall now undergo the interview process conducted by the college dean/faculty. He/she will be given an admission slip or notice of acceptance if ever he/she is accepted…

*Use Case: English bridge
Actors: student applicant, English teacher
Scenario: If required (only if the student fails to pass the passing score of English test), the student applicant shall take the English bridge program of the university before enrolling…

*Use Case: Application
Actors: student applicant, medical doctor
Scenario: The student applicant also undergoes a medical examination before enrolling. He/she will be examined by the medical doctor in the university clinic to check his/her health condition…

If the student applicant passes all the tests, he/she can now proceed with the enrollment process (given that he/she has received an admission slip from the college/department of his/her chosen course).



Many thanks to www.usep.edu.ph and Edraw UML Diagram software...

The System Analyst vs The Department Manager on Developing an Information System

(Note: This is a reply to Mr. G.'s thread in USeP-IC Web Forum - Assignment 6: Consider the following 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?)

 

The situation stated above reminds me of similar scenarios that my software engineering professor told us – of the high tendency that a problem will not be given an ideal and right or best solution just because of miscommunication between the developer and the client. I just could imagine if the system developers and the clients often argue with the specifications of the project, how much more about these two professionals that have different views?

Most people from diverse line of work (or even mere individuals) disagree about certain matters especially when it is a highly critical issue that needs utmost and immediate attention as it would affect the persons involved or the organization in general. This usually happens when parties have different views on solving a particular problem. At some point in time, one person may think that his solution is better than the other who believes that his way is the better way out. Both of them may be right anyhow, but what is being weighed in here is of which consequences would solve the problem, yield far better results, and lesser expenditure and risks. That is, the benefits should outweigh the costs.

We understand that the situation above calls for a change or improvement in the information systems of the department which is managed by Peter Pedro, and the systems professional assigned is John Juan. It seems that Juan aims to investigate first the processes of the whole system, reviewing and observing the details of how the old system functions, and after that, determine which parts really needs improvements and are targeted for renovation or should be kept. On the other hand, Pedro believes that Juan’s style is just like any other he had experienced where the professional team suggests to make similar steps as mentioned by Juan then after all they (Pedro’s department) only gets the same old system but just slightly customized. Pedro now does not want to be confined in the old system so he recommends that they better identify a list of requirements for their system and let Juan and his team develop it.



Well, I could say that Juan was just being ‘economic’. I mean he was taking steps which are appropriate for an organization that could still benefit from the resources of the old system. After all, it needs thorough studying and planning to identify the problem or which particular component needs to be targeted before jumping into conclusions of making out the solution directly without checking if it is feasible enough to be applied. The approach that Juan is making is part of the initial phases of the system development life cycle.



Just a short review: systems (or software) development life cycle is a logical process undertaken by system analysts to develop an information system (wikipedia reference). It involves several phases necessary for the development, such as planning, analysis, design, and implementation. The usual first step in building up a system is initiation or planning. This is where the goals of the project is determined, or shall I say, the analyst or manager identifies the need or opportunity for improvement or a problem perhaps. So the concept is made for a proposal to the upper management. A feasibility study is typically conducted and this is to be submitted to the management in an attempt to gain funding. This is part of the analysis stage.

Systems analysis is done to determine where the problem is. Essentially, Juan is trying to analyze the situation and project goals, so in breaking down the elements of the system, the particular part which needs to be targeted can be recognized. In this way definite requirements can be defined. Requirements gathering sometimes call for the individuals or team who are involved in developing the information system in the organization. This is where Peter Pedro, the manager of the department where the new information systems be developed comes into view.

Requirements shall be well determined and defined so to give an accurate list of what should be aimed to develop, change, or improve in a system. In constructing or repairing a house, you must first then identify which parts you need to build, hammer, saw, or paint and elicit the materials and equipments you needed. Just like in solving any problem, you first identify the scope, the given, the steps you have to take before implementing the solution.

Gathering the right and accurate data is crucial in defining the requirements. It is because the specifications of the system to be developed depend largely on the requirements you have elicited. That is why, Mr. Pedro asserts to have a list of requirements to tell exactly what they wanted their system to do with their department.



Actually, in my view, both professionals have justified reasons in taking the initial steps in developing an information system. (I may say, they can combine forces. Haha.) But the point of their argument is rooted on the part of which step shall be taken and concentrated granting that the manager already mentioned they had the same experience before yet always getting back to the old system. I think the issue stems out from whether they should have to regain the old system or develop a new system.

They in fact have the same points, I just have taken note of the last statement emphasized by the department manager – “…just don’t constrain us with the old system.” With this, as a system analyst (but not having the actual look and feel of the real system), I should say I support the systems professional’s idea. Mr. Juan just needs to elicit the requirements of the system, yes, as it is also what Mr. Pedro wants. The only thing is, in developing a system, be it basically manual, semi-automated, or fully computerized, it does not necessarily mean to design and develop a new one. Maybe the idea of a new system in the form of a modified version doesn’t sound appealing to Mr. Pedro. Maybe he desires for an entire change. Hehe. That’s a form of resistance – to the analyst’s view.

The bottomline here is, why make out or build a project back from scratch when you can have the old system as basis and get back some old yet still usable portions from it? If Pedro was just being cautious that they might get a revised-but-still-got-from-the-old system when they are promised with a new one, I must say they deserve it. After all, the scenario didn’t mention something like “we always seem to get the old system back, though revised, but the outputs are just the same, no changes, no improvements” then I think he has the guts to say that his demands for an entire system should be met.


Ms. Charmaine Dayanan as part of John Juan's team: (ehem)

Their unified yearning to elicit the right requirements might be right, as it always should be. But I would like to say to you, Mr. Department Manager, that Mr Juan (my boss! hehe) would certainly keep his word that your new information system will address the needs of your department. We will first examine your old system (granting that your company just hired us and we knew nothing of your operations here), review some of your key documents, probably observe the workers perform their tasks (as they are the users of the system that we will be developing), so in that way we could determine which aspects are working well (and we will consider some parts which may be preserved too). Then we will acquire your list of requirements, the ones you consider as the elements that your system should be performing, identify the details and compare it to our data gathered. In that way, we could verify and agree on what method or strategy we shall make. But if ever we’ll find out that some parts of your old system is feasibly functional and performing its required task, we’ll think about it considering your case (demand).

What is more important to us is you will get what you needed, and not necessarily getting what you want. After all, we could spend less on revising your old system (that is if there is no great risk on your budget depending on the type of weak point/s) than possibly spending much on the new system. Well, cost-benefit is included in our feasibility analysis, Mr. Department Manager. If we’ll find that it would be costly on the resources to modify the old system then we would consider changing the entire system. We will just see to it that the benefits should outweigh the risks. And most importantly, you will surely get what your department needed. Okay, Mr. Department Manager? What do you think of my concept? Should we make a deal? :-)


Many thanks to wikipedia.org references in ‘systems development life cycle’ and Microsoft Encarta Dictionaries-Thesaurus for a lot of help…