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

1. Софтуерни проекти Софтуерни изисквания Софтуерни архитектури Планиране на проект Александър Далемски musashi.bg@gmail.com

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

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

4. Софтуерен проект • Цел – създаване на специфична софтуерна система или приложение • Бюджет • График • Екип

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

6. Софтуерен продукт • Софтуерна система или приложение – краен резултат от изпълнението на софтуерен проект • Custom software • Commercial software

7. Заинтересовани лица • Всички, които са свързани пряко или косвено със софтуерния продукт • Клиенти/купувачи • Потребители • Есперти в областта • Юристи

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

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

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

11. Събиране и специфициране на изискванията • Много начини за събиране – интервюта, анкети, фокус групи, допитване до експерти в областта, проучване на сходни системи... • Често си противоречат • Трябва да се постигне компромис • Формулират се в спецификация

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

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

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

15. Клиент-сървър архитектура (Client-Server) • Нееднородна • Обикновено един сървър • Много клиенти • Клиентът инициира връзката със сървъра • Централизиран достъп до данните

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

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

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

19. Event-Drivenархитектура • Събития • Абониране • Компонентите, които предоставят услугите/събитията, инициират действията

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

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

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

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

24. Модел на софтуерен процес • Шаблон, описващ фазите на процеса, дейностите, ролите и ресултатите от всяка фаза • Съществуват много модели • Ориентирани към различни видове проекти

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

26. Модел на водопада(Waterfall Model) • Фази: извличане на изисквания, проектиране, разработка, тестване, внедряване • Не е възможно връщане към предишна фаза • Не се справя добре с промени в изискванията в късен етап от проекта

27. Спираловиден модел(Spiral Model) • Прилагане на модела на водопада множество пъти • Всеки цикъл започва със специфициране на изисквания, продължава с проектиране, разработка и тестване • Продължава до достигане на завършен вид • Позволява адаптация към промени в изискванията

28. Прототипен модел(Prototype Model) • Бърза разработка на прототип в началото на проекта • Proof of concept • Откриване на потенциални проблеми и рискове • Throwaway прототипи • Еволюционни прототипи

29. Итеративен модел(Iterative Model) • Комбиниране на спираловидния и прототипния модели • В края на всяка итерация трябва да се получи работеща версия на крайния продукт • Може да се добавят отделни пълни модули, или да се започне с непълни модули и те да се доразвиват

30. Agile разработка • Традиционните модели на софтуерни процеси изразходват твърде много време и пари за документация и формалности • Agile подходите минимизират излишните дейности • Множество различни Agile подходи

31. Сходни черти на Agile подходите • Постоянна пряка комуникация със заинтересованите лица • Минимална употреба на сложни инструменти и излишна документация • Кратки цикли (спринтове) • Бърза реакция при промени в изискванията • Ограничават се страничните дейности

32. Полезни връзки • Софтуерно инженерство –Software Engineering by Ian Sommerville, http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/ • Agile разработка - http://www.agilealliance.org/

33. Благодаря за вниманието! • Въпроси? • musashi.bg@gmail.com