tspsymposium2014

Is your process huge, complicated, and full of bells and whistles? Does it look nice, create lots of paper and meetings, but not result in a great system? In this tutorial, you will start with a basic implementation of Scrum (as an example starting point) and adapt it to meet the needs of your customers, team, and organization. The method of adapting a process can then be used back in your own work place (Agile or not).

The interest in Agile, CMMI, and PSP/TSP development practices continues to grow as companies seek more efficient methods of developing software while meeting market demands for delivery. These methods can help organizations face end-user issues early and provide a mechanism to deliver incremental functionality to customers. However, implementations don't always go as planned, and without some due diligence, chaos is easy.

This tutorial will do three things:

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.

Learning Outcomes

• 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

Many legacy systems were built decades ago using the technologies available at the time and have been operating successfully for many years. But they suffer from being built with components that are becoming obsolete, high licensing costs for COTS components, awkward user interfaces, and business processes that evolved based on expediency rather than optimality. In addition, new software engineers familiar with current technology are unfamiliar with the domain; documentation is scarce and outdated; the business rules are likely to be embedded in code that was written in an obsolete language using obsolete data structures; and the cadre of aging domain experts maintaining them is unfamiliar with newer technologies.

There are a number of optional large-grained approaches to modernization. We propose a rational way of using system architectural concepts to develop architectural options, create a scorecard, apply the scorecard, and present the results with recommendations to decision makers. The approach includes four steps:

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.

The presentation will describe how this approach was applied to a large-scale IT modernization effort.

We present an architecture-led incremental assurance strategy throughout the development life cycle to address the challenges of certifying mission- and safety-critical systems that have become increasingly software reliant. This strategy is pursued in an international SEI, industry, and government collaboration. For aircraft, software as percentage of total system cost has grown from 33% in 1997 to 67% in 2010, with verification-related software rework cost alone exceeding 50%. Systems are currently verified against ambiguous, incomplete, and inconsistent requirements. Industry studies show that 70% of embedded software system defects are introduced in requirements and architecture design, while 80% are discovered post-unit test, with rework cost as much as 300–1,000 times the cost of in-phase correction.

The strategy involves a paradigm shift from build-then-test to an architecture-centric engineering approach that utilizes analytical virtual system integration based on the SAE Architectural Analysis & Design Language standard to discover problems earlier in the life cycle. This paradigm shift is being pursued by an international aerospace industry initiative known as System Architecture Virtual Integration, with return on investment studies showing major cost savings.

The strategy measurably improves requirement coverage through architecture-led requirement specification—incorporating operational requirements such as performance, timing, safety, reliability, and security—and systematically addressing hazards in the process. The strategy applies contract-based compositional verification one architecture layer at a time to ensure that requirements are addressed throughout the life cycle. Finally, the strategy incrementally manages an assurance plan and its execution throughout the life cycle, producing assurance case artifacts for certification.

A software product line is a set of software-intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way. Organizations developing a portfolio of products as a software product line are experiencing order-of-magnitude improvements in cost, time to market, staff productivity, and quality of the deployed products.

This presentation will introduce the essential activities and underlying practice areas of software product line development. It will review the basic concepts of software product lines, discuss the costs and benefits of product line adoption, introduce the SEI Framework for Software Product Line Practice(SM) guidelines, and describe approaches to applying the practices of the framework.

This presentation will describe how basic Team Software Process (TSP) principles were used to bring the Smart Grid Maturity Model (SGMM) project under control. The SGMM project is a non-software project composed of geographically dispersed, part-time resources from multiple departments within the organization. This presentation will follow the journey of the SGMM from conducting an initial project launch through developing two version releases of the SGMM product suite. It will discuss how the team first got its schedule under control, then focused on quality and cost. Particular attention will be paid to how MS Project was used to budget and track project costs, including manpower, travel, subcontractors, and all other expenses. We will also discuss how other aspects of the TSP were tailored to our situation including roles, lessons learned, and weaknesses with our approach.

The Performance and Capability Evaluation (PACE) establishes a framework to build the management capabilities that transform outsourcing companies into strategic business partners. Firms with an outsourcing strategy need data for decision making and need the ability to govern the service portfolio in order to enjoy the benefits of successful relationships with software providers. Internal resources’ skills correlate directly to the firm’s transformation success. To obtain this success, the client must help its provider succeed by helping it grow and improve capabilities and performance.

The PACE framework offers measurable goals, a baseline for process improvement, and a maturity path to documentation of metrics and performance reporting. This framework can support a Vendor Development Program based on the four dimensions of PACE: coverage, fidelity, performance, and customer satisfaction. It also provides the database structure to collect the vendors’ project data. Establishing this program poses a double challenge: it is not only one firm’s internal transformation; it also requires external firms’ transformation.

This presentation will describe periodic team survey data collection initiated at Hill Air Logistics Complex during 2014 that was analyzed and modeled using traditional statistical analysis and modern structural equation modeling (SEM). Results of the analysis and SEM will demonstrate how team performance may be enhanced through a focus on key team strengths and weaknesses associated with team practices discussed in TSP: Leading a Development Team, by Watts Humphrey. The authors seek to show the practicality of collecting such practice data and combining it with existing TSP data to reduce barriers to successfully implementing stronger team practices and achieving more sustainable team performance.

Data from the Personal Software Process (PSP) courses indicates that the PSP improves the quality of the developed programs. However, since the programs (exercises of the course) are in the same application domain, the improvement could be due to programming repetition. In this research, we try to eliminate this threat to validity in order to confirm that the quality improvement is due to the PSP. In a previous study, we designed and performed a controlled experiment with software engineering undergraduate students at the Universidad de la República. The students performed the same exercises of the PSP course but without applying the PSP techniques. Here we present a replication of this experiment. The results indicate that the PSP and not programming repetition is the most plausible cause of the important software quality improvements.

Students experience significant over- or underestimates in new program development when it follows the Personal Software Process (PSP) PROBE process. This presentation overviews how this potential problem can be reduced or solved by extending the PSP PROBE process.

A strategy is to find a logical evaluation combination of the productivity, correlation, and β1 and β0 used in the PROBE process. The estimated average size and time for a new program to be developed are obtained when method C is selected. The estimated proxy size is obtained for the new program through the PSP relative size table applied to the conceptual design. The estimated average size replaces the estimated proxy size when a student selects method C. If the estimated average size is not reasonably consistent with the past productivity data, the student should select method D for the size estimate. The similar discussion holds for the time estimate.

Another extension that is effective in the PSP PROBE process is to allow selecting method A or B when high correlations are recognized between the estimate and actual values, regardless of whether β0 or β1 satisfies the desired conditions respectively described in the PSP PROBE process, although the PROBE process suggests selecting method C for these cases.

After this extended PROBE process was presented, PSP students demonstrated reaching fewer over- or underestimates on the size and time of new programs.

How do you implement Team Software Process (TSP) on a national scale? Mexico has worked similarly to a TSP team in planning and developing a national rollout for TSP implementation. Mexico is convinced that alone we can do so little, but together we can do so much. We are also convinced that TSP is the key to build and grow small and medium enterprises and to achieve a global position in IT software development. Organizations such as INFOTEC, ITESM, SIE Center, Kernel, and Delaware are sharing TSP benefits across the country in a clustered way.

In this presentation, we will show how INFOTEC led a national TSP initiative to share TSP benefits from promotion to implementation, from training to piloting, from coaching to mentoring, and even in some clusters to achieve a PACE certification. We discuss how the country worked together to develop a national plan starting with a five-state pilot run to drive excellence in performance measures.

This presentation will include overall results in each of the five states. We will include the State TSP Initiative Implementation Plan, Personal Software Process training results, TSP pilot results, and PACE results for different organizations, making a comparison of how each state worked through the national TSP initiative. We will share our lessons learned and our improvement proposals.

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.

The interest in Agile/Scrum software development practices continues to grow as companies seek more efficient methods of developing software while meeting market demands for delivery. Scrum is a software development methodology based on Agile principles. Agile methodologies promote a project management process that encourages frequent inspection and adaptation; a leadership philosophy using teamwork, self-organization, and accountability; and strong customer involvement.

However, Scrum/Agile implementations don't always go as planned, and without some due diligence, chaos is easy. In this session, Neil enumerates the problems to look out for and provides example corrective actions:

• Scrum/Agile overview
• What to use from the Agile Manifesto
• Definition of Scrum
• Scrum risks to look out for and what to do about them:
   – Mistaking speed for progress (many components developed that don’t work together)
   – One-liner requirements (the devil is in the details)
   – Missing architecture/design
   – Missing final system test/validation
   – Missing configuration management
   – Missing risk management
   – Missing process assurance (known as ScrumBut)

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