Moze bardziej rozlegly wywod, ale na poziomie szkolnym, czyli jak szkola przedstawia tworzenie software w firmach oraz jakich narzedzi przy ucza do tego itd (Niemcy). Uwaga pojawia sie pojecia po niemiecku, bo nie mam pojecia, jak nazywaja sie po polsku a tlumaczenie 1:1 moze byc dziwne. Tresc bazuje na prostych modelach tworzenia software, w tym przypadku waterfall model, oprocz tego podam link, do innego modelu, ktorym w swojej formie jest duzo dokladniejszy, ale przez to trzeba poswiecic tez wiecej czasu.
Calosc opiera sie o tak zwany Waterfall model, w ktorym wystepuja najczesciej 4 fazy, az do oddania softu, ale ten 6 fazowy jest lepszy: (angielkie nazwy)
System engineering, analysis, design, coding, testing, maintenance
https://en.wikipedia.org/wiki/Waterfall_model
Zacznij od 2 prostych pojec:
- #systemengineering#
- Lastenheft: czyli tak zwana specyfikacja klienta, w ktorej opisuje co dokladnie chce miec w swoim projekcie (funkcjonalnosci, moze jakies gui juz czesciowo stworzene, moze chce ekstra dokumentacje tylko dla usera, jakies systemy zabezpieczen itd itd.)
- kalkulacja projektowa (kosztorys itd)
- work breakdown structure
- netzplan (jest to lista zadan, ktora ma okreslony czas wykonania, dzieki czemu mozna ustalic kiedy teoretycznie powinnien skonczyc sie projekt, jakie zadania mozna wykonac rownolegle w czasie itd). To sa te nazwazniejsze, cala resta jak lista terminow itp, mozna odczytac z netzplan.
- w przypadku gier dalbym tutaj jeszcze GDD
- #analysis#
- Pflichtenheft: to takze specyfikacja, ale od strony firma, jest wiec to dokument w ktorym jest opisane jakie elementy softu i jakimi metodami chce stworzyc je firma, oraz czy pewne czesci sytsemu moga zostac wgl stworzone tak, jak wymaga tego klient, oprocz tego jest podawany tez szacowany czas pracy itd. I ogolnie to jest dokument, ktory jest podstawa umowy miedzy klientemm, a firma i w razie czego, gdybys cos bylo nie tak z programem, brakowalo czegos, a jest w tym dokumencie, to klient moze wytoczyc proces itd. Ale mniejsza z tym.
- Model produktu: tutaj moga to byc jakies modele CAD, jakies plany plytek PCB itd, wymienic mozna sporo
- Model GUI
- i czasami juz powstaje istrukcja obslugii odnosnie programu, aczkolwiek nie jest to najlpeszy pomysl na poczatek, tzn mozna stworzyc i pozniej edytowac, zeby zobaczyc co sie zmienilo itd.
- #Design#
- UML: doslownie kazdy rodzaj diagramu, use-case, life-diagram, class-diagram, table-diagram, entity relationship model itd. Mozna tu wymienic wiele rzeczy, wszytsko zalezy co sie robi, innych diaramow uzyjesz w przypadku bazy danych, innych gdy tej bazy danych w projekcie nie ma, bo wtedy zrezygnujesz z table model oraz ERM. Wiec tutaj musialbys zglebic troche temat. To czego na pewno bys nie ominal to use-case, jezeli robisz jakis program, bo ona pokazuje interakcje systemu, czy uzytkownika z pewnymi funkcjonalnosciami systemu lub ze wszystkimi. Tutaj mam DIA, ale pewnie jakies edytory online bylyby lepsze, jezeli jezdzisz lub chcesz edytwac cos na tablecie itd. Lista:
- class diagram
- component diagram,
- deployment diagram
- object diagram
- package diagram
- use case
- activity
- state machine
- sequence/life
- interaction overwiev
- communication
- jest ich pewnie wiecej, wiec najlepiej jak wejdziesz w standard UML i zobaczysz pelna liste, to sa akurat te ktorych ja musialem uzywac
- Nassi-Shneiderman-diagram, jak dla mnie najbardziej wkurzajace diagramy ze wszytskich, poniewaz nie spotkalem dobrego i fajnego softu do nich. Ale slyszalem, ze jest soft, ktory potrafi nawet dobrze wygenerowac kod z nich, ale wtedy wszytsko musi byc piko bello zrobione, kazdy znak itd zgodnie ze standardm. Ja akurat pod reka mamhttps://structorizer.fisch.lu/
- #Coding#
- No i tutaj jest juz impelemntacja calego projektu bazuja glownie na tych diagramach, bo po to je stworzyles, zeby nie musiec myslec podczas kodzenia, czy to ma byc tak, czy siak, czy owak. MAsz digram, widzisz, ze to i to dziala tak czy tak i tyle.
- Pokusze sie o stwierdzenie, ze tutaj tez moze powstac dokumentacja, ale odnosnie opisu funkcji (parametry jakie przcjmuja, odbjasnienei, kiedy sie jej uzywa itd) i pozniej jest to pewnie klejone w calosc razem z diagramami, ale o tym pozniej.
- #Testing#
- Blackbox test
- Whitebox test
- #maintenance#
- Oddanie gotowego programu + pielegnacja
Odnosnie samego podejscia i czy z takim sie spotkasz, to szczerze watpie :D wiele osob, ktore pracuje nie widzialo w pracy na oczy tych diagramow z UML. Jest to raczej mocno techniczne podejscie, ktore zabiera mnostwo czasu, bo stworzenie samych diagramow, zabiera sporo czasu. Oczywiscie w tym przypadku dokumentacja jest bardzo duza i dokladna, ale czy zawsze jest to potrzebne tego nie wiem. Oprocz tego na dole zostawiam link do innego modelu, czyli V-Modell, ktory jest rozwinieta wersja Waterfall model i jest na 100% lepszy do implementacji oraz umozliwia skoki miedzy fazami w projekcie.
https://en.wikipedia.org/wiki/V-Model
