App Dev Enterprise Day 1 PDF

**True or False** **Identification** **APP DEV** **Software quality** is the degree to which a software product meets the gathered requirements. **Software quality assurance** is a set of activities that define and assess the adequacy of software process to provide evidence which establishes con...

**True or False** **Identification** **APP DEV** **Software quality** is the degree to which a software product meets the gathered requirements. **Software quality assurance** is a set of activities that define and assess the adequacy of software process to provide evidence which establishes confidence that the software processes are appropriate for and produce software products of suitable quality for their intended processes. **Reputation** -- Software developers and their organizations rely on this. Software bugs can have immediate impacts on clients or customers. **Limiting** **Technical** **Debt** -- Poor quality software tends to be expensive to develop and maintain, which can negatively affect organizations or end up maintaining the software in the longer term. These costs are often referred to as "technical debt." **Software** **Certification** -- The development and use of the software might require some form of certification, which can often require evidence of the application of various quality control and assessment measures. **Legality** -- There may be overriding legal obligations that apply to organizations that use the software. As such, every practicable measure must be taken to demonstrate that the software system does not pose a risk to its users. **Ethical** **Codes** of **Practice** -- In cases where a software system is not covered by software certification and legislation, and where its failure is not necessarily business or safety-critical, there can remain moral obligation to the users. **Software prototyping** refers to building software application prototypes which **displays** the **functionality** of the product under development, but may not actually hold the exact logic of the original software. - Allow users to evaluate the software system design and how the software actually works. - Clarify the functionalities of the software to both users and developers - Reduce cost and time relative to building software product and iterating the process - Reduce the need to recreate the software system due to some gaps on the implementation. **Paper**-**Based** **Prototyping** -- This prototyping technique is used to create a prototype based on hand drawings that represent user interfaces of the software **Wireframing** -- A wireframe is a visual representation of a product page that developers can use to arrange pages of user interfaces **Software inspection** or **software review** is a formalized peer review process for detecting and correcting defects or bugs in software artifacts. **Software artifacts** are any things that have been documented and stored during the software development process, such as requirements document, source code, user documentation, and test plans and test cases. **Fagan inspection methodology** -- This methodology was **developed** by Michael Fagan. The objectives of this methodology are to identify and remove errors in the software products and to identify any systematic defects in the processes that are used to create software products. **Moderator** -- S/He leads the inspection team and takes care of logistics. **Author** -- S/He is the creator of the software artifacts under inspection. The author will actively answer all the questions regarding the artifacts during the inspection meeting. The author is responsible for fixing identified defects and bugs in the artifacts **Reader** -- S/He is an experienced peer who can be a subject matter expert on the software artifacts under inspection. **Tester** -- S/He is responsible for writing and executing test cases for the software module or product. The role of the tester is focused on how the product would be tested. **Structured** **Walkthrough** -- It is a peer review in which the author of a deliverable, such as a document or source code, brings one (1) or more reviewers through the deliverable. **Code reviewing** or **inspection** is the act of systematically convening with fellow programmers to check each other's code for faults to ensure the code meets quality standards. **Tool-Driven Code Review** -- This approach uses automated code analysis techniques that can **pick** **out problematic patterns** within the source code. The source code analysis drive automated code reviews. **Developer-Driven Code Review** -- Some properties of code quality are difficult to assess automatically. In this approach, the developers themselves reviews the code to pick out problems. Then, the reviewers manually assess source codes before deployment **The modern code review** is a lightweight variant of the code inspections because it does not rely on face-to-face meetings. This operates on tools and development processes. **Pull-Based Development** -- This development approach enforces modern code review and does **not use** code reviewing tools. This revolves around a mechanism known as a "**pull request**." **\ ** **Enumeration** **True or False** **Identification** **ARCHI ENTREP** **MODELING AS TRANSFORMATION PROCESS** **Knowledge Representation** -- This depicts an enterprise architecture model in a specific manner based on the agreed perception of the individuals involved in the process. **Knowledge Goals** -- These are the goals under the modeling process of an enterprise architecture. **Knowledge State** -- This involves the condition and commitment of stakeholders on enterprise architecture. **Knowledge Transformation** -- This is the situation where knowledge passes through the modeling process while considering goals and guidelines. **Central Representations** -- These are the primary and essential models that are used in the transformation of knowledge. **DIFFERENT MODELING ACTIVITIES** ** Establishing the purpose, scope, and focus** -- It is a goal-driven activity wherein architects determine all possible stakeholders and the different purposes of the model in relation to the stakeholders. **Establishing the purpose, scope, and focus** -- This is considered as a starting point in establishing a model. **Selecting one or more viewpoints** -- Models are created using different viewpoints that give a specific set of concepts and relations to be used during the modeling process. **Creating and structuring the model** -- This activity involves requirements gathering, such as appropriate information, to create, structure, and visualize an enterprise architecture model. **Visualizing the model** -- Stakeholders and their needs must be considered in visualizing a model. **Using the model** -- This activity uses the model representation to communicate with the stakeholders and evaluate whether the model and the visualization achieved the intended outcome. **o Validation** -- This involves checking whether the key stakeholders agree that the viewpoints in the model are correct representations of the actual and intended situation. **o Obtaining Commitment** -- After reaching an agreement during validation, the key stakeholders must commit that they fully understand the potential impacts of implementing the model. **o Informing** -- This involves the dissemination of information to all the stakeholders. ** Maintaining the model** -- Enterprise architecture model must be kept up to date for it not to lose its value for the stakeholders. **TYPES OF MODELING ACTIONS** ** Introduction** -- Introduce a candidate element in a model. This is the act of placing a fresh term for a concept or relation within a model. ** Refinement** -- Refine an element in a model. Other than introducing new elements, refining can be done by adding specific details to existing elements ** Abandoning** -- Abandon a model element. This involves an explicit decision of eliminating or delete a concept or relation with proper documentation, to avoid the concept of \"lingering around.\" ** Abstraction** -- Abstract from a concept or relation. The concept of abstraction is the opposite of refinement. In this activity, an architect decides whether information, that is available in the model, is to be left out or not. ** Translation** -- Translate an element. This is the process of finding a suitable alternative for an element. ** Documentation** -- Document modeling actions. This action involves the administration and documentation of all or some modeling actions, such as refinement and abstraction. **Gestalt Theory of Human Perception** ** Proximity** -- People have the tendency to relate objects that are near to each other. Therefore, related objects should be placed near to each other. The proximity rule also applies to colors, wherein objects with the same color can indicate relationships between objects. ** Similarity** -- People have the tendency to perceive objects that are similar, belong together as a unit. Also, objects with similar size are often perceived as having the same or equal importance. ** Continuity** -- People have the tendency to perceive a line as continuous establishing directions, based on their perspective. Therefore, lines forming a right angle should not be positioned next to each other in a model, to avoid confusion. ** Closure** -- People have the tendency to perceive incomplete objects as complete and asymmetric objects as symmetric. Symmetry and regularity increase the readability of models and reduces perceived complexity ** Common Fate** -- People have the tendency to perceive different objects that move or function in a similar manner as a unit. **Representation** **Conventions** ** Use of Layouts** -- The layout aspects of a diagram include basic pattern, horizontal and vertical alignment, above/before positioning, symmetry, distance of objects, distribution and density objects and connectors. ** Use of Symbols** -- The shapes of objects in a model usually match the intrinsic properties of the real-life objects. ** Use of Texts** -- Texts suggests proper interpretations, associations, and stimulates thinking. It also speeds up the creation of a proper mental state in modeling, while creating a good starting for the line of reasoning. ** Use of Colors** -- Color is a strong visual signal. It is a visual attribute that is strongly influenced by \"prior knowledge.\" It can also increase the appeal of a diagram, but can also lead to contrary effects, such as confusion and distraction.