Summary Lecture 1-10 (midterm) - Systems Development Methods (INFOB2SOM)
26 views 0 purchase
Course
Systeemontwikkelingsmethoden (INFOB2SOM)
Institution
Universiteit Utrecht (UU)
This summary contains everything you need to know for the midterm exam of Systeemontwikkelingsmethoden (System design methods) (INFOB2SOM). They are based on my lecture notes, and the lecture slides. In case the topics of the course are mixed up in between the exams and you miss something in this s...
Abstract class: class containing (at least 1) abstract method.
Abstract method: method that can only be realized by subclasses, but not by superclasses.
Acceptance test: test if the user accepts the final product
Agile development: development embracing change and flexibility, receiving continuous
feedback
Class: collection of objects with same characteristics (defining a concept)
Code review: Some reviews the code made by someone else
Code smells: code problems indicating bad design
Cohesion: how closely code inside method / object is related
Concern (in requirements): intention or objective of a stakeholder
Control coupling: method tells other method what to do
Controller: subsystem handling events
Coupling: how closely different elements / objects in a program are related
Creator: part of system which creates (new) instances
Daily scrum: 15 minute standup meeting, to plan activities for the coming day.
Data coupling: a method relies on other method output
Definition of Done (DoD): criteria for backlog item to be reached
Development team (scrum): team that delivers product, decides how sprint is performed
Domain-driven design: Designing using independent domain (e.g. User, Order in a webshop
system)
Domain model: representation of a business domain, general description but not technically
Elicitation: Talking to clients / users to gather requirements
Encapsulation: abstraction from internal state of an object
Epic: user story covering large functionality
F.I.R.S.T. principles: Fast, Independent, Repeatable, Self-checking, Timely (testing)
Fake object: behaves as the same as real object, but simplistic
Flaky test: non-repeatable test
Framework: libraries (code) + patterns (structure)
Functional requirement: specifies what the system should do (functionality)
Global data coupling: methods use same global variable
Horizontal scaling: adding more machines (in microservices)
Increment: backlog items that reached Definition of Done during sprint
Information expert: part of system which has certain information
Information hiding: private methods of object are hidden for other objects.
Inheritance: Subtypes inherit all variables & methods from supertype
Inheritance coupling: this is natural, but is worse when superclass depends on subclass
Instantiation: realization of an object (for example, a specific green bike is an instantiation of
the Bike class.)
Integration test: test if components work together
INVEST: assessment checklist for user stories: Independent, Negotiable, Valuable,
Estimable, Small, Testable
Iterative development: development in iterative mini-projects, each one leading to a working
(part of the) system.
, Library: a library of code you can import and use
License: reciprocal contract between user & provider of service / product
Linter: automatic tool for checking code quality
Microservices: architectural pattern with different parts, connected via API. One microservice
is a small autonomous service working together with others.
Mock: test checking if interaction / object calls are properly done.
Monolith: 1 big system with interwoven functionality (opposed to microservices)
Negotiation: prioritizing requirements together with customer (which one is most important?)
Non-functional requirement: specifies system qualities (performance, usability, etc)
Object: state (variables) + behavior (functions)
Pathological coupling: method relies on exact implementation of other method
Product backlog; list with possible options of changes to be made
Product owner (scrum): (ideally) represents customer, manages product backlog, addresses
conflicts
Refactoring: changing internal software structure to make it easier to understand & modify
Reference semantics: assignment of a variable to another variable references to the same
memory address.
Regression test: test that is regularly ran to find bugs after code update
Remote Procedure Calls (RPC): call used by microservices calling each other via an API.
Requirements engineering: process of defining, documenting & maintaining requirements
Responsibility: which class is responsible for this? (in object-oriented design)
Scenario: narrative description of people using the system
Scrum: An agile method of organizing software development process, by organizing into
sprints
Scrum master: scrum expert / coach, ensures team lives up to scrum principles. Is not a
boss, but a servant.
Sprint (scrum): Period from 2-4 weeks, during which a team works on a software part of a
fixed scope. Goal: working software!
Sprint backlog: list of items / tasks the team will be working on during sprint
Sprint planning: planning before sprint, leads to sprint backlog
Sprint retrospective: reflection with team how process went
Sprint review: review sprint with stakeholders, leading to feedback
Stakeholders: entity with interest in a project
Stub object: always returns same response
System test: development team tests entire system
Test-driven development: Write tests first, code afterwards to meet tests
Unified process: iterative software development process with 4 phases, tries to acknowledge
but also minimize change.
Unit test: test if a single code unit works
Use case: documents interaction yielding value
User story: description from user perspective who wants a certain feature
Validation: formal mathematical analysis of requirement
Verification: check if requirement is consistent / complete / accurate
Vertical scaling: adding more power to the current machines (in microservices)
Waterfall model: Linear (not iterative) model of software development process, does not
work in practice
The benefits of buying summaries with Stuvia:
Guaranteed quality through customer reviews
Stuvia customers have reviewed more than 700,000 summaries. This how you know that you are buying the best documents.
Quick and easy check-out
You can quickly pay through credit card or Stuvia-credit for the summaries. There is no membership needed.
Focus on what matters
Your fellow students write the study notes themselves, which is why the documents are always reliable and up-to-date. This ensures you quickly get to the core!
Frequently asked questions
What do I get when I buy this document?
You get a PDF, available immediately after your purchase. The purchased document is accessible anytime, anywhere and indefinitely through your profile.
Satisfaction guarantee: how does it work?
Our satisfaction guarantee ensures that you always find a study document that suits you well. You fill out a form, and our customer service team takes care of the rest.
Who am I buying these notes from?
Stuvia is a marketplace, so you are not buying this document from us, but from seller danielgeelhoed. Stuvia facilitates payment to the seller.
Will I be stuck with a subscription?
No, you only buy these notes for $6.39. You're not tied to anything after your purchase.
