martZ

From a news article or internet information, find an example of an organization that is installing an ERP package. If possible get a copy of the over-all project plans and analyze thae various activities and compare them with a standard SDLC.

2010-03-12T06:50:00.000-08:00

SAD 1
Assignment 12

About the company:

During the last 18 years, TTT Corporation has built up reputation through maintaining a great reputation of more than 2,000 regular clients.

Also in those 18 years, we have given rise to the richness of culture and tradition in TTT Family of which the members are very creative, prestigious, gifted to endure high pressure and always being motivated.

2010 is declared to be the year that TTT family focuses on building Quality policy and Efficiency measurement system in order to greatly improve our customer service as well as better support our customers community.

After applying ERP, management became a lot easier...

Even though it is not well developed, there are powerful companies applying ERP.
With these strong companies, ERP has been applied and even a structure for businesses.

From Architects

TTT Corporation is one of the earliest company that has applied ERP in Vietnam. At the end of 1999, TTT Corporation began to invest into buying ERP.

They have pushed forward on researching, process, train ERP in the company in 2000. From 2001, the company officially applied ERP.

Mr. Tran Minh Tam, chairman of TTT Corporation said: "Before applying ERP, each year, TTT has around 30 - 40 projects. Managing wasn't easy, information was all over the place, does not focus in one area.

Every project managers have to really motivate themselves in many different areas. A the same time, information and reports are being handled vertically in turns overload directors."

After applying ERP, managing became a lot easier. Project managers don't have to be all over the place. Saving lots of time due to all information are constantly available in an orderly fashion.

Every requests or complaints from clients are solved extremely fast and our trust increases, and the amount of projects shoot through the roof...

Mr. Tran Minh Tam letting us know more: "Year 2006, TTT has about 300 projects. This is an impressive number and sweetness from ERP.

Their Project Summary

* The Challenge
-----> define the challenge or problem
* The Solution
-----> generate a solution
* Design Freely
-----> have a design on your own expressing your own idea and perspective
* Deliver Efficiency
-----> must consider the efficiency of the proposed solution
* Increase Coordination and Quality
-----> good coordination between team members
* Accelerate Decision Making
-----> important that the margin of error on any project be reduced to the bare minimum,
could make sure that mistakes and errors were detected at a very initial stage. As a result, we could reach decisions faster since all the information was right in front of us.
* Enhance Client Communication
-----> inform our client about every aspect of the project and enable the client to see an actual model of the project. And with the help of third-party analysis software, they could simulate how it reacts to real-time climate conditions—before construction.
* The Result
-----> the overall acquisition

Compared to Standard SDLC

* Initiation/planning
-----> view of the intended project and determine the goals of the project
* Requirements gathering and analysis
-----> goal of systems analysis is to determine where the problem is in an attempt to fix the system
* Design
-----> functions and operations are described in detail, including screen layouts, business rules, process diagrams and other documentation
* Build or coding
-----> programming code will be accomplished
* Testing
-----> code is tested at various levels in software testing
* Operations and maintenance
-----> changes and enhancements before the decommissioning or sunset of the system

References:

http://www.tttcompany.com/Home/tabid/36/ArticleID/59/Default.aspx
http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle

You were tasked by the IC- Dean to evaluate the enrollment system of the University, list and briefly describe the characteristics that an analyst (you) examines when choosing or defining deployment environment.

2010-03-04T19:57:00.001-08:00

SAD 1
Assignment 11

First and foremost, before I describe or evaluate the current enrollment system of the University, let me introduce to you my researched topics of procedures on how and where to effectively deploy a system using a deployment phase guideline to have a basis on my further evaluation.

Purpose of Deployment Phase

There are three (3) major reasons or goals on why we have to dwell on the deployment phase for our system. And here are as follows:

a. If the infrastructure system is installed as planned and specified,

b. If users are trained,

c. If end users and supporting organizations are prepared to accept the system.

For these goals to be met, it is very important that an analyst should carefully plan for the eventual deployment of the system including needed staffing, training, as well as anticipated policy and procedure changes.

Overview of the Deployment Phase

The infrastructure system is installed to support the intended business functions. Performance objectives are identified, agreed to, and recorded in a Service Level Agreement before going into operation. The analyst decides when deployment to the workforce is to begin and determines the general deployment schedule and approach. From a technical perspective this phase is concerned with installation, operational assessment, and independent acceptance of the AIS or infrastructure system. Users, operational support staff and testers from outside the developing organization must be involved in accepting the AIS or infrastructure system. From the business point of view, this phase is concerned with ensuring that the customer organization is fully trained and prepared to use the new or modified infrastructure system.

Tasks Acquired During the Deployment Phase

The tasks to be performed during this phase are:

a. Ensure that deployment, operational support, and maintenance resources are adequate.

b. Train user and information technology support personnel.

c. Prepare the sites where the infrastructure system will be used and operated.

d. Install the system at sites designated by the Project Manager.

e. Complete all necessary data conversion.

f. Ensure that all documentation and procedures are fully developed and tested.

g. Conduct periodic Functional and Physical Configuration Audits.

h. Conduct AIS or infrastructure system security review.

i. Identify AIS or infrastructure system performance objectives in a Service Level Agreement contained in the OSP.

j. Ensure that adequate production and maintenance procedures are in place.

My Evaluation

So, if I were to evaluate the enrollment system of the University, I have listed different characteristics or strategies that serve as my guideline which is a summarized category of the above discussions.

1. Physical Architecture

a. The physical layout of the servers and network elements needed for the environment.

2. Logical Layout

a. Includes the logical layout of the web application and service elements needed for the environment.

3. Security Configuration

a. This outlines the security mechanisms that will be employed to control access to the environment and environment resources

4. Connectivity Planning

a. Details the environment access points and user connectivity methodology and controls.

5. Usability Planning

a. Details the usage for the environment and reviews application needs and plans.

6. Disaster Prevention and Recovery Planning

a. Including the protection of the environment from potential service interruptions or loss of data in the event of a disaster.

References:

http://search.yahoo.com/search;_ylt=A0geu5TSgZBLJCYBJSxXNyoA?p=deployment+phase&fr2=sb-top&fr=yfp-t-701&fp_ip=ph&rd=r1&meta=vc%3Dph&sao=0

http://www.datalan.com/Solutions/Pages/Design%20and%20Deployment.aspx

With reference to assignments 8 and 9, what characteristics does an analyst (you) examine when evaluating DFD quality? (1,500 words)

2010-02-25T20:45:00.000-08:00

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

Different types of Data Flow Diagram

2010-02-18T20:19:00.000-08:00

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

Using the same narrative as reflected in your Assignment #7, develop an activity diagram and a fully developed description for a use case.

2010-02-11T20:39:00.000-08:00

SAD
Assignment 8

Consider USEP's pre-enrollment system, develop a use case diagram and write a brief use case description.

2010-02-04T20:41:00.000-08:00

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.

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)

2010-02-03T23:22:00.000-08:00

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

Consider your school, how do you know that the life cycle was developed specifically for the university. How do we know it meets our needs? At least 2500 words.

2010-01-03T04:28:00.003-08:00

SAD Assignment 5

About my school

As a state university, primarily the University of Southeastern Philippines is a big government institution that provides big range of services may it be to students, staff, and employees and also to others. With that, it needs or requires a big real time system that could be adaptive to any changes that may occur or imposed from time to time. Being a university type of institution, the crucial parts of the system are the data, records or accounts, the system governance flow, and the management which must be taken care of seriously. Since it caters educational related professions, it is expected to last for a long period of time be it in a number of decades or century. An exclusive system for the university itself must be able to support the university needs and that would last up to the university’s existence.

Systems Development Life Cycle

It is a project management technique that divides complex projects into smaller, more easily managed segments or phases. Segmenting projects allows managers to verify the successful completion of project phases before allocating resources to subsequent phases.

Software development projects typically include initiation, planning, design, development, testing, implementation, and maintenance phases. However, the phases may be divided differently depending on the organization involved.

We will know that the life cycle was developed specifically for the university if it practices the following Systems Development Life Cycle Phases that is related to the system itself and provides solutions to every phases that meets the need of the university.

Systems Development Life Cycle Phases

Initiation Phase

• To add, improve, or correct a system

- identified and formally requested through the presentation of a business case.

• The business case should, at a minimum

- describe a proposal’s purpose, identify expected benefits, and explain how the proposed system supports one of the organization’s business strategies.

• The business case should also identify alternative solutions and detail

- as many informational, functional, and network requirements as possible.

• To conduct a more thorough feasibility study

- requires management to verify the accuracy of the preliminary assumptions and identify resource requirements in greater detail.

Primary issues organizations should consider when compiling feasibility study support documentation include:

- Business Considerations:

1. Strategic business and technology goals and objectives;

2. Expected benefits measured against the value of current technology;

3. Potential organizational changes regarding facilities or the addition/reduction of end users, technicians, or managers;

4. Budget, scheduling, or personnel constraints; and

5. Potential business, regulatory, or legal issues that could impact the feasibility of the project.

- Functional Requirements:

1. End-user functional requirements;

2. Internal control and information security requirements;

3. Operating, database, and backup system requirements Connectivity requirements

4. Network support requirements

5. Interface requirements

- Project Factors:

1. Project management methodology;

2. Risk management methodology;

3. Estimated completion dates of projects and major project phases; and

4. Estimated costs of projects and major project phases.

- Cost/Benefit Analysis:

 Expected useful life of the proposed product;

 Alternative solutions

 Nonrecurring project costs

 Recurring operational costs

 Tangible benefits

 Intangible benefits

- Should be compiled and submitted for senior management or board study.

- Should provide an overview of the proposed project and identify expected costs and benefits in terms of economic, technical, and operational feasibility.

- Document should also describe alternative solutions and include a recommendation for approval or rejection.

- Document should be reviewed and signed off on by all affected parties.

Planning Phase

It is the most critical step in completing development, acquisition, and maintenance projects. Careful planning, particularly in the early stages of a project, is necessary to coordinate activities and manage project risks effectively.

• Coordinate discussions between user, audit, security, design, development, and network personnel to identify and document as many functional, security, and network requirements as possible.

Primary items organizations should address in formal project plans include:

1. Project Overview -should identify the project, project sponsors, and project managers; and should describe project goals, background information, and development strategies.

2. Roles and Responsibilities –should define the primary responsibilities of key personnel, including project sponsors, managers, and team members.

3. Communication –should establish procedures for gathering and disseminating information. Standard report forms, defined reporting requirements, and established meeting schedules facilitate project communications.

4. Defined Deliverables – Clearly defined expectations are a prerequisite for successfully completing projects.

5. Control Requirements – involves designing and building automated control and security features into applications. Identifying all required features and exactly where they should be placed is not always possible during initial project phases.

6. Risk Management –should establish procedures to ensure managers appropriately assess, monitor, and manage internal and external risks throughout a project’s life cycle.

7. Change Management –standards should be in place to control changes in order to minimize disruptions to the development process.

8. Standards –should reference applicable standards relating to project oversight activities, system controls, and quality assurance.

9. Documentation –should identify the type and level of documentation personnel must produce during each project phase.

10. Scheduling –identify and schedule major project phases and the tasks to be completed within each phase.

11. Testing –should develop testing plans that identify testing requirements and schedule testing procedures throughout the initial phases of a project

12. Staff Development –should develop training plans that identify training requirements and schedule training procedures to ensure employees are able to use and maintain an application after implementation.

Design Phase

• involves converting the informational, functional, and network requirements identified during the initiation and planning phases into unified design specifications that developers use to script programs during the development phase.

• designs are constructed in various ways.

• end users, designers, developers, database managers, and network administrators should review and refine the prototyped designs in an iterative process until they agree on an acceptable design.

• management should be particularly diligent when using prototyping tools to develop automated controls. Prototyping can enhance an organization’s ability to design, test, and establish controls.

• Designers should carefully document completed designs.

• Organizations should create initial testing, conversion, implementation, and training plans during the design phase.

Application Control Standards

• Application controls include policies and procedures associated with user activities and the automated controls designed into applications.

• Designing appropriate security, audit, and automated controls into applications is a challenging task. Adding controls late in the development process or when applications are in production is more expensive, time consuming, and usually results in less effective controls.

• Standards should be in place to ensure end users, network administrators, auditors, and security personnel are appropriately involved during initial project phases.

• Application control standards enhance the security, integrity, and reliability of automated systems by ensuring input, processed, and output information is authorized, accurate, complete, and secure.

Input Controls

• Automated input controls help ensure employees accurately input information, systems properly record input, and systems either reject, or accept and record, input errors for later review and correction. Examples of automated input controls include:

1. Check Digits – Check digits are numbers produced by mathematical calculations performed on input data such as account numbers.

2. Duplication Checks – Duplication checks confirm that duplicate information is not input.

3. Limit Checks – Limit checks confirm that a value does not exceed predefined limits.

4. Range Checks – Range checks confirm that a value is within a predefined range of parameters.

5. Reasonableness Checks – Reasonableness checks confirm that a value meets predefined criteria.

6. Sequence Checks – Sequence checks confirm that a value is sequentially input or processed.

7. Validity Checks – Validity checks confirm that a value conforms to valid input criteria.

Processing Controls

• Automated processing controls help ensure systems accurately process and record information and either reject, or process and record, errors for later review and correction. Processing includes merging files, modifying data, updating master files, and performing file maintenance.

• Examples of automated processing controls include:

1. Batch Controls – Batch controls verify processed run totals against input control totals. Batches are verified against various items such as total dollars, items, or documents processed.

2. Error Reporting – Error reports identify items or batches that include errors. Items or batches with errors are withheld from processing, posted to a suspense account until corrected, or processed and flagged for later correction.

3. Transaction Logs – Users verify logged transactions against source documents. Administrators use transaction logs to track errors, user actions, resource usage, and unauthorized access.

4. Run-to-Run Totals – Run-to-run totals compiled during input, processing, and output stages are verified against each other.

5. Sequence Checks – Sequence checks identify or reject missing or duplicate entries.

6. Interim Files – Operators revert to automatically created interim files to validate the accuracy, validity, and completeness of processed data.

7. Backup Files – Operators revert to automatically created master-file backups if transaction processing corrupts the master file.

Output Controls

• Automated output controls help ensure systems securely maintain and properly distribute processed information. Examples of automated output controls include:

1. Batch Logs – Batch logs record batch totals. Recipients of distributed output verify the output against processed batch log totals.

2. Distribution Controls – Distribution controls help ensure output is only distributed to authorized individuals.

3. Destruction Controls – Destruction controls help ensure electronically distributed and stored information is destroyed appropriately by overwriting outdated information or demagnetizing (degaussing) disks and tapes.

Development Phase

• Involves converting design specifications into executable programs. Effective development standards include requirements that programmers and other project participants discuss design specifications before programming begins.

• Procedural programming involves the line-by-line scripting of logical instructions that are combined to form a program.

• Advancements in programming techniques include the concept of "object-oriented programming."

• Organizations should complete testing plans during the development phase. Additionally, they should update conversion, implementation, and training plans and user, operator, and maintenance manuals.

Development Standards

• should be in place to address the responsibilities of application and system programmers. Application programmers are responsible for developing and maintaining end-user applications.

• Development standards should prohibit a programmer's access to data, programs, utilities, and systems outside their individual responsibilities.

• Coding standards, which address issues such as the selection of programming languages and tools, the layout or format of scripted code, and the naming conventions of code routines and program libraries, are outside the scope of this document.

Library Controls

• Libraries are collections of stored documentation, programs, and data. Program libraries include reusable program routines or modules stored in source or object code formats.

Library controls should include:

1. Automated Password Controls – Management should establish logical access controls for all libraries or objects within libraries.

2. Automated Library Applications – When feasible, management should implement automated library programs, which are available from equipment manufacturers and software vendors

Version Controls

• Library controls facilitate software version controls. Version controls provide a means to systematically retain chronological copies of revised programs and program documentation.

• Development version control systems, sometimes referred to as concurrent version systems, assist organizations in tracking different versions of source code during development.

Software Documentation

• should maintain detailed documentation for each application and application system in production.

• The documentation should contain detailed application descriptions, programming documentation, and operating instructions.

• Standards should be in place that identify the type and format of required documentation such as system narratives, flowcharts, and any special system coding, internal controls, or file layouts not identified within individual application documentation.

• should maintain documentation for internally developed programs and externally acquired products.

• Examiners should consider access and change controls when assessing documentation activities.

• System documentation should include:

1. System Descriptions – System descriptions provide narrative explanations of operating environments and the interrelated input, processing, and output functions of integrated application systems.

2. System Documentation – System documentation includes system flowcharts and models that identify the source and type of input information, processing and control actions (automated and manual), and the nature and location of output information.

3. System File Layouts – System file layouts describe collections of related records generated by individual processing applications.

Application documentation should include:

1. Application Descriptions – Application descriptions provide narrative explanations of the purpose of an application and provide overviews of data input, processing, and output functions.

2. Layouts – Layouts represent the format of stored and displayed information such as database layouts, screen displays, and hardcopy information.

3. Program Documentation – Program documentation details specific data input, processing, and output instructions, and should include documentation on system security.

4. Naming Conventions – Naming conventions are a critical part of program documentation.

5. Operator Instructions – Organizations should establish operator instructions regarding all processing applications.

6. End-User Instructions – Organizations should establish end-user instructions that describe how to use an application.

Testing Phase

• requires organizations to complete various tests to ensure the accuracy of programmed code, the inclusion of expected functionality, and the interoperability of applications and other network components.

• identify program defects or weaknesses during the testing process. Procedures should be in place to ensure programmers correct defects quickly and document all corrections or modifications.

• Primary tests include:

1. Acceptance Testing – End users perform acceptance tests to assess the overall functionality and interoperability of an application.

2. End-to-End Testing – End users and system technicians perform end-to-end tests to assess the interoperability of an application and other system components such as databases, hardware, software, or communication devices.

3. Functional Testing – End users perform functional tests to assess the operability of a program against predefined requirements. Functional tests include black box tests, which assess the operational functionality of a feature against predefined expectations, or white box tests, which assess the functionality of a feature’s code.

4. Integration Testing – End users and system technicians perform integration tests to assess the interfaces of integrated software components.

5. Parallel Testing – End users perform parallel tests to compare the output of a new application against a similar, often the original, application.

6. Regression Testing – End users retest applications to assess functionality after programmers make code changes to previously tested applications.

7. Stress Testing – Technicians perform stress tests to assess the maximum limits of an application.

8. String Testing – Programmers perform string tests to assess the functionality of related code modules.

9. System Testing – Technicians perform system tests to assess the functionality of an entire system.

10. Unit Testing – Programmers perform unit tests to assess the functionality of small modules of code.

Implementation Phase

• involves installing approved applications into production environments. Primary tasks include announcing the implementation schedule, training end users, and installing the product. Additionally, organizations should input and verify data, configure and test system and security parameters, and conduct post-implementation reviews.

• Verifying the accuracy of the input data and security configurations is a critical part of the implementation process.

PROJECT EVALUATION

• should conduct post-implementation reviews at the end of a project to validate the completion of project objectives and assess project management activities.

• should analyze the effectiveness of project management activities by comparing, among other things, planned and actual costs, benefits, and development times.

Maintenance Phase

• involves making changes to hardware, software, and documentation to support its operational effectiveness. It includes making changes to improve a system’s performance, correct problems, enhance security, or address user requirements

• Change management (sometimes referred to as configuration management) involves establishing baseline versions of products, services, and procedures and ensuring all changes are approved, documented, and disseminated.

• changes must be made quickly.

• Emergency change controls should include the same procedures as routine change controls.

• should test routine and, whenever possible, emergency changes prior to implementation and quickly notify affected parties of all changes.

• Patch management programs should address procedures for evaluating, approving, testing, installing, and documenting software modifications.

• patch management process involves maintaining an awareness of external vulnerabilities and available patches.

• should carefully document all modifications to ensure accurate system inventories.

• Management should coordinate all technology related changes

• Quality assurance, security, audit, regulatory compliance, network, and end-user personnel

• Risk and security review should be done whenever a system modification is implemented to ensure controls remain in place.

Disposal Phase

• involves the orderly removal of surplus or obsolete hardware, software, or data.

• primary tasks include the transfer, archiving, or destruction of data records.

• should transfer data from production systems in a planned and controlled manner that includes appropriate backup and testing procedures.

• should maintain archived data in accordance with applicable record retention requirements.

• should also archive system documentation in case it becomes necessary to reinstall a system into production.

• should destroy data by overwriting old information or degaussing (demagnetizing) disks and tapes.

Reference:

http://www.ffiec.gov/ffiecinfobase/booklets/d_a/08.html

Identify and discuss at least 3 systems development models. Discuss each phases, at least 3,000 words.

2009-12-31T21:49:00.001-08:00

What is the purpose of system development model?

System development models are used to guide the analysis, design, development, and maintenance of information systems. Each is designed for a specific purpose or reason; most have similar goals and share many common tasks.. In order to ensure that cost-effective, quality systems are developed which address an organization’s business needs, developers employ some kind of system development model to direct the project’s life cycle.

3 System Development Models

Waterfall Model

Introduction

This model is sometimes referred to as the linear sequential model or the software life cycle.

The waterfall model is the earliest method of structured system development. Although it has come under criticism in recent years for being too rigid and unrealistic when it comes to quickly meeting customer’s needs, the waterfall model is still widely used.

The waterfall model derives its name due to the cascading effect from one phase to the other. In this model each phase well defined starting and ending point, with identifiable deliveries to the next phase.The waterfall model is a sequential software development process, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of conception, initiation, analysis, design (validation), construction, testing and maintenance. Progress flows from the top to the bottom, like a waterfall.

To follow the waterfall model, one proceeds from one phase to the next in a purely sequential manner. For example, one first completes requirements specifications, which are set in stone. When the requirements are fully completed, one proceeds to design. The software in question is designed and a blueprint is drawn for implementers (coders) to follow — this design should be a plan for implementing the requirements given. When the design is fully completed, an implementation of that design is made by coders. Towards the later stages of this implementation phase, separate software components produced are combined to introduce new functionality and reduced risk through the removal of errors.

Thus the waterfall model maintains that one should move to a phase only when it’s proceeding phase is completed and perfected.

Waterfall Development Phases:

Observe that feed back loops allow for corrections to be incorporated into the model. For example a problem/update in the design phase requires a ‘revisit’ to the specifications phase. When changes are made at any phase, the relevant documentation should be updated to reflect that change.

The model consists of six distinct stages, namely:

1. In the requirements analysis phase

- This step refers to the gathering of system requirements, with the goal of determining how these requirements will be accommodated in the system. Extensive communication between the customer and the developer is essential.

• The problem is specified along with the desired service objectives (goals)

• The constraints are identified

2. In the specification phase

- the system specification is produced from the detailed definitions of (a) and (b) above. This document should clearly define the product function.

- The consideration of all aspects of the targeted business function or process, with the goals of determining how each of those aspects relates with one another, and which aspects will be incorporated into the system.

3. In the system and software design phase, the system specifications are translated into a software representation.

- Once the requirements have been collected and analyzed, it is necessary to identify in detail how the system will be constructed to perform necessary tasks. More specifically, the System Design phase is focused on the data requirements (what information will be processed in the system?), the software construction (how will the application be constructed?), and the interface construction (what will the system look like? What standards will be followed?).

The software engineer at this stage is concerned with:

• Data structure

• Software architecture

• Algorithmic detail and

• Interface representations

The hardware requirements are also determined at this stage along with a picture of the overall system architecture. By the end of this stage the software engineer should be able to identify the relationship between the hardware, software and the associated interfaces. Any faults in the specification should ideally not be passed ‘down stream’

4. In the implementation and testing phase stage the designs are translated into the software domain

• Detailed documentation from the design phase can significantly reduce the coding effort.

• Testing at this stage focuses on making sure that any errors are identified and that the software meets its required specification.

5. In the integration and system testing phase all the program units are integrated and tested to ensure that the complete system meets the software requirements. After this stage the software is delivered to the customer.

- As the software is created and added to the developing system, testing is performed to ensure that it is working correctly and efficiently. Testing is generally focused on two areas: internal efficiency and external effectiveness. The goal of external effectiveness testing is to verify that the software is functioning according to system design, and that it is performing all necessary functions or sub-functions. The goal of internal testing is to make sure that the computer code is efficient, standardized, and well documented. Testing can be a labor-intensive process, due to its iterative nature.

6. The maintenance phase the usually the longest stage of the software. In this phase the software is updated to:

• Meet the changing customer needs

• Adapted to accommodate changes in the external environment

• Correct errors and oversights previously undetected in the testing phases

• Enhancing the efficiency of the software

Advantages / Constructive Details

• Testing is inherent to every phase of the waterfall model

• It is an enforced disciplined approach

• It is documentation driven, that is, documentation is produced at every stage

• it is easier to fix the specific components

• A further argument for the waterfall model is that it places emphasis on documentation

• simple approach

• provides a structured

• easily understandable and explainable phases and thus is easy to understand

• The waterfall model also requires that implementers follow the well made, complete design accurately, ensuring that the integration of the system proceeds smoothly.

Disadvantages / Criticism

The waterfall model is the oldest and the most widely used paradigm.

However, many projects rarely follow its sequential flow. This is due to the inherent problems associated with its rigid format. Namely:

• It only incorporates iteration indirectly, thus changes may cause considerable confusion as the project progresses.

• As The client usually only has a vague idea of exactly what is required from the software product, this WM has difficulty accommodating the natural uncertainty that exists at the beginning of the project.

• The customer only sees a working version of the product after it has been coded. This may result in disaster if any undetected problems are precipitated to this stage.

• The waterfall model is argued by many to be a bad idea in practice. This is mainly because of their belief that it is impossible for any non-trivial project to get one phase of a software product's lifecycle perfected, before moving on to the next phases and learning from them.

• Designers may not be aware of future implementation difficulties when writing a design for an unimplemented software product.

• Its rigid design and inflexible procedure.

• Real projects rarely follow the sequential flow that the model proposes.

• At the beginning of most projects there is often a great deal of uncertainty about requirements and goals, and it is therefore difficult for customers to identify these criteria on a detailed level. The model does not accommodate this natural uncertainty very well.

• Developing a system using the Waterfall Model can be a long, painstaking process that does not yield a working version of the system until late in the process.

Spiral model

Introduction

The spiral model is a software development process combining elements of both design and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts. Also known as the spiral lifecycle model (or spiral development), it is a systems development method (SDM) used in information technology (IT). This model of development combines the features of the prototyping model and the waterfall model. The spiral model is intended for large, expensive and complicated projects.

The spiral model combines the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model, therein providing the potential for rapid development of incremental versions of the software. In this model the software is developed in a series of incremental releases with the early stages being either paper models or prototypes. Later iterations become increasingly more complete versions of the product. It was the first model to explain why the iteration matters.

Spiral Development Phases:

Depending on the model it may have 3-6 task regions (/framework a ctivities) our case will consider a ‘6-task region’ model.

These regions are:

1. The customer communication task – to establish effective communication between developer and customer.

2. The planning task – to define resources, time lines and other project related information..

3. The risk analysis task – to assess both technical and management risks.

4. The engineering task – to build one or more representations of the application.

5. The construction and release task – to construct, test, install and provide user support (e.g., documentation and training).

6. The customer evaluation task – to obtain customer feedback based on the evaluation of the software representation created during the engineering stage and implemented during the install stage.

Advantages of the Spiral Model

• The spiral model is a realistic approach to the development of large-scale software products because the software evolves as the process progresses. In addition, the developer and the client better understand and react to risks at each evolutionary level.

• The model uses prototyping as a risk reduction mechanism and allows for the development of prototypes at any stage of the evolutionary development.

• It maintains a systematic stepwise approach, like the classic life cycle model, but incorporates it into an iterative framework that more reflect the real world.

• If employed correctly, this model should reduce risks before they become problematic, as consideration of technical risks are considered at all stages.

Disadvantages of the Spiral Model

• Demands considerable risk-assessment expertise

• It has not been employed as much proven models (e.g. the WF model) and hence may prove difficult to ‘sell’ to the client (esp. where a contract is involved) that this model is controllable and efficient. [More study needs to be done in this regard]

Agile Modeling

Introduction

Agile Modeling is a practice-based methodology for modeling and documentation of software-based systems. It is intended to be a collection of values, principles, and practices for modeling software that can be applied on a software development project in a more flexible manner than traditional modeling methods.

Agile methods generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices that allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals.

There are many specific agile development methods. Most promote development iterations, teamwork, collaboration, and process adaptability throughout the life-cycle of the project.

Agile methods emphasize face-to-face communication over written documents when the team is all in the same location. When a team works in different locations, they maintain daily contact through videoconferencing, voice, e-mail, etc.

Most agile teams work in a single open office (called bullpen), which facilitates such communication. Team size is typically small (5-9 people) to help make team communication and team collaboration easier. No matter what development disciplines are required, each agile team will contain a customer representative.

Most agile implementations use a routine and formal daily face-to-face communication among team members. Agile emphasizes working software as the primary measure of progress.

Agile methods differ to a large degree in the way they cover project management. Some methods are supplemented with guidelines on project management, but there is generally no comprehensive support.

Agile software development depends on some special characteristics possessed only by software, such as object technologies and the ability to automate testing. However, related techniques have been created for developing non-software products, such as semiconductors, motor vehicles, or chemicals. For more on them, see Flexible product development.

Agile Procedures:

Agile methods break tasks into small increments with minimal planning, and do not directly involve long-term planning. Iterations are short time frames that typically last from one to four weeks. Each iteration involves a team working through a full software development cycle including planning, requirements analysis, design, coding, unit testing, and acceptance testing when a working product is demonstrated to stakeholders. This helps minimize overall risk, and lets the project adapt to changes quickly. Stakeholders produce documentation as required. An iteration may not add enough functionality to warrant a market release, but the goal is to have an available release (with minimal bugs) at the end of each iteration. Multiple iterations may be required to release a product or new features.

Agile values:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

• Customer satisfaction by rapid, continuous delivery of useful software

• Working software is delivered frequently (weeks rather than months)

• Working software is the principal measure of progress

• Even late changes in requirements are welcomed

• Close, daily cooperation between business people and developers

• Face-to-face conversation is the best form of communication (co-location)

• Projects are built around motivated individuals, who should be trusted

• Continuous attention to technical excellence and good design

• Simplicity

• Self-organizing teams

• Regular adaptation to changing circumstances

Comparisons

Agile methods lie on the "adaptive" side of this continuum. Adaptive methods focus on adapting quickly to changing realities. When the needs of a project change, an adaptive team changes as well. An adaptive team will have difficulty describing exactly what will happen in the future. The further away a date is, the vaguer an adaptive method will be about what will happen on that date. An adaptive team can report exactly what tasks are being done next week, but only which features are planned for next month. When asked about a release six months from now, an adaptive team may only be able to report the mission statement for the release, or a statement of expected value vs. cost.

Predictive methods, in contrast, focus on planning the future in detail. A predictive team can report exactly what features and tasks are planned for the entire length of the development process. Predictive teams have difficulty changing direction. The plan is typically optimized for the original destination and changing direction can cause completed work to be thrown away and done over differently. Predictive teams will often institute a change control board to ensure that only the most valuable changes are considered.

Most agile methods share other iterative and incremental development methods' emphasis on building releasable software in short time periods. Agile development differs from other development models: in this model time periods are measured in weeks rather than months and work is performed in a highly collaborative manner. Most agile methods also differ by treating their time period as a time box.

Agile development has little in common with the waterfall model. The waterfall model is the most structured of the methods, stepping through requirements-capture, analysis, design, coding, and testing in a strict, pre-planned sequence. Progress is generally measured in terms of deliverable artifacts: requirement specifications, design documents, test plans, code reviews and the like.

The main problem with the waterfall model is the inflexible division of a project into separate stages, so that commitments are made early on, and it is difficult to react to changes in requirements. Iterations are expensive. This means that the waterfall model is likely to be unsuitable if requirements are not well understood or are likely to change in the course of the project.

Agile methods, in contrast, produce completely developed and tested features every few weeks. The emphasis is on obtaining the smallest workable piece of functionality to deliver business value early, and continually improving it and adding further functionality throughout the life of the project. If a project being delivered under the waterfall method is cancelled at any point up to the end, there is nothing to show for it beyond a huge resources bill. With the agile method, being cancelled at any point will still leave the customer with some worthwhile code that has likely already been put into live operation.

In this respect, agile critics may assert that these features are not placed in context of the overall project, concluding that, if the sponsors of the project are concerned about completing certain goals with a defined timeline or budget, agile may not be appropriate. Proponents of agile development counter that adaptations of Scrum show how agile methods are augmented to produce and continuously improve a strategic plan.

Grounds of Agile

Agile home ground: Low criticality

• Senior developers

• Requirements change often

• Small number of developers

• Culture that thrives on chaos

Plan-driven home ground: High criticality

• Junior developers

• Requirements do not change often

• Large number of developers

• Culture that demands order

Agile methods

Some of the well-known agile software development methods:

• Agile Modeling

• Agile Unified Process (AUP)

• Agile Data Method

• DSDM

• Essential Unified Process (EssUP)

• Extreme programming (XP)

• Feature Driven Development (FDD)

• Getting Real

• Open Unified Process (OpenUP)

• Scrum

• Lean software development

Agile practices

• Test Driven Development (TDD)

• Behavior Driven Development (BDD)

• Continuous Integration

• Pair Programming

• Planning poker

• RITE Method

Measuring agility

While agility can be seen as a means to an end, a number of approaches have been proposed to quantify agility. Agility Index Measurements (AIM) score projects against a number of agility factors to achieve a total. The similarly-named Agility Measurement Index, scores developments against five dimensions of a software project (duration, risk, novelty, effort, and interaction). Other techniques are based on measurable goals. Another study using fuzzy mathematics has suggested that project velocity can be used as a metric of agility. There are agile self assessments to determine whether a team is using agile practices. While such approaches have been proposed to measure agility, the practical application of such metrics has yet to be seen.

Criticism

The criticisms regarding insufficient software design and lack of documentation are addressed by the Agile Modeling method, which can easily be tailored into agile processes.

Agile software development has been criticized because it may not bring about all of the claimed benefits unless utilized by above average programmers; above average programmers create above average code regardless of the method used.

References:

http://www.ctg.albany.edu/publications/reports/survey_of_sysdev/survey_of_sysdev.pdf

http://en.wikipedia.org/wiki/Waterfall_model

http://scitec.uwichill.edu.bb/cmp/online/cs22l/waterfall_model.htm

http://en.wikipedia.org/wiki/Spiral_model

http://scitec.uwichill.edu.bb/cmp/online/cs22l/spiralmodel.htm

http://en.wikipedia.org/wiki/Agile_Modeling

http://en.wikipedia.org/wiki/Agile_software_development

Discuss the role of a systems analyst as a project manager. (At least one thousand words) .... you need to interview an analyst/project manager...

2009-12-24T18:24:00.000-08:00

SAD Assignment3

In general, the project manager is responsible for the overall success of the project. In some companies, this person might be called a Project Coordinator, or a Team Leader, however, the key aspect is that the person is responsible for ensuring the success of the project while the system analyst is the person (or persons) who guides through the development of an information system. In performing these tasks the analyst must always match the information system objectives with the goals of the organization.

Based on our interview with the manager in PIADI (Printing Industries Association of Davao Incorporated), having been exposed for twenty- one (21) years in banking business, it is anymore not that hard to design a specified system for their company which is somewhat related to money, business, customers and employees. But playing the role of a systems analyst is not that easy, specifically when it comes to the contribution for the project or system. In the systems analyst lies the outline and flow of the system, making up together the factor for the success of the business. The analyst knows the contributing factors for the system, be it software or hardware and also foresees the product of the system itself.

Planning those systems would not be made unless great understanding and responsibilities were taken care of. Planning a system without comprehension is not effective. A systems analyst as a project manager must take into accounts every single data, instruction and procedure that contributes to the system development.

Since the analyst served as a bridge between the business professionals and the information technology buddies, as a project manager lays the readable outline or plan for both parties. With that both parties can give their comments and site renditions for the system plan. As a project manager, the analyst may have the great authority in designing the system, but would never be successful without the contribution from each of both parties.

The systems analyst plays the great part of the project that serves as the brain for the whole project. For in the hands of the analysts lies the success of the project. Just like a project manager, the analysts’ layouts in advance the image of the project taking into account all the mandated requirements and sees the causes and outcomes of every procedure in the system. In managing the project, trial and error is the basic procedure to test every single solution and to find out the best one.

Such that the project manager manages the implementation of the project, the analysts also possess the role of having in control of all the resources needed from the minor part implementation up to the critical part. The systems analyst must take into account the available resources and if not met, find other resources. The analyst is accountable for very failures in the implemented project. Just as a project manager does, the analyst checks and is accountable for any unexpected outcome or failures. For example, if the system started clearly and as it goes later on, it is becoming so vague. Another is when the poor scheduling of the system implementation is present that prolongs the systems implementation duration.

The systems analyst also plays the role as a budget consultant. The analyst must know how much his/her system costs. Taking into consideration the financial budget that is needed that counts the physical resources or materials needed that is composed of the equipments and manpower resources. Also budgets the time allocation from the design, to documentation and to implementation then to testing. The systems analysts must have laid in his/her plan the estimated total time of the system making would cost.

Upon designing the system, the analyst same as a project manager chooses the best procedure that will be used for the system design and implementation. As what was discussed from the previous chapters, an analyst must look for the best possible way or procedure to develop their system.

For being so knowledgeable about the system components, requirements, elements and all, the systems analyst designs a database management system and also may write some of the project documentation.

A systems analyst spends the rest of their time in major project roles such as the designer and technical writer. A systems analyst has the unique ability to "step outside and look in". An analyst looks into the bigger outline of the business and sees every single procedure that makes up the whole. The analyst is not indulged to any particular technology, theory or methodology. They just bring with them both business and technological experience and are open to learning from the other people.

As discussed from our interview, the role of the systems analyst does not end into the making of the system. As playing also the role of a project manager, the analyst foresees the possible developments for the system. Of course, in line with the development, the analyst has to maintain the system and is accountable to any system breakdown.

The systems analyst is an “IT systems Analyst” who is more focused on system design and the technical aspects of the solution for the system. The systems analyst’s role is mostly system solution centric (does not generally participate in the requirements gathering process) and is involved in the creation of functional and technical specifications. This is the professional who, once requirements are clearly defined, creates the functional solution and, by working with the technical team (architect and developers), creates technical specifications and designs. In virtually every organization, the pivotal leadership role of the systems analyst is beginning to shape the future of IT. In a nutshell, analysts are focused on business needs and on monitoring the value a project has promised to deliver to the organization throughout its implementation. The analyst continually scrutinizes costs and compares them to benefits to ensure the project remains sound. Projects of different sizes have different ways and requirements on how the people are organized. In a small project, little organization structure is needed. There might be a primary sponsor, project manager and a project team. However, for large projects, there are more and more people involved, and it is important that people understand what they are expected to do, and what role people are expected to fill.

References:

http://www.freetutes.com/systemanalysis/role-of-system-analyst.html

http://www.lifecyclestep.com/open/407.1TheRoleoftheProjectManager.htm

http://it.toolbox.com/blogs/business-analyst/the-role-of-business-analyst-3357

http://www.batimes.com/articles/106-articles/53-the-coming-of-age-of-the-business-analyst.html

Interview a Systems Analyst and ask what skills and characteristics must a systems analyst develop in order to be more effective in any design modeling process [include in your answer evidences (pix, ltrs, etc)]? At least 2000 words excluding your evidence

2009-12-24T18:20:00.000-08:00

SAD Assignment2

Company Background:

The company we adopted is PIADI Multi-Purpose Cooperative (Printing Industries Association of Davao Incorporated) located at PIADI Building, Araullo Street, Davao City. It started operating sine 1992 here in Davao City and now has a branch in General Santos City.

Interview Proper:

We were able to interview the branch manager of PIADI Multi-Purpose Cooperative (Printing Industries Association of Davao Incorporated), Mr. Franklin M. Sanchez. And to take note, he was neither a graduate in business related course nor a graduate of any computer related course, but he was a graduate of Bachelor of Arts in Philosophy. Although he was enrolled in that course, he noticed that he is fun and interested in numbers. Before he reached his position as a manager, he went from rags to riches. He was once collector, then a teller until he became a manager in Banco de Oro (formerly PCI Bank). He worked there for about twenty- one (21) years. That experience became his foundation in his career right now. Managing a business is not just monitoring the business, employees and customers in the said company. He also portrays the role of being a systems analyst and a project manager. He told us that although the person who made their system is an attorney who has an agency himself or what we called a legal council, his approval still matters.

He told us that a cooperative does not necessarily means money and loans that is somewhat a misconception when it talks about a “cooperative”. For him, a cooperative is owned by every member. And every member has a power of their votes and shares. The cooperative’s business transaction should be voted and approved by the members.

According to him, the top most skill that a system analyst should possess is to have a working knowledge of the business he/she is in to. Primarily, in the multi- purpose cooperative business, accounting knowledge is a must. The system analyst must know the accounting principles, for example, inventory, accounts payable, bookkeeping, cash in- flow, cash out- flow and many more.

Also, experience is a big plus. Having been experienced and exposed in to a certain business serves as a foundation in creating an effective design modeling process. In his twenty- one (21) years experience in the banking business is a big contribution in his carrier right now.

Next is that a system analyst must have a good working habits. It pertains to the control and manipulation between his appointments and responsibilities. If a systems analyst has poor working habits, it would be harder for him/her to finish his work or design in time. Aside from the dedicated time to meet or so called the deadline, also the quality of the system is affected. A systems analyst must be flexible enough to work in great pressure anytime and anywhere. A good theory or working knowledge is not enough to have or to become an effective systems analyst unless applied. Working habits has to be maintained for good or even be developed for the better. Good working habit will not be counted unless the product or the result is good.

Being intelligent is still not enough to create a good modeling process. Attitude means a lot. All your achievements will be for no good if you do not have that right attitude towards other people and most especially to yourself. Being discipline goes in line with this key. To relate it to my interviewee, he was a graduate of Philosophy and expectantly, he is more expert in dealing with different types of people. That is why he values attitude towards his employees and customers.

Another skill he desired is that a systems analyst must be computer literate. He mentioned that during their time, computers has already evolved but are not reachable by their resources and knowledge. Even up to know they are not that good. Having basic information about Microsoft Word, Excel and PowerPoint is enough to run their system.

“It is better to live below your means that to live above it”, as Mr. Franklin M. Sanchez quoted. It means that I business, having control of your expenses makes your field profitable enough. It comprises that you must know your limitations. As a systems analyst, another skill to develop in order to be effective in designing a modeling process is by knowing your limitations and boundaries.

Concerning with business, he told us a simple and short but a meaningful story about a family with a small “sari- sari” store. The store was managed by the mother but somehow also managed by the father of the family as well as the children. Then at a certain time, the mother noticed that all her products are already sold but the money or income does not change at all. Then her nephew told her that maybe all her profits were turned to change for the customers. In a simple point of view, the issue is that a certain business or even a system must be managed by a single person, if many, at least with the same interest and goal. With this straight manipulation from the analyst, the systems manipulations by others are avoided.

Based on your learning of chapter 1, identify and discuss some characteristics you have as a good Systems Analyst.

2009-12-14T21:44:00.001-08:00

SAD Assignment1

A systems analyst plays a big part in a company or business. Or should I say that a systems analyst serves as the heart and brain of a company. Without a brain that decides the best for the company and without a heart that beats which keeps the parts to function well, it would be a dead business. But having a plain brain and a plain heart does not guarantee that the business would run and last for a long time. What is the use of the brain if it decides for the worst? And what is the use of the heart if it beats so slowly? For the company to survive, a good system analyst is badly needed. Based on the discussion we had in Chapter 1, he/ she should possess the following characteristics or skills; analytical, technical, managerial and intrapersonal skills¹.

Since I am enrolled in the subject Systems Analysis and Design, whether I like it or not, I will be making a system together with my group mates. And each one of us must practice the role of being a good systems analyst. And to look at the brighter side of it, what are the characteristics that I already possess that qualifies as a so called “good systems analyst”? Let me discuss it one by one.

In the aspect of analytical skills, a systems analyst must understand the nature of the business he/she is in. He/she must able to analyze problems and propose possible solutions to it. As a computer science student, I have encountered many mathematical and procedural problems in my programming subjects. I comprehended each problem and have come up with a step by step solution. I am that kind of programmer that follows the waterfall algorithm. I cannot proceed to the next step unless the current state is resolved. Being so detailed with my work, I believe that it is one of the characteristic of a good systems analyst. Being so detailed may be costly when it pertains to time consumed but I think it is a safer way to deal with my system. Security when it comes to system performance is high and every procedure is traceable. Practically, every company demands for different systems, that could be unfamiliar with what I used to encounter, but on how I will deal or analyze each problem matters most.

Technically speaking, I am not that skilled but I have the characteristic or attitude of being adoptive in any changes. A good systems analyst must be an agent of change³. Especially in the field of technology, where there is nothing constant but only change. Anyway, technical skills could be learned in a period of time. Since I am in the field of computer science, the basic technical skill when it comes to different programming languages is not anymore a problem and also basic knowledge on programming concepts is no longer an issue. I am computer literate enough to deal and analyze the limitations of what a computer could do.

Managing a business is not a joke! Since the flow of the company lies in the hands of the manager. From the moment of gathering information, to developing a system, then to testing and to deployment and finally up to the maintenance of the system, the systems analyst already plays a big part for the company as a manager. The systems analyst manages the functions, the data and the system that is needed by the company itself. In order to manage a system, one has to have the leadership ability to govern the said responsibilities. The sense of leadership is one of the characteristic that I possess that makes up a good systems analyst. Since first year college up to now, I have this attitude of being dominant when it comes to group activities. Not in the sense that it could harm our group but for the betterment of it. I have this attitude of being persevered by giving all the best that I can for the group, of course also taking in to account the contribution of my colleagues. What I just want is for our group not just to win, but to satisfy the requirements of each project and prove to ourselves that we are great.

One cannot manage something if he/she could not manage his/her own. Being self- disciplined is the key. People around you would not believe your system of leadership if they could see that your own system is much more likely needs to be resolved. For having been four years staying here in the Institute of Computing, self- discipline is the great factor that I possessed that made myself standing up to now. Compared to other courses, this course exercises self- discipline more. And one that pushes us a lot to be disciplined are our professors by giving us assignments, quizzes and project at a short period of time. Self- discipline is not enough for me to do what I am supposed to do. Self- motivation comes along with self- discipline because if you are disciplined enough but still you are not motivated enough to do the things that you are supposed to do, it would still be use less. Self- motivation requires me not to be dependent on others. I have the sense of common that pushes me to do my duties. But sometimes it cannot be avoided to feel lazy at certain time. Taking into account that “nobody is perfect”, one has its own limitations. But still I just have to try and try until I succeed but if I cannot, at least I have tried and given my best shot! And just think that everything happens for a purpose. The sense of being optimistic in life makes me stronger in every trial. Sometimes I breakdown and cry, but still life goes on.

There is a saying that “no man is an island”. A systems analyst could not work on its own. Without a company where a systems analyst would depend or serves as his/her client, he/she could not make a system. And if it has and does not have a programmer, his/her system would not be made unless that systems analyst is well rounded with programming. In short, a systems analyst must cooperate with different kinds of people at a certain system development. In this situation, the intrapersonal skill of a systems analyst is developed. This is the characteristic that I greatly possess as a good systems analyst. I am flexible enough to deal with different kinds of people. As mentioned earlier, I am that adoptive enough to changes. And a part of it is dealing with different kinds of personalities with different professions. I am not that friendly and outspoken enough to meet knew people, but I am understanding and well adjusted to every situation. Sometimes I complain maybe because I lack a little reason for me to understand the changes, but later it is not anymore a problem. As a future systems analyst, I am entitled to interact with the customers to know their requirements, also interact with designers to convey the possible interface of the software and guide the coders/developers to keep track of system development². Open mindedness and being a good listener are exercised in this task which I already have. Honestly, I like to listen to different stories because I know that is it a big factor to learning rather than reading books all alone. I am into interactive learning because out of that, you can share your ideas and opinions.

Aside from those four specific skills that I mentioned above, I think the other characteristic that I possess that composes a so called “good systems analyst” is me being good with my communication skills. A systems analyst would find it difficult to communicate with other professionals if he/she is not good in communication by the use of the universal language. It was standardized just for the people to meet half way. An intelligent and technically motivated person must reach the lower standard type of communication to deal with other people. And a person who has a very low communication capability must strive hard to communicate also with others until both parties meet. And that characteristic is not anymore a problem with me.

Another issue about having good communication skills is that as a future systems analyst, I must have a good customer service, which I also possess. Being confident enough to deal and communicate with other people is still not enough. Having a good customer service towards clients is a big factor. If I am already a systems analyst and takes a great part in the company does not mean that I have all the power and value that I may be arrogant towards others. Having a good attitude I think is the most important characteristic that I possess and that every good systems analyst should possess. Even if you have all the knowledge, intelligence, experience and expertise towards technical and business oriented skills, but if you do not have that good and humble attitude, it would be all worthless!

To relate it in the real situation, great percentage of systems failed. And as discussed, budget is primarily the reason. But for me, being humble and considerate enough in making a system is the key. Taking into account all the possibilities and not just think of self interests. If I would design a system that is very classic and costly to implement, only few could benefit and afford it and maybe would not be implemented at all due to financial disability. So I would rather implement a system that is simple and justly so that it would be beneficial and affordable to the majority.

Time management is not that a big issue for me. I always find time to do the things that I am supposed to do at a given time. But sometimes I have this attitude of doing things at the eleventh hour. Although I could pass the required task at the given deadline, but my product is not that admirable. I have this attitude of being moody. I do not force myself to do things that are against my will or mood because I know that my product at that time would not be that good. I just take things smoothly and do not blend in to things harshly. I always put my heart into everything I do and expects a lot from it. But if my work would be criticized or neglected; I just take it as a challenge for me to do better and prove to them that I can.

Database knowledge is also a factor to become a good systems analyst. I am now in the stage of knowing the basic relations in the database management. I was able to use and practice Visual FoxPro, have already created a simple system for records. Related relations with that data involved in the system and generated solutions to it.

A systems analyst plays a big part especially in the information security. Since, a systems analyst is in charge with the whole system, he/she knows every single data that is stored and used in a system. Intellectual skills are not enough to use as a basis for a systems analyst. Hi/her attitude counts. When it comes to data security, a systems analyst must be honest and loyal towards the company. I can say that I possess those values. In my own little way as a daughter, as a student, as a friend and as a person, I am honest and loyal enough. I can assure the company I am in with my honesty and loyalty. If I can be trusted with little things, rest assured I can also be trusted to more serious issues.

Out of all the things that I learned, I am also willing to share and teach others who wish to follow my field. I am generous to everyone who perseveres and deserves to be parted with my talent. It is my pleasure to share and could somehow serve as an inspiration to them. Others maybe would want to keep their talents for themselves, those that are selfish ones that would never grow and just remain from where they are. To more you share, the more windows of opportunity are waiting.

From the fact that I am adoptive to changes, I believe that I am competitive enough. For I always aim and look for improvement that could really help me. Sooner or later, I would be knowledgeable enough when it comes to all fields. Although I am not into competition, but I think that makes me more competitive because I seek improvement for the benefit of many and not just for my self.

During the class discussion, it was questioned that what would we prefer for a certain system analyst must possess, to be business skilled type or technically skilled one? Although I am in the field of computer science, and technically skilled enough to be a systems analyst, I still want to be knowledgeable in business. For short, a systems analyst must be integrated enough on different professions. Anyone could be a systems analyst providing that you have all the skills needed. No one is born to be a systems analyst but one is trained to be one of a “good systems analyst.”

For four years stay in college, still I can say that I am not yet a good systems analyst. I still have to learn more. I still need experiences to bold myself to become one. Aside from the characteristics I enumerated above, it might seem many or perfect, still it’s not yet enough. For me to determine my weakness or characteristic that needs to be practiced, let me analyze it one by one.

Analytically, I still need to research more on different algorithm approaches. I must be knowledgeable on business oriented situations so that I can analyze well and provide good solutions.

Technically, the languages that I was able to practice are Assembly, C, C++ and Java. That means that I have to research more on different or other object oriented related programming languages for me to express more my system design and for me to produce a good system.

In managerial field, I still need more experience. But I am hoping that as we go on with our project, I will learn many things and practice much more good characteristics. And also practice not to be totally dominant on things and give way to my colleagues.

Intrapersonal skill is the one I humbly possess greatly. I just have to develop it as we go along with this subject, Systems Analysis and Design.

Having been illustrated the characteristics that I possess as a good systems analysis, I can now view my self on where stage I am already in the development of our system. I have laid the dos and manifested the don’ts; I can now develop my self to become a good systems analyst.

Resources:

http://en.wikipedia.org/wiki/Systems_analyst
http://en.wikipedia.org/wiki/Systems_analyst
'Role of the Systems Analyst' - Systems Analysis and Design, Kendall and Kendall p. 5

Yeheey!!!!!!!!!

2009-12-07T20:26:00.000-08:00

I just got in to blog!!!!!

Congratulations to me!!!!!!!!

hehehe........

:-)