Жизнен цикъл на софтуерния процес

Слайд 1

СОФТУЕРНО
ИНЖЕНЕРСТВО
ЖИЗНЕН ЦИКЪЛ НА СОФТУЕРНИЯ ПРОЦЕС. ОСНОВНИ ЕТАПИ.
ДЕФИНИРАНЕ НА ИЗИСКВАНИЯ. ПРИОРИТИЗАЦИЯ. ПЛАНИРАНЕ.
PROJECT MANAGEMENT SYSTEM

Слайд 2

НА СОФТУЕРНИЯ ПРОЦЕС
ЖИЗНЕН ЦИКЪЛ
ПРОБЛЕМ
ФОРМУЛИРАНЕ НА ПРОБЛЕМА
ДЕФИНИРАНЕ
НА ИЗИСКВАНИЯТА
ОБЗОР НА СЪЩЕСТВУВАЩИ
РЕШЕНИЯ НА ПОДОБНИ ПРОБЛЕМИ
АНАЛИЗ НА ИЗИСКВАНИЯТА
(нови данни, допълнителни условия)
ИЗВОДИ
СПЕЦИФИКАЦИЯ
ПРОЕКТИРАНЕ
ДОКУМЕНТИРАНЕ
КОДИРАНЕ
ТЕСТВАНЕ
КОРЕКЦИИ
ЕКСПЛОАТАЦИЯ
КОРЕКЦИИ
ОБНОВЯВАНЕ
НОВИ ВЕРСИИ

Слайд 3

ДЕФИНИРАНЕ НА ИЗИСКВАНИЯТА
Изискванията могат да бъдат дефинирани от клиент, бизнес аналитик, ръководител на проекта, т.н.

Изисквания:
под формата на идея, устен вид, задание, спецификация, описание;
функционални изисквания (КАКВО прави софтуера);
нефункционални изисквания (бързодействие, платформа, стандарти за информационна сигурност и др.)

Софтуерните изисквания описват функционалността на системата.

На първия етап се определят изискванията, изпълнението на които позволява да се получи приемливо решение на проблема.

Слайд 4

ВИДОВЕ ИЗИСКВАНИЯ
Бизнес изисквания - описват сe с термини от бизнеса - какво трябва да бъде създадено или получено в резултат на проекта.
Пример: Да се разработи система за онлайн банкиране, гарантираща сигурност на данните и дейностите, според държавната нормативна уредба и вътрешния правилник на банката.

Функционални изисквания - изисквания към функционалността
Пример: При избиране на опцията „Банкови сметки“ трябва да се отвори екран със списък на всички активни банкови сметки на потребителя.

Потребителски изисквания – използва се естествен език за разбиране от потребителите, които не са с технически знания. Проблем при използване на естествен език е възможността за двусмислие – тълкуване на текста по различен начин от двете страни. Като алтернативи на естествения език е най-добре да се използват графични и математически означения.

Слайд 5

ВИДОВЕ ИЗИСКВАНИЯ
Нефункционални изисквания - ограничения върху разработката на продукта (архитектура, платформа, езици за програмиране, документиране на кода) или върху самия продукт (производителност, надеждност, сигурност, натоварване (scalability). За сложни системи са възможни конфликти между нефункционалните изисквания.
Пример: Системата трябва да бъде реализирана с обектно-ориентиран език. Сървърът да може да обслужва едновременно над 100 клиента.
Изисквания на предметната област - изисквания, наложени върху продукта от външни фактори, като например международни стандарти, държавни норми или фирмени правила.
Пример: Цветовата гама и шрифта на всички екрани на системата трябва да бъдат съобразени с описаните в държавната нормативна уредба критерии.

Слайд 6

АНАЛИЗ НА ИЗИСКВАНИЯТА

На етапа на анализ на изискванията се решават въпроси свързани със целесъобразността. Трябва да се вземат под внимание изисквания като: време–пространствени ограничения; ресурси, разходи; вероятност за грешки.
Трябва да се отчете и още един проблем: клиентите често променят изискванията си дори в напреднал стадий на проектната реализация. Обикновенно клиентите имат само ИДЕЯ в началото, а самите детайли се изестяват в последствие. Това не бива да се допуска, тъй като води до силно усложняване на разработката и възникване на феномена “метастаза на възможностите” (раздуване на списъка от възможности, които трябва да се добавят към програмата).
Софтуерът трябва да се планира и разработва на етапи – итеративна разработка. Големият проект трябва да се планира от по-малки проекти.

Слайд 7

АНАЛИЗ НА ИЗИСКВАНИЯТА

Анализа на изискванията може да се разглежда като итеративен процес, който формализира идеята на клиента под формата на :
спецификация (Software Requirements Specification) – описание на функционалните изисквания, описание на бизнес процесите, ролите на потребителите (use-case). Спецификацията на изискванията подпомага изграждане на обща визия за софтуерния продукт между клиентите и разработчиците. В спецификацията се прави точно описание на функциите. Описва се функционална спецификация, софтуерните и хардуерни решения;
прототип - прототипирането е също често използван и важен начин за представяне на идеята под формата на макет (прототип), който дава представа за някои основни функционалности на потребителския интерфейс. Пример;
задание (userstory – термин от Scrum).

Слайд 8

БИЗНЕС АНАЛИЗ
АНАЛИЗИРА ПРОБЛЕМИ!
Бизнес анализът е процесът на изучаване на бизнес или всяка друга организация, за да се идентифицират възможностите за бизнес/проблемите и да се предложат възможни решения.
ПРЕДЛАГА ВЪЗМОЖНОСТИ!
Видео пример – 4 мин
ПРИНЦИП НА НЕОПРЕДЕЛЕНОСТТА
Видео пример – 7 мин

Слайд 9

USER STORY – ПОТРЕБИТЕЛСКА ИСТОРИЯ
Източни: http://services.natureserve.org/member/userStory.htm
Бележки или кратки задания (карти), които описват специфични действия (GOAL) на определен тип потребител (Actor), които могат да се реализират бързо. Посочва се името на потребителя, конкретното действие, собственика (OWNER) или т.н човек, който изисква тази функционалност. Определя се и приоритет (1- критична (важна) ; 2- основна; 3 - добра функционалност; 4 – несигурна, но може би важна; 5 – козметична, която може да се реализира, ако не е сложно)

Слайд 10

ИЗИСКВАНИЯ КЪМ ИСТОРИЯТА (USER STORY)
- ПРАВИЛО 1: Използват се прости изречения !
- ПРАВИЛО 2: Описват КАКВО трябва да бъде направено, а не КАК да се направи.
ПРАВИЛО 3: Изискванията трябва да са пряко свързани с проекта.
ПРАВИЛО 4: Потребителските истории с голяма продължителност се разделят на по-малки.

Видео пример – 3:10 мин

КАТО СТУДЕНТ
(РОЛЯ - КОЙ)
ИСКАМ ДА ИЗБИРАМ ДИСЦИПЛИНИ
С ОБЩО 30 КРЕДИТА (ФУНКЦИОНАЛНОСТ - КАКВО)
ЗА ДА ПЛАНИРАМ СЕМЕСТЪРА
(СТОЙНОСТ ЗА ПРОЕКТА - ЗАЩО)
АВТОР: Клиент Приоритет: 4

Слайд 11

ПРИОРИТИЗАЦИЯ НА ИЗИСКВАНИЯТА

Съществуват различни техники за приоритизиране на изискванията на софтуерния проект.

Приоритизацията на изискванията и съответно на задачите е едно от най-важните задължения на всеки един проектен мениджър. Независимо колко успешно е стартирал един проект, рано или късно се стига до ситуация, в която трябва да се избере кои изисквания да се изпълнят и кои да се отложат, за да се успее с поставените срокове. Най-добре е това разпределение да се прави от самото начало на проекта.

Видео пример – 3 мин.

Слайд 12

ПРИОРИТИЗАЦИЯ НА ИЗИСКВАНИЯТА

Методът MoSCoW - Той възниква за пръв път в методологията DSDM (Dynamic Software Development Method) – един от първите “гъвкави” подходи, но е приложим във всеки един проект, независимо от избраната управленска методология. “Московският метод” (двете “о”-та са поставени за благозвучие и така се е получило съвпадението с името на руската столица) е прост начин за категоризиране на изискванията по важност, за да може на всички участници в проекта да бъде ясно кое е важно за клиента и кое – не.
Съкращението MoSCoW означава:
- Must have (задължително трябва да го има)
- Should have (би трябвало да го има)
- Could have (добре би било да го има)
- Won’t have (няма да го има)

Слайд 13

ПРИОРИТИЗАЦИЯ НА ИЗИСКВАНИЯТА

- Must have. Това са изисквания и функционалности, без които основната цел на проекта не би могла да бъде постигната. Те са гръбнакът на системата, абсолютният минимум, за да има проекта някакъв смисъл.
- Should have. Тези изисквания не са критични за съществуването на продукта, но са изключително важни и от голямо значение за клиента.
- Could have. Това са изисквания, които е добре да ги има в системата, и биха могли да бъдат реализирани, ако не изискват някакви особени усилия. Но те са и първите, които ще бъдат отхвърлени от обхвата на проекта, ако се появи опасност от изпускане на сроковете.
- Won’t have. Тези изисквания са категорично извън обхвата на текущия проект и дори не влизат в плана. Те се поддържат в списъка на изискванията за евентуални следващи версии на продукта.

Добрата практика изисква да има баланс между различните категории изисквания.

Слайд 14

ПРИОРИТИЗАЦИЯ НА ИЗИСКВАНИЯТА

Много често се прави грешка всички изисквания да са отбелязани като абсолютно задължителни (Must Have), но това почти винаги обрича проекта ако не на провал, то на изключително мъчително завършване. Затова още в самото начало на проекта, екипът по бизнес анализ и проектният мениджър трябва да извършат това приоритизиране и да получат неговото потвърждение и от клиента.
Възможно е по време на работата по проекта да се променят някои от бизнес приоритетите на клиента. Това налага да се извърши наново и приоритизацията на изискванията. Добра практика е в края на всеки етап да се прави ревизия на приоритетите, за да може усилията на проектния екип да се фокусират във всеки един момент към най-важните задачи и да не се пилее енергия, време и пари по нещо маловажно.
Източник: http://pmstories.com/

Слайд 15

СПЕЦИФИКАЦИЯ

Функционалната спецификация е нужна на програмистите за да могат на базата на нея да създадат продукта, който ще е съобразен с изискванията на клиента. Във функционалната спецификация се описва това , което иска клиента, но описано с функционални изисквания за продукта или услугите - обобщено така че да могат програмистите и след това QA специалистите да разберат какво трябва да представлява продукта. QA специлистите например да могат намерят функционалните бъгове преди клиента.
След създаване на спецификацията, тя трябва да бъде валидирана (проверена).
Трудно е да се направи спецификация, която никога няма да се промени! Добрите спецификации не премахват, но намаляват промените!
Най-добрият вариант е кратка спецификация + детайлен прототип + договор!

Слайд 16

ОЦЕНЯВАНЕ НА РИСКА. ПЛАНИРАНЕ

Работата по софтуерните проекти може да се планира по няколко подхода:
Изискванията са под фомата на оферта - и в този случай са отворени за интерпретация и преговори !!!
Изискванията може да са под формата на договор – и следователно са подробно дефинирани.
Договаря се фиксиран бюджет (крайна цена), краен срок, фиксирани параметри.
Договаря се работа със заплащане на час. В съвременното софтуерно инженерство се използват все по-често Agile методологиите, които са са адаптивни (гъвкави) към промени. Agile проектирането предразполагат работа на малки итерации.

Слайд 17

ОЦЕНЯВАНЕ НА РИСКА. ПЛАНИРАНЕ

За по-големи дългосрочни проекти е удачно да се планира по-гъвкав итерационен подход.
ПРИМЕР: Софтуер за здравно осигуряване. Промяната на закона за здравното осигуряване може да се отрази съществено на предварително планиране параметри в спецификацията. Според Agile методологиите се работи на малки итерации. Например специфи

Регистрирайте се за пълен достъп