CS 458 - Week 5 Lecture 1 - 2017-09-19

**** ADDITIONAL PROJECTS ****

Brennen Rose -- client/contact
*   CAPS looking for a web application to allow users to
    *   figure out what they are feeling and find resources
        about it;
    *   answer some questions, and the resource list some
        suggestions
    *   resource area - list local Humboldt-area
        mental health resources -- could also be dynamic,
	based on the phone's IP and/or web-crawling
    *   list events on campus related to mental health
        (list of CAPS groups, etc.)
    *   allow push notifications for those who opt-in

from Harry Almeraz:
*   talked to friend managing properties
    *   application to manage cleaning supplies
    *   (add, remove supplies)
    *   potential auto-purchasing?
    *   COMMITTED client
    *   does understand class restrictions

*   Harry started cleaning business
    *   application to streamline daily workflow
    *   (to improve on existing pieces)
    *   willing to be client

*   Travis Houle 
    *   Work with CMS (Content Management System) to create
    	commercial quality website using/modifying Joomla Extensions
    *   Create C# application to update database
    *   Can choose type (fake company) of website to design
    *   Must add and modify e-commerce store
    *   willing to answer questions about such features from
        multiple teams 

*   Lam Ngo
    *   Design front end for supercomputer to make more usable
    *   contact/talk to Tim Lauck 

**** ADDITIONAL PROJECTS ****


------------------------------------------
Jalote - Chapter 2 - Software Processes
------------------------------------------
*   process model - the approach you plan to take for a project
    process - actual approach you take

*   why worry about having a process?
    *   because we WANT high QUALITY and high PRODUCTIVITY
        ...an appropriate process can help with improving both;

    *   in software, three major factors that influence
        quality and productivity:
	*   people
        *   processes
        *   technology

    *   how do processes help?
        can HELP specify WHAT tasks to do, HOW to do them
	(I'd add "when" to do them, also...)

*   indeed, a focus on PROCESS distinguishes software engineering
    from most other computing disciplines;

*   there are NUMEROUS software development process models
    here are 6 classic ones:
    *   Waterfall
    *   Prototyping model
    *   Iterative development model
    *   Rational Unified Process (RUP)
    *   Timeboxing
    *   Agile process models (e.g., Extreme Programming, Scrum, etc.)

*   Waterfall -
    requirements, design, coding, testing phases in linear
    progression
    *   specific artifacts from each stage

    *   conceptually the simplest process model for software
        development
    *   DOES work best when requirements can be
        "nailed down" <-- works best for well-understood problems

    *   when does it not work so well? disadvantages?
        *   what if the requirements can't be reasonably
	    determined and "frozen"? unchanging requirements
	    may not work well;

        *   entire software is delivered in ONE SHOT at
	    the end; this is a big risk for the user;

        *   encourages "requirements bloating"
            if you think you MIGHT need it, you might be
	    tempted to include everything you can think of;

        *   it is document-driven process that requires
	    formal documents at the end of each phase

*   Prototyping model
    *   this is ONE version of this classic model
    *   one or more THROW-AWAY prototypes are built FIRST
        with the purpose of FURTHER DEVELOPING the requirements,
        to lead to MORE STABLE requirements
        *   prototype is not considered an actual, final product
            or even part of that product; it is just to
            help the user figure out what they want/need

        *   "quick'n'sleazy", doesn't have to be completely operational,
            may be a "facade" or even a "paper" prototype;

        *   the user/client(s) try these out to help to improve the
            quality of the requirements (especially when they might be
            hard to get "firm" enough otherwise)

        *   in Jalote Ch. 2's version of this,
            you use the (inexpensive, quickly-produced)
	    prototypes to come up with a more-robust
            set of requirements,
	    and then proceed in a Waterfall-like approach

            *   (that is, once all agree the requirements are clear
                enough, proceed in a waterfall-like fashion from that
                point)

    *   potential advantages:
        *   better, more stable requirements might result
        *   experience of developing even these
            quick'n'sleazy prototypes
            can reduce the cost of the development
            of the eventual deliverable version
        *   ...and might improve its quality as well
        *   reduces risk that final project won't
            actually meet the client's needs

    *   potential disadvantages:
        *   there is a cost for these prototypes
            (but hopefully you try to minimize this);
        *   you do have to have a cooperative client;
        *   still has some of the remaining issues
            that Waterfall has -- still an all-or-nothing
            single product delivery at the end

*   Iterative Development
    *   so, waterfall and prototype are all-or-nothing,
        you get the deliverable product all at the end;

    *   iterative development reduces that risk by
        developing the software in iterations,
	EACH iteration resulting in a working
	deliverable software system

    *   depending on the variant, may not need
        to know ALL of the requirements at the
	start

    *   more discussion on this --
        and RUP
	and Timeboxing --
	on THURSDAY