Всеки софтуерен продукт трябва да предоставя
удобен и лесен за усвоя-
ване потребителски интерфейс. Това става все по-актуално поради драс-
тичното нарастване броя на потребителите и разширяването на спектъра им.
Не са малко случаите, когато поради недобре проектиран или реализиран ин-
терфейс много от възможностите на продукта остават неизползвани от пове-
чето потребители. Това от своя страна директно води до намаляване броя на
продажбите му.
Особено място сред тези атрибути на качеството заема
цената му. Тук
става въпрос за минимизиране разходите по разработването, но и особено по
съпровождането, доколкото последните са неочаквано големи.
He e възможно да бъдат постигнати едновременно най-добри стойности за
всички изброени атрибути. Просто защото някои от
тях направо си противоре-
чат. Веднага се вижда например, че ако интерфейсът се направи прекалено ,ДРУ-
желюбен" (естетичен, ергономичен, лесноразбираем, снабден с много помощ-
ни указания и пp.), ефективността на програмния продукт ще пострада. Нещата
се усложняват и от факта, че цената на подобренията в много случаи не расте
линейно, т. е. малки подобрения в определен атрибут могат да изискват значи-
телно (дори експоненциално) нарастване на вложените ресурси, следователно
и на цената.
Всъщност, погледнато най-общо, задачата на софтуерните технологии е да
покаже как да се произвежда софтуер, който да притежава в
оптимално съотно-
шение упоменатите характеристики. Това е смисълът на преодоляването на соф-
туерната криза, станала причина за появяването на тази дисциплина. Общо е
обаче мнението, че софтуерната криза все още не е преодоляна. Независимо от
значителните постижения, подобряващи методите и технологиите на разработ-
ване на софтуер или довели до създаването на мощни инструментални средст-
ва, изглежда, че нуждите от софтуер нарастват по-бързо, отколкото се подобря-
ва производителността на разработчиците на софтуер.
Тук не са толкова интересни установените от проучването най-прилагани
технологии и методи (прототипиране, езици от четвърто поколение, методи и сред-
ства за изграждане на графически потребителски интерфейс), колкото тези, кои-
то не се прилагат. За повечето от тях преобладаващият отговор (в
различен про-
цент) е най-ниската степен — "не проявявам никакъв интерес". Най-отблъсква-
ната методика се оказва прилагането на метрики и различни техники на измерва-
не. Обяснението е, че сред теоретиците не съществува единно становище относ-
но това, кои метрики кога да се прилагат, както и че липсват за повечето теоре-
тично разработени метрики съответни програмни средства, които ги реализират.
Това, разбира се, не пречи големи фирми (Hewlett—Packard, IBM) да ги прилагат
масово и задължително. Особено учудващо е, че практиците нямат голям интерес
и към обектно ориентираните (OO) методи. Тук обяснението се търси в това, че
от една страна, за проектантите и програмистите от по-възрастното поколение
тази парадигма е необичайна и
трудна за усвояване, че немалка част от тях се
занимават със съпровождане на софтуер, създаван преди доста време с тогаваш-
ните средства и неподлежащ на преработване с ОО-методи, че независимо от
неоспоримите им предимства по отношение на валидирането на програмите OO-
методите засега изостават от класическите структурни методи.
Свързан с този е и въпросът, докъде всъщност е науката в създаването на
софтуерни продукти. Ясно е, че ако трябва например да се натоварят повечко
пакети в багажника на кола, никой не решава въпроса математически (въпреки
изключително елегантните методи, които математиката дава за целта) — всеки
прави няколко проби и решава проблема. В много случаи софтуеристите не
могат без формални методи или пък биха постигнали по-лоши резултати без
тях. Във всеки случай с такива методи трябва да се процедира,
когато задачата
е добре формулирана и разбрана или пък е с рутинен характер. Когато обаче е
поставен сложен проблем или пък такъв, изискващ творческо решение, еврис-
тичният подход е по-добрата възможност.
1.3.4. Наука и практика
Както в много други области, и в полето на софтуерните технологии прак-
тиците невинаги са склонни да следват незабавно теоретиците. Това е обясни-
мо, а и „здравословно". Не всяка теория се оказва толкова полезна, колкото е
изглеждала на пръв поглед, а понякога се оказва дори, че не е вярна. От друга
страна, пренастройването към един нов метод, език
или технология изисква от
крайния му потребител (ръководител, проектант, програмист) усилия и време
за усвояването му. Много поучително в това отношение е едно изследване, из-
вършено наскоро в САЩ. Анкетираните професионалисти практици са отгово-
рили на въпроси, свързани с приложението на нови методи, предлагани им от
науката за софтуерните технологии. Формулирали са отговора си съгласно след-
ната петстепенна скала:
използвам активно;
изучавам задълбочено;
следя литературата;
очаквам, без да следя;
не проявявам никакъв интерес.
16
Литература
Fox J.M., Software and its Development. Prentice-Hall, Inc., Englewood Cliffs, 1982.
Charette R.N., Software Engineering Environments, Concepts and technology. Intertext
Publications, Inc., McGraw-Hill, Inc., New York, 1987.
Sommerville I., Software Engineering. Addison Wesley Publishing Company, 4. edition, 1992.
Glass R.L., Formal Methods vs. Heuristics: Clarifying a Controversy, The Journal of Systems
and Software, 15(1991),No2, p. 103—105.
Glass R.L., „Who Cares?" Technologies in Practice, The Journal of Systems and Software,
41(1998),Nol,p.l-2.
17