Fixed a few typos.

process.html

@@ -24,13 +24,12 @@
 		<img src="images/flow.jpg" class="img-responsive" />		
 		<small>Credit: public domain</small>
 		
-		<!-- UPDATE -->
 		<h1>Process</h1>
 		<div class="lead">Andrew J. Ko</div>
 
 		<p>So you know what you're going to build and how you're going to build it. What process should you go about building it? Who's going to build what? What order should you build it in? How do you make sure everyone is in sync while you're building it? And most importantly, how to do you make sure you build well and on time? These are fundamental questions in software engineering with many potential answers. Unfortunately, we still don't know which of those answers are right.</p>
 
-		<p>At the foundation of all of these questions are basic matters of <a href="https://en.wikipedia.org/wiki/Project_management" target="_blank">project management</a>: plan, execute, and monitor. But developers in the 1970's and on found that traditional project management ideas didn't seem to work. The earliest process ideas followed a "waterfall" model, in which a project begins by identifying requirements, writing specifications, implementing, testing, and releasing, all under the assumption that every stage could be fully tested and verified. (Recognize this? It's the order of topics we're discussing in this class!). Many managers seemed to like the waterfall model because it seemed structured and predictable; however, because most managers were originally software developers, they preferred a structured approach to project management (<a href="#weinberg">Weinberg 1982</a>). The reality, however, was that no matter how much verification one did of each of these steps, there always seemed to be more information in later steps that caused a team to reconsider it's earlier decision (e.g., imagine a customer liked a requirement when it was described in the abstract, but when it was actually built, they rejected it, because they finally saw what the requirement really meant).</p>
+		<p>At the foundation of all of these questions are basic matters of <a href="https://en.wikipedia.org/wiki/Project_management" target="_blank">project management</a>: plan, execute, and monitor. But developers in the 1970's and on found that traditional project management ideas didn't seem to work. The earliest process ideas followed a "waterfall" model, in which a project begins by identifying requirements, writing specifications, implementing, testing, and releasing, all under the assumption that every stage could be fully tested and verified. (Recognize this? It's the order of topics we're discussing in this class!) Many managers seemed to like the waterfall model because it seemed structured and predictable; however, because most managers were originally software developers, they preferred a structured approach to project management (<a href="#weinberg">Weinberg 1982</a>). The reality, however, was that no matter how much verification one did of each of these steps, there always seemed to be more information in later steps that caused a team to reconsider it's earlier decision (e.g., imagine a customer liked a requirement when it was described in the abstract, but when it was actually built, they rejected it, because they finally saw what the requirement really meant).</p>
 
 		<p>In 1988, Barry Boehm proposed an alternative to waterfall called the Spiral model (<a href="#boehm">Boehm 1988</a>): rather than trying to verify every step before proceeding to the next level of detail, <em>prototype</em> every step along the way, getting partial validation, iteratively converging through a series of prototypes toward both an acceptable set of requirements <em>and</em> an acceptable product. Throughout, risk assessment is key, encouraging a team to reflect and revise process based on what they are learning. What was important about these ideas were not the particulars of Boehm's proposed process, but the disruptive idea that iteration and process improvement are critical to engineering great software.</p>