Reviewer (ITEC - Lesson 1)
🇬🇧
In Inglés
In Inglés
Practique preguntas conocidas
Manténgase al día con sus preguntas pendientes
Completa 5 preguntas para habilitar la práctica
Exámenes
Examen: pon a prueba tus habilidades
Pon a prueba tus habilidades en el modo de examen
Aprenda nuevas preguntas
Modos dinámicos
InteligenteMezcla inteligente de todos los modos
PersonalizadoUtilice la configuración para ponderar los modos dinámicos
Modo manual [beta]
Seleccione sus propios tipos de preguntas y respuestas
Otros modos disponibles
Aprende con fichas
Completa la oración
Escuchar y deletrearOrtografía: escribe lo que escuchas
Expresión oralResponde con voz
Expresión oral y comprensión auditivaPractica la pronunciación
EscrituraModo de solo escritura
Reviewer (ITEC - Lesson 1) - Marcador
Reviewer (ITEC - Lesson 1) - Detalles
Niveles:
Preguntas:
130 preguntas
| 🇬🇧 | 🇬🇧 |
| Taking a holistic or systems view of a project; understand how it is situated within a larger organization. | Project Manager |
| Combination of interrelated elements to achieve a common objective. | System Integration |
| Defines its high-level structure; Defines the structure of software system; usually uses diagrams to illustrates services, components, layers, and interactions. | System Architecture |
| Ideas and request from employees, managers, or other internal stakeholders can serve as a source for information systems projects. | Internal Stakeholders Initiatives |
| Is a new requirement that is imposed by management, government, or some external influence. | Directive |
| Proposed by Bolman and Deal | Four Frames Model |
| Seen as structures with responsibilities, rules and procedure. | Structural Frame |
| Organizations are seen as a group or society with the obligation to satisfy human needs and build positive interpersonal and group dynamics. | Human Resource Frame |
| Structure helps define the roles and responsibilities of the members of the department, work group, or organization. | Organizational structure |
| People who do similar tasks, have similar skills and/or jobs in an organization are grouped into a functional structure. | Functional Structure |
| A mindset where one team hesitates to share information or knowledge with other teams within the same organisation. | 'organisational silos' |
| A type of basic organizational structure that organizes a company based on its different product lines, services, customer groups, or geographical locations. | Divisional Structure |
| Is a hybrid organizational structure that combines elements of both functional and divisional structures. | Matrix Structure |
| In this structure, project teams are formed to work on temporary initiatives with specific goals and deadlines. | Project Organization Structure |
| Is a framework that is used to structure, plan, and control the process of developing an information system. | System Development Methodology |
| Process of defining clear, discrete activities, and the work needed to complete each activity within a single project. | Project Planning Phase |
| Understand and document the business needs and the processing requirements of the new system | Analysis Phase |
| Design the solution system based on the requirements defined and decisions made during the analysis phase. | Design Phase |
| Ensure that the users are all trained and that the organization is ready to benefit as expected from the use of the system | Implementation Phase |
| Requirements should be written in a way that leaves no room for interpretation or misunderstanding. They should convey a single, clear meaning to all stakeholders. | Clear and Unambiguous |
| Requirements should be grounded in reality and aligned with the capabilities of the project team and available resources. | Realistic and Achievable |
| Avoid duplicating requirements. Each requirement should add unique value to the project. | Non-redundant |
| Use clear and precise language to minimize ambiguity and ensure a shared understanding among stakeholders. | Precise Language |
| Requirements should allow for some flexibility to accommodate changes that might arise during the project's lifecycle. | Adaptable to Change |
| Requirements should directly contribute to the achievement of the project's overall business goals and objectives. | Aligned with Business Goals |
| Describe what the system should do | Functional requirements |
| Consists of Constraints that must be adhered to during development | Non-functional requirements |
| Describe the specifications, constraints, and characteristics of the overall system or software being developed. | System requirements |
| Involve using various techniques and tools to create visual representations or models of the system's functionalities, behavior, structure, and interactions. | Modeling requirements |
| Depict how users interact with the system by illustrating different use cases (user scenarios) and the interactions between users and the system. | Use Case Diagrams |
| Visualize the flow of activities and actions within a process or use case. They show the sequence of steps and decisions in a graphical format. | Activity Diagrams |
| Are used to model the relationships between different data entities in a database, helping to design the data structure of the system. | Entity-Relationship Diagrams (ERDs) |
| Shows that one use case includes the functionality of another use case. | Include Relationships |
| Illustrates optional behavior that can be added to a base use case. | Extend Relationships |
| Different types of architecture are used to address various aspects of a system's structure, behavior, and implementation. | System architectural types |
| Addresses the physical components, resources, and infrastructure needed to implement a system. | Physical architecture |
| Encompasses the underlying technologies, software frameworks, programming languages, and design patterns used to build the system. | Technical architecture |
| Refers to the logical organization of a distributed system into software components. | Software architecture |
| System architecture considers how various components and subsystems interact with each other, as well as their relationships and dependencies. | Interactions and Relationships |
| System architecture addresses non-functional requirements such as scalability, availability, performance, security, reliability, and maintainability at the system level. | Non-Functional Concerns |
| Software architecture is concerned with how different software components, modules, and services interact with each other to achieve the application's functionalities. | Component Relationships |
| Software architecture abstracts away the hardware details and primarily concentrates on the logical and functional aspects of the software system. | Abstraction from Hardware |
| Used for Process Modelling language. | Business Process Modelling Notation (BPMN) |
| Used for systems engineering. | Systems Modelling Language (SysML) |
| To describe software both structurally and behaviourally with graphical notation. | Unified Modelling Language (UML) |
| To describes the views, models, behavior, and structure of the system. | Architectural design |
| Defined as how users add information to the system and how the system represents information back to the user. | Physical design |
| Is a tool that helps you break down large projects into smaller, easier-to handle stages. | Design process |
| Whether you found a pattern in negative customer feedback or you have some R&D budget left to spend, the approach stays the same. | Identify the problem you want to solve |
| At this stage, you’ll figure out the market state, whether any competing products exist or are on their way, and what user needs competitors neglect. | Research the problem in-depth |
| Start by using “how might we” questions to create a list of ideas. | Ideate possible solutions |
| So you have your shortlist of ideas. Now, it’s time to put them to the test. | Evaluate and select a promising solution |