|
#REDIRECT [[Web 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 server]]s 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 [[Computer security|security]], [[software bug]]s, [[Software documentation|documentation]], etc. are major issues.
==Planning and Management==
Planning and management also depend on the formality of the project. On informal projects, organizations can plan the project incrementally. On more formal projects, organizations might need to do at least basic, up-front project planning. On informal projects, [[Software testing|testing]] can be planned as-needed, but formal projects should do at least some of this [[Test plan|planning]] up front. QA planning can be done as-needed in either case. And while [[change control]] can be informal on informal projects, it should be formal on formal projects.
==Upstream Activities==
The results of shortchanging upstream activities are predictable. Organizations that skimp on them will have to eventually do them anyway, at 10 to 100 times the original cost. (McConnell 1996:45).
===Problem Definition===
You first must understand what problem your web application will solve. Know who your users and stakeholders are. Then you must understand what their needs and challenges are. Understand the [[root cause]] of the problem, as well as any constraints imposed on the solution. Once you understand who your users are and what their needs are, you can come up with a list of features that satisfy those needs.
===Requirements Definition===
; requirement :
#A software capability needed by the user to solve a problem to achieve an objective
#A software capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documentation
(Leffingwell & Widrig 2005:15)
Depending on the formality of the project, [[requirement]]s specifications can be either informal or semi-formal. On more formal projects, requirements should also be reviewed as-needed.
===Architectural Description===
; Architectural description : An architectural description (AD) is a set of products that documents an architecture in a way its stakeholders can understand and demonstrates that the architecture has met their concerns. (Rozanski & Woods 2005:175)
On more formal projects with more up-front planning, an [[Software architecture|architectural description]] can be beneficial. Also, this might be the place to specify if you'll [[Code reuse|reuse]] any pre-built components, or build any components for future reuse.
==Technologies==
* [[PHP]]
* [[ASP.NET]]
* [[Ruby (programming language)|Ruby]]
* [[Cascading Style Sheets|CSS]]
* [[JavaScript]]
* [[Ajax (programming)|Ajax]]
==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, etc.)
* [[Software prototyping#Evolutionary prototyping|Evolutionary prototyping]]
* Staged delivery
* Evolutionary delivery
* [[Spiral model|Spiral development]]
==Design==
On informal projects, design and coding can be combined. But on more formal projects, a separate [[Software architecture|architectural description]], informal detailed designs and as-needed design reviews can be beneficial.
==Construction==
Programmers can program individually, or in pairs (as in [[Extreme Programming]]). And depending on criticality, the project might need an informal code check-in procedure and as-needed [[code review]]s. (McConnell 1996:48)
==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. [[Cascading Style Sheets|CSS]] failure, no images, no [[JavaScript]], etc.)
* [[HTML]]/[[Cascading Style Sheets|CSS]] validation
* [[Web accessibility|Accessibility]]
* [[Usability testing|Usability]]
* [[Performance Engineering|Performance]] (download speed)
===Unit and GUI test automation===
Many types of tests are [[Test automation|automatable]]. At the [[Unit test|unit]] level, one of the [[XUnit|xUnit]] packages can be a helpful tool. Or an organization can create its own unit testing framework. At the GUI level, [[Watir]] is useful.
==Deployment==
Deployment describes what software runs on which hardware. The act of deployment involves installing the necessary software on the hardware. Again, depending on the formality of the project, the deployment procedure can be either formal or informal.
==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.
==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]]
===Building Reusable Components===
Evidence suggests that smaller, more specific components are better targets for reuse than larger, more generalized ones. (McConnell 1996:533) And it pays to question whether or not reuse will be worthwhile in the end. For example, if you only plan to build one photo sharing web site, the resources put into making your components reusable might not pay off. But if you plan to build several photo sharing web sites, reuse is almost necessary. (McConnell 1996:492)
==Search Engine Optimization==
In the case of a public web site, as opposed to an [[Intranet]] or otherwise private site, it is usually very beneficial to have high [[search engine]] rankings.
==See also==
*[[Device Independence]]
*[[List of Web based applications]]
*[[Web Interoperability]]
==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 0321369440 }}
==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 0735619670 }}
{{cite book | last = McConnell | first = Steve | authorlink = Steve McConnell |
title = Rapid Development | publisher = Microsoft Press | date = July 2, 1996 |
pages = 680 | id = ISBN 1556159005 }}
{{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 0321112296 }}
{{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 032112247X }}
[[Category:Web applications]]
[[Category:World Wide Web]]
| 