Assignment 10
SAD 1
As a review, an analyst as designer:
In designing or modeling a system, an analyst must focus on the logical view of the system and not the physical. Also an analyst must take into account on what the system is to accomplish and don’t focus on how to accomplish the system specified.
A system designer or analysts will or can convert specific requirements to optimized system design which will help programmers to convert it to database design and as well as script design. He/ she provide capabilities that make it the industry leader in the database design and data modeling market. In addition to automating all of the traditional structured methods and also features advanced database engineering, transition to object oriented design, repository extensibility, distributed repository capabilities, and model permission controls.
In what I did during the previous assignments, where I designed different data flow representation in the process of the “Pre- Enrollment in USEP”, there are certain characteristic which I evaluated in order for me to provide data flow diagrams of good quality.
As a review, DFD as a modeling tool:
The DFD portrays the system in terms of its component pieces, with all interfaces among the components indicated. Also, DFD focuses on the movement of data between external entities and processes, and between processes and data stores.
DFD is used to perform structured analysis to determine logical requirements. It is a graphical tool, useful for communicating with users, managers, and other IS personnel. It is also useful for analyzing existing as well as proposed systems and it is a relatively simple technique to learn and use.
Data Flow Diagramming is a means of representing a system at any level of detail with a graphic network of symbols showing data flows, data stores, data processes, and data sources/destinations.
Characteristics Examined in Evaluating DFD:
1. Remember
(Also commonly referred to as recognition, recall, or rote knowledge.) Be able to remember or recognize terminology, definitions, facts, ideas, materials, patterns, sequences, methodologies, principles, etc.
2. Understand
Be able to read and understand descriptions, communications, reports, tables, diagrams, directions, regulations, etc.
3. Apply
Be able to apply ideas, procedures, methods, formulas, principles, theories, etc., in job-related situations.
4. Analyze
Be able to break down information into its constituent parts and recognize the parts’ relationship to one another and how they are organized; identify sublevel factors or salient data from a complex scenario.
5. Evaluate
Be able to make judgments regarding the value of proposed ideas, solutions, methodologies, etc., by using appropriate criteria or standards to estimate accuracy, effectiveness, economic benefits, etc.
6. Create
Be able to put parts or elements together in such a way as to show a pattern or structure not clearly there before; able to identify which data or information from a complex set is appropriate to examine further or from which supported conclusions can be drawn.
Guidelines for constructing DFDs
The guidelines include the following:
1. Choose meaningful names for processes, flows, stores, and terminators.
- identify the role that the person is carrying out, rather than the person’s name or identity.
2. Number the processes.
- As a convenient way of referencing the processes in a DFD, most systems analysts number each bubble. It doesn’t matter very much how you go about doing this — left to right, top to bottom, or any other convenient pattern will do — as long as you are consistent in how you apply the numbers.
3. Redraw the DFD as many times as necessary for esthetics.
- The purpose of a DFD is to accurately model the functions that a system has to carry out and the interactions between those functions. But another purpose of the DFD is to be read and understood, not only by the systems analyst who constructed the model, but by the users who are the experts in the subject matter. This means that the DFD should be readily understood, easily absorbed, and pleasing to the eye.
4. Avoid overly complex DFDs.
- In a real-world systems analysis project, the DFD that will have to be drawn, redrawn, and redrawn again, often as many as ten times or more, before it is (1) technically correct, (2) acceptable to the user, and (3) neatly enough drawn that you wouldn’t be embarrassed to show it to the board of directors in your organization. This may seem like a lot of work, but it is well worth the effort to develop an accurate, consistent, esthetically pleasing model of the requirements of your system.
5. Make sure the DFD is internally consistent and consistent with any associated DFDs.
- a number of rules and guidelines that help ensure the dataflow diagram is consistent with the other system models — the entity-relationship diagram, the state-transition diagram, the data dictionary, and the process specification. However, there are some guidelines that we use now to ensure that the DFD itself is consistent. The major consistency guidelines are these:
* Avoid infinite sinks, bubbles that have inputs but no outputs. These are also known by systems analysts
as “black holes,” in an analogy to stars whose gravitational field is so strong that not even light can escape.
* Avoid spontaneous generation bubbles; bubbles that have outputs but no inputs are suspicious, and generally incorrect. One plausible example of an output-only bubble is a random-number generator, but it is hard to imagine any other reasonable example.
* Beware of unlabeled flows and unlabeled processes.
* Beware of read-only or write-only stores. This guideline is analogous to the guideline about input-only
and output-only processes; a typical store should have both inputs and outputs.
Why They Aren’t Called “Rules”
The most important thing to remember is that there are no hard and fast rules when it comes to producing DFDs, but there are when it comes to valid data flows. For the most accurate DFDs, you need to become intimate with the details of the use case study and functional specification. This isn’t a cakewalk necessarily, because not all of the information you need may be present. Keep in mind that if your DFD looks like a Picasso, it could be an accurate representation of your current physical system. DFDs don’t have to be art; they just have to accurately represent the actual physical system for data flow.
Some Guidelines About Valid and Non- Valid Data Flows
Before embarking on developing your own data flow diagram, there are some general guidelines you should
be aware of. Data stores are storage areas and are static or passive; therefore, having data flow directly from one data store to another doesn't make sense because neither could initiate the communication. Data stores maintain data in an internal format, while entities represent people or systems external to them. Because data from entities may not be syntactically correct or consistent, it is not a good idea to have a data flow directly between a data store and an entity, regardless of direction. Data flow between entities would be difficult because it would be impossible for the system to know about any communication between them. The only type of communication that can be modeled is that which the system is expected to know or react to. Processes on DFDs have no memory, so it would not make sense to show data flows between two asynchronous processes (between two processes that may or may not be active simultaneously) because they may respond to different external events.
Therefore, data flow should only occur in the following scenarios:
· Between a process and an entity (in either direction)
· Between a process and a data store (in either
direction)
· Between two processes that can only run
simultaneously
Data Flow Diagram Principles
* The general principle in Data Flow Diagramming is that a system can be decomposed into subsystems, and subsystems can be decomposed into lower level subsystems, and so on.
* Each subsystem represents a process or activity in which data is processed. At the lowest level, processes can no longer be decomposed.
* Each 'process' (and from now on, by 'process' we mean subsystem and activity) in a DFD has the characteristics of a system.
* Just as a system must have input and output (if it is not dead), so a process must have input and output.
* Data enters the system from the environment; data flows between processes within the system; and data is produced as output from the system
1. A system can be decomposed into subsystems, and
subsystems can be further decomposed into lower level
subsystems.
2. Each subsystem represents a process or activity in which
data is processed.
3. At the lowest level, processes can no longer be decomposed.
4. Each 'process' has the characteristics of a system. A process
must have input and output.
5. Data enters the system from the environment, data flows
between processes within the system and data is produced
as output from the system.
Data Flow Diagram Rules
1. Any data flow leaving a process must be based on data that
are input to the process.
2. All data flows are named and the name reflects the data
flowing between processes, data stores, sources, or sinks.
3. Only data needed to perform the process should be an input
to the process.
4. A process should know nothing about, that is, be
independent of, any other process in the system, it should
References:
http://www.asq.org/certification/quality-process-analyst/bok.html
http://www.cmp.jobs/qa-analyst-1153.php
http://spot.colorado.edu/~kozar/DFDtechnique.html
Thursday, February 25, 2010
Thursday, February 18, 2010
Different types of Data Flow Diagram
Usep's Pre- Enrollment System
There are four(4) different types of Data Flow Diagram. These are:
1. Current Physical
- Process label includes an identification of the technology (people or systems) used to process the data
- Data flows and data stores are labeled with the actual name of the physical media on which data flow or in which data are stored
2. New Physical
- Represents the physical implementation of the new system
3. Current Logical
- Physical aspects of system are removed as much as possible
- Current system is reduced to data and processes that transform them
4. New Logical
- Includes additional functions
- Obsolete functions are removed
- Inefficient data flows are reorganized
There are four(4) different types of Data Flow Diagram. These are:
1. Current Physical
- Process label includes an identification of the technology (people or systems) used to process the data
- Data flows and data stores are labeled with the actual name of the physical media on which data flow or in which data are stored
2. New Physical
- Represents the physical implementation of the new system
3. Current Logical
- Physical aspects of system are removed as much as possible
- Current system is reduced to data and processes that transform them
4. New Logical
- Includes additional functions
- Obsolete functions are removed
- Inefficient data flows are reorganized
Thursday, February 11, 2010
Thursday, February 4, 2010
Consider USEP's pre-enrollment system, develop a use case diagram and write a brief use case description.
SAD Assignment 7
USEP Pre- Enrollment Procedure
Use Case: Requirements
Brief Description: The student must have all the requirements ready for application
Use Case: Application
Brief Description: The student will avail an application form from UGTO office or will be given by the in- charge.
Use Case: Payment
Brief Description: The student will have to pay for the application or entrance fee which will be handled by the cashier.
Use Case: Scheduling
Brief Description: The student will present the receipt and the UGTO member will issue a schedule for the exam.
Use Case: Entrance Exam
Brief Description: The student will take the exam at the given schedule which will be conduct the exam.
Use Case: Medical Exam
Brief Description: The student will have to take the medical exam after the entrance exam as part of the requirement which will be conducted by the clinic division.
Use Case: English Plus/ English Bridge
Brief Description: The student will have to take the English plus. If the student will not pass the exam, he/she will be required to take an English bridge program which is conducted by the UGTO staff.
Use Case: Interview
Brief Description: After the certificate has been given with the said English plus activity, they will proceed now to their desired college together with the other requirements. They will undergo for an interview which will be conducted by a college instructor.
Use Case: Qualified
Brief Description: The college instructor will post the qualified students. If that student is in the list, he/ she is now ready for enrollment.
Brief Description: The student must have all the requirements ready for application
Use Case: Application
Brief Description: The student will avail an application form from UGTO office or will be given by the in- charge.
Use Case: Payment
Brief Description: The student will have to pay for the application or entrance fee which will be handled by the cashier.
Use Case: Scheduling
Brief Description: The student will present the receipt and the UGTO member will issue a schedule for the exam.
Use Case: Entrance Exam
Brief Description: The student will take the exam at the given schedule which will be conduct the exam.
Use Case: Medical Exam
Brief Description: The student will have to take the medical exam after the entrance exam as part of the requirement which will be conducted by the clinic division.
Use Case: English Plus/ English Bridge
Brief Description: The student will have to take the English plus. If the student will not pass the exam, he/she will be required to take an English bridge program which is conducted by the UGTO staff.
Use Case: Interview
Brief Description: After the certificate has been given with the said English plus activity, they will proceed now to their desired college together with the other requirements. They will undergo for an interview which will be conducted by a college instructor.
Use Case: Qualified
Brief Description: The college instructor will post the qualified students. If that student is in the list, he/ she is now ready for enrollment.
Wednesday, February 3, 2010
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? (3000 words)
SAD Assignment 6
Role of each character
In my understanding with the given scenario, I can say that the character portrayed by John Juan who is a system professional mainly functions as the developer of the system and the other character Peter Pedro who is a manager of a department targeted for a new information system serves as the client.
General differences of each character
Although they are in the same field which is the IT industry, still they have their own job specification, title, profession and experiences. And in line with that, as presented in the dialogue or short conversation between both of the party, their approach in dealing with the conduction of a system analysis phase is mainly different aside from the fact that they have the same goal which is to provide a new information system for a certain company. To better understand their differences in dealing with the conduction of a system analysis phase and on how they have come up with their ways or solutions, let us try to know them and dig down deeper on their ideas respectively.
John Juan (A System Professional)
* What is a system professional?
A system professional or should I say a system analyst is a well educated person when it comes to system making. He/she is well rounded with the steps in making an effective system. He/she is capable enough to determine the clients or users problem, capable to define a system, capable to design a system, capable to implement a system and also capable to evaluate a system.
* His proposed idea
Therefore in line with his profession, he proposed the idea of examining the old system as the first way to go about the analysis of the proposed system. And that idea is just an application on what he learned in his profession.
Peter Pedro (Department Manager)
* What is a department manager?
In general, a manager manages the operational and fiscal activities of the department. Plan and develop systems and procedures to improve the operating quality and efficiency of the department. Supervise staff in accordance with company policies and procedures. A manager is also responsible for hiring, training, and coaching employees.
* His proposed idea
A manager is well exposed in layout and performance of a current system or a company. And in any problem existence, a manager is the one who is observant enough. And to relate in his field, he proposed the idea of directly listing the requirements and focus only on the proposed or future system and do not just dwell on the existing or current system in the analysis of the proposed system.
My comparison between both ideas
John Juan just applied a step by step process in the system analysis phase. While Peter Pedro jumped into the realization of listing the new specified system requirements for him to get rid of the existing system. As stated in the dialogue, Peter Pedro already had the experience of trying to make a new system but the assigned analyst just developed the existing one and did not address well his requirements. That is why he has his reason on why he wanted to get rid of the older system.
But which idea is more brilliant enough in terms of the system analysis phase? Let us try to define what system analysis is and what the steps are in order to analyze a system for us to design a good system which answers our client’s requirements or concern.
What is system analysis?
There are many different definitions about systems developed over time. The word “system” can be defined in many ways. First, system is a set of interrelated elements each of which is related directly or indirectly to every other element, and no subset of which is unrelated to any other subset. Second, system in a set of objects together with relationships between the objects and between their attributes connected or related to each other and to their environment in such a manner as to form an entirety or whole. These definitions seem to place more emphasis on the elements (activities) and do not emphasize the individual\\\'s perceptions. Other system definition is that system is a mental construct of parts and relationships which make up a whole that explains that system is not just activities but concepts, problems, or an organization.
While “analysis” is performed to determine what is needed or determine you want to improve in a part of the organization (look for needs) or to fix a problem that someone has brought forth.
The term “systems analysis” is reserved for the study of systems that include the human element and behavioral relationships between the system\\\'s human element and its physical and mechanical components, if any. Examples of public policy systems are the federal government\\\'s welfare system, a state\\\'s criminal justice system, a county\\\'s educational system, a city\\\'s public safety system, and an area\\\'s waste management system. Examples of industrial systems are a manufacturer\\\'s production distribution system and an oil company\\\'s exploration, production, refining, and marketing system. Examples with physical environmental components are the atmospheric system and a water supply system. The direct transfer of systems engineering concepts to the study of a system in which the human element must be considered is restricted by limitations in the ability to comprehend and quantify human interactions. (Operations research, a related field of study, is directed toward the analysis of components of such systems. Public policy analysis is the term used for a system study of a governmental problem area.)
Systems analysis is the interdisciplinary part of science,
dealing with analysis of sets of interacting entities, the systems, often prior to their automation as computer systems, and the interactions within those systems. This field is closely related to operations research. It is also \\\"an explicit formal inquiry carried out to help someone, referred to as the decision maker, identify a better course of action and make a better decision than he might have otherwise made. It is the study of an activity or procedure to determine the desired end and the most efficient method of obtaining this end. Systems analysis in information processing is a phase of systems engineering.
The systems analysis process is an iterative one that cycles repeatedly through the following interrelated and somewhat the same
phases:
(1) Problem statement, in which the system is defined in terms of its environment, goals, objectives, constraints, criteria, actors (decision makers, participants in the system,
impacted constituency), and other objects and their attributes;
(2) Alternative designs, in which solutions are identified;
(3) Mathematical formulation, in which a mathematical description of the system is developed, tested, and validated;
(4) Evaluation of alternatives, in which the mathematical model is used to evaluate and rank the possible alternative designs by means of the criteria; and
(5) Selection and implementation of the most preferred solution.
The process includes feedback loops in which the outcomes of each phase are reconsidered based on the analyses and outcomes of the other phases. For example, during the implementation phase, constraints may be uncovered that blocks the solution\\\'s implementation and thus cause the mathematical model to be reformulated. The analysis process continues until there is evidence that the mathematical structure is suitable; that is, it has enough validity to yield answers that are of value to the system designers or the decision maker.
What occurs in the system analysis phase?
In this phase, we begin to move toward the future; the team analyzes the desired system, not the current system. This is where new ideas, features, and design changes should be introduced. The team focuses more closely on the transactions and events that make up the process.
The primary participants in this phase are the members of the core facilitation team, with the extended team identified for the system analysis phase during the previous phase. The extended team may be the same as that for the business analysis phase, or it may be different, but it should include extended team members who are knowledgeable about the business function, the systems that interface with this system, or the architecture or data requirements for the
system.
The team must stay focused on system analysis, not design decisions, and especially screen design or content.
In the final steps of this phase, the team focuses on creating or refining the plan for the completion of the project. This is when the requirements are developed, the remaining project phases are scheduled, the resources are identified and scheduled, and the deliverables are identified.
The development of a computer-based information system often comprises the use of a systems analyst. When a computer-based information system is developed, systems analysis (according to the Waterfall model) would constitute the following steps:
* The development of a feasibility study, involving determining whether a project is economically, socially, technologically and organizationally feasible.
* Conducting fact-finding measures, designed to ascertain the requirements of the system\\\'s end-users. These typically span interviews, questionnaires, or visual observations of work on the existing system.
* Gauging how the end-users would operate the system (in terms of general experience in using computer hardware/software), what the system would be used for etc.
Systems Analysis Procedures
1. Problem identification
There must be a clear identification and definition of the problem to be studied included scope (from one point to another point in time) of the process and overall criteria of effectiveness, efficiency, and adaptability.
2. FeasibilityStudy
The term \\\"Feasibility study\\\" implies a study of the practicality of a proposed project. It involves a preliminary analysis of the total requirements needed for the evaluation of the problem. Some problems might be easily defined but also might be too large to study adequately. In addition, it might not be possible to obtain all required information about a problem or there might be legal problems concerned with the analysis of the problem.
3. System definition (detailed study)
The purpose of this phase is to obtain a clear, concise and bounded definition. The subject of the proposal and its limits, and well as the objectives and anticipated benefits, should be specified. This section covers a wide range of activities: (1) investigation of the current (existing) system, and (2) analysis of the results, and (3) identification of the problemsin the current system.
4. Systems Design
The purpose of this phase is to suggest changes to transform the current system by altering the performance and activities to solve the problems.
5. System Implementation
Implement the said system.
6. System Evaluation
This section is included to reevaluate the effectiveness, efficiency, and adaptability of the changes that were made to the process.
Whose idea would I prefer?
After reviewing the proper conduct on the system analysis phase, I found out that the two characters in the short dialogue conversation have their own ideas interpreted correctly. Means that I do not choose any party at all, in fact I believe that those ideas both composes the main procedures in analyzing a system. As proof of my answer, I was able to research a diagram that shows the proper system requirements analysis. As shown below:
Figure 4.2: SD1 - System Requirement Analysis
As labeled #1 in the figure, it is comprise of the “External Specification”. To relate in the dialogue, I believe that it is the ides that is presented by Peter Pedro which is to list down the specified general system requirements. It will serve as the basis or goal of the desired system.
As labeled #2 in the figure, it is comprise of the “Recording of Actual Status and Analysis” which is the idea laid by John Juan. It is basically the first step in the analysis from which the older system will serve as the basic point in the analysis or development. It is one way of determining some logs or system deficiency that could hopefully be answered or developed.
Next are steps in the detailed analysis of the system.
As labeled #3 in the figure, here comes the user or client’s requirements that are specifically defined. Therefore as concluded, the specific requirements lay by Peter Pedro or the client which is somehow already addressed.
Method I would like to propose and why?
I have researched in Wikipedia about this method in systems analysis. i suggest that both characters, John Juan and Peter Pedro must be knowledgeable in this method so that they will share opinions and so that they will not argue no more...
Structured Systems Analysis and Design Method (SSADM) is a systems approach to the analysis and design of information systems.
The three most important techniques that are used in SSADM are:
Logical Data ModelingThis is the process of identifying, modeling and documenting the
data requirements of the system being designed. The data are separated
into entities (things about which a business needs to record
information) and relationships (the associations between the entities).Data Flow ModelingThis is the process of identifying, modeling and documenting how
data moves around an information system. Data Flow Modeling examines
processes (activities that transform data from one form to another),
data stores (the holding areas for data), external entities (what sends
data into a system or receives data from a system), and data flows
(routes by which data can flow).Entity Behavior ModelingThis is the process of identifying, modeling and documenting the
events that affect each entity and the sequence in which these events
occur.
The SSADM method involves the application of a sequence of analysis,
documentation and design tasks concerned with the following.
Analysis of the current system
* Develop a Business Activity Model. A model of the business activity
is built. Business events and business rules would also be investigated
as an input to the specification of the new automated system.
* Investigate and define requirements. The objective of this step is
to identify the problems associated with the current environment that
are to be resolved by the new system. It also aims to identify the
additional services to be provided by the new system and users of the
new system.
* Investigate current processing. It investigates the information
flow associated with the services currently provided, and describes
them in the form of Data Flow Model. At this point, the Data Flow Model
represents the current services with all their deficiencies. No attempt
is made to incorporate required improvement, or new facilities.
* Investigate current data. This step is to identify and describe the
structure of the system data, independently of the way the data are
currently held and organized. It produces a model of data that supports
the current services.
* Derive logical view of current services. The objective of this step
is to develop a logical view of the current system that can be used to
understand problems with the current system.
Outline business specification
Also known as: logical system specification stage. This stage
consists of 2 parts. The first part is researching the existing
environment. In this part, system requirements are identified and the
current business environment is modeled. Modeling consists of creating
a DFD and LDS (Logical Data Structure) for processes and data
structures that are part of the system. In the second part, BSO
(Business Systems Options), 6 business options are presented. One of
the options is selected and built.
The following steps are part of this stage:
* Define BSOs. This step is concerned with identifying a number of
possible system solutions that meet the defined requirements from which
the users can select.
* Select BSO. This step is concerned with the presentation of the
BSOs to users and the selection of the preferred option. The selected
option defines the boundary of the system to be developed in the
subsequent stages.
Detailed business specification
Also known as: requirements specification stage. To assist the
management to make a sound choice, a number of business system options,
each describing the scope and functionalities provided by a particular
development/implementation approach, are prepared and presented to
them. These options may be supported by technical documentation such as
Work Practice Model, LDM (Logical Data Model) and DFD. They also
require financial and risk assessments to be prepared, and need to be
supported by outline implementation descriptions.
The following steps are part of this stage:
* Define required system processing. This step is to amend the
requirements to reflect the selected Business System Option, to
describe the required system in terms of system data flows and to
define the user roles within the new system.
* Develop required data model. This step is undertaken in parallel
with the above step. The LDM of the current environment is extended to
support all the processing in the selected business system option.
* Derive system functions. During the parallel definition of data and
processing, additional events are identified, which cause existing
functions to be updated, and new functions to be defined. Service level
requirements for each function are also identified in this step.
* Develop user job specifications. A Work Practice Model is developed to document the understanding of the user jobs in concern.
* Enhance required data model. Its objective is to improve the
quality of the required system LDM by the application of relational
data analysis (also known as normalization).
* Develop specification prototypes. It is used to describe selected
parts of the required system in an animated form, for demonstration to
the users. The purpose is to demonstrate that the requirements have
been properly understood and to establish additional requirements
concerning the style of the user interface.
* Develop processing specification. This step is principally
concerned with defining the detailed update and enquiry processing for
the required system.
* Confirm system objectives. During stage 1 and 3, the requirements
will have been recorded, as they are identified, in the user
requirements. This step represents the final review of the requirements
before the completion of the Definition of Requirements Stage.
Logical data design
Also known as: logical system specification stage. In this stage,
technically feasible options are chosen. The development/implementation
environments are specified based on this choice. The following steps
are part of this stage:
* Define TSOs: Up to 6 technical options (specifying the development
and implementation environments) are produced, one being selected.
* Select TSOs. Select the most favourable TSO
Logical process design
Also known as: logical system specification stage. In this stage,
logical designs and processes are updated. Additionally, the dialogs
are specified as well. The following steps are part of this stage:
* Define user dialogue. This step defines the structure of each
dialogue required to support the on-line functions and identifies the
navigation requirements, both within the dialogue and between dialogues.
* Define update processes. This is to complete the specification of
the database updating required for each event and to define the error
handling for each event.
* Define inquiry processes. This is to complete the specification of
the database enquiry processing and to define the error handling for
each inquiry.
*
Physical design
The objective of this stage is to specify the physical data and
process design, using the language and features of the chosen physical
environment and incorporating installation standards. The following
activities are part of this stage:
* Prepare for physical design
* Learn the rules of the implementation environment
* Review the precise requirements for logical to physical mapping
* Plan the approach
* Complete the specification of functions
* Incrementally and repeatedly develop the data and process designs
References:
http://infolab.stanford.edu/~burback/watersluice/node4.html
http://webware.princeton.edu/dms/public/methodology/dev/sysabase.html
http://www.hrvillage.com/hrjobdesc/Manager.htm
http://en.wikipedia.org/wiki/Requirements_analysis
http://www.engr.sjsu.edu/pabacker/systems.html
http://www.nwlink.com/~donclark/analysis/analysis.html
http://en.wikipedia.org/wiki/Systems_analysis
http://www.answers.com/topic/systems-analysis
http://en.wikipedia.org/wiki/Structured_Systems_Analysis_and_Design_Method
Role of each character
In my understanding with the given scenario, I can say that the character portrayed by John Juan who is a system professional mainly functions as the developer of the system and the other character Peter Pedro who is a manager of a department targeted for a new information system serves as the client.
General differences of each character
Although they are in the same field which is the IT industry, still they have their own job specification, title, profession and experiences. And in line with that, as presented in the dialogue or short conversation between both of the party, their approach in dealing with the conduction of a system analysis phase is mainly different aside from the fact that they have the same goal which is to provide a new information system for a certain company. To better understand their differences in dealing with the conduction of a system analysis phase and on how they have come up with their ways or solutions, let us try to know them and dig down deeper on their ideas respectively.
John Juan (A System Professional)
* What is a system professional?
A system professional or should I say a system analyst is a well educated person when it comes to system making. He/she is well rounded with the steps in making an effective system. He/she is capable enough to determine the clients or users problem, capable to define a system, capable to design a system, capable to implement a system and also capable to evaluate a system.
* His proposed idea
Therefore in line with his profession, he proposed the idea of examining the old system as the first way to go about the analysis of the proposed system. And that idea is just an application on what he learned in his profession.
Peter Pedro (Department Manager)
* What is a department manager?
In general, a manager manages the operational and fiscal activities of the department. Plan and develop systems and procedures to improve the operating quality and efficiency of the department. Supervise staff in accordance with company policies and procedures. A manager is also responsible for hiring, training, and coaching employees.
* His proposed idea
A manager is well exposed in layout and performance of a current system or a company. And in any problem existence, a manager is the one who is observant enough. And to relate in his field, he proposed the idea of directly listing the requirements and focus only on the proposed or future system and do not just dwell on the existing or current system in the analysis of the proposed system.
My comparison between both ideas
John Juan just applied a step by step process in the system analysis phase. While Peter Pedro jumped into the realization of listing the new specified system requirements for him to get rid of the existing system. As stated in the dialogue, Peter Pedro already had the experience of trying to make a new system but the assigned analyst just developed the existing one and did not address well his requirements. That is why he has his reason on why he wanted to get rid of the older system.
But which idea is more brilliant enough in terms of the system analysis phase? Let us try to define what system analysis is and what the steps are in order to analyze a system for us to design a good system which answers our client’s requirements or concern.
What is system analysis?
There are many different definitions about systems developed over time. The word “system” can be defined in many ways. First, system is a set of interrelated elements each of which is related directly or indirectly to every other element, and no subset of which is unrelated to any other subset. Second, system in a set of objects together with relationships between the objects and between their attributes connected or related to each other and to their environment in such a manner as to form an entirety or whole. These definitions seem to place more emphasis on the elements (activities) and do not emphasize the individual\\\'s perceptions. Other system definition is that system is a mental construct of parts and relationships which make up a whole that explains that system is not just activities but concepts, problems, or an organization.
While “analysis” is performed to determine what is needed or determine you want to improve in a part of the organization (look for needs) or to fix a problem that someone has brought forth.
The term “systems analysis” is reserved for the study of systems that include the human element and behavioral relationships between the system\\\'s human element and its physical and mechanical components, if any. Examples of public policy systems are the federal government\\\'s welfare system, a state\\\'s criminal justice system, a county\\\'s educational system, a city\\\'s public safety system, and an area\\\'s waste management system. Examples of industrial systems are a manufacturer\\\'s production distribution system and an oil company\\\'s exploration, production, refining, and marketing system. Examples with physical environmental components are the atmospheric system and a water supply system. The direct transfer of systems engineering concepts to the study of a system in which the human element must be considered is restricted by limitations in the ability to comprehend and quantify human interactions. (Operations research, a related field of study, is directed toward the analysis of components of such systems. Public policy analysis is the term used for a system study of a governmental problem area.)
Systems analysis is the interdisciplinary part of science,
dealing with analysis of sets of interacting entities, the systems, often prior to their automation as computer systems, and the interactions within those systems. This field is closely related to operations research. It is also \\\"an explicit formal inquiry carried out to help someone, referred to as the decision maker, identify a better course of action and make a better decision than he might have otherwise made. It is the study of an activity or procedure to determine the desired end and the most efficient method of obtaining this end. Systems analysis in information processing is a phase of systems engineering.
The systems analysis process is an iterative one that cycles repeatedly through the following interrelated and somewhat the same
phases:
(1) Problem statement, in which the system is defined in terms of its environment, goals, objectives, constraints, criteria, actors (decision makers, participants in the system,
impacted constituency), and other objects and their attributes;
(2) Alternative designs, in which solutions are identified;
(3) Mathematical formulation, in which a mathematical description of the system is developed, tested, and validated;
(4) Evaluation of alternatives, in which the mathematical model is used to evaluate and rank the possible alternative designs by means of the criteria; and
(5) Selection and implementation of the most preferred solution.
The process includes feedback loops in which the outcomes of each phase are reconsidered based on the analyses and outcomes of the other phases. For example, during the implementation phase, constraints may be uncovered that blocks the solution\\\'s implementation and thus cause the mathematical model to be reformulated. The analysis process continues until there is evidence that the mathematical structure is suitable; that is, it has enough validity to yield answers that are of value to the system designers or the decision maker.
What occurs in the system analysis phase?
In this phase, we begin to move toward the future; the team analyzes the desired system, not the current system. This is where new ideas, features, and design changes should be introduced. The team focuses more closely on the transactions and events that make up the process.
The primary participants in this phase are the members of the core facilitation team, with the extended team identified for the system analysis phase during the previous phase. The extended team may be the same as that for the business analysis phase, or it may be different, but it should include extended team members who are knowledgeable about the business function, the systems that interface with this system, or the architecture or data requirements for the
system.
The team must stay focused on system analysis, not design decisions, and especially screen design or content.
In the final steps of this phase, the team focuses on creating or refining the plan for the completion of the project. This is when the requirements are developed, the remaining project phases are scheduled, the resources are identified and scheduled, and the deliverables are identified.
The development of a computer-based information system often comprises the use of a systems analyst. When a computer-based information system is developed, systems analysis (according to the Waterfall model) would constitute the following steps:
* The development of a feasibility study, involving determining whether a project is economically, socially, technologically and organizationally feasible.
* Conducting fact-finding measures, designed to ascertain the requirements of the system\\\'s end-users. These typically span interviews, questionnaires, or visual observations of work on the existing system.
* Gauging how the end-users would operate the system (in terms of general experience in using computer hardware/software), what the system would be used for etc.
Systems Analysis Procedures
1. Problem identification
There must be a clear identification and definition of the problem to be studied included scope (from one point to another point in time) of the process and overall criteria of effectiveness, efficiency, and adaptability.
2. FeasibilityStudy
The term \\\"Feasibility study\\\" implies a study of the practicality of a proposed project. It involves a preliminary analysis of the total requirements needed for the evaluation of the problem. Some problems might be easily defined but also might be too large to study adequately. In addition, it might not be possible to obtain all required information about a problem or there might be legal problems concerned with the analysis of the problem.
3. System definition (detailed study)
The purpose of this phase is to obtain a clear, concise and bounded definition. The subject of the proposal and its limits, and well as the objectives and anticipated benefits, should be specified. This section covers a wide range of activities: (1) investigation of the current (existing) system, and (2) analysis of the results, and (3) identification of the problemsin the current system.
4. Systems Design
The purpose of this phase is to suggest changes to transform the current system by altering the performance and activities to solve the problems.
5. System Implementation
Implement the said system.
6. System Evaluation
This section is included to reevaluate the effectiveness, efficiency, and adaptability of the changes that were made to the process.
Whose idea would I prefer?
After reviewing the proper conduct on the system analysis phase, I found out that the two characters in the short dialogue conversation have their own ideas interpreted correctly. Means that I do not choose any party at all, in fact I believe that those ideas both composes the main procedures in analyzing a system. As proof of my answer, I was able to research a diagram that shows the proper system requirements analysis. As shown below:
Figure 4.2: SD1 - System Requirement Analysis
As labeled #1 in the figure, it is comprise of the “External Specification”. To relate in the dialogue, I believe that it is the ides that is presented by Peter Pedro which is to list down the specified general system requirements. It will serve as the basis or goal of the desired system.
As labeled #2 in the figure, it is comprise of the “Recording of Actual Status and Analysis” which is the idea laid by John Juan. It is basically the first step in the analysis from which the older system will serve as the basic point in the analysis or development. It is one way of determining some logs or system deficiency that could hopefully be answered or developed.
Next are steps in the detailed analysis of the system.
As labeled #3 in the figure, here comes the user or client’s requirements that are specifically defined. Therefore as concluded, the specific requirements lay by Peter Pedro or the client which is somehow already addressed.
Method I would like to propose and why?
I have researched in Wikipedia about this method in systems analysis. i suggest that both characters, John Juan and Peter Pedro must be knowledgeable in this method so that they will share opinions and so that they will not argue no more...
Structured Systems Analysis and Design Method (SSADM) is a systems approach to the analysis and design of information systems.
The three most important techniques that are used in SSADM are:
Logical Data ModelingThis is the process of identifying, modeling and documenting the
data requirements of the system being designed. The data are separated
into entities (things about which a business needs to record
information) and relationships (the associations between the entities).Data Flow ModelingThis is the process of identifying, modeling and documenting how
data moves around an information system. Data Flow Modeling examines
processes (activities that transform data from one form to another),
data stores (the holding areas for data), external entities (what sends
data into a system or receives data from a system), and data flows
(routes by which data can flow).Entity Behavior ModelingThis is the process of identifying, modeling and documenting the
events that affect each entity and the sequence in which these events
occur.
The SSADM method involves the application of a sequence of analysis,
documentation and design tasks concerned with the following.
Analysis of the current system
* Develop a Business Activity Model. A model of the business activity
is built. Business events and business rules would also be investigated
as an input to the specification of the new automated system.
* Investigate and define requirements. The objective of this step is
to identify the problems associated with the current environment that
are to be resolved by the new system. It also aims to identify the
additional services to be provided by the new system and users of the
new system.
* Investigate current processing. It investigates the information
flow associated with the services currently provided, and describes
them in the form of Data Flow Model. At this point, the Data Flow Model
represents the current services with all their deficiencies. No attempt
is made to incorporate required improvement, or new facilities.
* Investigate current data. This step is to identify and describe the
structure of the system data, independently of the way the data are
currently held and organized. It produces a model of data that supports
the current services.
* Derive logical view of current services. The objective of this step
is to develop a logical view of the current system that can be used to
understand problems with the current system.
Outline business specification
Also known as: logical system specification stage. This stage
consists of 2 parts. The first part is researching the existing
environment. In this part, system requirements are identified and the
current business environment is modeled. Modeling consists of creating
a DFD and LDS (Logical Data Structure) for processes and data
structures that are part of the system. In the second part, BSO
(Business Systems Options), 6 business options are presented. One of
the options is selected and built.
The following steps are part of this stage:
* Define BSOs. This step is concerned with identifying a number of
possible system solutions that meet the defined requirements from which
the users can select.
* Select BSO. This step is concerned with the presentation of the
BSOs to users and the selection of the preferred option. The selected
option defines the boundary of the system to be developed in the
subsequent stages.
Detailed business specification
Also known as: requirements specification stage. To assist the
management to make a sound choice, a number of business system options,
each describing the scope and functionalities provided by a particular
development/implementation approach, are prepared and presented to
them. These options may be supported by technical documentation such as
Work Practice Model, LDM (Logical Data Model) and DFD. They also
require financial and risk assessments to be prepared, and need to be
supported by outline implementation descriptions.
The following steps are part of this stage:
* Define required system processing. This step is to amend the
requirements to reflect the selected Business System Option, to
describe the required system in terms of system data flows and to
define the user roles within the new system.
* Develop required data model. This step is undertaken in parallel
with the above step. The LDM of the current environment is extended to
support all the processing in the selected business system option.
* Derive system functions. During the parallel definition of data and
processing, additional events are identified, which cause existing
functions to be updated, and new functions to be defined. Service level
requirements for each function are also identified in this step.
* Develop user job specifications. A Work Practice Model is developed to document the understanding of the user jobs in concern.
* Enhance required data model. Its objective is to improve the
quality of the required system LDM by the application of relational
data analysis (also known as normalization).
* Develop specification prototypes. It is used to describe selected
parts of the required system in an animated form, for demonstration to
the users. The purpose is to demonstrate that the requirements have
been properly understood and to establish additional requirements
concerning the style of the user interface.
* Develop processing specification. This step is principally
concerned with defining the detailed update and enquiry processing for
the required system.
* Confirm system objectives. During stage 1 and 3, the requirements
will have been recorded, as they are identified, in the user
requirements. This step represents the final review of the requirements
before the completion of the Definition of Requirements Stage.
Logical data design
Also known as: logical system specification stage. In this stage,
technically feasible options are chosen. The development/implementation
environments are specified based on this choice. The following steps
are part of this stage:
* Define TSOs: Up to 6 technical options (specifying the development
and implementation environments) are produced, one being selected.
* Select TSOs. Select the most favourable TSO
Logical process design
Also known as: logical system specification stage. In this stage,
logical designs and processes are updated. Additionally, the dialogs
are specified as well. The following steps are part of this stage:
* Define user dialogue. This step defines the structure of each
dialogue required to support the on-line functions and identifies the
navigation requirements, both within the dialogue and between dialogues.
* Define update processes. This is to complete the specification of
the database updating required for each event and to define the error
handling for each event.
* Define inquiry processes. This is to complete the specification of
the database enquiry processing and to define the error handling for
each inquiry.
*
Physical design
The objective of this stage is to specify the physical data and
process design, using the language and features of the chosen physical
environment and incorporating installation standards. The following
activities are part of this stage:
* Prepare for physical design
* Learn the rules of the implementation environment
* Review the precise requirements for logical to physical mapping
* Plan the approach
* Complete the specification of functions
* Incrementally and repeatedly develop the data and process designs
References:
http://infolab.stanford.edu/~burback/watersluice/node4.html
http://webware.princeton.edu/dms/public/methodology/dev/sysabase.html
http://www.hrvillage.com/hrjobdesc/Manager.htm
http://en.wikipedia.org/wiki/Requirements_analysis
http://www.engr.sjsu.edu/pabacker/systems.html
http://www.nwlink.com/~donclark/analysis/analysis.html
http://en.wikipedia.org/wiki/Systems_analysis
http://www.answers.com/topic/systems-analysis
http://en.wikipedia.org/wiki/Structured_Systems_Analysis_and_Design_Method
Subscribe to:
Posts (Atom)
RSS Feed (xml)