Spis treści na inżynierke

Mój temat pracy to pisanie własnego frameworka w PHP. Kod mam już napisany, wszystko działa, tylko muszę powoli zacząć pisać tekst, i napisać spis treści. Naklepałem coś takiego:

1. Wstęp
   1.1. Czym jest framework? Korzystanie z framework’ów vs pisanie w czystym PHP.
   1.2. Idea wzorców projektowych, opis wzorca MVC.
2. Projekt aplikacji
   2.1. Struktura aplikacji, struktura przestrzeni nazw, nazewnictwo.
   2.2. Flow aplikacji, diagram klas.
3. Implementacja jądra aplikacji
   3.1. Implementacja autolaodera.
   3.2. Implementacja routingu.
   3.3. Implementacja jądra aplikacji (obiekt request, warstwa bazy danych, pliki konfiguracyjne, implementacja instalacji aplikacji...).
   3.4. Logowanie i przechwytywanie błędów
4. Implementacja pobocznych elementów aplikacji
   4.1. Serwisy (obiekty do budowania formularzy, HTML, ...).
   4.2. Query builder.
   4.3. Idea instalacji zewnętrznych aplikacji przez composera.
5. Uwagi końcowe
   5.1. Idea wykorzystania ORMa we frameworkach na podstawie Doctrine ORM.
   5.2. Idea języka szablonów we frameworkach na podstawie twig'a.
   5.3. Krótki opis najbardziej popularnych, istniejących open-source'owych frameworków w PHP.
   5.4. Korzyści wynikające z pisania aplikacji we framework'u.
6. Bibliografia

Tak to powinno wyglądać? Spis treści jest w porządku?

Dzięki!

Wstęp służy do przestawienia celu pracy i motywacji do jej napisania, a nie opisywania alternatywnych sposobów realizacji czegoś. Z tego powodu, punkt 1.1 przeniósłbym do osobnego rozdziału, który miałby numer 1 - bo wstępu (podobnie jak i zakończenia) się nie numeruje. Do niego przeniósłbym zawartość rozdziału 5, żeby w jednym miejscu mieć coś w rodzaju analizy obecnych możliwości (czyli obecnie dostępne frameworki) i ich porównania z czystym PHP. Do tego wymieniłbym wady tych frameworków i solidnie wyjaśnił, czemu zdecydowałem się napisać własny.
Dalej umieściłbym rozdział z wymaganiami funkcjonalnymi wobec powstającego frameworka. Bo obecnie wygląda na to, że zaprojektowałeś i wykonałeś coś, nie mając żadnego celu ani wiedzy o tym, co chcesz zrobić. To zachowanie godne dziennikarza, nie inżyniera.
Następnym rozdziałem niech będzie projekt, ale tu wkleiłbym 1.2, skoro projekt jest oparty o wzorzec MVC.
Na końcu ma być zakończenie, a nie uwagi. Tam piszesz, co Ci się udało, co nie udało, co było największym wyzwaniem, i czy to co stworzyłeś, się do czegoś nadaje, w szczególności, czy da się to ulepszyć w przyszłości.