0% found this document useful (0 votes)
8 views

Software Quality

The document discusses software quality, emphasizing that traditional definitions like 'fitness of purpose' are insufficient for software products. It outlines key factors of software quality, including portability, usability, reusability, correctness, maintainability, reliability, and efficiency. Additionally, it describes design classes in software architecture, detailing their characteristics and types, which help in refining analysis classes into implementable design representations.

Uploaded by

nayna sawant
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
8 views

Software Quality

The document discusses software quality, emphasizing that traditional definitions like 'fitness of purpose' are insufficient for software products. It outlines key factors of software quality, including portability, usability, reusability, correctness, maintainability, reliability, and efficiency. Additionally, it describes design classes in software architecture, detailing their characteristics and types, which help in refining analysis classes into implementable design representations.

Uploaded by

nayna sawant
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 7

 Software Quality – Software Engineering

Traditionally, a high-quality product is outlined in terms of its fitness


of purpose. That is, a high-quality product will specifically be what the
users need to try. For code merchandise, the fitness of purpose is
typically taken in terms of satisfaction of the wants arranged down
within the SRS document.
-Though “fitness of purpose” could be a satisfactory definition of
quality for some merchandise like an automobile, a table fan, a
grinding machine, etc. – for code merchandise, “fitness of purpose”
isn’t a completely satisfactory definition of quality.

 What is Software Quality?


Software Quality shows how good and reliable a product is. To convey
an associate degree example, think about functionally correct
software. It performs all functions as laid out in the SRS document.
But, it has an associate degree virtually unusable program. even
though it should be functionally correct, we tend not to think about it
to be a high-quality product.
Another example is also that of a product that will have everything
that the users need but has an associate degree virtually
incomprehensible and not maintainable code. Therefore, the normal
construct of quality as “fitness of purpose” for code merchandise isn’t
satisfactory.
 Factors of Software Quality
The modern read of high-quality associates with software many
quality factors like the following:
1. Portability: A software is claimed to be transportable, if it may be
simply created to figure in several package environments, in
several machines, with alternative code merchandise, etc.
2. Usability: A software has smart usability if completely different
classes of users (i.e. knowledgeable and novice users) will simply
invoke the functions of the merchandise.
3. Reusability: A software has smart reusability if completely different
modules of the merchandise will simply be reused to develop new
merchandise.
4. Correctness: Software is correct if completely different needs as
laid out in the SRS document are properly enforced.
5. Maintainability: A software is reparable, if errors may be simply
corrected as and once they show up, new functions may be simply
added to the merchandise, and therefore the functionalities of the
merchandise may be simply changed, etc
6. Reliability: Software is more reliable if it has fewer failures. Since
software engineers do not deliberately plan for their software to
fail, reliability depends on the number and type of mistakes they
make. Designers can improve reliability by ensuring the software is
easy to implement and change, by testing it thoroughly, and also by
ensuring that if failures occur, the system can handle them or can
recover easily.
7. Efficiency. The more efficient software is, the less it uses of CPU-
time, memory, disk space, network bandwidth, and other
resources. This is important to customers in order to reduce their
costs of running the software, although with today’s powerful
computers, CPU time, memory and disk usage are less of a concern.

 Design Classes


The Requirements Model defines a set of analysis classes. Each


describes some element of the problem domain, focus on an aspect of
the problem that is visible. The level of abstraction of the analysis
class is comparatively high. The set of design classes refine analysis
classes and providing design detail that enables classes to execute a
software infrastructure that supports business solutions.
Types:
There are 5 different types of design classes that represent a different
layer of design architecture that can be developed:
1. User interface classes define abstraction that mandatory for
human-computer interaction [HCI]. In cases, HCI occurs within the
context of metaphor, and design classes for the interface may be
visible representations of elements of metaphor.
2. Business domain classes are often refinements of analysis classes
defined earlier. The class identifies the attributes that are required
to implement some elements of the business domain.
3. Process classes implement lower-level business Preoccupation
need to manage business domain classes.
4. Persistent classes represent the data stores that will persist beyond
the execution of software.
5. System classes implement software management and control
function that permits the system to operate and convey within its
computing environment and with the outside world
As architecture forms, the level of abstraction is reduced as each
analysis class transformed into two design representations. That is,
analysis classes represent data objects using the jargon of the
business domain. Design classes present notably more technical detail
as a guide for implementation.

Characteristics:
1. Complete and sufficient: A design class should be complete
encapsulation of all attributes and method that can be reasonably
be expected to exist for class. For example, the class scene defined
for video editing software is complete only if it contains all
attributes and methods that can agreeably be associated with the
creation of a video scene. Sufficiently ensure that design class
contains only those methods that are sufficient to achieve the
intent of class, no more and no less.
2. Primitiveness: Method associate with design class should be
focused on accomplishing one service for class. Once service
implemented with the method, the class should not provide
another way to accomplish the same thing. For example, the
class Video Clip for video editing software might have
attributes start point and end point to specify start and endpoint of
clip.
3. High Cohesion:/strong> A cohesion design class has a small,
concentrated set of authority and single-mindedly applies
attributes and methods to implement those responsibilities. For
example, the class video clip might contain set of method for
editing the video clip. As long as each method focus solely on
attributes associated with video clip, cohesion is maintained.
4. Low Coupling: Within the design model, it is necessary for design
classes to get together with one another. However, get together
should be kept to an acceptable minimum. If the design model is
highly coupled, the system is difficult to implement to test and to
maintain over time, In general, design classes within subsystem
should have only limited knowledge of other classes. This
restriction called the Law of Demeter, suggest that method should
only send message to methods in neighboring classes.

You might also like