AS Analiza - Anna Sędek

Dziś połączymy odpowiedź do trzech pytań z listy 99 😊 Proszę napisać wymganie w formie user stories.  Proszę zapisać wymaganie w formie przypadku użycia. Czym są sytuacje wyjątkowe w opisie przypadków użycia ? No to może zanim zabierzemy się za konkretną odpowiedź, musimy wiedzieć (chociaż tak pokrótce), czym jest User Stories , a czym Use Case . User Stories (US) – inaczej historyjki użytkownika (po angielsku zawsze lepiej to brzmi), są krótką notatką z konwersacji/wywiadu na temat działania systemu. Dzięki User Stories doprecyzowujemy wymagania z rozmowy z klientem. Tylko pamiętajmy, że nie są one po to, aby szukać winnych w razie ewentualnych niedomówień i nie powinny stanowić dowodów w „kwitach” na naszych klientów 😉. [2] User Stories mają w sposób syntetyczny opisywać warunki, jakie powinny zostać spełnione z perspektywy użytkownika i cel, w jakim ta funkcja ma zostać przygotowana.  (definicję tę znalazłam w kursie Specjalistów Analizy )[3]. Ważne...

Na czym polega model V ?   Nie wiem czy gdzieś wcześniej o tym pisałam, ale jestem słuchaczką na studiach „ Analityk, profesjonalista na styku IT i biznesu” gdzie uczę się o swoim wymarzonym zawodzie w super wyidealizowanym środowisku akademickim 😉  W programie przewidziany został przedmiot o wdzięcznej nazwie „Role Analityka” prowadzone przez pana Jerzego Leyka (cudowny człowiek, od którego czerpie mnóstwo inspiracji). To właśnie on ciągle nam kładzie do głowy, że te wszystkie BPMNy, UMLe to jest pikuś w porównaniu do zarządzania ludźmi i próby budowania z nim poprawnych relacji, ale dziś nie o tym 😉 Na dzisiejszym wykładzie omawialiśmy planowanie podejścia analizy biznesowej z wykorzystaniem „metodyk ciężkich”, ja wcześniej spotkałam się z nazwą „metodyki tradycyjne”, ale te „ciężkie” dużo bardziej do mnie przemawiają 😉 Czym, że jest ta „ciężka metodyka” ? A no niczym innym jak dobrze wszystkim znany wodospad, watterfall, kaskada czy jak tam chcecie ...

Dziś kolejny post z cyklu, zaczytane w portalu zza wielkiej wody 😉 link do całej treści znajdziecie tutaj Artykuł dotyczy …. Empatycznego tworzenia nowych produktów… … tak tak, EMPATYCZNEGO 😊 I już widzę minę każdego programisty/osoby, która bardzo twardo i rzeczowo podchodzi do swoich zadań. Uniesiona brew, wykrzywione w grymas usta wyrażające superdezaprobatę i bajkowa chmura nad głową z wielkim znakiem zapytania i trzema bardzo znaczącymi literami WTF?!   I prawdę mówiąc, mimo, że nie jestem istotą twardo stąpającą po ziemi, to w pierwszej chwili pomyślałam no oni chyba nie mają już o czym pisać na tym „habeerze” 😊 Ale z babskiej ciekawości postanowiłam sprawdzić o co tak naprawdę chodzi i rozwiać to bajkowe chmurzysko 😊 Pomyślmy, czym tak naprawdę zajmuje się analityk ? Pisze opasłe dokumentacje, tworzy diagramy, uzgadnia harmonogramy, wdraża metodyki, organizuje spotkania, analizuje ryzyka, zmiany, zarządza backlogiem,itd., itp....

Kolejny post z cyklu przygotowań do certyfikatu REQB Coś jest w tym tytułowym cytacie 😉 Czy warto jest analizować ryzyko ? czy w ogóle jest to komuś do czegoś potrzebne ? Mam nadzieje, że większość osób, która czyta to pytanie, odpowie sobie NO JASNE, ŻE TAK! 😉 a skoro już wiemy, że warto to zastanówmy się jak do podejść do tego tematu. Jeśli po raz kolejny w swoim projekcie usłyszysz stwierdzenie, że coś się wywaliło ze znanych wszystkim przyczyn albo czegoś można byłoby uniknąć gdyby… to oznacza, że ktoś nie odrobił poprawnie swoich zadań pracowych – ktoś, a konkretnie Ty Analityku! Ale tak szczerze, z ręką na sercu, pracując w nawale różnych projektów, zadań, zadanek czy ktokolwiek się przejmuje czymś takim jak „ryzyko”. Śmieszki powiedzą „jest ryzyko, jest zabawa” ale myślę, że Biznes nie będzie zadowolony jak przez błąd Pani Analityk (Pana Analityka) straci swoje pieniądze, reputację albo znaczną grupę klientów. Od czego należałoby zacząć? Od Ide...

Dziś trochę o przygotowaniach do certyfikatu z Inżynierii Wymagań REQB. Dlaczego Inżynieria Wymagań ?, bo od tych nieszczęsnych wymagań wszystko się zaczyna. 😉 Źle zdefiniowane wymaganie będzie się mścić przez cały okres trwania projektu, dlatego tak ważne jest, żeby znać i umieć stosować metodyki związane z poprawnym definiowaniem i zarządzaniem wymaganiami. Z pomocą biegnie Inżynieria Wymagań! Uznałam, ze skoro i tak dużo o tym czytam to poprzygotowywuje się do certyfikatu REQB. Egzamin REQB (Requirements Engineering Qualification Board) jest przeznaczony dla osób, które pracują z wymaganiami na systemy informatyczne. Wiedza, którą należy posiadać, aby móc podejść do egzaminu obejmuje  Sylabus znajdujący się na stronie reqb.pl Zagadnienia, z którymi możemy się „spotkać” w trakcie egzaminu to: Podstawy inżynierii wymagań Proces inżynierii wymagań Pozyskiwanie wymagań Analiza i modelowanie wymagań Specyfikacja i opis wymagań Walidacja wymagań ...

Hm, jak można się doszkalać, uczyć i zdobywać nową wiedzę z związaną z Analizą ? Metod jest kilka: Czytanie - książek i artykułów branżowych jest całe mnóstwo, więc jest w czym wybierać; Śledzenie blogów - i tu nie skupiałabym się tylko na blogach związanych stricte z analizą – chociaż te oczywiście warto podglądać. Wg mnie należy poznać inne punkty widzenia związane z pracą nad konkretnym rozwiązaniem. Myślę, że przemyślenia developerów i testerów są bardzo dobrą wskazówką, do prowadzenia prac analitycznych. Pamiętajmy, że te wszystkie dokumenty, wykresy, diagramy czy zestawienia później trafiają w ich ręce i warto je tworzyć tak, żeby były dla nich użyteczne; Studiowanie – ja osobiście postawiłam na studia podyplomowe prowadzone przez SGH. Jak wejdziecie na stronę uczelni to w zakładce studiów podyplomowych znajdziecie całą masę różnych, ciekawych kierunków, które pomogą w dalszej pracy zawodowej ( mi pomagają, nawet bardzo ); Uczenie kogoś – na warsztatach z co...

Wymień znane Ci rodzaje analiz.  Odpowiedź nie jest jakaś super rozbudowana, bo mamy tylko wymienić rodzaje analiz, więc nie ma co tu za dużo się rozwodzić 😉 Kolejność jest zupełnie losowa. ü   Analiza porównawcza ü   Analiza reguł biznesowych ü   Analiza decyzji ü   Analiza dokumentów ü   Analiza interfejsu ü   Lesson Learned Process ü   Analiza wymagań niefunkcjonalnych ü   Analiza ryzyka ü    Analiza śledzenia zmian ü    Analiza ü    Analiza potrzeb ü    Analiza przypadków użycia ü   Analiza SWOT ü   Analiza przyczyn ü   Burza Mózgów ü   Modelowanie ü   Prototypowanie Jedną z analiz, na którą warto zwrócić szczególną uwagę to Analiza SWOT ( warto zwrócić uwagę, ponieważ pojawia się na „liście 99”).  W jaki sposób wykonuje Pani analizę SWOT Znalazłam bardzo dobry artykuł, który super dokładnie opisuje jak należy pod...