📄 lib0006.html
字号:
<html>
<META http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<head>
<title>Chapter 1: Project Development Team and Project Life Cycle</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="LiB0005.html"><img src="images/previous.gif" width="62" height="15" border="0" align="absmiddle" alt="Previous Section"></a>
<a href="LiB0007.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>
<h1 class="chapter-title"><span class="chapter-titlelabel">Chapter 1: </span>Project Development Team and Project Life Cycle</h1><a name="25"></a><a name="IDX-1"></a>
<div class="highlights">
<p class="first-para">This chapter lays the foundation for building a successful first project, from inception to release. It begins by defining what a technical architect is and does and summarizes how the architect works with other team members. The chapter continues with a look at a few alternative approaches to the development process. Still a subject of considerable debate, the definitive process for building a successful project does not yet exist, leading many companies to adopt a hybrid plan.</p>
</div>
<div class="section">
<h2 class="sect2-title">
<a name="26"></a><a name="ch01lev1sec1"></a>Project Development Team: Roles and Responsibilities</h2>
<p class="first-para">All J2EE development teams need people with a wide variety of skills to fill numerous roles within the team. Among the many skill sets needed to make a J2EE project successful are:</p>
<ul class="itemizedlist">
<li class="first-listitem">
<p class="first-para">Technical architect</p>
</li>
<li class="listitem">
<p class="first-para">Project manager</p>
</li>
<li class="listitem">
<p class="first-para">Business analyst</p>
</li>
<li class="listitem">
<p class="first-para">Layout designer</p>
</li>
<li class="listitem">
<p class="first-para">Presentation-tier developer</p>
<a name="27"></a><a name="IDX-2"></a>
</li>
<li class="listitem">
<p class="first-para">Business logic developer</p>
</li>
<li class="listitem">
<p class="first-para">Data modeler</p>
</li>
<li class="listitem">
<p class="first-para">Database administrator</p>
</li>
<li class="listitem">
<p class="first-para">Data migration specialist</p>
</li>
<li class="listitem">
<p class="first-para">Infrastructure specialist</p>
</li>
<li class="listitem">
<p class="first-para">Testing specialist</p>
</li>
</ul>
<p class="para">Although the book focuses on the role of the technical architect, this section defines the roles and responsibilities of other major players on the J2EE development team and describes the responsibilities of the technical architect with respect to those roles.</p>
<p class="para">Some organizations use different labels for the roles. For instance, an infrastructure specialist may be called a system administrator, a testing specialist may be a tester, and some organizations may distinguish between a test team manager and individual testers. Regardless of the terms you attach to these skill sets, making all of them part of a development team greatly increases its chances of creating a successful J2EE project.</p>
<p class="para">Further, it's possible for one person on the team to fill many roles and for one role to be co-owned by multiple people if the project is large enough. Some organizations combine the roles of technical architect and project manager. Some organizations have a senior developer double as a database administrator or as an infrastructure specialist. And some have the same developers work on the presentation tier as well as the business layer. I'm not trying to recommend a team organization but merely to communicate what skill sets are necessary, however they are organized.</p>
<div class="section">
<h3 class="sect3-title">
<a name="28"></a><a name="ch01lev2sec1"></a>Technical Architect </h3>
<p class="first-para">
<b class="bold">The technical architect identifies the technologies that will be used for</b> <b class="bold">the project.</b> In many organizations, some technology choices are made at an enterprise level. For instance, many organizations make hardware and operating system choices and some software choices (e.g., the J2EE container vendor) at an enterprise level. Commonly, choosing a language, such as Java, is an enterprise-level decision.</p>
<p class="para">However, most applications have technical requirements that aren't explicitly provided in enterprise-level edicts. I make a distinction between technology choices made at an enterprise level and those made for individual applications. For example, a decision to use the Java language for all server-side programming might be made at an enterprise level, but a decision about <a name="29"></a><a name="IDX-3"></a>which XML parser to use might be left to individual application architects. In many organizations, the people making enterprise-level technology choices make up a group separate from the J2EE development team.</p>
<p class="para">The technical architect is commonly responsible for identifying third-party packages or utilities that will be used for a project. For example, the architect might identify a need for a template-based generation engine and choose Apache's Velocity.</p>
<p class="para">
<b class="bold">The technical architect recommends the development methodologies and</b> <b class="bold">frameworks of the project.</b> Typically, the architect makes these recommendations to the project manager. For example, a common recommendation is to document all analyses in use-case format and supplement with a prototype. Another common recommendation is to document the design in terms of an object model. Some organizations define the methodologies used at an enterprise level.</p>
<p class="para">
<b class="bold">The technical architect provides the overall design and structure of the</b> <b class="bold">application.</b> Each developer brings to a project a unique set of preconceived opinions, habits, and preferences. Synthesizing the input of this sometimes widely divergent group, the technical architect ensures that the work done by individual developers is complementary.</p>
<p class="para">I liken the role of technical architect to that of an orchestra conductor. All musicians have differing opinions about how to interpret a given work. The conductor provides the interpretation that will be used and works with the musicians to implement it.</p>
<p class="para">
<b class="bold">The technical architect ensures that the project is adequately defined.</b> A project analysis must be detailed and consistent enough to form the basis for building an application. Typically, the technical architect works with the project manager and business analyst to define the project.</p>
<p class="para">
<b class="bold">The technical architect ensures that the application design is adequately</b> <b class="bold">documented.</b> Documenting the application design is a critical step in establishing sound communication with and among developers. The process of creating documentation forces the architect to think through issues thoroughly. And the final document enables management to add or change developers to the project without adversely encroaching on the architect's time. For developers, documentation allows them to proceed if the technical architect is absent from the project for a limited period and enables them to work through design inconsistencies on their own without consuming the <a name="30"></a><a name="IDX-4"></a>time of other members of the development team. Documentation also helps to insulate the project against the effects of personnel turnover.</p>
<p class="para">I've seen many projects that were not documented, and the result was that adding a developer was a major chore because the architect had to verbally convey the design to the newcomer. Having to communicate the design verbally negates some of the benefits to bringing on additional developers.</p>
<p class="para">
<b class="bold">The technical architect establishes coding guidelines.</b> Because individual developers have coding preferences, coding standards need to be articulated so that the individual pieces are more easily brought together. The technical architect is responsible for establishing project procedures and guidelines for topics such as the following, which are covered in more depth later in the book:</p>
<ul class="itemizedlist">
<li class="first-listitem">
<p class="first-para">Exception handling</p>
</li>
<li class="listitem">
<p class="first-para">Logging</p>
</li>
<li class="listitem">
<p class="first-para">Testing</p>
</li>
<li class="listitem">
<p class="first-para">Threading</p>
</li>
</ul>
<p class="para">
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -