Oj

W polibudzianej bibliotece jest z kilkanaście kilo książek o inżynierii oprogramowania. Zdecydowanie nie na moją głowę. Jakby tam była jakaś sensowna książka z opisanymi najpopularniejszymi metodologiami (oczywiście nie do przesady szczegółowo), to ja chętnie, ale takie czytanie tysięcy stron bez celu to nie dziękuję. Jakoś przeżyję będąc ograniczony tylko do znajomości metodologii stosowanych w open source. I tak pewnie będą we mnie wmuszać coś wielkokorporacyjnego na studiach.

A właśnie - umiejętność rozpoznawania przydatnych książek jest właściwie bezcenna. Obok mnie leży kilka kilo książek z czasów, gdy jeszcze nie wiedziałem jak rozpoznawać te przydatne. Np. na kij mi C++ Stroustrupa albo C K&R? Chyba nigdy to tego nie zajrzałem. Na tej zasadzie się zastanawiałem, czy sobie kupić wirtha 'algorytmy+struktury=programy', a może 'rzecz o istocie'? Przejrzałem algorytmy i stwierdziłem, że coś podobnego to ja w domu mam, po prostu omówienie co popularniejszych algorytmów. Jakbym ja miał wydawać pieniądze na omówienie algorytmów, to tylko i wyłącznie na knutha - wtedy przynajmniej bym miał poczucie, że sobie kupiłem encyklopedię z tej dziedziny i mogę do niej zaglądać w razie potrzeby. Za to 'rzecz o istocie' jest bardziej poglądowa (przynajmniej o ile się zorientowałem), teoretyczna, coś co warto wiedzieć nawet jeśli nie jest się w stanie tej wiedzy od razu w jakimś konkretnym celu spożytkować. Bo podstawa to znajomość ogólnych koncepcji - szczegółów konkretnego zastosowania można się zawsze douczyć później.

  1. 1. marcoos

    Oj, będą wmuszać, będą. :)

    /me musiał przeczytać cegłę Yourdona z 1989 r. (oh yeah! nie ma jak *współczesna* wiedza informatyczna! ;))) Dobrnąłem do tylko połowy... :P

  2. 2. marcoos

    ?SYNTAX ERROR.
    READY.
    []

    s/do tylko/tylko do/

  3. 3. m

    1: metodyka to nie metodologia
    2: Agile software development methods - http://www.inf.vtt.fi/pdf/publications/2002/P478.pdf
    3: żeby umieć trzeba czytać i się uczyć
    4: metodyki typu "open-source" to najwieksza bolaczka wolnego oprogramowania (testy, zarzadzanie wydaniami)

  4. 4. D-

    Knuth to może jest encyklopedia, ale właśnie z tego powodu źle się go czyta.

  5. 5. mmazur

    Knuth to nie beletrystyka, żeby się go dobrze czytało - po to jest, żeby można było zajrzeć w poszukiwaniu konkretnej rzeczy, a nie czytać od deski do deski.

    Co do Agile software development methods, to wiem, że to jest, ale mnie interesują właśnie te nieagile. Agile jest dla mnie niejako naturalny, za to borgowe metody z wielkich korporacji, to jest coś, co warto by było poznać. Ale do tego musiałbym mieć właśnie jakiś "Borgish software development methods", a nie czytać niewiadomoile książek z nadzieją, że po ich przeczytaniu będę rozpoznawał poszczególne metody.

    Ja Yourdona mam 'marsz ku klęsce' i jest fajny :)

  6. 6. D-

    No, wiesz... Stroustrup to jakby też nie beletrystyka, a czyta się dobrze.

  7. 7. m

    Metodyki wielkich korporacji sa w zdecydowanej wiekszosci zastrzezone albo platne...

  8. 8. mmazur

    No to przynajmniej poznać frameworki (o ile mnie pamięć nie myli, to RUP jest właśnie takim frameworkiem). Na polibudzie jest chyba nawet dokładny opis COCOMO2, ale mam dziwne wrażenie, że (a) zanudzi mnie to na śmierć i (b) czynniki, jakie się tam uwzględnia przy wyliczeniach, to nie na moją głowę i brak doświadczenia w tego typu projektach.

  9. 9. m

    COCOMO2 to jedna z metod *wyceny* projektu informatycznego. RUP to nie framework, a metodyka. Frameworkiem jest Struts, Spring...

  10. 10. m

    btw, nikt już nie stosuje COCOMO

  11. 11. mmazur

    Wiem co to COCOMO2. Nikt nie stosuje COCOMO, czy nie stosuje COCOMO2? (a jeśli obu, to co się w takim razie stosuje?)

  12. 12. mmazur

    Chwila moment. Nie chodziło mi o framework as in plone, struts, czy spring, tylko zestaw klocków, które można użyć do stworzenia... erm... zasad działania konkretnego projektu (nie w sensie technicznym, tylko organizacyjnym). Wnioskuję, że właśnie coś takiego się nazywa metodyką.

  13. 13. m

    1) metodyka to niezupelnie zestaw klockow organizacyjnych - nie ma co samemu wymyslac, lepiej przeczytac: http://en.wikipedia.org/wiki/Methodology_%28software_engineering%29

    Typowy kompleksowy zestaw klockow (technologicznych) to chocby Microsoft Application Building Blocks - nota bene bardzo fajna idea, zerknij na to. No i trzeba odroznic metodyki biznesowego zarzadzania projektem informatycznym (jak prince2) od technicznych metodyk prowadzenia projektu (jak USDP czy RUP) - te pierwsze sa nieobecne w projektach nie-zupelnie-biznesowych takich, jak typowe open-source (to drugie zreszta tez, bo trudno mowic o konsekwentnej realizacji wytycznych danej metodyki...).

    2) Wiekszosc firm wytwarzajacych oprogramowanie na zlecenie nie moze nawet myslec o stosowaniu COCOMOx do wyceny zewnetrznej realizowanych projektow, bo ten model nie pozwala na oszacowanie kosztow na starcie projektu, a dopiero w fazie design. Stosuje sie zwykle wycene przez analogie wspartej wycena przez ekspertow w polaczeniu z wycena dla wygranej. Nie znam firmy, ktora stosowalaby jako glowna metode wyceny samo COCOMOx.

  14. 14. mmazur

    http://en.wikipedia.org/wiki/Rational_Unified_Process

    "It describes how to deploy software effectively using commercially proven techniques. It is not a process but a process framework or meta-model."

    Ja przeważnie pamiętam co czytam :) (stąd mi się wziął ten framework)

    Hmmm. Biznesowe są kompletnie oddzielone od technicznych? (as in można sobie wziąć taki biznesowy i dokleić do takiego technicznego?)

    Co do COCOMO, to dla mnie w ogóle niepojęte jest jak można w miarę dokładnie przewidywać czas trwania projektu programistycznego, skoro to jest tak bardzo nieliniowy proces. A bodajże w Mitycznym Osobomiesiącu czytałem, że COCOMO pozwala określić czas w zasięgu 30% rzeczywistego w 80% projektów.

  15. 15. rk

    SYSTEM ERROR
    OK

Adde commentarium: (textile lite)