🚀 go-pugleaf

Jacek Pietraszek <pmpietrawytnijto@kingausunto.cyf-kr.edu.pl> writes:

[...]

> 1. Jak w praktyce wyglada w Waszych firmach kosztorysowanie
> projektow, w szczegolnosc wstepny obmiar robot?

Chciałbym zauważyć, że -- o ile w branży budowlanej podobno 
istnieją odpowiednie normy dla kosztorysowania -- to w inżynierii
oprogramowania takich norm brakuje.

-- 
http://www.piotr.dembiński.prv.pl

Piotr Dembiński <pdemb@gazeta.pl> napisal:
> Chciałbym zauważyć, że -- o ile w branży budowlanej podobno 
> istnieją odpowiednie normy dla kosztorysowania -- to w inżynierii
> oprogramowania takich norm brakuje.

Alez gdyby istnialy, to nie zadawalby takiego pytania :)
Interesuje mnie praktyczne rozwiazania realizowane w warunkach
braku powszechnie uznanego standardu. A ze istnieja, to rzecz
niewatpliwa, bo jak inaczej mozna by przystapic do wyceny
projektu? Zwlaszcza duzego...
-- 
Pozdrawiam,

Jacek

Jacek Pietraszek <pmpietraABCDEF@kingaXXXYYYZZZ.cyf-kr.edu.pl> writes:

> Piotr Dembiński <pdemb@gazeta.pl> napisal:
>> Chciałbym zauważyć, że -- o ile w branży budowlanej podobno
>> istnieją odpowiednie normy dla kosztorysowania -- to w inżynierii
>> oprogramowania takich norm brakuje.
>
> Alez gdyby istnialy, to nie zadawalby takiego pytania :)
> Interesuje mnie praktyczne rozwiazania realizowane w warunkach
> braku powszechnie uznanego standardu. A ze istnieja, to rzecz
> niewatpliwa, bo jak inaczej mozna by przystapic do wyceny
> projektu? Zwlaszcza duzego...

Liczysz na to, że Prokom udostępni ci informacje na temat własnych
procedur określania pracochłonności przedsięwzięcia?

On Sat, 07 Apr 2007 12:11:03 +0200, pdemb@gazeta.pl (Piotr Dembiński)
wrote:

>Jacek Pietraszek <pmpietrawytnijto@kingausunto.cyf-kr.edu.pl> writes:
>
>[...]
>
>> 1. Jak w praktyce wyglada w Waszych firmach kosztorysowanie
>> projektow, w szczegolnosc wstepny obmiar robot?
>
>Chciałbym zauważyć, że -- o ile w branży budowlanej podobno 
>istnieją odpowiednie normy dla kosztorysowania -- to w inżynierii
>oprogramowania takich norm brakuje.

Penei Debinski, jak zwukls pisze pan o rzeczach na ktorych sie nei zna

A.L.

Jacek Pietraszek napisał(a):
> Witam,
> 
> dyskusja nad Ada rozwinela sie tak owocnie, ze pozwalam
> sobie wrzucic nastepne dwa granaty do dyskusyjnego kacika:
> 
> 1. Jak w praktyce wyglada w Waszych firmach kosztorysowanie
> projektow, w szczegolnosc wstepny obmiar robot? Czy dostepne
> sa dla naszej branzy zestawy cennikowe o charakterze nieco
> bardziej ogolnym\ typu "Sekocenbudu" :)
Ale dlaczego terminologia budowlana. Czemu porównujemy programowanie do budowy 
domu. Spójrzmy do innych branż. Jak wycenia prawnik wygranie sprawy, lekarz 
wyleczenie, pisarz książkę czy "przedstawiciel motoryzacji"(brak mi terminu) cenę 
samochodu.  Każda jest zupełnie inna i rządzi się innymi prawami. O ile wiem, to w 
programowaniu też można kilka (naście) zupełnie różnych sytuacji, które mają 
więcej analogii do powyższych niż do budowlanki.

Po drugie stosunek  kosztu wykonania pierwszego egzemplarza a kolejnych w pewnych 
warunkach dąży do nieskończoności. Tego nie ma chyba w żadnej innej branży (no 
może poza pisarstwem, ale trzeba zrezygnować z papierowych wersji)

Po trzecie nie koniecznie trzeba zarabiać na kodzie (patrz przeklęty powyżej GPL). 
Natomiast moim zdaniem kod należy wykorzystać do przywiązania klienta.


Darek

PS. Również pozdrowienia świąteczne

Piotr Dembiński <pdemb@gazeta.pl> napisal:
> Liczysz na to, że Prokom udostępni ci informacje na temat własnych
> procedur określania pracochłonności przedsięwzięcia?

Zastrzeglem sie "o ile pozwoli", wiec nie zakladam, ze udostepnia
np. tabele wskaznikow lub elementow scalonych. Natomiast sama
procedura raczej powinna byc dostepna, gdyz realizuja ja ludzie,
ktorzy w firmie pojawiaja sie i znikaja, wiec liczenie na utajnienie
samej procedury byloby naiwnoscia.
-- 
Pozdrawiam,

Jacek

A.L. <fela@2005.com> napisal:
> Penei Debinski, jak zwukls pisze pan o rzeczach na ktorych sie nei zna

Ponowie swoje pytanie: czy sa ogolnie dostepne opisy
procedur kosztorysowania projektow z zakresu oprogramowania,
a nawet - byc moze - tablice odpowiednich wskaznikow kosztowych.
Ewentualnie jakas literatura przedmiotu?
-- 
Pozdrawiam swiatecznie,

Jacek

On Sat, 07 Apr 2007 16:57:32 +0200, pdemb@gazeta.pl (Piotr Dembiński)
wrote:

>A.L. <fela@2005.com> writes:
>
>> On Sat, 07 Apr 2007 12:11:03 +0200, pdemb@gazeta.pl (Piotr
>> Dembiński)
>> wrote:
>>
>>>Jacek Pietraszek <pmpietrawytnijto@kingausunto.cyf-kr.edu.pl>
>>>writes:
>>>
>>>[...]
>>>
>>>> 1. Jak w praktyce wyglada w Waszych firmach kosztorysowanie
>>>> projektow, w szczegolnosc wstepny obmiar robot?
>>>
>>>Chciałbym zauważyć, że -- o ile w branży budowlanej podobno 
>>>istnieją odpowiednie normy dla kosztorysowania -- to w inżynierii
>>>oprogramowania takich norm brakuje.
>>
>> Penei Debinski, jak zwukls pisze pan o rzeczach na ktorych sie nei
>> zna
>
>A są?

Rzecysisciee, "norm" w seensie "norm prawnych", "norm standardow" nie
ma. Co nie znaczy ze nie ma powszechnie stosowanych soposbow
obliczania kosztow.

W USA "regula kciuka" jest nastepujaca :a) roczny koszt programisty
jest 2.2 - 2.5 jego rocznej pensji, b) koszt jest modyfikowany
stosownie do casu trwania projektu, c) dodaje sie koszta wszystkich
programistow bioracych udzial w projekcie d) Nie dodaje sie kosztow
pracownikow "nieprodukcyjnych", bo ow koszt jest juz uwzgledniony w
postaci owego wspolczynnika. 

Czy to ma byc 2.2 czy 2.5 zalezy od firmy i jest firmy scisle
strzezona tajemnica. Oczywiscie, realny koszt jest ustalany
dokladniej, ale owa regula daje zadziwiajaco dobre rezultaty i jest
powsechnie stosowana na etapie "oplaca sie brac projekt czy nie"


A.L.

A.L. <fela@2005.com> writes:

> On Sat, 07 Apr 2007 12:11:03 +0200, pdemb@gazeta.pl (Piotr
> Dembiński)
> wrote:
>
>>Jacek Pietraszek <pmpietrawytnijto@kingausunto.cyf-kr.edu.pl>
>>writes:
>>
>>[...]
>>
>>> 1. Jak w praktyce wyglada w Waszych firmach kosztorysowanie
>>> projektow, w szczegolnosc wstepny obmiar robot?
>>
>>Chciałbym zauważyć, że -- o ile w branży budowlanej podobno 
>>istnieją odpowiednie normy dla kosztorysowania -- to w inżynierii
>>oprogramowania takich norm brakuje.
>
> Penei Debinski, jak zwukls pisze pan o rzeczach na ktorych sie nei
> zna

A są?

On Sat, 7 Apr 2007 14:37:48 +0000 (UTC), Jacek Pietraszek
<pmpietraALAMAKOTA@kingaOLAMAPSA.cyf-kr.edu.pl> wrote:

>A.L. <fela@2005.com> napisal:
>> Penei Debinski, jak zwukls pisze pan o rzeczach na ktorych sie nei zna
>
>Ponowie swoje pytanie: czy sa ogolnie dostepne opisy
>procedur kosztorysowania projektow z zakresu oprogramowania,
>a nawet - byc moze - tablice odpowiednich wskaznikow kosztowych.
>Ewentualnie jakas literatura przedmiotu?


Loco USA nie ma "tablic kosztow" ani niczego takiego. Jedna z "metod
kciuka" opisalem w odpowiedzi Panu Debinskiemu.

Ksiazki ktore moge polecic sa nastepujace:

"Software Cost Estimation and Sizing Mathods, Issues, and Guidelines",
Shari Lawrence Pfleeger

a poniewaz dokladnosc obliczanai kosztow jest scisle zwiazana z
obliczeniem potrebnych "sil i srodkow" oraz czasu, polecam rzecz
nastepujaca:

"Software Estimation: Demystifying the Black Art", Steve McConnell

A.L.

A.L. <fela@2005.com> writes:

[...]

>>>>> 1. Jak w praktyce wyglada w Waszych firmach kosztorysowanie
>>>>> projektow, w szczegolnosc wstepny obmiar robot?
>>>>
>>>>Chciałbym zauważyć, że -- o ile w branży budowlanej podobno
>>>>istnieją odpowiednie normy dla kosztorysowania -- to w inżynierii
>>>>oprogramowania takich norm brakuje.
>>>
>>> Penei Debinski, jak zwukls pisze pan o rzeczach na ktorych sie nei
>>> zna
>>
>>A są?
>
> Rzecysisciee, "norm" w seensie "norm prawnych", "norm standardow"
> nie ma. Co nie znaczy ze nie ma powszechnie stosowanych soposbow
> obliczania kosztow.

Istnieją powszechnie przyjęte metody szacowania pracochłonności, ale
-- z tego, co wiem -- póki co nie zostały opracowane normy zalecające
stosowanie którejkolwiek z tych metod.  

Z drugiej strony -- w ramach ISO został opracowany standard dla
punktów funkcyjnych, a od zmierzenia do wyceny droga nie jest znowu 
aż tak daleka.

-- 
http://www.piotr.dembiński.prv.pl

A.L. <fela@2005.com> writes:

[...]

>>>>> 1. Jak w praktyce wyglada w Waszych firmach kosztorysowanie
>>>>> projektow, w szczegolnosc wstepny obmiar robot?
>>>>
>>>>Chciałbym zauważyć, że -- o ile w branży budowlanej podobno
>>>>istnieją odpowiednie normy dla kosztorysowania -- to w inżynierii
>>>>oprogramowania takich norm brakuje.
>>>
>>> Penei Debinski, jak zwukls pisze pan o rzeczach na ktorych sie nei
>>> zna
>>
>>A są?
>
> Rzecysisciee, "norm" w seensie "norm prawnych", "norm standardow"
> nie ma. Co nie znaczy ze nie ma powszechnie stosowanych soposbow
> obliczania kosztow.

Istnieją powszechnie przyjęte metody szacowania pracochłonności, ale
-- z tego, co wiem -- póki co nie zostały opracowane normy zalecające
stosowanie którejkolwiek z tych metod.  

Z drugiej strony -- w ramach ISO został opracowany standard dla
punktów funkcyjnych, a od zmierzenia projektu oprogramowania do
oszacowania pracochłonności wykonania droga nie jest znowu aż 
tak daleka.

-- 
http://www.piotr.dembiński.prv.pl

Jacek Pietraszek <pmpietraALAMAKOTA@kingaOLAMAPSA.cyf-kr.edu.pl>
writes:

[...]

> Ponowie swoje pytanie: czy sa ogolnie dostepne opisy
> procedur kosztorysowania projektow z zakresu oprogramowania,
> a nawet - byc moze - tablice odpowiednich wskaznikow kosztowych.
> Ewentualnie jakas literatura przedmiotu?

COCOMO2

pdemb@gazeta.pl (Piotr Dembiński) writes:

> Jacek Pietraszek <pmpietraALAMAKOTA@kingaOLAMAPSA.cyf-kr.edu.pl>
> writes:
>
> [...]
>
>> Ponowie swoje pytanie: czy sa ogolnie dostepne opisy procedur
>> kosztorysowania projektow z zakresu oprogramowania, a nawet - byc
>> moze - tablice odpowiednich wskaznikow kosztowych.  Ewentualnie
>> jakas literatura przedmiotu?
>
> COCOMO2

Nawiasem mówiąc, to w ISO/IEC TR 19759:2005 nie ma na temat COCOMO 
ani słowa.

A.L. <fela@2005.com> napisal:
> 
> Loco USA nie ma "tablic kosztow" ani niczego takiego. Jedna z "metod
> kciuka" opisalem w odpowiedzi Panu Debinskiemu.
> 
> Ksiazki ktore moge polecic sa nastepujace:
> 
> "Software Cost Estimation and Sizing Mathods, Issues, and Guidelines",
> Shari Lawrence Pfleeger
> 
> a poniewaz dokladnosc obliczanai kosztow jest scisle zwiazana z
> obliczeniem potrebnych "sil i srodkow" oraz czasu, polecam rzecz
> nastepujaca:
> 
> "Software Estimation: Demystifying the Black Art", Steve McConnell

Serdecznie dziekuje.
-- 
Pozdrawiam,

Jacek

"Jacek Pietraszek" <pmpietraABCDEF@kingaXXXYYYZZZ.cyf-kr.edu.pl> wrote in 
message news:ev7rd0$od9$2@srv.cyf-kr.edu.pl...
> Piotr Dembiński <pdemb@gazeta.pl> napisal:
>> Chciałbym zauważyć, że -- o ile w branży budowlanej podobno
>> istnieją odpowiednie normy dla kosztorysowania -- to w inżynierii
>> oprogramowania takich norm brakuje.
>
> Alez gdyby istnialy, to nie zadawalby takiego pytania :)
> Interesuje mnie praktyczne rozwiazania realizowane w warunkach
> braku powszechnie uznanego standardu. A ze istnieja, to rzecz
> niewatpliwa, bo jak inaczej mozna by przystapic do wyceny
> projektu? Zwlaszcza duzego...
> -- 
Polska praktyka wyglada w ogolnosci tak, ze sie zgaduje jakas wartosc z 
bledem rzedu 90%, a potem generuje straty. Niestety swiadmosc tego, ze 
software estimation/sizing/costing jest integralna czescia cyklu 
projektowego jest niska.
Jednakze sa firmy gdzie do costingu podchodzi sie bardziej 
analityczno-formalnie. Pierwszym krokiem jest WBS i sizing. W mojej praktyce 
korzystam z function point analysis 
(http://www.softwaremetrics.com/freemanual.htm) badz opieram sie na danych 
historycznych tzn. metrykach z zakonczonych juz projektow. Oczywiscie 
zgadywania nie da sie do konca wyeliminowac, ale w koncu sa to szacunki.
Majac wyniki sizingu, wrzucam je do COCOMO II, kalibruje i dostaje effort. 
Majac effort i znajac deadline okreslam potrzebny staffing i dalej schedule. 
Wiedzac jaki jest koszt utrzymania jednego architekta/programisty/testera 
mam koszt projektu. To tak w skrocie. Generalnie liczby nie klamia i 
pomagaja uniknac nieprzyjemnych sytuacji w pozniejszych fazach projektu. 
Oczywiscie do effortu nalezy dodac jeszcze czas poswiecony na ogolnie pojety 
"overhead", do kosztu zakup licencji na potrzebne oprogramowanie itp.

Podobnie jak A.L. polecam "Software Estimation: Demystifying the Black Art". 
Podstawa dla kogos kto chce byc kims wiecej niz programista, a juz na pewno 
obowiazek dla przyszlych manago.
Swego czasu natknalem sie tez na sieci na jakis white paper z Rationala 
gdzie liczyli effort na bazie use case'ow. Wygladalo ciekawie, ale nie 
mialem czasu sie w to zaglebiac.

pzdr
Muchomor 

On Sun, 8 Apr 2007 01:58:46 +0200, "Muchomor"
<muchomor_w_kropkiCUT_THIS@gazeta.pl> wrote:
 
>> -- 
>Polska praktyka wyglada w ogolnosci tak, ze sie zgaduje jakas wartosc z 
>bledem rzedu 90%, a potem generuje straty. Niestety swiadmosc tego, ze 
>software estimation/sizing/costing jest integralna czescia cyklu 
>projektowego jest niska.
>Jednakze sa firmy gdzie do costingu podchodzi sie bardziej 
>analityczno-formalnie. 

E... Zgadnac ile zazyczy sobie konkurencja i policzyc 10% taniej :)

A.L.

"Muchomor" <muchomor_w_kropkiCUT_THIS@gazeta.pl> writes:

[...]

> Swego czasu natknalem sie tez na sieci na jakis white paper
> z Rationala gdzie liczyli effort na bazie use case'ow. Wygladalo
> ciekawie, ale nie mialem czasu sie w to zaglebiac.

Use Case Points.

"A.L." <fela@2005.com> wrote in message 
news:aedg13pmt665v6c8jjeo7n5rcqsu6359qr@4ax.com...
> On Sun, 8 Apr 2007 01:58:46 +0200, "Muchomor"
> <muchomor_w_kropkiCUT_THIS@gazeta.pl> wrote:
>
>>> -- 
>>Polska praktyka wyglada w ogolnosci tak, ze sie zgaduje jakas wartosc z
>>bledem rzedu 90%, a potem generuje straty. Niestety swiadmosc tego, ze
>>software estimation/sizing/costing jest integralna czescia cyklu
>>projektowego jest niska.
>>Jednakze sa firmy gdzie do costingu podchodzi sie bardziej
>>analityczno-formalnie.
>
> E... Zgadnac ile zazyczy sobie konkurencja i policzyc 10% taniej :)
>
Procowalem kiedys w firmie, ktora tak dzialala. Boss mowi: "macie we czworke 
skonczyc do konca sierpnia."
Szef Projektu (z przerazeniem) : "nie damy rady"
Boss: " to bedziecie dymac w likendy"

Skonczylo sie kompromitacja przed bardzo duzym i bogatym klientem. Szef 
projektu zaczal regularnie uczeszczac do psychiatry. Nasza czworka zmienila 
prace przed koncem sierpnia. Firma ponoc jeszcze dziala, ale Boss (po kliku 
kolejnych spektakularnych wtopach) wylecial na kopach wyrzucony przez zaloge 
jakis czas temu.

pzdr
Muchomor 

On Mon, 9 Apr 2007 17:17:44 +0200, "Muchomor"
<muchomor_w_kropkiCUT_THIS@gazeta.pl> wrote:

> 
>Skonczylo sie kompromitacja przed bardzo duzym i bogatym klientem. Szef 
>projektu zaczal regularnie uczeszczac do psychiatry. Nasza czworka zmienila 
>prace przed koncem sierpnia. Firma ponoc jeszcze dziala, ale Boss (po kliku 
>kolejnych spektakularnych wtopach) wylecial na kopach wyrzucony przez zaloge 


O... "wyrzyciny przez zaloge"?... To jaki system polityczny tam
panuje?...

A.L.

A.L. wrote:
> O... "wyrzyciny przez zaloge"?... To jaki system polityczny tam
> panuje?...

Może to była "spółka skarbu państwa".

w.

"A.L." <fela@2005.com> wrote
>>
>>Skonczylo sie kompromitacja przed bardzo duzym i bogatym klientem. Szef
>>projektu zaczal regularnie uczeszczac do psychiatry. Nasza czworka 
>>zmienila
>>prace przed koncem sierpnia. Firma ponoc jeszcze dziala, ale Boss (po 
>>kliku
>>kolejnych spektakularnych wtopach) wylecial na kopach wyrzucony przez 
>>zaloge
>
>
> O... "wyrzyciny przez zaloge"?... To jaki system polityczny tam
> panuje?...
>
Nie wiem jak sie ten system nazywa, ale jako ze Boss nie byl wlascicielem 
firmy tylko jakims "dyrektorem na kontrakcie" to zaloga (grupa tzw 
"niezastapionych") straszac odejsciem wymusila na grupie vice-Bossow 
zwolnienie glownego Bossa. Szczegolow nie znam bo to bylo dlugo po moim 
odejsciu.

pzdr
Muchomor 

On 9 Kwi, 14:54, A.L. <f...@2005.com> wrote:
> Wszystko mi to wyglada na pomieszanie pojec z ksiazki "Ekonomia
> Polityczna Socjalizmu" z ksiazka "Ania z Zielonego Wzgorza".
>
> Nie wiem, moze w Polsce wszyscy sie kochaja i klient z ochota wybiera
> projekt drozszy bo po prostu kocha kontrachenta. Jak rozniez kazda
> konkurencja jest uczciwa.
>
> Z perspektywy tu gdzie jestem, "zdobycie rynku" i wyparcie konkurencji
> jest jednym z instotnych kryteriow, a efekty ekonomiczne nei sa
> mierzone w perspektywie konkretnego projektu, a w perspektywie
> bardziej dlugofalowej. Wiec nie ma problemu z puszczeniem paru
> projektow na stratach, po to tylko zeby pozniej to sobie sowicie
> odbic.
>
> A.L.

Faktycznie jesteśmy z dwóch róznych bajek... odpadam....

jz

"Zycie jest zbyt krotkie by marnowac je na kontakty z idiotami (Jean
Paul Sartre)"

On 9 Apr 2007 11:39:19 -0700, "ToJaJarek" <tojajarek@gmail.com> wrote:

>On 9 Kwi, 14:54, A.L. <f...@2005.com> wrote:
>> Wszystko mi to wyglada na pomieszanie pojec z ksiazki "Ekonomia
>> Polityczna Socjalizmu" z ksiazka "Ania z Zielonego Wzgorza".
>>
>> Nie wiem, moze w Polsce wszyscy sie kochaja i klient z ochota wybiera
>> projekt drozszy bo po prostu kocha kontrachenta. Jak rozniez kazda
>> konkurencja jest uczciwa.
>>
>> Z perspektywy tu gdzie jestem, "zdobycie rynku" i wyparcie konkurencji
>> jest jednym z instotnych kryteriow, a efekty ekonomiczne nei sa
>> mierzone w perspektywie konkretnego projektu, a w perspektywie
>> bardziej dlugofalowej. Wiec nie ma problemu z puszczeniem paru
>> projektow na stratach, po to tylko zeby pozniej to sobie sowicie
>> odbic.
>>
>> A.L.
>
>Faktycznie jesteśmy z dwóch róznych bajek... odpadam....
>
>jz
>
>"Zycie jest zbyt krotkie by marnowac je na kontakty z idiotami (Jean
>Paul Sartre)"
>

Jak dla mnie, Sartre byl idiota.

A.L.

On 10 Kwi, 06:11, A.L. <f...@2005.com> wrote:
> On 9 Apr 2007 11:39:19 -0700, "ToJaJarek" <tojaja...@gmail.com> wrote:
>
>
>
> >On 9 Kwi, 14:54, A.L. <f...@2005.com> wrote:
> >> Wszystko mi to wyglada na pomieszanie pojec z ksiazki "Ekonomia
> >> Polityczna Socjalizmu" z ksiazka "Ania z Zielonego Wzgorza".
>
> >> Nie wiem, moze w Polsce wszyscy sie kochaja i klient z ochota wybiera
> >> projekt drozszy bo po prostu kocha kontrachenta. Jak rozniez kazda
> >> konkurencja jest uczciwa.
>
> >> Z perspektywy tu gdzie jestem, "zdobycie rynku" i wyparcie konkurencji
> >> jest jednym z instotnych kryteriow, a efekty ekonomiczne nei sa
> >> mierzone w perspektywie konkretnego projektu, a w perspektywie
> >> bardziej dlugofalowej. Wiec nie ma problemu z puszczeniem paru
> >> projektow na stratach, po to tylko zeby pozniej to sobie sowicie
> >> odbic.
>
> >> A.L.
>
> >Faktycznie jesteśmy z dwóch róznych bajek... odpadam....
>
> >jz
>
> >"Zycie jest zbyt krotkie by marnowac je na kontakty z idiotami (Jean
> >Paul Sartre)"
>
> Jak dla mnie, Sartre byl idiota.
>
> A.L.

Czyżbyś odebrał ten cytat do siebie? Hm... to był tylko zwykły
cytat.....przepraszam...


Wracając do wątku:

Większość oprogramowania dedykowanego jest pisana na bazie umowy o
dzieło (lub jej prawnych odpowiedników). To znaczy, że obowiązuje tu
ustawa o prawie autorskim, w tym także definicja utworu z tej ustawy,
który jest tu tymże dziełem.

"Art. 1. 1. Przedmiotem prawa autorskiego jest każdy przejaw
działalności twórczej o indywidualnym charakterze, ustalony w
jakiejkolwiek postaci, niezależnie od wartości, przeznaczenia i
sposobu wyrażenia (utwór).
2. W szczególności przedmiotem prawa autorskiego są utwory:
1) wyrażone słowem, symbolami matematycznymi, znakami graficznymi
(literackie, publicystyczne, naukowe, kartograficzne oraz programy
komputerowe)," (cytat z ustawy)

Programy komputerowe są więc traktowane, także przez rynek, jako
utwory o konkretnych cechach. Mają one wartość jako gotowy produkt. Z
uwagi na te cechy i konkurencję pomiędzy twórcami oprogramowania traci
znaczenie pracochłoność a nabiera znaczenia efekt końcowy. Program
komputerowy to efekt pracy głównie analityka, projektanta systemu i
programisty. Dla nabywcy nie ma znaczenia jakich narzędzi i metodyki
użył wykonawca, nie licząc oczywiscie analizy ryzyka związanego z
zatrudnieniem takiej a nie innej firmy i narzędzi jakich używa. Liczy
się produkt, to czy spełnia oczekiwania (zakres projektu), jakim
kosztem i w jakim czasie zostanie wykonany.

Gdyby było inaczej, programiści kodujacy systemy ERP latami w kodzie
maszynowym zarabiali by krocie a Ci którzy używają narzędzi CASE,
skutecznych motodyk projektowania, wydajnych języków programowania i
potrafią wymyślać dobre i szybkie algorytmy poszli by z torbami.

Klient dzisiaj coraz częściej płaci za gotowy wykop a nie za liczbę
łopato-człowieko-godzin. Firma z koparką i dobrem inżynierem zawsze
wygra i liczy sobie za kilometr gotowego wykopu a nie za liczbę
ekwiwalentu z tablicy machnięć łopatą.