Web application development: Difference between revisions

Content deleted Content added
Changed redirect target from Web application to Web application#Development
Tags: Redirect target changed 2017 wikitext editor
 
(266 intermediate revisions by more than 100 users not shown)
Line 1:
#REDIRECT [[Web application#Development]]
{{howto}}
{{Merge|web development|date=October 2006}}
 
'''Web application development''' is the process and practice of developing [[web application]]s {{Fact|date=February 2007}}.
 
==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 [[Computer security|security]], [[software bug]]s, etc. are major issues. Depending on formality, lifecycle activities can range anywhere from no planning at all, to formal [[Software documentation|documentation]], [[test plan]]ning, [[change control]], [[requirements analysis]], [[software architecture|architectural description]], design and construction practices.
 
==Technologies==
* [[Ajax (programming)|Ajax]]
* [[ASP.NET]]
* [[Cascading Style Sheets|CSS]]
* [[ColdFusion]]
* [[Java Platform, Enterprise Edition|Java EE]]
* [[JavaScript]]
* [[PHP]]
* [[Ruby (programming language)|Ruby]]
 
==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 software development|Agile]] practices. Some lifecycle models are:
 
* [[Agile software development|Agile]] ([[Extreme Programming]], [[Scrum (development)|Scrum]], [[Timebox]] development, [[Feature Driven Development]], etc.)
* [[Software prototyping#Evolutionary prototyping|Evolutionary prototyping]]
* Staged delivery
* Evolutionary delivery
* [[Spiral model|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 [[Software testing|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 testing|Performance]], [[Load testing|Load]], and [[Stress testing|Stress]]
 
Also, since [[web application]] clients can be a variety of [[Web browser|browsers]], [[operating system]]s, displays and even different devices in the case of mobile phones and [[Handheld device|handhelds]], and that users will vary greatly in preferences and [[Web accessibility|accessibility]] needs, many tests for the presentation of the application exist. Here are some:
 
* Compatibility tests:
** [[Web browser|Browser]]
** [[Operating system]]
** Different display resolutions
** Browsing impediments (e.g. no images, no [[JavaScript]], etc.)
* [[HTML]]/[[Cascading Style Sheets|CSS]] validation
* [[Web accessibility|Accessibility]]
* [[Usability testing|Usability]]
* [[Performance Engineering|Performance]] (download speed)
 
Many types of tests are [[Test automation|automatable]]. At the [[Component test|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 [[Web browser|browsers]], [[File Transfer Protocol|FTP clients]], etc.
{{Sectstub}}
 
==Frameworks and Reuse==
Practicing [[code reuse]] can greatly improve both productivity and [[time to market]] (McConnell 1996:537). Reusing externally developed [[Software componentry|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 [[Application programming interface|API]]s. Also, if a component is essential to the business, an organization might want to control its development.
 
Some common [[framework]]s are:
* [[Ruby on Rails]]
* [[CakePHP]]
* [[.NET Framework|.NET]]
 
==See also==
*[[Device Independence]]
*[[List of Web based applications]]
*[[Search engine optimization]]
*[[Web Interoperability]]
 
==References==
*{{cite book | last = McConnell | first = Steve | authorlink = Steve McConnell |
title = Code Complete, Second Edition | publisher = Microsoft Press | date = June 2004 |
pages = 960 | id = ISBN 0-7356-1967-0 }}
*{{cite book | last = McConnell | first = Steve | authorlink = Steve McConnell |
title = Rapid Development | publisher = Microsoft Press | date = July 2, 1996 |
pages = 680 | id = ISBN 1-55615-900-5 }}
*{{cite book | last = Rozanski | first = Nick | coauthors = Eóin Woods |
title = Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives | publisher = Addison-Wesley Professional | date = April 20, 2005 |
pages = 576 | id = ISBN 0-321-11229-6 }}
*{{cite book | last = Leffingwell | first = Dean | coauthors = Don Widrig |
title = Managing Software Requirements: A Use Case Approach, Second Edition |
publisher = Addison-Wesley Professional | date = May 16, 2003 | pages = 544 |
id = ISBN 0-321-12247-X }}
 
==Further reading==
*{{cite book | last = Whittaker | first = James A. | coauthors = Mike Andrews |
title = How to Break Web Software: Functional and Security Testing of Web Applications and Web Services | publisher = Addison-Wesley Professional | date = February 2, 2006 |
pages = 240 | id = ISBN 0-321-36944-0 }}
 
[[Category:Web applications]]
[[Category:World Wide Web]]
[[Category:Web development]]