Software Projects Secrets: Why Projects Fail

Software Projects Secrets: Why Projects Fail

George Stepanek

Language: English

Pages: 173

ISBN: 2:00114849

Format: PDF / Kindle (mobi) / ePub

George Stepanek, "Software Projects Secrets: Why Projects Fail"
English | ISBN: 1430251018 | 2012 | Publisher: Apress | PDF | 184 pages | 3 MB

Software Project Secrets: Why Software Projects Fail offers a new path to success in the software industry. This book reaches out to managers, developers, and customers who use industry-standard methodologies, but whose projects still struggle to succeed.

Author George Stepanek analyzes the project management methodology itself, a critical factor that has thus far been overlooked. He explains why it creates problems for software development projects and begins by describing 12 ways in which software projects are different from other kinds of projects. He also analyzes the project management body of knowledge to discover 10 hidden assumptions that are invalid in the context of software projects.
Table of Contents
Why Software Is Different
Project Management Assumptions
Case Study: The Billing System Project
The New Agile Methodologies
Budgeting Agile Projects
Case Study: The Billing System Revisited

JavaScript Enlightenment

An Introduction to Sustainable Development (Routledge Perspectives on Development)

Testable JavaScript

Programming Windows 8 Apps with HTML, CSS, and JavaScript

Bad Samaritans: The Myth of Free Trade and the Secret History of Capitalism
















these projects. 87 5505CH05.qxd 88 7/22/05 12:06 PM Page 88 Part II . . .And How to Make Them Succeed Interestingly, the Project Manager’s artifacts are organized quite differently from those defined by the PMBOK (there’s no Work Breakdown Schedule, for example), so a manager who wishes to use both RUP and the PMBOK faces a dilemma regarding which methodology to give priority to. Activities and Workflows The link between the artifact and the role is the activity. A role creates or

unit tests ᭿ An acceptance test plan ᭿ A breakdown of the work, with estimates ᭿ An iteration plan The scoping study should be organized and funded as a separate project in itself, not as part of the main project—although it would be equivalent to the RUP Elaboration phase for that project. It provides the information needed to effectively plan the main project, which is why it must finish before the project starts. You can evaluate the project with much better information, but you must be

also a few outstanding bugs that Emily found, but most of them are quite minor. The formatting on some of the screens and reports can get stuffed up if the data items are too long, but that should only take a few hours to fix. Apart from that, the software passes all of our unit tests, and all of Emily’s acceptance tests.” “It sounds like both the software and the project are in good shape. I think we can use up some of that contingency time. We had 36 units of could-do features that were traded

fulfill its requirements. It shows how the constituent components make up the software, and how it connects to external systems such as a database or another application. artifact The product of an activity during software development. Examples of artifacts include a project plan, an architecture document, a set of unit tests, an acceptance test plan, some components, an entire application, a user manual, and so on. best practice A process or technique that has a proven record of success in

register categories, 46–47 as part of risk management, 46–47 management, 48 mitigating risks with agility, 91–93 risk avoidance as part of, 48 risk mitigation as part of, 48 risk transference as part of, 47 in software development, 45–48 management, 48 for the billing system project, 53 typical for software development projects, 46 risk transference, as part of risk management, 47 risks mitigating in Extreme Programming and Crystal methodologies, 91–93 mitigating with agility, 91–93 road building

Download sample