Software Exam 1

Team Guidelines:
1. Get everyone to work at their best/max capacity
a. No one should be idle
b. Know what all the work to be done is (backlog)
c. Break pieces of work up (smaller is better)
d. May need to teach or bring up to speed team members
e. Dependencies arent an excuse to be idle
2. Worry about yourself. Let the manager reward
3. Dont flip the bozo bit
a. Listen to people
b. Everyone has something to contribute
Key components of software engineering:
1. Solving the problem
2. Producing a high quality solution
Important variables that affect the above:

# of customers
Team size

# of Customers
0
1

Team Size
1
1

>1

>1

>1

Notes
Read your own mind
Cant read the customers
mind. You will
misunderstand the
customer
No such thing as perfect
communication. We
develop tools and
processes to help with
that
Coordination of team
work is critical
Hard to understand all
these customers

Producing a quality solution:

1. Good design
2. Good construction
Is software like homes? Similar but important differences

We have lots of experience with homes even without perfect blueprints

(requirements/specifications). Trades people know how to fill in the gaps.
Software: Every app is different. Difficult to fill in the gaps
1. This design does not work for software (House vs software):

Designer/Analyst/Program manager create detailed specification

Developers build
Quality Test
BRUP -> Big requirements up-front
Reach a shared understanding via documents, talking, whiteboards,
pictures, diagrams (multiple iterations)

2. Home Design is constraint in obvious ways:

Software appears unlimited in what it can do
Home design constrained by area, location etc.
3. Looks cheap to change software Expensive to change a house
4. Everyone works on the house, therefore progress is easily visible.
Its very easy in software to obfuscate and hide your work.
Software is invisible and its easy to not be working on the same code
Documents (For Software):

Vision and Scope document -> common understanding of needs of customer

Software requirement specification:
a. For Agile teams, the SRS may take the form of a collection of user
stores

Traditional Software Phases:

Plan

| Develop |
Requirements
QA
Design

Test and Sip

Code

Agile Process:
Plan -> design, build and test -> deploy (real thing to customer) -> learn
Outline of elicitation of needs (via interviews):
1. Talk/interview stakeholder for vision and scope
2. Have stakeholder review vision scope document and help prioritize scope.
Levels: Must have, good, nice, will not have.
3. To get at full requirements, you need to also
interview/talk/observe/interact/brainstorm/focus group/etc users of the
product (which also may be stakeholders)
a. Observe users doing task today
b. Collect documents about current system/workflow
4. Write up requirements (SRS) and have people review and see if you captured
their needs (and help prioritize)
Basic Interview Process:

1. Team size is 5-7 people

2. Designate a main interviewer but others may talk also, but also willing to
have the strength to end fruitless debater
3. Designate note takers- goal is to capture exact quotes
4. Show up 5 min early. You cant be late. Customer can be late
a. Ask for permission to record interview
5. Introduce everyone using first name
6. Ask if this is still a good time to meet (more for phone interview/skype)
7. Encourage low level detail
8. Capture exactly what person says: VOC. If information is not enough, follow
up with 4W (who, what, when where) and How. NEVER USE THE WORD WHY
9. One person need to have job of checking off questions
10.End by thanking
11.Immediately following meeting, go as group, and each person creates 5-10
stickies that capture user issues/needs brought up in the interview. Must be
full sentences, written in black
Questions for Interview:
1. Framing question for whole interview that captures the primary info goal of
your interview. Ex: What did end users of Firefly websites say we should
improve?
2. 4 main questions to sequence through:
a. Tell me how you currently solve this problem/use the system? Goal: For
what, where, how of their current environment/system operates
b. From your experience, what complaints, problems, or weakness would
you like to mention about your current system?
c. What do you like about the current system?
d. What should we do to address the weaknesses you mention?
Simple version of scrum:
1. Make a poster: To do, in-progress, done
2. Have team come up with tasks that will take 1-2 days or less to do, put each
task on a sticky note in to do column
3. Approximately order tasks from most important and highest value to
customer to least important and lowest value.
4. Each person self-assigns themselves a task (one task) and moves sticky note
to the in-progress column
a. If task is new for someone (never done before), may pair up on task to
do it together
5. As people think of new tasks go ahead and add to the to-do column (in proper
order
6. Some tasks will require verification of completeness, write verification rule on
back of card/sticky. Team members are to verify/check completeness of each
others work before moving task to done
7. Have a daily standup/scrum each day to update board of tasks
Bad approach to task management (common)
1. Manager assigns requirements/features to people
2. Manager determines the time for tasks either by:

a. Doing it themselves
b. Ask employee for time estimate and then says it shouldnt take so long
3. Build a big Gnatt chart
4. Have to chase people for updates

Bad Approach to task management:

1. Manager assigns requirements/featres to people
2. Manager determines time for tasks by:
a. Doing it themselves
b. Ask the employee for time estimate and then say it shouldnt take
so long
3. Build a big Gnatt chart
4. Have to chase people for updates
Scrum:
1. Pick Product Owner: Business person in charge of product and customers.
Determines what has the most value and what is the highest priority
2. Pick team (3-9 people) dedicated to project
3. Pick scrum master
4. Create and prioritize a product backlog
5. Refine and estimate backlog
6. Sprint Planning: What goes into sprint, how to do it (design), break into
engineering tasks
7. Make work visible: Scrum board, burndown chart
8. Daily scrum/standup
9. Sprint review/demo
10.Sprint retrospective
11.Start next sprint
Burn down chart:

Estimate: How much to complete each item in backlog. Example units used to
estimate: Breakdown feature into tasks of approx. same size, story points (Fibonacci
sequence, start with easiest ones), small, medium, large, planning poker
1.
2.
3.
4.
5.

Is the item doable

Enough information to complete item?
Small enough to estimate?
Is there a definition of done that everyone agrees on?
Does it create visible value?

Planning Poker:
1. Each person gets a set of cards with the units on them (1, 2, 4, 8, 13, 15,
etc.)
2. Talk about task
3. Each person puts face down the care that is their estimate
4. Flip over cards
o If all agree, done
o Otherwise, smallest and largest estimates are explained. Redo 3.
Waterfall method

Development process: Goal: Software without defects- quality

1. Establish a shared repository for your code and related files. Version control
system (source control) such as subversion or git.
2. Develop process or automate process by which a build and deployment of the
software can be created, given only the shared repository.
a. A build is a working version of the software
b. A deployment is to install software for use by customers (a website
deployment is a website available for customer use)
3. Developers work using copies of the share repository and they:

a. Make sure their code works before it is back in the repository

b. Provide a way to prove their code works via documented manual or
automated tests
Rules:
1. Repository is always in a shippable (can be built and deployed) state.
2. No one is allowed to break the build, ie prevent a successful build and
deployment or cause existing tests to fail
3. At a minimum, product must be built and tested and deployed atleast once
each day.
a. If build is broken, engineers must stop work and fix
b. Historically, one person a team is the build and deploy engineering
who automates builds, (smoke) tests, and deploys the latest version for
all to see.
Quality Assurance (QA)

Historically separated from dev (today viewed as a mistake)

Not trained in dev, but are maybe bio, chem, pysics majors who know the
scientific process (today a mistake as QA engineers should have the same
capability as devs)
Historically, bug count grows and grows while new code keeps coming in
(bad)
Modern shops:
o Dev must create bug free code
o QA assists dev in how to build tests
o Utilize techniques such as test driven development, pair programming,
or code reviews before code goes into repository

Dividing a software product among team members or teams:

If small project and team, you have the option of having team members pick
a user story or feature and begin work
Any integration issues will be dealt with as you proceed with
Better and more common to divide up work by features or steps of workflow
and then design the interaction between each piece of work
Example: MSCI 240 Kevin Bacon problem
o DFS: Input graph, return component sizes
o Read the file and put graph into adjacency list
o BFS
o Statistics
o Tabulate
o Main