Project management Flashcards
Last part of the software engineering module
Why do software engineering projects fail?
Poor planning
Unclear requirements
Scope creep
Insufficient communication with end client
What is agile software development?
Flexible and iterative process to creating software
What are the core values of agile software development
Individuals and interactions over process and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Why use agile software development
Increase team productivity
Visability
Improve adaptability of code
Business and IT alignment
Collaboration with client
Why might agile not make projects faster and cheaper?
Too much time on prototyping and not working on actual software
Why might agile make projects faster and cheaper?
Working software sooner by iteration
Give three examples of agile software development
Scrum, Kanban and XP
Explain Scrum
Uses sprint cycles where there is a plan for what each sprint will implement
Scrum master defines roles
Changes made at the end of each sprint
Explain Kanban
Kanban board is a list of features to implement
Roles are fluid, project manager is optional
Changes made at any time
Explain XP
Pick a user story, plan, develop, test and release software
Roles are fluid and project manager is optional
Changes made at any time
What is traditional software development?
Rigid and inflexible approach to developing software. Uses top-down heavy approach to development (all planning, developing then testing)
Give two examples of traditional software engineering techniques
V-model and waterfall
What do the software quality assurance team do?
Defining quality
Planning for quality
Checking for quality
Explain how QA team defines quality
Define product and process standards
Give some examples of product standards
Documentation standards
Coding conventions
Class structures
Give some examples of process standards
Defined good practices at each stage of SE process (TDD, paired programming)
Explain how the QA plans for qualty
Identify standards that will be met, recommending quality promoting processes for the project
Explain how the QA checks for quality
Traditional inspection
Fagan inspection
Agile inspections
Explain traditional inspection
Group of 3-7 people finding problems in code
Explain fagan inspection
Inspection to find defects in code through predefined roles in structured meetings
Explain agile inspection
Paired programming, more flexible and informal review of code
Retrospective inspection done at the end of each Scrum sprint
Postmortem inspection done at the end of the project review
What is the problem with inspection?
Criticism of person who build code
People worry their performance will be judged
Don’t properly prepare for inspection
People try to discuss every problem as they find it
What are the advantages of paired programming
- No ownership of code
- Informally spreads good practice among the team
- Reviewing and coding at the same time
- Separate coding and thinking
Why do code conventions help maintain implementation quality?
-Increases the readability of code
-Creates a single style, rather than N peoples different styles
-Defines good practice
Explain 3 main activities that the software quality team manage
Define quality
- Identify product and process standards
Plan for quality
- Identify standards and quality promoting processes for project
Check for quality
- inspections
Explain how the four original values of the agile manifesto are represented in scrum, kanban and xp
Individuals and interactions over processes and tools
- Daily meetings with team to discuss progress, kanban board to show progress, paired program and collective ownership of code
Working software over comprehensive documentation
- Working software always output of every sprint, short iterations with minimal documentation
Customer collaboration over contract negotiation
- Continuous engagement wiht customer in sprint reviews (and QA with retrospective inspection)
Responding to change over following a plan
- Adjusting plans at the end of each sprint, roles are fluid and plans adjust at any point, continuous integration and responding to change
