Софтуерни технологии
Изтегляне 2.27 Mb.
|
Свързани:
empty doc
| 15.2. Екстремно програмиране
15.2.1.Heo6xoguмоcm На пръв поглед това, което следва, е в пълно противоречие със системните подходи, основани на сериозни теоретични модели, които бяха изложени в пред- ходните глави. От друга страна, не можем да си затваряме очите за реалността, особено за тази в малките фирми. Когато реализацията на даден софтуерен про- ект лежи върху плещите на 10, а понякога и по-малко специалисти, едва ли е възможно педантично да се приложат организационните и технологичните схе- ми, предлагани от теорията. He e трудно да се повярва например на следните данни: ако една софтуерна фирма има 1500 служители, а друга 150, усилията да се реализира подобряване на софтуерните процеси на основата на СММ (вж. глава 8.) в никакъв случай няма да са 10 пъти по-малки във втората фирма спрямо първата [3]. Изненадата е може би в това, че като се изключи обучени- ето (което е силно зависимо от конкретния брой), за останалите дейности ycu- лията в двете фирми не се отличават особено. Въпреки това е добре извес- 189 тно, че много малки фирми създават отлични по качество софтуерни продукти, спазвайки договорените срокове и постигайки добра рентабилност. Разумният подход е тези факти да не се игнорират, а да се направи опит да се обяснят. Един от тези опити е парадигмата на т. нар. екстремно програмиране, поняко- га обозначавано с акронима ХР (от Extreme Programming). 15.2.2. Корени Този модел има за свой прототип каскадния модел на жизнения цикъл на прог- рамния продукт (вж. 2.3.6.). В най-опростения му вариант може някои фази да се слеят и да се смята, че има 4 фази — анализ, проектиране, програмиране и тества- не. Тези фази в някаква степен могат да се припокриват (например програмирането да започне преди окончателно да е завършено проектирането или пък, съвсем ес- тествено, да има програмиране, след като е вършено тестване). Твърдо се приема още, че потребителят дефинира своите изисквания в началото и после повече не ги променя. И в това е първата неадекватност на този модел. Практиката отдавна е показала, че почти не се срещат сериозни възложители, които да не променят малко или повече изискванията си по време на процеса на разработване на програмния продукт. За да отразят тази особеност, теоретиците предложиха прототипния мо- дел (вж. 2.3.7.). При него до известна степен се допуска повтаряне на някои от фазите (итерации), но не толкова заради променящите се потребителски изисква- ния, колкото с цел по-ранното откриване и преодоляване на неуспешни техноло- гични решения (например непостигане на желаното време за отговор, неудовлет- ворителни от ергономична гледна точка интерфейси и т. н.). Последните две стъп- ки, приближаващи ни към ХР, са еволюционният (вж. 2.3.8.) и спиралният (вж. 2.3.9.) модел. При първия особено се набляга на непрестанно променящите се пот- ребителски изисквания, при втория — на непрекъснатото оценяване на риска. И двата обаче са предназначени да отразяват разработването на големи или относи- телно големи проекти и по необходимост се налага да се предвиждат съответните на мащабите организационни и рискови аспекти. 15.2.3. Същност Постепенно някои от разработчиците решават, че при относително малки проекти могат да доведат тези итерации до крайност, т. е. да повтарят четирите горни фази много пъти, като очевидно при това ги скъсяват до разумния мини- мум [4]. Какъв е този разумен минимум, естествено, не може да се каже с абсо- лютна точност, но един достатъчно конструктивен отговор гласи: дни. Основополагащият принцип е при всяка такава итерация да се подберат едно или малък брой от най-необходимите за потребителя средства (наричани в ХР stories — не превеждаме този термин буквално, защото не го намираме за подходящо) сред всички поискани. Този избор се прави на основата на предпо- лагаемата цена и бързина на реализация и на ценността от гледна точка на пот- ребителя. По-просто казано, избират се за реализация най-напред тези средст- ва (функции), които ще свършат най-много работа на потребителя, а от друга страна, ще бъдат направени качествено за най-кратко време. 190 Доколкото говорим за итерации, ясно е,че веднага щом дадена итерация приключи с предаване на разработените средства на потребителя, започва след- ващата с избор на най-подходящите средства от останалите. Много е важно да се знае, че при този избор решаваща дума има клиентът (възложител, потреби- тел), но на основата на информация, предоставена от разработчика. За програ- мистите остава да направят необходимите технологични стъпки — да декомпо- зират поисканото средство (услуга, функция) до необходимия брой задачи, да ги реализират, тестват и предадат за ползване на клиента. Лесно се вижда, че при този подход четирите фази остават, естествено, в много кратки отрязъци от време. Изтегляне 2.27 Mb. Сподели с приятели:
|