1Static vs. Dynamic Synergy: Many organizations use both static analysis tools and dynamic testing suites. Explain why relying on only one of these approaches leaves a system vulnerable to failure. In your explanation, provide a concrete example of a defect that static analysis would catch but dynamic testing might miss, and vice versa.
Static analysis checks code structure without running. Dynamic checks behavior while running. Example: Static detects unused variables; Dynamic detects runtime crashes (like full database). Both are needed for comprehensive testing.
2Many organizations use both static analysis tools and dynamic testing suites. Explain why relying on only one of these approaches leaves a system vulnerable to failure. Provide an example.
Static analysis checks code structure without running. Dynamic checks behavior while running. Example: Static detects unused variables; Dynamic detects runtime crashes (like full database). Both are needed for comprehensive testing.
3The Security Mindset: Contrast the approach of a Quality Assurance (QA) engineer testing for reliability against a Security Engineer testing for penetration. How do their goals, their view of the "user," and their definition of a "successful test" differ?
Reliability QA views the user as someone trying to get work done and tests for expected conditions/errors. Security tests for a malicious adversary trying to actively break the system under hostile conditions.
4The Buy vs. Build Dilemma: You are the CTO of a logistics company needing a new "Warehouse Management System" (WMS). You have two options: ○ Option A: Buy a COTS WMS from a vendor like SAP. ○ Option B: Build a custom WMS using an Application Framework (e.g., Spring Boot or .NET). Analyze this decision using the benefits and problems of reuse. Discuss specific trade-offs regarding Control, Time-to-Market, Maintenance Costs, and Competitive Advantage.
COTS provides fast time-to-market and high reliability but involves vendor lock-in, low control, and no competitive advantage. Frameworks take longer and cost more initially but offer total control and unique competitive advantage.
5Product Line Engineering: Explain the concept of a Software Product Line (SPL) using the example of a "Smart Phone Operating System" for different tiers of phones (Budget, Mid-range, Flagship). ○ Identify what would constitute the Core Assets (the common base). ○ Identify the Variation Points (what changes between tiers). ○ Explain why this approach is economically superior to maintaining three completely separate codebases.
Core assets: Kernel, basic UI, networking. Variation points: Specific camera drivers, flagship apps. Economics: Fixing a bug in the core once fixes it across all tiers, severely reducing maintenance and testing overhead.
6The Requirements Compromise: In traditional software engineering, requirements drive the implementation. In CBSE, the availability of components often drives the requirements. Explain this inversion. How does a project manager handle a situation where a critical user requirement cannot be met by any available off-the-shelf component? Discuss the trade-off between "modifying the requirement" and "custom building the component."
In CBSE, off-the-shelf components are found first. It is often cheaper and faster to modify system requirements to fit the existing component rather than custom building a component from scratch to perfectly meet an exact requirement.
7Composition Conflicts: You are integrating a "Credit Card Processor" component with an "Order Management" component. Describe three distinct types of Interface Incompatibility that might prevent these two from working together (e.g., Parameter Incompatibility). For each type, describe the specific function of the "Glue Code" needed to resolve it.
1) Parameter Incompatibility: Glue code casts/converts data. 2) Operation Incompleteness: Glue code implements missing logic using available methods. 3) Operation Incompatibility: Glue code maps mismatched method names.
8Client-Server Architecture Trade-offs: Compare and contrast Thin-Client and Fat-Client architectures. ○ Explain the distribution of processing load in each. ○ Discuss a specific scenario where a Thin-Client approach is superior (e.g., a legacy system migration) and a scenario where a Fat-Client approach is necessary (e.g., a graphics-intensive mobile game). ○ Analyze the impact of each on network bandwidth and system management costs.
Thin Client: Server processes, easy management, high bandwidth needed (good for corporate data entry). Fat Client: Client processes, harder managementpdates, lowursty bandwidth needed (good for graphics-intensive games).
9Middleware and Transparency: Explain the role of Middleware in achieving Transparency (Location, Migration, Replication). Why might a developer bypass transparency?
Middleware translates network details so apps don't need to know locations. Location/Migration/Replication hides where/how data moves. Developers bypass it to optimize local speed or ensure data stays in specific legal jurisdictions.
10Configuration vs. Customization: A major challenge in SaaS is meeting the specific needs of different customers without fracturing the code base. ○ Explain the technical difference between Configuration (in SaaS) and Customization (in traditional software). ○ Describe two architectural mechanisms a SaaS architect can use to allow users to "change" the software (e.g., Custom Fields, Workflow Rules) without altering the source code. ○ Why is allowing source-code customization dangerous for a SaaS vendor?
Customization alters source code (forking); configuration changes settings or metadata like fields and workflow rules. Allowing source-code customization breaks the single code base model and prevents unified upgrades for all customers.
11The Multi-Tenancy Trade-off: You are designing a medical records system. You must choose between a Multi-Tenant architecture (all hospitals on one database) or a Single-Tenant/Isolated architecture (one database per hospital). ○ Argue for Multi-Tenancy based on cost, maintenance, and scalability. ○ Argue for Single-Tenancy based on security, data isolation, and performance isolation. ○ Which would you choose for this specific domain, and why?
Multi-Tenant: Lower cost, easier maintenance, scalable. Single-Tenant: Stronger isolation, predictable performance, easier compliance. For medical records, Single-Tenant is preferred due to strict privacy and data protection laws.