Bsa 385 week 5 team assignment smith software testing environment

Running head: SMITH SOFTWARE TESTING ENVIRONMENT PROPOSAL 1
Smith Software Testing Environment Proposal
Team Bravo
The University of Phoenix
BSA/385 Introduction to Software Engineering

SMITH SOFTWARE TESTING ENVIRONMENT PROPOSAL 2
Abstract
Smith Systems Consulting has received some feedback and concerns that their processes and
procedures are not sufficiently documented. This lack of professional documentation has caused
some loss of potential contracts for the firm. The Learning Team Bravo has been given the
assignment to define, develop, and propose standards for a software testing environment at
Smith. This will be accomplished by defining the Smith engagement approach, introducing the
way the firm works with clients and how projects are managed, defining the software
development and quality assurance processes and procedures, describing in detail testing
procedures to be exercised, describing the infrastructure including hardware and software
capabilities that will make up the software testing environment, and by defining the format and
requirements for development of formal program specification.

Smith Systems Consulting recently tasked Learning Team Bravo (LTB) with developing
a standardized project plan, approach, and testing procedures. It is Smith’s goal to show
prospective clients that Smith is efficient and is confident that they are able to perform
contractual obligations smoothly. The following procedures will be generalized so that Smith
will be able to utilize this project plan in any project. This standardized project plan that LTB
developed will enable Smith to focus the resources of their project rather than developing
procedures to complete the project.
Software Development Processes and Procedures
Smith Systems Consulting understands that there is not a clear-cut solution for each
individual software development project and wishes to utilize a process that accounts for
multiple variables when developing new software. In order to accurately define this process,
Smith will benefit from a System Development Lifecycle (SDLC) approach. This means that
Smith will first need to determine the needs of the company. Within this phase, the first step is to
identify Smith’s stakeholders followed up with developing a project timeline and budget.
Stakeholders will consist predominately of Smith employees so that in-house management will
have a firm grasp on the resources needed.
The next step in the SDLC approach is to form an analysis team to identify the needs of
the various stakeholders as well as to better understand the needs of the proposed system. This
analysis team is responsible of keeping the stakeholders informed by using data flow diagrams as
the project progresses for an all encompassed strict change control process. This step is vital in
quality assurance which will be discussed at a later time. Smith will also be responsible in
designing methods required by the needs of the project. Methods include resources, tools, new
models and various techniques used to fully identify system requirements. In some cases third-
party vendors are valuable for they provide and use tools that some methods may require. Third-

party vendors will be procured via contract and are subject to a determination of need by the
project stakeholders.
A finalized data flow diagram will be presented for the next step. A design team will then
determine the most effective and efficient approach to implement the design. Stakeholders will
be consulted before any final orders are given to include the procurement of vendors and the
resources they will provide. Once a vendor and resource are determined the design team will
execute the design as part of the project plan timeline. Smith will initiate developer testing as
well as end-user testing to ensure the final product meets the project plan criteria. After
acceptance testing, the system will be implemented and the training phase will begin.
Upon full implementation completion, a maintenance phase will begin. During this phase
Smith will be involved through its entire life cycle. Any and all contracts, to include telephone
support, will be included as essential elements of this system.
Quality Assurance Processes and Procedures
Smith is dedicated to providing development solutions to business information processes
of the highest quality to its clients. This quality is measured and ensured through the use of
resource and tools put in place from the very start of the project. In order to strengthen existing
business processes by the practical application of new technologies, Smith will use highly trained
and qualified project managers (PM’s). Each of Smith’s PM’s has a multitude of experience and
flawless track records that show they will stay on time and within the budget. Smith PM’s will
provide weekly updates to shareholders as well as daily meetings to ensure everyone involved in
the project is on track, but more importantly that there are no concerns for delays. Any concerns

will be of utmost importance and PM’s will alleviate concerns with additional resources to
address the problem with minimal operations impact or deviation from the project plan.
As mentioned earlier, a strict change control process will be used to ensure that the
project is kept within scope. Any changes to the project must be approved. Also mentioned
earlier, Smith realizes that that there is not a clear-cut solution for each individual software
development project and wishes to utilize a process that accounts for multiple variables when
developing new software. This strict change control process will reflect Smith’s project plan of
priority and secondary goals. These goals will be defined during the analysis phase however the
stakeholders will have the option to make changes during the change control process. Primary
goals are to be strictly followed and any deviation to them must occur due to imminent danger or
jeopardy to the project itself. Secondary goals on the other hand are identified as flexible and are
not bound such a strict change control process. Adherence to the change control process is vital
for project success and not reliant on the outcome of each individual system development
lifecycle phase.
Formal Program Specification Document
Smith systems will be recommending several changes to the current system at Kudler
Fine Foods. This is due in large part by the hardware and software that are out of date. All
locations for Kudler Fine Foods including La Jolla, Del Mar, and Encinitas have a similar layout
of multiple PII Win9x to include office 97, Novell 4.11 Servers and NT Server support.
Locations also sport 56k modem for internet connection. The system is relatively old and could
use replacement systems such as the latest in Windows operating systems and hardware. For this

project, Smith Consulting recommends an Agile Development Methodology to better serve
Kudler’s needs. This approach will promote extensive testing and reviews from the owner.
Design Considerations
Possible reasons for the development are to improve sales with Kudler Fine Foods and to
boost customer satisfaction. KFF has a strong reputation and is taking measures to improve on
this by the implementation of a rewards program. A feasibility study will address several
concerns that exist such as how much to invest and identifying acceptable risks.
Team Bravo believes that the number one constraint will be the budget. Since Kudler
Fine Foods is a smaller business with only three store locations the budget for implementing a
new system for each location will be not an easy task. The budget will be closely monitored in
regular progress reports within the Agile System Development Lifecycle (SDLC).
The goals and guidelines of this proposal will be solely based on the project plan within
the Agile SDLC. To reiterate, the main goal of the project is to provide a service to customers
that allow them to attain rewards for every product that they purchase, whether it is a bag of
potatoes or a magazine. The secondary goal, or byproduct of the system, will be an increase of
customer satisfaction and loyalty.
System Development Life Cycle
In review, the software method of choice will be the Agile SDLC. Taking a closer look,
Smith Systems Consulting will use the Scrum methodology. With Scrum, this development
methodology will be centered on testing and reviews after each sprint, or increment. A Scrum
Team and Scrum master will be formed to carry out the plan. The Scrum Master an owner will
periodically reviews the work after each increment. The steps will be organized and put in

sections so efficient prediction and development is achieved for the project. In order for the
Scrum Team to carry out its project plan, a System Requirement Specification (SRS) must be
defined. This formal program specification document will be used by Smith Consulting when
providing programming assignments to software developers (either in-house or contracted
personnel).
Testing Procedures
“Testing is an extremely crucial phase of the software development life cycle (SDLC)
and developers today face most demanding customers who expect 100% flawless functioning of
the applications in use (Olive, 2011).” Because of this, Smith will develop procedures for each
level of testing that takes place. Smith will employ a full range of sophisticated testing methods
to make sure top quality solutions are presented to Kudler Fine Foods. These procedures will be
adequate to support both Smith developed software and any commercial off-the-shelf (COTS)
software to be delivered.
Smith Systems Consulting requires its developers to initiate and perform testing on each
phase of a project that they are responsible for developing. These tests are performed to ensure
the software is ready for the next phase in the process. Developers are required by Smith to cover
all aspects of the project to include reliability, accuracy, fault tolerance and performance. Finally,
Smith will use test charts to document testing.

Reliability Testing
“Reliability Testing is meant to analyze the expected or actual reliability of a product and
identify actions, which should be taken in order to reduce the rate of failures (OCM, 2011).”
Reliability testing is imperative to guarantee the system is capable of managing all input and
output process and procedures. This will include programming for error handling in the event a
user inputs unexpected or false data. Reliability will also include handling exceptions of data
output.
Developers of SSC utilize the Architecture Document to control errors that occur without
passing inaccurate data to the next process. In order to perform controlled testing, developers
will input false data to see if the system handles the errors correctly. This process is vital to
manage false data and ensure it does not output. Smith will also perform stress testing. “Stress
testing, or load testing, is often used to test the whole system rather than the software alone. In
such tests the software or system are exercised with or beyond the specified limits. Typical stress
includes resource exhaustion, bursts of activities, and sustained high loads (Carnegie Mellon
University, 1999).”
Accuracy Testing
Accuracy testing is imperative for the input must be received, stored, translated and
output correctly. Any failure within those four steps will affect the accuracy of a system. Smith’s
developers will create unique algorithms for the Frequent Shopper Program so that the program
transforms data properly and the intended output is given.
Smith’s developers are required to utilize use cases to ensure proper communication
between systems. This use case will be a list of steps, typically defining interactions between a

role and a system, to achieve a goal. In this case the actor will be a human or an external system.
This tool will come in handy in the event an unexpected output is experienced. An engineer will
simply use the use case to troubleshoot and track down the problem. Accuracy testing is a key
step for developers in the implemented system.
Fault Testing
Smith will use fault injection to test both hardware and software. Fault injection is “the
deliberate introduction of faults into a system, and the subsequent examination of the system for
the errors and failures that result (Carnegie Mellon University, 1999).” This method of testing
will assist developers to identify and in turn use tools and techniques to overcome the shortfalls.
Performance Testing
Performance testing is obligated to occur during the development phase to warranty
customer satisfaction. Performance testing will include “resource usage, throughput, stimulus-
response time and queue lengths detailing the average or maximum number of tasks waiting to
be serviced by selected resources (Carnegie Mellon University, 1999).” Resources that need to
be considered during the performance testing include “network bandwidth requirements, CPU
cycles, disk space, disk access operations, and memory usage (Smith, 1990).” The goal of
performance testing will be performance bottleneck identification, performance comparison and
evaluation. The method of doing performance testing will be the use of a benchmark.

Test Charts
For each level of testing that is accomplished by Smith, the following Testing Chart will be used
to identify outcome. The testing chart will include a section to identify who is testing (Actor),
what area is being tested (Action), and a description of the task being tested.
Testing Chart - Figure 1
Actor Action Description
Customer/Employee/Etc. Click Button 1 Button 1 starts the applications and takes the
user to the login, etc.
Customer/Employee/Etc. Click Button 2 Button 2 logs the current user into the system
Continue… Continue… Continue…
In addition to this chart, Smith will include a secondary chart that provides details of each
step being performed or tested and its expected results. This Expected Results Chart will
resemble figure 2.
Expected Results Chart – Figure 2
Step Step Expected Result
Launch Application/Etc. Application window should open; prompt user for credentials, etc.
Login/Etc. Users should log into application; appropriate menu items should
appear based on user’s access and security level; etc.
Continue… Continue…
Hardware and Software Capabilities
Smith Systems Consulting currently uses Hewlett Packard QuickTest Professional 10.0
for all of its testing on its software projects. This program “supports functional and regression
test automation that addresses every major software application environment. This solution uses

the concept of keyword-driven testing to simplify test creation and maintenance. It enables
testers to build functional and regression test cases by capturing flows directly from the
application screens using specialized capturing technology. Test experts also have full access to
the underlying test and object properties via an integrated scripting and debugging environment
(Hewlett Packard, 2009).” This ease of use will assist Smith to control the testing timeline so that
projects stay on track.
For hardware testing, Smith will accomplish this separately. This environment utilizes
Intel Quad-Core processors with Windows 7 and equipped with 2GB of memory. The increased
processor speed and memory capacity will enable testing to run as quickly as possible. With the
hardware separated, this ensures that testing will have the ability to run simultaneous to the
project development; thus enabling strict adherence to any timeline.
Formal Program Specification
Formal program specifications for Smith Systems Consulting will be used by the
software developers and engineers. This document is detailed in the attachment named: “System
Requirements Specification.” Additionally, detailed instructions are included in this document
preceding the System Requirement Specification (SRS) document to assist developers in the
definition system requirements as well as what is needed to satisfy the requirement(s).
Conclusion
This recommendation to Smith Systems Consulting defined a proposed Smith
engagement approach, introduced the way the firm should work with clients and how projects
should be managed, defined the software development and quality assurance processes and
procedures, described in detail testing procedures to be exercised, described the infrastructure

including hardware and software capabilities that will make up the software testing environment,
and defined the format and requirements for development of formal program specification.
It is obvious that Smith Systems Consulting takes pride in providing the best software
development for its clients. With the above testing process and procedures in place, Smith will
guarantee Kudler the quality assurance it needs while remaining within scope of any project plan
and within budget. This proposal not only enhances Smith’s process and procedures, it will also
ensure stakeholders are engaged throughout the SDLC.

References
OCM (2011). “Reliability Testing” Retrieved on March 26, 2012 from
http://www.ocmtestlabs.com/default.asp?mode=testcategories&catid=9
Carnegie Mellon University (1999). “Software Testing.” Retrieved on March 26, 2012 from
http://www.ece.cmu.edu/~koopman/des_s99/sw_testing/
Hewlett Packard (2009). “Software Solution” Retrieved on March 26, 2012 from
http://www8.hp.com/us/en/software/software-solution.html?compURI=tcm:245-937061
Smith, C. U. (1990). “Performance Engineering of Software Systems.” Addison-Wesley. Page
40 Para 3.4

Attachment A: System Requirements Specification (SRS)
The System Requirements Specification (SRS), to be defined by Smith Consulting, is a
complete description of the proposed requirements for the Frequent Shopper Program. These
specifications are derived from customer requirements. The SRS will cover all business
functions, inputs, outputs, in addition to the system interfaces of the proposed project. The
following will detail the steps and requirements for the project. This will include possible
constraints such as budget problems, hardware changes, software development methods, and
others in order to maintain efficiency and to develop a working Frequent Shopper Program.
Purpose
The purpose of this SRS is designed to answer the following questions:
What is the information system or software going to accomplish?
With what system hardware, software and users will the program interact?
What are the performance requirements, such as capacity, speed and recovery?
What, if any, are the constraints on the design?
Scope
The System Requirements Specification is required for systems development projects.
Instructions
The following instructions will act as a guide for the SRS template.

1. Before publication and releasing of this document remove this template cover page and
instructions. Pages 1-4 are intended for official use only and not part of the finished document.
2. Angle brackets (< >) identify information to be input for each unique project. Removal of
the angle brackets (< >) are required after appropriate data is entered.
3. Template sections that do not apply to a unique project shall be labeled “N/A” or “Not
Applicable.”
4. Template instructions are denoted as italicized and shall be removed from the document
before publication.
5. Update the header with appropriate information.

<Beginning of Document>
<Project Name>
System Requirements Specification
<Date of Revision>
<Revision Number>
Prepared by:
<Author>
The following “Approvers” are deemed responsible for oversight of the System
Requirements Specification (SRS) and unanimously agree with the project scope and project
requirements. Approvers recognize and will maintain responsibilities described herein. Note:
Approver signatures are capable of being documented electronically via Electronic Qualification
Document Management System (EQDMS).
<Name>
Project Lead
<Name>
Project Superintendent
<Name>
Administrative Staff
<Name>
<Key Stakeholder #1 - Title>
<Name>
<Key Stakeholder #2 - Title>

Document History
Date Revised Version No. Author Reason for Changes

Table of Contents
Purpose............................................................................................................................................19
Scope...............................................................................................................................................19
Definitions, Acronyms, and Abbreviations .........................................................................................19
References .......................................................................................................................................19
Overview .........................................................................................................................................19
System Perspective...........................................................................................................................19
System Requirements....................................................................................................................19
System Interfaces .............................................................................................................................19
User Interfaces..............................................................................................................................20
Hardware Interfaces......................................................................................................................20
Software Interfaces .......................................................................................................................20
Communications Interfaces ...........................................................................................................20
Memory Constraints .........................................................................................................................20
Operations........................................................................................................................................20
Site Adaptation Requirements ...........................................................................................................20
System Functions .............................................................................................................................20
User Characteristics ..........................................................................................................................20
Constraints.......................................................................................................................................20
Assumptions and Dependencies.........................................................................................................21
Apportioning of Requirements...........................................................................................................21
Functional Requirements...................................................................................................................21
Performance Requirements................................................................................................................21
Logical Database Requirements.........................................................................................................21
Design Constraints............................................................................................................................21
Standard Compliance........................................................................................................................21
Software System Attributes ...............................................................................................................21
Supporting Information .................................................................................................................21

Purpose
The System Requirement Specification’s (SRS) purpose is to identify all system requirements.
The system requirements herein are derived from customer requirements in addition to
forecasted consumer needs and regulatory requirements. The SRS must identify requirements in
such a way to meet customer expectations. Additionally, the SRS must provide adequate
specifications for system validation.
Scope
<Identify the software product(s) and information system to be developed; Paraphrase what the
software product will accomplish; Include pertinent advantages and disadvantages as well as
objectives and goals of the proposal>
Definitions, Acronyms, and Abbreviations
<Identify and define all terms, acronyms, and abbreviations within the document>
References
<Present the inclusive listing of all documents and credentials referenced within the document;
References will be identified with the following information: Title, Date, and Publisher>
Overview
<Briefly describe information contained within the SRS; Provide explanation to the organization
of the SRS>
System Perspective
<Explain whether the proposed system is self-sufficient or contains relations with multiple
systems; a supplemental block diagram may be used to illustrate interconnections within the
overall system>
<The following is a sub-section of System Perspective>
System Requirements
<Describe all software requirements to the appropriate level to assist software designers and
software testing; Include narratives for each input and output of system requirements; Identify
input and output functions>
System Interfaces
<Identify system interfaces within proposal; Introduce differences of interfaces>
<The following are sub-sections of System Requirements>

User Interfaces
<Catalog all user interfaces; Identify functionality>
Hardware Interfaces
<Catalog all hardware interfaces; Identify functionality>
Software Interfaces
<Catalog all software interfaces; Identify functionality>
Communications Interfaces
<Catalog all communication interfaces; Identify functionality>
Memory Constraints
<Identify inclusive characteristics and limitations for primary and secondary memory>
Operations
<Present modes of operations, data processing support functions and options for backup and
restore operations>
Site Adaptation Requirements
<Define initialization sequence requirements; Identify mission-related features needed for
adaption of software>
System Functions
<Summarize major functions the software will carry out; Organize functions so that all levels of
audience may comprehend; Use graphics to show relationships between functions>
User Characteristics
<Explain universal characteristics of anticipated users; identify preferred experience, technical
expertise and educational level>
Constraints
<Describe in detail the limitations for developers to include, but not limited to, reliability
requirements, higher-order language requirements, parallel operation, signal handshake
protocol, hardware limitations, interfaces to other applications, safety and security
considerations, regulatory policies, criticality of the application, control functions, and audit
functions>

Assumptions and Dependencies
<Catalog software changes that directly affect requirements within the SRS>
Apportioning of Requirements
<Identify possible requirement delays for future versions>
Functional Requirements
<Depict essential measures needed for software acceptance and processing of inputs generating
the outputs; Include measures such as validity checks on the inputs, effect of parameters,
responses to abnormal situations, exact sequence of operations, relationship of outputs to inputs,
as well as input and output sequences; Use sub-functions if required>
Performance Requirements
<List performance requirements in measurable terms in relation to static and dynamic numerical
requirements>
Logical Database Requirements
<Indicate logical requirements for database; Identify and explain frequency of use, integrity
constraints, data retention requirements, data entities, and accessing capabilities>
DesignConstraints
<Indicate design constraints; Include hardware limitations related to design>
Standard Compliance
<Identify requirements based on standards and existing regulations>
Software System Attributes
<Identify related software requirement features; Describe factors such as portability,
maintainability, security, availability, and reliability of the software system>
<The following is a sub-section of Software System Attributes>
Supporting Information
<Include additional pertinent information via appendix or glossary>
<End of Document>

Bsa 385 week 5 team assignment smith software testing environment

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Bsa 385 week 5 team assignment smith software testing environment

Similar to Bsa 385 week 5 team assignment smith software testing environment (20)

Recently uploaded

Recently uploaded (20)

Bsa 385 week 5 team assignment smith software testing environment