SD TF Week 7-9 Yu

Static analysis tools are generally more effective than human inspections at finding subtle logic errors where the code is syntactically correct but functionally wrong.

Testing can successfully prove that a software system is completely free of defects.

A high level of test coverage (e.g., 100% statement coverage) guarantees that the software is reliable.

Security testing is fundamentally different from reliability testing because security testing must account for intelligent, malicious inputs rather than just accidental user errors.

In a safety-critical system, it is acceptable to sacrifice some performance speed to ensure the system fails safely.

Penetration testing should be performed during the requirements phase of the software development lifecycle (SDLC).

Reliability growth models assume that when a defect is discovered and fixed, the overall reliability of the system increases.

Static analysis is limited because it cannot detect errors that depend on the specific timing of interactions between different software components.

An operational profile is not required for stress testing because the goal is to break the system, not simulate normal usage.

Safety assurance focuses on protecting the system from external attacks, while security assurance focuses on preventing the system from harming the environment.

Use of safe programming languages (like Java or Rust) eliminates the need for static analysis regarding memory management errors.

Formal methods are rarely used in general commercial software development due to the high cost and specialized skills required.

If a system has been formally verified, it does not require dynamic testing.

A 'safety case' is a legal defense used after an accident occurs, rather than a technical document created during development.

Automated static analysis is computationally inexpensive and can be run frequently, making it suitable for integration into daily builds.

Developing a software product line is initially more expensive than developing a single standalone system.

Application frameworks are generally easier to learn than simple class libraries because they enforce a standard structure.

The 'Not Invented Here' syndrome is purely a technical problem related to incompatible code interfaces.

Reusing software always increases the overall development speed, even if the team is unfamiliar with the reusable components.

In a 'White-box' framework, the developer customizes behavior by subclassing and overriding methods, requiring access to the framework's source code logic.

COTS solution systems generally offer the highest flexibility because the source code is available for modification.

One of the main arguments for software reuse is the effective use of specialists; a security expert can write a module once, and non-experts can safely use it.

System adaptation (modifying code to fit) is rarely required when using COTS systems.

Software reuse eliminates the need for system testing since the components have already been tested.

Adaptation of a software product line can include both selecting modules to include and adding new, unique modules.

'Inversion of Control' is a defining characteristic that distinguishes libraries from frameworks.

Component-level reuse is generally easier to implement than Concept-level reuse (Design Patterns) because components are executable binaries.

If a COTS product contains a bug, the integrating company usually has the legal right and technical ability to fix the source code immediately.

The 'Reuse Landscape' suggests that as you move from small-scale (objects) to large-scale (systems), the cost of adaptation generally decreases.

A major risk of COTS reuse is that the evolution of the system is dictated by the vendor's upgrade schedule, not the user's business needs.

In Component-Based Software Engineering, the system requirements are typically finalized before any components are selected to ensure the system meets user needs exactly.

A key distinction between a Class and a Component is that a Component is an independent deployment unit, whereas a Class must be compiled into a program.

'Glue code' is used to optimize the performance of two compatible components by bypassing the standard interface.

The 'Requires Interface' of a component allows the system architect to know which external services must be present for the component to operate.

Component-Based Software Engineering eliminates the need for system testing because the individual components are already pre-tested by their vendors.

Parameter incompatibility occurs when the number of parameters in a method call matches, but the data types or semantic meanings do not align.

Development with reuse (building an app) follows the same V-model process as Development for reuse (building a component).

Middleware is optional in CBSE; components can easily communicate directly with each other across different operating systems without it.

Hierarchical composition implies that a new component is created by wrapping one or more existing components, effectively hiding them from the external system.

One of the major risks in CBSE is the lack of control over the evolution and maintenance of third-party components.

In a sequential composition, the components execute concurrently and share a common database state.

Finding suitable components is often the most time-consuming phase of the CBSE process due to poor indexing and vague documentation.

If a component's source code is unavailable, it is impossible to write an adaptor to fix interface incompatibilities.

A 'Provided Interface' defines the services that the component expects the environment to supply.

Trustworthiness is a significant concern in CBSE because the integrator cannot formally verify the internal logic of a black-box component.

Distributed systems generally offer better resource sharing than centralized systems because users can access hardware and software resources located on other computers.

A 'Thin Client' architecture is typically more difficult to manage than a 'Fat Client' architecture because software updates must be installed on every individual user machine.

Scalability in distributed systems can be achieved by adding more resources (horizontal scaling) rather than just upgrading the central hardware (vertical scaling).

Middleware is strictly defined as the hardware components (routers and switches) that physically connect distributed computers.

In a Master-Slave architecture, if the Master node fails, the system can usually continue to function automatically without interruption by electing a new Master immediately (unless specifically designed for such failover).

One major disadvantage of distributed systems is that they are inherently more complex to secure than centralized systems due to the multiple points of access.

Peer-to-Peer (P2P) systems are distinguished by the clear separation of roles where one node always requests services and the other always provides them.

The 'Openness' of a distributed system refers to the extent to which the system can be extended and re-implemented in various ways.

In a multi-tier client-server architecture, the database server handles the presentation logic to ensure data is displayed correctly to the user.

Distributed object architectures allow objects to be distributed across a network, but they must all be written in the same programming language to communicate.

A Denial of Service (DoS) attack is a reliability issue but not strictly a security issue since no data is stolen.

'Transparency' in a distributed system means that the user is explicitly made aware of which server is processing their request to ensure trust.

Three-tier client-server architectures are generally more scalable than two-tier architectures because the application processing load can be distributed separately from the data management.

The primary benefit of a distributed system is that it eliminates the need for network communication, as all data is stored locally.

In a distributed system, failure is often partial; the system may continue to provide some services even if parts of it have crashed.

In a true multi-tenant SaaS architecture, the provider maintains a separate source code branch for each major customer to accommodate their specific feature requests.

One of the primary benefits of SaaS for the software vendor is the ability to continuously deploy bug fixes to all customers instantly.

Data transfer speed (bandwidth) is rarely a limiting factor in SaaS design because modern internet connections are universally fast.

Customization in SaaS is achieved by writing new code modules that are linked to the core application, similar to writing a plugin for a desktop app.

Service Level Agreements (SLAs) typically place the liability for data loss entirely on the user, absolving the provider of all responsibility.

SaaS applications generally require less local processing power on the client machine compared to traditional installed software.

For a SaaS provider, the cost of supporting users typically increases linearly with the number of users, just like in the traditional shrink-wrapped software model.

Security is often cited as a major barrier to SaaS adoption because the organization loses physical control over where its data is stored.

Scalability in the cloud is achieved primarily by 'vertical scaling' (buying a faster CPU for the central server) rather than 'horizontal scaling' (adding more servers).

A 'Stateless' architecture is preferred for SaaS because it allows the system to easily route user requests to any available server in the cluster.

In the SaaS model, the software is treated as a capital asset (CapEx) that depreciates over time on the company's balance sheet.

Configuration of a SaaS application usually involves setting parameters in a database that determine how the generic software code behaves for a specific tenant.

Latency is more critical in transactional SaaS applications (like text editing) than in batch-processing applications (like payroll generation).

Local regulations regarding data privacy (such as GDPR) are irrelevant in Cloud Computing because the internet has no borders.

The 'Application Service Provider' (ASP) model of the late 1990s is identical to modern SaaS, with the only difference being faster internet speeds.