Web application development

This article is intended as an end-to-end reference for intermediate- and professional-level web application developers. Though it should avoid the topics of web servers and web design, there will be some overlap.

Formality

How formal the project is affects virtually every activity throughout the life of the project. More formality means more overhead. But larger projects require more planning and attention to detail. (McConnell 2004:657)

A personal home page might require less formality than, for example, a stock trading web site. At the formal end of the spectrum security, software bugs, etc. are major issues. Depending on formality, lifecycle activities can range anywhere from no planning at all, to formal documentation, test planning, change control, requirements analysis, architectural description, design and construction practices.

Technologies

Lifecycle Model

The more mission critical a project is the more formal the lifecycle should be. On the other hand, time to market, company-growth and requirements churn, three things that are emphasized in web-based business, coincide with the principles of the Agile practices. Some lifecycle models are:

Agile (Extreme Programming, Scrum, Timebox development, etc.)
Evolutionary prototyping
Staged delivery
Evolutionary delivery
Spiral development

Testing

Typically, developers test their own code. This is especially true in the case of Test-driven development. While informal projects might or might not require very little testing by a separate testing group, formal projects should be thoroughly tested. Some of the types of tests for testing the application, aside from developer testing, include:

Security
Performance, Load, and Stress

Also, since web application clients can be a variety of browsers, operating systems, displays and even different devices in the case of mobile phones and handhelds, and that users will vary greatly in preferences and accessibility needs, many tests for the presentation of the application exist. Here are some:

Compatibility tests:
- Browser
- Operating system
- Different display resolutions
- Browsing impediments (e.g. no images, no JavaScript, etc.)
HTML/CSS validation
Accessibility
Usability
Performance (download speed)

Many types of tests are automatable. At the component level, one of the xUnit packages can be a helpful tool. Or an organization can create its own unit testing framework. At the GUI level, Watir is useful.

Tools

In the case of ASP.NET, a developer can use Microsoft Visual Studio to write code. But, as with most other programming languages, he can also use a text editor. Notepad++ is an example.

Other tools include various browsers, FTP clients, etc.

Frameworks and Reuse

Practicing code reuse can greatly improve both productivity and time to market (McConnell 1996:537). Reusing externally developed components can allow an organization to reap the above benefits, while potentially saving money.

However, there are many reasons not to. For smaller components, it might be just as easy to develop your own components as it would be to learn new APIs. Also, if a component is essential to the business, an organization might want to control its development.

Some common frameworks are:

References

McConnell, Steve (June 2004). Code Complete, Second Edition. Microsoft Press. p. 960. ISBN 0735619670.

McConnell, Steve (July 2, 1996). Rapid Development. Microsoft Press. p. 680. ISBN 1556159005.

Rozanski, Nick (April 20, 2005). Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives. Addison-Wesley Professional. p. 576. ISBN 0321112296. {{cite book}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)

Leffingwell, Dean (May 16, 2003). Managing Software Requirements: A Use Case Approach, Second Edition. Addison-Wesley Professional. p. 544. ISBN 032112247X. {{cite book}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)