The purpose of this book is to provide professionals and academics with a guide to manage the life cycle of placing software applications into production. This book breaks new ground because of this narrow focus, which is more on implementation than on engineering per se. This book provides guidance on how to determine whether to make or buy and allows readers to determine sections that are fitting for their use. Technical readers, that is, those engaged in analysis and design will find chapters that provide the approach and tools on how to create an architecture of system needs. Business users can become more educated in the system development life cycle for both package software and customized applications. Business and IT people will also get a better understanding of project management methods and contract consideration in the relationships they have with vendors and independent consultants. What Is, Is
Over 40 years of developing requirements for systems has taught us that the only successful approach to developing software applications is to accept what exists in the user’s environment, however far from ideal those conditions may be, and work within those limitations. It may be very tempting to use analysis time to try to refocus on how the user does business. Yet efforts to redesign or reengineer, unless specifically requested by the user, will typically be a waste. Although your assessment may be correct and your suggestions potentially useful, being correct is less important in this situation than being wise and understanding the ability of your users to successfully implement and utilize what they need. Analysts tend to ignore this simple wisdom, much to their own distress and that of their clients.
Looking at a typical example of an analysis situation will help to illustrate this point. Let us assume that an enterprise needs a relational database model to gather information about a subject area of the business. There are 200 offices that will need to connect into a nationally provided service. Users disagree on the mission of the applications and cannot determine what reports or query information they want.
Some offices are automated, but they do not have the same software and hardware.
There is little expertise in the user community to determine the data requirements and file layouts (identifying elements in each file). Management has requested that the analyst establish a specification which identifies the requirements of the system as well as the necessary hardware and software.
Faced with so unwieldy a task, many analysts will adopt the following approach in an attempt to impose order on a disorderly situation:
1. Force users to define all requirements. Since they are unable to do so, this insistence will probably result in their guessing or providing incomplete information.
2. Determine the hardware and software configuration, despite having inaccurate or incomplete requirements.
3. Ignore the political environment.
4. Establish a project plan that everyone knows will fail, but push ahead with it anyway. It should be clear that this approach is the wrong one, on a number of different