Технологии за програмиране (Софтуерно инженерство)

Цялата съвкупност от разработки, в зависимост от броя на участниците и видовете взаимоотношения между тях, може да се сведе до триадата от разработки, показана на фиг. 3.21.

технологии

6.1. Авторска разработка

Обичам да съм сам, дори когато съм сам. F. Ренар

Авторската разработка е принципът на създаване на софтуерни продукти, при който целият жизнен цикъл на разработка се поддържа от едно лице.

Развитието на автора включва само постигане на професионален успех, слава и слава. Това е съвсем реално, просто трябва да изберете правилната професионална "ниша", областта на развитие.

6.2. Развитие на екипа

Лесно е да събереш стадо овце, трудно е да събереш стадо котки. С. П. Капица

Един от основните въпроси на колективното развитие е разделението на труда - от равни съизпълнители до организация под формата на твърда йерархия (например екип на главния програмист).

За първите опити на колективно разработване Известно е, че първото колективно разработване на програми е извършено приблизително по този начин. Шефът извърши разделянето на голям проект на по-малки части и го предаде по-нагоре в йерархията. След известно време, сега отдолу нагоре, програмата беше сглобена от написаните фрагменти. Не винаги беше възможно да се сглоби работещ софтуерен продукт.

6.2.1. Роли в техническия екип

Екип от равностойни съизпълнители обикновено се състои от специалисти, които се занимават с приблизително сходни задачи в рамките на един и същи проект. Естествено в една бригада може да има няколко специализации. В сек. 1.7.6.2 вече е дал приблизителния състав на такъв екип за разработка. Припомнете си го:

  • инженери по разработка (специалисти по инженерствопрограмиране и програмисти);
  • технически писатели;
  • тестващи инженери;
  • инженери по качеството;
  • поддържащи продукти;
  • специалисти по продажби на продукти.

От изброените специализации много интересна е специализацията на системния интегратор. Основните задачи на системния интегратор са да предложи на клиента решение на неговия проблем, като избере най-достъпното и технически приемливо и да го приложи. Така системният интегратор продава решения и отговаря за тяхното внедряване. Системният интегратор, като професионалист, трябва да има познания от много области – приложен и системен софтуер, системна администрация, хардуер, мрежи, икономика и др.

Екипът на главния програмист

- Защо екипът на Бърза помощ е от двама лекари? - Единият знае къде да сложи клизма, а другият - защо! Шега за екипната специализация

Харлан Милс [Brooks 1999] предложи да се организират екипи от главни програмисти, подобни на хирургическите екипи. Само един член на екипа е ангажиран с основната работа, останалите му оказват всякаква подкрепа. Екипът на главния програмист включва десет души, които изпълняват специализирани роли в екипа (Фигура 3.22).

софтуерно

6.2.2. Психологически екипни роли

Роб Томсет [Thomsett 1990] предлага осем ключови роли в проекта (Фигура 3.23).

софтуерно
  • председател. Избира пътя, по който екипът се движи напред към общи цели. Умее да идентифицира силните и слабите страни на екипа и да осигури максимално използване на потенциала на всеки член.
  • Архитект. Освен това е и декоратор. Придава завършен вид на действията на отбора.Има ясно разбиране за проблемите и възможните им решения.
  • Генератор на идеи. Предлага радикално нови идеи и стратегии, нови подходи за решаване на проблемите, пред които е изправена групата. Обръща специално внимание на основните проблеми.
  • Критик. Той е и скептик, който оценява проблемите от прагматична гледна точка. Търси недостатъци, недостатъци и несъвършенства. Компенсира оптимизма на генератора на идеи.
  • Изпълнител. Човекът, който всъщност пише кода. По правило той няма широчина на хоризонтите.
  • Финал. Подпомага упоритостта на екипа в постигането на целта. Играе доминираща роля в крайните етапи на развитие.
  • Дипломат. Подпомага силата на духа на участниците в проекта. Помага им в трудни ситуации. Опитва се да подобри взаимоотношенията в екипа.
  • Организатор. Открива и съобщава нови идеи, разработки и ресурси. Има много приятели и връзки в организацията си, чрез които може да измоли или заеме необходимите ресурси.

В реални екипи от програмисти не всички от тези роли могат да бъдат разграничени. Ролята на изпълнителя често се поема от няколко членове на екипа наведнъж.

6.2.3. Видове съвместни дейности

Съвместното развитие включва голям брой различни дейности и степента на съвместна дейност може да варира значително от една дейност до друга. Има четири вида съвместни дейности [Robillard, Robillard 2000].

  • Мандатна дейност, обикновено представена от официални срещи, провеждани редовно. Срещите обикновено се планират предварително и присъствието е задължително. Статистиката показва, че програмистите прекарват около 4% от работното си време на срещи.
  • Свикваща дейност, която имамясто в случай на решение на двама или повече програмисти да се съберат, за да разрешат някакъв технически проблем. Такива срещи обикновено не се планират предварително и в тях участват само програмисти, които наистина са заинтересовани от решаването на проблема. Тази дейност отнема около 14% от работното време.
  • Естествено сътрудничество възниква, когато поне двама програмисти работят по една и съща задача едновременно и споделят информация за извършената работа. Тази дейност отнема около 41% от работното време.
  • Индивидуалната дейност се извършва, когато програмист работи върху задача, която не се изпълнява по същото време от друг програмист и следователно е малко вероятно да взаимодейства по темата с други програмисти в групата. Тази дейност също заема около 41% от работното време.

6.3. Модел за развитие на общността

Съвършенството в един проект се постига не когато няма какво да се добави, а когато няма какво да се отнеме. Антоан дьо Сент-Екзюпери

Идеологията на модела на развитие на общността („базар“) е формулирана в политическата статия на Ерик Реймънд „Катедралата и базарът“ (http://www.tuxedo.org/

esr/писания/катедрала-базар/). Моделът на общността се характеризира с три основни фактора.

  • Децентрализирано развитие. Няма горна граница за броя на хората, участващи в проекта. По правило разработките от този тип се извършват на базата на Интернет и могат да включват всеки заинтересован разработчик на Мрежата.
  • Разработката е базирана на текстове с отворен код. Използвайки ги, можете да разберете същността на задачата и да се свържете с разработката по всяко време.
  • Голям брой външни тестери (бета тестери), които ви позволяват бързооткриване на грешки и проблеми в програмата.

Ерик Реймънд предложи няколко урока, за да ви помогне да разберете по-добре естеството на развитието на общността.

  • Всяка добра програма започва с ентусиазма на разработчика.
  • Добрите програмисти знаят какво може да се напише, великите програмисти знаят какво може да се пренапише.
  • С правилното отношение интересен проблем ще ви намери.
  • Когато загубите интерес към дадена програма, вашето последно задължение е да я предадете на компетентен наследник.
  • Пускане на ранни и чести версии на софтуера.
  • Различни хора могат да открият проблема и да го отстранят.
  • Понякога използването на потребителски идеи е по-добро от използването на вашите собствени идеи.