Category Archives metodyki wytwarzania oprogramowania

W 2009 roku zamieściłem linki do metodyk online. Dziś robiłem drobne porządki i stwierdziłem, że linki są nieaktywne. Zaktualizowałem je w poście z 2009 roku oraz dodałem Agile Business Rule Development Scrum OpenUP Extreme Programming Agile Business Rule Development Uwaga zdarza się, że niektóre przeglądarki nie otwierają tych metodyk. Firefox sprawia najmniej problemów. Miłego korzystania :)

Koniec roku pozwala mi wreszcie odetchnąć. Ostatnie tygodnie były mega pracowite. To czym chcę się pochwalić to fakt iż w tym roku udało się opracować dedykowane metodyki prowadzenia projektów w Enterprise Architect. Odbiorcami tej dedykowanej usługi były bank, duży ubezpieczyciel oraz firma wytwarzająca oprogramowanie. Każdy z opracowanych metodyk była spersonalizowana pod kątem klienta. Każda z nich czerpała z moich wcześniejszych…

W czasie ostatnich wyborów, jeden z uczestników spotkania wyborczego zapytał: “Jak żyć Panie Premierze?” Przekładając na grunt modelowania często słyszę: “Jak modelować?”. I o ile daleko mi do Premiera i jego problemów dot. rządzenia krajem, tak blisko mi do problemów z modelowaniem. Otóż UML zna już sporo osób. Nieformalnym standardem w zakresie narzędzi jest Enterprise Architect, który jest używany Problem…

Ostatnio zaniedbałem wpisy dot. moich działań szkoleniowych i konsultingowych. Stało się to przede wszystkim przez produkty: MANEA (MANEA – Mantis Bug Trucker i Enterprise Architect) oraz TORMIGO (Tormigo wersja beta), oraz brak czasu związany ze wspomnianymi działaniami. Zacznę od ostatnich większych projektów, których wspólnym mianownikiem jest branża ubezpieczeniowa. W jednej firm zajmowałem się przygotowaniem a raczej adaptacją znanych metodyk wytwórczych…

Architektura zorientowana na usługi to naturalny krok ewolucyjny od podejść zorientowanych obiektowo (OO), proceduralnych oraz dano-centrycznych stosowanych we wdrażaniu rozwiązań.

Fundamentalnymi zasadami rządzącymi SOA są:

  • Wiadomości wymieniane pomiędzy uczestniczącymi systemami muszą być opisowe a nie instruktażowe, ponieważ system informatyczny świadczący usługę odpowiedzialny jest za wszelkie problemy. Komunikaty opisowe podają informacje o usłudze oraz o powiązanych z nią danych wejściowych i wyjściowych. Usługodawcy odpowiedzialni są za wskazówki; stąd też potrzeba na komunikaty instruktażowe nie istnieje.
  • Słownik oraz struktura komunikatów muszą być zrozumiałe przez wszystkie strony. To powszechne zrozumienie przez wszystkie strony wymaga ograniczenia słownictwa oraz struktury komunikatów, ale jest koniecznością dla skutecznego komunikowania.
  • Struktura komunikatu powinna być rozszerzalna.

Bardzo się cieszę, że po kilku latach "ukrywania" w płatnych wersji metodyki Rational Unified Process (RUP) IBM uwolnił ją publikując bezpłatną jej wersję zwaną OpenUP - Open Unified Process. Open Unified Process (OpenUP) jest częścią szablonu procesów Eclipse'a Eclipse Process Framework (EPF) o którym pisałem kilka dni temu. Można powiedzieć, że proces OpenUP jest bratem procesu RUP. Z dokumentacji procesu…

Na początku lat 90-tych dwaj programiści: Kent Beck i Ward Cunnigham zdefiniowali kilka praktycznych reguł, które miały za zadanie uprościć proces wytwórczy oprogramowania. Tak powstała jedna z najbardziej kontrowersyjnych metodyk: Extreme Programming (XP)

Dla wszystkich zainteresowanych zamieszczam 12 praktyk XP wg Kenta Becka:

Close