Our task in the second assignment is to interview a System Analyst and ask the skills and characteristics must a Systems Analyst develop in order to be more effective in any design modeling process.
AMS Group of Companies
In our interview in the AMS Group of Companies located at F Torres , Davao City, we found out that the MIS Department Head was at the same time, Systems Analyst. His name was Mr. Jemrald.
He identified the problems found in their organization. Some of these are the lack of programmers, time pressures and constraints. He also shared the type of model they are implementing during the software development cycle and he cited the rapid Model. He also stated that the budgetary requirement for the project management is very minimal because they normally don’t outsource the systems. The tasked teams are the ones who create the systems in their organization. Whenever they have to outsource some systems, they are to customize it to meet the specifications needed by the organization itself.
Process models are processes of the same nature that are classified together into a model. Thus, a process model is a description of a process at the type level. Since the process model is at the type level, a process is an instantiation of it. The same process model is used repeatedly for the development of many applications and thus, has many instantiations. One possible use of a process model is to prescribe how things must/should/could be done in contrast to the process itself which is really what happens. A process model is roughly an anticipation of what the process will look like. What the process shall be will be determined during actual system development.
The goals of a process model are to be:
• Descriptive
o Track what actually happens during a process.
o Takes the point of view of an external observer who looks at the way a process has been performed and determines the improvements that have to be made to make it perform more effectively or efficiently.
• Prescriptive
o Defines the desired processes and how they should/could/might be performed.
o Lays down rules, guidelines, and behavior patterns which, if followed, would lead to the desired process performance. They can range from strict enforcement to flexible guidance.
• Explanatory
o Provides explanations about the rationale of processes.
o Explore and evaluate the several possible courses of action based on rational arguments.
o Establish an explicit link between processes and the requirements that the model needs to fulfill.
o Pre-defines points at which data can be extracted for reporting purposes.
From a theoretical point of view, the Meta-Process Modeling explains the key concepts needed to describe what happens in the development process, on what, when it happens, and why. From an operational point of view, the Meta-Process Modeling is aimed at providing guidance for method engineers and application developers.[1]
The activity of modeling a business process usually predicates a need to change processes or identify issues to be corrected. This transformation may or may not require IT involvement, although that is a common driver for the need to model a business process. Change management programmes are desired to put the processes into practice. With advances in technology from larger platform vendors, the vision of business process models (BPM) becoming fully executable (and capable of round-trip engineering) is coming closer to reality every day. Supporting technologies include Unified Modeling Language (UML), model-driven architecture, and service-oriented architecture.
Process Modeling addresses the process aspects of an Enterprise Business Architecture, leading to an all encompassing Enterprise Architecture. The relationships of a business processes in the context of the rest of the enterprise systems, data, organizational structure, strategies, etc. create greater capabilities in analyzing and planning a change. One real world example is in corporate mergers and acquisitions; understanding the processes in both companies in detail, allowing management to identify redundancies resulting in a smoother merge
The problems of designing large software systems were studied through interviewing personnel from 17 large projects. A layered behavioral model is used to analyze how three of these problems—the thin spread of application domain knowledge, fluctuating and conflicting requirements, and communication bottlenecks and breakdowns—affected software productivity and quality through their impact on cognitive, social, and organizational processes.
First, we introduce general design theory, from which a descriptive model of design processes is derived. In this model, the concept of metamodels plays a crucial role in describing the evolutionary nature of design. Second, we show a cognitive design process model obtained by observing design processes using a protocol analysis method. We then discuss a computable model that can explain most parts of the cognitive model and also interpret the descriptive model. In the computable model, a design process is regarded as an iterative logical process realized by abduction, deduction, and circumscription. We implemented a design simulator that can trace design processes in which design specifications and design solutions are gradually revised as the design.
A comprehensive model of design should address the following aspects of the design process:the state of the design ; the goal structure of the design process;design decisions; rationales for design decisions; control of the design process; and the role of learning in design. This article presents some of the most important ideas emerging from current AI research on design especially ideas for better models design. It is organized into sections dealing with each of the aspects of design listed above.
According to Ryan Magennis in his article What Does a Systems Analyst Really Do? The job of systems analyst was very exciting. He has to spent most of his time talking with users to understand the business and to other analysts to ensure compatibility between subsystems. He did a lot of design work, and created documentation for these designs, including reports, input forms, and programming specifications. He coded some of the programs himself. He learned how to test systems as well as implement them. He did some technical writing by documenting new systems, including technical documentation and user documentation. In his years being a System Analyst, he was able to making friends with all the other analysts (work was very social), learning all the time about both the business and technology, meeting new challenges such a public speaking and learning to adjust his “technical jargon” to his audience.
Systems Analyst must have the following skills:
Understanding written sentences and paragraphs in work related documents.
Writing computer programs for various purposes.
Determining causes of operating errors and deciding what to do about it.
Analyzing needs and product requirements to create a design.
Communicating effectively in writing as appropriate for the needs of the audience.
Conducting tests and inspections of products, services, or processes to evaluate quality or performance.
Giving full attention to what other people are saying, taking time to understand the points being made, asking questions as appropriate, and not interrupting at inappropriate times.
Using logic and reasoning to identify the strengths and weaknesses of alternative solutions, conclusions or approaches to problems.
Talking to others to convey information effectively.
Identifying complex problems and reviewing related information to develop and evaluate options and implement solutions.
Systems Analyst must have the knowledge of:
Circuit boards, processors, chips, electronic equipment, and computer hardware and software, including applications and programming.
Structure and content of the English language including the meaning and spelling of words, rules of composition, and grammar.
Principles and methods for curriculum and training design, teaching and instruction for individuals and groups, and the measurement of training effects.
Arithmetic, `lgebra, geometry, calculus, statistics, and their applications.
Principles and processes for providing customer and personal services. This includes customer needs assessment, meeting quality standards for services, and evaluation of customer satisfaction.
Systems Analyst must have the ability to:
Read and understand information and ideas presented in writing.
Communicate information and ideas in writing so others will understand.
Choose the right mathematical methods or formulas to solve a problem.
Listen to and understand information and ideas presented through spoken words and sentences.
Apply general rules to specific problems to produce answers that make sense.
See details at close range (within a few feet of the observer).
Communicate information and ideas in speaking so others will understand.
Come up with a number of ideas about a topic (the number of ideas is important, not their quality, correctness, or creativity).
Tell when something is wrong or is likely to go wrong. It does not involve solving the problem, only recognizing there is a problem.
Combine pieces of information to form general rules or conclusions (includes finding a relationship among seemingly unrelated events).
A systems analyst must perform the following tasks:
Interact with the customers to know their requirements
Interact with designers to convey the possible interface of the software
Interact/guide the coders/developers to keep track of system development
Perform system testing with sample/live data with the help of testers
Implement the new system
Prepare High quality Documentation
Analyze information processing or computation needs and plan and design computer systems, using techniques such as structured analysis, data modeling and information engineering.
Assess the usefulness of pre-developed application packages and adapt them to a user environment.
Confer with clients regarding the nature of the information processing or computation needs a computer program is to address.
Define the goals of the system and devise flow charts and diagrams describing logical operational steps of programs.
Determine computer software or hardware needed to set up or alter system.
Develop, document and revise system design procedures, test procedures, and quality standards.
Expand or modify system to serve new purposes or improve work flow.
Interview or survey workers, observe job performance and/or perform the job in order to determine what information is processed and how it is processed.
Provide staff and users with assistance solving computer related problems, such as malfunctions and program problems.
Recommend new equipment or software packages.
A Systems Analyst must have the following characteristics:
Investigative — Investigative characteristic frequently involves working with ideas, and require an extensive amount of thinking. These characteristics can involve searching for facts and figuring out problems mentally.
Conventional — Conventional characteristic frequently involve following set procedures and routines. These characteristics can include working with data and details more than with ideas. Usually there is a clear line of authority to follow.
Realistic — Realistic characteristic frequently involve work activities that include practical, hands-on problems and solutions. Many of the occupations require working outside, and do not involve a lot of paperwork or working closely with others.
Systems analysts need to be independent thinkers-people who can “think out of the box” by grasping concepts quickly and seeing the big picture as opposed to the small details. “
Ability to see the big picture: translate geek-speak into plain English
Identify company needs, and get everybody on board.
The system analyst must be able to communicate in writing and orally.
The analyst must easily get along with people.
The analyst must be a good listener and be able to react to what people say.
The analyst must be knowledgeable of technology. The analyst is not expected to know the intricacies of programming, but a decent general knowledge of concepts and terms is essential.
The analyst must be knowledgeable of business. The analyst is not expected to be an expert in business but a decent understanding of the client's world is required.
One should be familiar with designing concepts that is appropriate for the particular development environment. This means one who is good at designing commercial buildings isn't necessarily a good person to design residential housing. Although a lot of concepts overlap, one who is good at designing mainframe system isn't necessarily a good candidate for web projects.
One should have the skills to use the tools to facilitate his/her work. i.e. design software tools. If someone is struggling to use a hammer s/he is worrying about putting a nail in straight not about building a good structure.
One should have the industry/business knowledge or the capacity to acquire them. System implementation is a lot like a bunch of blind people trying to figure out what an elephant looks like. Each person has his/her own field expertise. However, the more knowledge one person has would make the process easier and create better results.
References:
http://answers.yahoo.com/question/index?qid=20080725042042AA2MqMh
http://en.wikipedia.org/wiki/Systems_analyst
http://jobs.virginia.gov/careerguides/computersystemsanalyst.htm
http://portal.acm.org/citation.cfm?id=50089
http://www.aaai.org/ojs/index.php/aimagazine/article/viewArticle/855
AMS Group of Companies
In our interview in the AMS Group of Companies located at F Torres , Davao City, we found out that the MIS Department Head was at the same time, Systems Analyst. His name was Mr. Jemrald.
He identified the problems found in their organization. Some of these are the lack of programmers, time pressures and constraints. He also shared the type of model they are implementing during the software development cycle and he cited the rapid Model. He also stated that the budgetary requirement for the project management is very minimal because they normally don’t outsource the systems. The tasked teams are the ones who create the systems in their organization. Whenever they have to outsource some systems, they are to customize it to meet the specifications needed by the organization itself.
Process models are processes of the same nature that are classified together into a model. Thus, a process model is a description of a process at the type level. Since the process model is at the type level, a process is an instantiation of it. The same process model is used repeatedly for the development of many applications and thus, has many instantiations. One possible use of a process model is to prescribe how things must/should/could be done in contrast to the process itself which is really what happens. A process model is roughly an anticipation of what the process will look like. What the process shall be will be determined during actual system development.
The goals of a process model are to be:
• Descriptive
o Track what actually happens during a process.
o Takes the point of view of an external observer who looks at the way a process has been performed and determines the improvements that have to be made to make it perform more effectively or efficiently.
• Prescriptive
o Defines the desired processes and how they should/could/might be performed.
o Lays down rules, guidelines, and behavior patterns which, if followed, would lead to the desired process performance. They can range from strict enforcement to flexible guidance.
• Explanatory
o Provides explanations about the rationale of processes.
o Explore and evaluate the several possible courses of action based on rational arguments.
o Establish an explicit link between processes and the requirements that the model needs to fulfill.
o Pre-defines points at which data can be extracted for reporting purposes.
From a theoretical point of view, the Meta-Process Modeling explains the key concepts needed to describe what happens in the development process, on what, when it happens, and why. From an operational point of view, the Meta-Process Modeling is aimed at providing guidance for method engineers and application developers.[1]
The activity of modeling a business process usually predicates a need to change processes or identify issues to be corrected. This transformation may or may not require IT involvement, although that is a common driver for the need to model a business process. Change management programmes are desired to put the processes into practice. With advances in technology from larger platform vendors, the vision of business process models (BPM) becoming fully executable (and capable of round-trip engineering) is coming closer to reality every day. Supporting technologies include Unified Modeling Language (UML), model-driven architecture, and service-oriented architecture.
Process Modeling addresses the process aspects of an Enterprise Business Architecture, leading to an all encompassing Enterprise Architecture. The relationships of a business processes in the context of the rest of the enterprise systems, data, organizational structure, strategies, etc. create greater capabilities in analyzing and planning a change. One real world example is in corporate mergers and acquisitions; understanding the processes in both companies in detail, allowing management to identify redundancies resulting in a smoother merge
The problems of designing large software systems were studied through interviewing personnel from 17 large projects. A layered behavioral model is used to analyze how three of these problems—the thin spread of application domain knowledge, fluctuating and conflicting requirements, and communication bottlenecks and breakdowns—affected software productivity and quality through their impact on cognitive, social, and organizational processes.
First, we introduce general design theory, from which a descriptive model of design processes is derived. In this model, the concept of metamodels plays a crucial role in describing the evolutionary nature of design. Second, we show a cognitive design process model obtained by observing design processes using a protocol analysis method. We then discuss a computable model that can explain most parts of the cognitive model and also interpret the descriptive model. In the computable model, a design process is regarded as an iterative logical process realized by abduction, deduction, and circumscription. We implemented a design simulator that can trace design processes in which design specifications and design solutions are gradually revised as the design.
A comprehensive model of design should address the following aspects of the design process:the state of the design ; the goal structure of the design process;design decisions; rationales for design decisions; control of the design process; and the role of learning in design. This article presents some of the most important ideas emerging from current AI research on design especially ideas for better models design. It is organized into sections dealing with each of the aspects of design listed above.
According to Ryan Magennis in his article What Does a Systems Analyst Really Do? The job of systems analyst was very exciting. He has to spent most of his time talking with users to understand the business and to other analysts to ensure compatibility between subsystems. He did a lot of design work, and created documentation for these designs, including reports, input forms, and programming specifications. He coded some of the programs himself. He learned how to test systems as well as implement them. He did some technical writing by documenting new systems, including technical documentation and user documentation. In his years being a System Analyst, he was able to making friends with all the other analysts (work was very social), learning all the time about both the business and technology, meeting new challenges such a public speaking and learning to adjust his “technical jargon” to his audience.
Systems Analyst must have the following skills:
Understanding written sentences and paragraphs in work related documents.
Writing computer programs for various purposes.
Determining causes of operating errors and deciding what to do about it.
Analyzing needs and product requirements to create a design.
Communicating effectively in writing as appropriate for the needs of the audience.
Conducting tests and inspections of products, services, or processes to evaluate quality or performance.
Giving full attention to what other people are saying, taking time to understand the points being made, asking questions as appropriate, and not interrupting at inappropriate times.
Using logic and reasoning to identify the strengths and weaknesses of alternative solutions, conclusions or approaches to problems.
Talking to others to convey information effectively.
Identifying complex problems and reviewing related information to develop and evaluate options and implement solutions.
Systems Analyst must have the knowledge of:
Circuit boards, processors, chips, electronic equipment, and computer hardware and software, including applications and programming.
Structure and content of the English language including the meaning and spelling of words, rules of composition, and grammar.
Principles and methods for curriculum and training design, teaching and instruction for individuals and groups, and the measurement of training effects.
Arithmetic, `lgebra, geometry, calculus, statistics, and their applications.
Principles and processes for providing customer and personal services. This includes customer needs assessment, meeting quality standards for services, and evaluation of customer satisfaction.
Systems Analyst must have the ability to:
Read and understand information and ideas presented in writing.
Communicate information and ideas in writing so others will understand.
Choose the right mathematical methods or formulas to solve a problem.
Listen to and understand information and ideas presented through spoken words and sentences.
Apply general rules to specific problems to produce answers that make sense.
See details at close range (within a few feet of the observer).
Communicate information and ideas in speaking so others will understand.
Come up with a number of ideas about a topic (the number of ideas is important, not their quality, correctness, or creativity).
Tell when something is wrong or is likely to go wrong. It does not involve solving the problem, only recognizing there is a problem.
Combine pieces of information to form general rules or conclusions (includes finding a relationship among seemingly unrelated events).
A systems analyst must perform the following tasks:
Interact with the customers to know their requirements
Interact with designers to convey the possible interface of the software
Interact/guide the coders/developers to keep track of system development
Perform system testing with sample/live data with the help of testers
Implement the new system
Prepare High quality Documentation
Analyze information processing or computation needs and plan and design computer systems, using techniques such as structured analysis, data modeling and information engineering.
Assess the usefulness of pre-developed application packages and adapt them to a user environment.
Confer with clients regarding the nature of the information processing or computation needs a computer program is to address.
Define the goals of the system and devise flow charts and diagrams describing logical operational steps of programs.
Determine computer software or hardware needed to set up or alter system.
Develop, document and revise system design procedures, test procedures, and quality standards.
Expand or modify system to serve new purposes or improve work flow.
Interview or survey workers, observe job performance and/or perform the job in order to determine what information is processed and how it is processed.
Provide staff and users with assistance solving computer related problems, such as malfunctions and program problems.
Recommend new equipment or software packages.
A Systems Analyst must have the following characteristics:
Investigative — Investigative characteristic frequently involves working with ideas, and require an extensive amount of thinking. These characteristics can involve searching for facts and figuring out problems mentally.
Conventional — Conventional characteristic frequently involve following set procedures and routines. These characteristics can include working with data and details more than with ideas. Usually there is a clear line of authority to follow.
Realistic — Realistic characteristic frequently involve work activities that include practical, hands-on problems and solutions. Many of the occupations require working outside, and do not involve a lot of paperwork or working closely with others.
Systems analysts need to be independent thinkers-people who can “think out of the box” by grasping concepts quickly and seeing the big picture as opposed to the small details. “
Ability to see the big picture: translate geek-speak into plain English
Identify company needs, and get everybody on board.
The system analyst must be able to communicate in writing and orally.
The analyst must easily get along with people.
The analyst must be a good listener and be able to react to what people say.
The analyst must be knowledgeable of technology. The analyst is not expected to know the intricacies of programming, but a decent general knowledge of concepts and terms is essential.
The analyst must be knowledgeable of business. The analyst is not expected to be an expert in business but a decent understanding of the client's world is required.
One should be familiar with designing concepts that is appropriate for the particular development environment. This means one who is good at designing commercial buildings isn't necessarily a good person to design residential housing. Although a lot of concepts overlap, one who is good at designing mainframe system isn't necessarily a good candidate for web projects.
One should have the skills to use the tools to facilitate his/her work. i.e. design software tools. If someone is struggling to use a hammer s/he is worrying about putting a nail in straight not about building a good structure.
One should have the industry/business knowledge or the capacity to acquire them. System implementation is a lot like a bunch of blind people trying to figure out what an elephant looks like. Each person has his/her own field expertise. However, the more knowledge one person has would make the process easier and create better results.
References:
http://answers.yahoo.com/question/index?qid=20080725042042AA2MqMh
http://en.wikipedia.org/wiki/Systems_analyst
http://jobs.virginia.gov/careerguides/computersystemsanalyst.htm
http://portal.acm.org/citation.cfm?id=50089
http://www.aaai.org/ojs/index.php/aimagazine/article/viewArticle/855
No comments:
Post a Comment