Софтуерни технологии
ОРГАНИЗАЦИОННО УПРАВЛЕНИЕ
Изтегляне 3.19 Mb.
|
- Навигация на страницата:
- 9.2. Основни понятия
- 9.3. Управление на софтуерни проекти
- 9.4. Планиране
- 9.5. Анализ и управление на риска
- 9.6. Организация на софтуерните проекти
- Задачи Трудоемкост (човекочаса)
- Задача Трудоемкост (човекочаса) Трудоемкост (човекодни)
9. ОРГАНИЗАЦИОННО УПРАВЛЕНИЕ Литература
1989, 489 pp.
110 9.1.Bъведение Според Б. Боем целта на софтуерните технологии е осигуряване на ефек- тивен процес на разработване на висококачествен софтуер. Основна тех- ника за преодоляване на стихийността в създаването на ПП е мениджърският подход. Разглеждането му е актуално заради все още тревожните данни за незавършване (изобщо или в срок) на софтуерните проекти, на превишаване на предварително определените ресурси за разработване или за разпростра- нение на ПП, които затрудняват потребителите със сложността и ненадежд- ното си функциониране. По публикувани данни през 1998 г. 26% от софтуер- ните проекти са преустановени, а 46% са завършили с превишаване на плани- раните ресурси за разработване. За съжаление не е възможно автоматично пренасяне в софтуерното произ- водство на полезни мениджърски практики от материалното производство или други области поради:
9.2. Основни понятия Извършваните в една организация дейности могат да се разделят в две гру- пи: продължителни, повтарящи се, стандартни и рутинни дейности или еднок- ратни за създаване на нещо ново, уникално. Вторият вид дейности се реализи- рат чрез проекти. Всеки проект има определена цел, която трябва да се пос- тигне с крайни и ограничени ресурси (време, финансови средства, екип от спе- циалисти). Обикновено изискванията се уточняват постепенно и поради уни- 111
 калността на проекта участниците в него могат да разчитат на опита си, но тряб-
ва да са в състояние да разрешават и нововъзникнали проблеми, които е трудно да се предвидят отнапред. Целта на управлението на проекти е те да се осъ- ществяват систематично и контролирано чрез постъпкови процедури. Ефек- тивни проекти са тези, които водят до повишаване на производителността на участниците и осигуряване на качествени крайни продукти и услуги. Резулта- тите от тях са постигнати в определен срок и с оптимално използване на ресур- сите. Предпоставки за ефективни проекти са [1]:
9.3. Управление на софтуерни проекти 9.3.1. Методология на управлението на проектц Управлението на софтуерните проекти може да се декомпозира на управле- ние на четири основни обекта (т. нар. four P's: people, product, process and project). Управлението на човешките ресурси е преди всичко признаване на роля- та на човешкия фактор в разработването и използването на софтуера (вж. глава 14.). С развитието на софтуерната психология в последните години стандартна- та за софтуерните системи двойка „хардуер-софтуер" се разшири с трети еле- мент, наречен peopleware. От гледна точка на мениджмънта това са дейностите по подновяване и подбор на кадрите, повишаване на квалификацията, атести- ране и професионално развитие, организация на работата и на работното мяс- то, обучение за работа в екип и т. н. Управлението на продукта е преди всичко определяне на предназначение- то, основните функции и изисквания към новия продукт още в началото на про- екта, за да се оценят предварително необходимите ресурси за реализацията му. Управлението на процеса на разработване включва планиране и ефек- тивно осъществяване на всички дейности. В зависимост от предназначението, обхвата и начина на организирането им дейностите могат да бъдат основни (проектиране, програмиране, тестване) или допълнителни (осигуряване на ка- чеството, управление на софтуерните конфигурации и измерване). Избраният в софтуерната организация модел на жизнения цикъл определя осъществява- нето на основните дейности, общите характеристики на които се настройват за отразяване на специфичните особености на всеки проект. Глобалните дейности 112
са едни и същи за всички проекти и за организирането им могат да се прилагат общоприети стандартни методики. Основната цел на управлението на проекта е да се държат нещата под кон- трол. Всеки проект има определена начална и крайна дата, цел и обхват, опреде- лено и документирано съотношение цени-ползи, добре дефиниран краен резул- тат, ясни и точни критерии за завършване. Управлението на проекти е в съответ- ствие с избрана методология — съвкупност от принципи, подходи, методи, про- цедури, правила и указания, изясняващи как се осъществява определен проект и какви са взаимоотношенията му с други обекти и субекти. Методологията е фор- мална, ако е представена в писмен вид и се прилага систематично в дадена орга- низация. Преимуществата на прилагане на формална методология са, че тя:
9.3.2. Управленска структура Традиционната управленска структура е йерархична, като нивата на йе- рархията, видът и броят на ръководителите на всяко ниво зависят от големината на софтуерната фирма и размаха на дейностите в нея. В общия случай се разг- раничават две нива: ръководители на фирмата (senior managers) и ръководите- ли на проекти {project managers). Ръководителите на фирмата отговарят за:
Ръководителите на проекти отговарят за:
113
проекта; — текущо управление на проекта (проследяване, отчитане в контролни точки); — представяне на проекта и развитието му пред външни или горестоящи инстанции. Практиката показва, че успехът на проекта зависи в голяма степен от ка- чествата на ръководителя му. Затова са разработени и специални процедури за подбор на ръководителите на проекти. Обикновено се предпочитат лица с ин- форматично или бизнесобразование с допълнителна специализация в областта на софтуерните технологии. Практическият опит в разработването на софтуер е съществено предимство. Професионалните изисквания се допълват от изиск- вания за лидерски качества, комуникационни умения и индивидуални характе- ристики, като сговорчивост, способност за оценяване на нови идеи и създаване на подходящ микроклимат в екипа и т. н. Личната мотивация за превръщане на разработчик в ръководител на проект е освен по-високото заплащане приема- нето на предизвикателствата и отговорностите на нов проект, издигане в йерар- хията на софтуерната организация, чувството на удовлетворение от вземане на решения, водещи до успешно завършване на проекта, и не на последно място — упражняване на власт. 9.4. Планиране Планирането обхваща дейностите по съставяне и проследяване на всички видове планове, т. е. разработване на планове и процедури за реализирането им, възлагане на задачи и проверка на изпълнението им. Планирането е основ- на управленска функция и не е предсказание, какво ще стане, а какво бихме искали да стане. Ръководството на фирмата определя дали и какво да се плани- ра. Основни възражения срещу планирането са, че отнема много време, че е скъпо и ограничава гъвкавостта; че се основава на предположения, които може и да не са верни, че потиска творческия подход и доколкото всеки проект е уникален, не може да се използва рационално опитът от предишни проекти. В подкрепа на планирането се посочва, че то:
В зависимост от целите и предназначението си плановете се делят на общи и конкретни. Общите планове се отнасят до софтуерната организация като цяло и са целева програма, стратегически и тактически план. Целевата програма (The Mission) отговаря на въпроса, защо съществува софтуерната организация. Най-често целта е разработване на софтуер, който да се разпространява с цел да се реализира печалба. Но съществуват и софту- 114
ерни организации с идеална цел (например софтуерни отдели на научни инсти- тути), които разработват софтуер за популяризиране на нови научни постиже- ния, създаване Ha freeware или shareware за издигане на авторитета на съответ- ния научен институт и др. Специални са целите на разработване на софтуер за военните, за космическите изследвания и др. Стратегическият план отговаря на въпроса, какво да създава софтуер- ната организация. Този план се създава за относително по-дълъг период от вре- ме (обикновено за 5 години) и определя в какви приложни области ще бъдат разработваните ПП, дали и как ще се разширява дейността на организацията, какви ще са нейните основни и странични дейности (например съпровождане, сертифициране, документиране на софтуер и др.). Тактическият план отговаря на въпроса, как ще се осъществяват плани- раните софтуерни проекти (в каква последователност, с какви ресурси, в каква среда на разработване). Той обикновено се съставя за една календарна година. Конкретните планове се отнасят до отделен софтуерен проект. Освен плана за проекта се съставят бюджет, календарни планове и графици за групи- те, реализиращи проекта, както и индивидуални планове за всеки участник. Съществен конкретен план е бюджетът, описващ разпределението на средст- вата за разработване. Съставянето на бюджета се подчинява на следните правила:
9.5. Анализ и управление на риска Под риск се разбира потенциален проблем, който може да възникне и да застраши успешното завършване на проекта. Всеки риск се характеризира с 115
неопределеност (може да се появи или не) и вредност ■— винаги има нежела-
ни последици или загуби. В зависимост от това, какво засягат, рисковете се делят на рискове на проекта, технически или бизнесрискове. В [3] е дадена и класификация на рисковете в зависимост от степента на прогнозируемост. Очак- вани са рисковете, които могат да се идентифицират чрез анализ на проекта; предвидими са рисковете, които могат да се опишат въз основа на опита от предишни проекти, и непредвидими са рисковете, които просто се случват. Основната идея на управлението на риска е да се анализират някои от най- вероятните рискови ситуации и да се направят опити за избягването им или за намаляване на последиците от тях. Допълнителните разходи за изследване на рисковите фактори се компенсират с предотвратяването на значителните щети, които биха се получили, ако рискът е действителен. Управлението на риска се осъществява в три стъпки: идентифициране, оценяване и ограничаване на въз- можните последици. За всеки риск тези стъпки са последователни, но дейности- те за управление на различните рискове се преплитат (например някои рискове се контролират, докато нови рискове се идентифицират и оценяват). Идентифицирането на риска е систематичен опит да се установи какво мо- же да застраши успешната реализация на проекта. Рисковите фактори могат да се разделят на две групи: общи за всички софтуерни проекти и специфични за даден проект. Основна техника за идентифициране на риска е съставянето на въпросни- ци, свързани с характеристики на основните застрашени обекти. Например за обекта проект въпросите се отнасят до характеристиките обхват, размер и продължител- ност; за обекта продукт — спецификации, сложност, уникалност и специални изис- квания; за обекта персонал — организация, състав и мотивираност на работната група, качества на ръководителя на проекта; за обекта процес на разработване — процедура за избор на проекти, методология и стандарти за работа и др. За всеки риск се определя и степента му на влияние върху проекта. Оценяване на риска — данните за риска се систематизират и се преобра- зуват в информация за вземане на решения. За всеки риск се определя вероят- ността и последиците от риска [3], въз основа на които се определя и приорите- тът му. Предотвратяване на последиците от риска изисква планиране на уп- равлението на риска — определянето на рисковете с най-висок приоритет, ко- ито ще се наблюдават, и свързаните с тях действия за предотвратяването им. По време на разработването се следят идентифицираните рискови фактори и се натрупва информация за всеки от тях, за да се установи дали и как се променя вероятността за настъпване на рисковата ситуация. Управлението на риска е свързано с допълнителни ресурси, но някои проб- лемни ситуации могат да се избегнат, като се спестят средствата за възстановя- ване на щетите след настъпването им. Политиката на следене на риска поддър- жа увереността на ръководителя, че всичко е под контрол, и увеличава шансо- вете за успешно завършване на проекта. 9.6. Организация на софтуерните проекти След изясняване на основните параметри на проекта — съдържание, тру- доемкост, продължителност и рискове — работата по проекта трябва да се op- 116
ганизира така, че той да се вмести в определените срок и ресурси [4]. За тази цел се съставя и се следи изпълнението на календарен план-график, представящ разработването на ПП във времето. Съставянето на графици преминава през следните етапи:
Като пример ще разгледаме съставянето на график за дадена фаза на соф- туерен проект. Нека за тази фаза да са определени три стандартни задачи, изис- кващи едни и същи умения и квалификация на разработчиците. Въз основа на информация от предишни проекти е определена трудоемкостта на всяка от за- дачите. Данните от предишни проекти показват, че около 60% от усилията в тази фаза са продуктивни. Следователно от 8 работни часа само 5 ще са про- дуктивни. Тези предварителни оценки са представени в таблицата на фиг. 9.1.
Фиг. 9.1. Ръководителят на проекта оценява особеностите на проекта и планира след- ната трудоемкост на задачите: Алализирайки същността на задачите, ръководителят на проекта установя- ва, че първите две задачи могат да се изпълняват паралелно, но третата може да започне едва след завършването на първите две.
Каталог: fmi -> fmi-ftp-upload-folder -> 4%20Semestur%202005 -> Predmeti -> AMP AMP -> Спецификация на софтуерен проект fmi-ftp-upload-folder -> Oracle e-business Suite Модул Financials, подмодул Fixed Assets fmi-ftp-upload-folder -> Бази от данни Упражнение 9 fmi-ftp-upload-folder -> Basic structures напишете pl/sql блок, който въвежда номера в таблицата messages AMP -> Спецификация на изискванията AMP -> 10. Управление на документацията Документация предназначена за разработчиците AMP -> 1. Анализ на риска Изтегляне 3.19 Mb. Сподели с приятели:
|