Just as with a traditional desktop application, web applications have varying levels of risk. A personal home page is much less risky than, for example, a stock trading web site. For some projects security, software bugs, etc. are major issues. If time to market, or technical complexity is a concern, documentation, test planning, change control, requirements analysis, architectural description and formal design and construction practices can mitigate risk.
- Java EE
- Ruby, including Ruby on Rails
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 agile lifecycle models are:
- Extreme Programming
- Timebox development
- Feature Driven Development
Like traditional desktop applications, web applications undergo the same unit, integration and system testing. But because web application clients vary so greatly, teams might perform some additional testing, such as:
- Performance, Load, and Stress
- HTML/CSS validation
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.
In the case of ASP.NET, a developer can use Microsoft Visual Studio to write code. But, as with most other programming languages, he/she can also use a text editor. Notepad++ is an example.
For PHP, the Zend Development Environment provides numerous debugging tools and provides a rich feature set to make a PHP developer's life easier.
Several code generation tools such as dbQwikSite are available to automate the development of code. Using such tools, non-technical users can produce working code, and experienced coders can accelerate the development cycle.
Other tools include various browsers, FTP clients, etc.
Frameworks and Reuse
Practicing code reuse and using web application frameworks 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, 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.