The revolution of the World Wide Web and the significant impact it has had on the growth of the global economy, education, healthcare, and our society (Kappel et al., 2004) makes the creation of web systems increasingly important to the business strategy of many companies. Essentially the Web has created a new way of trading, enabling cross country selling in a manner which was not as easily achievable before.
The creation of a web site for many businesses often draws in new trade and has a significant impact on the nature of the interaction that an organisation has with its clients and other external stakeholders. This impact will typically lead to a change in internal business processes and on the company’s business model (Lowe, 2004).
Previous to the phenomenon of the web most traditional systems were generally designed and implemented to resolve internal business process problems. Often improving and streamlining existing manual practices, but rarely altering the core business model or the interaction with clients.
Traditional software development often tends to focus on developing systems to enhance internal company processes. Requirements are known to clients as the system will be for an existing process, and simply need to be elicited. This is achieved from analysing existing processes and documentation (Lowe, 2004). However the implementation of a web system is likely to provide a new outlet for a company’s products or services altering their business model and the way they interact with stakeholders. As the system will interface with external influences it will not be possible to only gather requirements from existing sources and processes. Requirements will also need to be created by working with the client, discovering their needs, and outlining the impact the solution may have on their business processes. In a simple scenario an e-commerce store may have to interface with the stock control system which may require a new staff member to monitor orders and stock levels.
Clients can often be unsure of the solution they require for their business and are often not completely knowledgeable of how their company operates, or the effect a web system will have on their operations (Lowe, 2004). This uncertainty can lead to volatile requirements, as the projects lifespan increases and the clients knowledge of their company and the technology being used increases, coupled with their high involvement in the project, can lead to the client changing existing requirements or even introducing new requirements, causing requirements creep.
End users are divorced from the web development cycle and developers are unable to predict how an end user will access the system. This is the opposite of traditional development where a company’s hardware can be analysed during the requirement elicitation phase. End users of web systems may access the system on a variety of different devices, which vary in hardware and software capabilities such as display size, computational power, network connection, or the browser they use. End users may disable scripting technologies such as JavaScript, leading to a situation where if this technology is implemented, the system may not function correctly, and alternatives need to be provided (Kappel et al., 2004).
Many web-development projects are conducted by staff comprising of many expertise groups, with little training and experience in information systems design (Carstensen & Vogelsang, 2001). “With the support of content management tools, commercial off-the-shelf products, open source solutions, prefabricated components and applets, and visual programming interfaces, designers from these backgrounds have become capable of developing complex hypermedia applications without needing to know much about programming (Lang & Fitzgerald, 2005)”.
The power of these technologies and tools to produce fully functioning web pages, coupled with many developers originating from non-technical backgrounds has lead to a belief from clients that web system projects should have a much shorter development cycle than more established traditional systems. This stereotype has introduced short project lifespan, an extremely pressurised development environment, and a lack of developer experience (Overmyer, 2000).
Despite these differences there are some similarities between the two types of development. Traditional development experienced hectic projects in its infancy. There are also many development methodologies available for traditional development. However not all traditional developers will follow these guidelines word for word, and are more likely to adapt processes to suit their experience and skill set. This has lead to methodologies which have been created through observed best practices, much like web development companies are doing today (Glass, 2003).
It’s these types of variables which have lead Glass, (2003) to believe that web development is similar to traditional development. However there are differences between the two. Jeary et al., (2009) confirm this view and suggest that web development should continue with all the disciplines the industry has learnt from traditional software development, but should also offer additional capabilities to handle the differences. The author agrees with this view. Web development could be seen as an evolution from traditional development, basic characteristics are shared, however new unique characteristics will be born upon the evolution.
Works Cited
Carstensen, P.H. & Vogelsang, L., 2001. Design of Web-Based Information Systems – New Challenges for Systems Development? In Proceedings of the 9th European Confrence on Information Systems, Global Co-operation in the New Millennium, ECIS. Bled, Slovenia, 2001.
Glass, R.L., 2003. A Mugwump’s-Eye View of Web Work. Communications of the ACM, 46(8), pp.21-23.
Kappel, G. et al., 2004. Web Engineering – Old wine in new bottles? In Proceedings of the 4th International Conference on Web Engineering., 2004. Springer-Verlag.
Lang, M. & Fitzgerald, B., 2005. Hypermedia Systems Development Practices: A Survey.
Lowe, D., 2004. Web System Requirements: an overview. Requirements Engineering, 8(2), pp.102-13.
Overmyer, S.P., 2000. What’s Different about Requirements Engineering for Web Sites? Requirements Engineering, 5(1), pp.62-65.
Amazing post thank you!
Sent via Blackberry