Fluent Essays

I have uploaded all the requirements, please pay attention to check.Thank you very much! wa_02request.docx beginning_software_engineering_1st_edition.pdf Unformatted Attachment Preview Read Chapter 2 and complete the following tasks Hopefully throughout the semester, students will occasionally gain deeper learning/insights that they will find especially useful in their personal or professional lives. I call these kinds of insights “AHA’s!” because they often occur to us seemingly out of nowhere. These AHA’s! are not usually fact-based pieces of information, but are usually integrative ideas about how to apply IT in personal professional lives, how to interact with others, or perhaps to how to be more effective in your endeavors. ```Each AHA! paper should be approximately 300 words in length (minimum 250 words) ! BEGINNING SOFTWARE ENGINEERING INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi ▸ PART I SOFTWARE ENGINEERING STEP‐BY‐STEP CHAPTER 1 Software Engineering from 20,000 Feet. . . . . . . . . . . . . . . . . . . . . . . 3 CHAPTER 2 Before the Beginning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 CHAPTER 3 Project Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 CHAPTER 4 Requirement Gathering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 CHAPTER 5 High‐Level Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 CHAPTER 6 Low‐Level Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 CHAPTER 7 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 CHAPTER 8 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 CHAPTER 9 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 CHAPTER 10 Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 CHAPTER 11 Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 ▸ PART II PROCESS MODELS CHAPTER 12 Predictive Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 CHAPTER 13 Iterative Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 CHAPTER 14 RAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 APPENDIX Solutions to Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361 GLOSSARY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417 INDEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437 BEGINNIING Software Engineering Rod Stephens Beginning Software Engineering Published by John Wiley & Sons, Inc. 10475 Crosspoint Boulevard Indianapolis, IN 46256 www.wiley.com Copyright © 2015 by John Wiley & Sons, Inc., Indianapolis, Indiana Published simultaneously in Canada ISBN: 978-1-118-96914-4 ISBN: 978-1-118-96916-8 (ebk) ISBN: 978-1-118-96917-5 (ebk) Manufactured in the United States of America 10 9 8 7 6 5 4 3 2 1 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 authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, or online at http://www.wiley.com/go/permissions. Limit of Liability/Disclaimer of Warranty: The publisher and the author make no representations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation warranties of fitness for a particular purpose. No warranty may be created or extended by sales or promotional materials. The advice and strategies contained herein may not be suitable for every situation. This work is sold with the understanding that the publisher is not engaged in rendering legal, accounting, or other professional services. If professional assistance is required, the services of a competent professional person should be sought. Neither the publisher nor the author shall be liable for damages arising herefrom. The fact that an organization or Web site is referred to in this work as a citation and/or a potential source of further information does not mean that the author or the publisher endorses the information the organization or Web site may provide or recommendations it may make. Further, readers should be aware that Internet Web sites listed in this work may have changed or disappeared between when this work was written and when it is read. For general information on our other products and services please contact our Customer Care Department within the United States at (877) 762-2974, outside the United States at (317) 572-3993 or fax (317) 572-4002. Wiley publishes in a variety of print and electronic formats and by print-on-demand. Some material included with standard print versions of this book may not be included in e-books or in print-on-demand. If this book refers to media such as a CD or DVD that is not included in the version you purchased, you may download this material at http://booksupport.wiley.com. For more information about Wiley products, visit www.wiley.com. Library of Congress Control Number: 2015930533 Trademarks: Wiley, the Wiley logo, Wrox, the Wrox logo, Programmer to Programmer, and related trade dress are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affi liates, in the United States and other countries, and may not be used without written permission. All other trademarks are the property of their respective owners. John Wiley & Sons, Inc., is not associated with any product or vendor mentioned in this book. ABOUT THE AUTHOR ROD STEPHENS started out as a mathematician, but while studying at MIT, he discovered how much fun programming is and he’s been programming professionally ever since. During his career, he has worked on an eclectic assortment of applications in such fields as telephone switching, billing, repair dispatching, tax processing, wastewater treatment, concert ticket sales, cartography, and training for professional football players. Rod has been a Microsoft Visual Basic Most Valuable Professional (MVP) for more than a decade and has taught introductory programming courses. He has written more than two dozen books that have been translated into languages from all over the world, and he’s written more than 250 magazine articles covering Visual Basic, C#, Visual Basic for Applications, Delphi, and Java. Rod’s popular VB Helper website (www.vb-helper.com) receives several million hits per month and contains thousands of pages of tips, tricks, and example programs for Visual Basic programmers. His C# Helper website (www.csharphelper.com) contains similar material for C# programmers. You can contact Rod at RodStephens@CSharpHelper.com or RodStephens@vb-helper.com. ABOUT THE TECHNICAL EDITOR BRIAN HOCHGURTEL has been doing .NET development for over ten years, and actually started his .NET experience with Rod Stephens when they wrote the Wiley book, Visual Basic.NET and XML, in 2002. Currently Brian works with C#, SQL Server, and SharePoint in Fort Collins, CO. CREDITS EXECUTIVE EDITOR Robert Elliott PROFESSIONAL TECHNOLOGY & STRATEGY DIRECTOR Barry Pruett PROJECT EDITOR Adaobi Obi Tuiton BUSINESS MANAGER Amy Knies TECHNICAL EDITOR Brian Hochgurtel ASSOCIATE PUBLISHER Jim Minatel PRODUCTION MANAGER Kathleen Wisor PROJECT COORDINATOR, COVER Brent Savage COPY EDITOR San Dee Phillips PROOFREADER Sarah Kaikini, Word One MANAGER OF CONTENT DEVELOPMENT & ASSEMBLY INDEXER Mary Beth Wakefield Johnna VanHoose Dinse MARKETING DIRECTOR COVER DESIGNER David Mayhew Wiley MARKETING MANAGER COVER IMAGE Carrie Sherrill ©iStock.com/Chris Hepburn p ACKNOWLEDGMENTS THANKS TO BOB ELLIOTT, Adaobi Obi Tulton, San Dee Phillips, Katie Wisor, and all the others who worked so hard to make this book possible. (Adaobi was this book’s project manager. You’ll learn what a project manager does in Chapter 3. It’s a bit different for writing a book but not as different as you might think. As always, many thanks for your hard work, Adaobi!) Thanks also to technical editor Brian Hochgurtel for giving me the benefit of his valuable experience. Special thanks to Mary Brodie at gearmark.blogs.com for letting me use her quote in Chapter 13, “Iterative Models.” CONTENTS INTRODUCTION xxi PART I: SOFTWARE ENGINEERING STEP‐BY‐STEP CHAPTER 1: SOFTWARE ENGINEERING FROM 20,000 FEET Requirements Gathering High‐Level Design Low‐Level Design Development Testing Deployment Maintenance Wrap‐up Everything All at Once Summary CHAPTER 2: BEFORE THE BEGINNING Document Management Historical Documents E‐mail Code Code Documentation Application Documentation Summary CHAPTER 3: PROJECT MANAGEMENT Executive Support Project Management PERT Charts Critical Path Methods Gantt Charts Scheduling Software Predicting Times Get Experience Break Unknown Tasks into Simpler Pieces 3 4 5 6 6 6 8 9 9 10 11 15 16 18 19 21 22 25 25 29 30 31 33 38 41 42 42 44 44 CONTENTS Look for Similarities Expect the Unexpected Track Progress Risk Management Summary CHAPTER 4: REQUIREMENT GATHERING Requirements Defined Clear Unambiguous Consistent Prioritized Verifiable Words to Avoid Requirement Categories Audience‐Oriented Requirements Business Requirements User Requirements Functional Requirements Nonfunctional Requirements Implementation Requirements FURPS FURPS+ Common Requirements Gathering Requirements Listen to Customers (and Users) Use the Five Ws (and One H) Who What When Where Why How Study Users 49 53 54 54 55 56 56 60 60 61 61 61 62 63 63 63 64 64 66 67 67 68 68 68 69 69 69 69 70 Refining Requirements 71 Copy Existing Systems Clairvoyance Brainstorm 71 73 74 Recording Requirements 76 UML User Stories xii 45 45 46 47 77 77 CONTENTS Use Cases Prototypes Requirements Specification Validation and Verification Changing Requirements Summary CHAPTER 5: HIGH‐LEVEL DESIGN The Big Picture What to Specify Security Hardware User Interface Internal Interfaces External Interfaces Architecture Monolithic Client/Server Component‐Based Service‐Oriented Data‐Centric Event‐Driven Rule‐Based Distributed Mix and Match Reports Other Outputs Database Audit Trails User Access Database Maintenance Configuration Data Data Flows and States Training UML Structure Diagrams Behavior Diagrams Activity Diagrams Use Case Diagram State Machine Diagram Interaction Diagrams 78 78 80 80 80 81 87 88 89 89 90 91 92 93 94 94 95 96 97 97 97 98 98 99 101 102 102 103 103 104 104 105 105 105 107 109 110 111 112 113 xiii CONTENTS Sequence Diagram Communication Diagram Timing Diagram Interaction Overview Diagram Summary CHAPTER 6: LOW‐LEVEL DESIGN OO Design Identifying Classes Building Inheritance Hierarchies Refinement Generalization Hierarchy Warning Signs Object Composition Database Design Relational Databases First Normal Form Second Normal Form Third Normal Form Higher Levels of Normalization Summary CHAPTER 7: DEVELOPMENT Use the Right Tools Hardware Network Development Environment Source Code Control Profilers Static Analysis Tools Testing Tools Source Code Formatters Refactoring Tools Training Selecting Algorithms Effective Efficient Predictable Simple Prepackaged Top‐Down Design xiv 113 114 115 115 116 119 120 121 122 123 125 126 127 127 128 130 134 135 137 138 143 144 144 145 146 147 147 147 147 147 148 148 148 149 149 151 152 152 153 CONTENTS Programming Tips and Tricks Be Alert Write for People, Not the Computer Comment First Write Self‐Documenting Code Keep It Small Stay Focused Avoid Side Effects Validate Results Practice Offensive Programming Use Exceptions Write Exception Handers First Don’t Repeat Code Defer Optimization Summary CHAPTER 8: TESTING Testing Goals Reasons Bugs Never Die Diminishing Returns Deadlines Consequences It’s Too Soon Usefulness Obsolescence It’s Not a Bug It Never Ends It’s Better Than Nothing Fixing Bugs Is Dangerous Which Bugs to Fix Levels of Testing Unit Testing Integration Testing Automated Testing Component Interface Testing System Testing Acceptance Testing Other Testing Categories 155 155 156 157 159 160 161 162 163 165 166 167 167 167 169 173 175 175 175 175 176 176 176 177 177 177 178 178 179 179 179 181 182 183 184 185 185 Testing Techniques 186 Exhaustive Testing Black‐Box Testing 186 187 xv CONTENTS White‐Box Testing Gray‐Box Testing Testing Habits Test and Debug When Alert Test Your Own Code Have Someone Else Test Your Code Fix Your Own Bugs Think Before You Change Don’t Believe in Magic See What Changed Fix Bugs, Not Symptoms Test Your Tests How to Fix a Bug Estimating Number of Bugs Tracking Bugs Found Seeding The Lincoln Index Summary CHAPTER 9: DEPLOYMENT Scope The Plan Cutover Staged Deployment Gradual Cutover Incremental Deployment Parallel Testing 189 189 189 190 192 193 193 193 194 194 194 195 195 197 197 198 203 204 204 206 206 206 208 209 Deployment Tasks Deployment Mistakes Summary 209 210 211 CHAPTER 10: METRICS 215 Wrap Party Defect Analysis Kinds of Bugs Discoverer Severity Time Created Age at Fix Task Type Ishikawa Diagrams xvi 188 188 216 216 217 217 217 218 218 218 219 CONTENTS Software Metrics Qualities of Good Attributes and Metrics Using Metrics Process Metrics Project Metrics Things to Measure Size Normalization Function Point Normalization Count Function Point Metrics Multiply by Complexity Factors Calculate Complexity Adjustment Value Calculate Adjusted FP Summary CHAPTER 11: MAINTENANCE Maintenance Costs Task Categories Perfective Tasks Feature Improvements New Features The Second System Effect Adaptive Tasks Corrective Tasks Preventive Tasks Clarification Code Reuse Improved Flexibility Bug Swarms Bad Programming Practices Individual Bugs Not Invented Here Task Execution Summary 222 223 224 226 226 227 229 231 232 232 233 235 235 241 242 243 244 245 245 245 247 248 251 252 253 254 254 255 256 256 256 257 PART II: PROCESS MODELS CHAPTER 12: PREDICTIVE MODELS Model Approaches Prerequisites Predictive and Adaptive Success and Failure Indicators 265 266 267 267 268 xvii CONTENTS Advantages and Disadvantages 268 Waterfall Waterfall with Feedback Sashimi Incremental Waterfall V‐Model Systems Development Life Cycle Summary 270 271 272 273 275 276 280 CHAPTER 13: ITERATIVE MODELS 283 Iterative Versus Predictive Iterative Versus Incremental Prototypes Types of Prototypes Pros and Cons Spiral 288 289 290 Clarifications Pros and Cons 293 294 Unified Process 295 Pros and Cons Rational Unified Process Cleanroom Summary CHAPTER 14: RAD RAD Principles James Martin RAD Agile Self‐Organizing Teams Agile Techniques Communication Incremental Development Focus on Quality XP XP Roles XP Values XP Practices Have a Customer On Site Play the Planning Game Use Standup Meetings Make Frequent Small Releases xviii 284 286 287 296 297 298 299 303 305 308 309 311 313 313 314 316 317 318 319 319 320 320 321 322 CONTENTS Use Intuitive Metaphors Keep Designs Simple Defer Optimization Refactor When Necessary Give Everyone Ownership of the Code Use Coding Standards Promote Generalization Use Pair Programming Test Constantly Integrate Continuously Work Sustainably Use Test‐Driven and Test‐First Development Scrum Scrum Roles Scrum Sprints Planning Poker Burndown Velocity Lean Lean Principles Crystal Crystal Clear Crystal Yellow Crystal Orange Feature‐Driven Development FDD Roles FDD Phases Develop a Model Build a Feature List Plan by Feature Design by Feature Build by Feature FDD Iteration Milestones Agile Unified Process Disciplined Agile Delivery DAD Principles DAD Roles DAD Phases Dynamic Systems Development Method DSDM Phases DSDM Principles DSDM Roles 322 322 322 323 323 324 324 324 324 325 325 325 327 327 328 329 330 331 332 332 333 335 336 337 338 338 340 340 340 341 341 342 342 343 345 346 346 347 348 348 349 350 xix CONTENTS Kanban Kanban Principles Kanban Practices Kanban Board Summary xx 351 352 353 353 355 APPENDIX: SOLUTIONS TO EXERCISES 361 GLOSSARY 417 INDEX 437 INTRODUCTION Programming today is a race between software engineers striving to build bigger and better idiot‐proof programs, and the universe trying to build bigger and better idiots. So far the universe is winning. —Rick Cook With modern development tools, it’s easy to sit down at the keyboard and bang out a working program with no previous design or planning, and that’s fi ne under some circumstances. My VB Helper (www.vb‐helper.com) and C# Helper (www.csharphelper.com) websites contain thousands of example programs written in Visual Basic and C#, respectively, and built using exactly that approach. I had an idea (or someone asked me a question) and I pounded out a quick example. Those types of programs are fi ne if you’re the only one using them and then for only a short while. They’re also okay if, as on my websites, they’re intended only to demonstrate a programming technique and they never leave the confi nes of the programming laboratory. If this kind of slap‐dash program escapes into the wild, however, the result can be disastrous. At best, nonprogrammers who use these programs quickly become confused. At worst, they can wreak havoc on their computers and even on those of their friends and coworkers. Even experienced developers sometimes run afoul of these half‐baked programs. I know someone (I won’t give names, but I also won’t say it wasn’t me) who wrote a simple recursive script to delete the files in a directory hierarchy. Unfortunately, the script recursively climbed its way to the top of the directory tree and then started cheerfully deleting every file in the system. The script ran for only about five seconds before it was stopped, but it had already trashed enough files that the operating system had to be reinstalled from scratch. (Actually, some developers believe reinstalling the operating system every year or so is character‐building. If you agree, perhaps this approach isn’t so bad.) I know another experienced developer who, while experimenting with Windows system settings, managed to set every system color to black. The result was a black cursor over a black desktop, displaying black windows with black borders, menus, and text. This person (who wasn’t me this time) eventually managed to fi x things by rebooting and using another computer that wasn’t color‐ impaired to walk through the process of fi xing the settings using only keyboard accelerators. It was a triumph of cleverness, but I suspect she would have rather skipped the whole episode and had her two wasted days back. For programs that are more than a few dozen lines long, or that will be given to unsuspecting end users, this kind of free‐spirited development approach simply won’t do. To produce applications that are effective, safe, and reliable, you can’t just sit down and start typing. You need a plan. You need … … software engineering. This book describes software engineering. It explains what software engineering is and how it helps produce application ... Purchase answer to see full attachment