CSCE 431 Lecture 14

« previous | Tuesday, March 4, 2014 | next »

End Exam 1 content

Exam Review

Software Engineering

Most large-scale software projects are challenged or abandoned:

• over-budget
• behind schedule
• scope reduced

Most "successful" software still has issues

Five Most Common Causes of Software Project Failure

• unrealistic schedules
• inappropriate staffing
• changing requirements during development
• poor quality work
• believing in magic

No Silver Bullet

Fred Bruegge

claim: no individual technology will yield a 10-fold increase in productivity, reliability, simplicity in 10 years (from 1986)

More progress can be made over time.

Software Engineering is a collection of techniques, methodologies, and tools that help with the production of a high-quality software system developed with a given budget bedore given deadline while change occurs.

IEEE: Application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software.

Software Lifecycle

Life of software from idea to deployed and maintained application (e.g. Windows XP "dies" on April 20)

Software Development Process

No-Method

code first

sketch, code, debug, modify, repeat

Waterfall

• Requirements → Design → implementation → verification → maintenance
• Sequential, inflexible, lots of documentation
• Can include some feedback
• Assumes requirements are complete.
• Debugging and Verification are part of development.

V-Model

• testing is a parallel activity to development

Evolutionary

• Prototype, evaluate, then build

Prototype

• prototype, evaluate, repeat until convergence

Spiral

• Iterate through waterfall (6-24 months)
• Generate succession of prototypes / versions
• Continuous assessment of risk
• Most successful approach for safety-critical systems

Agile

• Focus on schedule
• Frequent cycles of code, build, test
• Every build integrated all code from the cycle
  • stable, deliverable, partially-complete system

Features

• Refactoring
• Continuous Integration
• Pair Programming
• Shared Code
• Coding Standard
• Common Workspace
• Customer as part of the team
• Driven by user stories
• Assumes requirements will change during project
• About 50% of requirements should be done when project starts.
• Change only between development cycles
• Documentation and code evolve together
• Document with diagrams (e.g. UML)

Agile Manifesto

• Individuals and interactions > processes and tools
• Working software > comprehensive documentation
• Customer collaboration > contract negotiations
• Responding to change > following a plan

Software Process Maturity

Capability Maturity Model (CMM)

1. Initial: ad hoc; chaotic
2. Repeatable: process at least documented
3. Defined: process is institutionalized or sanctioned by management
4. Managed: quantitative, agreed upon metrics, provide feedback for resource allocation (process itself does not change)
5. Optimizing level: process allows feedback of information to change process itself.

Requirements

Large fraction of software system problems are due to incomplete or wrong requirements

Requirements are statements of desired behavior for a system

Requirements process has two activities:

1. requirements elicitation: definition of system in terms understood by the customer and/or user
2. Requirements analysis: definition of system in terms understood by the developer

Requirements Goals

• Understand the problem(s) that the system should solve
• Prompt relevant questions about the problem and system
• Provide basis for answering questions about specific properties of the problem and system
• Decide what system should do
• Decide what system should not do
• Ascertain that the system will satisfy needs of its stakeholders
• Provide basis for development of system
• Provide basis for validation and verification (especially testing) of the system.

Requirements Components

Domain Properties: assumptions that are true ind the domain

Functional requirements

• What the system should do

Non-Functional requirements

• Reliability
• Security
• Accuracy
• Time/space performance
• Portability
• …

Roles of Domain Properties vs. Requirements

Requirement ($R$): DB shall only be accessible to authorized personnel

Domain Properties ($D$): Authoried personnel have passwords passwords are never shared with non-authorized personnel

Specification ($S$): access to dDB shall only be granted after the user enters an authorized password

$S\wedge D\implies R$

What if domain assumptions are wrong?

Quality Goals for Requirements

• Correct: person paying money decides
• Complete: didn't miss anything
• Consistent: requirements work with each other
• Unambiguous: two people who read requirements should think the same thing
• Traceable: requirement comes from particular user need
• Modifiable: (speaks for itself)
• Verifiable: should be able to check that system meets requirement
• Prioritized: some things have to be there in order for system to "work"

A Balancing Act

• Should not over-specify
• Should not under-specify

Example

Study Naur's Example

Definition of specification: Precise definition of the tasks to be performed by the system

Requirements are a natural-language definition of system objectives

Favor precise, falsifiable language over generalities:

For example: When system encounters an error, it should "recover"

(what does "recover" mean)

Seven Sins of the Specifier

1. Noise: irrelevant information, redundancy, remorse (restriction at use, not definition, of an element)
2. Silence: feature exists, but not discussed
3. Over-specification: specification of a solution to the problem, not the problem.
4. Contradiction: Saying system should do something, and then saying the system should not do that thing.
5. Ambiguity: Multiple interpretations for requirement
6. Forward Reference: referring to something that is mentioned/defined later
7. Wishful Thinking: Feature definition, far which candidate solutions cannot be validated realistically

Complete Requirements

Software Requirements Specification (SRS) is complete if and only if it has following elements:

• significant requirements covered; in particular, external requirements imposed by environment
• definition of responses to all inputs in all situations (both valid and invalid input)
• Full labels and references to all figures, tables, and diagrams

SRS Structure

1. Introduction
2. Overall Description
3. Requirements

Requirements and Agile Methods

→ Under Extreme Programming (XP)

• requirements taken into account as defined at particular time considered
• Largely embedded in test cases

Benefits:

• test plan directly available
• Customer involvement in test development

Risks:

• Change may be difficult (refactoring)
• Structure may not be right
• Tests only cover foreseen cases

Useful advice:

• Retain best agile practices: frequent iterations, customer involvement, centrality of code, and testing
• Disregard those that contradict proven software engineering principles

Techniques for Requirements Elicitation

• Questionnaires: list of pre-selected questions
• Task Analysis: watch how user performs actions
• Scenarios: describe use of system as series of interactions between specific end user and the system
• Use Cases: abstractions that describe a class of scenarios

Use Cases

System treated as "black box" (iterations and responses perceived from outside system)

Capture who (actor) does what (interaction) with system and for what purpose (goal) without dealing with system internals

Complete set of use cases should specify all ways system should be used, bounding the scope of the system.

Written in an easy-to-understand, structured narrative using vocab of domain (Might use UML)

Unified Modeling Language (UML)

http://www.uml.org

Diagrams

• Use case: Describe functional behavior of system as seen by the user
• Class: Describe static structure of system (objects, attributes, associations, etc.)
• Sequence: Describe dynamic behavior between objects of the system (in form of messages and method calls)
• Statechart: Describe dynamic behavior of an individual object as a state machine
• Activity: Describe dynamic behavior of a system, in particular the workflow.

Summary

Goal: describe problem not solution

Variety of sources and means for eliciting requirements.

Variety of definition and specification techniques.

Requirements should be validated , or they meet customer expectations.

Specifications should be verified , or they satisfy the requirements.

Software Configuration Management (SCM)

• Configuration identification
• Configuration control
• Configuration status accounting (recording/reporting)
• Configuration auditing
• Build management
• Process management
• Environment management (hardware/software that hosts the system)
• Teamwork
• Defect tracking

Separate Branches

Separation of concerns

Less contention over repository

Groups commit according to common theme, allowing easier porting or roll-back.

Examples

• Released Versions
• Soon-to-be-released versions
• Ongoing development: Ideas may never actually show up in release, but do not delete the code.
• Features or topics
• Hotfixes: emergency fixes

Branch model "borrowed" from Nvie

Summary

Traditional development has graph-like dependency

Use version control systems to manage code (synchronization and consistency across developers)

Allows roll-back to previous point in code history.

Object-Oriented Design

Recall $S\wedge D\implies R$: the goal with OO-Design: Goal is to come up with design that satisfies the specification

Object-Oriented Analysis

Formalize requirements specification

• exceptional cases, boundary conditions
• clients engaged

Developers build object model of application

Process

Repeat in some order until convergence:

• Identify classes
• Find attributes
• Find operations
• Find associations between classes

Kinds of Objects

Similar to MVC (in that order)

• Entity (keeps data)
• Boundary (handles interactions between user and system)
• Control (tasks performed by system)

Unified Modeling Language (UML)

Sequence Diagrams

• Colmun represents object
  • First = initiating actor
  • Second = boundary object
  • Third = control object managing rest of use case (created by boundary)
  • Others: entities and other controls
  • Entities never access control or boundary obects
• Horizontal arrows (messages or stimuli)
• Vertical rectangle is activation of operation representing time being active; triggered by message
• Time goes from top-to-bottom
• Depicts lifetime with «create» to «destroy»

State Machine Diagrams

• Represents single object's perspective of a behavior (c.f. sequence diagrams, which depict behavior from a single use case)
• cross-check between state machine and sequence diagrams
  • can reveal new use cases
  • can reveal missing states
  • can reveal ambiguities and incoherences

Design Patterns

Subsystem decomposition

Abstraction of machines

• choose middleware
• GUI frameworks
• class libraries
• database engines

Application of domain components

Modularization

Low coupling, high cohesion

• Minimize dependencies: changes are localized
• Maximize unity: modules work well together
• Encapsulation: bundle data and methods, with access protection; enforce invariants
• open closed principle: class open for extension, closed for modification

Liskov substitution principle - subclass can substitute for parent/base class (is this definition correct?)

Derived methods should expect no more and provide no less (pre- and post-conditions, respectively)

Encapsulation

Bundling data and methods with access protection

• Enables object invariants to be enforced

The process of compartmentalizing the elements of an abstraction that constitute its structure and behavior; encapsulation serves to separate the contractual interface of an abstraction and its implementation. Booch

Inheritance

1. Organization (during analysis)
   • Express generalization and specialization in taxonomies in application domain
2. Reuse (during object design)
   • reduce redundancy and obtain extensibility

Structure of Design Pattern

• unique name
• problem description (motivation)
• solution (specification of design pattern)
• set of consequences that describe trade-offs, alternatives, and related patterns

Know at least the following

• Composite ✔
• Observer ✔
• Memento ✔
• Adapter ✔
• Flyweight ✔