Wycena aplikacji (C#) - obsługa kart zbliżeniowych

0

Hej! Napisałem program do obsługi kart w standardzie MIFARE OmniKey.. Właściwie to jest wrapper... tzn. DLL w .NET (ale może być wykorzystywana także w środowiskach z poza .NET, np. w Delphi czy C++, pod warunkiem zainstalowanego .NET framework w systemie).
Program tj. biblioteka odczytuje z czytnika kart zbliżeniowych nr karty i zwraca go jako wynik funkcji...
Ile za taką DLLke wziąć? Firma zewnętrzna chce wycenę...
Nie mam pojęcia bo nigdy czegoś takiego nie robiłem (zawsze na etacie pracowałem lub na ryczałcie)...
Kod programu to zaledwie 1000 linijek kodu z groszami.... Plus przykładowa aplikacja testująca...
DLL na pewno działa w programach .NET oraz w C++ (Visual C++, MinGW), CA Visual Objects...

3

Policz ile czasu ci to zajęło, pomóż przez stawkę godzinową i pomnóż razy trzy.
Nie zapomnij spisać umowy, która dokładnie określa:

  • licencję na produkt
    • kto ma prawa majątkowe do biblioteki
    • czy mają prawa dokonywać zmian
    • czy mają prawa sprzedawać bibliotekę osobą trzecim (lub ją upublicznić)
  • twoją odpowiedzialność
    • co jeśli coś przestanie działać
    • co jeśli wykryją błąd w jakimś dziwnym przypadku
    • co jeśli w działaniu twoja biblioteka zawiedzie co spowoduje jakieś straty,
    • przez jaki czas zapewniasz suport (usuwanie bugów, nauka użytkownika biblioteki).
  • co powinien zawierać produkt poza samą dll-ką
    • kod
    • przykładowa aplikacja
    • testy jednostkowe funkcjonalne

Może ktoś jeszcze uzupełni ci tę listę o inne ważne punkty.

To wszystko dość znacznie modyfikuje cenę, a jeśli nie określisz tego w umowie, to po roku będziesz miał dziwne telefony i domaganie się różnych cudów, napraw i rozbudowań w ramach starej umowy (tak z góry założy sobie klient).

0

Dziękuje za odpowiedź...
A jakieś przykładowe teksty umowy licencyjnej?? Wiem, że można popytać wujka google.pl ale wole się spytać na wszelki wypadek doświadczonych praktyków:)

0

pomóż przez stawkę godzinową i pomnóż razy trzy.

Jakim prawem razy trzy? Takie swoje "widzi mi się"?

2
Cennik napisał(a):

pomóż przez stawkę godzinową i pomnóż razy trzy.

Jakim prawem razy trzy? Takie swoje "widzi mi się"?
a takim, że to MÓJ kod i mogę go wycenić jak mi się podoba. Masz z tym jakiś problem?

0

Dzięki za informacje. Jeszcze muszę sporządzić umowę licencyjną. :)
Btw. pisałem kiedyś DLLke w C++ i WinAPI i hmm.. muszę powiedzieć, że C# jest jednak w komercyjnych zastosowaniach zdecydowanie "przyjemniejszy" i jest mniej dziwnych niespodzianek... :)

0

a takim, że to MÓJ kod i mogę go wycenić jak mi się podoba. Masz z tym jakiś problem?

Jasne, ale skoro podaje się pewne dane matematyczne np wzór (w tym przypadku: Zarobki * godziny * 3) to stałę powinny mieć jakieś uzasadnienie i jestem ciekaw włąśnie tego uzasadnienia.
Bo to, że to "standard" do mnie nie przemawia, bo jeszcze nie widziałem w życiu standardu wycen aplikacji...

Ja rozumiem wycenę w stylu:
(Stawka godzinowa * ilość godzin) * umiejętności * motywacja * jakość kodu
gdzie trzy ostatnie parametry są wartościami od 0.0 do 2.0

I to ma sens wtedy bo każda zmienna ma swój rzeczywisty sens, a wartość 3? Czym ona jest i dlaczego właśnie 3?

0
Cennik napisał(a)

Czym ona jest i dlaczego właśnie 3?

Jest stałą równą 3, a jest równa tyle, bo tak mu się podoba :P

0

taki przelicznik może wynikać m.in. z gwarancji. Często napisanie programu to ta łatwiejsza strona pracy, wdrożenie i późniejsze zmiany mogą kosztować więcej czasu niż napisanie samego programu.

1
MarekR22 napisał(a):
  • twoją odpowiedzialność
    • co jeśli coś przestanie działać
    • co jeśli wykryją błąd w jakimś dziwnym przypadku
    • co jeśli w działaniu twoja biblioteka zawiedzie co spowoduje jakieś straty,
    • przez jaki czas zapewniasz suport (usuwanie bugów, nauka użytkownika biblioteki).

Może ktoś jeszcze uzupełni ci tę listę o inne ważne punkty.

To wszystko dość znacznie modyfikuje cenę, a jeśli nie określisz tego w umowie, to po roku będziesz miał dziwne telefony i domaganie się różnych cudów, napraw i rozbudowań w ramach starej umowy (tak z góry założy sobie klient).

Ja właśnie ująłbym to inaczej.
Błędy w naszym oprogramowaniu powinniśmy naprawiać za darmo... w okresie rozruchowym (1 mc do 1 rok).
Natomiast analiza potrzeb, reinstalacja, dodatkowa konfiguracja, kontakt telefoniczny nie związany z błędami - wszystko to powinno być płatne.

A jaka jest definicja błędu? Chyba najprościej taka: "działanie programu niezgodne z zapisami w zatwierdzonej dokumentacji wymagań". Można doszczegóławiać i upierdliwy klient może podciągać pod błędy sprawy typu "ja myślałem że to oczywiste że to musi również działać z Office 3000". Dlatego warto z góry określić okres wsparcia darmowego, a okres wsparcia płatnego - może być przedłużany co roku (lub nie). Okres wsparcia płatnego powinien mieć określone limity (kontaktów tel, maili, incydentów - do wyboru). Bo bez tego powinniśmy kasować za ten okres tak samo jakbyśmy pracowali dla klienta na 100% czasu.

Dodatkowo ważne jest żeby określić czy klient dostaje wyłączną licencję (exclusive).
Jeśli dostanie, to produkt nie może zostać sprzedany przez autora innemu klientowi.

O transferowaniu licencji już napisano.

0

A dlaczego są wartościami od 0.0 do 2.0, a nie od 2.0 do 2000.0? Uzasadnij. Czym jest i dlaczego właśnie 2 przyjąłeś za górną granicę?

hmmmm... chyba ktoś nie chodził na lekcje matematyki. Możesz podać sobie wartości od -2000 do 2000, ale na pewno nie od 2 do 2000.

taki przelicznik może wynikać m.in. z gwarancji. Często napisanie programu to ta łatwiejsza strona pracy, wdrożenie i późniejsze zmiany mogą kosztować więcej czasu niż napisanie samego programu.

No i ok. Przynajmniej jest jakiś powód tej liczby :) Nie ważne ile by ona nie wynosiła.
Chodziło mi o to, że sztuczne wartości jak jakaś liczba z kosmosu np. 100 jest nie wiadomo skąd.

Nawet czasami klient prosi o wycenę szczegółową aplikacji i co w takim przypadku?
Poda się wzór x * y * 3?
Klient od razu by się oburzył, że z jakiej racji ma płacić 3 razy za to samo.
Ale jeśli napiszemy:
x * y * cena wdrożenia to już jest ok.

0

Tylko, że w wycenie nie podaje się wzoru :) Po prostu za to tyle, za coś innego tyle. A te 3-5 to wzięło się stąd, że przy projektowaniu aplikacji coś co wg. nas powinno zająć godzinę nierzadko zajmuje o wiele, wiele więcej czasu.

Przecież to bez sensu.
Wyżej było napisane:

Policz ile czasu ci to zajęło, pomóż przez stawkę godzinową i pomnóż razy trzy.

Więc skoro w wycenie już uwzględniamy faktyczną liczbę godzin, to nie musimy mnożyć jej dodatkowo o X.

W wycenie projektu często mnoży się właśnie o liczbę 3, ALE przed ukończeniem projektu. Na zasadzie, klient przychodzi do nas z pomysłem i specyfikacją, a my wyceniamy długość trwania prac.
W tym topicu mamy jednak sytuację, iż projekt jest już ukończony, więc mnożenie przez 3 (zakładając, że to 3 to liczba "zabezpieczająca") jest bez sensu.

0

Profesjonaliści od razu myślą o okresie gwarancyjnym, którego na bank będzie domagał się klient. Co z tego, że programista klepnie aplikację? Po kilku miesiącach program rozpieprzy se radośnie bazę danych wskutek błędu w logice, nie mając żadnego ogarniętego programisty pod ręką (jeszcze gorzej jeśli nawet nie masz źródeł) nic nie zdziałasz.

0

Ok, zgadzam się, tylko tak jak wcześniej napisałem chciałem wiedzieć skąd ta liczba.

0

BTW, przypomniało mi się. Przy wymaganiach warto opisać wymagany sprzęt i środowisko.
Klient może zaktualizować sobie CPU, HDD, RAM lub Windows a potem mieć wymóg poprawienia Twojego softu (bo nie działa).
Widziałem np. program instalacyjny w Javie który nie chodził na pewnym CPU i koniec. Trzeba było to obchodzić.

1 użytkowników online, w tym zalogowanych: 0, gości: 1