Software Development Methodologies Notes PDF

Week 1 Software Development Processes - Structured software development processes have been established to improve quality, efficiency and predictability in software projects. Traditional - Waterfall - Break software development into linear, sequential phases - Ration...

Week 1 Software Development Processes - Structured software development processes have been established to improve quality, efficiency and predictability in software projects. Traditional - Waterfall - Break software development into linear, sequential phases - Rational Unified Process (RUP) - Iterative traditional method Agile - Extreme programming - Kanban - Scrum Waterfall - Break software development into linear, sequential phases Phases 1. Requirements 2. Design 3. Code 4. Integration 5. System Test Waterfall works well under these scenarios - If the project is small to medium-scope (relatively short duration required) - If the requirements are contractually agreed before development (e.g when outsourcing to vendors) - If the product definition is stable and unlikely to evolve over time - If the industry is regulated (strict compliance with standards in healthcare, aerospace, defence etc) Negatives about waterfall methodology  - Waterfall’s inflexible partitioning of phases makes it less appropriate for projects that involve a lot of uncertainty - Cause maybe the requirements may keep changing so you cannot just follow a linear and sequential approach - Harder to respond to changing customer requirements - Difficult to experiment, which may stifle the team’s motivation - Testing only at the end of the process - Any issues or bugs in the earlier phases (e.g requirements or design) are not discovered until much later, making it more complex and costlier to fix Rational Unified Process (RUP) The RUP consists for 4 phases 1. Inception - Understand what product to build 2. Elaboration - Understand how to build the product 3. Construction - Actually build the product 4. Transition - Validate and deploy the product Inception - Vision document / business case - Develop high-level requirements / use cases - Stakeholder concurrence; identify risks Elaboration - 80% complete use case models - Prototypes for exploring key risks - Development plan; architecture description Construction - Demonstrable prototypes - Working software components - Bulk of coding Transition  - Training end users / maintainers - Evaluate against Inception requirements - Post-mortem project analysis Advantages of RUP - Support for iteration a big advantage over classic waterfall - Forces integration to happen throughout the software development process - Testing can happen as early as the inception stage (Not left until the end) Possible disadvantage - RUP is complex (A lot of process ‘overhead’) - Meaning more time and resources are spent managing the process itself rather than just on development as RUP is structured and detailed and emphasises adherence to specific processes. RUP vs Agile methods 1. RUP is less flexible than Agile - Agile methodologies emphasise flexibility, customer collaboration and rapid iterations with minimal process overhead. - Agile is designed to adapt quickly to changes in requirements and is less rigid in its structure. 2. RUP is iterative but structured - While RUP does incorporate iterations, its structure is more rigid compared to Agile. - Agile processes are more adaptive and allow for continuous feedback and change, which can be more effective in fast-paced or uncertain environments. Agile - Lightweight software processes which emphasise 1. Individuals and interactions 2. Working software 3. Customer collaboration 4. Responding to change OVER 1. Processes and tools 2. Comprehensive documentation 3. Contract negotiation 4. Following a plan Agile Principles 1. Organisational - Put the customer at the centre - Let the team self-organise - Work at a sustainable pace - Develop minimal software - Produce minimal functionality  - Produce only the product requested - Develop only code and tests - Accept change 2. Technical - Develop iteratively - Produce frequent working iterations - Freeze requirements during iterations - Treats tests as a key resource - Do not start any new development until all tests pass - Test first - Express requirements through scenarios Key Characteristics of Agile - Highly iterative and flexible - Working software delivered frequently - Working software (not ‘WIP’ ) is the measure of progress - The key point is that WIP doesn't provide immediate value because it is incomplete and cannot be used by the customer. While WIP is part of the development process, it is not considered a true indicator of progress in Agile. Only software that is complete and functional counts as progress. - Late changes in requirements is not a problem - Close, daily co-operation - VIsualise ‘WIP’ to manage team’s capacity and highlight constraints Extreme Programing (XP) - Code early - Release early - Continuous design Extreme Programming (XP) advocates frequent releases in short development cycles How does XP take good software development practices to a logical extreme? 1. Pair Programming - Good Practice: Code reviews are a common practice to ensure quality and catch errors - XP Extreme: XP takes this a step further by having 2 devs work together (pair programming), leading to immediate feedback and continuous knowledge sharing. 2. Test-Driven Development (TDD) - Good Practice: Writing unit tests to validate code and ensures it works as expected - XP Extreme: In XP, tests are written before the code itself. Every piece of functionality starts with a test, ensuring that the code is always tested and that the development is driven by meeting the test criteria. Four Principles of XP 1. Coding is the core activity - Code doesn’t only deliver the solution - Use it to explore / explain problems too! 2. LOTS of testing during dev - Design unit tests or software contracts first, then code (Test-Driven Development) 3. Developers and customers communicate directly - Programmers must understand the business requirements to design a technical solution 4. Regular refactoring - Continuously improving the structure of the code without changing its functionality. XP encourages devs to refactor code frequently to keep it clean, efficient and easy to maintain. 12 XP Practices Fine-scale feedback - Pair programming - Planning game - Test-driven development - Whole team Shared understanding - Coding standard - Collective code ownership - Simple design - System metaphor Continuous process - Continuous integration - Design refactoring - Small releases Programmer welfare - Sustainable pace Impact of Extreme Concert 1. XP’s influence of agile methods - XP was one of the pioneering methodologies in the Agile movement. 2. Perceptions of XP - Dogmatic - Some people view XP as overly strict because it insists on following its practices very closely. - Consistent - Others see this strictness as a strength. They argue XP provides a clear, consistent approach to programming that, when followed correctly, leads to high-quality software.  3. XP’s legacy in the industry - Projects should integrate code all the time - Tests are a KEY resource, and should be run against code often 4. Integration with other processes - XP practices like Test-Driven Development (TDD) can be integrated with other software development processes. (e.g. scrum) Kanban - Visualise a team’s WIP (Work-in-Progress) on a Kanban Board to help track workflow and identify constraints - In the Kanban Process, a single board is used continuously throughout the whole project - Work-in-Progress (WIP) doesn’t deliver value until deployed - Focus should be on moving tasks through to completion as efficiently as possible, rather than just having a lot of work started but not finished - Limiting / Minimising WIP makes it easier to identify inefficiencies and constraints in a team’s workflow - Forces the team to focus on completing tasks before starting new ones, which generally leads to higher quality and faster delivery. - Kanban boards clearly visualise WIP and match to team’s capacity - Simple, but effective approach to help teams coordinate Scrum - Scrum is lightweight, iterative software process - The iterations are structured in 2-4 week sprints, which are designed to foster collaboration, accountability, and continuous improvement. Product Backlog - A product backlog is a prioritised list of features that: - Will deliver an overall product goal - Adds value to the customer - Is Estimated (i.e amount of effort required) - It mainly contains items that bring direct value to customers - Features expressed as User Stories - It can also contain items that bring indirect value to customers - Enhancements and fixes - Infrastructure set up (e.g Git repository, CI/CD pipeline) - It does not contain low-level tasks - E.g ‘send email to Rajesh’ , ‘implement PersonDAO class’ - It is created / groomed by the Product Owner - It is a living document that continuously evolves through the projects Scrum Team 1. Developers - Design, code, test, and integrate the software product - Deliver high-quality shippable software increments - Self-organised and cross-functional - Pace development in a sustainable manner 2. Scrum Master - Facilities scrum meetings (standups, review, retros) - Removes impediments / blockers - Facilitates mentorship and conflict resolution - In small teams, may also development tasks 3. Product Owner - Identifies and re/prioritise product features (user stories / enhancements) - Writes user stories and grooms the product backlog - collaborates with stakeholders (e.g customer) - Validates product increments after each sprint Scrum Master can be Developer Product Owner can be Developer Product Owner CANNOT be Scrum Master Sprint Backlog - The sprint backlog lists the product backlog items (e.g user stories) to be completed in the current sprint.  - List of user stores is typically frozen for the duration of the sprint - Helps the team stay focused on the tasks on hand, without the distraction or disruption of new or changing requirements. - The stories are associated with one or more implementation tasks - Each user story in the sprint backlog is broken down into smaller, actionable implementation tasks. - These tasks could include setting up a database, writing front-end code, creating tests, writing documentation, etc. - The tasks are places on a scrum task board (similar to kanban board) to visualise progress - Updated by team during stand-up meetings - Monitored by Scrum Master - If WIP is stagnant, it's a warning sign. Scrum Taskboard Difference between Scrum and Kanban Week 2 User Story - A user story is a brief, simple description of a feature or functionally from the perspective of the end user Format for User Stories Examples of User Stories Benefits of describing features as user stories 1. User stories use non-technical language to provide context for the whole team 2. User stories put end users (customers) at the centre of the conversation 3. User stories convey the value of the feature which helps with prioritisation (maybe for choosing what features to work on during a scrum sprint) 4. They facilitate a conversation Acceptance criteria - Boundaries of the story - Define the conditions that must ALL be met for a user story to be considered complete - Can be used to check if the story is ‘done’ - Should be clear, but not overly specific - They should be measurable / testable Acceptance criteria can be written in 2 ways 1. Checklist-based AC - Concise and faster to write (more agile) - Useful when the requirements are simple and do not involve complex user interactions - Less can be more! (leaves scrum-team to decide on the details) 2. Scenario-Based AC - It can be helpful to elaborate on ACs using the given-when-then format. - Condition (given) triggers event (when) resulting in a outcome (then) - Useful when the requirements are complex or involve multiple user journeys - Useful when it’s important to understand the system behaviour across different conditions A good user story card satisfies 6 attributes (INVEST) 1. Independent - Ensure user stories are as independent as possible - The effort required for each story can then be estimated and selected for inclusion in a Sprint without regard for any other user stories 2. Negotiable - User stories are not set in stone when first written - They should be open to discussion and refinement until the start of the SPrint. - Once the Sprint begins, user stories become fixed until the Sprint is completed 3. Valuable - User stories should be valuable to the person whose perspective the user story is written in. - Valuable in the form of increased efficiency, improved experience, cost savings etc. - Example - As a subscriber, I can be alerted to my unpaid bills, so I can pay punctually and not be charged the penalty - This user story provides value to the subscriber by potentially saving them from penalty charges 4. Estimable - User stories should be clear enough so that developers can reasonably estimate the required effort - User stories may be unclear when - Developers lack domain knowledge - Developers lack technical knowledge - User story is too big 5. Small - Cannot be too big because cannot fit within a sprint - Break into smaller stories - Cannot be too small cause it might cause inefficiency or lack functional value - Club them up to modular size 6. Testable - There must be a clear set of acceptance criteria for what success looks like and the means to test the criteria - E.g The screen must not take too long to appear (untestable cause what is too long) - The screen must appear within 2 seconds (testable due to quantitative metric) Epics - Large stories that represent a broad objective or significant piece of functionality - Use epics are a placeholder on the product backlog until they are ready to be replaced by (multiple) INVEST-able user stories - Epics can also be used to help organising user stories 2 ways to use epics 1. Grouping user stories together to organise user stories 2. Use as a placeholder on the product backlog, when you finally decide to tackle it, break it down into multiple user stories User story mapping - Story mapping is a technique that provides the big picture that a pile of stories so often misses - So like map the user stories to like epics, themes and sprints Right-sizing your user stories - Suppose your user story violates the “S” of INVEST - Splitting it into smaller user stories will give us more freedom for planning - Apply splitting patterns to split a user story A good product backlog should be 1. Detailed approximately - Top priority items are more fine-grained and detailed than lower priority items 2. Estimated - The items for the current release need to have estimates 3. Emergent - The product backlog should be regularly refined. Items may be added, removed, modified, split or changed in priority so the backlog is continuously updated by PO to reflect these changes 4. Prioritised - Items at the top of the product backlog are prioritised