Information Technology Reference
In-Depth Information
messengers, wikis, defect-tracking tools and change-management tools,
intranet capabilities, and so on, to ensure that information/documentation
is available and up-to-date. Electronic exchange is preferable, as it is fast and
easy to share among team members and end users. Promote teamwork and
cooperation; use prototypes and/or continuous communication with end
users if possible to clarify expectations.
1..
Deinition of Software Quality
From the perspective of the customer, outsourcer, or any other stakeholder, the
definition of software quality may vary. However, on a broader level we can say
that good-quality software is reasonably defect-free, is delivered on time and within
budget, meets requirements, meets expectations, and is maintainable.
Let us face it:
quality
is a subjective term. So software quality will depend on
who the customer is and the customer's involvement in the overall software project.
Enterprise software applications are used by many people at the customer organi-
zation like customer support people, factory shop personnel, clerks, accountants,
and in fact most of the people working for that customer. So here the customer
can be defined as the end users, customer acceptance testers, customer contract
officers, customer management, the development organization's management,
accountants, testers, salespeople, future software maintenance engineers, stock-
holders, and so on. Each type of customer who will be evaluating the value of the
software application will have their own way of defining and measuring quality;
for example, the accounting department might define quality in terms of return
on investment, while an end user might define quality as user-friendliness and a
defect-free product.
1.. Deinition of Good Design
Good software design is the design that incorporates the latest but proven technol-
ogy, has a scalable structure, facilitates easy integration with other systems, and is
flexible to allow incorporating changes in requirements. If the design is built for
older technology, then the system might become obsolete too soon. For example, if
the design team thinks of using mainframe technology, then it is not appropriate.
Similarly if the design team thinks of employing some new unproven technology,
then it could be a great risk that the application after development may become
obsolete soon as the new technology has failed. Businesses always keep on expand-
ing, and any system deployed should also scale up nicely so that the new needs of
the customer are incorporated in the application when they arise in the future.
Nowadays there are too many legacy systems for fulfilling different business needs
within the customer's premises as well as the application needs to be integrated with
