Клиентът бива запознат на първите срещи с процеса по-долу.
- Започва се предварително грубо описание на функционалностите очаквани от клиента.
- Създава се ориентировъчна оферта, тъй като на грубо ниво на описаните функционалности не е възможно да се направи точна оферта.
- Клиентът получава ориентировъчния бюджет, като в офертата е записано ясно, че това са ориентировъчни суми и е възможно да варират в хода на работа.
- Клиентът се разписва на офертата, че е запознат с офертата като е наясно с:
- Цени и условия на офертата;
- бланков договор, който в последствие се подписва;
- текущият процес на работа, както и са разяснени въпроси свързани с хода на развойната дейност и допълнителни разработки
- Подписва се договор за периодични поръчки.
- Подписва се поръчка, в която се прилагат данните на поръчката:
- Начало
- Срок за изпълнение
- Начин на плащане
- Данни за комуникация
- Данни за комуникация
- Прилага се самото задание.
- Започва се работа по наша преценка при наличие на част от нужните ни ресурси или всички ресурси и след като има направено авансово заплащане съгласно правилата на поръчката.
- Започват се срещи за изясняване на въпроси свързани с поръчката и заданието
- Описват се допълнителните данни във вътрешна оперативна документация, която се свежда до знанието на служителите изпълняващи развоя.
- Развой започва след събиране на минимално количество информация нужна старт.
- Развойна дейност от всеки отделен програмист се прави на своя лична среда.
- Всеки одобрен код от водещия главен програмист се качва в системата за контрол на изходния код.
- След одобрение на главния програмист с негова заявка DevOps служител качва частта от разработения продукт на Development среда
- Развойната дейност от програмистите се обединява на Development среда и се тества от QA agent – детайлно ако е изрично оферирано и вместено в договора или PM на базово ниво.
- Паралелно с развоя се провеждат срещи между представители на клиента и ръководителя на проекта, в които се изчистват подробности свързани с следващи функционалности които ще бъдат разработвани на по-следващ етап.
Всичко се разработва на DEVELOPMENT среда, до която клиентът няма достъп, тъй като там е динамично и се трие и чупи непрекъснато. Това е среда която се ползва в процеса на разработка само и единствено, докато няма реално създаден продукт.
- След преценка на проектен ръководител, че има достатъчно много стабилни функционалности, системата се извежда на TEST среда и се подготвя за тестова фаза.
TEST среда е място, на което клиентът прави тестове за видими и скрити дефекти и може да оказва контрол върху изработката на поръчания продукт. Информацията и данните въведени в тестова среда не трябва да бъдат реални, а с тестови цели, като целта е ако има проблем констатиран на тест среда да бъде отстранен и проверен на Development среда и в последствие да бъде качен отново на Test среда.
- Когато продуктът е готов да бъде въведен в тестова фаза, клиентът получава достъп до тестовата среда.
- Достъпът е със служебен потребителски акаунт за използване на функционално ниво на софтуерния продукт.
- Физически достъп до сървърните среди имат само програмистите, DevOPS и проектен ръководител от страната на Разработчика
- С получаването на достъп до тестовата среда, се приема, че това е работещ продукт, който трябва да бъде оценен от клиента, но все още не се използва активно от клиента, защото не е качен на LIVE среда преди отстраняване на дефекти регистрирани от клиента, като:
- Всички видими дефекти спрямо заданието трябва да бъдат докладвани в 7 дневен срок от него, след като е получил достъп.
- Всички невидими дефекти трябва да бъдат докладвани в 30 дневен срок от него, след като е получил достъп.
- Екипът проверява дали докладваните неточности са обект на пропуск на екипа поради разминаване с техническото задание или докладвания дефект или неточност е обект на пропуск на клиента или опит за промяна на функционалности и дава своето мнение дали ще поеме за своя сметка промяна или се очаква да бъде направена промяна за сметка на клиента.
В случай, че има докладвани проблеми и инциденти в срок, те трябва да бъдат отстранени от разработващия екип за негова сметка.
В случай, че срокът за доклади е изтекъл се решава по преценка на ръководството за чия сметка ще бъдат отстранени дефектите.
- Когато са приключили крайно всички срокове и са отстранени всички дефекти, екипът приема, че продуктът е крайно завършен и всички недостатъци по него са отстранени. Тогава реално и клиентът може да пусне в експлоатация, на своя LIVE среда продукта си, защото вече е потвърдено и от него финално че може да го използва.
- Издава се фактура и се очаква плащане.
- При регистрирано плащане на фактурата имаме основание да приемем, че се потвърждава отново, че продуктът е приет от клиент и можем да предадем изключителната собственост във владение на клиента чрез приемно предавателен протокол, като:
- първо се изпраща уведомление за приемане на продукта към клиента
- и му се предоставя физически достъп за сваляне на продуктовия код
- или се предоставя на флаш памет, CD или хартиен носител
Достъпът до изходния код ако бъде предоставен на сървър в 7 дневен срок трябва да бъде изтеглен от клиента и след това от съображения за сигурност достъпът трябва да бъде преустановен, за сигурността на сървъра и тестови проекти на други клиенти.
В случай, че се предоставя кодът на клиента на друг електронен носител, то той може да бъде пазен в компанията до 3 месеца и в последствие след решение на ръководството може да бъде унищожен или изпратен с куриер на клиента, ако той не го е взел.
- След като продуктът е приет от клиента след допълнително споразумение, DevOps служител може да качи и инсталира продукта на клиента на реална LIVE среда след пълното разрешение на клиента, което може да бъде обект на допълнително таксуване или бонус в зависимост от решение на ръководството.
LIVE средата е достъпна публично, само след като клиентът потвърди писмено, че е съгласен продуктът да стане live-публичен. В този момент продуктът е пуснат в експлоатация публично от клиента.
- След като продуктът е предаден на клиента, се архивира цялата документация по него и се запазва за срок от 5 години от съображения за сигурност.
