Software Process Flashcards

Question

INVEST GUIDELINES USED TO ASSESS USER STORY

Answer 1

** 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.

Answer 2

change code -> get code & dependencies -> build -> run tests -> deploy (important: all of these also point "feedback" back to "change code")

Answer 3

-** 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.

Answer 4

**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.

Answer 5

**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.

Answer 6

Tools like Netflix’s Chaos Monkey intentionally stress systems by simulating failures to validate recovery strategies in complex environments.

Answer 7

**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.

Answer 8

- 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

Answer 9

- MINOR and PATCH upgrades are safe as they maintain backward compatibility. - MAJOR upgrades risk breaking changes and should be approached with caution.

Answer 10

- 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.

Answer 11

- "^" (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.

Software Process Flashcards

(35 cards)