|
|
Patterns of Testability Testability requires interfaces for observing and controlling software, either built into the software itself or provided by the software ecosystem. Observability exposes the input and output data of components, as well as monitoring execution flow. Controllability provides the ability to change data and drive actions through the component interface. Without testability interfaces, defects are harder to find, reproduce, and fix. Manual testing can be improved by access to information these interfaces provide, while all automated testing requires them. Alan Myrvold shares software component diagrams that show patterns of testability. These patterns will help you architect and evaluate the observability and controllability of your system. Apply these testability patterns to describe and document your own testability interfaces.
|
Alan Myrvold, Microsoft
|
|
|
Architecture and Design: What Managers Need to Know In many current software development approaches, architecture and design are downplayed. Rather than actually architecting products, good designs are assumed to "emerge." Yet, managers must be confident that their products are well designed. In their efforts to produce products quickly, teams may overlook vital architecture and design issues, such as performance, security, usability, and accessibility. When managers try to help, they can be deterred by jargon and tools that are difficult for non-programmers to understand. Jonathan Kohl illustrates a way for managers to understand and influence product architecture and design. You don't need detailed technical skills to provide valuable insight into a project. Learn how to understand an application and its impact in three contexts: the code (where the application is developed), the system (where the application operates), and the social context (where the application is used).
|
Jonathan Kohl, Kohl Concepts Inc.
|
|
|
Ensuring Quality Requirements Quality assurance is more than just testing software through processing a series of controlled inputs and outputs. It must also include an assessment of all the deliverables associated with the project. Developers and testers often view software documentation as merely a source of information, not as artifacts that require evaluation. All software documentation should undergo a rigorous quality assessment just as the actual software is subject to comprehensive testing. Mark Haynes describes quality models and attributes that can be used to evaluate requirements documents. He shows how imprecision (that will haunt you later) can be detected and removed through a set of formal criteria and informal heuristics. To experience using these techniques, Mark shares examples of poorly written requirements for you to evaluate and improve. Additional quality attributes, even subjective ones, can be used to conduct a quality dialogue.
|
Donald Haynes, Synova
|
|
|
Agile Engineering for Architects Agile development requires architects and architecture, but the current user story-centric approach ignores the qualities of systems, instead overly focusing on features and functions. Sadly, developers who depend primarily on stories miss enormous value-creation opportunities for stakeholders. Developers often think system qualities (non-functional requirements) are someone else's responsibility to define. Even when defined, these qualities are typically not quantified, instead specified with vague terms such as "faster" and "better". Ryan Shriver believes that architects are needed to build successful systems. Architects think like engineers and actively participate in quantifying the key system qualities and then designing to implement those qualities. Ryan demonstrates techniques architects can use that are lightweight-but-rigorous and can be applied to agile projects of any size.
|
Ryan Shriver, Dominion Digital
|
|
|
Getting Agile with Legacy Code Applying agile methods to legacy code is challenging. You have to live with code that is not as testable or as modular as you'd like, and you have to manage support concerns that disrupt your iteration plan-all while trying to establish new build and testing practices. Even if your project is agile, you may have dependencies on legacy projects that are not delivering at iteration boundaries. Steve Berczuk explains how to be agile with a legacy code base using design, testing, build, and software configuration management practices so that you can be agile even when your code is not. You'll leave better understanding how to balance the requirements of working with an existing code base with the desire to have a more agile development environment.
|
Steve Berczuk, Cyrus Innovation
|
|
|
Test-Driven Development Takes On Embedded Software Embedded software developers face the same challenges as other software developers-unpredictable schedules, poor quality, and the problems that follow. In addition, embedded software developers must overcome the realities of concurrent hardware/software development, scarce target hardware availability, long download times, high deployment costs, as well as the challenges of testing embedded C. Test-Driven Development (TDD), a key agile practice, helps software developers improve schedule predictability and product quality; but very few embedded software engineers apply TDD to their craft. James Grenning describes the problems addressed by TDD, as well as the additional challenges and benefits of applying TDD to embedded software. He provides valuable lessons for doing TDD in the hostile environment of C. After the class, get hands-on experience with James' independent study exercise, "TDD in C".
|
James Grenning, Renaissance Software Consulting, Co.
|
|
|
Behavior-Driven Database Design Agile methods focus on creating executable code quickly and with fewer defects. But what about the database? The database is "the" component of the application that is thought to be the least agile and often excluded from agile development. Pramod Sadalage explains how the concepts of Behavior-Driven Development (BDD) can be applied to database development to drive the design of the database using executable specifications. Pramod describes how performing BDDD (Behavior-Driven Database Design) allows us to specify the behavior of the database as it is expected by the code running against the database, how BDDD allows us to easily refactor the database, and how BDDD provides an easy way to document the database design and behavior.
|
Pramod Sadalage, ThoughtWorks Inc
|
|
|
Agile Development Practices 2008: Refactoring: Where do I Start? Since Martin Fowler completed his now-classic work Refactoring: Improving the Design of Existing Code, few programming practices have been more effective-and more controversial-than refactoring. Refactoring is effective when you study and practice it diligently. It remains controversial because many development managers think developers should be adding features, not reworking old code. J. B. Rainsberger takes you deep inside the process of refactoring, including how to start reaping the benefits of refactoring while minimizing the disruption of learning a new practice, how to safely refactor code you don't know well, and the four key elements of simple design that should guide your refactoring. He explains the hazards of refactoring, when not to refactor, and how to refactor in such a way as not to upset your boss. After this presentation, you will be able to refactor your own code more confidently and effectively.
|
JB Rainsberger, Diaspar Software Services
|
|
|
Integrating Enterprise SOA Architecture with Scrum Development Methodology Many processes used to implement an enterprise architecture are in conflict with the agile development approach. An effective enterprise architecture framework represents the organization as it is today and as it is envisioned in the future. However, a key agile concept is that we design and build for today-and worry about the future only when it arrives. Steven Driver has found that a small change to the Scrum process flow allows easy integration of an enterprise architecture into the agile development of new systems. The translation of enterprise architecture into application architecture requires critical touch points within the Scrum process to emphasize service-based development required within the sprints. By combining an enterprise architecture approach using SOA (service-oriented architecture) and the Scrum development methodology, an organization can achieve effective system development-in both the short and long term.
|
Steven Driver, Airlines Reporting Corporation
|
|
|
API Design for Testability Many who try to unit test their applications-whether using agile or traditional methods-quickly find that doing a thorough job can be difficult if the code was not designed with testability in mind. Roy Osherove describes dependency injection methods for designing APIs so that they are easier to test. He explains how design patterns can help and how to implement applications with interface-based programming. Roy shares his insight on what "evolving a design" really means in the context of test-driven development. For those who are living with legacy code, he discusses special techniques for managing and implementing unit testing. In addition, Roy discusses the build life cycle and how continuous integration fits into the mix.
|
Roy Osherove, Team Agile
|
