Materiały do zajęć - Piotr Arłukowicz

Inżynieria oprogramowania

"Inżynieria oprogramowania to dziedzina inżynierii systemów zajmująca się wszelkimi aspektami produkcji oprogramowania: od analizy i określenia wymagań, przez projektowanie i wdrożenie, aż do ewolucji gotowego oprogramowania. Podczas gdy informatyka zajmuje się teoretycznymi aspektami produkcji oprogramowania, inżynieria oprogramowania koncentruje się na stronie praktycznej..." [Wikipedia: ]

Uwagi obecne

20080115: Zbieranie informacji w celu dokonania oceny pracy semestralnej. Ostatni dzwonek dla tych, którzy chcą mieć zaliczone zajęcia :)
Uwaga: NIE rozmawiam o zaliczeniu z osobami, które do dnia 20070122 nie uregulują swoich spraw związanych z zaliczeniem. Należy to rozumieć tak, że dnia 20070122 upływa OSTATECZNY termin, w którym przyjmuję dokumentację oraz projekty. Jest to też ostatni dzień, w którym chciałbym wpisać zaliczenia do indeksów i życzyć Wam powodzenia w dalszym studiowaniu. Od Was zależy, czy dzień ten będzie dniem zwycięstwa , czy dniem rzezi .

Poprzednie zajęcia

20080108: Pierwsze zajęcia w roku 2008, i jednocześnie ostatnie przed przedostatnimi. Proszę przygotować dokumentację końcową (wystarczy język naturalny), w której umieszczone będą co najmniej podane niżej informacje:

1. Nazwa grupy
2. Skład grupy (początkowy, i końcowy) z adresami email
3. Historia zmian personalnych w grupie (jeżeli w [2] stany się różnią)
4. Podział ról w grupie (kto zleca, kto wykonuje, stan początkowy i końcowy)
5. Nazwa projektu i oficjalna data jego 'rozpoczęcia'
6. Opis ramowy projektu zrobiony przez zlecających
7. Pierwszy opis projektu zrobiony przez wykonawców (po pierwszym spotkaniu)
8. Narzędzia i technologie użyte przez zespół (systemy kontroli wersji, przepływu zadań, harmonogramowania, zarządzania zasobami, systemy, bazy, języki, edytory, profilery, kompilatory, linkery, debuggery itp.)
9. Historia zmian w projekcie
   • changelog
   • milestones
   • snapshot points
   • zmiany koncepcji
   • stabilnosc developmentu
10. Harmonogram prac
    • pierwszy harmonogram
    • historia zmian harmonogramu
    • zauwazone przyczyny opoznien harmonogramu
    • przypadki progressow i nadprodukcji (gdy harmonogram przekroczono lub wyprzedzono)
11. Analiza wydajności zespołu
    • szybkość powstawania kodu
    • szybkość testowania
    • szybkość wdrozenia i urchuchamiania
12. Ocena subiektywna
    • czego się nauczyliśmy
    • co sprawiło najwięcej kłopotów

Każdy projekt przed zaliczeniem chcę zobaczyć i ocenić jego stan, w tym czy działa i czy spełnia założenia projektowe. Następnie, dokumentacja razem ze wszystkimi plikami projektu powinna zostać do mnie wysłana mailem lub jeżeli jest zbyt obszerna, dostarczona inną drogą. Dokumentacja musi być przygotowana w wersji offiline (akceptuję formaty TEX, HTML, DVI, PS, PDF, DOC, POD, MAN, TXT i ewentualnie inne, do uzgodnienia, zależnie od projektu). Wersje HTML powiny zostać przygotowane tak, aby można było je przeglądać bez dostępu do sieci (całość offline). Wersje TEX powinny być dołączone z całym używanym środowiskiem, stylami i ewentualnie fontami. Pliki PS, DVI, PDF i DOC są akceptowane we wszystkich wersjach. Projekt powinien zostać oddany w postaci wszystkich plików źródłowych, dodatkowych plików graficznych, jeżeli istnieją, kodów wynikowych (jeżeli są takie), z zaznaczeniem sposobu, metody i docelowej platformy kompilacji (jeżeli występuje). W przypadku wersji binarnych wskazane jest wykonanie wersji wykonywalnych na wszystkie docelowo planowane systemy (np. gdy projekt zakładał wykonanie programu dla MS Windows, należy przemyśleć i przygotować wydania dla Wni95/98, ME, 2k, 2k3, XP, i Visty, lub ograniczyć liczbę platform. Wszystkie projekty muszą dodatkowo zawierać informacje o sposobie ich instalacji, wymaganiach i konfiguracji środowiska (np. ustawienia i wersja Javy, zalecane wersje kompilatorów, serwerów, itp., dodatkowe biblitoeki systemowe, itp.). Oprócz tego spodziewałbym się także otrzymać dokumentację użytkownika i techniczną dotyczącą samego produktu, przynajmniej opis zastosowań, przypadków użycia, sceniariuszy, oraz zastosowane/wykorzystane/utworzone API. Wszystkie cytowane źródła muszą być dostępne w opisie w wersji offline (to znaczy, że nie wystarczy mi link do strony z dokumentacją o PHP). W skład oceny końcowej wchodzą oceny obecności, jakości pracy, zaawansowania projektu, charakteru pracy i wartości przedstawionej dokumentacji.

Bezpieczny termin oddawania projektów: 20080115:wtorek

20071204: Analiza prac grup wykazała, że zaznacza się coraz wyraźniej podział na tych, którzy zaliczą, i na tych, którzy będą mieli z tym zaliczeniem niesamowite problemy... Są grupy, które już dziś mają działające wersje RC1 albo beta/alfa, a są i takie, które dopiero tworzą podstawy współpracy z bazą danych. Regułą jest, że grupy, które dobrze zaplanowały pracę, postępują z nią szybciej i znajdują się już w końcowych etapach projektu. Porażką jest sytuacja, gdy dowiaduję się po dwóch tygodniach, że grupa zrobiła dopiero 'dokumentację', i ani na krok nie ruszyła dalej... Pamiętajcie, projekty należy KOŃCZYĆ w grudniu. Ci, którzy je w grudniu zaczynają, mogą liczyć na wielkie trudności z zaliczeniem, ponieważ będzie brana pod uwagę ich praca w ciągu całego semestru, NIE tylko w ostatnich tygodniach. Oczekiwać będę udokumentowanych zmian, historii projektu, jasnego wykazania różnic w stosunku do pierwotnych założeń i końcowych osiągnięć. Każda zmiana założeń, w sensie uproszczenie bazy, zmiana platformy lub języka musi być mocno poparta i interesuje mnie szczególnie. Podobnie, oczekuję, że przedstawicie mi na koniec szczegółową historię ze wszystkich odbytych spotkań wewnętrznych wraz ze wskazaniem, jak wpłynęły one na projekt. I z tego także będę rozliczał... :)

20071126: Zajęcia w pierwszej grupie nie odbyły się z powodu mojego awaryjnego spóźnienia ponad 15 minut. W drugiej grupie natomiast sytuacja wygląda dość nieciekawie dla jednych, a bardzo dobrze dla innych. Są zespoły, które były w stanie zaprezentować już działające prototypy aplikacji, i są takie, które z niewiadomych powodów niczego nie przygotowały. Tacy, którzy nic nie robią, nie zaliczą przedmiotu, i powinno to być dla nich tak oczywiste, jak oczywiste jest dla mnie.

20071120: Sprawdzanie postępu pracy w grupach. Widać, że niektórzy bardzo dobrze posunęli się w rozwoju projektu i mają realne szanse na zakończenie.

20071113: Sprawdzenie postępu prac w grupach doprowadziło do porażającego wniosku: nic nie robicie! W tym tygodniu należy doprowadzić projekty do ładu i wykonać prace, które sami obiecaliście zrobić. Oczekuję utworzenia sensownych harmonogramów, oraz dokumentacji z postępu prac. Zróbcie (ci, którzy jeszcze nie przyłożyli do tego ręki) zestaw raportów tygodniowych z postępu prac - będę wymagał na zakończenie pracy całej dokumentacji, włącznie z odnotowanymi zmianami w projekcie, decyzjami i wnioskami, które odkryjecie w trakcie pracy.

20071106:
Kolejny tydzień pracy samodzielnej: należy rozwijać projekt zgodnie z zasadami przestawianymi na wykładzie. Do samych uczestników projektu należy decyzja, które metody projektowe, schematy postępowania i rodzaje dokumentacji przygotować. Za tydzień odbędzie się inspekcja i korekta projektów oraz ocena trzytygodniowej pracy, więc proszę przygotować się najlepiej jak to tylko możliwe.

20071030:
Należy zapoznać się z podesłanymi materiałami i samodzielnie pracować nad projektem, rozwijając go zgodnie z wytycznymi zapodanymi w trakcie wykładu. Tym samym obecność na wykładzie jest silnie zalecana, mimo że, a nawet właśnie dlatego że jest on prowadzony po angielsku :)

20071023:
Przygotować diagram przypadków użycia w UML^EN,PL dotyczący projektu w programie dia^EN,PL i wysłać go do prowadzącego zajęcia. Bezwarunkowo należy to zrobić PRZED następnymi zajęciami (deadline mija z chwilą 20071029:2359).

20071016:
Wykonać analizę projektu i opisać go w języku naturalnym. Chodzi o zrobienie dokumentacji technicznej na poziomie ogólnym. Bardzo dobre jest wykonanie dwóch opracowań - w jednym umieszczenie tego, co chcą mieć klienci, w drugim tego, co zrozumieli developerzy.

20071009:
Podział na grupy i podgrupy klientów oraz dostawców projektu.

 Uniwersytet Gdański -  Instytut Informatyki -  Piotr Arłukowicz -  Inżynieria