Софтуерни технологии
Модели на жизнения цикъл и подходи за разработване
Изтегляне 2.27 Mb.
|
Свързани:
empty doc
- Навигация на страницата:
- 3.2. Определяне на софтуерната система
3.1. Модели на жизнения цикъл и подходи за разработване
Проучването на специализираната литература показва, че продължава съз- даването на нови модели на ЖЦ. Поради стремежа да обхванат най-различни аспекти (технологични, организационни и икономически) новосъздаваните мо- дели са все по-сложни и оттам — все по-малко приложими в практиката. Затова в последно време усилията са насочени към разглеждане на noдxoдu за разра- ботване. Всеки подход за разработване определя основните правила, практики и процедури, които трябва да се следват в процеса на създаване на ПП. Подходите могат да бъдат с различна степен на общност. Някои от тях обединяват сродни методи. Например известни от литературата са подходът за разработване съгласно целите (чрез проследяване на изискванията или чрез про- тотипиране) или подходът с управление на риска. Най-общите фундаментални подходи се наричат парадигми. Ще разгранича- ваме два такива подхода: традиционен (конвенционален) и обектно ориентиран. Традиционният подход се е формирал с възникването на научното направление соф- туерни технологии като възможно решение на т. нар. софтуерна криза. За съжале- ние десетилетия след прилагането му някои тревожни симптоми на софтуерната криза — висока цена на разработване и незадоволително качество — продължават да се наблюдават. Затова бе създаден нов поход — обектно ориентираният. Такова развитие е в пълно съответствие с диаграмата на Kuhn [1], показана на фиг. 3.1 3.2. Определяне на софтуерната система Целта на тази фаза е да се определят предназначението и обхватът на соф- туерната система; да се разберат потребностите и желанията на потребителя; да се оцени осъществимостта на избираните решения; да се обсъди и избере при- емлива съвкупност от изисквания, които да се специфицират, валидират и ут- върдят, като се регламентира и проследяването им така, че да се осигури вграж- дането им в целевата система. 3.2.1. Определяне на изискванията Основен проблем при определяне на изискванията е разминаването на спе- циалистите в съответната приложна област (наричани най-общо потребители) и софтуерните специалисти, които отговарят за първоначалното определяне на системата (т. нар. системни аналитици или проектанти). Обикновено потреби- телите не могат ясно и точно да формулират потребностите и очакванията си; пропускат очевидните за тях подробности и нямат реална представа за възмож- ностите на компютърните системи. Аналитиците пък не познават особеностите на дейностите, които ще автоматизират, и не могат да преценяват доколко са съществени обсъжданите проблеми. Затова определянето на изискванията трябва да се разглежда като итеративен процес с активното участие на подходящо изб- рани представители и от двете страни. Ще опишем целите, съдържанието и прилаганите техники за всяка от пос- ледователните стъпки. а) Формулиране на изискванията Основна цел на този етап е съставяне на съвкупност от всички възможни изисквания въз основа на определените вече предназначение и обхват на пред- лаганата софтуерна система. В [2] е предложен подходът FAST (Facilitated Ap- plication Specification Techniques). Съгласно този подход се съставят работни групи с представители на потребителите и разработчиците, със съвместните усилия на които се идентифицира проблемът, обсъждат се алтернативни реше- ния и се подготвя предварително множество от изисквания. Регламентирани са формите на комуникации, подготовката и организирането на ефективни обсъж- дания и др. Друга подходяща техника е анализът на различните гледни точ- 37 ки, описан в [3]. Първоначално се идентифицират, например чрез „мозъчна атака" (Brainstorming), всички възможни потребители на системата, които след това се групират по сходство на гледните точки, които те представят. В резултат на интервюта, провеждани от системните аналитици с членове на групата, разго- вори и целенасочени обсъждания се определят изискванията на групата. Ако е необходимо, се разработват сценарии (use-cases) за реализацията на някаква основна функция и дори прототипи за нея, за да могат да се дефинират по- точно съответните изисквания. Всяко изискване се описва (същност на изиск- ването, кой и защо го предлага). Тази документация е необходима за по-ната- тъшното разглеждане и оценяване. б) Анализ на изискванията Съставената съвкупност от изисквания се изследва за пълнота и непроти- воречивост. Всички изисквания се класифицират по няколко критерия — нап- ример на функционални и нефункционални, на задължителни и препоръчител- ни, като може да им се присвоява и коефициент на значимост. Изследват се връзките помежду им и противоречията се разрешават на основа на присвое- ния им приоритет. След формиране на непротиворечива система за всяко изис- кване се определя доколко ясно и точно е формулирано, осъществимо ли е в определената среда за разработване, с какви рискови фактори е свързано, с какви ресурси би се реализирало, проследимо ли е в процеса на реализация на ПП и как може да се провери удовлетворяването му в целевата система. Полу- ченото описание на изискванията е документ, който се нарича „Спецификация на изискванията" (според други автори — „Съглашение за изискванията"). в) Утвърждаване на изискванията Създадената спецификация на изискванията се проверява от представите- ли на заинтересованите страни — потребители и разработчици, като се изс- ледват и изискванията като цяло, и всяко изискване поотделно. Обичайната тех- ника е използване на стандартни въпросници, чрез които се постига система- тичност и изчерпателност на проверката. След приключването й спецификаци- ите на изискванията се утвърждават и стават основен документ за цялата софту- ерна разработка. г) Проследяване на изискванията Препоръчва се планиране на дейностите по проследяване на изискванията, като в определените за проекта контролни точки се включат и проверки за пос- тигнатата степен на удовлетворяване на избрана подсъвкупност от изисквания. Изтегляне 2.27 Mb. Сподели с приятели:
|