Ruankao System Analyst (Senior) cheat sheet

Amdahl's law: speedup = 1 / ((1-f) + f/s), where f is the fraction enhanced and s the enhancement factor; the serial fraction caps the gain.

CPU performance: execution time = instruction count × CPI × clock cycle time; clock rate = 1 / cycle time.

CISC favors few complex multi-cycle instructions and small code size; RISC favors fixed-length simple instructions, deep pipelines, and load/store architecture.

Pipeline speedup is limited by the slowest stage; hazards are structural (resource conflict), data (RAW/WAR/WAW), and control (branch); forwarding resolves many RAW cases, stalling the rest.

Cache hierarchy: L1/L2/L3 trade latency for capacity; write-through keeps memory coherent at higher traffic, write-back defers writes and needs a dirty bit.

Locality drives performance: temporal locality (reuse soon) and spatial locality (nearby addresses) justify caches and prefetching.

RAID levels: RAID 0 striping (no redundancy), RAID 1 mirroring, RAID 5 block striping with distributed parity (tolerates 1 disk failure), RAID 6 dual parity (tolerates 2), RAID 10 mirrored stripes.

Little's law: L = λ × W (items in system = arrival rate × time in system); applies to queues, thread pools, and connection pools.

Reliability of independent components in series: R = ΠRi; parallel redundancy: R = 1 − Π(1 − Ri); MTBF = 1 / failure rate.

Waterfall suits stable, well-understood requirements with contractual stage gates; iterative/incremental and spiral suit high uncertainty and risk-driven projects.

Scrum roles: Product Owner (backlog value), Scrum Master (process facilitation), Developers; events: Sprint Planning, Daily Scrum, Sprint Review, Retrospective.

Kanban limits work-in-progress and visualizes flow; Little's law predicts cycle time from WIP and throughput.

COCOMO II estimates effort as a function of size (KSLOC or function points) adjusted by scale and effort multipliers; it is an estimating model, not a schedule guarantee.

Function point analysis counts External Inputs, External Outputs, External Inquiries, Internal Logical Files, and External Interface Files, weighted by complexity.

Coupling should be low (data coupling preferred, content coupling worst); cohesion should be high (functional best, coincidental worst).

Test levels: unit, integration, system, acceptance; verification asks 'built right', validation asks 'right product'; black-box uses equivalence partitioning and boundary value analysis.

Continuous integration requires automated build, automated tests, and a single shared mainline with short-lived branches; trunk-based development minimizes merge risk.

Technical debt is a metaphor for deferred rework; it accrues interest as maintenance cost and must be tracked, not merely incurred.

Requirement types: functional (behavior), non-functional (quality attributes such as performance, security, usability), and constraints (technology, regulation, budget).

Requirements activities in order: elicitation, analysis and negotiation, specification, validation, and management (traceability, change control).

A use case describes actor-goal interaction with main success scenario plus alternate and exception flows; it is not a screen design.

MoSCoW prioritization: Must have, Should have, Could have, Won't have (this time); Must items define the minimum usable release.

A good requirement is unambiguous, verifiable, necessary, feasible, and traceable; avoid vague words such as 'fast', 'user-friendly', 'robust' unless quantified.

Data flow diagram levels: context diagram (one process), level 0, level 1; balancing requires parent and child flows to match; a data dictionary defines each flow and store.

Entity-relationship modeling: entities, attributes, relationships with cardinality (1:1, 1:N, M:N); M:N relationships resolve into associative entities in the relational model.

Prototyping (throwaway vs evolutionary) reduces elicitation risk when users cannot articulate needs; it is not a substitute for documented acceptance criteria.

Traceability matrix links requirement → design → code → test case, enabling impact analysis when a requirement changes.

Architecture quality attributes: performance, availability, modifiability, security, testability, usability; tactics exist per attribute (e.g., caching for performance, redundancy for availability).

Layered architecture restricts dependencies to adjacent layers; the dependency inversion principle says depend on abstractions, not concretions.

Microservices trade operational complexity and distributed data consistency for independent deployability and team autonomy; a monolith is often the correct first choice.

CAP theorem: under a network partition a distributed store must choose consistency or availability; PACELC adds latency vs consistency trade-offs when no partition exists.

Event-driven architecture decouples producers and consumers via a broker; at-least-once delivery requires idempotent consumers.

Design patterns by category: creational (Factory, Builder, Singleton), structural (Adapter, Decorator, Facade, Proxy), behavioral (Observer, Strategy, Template Method, Command).

Availability in nines: 99.9% ≈ 8.77 hours downtime per year; 99.99% ≈ 52.6 minutes per year; 99.999% ≈ 5.26 minutes per year.

API design: REST uses resources and HTTP verbs with statelessness; idempotent methods are GET, PUT, DELETE (not POST); version APIs to allow evolution.

Separation of concerns and information hiding (Parnas) localize change; high cohesion plus low coupling remains the core design heuristic.

Normalization: 1NF atomic attributes; 2NF no partial dependency on part of a composite key; 3NF no transitive dependency; BCNF every determinant is a candidate key.

ACID: Atomicity, Consistency, Isolation, Durability; BASE (Basically Available, Soft state, Eventually consistent) is the common distributed alternative.

Isolation levels and anomalies: Read Uncommitted (dirty read), Read Committed (non-repeatable read), Repeatable Read (phantom possible in some engines), Serializable (none).

Index B+ tree supports range scans and equality with O(log n) height; a covering index answers a query from the index alone; leading-column rule governs composite indexes.

SQL join semantics: INNER (matching rows), LEFT/RIGHT (preserve one side), FULL (preserve both), CROSS (Cartesian); NULL comparisons use IS NULL, and NULL in aggregates is ignored by AVG/COUNT(col).

Transaction log (WAL) enables rollback and crash recovery; checkpointing bounds recovery time; two-phase commit coordinates distributed transactions but blocks on coordinator failure.

Sharding partitions data horizontally by key; replication copies data for availability and read scaling; sharding complicates cross-shard joins and transactions.

Data warehouse modeling: star schema (fact table plus denormalized dimensions) vs snowflake schema (normalized dimensions); OLAP supports slicing, dicing, drill-down, and roll-up.

CAP-aware store selection: strong consistency for financial ledgers; eventual consistency acceptable for social feeds and catalog reads.

OSI seven layers: Physical, Data Link, Network, Transport, Session, Presentation, Application; TCP/IP maps to Network Interface, Internet, Transport, Application.

TCP is connection-oriented with a three-way handshake (SYN, SYN-ACK, ACK) and reliable ordered delivery; UDP is connectionless, best-effort, lower overhead.

TLS provides confidentiality, integrity, and server authentication via certificates; it does not by itself guarantee application-level authorization.

Symmetric ciphers (AES) are fast for bulk data; asymmetric ciphers (RSA, ECC) handle key exchange and signatures; hashes (SHA-256) provide integrity, and HMAC adds a key.

CIA triad: Confidentiality, Integrity, Availability; authentication proves identity, authorization grants permissions, non-repudiation prevents denial of an action.

Defense in depth layers controls: network segmentation, least-privilege IAM, encryption at rest and in transit, logging and monitoring, patching.

OWASP Top 10 categories include injection, broken access control, cryptographic failures, insecure design, and security misconfiguration; input validation prevents injection but authorization checks must be server-side.

Risk = likelihood × impact; controls are preventive, detective, or corrective; residual risk remains after controls are applied and must be accepted by the owner.

Common ports: 22 SSH, 53 DNS, 80 HTTP, 443 HTTPS, 3306 MySQL, 6379 Redis; DNS resolves names to addresses and uses UDP 53 for typical queries.

Critical path method: the critical path is the longest path through the network; its total float is zero, so any delay there delays the project end date.

Earned value: PV (planned value), EV (earned value), AC (actual cost); CV = EV − AC, SV = EV − PV, CPI = EV / AC, SPI = EV / PV; CPI < 1 means over budget.

Estimate at completion: EAC = BAC / CPI when current cost performance persists; EAC = AC + ETC when a fresh bottom-up estimate is used.

Risk response strategies: avoid, mitigate, transfer, accept (negative risks); exploit, enhance, share, accept (positive risks).

Quality assurance is process-oriented and preventive; quality control is product-oriented and detective (inspection, testing).

Defect cost grows through the lifecycle: a defect found in requirements costs far less to fix than the same defect found in production.

Coverage metrics: statement, branch/decision, and path coverage; 100% statement coverage does not imply 100% branch coverage.

Change control: a change request is assessed for impact on scope, schedule, cost, and quality, then approved or rejected by the change board before implementation.

Configuration management identifies, controls, and audits work products; baselines are the approved reference points for change.

Cloud service models: IaaS (infrastructure), PaaS (runtime platform), SaaS (application); deployment models are public, private, hybrid, and community.

Cloud elasticity scales automatically with demand; scalability is the capacity to scale, elasticity is the automatic realization of it.

Containers share the host kernel and package application plus dependencies; virtual machines each run a full guest OS, giving stronger isolation at higher overhead.

DevOps culture: shared ownership, automation of build/test/deploy, observability (logs, metrics, traces), and blameless postmortems.

Big data characteristics: volume, velocity, variety (plus veracity and value); batch processing (MapReduce) differs from stream processing (event windows).

Machine learning lifecycle: data collection, feature engineering, training, evaluation, deployment, and monitoring for drift; model accuracy degrades as data distributions shift.

Enterprise integration patterns: message queue, publish/subscribe, request/reply, and enterprise service bus; idempotency and dead-letter queues handle failure.

Blockchain provides an append-only distributed ledger with consensus; it suits multi-party trust scenarios but has throughput and governance costs.

Edge computing moves processing near data sources to reduce latency and bandwidth; it complements, not replaces, centralized cloud processing.

Use active voice and present tense for procedures: 'Run the script' rather than 'The script should be run by the operator'.

One idea per sentence; keep sentences under about 25 words and define an abbreviation at first use, e.g., 'service level agreement (SLA)'.

Requirements phrasing: use 'shall' for mandatory, 'should' for recommended, 'may' for optional; avoid 'will' which blurs obligation.

Structure technical documents as purpose, scope, audience, assumptions, body, and references; put the conclusion or recommendation early for decision-makers.

Use consistent terminology: pick one term per concept (e.g., 'customer' not alternating with 'client') and keep it in a glossary.

Tables and numbered lists suit parallel data and steps; prose suits reasoning and trade-offs; do not bury a decision inside a paragraph.

Avoid nominalizations and filler: 'decide' beats 'make a decision'; 'because' beats 'due to the fact that'.

For an English abstract, state problem, method, result, and conclusion in that order within about 150-250 words.

Use active voice and present tense for procedures: 'Run the script' rather than 'The script should be run by the operator'.

One idea per sentence; keep sentences under about 25 words and define an abbreviation at first use, e.g., 'service level agreement (SLA)'.

Requirements phrasing: use 'shall' for mandatory, 'should' for recommended, 'may' for optional; avoid 'will' which blurs obligation.

Structure technical documents as purpose, scope, audience, assumptions, body, and references; put the conclusion or recommendation early for decision-makers.

Use consistent terminology: pick one term per concept (e.g., 'customer' not alternating with 'client') and keep it in a glossary.

Tables and numbered lists suit parallel data and steps; prose suits reasoning and trade-offs; do not bury a decision inside a paragraph.

Avoid nominalizations and filler: 'decide' beats 'make a decision'; 'because' beats 'due to the fact that'.

For an English abstract, state problem, method, result, and conclusion in that order within about 150-250 words.