*   risk -
    *   an exposure to the chance of injury or loss

    *   something NEGATIVE might happen!
    *   for a software project: an ADVERSE effect on
        cost, quality, or schedule

*   risk management -
    *   dealing with POSSIBLE events, not expected ones...

    *   revolves around risk assessment and risk control

*   risk assessment -
    *   risk identification
    *   risk analysis
    *   prioritization

*   talking through Boehm's top 10 software risks;
    *   ...
    *   gold plating - adding features to the software
        that are only marginally useful

*   when going from risk assessment to risk control,
    note the distinction between risk avoidance and risk
    mitigation

*   starting up on some discussion of
    Jalote Chapter 5... SOFTWARE architecture
    *   NOT the same as CS 243's architecture!
    *   NOT the same as Brooks' MMM architecture (in the context
        of software design)

    *   ...here, software architecture of a complex system
        is meant to be the *software* subsystems that
	need to interact for the system to provide the
	expected behavior

        *   identifying the subsystems,
	*   determine the interfaces of those subsystems,
	*   and determine the rules for interaction between
	    the subsystems

*   NOTE: for a SINGLE project,
    (particularly for a large project)
    ...there can be MULTIPLE architectural views of the SAME
       software

    *   an architectural view consists of elements
        and relationships between them
	and describes a stucture

    *   different views expose different properties

*   MANY view types have been proposed!
    *   most belong to one of these 3 types:
        *   module views
	*   component and connector views (C & C views)
	*   allocation views

    *   the C & C view is very often done, and is sometimes
        considered the primary view
	amongst the several you may make of a system

    *   module views - 
        *   viewing the software as a collection of code
	    units (not runtime entities)
        *   here, the relationships are code-based --
	    part-of, depends-on, calls, generalization/specification

    *   C & C views -
        *   elements are run-time entities called components
	    ...a component is a unit that has identity in
	    executing systems -- server, objects, processes, .exe, dll

        *   connectors - means of interaction between components
            (pipes, shared memory, sockets)

    *   allocation views -
    	*   focusing on how software units are allocated to
	    resources such as hardware, file systems, people

	    ...the relationships between software elements
	    and execution units in the environment

*   Component and Connector view, in more details
    *   components, in a C & C diagram often represented as shapes,
        connectors, in a C & C diagram often represented as lines
	(but there are a few exceptions to that)

	*   components - computational elements or data stores
	    connectors - means of interaction between components