Мифтік адам-ай - The Mythical Man-Month - Wikipedia

Мифтік адам-ай
Мифтік адам-ай (кітап мұқабасы) .jpg
Бірінші басылым
АвторФредерик Брукс
ТақырыпБағдарламалық жасақтама жоба менеджменті
БаспагерАддисон-Уэсли
Жарияланған күні
1975
ISBN0-201-00650-2 (1975 ж.), 0-201-83595-9 (1995 ж.)
OCLC1201368
001.6/425
LC сыныбыQA76.6 .B75
Ілесуші"Күміс оқ жоқ

Мифтік адам-ай: бағдарламалық жасақтама туралы очерктер туралы кітап бағдарламалық жасақтама және жоба менеджменті арқылы Фред Брукс Алғаш рет 1975 жылы, 1982 және 1995 жылдардағы кейінгі басылымдарымен жарық көрді. Оның басты тақырыбы «кеш бағдарламалық жасақтамаға жұмыс күшін қосу кейінірек жасайды». Бұл идея белгілі Брукс заңы, және бірге ұсынылған екінші жүйелік әсер және адвокаттық қызмет прототиптеу.

Бруктың бақылаулары оның тәжірибесіне негізделген IBM дамуын басқару кезінде OS / 360. Ол көбірек қосты бағдарламашылар жоспардан кешеуілдеп келе жатқан жобаға, ол кейінірек тұжырым жасайтын шешім, интуитивті түрде жобаны одан әрі кешіктірді. Ол сондай-ақ бір жоба - ан жазуға қатысты деп қателесті АЛГОЛ құрастырушы - жұмысқа тартылған жұмысшылардың санына қарамастан, алты ай қажет болады (бұл ұзақ уақытты қажет етеді). Менеджерлердің жобаны дамытудағы осындай қателіктерді қайталау тенденциясы Бруксты оның кітабы «Інжіл бағдарламалық жасақтама» деп атады деп күдіктенуге мәжбүр етті, өйткені «бәрі оны дәйексөз етеді, кейбіреулер оқиды, ал бірнеше адам сол арқылы жүреді».[1]Кітап бағдарламалық жасақтаманың адами элементтері туралы классика ретінде кеңінен танымал.[2]

Басылымдар

Еңбек алғаш рет 1975 жылы жарық көрді (ISBN  0-201-00650-2), 1982 жылы түзетулермен қайта басылып, 1995 жылы төрт қосымша тараумен мерейтойлық басылымда қайта басылды (ISBN  0-201-83595-9), оның ішінде эссені қайта басу »Күміс оқ жоқ »автордың түсініктемесімен.

Ұсынылған идеялар

Мифтік адам айы

Брукс жоспарлаудың бұзылуының бірнеше себептерін қарастырады. Ең тұрақты - оны талқылау Брукс заңы:Кешіктірілген бағдарламалық жасақтама жұмыс күшін қосу оны кейінірек жасайды. Адам-ай бұл бір адамның бір айда жасаған жұмысын білдіретін гипотетикалық жұмыс бірлігі; Брукс заңы пайдалы жұмысты адам айларында өлшеу мүмкіндігі аңыз болып табылады, демек, кітаптың өзегі болып табылады дейді.

Кешенді бағдарламалау жобаларын жұмысшылар арасындағы байланыссыз және тапсырмалар мен оларды орындайтын жұмысшылар арасындағы күрделі өзара байланыс жиынтығынсыз жұмыс істеуге болатын дискретті тапсырмаларға бөлуге болмайды.

Сондықтан, жоспардан тыс жұмыс істейтін жобаға көптеген бағдарламашылар тағайындау оны кейінірек жасайды. Себебі, жаңа бағдарламашыларға жоба туралы білуге ​​қажет уақыт пен байланыстың жоғарылауы қол жетімді күнтізбелік уақыттың көбеюін қажет етеді. Қашан n адамдар өзара сөйлесуі керек, өйткені n ұлғаяды, олардың өнімділігі азаяды және теріс болған кезде жоба әр қосымша қосылған сайын кешіктіріледі.

  • Байланыстың топтық формуласы: n(n − 1) / 2
  • Мысал: 50 әзірлеуші ​​50 · (50 - 1) / 2 = 1225 байланыс арналарын береді.

Күміс оқ жоқ

Брукс қосылды «Күміс оқ жоқ - бағдарламалық жасақтаманың мәні мен апаттары»- және бұл туралы әрі қарай ой қозғау, «» Күміс оқ жоқ «жоқ»- мерейтойлық басылымға Мифтік адам-ай.

Брукс ешкім жоқ деп талап етеді күміс оқ - «технологияда да, басқару техникасында да бір өзі жоқ, ол өздігінен біреуін де уәде етеді шама [он есе] өнімділікті, сенімділікті және қарапайымдылықты жақсарту ».

Дәлел кездейсоқ күрделілік пен жолға ұқсас маңызды күрделіліктің арасындағы айырмашылыққа сүйенеді Амдал заңы «қатаң сериялық» және «параллельді» арасындағы айырмашылыққа сүйенеді.

Екінші жүйелік әсер

The екінші жүйелік әсер Сәулетші екінші жүйені жобалаған кезде, бұл олар ойлап тапқан ең қауіпті жүйе деп болжайды, өйткені олар уақыттың шектеулілігіне байланысты алғашқы жүйеге қоспаған барлық қосымшаларды қосады. Осылайша, екінші жүйеге кіріскенде, инженер оны шамадан тыс жобалауға бейім екенін ескеруі керек.

Төмендетілген қателіктерге бейімділік

Кодтағы 99 кішкентай қателер.

99 кішкентай қателер.
Біреуін түсіріңіз, айналасына жамаңыз.

Кодтағы 127 қате ...[3]

Автор сәйкесінше күрделі жүйеде белгілі бір азаймайтын қателіктер бар екенін байқады. Байқалған қателіктерді түзетудің кез-келген әрекеті басқа қателерді енгізуге әкеледі.

Прогрессті бақылау

Брукс «Сұрақ: Үлкен бағдарламалық жасақтама қалайша бір жылға кешігіп қалады? Жауап: Бір уақытта бір күн!» Көптеген фронттардың өсіп келе жатқан сырғулары ақыр соңында жинақталып, жалпы кешігуді тудырады. Менеджменттің әр деңгейінде кішігірім жеке межелерге қол жеткізуге үнемі назар аудару қажет.

Тұжырымдамалық тұтастық

Қолданушыға ыңғайлы жүйені құру үшін жүйенің тұжырымдамалық тұтастығы болуы керек, оған архитектураны іске асырудан бөлу арқылы ғана қол жеткізуге болады. Пайдаланушы атынан әрекет ететін жалғыз бас сәулетші (немесе сәулетшілердің аз бөлігі) жүйеде не болатынын және не қалатындығын шешеді. Сәулетші немесе сәулетшілер тобы жүйенің не істеуі керек екендігі туралы идеяны дамытып, осы көріністі топтың қалған мүшелері түсінетініне көз жеткізуі керек. Біреудің жаңа идеясы, егер ол жүйенің жалпы дизайнымен үйлесімді болмаса, енгізілмеуі мүмкін. Шын мәнінде, ыңғайлы жүйені қамтамасыз ету үшін жүйе әдейі ұсынуы мүмкін азырақ мүмкіндіктеріне қарағанда ерекшеліктері. Мәселе, егер жүйені қолдану өте күрделі болса, көптеген мүмкіндіктер пайдаланылмай қалады, өйткені оларды үйренуге ешкімнің уақыты жоқ.

Нұсқаулық

Бас сәулетші жүйенің техникалық сипаттамалары бойынша нұсқаулық шығарады. Ол жүйенің сыртқы сипаттамаларын егжей-тегжейлі сипаттауы керек, яғни, қолданушы көретін барлық нәрсе. Нұсқаулықты өзгерту керек, өйткені іске асыру топтары мен пайдаланушылардан кері байланыс түседі.

Пилоттық жүйе

Жүйенің жаңа түрін жобалау кезінде команда болады лақтыру жүйесін жобалау (қаласа да, қаламаса да). Бұл жүйе кейіннен жүйені толықтай қайта құруға себеп болатын тәсілдерді ашатын «пилоттық жоспар» рөлін атқарады. Осы екінші, ақылды жүйе тапсырыс берушіге жеткізілетін жүйе болуы керек, өйткені пилоттық жүйені жеткізу тұтынушыға азаптан басқа ешнәрсе әкелмейді, мүмкін жүйенің және тіпті компанияның беделін түсіреді.

Ресми құжаттар

Жобаның кез-келген менеджері жобаның мақсаттарын, оларға қалай қол жеткізуге болатындығын, оларға кім жететінін, қашан қол жеткізілетінін және қанша тұратындығын анықтайтын ресми құжаттардың кішігірім негізгі жиынтығын құруы керек. Сондай-ақ, бұл құжаттарда көрінбейтін сәйкессіздіктер анықталуы мүмкін.

Жобаны бағалау

Жоба уақытын бағалаған кезде мұны есте ұстаған жөн бағдарламалау өнімдері (оларды төлем жасаушы клиенттерге сатуға болады) және бағдарламалау жүйелерін жазу қарапайым тәуелсіз ішкі бағдарламалардан үш есе қиын.[4] Әкімшілік немесе басқа техникалық емес тапсырмалардан, мысалы, жиналыстардан, әсіресе «тұру» немесе «қолмен» жиналыстан айырмашылығы, жұмыс аптасының көп бөлігі техникалық мәселелерге жұмсалатындығын есте ұстаған жөн.

Байланыс

Апаттың алдын алу үшін жобада жұмыс жасайтын барлық топтар бір-бірімен мүмкіндігінше байланыста болулары керек - электрондық пошта, телефон, кездесулер, жадынамалар және т.с.с. мүлдем дұрыс емес болуы мүмкін жорамалды бастамас бұрын, өздері жүзеге асыратын функцияға деген ниеттерін нақтылау. Сәулетші (лер) жобаның топтық суретін құруға және оны басқаларға жеткізуге жауапты.

Хирургиялық топ

Операция кезіндегі хирургиялық топты ең маңызды жұмысты орындайтын бір хирург басқаратын болса, топты онша маңызды емес бөліктерге көмектесуге бағыттай отырып, «жақсы» бағдарламашының жүйенің маңызды компоненттерін әзірлеуі орынды сияқты, ал қалған командалар керек уақытта не керек. Сонымен қатар, Брукс «жақсы» бағдарламашылар негізінен орташа есеппен салыстырғанда бес-он есе өнімді екендігі туралы айтады.

Кодты тоқтату және жүйенің нұсқасы

Бағдарламалық жасақтама көрінбейді. Сондықтан, көп нәрсе пайдаланушыға оны сезінуге мүмкіндік беретін жаңа жүйеде белгілі бір жұмыс жасалғаннан кейін ғана айқын болады. Бұл тәжірибе пайдаланушының қажеттіліктерін немесе пайдаланушының қажеттіліктерін қабылдауды өзгертетін түсініктер береді. Сондықтан жүйені пайдаланушының өзгерген талаптарын орындау үшін өзгерту керек. Бұл тек белгілі бір уақытқа дейін болуы мүмкін, әйтпесе жүйе ешқашан аяқталмауы мүмкін. Белгілі бір күнде жүйеге өзгертулер енгізілмеуі керек және код қатып қалуы керек. Өзгертулер туралы барлық сұраныстар кейінге қалдырылуы керек Келесі жүйенің нұсқасы.

Мамандандырылған құралдар

Әрбір бағдарламашының жеке құралдар жиынтығының орнына әр командада белгілі бір құрал жасаушы болуы керек, ол команда орындайтын жұмысына өте ыңғайлы құралдарды жасай алады, мысалы, спецификацияға негізделген код жасайтын код генераторының құралы. Сонымен қатар, жалпы жүйелік құралдарды жоба менеджері бақылайтын жалпы құралдар тобы құруы керек.

Бағдарламалық жасақтама шығындарын төмендету

Брукс жазатын бағдарламалық жасақтама шығындарын төмендетудің екі әдісі бар:

  • Жүзеге асырушыларды жүйенің архитектурасы аяқталғаннан кейін ғана алуға болады (бірнеше айға созылатын қадам, бұл мерзімде мерзімінен бұрын жалданған бағдарламашылардың ешнәрсесі болмауы мүмкін).
  • Брукс айтқан тағы бір әдіс - бұл бағдарламалық жасақтаманы мүлде жасамау, оны жай сатып алу »дайын «мүмкіндігінше.

Сондай-ақ қараңыз

Библиография

Әдебиеттер тізімі

  1. ^ Рот, Даниэль (2005-12-12). «Жиі дәйексөз келтіріледі, сирек кездеседі». CNN. Алынған 2010-10-23.
  2. ^ «Хакерлердің кітап сөресіндегі үздік 9½». Алынған 2010-10-23.
  3. ^ Бұл әзіл-оспақты ән 99 бөтелке сыра кемінде 2000 жылдан бері хабарландыру тақталарында (Анонимді (2000). «Компьютерлік бағдарламалауға дәйексөздер».)
  4. ^ Мифтік адам айы 1.1-сурет, 13-бет

Сыртқы сілтемелер