Софтуерни технологии


Основна маркетингова концепция



страница72/106
Дата11.05.2023
Размер2.27 Mb.
#117653
ТипАнализ
1   ...   68   69   70   71   72   73   74   75   ...   106
Softuerni Texnologii
Свързани:
empty doc
11.3. Основна маркетингова концепция
Отново както и при проблема за качеството, във фокуса е потребителят.
Той е основополагащият елемент във философията на маркетинга. Формулира-
на в едно изречение и във възможно най-кратка форма, тази философия, наре-
чена още основна маркетингова концепция, гласи: задоволяване нуждите
на потребителя при печалба. Разбира се, тази формулировка може да се мо-
дифицира, без това да доведе до съществено смислово изменение. В [3] напри-
мер тя е, че постигането на фирмените цели зависи от определянето на
потребностите и желанията на целевите пазари и от задоволяването на
клиентите по начин, който е по-рентабилен и ефективен от този на кон-
курентите.
Не трябва да се забравя, че в областта на производството на софтуер (как-
то и в някои други области, свързани предимно с научни изследвания и въобще
с перспективни, но рискови и евентуално нерентабилни начинания) съществу-
ват организации, чиято приоритетна цел не е непременно печалбата, нито пре-
димство над конкурентите по отношение на рентабилността или ефективността.
Типичен пример са организации с идеална цел или държавни институции, чиято
основна цел е да разработят продукт с определени авангардни качества. Пос-
ледният, изнесен на пазара, се очаква да повлияе на характеристиките на про-
дуктите, разработвани от фирмите и други подобни организации. Добър при-
мер в това отношение са някои от първите компилатори, разработени в чужби-
на преди около четири десетилетия (Фортран, Алгол). Те не са били обект на
търговска разработка, финансирани са били без оглед на непосредствената пе-
чалба, но са оказали огромно влияние върху качеството на разработените по-
късно с тяхна помощ софтуерни продукти. Такава практика продължава да съ-
ществува и сега, макар че финансиращите институции все повече държат ре-
зултатният продукт от тази "непечеливша" схема на разработване да бъде лес-
141

Всеки софтуерен продукт трябва да предоставя удобен и лесен за усвоя-
ване потребителски интерфейс. Това става все по-актуално поради драс-
тичното нарастване броя на потребителите и разширяването на спектъра им.
Не са малко случаите, когато поради недобре проектиран или реализиран ин-
терфейс много от възможностите на продукта остават неизползвани от пове-
чето потребители. Това от своя страна директно води до намаляване броя на
продажбите му.
Особено място сред тези атрибути на качеството заема цената му. Тук
става въпрос за минимизиране разходите по разработването, но и особено по
съпровождането, доколкото последните са неочаквано големи.
He e възможно да бъдат постигнати едновременно най-добри стойности за
всички изброени атрибути. Просто защото някои от тях направо си противоре-
чат. Веднага се вижда например, че ако интерфейсът се направи прекалено ,ДРУ-
желюбен" (естетичен, ергономичен, лесноразбираем, снабден с много помощ-
ни указания и пp.), ефективността на програмния продукт ще пострада. Нещата
се усложняват и от факта, че цената на подобренията в много случаи не расте
линейно, т. е. малки подобрения в определен атрибут могат да изискват значи-
телно (дори експоненциално) нарастване на вложените ресурси, следователно
и на цената.
Всъщност, погледнато най-общо, задачата на софтуерните технологии е да
покаже как да се произвежда софтуер, който да притежава в оптимално съотно-
шение упоменатите характеристики. Това е смисълът на преодоляването на соф-
туерната криза, станала причина за появяването на тази дисциплина. Общо е
обаче мнението, че софтуерната криза все още не е преодоляна. Независимо от
значителните постижения, подобряващи методите и технологиите на разработ-
ване на софтуер или довели до създаването на мощни инструментални средст-
ва, изглежда, че нуждите от софтуер нарастват по-бързо, отколкото се подобря-
ва производителността на разработчиците на софтуер.
Тук не са толкова интересни установените от проучването най-прилагани
технологии и методи (прототипиране, езици от четвърто поколение, методи и сред-
ства за изграждане на графически потребителски интерфейс), колкото тези, кои-
то не се прилагат. За повечето от тях преобладаващият отговор (в различен про-
цент) е най-ниската степен — "не проявявам никакъв интерес". Най-отблъсква-
ната методика се оказва прилагането на метрики и различни техники на измерва-
не. Обяснението е, че сред теоретиците не съществува единно становище относ-
но това, кои метрики кога да се прилагат, както и че липсват за повечето теоре-
тично разработени метрики съответни програмни средства, които ги реализират.
Това, разбира се, не пречи големи фирми (Hewlett—Packard, IBM) да ги прилагат
масово и задължително. Особено учудващо е, че практиците нямат голям интерес
и към обектно ориентираните (OO) методи. Тук обяснението се търси в това, че
от една страна, за проектантите и програмистите от по-възрастното поколение
тази парадигма е необичайна и трудна за усвояване, че немалка част от тях се
занимават със съпровождане на софтуер, създаван преди доста време с тогаваш-
ните средства и неподлежащ на преработване с ОО-методи, че независимо от
неоспоримите им предимства по отношение на валидирането на програмите OO-
методите засега изостават от класическите структурни методи.
Свързан с този е и въпросът, докъде всъщност е науката в създаването на
софтуерни продукти. Ясно е, че ако трябва например да се натоварят повечко
пакети в багажника на кола, никой не решава въпроса математически (въпреки
изключително елегантните методи, които математиката дава за целта) — всеки
прави няколко проби и решава проблема. В много случаи софтуеристите не
могат без формални методи или пък биха постигнали по-лоши резултати без
тях. Във всеки случай с такива методи трябва да се процедира, когато задачата
е добре формулирана и разбрана или пък е с рутинен характер. Когато обаче е
поставен сложен проблем или пък такъв, изискващ творческо решение, еврис-
тичният подход е по-добрата възможност.


1.3.4. Наука и практика
Както в много други области, и в полето на софтуерните технологии прак-
тиците невинаги са склонни да следват незабавно теоретиците. Това е обясни-
мо, а и „здравословно". Не всяка теория се оказва толкова полезна, колкото е
изглеждала на пръв поглед, а понякога се оказва дори, че не е вярна. От друга
страна, пренастройването към един нов метод, език или технология изисква от
крайния му потребител (ръководител, проектант, програмист) усилия и време
за усвояването му. Много поучително в това отношение е едно изследване, из-
вършено наскоро в САЩ. Анкетираните професионалисти практици са отгово-
рили на въпроси, свързани с приложението на нови методи, предлагани им от
науката за софтуерните технологии. Формулирали са отговора си съгласно след-
ната петстепенна скала:

  • използвам активно;

  • изучавам задълбочено;

  • следя литературата;

  • очаквам, без да следя;

  • не проявявам никакъв интерес.

16
Литература

  1. Fox J.M., Software and its Development. Prentice-Hall, Inc., Englewood Cliffs, 1982.

  2. Charette R.N., Software Engineering Environments, Concepts and technology. Intertext
    Publications, Inc., McGraw-Hill, Inc., New York, 1987.

  3. Sommerville I., Software Engineering. Addison Wesley Publishing Company, 4. edition, 1992.

  4. Glass R.L., Formal Methods vs. Heuristics: Clarifying a Controversy, The Journal of Systems
    and Software, 15(1991),No2, p. 103—105.

  5. Glass R.L., „Who Cares?" Technologies in Practice, The Journal of Systems and Software,
    41(1998),Nol,p.l-2.

17

но усвоим от практиката и да окаже върху нея положително въздействие. Веро-
ятно най-добрият пример за такива финансиращи организации в областта на
софтуера в България през 90-те години са двата фонда към Министерството на
образованието и науката — за научни изследвания и за структурна и техноло-
гична политика, респективно комисиите им по информатика.


Сподели с приятели:
1   ...   68   69   70   71   72   73   74   75   ...   106




©obuch.info 2024
отнасят до администрацията

    Начална страница