Проблемите, които софтуерните инженери често трябва да решават, са изключително сложни. Разбирането на същността на проблемите може да бъде много трудно, особено ако системата е нова.
Следователно е трудно да се определи точно какво трябва да прави системата. Описанията на услугите и ограниченията са изискванията за системата, а процесът на откриване, анализ, документиране и проверка на тези услуги и ограничения се нарича инженеринг на изискванията. Много от проблемите на софтуерното инженерство произтичат от неточността в спецификацията на изискванията. Естествено е разработчикът на системи да дава интерпретации на нееднозначно изискване, за да опрости прилагането му. Често обаче не е това, което клиентът иска. Трябва да се предвидят нови изисквания и да се правят промени в системата. Разбира се, това забавя доставката на това и увеличава разходите.
Потребителските изисквания към дадена система описват функционалните и нефункционалните изисквания по такъв начин, че да са разбираеми от потребителите на системата, които не притежават подробни технически познания. Те само определят външното поведение на системата и избягват, доколкото е възможно, конструктивните характеристики на системата. Следователно потребителските изисквания не трябва да се определят с помощта на модел за внедряване. Те трябва да бъдат написани на естествен език, прости диаграми и представи.
Когато потребителските изисквания включват твърде много информация, те ограничават свободата на разработчика на системата да предоставя иновативни решения на потребителските проблеми и правят трудните за разбиране изискванията. Потребителските изисквания трябва просто да се съсредоточат върху основните ресурси, които трябва да бъдат предоставени.
Софтуерният процес представлява набор от дейности и свързани с тях резултати, които водят до създаването на софтуерен продукт. Това може да се състои в разработване на софтуер от нулата, въпреки че новият софтуер все повече се разработва чрез разширяване и модифициране на съществуващи системи. Една от причините да има ограничен фокус върху процеса на автоматизация е огромното разнообразие от софтуерни процеси. Няма идеален процес и различните организации са разработили напълно различни подходи за разработване на софтуер. Процесите са се развили, за да се използват възможностите на хората в дадена организация, както и специфичните характеристики на системите, които се разработват. Следователно, дори и в една и съща организация, може да има много различни процеси за разработване на софтуер.
The Unified Process развитие (ЗНЗ) методология очертания много специфични насоки за разработване на софтуерни проекти, дефинирани в силно сътрудничество, еволюционен и гъвкав подход към промените в усвоят софтуерни изисквания в динамична бизнес среда. По същия начин, тя ясно определя основните етапи, при които са необходими официални прегледи на проекти, които включват одобрение от клиента. Диаграмата по-долу показва жизнения цикъл на софтуерен проект, базиран на RUP:
Еволюционният му подход включва итеративно и постепенно развитие. Итеративният характер присъства в дейностите, разположени от лявата страна на диаграмата (изисквания, анализ, дизайн и т.н.); докато постепенното развитие се извършва чрез прототипиране във времето, разработено през целия жизнен цикъл, веднъж за всеки прототип. По време на фазата на изработване е разработен прототип с архитектурата, която включва случаи на използване с по-голям технически риск. От своя страна, софтуерът се произвежда и в края на всяка итерация във фазата на изграждане, по същия начин като във фазата на разработка, той може да се използва за тестване или демонстративен софтуер за клиента. Всеки път, когато итерацията приключи, тя поставя крайъгълен камък, когато е необходим преглед на клиента,където се анализира изпълнението на изискванията, напредъка на проекта, анализът на реалните и планираните разходи. В случай на последна итерация, съответстваща на всяка фаза на проекта, документът за одобрение трябва да бъде създаден от клиента, в който клиентът предлага съгласието си с постигнатите от проекта разработки, като по този начин приема финансовия и техническия смисъл на софтуера. което се развива.
В началния етап на развитие (Concepción) се създават основите на проекта. Определят се обхватът, първоначалният план, бизнес визията с целите и обосновката на проекта, тези артефакти се усъвършенстват през цялото развитие на проекта. Първоначалните изисквания се улавят чрез случаи на използване.
През този етап започвате да мислите за първоначалната архитектура на системата от бизнес гледна точка и от техническа гледна точка. Този процес включва създаване на концептуален модел и модел на внедряване, както на високо ниво в тази фаза.
Планът за проекти на високо ниво е дефиниран и след това преработен в по-подробен план в следващите итерации. Планът на високо ниво се справя с основните зависимости и общата стратегия, докато по-прецизираните планове (съответстващи на по-подробни итерации) се справят с тактиката на въпросните ситуации при всяка итерация. При планирането на проекти трябва да се вземат предвид дългосрочните действия като операции, подкрепа и непрекъснато подобрение.
Тази фаза на проектиране завършва, като гарантира наличието на определен обхват, план за развитие, анализ на риска, когато клиентите са съгласни с горното и имат жизнеспособна стратегия за изграждането на хранилището с данни.
Има някои често срещани грешки, които се правят на този етап, трябва да избягвате:
- Помислете, че това е фаза на определяне на изискванията по традиционен начин. Помислете, че трябва да имате перфектни модели и планове. Опитайте се да създадете цялостен модел на данни в началото на проекта.
Генерирани артефакти:
- План за проектиране Визия Използване на случаи Концептуална диаграма Диаграма на внедряване Документ за одобрение на клиента
Причините, поради които организациите използват RUP за разработване на софтуерни проекти, са:
- RUP контролира обхвата на риска: RUP признава като факт, че изискванията се променят при разработването на проекти и определя гъвкав подход за контрол на тези изисквания. Опитът да се дефинират напълно изискванията в началото на проекта е много рисковано решение.RUP изглежда извън данните: една от причините, поради които софтуерните проекти се провалят, е да не се осигури достатъчно бизнес стойност. Чрез идентифициране и фокусиране върху бизнес стойността чрез случаи на използване, RUP придобива оглед на изискванията, за предпочитане подход към подход, ориентиран към данни.RUP контролира техническия риск рано: много софтуерни проекти се провалят поради увереността, че Те предоставят подробни модели, създадени рано. Ако моделът на данните е много подробен,Той улавя "уникалната истина" и те са прекарали месеци, работещи върху нея. Проблемът е, че всяка архитектура работи добре на хартия. Докато архитектурата не се тества с код, не можете да сте сигурни в правилното й функциониране. RUP контролира риска. Финансов: Итеративната и постепенна разработка, която ранно управлява критичните компоненти на проекта, гарантира, че първо се гарантира най-високата стойност на функционалността, като максимално увеличава възвръщаемостта на инвестицията. RUP позволява гъвкавост по дисциплиниран начин: софтуерът е труден, необходима е гъвкавост, но в същото време поддържане на ниво на контрол, за да се направи ефективната разработка.Докато архитектурата не бъде тествана с код, не можете да сте сигурни в правилното й функциониране. RUP контролира финансовия риск: итеративната и постепенна разработка, която ранно управлява критичните компоненти на проекта, гарантира, че първо е гарантирана най-високата стойност на функционалността увеличаване на възвръщаемостта на инвестициите през цялото време RUP дава възможност за гъвкавост по дисциплиниран начин: софтуерните проекти са трудни, необходима е гъвкавост, но в същото време се поддържа ниво на контрол, за да се направи ефективната разработка.Докато архитектурата не бъде тествана с код, не можете да сте сигурни в правилното й функциониране. RUP контролира финансовия риск: итеративната и постепенна разработка, която ранно управлява критичните компоненти на проекта, гарантира, че първо е гарантирана най-високата стойност на функционалността увеличаване на възвръщаемостта на инвестициите през цялото време RUP дава възможност за гъвкавост по дисциплиниран начин: софтуерните проекти са трудни, необходима е гъвкавост, но в същото време се поддържа ниво на контрол, за да се направи ефективната разработка.Максимално увеличаване на възвращаемостта на инвестициите през цялото време. RUP дава възможност за гъвкавост по дисциплиниран начин: софтуерните проекти са трудни, необходима е гъвкавост, но в същото време се поддържа ниво на контрол, за да се направи ефективната разработка.Максимално увеличаване на възвращаемостта на инвестициите през цялото време. RUP дава възможност за гъвкавост по дисциплиниран начин: софтуерните проекти са трудни, необходима е гъвкавост, но в същото време се поддържа ниво на контрол, за да се направи ефективната разработка.
Промените в изискванията изискват еволюционен и гъвкав подход за високо сътрудничество. Единният процес на развитие (RUP) определя такъв подход.
библиография
Йън Сомървил, „ Софтуерно инженерство “, 6-то издание. Pearson Education, 2002.
I. Арчър Пупо, „Фази на единния процес на развитие“.
