Софтуерни проекти Софтуерни изисквания Софтуерни архитектури Планиране на проект

Copyright © 2012 DAVID Holding Company

Софтуерни проектиСофтуерни изискванияСофтуерни архитектури

Планиране на проект

Александър Далемски[email protected]


За какво ще говорим

• Софтуерни проекти• Извличане и специфициране на изисквания• Архитектури на софтуерни системи• Планиране на софтуерни проекти


Проект

• Има начало и край (ограничен е във времето)• Целта е да се създаде някакъв резултат• Проектен екип• Всеки проект, а следователно и резултатът от него, са

уникални


Софтуерен проект

• Цел – създаване на специфична софтуерна система или приложение

• Бюджет• График• Екип


Софтуерен процес

• Дейностите по разработката на софтуерна система• Всеки софтуерен проект се изпълнява следвайки

софтуерен процес• Определя дейности, роли, резултати


Софтуерен продукт

• Софтуерна система или приложение – краен резултат от изпълнението на софтуерен проект

• Custom software• Commercial software


Заинтересовани лица

• Всички, които са свързани пряко или косвено със софтуерния продукт

• Клиенти/купувачи• Потребители• Есперти в областта• Юристи


Софтуерни изисквания

• Събират се в началото на изпълнението на проекта• Ръководят проектирането, реализацията и тестването


Видове изисквания

• Бизнес изисквания• Изисквания към процеса• Изисквания към продукта


Изисквания към продукта

• Функционални изисквания• Нефункционални изисквания• Изисквания на предметната област


Събиране и специфициранена изискванията• Много начини за събиране – интервюта, анкети, фокус

групи, допитване до експерти в областта, проучване на сходни системи...

• Често си противоречат• Трябва да се постигне компромис• Формулират се в спецификация


Спецификация на изискванията(Software Requirements Specification – SRS)• Описват се всички изисквания• Проверява се за неточности и пропуски• Важно е проблемите да се отстранят максимално рано в

процеса


Формулиране на изискванията

• Ясно и точно• Консистентно (без противоречия)• Без повторения• Без сложни (комбинирани) изисквания• Да позволява проверка за изпълнението на изискването


Софтуерни архитектури

• Често използвани шаблони• Могат да се комбинират• Покриват определен клас проблеми• Предимства и недостатъци


Клиент-сървър архитектура (Client-Server)

• Нееднородна• Обикновено един сървър• Много клиенти• Клиентът инициира връзката със сървъра• Централизиран достъп до данните


Трислойна архитектура (Three-Tier)

• Три слоя – за данни, бизнес и презентационен• Изолира всеки слой от реализацията на останалите• Улеснява тестването и поддръжката• Ограничава обхвата на нужните промени• Много широко разпространена


Многослойна архитектура (n-Tier)

• Подобна на трислойната• Множество слоеве• Разделяне на отговорността (separation of concerns)• Локализиране на промените


Peer-to-Peer архитектура

• Обикновено еднородна• Липса на централизираност• По-висока надеждност• По-ниска сигурност на данните• По-сложна реализация


Event-Driven архитектура

• Събития• Абониране• Компонентите, които предоставят услугите/събитията,

инициират действията


Архитектура с обмяна на съобщения(Message Passing)• Pipes & Filters• Съобщения• Канали/опашки• Обработващи звена


Архитектура с общо хранилище(Shared Repository)• Общо хранилище за данни• Липса на преки взаимодействия между компонентите• Комуникация чрез хранилището


Архитектура с разпределяне на товара(Load Balancing)• Дублиране на еднакви звена• Разпределяне на заявките/натоварването• Load balancer• Допълнителна надеждност – резервни звена


Архитектура, ориентирана към услуги(Service-Oriented Architecture – SOA)• Описан набор от услуги• Съобщения• Клиенти – обикновено външни системи• Обикновено през HTTP• SOAP, WSDL и UDDI


Модел на софтуерен процес

• Шаблон, описващ фазите на процеса, дейностите, ролите и ресултатите от всяка фаза

• Съществуват много модели• Ориентирани към различни видове проекти


Ad-hoc модел

• Липса на специфичен план• Решенията се вземат на място• Сполучлив за малки непрофесионални проекти• Много висок риск от провал при сериозни проекти


Модел на водопада (Waterfall Model)

• Фази: извличане на изисквания, проектиране, разработка, тестване, внедряване

• Не е възможно връщане към предишна фаза• Не се справя добре с промени в изискванията в късен

етап от проекта


Спираловиден модел (Spiral Model)

• Прилагане на модела на водопада множество пъти• Всеки цикъл започва със специфициране на изисквания,

продължава с проектиране, разработка и тестване• Продължава до достигане на завършен вид• Позволява адаптация към промени в изискванията


Прототипен модел (Prototype Model)

• Бърза разработка на прототип в началото на проекта• Proof of concept• Откриване на потенциални проблеми и рискове• Throwaway прототипи• Еволюционни прототипи


Итеративен модел (Iterative Model)

• Комбиниране на спираловидния и прототипния модели• В края на всяка итерация трябва да се получи работеща

версия на крайния продукт• Може да се добавят отделни пълни модули, или да се

започне с непълни модули и те да се доразвиват


Agile разработка

• Традиционните модели на софтуерни процеси изразходват твърде много време и пари за документация и формалности

• Agile подходите минимизират излишните дейности• Множество различни Agile подходи


Сходни черти на Agile подходите

• Постоянна пряка комуникация със заинтересованите лица

• Минимална употреба на сложни инструменти и излишна документация

• Кратки цикли (спринтове)• Бърза реакция при промени в изискванията• Ограничават се страничните дейности


Полезни връзки

• Софтуерно инженерство – Software Engineering by Ian Sommerville, http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/

• Agile разработка - http://www.agilealliance.org/

http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/

http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/

http://www.agilealliance.org/

http://www.agilealliance.org/


Благодаря за вниманието!

• Въпроси?• [email protected]

Documents

Софтуерни проекти Софтуерни изисквания Софтуерни архитектури Планиране на проект