http://www.modernanalyst.com/Resources/BusinessAnalystHumor/tabid/218/Default.aspx?ArticleType=ArticleView&ArticleID=2471
źr. http://www.modernanalyst.com/Resources/BusinessAnalystHumor/tabid/218/Default.aspx?ArticleType=ArticleView&ArticleID=2471

Zwinna analiza biznesowa to mit czy fakt?

Agile business analyst has the capability to keep the wheel rolling. They?re a transformative funnel through which a requirement passes down to the delivery path towards an expected outcome. This SDLC machine needs continuous fuel in the form of well-defined and informed information which is provided by an agile business analyst. As long as an agile business analyst does the job, this machine will remain on its course to deliver greater solutions.Coming to our original question, is an agile business analyst a myth or a reality? There is a clear…

Czytaj dalejZwinna analiza biznesowa to mit czy fakt?

Znaczenie ma nie wielkość projektu, a cykl jego życia…

Powyższe nasuwa od razu kolejny wniosek: zamawiający najczęściej formułują zapytania w sposób pozwalający dostawcom składać oferty na pierwszy etap, polegający tylko na dostarczeniu i wdrożeniu. Jak widać z zasady wygrywają tu projekty "na żywioł". Żądanie od dostawców ujęcia kosztów utrzymania (tak zwany "maintenance") niczego nie zmienia bo to tylko stała oplata administracyjna. Jedynym sposobem na rzetelne porównanie ofert jest operowanie kosztem cyklu życia dostarczonego produktu.

Czytaj dalejZnaczenie ma nie wielkość projektu, a cykl jego życia…

Słabości tradycyjnych metod wytwarzania IT – czy na pewno słabości?

A co mówią statystyki?Analysts report that as many as 71 percent of software projects that fail do so because of poor requirements management, making it the single biggest reason for project failure?bigger than bad technology, missed deadlines or change management fiascoes. ( źr. Fixing the Software Requirements Mess CIO.com).Parząc na powyższe (wytłuszczenie: w większości z ponad 71% złych projektów programistycznych, powodem kłopotów było złe zarządzanie wymaganiami, co czyniło większe szkody niż pozostałe powody, takie jak technologie, napięte terminy czy zarządzanie zmianami, razem wzięte). Tak więc zastanówmy się czy aby na pewno brak projektu i specyfikacji wymagań to dobry sposób na projekt IT. Czy metody wytwarzania bazujące na braku pierwotnego projektu, faktycznie są zbawieniem projektów programistycznych... Dodam na koniec, że powyższe dotyczy w takim samym stopniu systemów dedykowanych jak i gotowych a wymagających "kastomizacji" bo to (nowe funkcjonalności systemu) także projekt dedykowany.

Czytaj dalejSłabości tradycyjnych metod wytwarzania IT – czy na pewno słabości?

Koniec treści

Nie ma więcej stron do załadowania