Beginning Software Engineering

If I were to sum this book up in once sentence fragment, it would be this: "Practical instructions on developing software in a clear and engaging format." This book was my main textbook in a software engineering class, so I've read the whole thing. First, it's a blast to read. It is full of funny quotes and down-to-earth tips from a veteran in the field. You will not get bored at any point! Second, the information is both relevant and useful. This comes from someone who expected it to be a waste of time because it doesn't teach any actual coding languages; however, anyone seeking a professional career in software development should learn to gather user requirements, design entities, test and debug code, and apply to correct SDLC methods to a development project. Even if you are not a solo contractor or team lead, you simply must learn how software development projects work in order to be a serious coder. Third, the author actually responds to email! Believe it or not, Rod is very friendly, helpful, and delighted to hear feedback about his book.

Hi all, I'm a computer science student and this textbook is the thing I liked most about my software engineering class. Writing: The information is practical and straightforward and there are lots of blurbs where the author includes real-life anecdotes that illustrate why the advice in the book is relevant in a business setting. Honestly, I just like the writing style. It feels more like reading well-curated blog posts than an academic book. I also like the fact that all the information is justified without making the reader feel like their being talked down to or using too many contrived examples. Layout: Not only is the book well written, its well designed. I have dyslexia and some textbooks are not formatted in a way that makes my life any easier. The book is black, white, and grey and there isn't a ton of fancy formatting. Everything is displayed clearly and ordered logically. The summaries and key chapter takeaways at the beginning and end of chapters are actually useful. I've always respected textbook authors who are willing to give you a condensed version of the information at the beginning of chapters. What I actually did with the book I've dragged this book with me through two co-ops. I found that it was useful to reference at work. I might have stretched the truth a bit by saying I've re-read the book but I have referenced it and re-read various parts of it multiple times.

(A preamble to the notion of Software Engineering). Software Engineering, is an arcane, heady topic, with swimming pools of ink, and several forests of paper dedicated to it, during the last 35 years or so. It is more of a belief system than an engineering discipline, or as an electrical engineer once said to me in 1973 “witchcraft”. (For 1973 he was correct!) This book was a stroll down memory lane for me, because I have been a developer since 1972, and still going strong (geriatric) today. I have been strongly attracted toward some of the techniques and organization of, or methodology for developing software. I have read most of the original tomes as they were first written, and I still have most of them. Ron’s book is rather small considering what it covers. Ron Stevens illustrates how it should be done, where most of the stakes should be driven into the ground, and in most cases, several variations and techniques for each phase. All of these have their pluses and minuses. The worst solution is not to choose any. You will come away with the notion that software engineering perpetuates massive paper work, and it does, or more likely it did. If you piled up all the blueprints of the space shuttle, or plotted out all the traces on the latest CPU chip, the Amazon rain forest would be diminished by the size of Rhode Island. Yet these requirements are accommodated in other engineering disciplines. Software engineering is everything you wanted to know about building a small modular city of code. All of the questions asked and answered, designed and laid out. Now, on with it. Question: “Is Sofia Loren attractive?” Answer: “She weighs 54480 grams!” Is the White Star Liner “Titanic” big? She has more life boats than any other passenger liner! What is the spectral wavelength of the color “purple?” Questions asked and answered with real facts or metrics. The story about the seven blind men examining an elephant with their hands, and coming away with seven different answers and impressions about the elephant, depending on where they were standing, sums it up out side of formal documents. Software development is more of an art form, than say, electrical engineering, or mechanical engineering. Software engineering is the building of a text blue print or text circuit schematic which is the guide to the construction of software. Software is implemented in text, in response to a stated need, which can be interpreted in many different ways. Ron’s chapters guide you through all the various stages and levels, and specifies the various techniques which address these issues. I have at least five of Rod Stevens books and the code in in his books is outstanding (or at least his code style and organization can be on anyone’s short list.) I got this book on the pre-order form and sat down and read it back to back. Twice. Rod’s engineering book is outstanding also, being more of a tour guide through the battlefield of techniques and applications of code development. Most of the battles are about which technique is “better” but all are subjective and have valid points. Rod starts out with a high level observation of software development illustrating the steps: requirements, high level design, low level design, development, testing, deployment, maintenance, and wrap up. He then proceeds through all the steps just enumerated above, with all the software packages of tools which more or less help the process along the way. “More or less” was not sarcastic, for these packages are good at implementing the scope of what they do, but like the blind men and the elephant you come away with that particular measurement on that particular measuring context. Rod’s style of writing in this book is darkly humorous and on occasion sarcastic. Some of his examples of metrics are “number of programmer trips to the coffee pot”, which is in the same spirit of meetings “where the minutes are kept, but the hours are lost.” Books about engineering are as lively as watching paint dry, so this relief is necessary. The topics are covered very well with examples following nearly all the sections. Software Engineering using the methodologies in the book would advance development enormously and projects would be less expensive. Software Engineering’s problems are mostly political (office or corporate). Management wants results at the smallest cost. Developers want to know what they are building. Both parties are guilty of not committing to paper what is necessary invoking the cliché “by the book” in meetings but avoidance outside the meeting room, (actually Rod Stevens book, or parts of the book, would be the stake in the ground) to improve their chances to be more successful and software projects. In the spirit of Sophia’s weight, and the Titanic’s life boat count, and the color purple, committing these metrics to paper will set them in a context which they deserve. The measure of "attractive" in grams has its counter part in program complexity in "lines of code". Everyone in the United States is the end user of software, knowing or unknowingly. When you see a piece of magnificent software on your PC admire the fortitude it took to following some or all of Ron’s collected methodologies or the sheer person power ([Mongolian hoard], a term used to indicate throwing a cast of 1000s, 100s, or 10s of tough, driven, code warriors, and overrun the problem, by shear human weight) to achieve results. Read the book to see the directed journey that needs to be taken to get an idea for a program in your head, to an Icon on your PC desktop.

This is a wonderfully-written discussion of the major (and a few not-so-obvious) disciplines you'll need to be a competent, effective, productive software engineer or project lead. It's also funny, and written with a friendly voice. It covers all the major areas in great, but not overly excessive detail.

I'm quite experienced software developer, however more on database, data warehousing side. But I liked and enjoyed reading. It's very nice end to end wrap-up. Many things I felt with my gut, but this books named them explicitly. Very much feels that the author writes from experience, not academic background. I used the structure of the book to consolidate my new team of developers for a new project.

One of the best and most entertaining books I have read on a professional basis. Rod mixes information, common sense, personal experience, and funny but oh-so-true witticisms perfectly, so the information rarely becomes too dry. I really enjoy this book!

Very well written text for introducing the concepts and options for software engineering. Cleverly includes witty quotes from many sources which the author relates to the topics included within the topics. Good additional educational materials available to support classroom instruction. Fairly extensive coverage of various development and management approaches. Good questions/exercises also.

lo compre por curiosidad queria ver como piensan los ingenieros en software te da una idea como se trabaja en una oficina de ingenieros de software lo que debes y no hacer, como sacar los proyectos, cuanto se tardan los proyectos informaticos , lo problemas que se presentan en los proyectos informaticos te da una buena idea del trabajo. no te ensena a programar pero te sientes como un futuro creador de los siguiente en informatica en pocas palabras me gusto el libro