Софтуерни технологии
Управление на обектно ориентираното разработване
Изтегляне 2.27 Mb.
|
Свързани:
empty doc
| 4.4. Управление на обектно ориентираното разработване
Както ще видим в глава 9., стихийността в софтуерното производство се преодолява с прилагане на основните управленски техники. За разработването на ПП те са за управление на: процеса на създаване на софтуер, създавания продукт, софтуерния проект и човешкия фактор. 4.4.1. Управление на процеса на разработване Както беше описано в глава 2., препоръчва се всяка софтуерна организа- ция да избере модел на жизнения цикъл на ПП, който идентифицира подхода за разработване и определя последователността и съдържанието на основните фа- зи и/или функции. За ОО-разработване Г. Буч [7] предлага т. нар. рекурсивно- паралелен модел, схематично представен на фиг. 4.1. Той е много близък до спираловидния и до еволюционния модел, споменати в глава 2., и същността му е в разработването на последователно разрастващи и усложняващи се прототи- пи до окончателното изграждане на целевата система. За всеки прототип се извършват едни и същи дейности: планиране, анализ, проектиране, извличане на компоненти от библиотеката за повторно използване, конструиране на про- тотипа с налични и новоразработени компоненти, тестване и оценка от потре- бителя, определящ изискванията към следващия прототип. Моделът се различава от останалите подобни модели по рекурсивното повтаряне на дейностите (включително и на анализа и проектирането!) за всеки прототип и по възможността за паралелното им извършване за независимите компоненти на системата. За ефективно управление на рекурсивно-паралелното разработване ръко- водителят на проекта трябва да осъзнае, че планирането (определянето на стан- дартните задачи и графици) и измерването на развитието на проекта се извърш- ва за всяка независима компонента поотделно. 4.4.2. Управление на проекта и продукта Стандартните техники за управление на софтуерни проекти (вж. глава 9.) са приложими и при ОО-разработване, но съдържанието на някои от извършва- ните дейности е различно. Ще споменем някои съществени разлики: а) допълване на стандартните методи за оценяване на цената на разра- ботване, трудоемкостта и продължителността на софтуерен проект с разрабо- тените ОО-метрики, измерващи специфични за подхода елементи — сценарии на използване, основни и поддържащи класове и връзките между тях [8]; б) за проследяване на развитието на проекта се препоръчва стандартната техника с използване на контролни точки, но достигането им се определя по 52 53 специфичен начин. В [1] са описани критерии за определяне, кога е завършил ОО-анализ (контролна точка 1), ОО-проектиране (контролна точка 2), програ- мирането (контролна точка 3) и тестването (контролна точка 4). Например кри- териите за завършване на ОО-анализ са: Всички класове и йерархията на класовете са дефинирани и проверени. Атрибутите на всеки клас и свързаните с него операции са дефинирани и проверени. Отношенията между класовете са описани и проверени. Поведенческият модел на системата е създаден и проверен. — Класовете за многократно използване са идентифицирани. Аналогични критерии са зададени и за останалите контролни точки. в) управлението на проекта и управлението на продукта се преплитат по- ради специфичното покомпонентно разработване при ОО-подход. Една от особеностите на ОО-разработване е, че всяко приложение може да се изгражда чрез компоненти. Под компонента се разбира клас, който е създа- ден и съхранен, с определено ниво на качество и степен на общност, която позволява да се използва многократно. На фиг. 4.2. е показана схема, илюстрираща управлението на проекта и про- дукта при ОО-разработване с използване на библиотека от компоненти. Организи- зацията на проекта е подчинена на краткосрочни цели като завършване на проекта в определения срок и в рамките на бюджета. Организацията на продукта преследва по-дългосрочни цели — създаване на компоненти за многократно използване. По- ради специалните изисквания към тези компоненти (да са с проверено и високо качество, да решават клас от сродни проблеми, да са подробно документирани) цената на разработването им е по-висока. Това се компенсира с намаляването на| цената за изграждане на приложения и намаляване на усилията за съпровождане. 54 4.4.3. Управление на персонала Както е показано на фиг. 4.2., разграничени са три групи изпълнители на 00 софтуерен проект: програмисти на приложения, програмисти на компонен- ти и стратези. Програмистите на приложения трябва да имат знания за приложната об- ласт и способност за абстрактно мислене. Те трябва да определят кои обекти трябва да се групират, за да се изгради приложението. Затова те се интересуват не от детайлите и реализацията на компонентите, а от същността им и за какво могат да се използват. Програмистите на компоненти трябва да проектират и реализират всяка компонента така, че тя да е настроеваема и да се използва лесно. Независимо че отговарят за изграждане и поддържане на библиотеката от компоненти, те учас- тват активно в началото на всеки проект, за да дадат информация, какви налич- ни компоненти има и как могат да се използват. Основните функции на стратезите са координиране и съветване. Те трябва да имат необходимата квалификация и опит в повторното използване (вж. гла- ва 13) като основен подход в софтуерната организация. Разполагайки със зна- ния за достъпните компоненти и начина им на вграждане в приложения, страте- зите са посредници между двете групи, като решават и по-глобални въпроси: какво да бъде съдържанието на библиотеката от компоненти, как да се оптими- зира описанието и търсенето на нужните компоненти в нея, какви автоматизи- рани средства да се използват и т. н. Различни са изискванията към квалификацията, опита, знанията и умения- та на трите категории софтуерен персонал и разпределянето на задълженията трябва да е съобразено с тях. Изтегляне 2.27 Mb. Сподели с приятели:
|