Fiszki do Dokumentacja oprogramowania i jej zasady
Dokumentacja oprogramowania i jej zasady: Przewodnik dla studentów
Dotknij, aby odwrócić · Przesuń, aby nawigować
Inżynieria Oprogramowania
15 fiszek
Fiszka 1
Pytanie: Jaki jest minimalny zestaw dokumentacji systemu z perspektywy podejścia opartego na przypadkach użycia (UC-driven) w inżynierii oprogramowania?
Odpowiedź: Przypadki użycia (perspektywa funkcjonalna), diagram klas/obiektów UML z pakietami (perspektywa statyczna) oraz diagram sekwencji UML (zachowanie dyna
Fiszka 2
Pytanie: Dlaczego autor preferuje minimalistyczne podejście do dokumentacji w inżynierii oprogramowania?
Odpowiedź: Ponieważ uważa je za efektywne i minimalizuje ilość dokumentacji, którą należy utrzymywać i aktualizować, co zmniejsza ryzyko niespójności i błędów w
Fiszka 3
Pytanie: Jaki problem pojawia się wraz ze wzrostem ilości dokumentacji w projekcie oprogramowania?
Odpowiedź: Więcej dokumentacji i powtarzających się informacji w wielu miejscach oznacza większe wymagania dotyczące aktualizacji oraz wyższe ryzyko niespójności
Fiszka 4
Pytanie: Jakie jest stanowisko autora dotyczące dokumentacji bazy danych?
Odpowiedź: Autor nie wspomina o dokumentacji bazy danych, ponieważ zakłada, że logika znajduje się w warstwie aplikacyjnej, a schemat bazy danych powinien być sa
Fiszka 5
Pytanie: Jakie specjalistyczne metody dokumentowania architektury wymienia tekst jako przykład podejścia naukowego?
Odpowiedź: Metody SEI: ATAM (Architecture Trade-off Analysis Method) i QAW (Quality Attribute Workshop).
Fiszka 6
Pytanie: Co autor mówi o istnieniu innych perspektyw i standardów w dokumentacji oprogramowania?
Odpowiedź: Istnieje wiele innych perspektyw, zaleceń i standardów, specyficznych technologicznie rekomendacji i opinii, których tekst nie wspomina, ponieważ pref
Fiszka 7
Pytanie: Kiedy wystarczy, aby dokumentem architektonicznym był jedynie sfotografowany szkic z tablicy, a kiedy nie?
Odpowiedź: Wystarczy, jeśli domena jest znana, a zespół mały; nie wystarczy w przypadku dużego/rozproszonego lub niedoświadczonego zespołu, złożonej lub nowej te
Fiszka 8
Pytanie: Dlaczego warto komentować kod źródłowy, nawet jeśli może się to wydawać zbędne?
Odpowiedź: Komentarze pomagają w powrocie do projektu po pewnym czasie, ułatwiają współpracę zespołową i umożliwiają używanie kodu jako biblioteki bez koniecznoś
Fiszka 9
Pytanie: Jaka jest główna korzyść z wysokiej jakości dokumentacji w przypadku bibliotek?
Odpowiedź: Umożliwia innym korzystanie z biblioteki bez znajomości jej wewnętrznego działania; bez dokumentacji biblioteka byłaby trudna lub niemożliwa do użycia
Fiszka 10
Pytanie: Jakie środki warto wykorzystać do dokumentowania architektury oprogramowania?
Odpowiedź: Narzędzia do modelowania i narzędzia CASE, programy graficzne, szkice na tablicy oraz tekst towarzyszący; forma może być różna w zależności od projekt