The directives from International Gadgets' management were unclear and ineffective because they lacked important details. For example, a request from Sales to Technical Support asked for "a list of the biggest problems with our hot products" but did not specify what information was needed, the format for the response, or the deadline. Similarly, a memo to reduce suppliers did not list which suppliers or products were involved, or the process and timeline for making changes. To improve, directives should be written with clarity and conciseness, specifying all relevant details such as intended audience, required deliverables, timeline and expectations.

1. As the new communications manager for International Gadgets,
you have come across many examples of ineffective
communications, including some older directives that were
never carried out, mostly because of their unclear nature.
One example included an email stating that the recipient (within
the R&D team) was to "create a presentation discussing the new
product and send it to interested departments." Others included
a request from Sales to Technical Support for "a list of the
biggest problems with our hot products" and a memo from
Finance to all departments to "reduce the number of suppliers
being used to better control costs."
In a memo to your team, describe what is wrong with directives
such as these and how to improve these messages so that they
are delivered to the recipient with clarity and conciseness.
MITRE. (2017). System design and development. System
Engineering Guide. Retrieve from
https://www.mitre.org/publications/systems-engineering-
guide/se-lifecycle-building-blocks/system-design-and-
development
MITRE. (2017). Assess the design's ability to meet the system
requirements. Retrieved from
https://www.mitre.org/publications/systems-engineering-
guide/se-lifecycle-building-blocks/system-design-and-
development/assess-the-designs-ability-to-meet-the-system-
requirements
Software Testing. (2017). Difference between system testing vs
integration testing? Retrieved from
http://www.softwaretestingclass.com/difference-between-
system-testing-vs-integration-testing/

2. Software Testing. (2017). User acceptance testing: What? why?
& how? Retrieved from
http://www.softwaretestingclass.com/user-acceptance-testing-
what-why-how/
Thakur, D. Software maintenance in software engineering.
(2017). Computer Notes. Retrieved from
http://ecomputernotes.com/software-engineering/types-of-
software-maintenance
Udacity. (2015, February 23). Maintenance - Georgia Tech -
software development process [video file]. Retrieved from
https://www.youtube.com/watch?v=0Y8YLMJ3ERw
Modules/Module4/Mod4Home.htmlModule 4 - Home
Software System Design and MaintenanceModular Learning
Outcomes
Upon successful completion of this module, the student will be
able to satisfy the following outcomes:Case
Explain why documenting a system design is useful to the
system development process.Identify the dynamics of testing a
system.SLP
Define what is meant by system evolution and how its
characteristics affect maintenance.Discussion
Discuss quality measure to maintain a system.Integration and
Reflection.Module Overview
System Design and Testing
Module 4 focuses on the process by which the requirements are
translated into a system design to deliver a software product. A
good design is one that describes a system able to meet all of
the requirements and user needs; however, other high-level
concepts in design are important. For example, it is essential

3. that a software application design be adequate for long-term
intended use and also consider components of reusability and
modifiability. Lower level concepts such as modularity and
abstraction are also used to measure characteristics of design
and to allow general guidelines to evaluate quality and
maintainability.
Planning the design includes devising and maintaining a
workable scheme to ensure that all requirements are addressed
during the design phase and not during coding or testing.
Design includes several plans such as working with users to
decide how system interfaces, reports, and screens best fit user
needs for acceptance. This may require developing several
prototypes to show users the possibilities, to determine how
performance requirements can be met, or to evaluate the best
look and feel. To account for quality conditions on the project
and in the organization, project teams often make decisions to
increase fault tolerance. Another goal is to anticipate potential
faults that may occur and design the system in ways that
minimize disruption to the user. Design also emphasizes
collaboration with other developers through the software life
cycle. Also, since designs are built from components, the
interrelationships among components and data must be well-
documented. Cross-referencing may be necessary to help
explain which parts of the design affect what components and
data. Other developers should also participate in design
reviews, evaluating the design at several stages and making
suggestions for improvement.
Testing an application includes coordinating with the project
team and developers to carry out the various test plans as shown
in Figure 4-1. Unit testing is very different from integration
testing. The developer performs unit testing of each components
and has complete control over the testing process. The
developer creates the test data, designs the test cases, and runs
the tests. When integrating components, the developer
sometimes works individually, but often collaborates with a
small part of the test and development team; however, when

4. testing a system, the developer works with the entire
development team and designated users coordinated and
directed by the test team leader.
Figure 4-1. Test Planning
Delivering the System
This module also discusses the need for training and
documentation, which are two issues key to successfully
transfer the system from developers to users. Even with turnkey
systems (where the developers hand over the system to the user
and are not responsible for its maintenance), delivery involves
more than putting the system in place. It is during training when
the development team helps users to understand and feel
comfortable with the product. If delivery is not successful,
users will not use the system properly and may be unhappy with
its performance.
As the system is being designed, training materials are
developed to help users learn to use the system. Accompanying
training guides is documentation to help user navigate through
problem-solving. Training and documentations should be done
from two perspectives: the user and the operator. Sometimes,
the same person is both user and operator. Something to
consider is that user and operator tasks have very different
goals, so the training for each job should emphasize different
aspects of the system. Training can be done in many ways. At
some point, if users forget how to access a file or use a new
function, training should include steps to locate components and
troubleshoot. Formal documentation, icons and on-line help,
demonstrations and classes, and expert users are examples of
training aids that are very helpful when a new system is
implemented.
System Maintenance
Implementing a system in production does not mark the end of
the software developers' involvement. Rather, many systems
require continuous change, extending even past delivery.
Software maintenance deals with managing change in this part

5. of the lifecycle. Performing maintenance requires its own skill
set, in addition to those required for software development.
Maintenance personnel are usually programmers and analyst
who interact continually with colleagues and users to
effectively define problems and find solutions. Maintainers
need to be good detectives, testing software thoroughly and
hunting down the sources of failure. They also need to
understand the “big picture” of how systems with complex
interactions interoperate with the environment.
Another important technique is software rejuvenation, which
may involve reverse engineering to re-document restructure, and
reengineer an existing system. The overall goal is to make
hidden information explicit, so that it can be used to improve
the design and structure of the code. Although complete
rejuvenation is unlikely in the near future, it is being used
successfully in mature domains like the Department of Defense,
IRS, insurance companies, and aerospace where legacy systems
are still efficient but are too complex to re-write from
scratch.Privacy Policy | Contact
Content images/test planning.png