poniedziałek, 20 lutego 2017

Zrozumieć IT dla nie-informatyków

Propozycja kolejnych seminariów PTIW - proszę o uwagi kontakt@requirements.org.pl

Agenda szkolenia:

  • Od Ady Lovelace przez Turinga do Gates'a, Jobsa i Zukerberga
  • Jak działa procesor?
    • Lampy elektronowe, druciki, magistrale i układy scalone
    • System dwójkowy, bity, bajty, kilo, kilo, mega, giga i tera
    • Instrukcje procesora
  • Jak działa komputer?
    • Przetwarzanie i pamięć (PROM, RAM, dyski)
    • Hardware (platforma sprzętowa) a oprogramowanie
  • Jak działa oprogramowanie?
    • Program, oprogramowanie, aplikacja
    • System operacyjny, API, sterowniki
    • Graficzny interfejs użytkownika
    • Wiele programów jednocześnie?
  • Jak tworzy się oprogramowanie?
    • Języki programowania - kod źródłowy
    • Od kodu źródłowego do instrukcji mikroprocesora
      • Kompilacja
      • Łączenie
      • Ładowanie do pamięci i uruchomienie
    • Różne tryby tworzenia i działania: na przykład HTML, Java Script, Java i C++ (tak, to są bardzo różne rzeczy)
    • Typy języków oprogramowania - i o co chodzi z tą obiektowością?
  • Jak komputer nadzoruje działanie pralki, czyli tak zwane systemy wbudowane, albo kontrolne
    • Niewidzialne systemy krytyczne dla bezpieczeństwa - sprawa życia i śmierci
  • Podstawy Internetu
    • Przeglądarka
    • HTTP
    • HTML i inne języki znaczników
    • Wyszukiwarki
    • Domeny, URL oraz IP
    • CSS, PHP, WordPress, Joomla?
    • Portale, blogi, fejsbuki i to wszystko
  • Usługi w chmurze, usługi internetowe, usługi mobilne i różna Androidy
  • Oprogramowanie a projekt informatyczny - trudna przyjaźń
  • Informatyka, elektronika, matematyka, IT, programowanie, komputery, sieci
  • Mody w świecie komputerów
  • Psychologia w IT
  • Te wszystkie straszne nazwy: Ruby, Apache, Cucumber, Joomla, Hadoop... jak się w nich nie pogubić?
  • Bugi i błędy - skąd się biorą?
  • Tak zwane testowanie, czyli łapanie bugów - jak to się odbywa?
  • Wsparcie i utrzymanie oprogramowania - z perspektywy programisty i z perspektywy klienta
  • Deweloper, architekt, inżynier, betoniarz-zbrojarz, hydraulik i murarz - kim są w IT?
  • Co będzie dalej?

niedziela, 19 lutego 2017

Discussing REQB mock exam questions



Hi All,

On 17.02.2017 07:40, […] wrote:

Hi Bogdan
I was wondering if you may help us because in one of the exams I found some different answers. You remember that I had the exam from Swedish board and also answers that I found on the Internet and in some cases the answers differ with yours, could you please double check these?

Thanks

_____________________________________________________________________
(13) Which of the following activities would primarily help to improve the quality of a Requirements Specification in an initial state?

a)  Make the specification formal as early as possible to avoid disturbances that can jeopardize the quality

b)  Executing System Test as early as possible to find discrepancies between stated requirement and actual outcome.
c)  Set clear statements of what a system should do rather than how it should do it

d)  Leave the development constraints to next phase, so they do not affect requirements quality

I have answer C here

"C" may have two meanings (and we do not know which one the question author had in mind):
  1. "what" = functional requirements, "how" = non-functional requirements;
  2. "what" = requirements, "how" = design, planned implementation details.
Whichever interpretation you choose, it cannot be "C": "1" is wrong (the syllabus rightly states that non-functional requirements are equally important as functional ones), and "2" is generally right, but not in any way specific for "an initial state" (regardless of whether "initial state" means early requirement's version, or early project stage).
Therefore, the right answer is "A", because "B" and "D" are impossible and wrong. However, some doubt may appear because in several places in the syllabus they say full formality is not always required nor preferable, but on the other hand, it states in many places that "early formal acceptance" is a good thing (please run "<Ctrl-F> formal" on the syllabus to check it).

_____________________________________________________________________

(15)   Which of the following will probably cause most problems when handling requirements?

a.    Prioritization of the requirements
b.    Too formal formulations
c.    Planned changes to requirements
d.    The fact that requirements are feasible

I have answer B here 

"B" is 100% wrong for two reasons: you seldom have problems with excessively formal description (the opposite is true - requirements specifications are commonly too vague), and even if they were too formal, the problem would be mild compared to prioritization problems. The syllabus says much on both subjects (check it, using " priori" and "> formal") but it does not say much on the relative levels of difficulty, sorry.

_____________________________________________________________________

(21)  Which one of the following is a main activity within the process Requirements Elicitation in Requirements Development

a)  Detailing known high-level requirements
b)  Defining and maintaining traceability of requirements
c)  Developing models of the business solution
d)  Elaborating business requirements into system/solution

I have answer A here (Syllabus mentions the answer A, the answer B belongs to Requirement Analysis) 

You and your answer is right! My mistake, SORRY! ("right" in the sense "according to the syllabus").


_____________________________________________________________________
 
(27) Which of the following statements about solution models is NOT correct?

a)  They serve as the basis for system design
b)  They are designed in parallel with the requirements model
c)  They describe various views of the system
d)  They serve as the basis for the estimate of work effort

I have answer D here.

Requirement models "serve as basis for the solution model" (syllabus, page 75), so they cannot be designed "in parallel" (i.e. simultaneously) - ergo, "B" is wrong (i.e. the right answer).

Both types of models [in reality, there is seldom any practical difference, but yes, you should forget about the reality as I told you] are basis for work effort estimation - first, requirements models, and solution models later on.

However - sorry for this! - in the next section on the same page the syllabus says that the "[business] solution model serves as a basis for the solution design". This is correct of course: solution model serves both as a basis for the solution design and for the work effort estimate.

So - yes - from these two sections the question author may have come to the (very wrong) conclusion that solution models are not used for work effort estimate. Hence their answer "D" here . Linguistics and psychology!


_____________________________________________________________________
 
(35)      Which of the following statements about requirements traceability is MOST correct [important]?

a)  It is extremely important to label requirements precisely in order to ensure good traceability

b)  Traceability provides a check on whether all requirements have been labelled precisely.

c)  The aim of traceability is to label interrelationships within a project precisely enough in order to comply with the requirements

d) Traceability is important to keep requirements stable and to ensure that they cannot evolve


I have the answer A here 

Concerning "A": the syllabus says "in order to ensure good traceability, it is important to label the requirements uniquely"; on one hand, the word "extremely" is excessive (both in reality and according to the syllabus") and the crucial word "unique" is omitted. So "A" is not fully correct nor the MOST important aspect of traceability.

The MOST important aspect (and, hopefully, the "MOST correct" answer according to the unusual figurative stylistics of this question) is its GOAL - to identify (and label) the interrelationships (between requirements and other artefacts) - therefore, the answer should be "C".

"B" and "D" are incorrect ("D" is simply WRONG, and "B" is very week).

_____________________________________________________________________
 
(36)      Which of the following statements about metrics is MOST correct [important]?

a.    Metrics must always be set in relation to reference data
b.    It is important to ensure that all metrics are selected

c.    Metrics in Requirements Engineering allow a qualified statement about the quality status of the system

d.    The lower the requirement rating, the greater the risk for the project

I have answer A here ( Syllabus also mentions here a similar answer) 

"A" is very true but very trivial, in the same sense as, for example, a sentence "Metrics is defined by the measurement scale it uses" is. True, but so what? "C" is the main GOAL of using metrics - to be able to "make quantifiable statement about project status and quality" (the preceding statement in the syllabus). And of course "quantifiable" metrics (the syllabus" makes the statement more "qualified" (the question). Quod erat demonstrandum.

_____________________________________________________________________
 
(40)  How exactly do process maturity models prescribe Requirements Engineering?

a)    CMMI and SPICE prescribe Requirements Engineering procedures
b)    CMMI and SPICE contain Requirements Engineering techniques

c)    CMMI and SPICE prescribe what Requirements Engineering must deliver, but not in detail how it is done

I have answer C here 

"B" is wrong (these maturity standards do not specify specific techniques), and "A" and "C" are both right: these standards tell us what [results] RE must deliver and how RE comes into development processes [RE procedures]. The choice is arbitrary. My choice of "A" rather than "C" is based on the assumption that "A" is more general and "C" is too detailed.

Summary: so what now? The problem is, you can almost never be 100% sure what the right answer is, because it depends on what a question author has in mind, and the questions are (like bad requirements) not sufficiently detailed to decide this! So guesswork and learning the way authors may think is the key to success here. Of course, you need to learn to guess what exam questions' authors think, and not Bogdan Bereza thinks . In this case (the SEQB questions) their authors must be Beata Karpinski and Ingvar Nordström. How probable is it that they are as well the authors of (some) real exam questions? I do not know.

Of course, there is as well some probability that certain answers in the "official" answer sheet are simply typing mistakes - this happens as well.


Please let me present you the uncensored version of the slide how these questions are created:
  • The question author takes a random piece / section of the syllabus and finds in it some complex / dubious / hard to remember statement.
  • The author rips this statement out of its context and changes a word or two in it.
  • This doctored statement becomes the "correct" answer, and three more statements are added to it (often sensible, but not from the syllabus)
  • To defeat such questions, the counter-measure it to read the syllabus slowly a few times (it is painful, but not deadly)
Cheers, Bogdan

Metody projektowania przypadków testowych

Krótki przegląd metod (albo nawet: metodyk) projektowania testów. Jak to jest naprawdę? I jak wykłada to ISTQB?










niedziela, 12 lutego 2017

Nowiny IREB CPRE

Dobry wieczór.

W roku 2016 łączna liczba egzaminów IREB CPRE wzrosła - w porównaniu z 2015 - o 11% i wyniosła 7,094 - tak, w ciągu roku do egzaminów IREB CPRE podeszły 7,094 osoby (więcej statystyk).

Szczególnie wyraźny był wzrost egzaminów na certyfikaty zaawansowane - o 36%, choć ich łączna liczba nadal nie jest imponująca 298 egzaminów.

Odbyły się 584 szkolenia podstawowe i 54 zaawansowane (22 "pozyskiwanie i konsolidacja wymagań", 15 "modelowanie wymagań" i 17 "zarządzanie wymaganiami").

Wkrótce będzie dostępny certyfikat podstawowy RE@Agile, a w połowie 2017 roku - także poziom zaawansowany RE@Agile oraz poziom ekspercki. Czeka nas bardzo ciekawy rok!
Pozdrawiam, Bogdan Bereza

piątek, 10 lutego 2017

Miary jakości w IT

"Książkę Andrzeja Kobylińskiego można polecić inżynierom jakości i testów, bo przecież testy są jednym z najważniejszych narzędzi pomiarowych w IT."
  • Andrzej Kobyliński "Modele jakości produktów i procesów programowych", Warszawa 2005, SGH w Warszawie, ISSN 0867-7727 [nakład wyczerpany]
Napisałem to w... 2005 roku. Nadal aktualne, może nawet bardziej niż wtedy, bo szarlataneria, zastępująca dobre miary wiedzą tajemną i społeczną wyczuwką wciąż nabiera śmiałości i tempa.
 
Miary często kojarzą się nam z czymś pozytywnym: mówi się umiarkowany, miarkować, znać miarę, na miarę czy miarowo. Z drugiej strony, brak miary też chwilami brzmi obiecująco, jak w słowie bezmierny. Miary są niebezpieczne dla tych, którzy usiłują coś ukryć, wolą mętniactwo i niejednoznaczność od precyzji.
  
Miary trzeba dobrze rozumieć, tak więc niektórym ludziom miary wydają się niebezpieczne; według Flawiusza to Kain wynalazł "miary i wagi, zmienił ową niewinną i szlachetną prostotę, w jakiej żyli ludzie, póki ich nie znali, w życie pełne oszustwa" (Józef Flawiusz, "Starożytności żydowskie").
  
Miary, które znamy na co dzień, wydają się oczywiste, ale nie ma nic oczywistego w tym, aby od prostego "zimno", "średnio" i "ciepło" przejść do skal, gdzie wartości liczbowe przypisywane temperaturze powietrza odnoszone są do długości słupka rtęci zamkniętej w szklanej rurce. Fakt, że istnieją trzy różne, powszechnie stosowane skale temperatury: Fahrenheita, Celsjusza i Kelvina, z których każda ma punkt zerowy przy innej temperaturze, a dwie pierwsze różnią się rozmiarem jednostki skali, wskazuje, że miary nie są niczym oczywistym, że są przyjmowanym częściowo arbitralnie sposobem odwzorowania natężenia pewnych atrybutów rzeczywistości - brzmi to wszystko bardzo naukowo, ale ma konkretny, praktyczny sens.
   
Inżynieria - zestaw zdefiniowanych, powtarzalnych technik projektowania, wytwarzania i utrzymania rozmaitych rzeczy, nie może istnieć bez pomiarów. Trudno wyobrazić sobie inżyniera, który nie umie mierzyć długości, ciężaru, napięcia czy natężenia, albo lekarza bez termometru i narzędzi do precyzyjnego pomiaru chemicznego składu krwi. Tymczasem tylko inżynieria oprogramowania choruje na brak umiejętności pomiaru nie tylko własnych procesów, ale nawet produktów!
      

Zapyta ktoś - jakie to ma znaczenie? Czyżby coś bardzo złego działo się z przemysłem informatycznym, podczas gdy gołym okiem widać, że dzieje się całkiem dobrze?
  
Wiele zależy od tego, w odniesieniu do czego jest to "dobrze". W porównaniu z przemysłem elektronicznym przyrost wydajności w produkcji oprogramowania jest od wielu lat skromny. Produkty programistyczne często okazują się zawodne, a spektakularne niepowodzenia projektów informatycznych - jak np. osławione dwuletnie opóźnienie oddania do użytku lotniska w Denver w 1995 r. z powodu przekroczenia terminu dostawy oprogramowania systemu bagażowego - przechodzą do legendy. Wielkie jest zróżnicowanie produktywności programistów w różnych firmach i projektach - według niektórych danych różnice wynoszą nawet 600:1 (słownie: sześćset do jednego, to nie jest błąd w druku).
   
"Nasze najnowsze metody gwarantują 100% wzrostu produktywności", "użycie narzędzi pozwoli skrócić testowanie o 2/3" - przykłady gołosłownych twierdzeń i sloganów w branży IT można dowolnie mnożyć.

Czego nam brakuje, by móc przeciwstawić wiedzę próbom manipulacji? Systematycznego stosowania pomiarów i dostępu do ich wyników.

Planowanie projektów informatycznych okazuje się w praktyce niejednokrotnie zwykłym wróżeniem z fusów. Jak oszacować pracochłonność projektu produkcji oprogramowania, którego wymagania są opisem słowno-muzycznym? Niełatwo na takiej podstawie oszacować wielkość produktu, np. w formie liczby linii kodu, a nawet mając do dyspozycji takie oszacowanie, nie ma prostej i godnej zaufania metody, aby przełożyć je na liczbę koniecznych "osobodni".

Brak umiejętności mierzenia powoduje, że jakiekolwiek dyskusje porównujące zalety i wady różnych metod, technik, języków programowania i modelowania cierpią na chroniczną dowolność, na odwoływanie się do anegdotycznych, statystycznie nieistotnych przykładów. Nie umiejąc mierzyć przebiegu projektów, nie umiemy na dobrą sprawę nimi zarządzać. Intuicja, objawienia - wszystko to bardzo ciekawe metody, wszakże pod warunkiem, że uzupełniają proces decyzyjny i przewidywania oparte na pomiarach, a nie usiłują je zastępować.

Zarządzanie ryzykiem staje się fikcją, jeśli ani nie potrafimy zagrożeń zidentyfikować, ani oszacować kosztów zapobiegania, ani ocenić ich prawdopodobieństwa. W opublikowanym artykule napisałem, że "w przemyśle informatycznym chętnie udajemy Kierowców Formuły 1 oraz dzielnych Przewodników, nie mając niezbędnych po temu umiejętności mierzenia".

Jak nauczyć się trudnej sztuki wykonywania i analizy wyników pomiarów? Jak nie dać się w przyszłości zagadać elokwentnym zwolennikom Jedynie Słusznej Drogi, czy będzie nią czysty Brak Procedur, czy ISO 9000, czy CMM, czy cokolwiek innego?

Doskonałym, praktycznym przewodnikiem jest wydana w 2005 roku książka dr Andrzeja Kobylińskiego z SGH pod niezbyt chwytliwym marketingowo tytułem "Modele jakości produktów i procesów programowych" - pewnie lepiej byłoby ją nazwać "Informatyk mierzy".
 
Pierwszą podstawową zaletę omawianej książki dla praktyków informatyki stanowi jej przystępność. Choć jest to pozycja akademicka, zarówno jej język, jak i zorientowany na praktyczne potrzeby tryb wykładu umożliwiają skuteczną lekturę także osobom mającym głównie praktyczne doświadczenia informatyczne.

Jakość to pojęcie kluczowe dla praktyki informatycznej, a mimo to niebezpiecznie niejednoznaczne. Choć definicji jakości jest wiele, a każda zasługuje na osobną monografię, istnieje przecież duża, niezaspokojona potrzeba jednoznacznego określenia jakości w ten sposób, by móc ją mierzyć, oceniać, porównywać, zapisywać w kontraktach i wymaganiach. Książka traktuje także o jakości produktu. Omawia atrybuty jakości, zależności między nimi oraz sposoby ich pomiarów. To tematyka o dużym znaczeniu dla wszystkich udziałowców projektu informatycznego. Niedostatki wiedzy na ten temat powodują, że klienci niejasno i niepoprawnie określają swoje wymagania, analitycy systemowi sporządzają niepełne modele, inżynierowie jakości mają problemy z jednoznaczną oceną jakości gotowego lub budowanego właśnie produktu.

Jeśli w projektach zdarzają się kłopoty, próbuje się je rozwiązywać, usprawniając procesy i procedury. Jest wiele różnych modeli dotyczących tego jak postępować, by określić i wdrożyć usprawnienia, a każdy z nich ma swoich zwolenników i przeciwników. Czym się od siebie różnią, który najlepiej pasuje do naszych potrzeb? Nie są to czcze pytania. Zmienia się środowisko, w którym firmom przychodzi działać i konkurować, więc firmy muszą także zmieniać się, by sprostać nowym wyzwaniom. Różne są przyczyny i cele zmian, a udoskonalenie sposobu pracy jest jednym z ważniejszych. Po to, aby zmniejszyć ryzyko niepowodzenia, trzeba sprawnie przeprowadzić analizę możliwej zmiany oraz skutecznie zrealizować jej wdrożenie. W książce znajdziemy zarówno przegląd istniejących, znanych metod oceny i doskonalenia procesów, jak i porównanie wynikających z nich korzyści oraz zagrożeń.

Tematyka budząca spore emocje, a przy tym znacząca dla powodzenia projektów oraz firm, to kwestia relacji między udoskonalaniem procesów a jakością produktów. Każdy pewnie słyszał sarkastyczne historyjki o wdrożeniach certyfikatów ISO 9000, wymagających jakoby jedynie naklejenia karteczek z nazwą na wszystkie znajdujące się w firmie przedmioty, mnożących zbędną papierologię i nieprzekładających się w żaden sposób na jakość produktów. Na przykład znany guru, Tom DeMarco, jest sceptycznie usposobiony do korzyści płynących z osiągania wyższych poziomów CMM twierdząc, że prowadzi to wyłącznie do polepszenia chwilowej sprawności kosztem zmniejszenia elastyczności i utraty strategicznej efektywności.

 Andrzej Kobyliński "Modele jakości produktów i procesów programowych", Warszawa 2005, SGH w Warszawie, ISSN 0867-7727 [nakład wyczerpany]