Tak, taką książkę można nabyć na Amazonie ;). Streszczenie na stronach sprzedawcy oddaje dobrze jej treść: This book provides a basic, conceptual-level description of engineering management disciplines that relate to the development and life cycle management of a system. For the non-engineer it provides an overview of how a system is developed. For the engineer and project manager it provides a basic framework for planning and assessing system development. Ogólnie książka opisuje podstawowy koncepcyjny etap inżynierii systemów (i nie należy tego utożsamiać tylko z branżą IT). Jest napisana przystępnym językiem,…
"Requirements must be based on facts and real-life scenarios." (wymagania muszą być oparte na faktach i realnych scenariuszach). Więc ile warte są wizje w projektach agile albo wydumane w toku warsztatowych burz mózgów litanie życzeń i pomysłów? Nie tylko moim zdaniem: nie są wiele warte i nie powinny być wymaganiami.
Skróty te oznaczają odpowiednio (w j.ang): Business Process Management oraz Business Process Management Software. Budzą one wiele nieporozumień i niezrozumienia. Pierwsze to "Zarządzanie procesami biznesowymi" rozumiane jako działalność związana z zarządzaniem organizacją. Drugie to "Oprogramowanie [służące] do zarządzania procesami biznesowymi" czyli jakaś aplikacja, której wewnętrzne działanie jest opisane procesami. Ten wpis zapewne wywoła wiele kontrowersji, gdyż opisuję tu przyczyny, dla których moim zdaniem, systemy BPMS nie tworzą wartości dodanej. Nie widzę sensu ich stosowania w wersji "process engine", moim zdaniem nie zastąpią nawet części "typowych aplikacji". Ale po kolei... Niedawno…
Tym razem antykwariat :). Książka leży u mnie niemalże od dnia wydania czyli od roku 2004-go: Podstawy techniczne inżynierii oprogramowania (Dick Hamlet, Joe Maybee, WNT Warszawa 2003). Przypomniałem sobie o niej gdy student poprosił o zalecaną literaturę. Zaryzykuję tezę, że to lektura obowiązkowa każdego analityka biznesowego projektanta (tak, analityk biznesowy to także projektant, odkrywca i projektant logiki biznesowej aplikacji). Książka zawiera cztery części: Inżynieria oprogramowania Wymagania i specyfikacja Projektowanie i kodowanie Testowanie Od razy zaznaczą, że mało tam o "suchym kodowaniu". To była pierwsza książka, która otworzyła mi oczy na inżynierię…
Od 17-go kwietnia mamy wersje 13.1 pakietu Visual-Paradigm (i pełnej wersji dla analityków i projektantów: ArchiMetric). Twórcy pakietu bardzo silnie współpracują z analitykami w wielu krajach (należę do nich ;) ) , zbierają sugestie ale też filtrują je. Cieszy mnie to, że w przeciwieństwie do (jak obserwuję) firmy SPARX (producent Enterprise Architekta), nie wychodzą poza standardy. W VP odrzucają wszelkie formy niestandardowych pomysłów (np. aktor "czas" w Enterprise Architect to kuriozalna, niestandardowa konstrukcja) ale za to implementują sprawdzone pomysły na ergonomie pracy oraz zarządzanie spójnością projektu. Jeżeli to tego dodać zdrowe podejście…
Niemalże każde spotkanie projektowe, na którym omawiane są modele UML, na każdym szkoleniu na temat UML, pojawia się problem o którym pisze Ron Ross (wytłuszczenia moje): Another implication is that concept models and logical data models are clearly distinct. Unfortunately, many people blur the line between them. That?s wrong. A concept model is about the meaning of the words you use, and the business statements you make assuming those meanings. It?s about communication. A logical data model is about how you organize what you think you know about the world…
