Scribd
Upload
11 views

Software Engineering 1B SWE320

it

Uploaded by

vhuhonerasila007
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
11 views

Software Engineering 1B SWE320

it

Uploaded by

vhuhonerasila007
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/ 3

Software Engineering 1B SWE320

Diploma in Information Technology

rasila vhuhone 201815351


August 2021
Question 1

Benefits of software reuse

Increased dependability Reused software, that has been tried and tested in working systems, should
be m ore dependable than new software. The initial use of the software reveals any design and
implementation faults. These are then fixed, thus reducing the number of failures when the software
is reused.

Reduced process risk If software exists, there is less uncertainty in the costs of reusing that software
than in the costs of development. This is an important factor for project management as it reduces
the margin of error in project cost estimation. This is particularly true when relatively large software
components such as sub-systems are reused.

Effective use of specialists Instead of application specialists doing the same work on different
projects, these specialists can develop reusable software that encapsulate their knowledge.

Standards compliance Some standards, such as user interface standards, can be implemented as a
set of standard reusable components. For example, if menus in user interfaces are implemented
using reusable components, all applications present the same menu formats to users. The use of
standard user interfaces improves dependability as users are less likely to make mistakes when
presented with a familiar interface.

Accelerated development Bringing a system to market as early as possible is often more important
than overall development costs. Reusing software can speed up system production because both
development and validation time should be reduced.

Reuse problems

Increased maintenance costs If the source code of a reused software system or component is n ot
available then maintenance costs may be increased as the reused elements of the system may
become increasingly incompatible with system changes.

Lack of tool support CASE toolsets may not support development with reuse. It may be difficult or
impossible to integrate these tools with a component library system. The software process assumed
by these tools may not take reuse into account.

Not-invented-here syndrome Some software engineers sometimes prefer to re-write components


as they believe that they can improve on the reusable component. This is partly to do with trust and
partly to do with the fact that writing original software is s een as more challenging than reusing
other people’s software.

Creating and maintaining a component library Populating a reusable component library and ensuring
the software developers can use this library can be expensive. Our current techniques for classifying,
cataloguing and retrieving software components are immature.

Finding, understanding and adapting reusable components Software components have to be


discovered in a library, understood and, sometimes, adapted to work in a n ew environment.
Engineers must be reasonably confident of finding a component in the library before they will make
routinely include a component search as part of their normal development process.

1.2

The reuse landscapes


Design patterns Generic abstractions that occur across applications are represented as design
patterns that show abstract and concrete objects and interactions.

Component-based development Systems are developed by integrating components (collections of


objects) that conform to component-model standards. This is covered in Chapter 19.

Application frameworks Collections of abstract and concrete classes that can be adapted and
extended to create application systems.

Legacy system wrapping Legacy systems that can be ‘wrapped’ by defining a set of interfaces and
providing access to these legacy systems through these interfaces.

Service-oriented systems Systems are developed by linking shared services that may be externally
provided

Application product lines An application type is generalised around a common architecture so that
it can be adapted in different ways for different customers.

COTS integration Systems are developed by integrating existing application systems.

Configurable vertical applications A generic system is designed so that it can be configured to the
needs of specific system customers.

Program libraries Class and function libraries implementing commonly-used abstractions are
available for reuse.

Program generators A generator system embeds knowledge of a particular types of application and
can generate systems or system fragments in that domain.

Aspect-oriented software development Shared components are woven into an application at


different places when the program is compiled.

1.3

- The development schedule for the software.

● The expected software lifetime.

● The background, skills and experience of the

development team.

● The criticality of the software and its non-functional requirements.

● The application domain.

● The execution platform for the software.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy