Software Exam 1

Team Guidelines:

1. Get everyone to work at their best/max capacitya. No one should be idleb. 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 memberse. Dependencies aren’t an excuse to be idle

2. Worry about yourself. Let the manager reward3. Don’t flip the bozo bit

a. Listen to peopleb. Everyone has something to contribute

Key components of software engineering:

1. Solving the problem2. Producing a high quality solution

Important variables that affect the above:

# of customers Team size

# of Customers Team Size Notes0 1 Read your own mind1 1 Can’t read the customer’s mind.

You will misunderstand the customerNo such thing as perfect communication. We develop tools and processes to help with that

1 >1 Coordination of team work is critical

>1 >1 Hard to understand all these customers

Producing a quality solution:

1. Good design2. 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 gaps1. 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-frontReach 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. It’s 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 | Test and Sip

Requirements Code QADesign

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 scope2. 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 todayb. 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 people2. Designate a main interviewer but others may talk also, but also willing to have the strength to

end fruitless debater3. Designate note takers- goal is to capture exact quotes4. Show up 5 min early. You can’t be late. Customer can be late

a. Ask for permission to record interview5. Introduce everyone using first name6. Ask if this is still a good time to meet (more for phone interview/skype)7. Encourage low level detail8. 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 WHY9. One person need to have job of checking off questions10. End by thanking11. 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 operatesb. 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, done2. 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 column3. 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

columna. 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 order6. Some tasks will require verification of completeness, write verification rule on back of

card/sticky. Team members are to verify/check completeness of each other’s 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 people2. Manager determines the time for tasks either by:

a. Doing it themselvesb. Ask employee for time estimate and then says it shouldn’t take so long

3. Build a big Gnatt chart4. Have to chase people for updates

Bad Approach to task management:

1. Manager assigns requirements/featres to people2. Manager determines time for tasks by:

a. Doing it themselvesb. Ask the employee for time estimate and then say it shouldn’t take so long

3. Build a big Gnatt chart4. 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 project3. Pick scrum master4. Create and prioritize a product backlog5. Refine and estimate backlog6. Sprint Planning: What goes into sprint, how to do it (design), break into engineering tasks7. Make work visible: Scrum board, burndown chart8. Daily scrum/standup9. Sprint review/demo10. Sprint retrospective11. 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. Is the item doable2. Enough information to complete item?3. Small enough to estimate?4. Is there a definition of done that everyone agrees on?5. 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 task3. Each person puts face down the care that is their estimate4. Flip over cards

o If all agree, doneo 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 repositoryb. 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 fail3. 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 fixb. 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 codeo QA assists dev in how to build testso 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 sizeso Read the file and put graph into adjacency listo BFSo Statisticso Tabulateo Main