Azərbaycanca AzərbaycancaБеларускі БеларускіDansk DanskDeutsch DeutschEspañola EspañolaFrançais FrançaisIndonesia IndonesiaItaliana Italiana日本語 日本語Қазақ ҚазақLietuvos LietuvosNederlands NederlandsPortuguês PortuguêsРусский Русскийසිංහල සිංහලแบบไทย แบบไทยTürkçe TürkçeУкраїнська Українська中國人 中國人United State United StateAfrikaans Afrikaans
Підтримка
www.wikidata.uk-ua.nina.az

Управління розробкою програмного забезпечення англ Software project management це мистецтво планування і керування проек

Управління розробкою програмного забезпечення

Управління розробкою програмного забезпечення

Управління розробкою програмного забезпечення (англ. Software project management) — це мистецтво планування і керування проектами з розробки програмного забезпечення, особливий вид управління проектами, в рамках якого відбувається планування, реалізація, відслідковування і контроль за проектами з розробки програмного забезпечення.

Історія

У період 1970–1980 років, індустрія програмного забезпечення розвивалася дуже швидко, так як комп'ютерні компанії зауважили, що виробництво програмного забезпечення є набагато дешевшим, ніж виробництво апаратного забезпечення і мікросхем. Для того, щоб керувати розвитком зусиль, компанії застосовували вже встановлені методи з управління проектами, але часто такі методи зазнавали невдачі, особливо коли виникали непорозуміння між початковими експлуатаційними характеристиками і кінцевим програмним забезпеченням. Для того, що уникнти цих проблем, основною ціллю методів управління програмним забезпеченням стала відповідність вимогам користувачів до кінцевого продукту. Цей метод відомий як водоспадна модель.

Дослідження проектів, які зазнали невдачі, показали, що найбільш поширеними причинами провалів були:

  1. Недостатнє залучення кінцевого користувача.
  2. Слабка взаємодія між замовником, розробником програмного забезпечення і користувачем.
  3. Нереальні, чи незрозуміло сформульовані цілі проекту.
  4. Помилковий підрахунок потрібних ресурсів.
  5. Некоректно визначені системні вимоги.
  6. Непоінформованість менеджера проекту про поточний стан проекту.
  7. Некеровані ризики.
  8. Використання надто нових, нестабільних техноногій.
  9. Нездатність впоратися зі складністю проекту.
  10. Слабке управління проектом.
  11. Відсутність виконавчої підтримки між замовником і кінцевим користувачем.
  12. Фінансові обмеження.

Перші п'ять пунктів зі списку вказують на проблеми формулювання потреб клієнта таким чином, що відповідні ресурси можуть поставити належні цілі проекту. Конкретні інструменти управління програмним забезпеченням є корисними і часто необхідними, але справжнім мистецтвом в управлінні проектами з розробки програмного забезпечення є застосовування коректного методу, і потім використання інструментів для підтримки методу. Без методу, інструменти нічого не варті. Починаючи з 1960-х, були вироблені декілька методів для управління проектами з розробки програмного забезпечення, запатентовані виробниками програмного забезпечення для власного використання, в той час як комп'ютерні консалтингові фірми також зробили подібні методи для своїх клієнтів. У наш час, методи управління розробкою програмного забезпечення все ще розвивається, але проглядається тенденція до переходу від водоспадної моделі до більш циклічної моделі, яка імітує процес розробки програмного забезпечення.

Процес розробки програмного забезпечення

Пов'язаний в першу чергу з виробничим аспектом розробки програмного забезпечення, на відміну від технічного аспекту, такого яка інструментальне програмне забезпечення. Ці процеси існують в першу чергу для підтримки управління розробки програмного забезпечення, і, як правило, направлені у бік бізнес-рішення проблеми. Багато процесів розробки програмного забезпечення можуть бути запущені аналогічним чином до загальних процесів управління проектом. Наприклад:

  • Міжособові комунікації управління та вирішення конфліктів. Активна, часта і чесна комунікація — це найбільш важливий фактор в збільшені ймовірності успіху проекту та пом'якшення проблемних проектів. Команда розробників повинна прагнути участі кінцевого користувача і заохочувати його вкладення в процесі розробки. Відсутність користувачів, що залучені до процесу, може привести до неправильного тлумачення вимог, нечутливість до потреб клієнтів і нереалістичні очікування з боку клієнта. Розробникам програмного забезпечення, користувачам, менеджерам проектів, замовникам і спонсорам проекту необхідно регулярно і часто спілкуватися. Інформація, отримана від цих дискусій, дозволяє команді проекту проаналізувати сильні і слабкі сторони, можливості та загрози і діяти відповідно до цієї інформації, щоб отримати вигоду з можливостей і звести до мінімуму загрози. Навіть погані новини можуть бути хорошими, якщо це було обговорено достатньо рано, тому що проблеми можуть бути пом'якшені, якщо вони не виявлені надто пізно. Наприклад, неформальна розмова з користувачами, членами команди, та іншими зацікавленими сторонами може часто вивести на поверхню потенційні проблеми раніше, ніж під час офіційних засідань. Всі комунікації повинні бути інтелектуально чесними і справжніми, і регулярними, критика роботи необхідна для розвитку, але якщо вона здійснюється в спокійній, шанобливій, конструктивній формі, а не у формі обвинувачень і люті. Часті випадкові розмови між розробниками і кінцевими користувачами, так як і між менеджерами та клієнтами проекту необхідні, щоб проект був актуальним, корисним і ефективним для кінцевих користувачів. Ефективне міжособове спілкування та управління конфліктами — це ключ до управління розробкою програмного забезпечення. Немає методології або стратегії покращення процесу, які б могли подолати серйозні проблеми у комунікації або неправильному управлінні міжособових конфліктів. Крім того, результати, пов'язані з такими методологіями і стратегіями, щодо поліпшення процесів, посилюються від кращої комунікації. Комунікація повинна зосередитися на тому, чи розуміє команда статут проекту і чи буде команда робити успіхи в досягненні цієї мети. Кінцеві користувачі, розробники програмного забезпечення та керівники проектів повинні часто задавати елементарні, прості питання, які допоможуть визначити проблеми, перш ніж вони гнитимуть в районі-катастроф. В той час, як участь кінцевого користувача, ефективна комунікація та команда не є достатніми для успіху, вони необхідні, щоб забезпечити хороший результат, і їх відсутність майже точно призведе до поганих результатів
  • Ризик-менеджмент це процес вимірювання або оцінки ризику і потім розробки стратегії управління ризиком. В цілому, стратегії, що використовуються, включають ризик для іншої сторони, уникнення ризику, зниження негативного впливу ризику і приймання всіх або деяких з наслідків конкретного ризику. Управління ризиками в управлінні розробкою програмного забезпевчення починається з Техніко-економічного обґрунтування для запуску проекту, який включає в себе аналіз витрат і вигод, а також список резервних варіантів у випадку провалу проекту, який називається називається резервний план.
    • Ризик-менеджмент включає в себе управління можливостями, що означає те ж саме, за винятком того, що потенційний результат-ризик матиме позитивний, а не негативний вплив. Хоча теоретично обробляються таким же чином, використання терміну «можливість» замість негативного терміну «ризик» допомагає зберегти команду зосередженою на можливих позитивних результатах будь-якого зафіксованого ризику у своїх проектах, таких як спін-оф проекти і безкоштовні додаткові ресурси.
  • Управління вимогами — це процес виявлення, документування, аналізу, відстежування пріоритетів і узгодження вимог, і потім контролювання змін і спілкування з відповідними зацікавленими сторонами. Управління вимогами нової або зміненої комп'ютерної системи, які включає в себе аналіз вимог, є важливою частиною процесу програмної інженерії; в результаті цього бізнес-аналітики або розробники програмного забезпечення визначають потреби або вимоги клієнта; виявивши ці вимоги, можна проектувати рішення.
  • це процес виявлення, документування, аналізу, визначення пріоритетів та узгодження змін Рамки (керування проектами), а потім контролювання змін і спілкування з відповідними зацікавленими сторонами. Змінити аналіз впливу нового або зміненого обсягу, який включає в себе аналіз вимог на рівні змін, є важливою частиною процесу програмної інженерії; в результаті чого бізнес-аналітики або розробник програмного забезпечення визначає змінені потреби або вимоги клієнта; виявивши ці вимоги, можна зробити ре-дизайн або змінити рішення. Теоретично, кожна зміна може вплинути на терміни і бюджет проекту програмного забезпечення, і, отже, за визначенням, кожний проект повинен включати в себе аналіз ризику і користі до затвердження.
  • Керування конфігурацією — це процес виявлення і документування самої сфери, в яку програмний продукт йде, в тому числі всіх субпродуктів та змін, і дозволяє дискутувати на ці теми відповідним зацікавленим сторонам. В цілому, процеси, які використовуються, включають контроль версій і архівні угоди програмного забезпечення.
  • Управління релізами це процес виявлення, документування, визначення пріоритетів та узгодження релізів програмного забезпечення, а потім контролювання графіку випуску та доведення до зацікавлених сторін. Більшість програмних проектів мають доступ до трьох програмних середовищ, в які програмне забезпечення може бути випущене; Розробка, випробування і виробництво. У дуже великих проектах, де розподіленим командам необхідно інтегрувати свою роботу, перш ніж випустити для користувачів, часто буде більше середовищ для тестування, так звані модульні тестування, системні тестування або інтеграційні тестування, до виходу на приймальне тестування.
    • Управління релізами включає , яка поступово набирає уваги. Оскільки, очевидно, що користувачі можуть ґрунтуватися тільки на даних, які доступні їм, і «реальні» дані доступні тільки в програмному середовищі під назвою «виробництво». Для того, щоб перевірити свою роботу, програмісти часто створюють «фіктивних дані» або «заглушки даних». Традиційно, більш старі версії системи виробництва колись використовувалися для цієї мети, але, оскільки компанії все більше покладаються на зовнішніх спонсорів для розробки програмного забезпечення, дані компанії не можуть бути випущені для команди розробників. У складних середовищах, набори даних можуть бути створені так, що потім мігруватимуть через тестові середовища відповідно до графіка випробувань релізу, як і в цілому графіку випуску програмного забезпечення.

Задача (Issue)

В обчисленні, термін issue являє собою одиницю роботи, яку потрібно виконати для покращення в системі. Проблемою може бути помилка, завдання, зникла документація і так далі.

Наприклад, у OpenOffice.org звикли називати їх модифіковану версію Баґзілла IssueZilla. Станом на вересень 2010 року, вони називали свою систему Issue Tracker.

Слово «issue» також використовується як синонім до слова «проблема». Проблеми виникають час від часу і важливо вирішувати їх вчасно, для того, щоб уникнути затримок під час доставки продукції.

Філософія

Оскільки управління розробкою програмного забезпечення є частиною загального управління проектами, дехто вважає, що управління розробкою програмного забезпечення схоже до управління виробництва, яке може бути здійсненим будь-ким з навичками управління, але без навичок програмування. спростовує цю точку зору і стверджує, що розробка програмного забезпечення є повністю дизайнерською роботою, і порівнює менеджерів, які не вміють програмувати, до редакторів з газет, які не вміють писати.

Див. також

Примітки

  1. Stellman, Andrew; Greene, Jennifer (2005). . O'Reilly Media. ISBN . Архів оригіналу за 9 лютого 2015. Процитовано 6 червня 2015.
  2. «Why Software Fails» [ 21 грудня 2011 у Wayback Machine.], in IEEE Spectrum
  3. Producing Open Source Software: How to Run a Successful Free Software Project (e-book, freely downloadable), by Karl Fogel
  4. Robert Frese and Vicki Sauter, "Improving your odds for software project success, " , Vol. 42, No. 4, Fourth Quarter, Dec 2014
  5. , in Jessica Livingston's (2007),
  6. John C. Reynolds, Some thoughts on teaching programming and programming languages, Notices, Volume 43, Issue 11, November 2008, p.108: «Some argue that one can manage software production without the ability to program. This belief seems to arise from the mistaken view that software production is a form of manufacturing. But manufacturing is the repeated construction of identical objects, while software production is the construction of unique objects, i.e., the entire process is a form of design. As such it is closer to the production of a newpaper [sic] — so that a software manager who cannot program is akin to a managing editor who cannot write.»

Посилання

  • from

Вікіпедія, Українська, Україна, книга, книги, бібліотека, стаття, читати, завантажити, безкоштовно, безкоштовно завантажити, mp3, відео, mp4, 3gp, jpg, jpeg, gif, png, малюнок, музика, пісня, фільм, книга, гра, ігри, мобільний, телефон, android, ios, apple, мобільний телефон, samsung, iphone, xiomi, xiaomi, redmi, honor, oppo, nokia, sonya, mi, ПК, web, Інтернет

Upravlinnya rozrobkoyu programnogo zabezpechennya angl Software project management ce mistectvo planuvannya i keruvannya proektami z rozrobki programnogo zabezpechennya osoblivij vid upravlinnya proektami v ramkah yakogo vidbuvayetsya planuvannya realizaciya vidslidkovuvannya i kontrol za proektami z rozrobki programnogo zabezpechennya IstoriyaU period 1970 1980 rokiv industriya programnogo zabezpechennya rozvivalasya duzhe shvidko tak yak komp yuterni kompaniyi zauvazhili sho virobnictvo programnogo zabezpechennya ye nabagato deshevshim nizh virobnictvo aparatnogo zabezpechennya i mikroshem Dlya togo shob keruvati rozvitkom zusil kompaniyi zastosovuvali vzhe vstanovleni metodi z upravlinnya proektami ale chasto taki metodi zaznavali nevdachi osoblivo koli vinikali neporozuminnya mizh pochatkovimi ekspluatacijnimi harakteristikami i kincevim programnim zabezpechennyam Dlya togo sho uniknti cih problem osnovnoyu cillyu metodiv upravlinnya programnim zabezpechennyam stala vidpovidnist vimogam koristuvachiv do kincevogo produktu Cej metod vidomij yak vodospadna model Doslidzhennya proektiv yaki zaznali nevdachi pokazali sho najbilsh poshirenimi prichinami provaliv buli Nedostatnye zaluchennya kincevogo koristuvacha Slabka vzayemodiya mizh zamovnikom rozrobnikom programnogo zabezpechennya i koristuvachem Nerealni chi nezrozumilo sformulovani cili proektu Pomilkovij pidrahunok potribnih resursiv Nekorektno viznacheni sistemni vimogi Nepoinformovanist menedzhera proektu pro potochnij stan proektu Nekerovani riziki Vikoristannya nadto novih nestabilnih tehnonogij Nezdatnist vporatisya zi skladnistyu proektu Slabke upravlinnya proektom Vidsutnist vikonavchoyi pidtrimki mizh zamovnikom i kincevim koristuvachem Finansovi obmezhennya Pershi p yat punktiv zi spisku vkazuyut na problemi formulyuvannya potreb kliyenta takim chinom sho vidpovidni resursi mozhut postaviti nalezhni cili proektu Konkretni instrumenti upravlinnya programnim zabezpechennyam ye korisnimi i chasto neobhidnimi ale spravzhnim mistectvom v upravlinni proektami z rozrobki programnogo zabezpechennya ye zastosovuvannya korektnogo metodu i potim vikoristannya instrumentiv dlya pidtrimki metodu Bez metodu instrumenti nichogo ne varti Pochinayuchi z 1960 h buli virobleni dekilka metodiv dlya upravlinnya proektami z rozrobki programnogo zabezpechennya zapatentovani virobnikami programnogo zabezpechennya dlya vlasnogo vikoristannya v toj chas yak komp yuterni konsaltingovi firmi takozh zrobili podibni metodi dlya svoyih kliyentiv U nash chas metodi upravlinnya rozrobkoyu programnogo zabezpechennya vse she rozvivayetsya ale proglyadayetsya tendenciya do perehodu vid vodospadnoyi modeli do bilsh ciklichnoyi modeli yaka imituye proces rozrobki programnogo zabezpechennya Proces rozrobki programnogo zabezpechennyaPov yazanij v pershu chergu z virobnichim aspektom rozrobki programnogo zabezpechennya na vidminu vid tehnichnogo aspektu takogo yaka instrumentalne programne zabezpechennya Ci procesi isnuyut v pershu chergu dlya pidtrimki upravlinnya rozrobki programnogo zabezpechennya i yak pravilo napravleni u bik biznes rishennya problemi Bagato procesiv rozrobki programnogo zabezpechennya mozhut buti zapusheni analogichnim chinom do zagalnih procesiv upravlinnya proektom Napriklad Mizhosobovi komunikaciyi upravlinnya ta virishennya konfliktiv Aktivna chasta i chesna komunikaciya ce najbilsh vazhlivij faktor v zbilsheni jmovirnosti uspihu proektu ta pom yakshennya problemnih proektiv Komanda rozrobnikiv povinna pragnuti uchasti kincevogo koristuvacha i zaohochuvati jogo vkladennya v procesi rozrobki Vidsutnist koristuvachiv sho zalucheni do procesu mozhe privesti do nepravilnogo tlumachennya vimog nechutlivist do potreb kliyentiv i nerealistichni ochikuvannya z boku kliyenta Rozrobnikam programnogo zabezpechennya koristuvacham menedzheram proektiv zamovnikam i sponsoram proektu neobhidno regulyarno i chasto spilkuvatisya Informaciya otrimana vid cih diskusij dozvolyaye komandi proektu proanalizuvati silni i slabki storoni mozhlivosti ta zagrozi i diyati vidpovidno do ciyeyi informaciyi shob otrimati vigodu z mozhlivostej i zvesti do minimumu zagrozi Navit pogani novini mozhut buti horoshimi yaksho ce bulo obgovoreno dostatno rano tomu sho problemi mozhut buti pom yaksheni yaksho voni ne viyavleni nadto pizno Napriklad neformalna rozmova z koristuvachami chlenami komandi ta inshimi zacikavlenimi storonami mozhe chasto vivesti na poverhnyu potencijni problemi ranishe nizh pid chas oficijnih zasidan Vsi komunikaciyi povinni buti intelektualno chesnimi i spravzhnimi i regulyarnimi kritika roboti neobhidna dlya rozvitku ale yaksho vona zdijsnyuyetsya v spokijnij shanoblivij konstruktivnij formi a ne u formi obvinuvachen i lyuti Chasti vipadkovi rozmovi mizh rozrobnikami i kincevimi koristuvachami tak yak i mizh menedzherami ta kliyentami proektu neobhidni shob proekt buv aktualnim korisnim i efektivnim dlya kincevih koristuvachiv Efektivne mizhosobove spilkuvannya ta upravlinnya konfliktami ce klyuch do upravlinnya rozrobkoyu programnogo zabezpechennya Nemaye metodologiyi abo strategiyi pokrashennya procesu yaki b mogli podolati serjozni problemi u komunikaciyi abo nepravilnomu upravlinni mizhosobovih konfliktiv Krim togo rezultati pov yazani z takimi metodologiyami i strategiyami shodo polipshennya procesiv posilyuyutsya vid krashoyi komunikaciyi Komunikaciya povinna zosereditisya na tomu chi rozumiye komanda statut proektu i chi bude komanda robiti uspihi v dosyagnenni ciyeyi meti Kincevi koristuvachi rozrobniki programnogo zabezpechennya ta kerivniki proektiv povinni chasto zadavati elementarni prosti pitannya yaki dopomozhut viznachiti problemi persh nizh voni gnitimut v rajoni katastrof V toj chas yak uchast kincevogo koristuvacha efektivna komunikaciya ta komanda ne ye dostatnimi dlya uspihu voni neobhidni shob zabezpechiti horoshij rezultat i yih vidsutnist majzhe tochno prizvede do poganih rezultativ Rizik menedzhment ce proces vimiryuvannya abo ocinki riziku i potim rozrobki strategiyi upravlinnya rizikom V cilomu strategiyi sho vikoristovuyutsya vklyuchayut rizik dlya inshoyi storoni uniknennya riziku znizhennya negativnogo vplivu riziku i prijmannya vsih abo deyakih z naslidkiv konkretnogo riziku Upravlinnya rizikami v upravlinni rozrobkoyu programnogo zabezpevchennya pochinayetsya z Tehniko ekonomichnogo obgruntuvannya dlya zapusku proektu yakij vklyuchaye v sebe analiz vitrat i vigod a takozh spisok rezervnih variantiv u vipadku provalu proektu yakij nazivayetsya nazivayetsya rezervnij plan Rizik menedzhment vklyuchaye v sebe upravlinnya mozhlivostyami sho oznachaye te zh same za vinyatkom togo sho potencijnij rezultat rizik matime pozitivnij a ne negativnij vpliv Hocha teoretichno obroblyayutsya takim zhe chinom vikoristannya terminu mozhlivist zamist negativnogo terminu rizik dopomagaye zberegti komandu zoseredzhenoyu na mozhlivih pozitivnih rezultatah bud yakogo zafiksovanogo riziku u svoyih proektah takih yak spin of proekti i bezkoshtovni dodatkovi resursi Upravlinnya vimogami ce proces viyavlennya dokumentuvannya analizu vidstezhuvannya prioritetiv i uzgodzhennya vimog i potim kontrolyuvannya zmin i spilkuvannya z vidpovidnimi zacikavlenimi storonami Upravlinnya vimogami novoyi abo zminenoyi komp yuternoyi sistemi yaki vklyuchaye v sebe analiz vimog ye vazhlivoyu chastinoyu procesu programnoyi inzheneriyi v rezultati cogo biznes analitiki abo rozrobniki programnogo zabezpechennya viznachayut potrebi abo vimogi kliyenta viyavivshi ci vimogi mozhna proektuvati rishennya ce proces viyavlennya dokumentuvannya analizu viznachennya prioritetiv ta uzgodzhennya zmin Ramki keruvannya proektami a potim kontrolyuvannya zmin i spilkuvannya z vidpovidnimi zacikavlenimi storonami Zminiti analiz vplivu novogo abo zminenogo obsyagu yakij vklyuchaye v sebe analiz vimog na rivni zmin ye vazhlivoyu chastinoyu procesu programnoyi inzheneriyi v rezultati chogo biznes analitiki abo rozrobnik programnogo zabezpechennya viznachaye zmineni potrebi abo vimogi kliyenta viyavivshi ci vimogi mozhna zrobiti re dizajn abo zminiti rishennya Teoretichno kozhna zmina mozhe vplinuti na termini i byudzhet proektu programnogo zabezpechennya i otzhe za viznachennyam kozhnij proekt povinen vklyuchati v sebe analiz riziku i koristi do zatverdzhennya Keruvannya konfiguraciyeyu ce proces viyavlennya i dokumentuvannya samoyi sferi v yaku programnij produkt jde v tomu chisli vsih subproduktiv ta zmin i dozvolyaye diskutuvati na ci temi vidpovidnim zacikavlenim storonam V cilomu procesi yaki vikoristovuyutsya vklyuchayut kontrol versij i arhivni ugodi programnogo zabezpechennya Upravlinnya relizami ce proces viyavlennya dokumentuvannya viznachennya prioritetiv ta uzgodzhennya reliziv programnogo zabezpechennya a potim kontrolyuvannya grafiku vipusku ta dovedennya do zacikavlenih storin Bilshist programnih proektiv mayut dostup do troh programnih seredovish v yaki programne zabezpechennya mozhe buti vipushene Rozrobka viprobuvannya i virobnictvo U duzhe velikih proektah de rozpodilenim komandam neobhidno integruvati svoyu robotu persh nizh vipustiti dlya koristuvachiv chasto bude bilshe seredovish dlya testuvannya tak zvani modulni testuvannya sistemni testuvannya abo integracijni testuvannya do vihodu na prijmalne testuvannya Upravlinnya relizami vklyuchaye yaka postupovo nabiraye uvagi Oskilki ochevidno sho koristuvachi mozhut gruntuvatisya tilki na danih yaki dostupni yim i realni dani dostupni tilki v programnomu seredovishi pid nazvoyu virobnictvo Dlya togo shob pereviriti svoyu robotu programisti chasto stvoryuyut fiktivnih dani abo zaglushki danih Tradicijno bilsh stari versiyi sistemi virobnictva kolis vikoristovuvalisya dlya ciyeyi meti ale oskilki kompaniyi vse bilshe pokladayutsya na zovnishnih sponsoriv dlya rozrobki programnogo zabezpechennya dani kompaniyi ne mozhut buti vipusheni dlya komandi rozrobnikiv U skladnih seredovishah nabori danih mozhut buti stvoreni tak sho potim migruvatimut cherez testovi seredovisha vidpovidno do grafika viprobuvan relizu yak i v cilomu grafiku vipusku programnogo zabezpechennya Zadacha Issue V obchislenni termin issue yavlyaye soboyu odinicyu roboti yaku potribno vikonati dlya pokrashennya v sistemi Problemoyu mozhe buti pomilka zavdannya znikla dokumentaciya i tak dali Napriklad u OpenOffice org zvikli nazivati yih modifikovanu versiyu Bagzilla IssueZilla Stanom na veresen 2010 roku voni nazivali svoyu sistemu Issue Tracker Slovo issue takozh vikoristovuyetsya yak sinonim do slova problema Problemi vinikayut chas vid chasu i vazhlivo virishuvati yih vchasno dlya togo shob uniknuti zatrimok pid chas dostavki produkciyi FilosofiyaOskilki upravlinnya rozrobkoyu programnogo zabezpechennya ye chastinoyu zagalnogo upravlinnya proektami dehto vvazhaye sho upravlinnya rozrobkoyu programnogo zabezpechennya shozhe do upravlinnya virobnictva yake mozhe buti zdijsnenim bud kim z navichkami upravlinnya ale bez navichok programuvannya sprostovuye cyu tochku zoru i stverdzhuye sho rozrobka programnogo zabezpechennya ye povnistyu dizajnerskoyu robotoyu i porivnyuye menedzheriv yaki ne vmiyut programuvati do redaktoriv z gazet yaki ne vmiyut pisati Div takozhMetodologiya programuvannya Upravlinnya proektami Programna inzheneriya Rizik menedzhmentPrimitkiStellman Andrew Greene Jennifer 2005 O Reilly Media ISBN 978 0 596 00948 9 Arhiv originalu za 9 lyutogo 2015 Procitovano 6 chervnya 2015 Why Software Fails 21 grudnya 2011 u Wayback Machine in IEEE Spectrum Producing Open Source Software How to Run a Successful Free Software Project e book freely downloadable by Karl Fogel Robert Frese and Vicki Sauter Improving your odds for software project success Vol 42 No 4 Fourth Quarter Dec 2014 in Jessica Livingston s 2007 ISBN 1 59059 714 1 John C Reynolds Some thoughts on teaching programming and programming languages Notices Volume 43 Issue 11 November 2008 p 108 Some argue that one can manage software production without the ability to program This belief seems to arise from the mistaken view that software production is a form of manufacturing But manufacturing is the repeated construction of identical objects while software production is the construction of unique objects i e the entire process is a form of design As such it is closer to the production of a newpaper sic so that a software manager who cannot program is akin to a managing editor who cannot write Posilannyafrom

Дата публікації:
Топ