In one sentence: the SDLC (Software Development Life Cycle) is the step-by-step route a team follows to turn "we need an app" into working software, and then keep it working for years.

Why the SDLC exists

The textbook opens with TechNova Solutions, a company hired to build a delivery-tracking app for a logistics firm. Without a structured process, the project "spirals into chaos": missed deadlines, blown budgets, an unhappy client. It then describes a government social welfare portal for all 36 states. That project involves biometrics, money, health data, many user types and frequent policy changes. Without an SDLC, requirements get misread, security gets forgotten and policy changes force costly rework.

The book defines the SDLC as a systematic, iterative process for building software that prioritises quality, efficiency, correctness and maintainability. Every phase is planned, documented, reviewed and validated.

The SDLC's dual nature (a favourite exam question)

Four big benefits the textbook lists

1. A blueprint: it keeps technical work aligned with business goals and user needs.
2. Predictability and control: you can estimate budget, effort and time, and spot risks early.
3. Accountability and documentation: every phase leaves artefacts (SRS, design docs, test plans, change logs, deployment records) that form an audit trail for audits, regulators or legal disputes.
4. Knowledge transfer and team scalability: a new developer can read the documents instead of relying on "tribal knowledge", so onboarding is faster and the team survives staff turnover.

The slides add five roles of the SDLC in software engineering: structure, efficient resource and cost management, risk reduction by catching issues early, consistency and quality assurance, and collaboration among stakeholders.

The 7 phases, one by one

1. Planning: "Should we build this, and how?"

The foundation stage. The team defines the scope (what's in and what's out, which prevents scope creep, the uncontrolled growth of features), sets measurable objectives, and runs a feasibility study with three checks:

Key activities: resource allocation (people and technology), budget estimation, risk identification and mitigation, timeline projection using Gantt charts, PERT diagrams (Program Evaluation and Review Technique) or critical path analysis, and initial stakeholder engagement.

2. Requirement Analysis: "What must the system do?"

The team works with clients, end users and business analysts to gather, clarify, prioritise and document requirements.

Techniques: stakeholder interviews (structured, semi-structured or unstructured), workshops including JAD (Joint Application Development) sessions, feasibility studies, and user stories in the format "As a [user], I want [goal] so that [reason]."

Deliverables: the SRS (Software Requirements Specification, the main deliverable), use case models and diagrams, feasibility reports and a prioritised requirement list. Prioritise with MoSCoW: Must have, Should have, Could have (nice but not essential), Won't have this time. The slides also mention cost-benefit analysis and stakeholder influence.

3. Design: turning the "what" into the "how"

Architects choose the architecture (client-server, microservices, or a single monolithic codebase), design the database schema, build UI mockups and prototypes, and draw diagrams: DFD (Data Flow Diagram: how data enters, moves through and leaves the system) and UML (Unified Modelling Language) class, sequence and component diagrams. They also plan security (authentication, encryption, authorisation), performance and scalability (caching, indexing, load balancing) and pick the technology stack. High-level design covers the overall architecture. Low-level design covers algorithms, database schemas and interface layouts. The output is a set of design documents that serve as the technical blueprint.

4. Implementation (Coding): "Let's build it"

Developers turn the design into code, following coding standards (naming, formatting, comments, error handling), using source control like Git (safe, trackable changes, branches and rollback), building modular pieces, and using practices like Agile, TDD and CI/CD. Peer code reviews catch errors and share knowledge. Documentation written alongside the code includes inline comments, API docs, installation guides and user manuals.

5. Testing: "Does it work as intended?"

This phase detects and fixes errors before release, validates the requirements and checks reliability under real-world stress. It covers unit, integration, system, acceptance, performance and security testing. Session 3 covers each type in detail.

6. Deployment: "How do we deliver it to users?"

The software goes live. Traditional deployment is one big, carefully scheduled event, which may involve downtime, major configuration changes and user training. Modern Agile and DevOps teams deploy small pieces often through CI/CD pipelines. Activities: data migration from old systems, installation and configuration, deployment automation (dev → staging → production) and training for users and administrators. The slides name three strategies: phased rollout, parallel deployment (old and new run side by side) and direct cutover (switch off old, switch on new).

7. Maintenance: keeping it alive

This phase is ongoing, and maintenance can account for up to 70% of the total lifetime cost of software. Learn the four types by heart:

SDLC models: different routes through the phases

A model is a strategy for moving through the phases. The textbook's LMS story: project manager Zion at TechNova must build a university Learning Management System and weighs each model. In the end she picks a hybrid: a prototype first to clarify unclear requirements, then Agile for full development.

Waterfall: one step at a time, no going back

Use it for: government and defence, construction and engineering software, embedded systems and firmware (printers, washing machines), aerospace, and banking systems with strict regulatory compliance. In short, anywhere requirements are fixed and documentation and approvals are mandatory.

V-Model: Waterfall with a matching test for every step

An extension of Waterfall focused on verification and validation. For every development stage there is a corresponding testing phase planned in parallel. For example, while architects design the system, testers write the integration test plans. It catches defects early but is just as inflexible as Waterfall.

Incremental Model: deliver in slices

Split the system into small modules and release the basics first (course registration and login), then add more in later increments (video lectures, then assignments, then grades). This allows partial delivery and user feedback at each stage.

Prototype Model: "I'll know it when I see it"

Quickly build a rough working model with limited features to get feedback when requirements are unclear. The prototype evolves until stakeholders know what they want.

Agile: short cycles, constant feedback

Agile is iterative and incremental. Work is split into sprints (short, fixed-length cycles of 1–4 weeks), each producing working software that users review. The Agile cycle in the textbook: Plan → Design → Develop → Test → Launch → Review → Deploy, then loop back.

The Agile Manifesto (2001) has four values. The item on the left is valued more, though the item on the right still matters:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

And 12 principles, which examiners describe as scenarios:

Scrum (Agile framework): sprints, a product backlog (prioritised list of everything to build, owned by the Product Owner) and daily stand-ups (15 minutes: what I did yesterday, what I'll do today, any blockers). Kanban: a visual board, limits on work in progress and continuous flow instead of fixed sprints. Session 4 covers both in depth.

Use Agile for: web and mobile apps, startups, dynamic markets, anything where requirements will change. Weakness: may lack formal documentation, is less suitable for fixed contracts or heavy regulation, and needs experienced, collaborative people.

Spiral: loops of risk analysis

Spiral combines Waterfall's structure with prototyping's flexibility and puts risk analysis at every loop. The textbook's quadrant names: Objective Identification → Alternate Evaluation and Risk Analysis → Product Development → Review and Next-Phase Planning. Best for: large, high-budget, high-risk projects, evolving requirements, critical systems (defence, aerospace, banking, healthcare), and research. Weaknesses: expensive, complex, needs risk-analysis experts, and too much overhead for small projects.

Compare the three main models (Table 1.1)

Summary

• The SDLC is both a process model and a project management tool, with 7 phases.
• Planning = scope, objectives, feasibility (technical, economic, operational). Analysis = requirements and the SRS. Design = "how". Implementation = code. Testing = verify. Deployment = deliver. Maintenance = corrective, adaptive, perfective, preventive (up to 70% of cost).
• Waterfall suits fixed requirements, Agile suits change, Spiral suits risk, the V-Model adds parallel testing, Prototype suits unclear needs, and Incremental delivers in slices.

In one sentence: an architectural pattern is a proven blueprint for arranging the big parts of a system, and coding best practices are the habits that keep the code inside those parts readable, safe and fast.

Architectural design patterns

Definition: a general, reusable solution to a commonly occurring problem in software architecture. It sits at a high level: it says which major components exist, what each is responsible for, and how they talk. It does not say how to write each line of code.

Why they matter: they give a shared vocabulary, set the system structure, help communication with stakeholders, support design decisions and make change and scaling easier. Benefits: maintainability, scalability, reusability, reliability (fault isolation), flexibility, team collaboration, and faster onboarding. The slides highlight scalability, maintainability, reusability, improved collaboration and performance optimisation.

1. Layered architecture

Good for enterprise apps (ERP, CRM, payroll, hospital systems). Layers can be built and tested separately. Weakness: coupling between layers is fairly tight and it scales less well (Table 2.1 lists scalability as "limited, monolithic").

2. Client-server

Clients (your phone or browser) request services and servers provide them. Strengths: centralised control, resource sharing, security. Examples: online banking, email, cloud platforms. Variants: 2-tier (client talks straight to the database) and 3-tier (client → application server with the business logic → database). The middle tier improves security by isolating database access.

3. MVC (Model–View–Controller)

The Model is independent of the View and Controller, so the UI can change without touching business logic. It enables parallel development and unit testing. Frameworks: ASP.NET MVC, Spring MVC, Ruby on Rails, Django. Used in CMS like WordPress and e-commerce.

4. Microservices

The app is a collection of small, loosely coupled, independently deployable services, one per business capability (accounts, fraud detection, loans). Each has its own database and talks through lightweight APIs (usually REST over HTTP). Benefits: independent deployment, technology diversity, fault isolation (if loans crash, transfers still work), and faster time to market. Used by Netflix, Amazon and Spotify. Tools: Spring Boot, Docker, Kubernetes. The opposite is a monolith: one big codebase, simpler for small apps.

5. Event-Driven Architecture (EDA)

Components react to events. Producers publish events ("withdrawal made"), an event channel / message broker (Kafka, RabbitMQ, AWS EventBridge) carries them, and consumers subscribe and react ("send SMS alert", "update fraud score"). It is asynchronous, very loosely coupled and real-time, which makes it ideal for fraud alerts, transaction notifications, IoT and live analytics.

6. SOA (Service-Oriented Architecture)

Applications are built by orchestrating reusable services exposed over a network using standard protocols (SOAP, XML, HTTP), often through an ESB (Enterprise Service Bus). Strengths: reuse, platform independence and interoperability. It is great for integrating legacy systems and third parties in banking, insurance and government. Bank examples from the slides: payment gateways (PayPal, Stripe), credit score checks and KYC identity verification.

Coding best practices

Readability = how easy code is to read. Maintainability = how easy it is to change, extend and debug. They go together.

• Clean code: simple, no redundant logic. KISS = Keep It Simple, Stupid. DRY = Don't Repeat Yourself. SOLID = five object-oriented design principles. SRP = Single Responsibility Principle (one function does one job).
• Comments explain why, not just what. Too many comments add clutter.
• Meaningful names: userAge, calculateSum, transactionAmount, not x or doMath. Conventions: camelCase for variables, PascalCase for classes, UPPERCASE for constants. Style guides: PEP 8 (Python), Google Java Style.
• Consistent indentation and formatting (IDEs can auto-format).

Version control (VCS)

A version control system tracks every change to code so a team can collaborate and roll back. Centralised: one central repository. Distributed: every developer has the full history locally, and this is how Git works.

Commit best practices: make atomic commits (one logical change each); write clear messages with a 50–72 character summary in the imperative ("Fix bug", "Add feature"); commit early and often; don't commit generated files (binaries, build artefacts, logs); use branches for tasks; rebase and squash before merging to keep history clean. Use pull requests for peer review.

Error handling and debugging

• Logging frameworks: Log4j (Java), NLog (.NET), Python's logging module. Levels: DEBUG, INFO, WARN, ERROR, FATAL. Include timestamps, error codes and method names. Never log PII (personally identifiable information) or passwords. In production, focus on ERROR and WARN.
• Structured exception handling (try–catch) stops crashes. Catch specific exceptions (NullPointerException, IOException), never leave empty catch blocks, and don't use exceptions for normal control flow.

Security best practices

Also: validate all user input; hash passwords (never store plain text); encrypt data in transit with TLS/SSL; use secure authentication.

Performance optimisation

Refactoring = restructuring code without changing its external behaviour. Techniques: modularisation (split big code into modules), inlining small frequently-called functions (with care, to avoid bloat), eliminating duplication, and simplifying conditionals (for example with lookup tables).

Big-O describes how time grows with input size: O(1) constant (hash table lookup), O(log n) (binary search on sorted data, balanced BST, heap insert and delete), O(n) linear (linear search), O(n²) gets slow quickly (bubble sort). Divide and conquer: merge sort, quick sort. Greedy: Kruskal's minimum spanning tree. Self-balancing trees (AVL, red-black) prevent slow unbalanced BSTs. Heaps suit priority queues. Dynamic programming avoids repeated calculation. Slides add database indexing, query optimisation and load testing.

More development methodologies

Session 2's version of Agile sprints is 2–4 weeks and produces a "potentially shippable product increment".

Summary

• Six patterns: layered, client-server, MVC, microservices, event-driven, SOA. Know each one's best use.
• Clean code: KISS, DRY, SOLID, good names, comments that explain why.
• Git flow uses master, develop, feature, release and hotfix branches. Commits should be small, atomic and clearly described.
• Handle errors with logging and specific try–catch. Secure against SQLi, XSS and buffer overflow. Optimise with refactoring and good algorithms.
• RAD = prototypes and speed. XP = pair programming, TDD, small releases.

In one sentence: testing finds defects in the product, while quality assurance (QA) improves the process so fewer defects get made in the first place.

The textbook's opening story: a remote patient-monitoring app skipped proper testing to meet a deadline. It sent false alerts, staff got overwhelmed and real emergencies were missed. Testing makes sure software does what it should (functional correctness) and doesn't do what it shouldn't (security and robustness).

Testing can be manual (a person runs it) or automated (tools and scripts run it).

The four levels of testing

Unit testing

Tests the smallest testable part (a function, method or class) in isolation. Goal: early bug detection, which is cheaper, and a safety net when refactoring. Frameworks: JUnit (Java), pytest (Python), NUnit (.NET). These run automatically in CI pipelines.

Integration testing

Tests how modules work together: data flow, API communication, dependencies, mismatched data types, protocol errors. Tools: Postman (REST APIs) and SoapUI (SOAP and REST web services). Strategies: top-down, bottom-up, sandwich (hybrid).

System testing

Tests the complete integrated system end-to-end, in an environment close to production, from the user's perspective.

Acceptance testing

The final phase before delivery. Checks the software meets business and user requirements and is fit for purpose. It involves stakeholders like clients, business analysts and product owners.

Test automation tools

In a pipeline, unit tests run right after the build, then integration, Selenium, JMeter and Appium tests. If a test fails, the pipeline halts deployment.

Quality assurance

Quality standards

Memory hook for ISO 25010: "Four Pretty Cats Usually Rest Safely, Mostly Purring" = Functional suitability, Performance, Compatibility, Usability, Reliability, Security, Maintainability, Portability. Reliability = works correctly for a set time under set conditions, including fault tolerance and recoverability. It's the answer for "handle failures" in aerospace.

Code reviews and pair programming

Reviews catch bugs early, share knowledge and create accountability. Pair (peer) programming: a driver writes and a navigator reviews live, then they swap. It comes from XP. Tools: SonarQube (automatic static code analysis: code smells, bugs, vulnerabilities, duplication, technical debt) and Crucible (Atlassian's collaborative peer code review tool).

Defect tracking

Record each bug with description, severity, steps to reproduce and screenshots, then track it until it's closed. Tools: JIRA (Atlassian), Bugzilla (open-source, from Mozilla), TestRail (test-case management that links to JIRA).

TDD vs BDD

Why testing matters in the SDLC

Fixing bugs early is cheaper, users trust reliable software, testing finds security holes (like SQL injection in banking apps) and it builds stakeholder confidence. Moving testing earlier in the cycle is called "shift left".

Summary

• Unit (isolation, JUnit) → Integration (modules, Postman) → System (whole, functional + non-functional) → Acceptance (UAT users, BAT business).
• Selenium = web, JMeter = performance, Appium = mobile.
• QA prevents defects. ISO 25010 = 8 product qualities, CMMI = 5 process maturity levels, IEEE 730 = QA plan.
• SonarQube = static analysis, Crucible = code review, JIRA and Bugzilla = defect tracking.
• TDD = Red–Green–Refactor. BDD = Given–When–Then with Cucumber.

In one sentence: Agile teams deliver small working pieces often. Scrum does it in fixed-length sprints with set roles and meetings, while Kanban does it as a continuous flow on a visual board with limits on how much is in progress.

The textbook's story: TechNova builds an e-commerce platform for a startup whose vision keeps changing. Waterfall fails, so they switch to Agile, involve the client throughout and deliver in small increments. Remember: Agile is not one method. It is a set of values and principles (the 2001 Manifesto) that several frameworks follow.

Scrum

A lightweight framework: it doesn't demand heavy documentation. It's built on empirical process control, meaning decisions come from experience and observation, not from predicting everything up front. It has three pillars:

The 3 roles

The 4 events (ceremonies)

Once a sprint starts, the Sprint Goal doesn't change, so the team can focus.

The 3 artefacts

Tracking a sprint

• Velocity: work completed per sprint (usually story points). Used for planning and forecasting. It is not a productivity score and shouldn't be used to compare teams.
• Burn-down chart: work remaining (vertical) vs days (horizontal). A steeper line than ideal means ahead of schedule. Flatter means behind.
• Burn-up chart: work completed and total scope, so it also shows scope changes.
• Story points are relative effort, often on a Fibonacci scale (1, 2, 3, 5, 8).

Kanban

Origin: Toyota, Japan, mid-20th century, developed by Taiichi Ohno. "Kanban" means "signboard" or "visual signal". It is based on Lean thinking (cut waste, deliver value faster).

Six principles: (1) visualise the workflow, (2) limit Work In Progress (WIP), (3) manage flow, (4) make process policies explicit, (5) feedback loops, (6) improve collaboratively and evolve experimentally.

Pull system: people pull new work only when they have capacity, instead of work being pushed onto them. This supports continuous delivery and shorter cycle time.

Kanban metrics: cycle time (start to finish of a task), lead time (from request to delivery) and the cumulative flow diagram (CFD), which shows bottlenecks. Tools: Trello (simple, small teams), Jira, Azure DevOps (large projects).

Kanban + Continuous Delivery gives faster time to market, transparency and quality. The challenges are cultural resistance, no prescribed roles (which can confuse immature teams), heavy automation needs and harder measurement.

Scrum vs Kanban

Scrumban is a hybrid that combines Scrum's structure with Kanban's flow.

Iterative vs incremental development (IID)

Phases of an iterative cycle (slides)

Requirement gathering → Design (HLD, detailed, UI, database, component design) → Implementation → Testing → Feedback and evaluation → Iteration planning → Release and deployment → Review and refinement. The textbook version: Initial planning → Planning → Requirements → Analysis and design → Implementation → Testing → Evaluation.

Steps in incremental development

Requirement analysis → Design and planning → Develop the initial increment → Testing and evaluation → Review and feedback → Develop later increments → Integration and deployment → Iterative improvement.

Managing evolving requirements

Keep a product backlog that's regularly reprioritised (using MoSCoW), hold feedback and review sessions at the end of each iteration, and put changes through a change control process. Mitigations: a flexible backlog (break epics into stories, leave buffer capacity), enforced coding standards (linters, reviews, pair programming), automated testing and CI/CD, retrospectives, and a clear Definition of Done.

Summary

• Scrum has 3 pillars (transparency, inspection, adaptation), 3 roles, 4 events and 3 artefacts.
• PO owns the product backlog, the Dev Team owns the sprint backlog, and the Scrum Master removes impediments.
• Kanban comes from Toyota and Taiichi Ohno ("signboard"). Visualise, limit WIP, pull system, measure cycle and lead time.
• Iterative = refine. Incremental = add. Together = Agile.

In one sentence: DevOps gets developers and operations staff working as one team, CI/CD automates building, testing and shipping code, and release management plans each release so it goes out safely, with a way back if it breaks.

The textbook story: 3Bells Solutions in Lagos is building a mobile banking app. Manual testing, ad hoc deployments, Dev-vs-Ops blame and a security hole in a release lead to a failed demo. They adopt DevOps, CI/CD (Jenkins, GitHub Actions), Docker and Kubernetes, canary deployments, security scanning (SonarQube, OWASP ZAP) and Infrastructure as Code (Terraform).

CI, Continuous Delivery, Continuous Deployment

Build stage details: compiles code (for example, Java into a JAR or WAR file, or builds a Docker image), resolves dependencies and produces artefacts. Deploy stage: should be fully automated, followed by smoke tests in production.

9 best practices: single source repository, automate everything, consistent builds (Docker), parallelise, store build artefacts centrally, comprehensive testing, monitor the pipeline (build time, failure rate), a collaboration culture, and security in the pipeline (DevSecOps).

DevOps

The problem: developers change code often, while Operations must keep systems up (often aiming for 99.999% uptime). Working in silos leads to "it worked on my machine" and a blame game. DevOps is a cultural and technical movement that bridges them with shared responsibility, automation and feedback.

DevOps principles (slides)

1. Automation of the software lifecycle (testing, builds, releases, environments)
2. Collaboration and communication: people make a great team, tools only help
3. Continuous improvement and minimisation of waste (for example, reducing mean-time-to-recovery)
4. Hyperfocus on user needs with short feedback loops

"Increased manual processes" is never a DevOps principle. Benefits: higher quality and security, faster time to market, collaboration, efficiency, continuous improvement.

Core DevOps practices and tools

DevSecOps

Dev + Sec + Ops: security is built in from the start, not bolted on at the end. "Shift left" means moving security checks earlier. Automated scanning in the pipeline uses SonarQube, Snyk, Checkmarx, OWASP ZAP. Train developers on the OWASP Top Ten. Use policy-as-code and compliance-as-code for GDPR, HIPAA and PCI DSS.

The textbook also shows a GitHub Actions workflow file (.github/workflows/nodejs.yml). It triggers on a push or pull request to main, runs on ubuntu-latest, tests Node versions 14, 16 and 18 (matrix), then checks out the code, runs npm install, npm test and npm run build, uploads artefacts and copies files to a server over SSH using secrets.

Software release management (SRM)

SRM plans, schedules, tests, deploys and controls a software release so it's delivered predictably without breaking the live system. Release decisions affect three things: time (time-to-market, scope creep, coordination delays), budget (resources, tooling and infrastructure, rework) and customer satisfaction (reliability, feature expectations, communication). Governance frameworks: COBIT, ITIL, ISO/IEC 20000. KPIs: deployment frequency, change failure rate, customer satisfaction score.

Release planning

Maps the timeline so software ships predictably and on time. Slide elements: release scope, resource allocation, timeline, communication. Why it matters: strategic alignment (map release objectives to organisational priorities and customer value), resource allocation, time management, risk mitigation. Textbook activities: set objectives, define scope, prioritise (MoSCoW), map critical paths and dependencies, set code and feature freeze dates, schedule milestones, coordinate teams.

Dependencies

Anything outside your code that your app needs. Types: internal components (microservices, shared libraries, authentication), external libraries (npm, PyPI, SDKs), third-party services (payment gateways, cloud, social login, analytics) and system-level tools (databases, file storage, message brokers). Steps: identify → map → version control (semantic versioning, lock versions) → automation tools (npm, yarn, pip, Poetry, Maven, Gradle, Composer, NuGet; Dependabot, Renovate, Snyk for updates) → test (smoke tests, contract tests, mocks) → coordinate with stakeholders. Unmanaged dependencies can break the build or introduce vulnerabilities.

Risks

Types: compatibility, performance, security, regulatory and compliance, user experience, operational. Lifecycle: identify → analyse (impact × likelihood, risk matrix or heat map) → mitigate → communicate (risk register). Mitigation: automated testing, staging environments, continuous integration, release gates and checklists, monitoring and rollback plans.

Deployment strategies

Rollback and recovery

Rollback = revert to the previous working version after a bad release. Triggers: system failures, broken critical functions (measured by SLOs and SLIs), user-impact thresholds, security issues. Tools: IaC templates, database migration reversal (Liquibase, Flyway), artefact reversion, Git (commit hashes, tags), GitOps. Always back up before releasing. Measure MTTR (Mean Time To Recovery) and plan RPO (how much data you can afford to lose) and RTO (how fast you must be back).

Recovery = restore working order after a failure. Techniques: failover (active-passive: backup waits idle; active-active: both run and share load), rollback procedures, hotfixes (urgent critical fixes) and patches (broader bug and security fixes), monitoring and alerts (Prometheus, Datadog, ELK, OpenTelemetry, PagerDuty) and an incident response plan.

PMBOK® Guide in release management

PMBOK = Project Management Body of Knowledge. Knowledge areas used: scope, time, cost, risk, contract, human resource, communication and quality management. Process groups: Initiating → Planning → Executing → Monitoring and Controlling → Closing.

Major release tasks, in order

Needs identification and feasibility → Business case approval (ROI) → Requirement definition → Documentation and design → Development → Testing (lab and field) → Beta testing with customers → Change control → Training and customer notification → Controlled deployment → General Availability (GA) → Debrief and transition to lifecycle management.

Release management process

FPR (Functional Product Request, raised by Sales, Marketing, R&D or customers) → Release packaging → Documentation → Development process (lab testing, field testing, quality gates) → Change control (manages scope creep and last-minute requests) → Customer notification → Training (influences the GO/NO-GO decision) → Deployment (controlled introduction, GA, back-out plan).

The Release Manager

A project manager specialised in software deployment, like the conductor of an orchestra. They coordinate Dev, QA, Ops and Support; manage schedules, risks and stakeholder communication; mediate with Finance, Legal and Sales; and lead the release team (planning meetings, release notes, GO/NO-GO decisions, retrospectives). Table 5.1: Sales raises the FPR, Finance approves budgets, Legal gives regulatory guidance, Operations deploys and monitors, Test Engineering validates quality.

Slides extras: the monitoring and controlling phase tracks progress (maintenance logs, risk documents, performance reports). The closure phase hands over user manuals, troubleshooting guides and final reports.

Summary

• CI = frequent merge and auto test. Delivery = always releasable, with a human approving. Deployment = fully automatic.
• DevOps = culture, automation, collaboration. Docker = containers, Kubernetes = orchestration, Terraform = IaC, Prometheus and Grafana = monitoring.
• DevSecOps = shift security left.
• Release management: plan (scope, resources, timeline, communication), manage dependencies and risks, deploy safely (blue-green, canary), roll back, recover.
• PMBOK process groups: Initiating, Planning, Executing, Monitoring and Controlling, Closing.

In one sentence: good documentation means anyone can understand, use and maintain the software, and good collaboration (clear communication plus tools like Jira, Confluence and Slack) keeps a spread-out team working as one.

The textbook story: a developer on a team split across time zones is blocked by a bug, and the colleague who can help only replies the next day. Clear documentation and communication are what separate a successful launch from a failed one.

The 7 types of software documentation

When each is written: Pre-development: requirements and design documents. During development: technical and testing documentation. Post-development: user and operation manuals, and the known-bugs list.

Documents across the project life cycle

The SRS (Software Requirements Specification)

A formal document of all functional and non-functional requirements, prepared in the requirements analysis phase and validated by both the developers and the client. Objectives: clarity, agreement, a basis for estimation, a baseline for testing, and communication.

Structure per IEEE 830-1998:

1. Introduction: purpose, scope, intended audience, definitions and acronyms, references
2. Overall description: product perspective, product functions, user characteristics, constraints (hardware, software, regulatory), assumptions and dependencies
3. Specific requirements: functional ("The system shall send a confirmation email…"), non-functional (performance, reliability, usability, security, maintainability, portability), external interfaces (user, hardware, software, communication)
4. Appendices: tables, mockups, glossary, revision history

A good SRS is: Correct, Unambiguous (one meaning only), Complete, Consistent (no conflicts), Verifiable (testable), Modifiable, Traceable. Memory hook: "CUCC-VMT: Can U Catch Critical Vague Missing Things?"

Guidelines, advantages, problems

Documentation tool features: Markdown and HTML support, feedback mechanism, access control and permissions, click-button APIs, table of contents, publishing control.

Team collaboration and communication

Team collaboration is a coordinated effort among developers, testers and stakeholders. It speeds delivery, improves quality through peer reviews and reduces risk by catching miscommunication early. In Agile it supports sprints, stand-ups and retros. In DevOps it supports shared CI/CD responsibility.

Challenges (slides): distributed teams (time zones), tool overload (too many platforms), knowledge silos (poor documentation keeps knowledge with a few people), miscommunication (vague requirements). Poor communication causes ambiguous requirements, duplicate effort, missed deadlines and quality issues.

Four communication principles: Clarity (simple language, diagrams), Transparency (share progress, blockers, decisions openly), Consistency (routine updates, standard templates), Empathy (active listening, cultural awareness, constructive feedback).

Six effective strategies (slides): clear and concise documentation; regular meetings and check-ins; real-time communication tools; active stakeholder engagement; code and peer reviews (pull requests, pair programming); conflict resolution and feedback.

Communication charter: drawn up at project start. It sets the preferred tool for each purpose (Slack for chat, Confluence for docs), response-time expectations, meeting frequency, decision-making authority and etiquette.

Collaboration tools

Jira task management process

Create a task (Create button → project → issue type: task, story or bug → summary, description, assignee) → assign it by skill and availability → set a due date → track it through the workflow using the Activity panel → mark it Done. Tracking templates include a board (Kanban: To Do → In Progress → Done), a list, a calendar and a form. Best practices: break big projects into small tasks, create a structured workflow, write clear descriptions, use labels, set realistic due dates, assign to the best-qualified person.

Task workflow and tracking

Create tasks (from user stories, technical requirements, bugs) → prioritise (MoSCoW, story points on a Fibonacci scale, business impact) → assign → move across boards → sprint review and retrospective. Track with burn-down charts, cumulative flow diagrams, velocity and task dependencies. Report with daily stand-ups, weekly summaries and stakeholder demos. Tailor reports to the audience: executives want high-level KPIs, developers want detailed boards.

Jira Cloud + Slack integration

A two-way link: create Jira issues from Slack and get Jira notifications in Slack. Key commands: /jira connect (link a project to a channel), /jira notify (personal notifications), /jira create (new work item), /jira manage, /jira [WORK-123] (show an item). Issue keys like PROJ-123 automatically expand into previews. It respects Jira permissions and a Jira admin must enable it.

Summary

• 7 documentation types, each with its own audience: user manual → end users, operation manual → sysadmins, design → developers.
• SRS follows IEEE 830 (Introduction, Overall description, Specific requirements, Appendices) and should be correct, unambiguous, complete, consistent, verifiable, modifiable, traceable.
• Synchronous vs asynchronous communication. Principles: clarity, transparency, consistency, empathy.
• Jira = tasks, Confluence = documentation, Slack = real-time chat. Integrate them.