There is a lot of jargon in the software development community.  Vendors of  "portal software" will tell you that a portal has unique characteristics, including a single login for the entire site, customized content for each user, hierarchical permission levels, etc.  We think this is mostly because they want to sell you development software.  (Is The New York Times' site a website or a portal?)

Similarly, some developers distinguish between content and applications.  We don't.  For our purposes, "content" is defined as anything that conveys information to the user.  So, text, images, but also user forums, e-commerce gateways, and so forth.

In addition, there is a lot of jargon surrounding the actual development process.  For many years, the "Waterfall Model" was in vogue, though this is an adaptation from the world of manufacturing and does not translate well to the world of software development.  Other methods include a Spiral Model and an Agile Model.  We cringe at all this jargon, and many of our customers have never heard of these models, but in a nutshell, the process is as follows:

1. Meet with the client to identify all stakeholders.
   
   
2. Brainstorm with all stakeholders to create "user stories"-- short statements that capture the functions that users seek from their web presence.  An example of this would be a statement such as: "As head of marketing, I would like to know who has visited our site in the past week." By definition, user statements are general, and refer to the functional, rather than technical, requirements that the end user seeks.
   
   
3. The client is then asked to rank user statements in order of priority.  This leads naturally to discussions of what content is required, and where it should go on the site.  We collect any existing content assets (text, images, logos, etc.) at this time.
   
   
4. The development team creates a "wire-frame" of the site—a schematic diagram of what content will go where, how it will be linked, and so forth.  At this time, we also come up with an estimate of the time and effort necessary to complete the project, and we submit a proposal (known in French as an Offre Technique et Financière) to the client.
   
   
5. Once the client has agreed to the proposal and wire frame, the actual development process begins.  The model that most closely describes our process is the Agile model. (Hey, we've been to business school too.) The process is divided into small increments of short duration, with the objective being to provide the client with a functioning component in approximately two weeks' time.  Our developers self-select to work on various parts of the project, with an emphasis on small, multidisciplinary teams.  Initially, one team might work on the template, and, in close coordination with the template team, another team will work on the stylesheet.  These days, Cascading Style Sheets control much more than colors, fonts, etc. (indeed, most of our layouts are purely CSS-driven), so design and layout are intimately linked.  Other teams will simultaneously work on "pure" content (i.e., the narrow definition of content-- text, images, and so forth).
   
   
6. At the end of each incremental stage, we meet with the client to show progress to date and to respond to feedback. Through this iterative process of incremental development, our development teams meet frequently for short "standup" meetings to identify any roadblocks and to allow for cross-pollination among teams.
   
   
7. Testing and customer feedback is a continuous process, so that problems are identified early and addressed before they become calcified in code.  Typically, we will prototype beta versions in a test environment with actual future end-users where possible.
   
   
8. Upon sign-off from the client, the site goes live.  Anapurna Web Design continues to work with the client regularly in the early stage of live deployment, making any final changes necessary, and once again after a period of time in live deployment, typically after three to six months.  We tend to keep a version of the live site in our test environment so that we can perfect any required changes and deploy them in the live environment when all the kinks, if any, are worked out.
   
   

The overarching principle of the Agile process is that it is non-linear, so if (as inevitably happens) the client discovers a new functional capability that he or she seeks, the entire process does not have to start again at square one.  The client is involved in every step of the process.