ISE SOFTWARE ENGINEERING: A PRACTITIONERS APPROACH

i'll have to put a link to the .pdf syllabus here i created using this book as the primary textbook. there's some controversy on book from practitioner to ivory tower. i think it's all rubbish.software engineering has a lot of production and this book gets students to the next level as working managers and thought leaders ensuring excellence in their work, thinking ahead, and ensuring their work substance ao they're not axed for getting lazy.I've used cengage, and others, but McGraw Hills additional resources are clutch. I do all my work lecture building, augmentation, and case studies unless schools, like R1s, have mandatory cases that must be done. McGraw provides valuable, well organized content. their IT support desk is "THE" best i've ever used.bottom line: up to date text, actionable, and good for students to purchase and keep on their work desk.pro tip: world has changed and companies love their IT and analyst professionals approaching items like a research scientist and writing papers.i) keep a small, poignant, library at work and KNOW what authors are top in their field like Kimball and Inmonii) have a github with completed .pdf of sample project outcomes that tell a story. u should create in Colab and have a table u can text anyone in 15 seconds right to the colab book and.or the .pdf of itiii) this shows how you have solved problems and u provide on demand actionable intelligence - senior guys love that

Perfect conditions and delivered on time, good

I am still reading this book. But I liked it because I see that it has remained updated and current through the years.

I always get to dislike this book and then read some parts after a few years to retest if I can prove myself wrong. But no, I am not wrong. It does not explain what software engineering is. It has too many pages. Everything is too long. It uses English terms throughout the book that should in my opinion never occur in technical writing. Those terms are various euphemisms, annoying colloquial words and cliches. I absolutely cannot stand when the author uses storytelling. It is vague, with a bad terminology, and extremely inefficient. When I read the book, it is to solve a problem. It is not to read silly stories, it is not to see anything funny or stupid, I have entertainment and comedians for funny, stupid, silly stories and stupid words. Engineering is to me strictly about solving problems in a highly efficient way. This book is the opposite of engineering.The book is vague. When you want to master for example component-based software engineering, you get an incomplete set of a few steps, and some vague rules that appear to be written perhaps 20 years ago even if you are reading the latest edition and although the rules are vague you get only one example of something done that is supposed to be satisfying those vague rules. From only one example, you cannot derive any rules, so you cannot in fact use this for any purpose.The book is fluffy and hairy. Engineering is exact, everything has to be precise, quantitative, measurable, unambiguous, etc. This book is however written by an obvious comedian who is deliberately vague and who intentionally witholds information (not providing more than 1 example, not explaining anything with unambiguous terms). The references he provides in his book point mostly to obscure and obsolete books that were written for a different purpose than he refers them for, and they are often books with a specific methodology that has never made it mainstream and your colleagues at work would not be inclined to use such methodologies because they are impractical or too vague to be used.Pressman writes that software processes are meant to be vague, that they are meant to be interpreted by different people differently, that they are not supposed to be followed exactly, etc. and that what he writes is the exact opposite of engineering.In engineering, processes are supposed to be unambiguous, anything open to different interpretations is meant to be fixed to allow only one interpretation, any rule is supposed to be exactly followed and compliance is supposed to be measured/validated or else if a rule is not followed the resulting product created by skipping and misinterpreting rules is not a good product.I find this book more vague and misleading than anything else. It mostly does the exact opposite of teaching engineering. It teaches you to be an ignorant comedian, one who does not do any engineering at all, one who probably does not even know what engineering is. There is not anything written about the engineering design process in the book.I often thought the book described useful methods in more detail than many people can describe them, however those descriptions are too vague, too ambiguous for use in practice among team members and people who read this book will forget the stuff written in there as they will not be able to use it in any team, so I honestly cannot recommend this book or what the author teaches as he in my opinion teaches people to be ignorant comedians, probably popular, but everything is shallow and fake. This guy is neither a guru nor an engineer. He cannot even do academic writing. Story telling is terrible. He cannot even exactly describe anything. I thought I will read a book from an expert, but when I closely scrutinize is there is nobody home, no expert, no clue, it's dumb.The rules described in there are completely disconnected from practice. This is not how you teach engineering. Engineering is empirical. It is all connected to practice. Engineering is problem solving. This book is useless. It lacks any practical use (impractical, lacks efficient descriptions of methods and examples). It lacks any theoretical use (too vague, too ambiguous, based on bad sources).The author does not do a good job teaching anyone anything. He can write and speak about software engineering like a clown all day, all night, teaching nothing. The rules he describes there are not supposed to be rules. He should be instead describing the exact scientific theories that explain how something works, so that readers would then derive for themselves any rule if they need to solve a problem that is governed by this specific theory. A person who can vaguel talk and vaguely write about something all day, without becoming exact, measurable, verifiable is an infallible person who kind of does a marketing of his persona instead of teaching people anything useful. An arrogant egomaniac is a good explanation.A great book about software engineering that teaches you something useful is Software Engineering by Ian Sommerville. Even better are the IEEE course (certified software engineering master) and the SWEBOK. All that I can see written by Pressman is a bunch of vague and useless rules that should have been instead exact and useful scientific theories and mathematically exact concepts that are guided by those theories, and exact frameworks that solve some problem exactly, systematically, measurably, while being project managed.Well, maybe you are supposed to put this book on your desk at work, and when working, open it, while being a laughing comedian who knows nothing, and find the relevant page and choose some of the rules that you will follow like a dummy, not knowing why, only because it is written in there. If anyone uses this book, I am afraid that is a clown and a dummy, not a practitioner of engineering. Making people solve problems by giving them rules is fundamentally wrong. People need first a scientific theory that explains, then an empirical practice (hands-on) in solving problems using that theory.A practitioner should refer to SWEBOK, this book is only giving you rules that you should be deriving yourself if you are given a better book that gives you concepts and explanations.