Temat: Ciekawy wynik małych badań stosowania modelowania w...

I started a company called Nascent Blue that specializes in MDD for application development. We have actually had the opportunity to compare MDD to traditional development side-by-side on large projects. Our client set up "the experiment" to collect the PM data for analysis. It was a large project with 5 teams. The results:

1. Our team was less than half the size of the other teams.

2. Our team produced more than twice the code of the other teams.

3. Our team achieved a 75% reduction in cost.

4. Our team achieved a 66% reduction in defect rate.

5. Our team was twice as fast (with half the size).

We have since gotten more efficient and more advanced, so I don't know what the numbers are now.

We develop our own modeling tools (UML, ERD, and DSLs for UI and other things). We also have tools for ADM, so we can achieve similar productivity gains for re-platforming and re-architecture projects.

http://www.linkedin.com/groups/Model-driven-productivi...

Temat: Ciekawy wynik małych badań stosowania modelowania w...

Jeżeli dobrze zrozumiałem opis: mieli duży projekt, podzielili go między 5 zespołów (czyli każdy zespół robił odrębną część) i jeden z tych zespołów pracował przy użyciu MDD.
Raczej trudno nazwać to "doświadczenie" badaniem. Nie spełnia po prostu podstawowych wymagań dla badań naukowych, ciężko więc wyciągnąć z tego jakiekolwiek wnioski. Aby móc przeprowadzić prawdziwy eksperyment należałoby zapewnić niezmienność parametrów - ci sami ludzie pracujący nad tym samym tematem dwoma różnymi metodami. Najlepiej jeszcze gdyby usunąć wiedzę jaką zespół zdobędzie przy pierwszej próbie. Wtedy można zrobić jakieś porównanie.
Niestety, w przypadku każdej metodyki czy narzędzia taki eksperyment nie jest możliwy. Jedyne co jest możliwe to badania statystyczne, jednak te także powinny być normalizowane: wielkością projektu, wielkością zespołu, jakością ludzi, złożonością projektu itp. Większość tych parametrów jest niemierzalna.

Temat: Ciekawy wynik małych badań stosowania modelowania w...

Jacek S.:
Jeżeli dobrze zrozumiałem opis: mieli duży projekt, podzielili go między 5 zespołów (czyli każdy zespół robił odrębną część) i jeden z tych zespołów pracował przy użyciu MDD.
Raczej trudno nazwać to "doświadczenie" badaniem. Nie spełnia po prostu podstawowych wymagań dla badań naukowych, ciężko więc wyciągnąć z tego jakiekolwiek wnioski.

masz rację

Aby móc przeprowadzić prawdziwy eksperyment należałoby zapewnić niezmienność parametrów - ci sami ludzie pracujący nad tym samym tematem dwoma różnymi metodami. Najlepiej jeszcze gdyby usunąć wiedzę jaką zespół zdobędzie przy pierwszej próbie. Wtedy można zrobić jakieś porównanie.
Niestety, w przypadku każdej metodyki czy narzędzia taki eksperyment nie jest możliwy.

Jest możliwy, obserwuje to średnio raz w roku i wyniki otrzymuje podobne. Jedyna różnica jest taka, że nie Ci samy fizycznie ludzie ale zespoły o takim samym lub nie wiele się różniącym składzie.

przypadek lżejszy:
1. klient opisał sam wymagania (czyli troszkę, tabel itp.), rozesłał zapytania, i otrzymał oferty (termin, koszt wykonania, okres gwarancji)
2. wykonano analizę w wyniku której powstały miedzy innymi modele, to jako zapytanie rozesłał klient i otrzymał oferty (termin, koszt wykonania, okres gwarancji)

oferty otrzymane jako odpowiedź na drugie zapytanie przeciętnie 3-5 krotnie niższe

Temat: Ciekawy wynik małych badań stosowania modelowania w...

Jarek Ż.:

Jacek S.:
Aby móc przeprowadzić prawdziwy eksperyment należałoby zapewnić niezmienność parametrów - ci sami ludzie pracujący nad tym samym tematem dwoma różnymi metodami. Najlepiej jeszcze gdyby usunąć wiedzę jaką zespół zdobędzie przy pierwszej próbie. Wtedy można zrobić jakieś porównanie.
Niestety, w przypadku każdej metodyki czy narzędzia taki eksperyment nie jest możliwy.

Jest możliwy, obserwuje to średnio raz w roku i wyniki otrzymuje podobne. Jedyna różnica jest taka, że nie Ci samy fizycznie ludzie ale zespoły o takim samym lub nie wiele się różniącym składzie.

Ale zapewne to są różne projekty? Różny klienci, różna tematyka?
Wpływ ludzi na przebieg projektu jest niestety bardzo znaczący.

Ale skoro masz tego typu dane to jest to już dobra podstawa do zrobienia statystyki

przypadek lżejszy:
1. klient opisał sam wymagania (czyli troszkę, tabel itp.), rozesłał zapytania, i otrzymał oferty (termin, koszt wykonania, okres gwarancji)
2. wykonano analizę w wyniku której powstały miedzy innymi modele, to jako zapytanie rozesłał klient i otrzymał oferty (termin, koszt wykonania, okres gwarancji)

oferty otrzymane jako odpowiedź na drugie zapytanie przeciętnie 3-5 krotnie niższe

To znaczy że w pierwszym przypadku otrzymał odpowiedzi od sensownych wykonawców. Potrafiących prawidłowo założyć potencjalne możliwości ryzyka i przyjąć właściwe marginesy wycen.
Punkt drugi pokazuje że w IT powinniśmy się w końcu nauczyć tego co od dawna działa w innych obszarach inżynierii: wykonawca i projektant są odrębnymi dostawcami i wzajemnie się maja kontrolować. Bo wtedy mamy porządnie zrobiony projekt, który jest też dobrze zweryfikowany i wyszacowany.

Temat: Ciekawy wynik małych badań stosowania modelowania w...

Jacek S.:
Ale zapewne to są różne projekty? Różny klienci, różna tematyka?
Wpływ ludzi na przebieg projektu jest niestety bardzo znaczący.

nie, ten sam projekt jest najpierw wyceniany na bazie "oczekiwań agile" a potem powtórnie, po analizie, na bazie mojej dokumentacji wymagań

Ale skoro masz tego typu dane to jest to już dobra podstawa do zrobienia statystyki

jak mnie najdzie to zrobię ;), na razie nie ma czasu, poprawiam po tych od agile ;)

przypadek lżejszy:
1. klient opisał sam wymagania (czyli troszkę, tabel itp.), rozesłał zapytania, i otrzymał oferty (termin, koszt wykonania, okres gwarancji)
2. wykonano analizę w wyniku której powstały miedzy innymi modele, to jako zapytanie rozesłał klient i otrzymał oferty (termin, koszt wykonania, okres gwarancji)

oferty otrzymane jako odpowiedź na drugie zapytanie przeciętnie 3-5 krotnie niższe

To znaczy że w pierwszym przypadku otrzymał odpowiedzi od sensownych wykonawców. Potrafiących prawidłowo założyć potencjalne możliwości ryzyka i przyjąć właściwe marginesy wycen.

to były bardzo często odpowiedzi od tych samych wykonawców

Punkt drugi pokazuje że w IT powinniśmy się w końcu nauczyć tego co od dawna działa w innych obszarach inżynierii: wykonawca i projektant są odrębnymi dostawcami i wzajemnie się maja kontrolować. Bo wtedy mamy porządnie zrobiony projekt, który jest też dobrze zweryfikowany i wyszacowany.

i tu zgoda w 100%, mój kolega nazywa to dosadniej: każdy wykonawca projekt powinien mieć nad sobą "psa ogrodnika". Ten post został edytowany przez Autora dnia 14.06.13 o godzinie 12:34

Temat: Ciekawy wynik małych badań stosowania modelowania w...

Jarek Ż.:

Jacek S.:
Ale zapewne to są różne projekty? Różny klienci, różna tematyka?
Wpływ ludzi na przebieg projektu jest niestety bardzo znaczący.

nie, ten sam projekt jest najpierw wyceniany na bazie "oczekiwań agile" a potem powtórnie, po analizie, na bazie mojej dokumentacji wymagań

Napisałeś:

Jest możliwy, obserwuje to średnio raz w roku i wyniki otrzymuje podobne. Jedyna różnica jest taka, że nie Ci
samy fizycznie ludzie ale zespoły o takim samym lub nie wiele się różniącym składzie.

Więc zadałem pytanie: "czy to średnio raz do roku" dotyczy tego projektu każdego roku? Raczej nie. Nie restartujecie projektu tylko za każdym razem oglądasz różne projekty?

Ale skoro masz tego typu dane to jest to już dobra podstawa do zrobienia statystyki

jak mnie najdzie to zrobię ;), na razie nie ma czasu, poprawiam po tych od agile ;)

To nawet nie są pewnie wymagania agile tylko "lista życzeń i skarg". Zapewne w postaci takich mniej-więcej zapisów:
"system ma mieć duże okienka"
"i kolorowe ikonki mają być"
"system ma szybko działać"
"system ma działać na infrastrukturze (tu jakieś modele serwerów, routerów itd)"
"system ma zapewniać wsparcie dla procesu oferowania klientów i obsługi zamówień"
"system ma przechowywać pola: (tu detaliczna lista pól jakiegoś wyrwanego z kontekstu obiektu)"
"system ma się integrować z systemem XYZ"
Zgadza się? :)

przypadek lżejszy:
1. klient opisał sam wymagania (czyli troszkę, tabel itp.), rozesłał zapytania, i otrzymał oferty (termin, koszt wykonania, okres gwarancji)
2. wykonano analizę w wyniku której powstały miedzy innymi modele, to jako zapytanie rozesłał klient i otrzymał oferty (termin, koszt wykonania, okres gwarancji)

oferty otrzymane jako odpowiedź na drugie zapytanie przeciętnie 3-5 krotnie niższe

To znaczy że w pierwszym przypadku otrzymał odpowiedzi od sensownych wykonawców. Potrafiących prawidłowo założyć potencjalne możliwości ryzyka i przyjąć właściwe marginesy wycen.

to były bardzo często odpowiedzi od tych samych wykonawców

To tylko potwierdza, że wykonawcy byli sensowni. Potrafili przewidzieć możliwe "wybuchy wymagań" w dostarczonej zbyt ogólnej specyfikacji i je uwzględnili w wycenie (dali duży margines bezpieczeństwa). Gdy dostali dokładniejsze, bardziej szczegółowe wytyczne, czyli umieli określić granice systemu i zmniejszyć margines.

Punkt drugi pokazuje że w IT powinniśmy się w końcu nauczyć tego co od dawna działa w innych obszarach inżynierii: wykonawca i projektant są odrębnymi dostawcami i wzajemnie się maja kontrolować. Bo wtedy mamy porządnie zrobiony projekt, który jest też dobrze zweryfikowany i wyszacowany.

i tu zgoda w 100%, mój kolega nazywa to dosadniej: każdy wykonawca projekt powinien mieć nad sobą "psa ogrodnika".

To niestety długo jeszcze nie przejdzie.

Temat: Ciekawy wynik małych badań stosowania modelowania w...

Jacek S.:

>> mój kolega nazywa to dosadniej: każdy

wykonawca projekt powinien mieć nad sobą "psa ogrodnika".

To niestety długo jeszcze nie przejdzie.

powoli przechodzi ;)

Temat: Ciekawy wynik małych badań stosowania modelowania w...

1) Nie każde badanie musi być statystycznie powtarzalne. Eksperyment jest niewątpliwie ciekawy.
2) Pracując drugi raz nad tym samym, w tych samych warunkach zawsze będziesz znacznie lepszy, bez względu na metodykę.
3) Szukając niezmienności warunków można przyjąć poziom entropii, który jest akceptowalny uznając np. że nie interesuje nas czy programistą jest Kazik fan motocykli, czy Józek rowerzysta - interesuje nas "Programista Java EE z 5 letnim doświadczeniem w tej technologii i 5 letnim doświadczeniem w projektach systemów CRM" wtedy możemy zapewnić niezmienność i przeprowadzić eksperyment dostarczający wartościowych informacji - ja tak odebrałem opisany w cytowanym przez Jarka tekście. Moje doświadczenia sa podobne - zwykle ejstem 2-3 krotnie tańszy i ok 2 krotnie szybszy niż konkurencja, stosujemy MDD i iteracyjno-przyrostowy model wytwarzania, ewoluując wymagania a nie sam kod. Ostatnio w jednym projekcie pozwoliliśmy sobie na olanie tych praktyk na prośbę klienta i wyszedł projekt-kalafior z opóźnieniem ok 40%. W mojej ocenie bez istotnej wartości dodanej dla projektu w tym czasie.