📄 lib0007.html
字号:
<html>
<META http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<head>
<title>Project Life Cycle Approaches</title>
<link rel="STYLESHEET" type="text/css" href="images/xpolecat.css">
<link rel="STYLESHEET" type="text/css" href="images/ie.content.css">
</head>
<body>
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr><td><div STYLE="MARGIN-LEFT: 0.15in;"><a href="toc.html"><img src="images/teamlib.gif" width="62" height="15" border="0" align="absmiddle" alt="Team LiB"></a></div></td>
<td align="right"><div STYLE="MARGIN-LEFT: 0.15in;">
<a href="LiB0006.html"><img src="images/previous.gif" width="62" height="15" border="0" align="absmiddle" alt="Previous Section"></a>
<a href="LiB0008.html"><img src="images/next.gif" width="41" height="15" border="0" align="absmiddle" alt="Next Section"></a>
</div></td></tr></table>
<br>
<div class="chapter">
<a name="ch01"></a>
<div class="section">
<h2 class="first-section-title"><a name="46"></a><a name="ch01lev1sec2"></a>Project Life Cycle Approaches</h2><p class="first-para">There are differing schools of thought as to what the J2EE project life cycle should be. This section describes these schools of thought and presents my views on the topic. The guidelines presented in this book are intended to be compatible with any methodology.</p>
<div class="section">
<h3 class="sect3-title">
<a name="47"></a><a name="ch01lev2sec12"></a>Waterfall Approach</h3>
<p class="first-para">The waterfall approach entails performing all analysis and design for a project before coding and testing. This approach was commonly used when most development was mainframe-based and is still the one most companies prefer.</p>
<p class="para">Projects developed under the waterfall approach tend to be large and have long delivery times. Hence, they entail more risk. These projects usually don't require business participants to learn as much technical terminology, and the business-side interface is tightly controlled.</p>
<p class="para">Compared with other approaches, the waterfall approach to project development does not provide feedback as early in the process but delivers a more complete solution. Waterfall projects tend to fit neatly into the budget planning cycle, which may be one reason for their popularity.</p>
<p class="last-para">Because of the length of time waterfall projects usually require, the business requirements often change during the project. Project managers then face a dilemma: if the project doesn't change with the business, the resulting application won't provide as much benefit; and if the project changes course to follow business requirement changes, the time and resources needed for the project will be negatively affected.</p>
</div>
<div class="section">
<h3 class="sect3-title">
<a name="48"></a><a name="ch01lev2sec13"></a>Iterative Approaches</h3>
<p class="first-para">Iterative approaches strive to separate a project into small component pieces that typically need few resources. Thus the iterative approach is the antithesis of the waterfall approach. The most popular iterative method is Extreme Programming (XP).</p>
<p class="para">The central objective of XP is reducing the technical risks and project costs that plague the waterfall approach. XP uses the following assumptions:</p>
<a name="49"></a><a name="IDX-10"></a>
<ul class="itemizedlist">
<li class="first-listitem">
<p class="first-para">Catching mistakes earlier is cheaper in the long run.</p>
</li>
<li class="listitem">
<p class="first-para">Reducing complexity also reduces technical risk and is cheaper in the long run.</p>
</li>
</ul>
<p class="para">XP dictates that you break the problem up into many small problems (called stories) that take three weeks or less to implement. Each story is co-developed by two programmers using one machine. The programmatic test to determine if the new story functionality works is developed and added to the regression test suite when the story is developed. These programmers ignore every aspect of the application except the story they are working on. A business participant is dedicated to the project and is immediately available to answer any business questions that arise.</p>
<p class="para">Using pairs of programmers to code everything theoretically reduces the probability that an error survives to deployment. Using pairs also tends to make code simpler because it takes time to explain the concept to another person. The more complicated the algorithm, the harder it is to explain. The emphasis on reducing complexity makes it less likely that mistakes will occur.</p>
<p class="para">The emphasis on testing, creating, and frequently running a regression test suite catches mistakes early and reduces the probability that any change will inadvertently introduce new bugs or have other unintended consequences.</p>
<p class="last-para">XP reduces risk by providing feedback early. A development team proceeding down the wrong track will be alerted and corrected earlier, when it's much cheaper.</p>
</div>
<div class="section">
<h3 class="sect3-title">
<a name="50"></a><a name="ch01lev2sec14"></a>Rational Unified Process</h3>
<p class="first-para">The Rational Unified Process (RUP) is a formalized development methodology. Most RUP literature describes it as an iterative approach, but that's only half the story. RUP emphasizes starting with requirements gathering, analysis, and design activities for the entire project—including object and data modeling—before proceeding to construction. In this sense, RUP takes a waterfall approach to analysis and design but an iterative approach to construction and delivery. By encouraging early requirements gathering and analysis, RUP seeks to keep the project aligned with user expectations.</p>
<p class="para">RUP mitigates risk by encouraging the team to develop the riskiest portions of the project first, allowing more time to recognize and respond to issues and problems. It also reduces rework when the design requires alteration.</p>
<a name="51"></a><a name="IDX-11"></a>
</div>
<div class="section">
<h3 class="sect3-title">
<a name="52"></a><a name="ch01lev2sec15"></a>Which Approach is Most Popular?</h3>
<p class="first-para">I'm not prepared to declare any of these approaches "best." They all have advantages and disadvantages. The waterfall approach appears to be the most commonly used.</p>
<p class="para">XP is rarely used in pure form. This isn't a judgment, merely an observation. Most companies use (and are more comfortable with) a waterfall approach to initial development and major enhancements. While enhancements are more iterative with the waterfall approach, the iteration size is usually much larger than with XP approaches.</p>
<p class="para">XP's requirement of two coders for one task is a hard sell. From a layman's perspective, XP appears to consume more resources than is necessary for any given coding task. The cost for the extra coder is readily quantifiable, but the lost productivity for mistakes often is not. And people tend to opt for reducing the costs they can easily see, not the ones they may know are present but are not apparent.</p>
<p class="last-para">RUP seems to be gaining popularity. In fact, more companies appear to be using RUP than are using XP. However, every implementation of RUP I've seen has been partial. It's common for organizations to be selective and use the portions of RUP that provide the most benefit to the project at hand.</p>
</div>
<div class="section">
<h3 class="sect3-title">
<a name="53"></a><a name="ch01lev2sec16"></a>Consider a Hybrid Approach</h3>
<p class="first-para">This book is largely compatible with either approach. XP users would merely choose much smaller iteration sizes than my illustrations. Because one approach rarely has a monopoly on common sense and is devoid of disadvantages, I prefer a hybrid approach.</p>
<p class="para">
<b>XP's emphasis on testing has great value.</b> I've adopted the practice of coding test sequences for everything I write and combining them into a full regression test. I've even seen a team go so far as to put a full regression test in the build and force the deployment to fail if all the tests don't pass. I find that the mistakes avoided by this practice more than pay for the extra time and effort required to develop and maintain test scenarios.</p>
<p class="para">
<b>XP's war on complexity has value.</b> Simpler is better. Ignoring all stories but the one you're working on does produce simpler code in the short term. But it also introduces a higher probability of rework (or refactoring, in more modern parlance), for which many projects have no budget. If refactoring isn't done properly or the developers are under time pressure, the code can easily end up being unnecessarily complex anyway. Also, many developers use the "complexity" excuse to ignore business requirements.</p>
<a name="54"></a><a name="IDX-12"></a>
<p class="para">
<b>RUP's emphasis on centralized analysis and design has great value.</b> XP assumes that developers can take a parochial view of the story they are working on and ignore anything else. This can cause some amount of rework. All developers really should have a larger focus. Because RUP concentrates analysis and design at the beginning of a project, it represents a sensible compromise between a purely iterative approach and the waterfall approach.</p>
<p class="para">
<b>It is necessary to control communication with end users.</b> XP assumes that any member of the development team should be able to talk to an end-user representative. Developers and end users usually have different perspectives and use different terminology. In practice, many developers have trouble adapting to nontechnical terminology. They simply can't translate business terminology into technical terminology, and vice versa. Some centralization of communication to the business side is necessary as a practical matter.</p>
</div>
</div>
</div><br>
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr><td><div STYLE="MARGIN-LEFT: 0.15in;"><a href="toc.html"><img src="images/teamlib.gif" width="62" height="15" border="0" align="absmiddle" alt="Team LiB"></a></div></td>
<td align="right"><div STYLE="MARGIN-LEFT: 0.15in;">
<a href="LiB0006.html"><img src="images/previous.gif" width="62" height="15" border="0" align="absmiddle" alt="Previous Section"></a>
<a href="LiB0008.html"><img src="images/next.gif" width="41" height="15" border="0" align="absmiddle" alt="Next Section"></a>
</div></td></tr></table>
</body></html>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -