tspsymposium2014

1. Teach an Agile/Scrum process as a base framework
2. Explain how to evolve the framework to address specific project goals and problems
3. Demonstrate how to start with a basic framework and evolve it using practices from PSP/TSP, ISO, CMMI, etc.

• Learn a basic framework for managing software projects
• Identify what risks and challenges exist, given your organization’s complexity
• Learn to evolve a framework to fit your organization’s situation

• Preparing for a successful project launch
• Leveraging Dashboard functionality to empower and accelerate team planning efforts

• Collecting data, managing team and personal plans, and facilitating team work
•  Understanding and customizing reports to monitor team progress, pinpoint project problems, and report to management

• Insight into the underlying data and tool architecture to accelerate mastery of the Dashboard

•  Tips for using the Dashboard more effectively
•  Advanced features for high-maturity teams

• Use the Process Dashboard confidently during TSP launches
• Use the tool more effectively and work smarter, with less overhead
• Apply advanced techniques for project planning and tracking
• Transition these skills to others in your organization

• Understand key concepts
• Acquire a technique for communicating the tradeoffs of technical debt to colleagues and managers
• Learn about practical tools and techniques that can address part of the problem today
• Gain knowledge of a foundation for managing tradeoffs based on models of economic impacts

Investigations into potential causes of Unintended Acceleration (UA) for Toyota vehicles have made news several times in the past few years. Some blame has been placed on floor mats and sticky throttle pedals. But a jury trial verdict found that defects in Toyota's Electronic Throttle Control System (ETCS) software and safety architecture caused a fatal mishap. This verdict was based in part on a wide variety of computer hardware and software issues. This talk will outline key events in the still-ongoing Toyota UA story and pull together the technical issues that have been discovered by NASA and other experts. The results paint a picture that should inform not only future designers of safety-critical software for automobiles but also all computer-based system designers.

1. Determine and score the options and make decisions.
2. Explore implementation alternatives.
3. Build a target architecture.
4. Build a roadmap to move over time to the target architecture.

• They customized planning and quality metrics and committed to follow disciplined measurement activities, even when traditional tools and repositories were adjusted.
• On average, these organizations could have been defined as small and medium enterprises. But even as very small entities, these projects were based on self-directed teams committed to challenging and achievable goals and encouraged a successful cross-training that team members consciously followed.
• All the companies implemented TSP cycles for the first time in their organizations. Some started with non-development software projects in which virtually all productive roles in the organization (analysts, architects, developers, testers) participated, which substantially reduced the resistance to change and motivated senior executives to continue the TSP implementation in subsequent cycles of the projects.

It is our intent that they form the industry de facto standard taxonomy of testing pitfalls and will be widely used for the following:

1. Training materials for testers and testing stakeholders
2. Standard terminology regarding commonly occurring testing pitfalls
3. Checklists for use when producing test plans and related documentation; evaluating contractor proposals, test plans and related documentation (quality control), and as-performed test process (quality assurance); and identifying test-related risks and their mitigation approaches
4. Categorization of pitfalls for metrics collection

• fear-mongering: An attack strategy involves creating infectious anxiety, scaring others into believing that a good idea is far too risky to pursue.
• delay: Stalling an idea with never-ending questions or requests for more meetings. A more creative approach is to focus attention on an urgent problem that, the attacker insists, can be resolved only if the new idea is put on hold.
• confusion: Throw irrelevant numbers, facts, and convoluted questions into the discussion, and suddenly support starts to waver.
• ridicule: A direct attack on you, the creator of the idea, engendering indirect doubts about the idea itself.

• applying what we were taught
• our first great team
• producing near-zero-defect products
• the ups and downs of tools and automation
• design for the long term
• simpler, smaller, better
• losing things
• the well-engineered, low-defect products that no one wanted
• filtering out the defects
• making reviews effective
• preventing defects

Video-game development is arguably one of the most difficult kinds of software development due to its combination of performance requirements, diverse team, immovable deadlines, and the fact that the software must be more than functional, it must also be fun. In this talk, Jesse Schell explains what he has learned from 20 years of professional game development about the secret forces that help teams succeed or cause them to fail.

1. Reduce cost of quality of software development and software engineering across the corporation.
2. Improve the overall maturity of approach and skill set in the IT department by implementing quality processes.
3. Reduce cost of quality on COTS applications, server and network infrastructure, and business processes.
4. Streamline testing by automating testing of key enterprise systems.

Since its inception in 1988, the CERT Coordination Center (CERT/CC) has been analyzing and coordinating software vulnerabilities. The CERT/CC’s vulnerability response process includes discovering and reporting, analyzing, coordinating with vendors (software development organizations), and public disclosure. The results of this work are documented in the Vulnerability Notes Database. One observation highlights a disconnect between software engineering, design, and development practices and constantly evolving threats posed to highly interconnected software and systems.

The CERT/CC contributed to the Data-Driven Software Assurance (DDSA) project recently published by the SEI. A significant area of the DDSA research investigated operational vulnerabilities that “likely had their origins early in the life cycle, in the requirements and design phases.” To give one example, the lack of threat modeling, particularly in emerging domains, leads to insecurity.

This session will provide background on and examples of the life cycle of vulnerabilities, with the goal of improving the connection between software development and increased operational security. The session will also highlight design-related causes of vulnerabilities and software security issues affecting the growing “Internet of Things.”

• “FBI, Secret Service Investigate Reports of Cyber Attacks on U.S. Banks” (Reuters)
• “Home Depot Confirms Hack; Cyber Attack Could Affect Customer Credit Cards” (Huffington Post)
• “300 Oil Companies Hacked in Norway” (The Local)
• “Cyber Attacks Cause Data Loss to Community Health Systems” (SPAMfighter)
• “ISIS Claims Sony Cyber Attack, Makes Bomb Threat Against Senior Exec John Smedley” (news.com.au)

From the beginning of a little process to the start of a hybrid Scrum-Team Software Process (TSP) product development process, the presenters will describe the two-year development methodology journey of a fast-growing company leading solutions for medical device information systems. The hybrid development method is a perfect example of TSP as a data and process framework combined with the best of Scrum practices and adapted to the regulated environment of health care. The presenters will explain how the journey evolved from the launch of one small software development TSP team to cross-functional hybrid team launches.

Have you ever worked on a software project that didn’t result in what the users really wanted? Stakeholders often have requirements that they aren’t aware of. Uncovering them can be challenging and involves ways of thinking not found in more traditional elicitation approaches. It requires probing interviews and expanded use of context information that go well beyond what the requirements engineer typically achieves with a specification-driven process. It requires a method that transforms stakeholders’ tacit knowledge into themes of experience so that insightful and innovative requirements can emerge.

The KJ+ method for eliciting unstated requirements, currently under development by a research team at the Software Engineering Institute, helps determine the unstated needs of the varied stakeholders typical of today’s large, diverse software projects. This method will be scalable to address the needs of multiple categories of stakeholders; be usable by a diverse, non-collocated team of requirements analysts; and result in a more complete set of requirements for subsequent system design, implementation, and sustainment. It can be used to support both traditional requirements specifications and Agile user stories.

This tutorial will present the traditional KJ method for eliciting unstated user needs and the extensions that allow KJ to be used in a virtual environment. Also included are activities integral to learning the KJ+ method:

• Role-playing interviews to elicit unstated needs and their context
• Distilling interview notes into context-rich need statements
• Identifying affinity groups for the statements
• Deriving unstated needs from the affinity groups
• Categorizing the unstated needs as must-be’s, satisfiers, or delighters

Practitioners who are concerned with delivering exciting and innovative features will learn how to apply KJ+ in their own projects. Researchers will find the kinds of requirements obtained using KJ+ vs. more traditional approaches of interest.

 Learning Outcomes

• Appreciate the opportunities lost due to missing requirements
• Understand how to use the KJ and Kano analysis methods to identify and analyze unstated requirements
• Understand how to tailor these methods for virtual environments