# content

### W1 -System Processes

SDLC

1. Plan
2. Code
3. Build
4. Test
5. Release



Waterfall

1.  Plan

    -> Software requirement documents, product roadmaps, what software should do...etc
2. Design   \
   -> Design architecture, user interface, database (Figma, ER models)
3. Code   \
   -> Developers working concurrently to work on different components in the software
4. Integration   \
   -> Combine all individual components to create a unified software
5. System Test   \
   -> Testing at the end of the software creation

✅ Logical and organised as the requirements are stated very early on; follows an iterative and incremental process.\
❌ A plan is executed, and it is not purposeful; this method assumes plan is clear from the start, but an iterative and incremental process brings in uncertainty as there may be discovery of bugs, change in clients plan/goals midway through the project.

Agile Process

* No standard template/checklists/procedures
* More prescriptive than descriptive
* Examples: Scrum, Extreme Programming (XP), Kanban

<figure><img src="https://482590904-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F6E9aQQS3hXkCehJiKzTA%2Fuploads%2Fjmxox6KbSBulnvu9lBJo%2Fimage.png?alt=media&#x26;token=b3227117-6fc5-41c9-ae8d-2b7707b5a641" alt=""><figcaption></figcaption></figure>

Scrum

* Uses short iterations called sprints that focus on productivity
* Breaks down a product into sprints, with each sprint focusing on one feature/task of the project.
* After each iteration, show something to the client.

Roles:

1. Product Owner: Lead user of the system, person with the vision of what he/she wants to build
2. Team: Develops the product
3. Scrum Master: Facilitates the process of stand ups.



Process:

1. Plan
   1. Customer presents user stories and prioritises the business value a feature will bring, and the developers will choose what features they can realistically deliver in a week
2. Execute
3. Review
   1. Potentially, when done, customer tries the features in a working build.





XP

* Focus on software engineering practices and quality



XP Main Practices

* Pair Programming + Test-Drive Development (TDD)
  * Developers pair up to write automated tests like unit tests
  * Code is then written to make the test pass, and then refactored to improve code quality
  * Pairs rotate to share knowledge and improve code quality.



* Continuous Integration
  * Automated build and test process for a team



* Code Review and Refactoring
  * Studying of source code by others
  * Modify existing code to imrpove design, structure, without changing functionalities



Kickoff/Sprint Planning

* Each project begins with a kickoff meeting
  * Overview of the project and the goals
  * Who will be working on the project
  * Determining the point person for client sign-off/contact
  * Creating project backlog
  * Determining which features to work on
  * Getting on the same page.



Software Operations

* Operate
  * Make sure apps runs well, reliably and avail with adequate security
* Monitoring
  * Be able to respond to any incidents early and predict future incidents
* Handle Requests and Feedback from Users
* Collect and analyse data on availability/performance, security and other operations-related processes.
* Securtiy
  * Data Theft, Data tampering, DDoS
  * Internal and external threats
  * Access control: authorisation and authentication
* Incidents and Recovery
  * Unplanned service interruption
  * Reduce quality of service
  * Minimize negative impact of incidents by restoring normal service operation as quickly as possible
  * To identify active and potential causes of incidents - prevent future incidents -proactive



Dev vs Ops

* Dev became faster than ops because of agile
* Testing and deployment were isolated activities done after code-build
* Separate Dev and Ops team timelines did not align well



DevOps team

* About collaborating to quickly develop deploy and support production
*   CICD

    * CI: Automating software build and test
    * CD: Pipeline to build, test and deploy the whole package.



Dev Ops Anti-Pattern

* Assign role of DevOps Engineer ⇒ No point! We are trying to collaborate so that everyone is doing Agile



DevSecOps

* Traditionally, security if an afterthought, and dev team might be disbanded by the time security testing are run and software issues are found.&#x20;
  * Security team finds it hard to understand root causes of software issues.
* Automate core security by embedding security practices and considerations in SDLC.



To start:

* Plan on where, how and where security testing will be done: Jira, Slack, IriusRisk
* SAST/DAST, code analysis, code reviews: Gerrit, PMD, SpotBugs, Copilot
* Build: OWASP Dependency-Check, Synk, SonarQube
* Test: ZAP, BurpSuite
* Release: Ansible, Chef, Docker
* Deploy: Osquery,Chaos Monkey
* Operate: IMperva RASP, Alert Logic



### W2

Software Requirement

* Customers must communicate with the software-building team
* This is a business vs technical side kinda situation
* If  either side dominates the communication, the project loses
  * All about functionalities and time, little to no concern on whether the tech team understand what is needed, or able to deliver by deadlines.
* Hard to predict software projects
  * Requirements, Complexity grows and changes as the project progresses
  * Difficulty to estimate how long thinfs will take



* User story
  * Define things user want from your product
  * "As a (XX user), I want to \[do smth] so that i can \[get to the goal]"



Product Backlog

* Something that is continuously derived and refined from large/existing customer stories.
* Usually describes the features, known issues/defects/research that is related to the product.
* Backlog is something continuously refined



Product Backlog Operations Requirements

* Consider: availability/latency/operational performance -> how much downtime?, scaling, monitoring needs
* Logging: what to log, purposes, and how to proper logging
* Testing needs: dynamic security testing, penetration testing
* Security and compliance: SAST, encyrption, data protection



User Story: Components:

1\) Card - holds the story

2\) Conversation - Detailed requirement (what models, what classes, what teams)

3\) Confirmation - Acceptance criteria



INVEST

* Independent
* Negotiable - flexible implementation choices
* Valuable
* Estimable
* Small
* Testable



Production:

User Testing/Accepting



Business and Technical Stories are the same, stories

* Business stories are dependent.



Story to Epic -> 1 to 1

Technical Story to Epic -> M:1



W3

Snapshots vs Delta-based (Difference) Version Control&#x20;

*



### W3

Component

* A class file/jar file, etc.\


Service

* Uses protocols
* An application outside of core application that communicates with the main application

\
DI can be done on Componenets and Services.



Coupling

* A situation in which a class depends on another concrete class
* Tight coupling: Hard to change/modify



Dependency Injection

* A system design pattern that connects components into apps
* Need for this might not be clear.\

* if we allows class to create dependences, the parents need to change
  * Tight coupling\

* Loosely dependent code
  * Car is not responsible to creating driver type. \


Do your own thing kinda concept



DI implements IOC concept



\>> Makes more things modularised, by injecting anything a concrete class needs; rather than making the class create what it needs.

* This makes the injected dependency open for extension

{% hint style="info" %}
This follows Java's SOLID principles, open/closed principle.
{% endhint %}

:white\_check\_mark: Easier to unit test

:white\_check\_mark: Java Standard under JSR 330

:x: Difficult to read and debug code

:x: Dependence on DI frameworks



Circular Dependency

* Chicken or Egg thing
* The solution is to use a setter injection to bypass the circular dependency





Spring Bean lifecycle

* Set application context, preDestroy, Destroyed
* Spring will manage this for you



Spring Framework

* Component-based software
* Create/Manage beans



SpringBoot

*   Helps to abstract from boiler codes

    * Less monolithic, more microservices
    * More abstraction, more devops



AutoConfiguration/Classpath



Monolithic

:x: Hard to scale everything is bloated\
\


Microservices

* to FrontEnd too
  * Micro front-end ->&#x20;
* Loose coupling



REST/SOAP

* Uses multiprotocols
* Streamable HTTP



HTTP Methods

* Safe -> Will not change the resource
* Idempotent -> Can be called several times with the same results



| Method | Safe | Idempotent |
| ------ | ---- | ---------- |
| POST   | N    | N          |
| GET    | Y    | Y          |
| PUT    | N    | N          |
| DELETE | N    | N          |



Best Practices

* Use correct verbs for actions
* Use only logical nesting for paths
* Return appropriate error codes
* Version your API, and show major only
  * MAJOR.MINOR.PATCH
    * Major ⇒ Breaking Changes
    * Minor ⇒ (99% updates here - does not affect consumers, backend kinda of stuff)
    * PATCH ⇒ Bug Fixes (Changelog - Major Version)



In Spring:

* @Get/Post Mapping
* @ResponseStatus&#x20;
* @RestController&#x20;



GraphQL

* Can specify field, more personalised
  * Order ala carte











