Software Management Tutorial / Edition 4

Hardcover (Print)
Used and New from Other Sellers
Used and New from Other Sellers
from $1.99
Usually ships in 1-2 business days
(Save 97%)
Other sellers (Hardcover)
  • All (9) from $1.99   
  • New (1) from $155.00   
  • Used (8) from $1.99   
Close
Sort by
Page 1 of 1
Showing All
Note: Marketplace items are not eligible for any BN.com coupons and promotions
$155.00
Seller since 2014

Feedback rating:

(177)

Condition:

New — never opened or used in original packaging.

Like New — packaging may have been opened. A "Like New" item is suitable to give as a gift.

Very Good — may have minor signs of wear on packaging but item works perfectly and has no damage.

Good — item is in good condition but packaging may have signs of shelf wear/aging or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Acceptable — item is in working order but may show signs of wear such as scratches or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Used — An item that has been opened and may show signs of wear. All specific defects should be noted in the Comments section associated with each item.

Refurbished — A used item that has been renewed or updated and verified to be in proper working condition. Not necessarily completed by the original manufacturer.

New
Brand new.

Ships from: acton, MA

Usually ships in 1-2 business days

  • Standard, 48 States
  • Standard (AK, HI)
Page 1 of 1
Showing All
Close
Sort by

Overview

Software Management, Sixth Edition provides software executives and corporate officers with the knowledge they need to develop their software engineering management strategies for the future. It also gives the software project manager insight into the tools and techniques that they can use to improve their ability to deliver high quality software products on time and within budget obligations. The book also provides sufficient instructional material to serve as a text for a course on software management.
Read More Show Less

Editorial Reviews

Booknews
A tutorial combining original materials with a collection of reprints to provide both novice and experienced managers with the information necessary to comprehend and use the basic theories, concepts, techniques, and tools of software management. It also includes coverage of process assessment, metrics, and risk management topics, and contains an annotated bibliography and a glossary. This edition (third, 1986) is totally revamped in both organization and content. It includes several new sections, more current papers, and case studies woven throughout the text. No index. Annotation c. Book News, Inc., Portland, OR (booknews.com)
Read More Show Less

Product Details

  • ISBN-13: 9780818633423
  • Publisher: IEEE Computer Society Press
  • Publication date: 8/28/1993
  • Series: IEEE Computer Society Press Tutorial
  • Edition description: Older Edition
  • Edition number: 4
  • Pages: 664

Meet the Author

Donald J. Reifer has over 30 years of progressive management experience in government and industry in a number of responsible positions. Entrepreneur who built a highly successful consulting firm, led major projects, participated in project recovery teams and developed improvement strategies for a number of Fortune 500 clients.
Read More Show Less

Read an Excerpt

Software Management


By Donald J. Reifer

John Wiley & Sons

ISBN: 0-7695-1100-7


Chapter One

Introduction

Under any social order from now to Utopia a management is indispensable and all enduring ... the question is not "Will there be a management elite?" but "What sort of elite will it be?" -Sidney Webb

Overview

The four papers selected for this introductory chapter provide insights into the concerns and challenges associated with software management and the framework composed to study ways to deal with them. Although each paper makes a unique point, most were selected because they searched for the root causes to what many of us in the industry have called "the software crisis." All too often, managers tend to treat the symptoms and not the root causes of their problems. They then use "gut feel" instead of "hard" data to develop a "quick fix" to the dilemma. For example, a manager might try to tie task progress to an impossible schedule when his group is falling behind instead of trying to convince the boss that rescheduling based on more realistic goals is a better option. The manager may not realize that rescheduling doesn't mean the end date has to change. In addition to permitting workers to dedicate more time and effort to the tasks that are causing the delays, rescheduling will allow them to refocus their resources and take advantage of opportunities to perform other tasks that are not on the critical path in parallel.

The papers included in this chapter were selected to provide you with help in figuring out the root causes of your problems. All too often, we treat the symptom because we don't know or can't figure out what the real root cause of the problem is. In the rescheduling example above, is progress behind because the people aren't productive enough, the task is tougher to perform than expected, or the original schedule was overly optimistic? These are difficult questions. To develop answers, I have selected papers that establish frameworks to help you understand how different software process, product, and people considerations relate to each other and the many life cycle management options that are available for use today. These frameworks are important because they establish a foundation that we will build on and reference in later chapters in this tutorial.

Article Summaries

Software Management's Seven Deadly Sins, Donald J. Reifer, pp. 5-8

This is a reprint of an editorial I wrote for IEEE Software magazine about my reflections on the state of software and software management worldwide. The paper summarizes the results of a straw poll of experts from 20 organizations who identified what they believed were the major problems when it came to managing software. What is surprising about the results is that they reflect problems that have been haunting software managers for the past 20 years. The seven sins include volatile requirements, poor planning, unrealistic schedules and budgets, inadequate controls, undercapitalization, the "we're different" syndrome, and lack of focus on quality. Read on if you are interested in reflections on what we've learned during the past two decades.

Principles of Software Engineering Project Management, Donald J. Reifer, pp. 9-15

I wrote this article to serve as an introduction to this tutorial The article reinforces the message that software can be managed using classical project management approaches. It ties chapters together and provides you with a road map through this tutorial. The paper has been rewritten for this volume to reflect the state of the practice of software management and the current content of this volume. The paper's findings, conclusions, and recommendations are presented as principles that you can use to guide your management actions. These principles have not changed much during the past decade. They provide you with basic truths or rules by which to manage software.

The "3P's" of Software Management, Donald J. Reifer, pp. 17-23

This paper communicates principles devised to improve how we address what I call the "3P's" of software management (i.e., the processes we use, the products we generate, and the people who perform the work on our software projects). The paper has been rewritten to show more clearly how these three important factors are related to one another and the methods, tools, and techniques that we use for software project management. My hypothesis in the paper if that you can increase your chances of success on a software project by reducing the conflicts that arise between the "3P's." Such conflicts arise as the factors take on different levels of importance as a project unfolds.

Critical Success Factor in Software Projects, John S. Reel, pp. 25-30

This excellent article looks at the things you can do on a software project to increase its chances of success. It suggests that you start off on the right foot by setting realistic objectives and expectations for those working on the project. Then it recommends that you focus on building the team by carefully selecting the members and furnishing them with what they need to get the job done. To maintain your momentum, the paper recommends that you focus on tracking progress, keeping attrition low, and gathering the "hard" data required to make smart decisions. The paper concludes by suggesting that you put a postmortem process in place that allows you to learn from your mistakes.

Key Terms

For those worried about terminology, I have include an updated and expanded glossary at the end of this tutorial volume. To communicate the meanings of the words, I have sometimes taken liberties with standard definitions to make them more understandable. Common acronyms used in this chapter follow right after the definitions.

Eight key terms, which are defined as follows, are important to understanding the articles provided in this introduction:

1. Attrition: A gradual, natural reduction in the workforce caused by various means like retirement.

2. Case study: An example employed to communicate lessons learned from trial use of a concept or idea.

3. Critical success factors: Those characteristics, conditions, or variables that have a direct influence on your customer's satisfaction with the products and services that you offer. 4. Lessons learned: The knowledge or experience gained by actually completing the project,

5. Motivation: In management, the act of influencing the behavior of others through the combined use of incentives and rewards.

6. Practice: In management, a preferred course of action for getting the job done.

7. Resources: In management, the time, staff, capital, and money made available to a project to perform a service or build a project.

8. Tracking: In management, the process of identifying cost and schedule variances by comparing actual expenditures to projects.

Acronyms

The following acronyms are used within the articles within this chapter:

3P's Process, product, and people

CMM Capability Maturity Model

GUI Graphical user interface

IEEE Institute of Electrical and Electronics Engineers

IS Information systems

PC Personal computer

SEI Software Engineering Institute

For Your Bookshelf

Although many books and articles on management theory are available, few of them apply this theory within the context of software projects. Few of these provide software project managers with help in identifying issues, bounding solutions, and resolving their day-to-day problems. The texts that I have listed in the annotated bibliography that appears at the back of this tutorial volume bridge the gap and provide practical guidance aimed at helping get the software management job done.

Most of the books in this list are relatively new. I have deliberately tried to make sure that they cover the latest concepts. I have eliminated most of the more technical texts and referred readers instead to more management-oriented books like McConnell's Software Project Survival Guide and my new book Making the Software Business Case: Improvement by the Numbers. I have also kept several classics on the list of recommended readings when they are easy to read and have something important to say. For example, I believe that everyone in the field should read the Mythical Man-Month by Fred Brooks. His messages are as relevant today as they were when he first published the book in 1975. They should also ponder Tom DeMarco's thoughts about measurement and management in his 1982 text Controlling Software Projects.

In addition, the Project Management Body of Knowledge (PMBOK(tm)) prepared by the Project Management Institute provides you with an excellent framework for putting the lessons learned that are discussed into action on your project. I highly recommend that you become familiar with its content.

I will point out books you should consider for your bookshelf in my introduction to each chapter of this volume. I will also provide you with pointers to additional information that is available to help you in this paragraph.

Finally, I will put updates to this volume and errata on my Web site (go to reifer.com). Use of the site will allow me to keep you posted on developments in the software management field.

Software Management's Seven Deadly Sins

Donald J. Reifer

During the past month, I have participated in an online discussion to look at the state of software and software management worldwide. What a revelation! Apparently, at least for the past several years, I have been living a sheltered existence.

That's because most of my consulting clients have had their acts together when it came to software management. These software organizations run like businesses, delivering what they promise-on schedule and within budget. Like well-lubricated machines, they crank out products for their customers-in the aerospace, process control, A medical, petrochemical, and telecommunications industries-that work the first time around. These firms have problems, as you might expect, but not overwhelming ones. Most track progress, use metrics, and employ risk management techniques to solve their problems early.

Others in the discussion group contended that I haven't been living in the real world. They argued that software organizations still have a tainted reputation because most software groups fail to deliver what they promise when they promise it. In many firms, senior managers still view software with disdain. To them, it represents the tall pole in the tent: with hardware now typically purchased off the shelf, software consumes most of their engineering resources and represents most of the risk their firms face. As evidence, my interlocutors pointed to statistics recently published by the Software Engineering Institute (SEI), which indicate that most firms recently rated using the Software Capability Maturity Model are still at Level 1. Group members also pointed to the horror stories appearing far too often in the professional literature, documenting what many call death-march projects and software mismanagement.

I decided to poll my industry friends to determine who was right. I drafted questions and conducted fact-finding using email. In all, senior managers from 20 organizations responded to my questions. To my surprise, most of them indicated that we still have major problems when it comes to managing software (see Table 1). Even more surprisingly, this table could have been built 20 years ago. Have we made no progress?

While these findings are not statistically significant, they are revealing. Most of these senior managers view software as a drain on their organizations rather than a contributor. Many think software people are unmanageable prima donnas. Many perceive software organizations as unable to deliver what they promise when they promise it. Interestingly enough, when I called several of these managers and asked them to characterize their firms' software groups, three themes echoed through their answers: software groups never seem to have the time to do the job right, their cost and schedule expectations are unrealistic, and I'm scared of them (because these managers do not understand software).

As one of the field's old-timers, I remember how things were the 1970s and early 1980s. Then, as companies increasingly bought their hardware off the shelf, they discovered that their products were becoming software-intense. Observers likened software development to hardware engineering, and the "software crisis" was on everyone's lips. Of course, the public did not have a clue about software. The PC was new and general use of the Internet was far in the future. To cope with this so-called software crisis, leading firms pursued software initiatives. Most embraced the following three-pronged attack:

Standardize the process.

Standardize the product.

Professionalize the workforce.

The leaders among them also educated their senior members to set expectations. In the late 1980s, the SEI software maturity model came out. This model formed the framework that enabled many firms to adopt the practices, methods, and tools needed to pursue process improvement. In the mid-1990s, architecture technology became the rage. These same firms then could use their processes to develop standard products using product-line management techniques. Because the technology used to develop software continued to change throughout this period, focus shifted to developing the workforce's skills. However, entire new industries emerged and software development moved away from the world of the large monoliths to the Web.

As Table 1 illustrates, some of us are apparently reliving this history. If so, perhaps we can reorient the solutions that worked in the past to help now. Let's turn our attention to what I call the seven sins of software management and see how solutions that worked in the past might again be our salvation.

Sin 1: Volatile requirements

In the old days, requirements were where the action was. The software industry developed better specification techniques to reduce volatility and get the user involved in the process early. We adopted object-oriented techniques to provide better mapping from problem to solution domains. We learned that we couldn't stabilize the software architecture and design if we let our customers alter requirements at will.

Today's quick-to-market projects seem to be teaching us this lesson anew. Although managers of such projects might use enlightened techniques such as prototyping and modern paradigms such as Mbase and the Rational Unified Process, they succeed only marginally when their organizations let requirements change whenever marketing staffs or customers and users suggest new features and functions. Clearly, better requirements-management processes are fundamental to making improvements. Sally Lee

Sin 2: Poor planning

Years ago, project teams would forsake requirements development and planning because management wanted them to get on with the coding. To cope with this foolishness, we likened software to hardware to illustrate the need for improvement. Firms developed planning templates only after they developed or bought into a life-cycle methodology. Then they brought in classical project-planning tools and techniques such as work breakdown structures and milestone schedules that worked for other disciplines. The software development community learned that we had to plan our future work in detail so we could control it and report its status. We invented terms such as inch pebbles to describe the depths to which our plans had to go so management would understand what we wanted.

Today, many firms have placed increased attention on planning, because they are trying to shorten the time-to-market interval by scheduling tasks in parallel using iterative and spiral techniques instead of sequential development approaches. They do so because there isn't enough time to plan all the options. To cope with such contingencies, we have learned that we can do planning in a just-in-time manner. We have also learned that plans should be living documents, iteration and evolving over time.

(Continues...)



Excerpted from Software Management by Donald J. Reifer Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

Read More Show Less

Table of Contents

Software management's seven deadly sins 5
Principles of software engineering project management 9
The "3 P's" of software management 15
Why big software projects fail : the 12 key questions 21
Critical success factor in software projects 27
A spiral model of software development and enhancement 37
Bridging agile and traditional methods 49
Coping with the new paradigms 55
Successful process implementation 77
The definitive paper : quantifying the benefits of software process improvement 87
Process improvement for small organizations 91
The clash of two cultures : project versus process management 99
The mythical man-month after 20 years 115
Traditional software management approaches 119
In-house software development : what project management practices lead to success? 129
The nine deadly sins of project planning 137
21 project management success tips 145
Requirements management : the search for Nirvana 153
Requirements engineering as a success factor in software projects 157
The secrets of planning success 167
The slacker's guide to project tracking 175
Software project estimation : an overview 189
Software engineering economics 203
Web development : estimating quick-to-market software 227
Software size estimation of object-oriented systems 235
Staffing and organization in the engineering of systems 251
The core competence of the corporation 259
Survival patterns in fast-moving software organizations 273
Fear of trying : the plight of rookie project managers 281
Coaching the rookie manager 285
Training developers in critical skills 289
Ten lessons learned from implementing integrated product teams 295
The softer side of project management 299
The human side of management 305
Motivating and keeping software developers 311
Successful software management : 14 lessons learned 315
A tale of three developers 319
Controlling software projects 327
Earned value project management 337
Software configuration management : a discipline with added value 343
Managing software quality with defects 349
Why bad things happen to good projects 353
Understanding risk management 361
Software risk management : principles and practices 365
Large-scale project management is risk management 375
A project risk metric 383
Catastrophe disentanglement : getting software projects back on track 387
Metrics and management : a primer 397
Back to the basics : measurement and metrics 403
Implementing effective software metrics programs 407
Software defect reduction top 10 list 419
Metrics for small projects : experiences at the SED 423
Software acquisition management 437
Managing subcontracts 451
Software licensing : a missed opportunity 463
Distributed development : insights, challenges, and solutions 475
The evolution of distribution project management 481
Managing product lines, architecture, and reuse 493
Improving the security of networked systems 499
Managing at light speed 505
Strategic information technology management : managing organizational, political, and technological forces 509
Information resources management : new era, new rules 519
Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)