TABLE
OF CONTENTS 1 BARRACUDA SCOPE - OVERVIEW
1.1 Document History
1.2 Open Issues
2 THE BARRACUDA PRESENTATION FRAMEWORK
PROJECT
2.1 Project Objectives
2.2 High Level Requirements
2.3 Detailed Project Requirements
2.4 Project Scope Limitations
3 BARRACUDA - FUNCTIONAL ANALYSIS
3.1 Application Paradigms
3.2 Understanding the Problem Domain
3.3 Functional Objectives
3.4 Functional Requirements /
Recommendations
4 PROJECT RISKS AND RISK MANAGEMENT
4.1 Risk: Community and user acceptance
4.2 Risk: Legacy application
support
4.3 Risk: Performance concerns
4.4 Risk: Security concerns
4.5 Risk: Stability concerns
4.6 Risk: Paradigm limitations
5 PROPOSAL
5.1 Summary
5.2 Proposed Project Schedule
5.3 Summary: Schedule Risk Management
1
BARRACUDA SCOPE - OVERVIEW
Enhydra.org is pleased to present this Scope Summary
Document for the Barracuda project. This document is designed to kickoff the initial
effort to understand the Barracuda project requirements and to provide a preliminary
roadmap to fulfill the Barracuda goals and objectives. The content of this document is
intended to provide information and constructive direction to all project participants in
order to facilitate the projects success.
The next step in the development of the Barracuda project is to solicit feedback from
the open source community and to initiate the Discovery Stage of project development. As
we move into this phase it is essential that all participants have a shared vision of the
scope and objectives of the project and the Discovery process for the initial phases of
the Barracuda Presentation Framework. The scope and objectives for the Discovery process
will directly and profoundly impact both the schedule and the content of what is delivered
in the Barracuda project. The purpose of this document is to assist the Enhydra community
in the selection of the scope and objectives for the Discovery effort of the Barracuda
project. Additionally, this document highlights strengths, weaknesses, and risks of
various alternative routes that may be pursued in the implementation of the Barracuda
project.
1.1 Document
History
Version |
Published |
Notes |
0.72 |
1/05/01 |
Changed all references from 'Rocks' to
'Barracuda'. Updated everything to reflect project changes since October (there really
have not been very many) and to clarify our current direction. Also added section 2.4
identifying what Barracuda is NOT addressing. |
0.71 |
10/05/00 |
Expanded the summary at the end of
section 5.2 to clarify how we intend to be focusing on phased delivery. |
0.70 |
9/14/00 |
Initial release of Rocks Scope Summary
working draft version |
Notes: |
1.2 Open
Issues
- Release to community and incorporate feedback
2 THE
BARRACUDA PRESENTATION FRAMEWORK PROJECT
This section is intended to provide a high level overview of the goals, objectives, and
requirements for the Barracuda project.
2.1 Project
Objectives
The primary purpose of the Barracuda project is to create a presentation-layer
framework of reusable server-side development components designed to make it easier to
build and maintain complex web applications. This will benefit the Enhydra community at
large.
Consequently, our key objectives may be summarized accordingly:
- Make it easier for Enhydra developers in general to build and maintain the presentation
layers of web-applications
- Foster community involvement in the design & development of the Barracuda project
- Encourage developer adoption of the Enhydra platform by adding value through the
Barracuda framework
- Do such a good job that Barracuda become the de facto standard throughout the industry
2.2 High
Level Requirements
This project is responsible for creating a powerful, flexible framework that can
significantly improve the process of building and maintaining the presentation layers
within web applications.
A successful Barracuda framework will exhibit the following characteristics:
- Raise the Bar - provide a presentation layer
paradigm that is cohesive, scalable, and intuitive
- Improve Process - streamline the design and
development process for the presentation layer
- Simplify Development - make it easier to build
web applications with a higher level of functional complexity
- Encourage Separation - continue to encourage the
proper separation of content from code that began with XMLC
- Promote Simplicity - ensure the framework is
simple to learn, understand and use
- Ensure Flexibility - always provide a way to get "under the hood" to handle tasks beyond the
scope of our abstractions
- Handle Multiple Domains - support applications
that range in functionality from simple to complex
- Guarantee Interoperability - allow integration
with other presentation architectures and support any Servlet 2.2 compliant container
- Support Diversity - simplify usage of multiple
presentation layers in the same application (HTML, WML, etc.)
- Allow Tools Integration - make it possible to
integrate the framework into visual development tools
- Facilitate Economy of Scale - allow for parallel
development efforts involving lots of developers and designers
While not being tied exclusively to XMLC, one of Barracuda's chief goals is to make it
easier to work with this powerful framework. Consequently, the Barracuda project is
working closely with Mark Diekhans -- XMLC's chief architect -- to ensure we stay abreast
of changes and enhancements in the XMLC arena. For the latest XMLC details, please refer to the the XMLC Webpage.
We believe the Barracuda framework will consist of several distinct layers:
Forms Validation & Mapping Framework
- When working with web applications, one of the more tedious aspects tends to lie in
taking data entered in web pages as Strings and validating it according to the
application's business rules (which often expect data as first class Java objects like
Date, Integer, etc.). This subsystem will make it easy to map HTML form data to first
class Java objects and validate it automatically.
Model 2 Flow Control System - Most
popular presentation frameworks have rallied around the Model 2 presentation paradigm as
an effective way to realize many of the benefits of client-server's Model-View-Controller
(MVC) approach in a web-app environment. In Model 2, there are essentially 2 phases:
a controller receives a request, updates the business model, and then redirects program
flow to the appropriate view, which generates a response to be sent back to the client.
Barracuda will offer a Model 2 flow control subsystem.
Server-Side Event Model - Many
developers who have seen the benefits of event driven programming in client-server
applications have begun to look for ways to apply this approach to web-application
development as well. Barracuda will provide a robust event model especially geared towards
the intricacies of server side event handling. This is particulary strategic in that it
sets us up to develop a server-side component model (see below) that will enable
developers to add listeners to components and receive notification when those components
generate an event, just like they would in stated application development.
MVC Component Model - Barracuda will go
one step further than Model 2 to define a full blown server-side component model that
offers a true MVC style interface, much like Java's Swing toolkit has done for stated UIs.
This subsystem will be the key to leveraging XMLC by allowing developers to bind
components to DOM structures and then programming against the component Models instead of
dealing with the XMLC or DOM APIs.
MVC Component Library - Building on the
component model, Barracuda will provide a basic suite of MVC style components for the
server. Such a library might include components like Label, Image, Form, TextField,
PasswordField, TextArea, ComboBox, List, Button, CheckBox, RadioButton, Link, Script,
Table, Tree, and TabbedPane. It will also allow developers to create and reuse more
complex components.
JavaScript Framework & Library -
This subsystem will provide a simple bridge between Javascript and the Barracuda component
model, allowing developers to create reusable Javascript components that can be plugged
into the server-side component model to provide client-side control for other components.
We have not yet defined the specific components that might be included.
The overarching goal for each of these subsystems is to minimize
interdependencies so developers can use as much or as little of the Barracuda framework as
they desire. We also want to maximize interoperability and portability so Barracuda can
coexist with other approaches and attract developers outside the existing Enhydra
community.
2.3 Detailed
Project Requirements
Please see the Requirements Specification document for each specific subsystem for a
detailed list of the Barracuda project requirements. It is important to note that at this
point there are still a large number of requirements that have not been defined. These to
be defined requirements will have a large impact upon the design decisions that will be
addressed during the analysis portion of the project. Until these requirements are well
understood all estimates, independent of the source, regarding the duration of the
development effort should be considered very rough.
2.4 Project
Scope Limitations
It is often helpful to specifically address what is NOT being addressed by the project.
There are several specifics worth noting:
Application Flow Control Framework -
Barracuda is specifically NOT addressing the issue of application flow control, which
would involve creating a framework to control how users can navigate through an
application. This type of problem domain has been variously addressed by others with
Storyboard frameworks, StateChart Frameworks, etc. While this certainly falls under the
realm of an overarching presentation framework, we are not addressing it at this time
because:
This does not mean that a flow control framework is incompatible with
Barracuda; on the contrary, we feel it will make an excellent foundation for any number of
presentation frameworks. At the same time, we really want to constrain our focus to make
sure we get the lower layers right first.
Application Assembly Framework - Some
people have expressed interest in assembling web-applications from XML descriptors, rather
than by coding. While this is certainly intriguing, and we feel Barracuda will be
fundamentally compatible with this approach, we're not actively addressing this issue at
the present (same issues as above).
Applets - There's been some discussion
about using headless applets in J2ME environments. We are certainly not opposed to this,
but we're not actively addressing it either.
Of course all of these subjects can be revisited as Barracuda implementation
progresses.
3
BARRACUDA - FUNCTIONAL ANALYSIS
This section provides a functional analysis of the Barracuda project. We begin by
highlighting the differences between Client-Server and Web-Application paradigms, and then
proceed to evaluate the problem domain. Finally we address the objectives, requirements,
and risks for the Barracuda project.
3.1
Application Paradigms
In the realm of distributed development, there are currently two main paradigms that
have enjoyed widespread adoption: Client-Server and Web-Applications. Most distributed
applications fall into one of these two categories.
Historically, many distributed applications have been built using Client-Server
technology. Programs built on this model can provide powerful, feature rich interfaces
that give users a tremendous amount of flexibility and control over highly complex problem
domains. Unfortunately, client-server applications are often expensive to build and have
proven difficult to deploy, especially over multiple client platforms. Typically, even
simple applications require a large amount of supporting infrastructure to get off the
ground.
The following diagram demonstrates this effect:
As we can see, although client-server applications may provide a long-term payoff, they
generally require a much higher up-front investment.
In recent years a new application paradigm has emerged -- the Web Application
development model. The concept is actually quite simple: a server generates application
content that is then downloaded across the network to run in a universal client, the
user's Web Browser.
This server-centric approach offers many distinct advantages. As the diagram
illustrates, it requires far less effort to build and deploy applications, which in turn
translates to a lower cost of entry. However, the inevitable desire to provide the user
with a richer UI experience coupled with a web browser's limited functionality means that
web applications are still difficult to build and maintain as functional requirements
increase.
Consequently, Web-Application architecture has enjoyed widespread adoption and growth,
and as many client-server developers have made the shift we are starting to see attempts
to apply proven OO design techniques to the model.
Most developers today recognize the intrinsic value of a layered architecture that
separates applications into data, business, and presentation layers. While tools like
databases and object-relational mappers have greatly streamlined development in the
non-GUI layers, the process of building the presentation layer has remained surprisingly
tedious for web applications, even in light of new technologies like Servlets, and JSP.
The Barracuda framework intends to make it easier to build the presentation layers for
complex web applications by creating a reusable component model for server-side
development.
3.2
Understanding the Problem Domain
Development Issues
There are a number of specific issues that complicate server-side presentation
development.
presentation issues - There are a number of problems
relating specifically to the presentation aspects of web applications:
code / content coupling - Creating content on the server
often involves mixing both programming logic (Java), and client presentation code (HTML,
JavaScript, etc). For instance, using Servlets to build pages usually means embedding HTML
in Java; JSP requires embedding Java in HTML. CGI, Perl, and ASP suffer from the same
problems. All these approaches become problematic as complexity increases because
developers end up mixing multiple languages in one source file.
single tier architecture - Often, classes meant to
generate dynamic presentation content are tightly intertwined with lower tier
(non-presentation) logic. This coupling of business and presentation logic contradicts
good object-oriented design and makes it more difficult to enhance the application later
on.
multiple client views - Quite frequently, content destined
for the browser needs to be modified based on specific client constraints. These often
include things like internationalization, configurable views or skins, security
constraints, and a variety of output formats (HTML, WML, XML, etc).
lack of a standard presentation framework - In Java
client-server applications, Swing has become the de facto UI development model.
Unfortunately, a similar presentation paradigm has not yet emerged for the web-app model.
This may be to lack of well-defined industry standards, widespread use of add-hoc
development styles, and varying levels of programmer skill.
client side scripting - Often times web applications may
need to leverage client side scripting. Because this scripting code must be generated on
the server side, the developer often ends up writing "code within code", which
can be very difficult to develop, debug, and maintain. This again adds to the overall
application complexity and slows the development process.
DOM complexity - The industry appears to be converging on
the Document Object Model as a powerful approach to generating dynamic content. This makes
sense because the DOM provides structured access to content as an object hierarchy.
However, programming against the DOM is still low-level and tedious, which again makes the
overall development efforts more difficult.
protocol limitations - Most web applications leverage HTTP
as a transport protocol. Because HTTP is a client-initiated request-response protocol, it
is very difficult for server code to initiate unsolicited callbacks to the client. These
factors make it harder to implement real time user interfaces like those used in typical
client-server applications.
high maintenance / TCO - The basic nature of the web-app
paradigm makes web applications difficult to build and maintain as functional complexity
increases. The problem is exacerbated by the lack of common methodologies and the
proliferation of proprietary approaches. As a result, it is often difficult for developers
to learn and understand applications that they did not write. This makes web apps
expensive to own and maintain.
Why do these Problems Exist?
Given the number of obstacles identified above, there is obviously a window of
opportunity for an application development model that can successfully address these
issues. However, it may be helpful to ask "Why haven't these problems already been
solved?"
We believe there are several reasons:
new territory - while the enabling technologies behind
web-based applications has been around for quite some time (i.e. HTTP, CGI, Perl, Java),
the internet has evolved around a page-based, linear navigation paradigm -- users move
from page A to page B -- that has only recently (within the last 3 years) been applied to
applications. This creates subtle yet significant differences when compared to
client-server development; it takes time for developers to understand these details and
apply this knowledge to new application domains.
ad hoc development - historically developers lacking solid
OO skills have found it easier to get started in the web-app model. While this low
technical barrier to entry greatly encourages adoption, the quality of implementation
sometimes suffers. In many cases, this facilitates ad hoc development, which in turn
results in classic "spaghetti code". Typically in cases like this, application
design problems extend far deeper than just the presentation layers.
paradigm differences - even developers with very good OO
skills have had difficulty creating frameworks for the presentation layer within web
applications. For instance, some client-server OO presentation techniques like MVC are
more difficult to apply because of limitations within the underlying paradigm -- because
HTTP is not a bi-directional protocol, the server cannot notify the client when something
changes on the server, but must instead wait for the next client request cycle. This makes
some client-server design patterns more difficult to implement.
Consequently, we should recognize that while there may be a fundamental limitation to
the overall complexity that can be addressed by the Web-Application paradigm, we still
believe there is significant room for improvement.
We intend to make Barracuda the framework that elevates the standard for web based
development.
3.3
Functional Objectives
In light of the above difficulties, we have identified key functional objectives for
each of the Barracuda subsystems:
Forms Validation & Mapping Framework
Typically, a developer must manually retrieve form values from an HttpServletRequest.
The values are returned as Strings, and then it's up to the developer to manually parse,
convert, validate, etc. This tends to be cumbersome. The form mapping and validation
package should make it easier to work with HTML forms.
- allow developers to specify which elements a form should contain and how they should be
mapped (eg. support String, Boolean, Integer, Date, Long, Short, Double, and Float)
- allow developers to specify how elements and forms should be validated
- make it possible to create reusable validators that can be assembled into groups to form
more complex validation procedures without recoding
- make it easy to trap validation errors so the users can be notified of what went wrong
Model 2 Flow Control System
MVC stands for Model-View-Controller. Model 2 is a term coined by Sun to describe an
MVC architecture for web-apps (stateless) in which HTTP requests are passed from the User
Agent to a "Controller" Servlet, which updates the "Model" and then
invokes the appropriate "View" renderer (JSP, Servlet, etc), which in turn
renders the view from the updated model. You can learn more about Sun's view of Model 2 by
reading the J2EE Blueprints.
In short, a Model 2 Flow Control system should meet the following objectives:
- provide for programmatic separation of "Control" logic from "View"
logic
- provide the opportunity for Controllers to specify which View should be generated
- make the system generic enough so that the Views can be generated by any URI (Servlets,
JSP, template engine, etc)
- support the concept of complex, nested views (aka Hierarchical MVC)
Server-Side Event Model
A server-side Event Model should make it easy for developers to use event driven
programming in the context of web apps. There are several key objectives:
- translate HTTP Requests into events and dispatch to all interested listeners
- ensure that for every HTTP Request there is always only one HTTP Response
- make the model as similar to traditional event models as possible without minimizing the
differences between web-app and client-server paradigms (stateless vs. stated)
- make the system completely pluggable for maximum configurability
- lay the necessary event delivery infrastructure for a server-side component model
MVC Component Model & Library
By representing documents as DOMs, XMLC provides an object-oriented approach to
developing dynamic content. However, the DOM API is low-level and tedious to use --
operations are at the level of the HTML and XML elements, attributes and text data. The
DOM Widget Framework provides support for the development of higher level classes,
resembling GUI widgets, on top of DOM nodes. Consequently, a DOM Widget Framework should
meet the following functional objectives:
- provide a complete widget set that maps onto the DOM
- provide a flexible set of classes and interfaces such that complex, nested
HTML structures may be represented by a hierarchical structure of widget APIs.
JavaScript Framework & Library
The Barracuda JavaScript Framework should make it easier
for server-side Java developers to work with JavaScript. We see several key functional
objectives:
- provide a Java-based component model for implementing client-side scripting
- free Java programmers from having to understand JavaScript implementation issues,
especially with regard to generating client scripting logic from a server-side application
- facilitate mapping JavaScript to server-side dynamic documents, raising the level of DOM
programming
3.4
Functional Requirements / Recommendations
Based on our objectives, we can identify a number of preliminary requirements for each
subsystem. As work on Barracuda progresses, we will provide links to more detailed
requirements documents.
Forms Validation & Mapping Framework
Please refer to the Form Validation &
Mapping Requirements document.
Model 2 Flow Control System
Please refer to the Event Model Requirements
document (the Model 2 Flow Control System has been integrated within the Server-Side Event
Model framework).
Server-Side Event Model
Please refer to the Event Model Requirements
document.
MVC Component Model & Library
In order to meet the stated high-level objectives we will create a
Model-View-Controller (MVC) framework based on the following list of essential functional
requirements: (design work in progress)
- Define common Components - Label, Image, Form, TextField,
PasswordField, TextArea, ComboBox, List, Button, CheckBox, RadioButton, Link, Script,
Table, Tree, and TabbedPane
- Define common Models - Create model interfaces for each component (much
like's Swing MVC Model interfaces)
- Component Binding - Enable components to be bound to DOM nodes. When
the components are rendered they will load data from their model into the appropriate
portions of the DOM view.
- Component Actions - Enable components to generate action events (ie.
when the user does something to invoke a URL). Some components may need to utilize
scripting in order to generate events. Components that generate events should allow
developers to add event listeners to them.
- Component Nesting - Enable components to be nested, allowing complex
components to be assembled from simpler ones.
- Multiple L&F - Recognize that components may need to be rendered
differently depending on L&F requirements (ie internationalization, user prefs, etc).
- Multiple Output Formats - Recognize that components may need to
generate different output formats, depending on client capabilities. This probably means
we will need some kind of structure to identify client capabilities. It may also be
helpful for components to be able to indicate which output formats they can support.
This list is still highly speculative and will be refined as the design process
continues.
Note that we do NOT feel that component scope (ie. how long the component hierarchy
lives, is it shared by multiple threads, etc.) is a distinct aspect of the component
model. We feel that should be addressed by a higher layer within the presentation
framework. At the same time, we recognize that we need to account for the possibility that
developers may want to provide shared access to component hierarchies, and as such intend
to take this into account in the design process.
JavaScript Framework & Library
We have identified the following list of key functional
requirements for a JavaScript Framework & Library:
Library of common scripts - The Barracuda
JavaScript Framework will consist of modules that provide specific types of JavaScript
functionality. These modules provide a library of common JavaScript functions and
utilities. For example, a single module handles a particular style of form
verification.
Encapsulates client scripting - These
components will shield the application developer from dealing with JavaScript
implementation issues. Such issues include any aspects of JavaScript management that
are common to using JavaScript in general, as well as implementing specific scripts.
Flexible scripting framework - Specific
modules do not depend on other modules that provide other types of JavaScript
functionality. That is, though module wrappers may be extended, or used with other
wrapper classes, they do not otherwise require the presence or use of others. This
ensures that their implementation details can change at any time, without requiring the
programmer to change how they are used.
This list is still highly speculative and will be refined as the design process
continues.
4
PROJECT RISKS AND RISK MANAGEMENT
This section highlights key known risks and plans for mitigating these risks. These
risks have been identified during the Scope phase of the project and are discussed in the
context of this particular project. This risk analysis is very important in the evaluation
of what we can realistically achieve during the Discovery phase of the project.
4.1
Risk: Community and user acceptance - Given the wide range
of problem domains for web applications, coupled with numbers of competing approaches and
the lack of a de facto standard, it may be difficult to create a framework that will be
acceptable for everyone.
Mitigation Strategy - We believe there are a
number of things we can do to help minimize this risk:
- Release early design documents and white papers to familiarize the Enhydra community and
users about our design paradigm.
- Provide early and complete examples with appropriate documentation.
- Actively solicit community for feedback and suggestions to ensure we account for all
aspects of the problem domain
- Evaluate and monitor other presentation framework efforts to fully understand the
pros/cons of existing approaches
- Focus on creating an architecture that is
- open ended and flexible (allowing developers to use as much or as little of the
framework as they desire)
- interoperable and portable (allowing for coexistence with other approaches and avoiding
vendor lock-in)
- incredibly easy to learn and use (making it the obvious path of least resistance)
4.2
Risk: Legacy application support -
Application maintenance is a fact of life; frameworks that can not integrate well with
existing applications or alternate development approaches may not be useful to developers
in the trenches.
Mitigation Strategy - We believe there are a number of things we can do to help
minimize this risk:
- Ensure the existing Enhydra 'Super Servlet' and Presentation Object model can be
incorporated within the new framework. This will allow enhancements to existing
Enhydra applications to occur within the new framework without modifying existing code.
- Allow for incremental adoption of the Barracuda framework as much as is possible.
- Provide a clear migration path for alternate approaches to make it easy to move to the
Barracuda framework.
4.3
Risk: Performance concerns - Scalability
and throughput are major issues for most web application developers. Creating layers of
abstraction inevitably adds overhead which eats away performance or increases system
resource requirements. Significant performance degradation can impede widespread
acceptance of the Barracuda framework.
Mitigation Strategy - Historically, many of
these same concerns have been applied to Java and OO development in general, where it has
been demonstrated that in many cases performance concerns can be minimized simply through
good design and development processes. In addition, we see several specific ways to
further offset these risks:
- Ensure object designs can easily be modified to provide optimization routines such as
object pooling.
- Take precautions to avoid breaking backward compatibility with previous releases
- Make framework components configurable where possible to allow for performance tuning at
runtime
- Perform regular performance audits of the Barracuda framework
- Evaluate Barracuda in the context of real-world applications to ensure sufficient
"reality factor" in our performance testing
- Develop a performance oriented testing suite that
- provides a basic performance analysis for major components within the Barracuda
framework
- establishes known performance baselines and helps prevent performance degradations from
creeping into the framework over time
- makes it possible to compare Barracuda performance with that of alternative presentation
frameworks
- Create performance utilities that make it easier for developers to test the performance
of the applications they build
4.4
Risk: Security concerns - Web applications built on
Request-Response paradigm often suffer from security issues that are exacerbated by HTTP's
"connectionless" nature.
Mitigation Strategy - While this is an issue
that faces all web application development, it is critical that the Barracuda framework
makes it easier to address these types of problems.
First and foremost, we make sure the Barracuda framework itself does not introduce any
additional security weaknesses. We can work towards this goal by:
- Performing regular security audits of the Barracuda framework
- Building the notion of security into the core aspects of the flow control framework
- Develop a testing suite focused on security that
- helps prevent protocol and framework vulnerabilities
- protects the fundamental security of Barracuda framework
- ensures appropriate regression tests are developed and executed prior to all releases
In addition, we must recognize that no framework can prevent all security
vulnerabilities within application specific code. As such, we should:
- Make it easy to build secure web applications by supporting security concepts with the
Barracuda framework itself
- Clearly document common mistakes and weaknesses
- Provide lots of examples of good security practices
- Create security tools that help application developers spot potential weaknesses
4.5
Risk: Stability concerns - An development framework which
is unstable or unreliable rarely succeeds; if Barracuda does not provide a high level of
stability between releases it may be difficult to establish long term viability and win
over new developers.
Mitigation Strategy - We feel that the best
means to ensure stability is through a combination of sound design, quality
implementation, and thorough testing. There are a number of ways this plays itself out:
- Provide regular releases incorporating the latest fixes and enhancements to ensure rapid
turnaround and quick response time
- Create a rigorous testing suite that
- contains comprehensive unit and regression test subsystems (these tests should focus on
API specifications and strive for complete code coverage.)
- contains a performance test subsystem
- contains a security test subsystem
- is executed and validated prior to all releases.
- Clearly document known bugs and issues, providing workarounds whenever possible
- Encourage an open and frank discussion within the Enhydra community of Barracuda flaws
and weaknesses for the purposes of improving the overall quality of the framework
4.6
Risk: Paradigm limitations - Because the Web-Application
paradigm is based on the HTTP Request-Response protocol, there are certain fundamental
limitations due to the uni-directional nature of component communication. Unlike the
Client-Server paradigm, which usually supports bi-directional communication, with web
applications only client components can initiate communication with the server -- server
components can never contact the clients on their own. This subtle yet significant
paradigm difference, combined with the limited feature set of HTML, may ultimately limit
the amount of functional complexity that web applications can effectively handle.
Mitigation Strategy - The best way of
handling this risk is primarily to acknowledge its presence and to recognize that
Web-Applications may not be the best solution for every problem domain. Nevertheless, we
still see tremendous room for improvement, and believe that a high quality presentation
layer can significantly extend the overall complexity that can be appropriately handled
with web applications.
5
PROPOSAL
5.1 Summary
Barracuda intends to thoroughly address the web application problem domain and provide
a vision for web-based presentation layer frameworks. This approach will place the
Barracuda Presentation Framework at the forefront of current web-development approaches.
We will accomplished these objectives by:
- Relying on and improving best-of-breed object oriented design techniques
- Providing white-papers and extensive tutorials.
- Supplying lots of example code.
- Ensuring proper regression and unit testing.
These advantages should accelerate development, simplify maintenance, and decrease
total cost of ownership by providing a common architecture across web applications. This
in turn will help establish Barracuda as the de-facto standard for web-application
architectures.
5.2 Proposed
Project Schedule
Based on sound engineering methodologies, we see the Barracuda
project progressing through a series of stages captured in the following outline:
Discovery Stage
- Discovery is the cornerstone of a successful project, providing the foundation for any
useful framework. It can be broken into six distinct phases, each of which provide an
important set of process control documents that capture the information needed to drive
development. The resulting documents detail the development objectives, the solution
architecture, the development plan, and a detailed project plan.
The Discovery stage phases are:
- Scope - "How Big is Discovery"
- Requirements - "Define the Problem"
- Analysis - "Define the Functionality"
- Architecture - "Lay Out the Blueprint"
- Prototype - "Demonstrate the Solution"
Confirmation - "Verify the Solution"
Development Stage
- Development is where the actual framework development occurs. In large, multi-faceted
frameworks like Barracuda, we intend to provide deliverables incrementally, rather than in
a single monolithic block. The benefits of this approach include more immediate developer
feedback, faster course corrections, and a better overall framework.
Process control in this stage revolves around change control
procedures to accommodate evolving develop requirements.
Development is divided into four phases:
- Engineering Design - "Document the Detailed Design"
- Incremental Development - "Build It"
- System Test - "Test It"
Community Preview - "Feedback &
Adjustment Loop"
Release Stage
- As the Barracuda framework approaches functional completion, we will enter a period of
beta testing and quality assurance. During this time we will be actively working to
"polish" the framework functionality, implement performance tuning, create
developer documentation and tutorials, and then ultimately release the framework into
production.
- Maintenance Stage
- Once the Barracuda has been released, we will enter a maintenance mode aimed at
improving the framework based on actual developer feedback. During this time, newly
identified enhancements may start this whole process all over again as we move forward
with the next round of development to ensure that Barracuda continues to meet developer
needs and expectations.
This document represents the Scope Phase of the Discovery
process. As we move forward, we will continue the Discovery process treating each
subsystem of the Barracuda framework as its own "mini-project". This means
developers can expect to see separate requirements, analysis, and design documentation for
each of the core Barracuda subsystems:
- Forms Validation & Mapping Framework
- Model 2 Flow Control System
- Server-Side Event Model
- MVC Component Model
- MVC Component Library
- JavaScript Framework & Library
These subsystems are ranked loosely in terms of development
priority, and we expect simultaneous development to be occurring where possible. At this
point (Barracuda PR1), the first 3 phases have been completed and released for community
review. We are now shifting design emphasis to the latter three phases. We hope to include
these in beta release by the end of January.
5.3 Summary:
Schedule Risk Management
In this section we have identified a number of risks that could negatively impact our
planned development effort. We have also identified a number of management plans intended
to mitigate these risks. It is important to note that mitigation strategies rarely
eliminate identified risks or their negative impact. The goal of the mitigation strategy
is to minimize the potential negative impact. It should also be noted that this early
analysis of the risks facing this project is undoubtedly incomplete. There will be other
risks that surface during the remainder of this project. Additionally, there will be the
interaction of the identified risks.
Review of this risk assessment section drives us to conclude three fundamental
recommendations:
This development effort will be greatly benefited by a strict adherence
to standard software development methodology. We need to stay focused on an up-front
design and analysis phase for the project. Due to this projects level of complexity,
inadequate investment in the analysis phase will inevitably cause significant impact on
the projects cost and schedule. Insufficient analysis also has a high probability of
undermining the projects objective of producing a product foundation for future
development efforts.
The large number of identified risks indicates that planning with
detailed and conservative effort estimates is the only prudent management strategy. We are
currently planning with high level and optimistic effort estimates. These estimates will
invariably slip and it is likely that they will slip drastically.
Project management and clear team communication are going to be critical
to the success of this project. It will be critical to ensure that there are appropriate
and adequate resources staffed in order to ensure that the risk management plans are
executed.
|