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

[Rabin]

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

Повечето фирми работят на конвейр. Като дадох примера с електронния магазин - 95% от логиката е вече реализирана и тествана. Плащаш си за труд по напасване за твоите условия. Както го написа от договора - ще ти дадат много малка част от сорса (ако въобще). Зависи от тяхното желание.
За конкретното задание нямам идея. Практиката показва, че всички фирми, които съм виждал, без изключение едва насмогват или изостават със сроковете. Уж няма работа, уж криза - не съм виждал софт проект да не е на косъм с времето. Това във връзка с времето за документиране.

[Nik Nikolov]

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

Това юристите за панацея ги имате. Човек дето ползва компа само за пишеща машина да дава становища и препоръки на програмисти?
За одита не я разбрах каква е идеята.
Могат да ти предадат купчина хартийки, наречени блок-диаграми. ......

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

Целта на цялото занятие е следната: Всяка фирма се развива. Условията, при които се прилага специализираният и софтуер - също.
Как да направим така, че едни програмисти да подължат работата на преди работилите програмисти с нова надстройка на софта, без да срещнат особени затруднения ?
Това се налага много често - уви. Поне аз така разбирам въпроса, при мен се е появявал такъв проблем. При това не свързан с пари. Просто конкретният човек писал програмата се пресели в Щатите и....край ! Никой не може да продължи готовия проект.
Това звучи ли ви сериозно в едни професионални отношения ?

[sparkybg]

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

Това звучи ли ви сериозно в едни професионални отношения ?

За съжаление е масов случай. Голямите фирми държат голями цени. Работят за голями клиенти. Малките работят "на парче", и макар в много случаи (според кадърността си) да са способни да създават по-качествен продукт, гаранцията, че ще ги има след 2-3-5 години, и ще вършат същото, е почти никаква. Ако пък софтуера е писан от програмист/и на свободна практика (също масова практика, особено в студентските години на същите) - гаранцията е още по-никаква. То е като всичко друго - освен за самия продукт, ако искаш сигурност, плаща се и за "марката", тоест за това, че разработчика е на пазара отдавна и е стигнал някакво ниво щото клиента да вижда в него надежден партньор.

Но тук при нас, както винаги, нещата понякога са малко абсурдни.

[Rabin]

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

На един познат му искаха 75 000 лева да му свържат GPS система към управлението на фирмата. Това за "големите софт. разработчици". Можеше малка фирма да го поеме под 10 К лв.
Опити за стандартизация в разработката на софт има от самото създаване на първия продукт. Малко или много работи, но проблемът не е там.
Колкото и да си документираш софта - сложността на алгоритъма е много голяма. ДНК-то на човека (софта, по който НИЕ като вид работим) като обем инфо се събира на половин DVD. 1 GB памет при компютрите вече я нямаме за нищо. Първите Линукси - сорса им тръгва от 60 000 реда. Вече нерядко на програмист му изсипват 30 000 реда омазан код да се оправя.
Проблемът идва от огромната сложност на софтуера, който ползваме. Оттам и трудното му наследяване от човек към човек.
В "големите фирми" се залага голяма бумащина. По правило бумащината е повече от работата. Оттам големите цени и гаранцията за поддръжка.

[sparkybg]

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

На един познат му искаха 75 000 лева да му свържат GPS система към управлението на фирмата. Това за "големите софт. разработчици". Можеше малка фирма да го поеме под 10 К лв.
Опити за стандартизация в разработката на софт има от самото създаване на първия продукт. Малко или много работи, но проблемът не е там.
Колкото и да си документираш софта - сложността на алгоритъма е много голяма. ДНК-то на човека (софта, по който НИЕ като вид работим) като обем инфо се събира на едно CD ако е архивирано. 1 GB памет при компютрите вече я нямаме за нищо. Първите Линукси - сорса им тръгва от 60 000 реда. Вече нерядко на програмист му изсипват 30 000 реда омазан код да се оправя.
Проблемът идва от огромната сложност на софтуера, който ползваме. Оттам и трудното му наследяване от човек към човек.

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

[Георги-trimata]

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

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

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

[Rabin]

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

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

Само ако имаш работещ сорс, ако и да е частичен, само на твоите неща. Питай създателите, ще ми е интересно какво ще кажат.

[sparkybg]

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

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

Значи, като за начало, поискай го във вид, в който след време ще може да се компилира наново (това ако се компилира въобще).

След това искай описание на модулите, класовете, функциите. Описание на базата данни - таблиците, stored процедурите и прочие. Дори като се замисля подробното описание на базата данни като че ли не отстъпва по важност на описанието на сорса. За съжаление обаче, ако нямате програмист, който знае за що и де реч, трудно ще можеш да прецениш до колко дадената документация е достатъчна. Кадърен човек ще се справи и без описание. Разликата е в загубата на време, додето се "вдене" за какво иде реч. Тук никакви юристи няма да помогнат. Трябва ти софтуерен специалист, и то точно в областта, и на езика/езиците/базите данни, които са използвани в разработака на продукта.

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

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

[Rabin]

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

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

Извън темата: Да не ти се налага да дописваш на език на ниско ниво, еле пък на Асемблер.

[sparkybg]

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

Извън темата: Да не ти се налага да дописваш на език на ниско ниво, еле пък на Асемблер.

Е, не е толкоз страшно. Някога, за да изкараш от една 286-ца някаква произовдителност, на асемблер си се пишеше редовно. Сега и разни микроконтролери и прочие.

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

[Тодор (Zaarin)]

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

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

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

Идеите, които ти дават за това, което трябва да искаш са много добри за следващия проект, който поръчвате. Обаче при така зададения казус имаш проблем. Ако коментарите в кода не са включени предварително в договора, няма сила, с която да ги накараш да ги добавят сега. За подробната документация важи същото. Причината не е толкова в, това че искат да крият нещо, а че не са ли го направили паралелно с разработката (а не е ли включено в договора, няма да са го правили), то това ще бъде много по-трудоемко сега. Съответно и договорените вече пари ще се наложи да се променят... Това е същото като да отидеш при майстора и да поискаш да ти смени диска на съединителя и след като е приключил, да му кажеш, да вземе да смени и пружината. Естествено ще те таксува два пъти за работата... В същото време писането на подробна документация и коментари в кода е едно от най-досадните неща зда разработчиците, така че шефовете им избягват да ги карат да го правят, ако не е част от договора или не става дума за вътрешен продукт.

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

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

[Rabin]

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

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

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

[Андрей Боянов]

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

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

Ами когато се пише от 100 човека трябва да има предварително наложен кодинг стайл (леле, какъв български!). Много "истински" програмисти го смятат за досадна глупост, но мога да ви кажа, че е супер важно да има правила за създаване на сорс код.

[Тодор (Zaarin)]

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

Ами когато се пише от 100 човека трябва да има предварително наложен кодинг стайл (леле, какъв български!). Много "истински" програмисти го смятат за досадна глупост, но мога да ви кажа, че е супер важно да има правила за създаване на сорс код.

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

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

[Андрей Боянов]

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

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

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

кодинг стайла и добрата архитектура на софтуера са си отделни неща. аман от демотивиращи се от всякакви правила програмисти и инженери

всички сериозни проекти, които съм виждал, имат строг кодинг стайл.