Софтуерни технологии
Изтегляне 3.19 Mb.
|
- Навигация на страницата:
- Табл. 11.1. Входни данни за модела
- 12.АВТОМАТИЗАЦИЯ НА СОФТУЕРНОТО ПРОИЗВОДСТВО
- 12.1. Автоматизация чрез индивидуални средства
- 12.2. Автоматизация чрез интегрирани среди
- 2. ЖИЗНЕН ЦИКЪЛ НА ПРОГРАМНИЯ ПРОДУКТ 2.1. Моделиране на жизнения цикъл
150
Получените по този начин и при тези входни данни резултати са дадени в таблица 11.1. 
Табл. 11.1. Входни данни за модела Получената ситуация е твърде интересна. Продукт 1 се появява първи на пазара и изгражда около себе си среда. В началото на период 3 се появява продукт 2, с по-добро вътрешно качество и веднага (поради тази причина) зав- зема по-голям дял от пазара, като създава очакване, че този процес ще продъл- жи. Така би и станало, но всъщност тенденцията трае до период 5, когато на пазара се появява продукт 3, с още по-добро качество. С тази си характеристи- ка продукт 3 започва да вреди на продукт 2, защото всъщност те двата започват да се конкурират и не си позволяват един на друг да увеличат средата си (т. е. броя на потребителите си). Крайният резултат се вижда в реда за период 10, когато на пазара е останал само продукт 1. Така описан, моделът е всъщност в най-простия си вариант. Допълнително в него могат да се въведат други фактори, реално влияещи на пазара: — Предварително обявяване на продукта. Ако потребителите имат дове- рие на производителя, обявяващ своя продукт, те вече имат поле за избор — могат да купят такъв продукт, който вече е на пазара, но могат и да изчакат известно време до появата на обявения и тогава да направят преценка за покуп- ка. He e трудно да се въведе в (11.1) параметър, отразяващ тази особеност, например да се раздели U(I) на (l+r)t, проблемът е да се определи адекватна стойност на r, за t е ясно, че е периодът на изчакване от момента на обявата до момента на появата на продукта на пазара. По-подробен анализ показва, че r следва да се дефинира като функция на няколко фактора — интензивността на рекламната кампания по предварителното обявяване, имиджа на производите- ля, неговата способност да удържи обещанията си за датата на пускане на про- дукта и за неговото качество. 151
12.АВТОМАТИЗАЦИЯ НА СОФТУЕРНОТО ПРОИЗВОДСТВО Литература 1. Friedman H. H.,L.W.Friedman, Marketing Methods for Software. The J. of Systems and Software, 7(1987), p. 207—212.
152 Същността на софтуерния парадокс е, че разработчиците на софтуер, които се занимават с автоматизиране на работата на другите, все още не са направили достатъчно за автоматизиране на собствената си работа. Статистически данни показват, че разходите за обработка на информацията се удвояват на всеки 5 години, а производителността на програмисткия труд се удвоява на всеки 25 години. Това обуславя актуалността на проблема за автоматизация на софтуер- ното производство (АСП). Предназначението на автоматизиращите средства е да поддържат избрани- те методи за разработване на софтуер, да улесняват управлението на проектите и на цялостния процес на създаване на ПП, да извършват трансформации от едно представяне на софтуерните продукти в друго и да проверяват правил- ността им. В зависимост от прилаганите автоматизиращи средства могат да се разграничат два основни подхода — използване на индивидуални средства и използване на интегрирани среди. Ще се спрем на основните характеристики и особености на всеки от тези два подхода. 12.1. Автоматизация чрез индивидуални средства Този подход е исторически първият и се състои в използването на отделни (stand-alone) "полезни" програми, улесняващи извършването на някаква дей- ност при създаването на софтуера. Първоначално средствата са били компила- тори, асемблери, свързващи редактори, дебъгери, осигуряващи директна по- мощ за програмирането. Едва в началото на 70-те години се появяват средства, подпомагащи и други дейности. Съществуващите индивидуални средства за АСП могат да бъдат класифи- цирани по различни критерии — по функциите им (т. е. кои дейности подпома- гат), по използването им в различни фази от жизнения цикъл, по основните им потребители (мениджъри, програмисти, отговорници по осигуряване на качес- твото и др.), по степента им на сложност на усвояване и прилагане и др. В зависимост от автоматизираните дейности те се разделят на следните групи: 153
 а) средства за програмиране — езиковоориентирани редактори, трансла-
тори, свързващи редактори, дебъгери, средства за управляемо изпълнение на програми и др. б) средства за тестване — анализатори на програми, генератори на тестови данни, средства за управление на тестването в) средства, подпомагащи управлението на проекти. Чрез тези средства
— да оценява предварително трудоемкостта, стойността и продължителността на проекта и броя на хората, необходими за реализацията му. Оценката се прави чрез въвеждане на индиректна мярка за размера на проекта и анализиране на някои общи характеристики — сложност на проблема, опит на разработчиците в тази приложна област, зрелост на процеса на разработване и др.;
— да проследява удовлетворяването на изискванията, г) средства, подпомагащи документирането Те осъществяват създаването, оформянето и отпечатването на документи. В тази група са текстообработващите програми с възможности за въвеждане, ре- дактиране, проверка на граматическата правилност и стил на текст. Графичните редактори позволяват илюстрирането на текста с диаграми, схеми и произволни изображения. Издателските системи реализират форматирането (предпечатната подготовка) на оформените в съответствие с определени стандарти документи. д) средства, подпомагащи съпровождането:
е) средства за анализ и проектиране Те позволяват създаването и оценяването на модел на софтуерната систе- ма, която ще се разработва. Могат да поддържат различни методи на проекти- ране — структурни или обектно ориентирани. ж) средства за прототипиране и симулиране Тези средства представят някои функции или характеристики на поведени-
з) средства за проектиране и разработване на потребителския интерфейс; и) езикови процесори. Тези средства са за използване на различни езици — за специфициране, за описание на проекти, за автоматично генериране на текста на програмите и т. н. Изследвания за използване на индивидуални средства за АСП показват, че разпределението им по различните фази и функции от жизнения цикъл не е равномерно и че успехът на нови методи в софтуерното производство зависи в голяма степен от това, дали тези методи се подпомагат и от съответни автомати- зиращи средства [1]. 154
Основно предимство на подхода за АСП с индивидуални средства е, че те не са толкова скъпи и всяка софтуерна фирма може да си ги позволи. Освен това. тези средства улесняват една или няколко дейности и повишават производител- ността на персонала, участващ в създаването на софтуер. Недостатъците на под- хода са няколко. Преди всичко индивидуалните средства са обикновено хардуер- но зависими и са предназначени за точно определена операционна и програмна среда. Използването на няколко независими средства принуждава разработчици- те да разучат няколко различни потребителски интерфейса. Липсата на интегра- ция намалява производителността, защото не е възможно последователно извик- ване на някои средства, без да има дублиране на общите дейности. 12.2. Автоматизация чрез интегрирани среди Полезността на индивидуалните средства за АСП е безспорна, но интегри- рането им за съвместно използване би улеснило:
— реализацията на потребителски сценарии за решаване на конкретен проблем. Естествено развитие на идеята за' автоматизация с индивидуални средства е използването на групи от средства, които са проектирани да работят съвмес- тно. Един от приносите на операционната система UNIX към разработването на софтуера е предоставянето на т. нар. PWB (Programmer's workbench), при който интеграцията се осъществява чрез общи формати на файловете, възмож- ности за управление на версиите (SCCS) и за изграждане на софтуерна система чрез описание на съставящите я части (MAKE). Идеята за разрастващо се изг- раждане на средства чрез "навързване" на по-малки средства е изключително полезна. По-нататък развитието е през средите за програмиране на Ада, докато се достигне до сегашната обща теория за изграждане на интегрирани среди. В [2] са формулирани следните изисквания към интегрираните среди за АСП:
В зависимост от начина на свързване на група от автоматизиращи средства в единна среда интеграцията може да бъде: а) еклектична интеграция — съществуващи индивидуални средства се обе- диняват в система чрез създаване на програма—монитор, извикваща всяко от средствата; б) интеграция чрез данните — използване на общ модел на данните. Този вид интеграция може да бъде с различно ниво на сложност — обмен на данни 155
 между две средства чрез програма — конвертор, използване на обща съвкуп-
ност от прости символни файлове или чрез система за управление на обекти; в) интеграция чрез потребителския интерфейс. В този случай средствата в системата използват общ стил и съвкупност от общи стандарти за връзка с пот- ребителя; г) интеграция чрез дейностите, които се поддържат. Този тип интеграция се основава на модел на процеса, който определя ос-
Всяка интегрирана среда обединява в едно положение няколко софтуерни средства, поддържащи специфични дейности в процеса на създаване на софту- ер. Чрез интеграцията се постига:
начин. Удобствата за работа, предоставяни от някои среди за АСП, могат да доп- ринесат за въвеждане в софтуерната организация на нови методи и техники. В зависимост от предназначението си интегрираните среди могат да бъдат за: а) планиране и моделиране на бизнесинформационни системи. Този клас
б) анализ и проектиране. Съвременните средства автоматизират най-често използваните подходи за
Възможностите на средствата от този клас зависят от: —: нивото на формализираност на използваната нотация. Ако тя е неформал-
156
— от вида на приложението — дали преобладава обработката на данните, както е в банковите и счетоводни системи, или управленските функции; в) създаване на потребителски интерфейс Смята се, че потребителският интерфейс е определящ за пазарната реали-
— библиотеки за поддържане на генерирането на изпълним код. r) програмиране Те включват текстов редактор за създаване и променяне на текста на прог-. рамите, компилатор, свързващ редактор и дебъгер. Характеризират се с: — удобен потребителски интерфейс; — управление на създаваната по време на сесия информация — файлове с
д) верификация и валидация Такива среди подпомагат модулното и системно тестване и обикновено
е) съпровождане Средата за съпровождане управлява внасянето на промени, създаването и контрола на версии и за управление на софтуерните конфигурации. ж) управление на проекти Подпомагат се планирането, съставянето на графици и текущото следене
Ще представим концепцията за изграждане на АСП-среди, следвайки изло- жението в [3]. Предназначението на АСП-средата е да подпомага цялостния процес на 157
Поддържането и използването на информацията от хранилището се осъществява чрез интегрираща архитектура, представена на фиг. 12.1. Ос- новните компоненти са: база от данни, в която да се съхранява информацията, система за управление на обекти, чрез която да се управлява променянето на информацията, механизъм за управление на инструменталните средства (за ко- ординиране на използването им) и потребителски интерфейс. Повечето модели представят тези компоненти като слоеве. 
Ще опишем накратко основните й компоненти. Потребителският интерфейс осигурява удобна и ефективна работа със системата. Протоколът на представяне е множество от указания, чрез след- ването на които всички АСП-средства в системата се използват по подобен на- чин. Така екраните имат едно и също разпределение на отделни области с ед- накво предназначение; има правила за имената и организация на менюта, икони и обекти; стандартизирано е използването на клавиатура и мишка; описан е общ механизъм за достъп до средствата. С използването на протокол на предс- тавянето се постига унифицираност. Слоят на индивидуалните средства включва самите средства и програ- ми за управлението им. Препоръчва се управляващите програми да са проекти- рани и реализирани така, че да се поддържа динамична съвкупност от индиви- дуални средства. Това би позволило на потребителя да съставя нужната му кон- фигурация от средства и да я променя, като добавя, изключва или модифицира някои средства. Ако в системата се поддържа многозадачна работа, управлява- щите програми осигуряват синхронизация при прилагане на средствата, регу- лиране на потока на данните, следене на правата за достъп и прилагане на мет- рики за ефективността на използване на всяко от средствата. Слоят за управление на обекти осъществява интегрирането на средства- та с данните от хранилището и управлението на софтуерните конфигурации. Той е съвкупност от програми, които за всяка заявка идентифицират, обектите от съответната софтуерна конфигурация и ги представят във вид, подходящ за 158
съответното средство; поддържат различните версии, управляват планирането, внасянето и документирането на промени, регистрация и поддържане на опи- сание на всеки елемент на софтуерна конфигурация. Слоят за управление на хранилището включва базата данни на система- та и функциите за управлението й. Идеята за централизирано съхраняване на данните присъства във всеки модел на интегрирана среда, макар и под различни имена: АСП-база от данни, база на софтуерните разработки, хранилище и др. Съхраняваната информация може да се раздели на две: обща информация (свър- зана със софтуерната фирма като цяло и стила на работа в нея) и информация за всеки конкретен софтуерен проект. Общата информация може да включва описание на организационната структура в софтуерната фирма, съвкупността от вътрешни правила и стандарти, които трябва да се спазват, описание на из- ползваната методология на разработване, процедури за извършване на основ- ни дейности и др. Информацията за конкретен проект може да бъде:
Съдържанието и начинът на организация на данните в хранилището се оп- ределят при конкретната реализация на концептуалния модел. Освен обичайните функции на СУБД към компонентата за управление на хранилището са формулирани някои допълнителни изисквания:
Така се постига съхраняването и обработването на сложни структури от данни, които се използват ефективно от съответните инструментални средства в системата, и то така, че разработването на ПП става в съответствие с избрана- та методология. 159
12.2.3. Жизнен цикъл на софтуерните среди
Практическото използване на софтуерните среди преминава през следните шест фази: а) избор на софтуерна среда През тази фаза трябва да се направи проучване на софтуерния пазар и да
б) настройване на средата към специфични за организацията изисквания През тази фаза трябва да се създаде версия на средата, която да съответст- ва на използваната в организацията платформа и модел на процеса на разработ- ване. Това изисква определяне на стойностите на параметри, определяне на елементите на системата за управление на обекти, избор на съвкупност от сред- ства и цялостно документиране на получения вариант на средата. в) инсталиране и експериментално използване на средата Организира се обучение и пробно използване, за да се оцени полезността на средата. Обикновено трябва да се преодолява съпротивата на разработчици- те заради променения стил на работа и съпротивата на мениджърите заради големите инвестиции с неизвестна възвращаемост. г) използване и еволюция на средата Препоръчва се натрупване на статистически данни, въз основа на които да
д) преустановяване на използването на средата Възможни са две ситуации — отказ от използване на автоматизиращи сре-
Потенциалните ползи от прилагането на средства за автоматизация са: — повишаване на систематичността и управляемостта на софтуерните проекти; 160
Независимо от тези преимущества АСП-средите имат все още ограничено използване. Основни причини за това са:
Сложността на съвременните софтуерни системи изисква автоматизация през различните фази на разработването. Независимо от трудностите при прис- пособяване на автоматизиращите средства към стила на работа в конкретната организация бъдещето на софтуерната индустрия е немислимо без създаването и усъвършенстването на АСП-средствата. Подробно описание на АСП-средства може да бъде намерено чрез [4]. Литература
161  2. ЖИЗНЕН ЦИКЪЛ НА ПРОГРАМНИЯ ПРОДУКТ
2.1. Моделиране на жизнения цикъл 2.1.1. Защо се нуждаем от модел на жизнения цикъл Жизненият цикъл (ЖЦ) на програмния продукт (ПП) обхваща целия пе- риод на неговото създаване и използване. За начало на ЖЦ се смята моментът на възникване на идеята за създаването му. За край на ЖЦ се смята моментът, в който се преустановява използването на последното копие на ПП. В някои слу- чаи се разграничава физическият от логическия край на ЖЦ. За логически край се говори тогава, когато използването на 1111 е било толкова дълго, че от извес- тно време нататък не са били необходими никакви усилия по съпровождането му, т. е. спряло е внасянето на промени в ПП за поправяне на грешки, за усъ- вършенстването му или за пренасянето му в нова операционна и хардуерна среда или ПП продължава да съществува пасивно по отношение на разработчи- ците си. Модели са необходими не само в областта на софтуерните технологии. Цел- та на конструктивните дисциплини е да се отговори на три основни въпроса:
2.1.2. Какви свойства има моделът За да се отговори на горните въпроси, се използват модели на разглежда- ните обекти. Всеки модел се характеризира с три особености:
18 ти от реалността, които си заслужава да се изследват). Това впрочем е напълно в сила за програмния продукт и неговия жизнен цикъл — не е възможно да се построи модел, който да отрази всичките им особености. — Език за описание — всеки модел се описва на някакъв език — чисто математическите модели ползват езика на някой дял от математиката, възможни са различни графични, диаграмни, блокови и други подобни езици. В много случаи обаче за описание на даден модел се ползва естествен език, а не са редки случаите, когато се ползва и повече от един език. Моделите на ЖЦ на ПП обик- новено се отнасят към последния случай. От казаното следва основният проблем при моделирането: представянето на реалността в модела не е нито точно, нито пълно, а това от своя страна може да се окаже решаващо и за неговата полезност. Затова при оценяването на мо- делите обикновено се разглежда следната схема: 
Каталог: 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. Сподели с приятели:
|
