Fewer resources-more work-shorter deadlines-critical business applications ... what impact do these factors have on your application delivery? Do you question the "Go/No Go" recommendations you've provided to management? The common aspect in each of these factors is risk! How much do I have? How much is acceptable? What must be tested in the timeframe available? David Kapelanski describes in detail how to implement a risk-based testing strategy throughout the development lifecycle of your applications.
Better Software Conference & EXPO 2004
Scrum is an agile, lightweight and team-based process to manage software and product development within iterative software development lifecycles. By wrapping around existing engineering practices such as XP or RUP, Scrum generates many benefits of agile development with the advantages of simple implementation. Properly understood and implemented, Scrum significantly increases productivity and facilitates adaptive, pragmatic systems development.
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.
A revolution in the business of software is coming . . . The boundaries between the business and IT from one enterprise to another will disappear. The space around functional system silos will dissolve. How we develop and deploy software will have to undergo radical change, challenging our entire thought process about how, why, and for whom we build it. Already today, delivery cycle times are down to days and business processes embedded in software represent invaluable corporate intellectual property.
Software projects are like stud poker hands-all have great potential at the beginning, additional information becomes available as they progress, and it's hard to remain detached from the emotion of the game. The goal of an interim project review is to offer an independent analysis of the current state of a project and a pragmatic assessment of the project's chances of success or likelihood of failure. Learn the steps for performing an objective project assessment, getting the facts, and keeping emotions in check.
Whether you are using the Rational Unified Process (RUP), agile methods, spiral development, or a home grown iterative approach, there are some fundamental practices that can make a big difference. Esther Derby looks at ways to manage schedules and resources, keep progress visible, mitigate risk, and dynamically improve estimates throughout the project. After comparing and contrasting popular iterative process models, Esther offers practical, easy to implement practices to enhance your current process.
Most of the emphasis for development groups seeking improvement is to change processes and project management practices. But what are we missing? Why does our software often disappoint customers? One reason is quite simple-systems are built by people. People must work together, communicate well, learn from each other, and change personal behaviors based on experiences. In short they must operate as a team for the software to meet their customers' functional and quality needs.
Task Stack Planning (TASAP) is a novel approach to systematic and quantitative project management. With this process you break down work into small "packages" that form the basis for comprehensive planning, tracking, and reporting activities. Team members participate in bottom-up planning activities, allowing unplanned work to be seamlessly integrated into the operational planning process. The operational plan is updated weekly with all results fed back into the overall plan.
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.
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.