තොරතුරු තාක්ෂණ කර්මාන්තයට වෙනත් කර්මාන්තවල මෙන් විශාල හා දෝෂ රහිත ව්‍යාපෘති ඉක්මනින් ලබා දිය නොහැක්කේ ඇයි?

නැෂනල් ජෝග්‍රැෆික් හි මෙගා ස්ට්‍රක්චර්ස් මාලාව නැරඹීමෙන් පසු , විශාල ව්‍යාපෘති කෙතරම් වේගයෙන් නිම කරනවාදැයි මා පුදුමයට පත් විය. මූලික වැඩ (සැලසුම්, පිරිවිතර ආදිය) කඩදාසි මත සිදු කළ පසු, දැවැන්ත ව්‍යාපෘති සාක්ෂාත් කර ගැනීම සඳහා වසර කිහිපයක් හෝ සමහර විට මාස කිහිපයක් ගතවේ .

උදාහරණයක් ලෙස එයාර් බස් ඒ 380 “නිල වශයෙන් 2000 දෙසැම්බර් 19 වන දින දියත් කරන ලදි” සහ “2005 මාර්තු මුලදී” යානය දැනටමත් අත්හදා බලා තිබුණි. දැවැන්ත තෙල් ටැංකි, අහස ගොඩනැගිලි ආදිය සඳහාද මෙයම වේ.

මෘදුකාංග කර්මාන්තයේ ප්‍රමාදයන් සමඟ සසඳන විට, බොහෝ තොරතුරු තාක්ෂණ ව්‍යාපෘති මෙතරම් මන්දගාමී වන්නේ මන්දැයි හෝ වඩාත් නිවැරදිව කිවහොත්, ප්‍රමාණවත් තරම් මිනිසුන්ට ලබා දී ඇති එකම පරිමාණයෙන් ඒවා වේගවත් හා දෝෂ රහිත විය නොහැක්කේ මන්දැයි මට කල්පනා කිරීමට උදව් කළ නොහැක.

එයාර් බස් ඒ 380 වැනි ව්‍යාපෘති දෙකම ඉදිරිපත් කරයි:

• බලාපොරොත්තු නොවූ ප්‍රධාන අවදානම්: මෙය ඉදිකරන ලද පළමු ගුවන් යානය නොවුනද, එය තවමත් තාක්‍ෂණයේ සීමාවන් තල්ලු කරන අතර කුඩා ගුවන් යානා සඳහා හොඳින් වැඩ කළ දේවල් භෞතික බාධාවන් නිසා විශාල ගුවන් යානයට වැඩ නොකරනු ඇත; ඒ හා සමානව, නව තාක්ෂණයන් තවමත් භාවිතා කර නොමැති අතර, උදාහරණයක් ලෙස 1969 දී බෝයිං 747 සිදු කරන විට ඒවා නොතිබුණි.

• පොදුවේ මානව සම්පත් හා කළමනාකරණයට අදාළ අවදානම්: ව්‍යාපෘතිය මැදින් ඉවත්ව යන පුද්ගලයින්, ඇය නිවාඩුවක් ගත කර ඇති නිසා පුද්ගලයෙකු වෙත ළඟා වීමට නොහැකි වීම, සාමාන්‍ය මානව දෝෂ ආදිය.

එම අවදානම් සමඟ, මිනිසුන් තවමත් ඉතා කෙටි කාලයක් තුළ එම විශාල ගුවන් යානා වැනි ව්‍යාපෘති සාක්ෂාත් කර ගන්නා අතර, බෙදා හැරීමේ ප්‍රමාදයන් නොතකා, එම ව්‍යාපෘති තවමත් ඉතා සාර්ථක හා උසස් තත්ත්වයේ ය.

මෘදුකාංග සංවර්ධනය සම්බන්ධයෙන් ගත් කල, ව්‍යාපෘති ගුවන් යානයක් තරම් විශාල හා සංකීර්ණ නොවේ (තාක්‍ෂණිකව හා කළමනාකරණය අනුව), සහ සැබෑ ලෝකයෙන් බලාපොරොත්තු නොවූ අවදානම් තරමක් අඩුය.

කෙසේ වෙතත්, බොහෝ තොරතුරු තාක්ෂණ ව්‍යාපෘති මන්දගාමී හා ප්‍රමාද වී ඇති අතර ව්‍යාපෘතියට වැඩි සංවර්ධකයින් එකතු කිරීම විසඳුමක් නොවේ (සංවර්ධකයින් දස දෙනෙකුගෙන් යුත් කණ්ඩායමක සිට දෙදහසක් දක්වා යාම සමහර විට ව්‍යාපෘතිය වේගයෙන් ලබා දීමට ඉඩ දෙනු ඇත, සමහර විට එසේ නොවේ, සමහර විට හානියක් වනු ඇත ව්‍යාපෘති කිරීම සහ එය කිසිසේත් අවසන් නොකිරීමේ අවදානම වැඩි කිරීම).

තවමත් ලබා දී ඇති ඒවා බොහෝ විට දෝෂ රාශියක් අඩංගු විය හැකි අතර, අඛණ්ඩව සේවා ඇසුරුම් සහ නිතිපතා යාවත්කාලීන කිරීම් අවශ්‍ය වේ (මුල් නිෂ්පාදනයේ ඇති දෝෂ හඳුනා ගැනීමට සහ ගුවන් යානය අනතුරට පත්වීම වැළැක්වීමට සතියකට දෙවරක් සෑම එයාර් බස් A380 මත "යාවත්කාලීන කිරීම් ස්ථාපනය කිරීම" සිතන්න).

එවැනි වෙනස්කම් පැහැදිලි කළ හැක්කේ කෙසේද? මහා පරිමාණ, දෝෂ රහිත නිෂ්පාදන ඉතා වේගයෙන් ලබා දීම සඳහා මෘදුකාංග සංවර්ධන කර්මාන්තයට එක් ව්‍යාපෘතියක දහස් ගණනක් කළමනාකරණය කිරීමට නොහැකි තරමට තරුණ වීම ඊට හේතුවද?

එඩ් යුවර්ඩන්ගේ මරණ මාර්තු මෙම මෙටා වර්ගයේ ප්‍රශ්න ගණනාවක් ස්පර්ශ කරයි.

පොදුවේ ගත් කල, මෘදුකාංග කර්මාන්තයට පහත සඳහන් දෑ විශාල ප්‍රමාණයක් නොමැති අතර එය විශාල ව්‍යාපෘති සඳහා මග පාදයි.

• ප්‍රමිතිකරණය සහ වැඩ අයිතම බිඳවැටීම.

  • මෙය නිසැකවම හොඳ අතට හැරී ඇත, නමුත් නිර්මාණ පද්ධතියක් තවමත් විශාල පද්ධතියක් බිඳ දැමිය නොහැක. යම් ආකාරයකින්, දී ඇති ව්‍යාපෘතියකට අවශ්‍ය දේ මෘදුකාංගයට පවා එකඟ විය නොහැක .
  • අභ්‍යවකාශය, ගොඩනැඟිලි ඉදි කිරීම, ස්වයංක්‍රීය යනාදිය. මෘදුකාංග තවමත් අනුරූප ප්‍රදේශවල අධික ලෙස ලේ ගැලීමට ඉඩ දෙයි.

• සාර්ථක, සමාන ව්‍යාපෘති විශාල ප්‍රමාණයක්. එයාර්බස් විසින් සාදන ලද පළමු විශාල ගුවන් යානය A380 නොවේ . එහි විශාල මෘදුකාංග යෙදුම් විශාල ප්‍රමාණයක් ඇත, නමුත් ඒවායින් බොහොමයක් කිසියම් අංශයකින් හෝ වෙනත් ආකාරයකින් නාටකාකාර ලෙස පීඩා විඳ ඇති අතර ඒවා “සාර්ථක” ලෙස හැඳින්වීමට ආසන්න නොවනු ඇත.

• සමාන හා සාර්ථක ව්‍යාපෘති ගණනාවක වැඩ කළ නිර්මාණකරුවන් සහ ඉදිකිරීම්කරුවන්ගේ විශාල මණ්ඩලයක්. සාර්ථක ව්‍යාපෘති ගැටලුවට අදාළව, එහි සිටි මානව කුසලතා නොතිබීම, පුනරාවර්තන දෘෂ්ටි කෝණයකින් දේවල් ඉතා අපහසු කරයි.

• එකම දේ දෙවරක් ගොඩනඟන්න. බොහෝ ආකාරවලින්, ගුවන් යානයක් වෙනත් ඕනෑම ගුවන් යානයකට සමානය. එයට පියාපත්, එන්ජින්, ආසන යනාදිය ඇත. විශාල මෘදුකාංග ව්‍යාපෘති කලාතුරකින් පුනරාවර්තනය වේ. සෑම OS කර්නලයක්ම සැලකිය යුතු ලෙස වෙනස් වේ. ගොනු පද්ධතිවල ඇති විෂමතාවය දෙස බලන්න. එම කාරණය සඳහා, සැබවින්ම අද්විතීය මෙහෙයුම් පද්ධති කීයක් තිබේද? විශාල ඒවා යම් අවස්ථාවක දී මූලික අයිතමයක ක්ලෝන බවට පත්වේ. AIX , Solaris , HP-UX , ... හෙරල්ඩ් නැවත AT&T System V වෙත . වින්ඩෝස් එක් එක් පුනරාවර්තනය හරහා ඇදහිය නොහැකි තරම් ඉදිරියට ඇදගෙන ගොස් ඇත. ලිනක්ස් ප්‍රභේද සාමාන්‍යයෙන් ලිනස් ආරම්භ කළ එකම හරයට යයි. මම එය ගෙන එන්නේ, ප්‍රභේද සැබවින්ම අද්විතීය, හිමිකාර මෙහෙයුම් පද්ධති වලට වඩා වේගයෙන් ප්‍රචාරණය කිරීමට නැඹුරු වන බැවිනි.

• සැබවින්ම නරක ව්‍යාපෘති ඇස්තමේන්තු කිරීම. පුනරාවර්තන හැකියාව ඉතා අඩු බැවින්, එය කෙතරම් විශාලද යන්න සහ යමක් සෑදීමට කොපමණ කාලයක් ගතවේද යන්න ප්‍රක්ෂේපණය කිරීම දුෂ්කර ය. ව්‍යාපෘති කළමණාකරුවන්ට සහ කළමනාකාරිත්වයට කේතය මත අත තබා ඇත්ත වශයෙන්ම සිදුවන්නේ කුමක්දැයි බැලීමට නොහැකි බැවින්, කාල නියමයන් පිළිබඳ යථාර්ථවාදී නොවන අපේක්ෂාවන් ජනනය වේ.

• QA / QC විශාල ව්‍යාපෘති සඳහා විය හැකි හෝ විය යුතු තරම් දැඩි ලෙස අවධාරණය නොකෙරේ. මෙය සංරචක අතර ලිහිල් අතුරුමුහුණත් ඇති අතර සංරචක ක්‍රියා කළ යුතු ආකාරය පිළිබඳ දෘඩ පිරිවිතරයන් නොමැත. එම ලිහිල් භාවය අනපේක්ෂිත ප්‍රතිවිපාක සහ දෝෂ ඇතිවීමට ඉඩ සලසයි.

• නිරන්තරයෙන් මැනිය හැකි සුදුසුකම්. පොදුවේ ගත් කල, මිනිසුන් X භාෂාවෙන් හෝ ක්‍රමලේඛනයේ වැඩ කළ වසර ගණන ගැන කතා කරයි. නිපුණතාවයේ ගුණාත්මකභාවය හෝ ගුණාත්මකභාවය සඳහා ආදේශකයක් ලෙස කාලය භාවිතා වේ. කලින් සඳහන් කර ඇති පරිදි, සම්මුඛ සාකච්ඡා කිරීම සහ හොඳ ක්‍රමලේඛන කුසලතා සොයා ගැනීම දුෂ්කර ය. ගැටලුවේ කොටසක් නම් “හොඳ” යන්නෙහි අර්ථ දැක්වීම ඉතා ආත්මීය ය.

මම සියල්ලම නිෂේධාත්මක යැයි අදහස් නොකෙරේ, මම සිතන්නේ මෘදුකාංග කර්මාන්තය අප සිටි තැන සිට සැලකිය යුතු ප්‍රගතියක් ලබා ඇති බවයි. නිර්මාණ මූලධර්ම පිළිබඳ සංවාදය සහ සාකච්ඡාව ප්‍රවර්ධනය කිරීමට මෙවැනි සංසද සහ වෙනත් අය සැබවින්ම උදව් කර ඇත. මෘදුකාංග ඉංජිනේරුවන් සඳහා “මූලික” දැනුම ප්‍රමිතිකරණය කිරීමට කටයුතු කරන සංවිධාන තිබේ. වැඩිදියුණු කිරීම සඳහා නිසැකවම ඉඩක් ඇත, නමුත් මම සිතන්නේ කර්මාන්තය සෑහෙන කෙටි කාලයක් තුළ බොහෝ දුරක් පැමිණ ඇති බවයි.

පිළිතුර පුදුම හිතෙන ඉතා සරළ ය: ඒ 'අනෙක් කර්මාන්ත' කරන්නද ඉහළ අසාර්ථක අනුපාතය ඇත. අපි වැරදි දේවල් සංසන්දනය කරනවා. මෘදුකාංග ලිවීම බොහෝ විට 'ගොඩනැගීම' ලෙස හැඳින්වේ, එබැවින් අපි එය වෙනත් කර්මාන්තවල නිෂ්පාදන හෝ ඉදිකිරීම් අදියර සමඟ සංසන්දනය කරමු. නමුත් ඔබ එය දෙස බැලුවහොත් එය කිසිසේත්ම ඉදිකිරීමක් නොවේ: එය නිර්මාණයකි . මෘදුකාංග සැලසුම් කේතයෙන් ලියා ඇති අතර ගොඩනැගීම සිදු කරනු ලබන්නේ මෘදුකාංග සම්පාදනය කිරීමෙන් හෝ පියාසර කරන විට කෙලින්ම අර්ථ නිරූපණය කිරීමෙනි.

වෙනත් කර්මාන්තවල බොහෝ මෝස්තර එක්කෝ මුලින් ඇස්තමේන්තු කර ඇති කාලයට වඩා වැඩි කාලයක් ගත වේ, පිරිවැය වැඩියෙන් වැඩිය, නැතහොත් කිසි විටෙකත් නිම කිරීමක් නොපෙනේ. හුරුපුරුදුද?

ඉතින්, අපි මෘදුකාංග සැලසුම් කිරීමේදී අප කරන්නේ කුමක්ද? හොඳයි, අපි තවමත් සැලසුම් කරමින් සිටිමු, නමුත් මුල් අවධියේදී.

මෘදුකාංගයේ, සටහන් කිරීමේ නිෂ්පාදන රේඛාවක් නොමැත. අවසාන සංරචකය තැනීම (සාපේක්ෂව) ලාභදායී වන අතර, එම අවසාන නිෂ්පාදනයේ අනුරූකරණය පරිපූර්ණ හා free ලදායී ලෙස නොමිලේ වේ - ඔබ ගොඩනංවන කෞතුක වස්තු පිටපත් කරයි.

සමහර සංඛ්‍යා පෙන්වා දීමට:

1. ක්‍රියාත්මක කිරීම ආරම්භ කිරීමෙන් පසු අවශ්‍යතා වෙනස් කිරීම ; උදාහරණයක් ලෙස කර්මාන්ත ශාලාවේ පළමු එයාර් බස් ඒ 380 යානය නිර්මාණය කිරීමට පටන් ගත් විට යමෙකුට තවත් ආසන 200 ක් අවශ්‍ය නම් ඒවා එහි තබනු ඇතැයි මට විශ්වාස කළ නොහැකිය. නමුත් විශාල මෘදුකාංග ව්‍යාපෘතියක ක්‍රමලේඛකයින් සංවර්ධනය ආරම්භ කළ පසුවත් තවත් වර්ග 5 ක පරිශීලකයින් එක් කළ හැකිය.
2. සංකීර්ණත්වය - විශාල මෘදුකාංග ව්‍යාපෘති අතිශයින්ම සංකීර්ණ ය; මානව වර්ගයා විසින් නිර්මාණය කරන ලද සහ සංවර්ධනය කරන ලද වඩාත් සංකීර්ණ ව්‍යාපෘති විය හැකිය;
3. ගෘහ නිර්මාණ ශිල්පය සහ සැලසුම් අවධිය සඳහා ප්‍රමාණවත් සම්පත් වැය නොකෙරේ ;
4. ක්ෂේත්‍ර පරිණතභාවය - මෘදුකාංග ඉංජිනේරු විද්‍යාව අනෙකුත් ඉංජිනේරු සහෝදරියන් හා සසඳන විට සාපේක්ෂව තරුණ විනයකි; මෙයට ඇඟවුම් දෙකක් ඇත: අ) එතරම් ur ෂධ හා හොඳ භාවිතයන් නොමැත; ආ) එතරම් පළපුරුදු විශේෂ ists යින් නොවේ;
5. ගණිතමය සාක්‍ෂි නොමැතිකම - බොහෝ අවස්ථාවන්හිදී මෘදුකාංග කෑල්ලක් අවශ්‍ය පරිදි ක්‍රියාත්මක වන බව ඔප්පු කිරීමට ගණිතමය විධිමත් ක්‍රම භාවිතා නොකෙරේ; ඒ වෙනුවට පරීක්ෂා කිරීම භාවිතා කරයි. ගණිතය මත වැඩි වශයෙන් රඳා පවතින වෙනත් ඉංජිනේරු ක්ෂේත්‍රවල මෙය සත්‍ය වේ. මෙයට හේතුව සංකීර්ණ ය;
6. කඩිමුඩියේ - බොහෝ කළමනාකරුවන්ට අත් කරගත නොහැකි කාලසීමාවන් ඇත; එබැවින් අවසාන දිනය නිසා කේතයේ ගුණාත්මකභාවය දෙවන ස්ථානයට පත් වේ.

ප්‍රශ්නයට තදින් පිළිතුරු සැපයීම - අනෙක් අයට ක්‍රමලේඛකයින්ගෙන් ඉතා ඉහළ අපේක්ෂාවන් (විශේෂයෙන් බෙදා හැරීමේ වේලාවේදී) ඇති බවත්, විශාල මෘදුකාංග ක්‍රමලේඛනය කිරීම කොතරම් දුෂ්කර දැයි හරියටම නොතේරෙන බවත් මම විශ්වාස කරමි.

ප්‍රශ්නයේ පරිශ්‍රය ටිකක් දෝෂ සහිතය. A380 සහ බෝයිං 787 යන දෙකම වසර ගණනාවක් ප්‍රමාද වී ලබා දෙන ලදී.

A380 සම්බන්ධයෙන් බොහෝ ප්‍රමාදයන් සිදුවී ඇත්තේ CATIA සැලසුම් මෘදුකාංගයේ වෙනස් හා තරමක් නොගැලපෙන අනුවාදයන් භාවිතා කරමින් එයාර් බස් හි ප්‍රංශ සහ ජර්මානු ඒකක විසිනි . මෙය නොගැලපෙන ලෙස පෙන්නුම් කළේ ගුවන් යානයට නොගැලපෙන රැහැන් පටි ලෙස ය.

වැඩිපුරම භාවිතා වන ගුවන් යානා සැලසුම් මෘදුකාංගය වන CATIA හි කිසිදු වරදක් නොතිබුණි, නමුත් කවුරුහරි කොතැනක හෝ මෘදුකාංග වින්‍යාස කිරීමේ පන්දුව අතහැර දැමීය.

බෝයිං 787 මෘදුකාංග සම්බන්ධ ප්‍රමාදයන්ගෙන් ද පීඩා වින්දා, නමුත් එහි බොහෝ ගැටලු වූයේ බර පාලනය කිරීම සහ ප්‍රමිතියෙන් තොර කොටස් සැපයුම්කරුවන් විසින් ලබා දීම වැනි සාම්ප්‍රදායික නව ගුවන් යානා ගැටළු ය.

ආරම්භක ගුවන් යානයට ව්‍යුහාත්මක ගැටලු ඇති වූ පසු A380 සහ B787 යන දෙකටම ඔවුන්ගේ පියාපත් මෝස්තර වෙනස් කිරීමට සිදුවිය.

සෑම ක්ෂේත්‍රයකම විශාල සංකීර්ණ ව්‍යාපෘති මිනිසුන්ට අපහසුය.

අහස උසට කොල්ලෙක්. මට ඔබේ ප්‍රශ්නයට පිළිතුරු දිය හැකිදැයි විශ්වාස නැත, නමුත් මට ත්‍රෙඩ් එකේ විවිධ අයිතමවලට යම් ආලෝකයක් ලබා දිය හැකිය. ගොඩනැගිලි ඉතා වේගයෙන් සිදුවේ. ප්‍රධාන බාධකයක් වන්නේ පෙදෙසි (රෙගුලාසි) ය. නමුත් පොදුවේ ගත් කල උස ගොඩනැගිල්ලක් ආරම්භයේ සිට අවසානය දක්වා වසර 3 සිට 10 දක්වා ගත වේ.

මම හිතන්නේ නව ගොඩනැගිල්ලක් නව මෘදුකාංග ව්‍යාපෘතියක් සමඟ සංසන්දනය කිරීම එතරම් නිවැරදි නොවේ. නව ගොඩනැගිල්ලක් කර්නලයේ හෝ මෙහෙයුම් පද්ධතියේ නව අනුවාදයකට සමීප වේ. මේ සම්බන්ධයෙන් මෘදුකාංග සංවර්ධනය වඩා වේගවත් ය. සේවාදායකයා කිසි විටෙකත් ලියාපදිංචි නොවන ඉහළ අවදානම් කාර්යයක් වන බැවින් අපි කිසි විටෙකත් බිංදුවෙන් ගොඩනඟන්නේ නැත. ගොඩනැගිලිවල බොහෝ සැලසුම් සහ සංවර්ධනය ඔප්පු කර අවසන් කරන ලද ව්‍යාපෘති වල ව්‍යුත්පන්නයයි.

පුද්ගලික අත්දැකීම් වලින් මෙතෙක් ගොඩනඟා ඇත්තේ ව්‍යාපෘති දහයෙන් එකක් පමණි. මෙම ක්‍රියාවලිය සැලසුම් මත පදනම් වූවාට වඩා සංවර්ධනය මත පදනම් වූවකි, එබැවින් වානේ මිල වැනි දෙයක් ඉහළ යන මොහොතේ මුළු ව්‍යාපෘතියම ජනේලයෙන් පිටත හෝ සැලසුම් කර ඇත.

සැලසුම් කිරීම සඳහා සංකල්පයට ක්‍රමානුකූලව මාසයක්, සංවර්ධනය සැලසුම් කිරීම සඳහා මාස දෙකේ සිට හය දක්වා, ගෘහ නිර්මාණ ශිල්පීන්, සැලසුම් උපදේශකයින්, ව්‍යුහාත්මක ඉංජිනේරුවන්, සුළං ඉංජිනේරුවන්, සේවා ඉංජිනේරුවන්, ප්‍රමාණ හා පිරිවැය උපදේශකයින්, මිනින්දෝරුවන්, කණ්ඩායමක් විසින් විස්තර සහ ඉදිකිරීම් ලේඛන සඳහා තවත් මාස හයක් ගත වේ. ප්‍රවේශ්‍යතා ඉංජිනේරුවන් සහ ලැයිස්තුව දිගටම ...

අතථ්‍ය හා භෞතික යන තර්කය ඉතා නිවැරදි නොවේ. අපි ප්‍රධාන වශයෙන් අථත්ය මෙවලම් සමඟ වැඩ කරන අතර, එපමනක් නොව, අපගේ අවසාන නිෂ්පාදනයේ සිට කාලය හා පරිමාණයෙන් දුරස්ථව සිටිමු. බොහෝ අවස්ථාවන්හීදී අපට මොක්අප් පරිමාණයෙන් ගොඩනැගිලිවල අංශ පරීක්ෂා කිරීමට පවා නොහැකි අතර කුමක් සිදුවිය හැකිදැයි පුරෝකථනය කිරීමට අපි අනුකරණයන් භාවිතා කරමු.

සංකීර්ණත්වය අනුව වෙනස්කම් ඇත, නමුත් සමස්තයක් වශයෙන් එය සමාන විය හැකිය. අප අතර අන්තර් සම්බන්ධිත ඒකක සහ බහුවිධ මට්ටම්වල වියුක්ත කිරීම් සහ අතුරුමුහුණත් ඇතිවා පමණක් නොව, සන්නිවේදනය ඉතා අපහසු වන ක්‍රියාවලියේ කුඩා කොටස් පිළිබඳව මිනිසුන් විශේෂ specialized යෝ වෙති.

සැලසුමට එදිරිව සංවර්ධනය පිළිබඳ තර්කය සම්බන්ධයෙන් ගත් කල, මම සිතන්නේ ක්‍රියාවලි දෙකම සැලසුම් වලින් නිමවා ඇති බවයි. මේවා වෙන් කර තබා ගැනීම ශාස්ත්‍රීය වශයෙන් සතුටක් බව පෙනේ, නමුත් දේවල් ක්‍රියාත්මක වන්නේ කෙසේදැයි ඔබ නොදන්නේ නම් එය සැලසුම් කළ නොහැක. ඔබ අසමත් වීමේ අවදානම වැඩි කරයි.

OP හි ප්‍රශ්නයට අනුව සමස්තයක් වශයෙන් මගේ (වැරදි විය හැකි) තක්සේරුව නම් ක්‍රමලේඛනය ඉංජිනේරු විද්‍යාවට වඩා කලාවක් බවයි. මිනිසුන් සතුටින් හා නොමිලේ එය කරන්නේ ඇයි, එහි ප්‍රකාශනය සහ අලංකාරය සොයා ගන්නේ ඇයි? පරිගණක විද්‍යාව යනු (ටින් එකේ මෙන්) ඉංජිනේරු විද්‍යාවට වඩා විද්‍යාවකි. පවතින කොටස් එකට ඇලවීම වෙනුවට ඇල්ගොරිතම ඔප්පු කිරීමට ඔබ උත්සාහ කරන්නේ ඇයි? මෙය කිසියම් තේරුමක් තිබේදැයි විශ්වාස නැත; මම මෘදුකාංග කාරයෙක් නොවේ.

මෘදුකාංග නිර්මාණය හා සංවර්ධනය සමඟ මට පහර දෙන එක් අංගයක් වන්නේ මාධ්‍යය ගැනම ය. පරිගණක මානව කේන්ද්‍රීය කාර්යයන් ඉතා අස්වාභාවික කරයි. සෑම දෙයක්ම ඉතා පැහැදිලිව පෙනෙන අතර ඉවසීම් ස්වල්පයක් ඇත. මේ සඳහා ඔබේ මාර්ගය මානසිකව වැඩ කිරීම අසීරු වන අතර සමහරු සංකීර්ණත්වය තුරන් කිරීමෙන් එයින් ගැලවී යති. වෙන කිසිවක් නොමැති නම් මෙයට යම් සම්බන්ධයක් තිබිය හැකිද?

එසේ නම් ඒවා සැලසුම් කිරීමට කොපමණ කාලයක් ගතවේද? වසර? දෙක? අවුරුදු දහයක්? සැලසුම යනු යමක් තැනීමේ වඩාත් සංකීර්ණ කොටසයි, ඉදිකිරීමම පහසුය.

මෙම ලිපිය මත පදනම්ව , මෘදුකාංග සංවර්ධනය බොහෝ දුරට සැලසුම් ක්‍රියාවලියක් වන අතර එය නිර්මාණ ලේඛනය ප්‍රභව කේතයම වේ. සැලසුම් ක්‍රියාවලිය නිෂ්පාදන ක්‍රියාවලියට වඩා සම්පූර්ණයෙන්ම වෙනස් ය. එයට පළපුරුදු පුද්ගලයින් අවශ්‍ය වන අතර සැලසුම් කිරීමට අපහසුය, මන්ද කුඩා අවශ්‍යතා වෙනස්වීම් පවා ව්‍යාපෘතියේ සමස්ත ගෘහ නිර්මාණ ශිල්පයේ විශාල වෙනස්කම් ඇති කළ හැකිය. සුළං උමං මාර්ගවල ගුවන් යානා ආකෘති පරීක්‍ෂා කරනවා සේම, අවසාන සැලසුම් ලේඛනය ලෙස කේතයේ ගුණාත්මකභාවය වැඩි දියුණු කිරීම සහ සැලසුම් ක්‍රියාවලියේ කොටස් ලෙස පරීක්ෂණ සහ නිදොස්කරණය කිරීම කෙරෙහි අවධානය යොමු කරන කඩිනම් ක්‍රමවේදයන් සඳහා මෙම අවබෝධය පදනම වේ .

ඉදිකිරීම් සම්පාදකයින් විසින් ස්වයංක්‍රීයව හසුරුවනු ලැබේ. ඊට ස්තූතිවන්ත වන්නට, මිනිත්තු කිහිපයකින් සම්පූර්ණ නිෂ්පාදන ගොඩනගා ගැනීමට අපට හැකි වේ.

මෘදුකාංග ව්‍යාපෘති විශාල ප්‍රමාදයකින් හා උද්ධමනයකින් යුතුව නිම කිරීමට හේතුව කළමනාකරුවන් තවමත් එවැනි සැලසුම් ක්‍රියාවලියක් තක්සේරු කිරීමට, පුරෝකථනය කිරීමට හා සැලසුම් කිරීමට හැකි යැයි සිතන බැවිනි. මෙය ඇත්ත වශයෙන්ම වලංගු වනවාට වඩා බොහෝ විට පසුබසිනු ඇත. ඔවුන් තවමත් සිතන්නේ දෘඩ ඉදිකිරීම් ක්‍රියාවලියකට මිනිසුන් බැඳ තැබීමෙන් ඔවුන්ට කෙසේ හෝ ගුණාත්මක භාවය ඉහළ නැංවිය හැකි වුවද අවසාන ප්‍රති result ලය වැඩි වශයෙන් පිරිවැය හා නියමිත දින නියමයන් සමඟ ප්‍රතිවිරුද්ධ බවයි.

එයාර්බස් ඒ 380 යානයේ සැලසුම මධ්‍යයේ යමෙකු රැස්වීමක නළා "හෙහ්, එය ත්‍රිත්වයක් ලෙස ගොඩනගා ගත හැකිද?" තවත් සමහරු එකතු වී, "ඔව්, ඔව්, ත්‍රිත්වයක්. තවත් පියාපත් වඩා හොඳයි" A380 සැලසුම ත්‍රිත්වයක් බවට පත් කිරීම සඳහා ඊළඟ වසර ගත වේ. තවත් රැස්වීමකදී යමෙක් කියනවා, "ත්‍රිත්වයක්? එය පරණයි. අපට බයිප්ලේන් එකක් අවශ්‍යයි. එක් පියාපත් ඉවත් කරන්න."

නැතහොත් සිතන්න, පාලම් ඉදිකිරීමේ ව්‍යාපෘතියක් මධ්‍යයේ යමෙක් කියනවා, "හෙහ්, අපි නැව් සමාගමක් සමඟ ගනුදෙනුවක් කළා. ඔවුන්ට පාලම තවත් අඩි 40 ක් උස විය යුතුයි, මන්ද ඔවුන්ගේ නැව් වඩා උසයි. එය සවි කරන්න. ස්තූතියි. . "

විශාල හා කුඩා මෘදුකාංග ව්‍යාපෘති භයානක අනුපාතයකින් අසාර්ථක වීමට හේතු කිහිපයක් මේවා වේ.

තොරතුරු තාක්ෂණයේ වැඩ කරන යාන්ත්‍රික ඉංජිනේරු පසුබිමක් ඇති අයෙකු ලෙස, මම බොහෝ විට කල්පනා කළේ තොරතුරු තාක්ෂණයේ සාර්ථකත්ව අනුපාතය අඩු වීමට හේතු ගැන ය.

මෙම ත්‍රෙඩ් එකේ අනෙක් අය ලෙස, තොරතුරු තාක්ෂණයේ අසමතුලිතතාවය, සවිස්තරාත්මක ප්‍රමිතීන් නොමැතිකම (ඔව් මම බැරෑරුම් ය, සරල බෝල්ට් එකක සම්මත පත්‍රය ඔබ කවදා හෝ පරීක්ෂා කර තිබේද?) සහ ප්‍රමිතිගත නොවීම යන හේතු නිසා මම බොහෝ විට ආරෝපණය කර ඇත්තෙමි. සංරචක සහ මොඩියුල.

ගොඩනැඟිලි ඉදිකිරීම හෝ නැව් තැනීම වැනි වෙනත් කර්මාන්තවලට ද “පරාජිත මාවත්” ඇත: විශේෂිත විසඳුම් මූලාකෘතියක දැනුම සහ පළපුරුද්ද - අභිමතකරණය කළ ස්වරූපයෙන් - නැවත නැවතත් භාවිතා කරයි. විවිධ ප්‍රමාණයේ සහ අරමුණු සහිත ගොඩනැගිලි, නැව් හෝ ගුවන් යානා කෙසේ හෝ මෙතරම් සමාන වන්නේ මන්දැයි ඔබ කවදා හෝ කල්පනා කර තිබේද? (ඇත්ත වශයෙන්ම රීතියට ව්‍යතිරේක පවතී ...)

එයට හේතුව එම මූලාකෘති හොඳින් පර්යේෂණය කර, හොඳින් වටහාගෙන, සාමාන්‍යයෙන් භාවිතා වන අතර ඔප්පු කළ වාර්තාවක් ඇති බැවිනි. එය වෙනත් ආකාරයකින් කළ නොහැකි නිසා නොවේ. තොරතුරු තාක්‍ෂණ ප්‍රමිතිකරණයේදී කලාතුරකින් සිදු වන්නේ: (විශාල) ව්‍යාපෘති මඟින් සංරචක නැවත ප්‍රතිනිර්මාණය කිරීමට නැඹුරු වන අතර, එකම වේලාවක සහ එකම පුද්ගලයින් සමඟ පර්යේෂණ හා බෙදා හැරීම් සිදු කරයි !

මේවා නොවැලැක්විය හැකි ලෙසම එකවර නිෂ්පාදනය කිරීමට හේතු වන අතර ඒවා සංවර්ධනය කිරීම හා සේවය කිරීම සඳහා මිල අධික වන අතර ඒවා දෝෂ සහිත වන අතර අවිනිශ්චිත තත්වයන් යටතේ අනපේක්ෂිත ආකාරයකින් අසමත් වේ. මේ නිසා, ඇත්ත වශයෙන්ම, මෙම නිෂ්පාදන වඩා ඉක්මණින් යල්පැන ඇති, ලියා ඒවා සමානව විශාල පිරිවැයකින් ප්‍රතිස්ථාපනය කර තරමක් හොඳ ඒවා පමණක් ඇත. තොරතුරු තාක්ෂණයට අවශ්‍ය වන්නේ කාර්මික විප්ලවයට සමාන වන අතර එය මැදිවියේ ශිල්පීන් කාර්යක්ෂම කර්මාන්තශාලා බවට පත් කළේය.

කෙසේ වෙතත් තොරතුරු තාක්‍ෂණය සැබවින්ම අද්විතීය වන සාධක තිබේ. සඳහන් කළ අනෙකුත් කර්මාන්තවලට සාපේක්ෂව තොරතුරු තාක්‍ෂණය සැබවින්ම සර්වසම්පූර්ණ ය: එය අපගේ නූතන ජීවිතයේ සෑම අංශයකම භාවිතා වේ . එබැවින් එය කුඩා ප්‍රාතිහාර්යයක් වන අතර තොරතුරු තාක්ෂණය මෙතරම් ප්‍රගතියක් ලබා ඇති අතර එහි ප්‍රති results ල ලබා දීමට හැකියාව ඇත.

ඔබගේ ප්‍රකාශයට මා එකඟ නොවන බවට මම බිය වෙමි.

එයාර් බස් සහ බෝයිං යනු ගුවන් යානා තැනූ සමාගම් සඳහා උදාහරණ දෙකකි. ගුවන් යානා සාදන සමාගම් කීයක් තිබේද? සමාගම් කීයක් මෘදුකාංග සාදන්නේද යන්න ඔබ සැසඳුවහොත් ඉතා ස්වල්පයක් පමණි.

මෘදුකාංග ව්‍යාපෘතියක් ඉස්කුරුප්පු කිරීම සඳහා ගුවන් යානා ව්‍යාපෘතියක් ඉස්කුරුප්පු කිරීම සමානව පහසුය. මෘදුකාංග කර්මාන්තයේ මෙන් ගුවන් යානා තැනීමේ කර්මාන්තය තුළ පිවිසුම් බාධකය එතරම් අඩු මට්ටමක පැවතියේ නම්, බොහෝ අසාර්ථක ගුවන් යානා ව්‍යාපෘති ඔබට නිසැකවම පෙනෙනු ඇත.

කාර් දෙස බලන්න; ඉතා කල් පවතින හා ඉතා දියුණු මෝටර් රථ නිපදවන උසස් තත්ත්වයේ නිෂ්පාදකයින් සිටින බව සිතන්න (ලෑන්ඩ් රෝවර්, මර්සිඩීස් සිතන්න) සහ ඒවා අලුත්වැඩියා නොකර වසරක් නොපවතින කාර් නිපදවන අය සිටිති (කියියා හෝ චෙරි සිතන්න). තරමක් දුර්වල පිවිසුම් බාධකයක් ඇති කර්මාන්තයකට මෙය කදිම නිදසුනකි, ඔබ දුර්වල ක්‍රීඩකයන් ඇති කර ගැනීමට පටන් ගත්තා නම්.

මෘදුකාංග වෙනස් නොවේ. ඔබ සතුව දෝෂ සහිත නිෂ්පාදන රාශියක් ඇත, අනෙක් අතට, වින්ඩෝස්, ඔෆිස්, ලිනක්ස්, ක්‍රෝම් හෝ ගූගල් සෙවුම ඉතා උසස් තත්ත්වයේ ව්‍යාපෘති වන අතර ඒවා නියමිත වේලාවට ලබා දෙන ලද අතර ගුවන් යානයකට සමාන ගුණාත්මක මට්ටමක් ඇත.

බොහෝ දෙනෙකුට මග හැරෙන අනෙක් කරුණ නම්, අප ජීවිතයේ සත්‍යයක් ලෙස සලකන මෝටර් රථයක්, ටැංකියක් හෝ ගුවන් යානයක් නඩත්තු කිරීම සඳහා කොපමණ නඩත්තු කිරීමක් සිදු වේද යන්නයි. සෑම ගුවන් යානයක්ම ගුවන් ගත වීමට පෙර තාක්ෂණික පරීක්‍ෂණයකට භාජනය කළ යුතුය. සෑම සැතපුම් කිහිපයකට වරක් ඔබේ මෝටර් රථය පරීක්ෂා කර බලා තෙල් වෙනස් කිරීම, ටයර් වෙනස් කිරීම වැනි සාමාන්‍ය දේවල් කරන්න.

මෘදුකාංගයටද එය අවශ්‍ය වේ. යාන්ත්‍රික / භෞතික නිෂ්පාදන සමඟ කරන ආකාරයටම රෝග විනිශ්චය, වැළැක්වීම හෝ විගණනය කිරීමේ මෘදුකාංගයේ තත්වය සහ ගුණාත්මකභාවය සඳහා මිනිසුන් වැඩි කාලයක් ගත කළේ නම්, මම බලාපොරොත්තු වන්නේ මෙවැනි ප්‍රකාශයන් අඩු බවයි. ඔබ ඔබේ යෙදුමේ ලොග් දියත් කිරීමට පෙර සෑම විටම එය කියවනවාද? හොඳයි .. එය ගුවන් යානයක් නම් ඔබට කළ යුතුව ඇත්තේ ;-)

ඩිජිටල් ගොඩනැඟිලි කොටස් 1 හෝ 0 විය හැකිය.

යාන්ත්‍රික සැලසුමකට ඉවසීමේ මට්ටමක් ඇත. මට පරිපූර්ණ රිවට් එකකට වඩා අඩුවෙන් පාලමකට දැමිය හැකි අතර එය බොහෝ විට පහළට වැටෙන්නේ නැත, කෙසේ වෙතත්, කේතයෙන් එක් වරක් පමණක් 0 ක් තැබූ විට 1 ක් තිබිය යුතු අතර එය මුළු වැඩසටහනම අසමත් විය හැකිය.

පරිගණනයේ තාර්කික හා අන්තර්ක්‍රියාකාරී ස්වභාවය නිසා ඕනෑම කුඩා වෙනස්කම් පවා දරුණු ලෙස අසාර්ථක වීමට හේතු වේ.

මම බොහෝ විට එකම දේ ගැන කල්පනා කර ඇත්තෙමි. අප කරන දේ ගැන කිසිම අදහසක් නැති ආධුනිකයන් සමූහයක් මෙන් එය නිසැකවම දැනේ . කළමනාකරුවන්ට හෝ වෙනත් බාහිර සාධක වලට දෝෂාරෝපණය කරන පැහැදිලි කිරීම් වලට මම අකමැතියි - අප විසින් නිර්මාණය කරන දෙයට සංවර්ධකයින් අප වගකිව යුතුය.

මම හිතන්නේ අපි ඉන්නේ දෝෂ සහිත ව්‍යාපාරයක . අහස උසට නැගීම හෝ විකුණන සෑම ජංගම දුරකථනයක්ම සිහිපත් කිරීම හා සැසඳීමේදී මෘදුකාංග පැච් කිරීම ලාභදායී වේ.

දෝෂ එදිනෙදා ජීවිතයේ කොටසක් වන සංස්කෘතියක් මෙය නිර්මාණය කර ඇත . ඒවා පිළිගැනීමකින් පිළිගනු ලැබේ. සමහර දෝෂ වැළැක්විය නොහැකි වුවත්, ඒවා අපගේ එදිනෙදා වැඩ වල ආධිපත්‍යය දැරිය යුතුද ? QA කරදරයට වටිනවා යැයි හැඟෙන්නේ නැති කළමනාකරුවන් මට සම්පූර්ණයෙන්ම වැටහෙයි, හරියටම ඔවුන් කෙසේ හෝ දෝෂ අපේක්ෂා කරන බැවිනි. දෝෂ රහිත කේතයක් නිපදවීමට සෑම උත්සාහයක්ම නොගන්නා ක්‍රමලේඛකයින් මට තේරෙන්නේ නැත, මන්ද දෝෂ නිවැරදි කිරීම නිරය ලෙස කම්මැලි ය.

සාරාංශයක් ලෙස එය සංස්කෘතික ගැටලුවක් යැයි මම විශ්වාස කරමි, එය වෙනස් වනු ඇතැයි මම බලාපොරොත්තු වෙමි.

ඉංජිනේරු ප්‍රමිතීන් සහ භාවිතයන් අභ්‍යවකාශයට වඩා තොරතුරු තාක්ෂණයේ (ස්වාධීන කර්මාන්තයක් ලෙස) බෙහෙවින් වෙනස් ය . අභ්‍යවකාශයේදී තොරතුරු තාක්‍ෂණය සඳහා ප්‍රමිති ලේඛන හමු වූ විට තොරතුරු තාක්‍ෂණ වෘත්තිකයන් ප්‍රතික්‍රියා කරන ආකාරය සලකා බැලීමෙන් මෙය වඩාත් පහසුවෙන් වටහා ගත හැකිය . නිදසුනක් ලෙස, මෑත කාලවලදී අන්තර්ජාලය පුරා ගමන් කර ඇති ඒකාබද්ධ වැඩ වර්ජන සී ++ ප්‍රමිති .

බොහෝ අය කම්පා වීම හෝ නුවණැති ඉල්ලා අස්වීම ප්‍රකාශ කරති (අපට එසේ කළ හැකි යැයි සිතමු); පාරිභෝගික නිෂ්පාදන මේ ආකාරයෙන් ලබා දීමට ප්‍රායෝගික ක්‍රමයක් නොමැති බව පවසමින් බොහෝ දෙනෙක් සමච්චලයට ලක් කරති. පාරිභෝගිකයින්ගේ නොව කළමනාකරණයේ අපේක්ෂාවන්ට අනුව මෙය නිවැරදි විය හැකිය. කිසිවක් නිරූපණය නොකොට සති කිහිපයක් කේත කර කේත කරන කේත රචකයන් කෙරෙහි විශාල අවිශ්වාසයක් පවතී. සති දෙකක් සඳහා යමක් නිර්මාණය කරන කෝඩරයට දෙවියන් වහන්සේ උදව් කරයි . ගුවන් යානා සම්බන්ධයෙන් එසේ නොවේ.

මෘදුකාංග වලදී, මිනිසුන් ඇත්තටම යමක් බලාපොරොත්තු වේ. නිසැකවම, තර්කනය ඉදිරියට යයි, එය ඇත්ත වශයෙන්ම solid න වීමට ටික කාලයක් ගතවනු ඇත; නමුත් සතියකින් සරල වචන වලින් විස්තර කර ඇති සංකීර්ණ දෙයක් අපට තිබිය නොහැකිද? අවංක, සංකීර්ණ වචන වලින් විස්තර කර ඇති සංකීර්ණ දේ පරිකල්පනය උද්දීපනය කරන්නේ කලාතුරකිනි; මේ නිසා බොහෝ ඉංජිනේරුවන් පරිකල්පිත ලෝකයකට සැබවින්ම සරල දේ නිර්මාණාත්මක ආකාරවලින් එකට එකතු කර ගනී (අමාරු දේවල් කරන ලෝකයකට වඩා හොඳින් සිදු වේ).

මගෙන් සමහර දේවල්:

1- ප්‍රමිති සහ කොටස්: ඔවුන් ගුවන් යානා නිෂ්පාදකයින් මිස සංවර්ධකයින් නොවේ. මට සම්පුර්ණයෙන්ම විශ්වාස නැත, නමුත් මගේ අනුමානය නම් කොටස් විශාල ප්‍රමාණයක් බාහිරින් ලබා ගැනීමයි. ඔවුන් තමන්ගේම ඉලෙක්ට්‍රොනික / උපකරණ සාදන්නේ නැත, ඔවුන්ට යම් සමාගමකින් ආසන ලැබේ, එන්ජින් වෙනත් තැනක සංවර්ධනය කර ඇත.

මෘදුකාංග ව්‍යාපෘති, අනෙක් අතට, සෑම විටම පාහේ මුල සිටම කුඩා රාමු / සහායකයින් සමඟ ආරම්භ වේ.

2- වෙළඳපොළට පැමිණීමට කාලය: ගුවන් යානා සඳහා කාලය තීරණාත්මක කාරණයක් නොවේ. එයාර් බස් රථයේ සැලසුම අවසන් වීමට වසර ගණනාවකට පෙර අවසන් කර ඇති බව මම විශ්වාස කරමි. එම කාලය තුළ සිදුවිය හැකි ප්‍රධාන ජයග්‍රහණ නොසලකා හැරීමට ඔවුහු තීරණය කළහ. (මෝටර් රථ නිෂ්පාදකයින් සඳහාම, උදාහරණයක් ලෙස, ඔවුන් මේ වන විට දියුණු කරන නවීන තාක්ෂණය වසර 5-10 කින් පාරට බසිනු ඇත.)

මෘදුකාංග සඳහා ඔබ ඉතා කඩිසර විය යුතුය, මම දැන් විශාල ව්‍යාපෘතියක් ආරම්භ කර කිසිදු වෙනසක් නොමැතිව එය සංවර්ධනය කිරීමට වසර තුනක් ගත වුවහොත්, මා තවදුරටත් ලබා ගත නොහැකි තාක්‍ෂණය මත විශ්වාසය තැබීමට හෝ මගේ නිෂ්පාදනය සම්පූර්ණයෙන්ම යල් පැන ගිය එකක් බවට පත්වීමේ සම්භාවිතාව ඉතා ඉහළය. මෙය අනෙක් අතට ගැටලු රාශියක් ඉදිරිපත් කරයි.

3- මුදා හැරීමේ චක්‍රය සහ අනුවාද. - යානයක් “මුදා හරින විට” එය සම්පූර්ණයෙන්ම අවසන් කළ යුතුය. ස්ථාවර බීටා අනුවාද, රාත්‍රී ගොඩනැගීම් හෝ ඊට සමාන කිසිවක් නොමැත. මීට අමතරව, එය අවසන් වූ පසු, එය වෙනස් කළ හැක්කේ කුඩා ආකාරයකින් පමණි. ඔබට දැනට පවතින බෝයිං සඳහා ආසන 100 ක් සහිත අතිරේක මට්ටමක් එක් කළ නොහැක, එය කළ නොහැකි ය.

අනෙක් අතට මෘදුකාංගයේ වර්ධනාත්මක වෙනස්කම් ඇති අතර ඒවා බොහෝ විට “වැඩ කරන ඒවා ගොඩනංවයි”, නමුත් අවශ්‍යයෙන්ම නිමි භාණ්ඩ නොවේ. එසේම, තොරතුරු තාක්ෂණයේ "හේයි, අමතර ටොන් 50 ක් ඇති අපගේ ගුවන් යානයට තවත් ගමන් මලු එකතු කරමු" යනුවෙන් පැවසීම අසාමාන්‍ය දෙයක් නොවේ.

මම හිතන්නේ පිළිතුර තරමක් සරලයි:

1) භෞතික ඉදිකිරීම් සහ ක්‍රියාත්මක කිරීම මිනිසුන් සිටින තාක් කල් පැවතුනි - භෞතික ව්‍යාපෘති ක්‍රියාත්මක කිරීම සඳහා අපගේ ක්‍රම සහ ශිල්පීය ක්‍රම දියුණු කිරීමට අපට වසර දහස් ගණනක් ගතවී ඇත. මුළුමනින්ම නව හා වෙනස් නිපුණතා කට්ටලයක් අවශ්‍ය වන මෘදුකාංග 'ඉදිකිරීම' අවුරුදු 50 කට වඩා පැරණි නොවේ - අපට තවමත් ඒ සියල්ල සොයා ගැනීමට ප්‍රමාණවත් කාලයක් නොමැත.

2) අතථ්‍ය ඉදිකිරීම වඩා දුෂ්කර ය - භෞතික යථාර්ථයක් නැති දේවල් ඔබේ මනසෙහි දැකිය යුතුය. ඔබේ නිෂ්පාදනය කෙබඳු විය යුතුද යන්න සහ එය නිර්මාණය කිරීමට ගත යුතු පියවර දැන ගැනීමට පෙර බොහෝ තොරතුරු විශ්ලේෂණය කිරීම හා සාරාංශ කිරීම අවශ්‍ය වේ. පාලමක් හෝ ගොඩනැගිල්ලක් තැනීමේදී එසේ නොවේ.

3) භෞතික ඉංජිනේරු විද්‍යාවට වඩා මෘදුකාංග අසමත්වීමක හෝ දෝෂයක ප්‍රභවය සොයා ගැනීම බොහෝ විට වඩා දුෂ්කර ය. ඉඟුරු ගාංචු නම්, එය කොහේදැයි ඔබ දකින අතර එය රඳවාගෙන සිටින සහ අසමත් වන ආධාරක ඔබ දකී. භෞතික ව්‍යුහයන් පවතින ආකාරයට භෞතික විද්‍යාවේ සහ ගණිතයේ නීති.

ජැක් ගැන්ස්ල්ගේ කාවැද්දූ කෞතුකාගාරයේ ලිපියක වාචික පිටපතක් භාවිතා කර පිළිතුරු දීමට මම උත්සාහ කරමි. මෙය සෑම තැනකම ස්ථිරාංග යැයි පැවසුවද, එය මානසිකව මෘදුකාංග මගින් ප්‍රතිස්ථාපනය කරන්න.

කුමක් හා සසඳන විට?

ස්ථිරාංග යනු විශ්වයේ වඩාත්ම මිල අධික දෙයයි. ලොක්හීඩ් මාටින් හි හිටපු ප්‍රධාන විධායක නිලධාරි නෝමන් ඔගස්ටින් විසින් ඔහුගේ “ඔගස්ටින්ගේ නීති” නම් අපූරු පොතේ ආරක්ෂක ප්‍රජාව මුහුණ දෙන ගැටලුවක් පිළිබඳව හෙළි කරන කතාවක් පවසයි. ඉහළ කාර්යසාධනයක් සහිත ප්‍රහාරක ගුවන් යානයක් ගැටුම්කාරී අවශ්‍යතාවන්ගේ සියුම් ශේෂයකි: ඉන්ධන පරාසය එදිරිව කාර්ය සාධනය. වේගය එදිරිව බර. 70 දශකයේ අග භාගය වන විට සටන්කරුවන් ඔවුන් තරම් බරින් වැඩි බව පෙනේ. කොන්ත්‍රාත්කරුවන්, සෑම විටම විශාල ලාභයක් ලුහුබඳිමින්, ඔවුන්ට විශාල පිරිවැයක් එකතු කළ හැකි දෙයක් ගැන නිෂ් ain ල ලෙස බැලූ නමුත් එහි බර කිසිවක් නොවීය.

පිළිතුර: ස්ථිරාංග. අසීමිත පිරිවැය, ශුන්‍ය ස්කන්ධය. ඒවොනික්ස් දැන් සටන් කරුවෙකුගේ පිරිවැයෙන් අඩකට වඩා වැඩිය. නවතම ඇමරිකානු ප්‍රහාරක යානය වන එෆ් -22 ගැන ඔබ සලකන විට එය වෙනසකට භාජනය වේ. ඔගස්ටින් මෙම කථාව විස්තර කරන විට ප්‍රායෝගිකව ප්‍රීතියෙන් ඉපිල යයි.

නමුත් මෘදුකාංග මෙතරම් මිල අධික වන්නේ ඇයි? ටොම් ඩිමාර්කෝ වරක් මෙම වචන තුනෙන් මෙම ප්‍රශ්නයට පිළිතුරු දුන්නේය: කුමක් සමඟ සසඳන විට? ඔහු සාපේක්ෂව කම්මැලි ව්‍යාපාරික අවස්ථා පිළිබඳව සාකච්ඡා කිරීමට ගිය නමුත් එම පිළිතුර වසර ගණනාවක් තිස්සේ මගේ මනසෙහි අනුනාද විය. කුමක් හා සසඳන විට? මෘදුකාංග සමඟ අපි පෙර නොවූ විරූ සංකීර්ණත්වයේ නිෂ්පාදන හැසිරීම් පුරුද්දක් ලෙස නිර්මාණය කරමු. නිසැකවම, කේතය මිල අධිකය. එහෙත් ශිෂ් ization ාචාර ඉතිහාසයේ කිසි විටෙකත් කිසිවෙකු මෙතරම් සංකීර්ණ කිසිවක් ගොඩනඟා නැත.

පහත දැක්වෙන බුබුලු වර්ග කිරීම සලකා බලන්න, විකිපීඩියාවෙන් නිර්ලජ්ජිතව ඔසවා නිරවද්‍යතාව පරීක්ෂා කර නැත:

void bubblesort(int * A, int n){

    for(int i(0); i < n; ++i)

        for(int j(0); j < n - i - 1; ++j)

            if(A[j] > A[j + 1])

                std::swap(A[j], A[j + 1]);

}

එය හුදෙක් අභ්‍යවකාශ නොවන අක්ෂර 110 ක් වන අතර සමහර විට එය පැයක් හෝ දෙකකින් ඉවතට විසිවී යයි. අපට මෘදුකාංගයක් නොතිබූ අතර වෙනත් උපක්‍රමයක් භාවිතා කරමින් වර්ග කිරීමක් ක්‍රියාත්මක කිරීමට සිදුවිය. ඒ සඳහා වැය වන්නේ කුමක්ද?

යාන්ත්‍රික ඉංජිනේරුවෙකු තම වෘත්තිය පරිගණක වලට බොහෝ කලකට පෙර වර්ග කර ඇති බවට පුරසාරම් දෙඩීමට ඉඩ තිබේ. මිනිත්තුවකට කාඩ්පත් 650 ක ප්‍රතිදානයක් සහිත අයිබීඑම් හි 1949 යුගයේ මාදිලියේ 82 කාඩ්පත් වර්ග ( http://www.columbia.edu/acis/history/sorter.html ) සලකා බලන්න , අපගේ කේත ස්නිපටයට වඩා 4 MHz පවා කළමනාකරණය කළ හැකිය. Z80. 82 ආකෘතිය, ඇත්ත වශයෙන්ම, වරකට කාඩ්පතක එක් තීරුවක් පමණක් වර්ග කර ඇත; තට්ටුවක් සම්පුර්ණයෙන්ම වර්ග කිරීම සඳහා පාස් දුසිම් ගණනක් ගත වේ.

මෙම මෘගයා සැලසුම් කිරීමට හා ගොඩ නැගීමට කොපමණ කාලයක් ගතවේද? අවුරුදු, නිසැකවම. අපගේ කේතය හා සසඳන විට එහි ක්‍රියාකාරිත්වය ඉතා වේගවත් වන අතර දැවැන්ත දත්ත කට්ටල හැසිරවිය හැකිය. නමුත් එය 1949 විය. FPGAs සහ VHDL හෝ CPU නොමැතිව ඉලෙක්ට්‍රොනික උපාංග වලින් බුබුලු වර්ගයක් සෑදීමට කොපමණ කාලයක් ගතවේද?

පැයක් ඇතුළත මම චිප් මට්ටමට ඉහළින් රළු බ්ලොක් රූප සටහනක් කළමනාකරණය කළෙමි (බ්ලොක් වලට "ඇඩර්," "බිට් 16 ලච්" වැනි නම් ඇත). නමුත් අනුක්‍රමික තර්කනය පැහැදිලිවම අවුල් සහගත බැවින් මම පීඑල්ඩී එකකට විසි කළෙමි, යම් අවස්ථාවක දී සුදුසු සමීකරණ ලිවීම එතරම් අපහසු නොවනු ඇතැයි සිතමි. ඔව්, සමහර විට එය වැඩසටහන්ගත කළ නොහැකි-තාර්කික රීතිය බිඳ දමයි, නමුත් ඕනෑම සාධාරණ කාලයකදී ගේට්ටු භාවිතා කරමින් එම තර්කනය සැලසුම් කිරීම සහ නිදොස් කිරීම බක්-ඒ-ගැලන් වායුව තරම්ම අපහසුය.

බිට් වචන 16 සහ ලිපිනයන් උපකල්පනය කරමින්, පරිපථයට බිට් 16 අගුල්, එකතු කරන්නන් සහ ඒ හා සමාන දුසිම් 16 ක් පමණ අවශ්‍ය වේ. ප්ලස් මතකය. තවද, වර්ගීකරණය නොකළ දත්ත RAM වෙත පැමිණෙන්නේ කෙසේද යන්න හෝ ප්‍රති results ල අපනයනය කරන්නේ කෙසේද යන්න පිළිබඳව මට කිසිදු අදහසක් නැත. ඒවා නිශ්චිත සැලසුම් අවශ්‍යතා වේ. මෘදුකාංග පමණක් විසඳුම ස්වාභාවිකවම මෙම අවශ්‍යතා නිරාකරණය කරන්නේ ශ්‍රිත මූලාකෘතිය ලිවීමේ ක්‍රියාවෙනි.

රළු බ්ලොක් රූප සටහන ක්‍රමානුකූලව පරිවර්තනය කිරීම සඳහා දිනක් ගතවනු ඇත. එවිට PCB, ඇණවුම් සහ කොටස් පැටවීම (සහ අනපේක්ෂිත නමුත් නොවැළැක්විය හැකි ජීවිතයේ අවසාන ගැටළු සමඟ කටයුතු කිරීම සඳහා සැලසුම වෙනස් කිරීම) සැලසුම් කිරීම සහ නිෂ්පාදනය කිරීම සඳහා කාලය තිබේ, පසුව ඇත්ත වශයෙන්ම පරිපථය ක්‍රියාත්මක කරන්න. අපට සති ගණන් වෑයමක් සහ පුවරුව, කොටස් සහ සුදුසු පරීක්ෂණ උපකරණ සඳහා විශාල මුදලක් කතා කළ හැකිය.

මේ සියල්ල කුඩා කේත පේළි 7 ක් ප්‍රතිස්ථාපනය කිරීමට ය. සැබෑ කාවැද්දූ වැඩසටහන් 10,000 කට වඩා අඩුය; බොහෝ දෙනෙක් මිලියනය ඉක්මවයි. සැබෑ සුපිරි ප්‍රමාණයේ පරිගණක වැඩසටහනක් ප්‍රතිස්ථාපනය කිරීම සඳහා දෘඩාංග හා කොපමණ ඉංජිනේරු ප්‍රමාණයක් අවශ්‍ය වේද?

පැතුරුම්පතක් වැනි සැබෑ වැඩසටහනක් සලකා බලන්න. ප්‍රොසෙසරයක් නොමැතිව එකක් සෑදීමට කොපමණ පරිපථයක් අවශ්‍ය වේද? එය නගරයක ප්‍රමාණය විය හැකිය.

ස්ථිරාංග යනු විශ්වයේ වඩාත්ම මිල අධික දෙය වන නමුත් එය විසඳන ගැටළු වල සිතාගත නොහැකි සංකීර්ණත්වය නිසා පමණි. නමුත් එය ඕනෑම විකල්පයකට වඩා බෙහෙවින් ලාභදායී ය. එබැවින් ඔබේ ලොක්කා කෝපයෙන් මෘදුකාංගය මෙතරම් කාලයක් ගත කරන්නේ ඇයි දැයි විමසූ විට, ඔබ කුමක් කියන්නදැයි ඔබ දන්නවා. කුමක් හා සසඳන විට?

ඉතින් එතන! මෘදුකාංග / ස්ථිරාංග අසමසම සංකීර්ණතාවයක් ඇත.

මෘදුකාංග ඉංජිනේරු විද්‍යාව සහ කළමනාකරණය අනෙකුත් බොහෝ ඉංජිනේරු ක්ෂේත්‍රයන්ට වඩා මූලික වශයෙන් වෙනස් වේ. මෙම බෙදා හැරීම් භෞතික නොවන, සහ නිෂ්පාදන ක්රියාවලිය වේ නිර්මාණය සහ සංවර්ධනය ක්රියාවලිය. මෘදුකාංගයක තවත් පිටපතක් සෑදීම සඳහා අත්‍යවශ්‍යයෙන්ම ශුන්‍ය ආන්තික පිරිවැයක් ඇත; පළමු පිටපත සංවර්ධනය කිරීමේදී සියලු පිරිවැය සොයාගත හැකිය.

මෘදුකාංග ඉංජිනේරු විද්‍යාවේ හා කළමනාකරණයේ සාපේක්ෂ තාරුණ්‍යය විනයක් ලෙස පවතින හෙයින්, වැරදි තොරතුරු සහ අසත්‍යයන් තවමත් සත්‍යයක් ලෙස ගෙන ඇත ( මෙම සඳහන බලන්න ) එය සමස්තයක් ලෙස මෘදුකාංග සංවර්ධනයට හා ඉංජිනේරු විද්‍යාවට බාධාවක් වේ.

සියලුම සංවර්ධකයින් සමානව නිර්මාණය වී නොමැත. සමහර ඒවා හොඳයි, අනෙක් ඒවා හොඳයි.

මා පවසන දේ පිළිබඳ හැඟීමක් ලබා ගැනීම සඳහා අනෙක් පුද්ගලයින්ගේ කේතය නිතරම කියවීමට උත්සාහ කරන්න. අමතර තාර්කික ප්‍රකාශ ඕනෑවට වඩා අවදානම් එකතු කළ හැකිය. මෙම අවදානම් අයහපත් හැසිරීම් හෝ දෝෂ වලට හේතු විය හැක. ප්‍රමාණවත් තර්කන ප්‍රකාශ නොමැති අතර දැන් ඔබට ශුන්‍ය යොමු කිරීම් ඇත. හොඳ ක්‍රමලේඛකයා මෙය තේරුම් ගෙන කුමක් කළ යුතුද සහ කොතැනද යන්න දනී. නමුත් කිසිවෙකු පරිපූර්ණ නොවේ. දේවල් සංකීර්ණයි. අන් අයගේ දුර්වල ලෙස සිතූ වැඩ එකතු කරන්න, එවිට ව්‍යාපෘති ක්‍රියාත්මක වන්නේ කෙසේදැයි බැලීම පහසුය.

ආසන දෙව්මැදුර සෑදීම සඳහා වසර 100 ක් පමණ ගත වේ.

සමහර එයාර් බස් ගුවන් යානා වැඩ කිරීමට කේත පේළි මිලියනයක් අවශ්‍ය වේ.

ඔබ යමක් වැඩි දියුණු කර ඇති තරමට, ඔබට වැඩි දියුණුවක් ලැබෙනු ඇත, එබැවින් මෘදුකාංග කර්මාන්තයට වඩා හොඳ වීමට ශතවර්ෂ දෙකක අත්හදා බැලීමේ දෝෂයක් ලබා දෙන්න, දෝෂ නොමැතිව ශක්තිමත් දැවැන්ත ව්‍යාපෘතියක් සංවර්ධනය කිරීමට කොපමණ කාලයක් ගතවේදැයි අපි බලමු. හෝ අඩුපාඩු.

විශාල ව්යාපෘති බොහෝ විට විශාල සංවිධානවල සිදු වේ. ඔබ කිසි විටෙකත් විශාල සංවිධානයක සේවය කර නොමැති නම්, කාර්ය සාධනය සහ tivity ලදායිතාව විනාශ කිරීමට සහතික වන එක් දෙයක් තිබේ: නිලධාරිවාදය.

පුදුමයට කරුණක් නම්, බොහෝ අය නිලධරය යනු කුමක්දැයි නොදැන සිටිති (එය බොහෝ විට දේශපාලනය සමඟ ව්‍යාකූල වී ඇත), හෝ ඔවුන්ට නිලධාරිවාදී ගැටළුවක් ඇති විටදී පවා.

ස්මාර්ට් කාඩ් සත්‍යාපනය ක්‍රියාත්මක කිරීමේ ව්‍යාපෘතියක් අපි මෑතකදී අවසන් කළෙමු. එය මුලින් ඇස්තමේන්තු කර ඇත්තේ මාස තුනකි. මාස 15 ක් ගතවිය. ප්‍රමාදය සඳහා කිසිදු පිරිවැයක්, අයවැයක්, විෂය පථයක් හෝ තාක්ෂණික හේතු නොමැත. විෂය පථය සැබවින්ම තරමක් පටුය - ඉහළ වරප්‍රසාද සහිත ගිණුම් සඳහා (පරිපාලක ගිණුම්), මුළු ගිණුම් 1,200 ක් පමණ.

තවත් වැදගත් සාධකයක් වන්නේ ඔබේ ව්‍යාපාර හවුල්කරුවන් ය. මෙයට වෙළෙන්දන් ඇතුළත් වේ. ඔබේ ව්‍යාපෘතියේ ප්‍රමාදයක් හඳුන්වා දෙන ගැටළුවක් ඔබේ හවුල්කරුවන්ට තිබේ නම්, ප්‍රමාද ගැටලුව නිරාකරණය කරන බොහෝ විකල්ප නොමැත. ඔවුන් ඔබ වෙනුවෙන් කෙලින්ම ක්‍රියා නොකරන අතර, හවුල්කරුවකුට වෙඩි තැබීමට ඔබට නොහැකි විය හැකිය. හවුල්කරු සේවයෙන් පහ කළ හැකිය, නැතහොත් මූල්‍යමය ද ties ුවම් හෝ දිරිගැන්වීම් වලට යටත් විය හැකිය, නමුත් ව්‍යාපෘතිය ප්‍රමාද වී ඇති බවට එය වෙනස් නොවේ. බෝයිං 787 ඩ්‍රීම්ලයිනර් සමඟ දැවැන්ත මූලාශ්‍ර උපාය මාර්ගයක් අනුගමනය කරන විට බෝයිං සමාගමට සිදු වූයේ මෙයයි .

මට ඔබ වෙනුවෙන් කෙටි සංස්කරණයක් ඇත:

කුමක් කිරීමට පහසු හෝ විධිමත් වුවත්, අප වෙනුවට එය කිරීමට අපි වැඩසටහනක් ලියන්නෙමු.

ඉන්පසු ඒ වෙනුවට මෙටා ක්‍රියාවලිය සමඟ සටන් කරන්න.

එය එතරම් සත්‍යයක් නොවේ, නමුත් සෑම දිනකම බ්ලොග් එන්ජින් ලිවීම වෙනුවට බ්ලොග් දහස් ගණනක් පිහිටුවා ඇත. සෑම වැඩ දිනයකම, එක්සෙල් මැක්‍රෝ දහස් ගණනක් ලියා ඇත, මේවා සඳහා විෙශේෂෙයන් නිර්මාණය කරන ලද දත්ත සමුදා යෙදුම් ලිවීම වෙනුවට.

තවත් බොහෝ සාධක තිබේ - ඒවායින් සමහරක් මෙහි සඳහන් කර ඇත - නමුත් මට මෙම කරුණ සාකච්ඡාවට එක් කිරීමට අවශ්‍ය විය.

වගවීමක් නොමැතිකම ... ගුවන් යානයක් අනතුරට පත් වූ විට මිනිසුන්ට නඩු පවරනු ලැබේ. මෘදුකාංග කර්මාන්තය ඕනෑම මෘදුකාංග දෝෂයක ඕනෑම වගකීමක් ප්‍රතික්ෂේප කරයි, එබැවින් ශක්තිමත් හා ආරක්ෂිත නිෂ්පාදනයක් නිර්මාණය කිරීමට දිරිගැන්වීමේ lack නතාවක් ඇති කරයි.

බොහෝ විශාල ව්‍යාපෘතිවල උප ව්‍යාපෘතිවල ඉහළ වෙන්වීමක් ඇත, එහිදී ඔබට සැලසුම් සීමාවන් සුළු සංඛ්‍යාවක් අර්ථ දැක්විය හැකිය; එම උප ව්‍යාපෘති එක් එක් වැඩ අවසන් වූ විට සමස්ත ව්‍යාපෘතියම ක්‍රියාත්මක වේ. උප ව්‍යාපෘතියක යම් දෙයක් වැරදී ගියහොත්, මුළු උත්සාහයම ප්‍රශ්නයට භාජනය නොවේ. ඔබ උප ව්‍යාපෘතිය සම්පූර්ණ කිරීම සඳහා විකල්ප ක්‍රම සොයමින් සිටී (උදා: වෙනත් එන්ජිමක් භාවිතා කරන්න).

මෘදුකාංග ව්‍යාපෘති වලදී මෙය ප්‍රායෝගිකව මෙන්ම මිනිස් ස්වභාවයේ කාරණයක් ලෙස කළ හැකි නමුත් දුෂ්කර ය.

අර්ධ වශයෙන්, වෙනත් කර්මාන්ත විසින් මේ ආකාරයේ වෙන්වීම හොඳ දෙයක් බව දැඩි ලෙස ඉගෙන ගෙන ඇත. උදාහරණයක් ලෙස, ඔබ රෝල්ස් රොයිස් ගුවන් යානා එන්ජින් භාවිතා කිරීමට යන්නේ නම්, විශේෂිත සැලසුමක් සහිත පියාපත් සමඟ පමණක් ක්‍රියා කරන විශේෂ රෝල්ස් රොයිස් බෝල්ට් සහ ඇමිණුම් ස්ථාන භාවිතා කිරීමට ඔබට අවශ්‍ය නැත, ඉන්පසු ඔබ ප්‍රට් සහ විට්නි වෙත මාරු වීමට උත්සාහ කරන්නේ නම්, ඔබේ මුළු තටුවම බිම් මට්ටමේ සිට නැවත සැලසුම් කළ යුතුය (ඒ සඳහා ෆියුස්ලේජ් සම්පූර්ණයෙන්ම ප්‍රතිනිර්මාණය කිරීම අවශ්‍ය වන අතර එමඟින් ඔබට විවිධ ආසන මිලදී ගැනීමට අවශ්‍ය වන අතර එමඟින් ඔබට වෙනත් ගුවන් ගමන් විනෝදාස්වාද පද්ධතියක් මිලදී ගැනීමට අවශ්‍ය වේ. කුමන...). සම්බන්ධතා කිහිපයක් තිබිය හැකිය - ඔබට රැකවරණයකින් තොරව එන්ජින් මාරු කළ නොහැක - නමුත් විශාල ව්‍යාපෘති සාමාන්‍යයෙන් එවැනි දේ අවම කළ විට වඩා හොඳින් ක්‍රියා කරයි.

මම එකිනෙකාට කැමැත්ත අතර පිරිසිදු අතුරු මුහුණත් සමග කුඩා මෘදුකාංග ව්යාපෘති පොකුරු ලෙස නිර්මාණය විශාල මෘදුකාංග ව්යාපෘති උපග්රහනය නොවේ දිගු විශාල ව්යාපෘතිය ඇත්තටම කුඩා ව්යාපෘති පොකුරු විසින් විසඳා ඇත තරම්, විශේෂයෙන්ම බොහෝ විට අසමත් වෙති. (මේ සම්බන්ධයෙන් වැරැද්දක් කළ හැකිය.)

මෘදුකාංග පද්ධති තැනීම භෞතික ව්‍යුහයන් තැනීමට වඩා බෙහෙවින් වෙනස් ය. එනම්, ක්රියාත්මක කිරීම බෙහෙවින් වෙනස් ය. උදාහරණයක් ලෙස විශාල ටැංකියක් තැනීමේදී ඔබ රොබෝවෙකු හෝ අතින් කොටස් වෑල්ඩින් කිරීම, සියලු ඇට වර්ග සහ බෝල්ට් තද කිරීම, පින්තාරු කිරීම වැනි අලංකාර සරල (පහසු නැත!) කාර්යයන් බොහොමයක් කරයි. උපකරණ සහ ගෘහ භාණ්ඩ සහ එවැනි ය. මේ සියල්ලම කළ යුතු ඉතා සරල දේවල්.

කෙසේ වෙතත්, මෘදුකාංගය සම්බන්ධයෙන් ගත් කල, එය වඩාත් සංකීර්ණ වේ. උදාහරණයක් ලෙස, නිෂ්පාදනයේ ආරක්‍ෂිත පිවිසුම් සහ පරිශීලක අක්තපත්‍ර ගබඩා කිරීමේ කොටස ක්‍රියාත්මක කරන්නේ කෙසේද? ඔබට භාවිතා කළ හැකි පුස්තකාල සහ මෙවලම් මොනවාද? ඔබ හුරුපුරුදු පුස්තකාල සහ මෙවලම් මොනවාද? හැෂිං + ලුණු දැමීමේ කාර්යය ලිවීම ගැන ඔබ හරියටම යන්නේ කෙසේද සහ එය ආරක්ෂිත බව ඔබ සහතික කරන්නේ කෙසේද? ඔබට මෙය බොහෝ ආකාරවලින් කළ හැකි අතර මේ ආකාරයේ දේවල් සඳහා සැබෑ ප්‍රායෝගික මෝස්තර රටා සැකසිය නොහැක . ඔව්, නිර්මාණ රටාවන් පවසයි කරන්න "හොඳ පුරුදු" ලෙස කුඩා පරිමාණයේ පවතින්නා, නමුත් සෑම මෘදුකාංග පද්ධතිය අන් අය බොහෝ වෙනස් වන අතර, ඒ නිසා වේගයෙන් ක්ෂේත්රයේ අත්තිකාරම් සහ වෙනස්කම් එය තබා ගැනීමට අවශ්යයෙන්ම කළ නොහැකි දෙයක් බව.

නිවසක් තැනීමේදී, ප්‍රධාන ආධාරක බිත්ති ප්‍රමාණවත් නොවන බවත් ඒවා ප්‍රතිස්ථාපනය කළ යුතු බවත් ඔබ වටහා ගන්නා එවැනි ගැටලුවලට ඔබ සැබවින්ම නොයනු ඇත, මේ දක්වා ඇති ප්‍රගතිය කඩා බිඳ දමා ආධාරක බිත්ති නැවත සකස් කිරීමෙන් පාදමෙන් ආරම්භ කළ යුතුය. . සැලසුම් අවධියේදී ඔබ එවැනි ගැටළු නිරාකරණය කරයි , මන්ද ඔබේ ගොඩනැගිල්ලට අවශ්‍ය කුමන ආකාරයේ ආධාරක බිත්ති අනාවැකි කීම සාපේක්ෂව සරල ය.

මෘදුකාංග සම්බන්ධයෙන් එය එසේ නොවේ. ඔබට සම්පූර්ණ නිෂ්පාදිතය තනි ආයතනයක් ලෙස සැබවින්ම සැලසුම් කර එය ක්‍රියාත්මක කළ නොහැක. මෘදුකාංග සැලසුම් ක්‍රියාවලිය සාමාන්‍යයෙන් ක්‍රියාකාරී වන අතර නිෂ්පාදිතය ක්‍රියාත්මක කර පරීක්ෂා කරන විට අරමුණු හා අවශ්‍යතා වෙනස් වේ. සමස්තයක් ලෙස මෘදුකාංග සංවර්ධනය යනු අවම වශයෙන් අපේක්ෂා කළ විට සාමාන්‍යයෙන් දේවල් වෙනස් වන පුනරාවර්තන ක්‍රියාවලියක් වන අතර බොහෝ විට එවැනි වෙනස්වීම් මඟින් වැඩි වැඩ ප්‍රමාණයක්, වඩා සංකීර්ණ හා අවාසනාවකට මෙන් අවශ්‍ය වන අභියෝගයන් පැන නගින අතර අවසානයේදී නිවැරදි මුදල් ලබා ගැනීම සඳහා වැඩි මුදලක්, කාලය සහ වෙහෙස මහන්සි වී වැඩ කළ යුතුය.

එබැවින්, සාරාංශයක් ලෙස, විශාල ව්‍යාපෘති ලබා දීම සහ ව්‍යාපෘති කාල නියමයන් සහ මාර්ග සිතියම් තක්සේරු කිරීම අසීරු වීමට හේතුව මෘදුකාංග සංවර්ධනය සහ විශේෂයෙන් වැඩ කරන සැලසුම් ඉතා සංකීර්ණ ක්ෂේත්‍රයන් වීමයි. සංකීර්ණත්වය යනු මූල ගැටළුවයි.

"විශාල ව්යාපෘතිය" යන්නෙහි අර්ථ දැක්වීම නොගැලපේ.

විශාල ව්‍යාපෘතියක්, තාක්‍ෂණිකව, නියමිත වේලාවට ලබා දිය හැකි අතර, අඩුපාඩු රහිතව, එය වසර ගණනාවක් පුරා බොහෝ වාර ගණනක් ගොඩනගා ඇති දෙයක් ලෙස සලකනු ලැබේ.

• පැක්-මෑන් ක්ලෝනයක්.
• කැල්කියුලේටරයක්
• පෙළ සංස්කාරකය

මට විශ්වාසයි ඔබ සිතනවා ... "නමුත් ඒවා කුඩා ව්‍යාපෘති! පෙළ සංස්කාරකය සරලයි ." මම ඔබ සමඟ එකඟ නොවෙමි. පරිගණක අතිශයින්ම සංකීර්ණයි. මෙහෙයුම් පද්ධතියක පරිශීලකයින් ස්ථාපනය කිරීම සහ සැකසීම ඇතැම් විට දුෂ්කර විය හැකි අතර, ඔබ මෙහෙයුම් පද්ධතිය ලිවීම හෝ දෘඩාංග සෑදීම පවා නොකළේය .

ඔබ කතා කරන ව්‍යාපෘති අභ්‍යවකාශ ගවේෂණයට සමාන විශාල ව්‍යාපෘති වේ. අන්තර් මන්දාකිණි ගමන් දියුණු කිරීමට කොපමණ කාලයක් ගතවේදැයි ඔබ දන්නේ කෙසේද? අපි එය පදනම් කරගන්නේ කුමන ආකෘතියද? ඔබ දන්නා හඳුනන අය, දන්නා නොදන්නා අය, නොදන්නා අය සහ අවසාන වශයෙන් නොදන්නා නොදන්නා අය මෘදුකාංග සංවර්ධනයේ දී බොහෝ දේ සිදු වේ.

මම හිතන්නේ ගැටලුව අපේක්ෂාවෙන් එකක්. තාක්‍ෂණය පවතින පමණින් එය භාවිතා කිරීම ටික කලකට සාර්ථක වනු ඇතැයි අදහස් නොකෙරේ. මෘදුකාංග කර්මාන්ත මෙන් වෙනත් කර්මාන්ත හැසිරෙන්නේ නම්, දශකයේ අවසානය වන විට අපට කළු කුහර බලයෙන් ක්‍රියාත්මක වන වැකුම් ක්ලීනර් විකිණීමට ඇත. නැතහොත් සමහර "දර්ශනීය" අයට සඳ පදනමක් තැනීමට අවශ්‍ය සම්පත් ඇති අතර, ස්ටාර්බක්ස් නරඹන්නන් සඳහා අත්දැකීම් සැබවින්ම "වට කර" ගත හැකි යැයි තීරණය කරයි. ගැටලුව මෘදුකාංග කර්මාන්තය යැයි මම නොසිතමි, නමුත් අපේක්ෂාවන් ඒ මත තබා ඇත .

සඳහන් කළ හැකි එකම දෙය එය නොවන නමුත් , එක් මූලික දෙයක් පෙන්වා දීම වටී යැයි මම සිතමි. බොහෝ නිෂ්පාදන පවත්නා හැසිරීම් වලට ගැලපෙන පරිදි අදහස් කෙරේ. රැඩිකල් ඉදිරි ගමනක් වන නිෂ්පාදනයක් පවා (නිදසුනක් ලෙස, මෝටර් රථය) සාමාන්‍යයෙන් පවත්නා හැසිරීම් වලට සරිලන පරිදි ගොඩනගා ඇති අතර, එය කළ හැකි තරමක් සරල / පහසු / ලාභදායී / ඕනෑම දෙයක් බවට පත් කරන්න. ඔව්, බොහෝ විට පවත්නා හැසිරීම් වලටද යම් අතුරු ආබාධයක් ඇත (නිදසුනක් වශයෙන්, අශ්වයින් සඳහා ආහාර වෙනුවට මෝටර් රථයට ඉන්ධන ලබා ගැනීම), නමුත් බොහෝ ඒවායින් සුළු අතුරු ආබාධයක් ඇති වේ.

ඊට හාත්පසින්ම වෙනස්ව, පරිශීලකයින්ගේ හැසිරීම වෙනස් නොකරන ඕනෑම මෘදුකාංගයක් පාහේ (නිදසුනක් ලෙස, ඔවුන්ගේ කාර්යය සැලකිය යුතු ලෙස පහසුවෙන් කිරීමට ඔවුන්ට ඉඩ දෙන්න) මූලික වශයෙන් 1 වන දින සිට සම්පුර්ණයෙන්ම අසාර්ථක වන බවට සහතික වී ඇත. තනි මට්ටමින් පරිශීලකයින්ගේ හැසිරීම සම්බන්ධ වන නමුත් විශාල කණ්ඩායම්වල හැසිරීම - බොහෝ විට සංවිධානයේ සමස්තය.

කෙටියෙන් කිවහොත්, මෘදුකාංගය සැලසුම් කිරීම බොහෝ විට කාර්යයේ පහසුම කොටස වේ. අමාරුම දෙය නම් ජනතාවගේ රැකියා ඔවුන් සඳහා නැවත සැලසුම් කිරීමයි. එය ආරම්භ කිරීම දුෂ්කර ය; එය වැඩ කිරීම පමණක් නොව පිළිගැනීමට ලක්වන අයුරින් කිරීම තවමත් වඩා දුෂ්කර ය.

ඔබ සඳහන් කළ පරිදි එයාර් බස් ඒ 380 සාර්ථක ව්‍යාපෘතියක් නොවීය. මම CAD / CAM සමාගමක වැඩ කිරීමට යන අතර, එය (අපට එයාර් බස් ප්‍රමුඛතාවයද ඇත) වසර කිහිපයකින් ප්‍රමාද වූ බව මට දැනගන්නට ලැබුණි, මන්ද ඔවුන් විවිධ සමාගම්වල විවිධ මෘදුකාංග භාවිතා කරන බැවිනි. එනම්, ලෝකයේ විවිධ ප්‍රදේශවල විවිධ කොටස් නිර්මාණය වෙමින් පැවතුනි. ඒකාබද්ධ කිරීමේදී ඔවුන් සියලු නිර්මාණ ඒකාබද්ධ කළ නොහැකි බව දැනගත් බැවින් ඔවුන්ට එය එක් අනුවාදයකින් නැවත සැලසුම් කළ යුතුය. එබැවින් එය දෙස බැලීමෙන් එය සාර්ථක යැයි මම නොසිතමි. එය මීට වසර 2-3 කට පෙර පැමිණියේ නම් එය එයාර් බස් සඳහා ක්‍රීඩාව වෙනස් කිරීමට ඉඩ තිබුණි.

ශක්තිමත් මෘදුකාංග සම්බන්ධයෙන්ද, ඔබ ඕනෑම ගුවන් යානයක්, මෝටර් රථයක් (ඒබීඑස්, ඊපීඑස්, දේශගුණික පාලනය යනාදිය) හෝ අභ්‍යවකාශ ෂටලය දෙස බැලූ විට ඔවුන් සතුව 50% කට වඩා වැඩි මෘදුකාංග ප්‍රමාණයක් ක්‍රියාත්මක වන අතර ඒවා විශ්වාස කරන අතර ඒවා ඉතා ශක්තිමත් ය. එය අප මෘදුකාංගයට වඩා සමීප වන අතර තවත් බොහෝ මෘදුකාංග වැඩසටහන් ඇත, එබැවින් ඒවායේ වැඩි දෝෂ අපට පෙනේ.

පිවිසෙන්න: http://www.globalprojectstrategy.com/lessons/case.php?id=23 සහ එයාර් බස් A380 කොතරම් සාර්ථකදැයි බලන්න.

මෙහි ඉංජිනේරු පසුබිමක් ඇති මෘදුකාංග ඉංජිනේරුවරයෙකු සහ ඉදිකිරීම් කටයුතු කරන බිරිඳක්. අපගේ රැකියා වල වෙනස්කම් පිළිබඳව අපි දීර් discussions වශයෙන් සාකච්ඡා කර ඇත්තෙමු.

මෘදුකාංග ඉංජිනේරු විද්‍යාව යනු අලුත් දේවල් සැලසුම් කිරීමයි. මූලික සෑම දෙයක්ම පාහේ කොතැනක හෝ විවෘත මූලාශ්‍ර පුස්තකාලයක සිදු කර ඇත. මෘදුකාංග ඉංජිනේරුවරයෙකු කුලියට ගන්නා ඕනෑම රැකියාවකදී ඇයට නොපවතින දෙයක් සැලසුම් කළ යුතුය.

ඉදිකිරීම් සහ බොහෝ ඉංජිනේරු ක්‍රම වැනි දේවල, මෘදුකාංගයේ පුස්තකාලයක තිබිය හැකි දේවල් දැනටමත් සම්පුර්ණයෙන්ම නිර්මාණය කර ඇත. කුළුණක් සෑදීමට අවශ්‍යද? වෙනස් කිරීම් කිහිපයක් සහිතව, පවතින ව්‍යුහයකින් සැලසුම් පිටපත් කර අලවන්න.

ඇත්ත වශයෙන්ම, මම ඉංජිනේරුවෙකු නොවීමට තීරණය කළ එක් ප්‍රධාන හේතුවක් නම්, ඔබ දැනට පවතින නව නිපැයුමකට 10% ක වර්ධනයක් සැලසුම් කිරීම සඳහා ඔබේ කාලය වැඩි කාලයක් ගත කිරීමයි, එම කාලයම සමාජ ජාලයක් වැනි වඩා දෘශ්‍යමාන යමක් වැඩසටහන්ගත කිරීමට භාවිතා කළ හැකිය. .

ඉංජිනේරු විද්‍යාවේ නව නිර්මාණ බොහොමයක් නොමැත; අතිශයින්ම දක්ෂ ඉංජිනේරුවෙකු යනු පවත්නා සැලසුමක් නව දෙයකට හසුරුවා ගැනීමට හෝ එය වැඩිදියුණු කිරීමට හැකි අයෙකි. නමුත් සෑම ක්‍රමලේඛකයෙකුම පාහේ සැලසුම් වෙනස් කිරීම, ඒවා හැක් කිරීම හෝ අලුත් දෙයක් නිර්මාණය කිරීම අපේක්ෂා කරයි.

එකලස් කිරීමේ සිට සී ++ දක්වා ජාවා, ජාවාස්ක්‍රිප්ට්, සී #, පීඑච්පී සහ යනාදී ප්‍රමිතීන් මුළුමනින්ම වෙනස් වී ඇති ආකාරය දෙස ආපසු හැරී බලන්න . අවුරුදු 10 ක් හෝ 20 කට පෙර ප්‍රතිචක්‍රීකරණය කළ හැකි කේත විශාල ප්‍රමාණයක් නොමැත. මෙය කීමට බෙහෙවින් වෙනස් ය ... දශක ගණනාවකට පෙර සිට ඔබට නිර්මාණ වැඩි දියුණු කළ හැකි විට මෝටර් රථ හෝ ගගනගාමී කර්මාන්තය.

ව්‍යාපෘති කළමනාකරණය ව්‍යාපෘතිවල කුප්‍රකට දුෂ්කර ය . කාල ඇස්තමේන්තු වඩාත් සුදුසු වන්නේ වැඩ කරන පුද්ගලයින් විසිනි , නමුත් ඔවුන් කාර්යබහුල වන විට ඇස්තමේන්තු කිරීම, ඔවුන් කේත ලිවීම නොවේ . මෙය කිසිසේත්ම ව්‍යාපෘති කළමනාකරණයෙන් වැළකී සිටීමට ජනතාව පොළඹවයි.

බොහෝ විට, බොහෝ කේතයන් විශේෂිත පුද්ගලයින් මත රඳා පවතින අතර, මෙම පුද්ගලයින් ප්‍රමාද වී හෝ ක්‍රියා කිරීමට නොහැකි නම්, කේතය ඉදිරියට නොයනු ඇත. ඊට වෙනස්ව, ඔබට මෝටර් රථයක් තැනීමට අවශ්‍ය නම්, ටයර්, චැසි, බැටරි, එන්ජිම යනාදිය එක්රැස් කිරීම සඳහා ඔබට විවිධ පුද්ගලයින් බඳවා ගත හැකිය. වස්තු නැඹුරු සහ පවතින රාමු මඟින් මෙය කළ හැකි නමුත් ඔබ මුල සිටම සියල්ල සැලසුම් කරන විට එය ප්‍රායෝගික නොවනු ඇත.

මෘදුකාංගවල අසමත් වීමට ඉඩ දිය හැකිය . පරීක්ෂා කිරීම මිල අධික විය හැකිය. මෘදුකාංග වලදී, ඔබට බිඳවැටීමක් නිවැරදි කළ හැකි විට, එම පරීක්ෂණ සියල්ලම මඟ හැරීමට ඉතා පෙළඹේ. බොහෝ ඉංජිනේරු ක්‍රම වලදී, 'බිඳවැටීමක්' මාරාන්තික විය හැකිය.

ආන්තික ක්‍රමලේඛන (සැබවින්ම මෘදුකාංග මෙගා ප්‍රොජෙක්ට් මත භාවිතා කරන ලද) වැනි පුළුල් පරීක්ෂණ භාවිතා කරන ක්‍රමලේඛන ක්‍රම ඔබ සතුව ඇත . නමුත් දැඩි කාලසීමාවන් සමඟ (එය අරමුණින් දැඩි කළ හැකිය), එම වැඩසටහන් සියල්ලම මඟ හැර දෝෂ සමඟ දියත් කිරීමට පෙළඹේ. මෙම ජොයෙල් Spolsky "සෑම විටම සියලු දෝෂ සවි" ශෛලිය දිගු කාලයේදී වැඩියෙන් කාලය ඉතිරි වනු ඇත, නමුත් විනය හැසිරවීමක් නැති මෙම මඟ අසාර්ථක වනු ඇත.

කුඩා ව්යාපෘති වඩා හොඳය . වරක් මගේ බිරිඳ මගෙන් ඉල්ලා සිටියේ විශාල සමාගමක රැකියාවක් ලබා ගන්නා ලෙසයි. එය අවසන් වූයේ විශාල සමාගම් නරක සමාගම් යැයි තර්ක කිරීමෙනි ... ඇයට, විශාල සමාගමකට සම්පත්, අත්දැකීම්, ක්‍රියාකාරී ව්‍යාපෘති කළමනාකරණය සහ නිවැරදි ක්‍රියා පටිපාටි රාශියක් තිබුණි. මට නම්, විශාල සමාගමක් යනු ඩයිනෝසෝරයෙකි, එහිදී ඔබේ කාලය වැඩි වශයෙන් ගත කරන්නේ කේතය නිවැරදි කිරීම, පරීක්ෂා කිරීම සහ ලේඛනගත කිරීම සඳහා ය.

ඩොලර් මිලියනයක තොරතුරු තාක්ෂණ ව්‍යාපෘති 10 කට අඩු පිරිසක් විසින් ක්‍රියාත්මක කරනු මම දැක ඇත්තෙමි. තවත් බොහෝ අය ව්‍යාපෘතිය මන්දගාමී කර අනවශ්‍ය නිලධරයන් එකතු කිරීමට ඉඩ තිබුණි. WhatsApp යනු ඩොලර් බිලියන ගණනක් වටිනා 'කුඩා' ව්‍යාපෘතියකට උදාහරණයකි. විශාල ව්‍යාපෘති කළ නොහැකි බව නොවේ, නමුත් ඩොලර් බිලියන ගණනක් වටිනා මෘදුකාංග නිපදවීමට ඔබට දහස් ගණනක් අවශ්‍ය නොවේ.

අනෙක් ප්‍රශ්න වල සැබවින්ම ආවරණය නොවූ එක් හේතුවක් නම්, මෘදුකාංග ක්ෂේත්‍රය නව්‍යකරණය කරන්නේ ද්‍රව්‍යමය පදනම් වූ ලෝකයේ කලාතුරකින් පමණි.

මෘදුකාංග පරිණාමය ධනාත්මක ප්‍රතිපෝෂණ චක්‍රයක් වීම මෙයට එක් හේතුවක් වන්නේ මෘදුකාංග තැනීම සඳහා මෘදුකාංග (ක්‍රමලේඛන භාෂා, ගොඩනැගීමේ මෙවලම්, IDEs) භාවිතා කරන බැවිනි. රේ කුර්ස්වෙල්ගේ ප්‍රතිලාභ වේගවත් කිරීමේ නියමය සඳහා එය වඩාත් පැහැදිලි උදාහරණයකි , එහි ප්‍රති ing ලයක් ලෙස on ාතීය ලෙස වර්ධනය වන වේගයෙන් ප්‍රගතියක් ලැබේ. ඔබ එක් රාමුවක්, ක්‍රමලේඛන භාෂාව, සන්නිවේදන ප්‍රොටෝකෝලය ප්‍රගුණ කළ පසු ඊළඟට යාමට කාලයයි .

මෘදුකාංග මෙන් ගුවන් යානා ගොඩනඟා ඇත්නම්, අපි අනෙක් සෑම මාදිලියක් සමඟම ද්‍රව්‍ය වෙනස් කරන්නෙමු, සෑම මාස 18 කට වරක් ඒවායේ ධාරිතාව හා වේගය දෙගුණ කරන්න, සෑම නව මාදිලියකටම එන්ජින් තාක්‍ෂණය වෙනුවට නව නිපැයුමක් ලබා දෙන්නෙමු. ජීවිතය.

ඔහ්, එය ඉතා හොඳින් හ voice විධාන වලට සවන් දෙන අතර ඔබේ වැඩ චාරිකාව අවසන් වූ වහාම එය සම්පූර්ණයෙන්ම ගිලී ගිය සිනමාහලක්, තීන්ත බෝල පිටියක් සහ අඳුරු කාමරයක් සහිත රාත්‍රී සමාජ ශාලාවක් ලෙස දෙගුණ කරයි. එකම දේ! (A සිට B දක්වා ඔබට විශ්වාසදායක ලෙස ගුවන් යානා තැනූ සමාගම, සිනමාහල, තීන්ත බෝල් සහ රාත්‍රී සමාජශාලා අංගය එළියට පැමිණ වසරකට පසුව උදරයට නැංගේය.)

මට නම් මෘදුකාංග ඉංජිනේරු මුහුණ දෙන ප්‍රධාන ගැටළුව වන්නේ නඩු, පරිශීලක සහ හරස් වේදිකා භාවිතා කිරීමයි.

නඩු භාවිතා කරන්න

ගුවන් යානයක භාවිත අවස්ථා කීයක් තිබේද? එය බොහෝ දුරට එක් ස්ථානයක සිට තවත් ස්ථානයකට පියාසර කිරීම පමණි. සමහර විට රේඩාර්, ගමනාගමන පාලනය වැනි තවත් බොහෝ දේ ඇත, නමුත් භාවිත නඩුව පැහැදිලිය. මෘදුකාංග ඉංජිනේරු විද්‍යාවේදී, අපැහැදිලි අවශ්‍යතා සහ ඔවුන්ට අවශ්‍ය දේ නොදන්නා පරිශීලකයින් අපට මුහුණ දී සිටී. විවිධ පරිශීලකයින්ට වෙනස් වින්‍යාසයන් / ප්‍රවාහයක් අවශ්‍ය වේ, ගුවන් යානයක් පරිශීලකයාට අවශ්‍ය පරිදි රිසිකරණය කළ හැකිද (මට රූපවාහිනිය සහ ශීතකරණයක් තිබිය යුතුය!)?

පරිශීලක

ගුවන් යානයක් මෙහෙයවන්නේ කවුද? ගුවන් නියමුවෙක්, කොපිලට් කෙනෙක්, සමහර භාරකරුවන් (ගණන් කළහොත්) සහ කුළුණු ක්‍රියාකරුවන්. ඔවුන් සියල්ලන්ම වාසිදායක වන අතර ඔවුන්ගේ රැකියා විස්තරය පැහැදිලි ය. මෘදුකාංග භාවිතා කරනුයේ නොබ්ස් සහ ඩම්මි විසිනි, නපුරු හැකර්වරුන් සහ රති ers ් ers ා ගැන සඳහන් නොකොට, වෙනත් මොඩියුලයන් ( OpenID හෝ ගූගල් ඇඩ්සෙන්ස් වැනි ) සමඟ ඒකාබද්ධ විය යුතුය . මිසයිල හෝ නින්ජා මංකොල්ලකරුවන්ගෙන් බේරී සිටියදී ගුවන් යානයක් ඩම්මි මගින් මෙහෙයවිය හැකි නම්, ගුවන් යානයට මෘදුකාංග සමඟ සමාන ගුණාත්මක බවක් ඇති බව ඔබට පැවසිය හැකිය.

හරස් වේදිකා

ගුවන් යානයක් පියාසර කරන්නේ පෘථිවි අහසේ පමණි. මීදුම හෝ සුළං හෝ උණුසුම්, සීතල හා තෙතමනය සහිත දේශගුණය ඔවුන් හැසිරවිය යුතු ආකාරය ගැන මට සැක නැත, නමුත් ගුවන් යානයක් විවිධ ගුරුත්වාකර්ෂණ මට්ටමින් පියාසර කිරීමට සැලසුම් කර නැත ( අඟහරු වෙත පියාසර කළ හැකි නම් මා මවිතයට පත් වනු ඇත ). සමහර විට, යෙදුමක් බ්‍රව්සරය සඳහා ඉන්ටර්නෙට් එක්ස්ප්ලෝරර්, ගූගල් ක්‍රෝම් , ෆයර්ෆොක්ස් සහ සෆාරි (සමාවෙන්න ඔපෙරා ), හෝ වින්ඩෝස් එක්ස්පී / 7/8, හෝ ඕඑස් මට්ටම සඳහා ලිනක්ස් වැනි විවිධ වේදිකාවලින් නොනැසී පැවතිය යුතුය . ජංගම උපාංග සහ විවිධ විභේදන සහ දිශානතියන් ගැන සඳහන් නොකරමු.

වෙනත් කර්මාන්ත කිසිදු සිදුවීමකින් තොරව ව්‍යාපෘති සම්පුර්ණ කරයි යැයි ඔබ සිතන්නේ නම්, 1977 දී ඉදිකරන ලද සිටිග roup ප් මධ්‍යස්ථාන ගොඩනැගිල්ල පිළිබඳ කතාව ඔබ කියවිය යුතුය. වසර 7 කට ආසන්න කාලයක් සැලසුම් කර ඉදිකිරීම් කර තිබියදීත්, ගොඩනැගිල්ල සම්පූර්ණ කර ඇත්තේ බරපතල සැලසුම් දෝෂයකින් වන අතර එය කඩා වැටීමට හේතු විය. සෑම වසර 16 කට වරක්ම කුණාටු සිදුවීම අපේක්ෂා කෙරේ.

වෙනත් වචන වලින් කිවහොත්, සෑම වසරකම සිටිකෝර්ප් මධ්‍යස්ථානය සිටගෙන සිටියදී, එය කඩා වැටීමට 16 න් 1 ක් පමණ අවස්ථාවක් තිබුණි.

මුල් නිර්මාණකරුවන් ගැටළු පිළිබඳව දැන නොසිටි නමුත් වාසනාවකට එය ගොඩනැගිල්ල හදාරන සිසුවෙකුට හසු විය.

ලෙමෙසියර් පවසන පරිදි ඔහුට දුරකථන ඇමතුමක් ලැබෙන තෙක් සියල්ල හොඳින් පෙනේ. LeMessurier ට අනුව, 1978 දී උපාධි අපේක්ෂක ගෘහ නිර්මාණ ශිල්පියෙකු විසින් LeMessurier ගේ ගොඩනැගිල්ල පිළිබඳව නිර්භීත ප්‍රකාශයක් ලබා ගත්තේය: Citicorp Centre සුළඟට හමා යා හැකි බවට.

සැලසුම් දෝෂයේ රහස්‍යභාවය පවත්වා ගැනීම සඳහා අවම පිරිසකගේ සහභාගීත්වයෙන් රාත්‍රී ආවරණයේ අලුත්වැඩියා කටයුතු සිදු කරන ලදී.

ගොඩනැගිල්ල අවට ඇති කොටස් 10 ක අරය සඳහා හදිසි ඉවත් කිරීමේ සැලැස්මක් සකස් කරන ලදී.

ඔවුන් මුළු රාත්‍රිය පුරාම වෑල්ඩින් කර දිවා කාලයේ සේවයෙන් ඉවත් විය.

ලේඛක ජෝ මෝර්ගන්ස්ටර්න් එය සාදයකදී පවසන බව අසා ලෙමෙසියුරියර් සමඟ සම්මුඛ සාකච්ඡාවක් පවත්වන තෙක් කතාව රහසක්ව පැවතුනි. මෝර්ගන්ස්ටර්න් 1995 දී නිව් යෝර්කර්හි කතාව බිඳ දැමීය.

ප්‍රශ්නය මතු කරන; මහජන පිළිගැනීමකින් තොරව ව්‍යාපෘතිවල ඇති වෙනත් මාරාන්තික සැලසුම් අඩුපාඩු රහසිගතව අලුත්වැඩියා කිරීම හෝ නොසලකා හැරීම.

• NYC අහස උසට නැගුණු නිර්මාණ දෝෂය (slate.com)
• සිටිග roup ප් මධ්‍යස්ථානය (wikipedia.com)