Oprogramowanie dla serwisu komputerowego

Witam,
Mam do wykonania projekt na studia z przedmiotu Podstawy inżynierii oprogramowania. Temat jaki sobie wybrałem to "Oprogramowanie dla serwisu komputerowego". Mój problem polega na tym, że nie wiem jak taki program ma wyglądać, jakie powinien zawierać opcje (drugi problem, to, że nie byłem na żadnym wykładzie : P). Przecież jak programista pisze program powinien dostać specyfikację, ja dostałem tylko temat. Może mi ktoś z doświadczonych kolegów programistów doradzi... Czy mam ściągnąć jakiś trial programu do obsługi serwisu i pisać na jego wzór? Wtedy to nie będzie planowanie, analiza i projektowanie samemu programu tylko reverse engineering : P Nie wiem na prawdę jak się do tego zabrać. Przedmiot to Podstawy inżynierii oprogramowania, więc powinienem wszystko zaplanować od prostych schematów, potem rozrysować wszystkie klasy, przepływ komunikatów. Wiadomo, że mogę napisać to co sobie wymyślę, ale jakby ten program był taki, jaki na prawdę firmy używają w serwisach, to byłby on użyteczny i jakbym go opublikował może by i ktoś z niego skorzystał (nie chcę pisać bezużytecznego programu). Proszę o wskazówki jak się do tego zabrać, skąd dowiedzieć się jak taki program ma wyglądać. Może udałoby mi się znaleźć kogoś kto potrzebuje takiego programu, wtedy od tej osoby czy firmy dostałbym specyfikację. A może jest tu ktoś, kto pisał taki program i mi napisze jakie moduły powinien zawierać (magazyn, jakieś faktury, raporty pewnie itp.). Nigdy nie pracowałem w serwisie komputerowym i nie wiem co taki program ma zawierać.
Proszę o wskazówki i pozdrawiam.

Kiedy ja miałem podobny projekt na studiach to zalecenie było takie zeby wybrać temat stosowny do posiadanych znajomości. Tzn jeśli masz kogos znajomego kto prowadzi firmę X to projektuj system dla tej firmy bo masz z kim rozmawiać o wymaganiach funkcjonalnych.
A teraz musisz zapewne iść do jakiegoś serwisu i pytać ;]

Rzeczywisty i przystający do prawdziwego życia projekt to sobie zostaw na inżynierkę, bo chyba nie zdajesz sobie sprawy ile pracy wymaga taki projekt. Kilkadziesiąt przypadków użycia, scenariusze do tego i takie tam Cię zabije. Sprowadź projekt do obsługi bazy danych służącej do przetwarzania:

• listy klientow,
• listy pisadanego sprzętu,
• faktur.
  Zacznij od:
• use case (diagram przypadków użycia)
  pozniej zrob:
• opis przypadków użycia
  pozniej zrob:
• diagram klas
• diagram ERD
  Ogranicz się głównie do funkcjonalnośći typu:
• dodawanie
• usuwanie
• edycja.
  Pisz to na przeglądarke internetową w PHP, od podstaw w notatniku, lub w CakePHP.

protechnologia.pl napisał(a)

Pisz to na przeglądarke internetową w PHP, od podstaw w notatniku, lub w CakePHP.

Dlaczego radzisz to pisać w PHP? Klienci rejestrowali by się przez www i wysyłali zlecenia? Czy chodzi bardziej o możliwość połączenia do jednej bazy punktów serwisowych w różnych miejscach? Ja myślałem, że przychodzą do punktu serwisowego, oddają sprzęt do naprawy, a pracownik zapisuje w aplikacji wszystkie dane klienta, kiedy oddał sprzęt, opis usterki, na kiedy ma być skończone itp. Ewentualnie jak klient chce, żeby mu złożyć komputer to też w programie jest lista części, które się wybiera, a potem daje wydruk i koszty zestawu policzone, no i dodatkowe zlecenia takie jak odwirusowanie komputera, instalacja i konfiguracja systemu itp. Ja myślę, że to będzie mi dobrze pisać w C++, albo w C# w oparciu np. o SQLite albo coś tam znajde do bazy danych. Najgorsze te scenariusze i jakieś wykresy, nawet nie wiem co to i po co, ja bym zaczął kodować od teraz jakbym wiedział jakie to ma mieć funkcje, a nie rysunki robił.

Klienci nie będą korzystać z aplikacji tylko pracownik serwisu... W PHP tylko z powodu praktycznej wygody. Jak sobie to napiszesz w PHP i wrzucisz gdzies na serwa, to możesz sobie w to wejść na uczelni w domu, na konsultacjach itd. Tak samo pracownik serwisu, mógłby sobie w to wejść w domu, u klienta itd. Dokumentacja jest po to, że jak Ci klient, dla którego robisz program podpisze ją, to wtedy nie będzie wydziwiał i kazał wprowadzać jakieś niekończące się poprawki po zakończeniu pisania, bo to co chciał i podpisał ma. Bez dokumentacji, jak jedna strona udowodni drugiej, że się wywiązała ze zlecenia? Po zatym dokumentacja hest po to, że jak pracujesz w jakiejś firmie i piszesz dla nich program, a poźniej się zwolnisz, to Twoj następca ma od czego zacząć i nie musi sterczeć nad kodem i myśleć o co Ci chodziło.

0DFh napisał(a)

Najgorsze te scenariusze i jakieś wykresy, nawet nie wiem co to i po co, ja bym zaczął kodować od teraz jakbym wiedział jakie to ma mieć funkcje, a nie rysunki robił.

Nie chodziłeś na wykłady i takie są efekty. Słowo (skrót) klucz: UML. Jeśli nie wiesz jakie program ma mieć funkcje i nie rozumiesz do czego on ma służyć, to jak chcesz go napisać? Wszelkie diagramy i projekt służą właśnie opisaniu celu i sposobu w jakim aplikacja ma powstać.

protechnologia.pl napisał(a)

W PHP tylko z powodu praktycznej wygody. Jak sobie to napiszesz w PHP i wrzucisz gdzies na serwa, to możesz sobie w to wejść na uczelni w domu, na konsultacjach itd.

To czemu PHP, a nie Django albo RoR?

To może napiszę czego się dowiedziałem, bo szkoda tak dyskutować. Jest to przedmiot Podstawy inżynierii oprogramowania, czyli mam się tutaj uczyć tworzenia dokumentacji i kierowania rozwojem oprogramowania.

Zatem biorę sobie np. model kaskadowy:

Faza strategiczna
Polega na podjęciu decyzji dotyczącej tego, co pisać.
Faza określania wymagań
Polega na określeniu wymagań, jakie ma spełniać program.
Faza analizy (modelowania)
Polega na określeniu, jak program ma działać, żeby spełniał postawione mu wymagania.
Projektowanie
Polega na zaprojektowaniu implementacji programu, czyli zaplanowaniu, jak będzie wyglądał jego kod (podział na moduły, klasy, funkcje itp.).
Implementacja
Polega na napisaniu programu - to jest sedno programowania.
Dokumentacja
Odbywa się równolegle z innymi fazami i polega na sporządzeniu dokumentów opisujących tworzony program.
Testowanie
Polega na znalezieniu i usunięciu błędów.
Instalacja
Polega na przekazaniu systemu końcowemu użytkownikowi.
Konserwacja
Polega na dalszym poprawianiu programu, pisaniu kolejnych wersji itp.

//źródło: www.programuj.com/artykuly/rozne/projekty.php

I wypełniam poszczególne punkty.

Głównym problemem będzie dobre określenie wymagań, przypadków użycia, narysowanie mapy myśli (nie wiem, czy mapa myśli tylko dla mnie, czy dołączyć ją do projektu?), oszacowanie kosztów, przedstawienie klas na schematach UML oraz zaprojektowanie bazy danych itp. Program obsługujący to tylko interfejs, więc mogę go zrobić w C++ na PC, ponieważ zlecenia raczej przyjmuje się telefonicznie i pracownik sobie to pisze na swoim komputerze, a przyjeżdża tylko po sprzęt do odbioru.
Czy dobrze rozumuję? : )

I mam jeszcze prośbę skąd nauczę się UML, ponieważ z książki Thinking in C++ wiem tylko, że czarny romb oznacza, że klasa zawiera inną klasę (kompozycja), a biały trójkąt oznacza, że dana klasa dziedziczy z innej klasy. Podałby ktoś jakieś dobre źródła do nauki tego UML'a, rozplanowywania przypadków użycia (use cases) i jeszcze rozrysowywania przepływu jakiś komunikatów, bo tego to nie do końca rozumiem.

Dziękuję za dotychczasową pomoc i pozdrawiam.

Jak w Google wpiszesz "projekt systemu informatycznego" to na kilku pierwszych pozycjach będziesz mieć przykładowe projekty. A UMLa to jedynie z jakiejś książki, bo w necie nie ma nic godnego polecenia.

Dziękuję wszystkim za odpowiedzi.

0DFh napisał(a)

I mam jeszcze prośbę skąd nauczę się UML, ponieważ z książki Thinking in C++ wiem tylko, że czarny romb oznacza, że klasa zawiera inną klasę (kompozycja), a biały trójkąt oznacza, że dana klasa dziedziczy z innej klasy. Podałby ktoś jakieś dobre źródła do nauki tego UML'a, rozplanowywania przypadków użycia (use cases) i jeszcze rozrysowywania przepływu jakiś komunikatów, bo tego to nie do końca rozumiem.

Ta książka kompleksowo omawia UML: http://helion.pl/ksiazki/jezyk-uml-2-0-w-modelowaniu-systemow-informatycznych-stanislaw-wrycza-bartosz-marcinkowski-krzysztof-wyrzykowski,juml2.htm
Kompleksowo, ale nie zawsze jasno.

Tylko po co mu kompleksowa wiedza o UMLu? Zgodnie z zasadą 80/20 większości diagramów nigdy nie użyje. Jeśli to ma być zrobione szybko i efektywnie, dobrze by było przejrzeć, jak się robi projekty w metodyce ICONIX.