CS 345 Philip Riley JMU Software Engineering Test 1 (GUARANTEED "A" BABY) - help from Kyle Vinsand

Activity Diagram

Allows you to specify how your system works. Shows high level actions chained together to represent processes.

Activity

An Activity a process being modeled

Action

An action is a step in the overall activity.

What is the difference between an Action and an Activity?

An Activity is a process being modeled, while an action is a step in the overall activity.

Initial Node

Start point of the diagram represented by a filled circle

Software

Sequence of instructions executed on a computer

Program

Any piece of software that can run on its own

Library

Group of related sub-programs

Process

Collection of related actions that transforms a set of inputs into a set of outputs

Software Requirements Specification (SRS)

States the required behavior and appearance

Software design document (SDD)

Complete software specification

Prototype

Working model of some or all of a finished product

Throwaway prototype

Made to help nail down specifications, then is discarded

Evolutionary Prototype

A prototype that is modified into a working product

Waterfall Life Cycle Model

A process that goes down a list of steps not incrementing or going back, except for to maintain for a finished product

Pro: Very well planned

Con: No going back

Lots of documentation

Likely to result in a failed product

Spiral Model

Completely focused on risk management. Very general and adaptable.

Con: People are not good at risk management or tailoring software processes

rational unified process (RUP) methodology

Pros:

Fully specified and comes with templates, checklists and another process aids (Risk Management)

Adaptable to different projects

Incremental (Lessen the risk of project failure)

Iterative (Work is easier to schedule and monitor)

Cons:

Very Complex and requires experienced and knowledgable developers

A lot of documentation and management effort(Heavyweight process)

Requirement change is not well supported

Agile Process Models

Pro:

Product Specs can be changed frequently

Deliverable is sent to customers shortly after development begins

Bad projects can be recognized and ended early

Very lightweight

Waste & duplication are greatly reduced

Cons:

Customers and users must be involved throughout development

Working incrementally could degrade product quality and increase effort

Difficult to use on large projects

Harder to predict outcomes

Quality

Ability of a product to meet the needs and desires of its stakeholders

Stakeholder

Anyone involved or potentially affected by the product

functional suitability

the degree to which the product satisfies user needs

Performance efficiency

A measure of input that describes how well resources were used in completing an objective

Compatibility

the degree to which the product can coexist and interoperate with other products

Usability

The degree to which a system is easy to learn and efficient and satisfying to use

Reliability

The degree to which a product performs specified functions under specified conditions

Security

the degree of protection against criminal activity, danger, damage, and/or loss of confidentiality

Maintainability

the degree to which the product can be modified, improved, corrected, and adapted, and components of the product can be re-used

portability

Ease with which a product can be made to operate in a new or altered computing environment

Quality Assurance (QA)

To achieve and maintain quality

Validation

Are we building the right product?

Verification

Are we building the product right?

Defect

Something undesirable in a product

Defect elimination

Find and remove defects

Defect prevention

Avoid defects through good products and practices

Design Patterns

customizable solutions to design problems

Readiness check

Moderator ensures the product has been through all of the reviews and any defects have been corrected

Overview meeting

Author introduces and distributes the work product to the rest of the team

Preparation

Each inspector reviews the work product individually

Team Inspection

The reader guides other inspectors through the work product

Correction

Moderator provides the results of the inspection to the author, then corrects them

Follow-Up

Moderator insures that the defects are corrected

Moderator

Schedules and runs meetings

Organizers and distributes the materials to be used

Monitors follow up activities

Author

The meeting participant of the inspected work product

Reader

The one who guides team meetings

Recorder

Takes notes during inspection meetings

Inspector

Checks work product beforehand and helps find defects during the meeting

Trigger

Condition that causes a fault to result in a failure

Software Testing

process of identifying failures by creating "inputs" and applying them to the software product

Debugging

Process of using trigger conditions to identify and correct faults

Sprint Planning

Perform regular backlog refinement

Test driven design

Write tests first, then code

Continuous Integration

Ensure code always passes the tests

embedded QA analyst

Short test / fix cycle

Sprint Review

Show up product to stakeholders

Requirements

Property or behavior something must exhibit

Specification

Precise description of something

Requirements Specification

a precise description of properties or behaviors that something must have

Types of Stakeholders

Customers

Users

Clients

Developers

Regulators

Marketers

Stakeholder Needs

Inconsistent, incomplete, abstract and incorrect (Lack of understanding)

Functional needs and requirements

What a product is supposed to do

Nonfunctional needs and requirements

Tells you how the product will do what it does

Levels of Abstraction

Business Requirements

User Requirements

Operational Requirements

Physical Requirements

Traditional Requirements

Traditional Process Requirement

Clear

unambiguous

testable / verifiable

traceable

atomic

identifiable

Elicitation

Interviews

Observation

Focus group

Workshops

Prototypes

User Story

Description of a function a product must provide for a user

Redefined into sprintable stories

Epics

Larger scope, more abstract and less specific than user stories

Redefined into user stories

Too big to deliver in a sprint (supports Agile principles)

Sprintable Stories

User stories small enough to implement during a sprint

Theme

Collection of stories by category

An epic can be a theme

Task

Elements of a story (Steps to finish a sprintable story)

SMART

Specific, Measurable, Attainable, Realistic, Timely

Acceptance Criteria

A set of conditions that is required to be met before a user story is accepted

Three C's of user stories (Agile)

Card

Conversation

Confirmation

Rule Oriented

In the form of a list

Scenario Oriented

In the form of scenarios that illustrate each criterion

Scrum

Specifies a high level process consisting of activities that create and modify certain artifacts

Backlog Grooming

Break down high priority items

Done regularly

Scrum Roles

Product Owner

Scrum Master

Team Members

Product Owner

Responsible for deciding what will be done in what order

Scrum Master

Responsible for guiding the team and following the scrum development process

Team Members

Responsible for deciding how to build the product and for actually building it

Scrum Artifacts

Product Backlog

Sprint Backlog

Shipable Product

Product Backlog

A prioritized list of unimplemented product features or characteristics (Elements are product backlog items [PBI] )

Sprint Backlog

Collection of PBI's, the task needed to complete them, and estimates of how much effort each task will require

Potentially Shippable Product

A product increment that could actually be shipped to customers

Sprint Retrospective

After the sprint review, the team discusses what went well, what did not, and how the next sprint can be improved

Once the retrospective is done, the current sprint is closed and the next sprint begins

Priority

Determines when the PBI will be implemented

Set by Product Owner with feedback from stakeholders and the team

Story Points

Unit of relative effort

Velocity

The amount of work completed by a team in a sprint

Burn chart

a graphic whose vertical axis is work (in person-effort units or story points) and whose horizontal axis is time.

Burndown Chart

Shows the cumulative work remaining in a sprint based on time

Burn-Up Chart

A chart that shows how much work has been accomplished

Daily Scrum

A short meeting in which the team shares what they did since the last meeting, and what they're going to do today, and if they have any impediments

Interaction Design

Concerned with specifying the user experience for a software product

Dimensions of UI Quality

Effectiveness

Efficiency

Safety

Learn-ability

Memorability

Enjoy-ability

Beauty

static interaction design model

Depicts the visual and oral features of products that do not change during execution (UI)

Dynamic interaction design model

Depicts product behavior during execution (UX)

User Experience (UX)

How you go from one place to the other

User Interface (UI)

Aesthetic / static parts

Use case

type of complete interaction between a product and its environment

Actor

Type of agent that interacts with the product