SW Engineering
Aug. 28, 2013

Last time
  Covered what is SW engineering.
    Building quality software on a budget (time & money)

  Problems are in the details
    -hard to assess quality
    -communication and intelligence are key in building software
    -high cost in power because time spent thinking, designing, and coding 
     is not cheap
    -build smart to build cheap

  This semester we will focus on
    -Domain analysis
    -Requirements Gathering
    -Design
    -Implementation
    -Small portions on testing

  Next semester we will focus on
    -Implementation
    -Redesigning
    -Agile Methods
    -Project Management

  Software Crisis
    -problems with
      -communication
      -teamwork
    -solutions
      work together
        agile, scrum, xp
      use proper tools

Types of software
  -Custom, generic, or embedded
  -Real-time vs. data processing
    -hard vs soft

Stakeholders - people who have roles in a SW project

  Have different motivations or agendas

  Users - self explanatory
    Some could be replaced by SW
    Some could have their job or responsibility changed because of SW
    Some may have easier job because of SW

  Customers - decide what they want in SW
    Developers/Dev. Managers get info from them
    May have goals, e.g. increase profit, decrease manpower

  Developer - writes and maintains SW
    Often has specific role
      DB Manager, Requirements gathering, technical writer, config. mgmt., etc.
    Goal: work on interesting project

  Dev. Manager - may run all or part of a SW team/group/company
    May have business training
    Wants customer or client to be happy
    Must have good communication with the client

SW Quality has many attributes and different meanings for different people
  Usability - how easy is the software to use
  Efficiency - how much resources are used
    -CPU Time    -memory
    -Disk use    -bandwidth
  Reliability - few failures/lots of uptime/"it just works"
  Maintainability - ease of change/maintenance
  Reusability or portability - how easy to use on different systems or for different tasks

Quality Trade-offs
  efficiency of use vs. ease of use/understanding
    vi vs. nano
  reliability vs. efficiency (speedup)

  Important to determine client objectives!
  Different people may have different definitions of quality.

So far the discussion has been about external quality
  external quality - what the client can see.

  internal quality - includes code components and complexity

    can be measured using metrics
    Examples:
      comment ratio to lines of code
      complexity - branching/nesting depth, etc.

    metrics can be both good and bad

SE Projects - divided so teams can work on them
  Many categories

  Greenfield - building a project from scratch
  Evolutionary - building on an existing system (maintenance)
  Building on a framework - new system from existing components

  Lots of types of evolutionary projects.
    Corrective - fix defects (issue tracking)
    Adaptive - change system in response to environment
      (tax software)
    Enhancement - add new features (Windows)
    Re-engineering - make system internals more maintainable
      (OS versions)

Common to all SW projects
  Requirements and Specification

    Understand what the client wants/needs
    Determine if you can provide it.

  1. Domain Analysis - understand problem background
  2. Define the problem
  3. Gather Requirements - figure out what the SW should do
        Talk to all people involved
  4. Analyze Requirements
      Organize gatherd info
      May repeat steps above
  5. Specify Requirements
      Formalize into written specification - instructions defining what it should do
      Figure out how SW should behave from a user perspective
      Separate what SW should do from how to code it