Софтуерни технологии
Изтегляне 3.19 Mb.
|
- Навигация на страницата:
- 10.6. Оценяване при обектна ориентираност
- Табл. 10.7. Езици ■ производителност
- 11. МАРКЕТИНГ НА СОФТУЕРА 11.1. Общи съображения
- 11.2. Определения за маркетинг
- 11.3. Основна маркетингова концепция
- 11.4. Маркетингова стратегия
- 11.5. Пазарен жизнен цикъл
- 11.6. Позициониране и марка
- 11.7. Моделиране на софтуерния пазар
ЧМ = 5.288 х ХРПК1047 за ХРПК < 10 ЧМ = 2.060 х ХРПК1047 х f1 х f2 х... х f14 за ХРПК >= 10, където обозначенията имат същия смисъл, както при COCOMO, a fi са подобни атрибути, но само с по 2 възможни стойности.
Отново е инспириран от COCOMO. Основава се на 20добре дефинирани и 25 недостатъчно добре дефинирани фактора, определящи цената на разработ- ване на софтуера и на производителността. Доведен е до търговски продукт, но 136
не е достатъчно добре документиран. От потребителя се изисква да отговори на 100 въпроса, свързани със софтуерния проект. На тяхна основа се установяват стойностите на входните параметри. Авторът на модела Кейпърс Джоунс твър- ди, че с 90% вероятност моделът дава оценка в рамките на точност от +/- 15%. 10.5.3. ESTIMACS Този модел с автор Рубин е съсредоточен преди всичко върху разработва- нето. Претенциите му са също за точност в границите на 15%. Включва следни- те модули:
10.5.4. BANG Авторът на този модел е една от най-известните фигури в областта на соф- туерните технологии — Де Марко [8]. Методът е от типа на функционалните точки, но се знае, че е правен независимо от Олбрихт. Докато моделът и мето- дът на функционалните точки на Олбрихт е насочен най-вече към информаци- онни системи и бизнесприложения, целта на BANG e системният софтуер и този за научни приложения. Основните елементи, които се установяват и броят при този метод, са:
както и няколко фактора, свързани със спецификата На системите в реално вре- ме, каквито са между другото и операционните системи (преходи, състояния на чакане). 137
 Това значително по-широко множество от фактори дава основание този
модел да се разглежда като надмножество над модела на Олбрихт. Естествено, тази характеристика прави метода по-трудно приложим, което се е отразило и на далече по-малкия му брой потребители. 10.6. Оценяване при обектна ориентираност Оценяването на разходите и продължителността на разработване на соф- туер, създаден с обектно ориентирани методи, изисква специално внимание. По този въпрос много показателна е [9], където се излагат резултати от сравни- телно изследване на софтуер, създаден с различни средства, някои от които обектно ориентирани. Интересна е приложената технология, доколкото данни- те за езика Ада9х се е наложило да бъдат симулирани, а за други езици — да бъдат получени чрез трансформация на основата на аналогични проекти. Сами- ят софтуерен продукт е в областта на телекомуникациите Показано е, че модели, свързани с броя първични редове код, не могат да бъдат прилагани. Едновременно с това обаче се демонстрира, че методът на функционалните точки е приемливо приложим. Поради това, че е трябвало да се сравняват обектно ориентирани с процедурни езици, не е било възможно прилагането на специално създадения за обектно ориентирани приложения [10] модел и метод MOOSE (Metric for object-oriented system environment). Основ- ният извод от изследването е, че обектно ориентираните езици осигуряват по- висока производителност от процедурните. Към това трябва да се направи бе- лежката, че изводът засяга преди всичко програмирането, интегрирането, тест- ването и управлението, в много по-малка степен проектирането и по никакъв начин анализа, формулирането на изискванията и документирането. Направе- ни са изследвания и произтичащи от тях заключения, че при обектно ориенти- раното програмиране намирането на грешки в процеса на разработване става по-резултатно, отколкото при процедурните езици. Резултатите относнопроиз- водителността се виждат от табл.10.7. Числата в клетките са в човекомесеци.
Табл. 10.7. Езици ■ производителност Табл. 10.7. Езици и производителност Освен споменатия вече модел MOOSE известна е и една опростена версия
138
ляне приложението на метода във възможно най-ранен момент. Признава се, че точността при такъв подход силно страда, но се изхожда от презумпцията, че една ранна, донякъде неточна оценка е за предпочитане пред една точна, но късна. Засега приложението на метода на Снийд е силно ограничено. Известно е и едно предложение на Боем [12], основано на модела и метода СОСОМО 2.0, наречено обектни точки (object points). Тези точки се генери- рат чрез преброяване на екрани, отчети, определен тип модули, после се суми- рат с подходящо определени тегла и получената сума се донастройва с оглед свойства за повторно използване. За съжаление и този метод трудно може да бъде приложен преди завършването на фазата на проектиране. За стъпка в положителна посока се смята предложеният в [13] модел. В него на основата на предварително създаден бизнесмодел (такъв може да се прави за бизнесприложения и особено се препоръчва за приложения, работе- щи в Интернет, свързани с електронна търговия) се прилага методът System Meter, за който се твърда, че дава правдоподобни оценки за трудоемкостта на разработването. Литература
10. Kemerer, C.F., MOOSE: Metrics for Object-Oriented Systems Environments, Proc. ofASM93 Conference, Orlando, FL, November 1993. 11 .Sneed H., Calculating Software Costs using Data (Object) Points, SES, Ottobrunn, Germany. 12. Boehm B.W., B.Clark, E.Horowitz, Cost models for future life cycle process: COCOMO 2.0, Ann. Software Engineering, 1(1), p.l—24. 13.Moser S, B.Henderson-Sellers, VB.Misic, Cost estimation based on business models, The Journal of Systems and Software, 49(1999), p. 33—42. 139
 11. МАРКЕТИНГ НА СОФТУЕРА
11.1. Общи съображения Както става ясно от изложението дотук, софтуерът се разглежда винаги като продукт, който рано или късно трябва да се реализира на пазара. При това положение е невъзможно да се избегне маркетинговият аспект. Двете основни понятия, с които ще боравим в тази глава, са софтуер и маркетинг. При такава постановка единият възможен аспект за изследване е софтуе- рът, необходим за нуждите на маркетинга. Това е тема, сама по себе си важна от практическа гледна точка. He e трудно да се разбере, че в съвременни- те условия е немислимо да се осъществява маркетингова политика без съответ- ни софтуерни средства. От най-общи съображения е почти очевидно, че за цел- та е необходима разнообразна информация, организирана по такъв начин, че да е достъпна за съответните специалисти и лица, вземащи решения. При това този достъп трябва да е достатъчно бърз и ефективен при запитвания, формули- рани по разнообразен начин. Освен това са необходими разнообразни изходни документи за нуждите на анализа и отчетността. Непосредственият извод е, че не може да се мине без съответните технически средства и софтуер. Общото понятие, което се използва в тези случаи, е маркетингова информационна система. В последните години тя не може да бъде друга освен компютризира- на. Тази тема обаче излиза от обсега на настоящите разглеждания и затова пове- че няма да се спираме на нея. Остава за разглеждане вторият аспект — има ли специфика в маркетинга на софтуера и каква е тя [1]. Отговорът на този въпрос следва оттук нататък до края на тази глава, като се дават общите понятия и принципи на маркетинга, илюстрират се преди всичко с примери от областта на софтуера (и по-рядко на хардуера) и се очертава спецификата на маркетинговия софтуер, където я има. 11.2. Определения за маркетинг Твърде много определения за маркетинг могат да се намерят в литерату- рата. Това се обяснява с няколко фактора — сравнително краткия период на развитие на теорията на тази област, невъзможността (поне в настоящия мо- 140 мент и обозримото бъдеще) за формализиран подход, решаващото влияние на динамичната практика на маркетинга върху теорията и др. За илюстрация на разнообразието на подходите ще посочим малък брой от известните дефини- ции [2].
За нуждите на нашето разглеждане най-подходящо е да разглеждаме марке- тинга като съвкупност от научни, организационни и технически средства за изследване на състоянието и въздействие върху развитието на пазара. 11.3. Основна маркетингова концепция Отново както и при проблема за качеството, във фокуса е потребителят. Той е основополагащият елемент във философията на маркетинга. Формулира- на в едно изречение и във възможно най-кратка форма, тази философия, наре- чена още основна маркетингова концепция, гласи: задоволяване нуждите на потребителя при печалба. Разбира се, тази формулировка може да се мо- дифицира, без това да доведе до съществено смислово изменение. В [3] напри- мер тя е, че постигането на фирмените цели зависи от определянето на потребностите и желанията на целевите пазари и от задоволяването на клиентите по начин, който е по-рентабилен и ефективен от този на кон- курентите. Не трябва да се забравя, че в областта на производството на софтуер (как- то и в някои други области, свързани предимно с научни изследвания и въобще с перспективни, но рискови и евентуално нерентабилни начинания) съществу- ват организации, чиято приоритетна цел не е непременно печалбата, нито пре- димство над конкурентите по отношение на рентабилността или ефективността. Типичен пример са организации с идеална цел или държавни институции, чиято основна цел е да разработят продукт с определени авангардни качества. Пос- ледният, изнесен на пазара, се очаква да повлияе на характеристиките на про- дуктите, разработвани от фирмите и други подобни организации. Добър при- мер в това отношение са някои от първите компилатори, разработени в чужби- на преди около четири десетилетия (Фортран, Алгол). Те не са били обект на търговска разработка, финансирани са били без оглед на непосредствената пе- чалба, но са оказали огромно влияние върху качеството на разработените по- късно с тяхна помощ софтуерни продукти. Такава практика продължава да съ- ществува и сега, макар че финансиращите институции все повече държат ре- зултатният продукт от тази "непечеливша" схема на разработване да бъде лес- 141
 Всеки софтуерен продукт трябва да предоставя удобен и лесен за усвоя-
ване потребителски интерфейс. Това става все по-актуално поради драс- тичното нарастване броя на потребителите и разширяването на спектъра им. Не са малко случаите, когато поради недобре проектиран или реализиран ин- терфейс много от възможностите на продукта остават неизползвани от пове- чето потребители. Това от своя страна директно води до намаляване броя на продажбите му. Особено място сред тези атрибути на качеството заема цената му. Тук става въпрос за минимизиране разходите по разработването, но и особено по съпровождането, доколкото последните са неочаквано големи. He e възможно да бъдат постигнати едновременно най-добри стойности за всички изброени атрибути. Просто защото някои от тях направо си противоре- чат. Веднага се вижда например, че ако интерфейсът се направи прекалено ,ДРУ- желюбен" (естетичен, ергономичен, лесноразбираем, снабден с много помощ- ни указания и пp.), ефективността на програмния продукт ще пострада. Нещата се усложняват и от факта, че цената на подобренията в много случаи не расте линейно, т. е. малки подобрения в определен атрибут могат да изискват значи- телно (дори експоненциално) нарастване на вложените ресурси, следователно и на цената. Всъщност, погледнато най-общо, задачата на софтуерните технологии е да покаже как да се произвежда софтуер, който да притежава в оптимално съотно- шение упоменатите характеристики. Това е смисълът на преодоляването на соф- туерната криза, станала причина за появяването на тази дисциплина. Общо е обаче мнението, че софтуерната криза все още не е преодоляна. Независимо от значителните постижения, подобряващи методите и технологиите на разработ- ване на софтуер или довели до създаването на мощни инструментални средст- ва, изглежда, че нуждите от софтуер нарастват по-бързо, отколкото се подобря- ва производителността на разработчиците на софтуер. Тук не са толкова интересни установените от проучването най-прилагани технологии и методи (прототипиране, езици от четвърто поколение, методи и сред- ства за изграждане на графически потребителски интерфейс), колкото тези, кои- то не се прилагат. За повечето от тях преобладаващият отговор (в различен про- цент) е най-ниската степен — "не проявявам никакъв интерес". Най-отблъсква- ната методика се оказва прилагането на метрики и различни техники на измерва- не. Обяснението е, че сред теоретиците не съществува единно становище относ- но това, кои метрики кога да се прилагат, както и че липсват за повечето теоре- тично разработени метрики съответни програмни средства, които ги реализират. Това, разбира се, не пречи големи фирми (Hewlett—Packard, IBM) да ги прилагат масово и задължително. Особено учудващо е, че практиците нямат голям интерес и към обектно ориентираните (OO) методи. Тук обяснението се търси в това, че от една страна, за проектантите и програмистите от по-възрастното поколение тази парадигма е необичайна и трудна за усвояване, че немалка част от тях се занимават със съпровождане на софтуер, създаван преди доста време с тогаваш- ните средства и неподлежащ на преработване с ОО-методи, че независимо от неоспоримите им предимства по отношение на валидирането на програмите OO- методите засега изостават от класическите структурни методи. Свързан с този е и въпросът, докъде всъщност е науката в създаването на софтуерни продукти. Ясно е, че ако трябва например да се натоварят повечко пакети в багажника на кола, никой не решава въпроса математически (въпреки изключително елегантните методи, които математиката дава за целта) — всеки прави няколко проби и решава проблема. В много случаи софтуеристите не могат без формални методи или пък биха постигнали по-лоши резултати без тях. Във всеки случай с такива методи трябва да се процедира, когато задачата е добре формулирана и разбрана или пък е с рутинен характер. Когато обаче е поставен сложен проблем или пък такъв, изискващ творческо решение, еврис- тичният подход е по-добрата възможност. 1.3.4. Наука и практика Както в много други области, и в полето на софтуерните технологии прак- тиците невинаги са склонни да следват незабавно теоретиците. Това е обясни- мо, а и „здравословно". Не всяка теория се оказва толкова полезна, колкото е изглеждала на пръв поглед, а понякога се оказва дори, че не е вярна. От друга страна, пренастройването към един нов метод, език или технология изисква от крайния му потребител (ръководител, проектант, програмист) усилия и време за усвояването му. Много поучително в това отношение е едно изследване, из- вършено наскоро в САЩ. Анкетираните професионалисти практици са отгово- рили на въпроси, свързани с приложението на нови методи, предлагани им от науката за софтуерните технологии. Формулирали са отговора си съгласно след- ната петстепенна скала:
16 Литература
17  но усвоим от практиката и да окаже върху нея положително въздействие. Веро-
ятно най-добрият пример за такива финансиращи организации в областта на софтуера в България през 90-те години са двата фонда към Министерството на образованието и науката — за научни изследвания и за структурна и техноло- гична политика, респективно комисиите им по информатика. 11.4. Маркетингова стратегия Всяка организация трябва да има своя маркетингова стратегия. Последна- та се състои от две стъпки:
11.4.1.Целеви пазар Целевият пазар се определя като съвкупност от купувачи, притежаващи общи потребности или характеристики, които организацията решава да обс- лужва. За да определи своя целеви пазар, всяка организация трябва да го изследва с оглед на своите технологични, финансови, кадрови и други възможности. Пос- тигането на тази цел става най-удобно чрез прилагането на техниката на сег- ментиране на пазара, което означава разделяне на пазара на хомогенни под- пазари, т. е. на групи от подобни клиенти. Сегментирането може да се извърш- ва по различни признаци. Когато става въпрос за софтуер, тези признаци са следните. Индивидуален/индустриален. Първоначално пазарът е бил изключително от тип индустриален или корпоративен. Практически не е имало индивидуални потребители. Всички софтуерни продукти са били разработвани за компютри, притежавани и използвани за нуждите на организации (банки, заводи, търговс- ки фирми, армия и пp.). С възникването на персоналните компютри през 80-те години и с изключително интензивното нарастване на броя им, броят на инди- видуалните притежатели на компютри, a c това и на софтуер за тях, също се увеличава неимоверно. Поради тази причина в момента се налага сегментиране на пазара по този признак. Разбира се, има софтуерни продукти, които се из- ползват еднакво и в организациите, и от индивидуалните потребители — текс- тови редактори, електронни таблици, електронни калкулатори, средства за ком- пютърна презентация и др. Има обаче твърде много, които са предназначени точно за единия от тези два типа. Софтуерът за управление на производствени процеси, за резервация на самолетни или железопътни билети, за банково обс- лужване, за проектиране на големи обекти и т. н. се използва единствено от корпоративен тип потребители. От друга страна пък, програмни продукти за лично счетоводство, за попълване на лични данъчни декларации, компютърни игри и т. н. се ползват изключително от индивидуални потребители. Трябва оба- че да се отбележи, че дори за софтуер, използван от двата типа потребители, сегментиране по този признак е възможно, защото организацията производи- тел-разпространител може да реши да се занимава само с единия тип. 142
Възраст. Производителите на компютърни игри очевидно се насочват към детската и юношеска публика. Определянето на целеви пазар по този начин води по-нататък до съобразяването на цялата маркетингова политика с негови- те особености, което впрочем е вярно и за всеки друг определен целеви пазар. С развитието на информационното общество се очаква сред потребителите на софтуер все по-често да се оказват лица от всяка възрастова група и вероятно в много случаи този признак ще се окаже от значение за определянето на целеви пазар. Професия. Този признак е твърде очевиден. Ясно е, че адвокатите се нуж- даят от специфични за работата си информационни системи, архитектите и ин- женерите — от софтуер за нуждите на проектирането в дадената област. Спи- съкът може лесно да се продължи с лекари, фармацевти, програмисти, търговци на дребно, търговци на едро и т. н. Определянето на целеви пазар по този приз- нак може да стане твърде отчетливо. Образование. По принцип доскоро потребители на софтуер бяха хора с високо и специализирано образование. С масовизирането на компютрите и раз- ширяването на потребителската аудитория равнището на образование започва все повече да губи значението си и следователно сегментирането по този приз- нак започва да става от значение. География. Определени типове софтуер се влияят от това, дали са за мес- тно или международно ползване. Най-типични в това отношение са програмни- те продукти, свързани с естествения език. Доскоро текстовите редактори силно зависеха от този признак, но като че ли напоследък най-разпространените от тях започват да стават все по-независими благодарение на това, че допускат различни азбуки, съдържат средства за проверка на правописа за всеки език, за спазване на специфичните правила на пренасяне на нов ред т. н. Корсуерът (софтуер за нуждите на обучението) обаче продължава силно да зависи от мес- тния език. От една страна, в много случаи той е предназначен за подрастващите и трябва изцяло да бъде на съответния език, от друга — езиково универсализи- ране както в случая на текстовите редактори не е възможно, тъй като за всеки предмет и за всяка тема се създава отделен обучаващ софтуер. Това впрочем е една от силните възможности на местните фирми за намиране на свой целеви пазар. Тип организация. Това е сегментиране, което може да достигне до значи- телна дълбочина. Обикновено не е достатъчно да се определи типът организа- ция потребител на най-високо ниво на общност — военна, научна, банкова, търговска. Интересите в областта на науката например са най-разнообразни и ако за някои типове програмни продукти дори такова генерално сегментиране е достатъчно (почти всяка научна организация се нуждае от софтуер за статис- тически пресмятания, широка е общността на тези, които използват софтуер за различни видове симулации), то има и специфични нужди на отделните науки, което налага по-дълбоко сегментиране на пазара по тях. Любопитно е, че сами- те производители на софтуер се нуждаят от твърде разнообразни програмни продукти. Във връзка с това има класически пример за несъобразяване с особе- ностите на пазара, респективно за това, че производителят е пропуснал да ана- лизира сегментите и да определи своя целеви пазар. Става въпрос за разпрост- ранения навремето език за програмиране PL/1. Той е бил замислен и реализи- ран през 60-те години като език за всякакви нужди на всякакви потребители 143
(програмисти и проектанти). Скоро обаче се оказало, че политика, основана на
такава философия, е невъзможна и само мощта, допълнителните лостове, амби- циите и усилията на фирмата производителка успяват да задържат този софтуе- рен продукт на пазара относително по-дълго. Като изключим обаче един прова- лен опит в средата на 80-те години за създаване на компилатор за PL/1 за персо- нални компютри, никой вече не говори за този език — единствено някои потре- бители на по-стари разработки, за които преходът към нещо по-модерно остава голям и скъп проблем. В противовес на това може да се посочи езикът Фортран, чийто пазарен сегмент е много по-ясно определен и това продължава да го дър- жи на пазара. Към последния пример впрочем ще се върнем в друг аспект малко по-късно. Примерът с PL/1 e поучителен в още едно отношение — щом за една орга-
Още две са важните понятия, свързани с целевия пазар. Първото е пазарен прозорец и означава пренебрегнати от производителите и търговците сегменти от пазара. Второто е пазарна ниша. Това е такъв сегмент, на който подхожда в най-голяма степен конкретният продукт или опит. Първият компонент на мар- кетинговата стратегия е определянето на целевия пазар. За конкретната фирма е толкова по-добре, ако някой от определените за даден програмен продукт сегменти от фиксирания целеви пазар се окаже пазарна ниша. 11.4.2. Маркетингов микс Маркетингов микс се нарича съвкупност от четири управляеми мар- кетингови средства — продукт, цена, пласмент и промоция. Оригинално- то английско название — Marketing mix — понякога се превежда на български и като маркетингов комплекс. В английски език понякога се нарича „four p-s" — от първите букви на английските названия на казаните току-що четири сред- ства: product, price, place, promotion. За да поясним какво точно се има предвид под тези четири средства (нари- чани понякога и променливи) и доколко те подлежат на управление, да вземем следния пример. Да допуснем, че фирмата X е решила да атакува пазарния сег- мент на средните училища, като се насочва към потребителите на персонални компютри. Този пример впрочем от 1998 година става особено актуален и реа- листичен, като се вземат предвид предприетите активни мерки от държавата за въвеждане на информационните и комуникационни технологии в средното учи- лище. Какъв продукт би могла да предложи на пазара фирмата X? Една възмож- ност е това да е интегриран програмен пакет, който да съдържа най-необходи- мите за ученика средства. Разумно би било в този софтуерен продукт да се включи текстообработваща компонента, значително по-проста от известните и разпространени на пазара, непременно на български език, с включени средства за проверка на правописа (spell-checker) и за пренасяне на нов ред. Друга не- обходима компонента е калкулаторът. Вероятно подходящо е включването на несложен файлов процесор, който да позволява създаването и използването на 144
прости информационни системи, Необходимост за ученика би била и компо- нента справочник за математически формули, а защо не и с възможности за символни пресмятания. Би могла да се включи и компютърна игра — не прека- лено интересна, за да не му отнема твърде много от времето, но все пак доста- тъчно привлекателна, за да му служи за отмора за кратки периоди от време. Едва ли си струва да се включват средства за комуникация (връзка с Интернет), поради безусловната популярност на стандартните. Оформяйки по този начин съдържанието на продукта, фирмата X следва да извърши за него в съответст- вие с изискванията на софтуерните технологии анализ за осъществимост в раз- личните му аспекти. Този анализ между другото следва да установи и кои от фиксираните компоненти ще се разработват от самата фирма, кои евентуално ще бъдат поръчани за разработка навън и кои следва да се вземат наготово след съответните процедури за придобиване на права за това. Цената е следващата променлива, чиято стойност следва да се определи. В случая, като се изхожда от това, че се отнася преди всичко за индивидуални пот- ребители с неголеми финансови възможност, цената ще трябва да се фиксира на възможно най-ниско ниво. Това е валидно и в случай, че се хвърлят усилия да се продава продуктът и на училища — общо взето, тези организации не разполагат с особени финансови възможности, разчитат преди всичко на бюджета (и много по-рядко на други източници — дарения, спонсорства, собствени приходи) и ве- роятно винаги ще изискват значителни отстъпки в цената, може би все пак за сметка на закупуване на повече от един екземпляр от продукта. Несъмнено тряб- ва да се вземе предвид, че продуктът ще се продава в България и следователно следва да е съобразен с мащаба на цените на софтуерните продукти в страната. По принцип за определянето на цената са известни две крайни страте- гии: пробив (penetration) и обиране на каймака (skimming-the-cream). При стратегията на пробива продуктът се лансира с ниска цена, за да се запази конкурентоспособност на пазара и заедно с това да се привлекат макси- мален брой клиенти. При стратегията на обиране на каймака фирмата започва с висока цена като визира тези от потенциалните клиенти, които имат вкус към новото и са в състояние да платят за него. По-нататък цената постепенно се понижава, за да обхване все по-широки кръгове от потребители. Трудно е да се каже каква стратегия предпочитат софтуерните фирми. Дъл- го време пример за стратегията на пробива даваше фирмата "Борланд". До на- чалото на 90-те години, когато все още беше конкурент на „Майкрософт", тя продаваше всички свои програмни продукти на цена 99 щатски долара. За тази цена е имало и едно основание, специфично за софтуера. Фирмата е била пре- ценила, че при такава цена повечето потребители биха предпочели да я платят, вместо да направят известен разход за копиране и след това да носят увеличава- щия се риск от използването на незаконен софтуер. Не се наемаме да кажем кои са били по-късно причините за тежките проблеми и метаморфози на тази фирма, но е факт, че от един момент продуктите й започнаха или да бъдат раз- бивани на твърде дребни, отделно продавани компоненти, или просто да се про- дават на много по-високи цени. Друга възможност при определянето на цената е съобразяването със сег- ментите от пазара, където се лансира продуктът. Има сегменти, които са по- малко чувствителни към цената, и потребителите в тях могат да приемат да пла- 145
тят повече. Ясно е, че в областта на софтуера такава сегментация има място и
ние я отбелязахме вече (индустриален/индивидуален потребител). Понякога мо- же да се окаже, че е необходима обосновка за подобна диференциация на цени- те и това обикновено се прави, като се сочат примерно повече гаранции, някои допълнителни професионални" възможности, по-голяма ефективност на про- дукта и пр. Впрочем софтуерните фирми биха могли да вземат пример в това отношение от авиокомпаниите,които имат голямо множество от тарифи в зави- симост от сегментите на пазара, които обслужват. Пласментът е свързан преди всичко с местата на пласиране на продукта и начините, по които това става. За програмен продукт, предназначен за учени- ци, едно подходящо място за разпространение са ученическите книжарници. Друг тип подходящи магазини са тези за музикални касети и дискети. Естестве- но, не трябва да се забравят и стандартните места, където се знае, че такъв тип продукти могат да се купят — за София например това са някои от книжарските щандове на площад „Славейков" и, разбира се, неголемият брой специализира- ни магазини за продажба на хардуер и софтуер. Макар и ceгa да прохожда, разпространението чрез Интернет добива все по-голяма популярност и в ника- къв случай не трябва да се пренебрегва, особено за този тип потенциални купу- вачи — учениците, за които световната мрежа е изключително популярна. Промоцията се разглежда като специфичен комплекс от реклама, персо- нални продажби, насърчаване на продажбите и връзки с обществеността, които фирмата използва за достигане на своите маркетингови цели. В дадения приме- рен случай подходящо място за пускане на реклами за продукта са например предаванията на специализираните музикални телевизии, за които се знае, че се следят от ученическата публика. Възможно е също продуктът да бъде обявен като награда в някои от състезанията по тези телевизии или пък в насочени към ученическата аудитория радиопредавания. Практикувана форма са промоцио- налните продажби в определени магазини, когато no преценка на фирмата мо- же да се обявят промоционални ниски цени. 11.5. Пазарен жизнен цикъл Въпросът за жизнения цикъл може да се разглежда в два аспекта — жизнен цикъл на разработването [4] и жизнен цикъл на готовия продукт. Макар тези аспекти да са свързани, удобно е с цел съсредоточаване върху определени ха- рактеристики те да бъдат разделени. 11.5.1. Пазарен жизнен цикъл на разработването на продукта Доколкото общият предмет на разглеждането ни е софтуерът, интерес пред- ставлява едно успоредно разглеждане на пазарния жизнен цикъл на разработ- ване и някой от популярните модели на жизнения цикъл на програмния продукт [5] — например този на Гънтър. Сравнението ще бъде по-лесно и по-обозримо, защото така избраният модел на Гънтър може да бъде разглеждан в хронологич- ната му част, а пазарният жизнен цикъл е от същия тип. Припомняме, че Гънтър отличава във времето шест фази: изследване, анализ за осъществимост, npo- 146
ектиране, програмиране, оценка използване. В пазарния жизнен цикъл пър- вите две фази са силно разтегнати, разчленени и конкретизирани за сметка на същинското разработване. Всички фази на пазарния жизнен цикъл са следните: — Възникване на идеята. Най-същественото от маркетингова гледна точ- ка е, че всяка идея за нов програмен продукт трябва да е предизвикана от потре- бителски нужди, а не от интереси на проектанти или програмисти. —Анализ за осъществимост. Може да се приеме, че има пълно съвпаде- ние на пазарния и на производствения модел в тази фаза. Тя се занимава с ико- номическата и технологичната осъществимост на програмния продукт.
11.5.2. Пазарен жизнен цикъл на готовия продукт Отличават се четири фази в жизнения цикъл на готовия продукт (в скоби даваме оригиналните английски названия).
Удобен пример за илюстрация е програмният продукт компилаторът от Фор- тран. Макар и донякъде условно, във времето нещата изглеждат така: 147
В днешно време жизненият цикъл на софтуерните продукти се съкращава поради бързия технологичен напредък. Стремежът на всяка фирма е да удължи по възможност живота на своите продукти поради очевидни финансови причи- ни. За целта съществуват различни възможности. Една от тях е да се обявят нови свойства на съществуващ продукт. Класически пример са езиците за сим- волни преобразувания или за симулиране, създадени като такива. По-късно, когато терминът изкуствен интелект се изпълни със съдържание и най-важното стана модерен и търсен, същите тези езици бяха обявени за езици на изкустве- ния интелект. Има и други начини, но те изискват значителни усилия при проек- тирането и програмирането на софтуерния продукт с оглед осигуряването на по-голяма от обичайната гъвкавост. Така например един от езиците в популяр- ната система за управление на бази данни за персонални компютри ACCESS e BASIC ACCESS. В първоначалния си вариант, т. е. във версия 1.0 и 1.1 на ACCESS той се отличаваше малко от добре известния BASIC и само се загатва- ше за възможности за обектна ориентираност. Постепенно, минавайки през вер- сиите 2.0, 7.0, 97, 2000, BASIC ACCESS започна да придобива далеч по развити обектно ориентирани свойства. Това просто се оказа отдалече разработена гъв- кава концепция за паралелно развитие на няколко от базовите езици на „Майк- рософт". Разбира се, тук стои и другият въпрос — доколко част от потребите- лите биха се съгласили с така обявяваните и въвеждани нови свойства на про- дукта, с който вече са свикнали да работят. 11.6. Позициониране и марка Сред проблемите на маркетинга от особено значение са следните два — позиционирането на програмния продукт и марката. Позиционирането е създаване на силен и индивидуален образ на прог- рамния продукт и внушаване на този образ на потребителите. Начините за пос- тигането на това са систематизирани. Единият от тях е сравняване с познати образци. Ако отворите кое да е американско специализирано списание, ще видите например, как за всяка по- нова система за управление на бази данни се изтъква, че примерно сортира k пъти по-бързо от FoxPro (или ACCESS) или че допуска повече полета за запис от нея и т. н. Допреди няколко години на мястото на FoxPro (ACCESS) обикно- вено стоеше dBase III. Докато такъв начин на анонсиране и рекламиране, е поз- волен от закона в САЩ, в много страни не е разрешен или се допуска при значителни ограничения. У нас по тези въпроси няма категорична уредба и затова нещата се решават на морално равнище. Втори възможен начин е обявяването на програмния продукт за специ- фична категория потребители. Не е рядкост някой от известните у нас прог- 148
рамни продукти за счетоводство да се рекламира примерно така: „Вече няколко хиляди счетоводители от счетоводните колективи в над 1000 фирми в страната са освободени от рутинните трудопоглъщащи операции и работят в условията на компютъризирано счетоводство с помощта на..." Една модификация на този начин е подчертаването на ползата от експлоатацията на програмния продукт. Например: „Всяка грешка във ведомостта за заплати става невъзможна, ако внед- рите..." И още един начин: обявяване на специфични възможности: „Това е един- ственият програмен продукт за текстообработка на пазара, който има вградени средства за проверка на правописа и за пренасяне на думите на нов ред...". Марката е наименованието, под което програмният продукт навлиза на пазара. Има три вида марки; индивидуално име, общо име и комбинация.
Лесно могат да се видят предимствата и недостатъците на трите подхода. В третия случай названието на фирмата е протекция и гаранция, но един неуспе- шен продукт може да навреди на всички останали от същата фирма. Във втория случай положението е аналогично за съответната гама. Първият е противопо- ложност на разгледаните два — провалът му по-трудно ще се отрази отрицател- но на останалите продукти на същата фирма, но пък по-малко би ползвал евен- туално вече създаденото добро име на фирмата. Тук е невъзможно да навлезем в правните проблеми, до които може да до- веде необмисленият избор на търговска марка. Ще подчертаем само, че следва да се вземат предвид доста ограничения. Ще изброим обаче някои най-общи условия, чието спазване е в интерес на производителя и търговеца — марката трябва да е запомняща се, да внушава някакъв образ, да напомня за възмож- ностите на програмния продукт. Например Windows като че ли удовлетворя- ва и трите условия — лесно се запомня, говори за силно развитата прозоречна техника, а на по-абстрактно ниво внушава образа за отвореност и широк пог- лед към проблемите. 11.7. Моделиране на софтуерния пазар Специален интерес представлява моделирането на софтуерния пазар. Са- мо по себе си то е интересно от теоретическа гледна точка, но е изненадващо колко полезни практически резултати биха могли да се извлекат от един доста- тъчно адекватен модел, стига да е основан на достоверни входни данни. Първите и като че ли най-успешни опити за моделиране на софтуерния пазар са отразени в няколко статии с основен съавтор и идеолог Суон (напр. [6]). У нас този модел е бил усъвършенстван в определени насоки [7]. Моделът на Суон се основава на някои познати икономически модели, но в него са въведени съществени допълнения, важни за отразяване особеностите на софтуерния пазар. Разглеждат се два аспекта на вътрешното качество на прог- 149
рамния продукт — хоризонтален и вертикален. Към хоризонталния аспект
се отнасят тези характеристики на качеството на продукта, за които няма общо съгласие на потребителите, а към вертикалния — тези, за които всички потре- бители са на единно мнение. Освен това в модела се отчита и редица от външни обстоятелства (m. нар. среда), свързани с продукта и от значение за предпо- читанията на потребителя — брой на (другите) потребители, допълнителни въз- можности (,,add-on-s"), възможности за връзка с други продукти, фактори, на- маляващи риска от това продуктът бързо да остарее. В модела се приема, че интересът на потребителя i се описва с функцията U(i) = a(i) + b(i) * m(j) * N(j) + c(i) * Q(j) , (11.1) където Q(j) представлява вътрешното качество на продукта j, N(j) е броят на инсталираните копия от продукта j, m(j) е коефициент, усилващ значението на N(j), a(i), b(i), c(i) са параметри, отразяващи предпочитанията на потребителя i. Ще отбележим, че формулата е дадена вече във вид, в който параметрите за хоризонталното и за вертикалното качество са обединени в члена c(i) * Q(j) след добре дефинирана за целта процедура. Възможно е и известно нормализи- ране на тази формула. Предполага се, че всеки нов потребител i избира продукт j така, че да мак- симизира U(i). Отделно от това се прави и предположение (изведено от пред- шестващи емпирични изследвания), че потребителите се появяват в постоянен поток, дефиниран чрез т. нар. S-крива: 
където n(t) е броят на новите потребители в момент t (или сумата на продадени- те на тях моделирани програмни продукти), n(l) е същото в началния момент 1, g е функцията на нарастване, t* е инфлексната точка на кривата S, nmax — нивото на насищане с нови потребители. Да илюстрираме използването на модела с един пример. Да предположим, че n(l) = 1, t* = 3 и nmax=5. Броят на продуктите нека е 3 с дати на въвеждане на пазара 1, 3 и 5 и със съответно вътрешно качество Q(1)=1, Q(2)=2, Q(3)=3. Предполагаме още 15 потребителски типа от c(l)=0 до c(15)=5.7. Като изход от модела се получава обемът на продажбите за всеки продукт
Каталог: 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. Сподели с приятели:
|