After decades of writing about the field of analysis and design, I write this book to focus on the evolution of software in the world. We have seen over the past 40 years, the continual expansion of the library of software applications that are used in common workplace as well as in the personal lives of people throughout the world. Indeed, software applications continue to change the world and as a result the challenge of managing the advent of huge application libraries has become of paramount importance. In addition, the advent of social networking has also had a salient impact on the uses and effects of applications over the Internet and the expansion of open source has now created an environment of applications that can be used on demand and across multiple platforms.
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