![Son
établissement
sur l'Adige.
Ce qu'il y avait
de génie dans
cette résolution.
Naples. Il n'y songe même pas. C'est aux Allemands qu'il faut
disputer l'Italie, dit-il au Directoire, c'est contre eux qu'il faut prendre
position, et qui va au midi de l'Italie, trouvera au retour Fornoue,
comme Charles VIII, ou la Trebbia, comme Macdonald[32]. Il se
décide donc à rester au nord, et avec le même génie aperçoit que le
Pô a un cours trop long pour être facilement défendu, que l'Isonzo
trop avancé est toujours exposé à être tourné par le Tyrol, que
l'Adige seul peut être victorieusement défendu, parce qu'à peine
sorti des Alpes à Vérone ce cours d'eau tombe dans les marécages
à Legnago, et que placé en deçà du Tyrol il ne peut pas être tourné.
Le jeune Bonaparte s'établit alors sur l'Adige, en
raisonnant comme il suit: Si les Autrichiens veulent
forcer l'Adige par les montagnes, ils passeront
nécessairement par le plateau de Rivoli; s'ils
veulent le forcer par la plaine, ils se présenteront
ou devant Vérone, ou vers les marais, dans les
environs de Legnago. Dès lors il faut placer le gros
de ses troupes au centre, c'est-à-dire à Vérone,
laisser deux détachements de garde, l'un à Rivoli, l'autre vers
Legnago, les renforcer alternativement l'un ou l'autre suivant la
direction que prendra l'ennemi, et rester imperturbablement dans
cette position, en faisant du siége de Mantoue une sorte de passe-
temps entre les diverses apparitions des Autrichiens. Grâce à cette
profondeur de jugement, avec trente-six mille hommes, à peine
augmentés d'une quinzaine de mille pendant le cours de la guerre,
le jeune Bonaparte tient tête à toutes les armées autrichiennes, et en
dix-huit mois livrant douze batailles, plus de soixante combats,
faisant plus de cent mille prisonniers, accable l'Autriche et lui
arrache l'abandon définitif de la ligne du Rhin à la France, plus la
paix générale.
Certes, on peut parcourir les pages de l'histoire tout entière, et on
n'y verra rien de pareil. La conception générale et l'art des combats,
tout s'y trouve à un degré de perfection qui ne s'est jamais
rencontré. Passer les montagnes à Montenotte en attirant les
Autrichiens sur Gênes par une feinte, maître de Milan, au lieu de
courir à Rome et à Naples, courir à Vérone, comprendre que l'Italie](https://image.slidesharecdn.com/2537-250224012026-1006f4bd/85/Systems-Analysis-and-Design-with-UML-3rd-Edition-Alan-Dennis-53-320.jpg)
Systems Analysis and Design with UML 3rd Edition Alan Dennis
- 1. Visit https://ebookfinal.com to download the full version and explore more ebooks Systems Analysis and Design with UML 3rd Edition Alan Dennis _____ Click the link below to download _____ https://ebookfinal.com/download/systems-analysis-and- design-with-uml-3rd-edition-alan-dennis/ Explore and download more ebooks at ebookfinal.com
- 2. Here are some suggested products you might be interested in. Click the link to download Alternative Energy Systems Design and Analysis with Induction Generators Second Edition Farret https://ebookfinal.com/download/alternative-energy-systems-design-and- analysis-with-induction-generators-second-edition-farret/ Practical Object Oriented Design with UML 2nd Edition Mark Priestley https://ebookfinal.com/download/practical-object-oriented-design-with- uml-2nd-edition-mark-priestley/ Convergent Architecture Building Model Driven J2EE Systems with UML 1st Edition Richard Hubert https://ebookfinal.com/download/convergent-architecture-building- model-driven-j2ee-systems-with-uml-1st-edition-richard-hubert/ Systems Analysis and Design 10th Edition Harry J. Rosenblatt https://ebookfinal.com/download/systems-analysis-and-design-10th- edition-harry-j-rosenblatt/
- 3. Visual Design Fundamentals A Digital Approach 3rd Edition Alan (Alan Hashimoto) Hashimoto https://ebookfinal.com/download/visual-design-fundamentals-a-digital- approach-3rd-edition-alan-alan-hashimoto-hashimoto/ Design and Analysis of Experiments with R Lawson https://ebookfinal.com/download/design-and-analysis-of-experiments- with-r-lawson/ Essentials of Systems Analysis and Design 5th Edition Joseph Valacich https://ebookfinal.com/download/essentials-of-systems-analysis-and- design-5th-edition-joseph-valacich/ Model Based Design for Embedded Systems Computational Analysis Synthesis and Design of Dynamic Systems 1st Edition Gabriela Nicolescu https://ebookfinal.com/download/model-based-design-for-embedded- systems-computational-analysis-synthesis-and-design-of-dynamic- systems-1st-edition-gabriela-nicolescu/ Java Design Objects UML and Process 1st Edition Kirk Knoernschild https://ebookfinal.com/download/java-design-objects-uml-and- process-1st-edition-kirk-knoernschild/
- 5. Systems Analysis and Design with UML 3rd Edition Alan Dennis Digital Instant Download Author(s): Alan Dennis, Barbara Haley Wixom, David Tegarden ISBN(s): 9780470074787, 0470074787 Edition: 3 File Details: PDF, 5.50 MB Year: 2007 Language: english
- 8. Systems Analysis Design UML Version 2.0 An Object-Oriented Approach Third Edition
- 9. This page intentionally left blank
- 10. System Analysis Design UML Version 2.0 An Object-Oriented Approach Third Edition Alan Dennis Indiana University Barbara Haley Wixom University of Virginia David Tegarden Virginia Tech John Wiley & Sons, Inc.
- 11. Vice President & Executive Publisher Don Fowley Executive Editor Beth Golub Associate Editor Jen Devine Marketing Manager Carly DeCandia Design Director Harry Nolan Senior Designer Kevin Murphy Senior Production Editor Patricia McFadden Senior Media Editor Lauren Sapira Production Management Services This book was set in by Laserwords and printed and bound by RRD/Von Hoffmann. The cover was printed by RRD/Von Hoffmann. This book is printed on acid free paper. ∞ Copyright © 2009 John Wiley & Sons, Inc. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or autho- rization through payment of the appropriate per-copy fee to the Copyright Clearance Center, Inc. 222 Rosewood Drive, Danvers, MA 01923, website www.copyright.com. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030-5774, (201)748-6011, fax (201)748-6008, website http://www.wiley.com/go/permissions. To order books or for customer service please, call 1-800-CALL WILEY (225-5945). ISBN-13 9780470074787 Printed in the United States of America 10 9 8 7 6 5 4 3 2 1 Aptara®, Inc. Lang
- 12. Preface xiii Chapter 1 Introduction to Systems Analysis and Design 1 ■ PART ONE PROJECT INITIATION, PROJECT MANAGEMENT, AND REQUIREMENTS DETERMINATION 39 Chapter 2 Project Initiation 41 Chapter 3 Project Management 69 Chapter 4 Requirements Determination 110 ■ PART TWO ANALYSIS MODELING 155 Chapter 5 Functional Modeling 157 Chapter 6 Structural Modeling 207 Chapter 7 Behavioral Modeling 238 ■ PART THREE DESIGN MODELING 269 Chapter 8 Moving on to Design 271 B R I E F C O N T E N T S v
- 13. Chapter 9 Class and Method Design 318 Chapter 10 Data Management Layer Design 361 Chapter 11 Human–Computer Interaction Layer Design 411 Chapter 12 Physical Architecture Layer Design 463 ■ PART FOUR CONSTRUCTION, INSTALLATION, AND OPERATIONS 503 Chapter 13 Construction 505 Chapter 14 Installation and Operations 533 Index 536 vi Brief Contents
- 14. Preface xiii Chapter 1 Introduction to Systems Analysis and Design 1 Introduction 2 The Systems Development Life Cycle 3 Planning 4 Analysis 4 Design 5 Implementation 6 Systems Development Methodologies 6 Structured Design 8 Rapid Application Development (RAD) 10 Agile Development 14 Selecting the Appropriate Development Methodology 15 Object-Oriented Systems Analysis and Design (OOSAD) 17 Use-Case Driven 18 Architecture Centric 18 Iterative and Incremental 18 Benefits of Object-Oriented Systems Analysis and Design 19 The Unified Process 19 Phases 20 Workflows 22 Extensions to the Unified Process 24 The Unified Modeling Language 29 Project Team Roles and Skills 30 Business Analyst 32 Systems Analyst 32 Infrastructure Analyst 32 Change Management Analyst 32 Project Manager 32 Applying the Concepts at CD Selections 33 Summary 33 ■ PART ONE PROJECT INITIATION, PROJECT MANAGEMENT, AND REQUIRE- MENTS DETERMINATION 39 Chapter 2 Project Initiation 41 Introduction 41 Project Identification 43 System Request 44 Feasibility Analysis 44 Technical Feasibility 46 Economic Feasibility 48 Organizational Feasibility 56 Project Selection 58 Applying the Concepts at CD Selections 61 Project Identification and System Request 61 Feasibility Analysis 62 Project Selection 64 Summary 66 Chapter 3 Project Management 69 Introduction 69 Identifying Project Size 70 Function Point Approach 72 Creating and Managing the Workplan 77 C O N T E N T S vii
- 15. Identifying Tasks 78 The Project Workplan 79 Gantt Chart 79 PERT Chart 81 Refining Estimates 82 Scope Management 83 Timeboxing 85 Evolutionary Work Breakdown Structures and Iterative Workplans 86 Staffing the Project 91 Staffing Plan 91 Motivation 94 Handling Conflict 94 Coordinating Project Activities 96 CASE Tools 96 Standards 97 Documentation 98 Managing Risk 98 Applying the Concepts at CD Selections 100 Staffing the Project 104 Coordinating Project Activities 105 Summary 106 Chapter 4 Requirements Determination 110 Introduction 110 Requirements Determination 111 Defining a Requirement 111 Requirements Definition 114 Determining Requirements 115 Creating a Requirements Definition 116 Requirements Analysis Strategies 117 Business Process Automation 117 Business Process Improvement 120 Business Process Reengineering 121 Selecting Appropriate Strategies 122 Requirements-Gathering Techniques 125 Interviews 125 Joint application development (JAD) 132 Questionnaires 136 Document Analysis 138 Observation 138 Other Techniques 140 Selecting the Appropriate Techniques 142 The System Proposal 144 Applying the Concepts at CD Selections 145 Requirements Analysis Strategies 145 Requirements-Gathering Techniques 146 Requirements Definition 146 System Proposal 148 Summary 149 ■ PART TWO ANALYSIS MODELING 155 Chapter 5 Functional Modeling 157 Introduction 158 Business Process Modeling with Activity Diagrams 159 Elements of an Activity Diagram 160 Guidelines for Creating Activity Diagrams 165 Use-Case Descriptions 166 Types of Use Cases 167 Elements of a Use-Case Description 168 Guidelines for Creating Use-Case Descriptions 171 Use-Case Diagrams 173 Actors 173 Association 175 Use Case 176 System Boundary 176 Creating Use-Case Descriptions and Use-Case Diagrams 178 Identifying the Major Use Cases 179 Expanding the Major Use Cases 180 Confirming the Major Use Cases 181 Creating a Use-Case Diagram 181 Refining Project Size and Effort Estimation Using Use-Case Points 182 Applying the Concepts at CD Selections 188 viii Contents
- 16. Business Process Modeling with Activity Diagrams 188 Identifying the Major Use Cases 189 Expanding the Major Use Cases 191 Confirming the Major Use Cases 193 Creating the Use-Case Diagram 198 Refining Project Size and Effort Estimation Using Use-Case Points 198 Summary 201 Chapter 6 Structural Modeling 207 Introduction 207 Structural Models 208 Classes, Attributes, and Operations 209 Relationships 209 CRC Cards 211 Responsibilities and Collaborations 211 Elements of a CRC Card 212 Class Diagrams 213 Elements of a Class Diagram 213 Simplifying Class Diagrams 221 Object Diagrams 221 Creating CRC Cards and Class Diagrams 222 Object Identification 223 Building CRC Cards and Class Diagrams 225 Applying the Concepts at CD Selections 228 Step 1: Create CRC Cards 228 Step 2: Examine Common Object Lists 228 Step 3: Role-Play the CRC Cards 230 Step 4: Create the Class Diagram 231 Step 5: Review the Class Diagram 231 Step 6: Incorporate Patterns 231 Step 7: Review the Model 232 Summary 233 Chapter 7 Behavioral Modeling 238 Introduction 238 Behavioral Models 239 Interaction Diagrams 239 Objects, Operations, and Messages 240 Sequence Diagrams 240 Communication Diagrams 246 Behavioral State Machines 250 States, Events, Transitions, Actions, and Activities 250 Elements of a Behavioral State Machine 251 Building Behavioral State Machines 254 CRUD Analysis 256 Applying the Concepts at CD Selections 257 Sequence Diagrams 257 Communication Diagrams 260 Behavioral State Machines 261 CRUD Analysis 262 Summary 264 ■ PART THREE DESIGN MODELING 269 Chapter 8 Moving on to Design 271 Introduction 272 Verifying and Validating the Analysis Models 273 Verification and Validation through Walkthroughs 273 Functional Model Verification and Validation 275 Structural Model Verification and Validation 276 Behavioral Model Verification and Validation 278 Balancing the Analysis Models 280 Evolving the Analysis Models into Design Models 287 Factoring 290 Partitions and Collaborations 290 Layers 292 Packages and Package Diagrams 294 Identifying Packages and Creating Package Diagrams 297 Contents ix
- 17. Verifying and Validating Package Diagrams 297 Design Strategies 299 Custom Development 299 Packaged Software 300 Outsourcing 302 Selecting a Design Strategy 304 Developing the Actual Design 306 Alternative Matrix 306 Applying the Concepts at CD Selections 308 Packages and Package Diagrams 308 Verifying and Validating the Analysis Models 310 Developing the Actual Design 311 Summary 312 Chapter 9 Class and Method Design 318 Introduction 318 Review of the Basic Characteristics of Object Orientation 320 Classes, Objects, Methods, and Messages 320 Encapsulation and Information Hiding 321 Polymorphism and Dynamic Binding 321 Inheritance 322 Design Criteria 325 Coupling 325 Cohesion 328 Connascence 331 Object Design Activities 332 Adding Specifications 332 Identifying Opportunities for Reuse 333 Restructuring the Design 335 Optimizing the Design 336 Mapping Problem-Domain Classes to Implementation Languages 339 Constraints and Contracts 343 Types of Constraints 343 Elements of a Contract 346 Method Specification 347 General Information 348 Events 349 Message Passing 349 Algorithm Specification 349 Applying the Concepts at CD Selections 351 Summary 354 Chapter 10 Data Management Layer Design 361 Introduction 362 Object-Persistence Formats 362 Sequential and Random Access Files 363 Relational Databases 366 Object-Relational Databases 368 Object-Oriented Databases 368 Selecting an Object-Persistence Format 369 Mapping Problem-Domain Objects to Object-Persistence Formats 372 Mapping Problem-Domain Objects to an OODBMS Format 372 Mapping Problem-Domain Objects to an ORDBMS Format 376 Mapping Problem-Domain Objects to an RDBMS Format 379 Optimizing RDBMS-Based Object Storage 382 Optimizing Storage Efficiency 382 Optimizing Data Access Speed 388 Estimating Data Storage Size 393 Nonfunctional Requirements and Data Management Layer Design 394 Designing Data Access and Manipulation Classes 395 Applying the Concepts at CD Selections 398 Select Object-Persistence Format 398 Map Problem-Domain Objects to Object-Persistence Format 399 Optimize Object Persistence and Estimate Its Size 400 Data Access and Manipulation Class Design 402 Summary 404 x Contents
- 18. Chapter 11 Human–Computer Interaction Layer Design 411 Introduction 412 Principles for User Interface Design 412 Layout 413 Content Awareness 415 Aesthetics 417 User Experience 419 Consistency 419 Minimizing User Effort 420 User Interface Design Process 420 Use Scenario Development 421 Interface Structure Design 423 Interface Standards Design 424 Interface Design Prototyping 426 Interface Evaluation 428 Navigation Design 430 Basic Principles 430 Types of Navigation Controls 431 Messages 432 Navigation Design Documentation 435 Input Design 436 Basic Principles 436 Types of Inputs 439 Input Validation 441 Output Design 443 Basic Principles 443 Types of Outputs 445 Media 445 Nonfunctional Requirements and Human–Computer Interaction Layer Design 447 Applying the Concepts at CD Selections 448 Use Scenario Development 448 Interface Structure Design 448 Interface Standards Design 451 Interface Template Design 451 Interface Design Prototyping 453 Interface Evaluation 454 Navigation Design Documentation 455 Summary 456 Chapter 12 Physical Architecture Layer Design 463 Introduction 463 Elements of the Physical Architecture Layer 464 Architectural Components 464 Server-Based Architectures 465 Client-Based Architectures 466 Client–Server Architectures 466 Client–Server Tiers 468 Distributed Objects Computing 470 Selecting a Physical Architecture 471 Infrastructure Design 473 Deployment Diagram 473 Network Model 475 Nonfunctional Requirements and Physical Architecture Layer Design 480 Operational Requirements 481 Performance Requirements 482 Security Requirements 484 Cultural and Political Requirements 488 Synopsis 490 Hardware and Software Specification 492 Applying the Concepts at CD Selections 494 Summary 496 ■ PART FOUR CONSTRUCTION, INSTALLATION, AND OPERATIONS 503 Chapter 13 Construction 505 Introduction 505 Managing Programming 507 Assigning Programmers 507 Coordinating Activities 508 Managing the Schedule 509 Cultural Issues 510 Contents xi
- 19. Designing Tests 512 Testing and Object Orientation 513 Test Planning 515 Unit Tests 517 Integration Tests 519 System Tests 520 Acceptance Tests 520 Developing Documentation 520 Types of Documentation 521 Designing Documentation Structure 522 Writing Documentation Topics 524 Identifying Navigation Terms 525 Applying the Concepts at CD Selections 526 Managing Programming 526 Testing 526 Developing User Documentation 528 Summary 530 Chapter 14 Installation and Operations 533 Introduction 533 Cultural Issues and Information Technology 535 Conversion 537 Conversion Style 538 Conversion Location 539 Conversion Modules 540 Selecting the Appropriate Conversion Strategy 541 Change Management 543 Understanding Resistance to Change 544 Revising Management Policies 546 Assessing Costs and Benefits 547 Motivating Adoption 549 Enabling Adoption: Training 550 Postimplementation Activities 552 System Support 552 System Maintenance 554 Project Assessment 555 Applying the Concepts at CD Selections 557 Conversion 557 Change Management 558 Postimplementation Activities 558 Summary 558 Index 00 Available on line at www.wiley.com/college/dennis Appendix 1 Appendix 2 Appendix 3 xii Contents
- 20. PURPOSE OF THIS BOOK Systems Analysis and Design (SAD) is an exciting, active field in which analysts continually learn new techniques and approaches to develop systems more effectively and efficiently. However there is a core set of skills that all analysts need to know—no matter what approach or methodology is used. All information systems projects move through the four phases of planning, analysis, design, and implementation; all projects require analysts to gather requirements, model the business needs, and create blueprints for how the system should be built; and all projects require an understanding of organizational behavior con- cepts like change management and team building. Today, the cost of developing modern software is composed primarily of the cost associated with the developers themselves and not the computers. As such, object-oriented approaches to developing information systems hold much promise in controlling these costs. Today, the most exciting change to systems analysis and design is the move to object- oriented techniques, which view a system as a collection of self-contained objects that have both data and processes. This change has been accelerated through the creation of the Uni- fied Modeling Language (UML). UML provides a common vocabulary of object-oriented terms and diagramming techniques that is rich enough to model any systems development project from analysis through implementation. This book captures the dynamic aspects of the field by keeping students focused on doing SAD while presenting the core set of skills that we feel every systems analyst needs to know today and in the future. This book builds on our professional experience as systems analysts and on our experience in teaching SAD in the classroom. This book will be of particular interest to instructors who have students do a major project as part of their course. Each chapter describes one part of the process, provides clear explanations on how to do it, gives a detailed example, and then has exercises for the stu- dents to practice. In this way, students can leave the course with experience that will form a rich foundation for further work as a systems analyst. OUTSTANDING FEATURES A Focus on Doing SAD The goal of this book is to enable students to do SAD—not just read about it, but under- stand the issues so they can actually analyze and design systems. The book introduces each major technique, explains what it is, explains how to do it, presents an example, and pro- vides opportunities for students to practice before they do it for real in a project.After read- ing each chapter, the student will be able to perform that step in the system development life cycle (SDLC) process. P R E F A C E xiii
- 21. Rich Examples of Success and Failure The book includes a running case about a fictitious company called CD Selections. Each chapter shows how the concepts are applied in situations at CD Selections. Unlike running cases in other books, we have tried to focus these examples on planning, managing, and executing the activities described in the chapter, rather than on detailed dialogue between fictious actors. In this way, the running case serves as a template that students can apply to their own work. Each chapter also includes numerous Concepts in Action boxes, many of which were written by Dr. Bruce White from Quinnipiac University, that describe how real companies succeeded—and failed—in performing the activities in the chapter. Real World Focus The skills that students learn in a systems analysis and design course should mirror the work that they ultimately will do in real organizations.We have tried to make this book as “real” as possible by building extensively on our experience as professional systems analysts for organizations such as Arthur Andersen, IBM, the U.S. Department of Defense, and the Australian Army. We have also worked with a diverse industry advisory board of IS profes- sionals and consultants in developing the book and have incorporated their stories, feed- back, and advice throughout. Many students who use this book will eventually use the skills on the job in a business environment, and we believe they will have a competitive edge in understanding what successful practitioners feel is relevant in the real world. Project Approach We have presented the topics in this book in the SDLC order in which an analyst encoun- ters them in a typical project. Although the presentation is necessarily linear (because stu- dents have to learn concepts in the way in which they build on each other), we emphasize the iterative, complex nature of SAD as the book unfolds. The presentation of the material should align well with courses that encourage students to work on projects because it pre- sents topics as students need to apply them. WHAT’S NEW IN THIS EDITION In this edition, we have increased the coverage of and better organized the text around the enhanced Unified Process; provided a greater focus on nonfunctional requirements; provided a greater emphasis on the iterative and incremental development associated with object- oriented analysis and design; added figures and examples, along with additional explanatory text that addresses some of the more difficult concepts to learn; better aligned the CD selec- tions case material; and did some minor reorganization. However, the biggest changes that have been included address the issues surrounding information systems development and the so-called flat world. The global economy has brought up the need for much greater under- standing of cultural issues, regulatory issues, and the need for testing. The third edition covers this type of material throughout the text. Details of the major changes are as follows: 1. To better align the text with a Unified Process–based methodology, all references to the MOOSAD methodology have been removed, the object-oriented systems analysis and design material and the short overview of UML 2.0 have been moved to Chapter 1, and “Basic Characteristics of Object-Oriented Systems” section is now included in an optional appendix. This last change was driven by the desire of instructors to have the flexibility to cover this material at the most appropriate time for the students based on the students’ backgrounds. In some cases, students xiv Preface
- 22. may have had multiple object-oriented programming courses, whereas in other cases, students may not have had any programming courses at all. Either way, the material is not really necessary to understand until the functional modeling or the class and method design material is covered. Finally, we have tied the “Evolu- tionary Work Breakdown Structures and Iterative Workplans” section of the Pro- ject Management chapter to the enhanced Unified Process. This allowed us better to apply the iterative and incremental development characteristics of object- oriented systems development to the project management material. 2. With regards to the requirements determination, we introduced the idea that in today’s world, there are additional nonfunctional requirements, such as Sarbanes-Oxley, COBIT, ISO 9000, and CMM, being added to the set of non- functional requirements that the analyst must address. We also have introduced new requirements-gathering techniques, for example, throwaway prototyping, role-playing CRC cards, and mind/concept mapping. And, we have introduced the system proposal idea as a separate topic instead of only having it embedded in the CD Selections case. Furthermore, in the design chapters (data manage- ment layer design, human–computer interaction layer design, and physical architecture layer design), more emphasis has been placed on the impact of nonfunctional requirements on the design. 3. The material included within the functional, structural, and behavioral modeling chapters has been more tightly coupled. This is especially true with regard to the idea of iterative and incremental development. The text now emphasizes that sys- tems must be incrementally built by iterating over each of the models and over the intersection of the models. For example, the normal flow of events contained within a use-case description is associated with the activities on an activity dia- gram, the operations on a class diagram, the behaviors on the CRC cards, the messages on sequence and communication diagrams, and transitions on behav- ioral state machines. As such, any change to any one of these most likely will force changes in the others. Furthermore, we have promoted the use of CRUD analysis up to a behavioral modeling technique in and of itself instead of having it associated only with the communications diagram. 4. A major new section has been added to the Moving On to Design chapter that addresses the verification and validation of the analysis models. This section goes through great detail on how to verify and validate the analysis models developed during functional, structural, and behavioral modeling. Furthermore, there had been intentional oversights or errors placed in a couple of the earlier models. During this new section, those errors are uncovered and corrected. Furthermore, to enhance the coverage of testing material, we have added use-case testing as an integration-testing approach in the Construction chapter. 5. We have included material that addresses global concerns throughout the text. This includes material with regard to requirements determination, outsourcing, and class and method design. With regard to the construction chapter, a new sec- tion on cultural issues has been included with the managing programmers section. Finally, with the Installation and Operations chapter a new major section has been added to address cultural issues and information technology. This new section is based on the work of Geert Hofstede. 6. Additional figures and explanatory material have been added throughout the text. However, special attention was paid to the material contained in the struc- tural modeling, behavioral modeling, and the class and method design chapters. Preface xv
- 23. 7. The CD Selections case has now been more closely aligned with each chapter. Each chapter simply has a section of the case associated with it. For example, the intro- duction to the case is now associated with Chapter 1. The case has been slightly modified to ensure that the case itself is more cohesive. Furthermore, in some situa- tions, the CD Selections case had introduced new content material. We have moved any new content material into the content of the corresponding chapter. ORGANIZATION OF THIS BOOK This book is organized by the phases of the Systems Development Life Cycle (SDLC). Each chapter has been written to teach students specific tasks that analysts need to accomplish over the course of a project, and the deliverables that will be produced from the tasks. As students complete the book, tasks will be “checked off” and deliverables will be completed. Along the way, students will be reminded of their progress using roadmaps that indicate where their current task fits into the larger context of SAD. Chapter 1 introduces the SDLC, systems development methodologies, Object-oriented systems analysis, the Unified Process, UML 2.0, and describes the roles and skills needed for a project team. Part One contains material that in many ways goes across the phases of the traditional SDLC. Chapter 2 presents project initiation, with a focus on project identification, system request, feasibility analysis, and project selection. In Chapter 3, students learn about project management, with emphasis on the workplan, staffing plan, project charter, and risk assess- ment that are used to help manage and control the project. Chapter 4 introduces students to an assortment of analysis techniques to help with business automation, business improvement, and business process reengineering, a variety of requirements-gathering techniques that are used to determine the functional and nonfunctional requirements of the system, and to a system proposal. Part Two focuses on creating analysis models. Chapter 5 focuses on constructing func- tional models, Chapter 6 addresses producing structural models, and Chapter 7 tackles cre- ating behavioral models. Part Three addresses design modeling.In Chapter 8,students learn how to verify and val- idate the analysis models created during analysis modeling and to evolve the analysis models into design models via the use of factoring, partitions, and layers. The students also learn to create an alternative matrix that can be used to compare custom, packaged, and outsourcing alternatives. Chapter 9 concentrates on designing the individual classes and their respective methods through the use of contracts and method specifications. Chapter 10 presents the issues involved in designing persistence for objects. These issues include the different storage formats that can be used for object persistence, how to map an object-oriented design into the chosen storage format, and how to design a set of data access and manipulation classes that act as a translator between the classes in the application and the object persistence. This chapter also focuses on the nonfunctional requirements that impact the data management layer. Chapter 11 presents the design of the human–computer interaction layer, where stu- dents learn how to design user interfaces using use scenarios, windows navigation diagrams, storyboards,Windows layout diagrams, HTML prototypes, real use cases, interface standards, and user interface templates, to perform user interface evaluations using heuristic evaluation, walkthrough evaluation, interactive evaluation, and formal usability testing, and to address nonfunctional requirements such as user interface layout, content awareness, aesthetics, user experience, and consistency. Chapter 12 focuses on the physical architecture and infra- structure design, which includes deployment diagrams and hardware/software specification. This chapter, like the previous design chapters, covers the impact that nonfunctional require- ments can have on the physical architecture layer. xvi Preface
- 24. Part Four provides material that is related to the construction, installation, and opera- tions of the system. Chapter 13 focuses on system construction, where students learn how to build, test, and document the system. Installation and operations are covered in Chapter 14, where students learn about the conversion plan, change management plan, support plan, and project assessment. Additionally, these chapters address the issues related to developing systems in a flat world, where developers and users are distributed throughout the world. SUPPLEMENTS http://www.wiley.com/college/dennis Instructor’s Resources Web Site ■ PowerPoint slides, which instructors can tailor to their classroom needs and that students can use to guide their reading and studying activities ■ Test Bank, that includes a variety of questions ranging from multiple choice to essay style questions. A computerized version of the Test Bank will also be available. Online Instructor’s Manual The Instructor’s Manual provides resources to support the instructor both inside and out of the classroom: ■ Short experiential exercises that instructors can use to help students experience and understand key topics in each chapter. ■ Short stories have been provided by people working in both corporate and con- sulting environments for instructors to insert into lectures to make concepts more colorful and real ■ Additional minicases for every chapter allow students to perform some of the key concepts that were learned in the chapter. ■ Solutions to end of chapter questions and exercises are provided. Student Website ■ Relevant Web links, including career resources Web site. ■ Web quizzes help students prepare for class tests. Cases in Systems Analysis and Design A separate Case Book on CD-ROM provides a set of more than a dozen cases that can be used to supplement the book and provide exercises for students to practice with. The cases are primarily drawn from the United States and Canada, but also include a number of international cases. We are always looking for new cases, so if you have a case that might be appropriate please contact us directly (or your local Wiley sales representative). Software Tools Three Software Tools can be purchased with the text in special packages: 1. Visible Systems Corporation’s Visible Analyst Student Edition. 2. Microsoft’s Visio. 3. Microsoft’s Project. A 60-day trial edition of Microsoft Project can be purchased with the textbook. Note that Microsoft has changed their policy and no longer offers the 120-day trial previously available. Preface xvii
- 25. Another option now available to education institutions adopting this Wiley textbook is a free 3-year membership to the MSDN Academic Alliance. The MSDN AA is designed to provide the easiest and most inexpensive way for academic departments to make the latest Microsoft software available in labs, classrooms, and on student and instructor PCs. Microsoft Project 2007 software is available through this Wiley and Microsoft publishing partnership, free of charge with the adoption of any qualified Wiley text- book. Each copy of Microsoft Project is the full version of the software, with no time limitations, and can be used indefinitely for educational purposes. For more infor- mation about the MSDN AA program, go to http://msdn.microsoft.com/academic/. Contact your local Wiley sales representative for details, including pricing and ordering information. ACKNOWLEDGMENTS For the third edition, we would like to thank the students of the ACIS 3515: Information Sys- tems Development I and ACIS 3516: Information Systems Development II classes at Virginia Tech for giving many suggestions that drove most of the changes from the second edition to the third edition. Their feedback was invaluable in improving the text and examples. We would like to thank the following reviewers for their helpful and insightful com- ments on the third edition: Evans Adams, Fort Lewis College; Murugan Anandarajan, Drexel University; Rob Anson, Boise State University; Ravi Krovi, University of Akron; Leo Legorreta, California State University Sacramento; Diane Lending, James Madison Univer- sity; Major Fernando Maymi, West Point University; J. Drew Procaccino, Rider University; Bill Watson, Indiana University–Purdue University Indianapolis; and Amy B. Woszczynski, Kennesaw State University. We also thank the following reviewers from the first and second edition: Evans Adams, Fort Lewis College; Noushin Ashrafi, University of Massachusetts, Boston; Dirk Baldwin, University of Wisconsin-Parkside; Qing Cao, University of Missouri–Kansas City; Ahmad Ghafarian, North Georgia College & State University; Daniel V. Goulet, University of Wis- consin–Stevens Point; Harvey Hayashi, Loyalist College of Applied Arts and Technology; Jean-Piere Kuilboer, University of Massachusetts, Boston; Daniel Mittleman, DePaul Univer- sity; Fred Niederman, Saint Louis University; H. Robert Pajkowski, DeVry Institute of Tech- nology, Scarborough, Ontario; June S. Park, University of Iowa; Tom Pettay, DeVry Institute of Technology, Columbus, Ohio; Neil Ramiller, Portland State University; Eliot Rich, Univer- sity at Albany, State University of New York; Carl Scott, University of Houston; Keng Siau, University of Nebraska–Lincoln; Jonathan Trower, Baylor University; Anna Wachholz, Sheri- dan College; Randy S.Weinberg, Carnegie Mellon University; Eli J.Weissman, DeVry Institute of Technology, Long Island City, NY; Heinz Roland Weistroffer, Virginia Commonwealth University; Amy Wilson, DeVry Institute of Technology, Decatur, GA; Vincent C.Yen,Wright State University; MuruganAnandarajon,Drexel University; RonAnson,Boise State University; Noushin Ashrafi, University of Massachusetts Boston; Dirk Baldwin, University of Wisconsin; Robert Barker, University of Louisville; Terry Fox, Baylor University; Donald Golden, Cleve- land State University; Cleotilde Gonzalez, Carnegie Melon University; Scott James, Saginaw Valley State University; Rajiv Kishore, State University of New York–Buffalo; Ravindra Krovi, University of Akron; Fernando Maymi, United States Military Academy at West Point; Fred Niederman, Saint Louis University; Graham Peace, West Virginia University; J. Drew Procac- cino, Rider University; Marcus Rothenberger,University of Wisconsin–Milwaukee; June Verner, Drexel University; Heinz Roland Weistroffer,Virginia Commonwealth University; and Amy Woszczynski, Kennesaw State University. xviii Preface
- 26. 1 Chapter 1 first introduces the systems development life cycle (SDLC), the fundamental four-phase model (planning, analysis, design, and implementation) common to all infor- mation system development projects. Second, it describes the evolution of system develop- ment methodologies. Third, the chapter overviews object-oriented systems analysis and design and describes the Unified Process and its extensions. Finally, the chapter closes with a discussion of the roles and skills necessary within the project team. OBJECTIVES ■ Understand the fundamental systems development life cycle and its four phases. ■ Understand the evolution of systems development methodologies. ■ Be familiar with the Unified Process and its extensions. ■ Be familiar with the different roles on the project team. CHAPTER OUTLINE C H A P T E R 1 Introduction to Systems Analysis and Design Introduction The Systems Development Life Cycle Planning Analysis Design Implementation Systems Development Methodologies Structured Design Rapid Application Development (RAD) Agile Development Selecting the Appropriate Development Methodology Object-Oriented Systems Analysis and Design (OOSAD) Use-Case Driven Architecture Centric Iterative and Incremental Benefits of Object-Oriented Systems Analysis and Design The Unified Process Phases Workflows Extensions to the Unified Process The Unified Modeling Language Project Team Roles and Skills Business Analyst Systems Analyst Infrastructure Analyst Change Management Analyst Project Manager Applying the Concepts at CD Selections Summary
- 27. INTRODUCTION The systems development life cycle (SDLC) is the process of understanding how an infor- mation system (IS) can support business needs by designing a system, building it, and delivering it to users. If you have taken a programming class or have programmed on your own, this probably sounds pretty simple. Unfortunately, it is not. A 1996 survey by the Standish Group found that 42 percent of all corporate IS projects were abandoned before completion. A similar study done in 1996 by the General Accounting Office found 53 per- cent of all U.S. government IS projects were abandoned. Unfortunately, many of the sys- tems that aren’t abandoned are delivered to the users significantly late, cost far more than planned, and have fewer features than originally planned. Most of us would like to think that these problems only occur to “other” people or “other” organizations, but they happen in most companies. Even Microsoft has a history of failures and overdue projects (e.g., Windows 1.0, Windows 95).1 Although we would like to promote this book as a“silver bullet”that will keep you from IS failures, we readily admit that a silver bullet that guarantees IS development success sim- ply does not exist. Instead, this book will provide you with several fundamental concepts and many practical techniques that you can use to improve the probability of success. The key person in the SDLC is the systems analyst, who analyzes the business situation, identifies opportunities for improvements, and designs an information system to imple- ment them. Being a systems analyst is one of the most interesting, exciting, and challeng- ing jobs around. Systems analysts work with a variety of people and learn how they conduct business. Specifically, they work with a team of systems analysts, programmers, and others on a common mission. Systems analysts feel the satisfaction of seeing systems that they designed and developed make a significant business impact, knowing that they contributed unique skills to make that happen. However, the primary objective of a systems analyst is not to create a wonderful sys- tem; instead, it is to create value for the organization, which for most companies means increasing profits (government agencies and not-for-profit organizations measure value differently). Many failed systems have been abandoned because the analysts tried to build a wonderful system without clearly understanding how the system would fit with an orga- nization’s goals, current business processes, and other information systems to provide value. An investment in an information system is like any other investment, such as a new machine tool. The goal is not to acquire the tool, because the tool is simply a means to an end; the goal is to enable the organization to perform work better so it can earn greater profits or serve its constituents more effectively. This book introduces the fundamental skills a systems analyst needs. This pragmatic book discusses best practices in systems development; it does not present a general survey of systems development that presents everything about the topic. By definition, systems ana- lysts do things and challenge the current way that organizations work. To get the most out of this book, you will need actively to apply the ideas and concepts in the examples and in the “Your Turn” exercises that are presented throughout to your own systems development pro- ject. This book guides you through all the steps for delivering a successful information sys- tem. Also, it illustrates how one organization (called CD Selections) applies the steps in one project (developing a Web-based CD sales system). By the time you finish the book, you won’t be an expert analyst, but you will be ready to start building systems for real. 2 Chapter 1 Introduction to Systems Analysis and Design 1 For more information on the problem, see Capers Jones, Patterns of Software System Failure and Success (London: International Thompson Computer Press, 1996); Capers Jones, Assessment and Control of Software Project Risks (Englewood Cliffs, NJ: Yourdon Press, 1994); Julia King, “IS Reins in Runaway Projects,” Computerworld (February 24, 1997).
- 28. This chapter first introduces the basic SDLC that IS projects follow. This life cycle is common to all projects, although the focus and approach to each phase of the life cycle may differ. The next section describes three fundamentally different types of systems development methodologies: structured design, rapid application development, and agile development. The next three sections introduce the fundamental characteristics of object-oriented systems analysis and design, a specific object-oriented systems development methodology (The Unified Process), and a specific object-oriented systems development graphical nota- tion (The Unified Modeling Language). Finally, the chapter discusses one of the most chal- lenging aspects of systems development, the depth and breadth of skills required of systems analysts. Today, most organizations use project teams that contain members with unique, but complementary, skills. The chapter closes with a discussion of the key roles played by members of the systems development team. The Systems Development Life Cycle 3 A real-estate group in the federal government cospon- sored a data warehouse with the IT department. In the for- mal proposal written by IT, costs were estimated at $800,000, the project duration was estimated to be eight months, and the responsibility for funding was defined as the business unit’s. The IT department proceeded with the project before it even knew if the project had been accepted. The project actually lasted two years because require- ments gathering took nine months instead of one and a half, the planned user base grew from 200 to 2,500, and the approval process to buy technology for the project took a year. Three weeks prior to technical delivery, the IT director canceled the project. This failed endeavor cost the organization and taxpayers $2.5 million. Source: Hugh J. Watson et al., “Data Warehousing Failure: Case Studies and Findings,” The Journal of Data Warehousing 4, (no. 1) (1999): 44–54. Questions 1. Why did this system fail? 2. Why would a company spend money and time on a project and then cancel it? 3. What could have been done to prevent this? 1–A An Expensive False Start CONCEPTS IN ACTION THE SYSTEMS DEVELOPMENT LIFE CYCLE In many ways, building an information system is similar to building a house. First, the house (or the information system) starts with a basic idea. Second, this idea is transformed into a simple drawing that is shown to the customer and refined (often through several drawings, each improving on the last) until the customer agrees that the picture depicts what he or she wants. Third, a set of blueprints is designed that presents much more detailed information about the house (e.g., the type of water faucets, where the telephone jacks will be placed). Finally, the house is built following the blueprints, often with some changes directed by the customer as the house is erected. The SDLC has a similar set of four fundamental phases: planning, analysis, design, and implementation. Different projects may emphasize different parts of the SDLC or approach the SDLC phases in different ways, but all projects have elements of these four phases. Each phase is itself composed of a series of steps, which rely upon techniques that produce deliverables (specific documents and files that provide understanding about the project).
- 29. For example, when you apply for admission to a university, all students go through the same phases: information gathering, applying, and accepting. Each of these phases has steps—information gathering includes steps such as searching for schools, requesting information, and reading brochures. Students then use techniques (e.g., Internet search- ing) that can be applied to steps (e.g., requesting information) to create deliverables (e.g., evaluations of different aspects of universities). In many projects, the SDLC phases and steps proceed in a logical path from start to finish. In other projects, the project teams move through the steps consecutively, incre- mentally, iteratively, or in other patterns. In this section, we describe the phases, actions, and some of the techniques that are used to accomplish the steps at a very high level. Not all organizations follow the SDLC in exactly the same way. As we shall shortly see, there are many variations on the overall SDLC. For now, there are two important points to understand about the SDLC. First, you should get a general sense of the phases and steps through which IS projects move and some of the techniques that produce certain deliverables. Second, it is important to under- stand that the SDLC is a process of gradual refinement. The deliverables produced in the analysis phase provide a general idea of the shape of the new system. These deliverables are used as input to the design phase, which then refines them to produce a set of deliverables that describes in much more detailed terms exactly how the system will be built. These deliverables, in turn, are used in the implementation phase to produce the actual system. Each phase refines and elaborates on the work done previously. Planning The planning phase is the fundamental process of understanding why an information system should be built and determining how the project team will go about building it.It has two steps: 1. During project initiation, the system’s business value to the organization is identi- fied: how will it lower costs or increase revenues? Most ideas for new systems come from outside the IS area (from the marketing department, accounting department, etc.) in the form of a system request. A system request presents a brief summary of a business need, and it explains how a system that supports the need will create business value. The IS department works together with the person or department that generated the request (called the project sponsor) to conduct a feasibility analysis. The feasibility analysis examines key aspects of the proposed project: ■ The idea’s technical feasibility (Can we build it?) ■ The economic feasibility (Will it provide business value?) ■ The organizational feasibility (If we build it, will it be used?) The system request and feasibility analysis are presented to an information sys- tems approval committee (sometimes called a steering committee), which decides whether the project should be undertaken. 2. Once the project is approved, it enters project management. During project man- agement, the project manager creates a workplan, staffs the project, and puts tech- niques in place to help the project team control and direct the project through the entire SDLC. The deliverable for project management is a project plan, which describes how the project team will go about developing the system. Analysis The analysis phase answers the questions of who will use the system, what the system will do, and where and when it will be used. During this phase, the project team investigates any current system(s), identifies improvement opportunities, and develops a concept for the new system. 4 Chapter 1 Introduction to Systems Analysis and Design
- 30. This phase has three steps: 1. An analysis strategy is developed to guide the project team’s efforts. Such a strat- egy usually includes an analysis of the current system (called the as-is system) and its problems, and then ways to design a new system (called the to-be system). 2. The next step is requirements gathering (e.g., through interviews or question- naires). The analysis of this information—in conjunction with input from project sponsor and many other people—leads to the development of a concept for a new system. The system concept is then used as a basis to develop a set of business analysis models, which describe how the business will operate if the new system is developed. The set of models typically includes models that represent the data and processes necessary to support the underlying business process. 3. The analyses, system concept, and models are combined into a document called the system proposal, which is presented to the project sponsor and other key deci- sion makers (e.g., members of the approval committee) who decide whether the project should continue to move forward. The system proposal is the initial deliverable that describes what business require- ments the new system should meet. Because it is really the first step in the design of the new system, some experts argue that it is inappropriate to use the term analysis as the name for this phase; some argue a better name would be analysis and initial design. Most organiza- tions continue use to the name analysis for this phase, however, so we use it in this book as well. Just keep in mind that the deliverable from the analysis phase is both an analysis and a high-level initial design for the new system. Design The design phase decides how the system will operate, in terms of the hardware, software, and network infrastructure; the user interface, forms and reports; and the specific programs, data- bases, and files that will be needed. Although most of the strategic decisions about the system were made in the development of the system concept during the analysis phase,the steps in the design phase determine exactly how the system will operate. The design phase has four steps: 1. The design strategy is first developed. It clarifies whether the system will be devel- oped by the company’s own programmers, whether the system will be outsourced to another firm (usually a consulting firm), or whether the company will buy an existing software package. 2. This leads to the development of the basic architecture design for the system, which describes the hardware, software, and network infrastructure to be used. In most cases, the system will add or change the infrastructure that already exists in the organization. The interface design specifies how the users will move through the system (e.g., navigation methods such as menus and on-screen buttons) and the forms and reports that the system will use. 3. The database and file specifications are developed. These define exactly what data will be stored and where they will be stored. 4. The analyst team develops the program design, which defines the programs that need to be written and exactly what each program will do. This collection of deliverables (architecture design, interface design, database and file specifications, and program design) is the system specification that is handed to the pro- gramming team for implementation. At the end of the design phase, the feasibility analysis and project plan are reexamined and revised, and another decision is made by the project sponsor and approval committee about whether to terminate the project or continue. The Systems Development Life Cycle 5
- 31. Implementation The final phase in the SDLC is the implementation phase, during which the system is actu- ally built (or purchased, in the case of a packaged software design). This is the phase that usually gets the most attention, because for most systems it is the longest and most expensive single part of the development process. This phase has three steps: 1. System construction is the first step. The system is built and tested to ensure it per- forms as designed. Because the cost of bugs can be immense, testing is one of the most critical steps in implementation. Most organizations give more time and attention to testing than to writing the programs in the first place. 2. The system is installed. Installation is the process by which the old system is turned off and the new one is turned on. It may include a direct cutover approach (in which the new system immediately replaces the old system), a parallel conversion approach (in which both the old and new systems are operated for a month or two until it is clear that there are no bugs in the new system), or a phased conversion strategy (in which the new system is installed in one part of the organization as an initial trial and then gradually installed in others). One of the most important aspects of conversion is the development of a training plan to teach users how to use the new system and help manage the changes caused by the new system. 3. The analyst team establishes a support plan for the system. This plan usually includes a formal or informal post-implementation review as well as a systematic way for identifying major and minor changes needed for the system. 6 Chapter 1 Introduction to Systems Analysis and Design Consumer electronics is a very competitive business. What might be the success story of the year one year is a forgotten item two years later. Rapid product commoditi- zation makes the consumer electronic marketplace very competitive. Getting the right products to market at the right time with the right components is an ongoing chal- lenge for telecommunications and consumer electronic goods companies. Questions 1. What external data analysis should a consumer electronics company use to determine marketplace needs and its abilities to compete effectively in a marketplace? 2. Staying one step ahead of competitors requires a corporate strategy and the support of information systems. How can information systems and systems analysts contribute to an aggressive corporate strategy? 1–B Keeping Up with Consumer Electronics CONCEPTS IN ACTION SYSTEMS DEVELOPMENT METHODOLOGIES A methodology is a formalized approach to implementing the SDLC (i.e., it is a list of steps and deliverables). There are many different systems development methodologies, and each one is unique, based on the order and focus it places on each SDLC phase. Some method- ologies are formal standards used by government agencies, whereas others have been developed by consulting firms to sell to clients. Many organizations have internal method- ologies that have been honed over the years, and they explain exactly how each phase of the SDLC is to be performed in that company. There are many ways to categorize methodologies. One way is by looking at whether they focus on business processes or the data that support the business. A process-centered
- 32. methodology emphasizes process models as the core of the system concept. In Figure 1-1, for example, process-centered methodologies would focus first on defining the processes (e.g., assemble sandwich ingredients). Data-centered methodologies emphasize data mod- els as the core of the system concept. In Figure 1-1 data-centered methodologies would focus first on defining the contents of the storage areas (e.g., refrigerator) and how the con- tents were organized.2 By contrast, object-oriented methodologies attempt to balance the focus between process and data by incorporating both into one model. In Figure 1-1, these Systems Development Methodologies 7 2 The classic modern process-centered methodology is that by Edward Yourdon, Modern Structured Analysis (Englewood Cliffs, NJ: Yourdon Press, 1989). An example of a data-centered methodology is information engi- neering; see James Martin, Information Engineering, vols. 1–3 (Englewood Cliffs, NJ: Prentice Hall, 1989). A widely accepted standardized non–object-oriented methodology that balances processes and data is IDEF; see FIPS 183, Integration Definition for Function Modeling, Federal Information Processing Standards Publications, U.S. Department of Commerce, 1993. aParent aRefrigerator aCupboard aSandwich aLunch aLunchBag GetJelly GetPeanutButter GetCookies GetBread CreateSandwich GetMilk CreateLunch GetLunchBag PutLunchInBag FIGURE 1-1 A Simple Behavioral Model for Making Lunch
- 33. methodologies would focus first on defining the major elements of the system (e.g., sand- wiches, lunches) and look at the processes and data involved with each element. Another important factor in categorizing methodologies is the sequencing of the SDLC phases and the amount of time and effort devoted to each.3 In the early days of com- puting, programmers did not understand the need for formal and well-planned life cycle methodologies. They tended to move directly from a very simple planning phase right into the construction step of the implementation phase—in other words, from a very fuzzy, not-well-thought-out system request into writing code. This is the same approach that you sometimes use when writing programs for a pro- gramming class. It can work for small programs that require only one programmer, but if the requirements are complex or unclear, you may miss important aspects of the problem and have to start all over again, throwing away part of the program (and the time and effort spent writing it). This approach also makes teamwork difficult because members have lit- tle idea about what needs to be accomplished and how to work together to produce a final product. Structured Design The first category of systems development methodologies is called structured design. These methodologies became dominant in the 1980s, replacing the previous, ad hoc, and undis- ciplined approach. Structured design methodologies adopt a formal step-by-step approach to the SDLC that moves logically from one phase to the next. Numerous process-centered and data-centered methodologies follow the basic approach of the two structured design categories outlined next. Waterfall Development The original structured design methodology (still used today) is waterfall development. With waterfall development–based methodologies, the analysts and users proceed in sequence from one phase to the next (see Figure 1-2). The key deliv- erables for each phase are typically very long (often hundreds of pages in length) and are presented to the project sponsor for approval as the project moves from phase to phase. Once the sponsor approves the work that was conducted for a phase, the phase ends and the next one begins. This methodology is referred to as waterfall development because it moves forward from phase to phase in the same manner as a waterfall. Although it is pos- sible to go backward in the SDLC (e.g., from design back to analysis), it is extremely diffi- cult (imagine yourself as a salmon trying to swim upstream against a waterfall, as shown in Figure 1-2). Structured design also introduced the use of formal modeling or diagramming tech- niques to describe the basic business processes and the data that support them. Traditional structured design uses one set of diagrams to represent the processes and a separate set of diagrams to represent data. Because two sets of diagrams are used, the systems analyst must decide which set to develop first and use as the core of the system—process-model diagrams or data-model diagrams. There is much debate over which should come first, the processes or the data, because both are important to the system. As a result, several dif- ferent structured design methodologies have evolved that follow the basic steps of the waterfall model but use different modeling approaches at different times. Those that attempt to emphasize process-model diagrams as the core of the system are process cen- tered, whereas those that emphasize data-model diagrams as the core of the system con- cept are data centered. 8 Chapter 1 Introduction to Systems Analysis and Design 3 A good reference for comparing systems development methodologies is Steve McConnell, Rapid Development (Redmond, WA: Microsoft Press, 1996).
- 34. The two key advantages of the structured design waterfall approach are that it iden- tifies system requirements long before programming begins and it minimizes changes to the requirements as the project proceeds. The two key disadvantages are that the design must be completely specified before programming begins and that a long time elapses between the completion of the system proposal in the analysis phase and the delivery of the system (usually many months or years). Lengthy deliverables often result in poor com- munication; the result is that important requirements can be overlooked in the volumi- nous documentation. Users are rarely prepared for their introduction to the new system, which occurs long after the initial idea for the system was introduced. If the project team misses important requirements, expensive post-implementation programming may be needed (imagine yourself trying to design a car on paper; how likely would you be to remember interior lights that come on when the doors open or to specify the right num- ber of valves on the engine?). A system may also require significant rework because the business environment has changed from the time that the analysis phase occurred. When changes do occur, it means going back to the initial phases and following the change through each of the subsequent phases in turn. Parallel Development Parallel development methodology attempts to address the prob- lem of long delays between the analysis phase and the delivery of the system. Instead of doing design and implementation in sequence, it performs a general design for the whole system and then divides the project into a series of distinct subprojects that can be designed and implemented in parallel. Once all subprojects are complete, there is a final integration of the separate pieces, and the system is delivered (see Figure 1-3). The primary advantage of this methodology is that it can reduce the schedule time to deliver a system; thus, there is less chance of changes in the business environment causing rework. However, the approach still suffers from problems caused by paper documents. It also adds a new problem: Sometimes the subprojects are not completely independent; design decisions made in one subproject may affect another, and the end of the project may require significant integration efforts. Systems Development Methodologies 9 System Planning Analysis Design Implementation FIGURE 1-2 A Waterfall Development–based Methodology
- 35. Rapid Application Development (RAD) A second category of methodologies includes rapid application development (RAD)–based methodologies. These are a newer class of systems development methodologies that emerged in the 1990s. RAD-based methodologies attempt to address both weaknesses of structured design methodologies by adjusting the SDLC phases to get some part of the system developed quickly and into the hands of the users. In this way, the users can better understand the system and suggest revisions that bring the system closer to what is needed.4 Most RAD-based methodologies recommend that analysts use special techniques and computer tools to speed up the analysis, design, and implementation phases, such as CASE tools, joint application design (JAD) sessions, fourth-generation/visual program- ming languages that simplify and speed up programming (e.g., Visual Basic), and code generators that automatically produce programs from design specifications. The combi- nation of the changed SDLC phases and the use of these tools and techniques improves the speed and quality of systems development. However, there is one possible subtle problem with RAD-based methodologies: managing user expectations. Due to the use of the tools and techniques that can improve the speed and quality of systems develop- ment, user expectations of what is possible may dramatically change. As a user better 10 Chapter 1 Introduction to Systems Analysis and Design System Planning Analysis Design Implementation Design Integration Implementation Design Implementation Design Subproject 2 Subproject 1 Subproject 3 FIGURE 1-3 A Parallel Development–based Methodology 4 One of the best RAD books is Steve McConnell, Rapid Development (Redmond, WA: Microsoft Press, 1996).
- 36. understands the information technology, the systems requirements tend to expand. This was less of a problem when using methodologies that spent a lot of time thoroughly documenting requirements. Process-centered, data-centered, and object-oriented methodologies that follow the basic approaches of the three RAD categories are described in the following sections. Phased Development A phased development–based methodology breaks an overall system into a series of versions, which are developed sequentially. The analysis phase identifies the overall system concept, and the project team, users, and system sponsor then categorize the requirements into a series of versions. The most important and fundamental require- ments are bundled into the first version of the system. The analysis phase then leads into design and implementation—but only with the set of requirements identified for version 1 (see Figure 1-4). Once version 1 is implemented, work begins on version 2. Additional analysis is per- formed based on the previously identified requirements and combined with new ideas and Systems Development Methodologies 11 System version 1 Planning Analysis Analysis Implementation Design Analysis Implementation Design Analysis Implementation Design System version 2 System version 3 FIGURE 1-4 A Phased Development–based Methodology
- 37. issues that arose from the users’ experience with version 1. Version 2 then is designed and implemented, and work immediately begins on the next version. This process continues until the system is complete or is no longer in use. Phased development–based methodologies have the advantage of quickly getting a useful system into the hands of the users. Although the system does not perform all the functions the users need at first, it does begin to provide business value sooner than if the system were delivered after completion, as is the case with the waterfall and parallel methodologies. Likewise, because users begin to work with the system sooner, they are more likely to identify important additional requirements sooner than with structured design situations. The major drawback to phased development is that users begin to work with systems that are intentionally incomplete. It is critical to identify the most important and useful features and include them in the first version and to manage users’ expectations along the way. Prototyping A prototyping-based methodology performs the analysis, design, and imple- mentation phases concurrently, and all three phases are performed repeatedly in a cycle until the system is completed. With these methodologies, the basics of analysis and design are performed, and work immediately begins on a system prototype, a “quick-and-dirty” program that provides a minimal amount of features. The first prototype is usually the first part of the system that is used. This is shown to the users and the project sponsor, who pro- vide comments. These comments are used to reanalyze, redesign, and reimplement a sec- ond prototype, which provides a few more features. This process continues in a cycle until the analysts, users, and sponsor agree that the prototype provides enough functionality to be installed and used in the organization. After the prototype (now called the system) is installed, refinement occurs until it is accepted as the new system (see Figure 1-5). The key advantage of a prototyping-based methodology is that it very quickly provides a system with which the users can interact, even if it is not ready for widespread organiza- tional use at first. Prototyping reassures the users that the project team is working on the system (there are no long delays in which the users see little progress), and prototyping helps to more quickly refine real requirements. Rather than attempting to understand a sys- tem specification on paper, the users can interact with the prototype to better understand what it can and cannot do. The major problem with prototyping is that its fast-paced system releases challenge attempts to conduct careful, methodical analysis. Often the prototype undergoes such sig- nificant changes that many initial design decisions become poor ones. This can cause 12 Chapter 1 Introduction to Systems Analysis and Design System prototype System Planning Analysis Design Implementation Implementation FIGURE 1-5 A Prototyping-based Methodology
- 38. problems in the development of complex systems because fundamental issues and prob- lems are not recognized until well into the development process. Imagine building a car and discovering late in the prototyping process that you have to take the whole engine out to change the oil (because no one thought about the need to change the oil until after it had been driven 10,000 miles). Throwaway Prototyping Throwaway prototyping–based methodologies are similar to prototyping-based methodologies in that they include the development of prototypes; however, throwaway prototypes are done at a different point in the SDLC. These prototypes are used for a very different purpose than those previously discussed, and they have a very different appearance (see Figure 1-6). The throwaway prototyping–based methodologies have a relatively thorough analysis phase that is used to gather information and to develop ideas for the system concept. How- ever, users may not completely understand many of the features they suggest, and there may be challenging technical issues to be solved. Each of these issues is examined by ana- lyzing, designing, and building a design prototype. A design prototype is not a working sys- tem; it is a product that represents a part of the system that needs additional refinement, and it contains only enough detail to enable users to understand the issues under consid- eration. For example, suppose users are not completely clear on how an order entry system should work. The analyst team might build a series of HTML pages viewed using a Web browser to help the users visualize such a system. In this case, a series of mock-up screens appear to be a system, but they really do nothing. Or, suppose that the project team needs to develop a sophisticated graphics program in Java. The team could write a portion of the program with pretend data to ensure that they could do a full-blown program successfully. A system developed using this type of methodology probably relies on several design prototypes during the analysis and design phases. Each of the prototypes is used to mini- mize the risk associated with the system by confirming that important issues are under- stood before the real system is built. Once the issues are resolved, the project moves into design and implementation. At this point, the design prototypes are thrown away, which is an important difference between these methodologies and prototyping methodologies, in which the prototypes evolve into the final system. Systems Development Methodologies 13 Design prototype System Analysis Analysis Design Implementation Planning Implementation Design FIGURE 1-6 A Throwaway Prototyping–based Methodology
- 39. Throwaway prototyping–based methodologies balance the benefits of well-thought- out analysis and design phases with the advantages of using prototypes to refine key issues before a system is built. It may take longer to deliver the final system as compared to prototyping-based methodologies (because the prototypes do not become the final system), but this type of methodology usually produces more stable and reliable systems. Agile Development5 A third category of systems development methodologies is still emerging today: agile devel- opment. These programming-centric methodologies have few rules and practices, all of which are fairly easy to follow. They focus on streamlining the SDLC by eliminating much of the modeling and documentation overhead and the time spent on those tasks. Instead, projects emphasize simple, iterative application development. Examples of agile develop- ment methodologies include extreme programming, Scrum, and the Dynamic Systems Development Method (DSDM). The agile development approach, as described next, typi- cally is used in conjunction with object-oriented methodologies. Extreme Programming6 Extreme programming (XP) is founded on four core values: communication, simplicity, feedback, and courage. These four values provide a founda- tion that XP developers use to create any system. First, the developers must provide rapid feedback to the end users on a continuous basis. Second, XP requires developers to follow the KISS principle.7 Third, developers must make incremental changes to grow the sys- tem, and they must not only accept change, they must embrace change. Fourth, developers must have a quality-first mentality. XP also supports team members in developing their own skills. Three of the key principles that XP uses to create successful systems are continuous testing, simple coding performed by pairs of developers, and close interactions with end users to build systems very quickly. After a superficial planning process, projects perform analysis, design, and implementation phases iteratively (see Figure 1-7). 14 Chapter 1 Introduction to Systems Analysis and Design 5 Two good sources of information on agile development and object-oriented systems is S. W. Ambler, Agile Modeling: Effective Practices for Extreme Programming and The Unified Process (New York: Wiley, 2002), and R. C. Martin, Agile Software Development: Principles, Patterns, and Practices (Upper Saddle River, NJ: Prentice Hall, 2003). 6 For more information, see K. Beck, eXtreme Programming Explained: Embrace Change (Reading, MA: Addison- Wesley, 2000), M. Lippert, S. Roock, and H. Wolf, eXtreme Programming in Action: Practical Experiences from Real World Projects (New York: Wiley, 2002), or www.extremeprogramming.com. 7 Keep It Simple, Stupid. Implementation Design Analysis System Planning FIGURE 1-7 The Extreme Programming Methodology
- 40. Testing and efficient coding practices are core to XP. In fact, code is tested each day and is placed into an integrative testing environment. If bugs exist, the code is backed out until it is completely free of errors. XP relies heavily on refactoring, which is a disciplined way to restructure code to keep it simple. An XP project begins with user stories that describe what the system needs to do. Then, programmers code in small, simple modules and test to meet those needs. Users are required to be available to clear up questions and issues as they arise. Standards are very important to minimize confusion, so XP teams use a common set of names, descriptions, and coding practices. XP projects deliver results sooner than even the RAD approaches, and they rarely get bogged down in gathering requirements for the system. For small projects with highly motivated, cohesive, stable, and experienced teams, XP should work just fine. However, if the project is not small or the teams aren’t jelled,8 then the success of an XP development effort is doubtful. This tends to throw the whole idea of bringing outside contractors into an existing team environment using XP into doubt.9 The chance of outsiders “jelling” with insiders may simply be too optimistic. XP requires a great deal of discipline; otherwise projects will become unfocused and chaotic. Furthermore, it is recommended only for small groups of developers—no more than ten developers, and it is not advised for large mission-critical applications. Due to the lack of analysis and design documentation, there is only code documentation associated with XP, so maintaining large systems built with XP may be impossible. And because mission-critical business informa- tion systems tend to exist for a long time, the utility of XP as a business information system development methodology is in doubt. Finally, the methodology needs a lot of on-site user input, something to which many business units cannot commit.10 Selecting the Appropriate Development Methodology Because there are many methodologies, the first challenge faced by analysts is to select which methodology to use. Choosing a methodology is not simple, because no one methodology is always best. (If it were, we’d simply use it everywhere!) Many organizations have standards and policies to guide the choice of methodology. You will find that organi- zations range from having one “approved” methodology to having several methodology options to having no formal policies at all. Figure 1-8 summarizes some important methodology selection criteria. One impor- tant item not discussed in this figure is the degree of experience of the analyst team. Many of the RAD-based methodologies require the use of “new” tools and techniques that have a significant learning curve. Often these tools and techniques increase the complexity of the project and require extra time for learning. However, once they are adopted and the team becomes experienced, the tools and techniques can significantly increase the speed in which the methodology can deliver a final system. Clarity of User Requirements When the user requirements for a system are unclear, it is difficult to understand them by talking about them and explaining them with written reports. Systems Development Methodologies 15 8 A jelled team is one that has low turnover, a strong sense of identity, a sense of eliteness, a feeling that they jointly own the product being developed, and enjoyment in working together. For more information regarding jelled teams, see T. DeMarco and T. Lister. Peopleware: Productive Projects and Teams (New York: Dorset/House, 1987). 9 Considering the tendency for offshore outsourcing, this is a major obstacle for XP to overcome. For more infor- mation on offshore outsourcing, see P. Thibodeau, “ITAA Panel Debates Outsourcing Pros, Cons,” Computer- world Morning Update (September 25, 2003), and S. W. Ambler,“Chicken Little Was Right,”Software Development (October 2003). 10 Many of the observations described on the utility of XP as a development approach were based on conversa- tions with Brian Henderson-Sellers.
- 41. Users normally need to interact with technology to really understand what a new system can do and how to best apply it to their needs. Prototyping- and throwaway prototyping–based RAD methodologies are usually more appropriate when user requirements are unclear because they provide prototypes for users to interact with early in the SDLC. Familiarity with Technology When the system will use new technology with which the analysts and programmers are not familiar (e.g., the first Web development project with Java), early application of the new technology in the methodology will improve the chance of success. If the system is designed without some familiarity with the base technology, risks increase because the tools might not be capable of doing what is needed. Throwaway prototyping–based methodologies are particularly appropriate if users lack familiarity with technology because they explicitly encourage the developers to develop design prototypes for areas with high risks. Phased development–based methodologies are good as well, because they create opportunities to investigate the technology in some depth before the design is complete. Although you might think prototyping-based methodologies are also appropriate, they are much less so because the early prototypes that are built usually only scratch the surface of the new technology. It is generally only after several prototypes and several months that the developers discover weaknesses or problems in the new technology. System Complexity Complex systems require careful and detailed analysis and design. Throwaway prototyping–based methodologies are particularly well suited to such detailed analysis and design, as opposed to prototyping-based methodologies, which are not. The traditional structured design–based methodologies can handle complex systems, but with- out the ability to get the system or prototypes into the users’ hands early on, some key issues may be overlooked. Although phased development–based methodologies enable users to interact with the system early in the process, we have observed that project teams who follow these tend to devote less attention to the analysis of the complete problem domain than they might using other methodologies. SystemReliability System reliability is usually an important factor in system development— after all, who wants an unreliable system? However, reliability is just one factor among several. For some applications reliability is truly critical (e.g., medical equipment, missile control systems), whereas for other applications (e.g., games, Internet video) it is merely important. Throwaway prototyping methodologies are the most appropriate when system 16 Chapter 1 Introduction to Systems Analysis and Design With Unclear User Requirements Poor Poor Good Excellent Excellent Excellent With Unfamiliar Technology Poor Poor Good Poor Excellent Poor That Are Complex Good Good Good Poor Excellent Poor That Are Reliable Good Good Good Poor Excellent Good With a Short Time Schedule Poor Good Excellent Excellent Good Excellent With Schedule Visibility Poor Poor Excellent Excellent Good Good Agile Structured Methodologies RAD Methodologies Methodologies Ability to Develop Throwaway Systems Waterfall Parallel Phased Prototyping Prototyping XP FIGURE 1-8 Criteria for Selecting a Methodology
- 42. reliability is a high priority, because it combines detailed analysis and design phases with the ability for the project team to test many different approaches through design proto- types before completing the design. Prototyping methodologies are generally not a good choice when reliability is critical because it lacks the careful analysis and design phases that are essential for dependable systems. Short Time Schedules Projects that have short time schedules are well suited for RAD- based methodologies. This is due to them being designed to increase the speed of develop- ment. Prototyping and phased development–based methodologies are excellent choices when timelines are short because they best enable the project team to adjust the function- ality in the system based on a specific delivery date, and if the project schedule starts to slip, it can be readjusted by removing functionality from the version or prototype under devel- opment. Waterfall-based methodologies are the worst choice when time is at a premium because they do not allow for easy schedule changes. Schedule Visibility One of the greatest challenges in systems development is determin- ing whether a project is on schedule. This is particularly true of the structured design methodologies because design and implementation occur at the end of the project. The RAD-based methodologies move many of the critical design decisions earlier in the project to help project managers recognize and address risk factors and keep expectations in check. Object-Oriented Systems Analysis and Design (OOSAD) 17 Suppose you are an analyst for the Roanoke Software Consulting Company (RSCC), a large consulting firm with offices around the world. The company wants to build a new knowledge management system that can identify and track the expertise of individual consultants anywhere in the world based on their education and the various consulting projects on which they have worked. Assume that this is a new idea that has never before been attempted in RSCC or elsewhere. RSCC has an international network, but the offices in each country may use somewhat different hardware and software. RSCC management wants the system up and running within a year. Question 1. What type of methodology would you recommend RSCC use? Why? 1-1 Selecting a Methodology YOUR TURN OBJECT-ORIENTED SYSTEMS ANALYSIS AND DESIGN (OOSAD) Object-oriented approaches to developing information systems, technically speaking, can use any of the traditional methodologies (waterfall development, parallel development, phased development, prototyping, and throwaway prototyping). However, the object- oriented approaches are most associated with a phased development RAD methodology. The primary difference between a traditional approach like structured design and an object- oriented approach is how a problem is decomposed. In traditional approaches, the problem decomposition process is either process centric or data centric. However, processes and data are so closely related that it is difficult to pick one or the other as the primary focus. Based on this lack of congruence with the real world, new object-oriented methodologies have emerged that use the RAD-based sequence of SDLC phases but attempt to balance the
- 43. emphasis between process and data by focusing the decomposition of problems on objects that contain both data and processes. Both approaches are valid approaches to developing information systems. In this book, we focus only on object-oriented approaches.11 According to the creators of the Unified Modeling Language (UML), Grady Booch, Ivar Jacobson, and James Rumbaugh,12 any modern object-oriented approach to developing information systems must be (1) use-case driven, (2) architecture-centric, and (3) iterative and incremental. Use-Case Driven Use-case driven means that use cases are the primary modeling tools defining the behavior of the system. A use case describes how the user interacts with the system to perform some activity, such as placing an order, making a reservation, or searching for information. The use cases are used to identify and to communicate the requirements for the system to the programmers who must write the system. Use cases are inherently simple because they focus on only one activity at a time. In contrast, the process model diagrams used by traditional structured and RAD methodolo- gies are far more complex because they require the system analyst and user to develop models of the entire system. With traditional methodologies, each business activity is decomposed into a set of subprocesses, which are, in turn, decomposed into further sub- processes, and so on. This goes on until no further process decomposition makes sense, and it often requires dozens of pages of interlocking diagrams. In contrast, use cases focus on only one activity at a time, so developing models is much simpler.13 Architecture Centric Any modern approach to systems analysis and design should be architecture centric. Archi- tecture centric means that the underlying software architecture of the evolving system spec- ification drives the specification, construction, and documentation of the system. Modern object-oriented systems analysis and design approaches should support at least three sep- arate but interrelated architectural views of a system: functional, static, and dynamic. The functional, or external, view describes the behavior of the system from the perspective of the user. The structural, or static, view describes the system in terms of attributes, methods, classes, and relationships. The behavioral, or dynamic, view describes the behavior of the system in terms of messages passed among objects and state changes within an object. Iterative and Incremental Modern object-oriented systems analysis and design approaches emphasize iterative and incre- mental development that undergoes continuous testing and refinement throughout the life of the project.This implies that the systems analysts develop their understanding of a user’s prob- lem by building up the three architectural views little by little. The systems analyst does this by 18 Chapter 1 Introduction to Systems Analysis and Design 11 See Alan Dennis, Barbara Haley Wixom, and Roberta M. Roth, Systems Analysis and Design: An Applied Approach, 3rd ed. (New York: Wiley, 2006) for a description of the traditional approaches. 12 Grady Booch, Ivar Jacobson, and James Rumbaugh, The Unified Modeling Language User Guide (Reading, MA: Addison-Wesley, 1999). 13 For those of you that have experience with traditional structured analysis and design, this will be one of the most unusual aspects of object-oriented analysis and design using UML. Structured approaches emphasize the decomposition of the complete business process into subprocesses and sub-subprocesses. Object-oriented approaches stress focusing on just one use-case activity at a time and distributing that single use case over a set of communicating and collaborating objects. Therefore, use-case modeling may seem initially unsettling or counterintuitive, but in the long run this single focus does make analysis and design simpler.
- 44. working with the user to create a functional representation of the system under study. Next, the analyst attempts to build a structural representation of the evolving system. Using the structural representation of the system, the analyst distributes the functionality of the system over the evolving structure to create a behavioral representation of the evolving system. As an analyst works with the user in developing the three architectural views of the evolving system, the analyst will iterate over each of and among the views. That is, as the analyst better understands the structural and behavioral views, the analyst will uncover missing requirements or misrepresentations in the functional view. This, in turn, can cause changes to be cascaded back through the structural and behavioral views. All three archi- tectural views of the system are interlinked and dependent on each other (see Figure 1-9). As each increment and iteration is completed, a more complete representation of the user’s real functional requirements are uncovered. Benefits of Object-Oriented Systems Analysis and Design Concepts in the object-oriented approach enable analysts to break a complex system into smaller, more manageable modules, work on the modules individually, and easily piece the modules back together to form an information system. This modularity makes system development easier to grasp, easier to share among members of a project team, and easier to communicate to users, who are needed to provide requirements and confirm how well the system meets the requirements throughout the SDLC. By modularizing system devel- opment, the project team actually is creating reusable pieces that can be plugged into other systems efforts or used as starting points for other projects. Ultimately, this can save time because new projects don’t have to start completely from scratch. Many people argue that “object-think” is a much more realistic way to think about the real world. Users typically do not think in terms of data or process; instead, they see their business as a collection of logical units that contain both—so communicating in terms of objects improves the interaction between a user and an analyst or developer. THE UNIFIED PROCESS The Unified Process is a specific methodology that maps out when and how to use the var- ious UML techniques for object-oriented analysis and design. The primary contributors were Grady Booch, Ivar Jacobsen, and James Rumbaugh of Rational. Whereas the UML provides structural support for developing the structure and behavior of an information system, the Unified Process provides the behavioral support. The Unified Process, of course, is use-case driven, architecture centric, and iterative and incremental. The Unified Process 19 Functional view Structural view Behavioral view Object-Oriented Analysis FIGURE 1-9 Iterative and Incremental Development
- 45. The Unified Process is a two-dimensional systems development process described by a set of phases and workflows. The phases are inception, elaboration, construction, and tran- sition. The workflows include business modeling, requirements, analysis, design, imple- mentation, test, deployment, project management, configuration and change management, and environment. In the remainder of this section, we describe the phases and workflows of the Unified Process.14 Figure 1-10 depicts the Unified Process. Phases The phases of the Unified Process support an analyst in developing information systems in an iterative and incremental manner. The phases describe how an information system evolves through time. Depending on which development phase the evolving system is 20 Chapter 1 Introduction to Systems Analysis and Design 14 The material in this section is based on Khawar Zaman Ahmed and Cary E. Umrysh, Developing Enterprise Java Applications with J2EE and UML (Boston, MA: Addison-Wesley, 2002); Jim Arlow and Ila Neustadt, UML and The Unified Process: Practical Object-Oriented Analysis & Design (Boston, MA: Addison-Wesley, 2002); Peter Eeles, Kelli Houston, Wojtek Kozacynski, Building J2EE Applications with the Rational Unified Process, (Boston, MA: Addison-Wesley, 2003); Ivar Jacobson, Grady Booch, and James Rumbaugh, The Unified Software Development Process (Reading, MA: Addison-Wesley, 1999); Phillipe Krutchten, The Rational Unified Process: An Introduction, 2nd ed. (Boston, MA: Addison-Wesley, 2000). Phases Business Modeling Inception Engineering Workflows Elaboration Construction Transition Phases Inception Supporting Workflows Elaboration Construction Transition Requirements Analysis Design Implementation Configuration and Change Management Iter 1 … Iter i Iter i + 1 … Iter j Iter j + 1 … Iter k Iter k + 1 … Iter m Project Management Environment Test Deployment FIGURE 1-10 The Unified Process
- 46. Exploring the Variety of Random Documents with Different Content
- 47. L'ordre oblique. Le grand Frédéric après avoir changé la veille de périr, rétablit ses affaires en une journée, en prenant ou détruisant la moitié des forces qui lui étaient opposées. À Rosbach il était campé sur une hauteur d'accès difficile, ayant des marécages à sa droite, des bois à sa gauche. Le prince de Soubise opérant lui-même autrement que dans le dix-septième siècle, songe à tourner les Prussiens, et engage l'armée française, qu'il n'a pas su éclairer, dans les bois qui étaient à la gauche de l'ennemi. Frédéric laisse les Français s'enfoncer dans cette espèce de coupe-gorge, les arrête en leur présentant quelques bataillons de bonne infanterie, puis précipite sur leurs flancs la cavalerie de Seidlitz, et les met dans une déroute que, sans les triomphes de la Révolution et de l'Empire, nous ne pourrions nous rappeler sans rougir. Frédéric avait donc changé complétement l'art de combattre, en employant, selon le terrain, les diverses armes. Il avait cependant contracté une habitude, car, à la guerre ainsi que dans tous les arts, chaque individu prend le goût d'une manière particulière de procéder, et il adoptait, comme manœuvre favorite, de s'attaquer à une aile de l'ennemi, pour décider la victoire en triomphant de cette aile, d'où naquirent alors les fameuses discussions sur l'ordre oblique, qui ont rempli le dix- huitième siècle. Non-seulement Frédéric opérait une révolution dans l'emploi des diverses armes, il en changeait les proportions, réduisait la cavalerie à être tout au plus le tiers au lieu de la moitié, et développait l'artillerie, qu'il rendait à la fois plus nombreuse et plus mobile. Enfin sous le rapport qui exige le plus de supériorité d'esprit, celui de la direction générale des opérations, il accomplissait des changements plus notables encore. On pivotait dans le siècle précédent autour d'une place, pour la prendre ou empêcher qu'elle ne fût prise. Réduit à lutter contre les armées de l'Europe entière, lesquelles débouchaient tantôt de la Bohême, tantôt de la Pologne, tantôt de la Franconie, il se vit obligé de tenir tête à tous ces
- 48. l'ordre de bataille, imprime aux mouvements généraux une hardiesse et une étendue toutes nouvelles. ennemis à la fois, de négliger le danger qui n'était qu'inquiétant, pour faire face à celui qui était vraiment alarmant, de sacrifier ainsi l'accessoire au principal, de courir d'une armée à l'autre pour les battre alternativement, et se sauver par l'habile ménagement de ses forces. Mais, bien que la guerre soit devenue alors, grâce au progrès de chaque arme et à la situation extraordinaire de Frédéric, plus vive, plus alerte, plus hardie, elle était loin encore de ce que nous l'avons vue dans notre siècle. Frédéric n'était guère sorti de la Silésie et de la Saxe, c'est-à-dire de l'espace compris entre l'Oder et l'Elbe, et n'avait jamais songé à embrasser d'un vaste regard toute la configuration d'un empire, à saisir le point où, en s'y portant audacieusement, on pouvait frapper un coup qui terminât la guerre. Il avait bien pensé à entrer à Dresde, qui était à sa portée, jamais il ne s'était avisé de marcher sur Vienne. Si de Glogau ou de Breslau il courait à Erfurt, c'était parce qu'après avoir combattu un ennemi, on lui en signalait un nouveau qui approchait, et qu'il y courait, comme un vaillant animal traqué par des chiens, se jette tantôt sur celui-ci, tantôt sur celui-là, lorsque après la dent de l'un il a senti la dent de l'autre. En un mot, il avait déjà commencé une grande révolution, il ne l'avait pas terminée. Ainsi par exemple il campait encore, et ne sachant pas, comme Napoléon en 1814, chercher dans un faux mouvement de l'ennemi l'occasion d'une manœuvre décisive, il s'enfermait dans le camp de Buntzelwitz, où il passait plusieurs mois à attendre la fortune, qui vint en effet le sauver d'une ruine certaine, en substituant Pierre III à Élisabeth sur le trône de Russie. Il ne se bornait pas à camper, reste des anciennes coutumes, il couvrait sa frontière avec ce qu'on appelait alors le dégât. Voulant interdire l'accès de la Silésie aux armées autrichiennes, il brûlait les moissons, coupait les arbres, incendiait les fermes, sur un espace large de dix ou quinze lieues, long de trente à quarante, et, au lieu d'opérations savantes, opposait à l'ennemi la famine. Faute d'être assez hardie ou assez habile, la guerre était cruelle. Si donc Frédéric avait changé l'ordre de bataille, qu'il avait subordonné au terrain, s'il avait imprimé aux mouvements généraux une allure qu'on ne leur avait pas encore vue, obligé qu'il
- 49. Comment on peut s'expliquer que Frédéric ait pu, à la tête d'une nation de 6 millions d'hommes, tenir tête à la Russie, à l'Autriche et à la France durant sept années. était à lutter contre trois puissances à la fois, il n'avait pas poussé la grande guerre à ses derniers développements. Il laissait ce soin à la Révolution française, et à l'homme extraordinaire qui devait porter ses drapeaux aux confins du monde civilisé. Du reste il avait assez fait, et peu d'hommes dans la marche de l'esprit humain ont franchi un espace plus vaste. Il avait en effet, à force de caractère, de génie, résisté à la France, à l'Autriche, à la Russie, avec une nation qui, même après l'acquisition de la Silésie, n'était pas de plus de 6 à 7 millions d'hommes, vrai prodige qui eût été impossible sans quelques circonstances qu'il faut énumérer brièvement pour rendre ce prodige concevable. D'abord l'Angleterre aida Frédéric de son or, parcimonieusement il est vrai, mais l'aida néanmoins. Au moyen de cet or il se procura des soldats, et comme on se battait Allemands contre Allemands, le soir de ses batailles il convertissait les prisonniers en recrues, ce qui lui permit de suppléer à l'insuffisance de la population prussienne. De plus il occupait une position concentrique entre la Russie, l'Autriche et la France, et en courant rapidement de Breslau à Francfort-sur-l'Oder, de Francfort à Dresde, de Dresde à Erfurt, il pouvait tenir tête à tous ses ennemis, ce que facilitait aussi une circonstance plus décisive encore, c'est que si l'Autriche lui faisait une guerre sérieuse, la Russie et la France, gouvernées par le caprice de cour, ne lui faisaient qu'une guerre de fantaisie. Élisabeth envoyait chaque année une armée russe qui livrait une bataille, la perdait ou la gagnait, et puis se retirait en Pologne. Les Français, occupés contre les Anglais dans les Pays-Bas, et aussi déplorablement administrés que commandés, envoyaient de temps en temps une armée qui, mal accueillie, comme à Rosbach par exemple, ne reparaissait plus. Frédéric n'avait donc affaire véritablement qu'à l'Autriche, ce qui ne rend pas son succès moins étonnant, et ce qui ne l'eût pas sauvé, s'il n'avait été ce que de notre temps on appelle légitime. Deux fois en effet ses ennemis entrèrent dans Berlin, et au lieu de le détrôner, ce qu'ils n'auraient pas manqué de faire s'ils avaient eu un prétendant à lui
- 50. Grandeur des actions de Frédéric. C'était à la Révolution française qu'il appartenait d'achever la révolution de l'art militaire, en donnant à l'infanterie son entier développement, et à la guerre une audace extraordinaire. Caractère des premières substituer, s'en allèrent après avoir levé quelques centaines de mille écus de contribution. Ce sont ces circonstances réunies qui, sans le diminuer, expliquent le prodige d'un petit prince luttant seul contre les trois plus grandes puissances de l'Europe, leur tenant tête sept ans, les déconcertant par ses coups imprévus, les fatiguant par sa ténacité, donnant le temps à la fortune de lui envoyer en Russie un changement de règne, et désarmant enfin par son génie et sa constance les trois femmes qu'il avait déchaînées par sa mauvaise langue. Son œuvre n'en est pas moins une des plus mémorables de l'histoire, et mérite de prendre place à côté de celles qu'ont accomplies Alexandre, Annibal, César, Gustave-Adolphe, Napoléon. Il appartenait à la Révolution française d'imprimer à l'art de la grande guerre une dernière et décisive impulsion. Le mouvement civilisateur qui avait substitué l'infanterie à la cavalerie, c'est- à-dire les nations elles-mêmes à la noblesse à cheval, devait recevoir en effet de la Révolution française, qui était l'explosion des classes moyennes, son dernier élan. Les Français en 1789 avaient dans le cœur deux sentiments: le chagrin d'avoir vu la France déchoir depuis Louis XIV, ce qu'ils attribuaient aux légèretés de la cour, et l'indignation contre les puissances européennes, qui voulaient les empêcher de réformer leurs institutions en les fondant sur le principe de l'égalité civile. Aussi la nation courut-elle tout entière aux armes. La vieille armée royale, quoique privée par l'émigration d'une notable partie de ses officiers, suffit aux premières rencontres, et sous un général, Dumouriez, qui jusqu'à cinquante ans avait perdu son génie dans de vulgaires intrigues, livra d'heureux combats. Mais elle fondit bientôt au feu de cette terrible guerre, et la Révolution envoya pour la remplacer des flots de population qui devinrent de l'infanterie. Ce n'est pas avec des hommes levés à la hâte que l'on fait des cavaliers, des artilleurs, des sapeurs
- 51. campagnes de la Révolution. Pichegru, Moreau, Jourdan, Kléber, Hoche. Apparition du jeune Bonaparte. du génie, mais dans un pays essentiellement militaire, qui a l'orgueil et la tradition des armes, on peut en faire des fantassins. Ces fantassins incorporés dans les demi-brigades à ce qui restait de la vieille armée, lui apportant leur audace, lui prenant son organisation, se jetèrent d'abord sur l'ennemi en adroits tirailleurs, puis le culbutèrent en le chargeant en masse à la baïonnette. Avec le temps ils apprirent à manœuvrer devant les armées les plus manœuvrières de l'Europe, celles qui avaient été formées à l'école de Frédéric et de Daun; avec le temps encore ils fournirent des artilleurs, des cavaliers, des soldats du génie, et acquérant la discipline qu'ils n'avaient pas d'abord, conservant de leur premier élan l'audace et la mobilité, ils composèrent bientôt la première armée du monde. Il n'était pas possible que ce sentiment puissant de quatre-vingt- neuf, combiné avec nos séculaires traditions militaires, nous donnât des armées sans nous donner aussi des généraux, que notre infanterie devenue manœuvrière comme les armées allemandes les meilleures, et en outre plus vive, plus alerte, plus audacieuse, n'exerçât pas sur ceux qui la commandaient une irrésistible influence, et effectivement elle poussa Pichegru en Hollande, Moreau, Kléber, Hoche, Jourdan au milieu de l'Allemagne. Mais tandis qu'il se formait des généraux capables de bien diriger une armée, il devait s'en former non pas deux, mais un qui serait capable de diriger à la fois toutes les armées d'un vaste empire, car le mouvement moral est comme le mouvement physique, imprimé à plusieurs corps à la fois, il porte chacun d'eux à des distances proportionnées à leur volume et à leur poids. Tandis que Pichegru, Hoche, Moreau, Kléber, Desaix, Masséna, étaient le produit de ce mouvement national, leur maître à tous se révélait à Toulon, et ce maître que l'univers nomme, c'était le jeune Bonaparte, élevé au sein des écoles de l'ancien régime, dans la plus savante des armes, celle de l'artillerie, mais plein de l'esprit nouveau, et à son audace personnelle, la plus grande peut-être qui ait inspiré une âme humaine, joignant l'audace de la Révolution
- 52. Son étude approfondie de la carte. Son arrivée au commandement de l'armée d'Italie. française. Doué de ce génie universel qui rend les hommes propres à tous les emplois, il avait de plus une disposition qui lui était particulière, c'était l'application à étudier le sol sur la carte, et le penchant à y chercher la solution des phénomènes de la politique comme des problèmes de la guerre. Sans cesse couché sur des cartes, ce que font trop rarement les militaires, et ce qu'ils faisaient encore moins avant lui, il méditait continuellement sur la configuration du sol où la guerre sévissait alors, et à ces profondes méditations joignait les rêves d'un jeune homme, se disant que s'il était le maître il ferait ceci ou cela, pousserait dans tel ou tel sens les armées de la République, ne se doutant nullement que maître il le serait un jour, mais sentant fermenter en lui quelque chose d'indéfinissable, comme on sent quelquefois sourdre sous ses pieds l'eau qui doit bientôt percer la terre et jaillir en source féconde. Livré à ces méditations solitaires, il avait compris que l'Autriche, ayant renoncé aux Pays-Bas, n'était vulnérable qu'en Italie, et que c'était là qu'il fallait porter la guerre pour la rendre décisive. Parlant sans cesse de ces rêves aux directeurs, dont il était le commis, les en fatiguant presque, il est d'abord nommé commandant de Paris, et puis, Schérer s'étant laissé battre, général de l'armée d'Italie. À peine arrivé à Nice, le jeune général aperçoit d'un coup d'œil qu'il n'a pas besoin de forcer les Alpes, et qu'il lui suffit de les tourner, comme il l'a dit avec tant de profondeur. En effet, les Piémontais et les Autrichiens gardaient le col de Montenotte, où les Alpes s'abaissent pour se relever plus loin sous le nom d'Apennins. Il fait une menace sur Gênes afin d'y attirer les Autrichiens, puis en une nuit force le col de Montenotte où les Piémontais restaient seuls de garde, les enfonce, les précipite en deux batailles sur Turin, arrache la paix au roi de Piémont, et fond sur le Pô à la poursuite des Autrichiens, qui voyant qu'ils s'étaient trompés en se laissant attirer sur Gênes, se hâtaient de revenir pour protéger Milan. Il passe le Pô à Plaisance, entre dans Milan, court à Lodi, force l'Adda et s'arrête à l'Adige, où son esprit transcendant lui montre la vraie frontière de l'Italie contre les Allemands. Un génie moins profond aurait couru au midi pour s'emparer de Florence, de Rome, de
- 53. Son établissement sur l'Adige. Ce qu'il y avait de génie dans cette résolution. Naples. Il n'y songe même pas. C'est aux Allemands qu'il faut disputer l'Italie, dit-il au Directoire, c'est contre eux qu'il faut prendre position, et qui va au midi de l'Italie, trouvera au retour Fornoue, comme Charles VIII, ou la Trebbia, comme Macdonald[32]. Il se décide donc à rester au nord, et avec le même génie aperçoit que le Pô a un cours trop long pour être facilement défendu, que l'Isonzo trop avancé est toujours exposé à être tourné par le Tyrol, que l'Adige seul peut être victorieusement défendu, parce qu'à peine sorti des Alpes à Vérone ce cours d'eau tombe dans les marécages à Legnago, et que placé en deçà du Tyrol il ne peut pas être tourné. Le jeune Bonaparte s'établit alors sur l'Adige, en raisonnant comme il suit: Si les Autrichiens veulent forcer l'Adige par les montagnes, ils passeront nécessairement par le plateau de Rivoli; s'ils veulent le forcer par la plaine, ils se présenteront ou devant Vérone, ou vers les marais, dans les environs de Legnago. Dès lors il faut placer le gros de ses troupes au centre, c'est-à-dire à Vérone, laisser deux détachements de garde, l'un à Rivoli, l'autre vers Legnago, les renforcer alternativement l'un ou l'autre suivant la direction que prendra l'ennemi, et rester imperturbablement dans cette position, en faisant du siége de Mantoue une sorte de passe- temps entre les diverses apparitions des Autrichiens. Grâce à cette profondeur de jugement, avec trente-six mille hommes, à peine augmentés d'une quinzaine de mille pendant le cours de la guerre, le jeune Bonaparte tient tête à toutes les armées autrichiennes, et en dix-huit mois livrant douze batailles, plus de soixante combats, faisant plus de cent mille prisonniers, accable l'Autriche et lui arrache l'abandon définitif de la ligne du Rhin à la France, plus la paix générale. Certes, on peut parcourir les pages de l'histoire tout entière, et on n'y verra rien de pareil. La conception générale et l'art des combats, tout s'y trouve à un degré de perfection qui ne s'est jamais rencontré. Passer les montagnes à Montenotte en attirant les Autrichiens sur Gênes par une feinte, maître de Milan, au lieu de courir à Rome et à Naples, courir à Vérone, comprendre que l'Italie
- 54. Batailles d'Arcole et de Rivoli. Le général Bonaparte avait porté à la perfection l'art des mouvements généraux et des batailles. Campagne de 1800, et passage du Saint-Bernard. étant à disputer aux soldats du Nord, c'est au Nord qu'il faut vaincre, laisser le Midi comme un fruit qui tombera de l'arbre quand il sera mûr, choisir entre les diverses lignes défensives celle de l'Adige, parce qu'elle n'est pas démesurément longue comme le Pô, facile à tourner comme l'Isonzo, et s'y tenir invariablement jusqu'à ce qu'on y ait attiré et détruit toutes les forces de l'Autriche, voilà pour la conception. Attendre l'ennemi en avant de Vérone, s'il se présente directement le repousser à la faveur de la bonne position de Caldiero, s'il tourne à droite vers le bas pays aller le combattre dans les marais d'Arcole, où le nombre n'est rien et la valeur est tout, quand il descend sur notre gauche par le Tyrol, le recevoir au plateau de Rivoli, et là maître des deux routes, celle du fond de la vallée que suivent l'artillerie et la cavalerie, celle des montagnes que suit l'infanterie, jeter d'abord l'artillerie et la cavalerie dans l'Adige, puis faire prisonnière l'infanterie dépourvue du secours des autres armes, prendre dix-huit mille hommes avec quinze mille, voilà pour l'art du combat: et faire tout cela à vingt-six ans, joindre ainsi à l'audace de la jeunesse toute la profondeur de l'âge mûr, n'a rien, nous le répétons, de pareil dans l'histoire, pour la grandeur des conceptions unie à la perfection de l'exécution! Tout le reste de la carrière du général Bonaparte est marqué des mêmes traits: discernement transcendant du but où il faut viser dans une campagne, et habileté profonde à profiter du terrain où les circonstances de la guerre vous amènent à combattre, en un mot, égale supériorité dans les mouvements généraux et dans l'art de livrer bataille. En 1800, nous étions maîtres de la Suisse que nous occupions jusqu'au Tyrol, ayant à gauche les plaines de la Souabe, à droite celles du Piémont. Les Autrichiens ne s'attendant pas aux hardis mouvements de leur jeune adversaire, s'étaient avancés à gauche jusque vers Huningue, à droite jusqu'à Gênes. Le
- 55. Marengo. Campagne de 1805. Ulm. Premier Consul imagine de fondre des deux côtés de la chaîne des Alpes sur leurs derrières, propose à Moreau de descendre par Constance sur Ulm, tandis qu'il descendra par le Saint-Bernard sur Milan. Moreau hésite à se jeter ainsi en pleine Bavière au milieu des masses ennemies. Le Premier Consul laisse Moreau libre d'agir à son gré, passe le Saint- Bernard sans routes frayées, en faisant rouler à travers les précipices ses canons enfermés dans des troncs d'arbres, tombe sur les derrières des Autrichiens surpris, et les force à Marengo de lui livrer en une journée l'Italie entière, qui, deux ans auparavant, lui avait coûté douze batailles et soixante combats, tandis que Moreau, opérant à sa manière méthodique et sage, met six mois à s'approcher de Vienne. Là encore le point où il faut frapper est choisi avec une telle justesse que, le coup porté, l'ennemi est désarmé sur-le-champ. La bataille décisive, il est vrai, ne présente point la perfection de celle de Rivoli, par exemple. On était en plaine, le terrain offrait peu de circonstances heureuses, et une reconnaissance mal exécutée avait laissé ignorer la présence des Autrichiens. Le Premier Consul fut donc surpris et faillit être battu. Mais au lieu de Grouchy il avait Desaix pour lieutenant, et l'arrivée de celui-ci lui ramena la victoire. Du reste si un accident rendit la bataille chanceuse, l'opération qui le plaça à l'improviste sur les derrières de l'ennemi n'en est pas moins un prodige qui n'a de comparable que le passage d'Annibal, réalisé deux mille ans auparavant. En 1805, obligé de renoncer à l'expédition d'Angleterre et de se rejeter sur le continent, le jeune Consul devenu empereur, porte en quinze jours ses armées de Flandre en Souabe. Ordinairement nous passions par les défilés de la Forêt-Noire pour gagner les sources du Danube, et selon leur coutume les Autrichiens y accouraient en hâte. Il les y retient en présentant des têtes de colonnes dans les principaux de ces défilés, puis il se dérobe tout à coup, longe par sa gauche les Alpes de Souabe, débouche par Nuremberg sur les derrières des Autrichiens qu'il
- 56. Austerlitz. Campagne de 1806 en Prusse. enferme dans Ulm, et oblige une armée entière de soixante mille hommes à mettre bas les armes devant lui, ce qui ne s'était jamais vu dans aucun siècle. Débarrassé du gros des forces autrichiennes, et apprenant que les Prussiens deviennent menaçants, loin d'hésiter il s'élance sur Vienne, entraîne dans son mouvement ses armées d'Italie que commandait Masséna, les rallie à Vienne même, puis court à Austerlitz, où il trouve les Russes réunis au reste de la puissance autrichienne, arrivé sur les lieux feint d'hésiter, de reculer, tente ainsi la présomption d'Alexandre, qui, guidé par des jeunes gens, veut couper l'armée française de Vienne. Ce faisant, Alexandre dégarnit le plateau de Pratzen, où était son centre. Napoléon y fond comme un aigle, et, coupant en deux l'armée ennemie, en jette une partie dans les lacs, une autre dans un ravin. Il se retourne ensuite vers les Prussiens, qui, au lieu de se joindre à la coalition, sont réduits à s'excuser à genoux d'avoir songé à lui faire la guerre. Ici encore les mouvements généraux ont à la fois une audace et une justesse sans pareilles; la bataille décisive est une merveille d'adresse et de présence d'esprit, et ce n'est pas miracle que les empires tombent devant de tels prodiges d'art. Au lieu de la paix sûre, durable, qu'il aurait pu conclure avec l'Europe, le vainqueur d'Austerlitz enivré de ses succès, s'attire la guerre avec la Prusse, soutenue par la Russie. L'armée prussienne se porte derrière la forêt montagneuse de Thuringe pour couvrir les plaines du centre de l'Allemagne. Napoléon l'y laisse, remonte à droite jusque vers Cobourg, débouche sur l'extrémité gauche de la ligne ennemie, aborde les Prussiens de manière à les couper du Nord où les Russes les attendent, les accable à Iéna, à Awerstaedt, et, les débordant sans cesse dans leur retraite, prend jusqu'au dernier d'entre eux à Prenzlow, non loin de Lubeck. Ce jour-là il n'y avait plus de monarchie prussienne; l'œuvre du grand Frédéric était abolie!
- 57. Campagne de 1807 en Pologne. Friedland. Il fallait aller au Nord chercher les Russes, les saisir corps à corps pour les corriger de leur habitude de pousser sans cesse contre nous les puissances allemandes, qu'ils abandonnaient après les avoir compromises. Napoléon se porte sur la Vistule, et pour la première fois il se met en présence de ces deux grandes difficultés, le climat et la distance, qui devaient plus tard lui devenir si funestes. Son armée a encore toute sa vigueur morale et physique; cependant, à cette distance, il y a des soldats qui se débandent, il y en a que la faim, le froid dégoûtent. Napoléon déploie une force de volonté et un génie d'organisation extraordinaires pour maintenir son armée intacte, lutte sur les plaines glacées d'Eylau avec une énergie indomptable contre l'énergie barbare des Russes, emploie l'hiver à consolider sa position en prenant Dantzig, et le printemps venu, son armée reposée, marche sur le Niémen en descendant le cours de l'Ale. Son calcul, c'est que les Russes seront obligés de se rapprocher du littoral pour vivre, qu'il leur faudra dès lors passer l'Ale devant lui, et il s'avance l'œil fixé sur cet événement, dont il espère tirer un parti décisif. Le 14 juin en effet, anniversaire de Marengo, il trouve les Russes passant l'Ale à Friedland. Excepté les grenadiers d'Oudinot, tous ses corps sont en arrière. Accouru de sa personne sur les lieux, il emploie Oudinot à tirailler, et amène le reste de son armée en toute hâte. Une fois qu'il a toutes ses forces sous la main, au lieu de les jeter sur les Russes, il attend que ceux-ci aient passé l'Ale; pour les y engager il replie sa gauche en avançant peu à peu sa droite vers Friedland où sont les ponts des Russes, détruit ensuite ces ponts, et quand il a ainsi ôté à l'ennemi tout moyen de retraite, il reporte en avant sa gauche d'abord refusée, pousse les Russes dans l'Ale, les y refoule comme dans un gouffre, et noie ou prend presque tout entière cette armée, la dernière que l'Europe pût lui opposer. Certes, nous le répétons, tout est là au même degré de perfection. Prévoir que les Russes essayeront de gagner le littoral afin de rejoindre leurs magasins, et pour cela passeront l'Ale devant l'armée
- 58. Ces succès prodigieux devaient amener les grandes fautes française, les suivre, les surprendre au moment du passage, attendre qu'ils aient presque tous franchi la rivière, leur enlever leurs ponts, et ces ponts enlevés les refouler dans l'Ale, sont de vrais prodiges où la prévoyance la plus profonde dans la conception générale, égale la présence d'esprit dans l'opération définitive, c'est- à-dire dans la bataille. En Italie, Napoléon avait été le général dépendant, réduit à des moyens bornés; en Autriche, en Prusse, en Pologne, il avait été le général, chef d'État, disposant des ressources d'un vaste empire, donnant à ses opérations toute l'étendue de ses conceptions, et en un jour renversant l'Autriche, en un autre la Prusse, en un troisième la Russie, et tout cela à des distances où l'on n'avait jamais porté la guerre. Il avait été dans le premier cas le modèle du général subordonné, il fut dans le second le modèle du général tout-puissant et conquérant. Ici plus de ces mouvements limités autour d'une place, de ces batailles classiques où la cavalerie était aux ailes, l'infanterie au centre: les mouvements ont les proportions des empires à frapper, et les batailles la physionomie exacte du lieu où elles sont livrées. Les batailles ressemblent, en la surpassant, à celle de Leuthen; et quant aux mouvements, ils ont une bien autre portée que ceux de Frédéric, courant hors d'haleine de Breslau à Francfort-sur-l'Oder, de Francfort-sur-l'Oder à Erfurt, sans jamais frapper le coup décisif qui aurait terminé la guerre. Non pas qu'il ne faille admirer l'activité, la constance, la ténacité de Frédéric, bien digne de son surnom de grand! Il est vrai néanmoins que le général français, ajoutant à l'audace de la Révolution la sienne, étudiant les grands linéaments du sol comme jamais on ne l'avait fait avant lui, était arrivé à une étendue, à une justesse de mouvements telles, que ses coups étaient à la fois sûrs et décisifs, et en quelque sorte sans appel! L'art, on peut le dire, avait atteint ses dernières limites. Malheureusement ces succès prodigieux devaient corrompre non le général, chaque jour plus consommé dans son art, mais le politique, lui persuader que tout était possible, le conduire tantôt en Espagne, tantôt en Russie, avec des
- 59. d'Espagne et de Russie. Est-il vrai que Napoléon ne fut que le général des guerres heureuses? armées affaiblies par leur renouvellement trop rapide, et à travers des difficultés sans cesse accrues, d'abord par la distance qui n'était pas moindre que celle de Cadix à Moscou, ensuite par le climat qui était tour à tour celui de l'Afrique ou de la Sibérie, ce qui forçait les hommes à passer de quarante degrés de chaleur à trente degrés de froid, différences extrêmes que la vie animale ne saurait supporter. Au milieu de pareilles témérités, le plus grand, le plus parfait des capitaines devait succomber! Aussi beaucoup de juges de Napoléon qui, sans être jamais assez sévères pour sa politique, le sont beaucoup trop pour ses opérations militaires, lui ont-ils reproché d'être le général des succès, non celui des revers, de savoir envahir, de ne savoir pas défendre, d'être le premier dans la guerre offensive, le dernier dans la guerre défensive, ce qu'ils résument par ce mot, que Napoléon ne sut jamais faire une retraite! C'est là, selon nous, un jugement erroné. Lorsque dans l'enivrement du succès, Napoléon se portait à des distances comme celle de Paris à Moscou, et sous un climat où le froid dépassait trente degrés, il n'y avait plus de retraite possible, et Moreau, qui opéra l'admirable retraite de Bavière en 1800, n'eût certainement pas ramené intacte l'armée française de Moscou à Varsovie. Quand des désastres comme celui de 1812 se produisaient, ce n'était plus une de ces alternatives de la guerre qui vous obligent tantôt à avancer, tantôt à reculer, c'était tout un édifice qui s'écroulait sur la tête de l'audacieux qui avait voulu l'élever jusqu'au ciel. Les armées, poussées au dernier degré d'exaltation pour aller jusqu'à Moscou, se trouvant surprises tout à coup par un climat destructeur, se sentant à des distances immenses, sachant les peuples révoltés sur leurs derrières, tombaient dans un abattement proportionné à leur enthousiasme, et aucune puissance ne pouvait plus les maintenir en ordre. Ce n'était pas une retraite faisable que le chef ne savait pas faire, c'était l'édifice de la monarchie universelle qui s'écroulait sur la tête de son téméraire auteur!
- 60. Sa ténacité, sa vigueur dans les revers. Campagne de 1814. Mais on ne serait pas général si on ne l'était dans l'adversité comme dans la prospérité, car la guerre est une telle suite d'alternatives heureuses ou malheureuses, que celui qui ne saurait pas suffire aux unes comme aux autres, ne pourrait pas commander une armée quinze jours. Or, lorsque le général Bonaparte assailli par les Autrichiens en novembre 1796, au milieu des fièvres du Mantouan, n'ayant guère plus de dix mille hommes à mettre en ligne, se jetait dans les marais d'Arcole pour y annuler la puissance du nombre, il faisait preuve d'une fermeté et d'une fertilité d'esprit dans les circonstances difficiles qui certainement n'ont pas beaucoup d'exemples. Lorsqu'en 1809, à l'époque où la série des grandes fautes politiques était commencée, il se trouvait à Essling acculé au Danube, privé de tous ses ponts par une crue extraordinaire du fleuve, et se repliait dans l'île de Lobau avec un sang-froid imperturbable, il ne montrait pas moins de solidité dans les revers. Sans doute la résistance à Essling même fut le prodige de Lannes qui y mourut, de Masséna qui y serait mort si Dieu ne l'avait fait aussi heureux qu'il était tenace; mais la fermeté de Napoléon qui, au milieu de Vienne émue, de tous nos généraux démoralisés, découvrait des ressources où ils n'en voyaient plus, et adoptait le plan ferme et patient au moyen duquel la victoire fut ramenée sous nos drapeaux à Wagram, cette fermeté, tant admirée de Masséna, appartenait bien à Napoléon, et ce moment offrit certainement l'une des extrémités de la guerre les plus grandes et les plus glorieusement traversées, dont l'histoire des nations ait conservé le souvenir. Enfin, pour donner tout de suite la preuve la plus décisive, la campagne de 1814, où Napoléon avec une poignée d'hommes, les uns usés, les autres n'ayant jamais vu le feu, tint tête à l'Europe entière, non pas en battant en retraite, mais en profitant des faux mouvements de l'ennemi pour le ramener en arrière par des coups terribles, est un bien autre exemple de fécondité de ressources, de présence d'esprit, de fermeté indomptable dans une situation désespérée. Sans doute Napoléon ne faisait pas la guerre défensive, comme la
- 61. Aucune partie de l'homme de guerre n'avait manqué à Napoléon. Progrès qu'il a fait faire à l'organisation des armées. plupart des généraux, en se retirant méthodiquement d'une ligne à une autre, défendant bien la première, puis la seconde, puis la troisième, et ne parvenant ainsi qu'à gagner du temps, ce qui n'est pas à dédaigner, mais ce qui ne suffit pas pour terminer heureusement une crise: il faisait la guerre défensive comme l'offensive; il étudiait le terrain, tâchait d'y prévoir la manière d'agir de l'ennemi, de le surprendre en faute et de l'accabler, ce qu'il fit contre Blucher et Schwarzenberg en 1814, et ce qui eût assuré son salut, si tout n'avait été usé autour de lui, hommes et choses. S'il ne fut pas à proprement parler le général des retraites, parce qu'il pensait comme Frédéric que la meilleure défensive était l'offensive, il se montra dans les guerres malheureuses aussi grand que dans les guerres heureuses. Dans les unes comme dans les autres il conserva le même caractère de vigueur, d'audace, de promptitude à saisir le point où il fallait frapper, et s'il succomba, ce ne fut pas, nous le répétons, le militaire qui succomba en lui, c'est le politique qui avait entrepris l'impossible, en voulant vaincre l'invincible nature des choses. Dans l'organisation des armées, Napoléon ne fut pas moins remarquable que dans la direction générale des opérations, et dans les batailles. Ainsi avant lui les généraux de la République distribuaient leurs armées en divisions composées de toutes armes, infanterie, artillerie, cavalerie, et se réservaient tout au plus une division non engagée, composée elle-même comme les autres, afin de parer aux coups imprévus. Chacun des lieutenants livrait à lui seul une bataille isolée, et le rôle du général en chef consistait à secourir celui d'entre eux qui en avait besoin. On pouvait éviter ainsi des défaites, gagner même des batailles, mais jamais de ces batailles écrasantes, à la suite desquelles une puissance était réduite à déposer les armes. Avec la personne de Napoléon,
- 62. Sa manière de composer sa réserve. Son art pour recruter et tenir ses armées ensemble. l'organisation des corps d'armée devait changer, et changer de manière à laisser dans les mains de celui qui dirigeait tout le moyen de tout décider. En effet, son armée était divisée en corps dont l'infanterie était le fond, avec une portion d'artillerie pour la soutenir, et une portion de cavalerie pour l'éclairer. Mais, indépendamment de l'infanterie de la garde qui était sa réserve habituelle, il s'était ménagé des masses de cavalerie et d'artillerie, qui étaient comme la foudre qu'il gardait pour la lancer au moment décisif. À Eylau l'infanterie russe paraissant inébranlable, il lançait sur elle soixante escadrons de dragons et de cuirassiers, et y ouvrait ainsi une brèche qui ne se refermait plus. À Wagram Bernadotte ayant laissé percer notre ligne, il arrêtait avec cent bouches à feu le centre victorieux de l'archiduc Charles, et rétablissait le combat que Davout terminait en enlevant le plateau de Wagram. C'est pour cela qu'indépendamment de la garde il avait composé deux réserves, l'une de grosse cavalerie, l'autre d'artillerie à grande portée, lesquelles étaient dans sa main la massue d'Hercule. Mais pour la massue il faut la main d'Hercule, et avec un général moindre que Napoléon, cette organisation aurait eu l'inconvénient de priver souvent des lieutenants habiles d'armes spéciales dont ils auraient su tirer parti, pour les concentrer dans les mains d'un chef incapable de s'en servir. Aussi presque tous les généraux de l'armée républicaine du Rhin, habitués à agir chacun de leur côté d'une manière presque indépendante, et à réunir dès lors une portion suffisante de toutes les armes, regrettaient l'ancienne composition, ce qui revient à dire qu'ils regrettaient un état de choses qui leur laissait plus d'importance à la condition de diminuer les résultats d'ensemble. Mais l'organisation ne consiste pas seulement à bien distribuer les diverses parties d'une armée, elle consiste à la recruter, à la nourrir. Sous ce rapport, l'art que Napoléon déploya pour porter les conscrits de leur village aux bords du Rhin, des bords du Rhin à ceux de l'Elbe, de la Vistule, du Niémen, les réunissant dans des
- 63. Ses grandes opérations pour dompter la nature. Passage du Danube en 1809. dépôts, les surveillant avec un soin extrême, ne les laissant presque jamais échapper, et les menant ainsi par la main jusqu'au champ de bataille, cet art fut prodigieux. Il consistait dans une mémoire des détails infaillible, dans un discernement profond des négligences ou des infidélités des agents subalternes, dans une attention continuelle à les réprimer, dans une force de volonté infatigable, dans un travail incessant qui remplissait souvent ses nuits, quand le jour avait été passé à cheval. Et malgré tous ces efforts, les routes étaient souvent couvertes de soldats débandés, mais qui n'attestaient qu'une chose, c'est la violence qu'on faisait à la nature, en portant des hommes des bords du Tage à ceux du Volga! À ces tâches si diverses du général en chef il faut souvent en joindre une autre, c'est celle de dompter les éléments, pour franchir des montagnes neigeuses, des fleuves larges et violents, et parfois la mer elle-même. L'antiquité a légué à l'admiration du monde le passage des Pyrénées et des Alpes par Annibal, et il est certain que les hommes n'ont rien fait de plus grand, peut-être même d'aussi grand. La traversée du Saint- Bernard, le transport de l'armée d'Égypte à travers les flottes anglaises, les préparatifs de l'expédition de Boulogne, enfin le passage du Danube à Wagram, sont de grandes opérations que la postérité n'admirera pas moins. La dernière surtout sera un éternel sujet d'étonnement. La difficulté consistant en cette occasion à aller chercher l'armée autrichienne au delà du Danube pour lui livrer bataille, et à traverser ce large fleuve avec cent cinquante mille hommes en présence de deux cent mille autres, qui nous attendaient pour nous précipiter dans les flots, sans qu'on pût les éviter en se portant au-dessus ou au-dessous de Vienne, car dans le premier cas on se serait trop avancé, et dans le second on eût rétrogradé; cette difficulté fut surmontée d'une manière merveilleuse. En trois heures, 150 mille hommes, 500 bouches à feu, avaient passé devant l'ennemi stupéfait, qui ne songeait à nous combattre que lorsque nous avions pris pied sur la rive gauche, et que nous étions en mesure de lui tenir tête. Le passage du Saint-Bernard, si
- 64. Influence de Napoléon sur les armées. Tableau résumé des progrès de l'art militaire. extraordinaire qu'il soit, est loin d'égaler le passage des Alpes par Annibal; mais le passage du Danube en 1809 égale toutes les opérations tentées pour vaincre la puissance combinée de la nature et des hommes, et restera un phénomène de prévoyance profonde dans le calcul, et d'audace tranquille dans l'exécution. Enfin on ne dirait pas tout sur le génie militaire de Napoléon, si on n'ajoutait qu'aux qualités les plus diverses de l'intelligence il joignit l'art de dominer les hommes, de leur communiquer ses passions, de les subjuguer comme un grand orateur subjugue ses auditeurs, tantôt de les retenir, tantôt de les lancer, tantôt enfin de les ranimer s'ils étaient ébranlés, et toujours enfin de les tenir en main, comme un habile cavalier tient en main un cheval difficile. Il ne lui manqua donc aucune partie de l'esprit et du caractère nécessaires au véritable capitaine, et on peut soutenir que si Annibal n'avait existé, il n'aurait probablement pas d'égal. Ainsi, résumant ce que nous avons dit des progrès de la grande guerre, nous répéterons que deux hommes la portèrent au plus haut degré dans l'antiquité, Annibal et César; que César cependant, restreint par les habitudes du campement, y montra moins de hardiesse de mouvements, de fécondité de combinaisons, d'opiniâtreté dans toutes les fortunes qu'Annibal; qu'au moyen âge Charlemagne, chef d'empire admirable, ne nous donne pas néanmoins l'idée vraie du grand capitaine, parce que l'art était trop grossier de son temps; qu'alors l'homme de guerre fut presque toujours à cheval, et à peine aidé de quelques archers; qu'avec le développement des classes moyennes au sein des villes l'infanterie commença, qu'elle se montra d'abord dans les montagnes de la Suisse, puis dans les villes allemandes, italiennes, hollandaises; que, la poudre ayant renversé les murailles saillantes, les villes enfoncèrent leurs défenses en terre; qu'alors un art subtil, celui de la fortification moderne, prit naissance; qu'autour des villes à prendre ou à secourir, la guerre savante et hardie, la grande guerre, en un mot, reparut dans le monde; que les Nassau en furent les premiers
- 65. maîtres, qu'ils y déployèrent d'éminentes qualités et une constance demeurée célèbre, que néanmoins enchaînée autour des places, elle resta timide encore; qu'une lutte sanglante s'étant engagée au Nord entre les protestants et les catholiques, laquelle dura trente ans, Gustave-Adolphe, opposant un peuple brave et solide à la cavalerie polonaise, fit faire de nouveaux progrès à l'infanterie; qu'entraîné en Allemagne, il rendit la guerre plus hardie, et la laissa moins que les Nassau, circonscrite autour des places; qu'en France, Condé, heureux mélange d'esprit et d'audace, manifesta le premier le vrai génie des batailles, Turenne, celui des grands mouvements; que cependant l'infanterie partagée en mousquetaires et piquiers n'était pas manœuvrière; que Vauban, en lui donnant le fusil à baïonnette, permit de la placer sur trois rangs; que le prince d'Anhalt-Dessau, chargé de l'éducation de l'armée prussienne, constitua le bataillon moderne qui fournit beaucoup de feux en leur offrant peu de prise; que Frédéric, prenant cet instrument en main et ayant à lutter aux frontières de la Silésie et de la Bohême, changea l'ordre de bataille classique, et le premier adapta les armes au terrain; qu'obligé de tenir tête tantôt aux Autrichiens, tantôt aux Russes, tantôt aux Français, il élargit le cercle des grandes opérations, et fut ainsi dans l'art de la guerre l'auteur de deux progrès considérables; qu'après lui vint la Révolution française, laquelle, n'ayant que des masses populaires à opposer à l'Europe coalisée, résista par le nombre et l'élan aux vieilles armées; que l'infanterie, expression du développement des peuples, prit définitivement sa place dans la tactique moderne, sans que les armes savantes perdissent la leur; qu'enfin un homme extraordinaire, à l'esprit profond et vaste, au caractère audacieux comme la Révolution française dont il sortait, porta l'art de la grande guerre à sa perfection en méditant profondément sur la configuration géographique des pays où il devait opérer, en choisissant toujours bien le point où il fallait se placer pour frapper des coups décisifs, en joignant à l'art des mouvements généraux celui de bien combattre sur chaque terrain, en cherchant toujours ou dans le sol ou dans la situation de l'ennemi l'occasion de ses grandes batailles, en n'hésitant jamais à les livrer, parce qu'elles étaient la conséquence de ses mouvements généraux, en s'y prenant si bien en un mot que
- 66. Napoléon comparé aux grands hommes de l'histoire, quant à l'ensemble de leurs qualités et de leurs destinées. Alexandre le Grand. chacune d'elles renversait un empire, ce qui amena malheureusement chez lui la plus dangereuse des ivresses, celle de la victoire, le désir de la monarchie universelle, et sa chute, de manière que ce sage législateur, cet habile administrateur, ce grand capitaine, fut à cause même de toutes ses supériorités très-mauvais politique, parce que perdant la raison au sein de la victoire, il alla de triomphe en triomphe finir dans un abîme. Maintenant, si on le compare aux grands hommes, ses émules, non plus sous le rapport spécial de la guerre, mais sous un rapport plus général, celui de l'ensemble des talents et de la destinée, le spectacle devient plus vaste, plus moral, plus instructif. Si, en effet, on s'attache au bruit, à l'importance des événements, à l'émotion produite chez les hommes, à l'influence exercée sur le monde, il faut, pour lui trouver des pareils, aller chercher encore Alexandre, Annibal, César, Charlemagne, Frédéric, et en plaçant sa physionomie à côté de ces puissantes figures, on parvient à s'en faire une idée à la fois plus précise et plus complète. Alexandre héritant de l'armée de son père, nourri du savoir des Grecs, passionné pour leurs applaudissements, se jette en Asie, ne trouve à combattre que la faiblesse persane, et marche devant lui jusqu'à ce qu'il rencontre les limites du monde alors connu. Si ses soldats ne l'arrêtaient, il irait jusqu'à l'océan Indien. Obligé de revenir, il n'a qu'un désir, c'est de recommencer ses courses aventureuses. Ce n'est pas à sa patrie qu'il songe, laquelle n'a que faire de tant de conquêtes; c'est à la gloire d'avoir parcouru l'univers en vainqueur. Sa passion c'est sa renommée, reconnue, applaudie à Athènes. Généreux et même bon, il tue son ami Clitus, ses meilleurs lieutenants, Philotas et Parménion, parce que leur langue imprudente a touché à sa gloire. La renommée, voilà son but, but le plus vain entre tous ceux qu'ont poursuivis les grands hommes, et tandis qu'après avoir laissé reposer son armée il va de nouveau
- 67. Welcome to our website – the ideal destination for book lovers and knowledge seekers. With a mission to inspire endlessly, we offer a vast collection of books, ranging from classic literary works to specialized publications, self-development books, and children's literature. Each book is a new journey of discovery, expanding knowledge and enriching the soul of the reade Our website is not just a platform for buying books, but a bridge connecting readers to the timeless values of culture and wisdom. With an elegant, user-friendly interface and an intelligent search system, we are committed to providing a quick and convenient shopping experience. Additionally, our special promotions and home delivery services ensure that you save time and fully enjoy the joy of reading. Let us accompany you on the journey of exploring knowledge and personal growth! ebookfinal.com