Monday, May 31, 2010

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.

study study study
Acknowledgment:

Microsoft Encarta Dictionary and Thesaurus


bounce bounce bounce


lol! lol!

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.
bounce bounce bounce


study study study
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

lol! lol!

Friday, May 28, 2010

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


study study study study study study
Acknowledgment:
Edraw UML Diagram software

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