1 / 12

TDT4252/DT8802 Exam 2013 Guidelines to answers

TDT4252/DT8802 Exam 2013 Guidelines to answers. 1. Enterprise Architecture: 1 (a). Strategic Intention

brady-baird
Download Presentation

TDT4252/DT8802 Exam 2013 Guidelines to answers

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. TDT4252/DT8802 Exam 2013Guidelines to answers

  2. 1. Enterprise Architecture: 1 (a) • Strategic Intention • Create an architectural vision for the enterprise architecture project and the enterprise as a whole. Includes creating a common understanding and identifying a common requirements vision (e.g. Gartner), and creating high level business requirements (e.g. TOGAF). • Business Architecture • Here, the focus is on the business terms. Create the product and/or service strategy, identify the baseline business arhitecture and define the future business architecture and identify the gaps between them. • InformationArchitecture • Here, the focus is on the information. Identify major sources of information necessary to support the business architecture. Identify the baseline information arhitecture and define the future information architecture and identify the gaps between them. • Technical Architecture • Here, the focus is on the information. Identify the technology and the technological services that will form the basis of the implementation of technology. Define the infrastructure necessary to support proposed new architecture. • Portfolio Management • Management and governance of the enterprise architecture endeavour by identifying major implementation projects, prioritising them, evaluating business opportunities associated with them.

  3. 1 (b) – types of roles • Strategic Intention • CEO or top management • Business Architecture • Business Manager • InformationArchitecture • CIO or IT Manager • Technical Architecture • CIO or IT Manager • Portfolio Management • Both business and IT manager • Note these are clearly explained in the case study in the paper by Sessions.

  4. 1 (c) • Examples of support for reuse of knowledge and best practices: • A taxonomy of models or types of information to be considered. E.g. Zachman Framework. • Reference models such as Technical Reference model in TOGAF & FEA, Business, Service Component, Data and Performance Reference models in FEA. • Standards Information database in TOGAF

  5. Question 2: Stakeholders and Requirements Modelling. 2 (a) • Human Activity Modelling • Aim: to understand the activities done by the humans. • Activities: Identify the goals of the human activities, the resources required and the actions involved in the activities. • System Goal Modelling • Aim: to understand the system context and the boundaries between the human activity and the system. An understanding of the stakeholders' requirements from the system perspective. • Activities: identify the context, the system actors and their dependencies, input to scenarios and requirements management. • Use case modelling • Aim: to acquire the requirements from stakeholders that are complete, precise and testable. • Activities: create use case diagrams using input from the i* models and use case descriptions. • Requirements management • Aim: to collect and structure all the requirements, ensure that they are categorised so that they can be tested. • Activities: requirements management activities as stated In the aims of this activity.

  6. 2 (b) – types of models • Human Activity Modelling • Stakeholder model, structured descriptions of actitivties, perhaps high-level activity models. • System Goal Modelling • Goal model, i* models (SD and SR models). • Use case modelling • Use case models and descriptions (UML) • Requirements management • Requirements models

  7. 2(c) . Example of a metamodel High-level actvity models Goals (i*) Requirements Stakeholders Use cases Systems model

  8. Question 3: Interoperability3 (a) • Definition: • Interoperability is a property of a product or system, whose interfaces are completely understood, to work with other products or systems, present or future, without any restricted access or implementation. • The ability of two or more systems or components to exchange information and to use the information that has been exchanged (IEEE). • Examples: When 2 companies (e.g. a manufacturer and a supplier) need to share some information, when the doctor sends information to the hospital about a patient, or writes a prescription to a patient that should be used by the pharmacy.

  9. 3 (b) – 3 types of interoperability • Syntactic Interoperability: • If two or more systems are capable of communicating and exchanging data, they are exhibiting syntactic interoperability. Specified data formats, communication protocols and the like are fundamental. XML or SQL standards are among the tools of syntactic interoperability. • Example: if the data about a patient from the GP is received correctly at the pharmacy, e.g. date of birth. • Semantic Interoperability: • The ability to automatically interpret the information exchanged meaningfully and accurately in order to produce useful results as defined by the end users of both systems. To achieve semantic interoperability, both sides must refer to a common information exchange reference model. • Example: if the data: date of birth can be interpreted as date of birth at the pharmacy. • Business Interoperability: • The ability for diverse business processes to work together • Example: if the pharmacy is able to operate appropriately on the date of birth or other information received to conduct their work such as process the e-prescription and serve the patient.

  10. Question 4: Enterprise Modelling and Enterprise Reference Architectures • 4 (a) An Enterprise Reference Architecture (ERA) provides a framework for modelling and integrating enterprises whereas an enterprise architecture (EA) provides guidance to bridging the business and IT strategy of an enterprise. (ERA addresses the lifecycle of an enterprise. EA does not address the lifecycle issue, but considers an enterprise in a current or a future state, to move forward from one state to another.) • 4 (b) main characteristics: addresses the lifecycle of an enterprise, identifies the different types of models in an enterprise, highlights the human as well as the technological aspects of an enterprise.

  11. 4 (c) generic concepts in GERAM • GERA defines the enterprise related generic concepts recommended for use in enterprise engineering and integration projects. These concepts can be categorised as: • a) Human oriented concepts • to describe the role of humans as an integral part of the organisation and operation of an enterprise. • to support humans during enterprise design, construction and change. • b) Process oriented concepts for the description of the business processes of the enterprise; • c) Technology oriented concepts for the description of the business process supporting technology involved in both enterprise operation and enterprise engineering efforts (modelling and model use support).

  12. 4 (d) • Question 2 is about a socio-technical system, which by definition involves humans and technology. • Human oriented: stakeholders, human actvity and the interaction between the human and the technology. • Technology oriented: System goals, use cases as seen from a system's perspective, requirements from the system. • Process oriented: Not as obvious as the others. However, the observation of the human activity gives an insight into the processes to be supported by the system and the resources required by the processes. High-level actvity models Goals (i*) Requirements Stakeholders Use cases Systems model

More Related