Po co?
Poprzednie rozdziały miały wykazać, że autor pracy posiada zdolności analityczne. Ten rozdział ma wykazać, że autor potrafi zaproponować własne rozwiązania, zatem dowodzi kreatywności oraz umiejętności dokonywania syntezy.
Zawartość
Znamy już dobrze problem (opisuje go rozdział Charakterystyka/Analiza problemu), znamy istniejące/znane sposoby jego realizacji (opisuje to rozdział Analiza istniejących rozwiązań), teraz trzeba przedstawić propozycję własnego rozwiązania. Ten rozdział koncentruje się na koncepcji rozwiązania problemu, głównie na własnej propozycji autor pracy inżynierskiej.
W tym rozdziale przedstawia się konkretnie ideę proponowanego rozwiązania, możliwe warianty, uzasadnienie wybranego rozwiązania. Koniecznie trzeba się odnieść do analizy istniejących rozwiązań i przedstawiać koncepcję rozwiązania przedstawionych tam problemów. Mile widziane schematy ideowe, graficzne ilustracje przedstawionych koncepcji. Tutaj można wskazać szerszy kontekst proponowanego rozwiązania, wskazując zagadnienia możliwe do wykonania, choć wykraczające poza ramy pracy. Tutaj można wskazać i uzasadnić wybór metod i narzędzi realizacji.
W rozdziale tym przedstawia się również takie zagadnienia jak koncepcja licencjonowania systemu, przewidywany sposób dystrybucji, grupy odbiorców, można przedstawić studium wykonalności, analizę ryzyka.
Wskazówki
4. Koncepcja proponowanego rozwiązania
W rozdziale tym przestawiona zostanie koncepcja ….
4.1 Koncepcja rozwiązania użytkowego
W tym podrozdziale autor pracy wciela się w rolę właściciela produktu — PO. Właściciela produktu, będącego na etapie rozpoznania wymagań użytkowych/biznesowych. Tutaj autor pracy opisuje w jaki sposób proponowany system ma spełniać wymagania użytkowe zidentyfikowane w rozdziale poprzednim, poświęconym analizie problemu, jak jego działanie będzie mogło zaspokoić potrzeby użytkownika/klienta biznesowego. Przedstawiamy przewidywane zastosowania, grupy odbiorców, jak dana grupa ma wykorzystywać system, najlepiej przedstawić to opisując przewidywane scenariusze wykorzystania systemu. Sporządzony tekst nie ma być jeszcze rejestrem produktu a raczej wstępem do jego wytworzenia w przyszłości. Zaleca się, aby właściwości użytkowe zostały opisane z punktu widzenia użytkownika, najlepiej aby przedstawiały konkretne, przewidywane scenariusze wykorzystania systemu. Nie powinny to jednak jeszcze być konkretne historie użytkownika a raczej ogólne scenariusze, służące do ich późniejszego napisania. Nie umieszczamy tutaj zagadnień technologicznych. Uwaga: jeżeli to możliwe, jasno opisujemy elementy wyróżniające proponowane rozwiązania od innych rozwiązań.
4.2 Koncepcja rozwiązania technologicznego
W tym podrozdziale autor pracy wciela się w rolę architekta oprogramowania — SA. Pamiętamy, że w 4.1 autor wcielić się miał w rolę PO. Tutaj autor nawiązuje wewnętrzny dialog pomiędzy dychotomicznymi wcieleniami PO i SA, tak aby przedstawić najlepszą koncepcję rozwiązania technologicznego. Tutaj przedstawia się opis technologicznej koncepcji realizacji systemu, jaką postać on ma przyjąć (aplikacja WWW, typu desktop, mobilna, a może hybrydowa), ogólny szkic architektury (szczegółowy będzie w następnym rozdziale), przewidywane narzędzia realizacji (krótko, więcej szczegółów w następnym rozdziale). Jeżeli w 4.1 ustalono, że np. system ma obejmować w pełni funkcjonalną aplikację WWW oraz uzupełniającą ją, uproszczoną natywną aplikację mobilną, należy przedstawić koncepcję architektury (zapewne ze wspólną warstwą serwerową) zdolną do spełnienia takich wymogów. Tutaj można również przedstawić dyskusję możliwych metod, technik i narzędzi realizacji, dokonać ich oceny, wskazać wady, zalety, wskazać i uzasadnić dokonany wybór. Nie wchodzimy głęboko w zagadnienia technologiczne, pamiętamy, że prezentujemy koncepcję a jeszcze nie szczegółowe założenia.
Typowy rozmiar
Typowa, sumaryczna objętość — 2-5 stron.
Powróć do Struktura pracy inżynierskiej