Fall 2016, CS-160 Lecture: Deployment, Metrics, and Maintenance

Deployment planning: very important to plan out your strategy of getting your software installed (pp. 204-205).
Cutover: "the process of moving users to the new application" (p. 206)
Staged deployment: minimizing unexpected software upgrade failures by creating a "fully functional environment where you can practice deployment until you’ve worked out all the kinks" (p. 206).
Gradual Cutover: "install the new application for some users while other users continue working with their existing system" (p. 206).
Incremental deployment: "release the new system’s features to the users gradually" (p. 208).

Source: Rod Stephens, Beginning Software Engineering

"Physical environment" (p. 209). Examples: office furniture, electricity, toilet, kitchen, etc.
"Hardware" (p. 209). Computer hardware.
"Documentation" (p. 209). "...training materials, user manuals, help guides..." (p. 209)
"Training" (p. 209). Do your users need instruction / lessons on how to use your application?
"Database" (p. 209). All things database (server hardware, server software, network configuration, etc.).
"Other people’s software" (p. 209). Software that coexists with the software you’d written. This includes operating system software, productivity software, etc.
"Your software" (p. 210). Your contributions include the software and hardware necessary to run your application.

Source: Rod Stephens, Beginning Software Engineering

"Assume everything will work" (p. 210).
"Have no rollback plan" (p. 210). Do you have a way to undo a software distribution if something fails? Rolling back to previous version could save lost productivity and time, especially in production environments.
"Allow insufficient time" (p. 210). Expect the unexpected when distributing new software. Allocate extra time to accommodate the unexpected failures.
"Don’t know when to surrender" (p. 210). Set limits on how long and how many unexpected problems you will tackle before taking a break or stopping for the day. Important not to burn out on issues, especially under stress. Clear your mind. Relax. Come back and attack the problems with a fresh mind and perspective.
"Skip staging" (p. 210). Important to install software in stages or steps. Testing carefully as your proceed to avoid unexpected incompatibilities and ultimately downtime. Example: don’t install new software on every user machine. Stagger the installation and test to ensure the new installation works well.
"Install lots of updates all at once" (p. 211).
"Use an unstable environment" (p. 211). Don’t install software in an unreliable computing environment. It will only disrupt the deployment process.
"Set an early point of no return" (p. 211). When installing new software don’t make the upgrade process irreversible when the new upgrade fails unexpectedly.

Source: Rod Stephens, Beginning Software Engineering

Attribute: "something that you can measure" (p. 222).
Metric: "a value that you use to study some aspect of a project" (p. 222).
Process metrics: "measure your organization’s development process" (p. 226).
Project metrics (aka product metrics): "intended to measure and track the current project" (p. 226).

Source: Rod Stephens, Beginning Software Engineering

"Minimize a schedule" (p. 224).
"Reduce the number of defects" (p. 224).
"Predict the number of defects that will arise" (p. 224).
"Assess ongoing quality" (p. 224).
"Improve finished results" (p. 224).
"Improve maintenance" (p. 224).
"Make sure a project is on schedule" (p. 224).
"Detect risks such as schedule slip, excessive bugs, or features that won’t work and adjust staffing and work effort to address them" (p. 224).

Source: Rod Stephens, Beginning Software Engineering

"Simple: The easier the attribute is to understand, the better" (p. 224).
"Measurable: To be useful, you must measure the attribute" (p. 224).
"Relevant: If an attribute doesn’t lead to a useful indicator, there’s no point measuring it" (p. 224).
"Objective: It’s easier to get meaningful results from objective data rather than subjective opinions" (p. 224).
"Easily obtainable: ...Gathering attribute data should not be a huge burden" (p. 224).

Source: Rod Stephens, Beginning Software Engineering

"Cost: Money spent on the project for hardware, software development tools, networking, services, training, and so fourth” (p. 227).
"Effort: This is the amount of work being put into the project” (p. 227).
"Defect rates: The number of defects discovered over time" (p. 227).
"Lines of code (LOC): The number of lines of code produced per day" (p. 227).
"Pages of documentation:" Examples include "Project documentation” and “user documentation" (p. 227).
"Functionality: How well does the application do what it’s supposed to do?" (p. 227).
Measured by "number of help requests, change requests, and user complaints" (p. 227).
"Quality: Do the users think this is a high-quality application?" (p. 227).
Measured by user surveys (p. 227).
"Complexity: How complex is the project?" (p. 227).
Difficult to evaluate/measure this!
"Efficiency: How efficient is the project?" (p. 227).
Measure user productivity with the software possibly using a control group and an experimental group?
"Reliability: How reliable is the application?" (p. 227).
Measure the number of unexpected program exists / failures (p. 227).
"Maintainability: How easy will it be to maintain the application in the long term?" (p. 227).
Examine "the amount and quality of the project documentation" (p. 227).

Source: Rod Stephens, Beginning Software Engineering

"Perfective: improving existing features and adding new ones" (p. ?)
"Adaptive: Modifying the application to meet changes in the application’s environment”" (p. ?)
"Corrective: Fixing bugs" (p. ?)
"Preventive: Restructuring the code to make it more maintainable" (p. ?)