Hardware Reference
In-Depth Information
on a waterfall style model. Only the two companies using RUP had a fully docu-
mented process. The company using an Agile approach had a partially documented
process and the two companies using an internally developed process had not docu-
mented it at all. Analysis of the development process revealed that all five companies
were knowledgeable and clear in describing the steps that they follow, regardless of
whether it was documented or not. All but one of the companies believed the process
was being followed in all projects. However, four out of five companies also cited
deviations from the process.
An interesting finding was that three of the companies had recently undergone sig-
nificant improvements to their processes. One company had hired a project manager
with the responsibility of establishing a more structured, repeatable development
process. Another set up a new test team and formalized the build process. It was evi-
dent that these companies were moving in the right direction while still being aware
that they had more improvements to make.
None of the companies were following any of the available development models
without having customized it to their needs. When describing their development proc-
ess, all five companies reported having a Requirements Analysis phase at the begin-
ning of the lifecycle. Much of the literature cites poor requirements as the cause of
many subsequent problems in the software. But [21] believe that in web projects,
clients do not have a clear enough understanding of their requirements at the begin-
ning of a project for existing software processes to be effective. They believe that web
development companies should adopt an iterative approach that incorporates client
developer interaction and that assesses partial designs in order to clarify the client's
requirements. Although only one company cited poor Requirements Analysis as a
problem in their process, there appears to be a lack of awareness that a key advantage
of the iterative design process is its ability to involve the end user early in the product
lifecycle. Of the three companies following an iterative process, only two delivered
interim software builds to the client. But both of these companies described the client
as a distinct entity to the end user of the system. Delivery of the builds appeared to be
more to meet the contract deliverable rather than a design tool.
The literature suggested that web application development can be likened to the
early days of traditional software development, when applications were mostly being
developed in an ad-hoc manner. But this study has revealed that all five case studies
have a defined development process. Although the process may not have been docu-
mented in two cases, all of the companies were able to clearly describe the steps in-
volved in their process and believed it to be a clearly defined, repeatable process.
They were also able to acknowledge deviations from the defined process. These find-
ings suggest that although there appears to be a need for a process suitable to small
companies developing web applications, practices are more formal than anecdotal
evidence suggests.
4.2 Usability Awareness
All of the companies had very little awareness of usability standards, with only one
company having a good knowledge of usability. Most of the companies believed
usability was well represented in their development process and that usability aware-
ness was good throughout the company. It emerged that two companies had a limited
