Софтуерни технологии
Изтегляне 2.27 Mb.
|
Свързани:
empty doc
| основните усилия при производството на програмен продукт са преди
появата на първото работещо копие, докато производството на всеки автомо- бил (без да забравяме значителните ресурси, необходими за проектирането на дадения модел и настройката на производствените линии) изисква влагането на немалко труд, енергия, материали; ако има грешка в даден програмен продукт (а безгрешен софтуер, както е известно, няма), то тя се отнася до всички негови копия; при автомобилите този случай е твърде рядък или поне не е типичен — там дефектите могат да бъде разнообразни, но, общо взето, са индивидуални — за всеки конкретен автомобил; когато дойде време програмният продукт да излезе от употреба, все повече това става относително едновременно и поради една и съща причина — обикновено идва нова версия, от една страна, с някоя и друга възможност пове- че и най-вече — съобразена с променения хардуер; при автомобилите и причи- ните за „умирането" на даден екземпляр са индивидуални (катастрофа, повре- ди, възможности на собственика и пр.) и времето на живот се отличава от ек- земпляр към екземпляр значително. 1.2.4. Мултидисциплинарност на разработването на софтуер Отделните програмни продукти са изключително разнообразни по пред- назначение. Като изключим специфичните инструментални средства (компи- латори, свързващи редактори, средства за тестване на програми), операцион- ните системи и още малък брой типове софтуер, разработван изключително от софтуеристи, във всички останали случаи не е възможно програмният про- дукт да бъде създаден само от програмисти. Когато се прави счетоводен соф- туер, трябва задължително да участва експерт по счетоводство, ако се разра- ботва статистически пакет, не може да се мине без математици статистици, за медицинския софтуер са необходими лекари, а при много видове програмни продукти трябва да се впрегнат заедно усилията на много повече групи специалисти. При такова сътрудничество почти винаги възникват проблеми на общуването, породени не толкова от личните особености на участниците, кол- кото от различния им тип на мислене и различните професионални езици, на които те говорят. Не е случайно, че в последните години в комплексите от курсове по софтуерни технологии много често има курс, занимаващ се с проб- 12 1.2.5. Специфични проблеми на надеждността Вече беше споменат известният на всички програмисти факт, че абсолют- но безпогрешен софтуер няма. Разбира се, малка програма с линеен характер и еднообразни входни данни вероятно би могла да бъде проверена докрай. Ти- пичният програмен продукт обаче никога не може да бъде абсолютно гаранти- ран срещу грешки. Причината за това е известна — прекалено много са въз- можните пътища през програмата, допустимите (и недопустими) съвкупности от данни, да не говорим за действията от страна на потребителя, които наистина не могат да бъдат изцяло предвидени. Следователно, дори да разполага с много време, пари и други ресурси, разработчикът едва ли би бил в състояние да дока- же абсолютна липса на грешки в предлагания програмен продукт. Естествено, съществуват чисто теоретически методи, гарантиращи пълна безпогрешност на програмата, но те са засега приложими само към прекалено тривиални програ- ми. Има разработени и технологии за тестване и отстраняване на грешки, които обаче поне от теоретическа гледна точка не могат да гарантират пълна липса на грешки. Да не говорим за иначе много добрата в други отношения обектно- ориентирана технология, при която за съжаление все още няма и теоретически възможности за доказване на безпогрешност на програмите. Няма да се спираме на отдавна станалите анекдотични примери за програ- мата, която работила безпогрешно х години и изведнъж сгрешила (което е на- пълно възможно), или за онази 0 вместо 1 в програмата, управляваща космичес- ка ракета, довела до преждевременно прекратяване на полета. Ежедневно сме свидетели на програмни продукти, разработени и продавани в стотици хиляди и милиони екземпляри от световни фирми, в които изскача по някоя грешка. От друга страна обаче, ако за дадена програма се докаже по един или друг начин, че не прави грешки поне при определени условия, ясно е, че нито едно копие на тази програма никога няма да направи грешка при тези условия. 1.2.6. Рискове Производството на софтуер в много повече случаи, отколкото това става в по-стари и утвърдени производства, може да доведе до по-малка или по-голяма загуба. Не са малко случаите, когато потребители съдят производителя на по- ръчания от тях софтуер и успяват да получат огромни суми за неизпълнени изисквания от доставения програмен продукт. Често се цитира като пример голяма хардуерно-софтуерна компания, която преди години трябвало да реа- лизира програмна система за резервация на самолетни билети. Едно от изиск- ванията било свързано с максималното време на отговор при извършването на транзакция в реално време. Не са известни подробностите, но поради това, че в много малък брой случаи специфицираното в заданието време е било просроч- 13 Ниво 1 се нарича начално (initial). Организация на ниво 1 не осигурява ста- билна среда за разработване и съпровождане на софтуер. В такива фирми управле- нието не е на здрава основа. Дори да има планирани процедури, в момента когато настъпи криза по отношение на срокове или ресурси, плановете се изоставят и се преминава изключително към програмиране (кодиране) и тестване. Успехът зависи само от опитността и квалификацията на ръководителя и членовете на екипа. Об- щата способност на организациите на ниво 1 е непредсказуема, каквито са и всич- ки елементи на софтуерния процес — графици, бюджет, качество на продукта и др. Поради това не може да се предскаже и ефективността на такава организация. Ниво 2 се нарича повторяемо (repeatable). В организацията е установена политика за управление на софтуерния проект и процедури за прилагане на тази политика. Планирането и управлението на нови проекти се основава на опита от предишни проекти. Показател за достигането на това ниво е формал- ното установяване на ефективни процедури за управление. Това позволява на организацията да повтаря успешните дейности от проект на проект. Може оба- че да се случи някои от дейностите (практиките) да не се повторят. По принцип, за да бъде един процес ефективен, той трябва да е приложим, документиран, измерим, с възможности за усъвършенстване и с обучени за приложението му кадри. Ръководството на всеки проект следи разходите и графиците. Дефинира- ни са стандарти и има стремеж към съблюдаването им. Ниво 3 се нарича определено (defined). Тук стандартният процес за разра- ботване и съпровождане на софтуер в организацията е документиран, включи- телно технологичните и управленските процеси, като при това те се интегрира- ни. Така стандартизираният процес в рамките на СММ се нарича стандартен софтуерен процес на организацията. Налична е специална група, отговорна за този процес. Действа програма за обучение на членовете на колектива в съ- ответствие с изпълняваните от тях задачи. Съществува процедура за настройва- не на стандартния софтуерен процес към нуждите на всеки конкретен проект. Накратко, на това ниво процесите са стандартни и непротиворечиви пора- ди стабилността и повторяемостта на технологичните и управленските дейнос- ти. Цената, графиците и функционалността са под контрол и качеството на соф- туера се следи. Ниво 4 се нарича управляемо (managed). На това ниво организацията уста- новява количествено измерими критерии за качество и се стреми към постигане- то им — както за софтуерните процеси, така и за софтуерните продукти. Произ- водителността и качеството се измерват за важните софтуерни процеси през ця- лото време в рамките на специална програма. Всеобхватна база данни се ползва за събиране и анализ на параметрите на софтуерните процеси. За измерването им са предвидени инструментални средства. При излизането на тези параметри от определени граници може да се установи дали това е случайно явление, или са необходими коригиращи действия. При преминаването към нова област на при- ложение или нов инструментариум се пресмята и контролира рискът. Накратко, организациите на това ниво са предсказуеми, защото работят с из- мерими процеси и в дефинирани измерими граници. Предсказуеми са както висо- кото качество на процесите и продуктите, така и тенденциите в развитието му. На- рушаването на определените количествени граници подлежи на коригиране. Ниво 5 се нарича оптимизиращо (optimizing). На това ниво цялата орга- низация е съсредоточена към непрекъснато подобряване на процесите. Тя има средствата за идентифициране на силните и слабите страни на процесите с цел предотвратяване на дефекти. Разполага се с данни за ефективността на софту- ерния процес, които се използват за анализ на цената и ползата от въвеждането на нови технологии или изменения в него. Технологични иновации се иденти- фицират и евентуално се въвеждат в практиката. Дефектите се анализират до установяване на причините и избягване на повтарянето им както в текущия, така и в бъдещи проекти. |