Scenariusz (przetwarzanie)

W informatyce scenariusz ( UK : / s ɪ ˈ n ɑː r i oʊ / , US : / s ə ˈ n ) i oʊ / ɛər ; zapożyczony z włoskiego scenariusza ( wymawiane [ʃeˈnaːrjo] , z łac. scena „scena”) to narracja przewidywalnych interakcji ról użytkowników (znanych w Unified Modeling Language jako „ aktorzy ”) oraz system techniczny, który zwykle obejmuje sprzęt komputerowy i oprogramowanie .

Scenariusz ma cel , który zwykle jest funkcjonalny. Scenariusz opisuje jeden sposób, w jaki system jest używany lub ma być używany w kontekście działania w określonych ramach czasowych. Ramy czasowe dla scenariusza mogą obejmować (na przykład) pojedynczą transakcję; operacja biznesowa; dzień lub inny okres; lub cały okres eksploatacji systemu. Podobnie zakres scenariusza może obejmować (na przykład) pojedynczy system lub element wyposażenia; wyposażony zespół lub dział; lub całej organizacji.

Scenariusze są często używane jako część procesu tworzenia systemu. Są one zazwyczaj tworzone przez specjalistów ds. użyteczności lub marketingu , często współpracujących z użytkownikami końcowymi i programistami. Scenariusze są pisane prostym językiem, z minimalną ilością szczegółów technicznych, tak aby interesariusze (projektanci, specjaliści ds. użyteczności, programiści, inżynierowie, menedżerowie, specjaliści ds. marketingu itp.)

Coraz częściej scenariusze są wykorzystywane bezpośrednio do definiowania pożądanego zachowania oprogramowania: zastąpienia lub uzupełnienia tradycyjnych wymagań funkcjonalnych . Scenariusze są często definiowane w przypadkach użycia , które dokumentują alternatywne i nakładające się sposoby osiągnięcia celu.

Rodzaje scenariuszy w rozwoju systemów

W rozwoju systemu stosuje się wiele rodzajów scenariuszy. Alexander i Maiden wymieniają następujące typy:

Historia : „narracyjny opis przyczynowo powiązanej sekwencji zdarzeń lub podjętych działań”. Krótkie historie użytkowników są pisane w zwinnym stylu tworzenia oprogramowania.
Sytuacja, alternatywny świat : „przewidywana przyszła sytuacja lub migawka”. To znaczenie jest powszechne w planowaniu, ale rzadziej w tworzeniu oprogramowania.
Symulacja : wykorzystanie modeli do eksploracji i animowania „Historii” lub „Sytuacji”, „udzielania precyzyjnych odpowiedzi na pytanie, czy taki scenariusz można zrealizować przy użyciu jakiegokolwiek wiarygodnego projektu” lub „oceny implikacji alternatywnych możliwych światów lub sytuacji”.
Storyboard : rysunek lub sekwencja rysunków używana do opisu interfejsu użytkownika lub do opowiedzenia historii. To znaczenie jest powszechne w interakcji człowiek-komputer, aby określić, co użytkownik zobaczy na ekranie.
Sekwencja : lista interaktywnych kroków podejmowanych przez agentów ludzkich lub maszynowych odgrywających role systemowe. Wiele form scenariuszy napisanych jako sekwencje kroków obejmuje scenariusze operacyjne, koncepcje operacji i przypadki testowe.
Struktura : dowolna bardziej rozbudowana reprezentacja scenariusza, w tym schematy blokowe , „wykresy sekwencji” UML /ITU, a zwłaszcza w przypadku tworzenia oprogramowania Przypadki użycia .

Negatywne scenariusze lub przypadki nadużyć mogą być zapisywane w celu wskazania prawdopodobnych zagrożeń, którym należy przeciwdziałać, aby zapewnić systemom wystarczającą ochronę , bezpieczeństwo i niezawodność . Pomagają one odkryć wymagania niefunkcjonalne .

Zastosowania w rozwoju systemu

Scenariusze mają wiele możliwych zastosowań w rozwoju systemu. Carroll (1995) wymienia 10 różnych „roli scenariuszy w cyklu życia rozwoju systemu”:

Analiza wymagań : scenariusze opisują stan techniki (często nazywany „tak jak jest”); odgrywane scenariusze pomagają odkrywać wymagania, gdy analitycy „inscenizują symulowaną sytuację w pracy”.
Komunikacja między użytkownikiem a projektantem : użytkownicy wnoszą ważne dla nich scenariusze lub sytuacje, których chcą doświadczyć lub których chcą uniknąć.
Uzasadnienie projektowe : uzasadnienie może wyjaśniać projekt „w odniesieniu do określonych scenariuszy interakcji użytkownika”.
Wizja : scenariusze „mogą być środkiem do ustalenia, jak powinien wyglądać i działać projektowany system”. W tej roli scenariusze mogą być „makietami graficznymi, takimi jak scenorysy lub symulacje wideo” i mogą tworzyć wczesne prototypy projektowanego systemu.
Projektowanie oprogramowania : „można analizować scenariusze w celu zidentyfikowania potrzebnych obiektów domeny centralnego problemu”; te same scenariusze można opracować w celu opisania stanu, zachowania i interakcji obiektów.
Wdrażanie : oprogramowanie można budować według jednego scenariusza na raz, pomagając „utrzymywać koncentrację programistów” i „tworzyć kod, który jest bardziej ogólnie użyteczny”.
Dokumentacja i szkolenie : „scenariusze interakcji, które są znaczące dla użytkowników” mogą wypełnić lukę między zbudowanym systemem „a zadaniami, które użytkownicy chcą wykonać za jego pomocą”.
Ocena i testowanie : ponieważ „system musi być oceniany pod kątem konkretnych zadań użytkownika, które ma obsługiwać”, scenariusze są idealne do oceny.
Abstrakcja : ogólne zasady mające zastosowanie do różnych zadań (lub systemów) można zidentyfikować, porównując scenariusze.
Budowanie zespołu : „zestaw probierczych historii jest ważnym, spójnym elementem każdego systemu społecznego”.

W różnych stylach rozwoju systemu

Wybór reprezentacji scenariuszy różni się znacznie w zależności od stylu rozwoju, który jest związany z kontekstem przemysłowym.

Scenariusze w różnych kontekstach projektowych
Kontekst projektu	Przykład	Styl scenariusza	Styl rozwoju
Duży projekt wojskowy	Samolot myśliwski	Widok operacyjny , koncepcja operacji	Etapowe cykle życia, dokładna dokumentacja (patrz DoDAF )
Połączony sprzęt/oprogramowanie	Samochód	Przypadek użycia	RUP
Oprogramowanie biznesowe	Aplikacja na telefon komórkowy	Historia użytkownika	Zwinne tworzenie oprogramowania

Zobacz też

Bibliografia

Alexander, Ian i Beus-Dukic, Ljerka. Odkrywanie wymagań: jak określać produkty i usługi . Wiley, 2009.
Alexander, Ian F. i Maiden, Neil. Scenariusze, historie, przypadki użycia . Wiley, 2004.
Carroll, John M. (red.) Wykorzystanie: oparte na scenariuszach projektowanie interakcji człowiek-komputer . MIT Press, 2000.
Carroll, John M. (red.) Projektowanie oparte na scenariuszach: przewidywanie pracy i technologii w rozwoju systemu . Wiley, 1995.
Cockburn, Alistair. Pisanie efektywnych przypadków użycia . Addison-Wesley, 2001.
Cohn, Mike. Stosowane historie użytkowników: do zwinnego tworzenia oprogramowania . Addison-Wesley, 2004.
Fowler, Marcin. UML destylowany . 3. edycja. Addison-Wesley, 2004.

Linki zewnętrzne

Uwagi dotyczące praktyki projektowej: historie i prototypy jako katalizatory komunikacji. przez Thomasa Ericksona w Carroll, 1995.