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

Следващият етап е всички да прочетем и коментираме изискванията, за да сме подготвени за писането на код.

Как ще процедираме ?

Може да свалите документът (Формат PDF) от следният адрес, да го прочетете и да използвате Disqus коментарите към тази тема, за да обсъдим изискванията и да изчистим всичко неясно.

Техническите спецификации се намират в GitHub.

Това е втора версия на изискванията, първата може да намерите тук.

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

Използвайте секцията за коментари Disqus (Важно ! За да следите thread-a, сортирайте коментарите по Oldest. Така изглеждат най-естествено), за да:

  • Задавате въпроси към всичко, което излиза неясно от проектните изисквания.
  • Коментирате техническата част на проекта – при така изглеждащи изисквания, какъв ще бъде най-добрият подход откъм технологията (Python / Django / JavaScript) ?
  • Давате предложения за визията на новият сайт на Студентски Съвет

Колкото повече коментари съберем предварително, толкова по-подготвени ще бъдем за същинската част на хакатона – създаването на системата.

Действаме !

  • Вихрен

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

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

    Трябва да се помисли добре по точки 2. и 3., а именно потребителските роли и документите. Може би ще трябва по-пълно описание в приликите и разликите при потребителите.

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

    Добре ще е да имаме постоянна връзка с човек от СС, който да се включва при възникнали въпроси в процеса на работа.

    Въпроси към програмистите:
    Има ли начин за лесна имплементиция на работата с формуляри и потребителски роли?
    За front-end частта: Angular? Less? jQuery? Bootstrap? Темплейти? Друго?
    Предизвикателство ще е responsive design-ът (защо не мобилна версия?). Можем ли да се ограничим до списък от устройства или изисквания към тях. Например над .. резолюция или дата на производство след ..г., или операционна система след …
    Разделяне на front-end и back-end? Лесно ли ще стане?
    Използване на част от текущите функционалности – ще може ли, ако да – колко време ще отнеме интеграцията?
    Връзка със СУСИ?

    Базата от данни? Старата, нова (каква)? Защо?

    • Radoslav Georgiev

      Ето един частичен отговор на нещата :

      Ще има постоянна връзка с човек от СС – Даниел Стоев, който даже ще следи коментарите тук и ще отговаря (Съответните въпроси за документите и архивите ще бъде адресирани от него по-късно днес)

      Относно frontend частта :

      Говорих си с Минко Гечев, който ще говори JavaScript и стигнахме до извода, че за такъв проект няма нужда да се прави SPA (Single Page App), т.е няма да има нужда от AngularJS – по-скоро BackboneJS за структура, jQuery за валидация и AJAX.

      Откъм HTML и CSS предложението е Bootstrap, за да не се налага да търсим и дизайнер в момента, плюс да имаме някакъв fluid-ен layout, който да се вижда добре под мобилни устройства.

      Говорейки за мобилни устройства – и според мен ще е добра идея да се ограничим само до таблети, защото при телефони играта е друга.

      Разделянето на Frontend / Backend би трябвало да стане лесно, тук ще оставя Киро да отговори – той ще помага с Python и Django.

      За връзка със СУСИ – тук чакаме отговор от ръководството – трябва да има Web Service, който по факултетен номер да ти казва дали човекът е студент или не.

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

    • atodorov

      Работа с форми в Django:
      https://docs.djangoproject.com/en/dev/topics/forms/

      Работа с потребители и роли:
      https://docs.djangoproject.com/en/dev/topics/auth/

      според мен ролите могат да се реализират елементарно посредством двоични права или групи.

      • Radoslav Georgiev

        Django поддържа ли някакви хубави модули, за оправяне на тези роли ? Или се разчита на стандартна имплементация тип степен над двойката и побитови операции ?

        • atodorov

          Предполагам, но не съм ползвал, защото не ми е трябвало. Но тази функционалност може да се реализира и без допълнителни модули според мен. Просто проверка дали потребителя е в група Х или има правото Y.

    • atodorov

      По повод разделянето на предна и задна част аз бих подходил така:

      – всичко на API, което връща JSON
      – UI ползва само API-то и рендира в браузъра

  • atodorov

    Радо,
    по точка 1.2 от изискванията:

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

    • Radoslav Georgiev

      Валиден аргумент. Дефакто, трябва да се напише точно и ясно :

      По какъв начин ще се постигне повече прозразчност чрез тази софтуерна система ?

      По какъв начин ще се постигне повече контрол от страна на студентите чрез тази софтуерна система ?

      Ако разбирам правилно – това са основните въпроси – какво мислиш Сашо ?

      • atodorov

        ДА

    • Даниел Стоев

      Здравейте, колеги, ще опитам да разясня. Ако не съм отговорил на нещо, дайте ми сигнал.
      По отношение на целите (1.2) най-напред ще формулирам проблемите и критиките към СС, на които се търсят решения.
      №1 (прозрачност на проектната дейност).
      – Критика: безсмислени проекти или просто такива без всяка връзка с образованието/ културата и т.н. (“как може за такива неща се дават пари ?” и пр.)
      -Критика: тенденциозно одобряване на проекти на “свои” хора, респ. отхвърляне на “непознати”, “произволни” студенти.
      -Критика: несериозно обсъждане на проектите, безотговорно гласуване; това е във връзка и с неяснотата как протичат заседанията на СС;
      -Критика: липса на обратна връзка със студентите, на които са дадени пари (какво са реализирали, какво са постигнали, с какво това е полезно за студентската общност, накратко: отчетност за свършеното);
      -> Всичко това няма да може да бъде скрито, ако всеки проект се вижда от всеки директно в този електр. архив. Лично аз искам да се спре” анонимното” осъществяване на проекти, без да се даде някаква справка за извършеното, а повечето случаи са такива, безотговорни.
      -> Нека се направи функционалност студент, който не е въвел информация (за резултатите от изследването/ събитието и т.н. + снимков материал) за предишен негов проект, да не може да подава нов проект, поради некоректност.
      -> Също би била нужна функционалност, ако проект не е разгледан на заседанието на СИС ( органът, който одобрява проектите) поради основателни причини, автоматично да се прехвърля към следващата дата на СИС.
      – Олеснения: за обработването на формулярите + по-бързо сигнализиране за корегиране при неясни/недостатъчни данни; и др. под.
      … По-общи бележки:
      По корекциите на формулярите: проектният координатор ще може само да дава бележки за недостатъците, а отговорността за корегирането им е на колегата, който е подал формуляра. (Нека историята по редакция на проекта до гласуването му да се пази – не знам по какъв начин, допускам, че ще измислите варианти).

      Никои членове от СС /ако е възможно и администраторът/ да не нанасят корекции върху подадени формуляри, освен ако самите те не са подали формуляра.

      В профила на потребителя да се води хронология на подадените проекти, (може би там да се съхраняват корекциите по съдържанието му). Всеки подаден проект да се прехвърля към електр. архив на проектите. Да има бутон “разпечатай”.

      • Даниел Стоев

        Студенти (проекти) СС (одобряване на проект); (доклад за проекта) Администрация на СУ (разглеждане и одобряване/неодобряване на доклада за проекта);

        Това е пътят, за да се реализира проектът докрай. Одобряването му на заседание на СИС не е крайният момент. Трябва администрацията на СУ да позволи по законосъобразност да се отпуснат средства от бюджета на СС за въпросния проект. (СС не може напълно автономно да се разпорежда с бюджета си, понеже МОЛ на СУ е Ректорът). Посредникът тук е докладът, който съответно длъжностно лице от СС пуска в деловодството на Ректората. Докладът получва вх. № / рег. дата. И оттам почва “обхождане” по разните звена. Тук виждам един ПРОБЛЕМ.
        Съвсем намясто е да се заподозре, че едни проекти и доклади могат да се подават и качват в сайта на СС, а други – в деловодството. Едва ли не, сайтът ще бъде някакъв изкуствен параван. Трябва да се свърже “пътят” на доклада из административните звена със студентите, които да могат да го следят.
        1.За това може да послужи електр. система “Архимед”, където се следи какво се случва с докладите, там по тях се нанасят бележките от отделите и т.н. От СС имаме достъп до нея, но тя трябва да се свърже по някакъв начин със сайта, така че да може да се потвърди, че онова, което е подадено в сайта на СС от студентите, е това, което СС е подал чрез доклад в деловодството на Ректората. Ще се опитам да науча дали това може да се разреши: студентите да следят какво се случва с докладите на СС, респ. дори да виждат съдържанието на тези доклади. (Така няма как да има разминаване).
        2.От друга страна, може допълнително към всеки проект на студентите да има и поле: вх. № / рег. дата на доклад по проекта, където да се вписват данните на доклада, входиран в деловодството на СУ. Така с проста справка в търсачката на “Архимед” ще се види, че проектът действително е задвижен с доклад с посочения вх.№ и дата.

        • Radoslav Georgiev

          Тук мисля, че последното предложение е най-добро.

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

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

          Поздрави 🙂

      • Radoslav Georgiev

        Дани, благодарности за изчерпателният отговор !

        Ето няколко уточняващи въпроса от моя страна:

        1) Заседанията на СИС на какъв принцип се провеждат ? (Например, всяка седмица в сряда ?)
        Това е важна информация, за да може да се направи автоматично прехвърляне.

        2) Кой е моментът от целият процес, след който не е желателно да се нанасят корекции по проектният формуляр ?

        3) Според изискванията, пише, че само проектният координатор има право да нанася промени по формуляра (точка 4.1.5)

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

        Кое от двете е вярното ? (Това също е важно откъм гледна точка на логика на системата)

        Поздрави 🙂

        • Даниел Стоев

          по 1) Ще има 2 фиксирани дати в месеца (ще се изберат в началото на годината; ако е нужно, сега може да сложим някакви условни, напр. 1вия и 3тия понеделник от месец А). Ако си подал проекти (> или =1) на 1вото заседание от месец А, но не си ги отчел парично, нито си качил информация/снимки за направеното по проекта, то нямаш право да подаваш нов(и) на 2рото заседание от месец А, нито на 1вото от месец Б и т.н. напред;
          по 2) Три дена преди датата на заседанието за гласуване проекти не могат да се подават. Така има 3 чисти дена за техническа обработка на подадените формуляри. Ако такива се подадат, то автоматично да се препращат към проектите за следващата планирана дата на заседание за гласуване.
          Но още ПРЕДИ настъпване на 3тия ден преди заседанието проектният координатор ще може да дава БЕЛЕЖКИ за промяна по данните в проекта, а отговорност на студента е ДА ПРОМЕНИ/ДОПЪЛНИ своя проект.
          3те дни, в които не се подават проекти преди заседанието, ще са просто време за концентрирана финална обратна връзка м/у проектния координатор и студентите за корекции.
          по 3) Възможно е да не съм уточнил добре при разговора със Стела, за което се извинявам. Но мисля, че горе вече е еднозначно.

      • atodorov

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

        Зададените цели прозрачност, следене и ефективност ще бъдат постигнати само ако се вземат предвид следните фактори:

        * Информацията от всички документи трябва да бъде структурирана, а не просто текст, за да може да се правят справки по нея. Ще рече, че всички действия, потребители и промени по документите трябва да са взаймо-свързани обекти, с връзки във двете посоки. Ако е необходимо трябва да има и ясна класификация на данните – тип документ (има го), статус (има го), кога какво се е променило (като отделни записи) и т.н;

        * Трябва да има механизъм за следене и контрол: това, че имаме достъп до информацията е само предпоставка за контрол. В момента не виждам дефиниран такъв механизъм, а понеже не съм завършил ФМИ не ми е ясно и как се осъществява контрола от страна на студенти върху СС;

        * Обратното вече беше споменато – некоректни студенти няма да имат право да подават нови проекти (докато не станат пак коректни);

        * Какво и как се случва при откриване на злоупотреби или съмнения за тях? Също трябва да бъде добре описано;

        * Цитат:
        “Постигане на по-ефективна работа на Студентски съвет, посредством осигуряване
        на възможност за по-лесно проследяване на активността на членовете на съвета”

        Ефективността се повишава не като се проследява кой какво е правил, а как го е направил. Ако допуснем, че знаем потребител Х каква активност е имал в рамките на СС можем ли да кажем дали той е бил ефективен или не ? Според мен няма да можем. Тази цел трябва да се дефинира по-добре според мен.

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

        • Radoslav Georgiev

          Сашо, евала за структурираният отговор 🙂

          Прав си по точките и ще ги вкараме в спецификацията и ще ги адресираме, защото са важни.

          Под структура на самите документи. имаш предвид да има ясна спецификация какво съдържа един документ и той да може да бъде export-нат като JSON, например ?

          • atodorov

            Под структурирани данни имам предвид следното:

            * Имената на потребителите да не са текст, а ID-та;
            * Статусите на документите да са някакъв изброим тип, а не текст;
            * Одобрил проекта, гласували членове и т.н. отново да са ID-та;
            * Да има връзки както от един документ към всички хора ангажирани с него така и от един човек към всички документи, с които той е работил;

            Няма да изброявам всички възможни защото ще пропусна нещо. Мисълта ми е, че всичко трябва да е hyperlink-нато по подобие на HTML документите, а самите данни да бъдат разбити и обособени като самостоятелни обекти там където е възможно.

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

            Мога да дам и обратен пример, където липсата на така изградени документи води на практика до безполезност на системата – почти всички eGov услуги. Например годишен финансов отчет на фирмите в ТР. Въпросния отчет е сканиран документ и от него на практика не може да се извади почти никаква информация.

            Това трябва да се избегне!

          • Radoslav Georgiev

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

            Аз даже си мисля да има API, което просто да export-ва всичко в добре подреден JSON формат, за който иска да прави анализи върху документите, да може 🙂

  • Здравейте,
    доколкото виждам сегашния сайт на СС ползва wordpress. Което е супер. 🙂 Според мен използването на CMS за подобен тип сайт е доста добро начало поради ред причини. Основната е, че това е все пак сайт за менажиране на content. 🙂
    Мислено ли е върху вариант да се разшири текущия сайт с новата функционалност? Например да се направят custom plugin-и или разни модификации и т.н. за което е нужно? Съответно покрай новата функционалност да се поработи и върху usability-то на текущия сайт…

    Поздрави,
    Миро М.

    • Radoslav Georgiev

      Това е интересен въпрос.
      Гледайки в посока интеграция с WordPress – може да стане по следният начин – WordPress-а си остава, за да сервира съдържание и се разработва допълнително приложение за менажиране на документите.

      Друг възможен вариант е да се пишат Plugins и да се разшири съществуващата платформа, но в случая не разполагаме с достатъчно ресурси от WordPress-аджии, които да помогнат с това.

      Миро – ти как би подходил в случая ?

      • От гледна точка на развитие на проекта в дългосрочен план, според мен смесването на повече технологии е кофти. Ако трябва да се поддържа система направена от wordpress (php), python+django и други, означава, че трябва да има човек, който да разбира от двете технологии. (или да се разчита на повече хора).
        Аз лично бих заложил на една система + една технология – wordpress. Така е по-лесно за разработка и поддържане. А и wordpress предлага тонови функционалност for free. 🙂
        Но това, което казваш за липсата на wordpress-аджии е проблем. А и вече има програма все пак. 🙂
        Но все пак може да се помисли и за вариант-а, в който миксираме wordpress-а и го разширяваме с django app за менажиране на документите. Би било интересно като цяло. 🙂

        • Radoslav Georgiev

          Би било логично да не пренаписваме WordPress-a, а да създадем каквото има нужда към него, като отделен сайт.

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

          Това, което може да се включи в хакатона е малко поизчистване и стилизиране на WP-то да не изглежда толкова ужасно.

          Отделно, може да се направи 1 Web App, който да се логват студентите в него и да могат да пускат проекти, както и да browse-ват всички публично-достъпни данни.

          От друга гледна точка, точно това статично сервиране на съдържание, с Python и Django няма да бъде особен проблем и ще стане доста бързо и тривиално.

          Въпросът е кой ще поддържа после сайта и до колко човек с не-технически способности би се оправил с Django Admin-a 🙂

    • atodorov

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

      Иначе съм съгласен, че описаната функционалност може да се постигне и с текущата платформа на WP.

      Вярно е и обратното, че с Django сравнително лесно може да се сервира и само content без функционалност.

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

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

      • Radoslav Georgiev

        Краткосрочният план е да се даде начало на тази система и да се завършат поне основните функционалности.

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

        Освен това, кодът ще го има в GitHub open source, така че поддръжка ще се намери винаги.

        Специално за статичният content – може да остане WordPress, а за системата с документите – отделен app.

        Утре сутринта ще преразгледаме изискванията и ще пуснем втора версия на тях 🙂

  • Radoslav Georgiev

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

    Коментирайте ! 🙂

  • Toshko Todorov

    Добре, имаме идеята и клиентските изисквания…..Сега, системните:
    сървърен език – Python, с Django Framework,
    Ок, ще шерваме в Github!
    Kакъв сървър ще използваме / http://stackoverflow.com/questions/215815/python-for-web-development-in-apache / !!!

    База данни – MySQL / PostgreSQL.
    Web Hosting – ???;)

    • Kiril Vladimiroff

      Django 1.5.1
      Python 2.7.x или 3.3.x (повече за това ще си поговорим днес)
      PostgreSQL >= 9.1

      Ще го хостваме на nginx, с uwsgi.
      Изтървам ли нещо?

      • Toshko Todorov

        Просто се чудя от цял Университет няма ли толкова някой сървър?!..

        • Kiril Vladimiroff

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

          • Toshko Todorov

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

          • Radoslav Georgiev

            Ще се тества локално, пък като дойде време за мигриране към сървър – това няма да е проблем 😉

            Също така, има и Heroku + ако ни потрябва сървър – ще ползваме този, на който е host-нат сайтът на Студентски Съвет.

            Ако от Изчислителният центъра са така добри да конфигурират едно желязо (Или виртуално желязо) и да го пуснат с IP достъпно през интернет – още по-добре. Нека ми пишат на мен за подробностите 🙂

          • Toshko Todorov

            Би било страхотно,
            кой трябва да ги попита?

  • Radoslav Georgiev

    Добавих и техническата спецификация към статията – https://github.com/Hackfmi/SummerHackathon/blob/master/technical_specifications.md