Документация към софтуерен проект

[Георги-trimata]

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

[sparkybg]

От: Документация към софтуерен проект

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

E, това е трабвало да се уточни с договора. А сорс кода, в какъв смисъл "в каква форма"? То си е сорс код. това му е и формата. Продукта може да е ваша собственост, но сорс кода може и да не е - пак въпрос на договора.

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

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

Стандарти в това отношение си имат големите фирми, но и те подлежат на конкретни доуточнявания по време на договарянето.

[Nik Nikolov]

От: Документация към софтуерен проект

Имал съм подобен проблем.
Една фирма написа специализиран продукт по моя поръчка.
Дойдоха инсталираха го - платих.
Оставиха ми един диск с инсталационна програма. Никакъв листинг на програмата, никакви модули и никакви коментари.

След това не можаха да разделят парите. Изпокараха се и фирмата престана да съществува - студентска им работа.
След година се наложи създаване на допълнителен интерфейс и модифициране / леко/ на базата данни, по критерии.

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

Ако не искаш да плащаш за една и съща работа няколко пъти искай задължително информация.

[Rabin]

От: Документация към софтуерен проект

...
След година се наложи създаване на допълнителен интерфейс и модифициране / леко/ на базата данни, по критерии.

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

Ако не искаш да плащаш за една и съща работа няколко пъти искай задължително информация.

Tова е абсурдно! Визирам това с базата данни и леко пипане по интерфейс. В повечето случаи на неспециалист му се вижда малко работа, а иска много преработка, че и наново. Базата данни ти е в ръцете, и е много вероятно да имаш достъп дори до сорса на database сървъра. Че и на контейнера. И к'во от това?
Като напусне човек обикновено си оставя сорса. Кой ще му го поддържа е съвсем друга бира. И да, в повечето случаи се получава описаният от теб ефект.
Фирмите си пазят сорса като зеницата на очите си. Последната дума има редовия програмист, в повечето случаи шефовете си мислят, че знаят какво става. Ако и да са гурута, излезеш ли от тръстиката - губиш представа малко или много. К'ва е бумащина и там ме е срам да коментирам.
Да искаш коментари и блок-диаграми едва ли някой ще го прави в последствие, ако не е било договорено. Ще ти нарисуват нещо и ще си хепи, докато опре яйцето до...
С тестването същата работа.
Windows ти идва без сорс, сещаш се нататък.
Докато тръгне софта да ти върши работа ще мине много време. Ако е дебел проект - ще се пипа постоянно. Добре е да се имате със създателя. Дори добре документиран сорс може да няма кой да го поддържа после.
Една ERP система ако и да е добре направена и завършена и дават 5 г. докато започне да работи "сама" в твоите условия.
Може да ти дадат голяма част от кода в компилиран формат (еквивалента на obj, class и т.н.) . Трябва да си много навътре, че да се усетиш къде и как.
Такива неща...
Добре е да се имате със създателя. Другото е вятър!

[господин никой]

От: Документация към софтуерен проект

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

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

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

[sparkybg]

От: Документация към софтуерен проект

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

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

Нали това разправям и аз. Тия неща се договарят преди да се започне работа. Дали ще се дава сорс код и изискванията за коментари и документация и вида и - също.

[Ясен]

От: Документация към софтуерен проект

Я, каква изненада!

Най-общо, приема се това, което пише в договора и приложенията му (техническо задание, спецификация). Трагедията на нашия бизнес е, че това, което пише в документите, обикновено не е това, което му трябва на клиента, или поне не точно това (и той го разбира на късен етап от разработката). И което е по-лошото, написаното в документите често не е и това, което се предава, или поне не точно това (различни участници в процеса и това разбират не в най-удобния момент). Настава спиралата на поправки, доработки, преговори и откровени кандърми. От нея се излиза само с много добра воля от двете страни.

[Nik Nikolov]

От: Документация към софтуерен проект

От написаното дотук оставам с впечатление, че няма законодателно регулиране, относно предаването на програмен продукт написан по потребителски договор с конкретна потребителска заявка.
Имаше такива работи по БДС - на времето, но важат ли ????
Отменяно ли е БДС в тази си част ?
Жоро ще трябва да си проучи сам.
Защото не купува типово приложение на Майкрософт, а индивидуално разработена програма.
Както е по закон - така ще е.
Консултация със специализиран юрист ще бъде икономически обоснована.
Ако няма законова уредба - както е описано по договор.
Ако не е описано в договора - както е по изгодно в рамките на закона.

Изобщо уникална машина без чертеж и ремонтни наръчници е като прасе в чувал.
Същото е и със софта.

[Ясен]

От: Документация към софтуерен проект

От написаното дотук оставам с впечатление, че няма законодателно регулиране, относно предаването на програмен продукт написан по потребителски договор с конкретна потребителска заявка.
Имаше такива работи по БДС - на времето, но важат ли ????
Отменяно ли е БДС в тази си част ?
Жоро ще трябва да си проучи сам.
Защото не купува типово приложение на Майкрософт, а индивидуално разработена програма.
Както е по закон - така ще е.
Консултация със специализиран юрист ще бъде икономически обоснована.
Ако няма законова уредба - както е описано по договор.
Ако не е описано в договора - както е по изгодно в рамките на закона.

Изобщо уникална машина без чертеж и ремонтни наръчници е като прасе в чувал.
Същото е и със софта.

Няма законодателно наложени стандарти. В зависимост от бизнеса на поръчителя, може да са приложими разни ИСО-та, ДПП-та, което се записва в договора. По тях може да произлизат разнообразни изисквания и за съпровождащата документация.

Поръчителят може да е заложил в договора разни хубости, като предоставяне на пълен, четим сорс-код с процедура за компилация. Примерно. Може и да не е. Или API-документация, или данни за интеграция, или какво ли не.

[Nik Nikolov]

От: Документация към софтуерен проект

Няма законодателно наложени стандарти. В зависимост от бизнеса на поръчителя, може да са приложими разни ИСО-та, ДПП-та, което се записва в договора. По тях може да произлизат разнообразни изисквания и за съпровождащата документация.

Поръчителят може да е заложил в договора разни хубости, като предоставяне на пълен, четим сорс-код с процедура за компилация. Примерно. Може и да не е. Или API-документация, или данни за интеграция, или какво ли не.

Дааа ! В общи линии това ми замирисва на към 1000 Евро за Юридическа консултация, относно приемането на договора. Или може би Одит ?

[sparkybg]

От: Документация към софтуерен проект

Я, каква изненада!

Най-общо, приема се това, което пише в договора и приложенията му (техническо задание, спецификация). Трагедията на нашия бизнес е, че това, което пише в документите, обикновено не е това, което му трябва на клиента, или поне не точно това (и той го разбира на късен етап от разработката). И което е по-лошото, написаното в документите често не е и това, което се предава, или поне не точно това (различни участници в процеса и това разбират не в най-удобния момент). Настава спиралата на поправки, доработки, преговори и откровени кандърми. От нея се излиза само с много добра воля от двете страни.

В десятката!

Ник, не бъркай софтуера с хардуера. Едното, имайки го инсталационно, не можеш да го счупиш, щото е меко (soft). А това, какво ще получи клиента си е точно въпрос на договорка, и според мен задължителни стандарти не само не са нужни, ами са и крайно неправилни.

Това е като да наложиш стандарти на писателите за стила им на писане - просто няма как. Колкото и да не вярват някои, освен друго, писането на софтуер си е и творчески процес.

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

[Ясен]

От: Документация към софтуерен проект

Дааа ! В общи линии това ми замирисва на към 1000 Евро за Юридическа консултация, относно приемането на договора. Или може би Одит ?

Така поставен въпросът, предполага един пропуснат момент за консултация при писането на договора. Което може да е или да не е беда. Може например нашият човек да е формално включен в някоя комисия, чиито други членове са непосредствените ползватели на софтуера. Може и да му е прехвърлен горещ картоф.

Ник, не бъркай софтуера с хардуера.

За съжаление, твърде малко хора са в течение, че разликата е измислена. Правенето на софтуер е инженерна работа, за която могат да се приложат същите стандарти, които за архитектурата например. Е, обикновено не се прилагат, главно защото ще останем без софтуер. И това няма много връзка с писането както такова - прогамистът в архитектурата е еквивалентен на зидаря и арматуриста и творчеството му обикновено води до крясъци. Той просто трябва да изпълни чертежа на инженера. А, инженер ли казах?

[господин никой]

От: Документация към софтуерен проект

Казано в прав текст - уговори точно как ще бъде оформена документацията...

Няколко отправни точки - списък с променливите в приложението и какво точно вършат, в кои функции участват. Опис на видовете данни в базата данни и в кои точно функции участват. Списък с добавените от програмиста ти функции и как точно променият данните в приложението. И това е само върха на айсберга. Моят съвет е това да е под формата на коментар (разбирай точно преди да бъде използвана всеки път) към всяка функция/променлива... Най-вероятно ще поискат още пари и време - и оправдано, защото ако изпълнят проекта така работата им ще набъбъне доста, а е възможно и да ангажират специален човек, който да върши само това! (поне аз това бих направил...)

[Rabin]

От: Документация към софтуерен проект

Дааа ! В общи линии това ми замирисва на към 1000 Евро за Юридическа консултация, относно приемането на договора. Или може би Одит ?

Това юристите за панацея ги имате. Човек дето ползва компа само за пишеща машина да дава становища и препоръки на програмисти?
За одита не я разбрах каква е идеята.
Могат да ти предадат купчина хартийки, наречени блок-диаграми. Виждал съм опен сорс дипломна работа - електронен магазин. По поръчка на частна фирма, обаче се разработва от университет в Швейцария. Бяха дали документацията на енджина, който ползват, а не на самия продукт. Уж документирана за диплома в Швейцария, а инфото за продукта беше минимално.
И не на последно място - софта не е хардуер и не може да го пипнеш. По друг начин казано - програмистите решават какво става в компа ти. За добро и за лошо. Това във връзка с одита.
Не познавам ни една от страните и мнението ми не е пристрастно.
Техничар може да свърши работа, не юрист.

[Георги-trimata]

От: Документация към софтуерен проект

Ситуацията е следната:
Във вече подписания договор си пише че всички авторски права са наши, както и собствеността в/у софтуерния код с исключение на тази част от него която е разработена преди това за други приложения/задания.

Имаме едно сравнително кратко описание/спецификация на системата в началото.