ورود به حساب

نام کاربری گذرواژه

گذرواژه را فراموش کردید؟ کلیک کنید

حساب کاربری ندارید؟ ساخت حساب

ساخت حساب کاربری

نام نام کاربری ایمیل شماره موبایل گذرواژه

برای ارتباط با ما می توانید از طریق شماره موبایل زیر از طریق تماس و پیامک با ما در ارتباط باشید


09117307688
09117179751

در صورت عدم پاسخ گویی از طریق پیامک با پشتیبان در ارتباط باشید

دسترسی نامحدود

برای کاربرانی که ثبت نام کرده اند

ضمانت بازگشت وجه

درصورت عدم همخوانی توضیحات با کتاب

پشتیبانی

از ساعت 7 صبح تا 10 شب

دانلود کتاب What Every Engineer Should Know about Software Engineering

دانلود کتاب آنچه هر مهندس باید در مورد مهندسی نرم افزار بداند

What Every Engineer Should Know about Software Engineering

مشخصات کتاب

What Every Engineer Should Know about Software Engineering

دسته بندی: فن آوری
ویرایش:  
نویسندگان:   
سری:  
ISBN (شابک) : 0849372283, 9780849372285 
ناشر: CRC Press 
سال نشر: 2007 
تعداد صفحات: 330 
زبان: English 
فرمت فایل : PDF (درصورت درخواست کاربر به PDF، EPUB یا AZW3 تبدیل می شود) 
حجم فایل: 4 مگابایت 

قیمت کتاب (تومان) : 53,000



ثبت امتیاز به این کتاب

میانگین امتیاز به این کتاب :
       تعداد امتیاز دهندگان : 16


در صورت تبدیل فایل کتاب What Every Engineer Should Know about Software Engineering به فرمت های PDF، EPUB، AZW3، MOBI و یا DJVU می توانید به پشتیبان اطلاع دهید تا فایل مورد نظر را تبدیل نمایند.

توجه داشته باشید کتاب آنچه هر مهندس باید در مورد مهندسی نرم افزار بداند نسخه زبان اصلی می باشد و کتاب ترجمه شده به فارسی نمی باشد. وبسایت اینترنشنال لایبرری ارائه دهنده کتاب های زبان اصلی می باشد و هیچ گونه کتاب ترجمه شده یا نوشته شده به فارسی را ارائه نمی دهد.


توضیحاتی در مورد کتاب آنچه هر مهندس باید در مورد مهندسی نرم افزار بداند

آیا از رایانه برای انجام تجزیه و تحلیل یا شبیه سازی در کار روزانه خود استفاده می کنید؟ برای انجام کارهای تکراری اسکریپت های کوتاه بنویسید یا ماکروها را ضبط کنید؟ نیاز به یکپارچه سازی نرم افزارهای آماده در سیستم های خود دارید یا نیاز به چندین برنامه کاربردی برای کار با یکدیگر دارید؟ زمان زیادی برای کار کردن با پیچیدگی های کد خود دارید؟ به طور منظم با مهندسان نرم افزار کار کنید اما در برقراری ارتباط یا همکاری مشکل دارید؟ اگر هر یک از این موارد آشنا به نظر می رسد، ممکن است به یک آغازگر سریع در اصول مهندسی نرم افزار نیاز داشته باشید. تقریباً هر مهندس، صرف نظر از رشته، نیاز به توسعه نوعی نرم افزار در طول حرفه خود دارد. بدون مواجهه با چالش‌ها، فرآیندها و محدودیت‌های مهندسی نرم‌افزار، توسعه نرم‌افزار می‌تواند یک کار سنگین و ناکارآمد باشد. طراحی و ساخت نرم افزار صدا بر اساس اصول مستحکم. این کتاب با استفاده از فرمت پرسش و پاسخ منحصر به فرد، به مسائل و تصورات غلطی می‌پردازد که مهندسان برای کار موفقیت‌آمیز با مهندسان نرم‌افزار، توسعه مشخصات نرم‌افزار با کیفیت، و یادگیری اصول اولیه رایج‌ترین زبان‌های برنامه‌نویسی، رویکردهای توسعه، باید درک کنند. ، و پارادایم ها.


توضیحاتی درمورد کتاب به خارجی

Do you…Use a computer to perform analysis or simulations in your daily work?Write short scripts or record macros to perform repetitive tasks?Need to integrate off-the-shelf software into your systems or require multiple applications to work together?Find yourself spending too much time working the kinks out of your code?Work with software engineers on a regular basis but have difficulty communicating or collaborating?If any of these sound familiar, then you may need a quick primer in the principles of software engineering. Nearly every engineer, regardless of field, will need to develop some form of software during their career. Without exposure to the challenges, processes, and limitations of software engineering, developing software can be a burdensome and inefficient chore.In What Every Engineer Should Know about Software Engineering, Phillip Laplante introduces the profession of software engineering along with a practical approach to understanding, designing, and building sound software based on solid principles. Using a unique question-and-answer format, this book addresses the issues and misperceptions that engineers need to understand in order to successfully work with software engineers, develop specifications for quality software, and learn the basics of the most common programming languages, development approaches, and paradigms.



فهرست مطالب

0849372283......Page 1
What Every Engineer Should Know about Software Engineering......Page 2
What Every Engineer Should Know: Series Statement......Page 4
How is this book different from other software engineering books?......Page 5
Did anyone help you with this book?......Page 6
Are there copyrights and trademarks to be cited?......Page 7
Can you tell me about yourself?......Page 8
Table of Contents......Page 9
Appendix B......Page 0
What is software engineering?......Page 13
What is the difference between software engineering and systems engineering?......Page 14
What is the role of the software engineer?......Page 15
What kind of education do software engineers need?......Page 16
Why are there so many software engineers without the proper education?......Page 17
There are many proprietary certifications for software engineering practitioners. Are any of these valuable to a software engineer?......Page 18
Are there standards for software engineering practices, documentation, and so forth?......Page 19
Product Standards......Page 20
What is the Software Engineering Body of Knowledge?......Page 21
Are there any “fundamental theorems” of software engineering?......Page 23
Why is software so buggy and unreliable?......Page 24
Aren’t errors an unavoidable side effect of software development?......Page 25
1.5 Further Reading......Page 26
2.1 Introduction......Page 27
What is “software reliability”?......Page 28
What is a “bathtub curve”?......Page 29
How do we characterize software usability?......Page 31
What are the advantages of an open system?......Page 32
What is “verifiability”?......Page 33
Are there other software qualities?......Page 34
Isn’t every software process model just an abstraction?......Page 35
How many phases should the waterfall model have?......Page 36
What happens during the software design phase of the waterfall process model?......Page 38
What happens during the testing phase of the waterfall process model?......Page 39
What is the V model for software?......Page 40
What is the spiral model for software?......Page 41
What are evolutionary models?......Page 42
Why use the incremental model?......Page 43
Where is the UPM used?......Page 44
What is Extreme Programming?......Page 45
What are some of the practices of XP?......Page 46
When should agile methodologies be used?......Page 47
All of these process models look rather simplistic, artificial, or too prescriptive. Should they really be used?......Page 48
What is the DOD-STD-498 standard?......Page 49
What is in the ISO 9000-3 standard?......Page 50
What is ISO/IEC standard 12207?......Page 51
2.5 Further Reading......Page 52
3.1 Introduction......Page 54
What are the core requirements engineering activities?......Page 55
What are user requirements specifications?......Page 56
What are functional requirements?......Page 57
What are design constraint requirements?......Page 58
What is requirements elicitation?......Page 59
What is JAD?......Page 60
What are some of the ground rules for JAD sessions?......Page 61
What is QFD?......Page 62
But doesn’t the customer have to have teaching ability for this technique to work?......Page 63
Why can’t requirements just be communicated in English?......Page 64
What is a structured language specification?......Page 65
What are use cases?......Page 66
What are user stories?......Page 67
What are informal and semiformal methods?......Page 68
What are some of the formal methods techniques?......Page 69
How are FSAs represented?......Page 70
Can you give an example of an FSM?......Page 71
Can you give an example of a Mealy machine?......Page 72
What are statecharts?......Page 73
What is the advantage of using statecharts over FSMs?......Page 74
What is a chain reaction?......Page 75
When are petri nets used in requirements analysis and specification?......Page 76
Are their drawbacks to the use of formal methods?......Page 77
What is structured analysis and structured design?......Page 80
Can you give an example of SA?......Page 81
When is it appropriate to use OOA vs. SA?......Page 82
Who uses the requirements documents?......Page 83
How do you represent specific requirements in the SRS?......Page 84
What does a traceability matrix look like?......Page 86
Are there special challenges when engineers specify software systems?......Page 87
What wording is appropriate in requirements specifications?......Page 88
What is requirements triage?......Page 89
How are requirements validated?......Page 90
How does the tool measure specification depth?......Page 91
3.8 Further Reading......Page 92
4.1 Introduction......Page 94
What are the principal activities of software design?......Page 95
Can modular design lead to separation of concerns?......Page 96
What is cohesion?......Page 97
What is coupling?......Page 99
How do I do Parnas partitioning?......Page 101
Can you give an example of Parnas partitioning?......Page 102
How does incrementality manifest in software design?......Page 103
What are some typical software architectures?......Page 104
How do I go from SA to SD?......Page 105
Can you give an example?......Page 107
What is a data dictionary?......Page 108
Are there any problems with SDs?......Page 109
Can I use FSMs to derive a design?......Page 110
What is OOD?......Page 111
The Liskov Substitution Principle......Page 112
How does the UML help us with software design?......Page 113
What is the UML 2.0?......Page 114
What are the benefits of patterns?......Page 115
What are the “GRASP” patterns?......Page 116
What are structural patterns?......Page 119
How do I achieve traceability from requirements through design and testing?......Page 120
4.6 Further Reading......Page 122
5.1 Introduction......Page 124
So how many programming languages are there?......Page 125
Then what are object-oriented languages?......Page 126
What do you mean by visible features of programming languages?......Page 127
What about global variables?......Page 128
Are there any drawbacks to recursive algorithm formulations?......Page 129
What is meant by “strong typing” in a programming language?......Page 130
Which languages have the best exception handling facilities?......Page 131
Do object-oriented languages support a form of modularity?......Page 132
Is Ada still used?......Page 133
C is my favorite programming language. When can it be used?......Page 134
When should C++ be used?......Page 135
What about Java?......Page 136
What are the differences between Java and C++?......Page 137
It’s pretty easy to learn an object-oriented language, isn’t it?......Page 138
What is a compiler?......Page 139
Can you describe further the compilation process?......Page 140
Do you have any debugging tips?......Page 141
Is there any way to automatically debug code?......Page 142
What is a source code control system?......Page 143
What are in-circuit emulators?......Page 144
What about other tools?......Page 145
What is the conditional logic code smell?......Page 146
What are data clumps?......Page 147
What are dubious constraints?......Page 148
What are lazy methods and lazy procedure?......Page 149
What is the one big loop code smell and how is it refactored?......Page 150
What are tell-tale comments?......Page 151
How can I improve the run-time performance of the code I write?......Page 152
What do coding standards look like?......Page 153
5.5 Further Reading......Page 154
6.1 Introduction......Page 156
What is software quality?......Page 157
What is the history of the CMM?......Page 158
What are the levels of CMM?......Page 159
What is CMM Level 2?......Page 160
What is CMM Level 4?......Page 161
How can my organization use the CMM?......Page 162
Are there “conventional” objections to using the CMM?......Page 163
What is ISO 9000?......Page 164
Are there any similarities between ISO 9000-3 and CMM?......Page 165
What is Six Sigma?......Page 166
How does ITIL help with software quality management?......Page 167
without triggering a slash-and-burn frenzy?......Page 168
What is the role of testing with respect to software quality?......Page 169
What is a good test?......Page 170
What is unit level testing?......Page 171
What is boundary value testing?......Page 172
Are there any disadvantages to black box testing?......Page 173
What is DU path testing?......Page 174
What is formal program proving?......Page 175
What is bottom-up testing?......Page 176
What kinds of interfaces can be tested?......Page 178
What kinds of errors can occur at the interfaces?......Page 180
How can clusters of cooperating objects be tested?......Page 181
What is beta testing?......Page 182
What is software fault injection?......Page 183
How do I write a test plan?......Page 184
What are some motivations for measurement?......Page 185
What is the delta lines of code metric?......Page 186
Can you help me visualize the cyclomatic complexity?......Page 187
What are Halstead’s metrics?......Page 188
What are the primary drivers for FPs?......Page 189
What are feature points?......Page 190
What are commonly used class level metrics?......Page 191
What are use case points?......Page 192
Can you give a simple example?......Page 193
What are recovery blocks?......Page 194
What are software black boxes?......Page 195
Should built-in-test software test memory?......Page 196
What is an appropriate model for software reengineering?......Page 197
Since you like models so much, can you give me a maintenance process model?......Page 198
What is software reuse?......Page 199
Are there special techniques for achieving reuse in procedural languages?......Page 200
What is the “Second System Effect?”......Page 201
6.7 Further Reading......Page 202
7.1 Introduction......Page 204
How does team chemistry involve software projects?......Page 205
What is Theory X?......Page 206
What is Theory W?......Page 207
What is Principle Centered Leadership?......Page 208
How do I deal with difficult people?......Page 209
The principle of job matching:......Page 210
I want to select the right people, but how is it done in the software industry?......Page 211
You don’t seem to like these tests. How do I assess the potential of a candidate besides checking references?......Page 212
How should I reference-check a potential hire?......Page 213
How do I manage agile development teams?......Page 214
What is a project?......Page 215
What does the software project manager control?......Page 216
How does the project manager put all of these control factors together?......Page 217
What is a work breakdown structure and why is it important to project tracking?......Page 218
What is a Gantt chart?......Page 219
How can the Gantt chart be used for ongoing project management?......Page 220
What are the steps in CPM planning?......Page 221
Can you illustrate the technique using the baggage inspection system?......Page 222
Are there any downsides to using PERT?......Page 223
What is basic COCOMO?......Page 225
What about the intermediate and detailed COCOMO models?......Page 226
What is the effort adjustment factor?......Page 227
What is COCOMO II?......Page 228
What is WEBMO?......Page 230
What is an example of a project ROI justification?......Page 231
What is NPV and how can I use it?......Page 232
What is an IRR?......Page 233
How can using PI suboptimize the decision?......Page 234
What is discounted payback?......Page 235
Is there a predictive model for the likelihood of any of these risks?......Page 236
Do you have any other advice about management risk in software projects?......Page 237
7.8 Further Reading......Page 239
What is OSS?......Page 241
What kinds of code can be found as open source?......Page 242
Who contributes to OSS systems?......Page 243
What is software evolution?......Page 244
How does software requirements engineering occur in OSS?......Page 245
What is software archeology?......Page 246
Can you give an example of an archeological study?......Page 247
What is outsourcing?......Page 252
To whom should you outsource?......Page 253
When should outsourcing be done and at what stage of the process?......Page 254
Do you have any rules of thumb for outsourcing and offshoring?......Page 255
What software process can be used for GSD?......Page 256
What are the challenges for GSD?......Page 257
8.5 Further Reading......Page 258
A.1.2 Scope......Page 260
Detention basin......Page 261
Wet well......Page 262
A.2.1 Wet Well Overview......Page 263
Pump Control Unit......Page 265
Control Display Panel......Page 266
A.2.3 Product Functions......Page 267
A.3.1 External Interface Requirements......Page 268
A.3.2.1 Pump Control Unit......Page 269
A.3.2.2 Control Display Panel......Page 270
A.3.2.5 Methane Sensor......Page 271
A.4 References......Page 272
B.1.2 Scope......Page 273
B.2.1 Wet Well Overview......Page 274
B.3.1 Class Model......Page 276
B.3.2.1 CWetWellSimulator......Page 280
B.3.2.3 CXmlData......Page 281
B.3.2.4 CWetWellSimulationData......Page 282
B.3.2.9 CMethaneState......Page 283
Methane Sensors Reliability......Page 286
Methane Sensor Reading Period......Page 287
B.3.2.14 CWaterSensorRelay......Page 288
B.3.2.16 CPumpSensor......Page 289
B.3.2.18 CVentilationState......Page 290
B.3.3 Sequence Diagram......Page 291
B.4 References......Page 293
Appendix C: Object Models for a Wastewater Pumping Station Wet Well Control System......Page 294




نظرات کاربران