mikeem em's Bookmarks tagged exam →  View Popular

Spiral Methodology:

While the waterfall methodology offers an orderly structure for software
development, demands for reduced time-to-market make its series steps inappropriate. The
next evolutionary step from the waterfall is where the various steps are staged for
multiple deliveries or handoffs.  The ultimate evolution from the water fall is the
spiral, taking advantage of the fact that development projects work best when they are
both incremental and iterative, where the team is able to start small and benefit from
enlightened trial and error along the way. 

The spiral methodology reflects the relationship of tasks with rapid
prototyping, increased parallelism, and concurrency in design and build activities. The
spiral method should still be planned methodically, with tasks and deliverables identified
for each step in the spiral.

Waterfall Methodology

All projects can be managed better when segmented into a hierarchy of
chunks such as phases, stages, activities, tasks and
steps.  In system development projects, the simplist rendition of this is called the
"waterfall" methodology, as shown in the following figure:

In looking at this graphic, which was for major defense systems
developments, please note this presumes that the system requirement have already been
defined and scrubbed exhaustively, which is probably the most important step towards
project success.  Nevertheless, the graphic illustrates a few critical principles of
a good methodology:

• Work is done in stages,


• Content reviews are conducted between stages, and


• Reviews represent quality gates and decision points for continuing.

The waterfall provides an orderly sequence of development
steps and helps ensure the adequacy of documentation and design reviews to ensure the
quality, reliability, and maintainability of the developed software.  While
almost everyone these days disparages the "waterfall methodology" as being
needlessly slow and cumbersome, it does illustrate a few sound principles of life cycle
development. 

Pure
Waterfall

This
is the classical system development model. It consists of discontinuous
phases:

1. Concept


2. Requirements


3. Architectural
   design


4. Detailed
   design


5. Coding
   and development


6. Testing
   and implementation

Spiral

The
spiral is a risk-reduction oriented model that breaks a software
project up into mini-projects, each addressing one or more major
risks. After major risks have been addressed, the spiral model terminates
as a waterfall model. Spiral iterations involve six steps:

1. Determine
   objectives, alternatives and constraints.


2. Identify
   and resolve risks.


3. Evaluate
   alternatives.


4. Develop
   the deliverables for that iteration and verify that they are
   correct.


5. Plan
   the next iteration.


6. Commit
   to an approach for the next iteration.

In the water fall model the process flows from top to 
bottom like a flow of water . But any new changes can not 
be incorporated in the middle of the project development.

Whereas the spiral model is best suted for projects 
associated with risks.

Overview

Waterfall development isn't new -- it's been around since
1970 -- but most developers still only have a vague idea of what it means.
Essentially, it's a framework for software development in which development
proceeds sequentially through a series of phases, starting with system
requirements analysis and leading up to product release and maintenance.
Feedback loops exist between each phase, so that as new information is
uncovered or problems are discovered, it is possible to "go back" a
phase and make appropriate modification. Progress "flows" from one
stage to the next, much like the waterfall that gives the model its name.

The waterfall model, as described above, offers numerous
advantages for software developers. First, the staged development cycle
enforces discipline: every phase has a defined start and end point, and
progress can be conclusively identified (through the use of milestones) by both
vendor and client. The emphasis on requirements and design before writing a
single line of code ensures minimal wastage of time and effort and reduces the
risk of schedule slippage, or of customer expectations not being met.

Getting the requirements and design out of the way first
also improves quality; it's much easier to catch and correct possible flaws at
the design stage than at the testing stage, after all the components have been
integrated and tracking down specific errors is more complex. Finally, because
the first two phases end in the production of a formal specification, the
waterfall model can aid efficient knowledge transfer when team members are
dispersed in different locations.

Criticisms

Customer needs

While the model does have critics, it still remains useful
for certain types of projects and can, when properly implemented, produce
significant cost and time savings. Whether you should use it or not depends
largely on how well you believe you understand your customer's needs, and how
much volatility you expect in those needs as the project progresses. It's worth
noting that for more volatile projects, other frameworks exists for thinking
about project management, notably the so-called spiral model...but that's a
story for another day!

Web Development usage

In the Web development field, three-tier is often used to refer to Websites, commonly Electronic commerce websites, which are built using three tiers:

1. A front end Web server serving static content


2. A middle dynamic content processing and generation level Application server, for example Java EE platform.


3. A back end Database, comprising both data sets and the Database management system or RDBMS software that manages and provides access to the data.

Three Tier Architecture (Linux journal) [1]

• Presentation services tier    Responsible for gathering information from the user, sending the user information to the business services for processing, receiving the results of the business services processing, and presenting those results to the user.



• Business services tier    Responsible for receiving input from the presentation tier, interacting with the data services to perform the business operations that the application was designed to automate (for example, income tax preparation, order processing, and so on), and sending the processed results to the presentation tier.



• Data services tier    Responsible for storage, retrieval, maintenance, and integrity of data.

The Web is a good example of where to apply the three-tier model. Application developers know little about the potential clients except that they have a near-universal interface: the Web browser. The middle tier accepts requests from clients, retrieves information from the back-end systems, processes the data, and forwards the results to the client. The client is relieved of a lot of work. Thin clients are a good fit in this model.

The middle tier may provide the following services:

• The code for the middle tier can exist on multiple application servers, all accepting requests from multiple users (via load-balancing switches) and all connecting with the back-end systems.



• Message queuing allows clients to interact asynchronously with the back-end servers. In other words, transactions don't need to follow a precisely timed flow. The client may need to wait for a message from the server.



• The middle-tier server can provide transaction monitoring, which tracks the order and events of an online exchange to ensure that everything is complete and handled correctly. If not, the transaction is backed out.



• Distributed object computing services in which application logic and/or data resides in objects that are made available through an ORB (object request broker). An ORB provides a sort of software bus through which objects on one system can make requests of objects on another system. See "Distributed Object Computing."

1.1.1
<!--[endif]-->
3-Tier
Architecture

The 3-tier architecture overcomes the weaknesses
of the 2-tier and
client/server architectures. It contains a client workstation, a component
server, and a database server. The user interface is on the client side while
business logic and data management are in dedicated tiers. Business logic resides
on one machine where it can be easily managed. Successful implementation of a
3-tier architecture requires considerable
applied