Flashcards

ESAS

Josh Vogt English 72 cards

Cards in this deck (72)

1Waterfall - Overview
2Properties of WaterfallGood:
• Managers love waterfall models
• Nice milestones
• No need to look back (linear system)
• Always one activity at a time
• Easy to check progress during development
Bad:
software development is non-linear
• While a design is being developed, problems with
requirements are identified
• While a program is being coded, design and requirement
problems are found
• While a program is tested, coding errors, design errors and
requirement errors are found.
3V-Model
4Spiral Lifecycle
5Spiral Good & BadGood:
• Iterations involve the
customer before the product
is completed
• Reduces chances of
misunderstandings
• Risk management part of
lifecycle
• Project monitoring easy
• Schedule & cost more
realistic over time
Bad:
Iterations 6 to 24 months long
• time for customers to change
their minds!
• Lots of documentation per
iteration
• Lots of rules to follow, hard
for whole project
• Cost of process is high
• Hard to meet budget and
schedule targets
6Rational Unified Process (RUP) Lifecycle
7RUP Phases4 Phases (can iterate)
1. Inception: business case, set
schedule and budget, risk
assessment
2. Elaboration: use cases, SW architecture,
prototype
3. Construction: codes and tests the
product, 1st release.
4. Transition: move to real
environment, get customer
acceptance
8RUP Engineering Disciplines6 disciplines of people over lifetime of project
1. Business Modeling
2. Requirements
3. Analysis and Design
4. Implementation
5. Test
6. Deployment
9RUP Good & BadGood:
• Business practices tied to
development process
• Lots of tools from Rational
(now IBM)
• Tools support gradual
improvement of project
Bad:
Tools are expensive (not
open source)
• Much configuration built in –
increases room for error.
Convention over
configuration
• Only good for medium to
large-scale projects
• Manager's call size of
iterations to make
manageable
10P&D Project ManagerP&D depends on Project Managers
• Write contract to win the project
• Recruit development team
• Evaluate software engineers performance, which sets salary
• Estimate costs, maintain schedule, evaluate risks & overcomes
them
• Document project management plan
• Gets credit for success or blamed if projects are late or over
budget
11Agile Manifesto• Individuals and interactions over processes & tools
• Working software over comprehensive
documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
12Extreme Programming• If short iterations are good, make them as short as possible
(weeks vs. years)
• If simplicity is good, always do the simplest thing that could
possibly work
• If testing is good, test all the time. Write the test code before
you write the code to test.
• If code reviews are good, review code continuously, by
programming in pairs, taking turns looking over each other's
shoulders.
13Shared Nothing (Arch)Database doesn't scale -> use of load balance at each tier
Each app serves one client independently -> self contained
has db master & slave
14Sharding vs. ReplicationPartition data across
independent shards?
+ Scales great
– Bad when operations touch >1
table
– Example use: user profile
• Replicate all data everywhere?
+ Multi-table queries fast
– Hard to scale: writes must
propagate to all copies =>
temporary inconsistency in data
values
– Example: Facebook wall
posts/likes
15The MVC Design Pattern
16Rails Models Store Data in Relational Databases (RDBMS)Each type of model gets its own database table
– All rows in table have identical structure
– one row in table == one instance of model’s class
– Each column stores value of an attribute of the model
– Each row has unique value for primary key (by
convention, in Rails this is an integer and is called id)
17In-Memory vs. In-Storage objectsHow to represent persisted object in storage
– Example: Movie with name & rating attributes
• Basic operations on object: CRUD (Create,
Read, Update, Delete)
• ActiveRecord: every model knows how to
CRUD itself, using common mechanisms
18RESTRepresentational State
Transfer
• Idea: URI names resource, not page or action
– Self-contained: which resource, and what to do to it
–a post hoc [after the fact] description of the features
that made the Web successful
• A service (in the SOA sense) whose operations
are like this is a RESTful service
• Ideally, RESTful URIs name the operations
19Routes
20ModelModels are stored in tables of a relational
database, accessed using ActiveRecord
21RubysFeatures•Object-oriented with no multiple-inheritance
– everything is an object, even simple things like integers
– class,instance variables invisible outside class
• Everything is a method call
– usually, only care if receiver responds to method
– most operators" (like +, ==) actually instance methods
– Dynamically typed: objects have types; variables dont
• Destructive methods
– Most methods are nondestructive, returning a new copy
– Exceptions: <<, some destructive methods (eg merge
vs. merge! for hash)
• {} and () sometimes optional
22Metaprogramming & Reflection• Reflection lets us ask an object questions
about itself and have it modify itself
• Metaprogramming lets us define new code at runtime
23Rails as an MVC Framework
24Rails PhilosophyConvention over configuration
– If naming follows certain conventions,
no need for config files
• Don’t Repeat Yourself (DRY)
– mechanisms to
extract common functionality
• Both rely heavily on Ruby features:
– introspection and metaprogramming
– blocks (closures)
– modules (mix-ins)
25Multiple environments, multiple databases• Rails solution: development, production and
test environments each have own DB
– Different DB types appropriate for each!
• How to make changes to DB, since will have
to repeat changes on production DB?
• Rails solution: migration—script describing
changes, portable across DB types
26Migration Advantages• Can identify each migration, and know
which one(s) applied and when
– Many migrations can be created to be reversible
• Can manage with version control
• Automated == reliably repeatable
• Theme: don’t do it—automate it
27RASPDebugging is a fact of life.
• Read the error message. Really read it.
• Ask a colleague an informed question.
• Search using StackOverflow, a search
engine, etc.
– Especially for errors involving specific versions of gems, OS, etc.
• Post on StackOverflow, class forums, etc.
– Others are as busy as you. Help them help you
by providing minimal but complete information
28Validations vs. Filters
29Behavior-Driven Design (BDD)• BDD asks questions about behavior of app
before and during development to reduce miscommunication
– Validation vs. Verification
• Requirements written down as user stories
– Lightweight descriptions of how app used
• BDD concentrates on behavior of app vs. implementation of app
– Test Driven Development or TDD (future segments) tests implementation
30User StoriesIdea: user story can be formulated as acceptance test before code is written
“Connextra” format:
– Feature name
– As a [kind of stakeholder],
So that [I can achieve some goal],
I want to [do some task]
31Why 3x5 Cards?• Nonthreatening => all stakeholders
participate in brainstorming
• Easy to rearrange => all stakeholders
participate in prioritization
• Since stories must be short, easy to change during development
32Product Backlog• Real systems have 100s of user stories
• Backlog: User Stories not yet completed
• Prioritize so most valuable items highest
• Organize so they match SW releases over time
33Spike• Short investigation into technique or
problem
• Bound the time allotted
• When done, throw code away
34Measuring Productivity• A measure of team productivity:
calculate avg no. stories / week?
• Rate each user story in advance on a simple integer scale
• Velocity: avg number of points / week
35SMART stories• Specific
• Measurable
• Achievable
• Relevant
• Timeboxed
36Specific & Measurable
37Achievable• Complete in 1 iteration
• If can’t deliver feature in 1 iteration, deliver subset of stories
38Relevant: “business value”• Discover business value, or kill the story:
– Protect revenue
– Increase revenue
– Manage cost
– Increase brand value
– Making the product remarkable
39Timeboxed• Stop story when exceed time budget
• To avoid underestimating length of project
40Storyboards• Need to show how UI changes based on user actions
• HCI => “storyboards”
• Like scenes in a movie, but not linear
41Cucumber: Big Idea• Tests from customer-friendly user stories
– Acceptance: ensure satisfied customer
– Integration: ensure interfaces between modules consistent assumptions, communicate correctly.
• Cucumber meets halfway between customer and developer
– User stories not code, so clear to customer and can be used to reach agreement
– Also not completely freeform, so can connect to real tests
42Example User Story
435 Step Keywords1.Given steps represent state of world before event: preconditions
2.When steps represent event
3.Then steps represent expected postconditions; check if true
4. / 5. And & But extend previous step
44Capybara• Tool that pretends to be user to follow scenarios of user story
• Capybara simulates browser
– Can interact with app to
receive pages
– Parse the HTML
– Submit forms as a user would
45Explicit vs. Implicit Scenarios• Explicit requirements usually part of
acceptance tests
– Likely explicit user stories and scenarios: list movies
• Implicit requirements are logical consequence of explicit requirements, typically integration testing
– Movies listed in chronological order or
alphabetical order?
46Imperative vs. Declarative Scenarios• Imperative: Initial user stories with many steps, specifying logical sequence to desired result
– Not-DRY if many user stories imperative
• Declarative: describe state, not sequence
– Fewer steps
47BDD PitfallsDelivering a story as “done” when only the happy path is tested
– Need to test both happy path and sad path
• Correct app behavior when user accidentally does wrong thing is just as important as correct behavior when does right thing
• Careless use of negative expectations
– Beware of overusing “Then I should not see….”
• Careless use of positive expectations
– Then I should see “Emma”
what if string appears multiple times on page?
48Cucumber & RSpec
49TDD: The Big Picture• Test-driven development (TDD)
– step definitions for new story, may require new code to be written
– TDD says: write unit & functional tests for that code first, before the code itself
– that is: write tests for the code you wish you had
50Unit tests should be FIRST• Fast: run (subset of) tests quickly (since
you’ll be running them all the time)
• Independent: no tests depend on others, so can run any subset in any order
• Repeatable: run N times, get same result (to help isolate bugs and enable automation)
• Self-checking: test can automatically detect if passed (no human checking of output)
• Timely: written about the same time as code under test (with TDD, written first!)
51DSLDomain-Specific Language:
- small programming language that simplifies one task at expense of generality
52Seams• A place where you can change app's behavior without changing source code.
• Useful for testing: isolate behavior of some code from that of other code it depends on.
53mock• mock:
“stunt double” object
– verify if a value got propagated correctly
– need a “placeholder” value for code to work, even though test doesn’t depend on that value
54Unit vs. Functional tests in SaaS apps• Unit tests: behavior within a method/class
– collaborator classes are mocked
– collaborator methods may be stubbed out (in this class or collaborator classes)
– both are sometimes generically called doubles
• Functional test: behavior across methods/classes (multiple classes are exercised)
– e.g. controller flow from GET/POST all the way to template rendering, which rspec-rails stubs
– (so not a true full-stack test)
55FixturesStatically preload some known
data into database tables
• Pros/uses
– truly static data, e.g. configuration info that neverchanges
– easy to see all test data in one place
• Cons/reasons not to use
– may introduce dependency on fixture data
56FactoriesCreate only what you need per-test
• Pros/uses:
– Keep tests Independent: unaffected by
presence of objects they don’t care about
• Cons/reasons not to use:
– Complex relationships may be hard to set up
57Kinds of tests
58Stubsstubs are programs that simulate the behaviors of software components (or modules) that a module undergoing tests depends on
59P&D Testing• BDD/TDD writes tests before code
• BDD/TDD starts from user stories
• BDD/TDD developers write tests & code
60P&D Project Manager• P&D depends on Project Managers
• Document project management plan
• Creates Software Requirements Specification (SRS)
• Must document Test Plan
61P&D Approach to Testing• Manager divides SRS into programming units
• Developers code units
• Developers perform unit testing
• Separate Quality Assurance (QA)
team does higher level tests:
– Module, Integration, System, Acceptance
62Limits of Testing• Program testing can be used to show the
presence of bugs, but never to show their
absence!
63Formal Methods1. Human does proof
2. Computer via automatic theorem
proving
– Uses inference + logical axioms to
produce proofs from scratch
3. Computer via model checking
– Verifies selected properties by exhaustive search of all possible states that a system could enter during execution
64P&D vs. Agile
65Scrum•Scrum inspired by frequent short meetings
– 15 minutes every day at same place and time
1. What have you done since yesterday?
2. What are you planning to do today?
3. Are there any impediments or stumbling blocks?
66Scrum roles• Team: 2-pizza size team that delivers software
• ScrumMaster: team member who-
– Acts as buffer between the Team
and external distractions
– Keeps team focused on task at hand
– Enforces team rules (coding standard)
– Removes impediments that prevent team from making progress
• Product Owner: A team member
(not the ScrumMaster) who
represents the voice of the
customer and prioritizes user
stories
67Pair Programming• Goal: improve software quality, reduce time to completion by having 2 people develop the same code
• Driver enters code and thinks tactically about how to complete the current task, explaining thoughts while
typing
• Observer reviews each line of code as typed in, and acts as safety net for the driver
68SAMOSAS• Start and stop meeting promptly
• Agenda created in advance; no agenda, no meeting
• Minutes recorded so everyone can recall results
• One speaker at a time; no interrupting talker
• Send material in advance, since reading is faster
• Action items at end of meeting, so know what each should do as a result of the meeting
• Set the date and time of the next meeting
69SCMSource & configuration management:
• What is it?
– Version (snapshot) code, docs, config files, etc. at key points in time
– Complete copy of every versioned file per snapshot
– Implementation: deltas? complete file copy? symlink?
• Why do it?
– Roll back if introduce bugs
– Separate deployed from development version of code
– Keep separate branches of development
– Documented history of who did what when
– Track what changed between revisions of a project
7040 Years of Version Control
71Gitfalls• Stomping on changes after doing a merge or switching
branches
• Making "simple changes" directly on master branch
72The Five R's• Report
• Reproduce and/or Reclassify
• Regression test
• Repair
• Release the fix (commit and/or deploy)