 |
Software Dimensions and The International Institute for Software Testing Present PSQT/PSTT 2002 South |
|
|
|
Wednesday Conference Sessions (8:00 AM - 6:00 PM) Keynote Presentation (Wednesday 8:30 - 9:45 AM)
Concepts: If your top management doesn’t understand how to support your quality improvement efforts, you will be sidelined and ineffective. A simple one page policy statement, based on quantification and results is a powerful tool for both you and your top management to co-operate in change. The policy must cover areas of return on investment, measurable business results, and priority determination. This presentation will discuss how you can create such policy statement.Biography: Tom Gilb is a freelance consultant, teacher and author serving clients in Europe and the US. He has written "Principles of Software Engineering Management" and is Principal author of "Software Inspection". He specializes in software quality design and management. He lives in Norway, when he is not travelling. His work is available on www.result-planning.com.PSQT Featured Presentation (Wednesday 10:00 - 11:00 AM) Using Defect Data to Control Quality Concepts: Defect
Management can leverage development and test costs with 10 to 1 margins or better. Most
organizations never achieve these results because they focus on product metrics rather
than using process metrics. As organizations mature, their approach to defect management
changes. Process maturity is evidenced by metrics collected and analyzed, with resulting
changes in the organization’s processes. Organizational maturity is evidenced by how
the development and test staff collects and uses the data, and management’s use of
the data in the decision process. As
organizations move to CMM Level 3 and beyond, they become more capable of using defect
data to manage and control their development processes. Inspection data becomes a rich
source for understanding the organization’s development processes. Test and
inspection data guides planning for optimum defect removal strategies. Post-ship defect
data can be used to evaluate development life-cycle effectiveness, and begins to provide
input to quality versus ship date decisions. This presentation will discuss data analysis and project management decisions using data from the full development cycle, with examples of data analysis techniques useful for project, product, and process analysis. Biography: Ed Weller has
over 30 years of experience in hardware, test, software, systems, and software process
engineering, with software process his primary area of focus for the last 12 years. Prior
to joining STT full time, he was the senior technical leader for division level software
process improvement programs at Bull Information Systems and Motorola’s Satellite
Communications Division. In this role he has developed and implemented long-range process
improvement programs with demonstrated success. In 1992, Bull achieved SEI Level 2 and ISO
9001 certification under his leadership. He is a certified Lead Assessor in the SEI
CMM-Based Appraisal for Internal Process Improvement and instructor of the
“introduction to the CMM”. He has participated in numerous assessments and
software supplier process evaluations based on the SEI Appraisal model. Ed was a co-founder and first co-chair of the Software Inspection and
Review Organization, a special interest group promoting the use of inspection process. He
was a member of the SEI's Software Measurements Steering Committee and the DoD Software
Best Practices Initiative Steering Committee. He is a member of the Embry Riddle
Aeronautical University Industry Advisory Board, and was the Program Chair of the 7th
International Conference on the Applications of Software Measurement in 1996, 1999, 2000,
and 2001, and 2002. His September 1993 IEEE Software article was awarded best article of the year honors by the IEEE Software Editorial Board, and his presentation "Using Metrics to Manage Software Projects" was selected as the best presentation at the 1994 Applications of Software Measurement Conference. An article by the same title was published in the 1994 IEEE Computer. He recently published “Practical Applications of Statistical Process Control” in the May/June 2000 IEEE Software, and “Applying Quantitative Methods to Software Maintenance” in the December 2000 Software Quality Professional. He was the author of the Software Metrics column in the Software QA Quarterly (now Software Quality and Test Engineering) and has presented seminars at several major software companies on the inspection process. PSTT Track Presentations (Wednesday 10:00 - 11:00 AM) Managing the Test Effort Using Requirements-Based
Testing Metrics Concepts: In many organizations, there is
difficulty quantifying the true state of the test effort.
Often testing is measured by getting as much done as possible by an
arbitrary deadline. The true level of quality
is never really known, and software is released to the next phase of development with
portions of the code going untested. This
dramatically increases the risk of software failure. Ironically, when testing is properly
deployed, with heavy emphasis on Requirements-Based Testing (RBT), it can have a major
impact on overall project productivity as well as product quality. Presentation Outline: The
Requirements-Based Testing Methodology provides a set of metrics throughout the software
development cycle. These metrics clearly
provide the true state of the test effort at any point in time. This presentation describes the RBT process and
details the derivation of each RBT metric and its impact on the software development
process. This presentation addresses how the
RBT process reduces the risk of delivering untested code, and provides project management
with quantitative data on the test effort throughout the software development lifecycle. The combined results are fewer tests with greater
functional coverage, shortened time to delivery, reduced costs of development, and
significantly improved quality. Biography: Gary
Mogyorodi has over 28 years of experience in the computing industry.
Currently as a Senior Consultant with Bloodworth Integrated Technology (BIT), Inc., Mr.
Mogyorodi consults, trains and mentors in software testing, specializing in test case
design. Mr. Mogyorodi began working for Bender & Associates in 1998, which merged with
TBI in 1999, and was then acquired by Starbase Corp. in 2001. Prior to his tenure with
Bender & Associates, the majority of Mr. Mogyorodi’s career was with Dofasco Inc. From 1992, Mr. Mogyorodi was a Quality Assurance
and Software Testing specialist, managing testing efforts, developing testing
methodologies, and creating standards and procedures for quality assurance and testing.
Prior to that, he worked at Dofasco as a Programmer, Systems Analyst and Manager of
Software Development. Gary Mogyorodi obtained a B. Math degree from the University of Waterloo, and an M.B.A. from McMaster University. A prolific speaker, Gary has delivered presentations at events including the SQA User's Conference, CIPS (Canadian Information Processing Society, Toronto and Hamilton Chapters), TassQ (Toronto Association for System and Software Quality), CQAA (Chicago Quality Assurance Association), the STAR WEST (twice) and STAR EAST Conferences, the Software Quality Forum, the Toronto SPIN (Software Process Improvement Network) and PSQT/PSTT North. Test
Plan 101 Using IEEE 829 Concepts: The test plan is
the base of all the future tests for an SW application.
It is a kind of contract between the test team, the management and the
development team. It details the strategy
that will be used for testing and will enable : -
the management to understand the added values of the tests
and the remaining risks, the costs and requirements as well as the time frame, -
the development team to focus on the areas that are most
critical or where a required level of quality has been set, -
the test team to develop and execute the test campaigns in
order to reach the goals on time and within budget, -
the test project manager to have a reference document to
keep the project on course and on budget. This presentation
first describes the different types of documents used in the IEEE 829 standard and their
relations to one another. Building on this
information it details the different steps and aspects of the test plan as described in
the standard and the relations between the different chapters, how they complement each
other in order to provide a complete solution. From
there it shows how to use the plan for different types of tests such as functional /
regression testing, performance testing and configuration tests. The presentation ends with the application of
sub-plans to cover the different aspects of testing for a complex application. This original presentation is based on real life
experience and implementation of test plans developed using this and different methods and
their comparison. Biography: Bernard Homès is founder and principal consultant for TESSCO ltd (Tests Evaluation Service & Solution, Conseil & Organisation limited). After 20 years in software development (banking, ERP, ...) and testing with different consulting firms, he set up the TESSCO group in Europe (France and UK) and Canada. Currently Bernard helps customers in setting up software test centres, and provides trainings and consultancy services worldwide. Designing Automated Tests for Object Oriented
Applications Concepts: This presentation will offer an approach to automated test design
which is geared toward faster and more versatile development of scripts for today’s
software applications. As software design and
development moves from the Waterfall approach to Object Oriented approach, so must
automated testing. The use of object
scripting to design test cases will show standards used and the advantages of this
design. Presentation Outline: 1. Object Oriented
Design as Opposed to Waterfall Design
A.
In Application Software
B. In Script Design I. The Basic Concept A. Scripts are single actions B. Test Cases are an accumulation of scripts. C. Keep Scripts and Test Cases Separate 2. Building
a New Design
A. Analyze the Application B. Standards are Required C. Examples Biography: Penny Witt has been in the computer field for over 15 years, the last ten specifically in the testing arena. In 1994 she evaluated the top four automated test tools in the country and based on her recommendation, the U.S. Customs Enforcement Division purchased their first automated test ware. In 1995 she presented “Transition Testing: From Legacy to Distributed System” at the STAR International, describing data setup for transition testing which was done at U.S. Customs. She was an officer of a northwest automated test tool user group 1997-98. In 1998 she also participated as a panelist debating automated test tools, at the Seattle Area Software QA Group. Currently she is responsible for the development of automated regression tests on a nation wide facilities application for Weyerhaeuser. Deriving Test Cases from Use Cases for Web
Applications Concepts: Traditionally test cases are developed from functional requirement
specifications. This methodology inherently
restricts user-centric software testing. System
testing derived from functional requirement specifications overlooks or ignores dimensions
of quality related to actual usage including usability.
Without adequate knowledge of how the end customer will actually use the
system, test engineers are left with the impossible task of validating an end-to-end
solution integrity and quality. An
alternative technique of developing test cases from the use cases effectively centers
product testing on actual usage scenarios of the product.
Use cases contain the system functionality that delivers the core value to
the customer. Deriving test cases from the
use cases facilitates testing the product’s ability to deliver core value to the
customer. This paper first establishes the characteristics of good use cases
and then describes a method to derive effective test cases from use cases. It explores challenges such as, keeping a test
case self-contained and addresses the issues of boundary conditions and negative testing
in a web application development. While the
technique is effective it is not a panacea. It
is not possible to develop test cases comprehensive enough to address all possible system
variations. Also, system boundaries and error
conditions must be built into the use cases in order to effectively address them in
testing. Biography: Orhan Beckman,
Ph.D. works as a Human Factors Engineer/Scientist for HP’s Commercial Printing
Services Division in Vancouver, Washington. He manages human factors research and design
for product development. Dr. Beckman joined Hewlett-Packard in the spring of 1994. He
received his Ph.D. in Industrial/Organizational Psychology from Old Dominion University in
1998. Bhushan Gupta joined Hewlett Packard, Vancouver Printer Division as a Software Quality Engineer in 1997. He is currently a Software Process Architect for HP’s Commercial Printing Services Division. Bhushan Gupta was a faculty member in the Software Engineering Department of the Oregon Institute of Technology from 1985 to 1995. He has a MS degree in Computer Science from New Mexico Institute of Mining and Technology, Socorro, New Mexico. He is on the board of Pacific Northwest Software Quality Conference. PSQT Track Presentations (Wednesday 1:00 - 2:00 PM) Obvious,
But Do You Do It? Getting Value Out of Your Software Development Process Concepts: When you finish a project, do you feel that you spent too much time,
too many resources, and are not sure of the product quality or process efficiency? Are you using a process to fulfill a checkbox but
not sure how it affects product quality? Do
you spend too much time trying to get around the process? We had a good process that ensured a quality product. However, we felt that current pratices could be
improved in order to increase project efficiency while maintaining product quality. We went back to basics to make improvements. Determining the value of each step of our process
and ensuring that we obtained that value before moving on resulted in less rework, focused
efforts, and higher product confidence. Presentation Outline: 1. We had a project, didn’t like the schedule estimates, and due to the criticality of the project we had to figure out a way to come up with more acceptable, but realistic estimates. 2. Our company has a well-established process, containing the standard key elements. We didn’t do anything that wasn’t already called out in our process. The way we did things made the difference. 3. We obtained the most value from our requirements by ensuring that they were completed early and that they were measurable and testable. We didn’t confuse specifications with requirements. 4. Our Risk Analysis was done early and used to drive design and focus testing needs. 5. Our Product Design and Test Design evolved together to complement each other. 6. We ensured our entire technical team had a good understanding of both Product and Test Designs so that we could be more effective at implementation and testing. 7. As a
result, we reduced test time by 75%, completed the project according to plan, and
introduced no new defects. Biography: Robert Takemori is a Systems Engineer at Dade Behring MicroScan with twelve years of experience in software development and systems validation & verification. His experience also includes test tool development, project lead, and management of the Systems Integration Group. Robert holds a B.S. in Business Administration with a concentration in MIS. 10
Ways to Improve Your Technical Review Process Concepts: Suppose I told you about an amazing software engineering
discovery that can help your project improve software quality, productivity, and cost and
schedule performance. Sound good? But wait, there’s more: this technique can
help improve communication and understanding among your project team, reduce time spent in
testing, and reduce the risk that poor software will cause maintenance problems down the
road. This discovery is not new;
it’s called technical review, and it’s been used in various forms for at least
30 years. Almost all software professionals
know about the technique and its benefits. Why
don’t projects use it? The answer is
often related to ineffective execution. Badly
run technical reviews alienate developers, who avoid participating. The time spent in reviews doesn’t have much
effect on the project’s success. Without
a return on investment, management withdraws their support and technical reviews grind to
a halt. Other organizations conduct reviews,
but fail to collect or use data from the process. After a brief
survey of technical review terminology and methodology, we will examine and discuss 10
ways you can improve your organization’s technical review process. Your project can
enjoy the benefits of effective technical reviews! Presentation Outline: · Technical review tutorial · Project reviews vs. technical reviews · Benefits of technical reviews · 10 ways to improve technical reviews Document your review process Train people Appoint a process owner Use a review coach Put reviews in the project schedule Focus on upstream work products Capture basic review data Do something with your data Conduct causal analysis sessions Use what you learn for preventing defects ·
Summary Biography: Henrietta
Foster has over 28 years of
experience with computers, software development, software management, and process
improvement. After experiencing first-hand
the effects of chaotic software projects, she began working with software process
improvement in 1993, providing assessments, consulting and training to many project teams,
both large and small, to help them improve
their software development, management, and quality processes. Henrietta is founder and principal consultant for Northfield Training Solutions, where she provides training and consulting for software engineering and process improvement. Proper
Specification of Software Requirements Concepts: Some of the biggest challenges faced by
software engineers are those of requirements analysis, definition, validation,
verification and specification. In many software requirements documents the requirements
are ambiguous and inconsistent. They are not uniquely identified making them untraceable
and untestable. In many cases they are specified at too high a level, at the system level,
or to low a level, at the design level, not at the software requirements level.
· Traceability
Biography: Al
Florence has been employed at major technology firms, and is
currently employed at the MITRE Corporation. He
has been involved in all phases of the life cycle from concept to retirement in different
disciplines including, software, systems, test, configuration management, and quality assurance as a
developer and as a manager. His work has involved many diversified projects: spacecraft;
aircraft; missiles, weapon systems; particle accelerators; simulation; and information
systems. He has been involved with the
definition, specification and validation
of requirements on many of these projects. Mr. Florence holds a BS degree from the
University of New Mexico in mathematics and physics and did graduate work in computer
science at the University of California in Los Angeles and at the University of Southern
California. ISO,
CMM, Quality Management, Software Quality Assurance - What Works for Putting in Place
and Maintaining an Effective Software Process? Concepts: There are a myriad of software process tools and methodologies. Some
of the more well known names include ISO, CMM, RUP, among others. The idiosyncrasies of
software process are such that there is unlikely to be a silver bullet. A solution that
works well will likely involve experimentation and adaptation. Some key ideas in working
with process are that process should help, not hinder; and that people make process work,
not the other way around. Some key elements to consider in putting together and
maintaining an effective software process include a process/SQA person and a grass root
process improvement group. Presentation Outline: · Introduction · What happened early on · We lost our SQA person in 1997 · Lead up to rejuvenation · How things work now ·
What worked well and what
didn’t Biography: Wood Lee has a PhD in Computer Sciences from the University of Texas at Austin. He started working as a software developer in ’93 and has been involved in software process and continuous improvement efforts ever since. His involvement has increased through the years. He has led general continuous improvement efforts since ’95, conducted training on software process for ISO TickIT audits since ’97, led software process improvement efforts since ’98, acted as ISO management rep since 2000, performed a CMM mini-assessment as a co-assessor at the end of 2000 and taken on an SQA role starting in 2001. PSTT Featured Presentation (Wednesday 1:00 - 2:00 PM) Stomach Ache Metric for
Gaining Testing Buy-In Concepts: We hear a lot about how testing should address risk. That's very true. However, many testers need to
learn better how to define risks. The
conventional methods tend to be reactive. They
are necessary but relatively weak. In this
session, Robin Goldsmith shows a proven way to define risks proactively that finds three
times as many potential showstopper risks as traditional reactive methods. When managers, developers, and users become aware
of these lurking threats, some have been known literally to double over with stomach
cramps. One stomach ache turns them into
strong advocates for sufficient testing to reduce these risks. * Prevent showstoppers that testing ordinarily
would miss * Reduce major causes of project overruns * Gain user, developer, and manager support for testing Biography: Robin Goldsmith JD is internationally recognized as an authority on business engineering and software acquisition/development quality, testing, and productivity, he is a frequent speaker at leading conferences. Formerly International Vice President of the Association for Systems Management and Executive Editor of the Journal of Systems Management, he currently is Vice Chair of the 2000-member ASQ Boston Section.PSQT Featured Presentation (Wednesday 2:15 - 3:15 PM) Team Up with the Prroject
Manager to Improve Quality and Testing Concepts: The Project Manager is the key determiner of software quality. The PM determines in standards and methodologies will be followed and rigorously enforced. The PM can build a strong relationship with the internal customer and leverages that to get critical involvement in the project. Or the Project Manager can give in to customer reluctance and get poor requirements and inadequate acceptance testing. If you are going to be successful as a Quality Assurance or Testing professional, you must build a strong partnership with the Project Manager. Learn the Six Secrets of building the Quality/Project Connection that get winning results for you. Biography: Dr. Staton-Reinstein has had a long and successful career as an IT professional and organizational leader. She established the Quality Assurance function in three different companies. Her results led to her appointment as a corporate officer to implement total quality management. Her articles on building quality software appear regularly. She works with companies who want to improve their software and their IT management.PSTT Track Presentations (Wednesday 2:15 - 3:15 PM) Can a Testing Maturity Model Help Improve My
Testing Process? Concepts: The Software Testing Maturity Model (SW-TMM) is an exciting new tool
that can help organization's make significant improvements in the testing process. It is a companion to the Software Capability
Maturity Model (SW-CMM). In order for an organization to improve their software testing
process they should know their current testing maturity and how to progress to the next
level. This presentation will focus the
Software Testing Maturity Model (SW-TMM) developed by the Illinois Institute of
Technology. It will present the theory behind the SW-TMM, discuss why a company should use
it and lastly discuss how to effectively utilize the SW-TMM. This presentation will provide valuable testing
maturity and assessment information that can be brought back to your organization and
utilize immediately. Presentation Outline: v Introduction v What is a Testing Maturity Model? v Discussion of the Software Testing Maturity Model (SW-TMM) v Level 1 - Initial v Level 2 - Phase Definition v Level 3 - Integration v Level 4 - Management and Measurement v Level 5 - Optimization/Defect Prevention and Quality Control v Why Do I Need To Use It? v How Do I Use It? v What Will the Assessment Accomplish? v How Do We Conduct the Assessment? v
Test Maturity Assessment Procedure Biography: Thomas C. Staab owns an independent consulting firm, Wind Ridge International. He has over 35 years experience. Prior to opening his own consulting firm he worked for over 25 years in the quality assurance profession. He holds a Master of Science degree in Quality Systems. His consulting work incorporates his extensive quality assurance and information technology experience into every project. He has developed the test plan and coordinated the testing of numerous systems for clients. His expertise is in bringing this practical experience into the classroom. Mr. Staab is listed in the International Who’s Who of
Information Technology. He has currently
published over 25 articles (one of which earned him Author of the Year Award from the Comptroller
magazine) and presented over 50 speeches at regional, national and world conferences. He
has developed and taught numerous training courses during his career and has always
received excellent evaluations for his training courses and speeches. Mr. Staab holds a Bachelor of Arts degree from North Texas State
University and a Master of Science degree from the University of Dallas Test Integration with Testing Markup
Languages Concepts: Markup languages
have been around for about thirty years. HTML and XML are
the last very popular members of this category. Lately there have been very promising
approaches to use markup languages to integrate more closely the various work products
generated in a testing process. The Presentation/Paper will give a detailed view on what
specific approaches exists and will present a practical
example out of the banking industry. Presentation Outline: Anybody having
exposure to the challenge of software testing knows about the inherent difficulties:
With the arrival
–or the revival- of markup languages –primarily based on XML- there are
presently several approaches of using MLs for testing and test integration purposes
existing. The Presentation/Paper will focus explaining those proposals and will comment on
their benefits and drawbacks based on experience from their application. Biography: Gerold Keefer was educated at FHTE (Fachhochschule für Technik Esslingen), Department of Telecommunications with a degree of Dipl.-Ing.(FH). Since 1993 he has been working as a consultant in the field of software development, quality assurance, integration and acceptance testing. Clients include Alcatel, IBM, DEKRA, Dresdner Bank, German Post, and Robert Bosch. Since 1999 he is the CEO and founder of AVOCA LLC. Currently with 4 employees. He has been a speaker at GPM Stuttgart Branch, 2000. "Integration of project management and quality management". German Chapter of the ACM, Stuttgart University, 1999."CMM, ISO and after that ?". Automation
Testability Issues Concepts: Everyone who has ever used an automation tool has run up against the
same problem: Windows controls in the system under test that are not recognized by the
automation tool. Many do not understand why
this happens, or what you can do to prevent it. Typically,
automators spend inordinate amounts of time building programmatic workarounds to try to
solve the problem. There is an alternate
strategy to expensive work-arounds: engineering testability into the system before testing
starts. This presentation will deal with what
steps the automation team can make early in the cycle to prevent the dreaded “control
not identified” problem. Presentation Outline: Understanding why controls are not
seen correctly by an automation tool requires an understanding of how tools identify and
work with Windows controls; this will be discussed. We
will look at the many reasons why some controls are not understood. Then we will look at the options we have for
dealing with the problem. The concept of
testability engineering will be advanced; working with developers to solve testability
issues before they become problems. Solving
the unique political problems that testability raises will be presented. Biography: Jamie L. Mitchell is a Principal QA Consultant at BenchmarkQA. in Minneapolis, MN. He is a contributing editor and columnist for “The Journal of Software Test Professionals.” He previously was a Senior Consultant at CornerStone Consulting, and the Lead Automation Engineer for Distributed Integration Testing / Global for American Express Technologies Organization. He has long been involved in test automation as automator, designer, architect, and mentor. He has worked in test automation since the first automation tools were released in Windows 3.0, including stints with Prudential Insurance, IBM AS/400 division, and ShowCase Corporation. He earned the Master of Computer Science degree in 1992 from Lehigh University and is a QAI Certified Software Test Engineer. He resides in Farmington, MN, and is an active member of the Twin Cities Quality Assurance Association. QA and Testing Web-Based
Applications Concepts: Increasingly the Internet is being populated with web sites that do more than simply display static information. NASA is embracing the use of web-based applications to monitor and control space experiments. Internet commercialization has lead to the development of software assurance and testing practices to ensure proper operation of web-based applications but NASA has not yet adopted or institutionalized these or similar practices. The NASA IV&V Center is funding a three-year research effort to: · Investigate the current and future use of web based applications within NASA · Investigate the tools, techniques and practices being used commercially, by NASA, and by other government organizations to test and assure the quality and safety of the applications being developed · Prepare a best practices guidebook and training in order to institutionalize QA and testing of web-based applications within NASA This presentation discusses: · A brief history of the use of web-based applications · Research planned to develop NASA’s best practices ·
Initial results of the
research Presentation Outline: · Presenter: Tim Kurtz, Software Quality
Assurance Engineer, SAIC/NASA GRC · Introduction · Overview and history of web-based applications · Research plan · Initial results · Future plans ·
Summary Biography: For the last three years, Tim Kurtz has worked for SAIC as a Software Quality
Assurance Engineer in the Risk Management Office (RMO) at GRC in Cleveland, Ohio. RMO performs Safety and Mission Assurance
functions for NASA micro-gravity
experiments. Much of his work has been
developing the Ask Pete tool, a software project planning tool, with research funded by
the NASA IV&V Center. Prior to working
for SAIC, he was responsible for overseeing software surveillance for the Defense Contract
Management Command (DCMC) office at Wright-Patterson AFB in Dayton, Ohio. DCMC
was responsible for providing contract administration for DoD contracts, including
software quality and engineering oversight. Tim
developed tools, techniques and training for performing QA oversight of software being
developed for DoD, as well as, an ISO 9000 supplier certification and assessor training
program. PSQT Track Presentations (Wednesday 3:45 - 4:45 PM) How Can QA and Testing Be Tailored for a
Project? Ask Pete Concepts: Some degree of QA, testing, documentation, verification and validation are necessary for a successful project. But how much is too much? What risks will a project or organization face if not enough QA and testing is performed? For the last three years at GRC we have been working to encapsulate an ISO 9001 compliant tailoring philosophy into a planning tool that uses a project’s characteristics as determined through COCOMO II, GRC’s control level philosophy and NASA’s IV&V criteria. Each of these methodologies characterize a project by examining factors that have an affect on the project’s success. Areas, such as, the development team, resource investment, complexity, and integration requirements all influence the QA, test and documentation effort that would be appropriate the project. The Ask Pete tool is freely available at http://tkurtz.grc.nasa.gov/pete. This presentation discusses: · Overview of the methodologies · Tailored development processes based on an ISO 9001 compliant process · Planning the project and optimizing the plan by adjusting the characteristics that can be controlled ·
The effect of changes in scope on
a project and it’s plan Biography: For the last three years, Tim Kurtz has worked for SAIC as a Software Quality
Assurance Engineer in the Risk Management Office (RMO) at GRC in Cleveland, Ohio. RMO performs Safety and Mission Assurance
functions for NASA micro-gravity experiments. Much
of his work has been developing the
Ask Pete tool with research funded by the NASA IV&V Center. He is currently introducing the tool and providing
training to projects at all NASA centers. Prior to working for SAIC, he was responsible for overseeing software surveillance for the Defense Contract Management Command (DCMC) office at Wright-Patterson AFB in Dayton, Ohio. DCMC was responsible for providing contract administration for DoD contracts, including software quality and engineering oversight.Optimizing Inspections Through the
Application of Statistical Quality Management Techniques Concepts: Software inspections can be an extremely effective method for
removing defects early in the software life cycle while the removal cost is still
relatively low. We have found that many
organizations don’t understand how to calculate their return on investment and
therefore don’t manage their inspection process effectively. An open-loop inspection process that is not
measured and pro-actively managed, is unlikely to perform as well as it could. In fact, it could actually cost more than it
save. Our experience has shown that inspections can be effectively
characterized by a relatively small number of measurements: effort, product size, and
defects. When these characteristics were
measured consistently, it became possible to manage the quality of the review process and
the quality of the product under review. This
entailed tracking product quality costs across the software life cycle and understanding
and quantitatively managing the correlation between review rate and review yield. It became possible to forecast the number of defects found in
downstream test processes and to compare the predictions to actuals using statistical
techniques. If a product showed an unexpectedly high number of defects in test, it was
returned to inspection. Defect data from
test was fed back into the inspection checklist resulting in a self-optimizing closed loop
process. Use of a structured defect prevention process in tandem with the inspection
process engaged the developers in process improvement and greatly improved the quality of
defect data and ultimately of process yield. Several optimization strategies are considered, including the use of
bench checks prior to team inspections, optimizing the size of the inspection team,
inspection meeting duration, and inspection frequency.
Frequent short inspections covering a relatively small number of products
can have a significant performance advantage over less frequent inspections that attempt
to cover larger work products. We present
performance data from large and small inspection teams as well as from single person bench
checks, including the correlation between review rate and inspection yield, defect density
predictions, and relative cost of inspection and test.
Presentation Outline:
Biography: Ellen George
has 18 years of experience in software development, software process improvement, and
project management. She has held
positions ranging from developer to software manager of large scale embedded development
programs to manager of the Software Engineering Process Group. Ellen, together with Steve Janiszewski, led the
introduction and institutionalization of Inspections and Defect Prevention into
AlliedSignal’s Teterboro New Jersey site, helping the site to become the first CMM®
Level 4 site within the corporation. She
later became the software project manager of Allied Signal’s first PSPSM/
TSPSM project. Ellen has since become an SEI authorized PSPSM
instructor and TSPSM launch coach. More recently, Ellen was a member of
Honeywell’s corporate Software Six Sigma organization, helping to lead the deployment
of software process improvement initiatives in over 100 sites worldwide. She has been
active in training and management consulting on the application of software process. Ellen
holds a BA degree in Math from Fordham University, and both an MS in Computer Science
& a Masters in Technology Management from the Stevens Institute of Technology. Steve Janiszewski has 30 years of experience in all phases of software development, management, and process improvement. As Manager of the Software Engineering Department in Teterboro New Jersey, Steve quickly recognized the need to quantitatively manage the software process improvement effort. Together with Ellen George, he led the introduction of inspections and defect prevention, propelling the site to become the first CMM® Level 4 site within the AlliedSignal corporation. Since 1997, Steve has been leading the introduction of PSPSM and TSPSM at AlliedSignal. He has also been active in consulting on the application of software process to diverse domains including aerospace, medical instrumentation, industrial automation, automotive system, and financial systems. Prior to joining PS&J, Steve was the Director of the Honeywell corporate System and Software Six Sigma organization. At Honeywell, Steve’s responsibilities included providing process assessments, training, management consulting, and improvement planning assistance throughout the corporation, servicing over 6000 software engineers in more than 100 locations world-wide. Steve is an SEI authorized PSPSM instructor and TSPSM Launch Coach. He holds a MS and Ph.D. in theoretical physics from NYU. Software
Requirements Validation/Verification Concepts: This presentation covers a software
requirements verification effort conducted on an existing US Government system that has
been in operation for many years. The system
had never undergone an extensive formal or acceptance test activity. The system had many problems as reported by the
users. The intent of the verification effort
was to determine where these problems existed in relation to the expectations of the
users. The expectations of the users should
be reflected in the functional and performance requirements. The effort is to verify that the system in
operation meets it functional and performance requirements.
Requirements for the software were sketchy and existed in various formats
and documents. Updates to the system were not
well managed or documented. The system had
gone through incomplete initial acceptance testing at the time of delivery. A second effort to test the system was under
taken years later that ended in dismissal of the contractor soon after the effort started. The MITRE Corporation was asked to support the
Government agency in the verification effort. The
presentation will only cover
the duration of the effort that MITRE was involved in which does not include conducting
the actual verification.
The
presentation will focus on the identification and proper documentation of the
requirements, the test plan, test scenarios, detailed test procedures and the review
process with the stake holders. Many real project examples will be presented that support
the following outline. Presentation Outline:
· Introduction · Approach/Methodology · Responsibilities · Requirements Reverse Engineering (supported with project examples) · Verification Methods (supported with project examples) · Verification Scenarios (supported with project examples) · Verification Procedures (supported with project examples) · Requirements Tracability Matrix (supported with project examples) · Verification Plan (supported with project examples) ·
Conclusion Biography: Al
Florence has been employed at major technology firms, and is
currently employed at the MITRE Corporation. He
has been involved in all phases of the life cycle from concept to retirement in different
disciplines including, software, systems, test, configuration management, and quality
assurance as a developer and as a manager. His work has involved many diversified
projects: spacecraft; aircraft; missiles, weapon systems; particle accelerators;
simulation; and information systems. He has
been involved with the definition, specification and validation of requirements on many of these projects. Mr.
Florence holds a BS degree from the University of New Mexico in mathematics and physics
and did graduate work in computer science at the University of California in Los Angeles
and at the University of Southern California. Mr. Sanders is currently employed at the MITRE Corporation and has
previously been employed at major technology firms. He
has over twenty years of combined experience in systems engineering, software engineering,
and management leadership in a wide range of applications. His work has involved many
diversified projects: air traffic management; business systems; electronic systems; flight
planning; information systems; and telecommunication.
The diversity of these applications has given Mr. Sanders the experience and
adaptability to provide him with the expertise needed to plan, coordinate, control, and
support complex programs from inception through the entire life cycle. His experience in the development of Request for
Proposals as well as engineering plans such as Program Management Plans, System
Specifications, System Design Documents, and Project Implementation Plans has given him an
overall view of all aspects of program management. Mr.
Sanders holds a BS degree in Electrical Engineering and is also an inventor, having self
obtained the resulting patent. A CMMI Compatible Risk
Management Process Concept: Risk management is
the identification and treatment of risks in a most cost-effective way. The newly released
CMMI-SE/SW model –the successor of the Software-CMM published in 1993- has a detailed
outline of 3 specific goals and 7 specific practices to determine a capability rating in
the Risk Management Process Area:
o Determine
Risk Sources and Categories o Define
Risk Parameters o Establish
a Risk Management Strategy
o Identify
Risks o Evaluate,
Classify, and Prioritize Risks
o Develop
Risk Mitigation Plans o Implement
Risk Mitigation Plans In order to
achieve a desired capability rating a sound process covering those goals and practices has
to be employed. Biography: Gerold Keefer was educated at Fachhochschule fur Teknik Esslingen (FHTE) in the Department of Telecommunications and received his Degree: Dipl.-Ing.(FH). Since 1993, Gerold has been working as a consultant in the field of software development, quality assurance, integration and acceptance testing. His clients include Alcatel, IBM, DEKRA, Dresdner Bank, German Post, and Robert Bosch. Since 1999 CEO and founder of AVOCA LLC. Gerold has been a speaker at GPM Stuttgart Branch, 2000. "Integration of project management and quality management" and the German Chapter of the ACM, Stuttgart University, 1999."CMM, ISO and after that ?".PSTT Feature Presentation (Wednesday 3:45 - 4:45 PM) The Lighter Side of QA or What Happened to
Common Sense? Concepts: A light, thought provoking, politically incorrect, realistic, sarcastic, ironic, and useless presentation on the bits and pieces that go around while establishing and automating a Software QA process. (Yet, the only presentation that will really help you understand why the process fails.)Biography: |
|
|
