[KÉRDÉSEK] Közbeszerzési kiírás webes alapú programfejlesztésre

 ( john_silver | 2013. április 22., hétfő - 11:00 )

Nem találtam megfelelőbb témát, ha nem jó áthelyezem máshová.

Hamarosan elkezdünk írni egy ilyen dokumentációt.
Személy szerint én még soha nem vettem részt ilyenben.

A csapat tagjai több szakterületről érkeznek, lesz külön informatikus is.
Én elsősorban mint vizes szakember leszek jelen és másodsorban mint informatikus.

Szeretném, ha az elkészült program az igényeiknek megfelelően működne, ne pénzlenyúlás legyen egy félkész programért.

A kérdéseim:
A buktatók érdekelnének, mi az amire feltétlenül ki kell térni.
Van-e esetleg valamilyen leírás, segédanyag, mankó.
Mennyire legyen részletes a leírás, mi mindenre terjedjen ki.

Az én elképzelésem az, hogy először rögzítjük a szakmai követelményeket az előírások jogszabályok alapján kitől, mit, hogyan, milyen formában. Ezután felvázoljuk, hogy ezt milyen formában akarjuk bekérni, tárolni, milyen lekérdezéseket akarunk, jogosultsági szintek, stb.

Előre is köszönöm a válaszokat.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Röviden:

Írd le, hogy mit. A hogyant pedig hagyd arra aki megkapja a munkát. Legtöbb gond azzal szokott lenni (nálam), hogy nem tudja elmondani a megrendelő, hogy mit kér, de a hogyannal zsibbaszt és ezért nekem a hogyanból kell rájönnöm, hogy mit akar.
A vicc az, hogy hiába mondom el, hogy azt mondja mit akar és ne azt, hogy hogyan továbbra se érti(k) a feladatot és mondjá(k) tovább a hogyant. :)

Ne essetek ebbe a hibába, ha jó alkalmazást akartok.

Köszönöm.

Ez alapján akkor a mit kell annyira pontosan megfogalmazni, hogy abból a megvalósítás olyan legyen amit látni szeretnénk anélkül, hogy a hogyanba beleszólnánk.

Pontosan.
- Milyen információkat akartok látni.
- Mi alapján akartok lekérdezni.
- Mit akartok eltárolni.
...majd folytatják mások, tapasztaltabbak. (én csak házon belül fejlesztek, ráadásul a vevőim a saját alkalmazottaim). :)

MIT&HOGYAN (félreértések elkerülésére)

A programnyelv és a környezet még nálam nem a hogyan. Az még a mit illetve min kategória.

A hogyan kizárólag az alkalmazásra vonatkozik, mint kód és UX. Természetesen itt is lehetnek irányelvek amellyel már rendelkezik a megrendelő. (pl.: arculati kézikönyv, belsőszabályzatok, etc...)

A UX véleményem szerint inkább a "soft-mit" kategória (előre levéssük nagyvonalakban, aztán a vég-userekkel és a fejlesztőkkel/UX designerrel átbeszéljük már a kivitelezéskor), mert pl. valami régi DOS-os csoda lecserélésekor a dolgozók produktivitása kőkeményen visszaeshet, ha legalább a gyakran használt billentyűk nem azt csinálják, amit a korábbi rendszerben. Rakhatsz akármilyen intuitív UI-t Gizi néni elé, ha ő az elmúlt húsz évben megszokta, hogy az F2-re kinyomtatja az aktuális form-ot, ha az a funkció nem az F2-n lesz (hanem mondjuk a standard Ctrl+P-n), akkor Gizi néni meg lesz lőve.

Ha meg hivatalosan nincs is korábbi rendszer (pl. eddig e-mailben küldözgetett Excel táblák adták a verziókezelt adatbázist :) ), akkor is be kell vonni a végfelhasználót/megrendelőt, mert (legegyszerűbb példa) ha van egy entity-d 10 kötelező (alap tab) és 40 opcionális mezővel, akkor valszeg lesz egy 2-3 tabból álló felületed. Az end-usernek/megrendelőnek lehet tippje, hogy a 40 opcionálisból az esetek 95%-ában egy bizonyos 15-nek lesz értéke, ha ez sehol nincs dokumentálva, akkor az UX designer nem fogja kitalálni, hogy "első tab kötelező, második tab az a 15 mező, harmadik tab a maradék szutyok" legyen és az eredmény egy kevésbé optimális UI lesz.

BlackY
ui.: a példák itt persze elsősorban desktop appra vonatkoztak, de weben is ugyanígy, szerintem.

Értékhatár függő.
Ha erre az évre 25 millió alatt marad az ilyen jellegű IT büdzsé (vannak mindenféle egyszámításos dolgok) akkor egyszerűbb a történet.
Ha több mint 25 akkor viszont nagyon-nagyon részletesen le kell írni, mivel meg kell hirdetni a közlönyben és bárki (tényleg bárki) adhat ajánlatot.
Ha van már valamiféle elképzelés (programnyelv, funkciók), akkor központi közbeszerzésen keresztül is lehívható. Ez a legegyszerűbb egyébként.

Az én elképzelésem az, hogy először rögzítjük a szakmai követelményeket

Nem, először azt kell tisztázni, hogy milyen legyen (lehet) a közbeszerzés. Ez sok minden eldönt.

Köszönöm.

Jóval a 25 millió felett lesz (kb. 300 millió).
A készülő új webes programnak illeszkedni kell a már meglévő rendszerbe.

Nem tudom a döntési láncban hol vagy, de mindenképpen konzultáljatok közbesz. szakértővel.

Nem vagyok a döntési láncban, csak egy kicsit képbe szeretnék kerülni az egész eljárás vonatkozásában. Úgy gondolom, hogy van a rendszerben közbesz. szakértő, mert nem ez lesz az első ilyen fejlesztés.

Közben megnéztem, nyilvánosan elérhető egy rövid összefoglaló a pályázatról, nem hinném, hogy gond ha ide belinkelem.
https://www.antsz.hu/projectek/keop_7630_2008_0037

Azzal egyetértek, hogy a követelményelemzés fontos része az, hogy a rendszer mit tudjon (funkcionális követelmények), de a végtermék használhatósága szempontjából ugyanennyire fontosak a nem funkcionális követelmények, és ide tartozik annak a korlátozása, hogy a kedves pályázók milyen feltételek alapján válasszák ki a megoldást.

Ide tartoznak olyan szempontok, mint:
- a meglevő HW / SW park mire alkalmas, vagy új HW beszerzést is be kell tervezni
- a meglevő üzemeltető gárda mihez ért, vagy továbbképzést / új üzemeltetők felvételét is be kell tervezni
- a rendszert a felhasználóknak hol kell majd használniuk (irodában, valamilyen ipari környezetben, árvíz/belvíz környékén mindentől elvágva 1db GPRS kapcsolattal, esetleg 10m mélyen a víz alatt, búvárruhában)
- a rendszer felhasználóinak az előképzettsége
- vendor lock-in elkerülése (open-source komponensek használata, ahol lehet, és az egyedi fejlesztések forráskódjainak jogai kerüljenek a megrendelőhöz)
- megfelelő dokumentáció megkövetelése (felhasználói, üzemeltetői, fejlesztői)

Az én véleményem az, hogy a pályázati kiírást ezeknek a szempontoknak a figyelembevételével kell elkészíteni, különben megint közpénzpazarlás lesz a vége.

Van konkrét javaslatom is: vedd fel a kormányzati Nyílt forrású technológiai központtal a kapcsolatot, ők biztos tudnak abban segíteni, hogy olyan rendszer készüljön el, ami nem egy újabb vendor lock-in lesz, hanem valóban az ország vagyonát növelje.

Üdv,
Gergely

Köszönöm.

"különben megint közpénzpazarlás lesz a vége." Ennek az elkerülése a célunk.
"- vendor lock-in elkerülése (open-source komponensek használata, ahol lehet, és az egyedi fejlesztések forráskódjainak jogai kerüljenek a megrendelőhöz)" maximálisan egyetértek vele.

"Nyílt forrású technológiai központ" kérnék elérhetőséget, mert ezzel a címmel a google nem volt a barátom.

Én egy igen kis pont vagyok a rendszerben, javaslatokat mindenképpen fogok tenni, az hogy figyelembe veszik-e nem rajtam múlik.

Múltkor kellett ilyet írnom, ill. pontosabban az egyik ügyfél közbesz pályázatkiírása alapján kellett a másikat. Asszem az anyag valamiért bizalmas volt, nem adhatom ki :(

Alapvetően azt gondolom, a fejlesztés 90% CV és 10% minden más. Így legyen benne:
- a konkrét fejlesztők CV-je (a projektmenedzseré nem érdekes, az arra van hogy eltussolja ha valamit a fejlesztők rosszul csinálnak. Viszont ha 10 egyetemista csinálja otthonról, az gáz)
- munkakörnyezet (milyen közegben dolgoznak?), választott technológia (mivel dolgoznak?)
- az eddig elkészült hasonlónak nevezhető projektjeik listája, lehetőleg url-ekkel, screenshotokkal, esetleg ügyfélajánlóval
- ügyfélajánlók
- fejlesztési módszertan (ha nincs nekik, kár bármiről is beszélni)

Namost ezek alapján kiderül, ki a kókler, és ki nem az. Egy program annyira jó amennyire a fejlesztői azok, ha szar a fejlesztőcsapat, édesmindegy, mennyiért csinálják meg. A módszertan is leginkább azért kell, hogy lásd, mi a cég értékrendje. Ezzel vagy egyetértesz, vagy nem.

Ezzel már kiderül, te kivel szeretnél dolgozni, a kérdés az, honnan derül ki, hogy mennyiért.

A jó válasz a sehonnan, sajnos a mit és a hogyan eléggé szétválaszthatatlanok az informatikában, külföldön ezért se csinálnak fixáras informatikai szerződéseket.

De helyi viszonyok vannak.

Szóval fel kell írni a kontextusdiagrammot. A kontextusdiagramm azon szereplők halmaza, akikkel a rendszernek együtt kell működnie. Ezek lehetnek gépi szereplők (pl. Szenzorok, adatszolgáltatók) vagy emberek (adminisztrátor, karbantartó, titkárnő...)

Ezeket illik meginterjúvolni, nyitott kérdésekkel, hogy hogy zajlik egy napja, és mi dolga a rendszerrel. A karosszékből kitalálom megoldás gyakran vezet lekváros buktához (f.ckup with marmalade). Mindenkiből illik 1-2-vel beszélgetni, aki
A) közvetlenül használja a rendszert
B) közvetetten résztvesz a működtetésében vagy kihasználja előnyeit (pl. a nagyfőnök maga nem használja, de reportokat kap belőle, és jó kérdés, mit akar bennük látni)

Felsorolásszintjén a sajtótól a rendszergazdán át a szenzorokat cserélgető ipari búvárig mindenkit fel kell sorolni, ezek közül az interjút azokkal nagyon érdemes akik napi szinten használják a rendszert.

Ebből use case diagrammok születnek (jobb esetben esetleg use case scenario-k is, de az picit a hogyan kategóriája).

Ebből lehet tudni, a rendszert mire használják és milyen szolgáltatásokat vesz igénybe.

Ezen kívül részletes komponensdiagram, protokollokkal (miféle eszközökkel és rendszerekkel milyen protokollon kell beszélgetni), és ha van egy rakás saját rendszer, pláne ha ezt is oda kell rakni, akkor deployment diagram (mi mire van telepítve, mi van helyi hálózatban, mi jön az internetről, mivel milyen gyors a kapcsolat). Mindkettőben a rendszert homályos felhőként, kérdőjeles dobozként ábrázolni kb.

Ebből lehet tudni, mi a műszaki környezet, amibe illeszkedni kell.

Ebből a pár sologból már lehet hozzávetőleges árat mondani, aztán persze mindig kiderül, hogy az illetőnek természetes volt valami így nem mondta el hogy kell, de ez már más tészta és interjútechnika-függő is.

Bővebben szépen le van írva az UML Földi Halandóknak c. könyvben pl (lehetne ezt UML nélkül de más módszertanokkal is kb. ugyanoda jutnánk), interjútechnikákat ott nem találsz, ahhoz valami UX-es könyv kéne.

Kis beugatás az oldalvonal mellől: talán nem elveszett ötlet 1-2 egyetemet előre bevonni. Nem azért, hogy bennfentesek legyenek, nem is azért, hogy segítsenek saját profilra igazítani a pályázatot, de valószínűleg közbeszerzési tapasztalatuk van, és egy gentlemen's agreement lehet, hogy nincs nekik garantálva semmi, ugyanúgy lesznek elbírálva, mint más, de pusztán azért, hogy nem a közlönyből értesülnek a lehetőségről, és helyből nagyobb rálátásuk van, segítenek a kiírás formaiságát biztosítani, ill. akár a mit? kérdésre is jobban ráközelítenib.

Igen, egyetemi pjt-kkel meg lehet szívni... de sajnos nem egyetemiekkel is, viszont egy egyetemet nehezebb röhögve felszámolni, ha garanciálisan helyt kell állni. A Lajtától keletre ez nem utolsó szempont.