CPSC 3720 Quiz 1

Single Program

couple devs in a garage

used only by the devs

Programming System

dependencies/integration, performance testing

3x the development time as a single program

Programming Product

general usage, testing, documentation

3x the development time as a single program

Programming System Product

product + system needs

9x the development time as a single program

most complex software development programs

Program Diagram

Software Process

a way of breaking down the overall SW development work into manageable sub-tasks

systematic and somewhat formal

Software Development Life Cycle (SDLC)

how to manage the complexity of SW development

SDLC: Requirement Analysis

the WHAT and WHY - understanding what the customer wants and the important features to prioritize

documented in formal ways:

• formal requirement specifications

• wireframes

• use case documentation

• prototypes

SDLC: Requirement Analysis (Validation vs. Verification)

validation - are we producing the RIGHT product?

• assurance that a product meets the needs of the customer

• MORE IMPORTANT

verification - are we producing the product RIGHT?

• evaluation of whether or not a product complies with requirements

Rule of Software Engineering

“Software engineering IS requirement discovery“

SDLC: Define and Design

the HOW - need to understand both the business and non-functional requirements

depending on the type/size of the product, there will be various layers of design:

• system architecture

• deployment architecture

• object/class design

• database design

• UI design

can be documented in various ways depending on the product:

• formal design specifications

• UML/ERD diagrams

• wiki documents

• contract documentation (for APIs)

• data flow diagrams (DFDs)

• whiteboarding sessions

SDLC: Coding

the IMPLEMENTATION

different standard/methods depending on the organization:

• language/tool requirement

• code standards

• code reviews

• international/external frameworks

• unit testing requirements

dev/coding tools:

• version controls/ configuration management (git)

• IDEs

• 3rd party tools

• API development tools

• documentation tools

SDLC: Testing

the QUALITY ASSURANCE - validation and verification of the product

different approaches depending on the organization:

• when to test:

  • unit testing

  • integration testing

  • system testing

  • performance testing

  • regression testing

• how to test

  • test-driven development

  • continuous testing

  • automated/manual testing

SDLC: Testing (Regression Testing)

regression testing - testing new changes don’t break existing code

SDLC: Deployment

process of putting your SW into production for use by the customer

deployment will vary based on the type of SW being deployed:

• commercial “on-premise“ - customer’s IT will deploy the SW

• commercial SaaS - company’s dev/operations will deploy the SW

• internal - company’s dev/operation will deploy the SW

SDLC: Maintenance

fixing bugs in production that are found by customers

deployment model will determine how the maintenance is delivered:

• emergency patch fix

• maintenance release

• major releases

  • - OR -

• continuous deployment (CD)

SDLC Process/Approach Models

classic models:

• waterfall

• v model

• incremental model

• spiral

• rational unified process (RUP)

• …

agile models

• scrum

• kanban

• XP

• lean

SDLC Model: Waterfall

completing the SDLC steps sequentially

• not flexible, rigid model

problem: don’t recognize the Rule of SWE (“software engineering IS requirement discovery“)

Classic SDLC Model Disadvantages

process concerns:

• huge effort during the planning phase

• poor requirement conversion in rapidly changing environment

• treatment of staff as a factor of production

Agile Manifesto

closest definition of the agile model:

• individuals and interactions /over/ process and tools

• working software /over/ comprehensive documentation

• customer collaboration /over/ contract negotiation

• responding to change /over/ following a plan

agile methods consider:

• light-weight

• people focused instead go plan-based

Agile 12 Principles

Agile Scrum in ~100 Words

• process that allows the focus on delivering the highest business values in the shortest time

• allows the focus on rapidly/repeatedly inspecting actual working SW

• businesses set the priorities, and the team self-organizes to determine the best approach

• at the end of each sprint, see real work and decide to release it “as is“ or continue working

Scrum Photo

Scrum Sprints

scrum projects make progress in serous if sprints/iterations

• usually 2-4 weeks or a month (short the better)

product is designed, coded, and tested during the sprint

plan sprint duration around how long the team can commit to keeping change out of the sprint

Scrum Values (5): Courage

courage - to do the right thing and work on tough problems

Scrum Values (5): Focus

focus - everyone’s focused on the work/goal of the sprint

Scrum Values (5): Commitment

commitment - people personally commit to achieving the goals of the scrum team

Scrum Values (5): Respect

respect - scrum team members respect each other to be capable/independent

Scrum Values (5): Openness

openness - the team/stakeholders agree to be open about the work, and it challenges

Scrum Role (3): Product Owner/Manager

product owner/manager

• define the features of the product (iteration scope)

• works with stakeholders/customers and shares the vision to scum team

• accepts/rejects work results and decides release date/content

• responsible for the profitability of the product (ROI)

Scrum Role (3): Scrum Master

scrum master

• responsible for enacting scrum values/practices as a coach

• project management focus

• removes impediments/interferences

• ensures the team is fully functional/productive

• servant leadership

Scrum Role (3): Scrum Team Member/Developer

scrum team member/developer

• responsible for developing the product

• cross-functional: programmer, tester, UX designers, etc

• full-time for the team

• self-organizing

• membership should only change between sprints, but consistency is best

Scrum Artifacts/Frameworks (4): Product Backlog

product backlog

• requirements represented as epics/stories desired for the project

• each item has value to the user/customer

• prioritized by the product owner/manager

• reprioritized at the start of each sprint and used to create the next sprint backlog

Scrum Artifacts/Frameworks (4): Sprint Backlog

sprint backlog

• stories that are chosen to be delivered for that sprint

• stories for a sprint should be “developer ready“

• task breakdown for each story done in the sprint planning ceremony

• sprints are in story points, and tasks are estimated in days/hours

• scrum team will commit to the sprint backlog to be completed in that sprint

Scrum Artifacts/Frameworks (4): Burndown Chart

• tracks the progress of work within a sprint

Scrum Artifacts/Frameworks (4): Impediment Log

impediment log

• scrum master is managing all impediments to the team that is impacting their ability to get work done

• ex.: build server crashes, busy Sr. dev, team member not showing up to standup

Scrum Ceremonies (4): Sprint Planning

sprite planning

• scrum team select items from the product backlog to commit to for the next sprint

• next sprint backlog is created

• high level design is considered

  • tasks are identified/estimated (1-16 hours)

• collaborative, not done alone by scrum master

Scrum Ceremonies (4): Daily Scrum/Stand-up

daily scrum/stand-up

• parameters

  • daily

  • 15-30 mins

  • stand-up

• 3 questions (not a status for the scrum master)

  • what did you do yesterday?

  • what will you do today?

  • is anything blocking you?

• not for problem-solving but to help avoid unnecessary meetings

• anyone can be invited, but only scrum team members/developers, scrum master, and product owners/managers can talk

Scrum Ceremonies (4): Sprint Review (Meraki Weekly Team Meeting)

sprint review

• the team presents what’s accomplished during the sprint

• showing demos of new features

• informal

  • 2 hour prep time rule

  • no slides

• the whole team participates, but anyone can join

Scrum Ceremonies (4): Sprint Retro

sprint retro

• periodically take a look at what is/isn’t working after each sprint

• 15-30 mins

• whole team joins

• discussion

  • start, stop, and keep doing

    • - OR -

  • things the team loved, loathed, learned

Scrum Management

scrum process is usually managed using agile project management tools:

• atlassian products (jira, confluence)

• microsoft azure DevOps

• monday.com

Scrum Scalability

scrum teams usually 7 ± 2 people

factors in scaling:

• type fo application

• team size

• team dispersion

• project duration

The primary measure of progress in Agile is ____

working software

____ is a formal description of the state of the sprint to define when it meets the quality measures required for the prodcut

definition of done

Scrum master if responsible for:

• removing impediments

• coaching the team

Key to agile is that it harness ____ for the customer’s competitive advantage

change

The main roles in scrum are:

• scrum master

• team members/developers

• product owner

What is the most expensive software to create?

programming systems product

Individual developers usually estimate their work as if they were building a:

program

What are some reasons that building software is like a tar pit?

• getting entangled in the complexity

• stickiness of the problems

• the more factors the slower progress becomes

What are some of the coding gaps identified in the article regarding using AI coding copilots?

• corner code cases

• reliability

Example of AI coding assistants:

• copilot

• devin AI

• tabbing

What was identified as a key element in the software creation process when using AI coding assistants?

human collaboratio

T/F: Devin is able to resolve a majority of software issues in Github code repos?

False