Software is not built in one shot. It goes through a lifecycle: a series of phases from the first idea to the final retirement of the product. This is called the SDLC (Software Development Life Cycle).

The standard SDLC phases are:

1. Requirements analysis — find out WHAT the customer needs.
2. Design — plan HOW the software will be built (architecture, modules, data).
3. Implementation (coding) — write the actual code.
4. Testing — check that the software works and matches the requirements.
5. Deployment — deliver the software to the users.
6. Maintenance — fix bugs and add changes after release. This is often the longest and most costly phase.

A process model is a plan that says in which order and in what style we do these phases. Different projects need different models.

The Waterfall model is the oldest and simplest model. Phases run one after another, like water falling down steps. You finish one phase completely, get it approved, then move to the next. Going back is very hard.

Pros:

• Very simple to understand and manage.
• Each phase has a clear output (document, code, test report).
• Works well when requirements are fixed and well understood.

Cons:

• Working software appears only at the very end.
• Very hard to handle changing requirements.
• A mistake found late (in testing) is very costly to fix.
• Customer sees the product only at the end — big risk of "this is not what I wanted".

The V-model is Waterfall bent into a V shape. Each development phase on the left side has a matching testing phase on the right side. Test plans are written EARLY, while the matching left-side phase is running.

• Requirements ↔ Acceptance testing
• System design ↔ System testing
• Module (detailed) design ↔ Integration testing
• Coding ↔ Unit testing

Good for safety-critical projects (medical, avionics) where testing must be planned very carefully. Same weakness as Waterfall: rigid, bad with changes.

In the Incremental model, the product is built and delivered in pieces called increments. The first increment is usually the core product (most important features). Each new increment adds more features on top.

Customer gets working software early, and feedback from one increment improves the next. Needs good planning so the pieces fit together.

The Spiral model (by Barry Boehm) combines iteration with risk analysis. The project moves in loops (spirals). Each loop has 4 quadrants:

1. Determine objectives — set goals and constraints for this loop.
2. Risk analysis — find risks, analyze them, build prototypes to reduce them.
3. Develop and test — build the next version of the product.
4. Plan next iteration — review with customer and plan the next loop.

Its key word is risk-driven: before every loop, the biggest risks are attacked first. Good for large, expensive, high-risk projects. Downside: costly, needs risk experts, too heavy for small projects.

When the customer is not sure what they want, we build a quick, rough prototype (often just the UI, with fake logic). The customer plays with it and gives feedback. We refine or rebuild until requirements become clear, then build the real system.

• Throwaway prototype: the prototype is discarded; only the learned requirements are kept.
• Evolutionary prototype: the prototype slowly grows into the final system.

Risk: the customer may think the rough prototype is the real product and expect delivery too soon.

Agile is a family of methods based on the Agile Manifesto (2001). Core ideas: deliver working software in short cycles, welcome changing requirements, talk to the customer all the time, prefer people and working software over heavy documents and rigid plans.

Scrum is the most popular Agile framework. Work happens in fixed short cycles called sprints (usually 2–4 weeks). Each sprint ends with a potentially shippable product increment.

Scrum roles (only 3):

• Product Owner — owns the product backlog, decides WHAT to build and in what priority.
• Scrum Master — coach and protector of the process; removes blockers. NOT a boss/manager.
• Development Team — 3–9 people who actually build the product; self-organizing.

Scrum artifacts: Product Backlog (all wanted features, prioritized), Sprint Backlog (items chosen for this sprint), Increment (working product at sprint end).

Scrum events: Sprint Planning, Daily Scrum (15-minute stand-up), Sprint Review (demo to stakeholders), Sprint Retrospective (how can WE work better).

XP (Extreme Programming) is another Agile method focused on engineering practices: pair programming, test-driven development (write tests first), continuous integration, small frequent releases, refactoring.

Many software projects finish late, cost too much, or get cancelled. In the exam, you should be able to LIST the main reasons and say one line about each:

• Unclear or changing requirements — the team never really knew what to build, or the target kept moving.
• Poor estimation of time and cost — the schedule and budget were guesses that were too optimistic.
• Lack of user involvement — users were not asked during development, so the final product did not fit their real work.
• Poor communication — team members, managers, and the customer did not share the same understanding.
• Inadequate testing — bugs reached the users because testing was rushed or skipped.
• Scope creep — new features kept getting added without adding time or people.
• Weak project management — no clear plan, no progress tracking, wrong people on wrong tasks.
• Technical debt — quick-and-dirty code piled up until every new change became slow and risky.
• No risk management — nobody asked "what can go wrong?" early, so problems arrived as surprises.

Maintenance is everything done to the software AFTER delivery. It is usually the longest and most expensive part of the lifecycle (often 60% or more of total cost). There are four types of maintenance:

• Corrective — fix bugs that users find after release. (Reactive: something is broken.)
• Adaptive — change the software so it keeps working in a NEW environment: new OS, new hardware, new database, new law or tax rule.
• Perfective — improve the software for users: add requested features, make it faster, make reports nicer.
• Preventive — clean up NOW to avoid problems LATER: restructure messy code, update documentation, remove dead code.

The SMLC (Software Maintenance Life Cycle) has six phases, in order:

1. Identification — receive change requests and identify what kind of modification is needed.
2. Analysis — study the feasibility, impact, and cost of the change.
3. Design — design the modification using the current system's documents and structure.
4. Implementation — actually code the change into the system.
5. System testing — test the changed module, its integration, and run regression tests so old features still work.
6. Delivery — release the updated software to users (with updated manuals/training if needed).

Requirements engineering is the process of finding out, writing down, checking, and managing what the software must do. Most failed projects fail here — the team built the wrong thing.

Main activities: elicitation (gathering), analysis (making sense, removing conflicts), specification (writing the SRS), validation (checking the requirements themselves), and management (handling changes later).

Functional requirements (FR) say WHAT the system must do — its features and behaviors. Non-functional requirements (NFR) say HOW WELL it must do it — quality attributes like speed, security, usability. NFRs are often called quality requirements or "-ilities".

Elicitation = collecting requirements from stakeholders. Common techniques:

• Interviews — one-to-one talks with users/managers. Deep but slow.
• Questionnaires/surveys — many people, cheap, but shallow answers.
• Observation (ethnography) — watch users do their real work; catches things people forget to say.
• Workshops / brainstorming (JAD sessions) — all stakeholders in one room, fast agreement.
• Prototyping — show a mock version, users react to something concrete.
• Document analysis — read existing forms, reports, and old system manuals.
• Use cases / user stories — describe requirements as user–system interactions.

The SRS is the official document that records all requirements. It is a contract between customer and developers. A good SRS is: correct, complete, consistent, unambiguous, verifiable, traceable, and modifiable.

Typical structure (based on IEEE 830):

1. Introduction — purpose, scope, definitions, references.
2. Overall description — product perspective, user classes, operating environment, constraints, assumptions.
3. Specific requirements — all functional requirements (numbered, e.g., FR-1, FR-2), external interfaces, non-functional requirements (performance, security, etc.).
4. Appendices and index.

Validation checks the requirements THEMSELVES before building anything. We ask: are they complete? consistent (no two requirements conflict)? realistic (can we build this with our budget/technology)? verifiable (can we test it later)?

Techniques: requirements reviews (a team reads the SRS line by line), prototyping (show users), and test-case generation (if you cannot write a test for a requirement, the requirement is too vague — e.g., "the system shall be fast" is not verifiable).

A use case describes one goal-oriented interaction between an actor (a user or external system) and the system. It has a main success flow and alternate/exception flows.

UML (Unified Modeling Language) is a standard set of diagrams for drawing software designs. Why model? Because a picture lets the whole team share one understanding, find design mistakes BEFORE coding, and document the system for the future. UML diagrams split into two families: structural (class, component, deployment) and behavioral (use case, sequence, activity, state).

A class diagram shows classes and the relationships between them. Each class is a box with 3 parts: name, attributes, methods. Visibility marks: + public, - private, # protected, ~ package.

Attribute format: - balance : double. Method format: + deposit(amount : double) : void.

A use case diagram gives a bird's-eye view: stick-figure actors outside a system boundary box, oval use cases inside, lines connecting actors to their use cases. Two special arrows: «include» (one use case ALWAYS uses another, e.g., "Withdraw Cash" includes "Verify PIN") and «extend» (optional extra behavior, e.g., "Print Receipt" extends "Withdraw Cash").

A sequence diagram shows objects as vertical lifelines and messages as horizontal arrows, ordered top to bottom by TIME. Solid arrow = call, dashed arrow = return. The thin rectangles on lifelines (activation bars) show when an object is busy.

• Activity diagram: a flowchart of actions — rounded boxes for activities, diamond for decisions, bars for parallel (fork/join), filled circle for start, bullseye for end. Good for showing a business process or an algorithm's flow.
• State diagram (state machine): shows the STATES of ONE object and the events that move it between states. Example: an Order goes Created → Paid → Shipped → Delivered, with events like "payment received". Good for objects with clear life stages (order, connection, traffic light).

Quick memory: activity diagram = flow of a process; state diagram = life of an object; sequence diagram = messages over time between objects.

BUET asked students to draw a class diagram for an online shopping site with classes like Customer, Order, Product, ShoppingCart, and Payment. Here is a clean model answer. First learn the relationships, then the picture:

The same BUET question also asked for a state diagram of the shopping workflow. Model ONE object — the Order — and show its states and the events that move it:

Testing means running the software with the goal of FINDING defects. Testing can show that bugs exist — it can never prove there are zero bugs (Dijkstra's famous point).

1. Unit testing — test one function/class alone. Done by developers. Example: test that withdraw() rejects a negative amount.
2. Integration testing — test that modules work TOGETHER (interfaces between them). Approaches: big bang (join everything at once), top-down (use stubs for missing lower modules), bottom-up (use drivers for missing upper modules).
3. System testing — test the whole finished system against the SRS, in an environment like production.
4. Acceptance testing — the CUSTOMER tests whether the system meets their needs. Includes alpha testing (at the developer's site, controlled) and beta testing (at real users' sites, real environment).

Equivalence partitioning (EP): split the input space into groups (partitions) where every value in a group should behave the SAME. Test just one value per group — no need to test all.

Boundary value analysis (BVA): bugs love edges. Test the values AT and NEXT TO each boundary: for a range [min, max], test min−1, min, min+1, max−1, max, max+1 (a lighter version uses min, max and one middle value).

Coverage measures how much of the code your tests actually exercised.

• Statement coverage: every line runs at least once.
• Branch (decision) coverage: every decision (if/while) takes BOTH the true and false way at least once. Stronger than statement coverage.
• Path coverage: every possible route through the code runs. Strongest, but paths explode fast (2 independent ifs → 4 paths).

• Verification: "Are we building the product RIGHT?" — checking the work against the design/spec at each phase (reviews, inspections, walkthroughs; mostly static, done during development).
• Validation: "Are we building the RIGHT product?" — checking the finished product against the USER's real needs (actual testing, mostly dynamic).
• Regression testing: after any change or bug fix, RE-RUN old tests to make sure previously working features did not break. Usually automated.
• Alpha testing: by internal users/testers at the developer's site, before release.
• Beta testing: by real external users at their own sites, on a near-final version.

Software architecture is the high-level structure of a system: its main parts and how they talk to each other. Common architectural styles:

• Layered: code stacked in layers (presentation → business logic → data access → database). Each layer only calls the layer below. Easy to understand and replace layers; can be slow if a request must pass through many layers.
• Client–server: many clients request services from a central server (web browser ↔ web server). Central control and data, but the server is a bottleneck and single point of failure.
• MVC (Model–View–Controller): splits an interactive app into Model (data + business rules), View (what the user sees), Controller (receives user input, updates model, picks the view). One model can have many views; UI and logic change independently.
• Monolith vs Microservices: a monolith is one big deployable unit — simple to build/test/deploy at first, but hard to scale and one bug can crash everything. Microservices split the system into small independent services, each with its own database, talking over the network (HTTP/queues) — independent scaling and deployment, but complex operations, network latency, and hard distributed debugging.

Coupling = how much modules depend on EACH OTHER. Cohesion = how strongly the parts INSIDE one module belong together. Design goal (memorize this): LOW coupling, HIGH cohesion. Then a change in one module barely touches others, and each module is easy to understand, test, and reuse.

Cohesion types, best → worst: functional (module does exactly one task — best), sequential (output of one part feeds the next), communicational (parts work on the same data), procedural, temporal (things done "at the same time", e.g., init), logical (similar-looking tasks lumped together), coincidental (random unrelated stuff — worst, e.g., a "Utils" class holding date parsing + email + tax math).

• S — Single Responsibility: a class should have ONE reason to change. Bad: Report class that computes data AND prints AND saves to DB. Good: split into ReportData, ReportPrinter, ReportSaver.
• O — Open/Closed: open for extension, closed for modification. Bad: a big if (shape == "circle") ... else if (shape == "square") that must be edited for every new shape. Good: each shape class has its own area(); adding a shape adds a class, touches no old code.
• L — Liskov Substitution: a subclass must be usable anywhere its parent is expected, without surprises. Classic violation: Square extends Rectangle but setWidth() secretly changes height too — code written for Rectangle breaks.
• I — Interface Segregation: many small interfaces beat one fat one. Bad: Machine interface with print(), scan(), fax() forces a simple printer to implement fax. Good: separate Printer, Scanner, Fax interfaces.
• D — Dependency Inversion: depend on abstractions (interfaces), not concrete classes. Bad: OrderService creates new MySQLDatabase() inside. Good: it receives a Database interface — swapping MySQL for Postgres or a test mock needs no change to OrderService.

DRY — Don't Repeat Yourself: one piece of knowledge lives in ONE place; copy-pasted logic means every bug must be fixed twice. KISS — Keep It Simple, Stupid: the simplest design that works beats a clever complicated one.

A design pattern is a reusable, named solution to a common design problem. Three famous ones:

Singleton (creational): make sure a class has exactly ONE instance, with a global access point. Used for configs, loggers, connection pools.

Factory Method (creational): let a factory decide WHICH concrete class to create, so the caller never writes new ConcreteClass() itself.

Observer (behavioral): one subject keeps a list of observers; when the subject's state changes, it notifies all of them. This is the idea behind event listeners, notifications, and MVC's model→view updates.

Strategy (behavioral): define a family of algorithms, put each one in its own class behind ONE common interface, and let the client swap them at runtime. Classic example: a Sorter that can use QuickSort or MergeSort without changing its own code.

When to use it: (1) you need to pick the algorithm at runtime — e.g., small array → insertion sort, huge array → merge sort; (2) you want to add new algorithms WITHOUT touching old code — that is exactly the Open/Closed principle: a new algorithm is just one new class; (3) you want to replace a big if/else chain that chooses behavior.

An Information System (IS) is a combination of people, hardware, software, data, and processes that collects, stores, processes, and delivers information to support decisions in an organization. Software is just one part — the people and business processes matter too.

Different levels of an organization use different systems. From bottom (daily operations) to top (strategy):

• TPS (Transaction Processing System): records routine daily transactions — sales entry, ATM transactions, payroll, billing. Used by operational staff. Huge volume, simple decisions.
• MIS (Management Information System): takes TPS data and produces regular summary reports (weekly sales report, monthly production report) for middle managers.
• DSS (Decision Support System): interactive, model-based analysis for semi-structured decisions — "what happens to profit if we cut price 5%?". Used by managers/analysts.
• ESS / EIS (Executive Support System): dashboards of key indicators plus external data (market trends) for TOP executives making long-term strategic decisions.

Before starting a project, we check whether it is even worth doing. Main feasibility types:

• Technical feasibility: can we build it with available technology and skills?
• Economic feasibility: do the benefits beat the costs? (cost–benefit analysis)
• Operational feasibility: will people actually use it? does it fit how the organization works?
• Schedule feasibility: can we finish in the required time?
• Legal feasibility: does it break any law or regulation (data privacy etc.)?

How big/costly will the software be?

• LOC (Lines of Code): estimate size in (kilo) lines of code. Simple, but depends on language and coding style, and is hard to guess early.
• Function Points (FP): measure functionality instead of lines — count inputs, outputs, user inquiries, internal files, external interfaces, weight each by complexity, then adjust. Language-independent and usable early.
• COCOMO (Constructive Cost Model), by Boehm: converts size (KLOC) into effort and time.

Basic COCOMO formulas:

Business logic (also called domain logic) is the part of the software that encodes the REAL rules of the business: calculations, decisions, and workflows. It is NOT the UI (screens, buttons) and NOT the data access (SQL, files) — it is the "thinking" in between. Examples of business rules: "orders of 5000 Tk or more get a 10% discount", "a loan above 1 lakh needs manager approval", "stock can never go below zero".

Where it lives: in a 3-tier / layered design, business logic sits in the MIDDLE layer — the service layer / domain model — between the presentation (UI) layer and the data access layer. Kept there, you can change the UI or swap the database without rewriting the rules, and you can test the rules alone.

How it is implemented:

• Service classes: one class per workflow — e.g., OrderService.placeOrder() runs validation, discount, and stock update as one unit.
• Domain entities: objects like Order or Account carry their own small rules — e.g., order.subtotal() knows how to add its lines.
• Rule engines / config: rules that change often (discount rates, limits) are stored as data, so they can be updated without redeploying code.