Unit 6 - Practice Quiz

ISO 9001 is an international standard that specifies requirements for a quality management system (QMS). It is not specific to software but can be applied to any organization's processes for creating and controlling products or services.

CMMI stands for Capability Maturity Model Integration. It is a process level improvement training and appraisal program administered by the CMMI Institute.

Corrective maintenance involves diagnosing and fixing errors, bugs, and faults in the software that are discovered by users or reported by error logs.

CASE tools are software systems that are intended to provide automated assistance for software engineering tasks, such as design, code generation, testing, and management, throughout the software life cycle.

The main goal of low-code/no-code platforms is to enable rapid delivery of applications by using visual development interfaces and pre-built components, thereby reducing the need for traditional programming.

CBSD is a software development paradigm that focuses on building systems by composing them from existing, well-defined, and independent software components.

These tools are AI-powered 'pair programmers' that analyze the context of the code being written and provide real-time suggestions, from single lines to complete functions, to speed up development.

Six Sigma is a disciplined, data-driven approach and methodology for eliminating defects in any process – from manufacturing to transactional and from product to service.

Adaptive maintenance is concerned with modifying the software to cope with changes in its external environment, such as a new OS, hardware platform, or third-party dependencies.

Cloud-native applications are often built using microservices, which are small, independent services that work together. This architecture is well-suited for the scalability, resilience, and flexibility offered by the cloud.

Level 1 of the CMMI model is called 'Initial'. Processes at this level are usually ad hoc and chaotic. The organization does not provide a stable environment to support processes.

By reusing existing, tested components, organizations can significantly decrease development effort, which leads to lower costs and faster delivery of the final product.

Perfective maintenance involves implementing new or changed user requirements. This type of maintenance enhances the software by adding new functionalities or features.

The Personal Software Process (PSP) is a structured software development process that is designed to help individual software engineers better understand and improve their performance by using a disciplined, data-driven approach.

No-code platforms are designed to empower 'citizen developers'—users with deep business knowledge but little to no coding experience—to build applications using visual drag-and-drop interfaces.

ISO 9001 provides a framework for a quality management system that is generic and adaptable. It can be used by any organization, regardless of its size or field of activity, including software development.

CASE tools that assist with the analysis and design phases of the SDLC, such as those for creating UML diagrams, are known as Upper CASE tools or design/analysis tools.

Containerization (using tools like Docker) bundles an application's code with all the files and libraries it needs to run. This makes the application portable and consistent across different environments, which is crucial for cloud-native deployment.

These advanced AI tools are built on top of Large Language Models (like OpenAI's Codex) which have been trained on vast amounts of public source code, enabling them to understand context and generate relevant code.

One of the most common and difficult challenges in software maintenance is trying to understand and modify code that is poorly documented or has no documentation at all, making the maintainer's job much harder.

CMMI Level 2 (Managed) focuses on managing processes at the project level. The key evolution to Level 3 (Defined) is the establishment of a standardized, documented, and organization-wide software process. This ensures consistency across all projects. Option A describes Level 4 (Quantitatively Managed), Option C describes Level 5 (Optimizing), and Option D describes what is already achieved at Level 2.

Adaptive maintenance involves modifying the software to cope with changes in its external environment. New laws, changes in hardware, or operating system updates fall into this category. Corrective maintenance is for fixing bugs, perfective maintenance is for adding features or improving performance, and preventive maintenance involves refactoring to improve future maintainability.

A primary challenge in CBSD is 'architectural mismatch,' where components are built with different underlying assumptions about the system's architecture, data formats, control flow, or communication protocols. Integrating these 'black boxes' can be very difficult if their interfaces and implicit assumptions are incompatible.

Cloud-native applications are designed to leverage cloud benefits. The microservices architecture, where the application is broken into small, independent, containerized services, is a cornerstone of this approach. It allows for independent scaling, deployment (CI/CD), and resilience (fault isolation), which directly addresses the stated goals.

Traditional autocomplete suggests syntax-aware completions based on the existing codebase (e.g., variable names, function signatures). AI assistants like Copilot use large language models trained on vast amounts of code to synthesize entirely new code blocks, algorithms, and even documentation based on the broader context and natural language prompts.

The primary trade-off of low-code/no-code platforms is sacrificing fine-grained control for speed and simplicity. While excellent for standard business applications, they can be restrictive when dealing with unique business logic, complex integrations, or specific performance/scalability requirements, a phenomenon often called 'hitting the platform's wall'.

ISO 9001 is a process-oriented standard. It does not certify the quality of a specific product but rather certifies that the organization has a robust and consistent Quality Management System (QMS) in place. It's about ensuring processes are defined, controlled, and improved, with the expectation that good processes lead to good products.

CASE tools are often categorized based on which phase of the SDLC they support. Upper CASE tools are used in the early phases of development, such as requirements analysis and design. Tools for creating DFDs, ERDs, and managing specifications fall squarely into this category. Lower CASE tools focus on later phases like coding, debugging, and testing.

A core principle of PSP is using personal data for process improvement. The first step after identifying a pattern of defects is to analyze the collected data to understand why the errors are occurring (root cause analysis) and then modify the personal process (e.g., design checklists, coding standards) to prevent them in the future.

A defining challenge of maintaining legacy systems is the loss of domain and system knowledge. The original developers are often gone, documentation is typically sparse or outdated, and crucial business logic is often only discoverable by analyzing the source code itself. This makes any change risky, time-consuming, and difficult.

The Continuous Representation allows an organization to select specific process areas (like Verification or Validation) and improve their capability level (from 0 to 5) independently of other areas. This provides flexibility for targeted improvements. The Staged Representation, in contrast, groups process areas into predefined maturity levels, requiring an organization to master a whole set of processes before moving to the next level.

A successful reuse program isn't just about using components; it's about managing them. The foundational step is to create a robust process for the 'supply side' of reuse: identifying what is worth reusing, documenting and certifying its quality, and making it available in a trusted, searchable repository or library. Without this, any reuse effort will be ad-hoc and ineffective.

The 'Measure' phase of DMAIC is focused on collecting data to establish a baseline and understand the current state of the process. In this scenario, the team needs to gather concrete metrics about the defects to quantify the problem before they can analyze its root cause in the 'Analyze' phase. Defining the problem (Option C) occurs in 'Define', and brainstorming solutions (Option A) happens in 'Improve'.

While containers (e.g., Docker) package an application and its dependencies, an orchestrator (e.g., Kubernetes) is needed to manage these containers at scale. It handles critical operational tasks like scheduling containers onto nodes, service discovery, load balancing, self-healing (restarting failed containers), and automated rollouts/rollbacks, which are essential for running resilient applications in the cloud.

AI code generators are trained on vast public codebases, which inevitably include code with bugs, security flaws, or non-optimal patterns. The generated code is a suggestion, not a guaranteed-correct solution. Relying on it without careful human review, static analysis, and robust testing can lead to the introduction of quality and security issues. The developer remains accountable for the code they commit.

The defining characteristic of I-CASE tools is the central repository. This repository stores all information related to the project in a structured way. It ensures that a change in one artifact (e.g., a data element in a design model) can be automatically reflected or flagged in related artifacts (e.g., source code, requirements documents), thus maintaining consistency and traceability throughout the entire SDLC.

No-code platforms are designed for non-technical users (like the business analyst) to solve problems using purely visual, drag-and-drop interfaces without writing any code. Low-code platforms are aimed at developers to accelerate their work; they provide visual development tools but also allow them to 'drop down' into code to handle custom logic, complex integrations (like calling a custom API), and extend the platform's native capabilities.

In many software engineering cultures, working on new, 'greenfield' projects is seen as more glamorous and career-advancing than maintaining existing systems. This perception can make it difficult to staff maintenance teams with highly motivated and skilled engineers, as the work can be viewed as 'second-class' citizenship, leading to morale and retention issues.

The key distinction is their scope and origin. CMMI was developed by the Software Engineering Institute (SEI) specifically to be a model for improving software and systems development processes, and it is very detailed about what practices to implement. ISO 9001 is a general-purpose standard for a Quality Management System that can be applied to any organization, from a software company to a manufacturing plant or a hospital, and is less prescriptive about specific practices.

The essence of a reusable component is that it's a self-contained 'black box' that can be plugged into different systems. This requires it to be loosely coupled and have a clear, stable interface (its 'contract'). The component should not make assumptions about the larger system it will be part of (i.e., be context-independent) to be truly and easily reusable. High coupling (Option B) is the antithesis of reusability.

CMMI Level 5 (Optimizing) is distinguished from Level 4 (Quantitatively Managed) by its focus on continuous process improvement and defect prevention, not just control. While the process is statistically in control at Level 4, Level 5 requires understanding why the mean defect rate is what it is and proactively working to lower it. Causal Analysis and Resolution (CAR) is a key process area for this. Tightening limits without understanding the cause is counterproductive. Replacing the team or adding reviews are reactive solutions, not a systemic process improvement as mandated by Level 5.

This question tests the nuanced understanding of CBSD composition challenges. The change in C1 is a straightforward Interface Incompatibility, which is usually easy to detect and fix. The more insidious and 'harder' problem is the Property Mismatch from C2. The component still 'works' according to its API contract, but its changed non-functional properties (like performance, memory usage, or security posture) can negatively affect the entire system's behavior in ways that are difficult to predict or test for. This is a classic example of a problematic emergent property in a component-based system.

Lehman's Second Law, the Law of Increasing Complexity, states that as an E-type system (a system that solves a problem in a real-world domain) evolves, its complexity increases unless work is done to maintain or reduce it. This directly addresses the concept of entropy and structural decay due to continuous changes without refactoring. The Law of Continuing Change simply states that systems must change to remain useful. The Law of Conservation of Organizational Stability deals with the rate of change, and Self Regulation describes the feedback mechanisms, but Increasing Complexity is the core law describing the inevitable decay without proactive maintenance (i.e., perfective maintenance like refactoring).

The CAP theorem states that a distributed system can only provide two of the following three guarantees: Consistency (C), Availability (A), and Partition Tolerance (P). In a real-world distributed system, Partition Tolerance is a must. Therefore, the choice is between C and A. For a financial system requiring strong consistency (a CP system), when a partition occurs, it must sacrifice availability to ensure that no inconsistent data is written. This means the partitioned nodes that cannot communicate with the majority quorum will refuse to accept writes, resulting in an error or timeout for the user. Accepting the transaction for later reconciliation would be an AP (Availability + Partition Tolerance) system prioritizing availability over immediate consistency.

This question assesses a deep understanding of process data analysis in PSP. A high Defect Removal Yield (the percentage of defects found before the first compile) is desirable, but it's only meaningful relative to the total number of defects injected. The fact that many defects are found later in integration testing points to a blind spot in the developer's personal review process. It's not that the process is ineffective, but rather that it is ineffective for a specific class of errors—those that only become apparent when the code interacts with other system components. This is a more complex and realistic failure mode of PSP than simply gaming the metrics or having a bad standard.

This is the core challenge with LLM-based code generators. They are incredibly powerful pattern-matching systems, not sentient reasoners. The model doesn't 'understand' security or data sensitivity. It generates code that is statistically likely based on the vast corpus of public code it was trained on, which unfortunately includes many examples of insecure practices. The vulnerability is a probabilistic artifact of the training data, not a deterministic bug in the AI. While poor unit tests and developer skill are contributing factors, the fundamental origin of the insecure code is the nature of the generative model itself.

This is a classic problem with large, prescriptive I-CASE tools, often called 'methodology in a box'. These tools are built around a specific, often rigid, software development process (like a strict waterfall or structured analysis model). If an organization has an informal, iterative, or agile culture, forcing them to conform to the tool's rigid process can create massive overhead, stifle creativity, and ultimately reduce productivity. This process mismatch is a more profound and common cause of failure for I-CASE adoption than technical issues like code quality or performance, which are often solvable.

This question targets the architectural friction at the boundary of low-code and pro-code. Low-code platforms manage state, transactions, and data consistency automatically within their declarative model. When you 'escape' to external imperative code, that code operates outside this managed environment. The most difficult challenge is ensuring that operations performed by the custom code are transactionally safe and that its state changes are correctly synchronized back into the platform's state model without causing race conditions or data corruption. The other options are valid challenges, but this state/transactional management issue is the most fundamental architectural hurdle.

This is a sophisticated and common maintenance problem in modern development workflows. It's not a simple 'ripple effect' where one change breaks another functionally. Instead, it's a tooling and process failure where the merge algorithm cannot understand the intent of the two changes. The merge tool sees conflicting lines and the developer might resolve it by choosing the version from their feature branch, unknowingly undoing the critical fix. This leads to a regression—the reintroduction of a previously fixed bug. 'Semantic Decay' refers to code losing its meaning over time, which is related but less specific. 'Code Obfuscation' is about code being hard to read.

This question requires synthesizing knowledge of both standards. While the issue is also a CMMI failure, the question asks for the ISO 9001 perspective. ISO 9001 is fundamentally built on the PDCA cycle. The organizational standard process represents the 'Plan'. By not following it, the 'Do' phase is non-conformant. This leads to an inability to 'Check' the process effectiveness meaningfully and 'Act' on improvements systemically. This breakdown of the core quality management cycle is the most fundamental ISO 9001 non-conformance. 'Customer Focus' is a principle, but the PDCA breakdown is a more direct and actionable audit finding related to the Quality Management System's operation.

This is a key architectural distinction. When you use a library, you are in control. Your code calls functions/methods in the library to perform a task. When you use a framework, the framework is in control. It defines the application's overall structure and lifecycle, and it calls your custom code at specific points (e.g., via callbacks, event handlers, or dependency injection). This principle is known as Inversion of Control or the 'Hollywood Principle' ('Don't call us, we'll call you'). The other options are generalizations that are not always true: frameworks can be small, libraries can be dynamic or domain-specific.

Factor IX, Disposability, emphasizes that processes should be stateless and share-nothing. This allows them to be started or stopped at a moment's notice, which is essential for rapid elastic scaling, robust deployments, and fast recovery from crashes. A fast startup time minimizes the delay in scaling up or recovering. A graceful shutdown (e.g., by handling SIGTERM to finish current work and release resources) prevents data corruption and ensures a clean state. While health checks (related to robustness) and externalized config (Factor III) are important 12-Factor principles, fast startup and graceful shutdown are the direct implementation of disposability.

This question tests the practical meaning of sigma levels. A common misconception is to confuse different sigma values. A 6-sigma process corresponds to 3.4 DPMO. A 2-sigma process is very poor, corresponding to a 69.1% yield or 308,537 DPMO. This level of performance is far from capable for most business applications. A Cpk of 1.33 is generally considered the minimum for a capable process, which corresponds to roughly a 4-sigma level. A 2-sigma process is significantly outside customer specification limits.

The key concept of a CASE repository (or encyclopedia) is its role as a rich, integrated database of all project information, not just source code files. Unlike Git, which primarily tracks changes to text files, a CASE repository understands the semantics of the artifacts. It knows that a specific UML class in a design model is implemented by a particular source code file and is tested by a set of test cases. This enables powerful capabilities like impact analysis, traceability, and ensuring consistency across the entire lifecycle, which is far beyond the scope of a version control system.

Before any maintenance activity can begin on a poorly documented legacy system, the maintainers must first understand how it works. This process, known as program comprehension, is the most critical and time-consuming initial step. They need to figure out where and how personal data is stored, processed, and transmitted. While Testability, Maintainability Index, and Scalability are all valid and significant challenges, they are secondary to the fundamental problem of not understanding the system. You cannot test, measure, or scale a system whose logic and structure you do not comprehend.

The Fragile Base Class problem is a classic and severe issue with deep inheritance (a form of white-box reuse). Because subclasses are tightly coupled to the implementation details of their parents, a seemingly safe modification in a base class can break the assumptions or invariants of its descendants in subtle ways. This makes the entire hierarchy rigid and difficult to maintain. Black-box reuse (composition) avoids this by depending only on stable interfaces, not on implementation, promoting the 'composition over inheritance' principle.

This is a strategic, governance-level problem. When individual business units build their own applications without central oversight (a form of Shadow IT), they often solve local problems effectively. However, at the enterprise level, this leads to a fragmented technology landscape. Data becomes trapped in platform-specific silos, business rules are duplicated and become inconsistent, and there is no holistic view of enterprise data or processes. This fragmentation undermines data integrity, security, and the ability to perform enterprise-wide analytics or process automation. While cost, performance, and lock-in are real issues, the architectural and data fragmentation is the most profound long-term governance challenge.

This question gets to the core of the underlying technology. A traditional linter or static analyzer has a human-written rule set (e.g., 'a for loop variable should not be modified inside the loop'). Its analysis is deterministic and explainable. An AI tool like Copilot doesn't have explicit rules. It has learned the statistical likelihood of code patterns from its training data. It might flag code as 'unusual' or suggest a 'better' alternative because the existing code has a low probability compared to common patterns it has seen. This probabilistic nature is the key differentiator; it can find novel or stylistic issues but can also have false positives or 'hallucinate' problems because it lacks a formal, rule-based understanding of the code's semantics.

This is a critical architectural trade-off in distributed systems. 2PC provides strong consistency (ACID guarantees) but at a very high cost. It requires a central transaction coordinator and forces all participating services to lock their resources and wait for the coordinator's signal to commit or abort. This synchronous blocking is antithetical to the goals of high availability and independent scalability in a microservices architecture. The Saga pattern sacrifices strong consistency (offering eventual consistency through compensations) to gain availability and loose coupling, which is a much better fit for the cloud-native/microservices paradigm.

This is a high-level, analytical comparison. ISO 9001 is a generic quality management standard applicable to any industry. It defines the requirements for a Quality Management System (e.g., 'you must have a process for document control') but does not prescribe the specifics of that process. CMMI, on the other hand, is a capability and maturity model specifically for development. It provides a much more detailed and prescriptive framework of specific goals and practices (e.g., 'for Requirements Management, you must maintain bidirectional traceability from requirements to work products'). In essence, ISO 9001 sets the destination, while CMMI provides a detailed roadmap for getting there in a development context.