Един добре познат случай е пилотиращият софтуер на совалките от космическата програма, проект който е отличен от всички за завидното си качество, продуктивност и предвидливост. Някои теоретици видяха проекта като "узрял" - достигнал ниво 5 по скалата за узрялост на Института за Софтуерно инженерство в Карнеги Мелън. Марката на такава узрялост е възможността за успешно прилагане на същите методи за разработка в друг проект. За съжаление се показа, че независимо от узрялостта, която е постигната в проекта за совалка, методът не е готов да бъде наложен на други проекти. Свидетелство е провалът на предложената от FAA система за контрол на трафика, проект на стойност 6 милиарда долара, прекратен от правителството поради раздуване на бюджета и забавяния в крайния срок.
Миражът на узрялостта
Узрялост от ниво 5 изглежда като приказка : теоретична конструкция лишена от реални примери. Това не е за омаловажаване на постиженията на космическата програма, които са неуспорими. Нейните почти нулеви дефекти и постоянно навременни рилийзи са уникални в софтуерната индустрия.
Но да обърнем внимание, че този проект се въззползваше от определени предимства, които рядко се срещат другаде: хардуерна платформа, която не се променя две десетилетия, добре дефинирани и последователни изисквания, постепенно нарастване на добре разбран проблем, огромен бюджет,позволяващ изработка на непотребни прототипи , натиск от ръководителите за множество нива на тестове, непроменящ се персонал и план, който не се променя от действия на конкуренти или промени на пазара. Като се имат предвид всички тези предимства не е необходимо да се притежава стратосферни нива на узрялост за да се обясни просуктивността и качеството на космическата програма.
Несъмнено голяма заслуга за успеха на проекта имат и големите специалисти и техници. Но методологистите на обичат да показват тази част от проекта, защото съществуващите методи не указват пътя за изграждането на такъв тийм.
CASE Доиде и си замина
В средата на 80-те, по същото време, когато Фредерик Бруукс предвиди, че следващото десетилетие няма да донесе разтърсващи подобрения в качеството и продуктивността на софтуера, производителите на CASE туул-ове се арздвижиха с вълна от продукти и white papers, обещавайки не що подобно на това.
В борбата с върколака на софруернато развитие, всеки сребърен куршум, без значение колко е тънък, има голям отзвук. Вълната на CASE, която премина през индустрията остави някои наивни мениджъри, които харчиха $10-50 хиляди за стол, на сухо. Сега тази вълна се отдръпна и много от производителите, които останаха, както свидетели в програмата за защита на свидетели, си смениха имената и се опитват да имат нова идентичност (маркетинговият термин за това е "репозициониране"). Някои от тези играчи сега са яхнали текущата вълна : обектно ориентирани методологии и шаблони.
Въпреки че инструментите и техниките на CASE и неговите обектно-ориентирани наследници не са безполезни, много изпълнения все още изглеждат направени във вакуум. Много от класическата литература за софтуерно инженерство и процес на разработка не изглеждат приложими за истинския свят, в който изискванията се сменят с всяко връщане на маркетинговият отдел от обяд, много от средата е недокументирано или в бета версия, трябва да се разработват алгоритми и мениджърите сърпат шалтера на тестовете, защото е дошла датата за издаване.
Дори проекти, които са далеч от крайности срещат проблеми.Много са чували за проблемие в автоматичната система за багаж на денвърското летище. Има и маса по-малко познати случаи. Автоматичната система на Bay Area Rapid Transit (BART), метрото в Сан Франциско, беше декларирана като неподходяща и прекъсната четири години преди датата на завършването, което доведе до $40 милиона загуба. Bank of America преживя $100 милиона загуба от забавен и "бъгав" софтуер за управление на сметките, който бе изваден от употреба. Гигантът в здравеопазването Kaiser Permanente похарчи милиони последното десетилетие, опитвайки се да автоматизира картоните на пациентите, без видим ефект. Подразделението на Kaiser в Южна Калифорния стигна до инсталиране на пневматична тръба за доставка на хартиени копия на документите из сградите по старомодния начин.
Като резултат много програмисти са незадоволени от празните бюрократични процедури, които много CASE туул-ове и техники се опитват да наложат.Жан Станфорд обяснява в статия за Computerworld (4 Септември 1995) как програмистите в един проект се оправят с системата за менажиране на кода :
Те гордо демонстрираха хитроумен инструмент, който бяха написали, който лъже централното хранилище и им позволява да избегнат проверката за грешки при всяка промяна. Те трябваше да проверяват файловете при всяка промяна. Вмеато това те държаха файловете в домашните си директории. Веднъж на всеки три месеца техният малък инструмент изпразваше директориите им и пускаше за проверка цялата подсистема. Не бе чудо, че тестовете се проваляха.
Създателят на PERL Лару Уол пише за " трите добродетеля на програмиста: мързел, нетърпение и високомерие." Въпреки че израза на Уол не означава това, което изглежда на първо четене (той всъщност говори за това как тези качества мотивират програмистите да пишат страхотни профрами), мисълта е срещу командите на "абсурдния " мениджмънт, който има "страстно, но погрешно желание да притисне твоята мисъл, за да пасне на техните идеи, да опетнят твоят шаблон на мислене като безрадостно съществуване".
Гай Кавазаки от Ейпъл е обяснил идеята на много програмисти за процеса на разработка на софтуер. Типичната последователност(леко променена от авторът) е нещо като това :
Скицирай фанелка, напиши кодът, напиши документацията, достави софтуерът, потърси си нова работа, тествай софтуерът и ако остане време напиши спецификации и коментирай кодът. Повтаряй безкрайно този цикъл с промени в персонала.
С настроения като тези сред най-добрите и креативни програмисти, които по принцип служат за модел на останалите, не е учудващо че 70 процента от CASE средите стоят по лавиците и се превърнаха в украса за объркани мениджъри.
Няма коментари:
Публикуване на коментар