Software Process Flashcards
Documentation: Specification
- business objectives
- mission statements
- requirements themselves
Documentation: Validation plans
- test plans
- risk assessments
Documentation: Design Documents
- design plans
- system architectural plans
- implementation plans
Documentation: Deployment/Evolution
- Deployment/Ops plan
- Maintenance strategy
Traditional Approach: Waterfall
Requirements -> Design -> Implementation -> Verification -> Maintenance
- cons:
no stepping backwards
no realizing your mistakes to later
- cons:
- pros:
clarity between steps and teams
- pros:
Traditional Approach: Spiral
four main stages:
- Planning: Gathering and analyzing requirements.
- Risk analysis: Identify sources of risk and mitigation strategies.
- **Engineering: The system is built and validated.
- Evaluation: **System is validated externally with customers to inform future iterations
Pros/Cons
- was a direct response to waterfalls inadequacies
- aims to address risk by checking with the customer in validation
cons:
- effectively documenting the risk analysis process can be overwhelming
- waiting a year for feedback can slow down the process
AGILE MANIFESTO (4 main points)
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
- **main goal: **increased customer interaction and accountability
increase velocity by decreasing the amount of time developers spend on the wrong thing
Agile Approaches: XP Overview
- all about having a buildable system at all times
- start small and then build more based on feedback
- bottom up system
**5 key principles
**
- communication
- simplicity
- feedback
- courage
- respect
XP: Communication
Communication: Enabling open and continual communication between all stakeholders can help projects stay on track and make sure that all stakeholders are aware of the schedule impact various alternative decisions could have.
XP: Simplicity
Simplicity: By focusing on the simplest possible solution, engineers are able to validate their work with customers before tackling more expensive or challenging solutions.
XP: Feedback
Feedback: Software is not developed in a vacuum, by combining feedback from tests, customers, and the team, more knowledge can be applied to ensure the most locally ‘correct’ decisions are being made.
XP: courage
Courage: Be willing to discard failed experiments. An experiment is not a sunk-cost, but rather an opportunity to learn and improve the overall system.
XP: Respect
Respect: The focus on a system always being executable means that committing changes that ‘break the build’ is unacceptable as it slows down your teammates and hurts velocity. Respect also means focusing on the long-term understandability of your code by respecting the time a future developer would have to invest in understanding how your code works.
TDD Steps
1) Add a test:
to build controllable and observable code from the start
shifts emphasis to API signatures from body of functions
2) Run tests to ensure they fail
important to know pre refactoring
failing tests are expected fails
3) Write code/run tests
code is written so that tests can be made to pass
4) Refactor the code
once there re passing tests, refactor as needed to make improvements
Scrum Specific Roles (3 roles)
**Product owner: **
- defines product features and helps to prioritize features according to their value to the team.
- Establishing meaningful prioritization
- particularly important during sprint planning.
**Scrum Lead: **
- The scrum lead (a role formerly known as the scrum master) often works to shield the team from external interference and helps resolve problems that may be blocking the product. The Scrum lead is not the manager of the team.
**Team: **
- Scrum-based teams are typically diverse and cross-functional containing designers, managers, engineers, clients, and test specialists.
- Teams are usually between 5 and 9 people.
Broad Ceremonies in Scrum
- ** sprint planning**
- pre sprint
- product owner describes/motivates highest priority user stories
- team probes to understand task at hand
- technical team builds an estimated timeline for for each task
decides which ones will take place during thai sprint or future - standup meeting
- during sprint teams meet daily
- only those directly involved speak in these scrums
- outline: challenges, blocks
- stay up to date with technically interacting pieces
- sprint review
- review to demonstrate features
- opportunity to make sure activities are working
- start doing, stop doing, continue doing etc
Kanban
- pull based software process
- emphasizes continuous delivery and flexibility
- make use of agile boards to visualize
Common Kanban Board Columns
-
backlog: all available work
- doing: work currently being performed -
review: ready for sharing/review by team
-** done: **reviewed and completed work
Scrum vs Kanban
- while scrum focuses on delivering small deliveries every spring Kanban tries to reduce that further
- any time something moves to “done” it can be shipped rather than waiting until end of sprint
- those who prefer Kanban found Scrum too rigid and limiting
- both leverage daily stand up meetings
2 specification requirements
-
functional requirements:
what the system must do
describes a feature the system must have
-** non-functional requirements:**
requirements the system must have
quality attributes
ie: system should be usable
4 Specificaiton Considerations
-** Complete: A spec that does not completely describe the requirements provides opportunities for misunderstanding between stakeholders.
- Consistent: **Conflicting requirements also generate misunderstandings that can make knowing the right behaviour impossible to understand.
- **Precise: **Natural language is inherently imprecise while source code must be precise for the computer to be able to interpret it. This disconnect, and the fact that specs cannot be automatically validated, means imprecise language can further complicate understanding intended behaviour.
- Concise: While the above points seem to say that “more is better” when it comes to specifications, having “more” also provides more space for imprecision and inconsistency to become problems.
Validation Requirements
- it should be possible to validate that all requirements have been met, and that their implementation is correct
- In situations where validation is not easy (or even possible) the requirement is often restated in more concrete terms.
- ie a focus on being measurable
helps define “done”
role-goal-benefit
“As a < stakeholder > I want < function > so that < value >.”
User Story Format
**(usually) start with 1-3 sentences describing:
**Role - goal - benefit.
ex:
“As a <stakeholder> I want <function> so that <value>.”</value></function></stakeholder>
**a series of notes that describe:
**
- limitations
- clarifications
- **crucial: **definition of done
- helps them to avoid working unnecessarily on extra functionality the stakeholder might not need
**any specific engineering notes:
**
- key interactions of the feature with other parts of the system
- constraints the implementer must keep in mind
- problem domain: role-goal-benefit & definition of done
written from the client and users perspective
NOT written in solution domain
effort estimate
fibonacci sequence used when assigning a point value to stories to reflect the fact that the larger the story the worse we will be at estimating it
INVEST GUIDELINES USED TO ASSESS USER STORY
** Independent:** Stories need to be independent and self-contained, so they can be reordered and implemented as needed.
Negotiable: Choosing which stories are performed in the next iteration needs to be a negotiable activity. This also allows the product owner and technical team to ask more questions that flesh out the story and provide greater detail as needed.
**Valuable: **Being clear about the value of a story is important; most stories are not valuable to all stakeholders, but being able to have this conversation explicitly makes negotiating the relative benefits of various stories possible.
**Estimatable: **If a story lacks sufficient detail to evaluate its feasibility (and how long it will take) more specification work is needed. One of the cornerstones of user stories is they make reasoning about tasks and maintaining schedules tractable; if a story cannot be estimated it will not work in practice.
**Small: **User stories tend to describe features that take between half a day and half an iteration in length. Longer stories should be split up to reduce the chance of a story not making it in an iteration and so that future work on the story can be negotiated in the subsequent work period.
Testable: The definition of done is fundamentally important so all stakeholders understand the ways in which the story will be evaluated. This brings quality concerns to the forefront before development even starts and encourages that features be built in a verifiable manner.
Automation Action Sequence
change code -> get code & dependencies -> build -> run tests -> deploy
(important: all of these also point “feedback” back to “change code”)
Goal of Automating
-** Repeatable: **The process of building a product should not vary between different versions of the software (modulo minor improvements over time).
Reliable: If the build process was repeatable but was subject to many non-determinstic failures it would not have value. Being able to trust that the repeatable process will run to its successful completion is crucial
**Revertible: **The build process should make it possible to quickly and transparently revert out of any change.
Automatable Units (7)
Source control: Every software team uses version control to track their source code resources (and other assets including any automation tools themselves).
**Dependency management: **code uses libraries and frameworks. Dependency management solutions provide a means to reliably procure software required for the build process. (ant, mvn, npm, and yarn)
**Build tools: **Compiling the code into shippable units (be they libraries or actual executables) is the next step
**Analysis tools: **linting tools commonly validate changes to ensure that common mistakes that have shown to lead to defects. Or tools for security checkers to ensure that security policies (like not checking tokens or passwords into version control) are being followed. Or like checkstyle for consistent style
**Test tools: **Tests are code too, so enabling them to be written with as little boilerplate code as possible is important for reducing the costs of automated testing. Many unit test tools in particular have been developed to help software engineers write tests and form them into coherent test suites quickly. These tools include jUnit, NUnit, or mocha.
Test runners: Once test suites have been developed they must be run in a repeatable way. While this can take place on the engineer’s development machine, tests are often run on a common infrastructure to increase the consistency between test runs for all developers. Tools like Jenkins, Bamboo, and TravisCI all work to execute test suites remotely. These first five steps are often called continuous integration.
Deployment: In the online realm software must be deployed once it is built; this field (often referred to as continuous deployment) is beyond the scope of this reading.
Feature Flag Applications
**Canary Deployments: ** Trial new features on small user subsets to validate performance before broader rollout.
**A/B Testing: **Compare different feature versions simultaneously while ensuring user fairness.
Chaos Tools
Tools like Netflix’s Chaos Monkey intentionally stress systems by simulating failures to validate recovery strategies in complex environments.
Package Verioning Overview
Semantic Versioning (SemVer):
Uses the format MAJOR.MINOR.PATCH
each part is an integer that can only be incremented
leading 0s are not permitted, unless the part is actually 0 (ie. 1.02.2 is INVLAID and 1.0.2 is VALID)
Version Components:
MAJOR: Indicates breaking, incompatible API changes that can disrupt clients.
MINOR: Adds new features and APIs without affecting existing functionality.
PATCH: Applies bug fixes without impacting clients.
Package Versioning: Pre-release & Suffixes
- When the MAJOR version is 0, a package is considered pre-release and any version change should be treated as a breaking change
- It is common to add a suffix after the PATCH version, separated by a +, for example 2.12.7+20251123. These suffixes are often used to capture new builds that do not necessarily even contain changes that reach the threshold of a PATCH
Upgrading: MAJOR, MINOR, PATCH
- MINOR and PATCH upgrades are safe as they maintain backward compatibility.
- MAJOR upgrades risk breaking changes and should be approached with caution.
Downgrading: MAJOR, MINOR, PATCH
- Downgrading PATCH versions is generally safe.
- Downgrading MINOR versions can be acceptable if new APIs haven’t been adopted.
- Downgrading MAJOR (and sometimes MINOR) versions is risky and generally avoided.
Upgrade Policies in Metadata
- ”^” (e.g., “^7.1.1”) permits MINOR and PATCH updates.
- ”~” (e.g., “~5.3.2”) restricts updates to PATCH versions only.
- An exact version (e.g., “10.0.2”) requires that specific version.
