Specifications

increase the amount of dynamic content in Web sites to the level in which Web sites offer ser-
vices rather than documents, this paradigm no longer fits. Many people do not think to use
software engineering practices for a project at all.
The second reason software engineering practices are not used is that Web application develop-
ment is different from normal application development in many ways. We deal with much
shorter lead times, a constant pressure to have the site built now. Software engineering is all
about doing things in an orderly, planned manner, and spending time on planning. With Web
projects, often the perception is that we don’t have the time to plan.
When we fail to plan Web projects, we end up with the same problems as if we fail to plan any
software project: buggy applications, missed deadlines, and unreadable code.
The trick, then, is in finding the parts of software engineering that work in this new discipline
of Web application development, and discarding the parts that don’t.
Planning and Running a Web Application Project
There is no best methodology or project lifecycle for Web projects. There are, however, a num-
ber of things you should consider doing for your project. We’ll list them here, and talk about
some of them in more detail in the following sections. These considerations are in a specific
order, but you don’t have to follow this order if it doesn’t suit your project. The emphasis here
is on being aware of the issues and choosing techniques that will work for you.
• Before you begin, think about what you are trying to build. Think about the end goal.
Think about who is going to use your Web application; that is, your targeted audience.
Many Web projects that are technically perfect fail because nobody checked that there
were interested users for such an application.
• Try and break your application down in to components. What parts or process steps does
your application have? How will each of those components work? How will they fit
together? Drawing up scenarios, storyboards, or even use cases can be useful for figuring
this out.
• After you have a list of components, see which of these already exist. If a prewritten
module has that functionality, look at using it. Don’t forget to look inside and outside
your organization for existing code. Particularly in the Open Source community, many
preexisting code components are freely available for use. Decide what code you have to
write from scratch and roughly how big a job that is.
• Make decisions about process issues. This is ignored too often in Web projects. By
process issues, I mean things such as coding standards, directory structures, management
of version control, development environment, documentation level and standards, and
task allocations to team members.
Using PHP and MySQL for Large Projects
C
HAPTER 22
22
USING PHP AND
MYSQL FOR
LARGE
PROJECTS
461
28 7842 CH22 3/6/01 3:37 PM Page 461