A project schedule is an essential tool for planning the project, monitoring progress, managing the impact of changes to scope and requirements, and ultimately achieving customer satisfaction. Unfortunately, three common mistakes can make schedules useless-or worse, even destructive to the project: (1) using date constraints when dependencies should be used; (2) using dependencies when resource constraints should be used; and (3) poorly structured work breakdown structures. Using a sample project schedule that has these common scheduling mistakes, Kenneth Katz illustrates their impact through different scenarios for handling them. He shows how revising the schedules with the right practices will result in benefits to the project and the team. Learn how project schedules can become a positive force in your projects.
Project schedules that easily accommodate scope and resource change
Designing Web services is all about the interface. Although tools for Web services development have advanced to the point where exposing application functionality is simple, the ease of building Web services does not diminish the need for careful planning and a highly functional design. Dave Mount opens his presentation by spinning the cautionary tale of slapping together a Web services interface on a poorly structured application. This scenario serves as a reference point for a subsequent discussion of the pitfalls of a poorly designed interface. Dave illustrates techniques for correcting problems and improving the Web services interface. Looking at high profile Web services provided by Google, eBay, and Salesforce.com, he shows how an external perspective that emphasizes consistency and conceptual clarity is key to Web services interface design.
Failure to really understand business requirements, technical specifications, and schedule dependencies has embarrassed more than a few test teams. Before you assign the first test engineer to a project, sit down face-to-face with the customer and keep asking questions until you fully understand the scope of the system or application under test, how they will use it, and what success looks like through their eyes. A full needs analysis is the best preparation for designing a test strategy that will deliver exactly the data your customer needs to decide when they can ship or go live with their software. John Scarborough explores the critical areas of inquiry for conducting a needs analysis, using examples from projects he has worked on over the last five years. Learn to exercise deliberate, critical thinking while following a proven, systematic approach for conducting analyses.
The latest generation of Web technologies-AJAX, improved client-side scripting, support for extensive DOM manipulation in browsers, content syndication, Web service APIs, and simple interchange formats such as JSON-are all driving new, powerful Web applications. Based on his work on real world "Web 2.0" applications, Ivan Krstic discusses the security implications of these new technologies. Ivan describes specific attacks such as Web-based worms, XSS, CSRF, and HTTP response splitting and offers advice on mitigating security risks during the engineering process. Learn how standard security guidelines such as The Confidentiality-Integrity-Availability (CIA) model apply to the modern Web and about the role of cryptography and crypto-engineering in Web security.
When you go fishing, you want to use the right lures, catch lots of fish, and avoid falling out of the boat. Developing requirements for an Agile project is similar-you need to use the right process, get the requirements you need with minimum effort, and introduce minimal risk and rework. Because every Agile project has different needs, goals, and constraints, a "one size fits all" requirements process does not work in every Agile project. In this interactive session, Jennitta Andrea shows you how to fine tune the requirements process based on a unique set of project characteristics. Learn to visualize the distinctive characteristics of a project to determine what work products to produce, how much detail to include, and which tools will provide a payback to the project.
Strategies for shaping your Agile requirements process
Plan-driven development is challenged today by Agile methods, outsourcing trends, and a new emphasis on IT governance and program management. The days of straightforward software development projects are over as project managers must deal with delivery pressure from customers and the marketplace, teams distributed around the globe, and an increase in management and regulatory reporting. Using insight from her years of consulting, Carol Dekkers explores these challenges and recommends ways to adapt your practices. Learn how to realistically plan your future projects using benchmarking information such as ISBSG (International Software Benchmarking Standards Group) data together with knowledge about emerging trends. Take back a new appreciation of what constitutes “good enough” project planning today and learn to survive in this brave new world.
In the same way that every athlete needs a coach to help him develop and perfect their skills, software managers and technical leads need mentors to help them improve his leadership and management skills. Working with an effective coach should be part of every manager's personal career development plan. With his proven track record of identifying and developing strong technical managers, Kevin Bodie discusses how to find and recruit personal mentors. He also explains how to become a great mentor yourself. Learn what you can expect from a mentor, what your mentor will expect from you, and practical techniques for mentoring and coaching others. Take away tools to build and keep leading-edge management skills and ways to assess the results of mentoring.
Effective selection and recruiting of coaches and mentors
Determining whether legal and contractual issues apply to your development efforts isn't always simple. There may be some obvious factors: a well-regulated industry, service level agreements, or state or federal agency oversight. However, other factors may not be so obvious. The new Sarbanes-Oxley Act is largely legally untested, subjecting your company to unknown legal issues. You have an eCommerce site that stores credit card information. Your portal collects personal information. You produce proprietary software ... and more. Does Sarbanes-Oxley apply to you? Covering legal, compliance, and audit throughout the development lifecycle, Elle Ringham discusses the right questions to ask and what to do with the answers. She provides guidelines for working with stakeholders, attorneys, and auditors. Take away audit templates, metrics to help you, and sample reports you may need to produce.
In this presentation Michael Harris describes the findings of a quality assurance audit (PPQA) of the offshore outsourcing arm of a major U.S. software development company in late 2005. As the executive in charge of much of the development and as a member of the PPQA audit team, the Michael has a singular perspective on the expectations and the reality of the project. This presentation explores one particular aspect of the audit findings-the manifestations of the different CMMI® maturity levels of the onshore and offshore organizations. Take away suggestions for taking advantage of this mismatch situation instead of suffering from it.
Review a quality assurance audit (PPQA)
Explore the different CMMI® maturity levels of onshore and offshore organizations
Take advantage of mismatched outsourcing situations
Plan-driven software project management is very specific on how to identify and manage risks. When moving to Agile software development practices, what happens to all the risk management activities that project managers used to oversee? Contrary to what many expect, there are Agile risk management practices that reduce risk by providing opportunities for the team to identify, monitor, and control risk events. For each of the traditional risk management areas-identification, analysis, response planning, and monitoring and controlling-you will learn the corresponding Agile approach. In keeping with Agile's strengths, team involvement and collaboration are key inputs into the risk management process. Michele Sliger explains how and when to involve the team in identifying risks, analyzing the opportunities and threats, mitigating as appropriate, and monitoring these risks throughout the lifetime of the Agile project.