Menu
×
Menu

Archiwum dla Listopad, 2012

Możliwość komentowania Analiza Biznesowa. Wymagania – pozyskiwanie, dokumentowanie, komunikowanie, weryfikacja. została wyłączona

Analiza Biznesowa. Wymagania – pozyskiwanie, dokumentowanie, komunikowanie, weryfikacja.

Opublikowane przez | 28 listopada 2012 | felieton

Analiza Biznesowa. Wymagania – pozyskiwanie, dokumentowanie, komunikowanie, weryfikacja.

Etap analizy biznesowej jest jednym z kluczowych momentów w projekcie informatycznym. Jakość analizy i uzyskanych za jej pomocą produktów w znacznym stopniu determinuje jakość kolejnych etapów realizacji systemu. Niniejszy artykuł przedstawia podstawowe elementy dobrego procesu analizy.

Dowiesz się: Jakie czynniki wchodzą w skład analizy biznesowej; Jakie czynniki wpływają na jakość produktów analizy.

Zadaniem analityka biznesowego jest, najkrócej mówiąc, pozyskanie wymagań dotyczących oczekiwań klienta wobec planowanego systemu oraz takie zamodelowanie i udokumentowanie owych wymagań, by umożliwiały sprawną i poprawną implementację aplikacji. Analityk jest ponadto odpowiedzialny za komunikowanie wymagań członkom zespołu i udzielanie wsparcia merytorycznego wszędzie tam, gdzie jest ono potrzebne – podczas tworzenia kodu czy testowania.

Nie da się przecenić roli analizy biznesowej – szczególnie w przypadku, gdy tworzone jest nowe rozwiązanie (całkowicie nowy system). Samo spisanie wymagań nie wystarcza – owszem, daje wgląd w przybliżony zakres oczekiwań klienta i funkcje, jakie ma dostarczać dany system, ale nie obejmuje zależności pomiędzy poszczególnymi funkcjonalnościami, modułami systemu, nie określa możliwych interakcji z użytkownikiem, ewentualnych wyjątków etc.

Czym jest analiza biznesowa?
Najogólniej rzecz ujmując, analiza biznesowa jest procesem, którego celem jest zidentyfikowanie potrzeb klienta w zakresie funkcjonalności oraz innych biznesowych aspektów dotyczących systemu informatycznego. Zgodnie w wytycznymi BABOK w skład analizy biznesowej wchodzą następujące elementy (…) > czytaj dalej:

 http://sqam.org/magazine/1821-analiza-biznesowa-wymagania-pozyskiwanie-dokumentowanie-komunikowanie-weryfikacja

Możliwość komentowania Testowanie oprogramowania – Praca z zespołem testerów klienta. została wyłączona

Testowanie oprogramowania – Praca z zespołem testerów klienta.

Opublikowane przez | 28 listopada 2012 | felieton

Testowanie oprogramowania – Praca z zespołem testerów klienta. Autor: Karolina Zmitrowicz Zwiększenie efektywności testów przeprowadzanych przez klienta. Niniejszy artykuł przedstawia studium przypadku dotyczącego procesu testowania systemu bankowego w środowisku klienta. Zostaną przedstawione problemy wynikłe w trakcie organizacji testowania oraz czynności przedsięwzięte w celu ich eliminacji i osiągnięcia satysfakcjonującego poziomu współpracy pomiędzy dostawcą oprogramowania a klientem. Dowiesz się: Jakich reguł przestrzegać, aby testowanie nie doprowadziło do katastrofy; Jak poprawić proces testowy, gdy jest już w trakcie realizacji, a rezultaty są dalekie od ideału. Pierwsza część artykułu opisuje podstawowe rodzaje testów zwykle przeprowadzanych przez klienta. W następnej kolejności zostaną przedstawione zalety i wady udostępnienia aplikacji zespołowi klienta z punktu widzenia dostawcy oprogramowania. Trzeci rozdział artykułu jest subiektywną próbą stworzenia pewnego ogólnego schematu postępowania podczas organizacji testowania w środowisku klienta – przedstawia pewne zasady, które powinny być przestrzegane zarówno przez dostawcę, jak i klienta, aby uniknąć w przyszłości potencjalnych problemów. Ostatnia część artykułu to studium przypadku opisujące, w jaki sposób zorganizowano proces testowy w projekcie realizowanym dla zagranicznej instytucji bankowej. Po zapoznaniu się w treścią artykułu, czytelnicy zdobędą wiedzę, w jaki sposób można czerpać korzyści z udostępnienia systemu klientowi oraz zwiększyć efektywność testowania, a także zaufanie klienta zarówno do produktu, jak i samego producenta oprogramowania. Podejmując się realizacji usługi wytworzenia systemu informatycznego, dostawca IT zobowiązuje się do wypełnienia pewnych określonych czynności. Nie tylko musi dostarczyć gotowy produkt w założonym terminie i w ramach określonego budżetu, zagwarantować niezbędne wsparcie przy wdrożeniu systemu i przeszkoleniu użytkowników, ale i powinien przedstawić gwarancję niezawodności i poprawnego działania systemu. Warunkami spełnienia takiej gwarancji są na ogół kryteria wejścia / wyjścia stosowane dla poszczególnych etapów testowania wytwarzanej aplikacji. Dla każdego etapu testowania powinny zostać spełnione nieco inne kryteria. Zapewniają one, iż pewien etap implementacji systemu został ukończony, a jego rezultat zweryfikowany z pozytywnymi wynikami. Mimo obaw i sprzeciwów, związanych z ujawnieniem kondycji aplikacji przed czasem jej oddania do oficjalnych testów akceptacyjnych, wytwórcy oprogramowania coraz częściej godzą się na przeprowadzanie testów aplikacji przez zespół klienta. Zwykle dzieje się tak na życzenia klienta, który pragnie mieć stały wgląd w postęp prac deweloperskich i stan ukończenia systemu. Informacja taka ułatwia planowanie i podejmowanie decyzji dotyczących np. budżetu, daty oddania systemu na produkcję itd. Czasem rozstrzyga też o kwestii “być albo nie być” – kontynuować produkt czy go zawiesić ze względu na mniejsze niż zakładano postępy prac. Niniejszy artykuł przedstawia przykładowy proces testowania przez klienta oraz pokazuje trudności, które można napotkać wspomagając taki proces. Z drugiej strony zostaną ukazane korzyści takiego podejścia i jego możliwy pozytywny wpływ na powodzenie przedsięwzięcia IT (…) czytaj dalej: http://sqam.org/magazine/1822-testowanie-oprogramowania-praca-z-zespolem-testerow-klienta

Możliwość komentowania „Monitorowanie oprogramowania. Lepiej zapobiegać, niż leczyć…” została wyłączona

„Monitorowanie oprogramowania. Lepiej zapobiegać, niż leczyć…”

Opublikowane przez | 28 listopada 2012 | felieton, wydarzenia

„Monitorowanie oprogramowania. Lepiej zapobiegać, niż leczyć…”
Autor: Karolina Zmitrowicz

Coraz częściej instytucje zamawiające usługi informatyczne posiadają własne departamenty IT i pragną w określonym zakresie uczestniczyć w procesie wytwarzania oprogramowania.

Niniejszy artykuł przedstawia najczęściej spotykane z punktu widzenia klienta problemy związane z taką współpracą oraz propozycje rozwiązania czy uniknięcia owych problemów.

Dowiesz się: Jak skonstruować kontrakt z dostawcą, by zagwarantować pożądaną jakość procesu wytwarzania oprogramowania.

Do lamusa odchodzą czasy, w których zamawiający oprogramowanie nie miał pojęcia o jakości procesu i produktu informatycznego i ślepo wierzył w zapewnienia deklarowane w dostawcę IT. Obecnie większość instytucjonalnych klientów posiada własne działy IT, wykwalifikowany personel i świadomość procesów towarzyszących wytwarzaniu oprogramowania. W wielu przypadkach klient wie dokładnie, czego może oczekiwać od dostawcy i w jaki sposób weryfikować produkty projektu. Pracownicy klienta mają wiedzę i doświadczenie z zakresu realizacji projektów IT, technik analizy i testowania – zdarza się, iż równie duże (a nawet większe), niż personel dostawcy oprogramowania. Jednak nie zawsze klient wie, w jaki sposób zapewnić sobie środki i możliwości wglądu w proces produkcji systemu, czy jak egzekwować swoje prawa. W następnej części artykułu czytelnik zapozna się z najczęściej spotykanymi problemami we współpracy klienta z dostawcą IT. (…) czytaj dalej:

http://sqam.org/magazine/1820-monitorowanie-oprogramowania-lepiej-zapobiegac-niz-leczyc

Możliwość komentowania PRACA W ZESPOLE. WIEŻA BABEL – JAK DOGADAĆ SIĘ W PROJEKCIE? została wyłączona

PRACA W ZESPOLE. WIEŻA BABEL – JAK DOGADAĆ SIĘ W PROJEKCIE?

Opublikowane przez | 28 listopada 2012 | felieton, wydarzenia

PRACA W ZESPOLE. WIEŻA BABEL – JAK DOGADAĆ SIĘ W PROJEKCIE?
Autor: Karolina Zmitrowicz

Programiści, analitycy, testerzy, architekci – zespół projektowy to ludzie o różnej specjalizacji, osobowościach, charakterach, którzy w założeniu mają jeden cel – realizację projektu informatycznego. Artykuł przedstawia charakterystykę osób zaangażowanych projekt oraz podstawowe sposoby budowania pozytywnych relacji i zasad współpracy w zespole.

Dowiesz się: Jakie są typy ludzi wchodzących w skład zespołu; O co powinieneś zadbać PM, ustalając zasady współpracy.

Projekt informatyczny to przedsięwzięcie angażujące wielu ludzi skupionych w zespole projektowym. Ludzi o różnej wiedzy, kompetencjach i doświadczeniu – a z drugiej strony o różnych osobowościach, charakterach i podejściu do pracy. Odpowiedni dobór ludzi do zespołu jest jedną z kluczowych czynności w planowaniu projektu – niedobrany zespół może zniszczyć każde przedsięwzięcie, nawet to, o którym można mówić, że z góry skazane na sukces.

Niniejszy artykuł jest nieco żartobliwym i subiektywnym przeglądem typów ludzi występujących w projekcie IT – na przykładzie czterech podstawowych ról (funkcji) powtarzających się zwykle we wszystkich zespołach projektowych. W dalszej części artykułu charakterystyka zostanie uzupełniona propozycjami metod doboru personelu do projektu i takiej organizacji ludzi, by wydobyć ich zalety, a ukryć wady.

Zespół projektowy.

Projekt wraz ze swoim – często bardzo licznym zespołem przypomina Wieżę Babel: grupa ludzi mówiąca różnymi językami, przed którą postawiono wspólny cel, musi w jakiś sposób się dogadać. Od tego, czy znajdą wspólny język zależy, czy uda się stworzyć zgrany zespół, potrafiący wykorzystać wspólny potencjał i osiągnąć cel – czyli zrealizować projekt. Dlaczego twierdzę, że członkowie zespołu mówią różnymi językami? (…) czytaj dalej:

http://sqam.org/magazine/1819-praca-w-zespole-wieza-babel-jak-dogadac-sie-w-projekcie

Możliwość komentowania 10 błędów popełnianych przez testerów została wyłączona

10 błędów popełnianych przez testerów

Opublikowane przez | 28 listopada 2012 | felieton, wydarzenia

10 błędów popełnianych przez testerów
Autor: Karolina Zmitrowicz

Niniejszy artykuł przedstawia podstawowe pomyłki i nieprawidłowości popełniane podczas organizacji i realizacji procesu testowania oprogramowania. Zarówno kierownictwo, jak i sami testerzy potrafią dopuszczać się pewnych błędów, które mogą mieć negatywny wpływ na przebieg projektu, ciągłość i efektywność prac oraz atmosferę w zespole.

Dowiesz się:

– Jakie są najbardziej irytujące praktyki testerów;
– Dlaczego nie każdy powinien być testerem;
– Jakich praktyk unikać testując oprogramowanie, by wprowadzać do projektu chaosu.

Poziom trudności 1

Testowanie określane jest jako „proces sprawdzania oprogramowania w celu zweryfikowania, czy spełnia ono określone wymagania. Jest to również działanie zmierzające do wykrywania błędów”. Zgodnie z tą definicją, testowanie ma na celu wspomóc udoskonalanie produktu informatycznego. Co jednak dzieje się w przypadku, gdy sam proces testowania jest daleki od doskonałości i występują w nim błędy? Jak przekłada się to na jakość pracy i wyniki testów? W praktyce okazuje się, że bardzo łatwo jest popełnić błędy podczas organizacji lub samego wykonywania testów. Niektóre z owych błędów pojawiają się tak często, są powtarzane tak wiele razy przez różnych ludzi, że można określić je mianem klasycznych. Błędy popełniane przez testerów najczęściej wiążą się z następującymi kwestiami: (…) czytaj dalej:

http://sqam.org/magazine/1818-10-bledow-popelnianych-przez-testerow

Możliwość komentowania Wprowadzenie do Domain Driven Design w Javie – sposób na projektowanie złożonych modeli biznesowych została wyłączona

Wprowadzenie do Domain Driven Design w Javie – sposób na projektowanie złożonych modeli biznesowych

Opublikowane przez | 15 listopada 2012 | felieton, wydarzenia

Czy zastanawiałeś się co jest przyczyną rozkładu średnich i dużych systemów? Czy jest on nieunikniony i jest jedynie kwestią czasu? Być może istnieje jakiś sposób na utrzymanie entropii w ryzach? Jednak czy pomocny może być nowy język, nowa specyfikacja serwera, nowy framework webowy, nowy kolor karteczek przyklejanych na tablicy, nowe fancy-japońskie słówko?
Na pewno w jakimś stopniu, ale czy w wystarczającym?

Kontynuuj czytanie »

Możliwość komentowania „Budowanie Zespołu Testerów” została wyłączona

„Budowanie Zespołu Testerów”

Opublikowane przez | 12 listopada 2012 | felieton

„Zgodnie z definicją testowania ISTQB, cele testowania są następujące:
1. Znajdowanie błędów
2. Sprawdzanie zgodności z wyspecyfikowanymi wymaganiami
3. Sprawdzanie odpowiedniości do zastosowań.
Inne definicje słusznie dodają do tego (…)” czytaj dalej  http://sqam.edit.software.sdjournal.pl/magazine/1685-budowanie-zespolu-testerow-wybrane-aspekty

Możliwość komentowania Testowanie to nie klikanie, czyli umiejętności nowoczesnego testera została wyłączona

Testowanie to nie klikanie, czyli umiejętności nowoczesnego testera

Opublikowane przez | 8 listopada 2012 | felieton, wydarzenia

Testowanie oprogramowania wykonywane jest w określonym celu – znaleźć jak najwięcej krytycznych błędów zanim zrobią to użytkownicy. Samo znalezienie błędów nie jest, rzecz jasna, wystarczające, ale to co się z nimi stanie to zazwyczaj już nie nasze zmartwienie…

Kontynuuj czytanie »

Contact Us