Bsa 385 week 5 team assignment smith software testing environment

Running head: SMITH SOFTWARE TESTING ENVIRONMENT PROPOSAL1

Smith Software Testing Environment Proposal

Team Bravo

The University of Phoenix

BSA/385 Introduction to Software Engineering

SMITH SOFTWARE TESTING ENVIRONMENT PROPOSAL2

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 systemContinue… 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

http://www.ece.cmu.edu/~koopman/des_s99/sw_testing/

http://www.ocmtestlabs.com/default.asp?mode=testcategories&catid=9


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 ContentsPurpose........................................................................................................................................................7

Scope...........................................................................................................................................................8

Definitions, Acronyms, and Abbreviations..................................................................................................8

References...................................................................................................................................................8

Overview.....................................................................................................................................................8

System Perspective......................................................................................................................................8

System Requirements..............................................................................................................................8

System Interfaces........................................................................................................................................8

User Interfaces.........................................................................................................................................8

Hardware Interfaces.................................................................................................................................9

Software Interfaces..................................................................................................................................9

Communications Interfaces.....................................................................................................................9

Memory Constraints....................................................................................................................................9

Operations...................................................................................................................................................9

Site Adaptation Requirements.....................................................................................................................9

System Functions........................................................................................................................................9

User Characteristics.....................................................................................................................................9

Constraints...................................................................................................................................................9

Assumptions and Dependencies..................................................................................................................9

Apportioning of Requirements..................................................................................................................10

Functional Requirements...........................................................................................................................10

Performance Requirements........................................................................................................................10

Logical Database Requirements................................................................................................................10

Design Constraints....................................................................................................................................10

Standard Compliance.................................................................................................................................10

Software System Attributes.......................................................................................................................10

Supporting Information.........................................................................................................................10


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>

Design Constraints

<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

Software

Transcript of Bsa 385 week 5 team assignment smith software testing environment