Monday, March 8, 2010
ERP Companies
No two people see the world the same way. We invent accordingly.
HOYA Vision Care of the Americas makes and supplies ophthalmic lenses to Eye Care Professionals located within the United States, Canada, and South American countries. HOYA supplies a complete range of high quality lens designs, coatings and materials.
HOYA is tirelessly pushing ahead with the development of new lens technologies, always offering products with superior functionality and higher quality that further meet customer needs.
HOYA's complete offering of lens products includes the high index materials EYAS™ 1.60, EYNOA™ 1.67 or EYRY™ 1.70. HOYA's Phoenix™ lens material offers the broadest range of consumer benefits - it's safe, tough, light and clear.
HOYA offers superior AR lens performance through SUPER HiVision - the most scratch resistant anti-reflective coating on the market today. SUPER HiVision also automatically includes HOYA's ViewProtect, providing "easy to clean" lenses.
In the area of lens designs, HOYA offers unbeatable products such as HOYALUX iD - the world’s first integrated double-surface progressive lens design.
No matter what the needs of your patient are, HOYA has an unbeatable solution.
Mission Statement
Our Mission is to provide North America's highest quality eyewear and the industry's best customer service, to meet our customer's requirements and exceed their patient’s expectations.
Our Values
Team members who:
-Treat one another with fairness and respect
-Take accountability and ownership for failures as well as successes
A Company that:
-Believes and demonstrates that the customer is of the most importance
-Supports open and honest communications without fear of reprisal
-Celebrates its successes
A Workplace that:
-Provides the tools and resources to provide Great Quality
-Is safe from injuries and pleasant to work in
-Encourages and supports continuous improvement
-Provides training and opportunities for career advancement
HOYA Corporation Worldwide
Creating opportunities and exploiting them.
From our inception back in 1941, the HOYA Corporation has experienced remarkable growth. We intend to continue to expand our horizons in the future to be able to create and exploit new opportunities together with you, our customers.
A flexible global player.
The year 1974 heralded a period of globalization for the HOYA Corporation. Since then factories and distribution centres have been opened worldwide including our acquisition of the Buchmann group, which strengthened our position within Europe, and the integration of the North American market. All of our branches are founded on local and regional circumstances and cultural qualities, by spreading its production capacity in this way HOYA is able to operate flexibly.
It is not just a unique position from which we can provide you with new technologies and products; it is much more than that. It is also the far-reaching support that forms a central part of our working culture. In the meantime, with 46 branches in 24 countries HOYA has carved out a strong position for itself and in the process has become a flexible, global player.
This is the article that was release which is a sub company of HOYA Visions.
PRESS RELEASE - July 2009
Important step in the strategic plan of INDO a sub company of HOYA
Indo has reached a strategic agreement with the Japanese multinational Hoya.
Indo has signed an agreement with its bankers’ pool to refinance up to 85% of its bankers debt.
The Institut Català de Finances has granted a credit of 8 million euros.
Barcelona, 31 July- Commitments completed. This is what the strategic and financial alliances could be considered to be. One year ago, when Juan Casaponsa became the new Indo Executive President, Indo announced that the company initiated a major project of transformation. This project has been materializing in its two main areas: the refocusing on its three business units: lenses, eyewear and equipment, and consolidating and ensuring their financial soundness. Regarding financial soundness, just a year ago Indo made a successful capital increase. Now we can announce the agreement reached with the Banco Santander, BBVA, Bancaja, Banco de Sabadell and Banco Popular Español to refinance, in the long term, around 85% of its debt, which is equivalent to some 35 million euros. Besides, Indo has obtained a loan of 8 million euros from the Institut Català de Finances. These financing agreements underscore the trust placed in Indo’s financial future by financial entities and the Public Administration. The new approach in its three business units began with the Indo-Buchmann agreement of intent to merge their respective businesses of Equipment in order to create the new world leader in machinery. In the eyewear area, last Shareholders’ general Meeting we announced the agreement with McLaren for the design, production and worldwide marketing of its brand eyewear, which collections are avant-garde designed, innovative in materials and high added valued. In lens area, Indo reminded at a Shareholders’ General Meeting, that efforts were being made to strike-up a strategic alliance. The project has materialised with the signing of the agreement between the ophthalmic lenses divisions of Indo Lens Group and Hoya Vision Care. Hoya Corporation is the leading Japanese optical manufacturer and one of the worldwide ophthalmic lenses leaders regarding its business turnover. It also has other business areas such as Information Technology, Medical and Image Systems. Hoya Vision Care is one of its most important divisions, with its head office in Holland, and it is especially known for being a reference in high-index lenses, hardening and non-reflecting treatments for lenses and its products are among the most technologically advanced. This alliance will allow the interchange and supply of technology and of products, as well as collaboration in matters of research and development between the two companies. The agreement, which will be valid until the end of 2015 and which is extendable, states that Hoya will contribute 15 million euros to purchase technology and that Indo Lens Group will buy approximately 25% - 30% of its supply needs each year from Hoya Vision Care, especially in semi-finished products currently purchased from various sources of supply around the world. A key aspect of the agreement is that the two companies will continue to compete independently in all the markets, maintaining differentiated commercial strategies and complete independence in the management of each company. Juan Casaponsa, Indo's Executive President, considers that this strategic alliance will allow Indo “to substantially improve its structure of costs, making the most of synergies in R&D and offering the customer a wider and more innovative portfolio of products. Thanks to the association with Hoya, Indo will also benefit in scale, meaning that it will open the door to increasing its international presence with the entry into new markets". “The initiated transformational approach and the new new strategic business plan, will now be developed in detail once they have secured the foundations”
About Hoya Corporation
Since its creation in 1941 in Japan, Hoya Corporation has been the leading manufacturer of ophthalmic lenses. The Japanese giant company, which is listed in the first section of the Tokyo Stock Exchange, has diversified its business areas to also include information technology, medical systems and imaging. With more than 32,000 employees and 100 subsidiaries, Hoya Corporation registered total sales of 454.1 billion Japanese yen in the fiscal year 2009 (04/08 - 03/09). Hoya Vision Care Europe is responsible for the regional management of the Vision Care division, logistics centre, sales and marketing activities, dealing with European subsidiary companies and export activities in Europe, the Middle East and North and South Africa. The Spanish subsidiary company had a turnover of 26 million euros in 2008. About Indo International Indo is a Spanish multinational company dedicated to manufacturing and commercializing lenses, eyewear, sunglasses and equipment for opticians and ophthalmologists. Indo has more than 70 years' experience in the optical sector and is one of the leaders in the Spanish market. The group has subsidiary companies in the United States, France, Italy, Portugal, Morocco, India and Chile and has production centres in Spain, China and Thailand. Indo exports its products to more than 80 countries.
So to define Enterprise resource planning (ERP) is an integrated computer-based system used to manage internal and external resources including tangible assets, financial resources, materials, and human resources. It is a software architecture whose purpose is to facilitate the flow of information between all business functions inside the boundaries of the organization and manage the connections to outside stakeholders. Built on a centralized database and normally utilizing a common computing platform, ERP systems consolidate all business operations into a uniform and enterprise wide system environment.
An ERP system can either reside on a centralized server or be distributed across modular hardware and software units that provide "services" and communicate on a local area network. The distributed design allows a business to assemble modules from different vendors without the need for the placement of multiple copies of complex, expensive computer systems in areas which will not use their full capacity.
While SDLC Systems Development Life Cycle (SDLC) is a logical process used by a systems analyst to develop an information system, including requirements, validation, training, and user (stakeholder) ownership. Any SDLC should result in a high quality system that meets or exceeds customer expectations, reaches completion within time and cost estimates, works effectively and efficiently in the current and planned Information Technology infrastructure, and is inexpensive to maintain and cost-effective to enhance.
Computer systems are complex and often (especially with the recent rise of Service-Oriented Architecture) link multiple traditional systems potentially supplied by different software vendors. To manage this level of complexity, a number of systems development life cycle (SDLC) models have been created: "waterfall"; "fountain"; "spiral"; "build and fix"; "rapid prototyping"; "incremental"; and "synchronize and stabilize".
SDLC models can be described along a spectrum of agile to iterative to sequential. Agile methodologies, such as XP and Scrum, focus on light-weight processes which allow for rapid changes along the development cycle. Iterative methodologies, such as Rational Unified Process and Dynamic Systems Development Method, focus on limited project scopes and expanding or improving products by multiple iterations. Sequential or big-design-upfront (BDUF) models, such as Waterfall, focus on complete and correct planning to guide large projects and risks to successful and predictable results.
Some agile and iterative proponents confuse the term SDLC with sequential or "more traditional" processes; however, SDLC is an umbrella term for all methodologies for the design, implementation, and release of software.
In project management a project can be defined both with a project life cycle (PLC) and an SDLC, during which slightly different activities occur. According to Taylor (2004) "the project life cycle encompasses all the activities of the project, while the systems development life cycle focuses on realizing the product requirements”.
References:
http://www.hoyavision.com/home.aspx
http://linux.sys-con.com/node/160739
http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle
http://en.wikipedia.org/wiki/Enterprise_Resource_Planning
http://docs.google.com/viewer?a=v&q=cache:UkGw6w1qSZAJ:www.hoya.be/dn.php%3Fid%3D97394%26m%3D0%26dm%3D1+HOYA+Vision+Project+Plans&hl=tl&gl=ph&pid=bl&srcid=ADGEEShu0URvoO1EEGlSrwvYAxIIlNYFGVd1tF5ITvyURciqhzMgHZC47WsP0NcklSVqIafVNOZAmnI5JscNw3t1FtsV1TQVweVABfcLVo-3S6qn7Amd48hP0Mw8Wl64mNgusN-hsGd-&sig=AHIEtbTQmSzG2fe01uKDyR-4o-801re00A
Deployment Environment
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.
So basically, my idea is that use open source servers because the primary benefit of open source is that it is free. Also considering the university which lacks in budget allocation should really be advisable to use open source servers. But I’m not against package servers my point only is that we consider the budget allocation of the university. But for me, as to evaluate I think I would use Microsoft package servers because it’s the most commonly used servers. So I basically choose the SharePoint 2007. For organizations preparing to deploy SharePoint™ 2007 or to move from a pilot to full deployment, creating a properly designed environment is critical to the successful deployment of an enterprise business productivity infrastructure. The purpose of the SharePoint Environment Design and Deployment is to create a design and project plan that will meet the organizations requirements and leverages Microsoft and DataLan standards and best practices around the following areas: Physical Architecture, Logical Layout, Security Configuration, Connectivity Planning, Usability Planning, Disaster Prevention and Recovery Planning.
• Physical Architecture – This includes the physical layout of the servers and network elements needed for the SharePoint environment. Physical architecture considerations will include:
o SharePoint Server Farm Topology Configuration
o Third Party and Custom Service Configuration
o Server specifications and allocations
o Network integration points with other systems
o Network entry/boundary points
• Logical Layout – This includes the logical layout of the SharePoint web application and service elements needed for the environment. The logical layout review addresses:
o Web application, site collection and site structure and configuration
o Shared Services and My Site placement and configuration
• Security Configuration – This outlines the security mechanisms that will be employed to control access to the environment and environment resources including:
o Environment access method and AD integration
o Content access, control, and governance
o Security delegation
o Auditing and Policy management requirements
• Connectivity Planning – Details the environment access points and user connectivity methodology and controls. Connectivity planning includes:
o Local connectivity approach planning
o Remote user connectivity approach planning
• Usability Planning – Details the usage for the environment and reviews application needs and plans. Usability planning includes:
o User experience and usage of the environment will be reviewed
o Application planning will be performed in order to identify those applications to be created within or migrated into the environment
• Disaster Prevention and Recovery Planning – Including the protection of the environment from potential service interruptions or loss of data in the event of a disaster. This planning includes:
o Environment disaster methodology creation based on SLA requirements
o Environment backup requirement levels
o Environment Monitoring requirements and solution architecture
The deliverables include:
• SharePoint environment architecture document detailing all aspects of the environmental architecture
• Deployment of the SharePoint environment based on the Enterprise Architecture Plan
o Installation of a SharePoint small or medium farm environment
o Documentation of the installation and configuration of the SharePoint environment
But I’m not closing my doors to any suggestions or alternatives, maybe in my own opinion this is the deployment environment that I would suggest to them to be defined and used.
References:
http://sharepoint.microsoft.com/Pages/Default.aspx
http://www.datalan.com/Solutions/Pages/Design%20and%20Deployment.aspx
So basically, my idea is that use open source servers because the primary benefit of open source is that it is free. Also considering the university which lacks in budget allocation should really be advisable to use open source servers. But I’m not against package servers my point only is that we consider the budget allocation of the university. But for me, as to evaluate I think I would use Microsoft package servers because it’s the most commonly used servers. So I basically choose the SharePoint 2007. For organizations preparing to deploy SharePoint™ 2007 or to move from a pilot to full deployment, creating a properly designed environment is critical to the successful deployment of an enterprise business productivity infrastructure. The purpose of the SharePoint Environment Design and Deployment is to create a design and project plan that will meet the organizations requirements and leverages Microsoft and DataLan standards and best practices around the following areas: Physical Architecture, Logical Layout, Security Configuration, Connectivity Planning, Usability Planning, Disaster Prevention and Recovery Planning.
• Physical Architecture – This includes the physical layout of the servers and network elements needed for the SharePoint environment. Physical architecture considerations will include:
o SharePoint Server Farm Topology Configuration
o Third Party and Custom Service Configuration
o Server specifications and allocations
o Network integration points with other systems
o Network entry/boundary points
• Logical Layout – This includes the logical layout of the SharePoint web application and service elements needed for the environment. The logical layout review addresses:
o Web application, site collection and site structure and configuration
o Shared Services and My Site placement and configuration
• Security Configuration – This outlines the security mechanisms that will be employed to control access to the environment and environment resources including:
o Environment access method and AD integration
o Content access, control, and governance
o Security delegation
o Auditing and Policy management requirements
• Connectivity Planning – Details the environment access points and user connectivity methodology and controls. Connectivity planning includes:
o Local connectivity approach planning
o Remote user connectivity approach planning
• Usability Planning – Details the usage for the environment and reviews application needs and plans. Usability planning includes:
o User experience and usage of the environment will be reviewed
o Application planning will be performed in order to identify those applications to be created within or migrated into the environment
• Disaster Prevention and Recovery Planning – Including the protection of the environment from potential service interruptions or loss of data in the event of a disaster. This planning includes:
o Environment disaster methodology creation based on SLA requirements
o Environment backup requirement levels
o Environment Monitoring requirements and solution architecture
The deliverables include:
• SharePoint environment architecture document detailing all aspects of the environmental architecture
• Deployment of the SharePoint environment based on the Enterprise Architecture Plan
o Installation of a SharePoint small or medium farm environment
o Documentation of the installation and configuration of the SharePoint environment
But I’m not closing my doors to any suggestions or alternatives, maybe in my own opinion this is the deployment environment that I would suggest to them to be defined and used.
References:
http://sharepoint.microsoft.com/Pages/Default.aspx
http://www.datalan.com/Solutions/Pages/Design%20and%20Deployment.aspx
Evaluating DFD Quality
With reference to assignments 8 and 9, what characteristics does an analyst (you) examine when evaluating DFD quality? (1500 words)
Before going to the point I will just discuss about what Data Flow Diagram is:
As information moves through software, it is modified by a series of transformations. A data flow diagram is a graphical representation that depicts information flow and the transforms that are applied as data move from input to output. The basic form of a data flow diagram, also known as a data flow graph or a bubble chart, is illustrated in Figure 1. The data flow diagram may be used to represent a system or software at any level of abstraction. In fact, DFDs may be partitioned into levels that represent increasing information flow and functional detail. Therefore, the DFD provides a mechanism for functional modeling as well as information flow modeling. In so doing, it satisfies the second operational analysis principle (i.e., creating a functional model). A level 0 DFD, also called a fundamental system model or a context model, represents the entire software element as a single bubble with input and output data indicated by incoming and outgoing arrows, respectively. Additional processes (bubbles) and information flow paths are represented as the level 0 DFD is partitioned to reveal more detail. For example, a level 1 DFD might contain five or six bubbles with interconnecting arrows. Each of the processes represented at level 1 is a sub function of the overall system depicted in the context model. As has been noted earlier, each of the bubbles may be refined or layered to depict more detail.
As information moves through software, it is modified by a series of transformations. A data flow diagram is a graphical representation that depicts information flow and the transforms that are applied as data move from input to output. The basic form of a data flow diagram, also known as a data flow graph or a bubble chart. The data flow diagram may be used to represent a system or software at any level of abstraction. In fact, DFDs may be partitioned into levels that represent increasing information flow and functional detail. Therefore, the DFD provides a mechanism for functional modeling as well as information flow modeling. In so doing, it satisfies the second operational analysis principle (i.e., creating a functional model). A level 0 DFD, also called a fundamental system model or a context model, represents the entire software element as a single bubble with input and output data indicated by incoming and outgoing arrows, respectively. Additional processes (bubbles) and information flow paths are represented as the level 0 DFD is partitioned to reveal more detail. For example, a level 1 DFD might contain five or six bubbles with interconnecting arrows. Each of the processes represented at level 1 is a sub function of the overall system depicted in the context model. As has been noted earlier, each of the bubbles may be refined or layered to depict more detail.
Data flow diagrams defined
Data flow diagram is a geographical tool that shows, process, flows, stores and external entities in a system. Dataflow diagram shows the transformation of data into a system. DFD has got the following symbols
Process flow diagrams
Process symbol has got the following entities, process number (tells the number of the process), locality (where activity is happening) and a process name
Data flow datagram process symbol rules
• It symbolizes the transformation of data
• There must be data flowing into/out of the process
• Process can have several inputs to it or output to it
• Process with no out becomes a null process
Data store Symbol
Consist of the following entities, data store number and name of data store. The function of data store is to designate the storage of data in a DFD diagram
Rules of Data store
• DFD data store do not by level but they may reappear incase needed
• The symbol and the numbering remain the same
Data flow symbol
Data flow symbol may appear in different shape and they signify the movement of data. They do not signify the movement of people, goods etc
• Doubles arrows signifies that activities occur at the same time which is wrong
• Data flow in is never equal to data flow out
Extended entity symbol
Extended entity is sources and destination of data. This means that source is the origin and destination is the sink of data
Dos and Don’ts of external entity
• External entity never communicate with each other, this signify that there is no need for the process
• External entity should not communicate directly with data store because external entities can be identifier with the record of files and databases
How to develop Logical data flow diagram
Below are the guidelines in developing data flow diagrams
1. Develop a physical DFD
2. Explore the process for more details
3. Maintain consistency between the process
4. Following meaningful leveling convention
5. Ensure that DFD diagrams clarifies what is happening in the system
6. Remember DFD audience
7. Add control on the lower level DFD only
8. Assign meaningful level
9. Evaluate DFD for correctness
Step in drawing DFD diagrams
1. Make a list of all business activities and use it to determine the various external entities, data flows, process and data store
2. Create a context diagram which shows external entity and data flows to and from the system
3. Do not show any detailed process or data store
4. Draw diagram zero or the next level to show process but keep them general. Show data stores and the level
5. Create a child diagram for each of the process in diagram zero
6. Check for errors and make sure the levels you assign to each process and data flow are meaningful
7. Develop a physical DFD diagram from the logical DFD and distinguish between the manual and automated protocol, describe actual files and report by name and controls to indicate when the process are complete or errors occurs
8. Portion the physical DFD by separating or grouping parts of the diagram in order to facilitate programming and implementation
Advantages of data flow diagrams
• It gives further understanding of the interestedness of the system and sub-systems
• It is useful from communicating current system knowledge to the user
• Used as part of the system documentation files
• Dataflow diagram helps to substantiate the logic underlining the dataflow of the organization
• It gives the summary of the system
• DFD is very easy to follow errors and it is also useful for quick reference to the development team for locating and controlling errors
Disadvantages of data flow diagram
• DFD is likely to take many alteration before agreement with the user
• Physical consideration are usually left out
• It is difficult to understand because it ambiguous to the user who have little or no knowledge
So basically, these are the characteristics that a system analyst must have in order to evaluate the Data Flow Diagram with quality. The system analyst must have a good background of what are the systems that existed and he should also be able to identify what are those processes that a system must have with regarding to the goals of the organization. And also, an analyst must gather important information in order to have sufficient information in making the DFD. And he also must have enough background on what is their business processes. Good communication skills as well as good critical thinking. And lastly, being able to adapt to change, as we all know we are in the fast changing world or era. Well, that’s it. These are the characteristics that a good system analyst must have in order to evaluate the DFD with quality.
References:
http://hubpages.com/hub/What-is-a-data-flow-diagram
Before going to the point I will just discuss about what Data Flow Diagram is:
As information moves through software, it is modified by a series of transformations. A data flow diagram is a graphical representation that depicts information flow and the transforms that are applied as data move from input to output. The basic form of a data flow diagram, also known as a data flow graph or a bubble chart, is illustrated in Figure 1. The data flow diagram may be used to represent a system or software at any level of abstraction. In fact, DFDs may be partitioned into levels that represent increasing information flow and functional detail. Therefore, the DFD provides a mechanism for functional modeling as well as information flow modeling. In so doing, it satisfies the second operational analysis principle (i.e., creating a functional model). A level 0 DFD, also called a fundamental system model or a context model, represents the entire software element as a single bubble with input and output data indicated by incoming and outgoing arrows, respectively. Additional processes (bubbles) and information flow paths are represented as the level 0 DFD is partitioned to reveal more detail. For example, a level 1 DFD might contain five or six bubbles with interconnecting arrows. Each of the processes represented at level 1 is a sub function of the overall system depicted in the context model. As has been noted earlier, each of the bubbles may be refined or layered to depict more detail.
As information moves through software, it is modified by a series of transformations. A data flow diagram is a graphical representation that depicts information flow and the transforms that are applied as data move from input to output. The basic form of a data flow diagram, also known as a data flow graph or a bubble chart. The data flow diagram may be used to represent a system or software at any level of abstraction. In fact, DFDs may be partitioned into levels that represent increasing information flow and functional detail. Therefore, the DFD provides a mechanism for functional modeling as well as information flow modeling. In so doing, it satisfies the second operational analysis principle (i.e., creating a functional model). A level 0 DFD, also called a fundamental system model or a context model, represents the entire software element as a single bubble with input and output data indicated by incoming and outgoing arrows, respectively. Additional processes (bubbles) and information flow paths are represented as the level 0 DFD is partitioned to reveal more detail. For example, a level 1 DFD might contain five or six bubbles with interconnecting arrows. Each of the processes represented at level 1 is a sub function of the overall system depicted in the context model. As has been noted earlier, each of the bubbles may be refined or layered to depict more detail.
Data flow diagrams defined
Data flow diagram is a geographical tool that shows, process, flows, stores and external entities in a system. Dataflow diagram shows the transformation of data into a system. DFD has got the following symbols
Process flow diagrams
Process symbol has got the following entities, process number (tells the number of the process), locality (where activity is happening) and a process name
Data flow datagram process symbol rules
• It symbolizes the transformation of data
• There must be data flowing into/out of the process
• Process can have several inputs to it or output to it
• Process with no out becomes a null process
Data store Symbol
Consist of the following entities, data store number and name of data store. The function of data store is to designate the storage of data in a DFD diagram
Rules of Data store
• DFD data store do not by level but they may reappear incase needed
• The symbol and the numbering remain the same
Data flow symbol
Data flow symbol may appear in different shape and they signify the movement of data. They do not signify the movement of people, goods etc
• Doubles arrows signifies that activities occur at the same time which is wrong
• Data flow in is never equal to data flow out
Extended entity symbol
Extended entity is sources and destination of data. This means that source is the origin and destination is the sink of data
Dos and Don’ts of external entity
• External entity never communicate with each other, this signify that there is no need for the process
• External entity should not communicate directly with data store because external entities can be identifier with the record of files and databases
How to develop Logical data flow diagram
Below are the guidelines in developing data flow diagrams
1. Develop a physical DFD
2. Explore the process for more details
3. Maintain consistency between the process
4. Following meaningful leveling convention
5. Ensure that DFD diagrams clarifies what is happening in the system
6. Remember DFD audience
7. Add control on the lower level DFD only
8. Assign meaningful level
9. Evaluate DFD for correctness
Step in drawing DFD diagrams
1. Make a list of all business activities and use it to determine the various external entities, data flows, process and data store
2. Create a context diagram which shows external entity and data flows to and from the system
3. Do not show any detailed process or data store
4. Draw diagram zero or the next level to show process but keep them general. Show data stores and the level
5. Create a child diagram for each of the process in diagram zero
6. Check for errors and make sure the levels you assign to each process and data flow are meaningful
7. Develop a physical DFD diagram from the logical DFD and distinguish between the manual and automated protocol, describe actual files and report by name and controls to indicate when the process are complete or errors occurs
8. Portion the physical DFD by separating or grouping parts of the diagram in order to facilitate programming and implementation
Advantages of data flow diagrams
• It gives further understanding of the interestedness of the system and sub-systems
• It is useful from communicating current system knowledge to the user
• Used as part of the system documentation files
• Dataflow diagram helps to substantiate the logic underlining the dataflow of the organization
• It gives the summary of the system
• DFD is very easy to follow errors and it is also useful for quick reference to the development team for locating and controlling errors
Disadvantages of data flow diagram
• DFD is likely to take many alteration before agreement with the user
• Physical consideration are usually left out
• It is difficult to understand because it ambiguous to the user who have little or no knowledge
So basically, these are the characteristics that a system analyst must have in order to evaluate the Data Flow Diagram with quality. The system analyst must have a good background of what are the systems that existed and he should also be able to identify what are those processes that a system must have with regarding to the goals of the organization. And also, an analyst must gather important information in order to have sufficient information in making the DFD. And he also must have enough background on what is their business processes. Good communication skills as well as good critical thinking. And lastly, being able to adapt to change, as we all know we are in the fast changing world or era. Well, that’s it. These are the characteristics that a good system analyst must have in order to evaluate the DFD with quality.
References:
http://hubpages.com/hub/What-is-a-data-flow-diagram
Subscribe to:
Posts (Atom)