|
|
Service-Oriented Architecture - Exposed Service-Oriented Architecture (SOA), incorporating methods for Web services to communicate dynamically, promises to significantly improve organizational operating efficiency, change the way companies conduct business, and even alter the competitive landscape. However, Service-Oriented Architecture is a strategy rather than an objective, and, like any strategy, it is of no value unless it is implemented. With illustrations from companies who today are using SOA to transform their organizations, Sharon Fay shares current practices for exposing Web services and XML to internal development teams, outsourced development, external trading partners, and customers. Learn why reuse is a key method for supporting integration of SOA implementations and how it is being accomplished. Take away a set of metrics that you can use to measure the level of SOA adoption, development productivity gains, and organizational agility.
|
Sharon Fay, Flashline, Inc.
|
|
|
eXtreme Architecture and Design for Test eXtreme programming emphasizes test-first coding-you write the tests before writing the implementation code. You can apply the same approach in design when developing a complex system, including an architecture to support testing. To be successful, systems developed with agile methods must support a high level of testability and test automation. For large distributed systems, more sophisticated testing is needed to help determine which components may be contributing to failures. For such complex systems, you should architect the system for testing rather than add testing functionality as an afterthought. Ken Pugh presents a framework that employs polymorphic-style internal and external interface patterns to ease the work of testing and debugging. He also covers adding test-only functionality, test-only outputs, and test-only logging to interfaces.
|
Ken Pugh, Pugh-Killeen Associates
|
|
|
Refining Requirements with Test Cases Requirements are supposed to be the basis of most test cases, but can you use test cases to define what the system needs to do--to improve or to actually become the requirements? To some degree, your development process dictates the opportunities you have for test cases to define or refine requirements. However, everyone can benefit from test case writing techniques to identify missing requirements, surface ambiguous statements, and expose implied requirements early in the process. Find out how Tanya Martin-McClellan produces test cases that accurately reflect the requirements, as they are understood at the time, and conducts team reviews to find the gaps and misunderstandings. Although more time is spent writing and rewriting test cases, less time is spent later discussing requirements.
- Find the vaguely defined parts of the requirement definition
- A template of implied requirements you can customize
|
Tanya Martin-McClellan, Texas Mutual Insurance Company
|
|
|
Expressing Requrirements as Users Stories - an Agile Approach Expressing requirements as user stories is one of the most broadly applicable techniques introduced by eXtreme Programming and adopted by other agile development processes. User stories are an effective approach for capturing requirements from an agile project, not just those using XP. In this session learn what user stories are, how they differ from other requirements approaches, and why you should consider using them. You also will learn the six attributes all good stories must exhibit and see how to get started with user stories. Whether you are a developer, requirements analyst, tester, manager, or even a customer interested in applying agile techniques to your projects, this session is for you.
- The differences between user stories and other requirements documentation
- Attributes of "good" user stories
- Examples of User Stories from agile development projects
|
Mike Cohn, Mountain Goat Software
|
|
|
Go on Offense: Prevent Web Application Security Breaches You must successfully test your browser-based applications before hackers do the job for you! Whether you have to worry about critical business applications or government compliance issues like HIPPA (Health Insurance Portability and Accountability Act of 1996) or GLBA (Financial Services Modernization Act of 1999), security failures can cost your organization big dollars, unnecessary embarrassment, or both. Hackers have gone beyond simple exploits of open IP ports and standard applications such as Telnet, FTP, and Sendmail, turning their attention to commercial and custom Web applications. To thwart the hackers, test engineers must focus their efforts on common and uncommon security vulnerabilities within the application, including SQL injections, session hijacking, cross-site scripting, and more.
|
Dennis Hurst, SPI Dynamics Inc
|
|
|
Undoing Testing Methods in Agile Projects The period 2002-2004 was one of enormous progress in figuring out how testing fits in on agile projects. Test-driven design is more about designing and writing the code than about finding bugs. New testing tools such as xUnit and FIT came out and received a lot of use by early adopters. The hopeful notion that customers would write acceptance tests to find bugs was expanded, challenged, and deepened. With all that progress, it's hard to be dissatisfied with these methods in agile projects. But past ways of thinking are holding us back. To make further progress, we have to split our notion of testing into two parts: the task of after-the-fact product critique, and a role that has nothing at all to do with bugs and, really, little to do with the word "testing." Brian Marick, a founding member of the Agile Alliance, explains what that role presents and some ideas on how to fill it.
|
Brian Marick, Testing Foundations
|
|
|
Early Testing without the Test and Test Again Syndrome Developers and testers sometimes get into a frustrating dance in which the developers provide code for test, the testers run tests and document findings, developers fix the problems and re-release for testing, and the testers rerun and document new, different problems, and so on. For good reasons teams often begin "formal" testing on new software while it is still being coded. In this case the testers are working full tilt: running tests, investigating and isolating faults, writing up defects, rerunning the tests, and verifying fixes; but a lot of time is wasted by everyone on problems the developers already know about. As a manager, developer, or tester, you can break out of this vicious cycle and get to a better place. Douglas Hoffman shares his experiences seeing, participating in, and getting out of the test and test again syndrome.
- How to know when the test and test again syndrome is happening to you
|
Douglas Hoffman, Software Quality Methods LLC
|
|
|
People + Process = ROI! Return on investment (ROI) is a widely used approach for measuring the value of new or improved technology and business processes. Rather than limiting the discussion on ROI calculations to cost cutting measures, the most significant opportunities often come from addressing the overall business objectives. You need to step outside the focus of the IT department and relate improvements to opportunities for increased business revenue and customer value. The resulting impact on revenues makes the ROI argument for process improvement a compelling one. Discover the myths and realties of software process improvement and how to build a business case for improvement initiatives. By aligning business goals with areas of leverage and improvement plans, you will find both business and IT management more receptive to software process improvement programs and initiatives.
- The real ROI from software process improvement
|
Geoffrey Hewson, Software Productivity Center, Inc.
|
|
|
Using Defect Data to Make Real Quality Improvements A large development organization was challenged to decrease production defects by at least 70 percent. Without extra money or time to install major process changes, what should be done? For a baseline, there was a production defect database that had been running at a steady state for over a year, but no way to size the many different projects and no appetite for either function points or measuring lines of code. In this interesting case study, Betsy Radley reports how they used approximations and sometimes crude assumptions to develop measurements from the defect data. These measurements identified applications that had the fewest product defects. Find out how they used that information to look for processes and tools used in these "good" applications and then applied them to the "bad" applications.
|
Betsy Radley, Nationwide Insurance Company
|
|
|
Questions to Ask a Software Vendor about Security (and Verify) before Purchase How do you choose which software vendor's product to buy? For a long time, CRM packages, ERP systems, and other commercial software selection criteria have come down to factors such as performance, compatibility, reputation of the vendor, support, and price. Security, though, has become a looming factor in the total cost of ownership and the risk of selecting one software product over another. Ed Adams describes the tough questions you need to ask vendors about security and how to extract critical information from them. Find out the steps to verify that their statements are accurate and their answers complete. With an approach for quantifying security risk before purchase, your organization will make more informed acquisition decisions.
- A security assessment approach for purchased software packages
- Quantifying security risk in software packages before purchase
|
Ed Adams, Security Innovation LLC
|
