| Content of these pages are owned and copyrighted by the poster. | |
| Hosted by: |
|
&<&P&R&E&>&& &T&a&b&l&e& &o&f& &C&o&n&t&e&n&t&s&& && &1& &I&n&t&r&o&d&u&c&t&i&o&n&& & & & &1&.&1& &T&h&e& &W&a&t&e&r&f&a&l&l& &a&n&d& &T&h&e& &C&a&t&h&e&d&r&a&l&& & & & &1&.&2& &T&h&e& &B&a&z&a&a&r&& & & & &1&.&3& &T&h&e& &G&u&i&d&e&d& &B&a&z&a&a&r&& && &2& &T&h&e& &G&o&a&l&s& &o&f& &O&u&r& &P&r&o&c&e&s&s&& & & & &2&.&1& &O&p&e&n&n&e&s&s&& & & & &2&.&2& &W&e&b&-&w&i&d&e& &p&a&r&t&i&c&i&p&a&t&i&o&n&& & & & &2&.&3& &S&p&e&e&d&& & & & &2&.&4& &M&o&d&u&l&a&r&i&t&y&& & & & &2&.&5& &S&e&l&f&-&D&o&c&u&m&e&n&t&i&n&g&& & & & &2&.&6& &S&e&l&f&-&T&r&a&c&k&i&n&g&& & & & &2&.&6& &T&e&c&h&n&i&c&a&l& &e&x&c&e&l&l&e&n&c&e&& & & & &2&.&7& &R&e&c&o&g&n&i&t&i&o&n&& && &3& &H&o&w& &W&e& &D&e&v&e&l&o&p& &J&O&S&& & & & &3&.&1& &D&o&c&u&m&e&n&t& &N&a&m&i&n&g& &C&o&n&v&e&n&t&i&o&n&s&& & & & &3&.&1& &P&o&s&i&t&i&o&n& &P&a&p&e&r&s& &(&P&O&S&)&& & & & &3&.&2& &R&e&q&u&e&s&t& &f&o&r& &P&r&o&p&o&s&a&l& &(&R&F&P&)&& & & & &3&.&3& &R&e&q&u&e&s&t& &f&o&r& &S&p&e&c&i&f&i&c&a&t&i&o&n& &(&R&F&S&)&& & & & &3&.&4& &R&e&q&u&e&s&t& &f&o&r& &I&m&p&l&e&m&e&n&t&a&t&i&o&n& &(&R&F&I&)&& & & & &3&.&5& &R&e&q&u&e&s&t& &f&o&r& &C&h&a&n&g&e& &(&R&F&C&)&& & & & &3&.&6& &R&e&q&u&e&s&t& &f&o&r& &A&c&t&i&o&n& &(&R&F&A&)&& & & & &3&.&7& &S&u&b&m&i&s&s&i&o&n&& & & & &3&.&8& &T&h&e& &J&O&S& &V&o&t&i&n&g& &P&r&o&c&e&s&s&& & & & &3&.&9& &J&O&S& &P&r&o&c&e&s&s& &D&i&a&g&r&a&m&&
| | |||
| Version | Author | Description | Date |
| Draft | Eric Griffin | For Review | 26-JUL-98 |
1.The Waterfall and The Cathedral
No matter what development process you use, all have a foundation in the granddaddy of all life cycle models. The waterfall model. It has many problems, but it serves as the basis for other, more efficient lifecycle models. In the waterfall model, a project progresses through an orderly sequence of steps from the initial software concept through system testing. The waterfall model is document driven, which means the main work products that are carried from phase to phase are documents. These documents are reviewed at the end of each phase to determine whether it is ready to advance to the next phase. The pure waterfall model performs well when you have a stable resource base and a stable product definition. It provides the stability and clear vision of the final product that developers crave.
The waterfall model works especially well if you have technically weak staff or inexperience staff because it provides the project with a structure that helps to minimize wasted effort. The disadvantages of the pure waterfall model arise from the difficulty in fully specifying requirements at the beginning of the project and its dependency on a constant experienced resource base to drive the process forward.
The waterfall development process and its derivatives have been metaphorically described as the Cathedral. The Cathedral represents the monolithic nature of traditional development with its' constant resource base and core team leadership.
Adapting Cathedral development models to software projects that have a dynamic resource base and no clear vision of the final product, as is the case with many Internet software projects, proves nearly impossible. This was true until the Bazaar style development process.
2.The Bazaar
The Bazaar style development process is demonstrated by the most celebrated Internet software project to date. Linux.
The legend began with a student of the University of Helsinki in Finland. His name was Linus Torvalds and he started Linux out as a hobby in 1991. He wanted to create a replacement for the Minix operating system, an UNIX-like operating system available for intel-based PCs.
He invited the programming community to help him create a better Minux. The rest is history. Despite an undefined resource base and a lack of a common vision other that to "create a better Minix", Linux has been developed to the point where it competes with commercial operating systems in quality, features and stability.
Figure 2 The Bazaar
Note that new inputs comes from every where
An undefined resource base that contributes to an undefined vision of a product characterizes the Bazaar development model. Each resource that contributes to the product has their own personal vision of what they want in the product. This is the fundamental motivation for dedicating personal time to contribute to the product. It also makes the product evolve in "internet-time" because there are many personal sub-projects that add to the whole.
Key to its success, however, lies with a centralized individual or body that functions as the products core team leadership. This leadership filters the individual visions into a unified vision.
The downside to this development model, because of a diverse and de-centralized resource base, is the varying standards of documentation, design and implementation.
Unlike the waterfall model, the Bazaar does not provide the project with a structure that helps to minimize wasted effort. Without a strong central body, the product also risks loosing direction as many personal ideas and sub-projects are entered into the product. And there are no formal process of discussing and choosing a common product vision, technology or standards.
3.The Guided Bazaar
The JOS development process is an evolutionary step in Internet software development. The intent is to take the best from both the Waterfall and the Bazaar style development models.
Figure 3 The Guided Bazaar
Note that new inputs are requested or "guided" into the JOS Project.
From the waterfall we take the underlying structure. Through RFP (Request for Proposal), RFS (Request for Specification) and other request documents, we hope to galvanize and guide the JOS membership and outside resources to respond with the best of breed technical solutions. More traditional mechanisms like documentation, specification and coding standards that will guide technically weak contributors to produce professional quality technology .
From the Bazaar we will take the ability to tap into the ideas of the limitless resource base of the Internet community. However, we will have a structure that will allow new ideas to be requested, heard, discussed and chosen by the JOS membership.
2 The Goals of Our Process
The JOS Project develops and evolves JOS specifications in "Internet-time", by using an open process that produces high-quality specifications.
The five goals that drive it: openness, web-wide participation, speed, modularity, self-documentation, self-tracking, technical excellence and recognition. We believe that this process is fundamental to JOS's success because of the volunteer nature of free software projects.
2.1 Openness
Any person can participate in the process by simply becoming a JOS member. The only requirement is that they have access to the Internet.
All specifications must are open, free of any constraints or restrictions associated with intellectual property rights (IPR). Anyone wishing to contribute to JOS specifications must be willing to do so without imposing IPR barriers. We believe strongly in fostering competition around the technologies described by JOS specifications. Anyone should be able to produce a complete implementation of the technology described by JOS specifications without cost or red tape.
2.2 Web-wide participation
Once the individual becomes a member they have an opportunity to review, comment on, and contribute to JOS specifications. The best way to do this is to participate in the free form, dynamic JOS Collaboration Area. Here anyone can conduct a web-wide public review of his or her draft specifications or position papers. At the cost of a simple Internet connection, our process builds consensus on a truly international scale
2.3 Speed
Because JOS is has a volunteer workforce, it is very important to keep tasks as short as possible. Volunteers have many outside forces (i.e. Job, family, school) that effect the amount of time spent on outside activities. Time constraints on steps within the process increase speed by encouraging smaller milestones that can fit into any schedule.
2.4 Modularity
The dynamics of a volunteer workforce dictate that the JOS process be modular. The process accounts for the possibility of a developer not following a specification through implementation. The process divides itself into several steps. Each step produces a part of the specification that can be picked up by another developer. This insures that a specification can continue to completion with different resources.
2.5 Self-Documenting
Because of the possibility of a developer not following a specification through the entire process. It is important that each step in the process produce complete, high-quality documentation.
2.6 Self-Tracking
Dividing the process into clearly defined steps make the progress of a specification easily traceable. Each step in the JOS development process is assigned time estimation. Metrics can be gathered to evaluate performance and fine tune requests to meet realistic goals.
2.6 Technical excellence
We develop all JOS specifications with the active participation of computer experts and industry leaders. In this way, each specification embodies best of breed technology along with innovation that benefits every system on which the JOS platform is implemented. As such, no specification will ever lock implementers or users into a single company's proprietary technology or be tied to just one computer processor or operating system.
2.7 Recognition
Unlike other free software projects, the JOS project acknowledges the time spent by volunteer developers. Any JOS member can enter time sheets, verified by actual contributions to the JOS project. This time recognition can be used to provide reference letters to potential employers or proof of experience.
On To JOSProcDevelop
3 How We Develop JOS
The JOS Development Process is a consensus building process. The process provides the structure for specification development and implementation.
3.1 Document Naming Conventions
All JOS related document use the following the naming convention:
JOS-XXX-0000
JOS-(JOS Project Identification)
Because all JOS documents can be published on non-JOS related lists and newsgroups (to attract new volunteer developers), it is necessary to relate the document to the JOS project.
XXX-(JOS Document Type)
A three-letter abbreviation of the JOS document type, (i.e. RFP,RFS etc..)
0000-(JOS Specification Track)
A unique number used to identify related specification documents. For example a JOS-RFP-0022 and JOS-RFS-0022 would be related to the same specification (0022). The specification track number must be assigned by the JOS Project Coordinator at jos-admin@jos.org.
3.1 Position Papers (POS)
A position paper is a means by which members can express their ideas about the technology direction of JOS. They can be used to build member support for the idea or as a prelude to a Request for Proposal (RFP). It has no bearing on the process and stands alone. The author must request a new identifier to publish a position paper.
3.2 Request for Proposal (RFP)
An RFP is the first step in the beginning of the JOS process. It is a document used to describe a general JOS Project technology requirement.
The document must describe the general goals and guidelines of the proposal including, end user characteristics, design considerations and general constraints without being specific. RFPs are required to meet a proposal response deadline of 2 to 4 weeks.
After requesting a new RFP identifier (0000), the RFP is written and a response deadline is established, it is published on the JOS web site and optionally posted to non-JOS-related newsgroups, web sites and lists to attract new talent to the JOS membership.
(See JOS-TPL-001 for detailed guidelines about RFPs. See JOS-TPL-002 for detailed guideline about a RFP response proposal.)
All responding proposals are posted for review before voting. Formal input can be entered at the Review section JOS member area of the administration site. In the JOS collaboration area, merits of each proposal can be discussed in an informal forum. This helps build consensus and allows the proposal authors to further explain or elaborate on ideas.
3.3 Request for Specification (RFS)
The next step after a proposal has been voted through is the Request for Specification. The purpose of RFS is to request a specification document that will provide a detailed design based on the proposal. RFSs are required to meet a specification response deadline of 2 to 8 weeks.
Along with all of the information found in the RFP, this document must outline the basic requirements of a specification document including design drivers, reuse strategy, high-level diagrams, performance considerations and overall sub-system overview. It also must include Javadoc documentation of interfaces, in-use sample code from a developer's prospective and screen-shots or diagrams if necessary.
After assigning the same identifier (0000) as the RFP to the RFS, the RFS is written and a response deadline is established, it is published on the JOS web site and optionally posted to non-JOS related newsgroups, web sites and lists to attract new talent to the JOS membership.
(See JOS-TPL-003 for detailed guidelines about RFSs. See JOS-TPL-004 for detailed guideline about a RFS response specification document.)
All responding specification documents are posted for review before voting. Formal input can be entered at the Review section JOS member area of the administration site. In the JOS collaboration area, merits of each specification can be discussed in an informal forum. This helps build consensus and allows the proposal authors to further explain or elaborate on ideas.
3.4 Request for Implementation (RFI)
After a proposal has been created and a specification document has been created the next step is to create an implementation. The implementation is actual Java or C/C++ code that will be integrated into the current JOS code base. The RFP is a document that specifies the requirements for implementing a RFS.
Along with all of the information provided in the RFP and RFS the response to the RFI will include an archive (*.zip, *.tgz) of source code, binaries, build script, test suite and any additional documentation. ( see JOS Implementation Guidelines JOS-DOC-002)
After assigning the same identifier (0000) as the RFP, RFS to the RFS, the RFS is written and a response deadline is established, it is published on the JOS web site and optionally posted to non-JOS related newsgroups, web sites and lists to attract new talent to the JOS membership.
(See JOS-TPL-005 for detailed guidelines about RFIs. See JOS-TPL-006 for detailed guideline about a RFI response specification document.)
All responding specification documents and source code are assigned a Submission ID (SMT) and a revision number and posted for review and testing before voting. Formal input and testing/quality results can be entered at the Review section JOS member area of the administration site. In the JOS collaboration area, merits of each implementation can be discussed in an informal forum. This helps build consensus and allows the implementation authors to further explain or elaborate on ideas.
3.5 Request for Change (RFC)
The RFC's purpose is to provide a mechanism to request a change in an approved JOS specification. Used to describe a change in a general JOS Project technology specification. The document can describe the general goals and guidelines of the change including, end user characteristics, design considerations and general constraints without being specific. RFCs are not used to correct mistakes. They are used to change a technology direction. RFCs are required to meet a proposal response deadline of 2 to 4 weeks.
After assigning a unique identifier (0000) to the RFC, the RFC is written and it is published to the JOS web site for review. The JOS community with the voting process must approve the RFC. If the RFC passes the vote then it moves into the RFP(see section 3.2) stage.
(See JOS-TPL-007 for detailed guidelines about RFCs.)
3.6 Request for Action (RFA)
The RFA's purpose is to provide a mechanism to galvanize the JOS membership to solve a JOS process or organizational related problem.
For example:
A new Perl script needs to be written for the JOS web site Testing tools for the JOS development kit need to be written. Documentation for a JOS sub-process needs to be written.
After assigning a unique identifier (0000) to the RFA, the RFA is written and it is published to the JOS web site for review. The RFA must be approved by the JOS community by the voting process.
(See JOS-TPL-008 for detailed guidelines about RFAs.)
3.7 Submission
All responses to RFPs,RFS etc.. must follow minimum guidelines to be considered for review and voting. These guidelines are outlined in templates for the respective document types.
To Summarize:
JOS-TPL-001 Request For Proposal
JOS-TPL-002 Response to RFP
JOS-TPL-003 Request For Specification
JOS-TPL-004 Response to RFS
JOS-TPL-005 Request For Implementation
JOS-TPL-006 Response to RFI
JOS-TPL-007 Request For Change
JOS-TPL-008 Request For Action
| Content of these pages are owned and copyrighted by the poster. | |
| Hosted by: |
|