Софтуерни технологии
Изтегляне 3.19 Mb.
|
- Навигация на страницата:
- 2.2. Класификация на моделите на ЖЦ на ПП
- 2.3. Типове модели на ЖЦ на ПП
- Модел на фрийман Модел на Метцгер Модел на Боем
- Табл. 2.1. Стандартни модели
- 15. МАЛКАТА СОФТУЕРНА ФИРМА Литература
- 15.1. Еволюция на малката софтуерна фирма
- C1 — конфигурация, основана на технологическата насоченост на предприемаческата група;
- 15.2. Екстремно програмиране
180 екипите. По време на реализация на софтуерен проект вместо решения, осно- ваващи се на това, което би било по-добро за клиента, много софтуерни специ- алисти избират решения, които биха улеснили самите разработчици или софту- ерната разработка. Така ситуациите на некоректно отношение се повтарят, без да предизвикат обсъждане, преразглеждане или загриженост. Липсата на правилно етично поведение има огромно влияние върху разви- тието на организацията. Повтарящите се случаи на неволно или умишлено не- коректно поведение, в резултат на което са се оскъпили или провалили проек- ти, създават лош имидж на софтуерната фирма и застрашават нормалното й функциониране и дори съществуване. Друго следствие от липсата на утвърден етичен правилник е деформиране- то на компютърния специалист като личност. Сблъсквайки се с конкретна ситу- ация, той взема решения на основата на собствената си ценностна система и морал, понеже неговата организация не е осигурила насоки за приемливо етич- но поведение. След няколко подобни случая той може и да не разглежда поведе- нието си като неетично или непрофесионално. Едно възможно решение е в софтуерната организация да се обсъждат пробле- мите от морално-етично естество и да се приемат правила за етично поведение. Те не могат да бъдат задължителни, но поне биха определили приемливо поведение. Отклонението от него би било въпрос на личен избор и отговорност на индивида. Осъзнавайки значението на нормите за етично поведение, в [8] е предло- жен следният кодекс на работещите в областта на софтуерните технологии: Кодекс за етично поведение
181  организационна структура), следва ли всеки проект в дадената организация да
си има собствен ръководител и ако това е така — докъде да се простират управ- ленските му пълномощия, допустимо ли е даден специалист или дадена група от специалисти да работи едновременно по повече от един проект и т. н. — Технологически — какъв тип спецификации и техники на програмира- не са препоръчителни евентуално с оглед типа на разработвания софтуер, как- ви метрики да се ползват за оценяване качеството на разработвания продукт докато той се прави и след като бъде завършен, възможно ли е например полз- ването единствено на обектно ориентиран подход от самото начало на ЖЦ до завършване на тестването на ПП. 2.2. Класификация на моделите на ЖЦ на ПП Възможни са най-различни класификации. Тази, която следва, се опитва да обхване почти всички по-известни модели на ЖЦ на ПП, като отразява опреде- лящия ги признак. Към типовете ЖЦ в скоби са дадени по един или повече примера за съответния тип. Изрично трябва да се отбележи, че посочените като примери ЖЦ са на най-различно равнище на разработеност — някои от тях са изложени в единствена статия, понякога само като идея, други са предмет на цяла книга, в която твърде подробно и конструктивно са развити необходимите елементи за прилагане на съответния модел, трети пък, по-малко на брой, имат и реализирани поддържащи ги програмни средства. 1. Пълни
1.1. Едномерни 1.1.1. Хронологични
1.1.2. Функционален (Хамилтън—Зелдин) 1.2. Многомерни
2. Частични — за повторно използване (Епълтън) 2.3. Типове модели на ЖЦ на ПП Тук ще разгледаме най-общо типовете модели на ЖЦ, като следваме даде- ната по-горе класификация. Редът на изложение ще бъде различен от този на класификацията, за да обхванем по-напред тези модели, които представляват повече теоретичен интерес — било поради това, че са твърде абстрактни, било поради това, че вече са твърде остарели и са интересни най-вече от гледна точка на проследяване развитието на идеите за моделиране на ЖЦ на ПП. По-подроб- но ще се спрем на модела на Гънтър [1] (1.2.1.), който, от една страна, е твърде 20 подробно разработен, а от друга — твърде всестранно представя ЖЦ на ПП. Основният му недостатък е, че някои от конкретните числови стойности в него вече не обхващат увеличилото се разнообразие от типове софтуер. Ние обаче няма да навлизаме в такива подробности. 2.3.1. Стандартни хронологични модели Съгласно класификацията (1.1.1.1.) тези модели са построени на хроноло- гичен принцип. Това означава, че тяхна основа е развитието на ПП във време- то. Основният обект в тези модели е фазата. Всяка фаза е отрязък от време, през което се извършват определени дейности върху разработвания ПП. В след- ващата таблица в успоредни колони са дадени трите най-известни стандартни модела.
Табл. 2.1. Стандартни модели 21  13. Ще се противопоставям на всички нарушения на този кодекс от други
професионалисти. Разбира се, такъв кодекс не може да бъде задължителен, но се препоръчва спазването му от всички софтуерни специалисти, които го приемат и смятат, че е важно спазването на определени морално-етични норми и при изпълнение на софтуерните дейности. За важността на проблема говори и фактът, че най-голе- мите професионални организации, свързани със софтуера — АСМ и IFIP — от няколко години имат етичен кодекс за своите членове. 15. МАЛКАТА СОФТУЕРНА ФИРМА Литература:
1994.
7,1993. 6. Weinberg G.M., The Psychology of Computer Programming, Van Nostrand Reinhold, 1971. 7.Adler R., Communicating at work. McGraw-Hill, Inc., 1989. 8. Thomseff R., Crossing the line Professionalism and Software Ethics. in Special Issue on Peopleware, American Programmer, vol.6, No 7,1993. Всяка от главите дотук се смята за съществена част от всеки уводен курс по софтуерни технологии. Биха могли да се добавят (според предпочитанията на различните автори) и малък брой други важни теми. Решихме обаче да завър- шим тази книга с една глава, която да представлява интерес от гледна точка на реалната обстановка днес в България и да съответства на определени аспекти на най-често срещания сценарий, когато някой реши да започне самостоятелен бизнес в областта на софтуера. Знае се, че в софтуера навсякъде по света пре- обладават малките предприятия. В огромното мнозинство от случаите по света и още повече у нас софтуерният бизнес започва със създаването на малка соф- туерна фирма. Поради тази причина интерес представлява един аналитичен пог- лед в генезиса и еволюцията й 15.1. Еволюция на малката софтуерна фирма 15.1.1. Основа на изследването В световната литература са известни многобройни изследвания, посветени на малкото предприятие. Специфичните за софтуерната индустрия обаче са все още изключително малко. В това отношение [1] е пионерско изследване. Макар да се основава на конкретни данни от Италия, то има голямото достойнство да обхваща твърде представителен период от около 15 години, естествено, при всички възможни отклонения в течение на годините — закрити или изчезнали фирми, ръководители, загубили желанието си да отговарят на поставените въп- роси, сменени имена или предмет на дейност. За българския софтуерист е от значение и фактът, че изследваните фирми са от Южна Италия, част от страната която по степен на развитие (а защо не и донякъде по манталитет) е по-близка до България. Следователно резултатите и изводите от това изследване биха би- ли твърде полезни и поучителни за нас. 182 183  15.1.2. Типове ноу-хау на стартиращата софтуерна фирма
От особено значение за бъдещото развитие на стартиращата софтуерна фирма е ноу-хауто, с което тя започва. Един малко по-внимателен поглед показ- ва, че това ноу-хау се свежда до ноу-хау от съседна област, а след още малко анализ се вижда, че то е от 4 основни типа:
— пазарно ноу-хау (група 3), което включва знание за тенденциите в тър- сенето и на характеристиките на разпространителските канали; това ноу-хау човек може да придобие в резултат от работа като продавач на софтуер и xap- дуер;
— ноу-хау за потребителя (група 4), което включва знанието, необходи- мо за да се доведе софтуерният продукт до организацията потребител; такова ноу-хау започва с детайлното познаване на нуждите на крайния потребител (фирма, отдел, тип бизнес) и на умението да се установи съответствие между тези нужди и най-подходящия за целта софтуерен продукт. Какво ноу-хау имат стартиращите софтуерни фирми според изследвания- та? Условно могат да се разгледат три периода — инкубационен, начален и кон- солидационен. За Италия те са били от 1978 до 1984 година с нарастваща про- дължителност (1, 2, 4 години). Трудно е да се каже как във времето тази схема следва да се пренесе към България, но със сигурност тя е изместена най-малко с 10 години и е повече разтеглена. Разпределението е дадено в таблица 15.1. 
От таблицата веднага могат да се направят някои интересни изводи. 1. Сравнително по-малка част от фирмите са се развили на пазара с ноу-
недостатъчно. 2. Забелязва се нарастване на значението на ноу-хауто за пазара. Това
184
3. Независимо от горното обаче все пак най-голям е делът на фирмите, които са стартирали с базово ноу-хау. Още по-показателно е, че техният дял във времето нараства. Това отразява факта, че при изключителната динамика на областта, изменяща се техника и софтуерни инструменти, най-адаптивни си ос- тават тези, които имат фундаментални знания и умения. 15.1.3. Опростена схема на развитие на малката софтуерна фирма По принцип малките фирми преминават през два етапа [2] — технологично ориентиран и пазарно ориентиран. Технологично ориентираният е фокусиран навътре във фирмата — изграждат се и се развиват основните технологии, оценя- ват се силните и слабите им страни. В следващия — пазарно ориентирания етап — фирмата се съсредоточава върху пазара и върху методите за управление и планиране. Преходът от първия към втория етап протича по различен начин в големите и в малките фирми. В големите се осъществява смяна на организацион- ната схема (създават се нови функции и отговорности, нова йерархия, нови ко- муникационни връзки). В малките фирми такъв процес е невъзможен най-вече поради липса на ресурси за това и поради по-слабата организационна структу- рираност. Там този преход е много повече функционален и персонален, отколко- то цялостно структурен. Възможно е да се предприеме диференциране на функ- циите, преразпределение на отговорностите, известно пренареждане на дейнос- тите на фирмата и техните приоритети. Общо взето, този процес не следва строги процедурни правила както при големите фирми, а е по-скоро евристичен, с про- би и грешки. Специално за софтуерните фирми нещата се усложняват от висока- та степен на несигурност и трудна предсказуемост поради вече споменатата ди- намика. При това положение важна роля започват да играят фактори от рода на творческата способност и интуицията на водещите лица във фирмата. Оказва се обаче, че моделът с тези два етапа е твърде опростен и че в реал- ността нещата често са доста по-комплицирани. Едно по-сложно моделиране води до по-адекватни резултати и показва една много поучителна и полезна картина. 15.1.4. Един по-диференциран модел на развитието Начална точка на този модел е опитът да се идентифицират и групират ресурсите, които са определящи за еволюцията на малката софтуерна фирма. Определени са 16 такива и те са класифицирани в следните 3 групи: —ресурси, свързани с предприемача — индивидуално ноу-хау, опит, лични връзки, ангажираност с процесите на софтуерното производство; това са все ресурси, отнасящи се до основния опит на предприемаческата група и до ней- ното включване в технологическите и управленските аспекти на фирмата; — ресурси, свързани с професионалистите — технически умения, про- фесионална квалификация, разнообразие от компетенции; тези ресурси са свър- зани с характеристиките на специалистите в софтуерната фирма — колкото те са по-разнообразни и задълбочени, толкова по-благоприятно се отразяват на стабилността и конкурентоспособността й; 185
—ресурси, свързани с организацията и технологията — размер на фир-
мата, обвързаност с други фирми и лица, прилагани методологии; тези ресурси засягат технологическия и маркетинговия опит на фирмата, наличието на уста- новени организационни схеми и технологии, структурирани връзки с външния свят.
На основата на така идентифицираните и групирани ресурси става въз- можно дефинирането на 7 организационни конфигурации. Те са следните:
7. C7 — конфигурация, основана на комерсиализацията на системи. Такава конфигурация се характеризира с няколко дейности: комерсиализация на хардуер и софтуер, обучение на клиентите, консултации. Обикновено раз- работването на софтуер е само допълнителна поддържаща дейност към вече изброените. Изследванията на реално създадените и развили се малки софтуерни фир-
— C1 — конфигурация, основана на технологическата насоченост на предприемаческата група; — C5 — конфигурация, основана на пазарни взаимоотношения. След това те еволюират на една или две стъпки до други от седемте посоче- ни конфигурации. 186
15.1.5. Еволюция на конфигурация C1 Оказва се, че фирма, започнала от конфигурация C1, може да се развие през всички останали конфигурации, с изключение на C5. Възможно е дори да остане в началното си състояние. Интересно е обаче да се знае, че в края на еволюцията се достига само до 2 конфигурации — C4 и C7. Поучително е също да се види какъв е пътят до тези 2 крайни състояния и какво е съотношението между тях, т. е. кое е най-вероятното развитие на малката софтуерна фирма, която се организира от лице или лица с технологична компетентност. На фиг.15.1. са отбелязани възможните пътища, както и разпределението им в проценти. Следва да отбележим, че 6% остават в началното състояние C1. 
Макар че от фиг. 15.1. достатъчно ясно може да се проследят възможните пътища на развитие на фирма, започнала от конфигурация C1, ще отбележим още следното. Преминаването от C1 към C4 може да е директно (6%) и тогава то е свър- зано обикновено с увеличаване на броя на служителите и с въвеждане на стан- дарти. По-често обаче се преминава към конфигурация C2 (24%). Този преход се характеризира със стратегия за разнообразяване на продуктите и съответно разширение на професионалната компетентност посредством включване на но- ви специалисти с разнообразна квалификация. От C2 като втора стъпка има два пътя. Първият води отново до C4 (12%) обикновено чрез въвеждане на CASE средства, които сами по себе си до голяма степен стандартизират технологическите процедури. Вторият път пък довежда до конфигурация C7 (12%) и се постига с прилагането на стратегия на комер- сиализация. При нея над 50% от приходите на фирмата идват от продажба на готов хардуер и софтуер, а по-голяма част от останалото — от консултации. Следващата възможна първа стъпка не е много срещана и е преминаване към C6 (12%). Характеризира се с разширяване на мрежата от клиенти и задъл- бочаване на взаимоотношенията с тях, най-вече чрез оказване на поддържащи 187
услуги. Този преход изисква задълбочаване на маркетинговите познания за кон-
кретни сравнително тесни пазари. Рядко срещана алтернатива е запазване на статуквото (6%) — фирмата остава от тип C1 за по-дълго време. Това може да означава все пак, че след такъв по-продължителен период се преминава към някоя от другите конфигу- рации по общата схема за първа стъпка. Най-много фирми (29%) предпочитат да преминат към конфигурация C3. Те се свързват с големи хардуерни фирми и стават техни представители в една или друга форма. Друга стратегия е осигуряване на специализирани ресурси за такива фирми, респективно оказване на услуги в определени тесни области. Оттук форсирано, т. е. за всичките тези 29%, се извършва преход към конфигу- рация C7 по начина, описан вече с прехода от C2 към C7. Последният възможен директен преход е към C7 (23%). Схемата за преми- наване вече описахме по-горе като втора стъпка (от C2 към C7). Възможно е обаче такава стъпка да е принудителна — ако напусне предприемачът, който е бил софтуерно ориентиран. Тогава производството на софтуер по необходи- мост минава на втора линия като поддържаща дейност, а на преден план излизат продажбите на готов хардуер и софтуер и консултациите. 15.1.6. Еволюция на конфигурация C5 На фиг.15.2. са отбелязани възможните пътища с начало конфигурацията C5, както и разпределението им в проценти. 
Тук също накратко ще отбележим някои особености. Преминаването от C5 към C4 (7%) не е твърде характерно. Стандартизаци-
188
От C5 може да се премине и към C2 като първа стъпка (20%). Това озна- чава придобиване на допълнителна квалификация на специалистите (чрез обу- чение или назначаване на нови хора) и като следствие от това — възможност за разнообразяване на продуктите и инвестиции в разработването на нови продукти. C2 обаче е междинен стадий. Оттук пътищата са два — към C7 (13%) чрез мерките, описани вече или към C3 (7%) чрез обвързване с големи харду- ерни фирми и сътрудничество с тях в различни форми — представителство и/ или работа за тях. Много често срещан преход е към C3 (35%). Току-що видяхме как става това. От C3 в повечето случаи сравнително бързо се достига до крайната кон- фигурация C7 (20%), но доста често (15%) фирмата се задържа по-продължи- телно в това състояние. Най-често от C5 се преминава директно към конфигурация C7 (35%). 15.1.7.Извод От последните разглеждания се вижда, че независимо от коя начална кон- фигурация се стартира — технологично ориентирана (C1) или пазарно ориен- тирана (C5) — на една или на две стъпки, малката софтуерна фирма достига до две възможни конфигурации. Първата е C4, което означава превръщането й в добре структурирана и управлявана производителка на софтуер на основата на стандартизирани и формализирани технологии, с ясен поглед върху пазара, мяс- тото на фирмата в него и съответна маркетингова стратегия. Втората е C7, ха- рактеризираща се с относителното изоставяне на производството на софтуер за сметка на продажби на хардуер и софтуер и консултационна дейност. Без да се абсолютизира този модел и произлизащите от него движения на малките соф- туерни фирми, той може да е добра ориентация за тези, които се впускат в този тип бизнес. 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
Доколкото говорим за итерации, ясно е,че веднага щом дадена итерация приключи с предаване на разработените средства на потребителя, започва след- ващата с избор на най-подходящите средства от останалите. Много е важно да се знае, че при този избор решаваща дума има клиентът (възложител, потреби- тел), но на основата на информация, предоставена от разработчика. За програ- мистите остава да направят необходимите технологични стъпки — да декомпо- зират поисканото средство (услуга, функция) до необходимия брой задачи, да ги реализират, тестват и предадат за ползване на клиента. Лесно се вижда, че при този подход четирите фази остават, естествено, в много кратки отрязъци от време. Анализът се състои точно в този подбор на поредните средства за реализи- ране. Съществено е, че всяко нещо, което този анализ определи като такова сред- ство, трябва да бъде ясно ориентирано към нуждите на потребителя, да подлежи на тестване и усилията за реализацията му да могат да бъдат отделени и оценени. Проектирането и програмирането се движат практически едновремен- но. В момента на определянето на средствата от поредната итерация се извърш- ва декомпозиция и планиране. Това означава, че точно определен брой програ- мисти получават точно определени задачи със също така точно определени сро- кове. Тъй като става въпрос за малки и ясни задачи, определянето на тези сро- кове не би следвало да е трудно, особено след първите итерации. Докато прог- рамистите работят — всеки по своята задача, потребителят, който продължава да е активен участник, създава функционални тестове. Тук има още една ха- рактерна и малко странна особеност — програмистите работят по двойки вър- ху дадена задача на един компютър. Това се свързва с необходимостта да се осигури валидност на създадения програмен модул при липсата на стандартни- те процедури. Последната е породена от съкратеното време и намалените дру- ги ресурси. Предвидена е възможността за контакт на двойката с потребителя по въпроси на функционалността или пък с най-опитните програмисти по тех- нологични въпроси, но винаги в рамките на не повече от 15 минути. В този процес на реализация почти веднага навлиза и тестването. При това има още една особеност: по логически причини тестването следва програ- мирането, но самите тестови примери се пишат предварително. Както е обичайно, при почти всеки тест се изявяват различни грешки, които следва да бъдат отстранени. При това винаги приоритет се дава на конструктивността, по-точно:
На всеки програмист е ясно какво се разбира тук под „чисто" решение — то е съобразено със запазване на всички добри качества на програмата — прег- ледност, ясна структура, способност за лесно модифициране, запазена просто- та и т. н. При втората алтернатива се предпочита все пак „чистото" решение, въпреки че то изисква повече време и усилия. С това се осигурява обаче по- лесното съпровождане на продукта в бъдеще. 191
 Следва да се отбележи изрично — макар потребителят да задава свои фун-
кционални тестови примери, тестването се извършва от самите програмисти. Смята се, че макар това да елиминира независимото тестване, при възприетия модел и при относително малкия обем на решаваните задачи това не води до отрицателни последствия по отношение на валидността на разработвания соф- туер. 15.2.4. Съвсем практически аспекти Дори при най-добре планираните разработки и добре комплектовани ко- лективи могат понякога да възникнат проблеми. Един не толкова рядко срещан случай е надценяването на собствените (на колектива) възможности. Идва момент, в който става ясно, че сроковете няма да бъдат спазени. Ако този момент е все още достатъчно отдалечен от крайния срок, възможна е оценка на прилаганите процедури и евентуални про- мени в тях. Може обаче да се окаже, че е късно за дадения проект да се правят резул- татни промени. Няма друга възможност, освен изпълнителят да се обърне към възложителя и да поиска някаква форма на облекчение — удължаване на срока, временен отказ от определени планирани за реализация функции, отлагане на дадено средство за следващата итерация. Във всички случаи отрицателните стра- ни на такъв подход са по-добро решение, отколкото сляпата надежда за благоп- риятен изход в последния момент. Друг доста често срещан случай са клиентите (възложители), които не са склонни твърде да общуват с разработчика. Те не искат да определят средствата за реализация в поредната итерация, нито пък да създават тестови примери. На пръв поглед това не е никак лошо, но опитният софтуерист знае много добре, че в един момент спестеното време и неприятни моменти от липсата на комуни- кация с възложителя ще му се стоварят в двоен и троен размер, когато клиен- тът започне да експлоатира продукта и реши, че не е получил това, което си е представял. Ясно е, че всякакви промени на този стадий са много по-трудни (понякога невъзможни) и по-скъпи. Обикновено опитният изпълнител се е пог- рижил чрез подписания договор да няма никакви задължения за промени в та- къв късен момент. Но дори само усилията да убеди клиента в правотата си са достатъчно неприятни и отнемат време. Да не говорим, че ефектът от един неу- довлетворен потребител (макар и изключително по негова собствена вина) е във всяко отношение отрицателен за разработчика. Следователно разработчикът просто е длъжен във възможно най-ранен мо- мент да убеди възложителя да му сътрудничи. Във всички случаи, но особено при ХР е абсолютно недопустимо по време на разработката програмистът да се уповава на собствените си догадки вместо на ясно изразените изисквания на възложителя. Вероятно най-доброто решение е да се обяснят максимално наг- ледно на възложителя тежките последици от нежеланието му да участва в кръга на своята компетентност в разработката. Ако дори тогава няма резултат, изво- дът е, че сигурно тази разработка не си струва усилията. Друг важен практически проблем е текучеството. За България този проб- лем съдържа и известен момент на безвъзвратност, доколкото движението на 192
програмистите към чужбина е особено интензивно и не толкова често веднъж заминалите се връщат. А ако се върнат, това е знак, че може би програмистът не е чак толкова добър специалист. Впрочем известен „оборот" на членовете на колектива действа освежаващо. Ръководителят на екипа обаче винаги следва да се интересува от мотивите на напускащия. Ако те са свързани с по-добри мате- риални условия, каквито една малка софтуерна фирма по-трудно може да оси- гури, това не е толкова тревожно, най-малкото едва ли може да му се противос- тои. Ако обаче мотивите на отиващия си се дължат на нисък професионализъм във фирмата, на недобра атмосфера, на лоша организация, на неудовлетворе- ност от равнището на разработваните проекти, това би следвало да бъде сигнал за сериозния ръководител. Естествено, тук стои въпросът и доколко един на- пускащ програмист може да навреди на фирмата, отнасяйки със себе си опре- делена информация, натрупана по време на работата му там. От една страна това, че се работи в двойка, запазва почти напълно възможностите на колектива безболезнено да продължи работата си. От друга страна, са общите проблеми от опасностите от изнасянето на информация навън от фирмата, но това е тол- кова общ проблем, че разискването му тук не е смислено. 15.3. Правни проблеми 15.3.1. Необходимост от специализирана правна култура След като видяхме какво е най-вероятното развитие на една новосъздадена малка софтуерна фирма и разгледахме екстремното програмиране (ХP) като една подходяща възможност за организиране на разработването на определени типове програмни продукти, не може да не отбележим още едно нещо, без което ръково- дителят (собственикът) на такава малка фирма не може да има сериозни резултати. Става въпрос за една минимална правна култура, свързана със софтуера. Дори придобиването на минимални знания обаче в тази област според учебните планове по софтуерни технологии във водещите университети в САЩ [7] изискват от един до три специални курса. Поради това тук само ще набележим основните направле- ния, по които въпросният ръководител следва да придобие ориентация и знания. Необходимо е да се знае, че въпросите за разработването, разпространени- ето, съпровождането и разширяването на програмните продукти в правото са предмет на разглеждане от теорията, съответно законите, свързани с интелекту- алната собственост. При това положение разработчиците на софтуер трябва да са наясно с правата и отговорностите, произтичащи от тях. Като следствие идват договорите, които се сключват във всички изброени току-що случаи. Несъмнено софтуеристите трябва да познават стандартните лицензионни практики, а така също в какви случаи какви отговорности носят за евентуални вреди, които разра- ботеният и/или разпространяван от тях софтуер е причинил. Както вече се каза, нито в следващите няколко страници, нито дори в рамките на един или няколко курса е възможно достатъчно дълбоко и всестранно усвояване на тази материя. Тя просто изисква юридическо образование. Това, което се опитваме да постиг- нем обаче, е да убедим софтуеристите, че има немалко случаи, които те трябва да са в състояние да идентифицират и в които няма друг начин, освен да се обърнат за намиране на решение към юрист — тесен специалист в областта на софтуера. 193
15.3.2. Закони за интелектуалната собственост
Основната цел на законите за интелектуална собственост е да насърчават разработването и разпространението на иновации, така че те да се ползват от обществото. Ясно е, че създаването им (както и сътворяването на произведения на изкуството и литературата) обикновено изисква инвестирането на време, енергия и други ресурси от страна на знаещи, умеещи и надарени хора. За да окуражат подобни дейности, законите за интелектуална собственост предвиж- дат възможността да се придобиват изключителни права за контрол върху тър- говската експлоатация на иновационната (или артистична) творба за определен период от време. По този начин, от една страна, се защитават интересите на творците. От друга страна, и обществото има полза, защото получава възмож- ност за достъп до съответното творение при определени условия, а по-късно, след изтичането на определения законов срок — и напълно свободно. Има случаи, когато дадено интелектуално произведение не попада в рам- ките на действие на закона и остава за напълно свободно ползване от всекиго. Това става при определени условия, например:
По принцип даден закон за интелектуална собственост съдържа няколко елемента:
дейности. 4. Процедури, които позволяват да се установи има ли нарушения на тези права. 5. Процедури, които се прилагат при установено нарушение. 15.3.3. форми на правна защита на софтуера като интелектуално произведение От няколко десетилетия юристите усилено се опитват да намерят най-подхо- дящата правна форма за защита на софтуера. Това се прави и в България от около 20 години насам [5]. Първоначално тенденциите са били да се прилага патент- ното право въпреки значителните проблеми, свързани с идентифицирането на софтуера като съответстващ на съществуващите изисквания за патентоспособ- ност. Особени трудности предизвиква връзката на изобретенията (основния па- тентоспособен обект) с техниката. В българския закон от 1993 година [8] напри- мер основната характеристика "новост" се определя чрез понятието техника. He- 194
зависимо от това има прецеденти от 70-те и 80-те години в САЩ, когато в специ- фични случаи програми (например за управление на производството) са получа- вали патент. През 1977 г. авторът на тези редове заедно със съавтори също успя да получи 5 авторски свидетелства за изобретения (по току-що цитирания бъл- гарски закон те могат да бъдат трансформирани в патенти) за специализирана програма, след като обаче алгоритмите й бяха преобразувани до вид на схеми на техническо устройство, т. е. необходими бяха ред неестествени действия. Междувременно с появата и развитието на персоналните компютри и из- менението на формите и мащабите на разпространение на софтуера юристите започнаха да намират за все по-подходящо авторското право и да се оттеглят от патентното право. В българското право това е доведено до изричен текст в Закона за патентите: „Чл.6. (2) Не се считат за изобретения:
За пълнота следва да отбележим, че е имало един период, в който са пола- гани значителни усилия за създаване на специално право {sui generis) за соф- туерните продукти. Оказало се е обаче, че такъв опит ще се сблъска с непре- одолими теоретически и практически трудности и затова постепенно е бил изоставен. Преди да се спрем малко по-подробно на авторскоправната закрила, ще от- бележим и още една правна форма на защита — тази на марките. Законът за марките и географските означения [9] от 1999 година дава възможност да се пол- зва специфична защита, отнасяща се преди всичко до търговската дейност, свър- зана с разпространението на софтуера, както и със съпровождащите го услуги. В края на 15.2.4. се повдигна въпросът за проблемите, които може да пре- дизвика напускането на фирмата от страна на даден специалист, запознат с мал- ко или повече фирмени тайни. Сериозни правни средства за защита в това отно- шение може да предостави Законът за защита на конкуренцията. 15.3.4. Защита на софтуера чрез авторсното право Вече казахме, че в момента най-пълна и най-адекватна защита на софтуера предоставя Законът за авторското право и сродните му права [6]. Сред закриляните обекти в чл. 3 (1), т. 1 са посочени изрично и компю- търните програми. Те попадат под общата дефиниция за обект на авторското право, която включва "всяко произведение на литературата, изкуството и нау- ката, което е резултат на творческа дейност и е изразено по какъвто и да е начин и в каквато и да е обективна форма". Друго важно понятие е автор, който чл. 5 определя като „физическо лице, в резултат на чиято творческа дейност е създадено произведение". Не трябва обаче да влизаме в заблудата, че този автор е непременно и винаги носител на авторските права. В същия член веднага се пояснява, че "други физически или юридически лица могат да бъдат носители на авторското право". Последното пояснение е изключително важно за софтуера. To e развито в чл. 14, посветен специално на програми и бази данни и гласи: „Ако не е угово- 195
 рено друго, авторското право върху компютърни програми и бази данни, съз-
дадени в рамките на трудово правоотношение, принадлежи на работодате- ля." Както ръководителите (собственици) на софтуерни фирми, така и разра- ботчиците трябва да са наясно с правата си, произтичащи от този текст. Те след- ва също така да знаят, че разработването на софтуер може да се възлага и под други форми — не само в рамките на трудов договор. Такава възможност е поръчката и тогава според чл. 42 авторското право принадлежи на автора (ако договорът не гласи друго), но пък поръчващият има право да използва произве- дението без разрешение от автора за целта, за която е било поръчано. Важно е също да се знае, че ако е постигнато споразумение в рамките на трудовото правоотношение за друго разпределение на авторските права, то това трябва да бъде оформено документално във валидна правна форма. Има и още един текст, чиято цел е да възстанови справедливостта при определени случаи. Това е чл. 41 (3), според който: „Когато трудовото възнаграждение на автора по вре- мето, през което е създал произведението, се окаже явно несъразмерно на при- ходите, реализирани от използването на произведението, авторът може да поиска допълнително възнаграждение. Ако не се стигне до съгласие между стра- ните, спорът се решава от съда по справедливост." Доколкото в последния текст се споменаха бази данни, следва да се отбе- лежи, че в чл.11 (1) се определя и техният статут — „авторското право върху сборници, антологии, библиографии, бази данни и други подобни принадлежи на лицето, което е извършило подбора или подреждането на включените произ- ведения и/или материали, освен ако в договор не е предвидено друго". Един от най-съществените въпроси е този за ползването на произведение- то. В чл. 23 се третира въпросът за свободното ползване. Изрично е посочен специалният режим, отнасящ се до програмните продукти; „Без съгласие на автора и без заплащане на възнаграждение се допуска:... 2. Използването на части от публикувани произведения или на неголям брой малки произведе- ния, с изключение на компютърни програми и бази данни..." Този текст всъщ- ност се отнася до ползването в други произведения и показва, че не е възмож- но, когато пишем собствени програми, да ползваме пасажи от чужди програми. От практическа гледна точка още по-важен е друг текст, чл. 25, също трети- ращ софтуера като изключение: ,Изготвянето на копия от вече публикувани произведения се допуска без съгласие на автора и без заплащане на възнаграж- дение само за лично ползване. Това не се отнася за компютърните програми и архитектурните произведения." Смисълът на този текст е пределно ясен на всеки човек, който знае що е програма за компютър. Темата за пиратството е толкова дискутирана, предпри- еманите мерки срещу него така добре известни, че по-нататъшното й обсъжда- не е безсмислено. Колкото и да е странно за професионалистите, които знаят добре колко е животът на една програма, съгласно чл. 28a: „Авторското право върху компю- търните програми или бази данни... продължава 70 години след разгласяване- то на произведението." Ако авторът е известен, прилага се общата разпоредба на чл. 27, която включва периода до смъртта на автора и 70 години след това. Съществени за практиката са текстовете от закона (чл. 36), които опреде- лят начините на използване на произведението. Според ал. 1: „С договора за използване на произведението авторът отстъпва на ползвател изключи- 196 телното или неизключителното право да използва създаденото от него произведение при определени условия и срещу възнаграждение." По-нататък в същия член, в ал. 2, се изяснява смисълът на изключително- то право — лишава автора от възможността да ползва сам произведението или да отстъпва правата си върху него на трети лица — разбира се, само на угово- рената територия и за уговорения срок и други условия. Тези ограничения не са в сила, когато предоставеното право е неизключително (ал. 3). Чрез ал. 4 се защитават правата на автора, в случай че той поради незнание или друга подоб- на причина не си дава сметка за разликата между предоставяне на изключител- но и неизключително право — предвидено е изключителното право да се отстъпва само изрично и писмено. В закона има специален раздел (VII), посветен на използването на компю- търните програми. Ако по законен път е придобито право за ползване на прог- рама, с нея могат да се извършват всички действия, необходими за постигане на целите й (иначе казано, за това, за което е платено). Тези действия са избро- ени твърде подробно в чл. 70. Казано е изрично (чл. 71) и какви допълнителни действия са позволени на законния притежател на правото на ползване без изричното съгласие на ав- тора — създаване на резервно копие, изследване на свойствата на програмата и дори по-специализирани действия от рода на трансформиране на кода. Послед- ното обаче е допустимо при определени ограничения, изброени в същия член и целящи да се предотврати използването на програмата или части от нея в друга програма. Както беше упоменато в 15.3.2., законът предвижда мерки при нарушава- не правата на авторите. От една страна всеки автор може да претендира за обез- щетение от този, който му е причинил вреди, нарушавайки правата му по този закон(чл. 94). От друга страна, нарушителят носи и наказателна отговорност. Специ- ално за софтуера се отнася чл. 97 (1), т. 8 и 9, които гласят, че: „Който в нару- шение разпоредбите на този закон:
От така разгледаните най-съществени за софтуера текстове в закона става ясно на каква защита могат да разчитат разработчиците на софтуер — ръково- дители и преки изпълнители, какви са правата им, какво трябва да спазват, кога- то ползват чужд софтуер, и какво рискуват, когато нарушат правилата. Литература 1. Raffa M., Zollo G., Caponi R., The short but interesting life of small software firms. Achieving Quality in Software, Proceedings of the third international conference on achieving quality in software, 1996, Chapman & Hall, London, 1996, p.103—117. 197
ст. н. с. II ст. д-р Нели Милчева Манева ст. н. с. II ст. д-р Аврам Моис Ескенази СОФТУЕРНИ ТЕХНОЛОГИИ Корица Михаил Руев Технически редактор Симеон Айтов Компютърна обработка Георги Георгиев Коректор Даниела Славчева Българска. Издание първо. Излязла от печат 2001 г.
Издателска кьща Анубис, 1124 София, ул. Младен Павлов № 1, тел.443 503,9441643. Търговски отдел 1124 София ул. ,Никола Ракитин" №2, тел. 946 16 76, тел./факс 946 14 32 Печатница „Симолини"—София ISBN954-426-3ll-X Каталог: 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. Сподели с приятели:
|
