Beginning Software Engineering 1st Edition by Rod Stephens.
The book in PDF Format with title Beginning Software Engineering 1st Edition by Rod Stephens is available to download for free and Download Link is at the end of the article
Contents:
INTRODUCTION
▸ PART I SOFTWARE ENGINEERING STEP‐BY‐STEP
CHAPTER 1 Software Engineering from 20,000 Feet
CHAPTER 2 Before the Beginning
CHAPTER 3 Project Management
CHAPTER 4 Requirement Gathering
CHAPTER 5 High‐Level Design
CHAPTER 6 Low‐Level Design
CHAPTER 7 Development
CHAPTER 8 Testing
CHAPTER 9 Deployment
CHAPTER 10 Metrics
CHAPTER 11 Maintenance
▸ PART II PROCESS MODELS
CHAPTER 12 Predictive Models
CHAPTER 13 Iterative Models
CHAPTER 14 RAD
APPENDIX Solutions to Exercises
GLOSSARY
INDEX
Introduction: 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 fi les in a directory hierarchy. Unfortunately, the script recursively climbed its way to the top of the directory tree and then started cheerfully deleting every fi le in the system. The script ran for only about fi ve seconds before it was stopped, but it had already trashed enough fi les 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 applications that are effective, fl exible, and robust enough for use in real‐world situations. This book won’t make you an expert systems analyst, software architect, project manager, or programmer, but it explains what those people do and why they are necessary for producing high‐quality software. It also gives you the tools you need to start. You won’t rush out and lead a 1,000‐person effort to build a new air traffi c control system for the FAA, but it can help you work effectively in small‐scale and large‐scale development projects. (It can also help you understand what a prospective future boss means when he says, “Yeah, we mostly use Scrum with a few extra XP techniques thrown in.”).
WHO SHOULD READ THIS BOOK?
Everyone involved in any software development effort should have a basic understanding of software engineering. Whether you’re an executive customer specifying the software’s purpose and features, an end user who will eventually spend time working with (and reporting bugs in) the fi nished application, a lead developer who keeps other programmers on track (and not playing too much Flow Free), or the guy who fetches donuts for the weekly meeting, you need to understand how all the pieces of the process fi t together. A failure by any of these people (particularly the donut wallah) affects everyone else, so it’s essential that everyone knows the warning signs that indicate the project may be veering toward disaster.
This book is mainly intended for people with limited experience in software engineering. It doesn’t expect you to have any previous experience with software development, project management, or programming. (I suspect most readers will have some experience with donuts, but that’s not necessary, either.)
Even if you have some familiarity with those topics, particularly programming, you may still fi nd this book informative. If you’ve been focusing only on the pieces of a project assigned to you, you still need to learn about how the pieces interact to help guide the project toward success.
For example, I had been working as a programmer for several years and even taken part in some fairly large development efforts before I took a good look at the development process as a whole. I knew other people were writing use cases and deployment plans, but my focus was on my piece of the project. It wasn’t until later, when I started taking a higher‐level role in projects that I actually started to see the entire process.
This book does not explain how to program. It does explain some techniques programmers can use to produce code that is fl exible enough to handle the inevitable change requests, easy to debug (at least your code will be), and easy to enhance and maintain in the future (more change requests), but they are described in general terms and don’t require you to know how to program.
If you don’t work in a programming role, for example if you’re an end user or a project manager, you’ll hopefully fi nd that material interesting even if you don’t use it directly. You may also fi nd some techniques surprisingly applicable to nonprogramming problems. For example, techniques for generating problem‐solving approaches apply to all sorts of problems, not just programming decisions. (You can also ask developers, “Are you using assertions and gray‐box testing methods before unit testing?” just to see if they understand what you’re talking about. Basically, you’re using gray‐box testing to see if the developers know what gray‐box testing is. You’ll learn more about that in Chapter 8 , “Testing.”)
APPROACH:
This book is divided into two parts. The fi rst part describes the basic tasks you need to complete and deliver useful software. Things such as design, programming, and testing. The book’s second part describes some common software development models that use different techniques to perform those tasks.
Before you can begin to work on a software development project, however, you need to do some preparation. You need to set up tools and techniques that help you track your progress throughout the project. Chapter 1, “Software Engineering from 20,000 Feet,” describes these “before‐the‐ beginning” activities.
After you have the preliminaries in place, there are many approaches you can take to produce software. All those approaches have the same goal (making useful software), so they must handle roughly the same tasks. These are things such as gathering requirements, building a plan, and actually writing the code. The fi rst part of this book describes these tasks. Chapter 1explains those tasks at a high level. Chapters 2through 11 provide additional details about what these tasks are and how you can accomplish them effectively.
The second part of the book describes some of the more popular software development approaches. All these models address the same issues described in the earlier chapters but in different ways. Some focus on predictability so that you know exactly what features will be provided and when. Others focus on creating the most features as quickly as possible, even if that means straying from the original design. Chapters 12through 14 describe some of the most popular of these development models.
That’s the basic path this book gives you for learning software engineering. First learn the tasks you need to complete to deliver useful software. Then learn how different models handle those tasks. However, many people have trouble learning by slogging through a tedious enumeration of facts. (I certainly do!) To make the information a bit easier to absorb, this book includes a few other elements.
Each chapter ends with exercises that you can use to see if you were paying attention while you read the chapter. I don’t like exercises that merely ask you to repeat what is in the chapter. (Quick, what are some advantages and disadvantages of the ethereal nature of software?) Most of the exercises ask you to expand on the chapter’s main ideas. Hopefully, they’ll make you think about new ways to use what’s explained in the chapter.
Sometimes, the exercises are the only way I could sneak some more information into the chapter that didn’t quite fi t in any of its sections.
n those cases, the questions and answers provided in Appendix A are like extended digressions and thought experiments than quiz questions. I strongly recommend that you at least skim the exercises and think about them. Then ask yourself if you understand the solutions. All the solutions are included in Appendix A, “Solutions to Exercises.
WHAT THIS BOOK COVERS (AND WHAT IT DOESN’T):
This book describes software engineering, the tasks that you must perform to successfully complete a software project, and some of the most popular developer models you can use to try to achieve your goals. It doesn’t cover every last detail, but it does explain the overall process so that you can fi gure out how you fi t into the process.
This book does not explain every possible development model. Actually, it barely scratches the surface of the dozens (possibly hundreds) of models that are in use in the software industry. This book describes only some of the most popular development approaches and then only relatively briefly.
If you decide you want to learn more about a particular approach, you can turn to the hundreds of books and thousands of web pages written about specifi c models. Many development models also have their own organizations with websites dedicated to their promotion. For example, see www.extremeprogramming.org, agilemanifesto.org, and www.scrum.org.
This book also isn’t an exhaustive encyclopedia of software development tricks and tips. It describes some general ideas and concepts that make it easier to build robust software, but its focus is on higher‐level software engineering issues, so it doesn’t have room to cover all the clever techniques developers use to make programs better. This book also doesn’t focus on a specifi c programming language, so it can’t take advantage of language‐specifi c tools or techniques.
WHAT TOOLS DO YOU NEED?
You don’t need any tools to read this book. All you need is the ability to read the book. (And perhaps reading glasses. Or perhaps a text‐to‐speech tool if you have an electronic version that you want to “read.” Or perhaps a friend to read it to you. Okay, I guess you have several options.)
To actually participate in a development effort, you may need a lot of tools. If you’re working on a small, one‐person project, you might need only a programming environment such as Visual Studio, Eclipse, RAD Studio, or whatever. For larger team efforts you’ll also need tools for project management, documentation (word processors), change tracking, software revision tracking, and more. And, of course, you’ll need other developers to help you. This book describes these tools, but you certainly don’t need them to read the book.
Rod Stephens.
Beginning Software Engineering by Rod Stephens pdf.
Book Details:
⏩Edition: 1st
⏩Author: Rod Stephens
⏩Publisher: Sybex; 1 edition (March 23, 2015)
⏩Puplication Date: March 23, 2015
⏩Language: English
⏩Pages: 482
⏩Size: 20.8 MB
⏩Format: PDF
Disclaimer:
engreferencebooks.com website respects the intellectual property rights of others and expects its users to do the same, The book name and content is copyrighted material by the respective publishers and we are not publishing either or distributing the book. We here at Engineering Reference Pdf; neither upload books and not share it for commercial purpose. Only downloading links are shared which are found by detailed scrutiny and research over the internet. So we are here just sharing those links not the books. If you notice any copyright material please contact us immediately at DMCA form and point out its URL, we’ll remove relevant links or contents!
👇👇Downloading The Book👇👇
Download Beginning Software Engineering 1st Edition by Rod Stephens in pdf format for free.
