Według GOST norma ta (wznowiona w listopadzie 1987 r.) ustanawia procedurę konstruowania i przygotowywania specyfikacji technicznych dotyczących opracowywania programu lub oprogramowania dla komputerów, kompleksów i systemów, niezależnie od ich celu i zakresu.
Tworząc go trzeba zachować szczególną ostrożność i ostrożność, gdyż... Często umiejętnie (i kompetentnie) opracowana specyfikacja techniczna decyduje o powodzeniu całego dzieła. To specyfikacja techniczna uzgadniana z Klientem, który zazwyczaj stara się wprowadzić jak najwięcej sprzecznych i zawyżonych wymagań. Zadaniem Egzekutora jest wręcz przeciwnie ułatwianie mu życia. Jednak po złożeniu podpisów po obu stronach jest już za późno na odtworzenie czegokolwiek.
Postanowienia ogólne
Specyfikację istotnych warunków zamówienia sporządza się na arkuszach formatu A4 i/lub A3, co do zasady, bez wypełniania pól arkusza. Numery arkuszy (stron) umieszczane są w górnej części arkusza, nad tekstem.Aby dokonać zmian i uzupełnień w zapleczu technicznym na kolejnych etapach rozwoju programu lub oprogramowania, wydawany jest dodatek do niego. Koordynacja i zatwierdzenie dodatku do specyfikacje techniczne przeprowadzane w tej samej kolejności, jaka została ustalona w specyfikacjach technicznych.
Regulamin musi zawierać następujące sekcje:
- nazwa i zakres zastosowania;
- podstawa rozwoju;
- cel rozwoju;
- wymagania techniczne dotyczące programu lub oprogramowania;
- wskaźniki techniczne i ekonomiczne;
- etapy i etapy rozwoju;
- procedura kontroli i akceptacji;
- aplikacje.
Sekcja: Nazwa i zakres
W sekcji Nazwa i zakres wskazać nazwę, krótki opis zakresu zastosowania programu lub oprogramowania oraz przedmiot, w jakim program lub oprogramowanie jest używane.W sekcji Podstawa opracowania należy wskazać:
- dokument(-y), na podstawie którego przeprowadzane jest opracowywanie;
- organizacja, która zatwierdziła ten dokument i data jego zatwierdzenia;
- imię i (lub) symbol tematy rozwojowe.
Sekcja: Cel rozwoju
W sekcji Cel rozwoju Należy wskazać funkcjonalny i operacyjny cel programu lub oprogramowania. Możesz ograniczyć się tutaj do jednej lub dwóch fraz. Najważniejsze jest jasne określenie, do czego służy ten program.Przykładowo: Program stanowi rdzeń zautomatyzowanej stacji roboczej (AWS) dla programisty ciągłego systemy liniowe automatyczne sterowanie(ACS), pozwalający na rozwiązywanie problemów analizy prostych modeli.
Rozdział: Wymagania techniczne dotyczące programu lub oprogramowania
Sekcja ta powinna zawierać następujące podsekcje: - wymagania dotyczące cech funkcjonalnych;
- wymagania dotyczące niezawodności;
- warunki użytkowania;
- wymagania dotyczące składu i parametrów środki techniczne;
- wymagania dotyczące informacji i kompatybilność oprogramowania;
- wymagania dotyczące etykietowania i pakowania;
- wymagania dotyczące transportu i przechowywania;
- specjalne wymagania.
Sekcja: Wymagania dotyczące cech funkcjonalnych.
W tym miejscu należy wskazać wymagania dotyczące składu wykonywanych funkcji, organizacji danych wejściowych i wyjściowych, charakterystyk czasowych itp.Na przykład : Program powinien pozwalać... obliczyć... zbudować... stworzyć...
Dane wejściowe: plik tekstowy z podanymi...
Dane wyjściowe: informacje graficzne i tekstowe – wyniki analizy systemu...; pliki tekstowe - raporty z... diagnostyki stanu systemu oraz komunikaty o wszystkich błędach, które wystąpiły.
Wymagania dotyczące niezawodności. Należy określić wymagania zapewniające niezawodne działanie (zapewnienie stabilnej pracy, monitorowanie informacji wejściowych i wyjściowych, czas regeneracji po awarii itp.).
Trudno tu coś „odgadnąć”. W najlepszy scenariusz Może istnieć opcja, w której Twój program działa tylko z absolutnie poprawnymi danymi. Zwykle Klient nie wyraża na to zgody, ale możesz spróbować.
Przykładowo: Program musi współpracować z zadaną rozszerzoną macierzą zdarzeń badanego wykresu zgodnie z algorytmem działania, generować komunikaty o błędach w przypadku nieprawidłowego podania danych początkowych oraz wspierać tryb interaktywny w ramach możliwości udostępnionych użytkownikowi.
Warunki użytkowania. Należy podać warunki pracy (temperatura otoczenia, wilgotność względna itp. dla wybranych rodzajów nośników danych), które muszą zapewniać określone właściwości, a także rodzaj usługi, wymagana ilość i kwalifikacje personelu.
Zwykle nie ma z tym żadnych trudności. Niestety klauzula o profesjonalizmie użytkownika przez Klienta jest koniecznie dorozumiana. Jest to oczywiście kolejny powód, aby znaleźć błąd w programie. Jednak tutaj możemy ograniczyć się do sformułowań typu „Warunki działania programu pokrywają się z warunkami pracy komputera IBM PC i komputerów z nimi kompatybilnych”, „Program powinien być przeznaczony dla użytkownika nieprofesjonalnego”. itp.
Wymagania dotyczące składu i parametrów środków technicznych. wskazać wymagany składśrodki techniczne wskazujące ich właściwości techniczne.
Najważniejsze, żeby z jednej strony o niczym nie zapomnieć i o wszystko zadbać (w przeciwnym razie wsuną się tam jakiś IBM PC/XT z monochromatycznym wyświetlaczem i bez myszki), a z drugiej strony, żeby nie przesadzić z podwyższonymi wymaganiami, w przeciwnym razie Klient znajdzie bardziej elastycznego Wykonawcę.
Na przykład: Musisz mieć komputer PC kompatybilny z IBM PC z kartą graficzną EGA (VGA). Wymagane miejsce na dysku to co najmniej 600 KB, czyli ilość wolnego miejsca BARAN- co najmniej 400 KB. Pożądane jest posiadanie sterownika EMS i manipulatora typu mysz.
Wymagania dotyczące kompatybilności informacji i oprogramowania. Funkcje są takie same jak w poprzednim akapicie. W tym miejscu należy określić wymagania dotyczące struktur informacyjnych na wejściu i wyjściu oraz metod rozwiązania, kodów źródłowych i języków programowania. Tam, gdzie jest to konieczne, należy zapewnić ochronę informacji i programów.
Przykład: Program musi pracować autonomicznie pod systemem operacyjnym MS DOS w wersji nie niższej niż 3.3. Podstawowym językiem programowania jest Turbo Pascal 6.0.
Wymagania dotyczące etykietowania i pakowania oraz wymagania dotyczące transportu i przechowywania są dość egzotyczne. W przypadek ogólny tutaj należy wskazać wymagania dotyczące oznakowania oprogramowania, możliwości i metod pakowania. Wymagania dotyczące transportu i przechowywania muszą określać warunki transportu oprogramowania, miejsca przechowywania, warunki przechowywania, warunki przechowywania, okresy przechowywania w różnych warunkach.
Specjalne wymagania są bardzo ważną rzeczą. Jeśli to możliwe, lepiej ich unikać. I od razu to ogłoś.
Na przykład: Nie ma specjalnych wymagań dotyczących charakterystyki czasowej programu. Nie ma specjalnych wymagań dotyczących charakterystyki pojemnościowej programu.
Wskaźniki techniczne i ekonomiczne. Ten najtrudniejszy punkt dla programisty nie zawsze występuje. Jest ono potrzebne przede wszystkim wtedy, gdy Twoim celem jest uzasadnienie ogromnej efektywności i wagi wykonywanej pracy. Ten element zwykle działa bardzo dobrze dla Klienta. Jest to przynajmniej najlepsze uzasadnienie harmonogramu i kwot pieniężnych rozwoju.
Ta sekcja powinna wskazywać: przybliżone efektywność ekonomiczna, szacunkowe roczne zapotrzebowanie (na przykład: przewidywana liczba połączeń do kompleksu jako całości w ciągu roku - 365 sesji roboczych), zalety ekonomiczne opracowania w porównaniu z najlepszymi próbkami lub analogami krajowymi i zagranicznymi.
Ponadto wskazane jest podanie definicji zarówno szacunkowego kosztu opracowania programu, jak i definicji złożoności programowania.
Etapy i fazy rozwoju (zostanie to omówione bardziej szczegółowo poniżej) określają niezbędne etapy rozwoju, etapy i treść pracy (lista dokumentów programowych, które należy opracować, uzgodnić i zatwierdzić), a także zasady, terminy opracowania i określenie wykonawców.
Standardowe kroki opisano tutaj. Najważniejsze jest prawidłowe określenie czasu. Jeśli to możliwe, staraj się równomiernie rozłożyć etapy pomiędzy terminami (i kwotami). Pamiętaj, że nie wszystkie projekty przetrwają ostatni etap. I powinny być raporty z każdego etapu. Pamiętaj też, że projekt pracy zajmie najwięcej czasu. Jeżeli nie skompletujesz dokumentacji w terminie, Zleceniodawca ma prawo w ogóle nie przyjąć pracy ze wszystkimi tego konsekwencjami.
Głównymi i niezbędnymi etapami i krokami są same warunki zamówienia, projekt wstępny, projekty techniczne i wykonawcze.
Projekt projektu. Na tym etapie szczegółowo opracowywane są struktury danych wejściowych i wyjściowych oraz ustalana jest forma ich prezentacji. W fazie rozwoju opis ogólny algorytm, sam algorytm, struktura programu. Trwa opracowywanie planu działania dotyczącego opracowania i wdrożenia programu.
Projekt techniczny. Zawiera opracowany algorytm rozwiązania problemu oraz metody monitorowania informacji początkowych. Tutaj opracowywane są narzędzia do przetwarzania błędów i wystawiania komunikatów diagnostycznych, ustalane są formularze prezentacji danych wyjściowych oraz konfiguracja środków technicznych.
Projekt roboczy. Na tym etapie przeprowadzane jest programowanie i debugowanie programu, opracowywanie dokumentów programowych, programów i metod testowania. Przygotowywane są przykłady testów i debugowania. Dokumentacja i materiał graficzny są już gotowe. Zwykle określa się, że podczas tworzenia programu należy przygotować następującą dokumentację:
Tekst programu;
Opis programu;
Program i metodologia testów;
Opis aplikacji;
Instrukcja obsługi.
To są standardowe wymagania. Jeśli Klient zgadza się, że nie cała ta lista może zostać przedstawiona, oznacza to, że jego intencje dotyczące Ciebie i Twojego produktu nie są poważne.
Może nie być żadnego materiału graficznego. Zwłaszcza, gdy nie zamierzasz raportować wyników swojej pracy. Ale w przypadku poważnych projektów ten przedmiot jest wymagany.
Przykładowo: Podczas tworzenia programu należy przygotować następujący materiał graficzny:
Wskaźniki techniczne i ekonomiczne;
Struktura programu;
Format prezentacji danych wejściowych programu;
Ogólny schemat algorytmu (2 arkusze);
obasiczne algorytmy obliczeniowe;
Przykład działania programu.
Sekcja „Procedura kontroli i akceptacji” musi wskazywać rodzaje testów i wymagania ogólne o przyjęcie pracy. Jeśli to możliwe, w tym akapicie wskaż, że „kontrola i akceptacja opracowania odbywa się przy użyciu sprzętu dostarczonego przez Klienta”, w przeciwnym razie może być wymagane zabranie ze sobą sprzętu.
Przykładowo: Kontrola i akceptacja rozwoju odbywa się na podstawie przykładów testowania i debugowania. Sprawdza to wykonanie wszystkich funkcji programu.
W załącznikach do specyfikacji technicznych, jeśli to konieczne, podano co następuje:
wykaz badań i innych prac uzasadniających rozwój;
Diagramy algorytmów, tabele, opisy, uzasadnienia, obliczenia i inne dokumenty, które można wykorzystać podczas opracowywania;
Inne źródła rozwoju.
W podsekcji „Wymagania dotyczące kompatybilności informacji i oprogramowania” należy wskazać wymagania dotyczące struktur informacyjnych na wejściu i wyjściu oraz metod rozwiązywania, kodów źródłowych, języków programowania i oprogramowania używanego przez program. Tam, gdzie jest to konieczne, należy zapewnić ochronę informacji i programów.
Przykład. Na komputerze musi działać system operacyjny nie starszy niż Windows 98/NT 4.0. Wymóg zgodność informacji należy zapewnić, pracując z plikami informacji geometrycznych o określonej konstrukcji jako informacjami wejściowymi i wyjściowymi.
Koniec pracy -
Ten temat należy do działu:
Technologia tworzenia oprogramowania
Na stronie przeczytaj: "Technologia tworzenia oprogramowania"...
Jeśli potrzebujesz dodatkowy materiał na ten temat lub nie znalazłeś tego, czego szukałeś, polecamy skorzystać z wyszukiwarki w naszej bazie dzieł:
Co zrobimy z otrzymanym materiałem:
Jeśli ten materiał był dla Ciebie przydatny, możesz zapisać go na swojej stronie w sieciach społecznościowych:
| Ćwierkać |
Wszystkie tematy w tym dziale:
Wymagania funkcjonalne
Podsekcja „Wymagania dotyczące cech funkcjonalnych” musi wskazywać wymagania dotyczące składu wykonywanych funkcji, organizacji danych wejściowych i wyjściowych oraz charakterystyk czasowych
Umowa dotycząca wymagań
Stworzenie umowy dotyczącej wymagań jest celem drugiej części pierwszego laboratorium. Uzgodnienie wymagań stanowi także drugą część pracy kursu.
Poniżej znajduje się op.
Krótki opis produktu Opisane krótko i koncepcje ogólne
główne właściwości funkcjonalne produktu. Jeśli oprogramowanie jest rozszerzeniem istniejącego produktu, scharakteryzowane są jedynie jego nowe funkcje.
Powstałe składniki produktu
W tej sekcji przedstawiono tabelę podobną lub równoważną tabeli 2.1. W tym przypadku stosuje się wstępnie przygotowany drukowany formularz, co skraca czas przygotowania informacji.
Odrzucone wnioski Jeśli celem jest przeróbka lub ulepszenie produktu albo zastąpienie produktu znanymi błędami, należy zaplanować naprawę błędów wykrytych w produkcie. w tej chwili
czas. Dlatego w tym momencie
Wykluczone elementy planu
Jeśli istnieją instrukcje planowania wymagające specjalnych funkcji i możliwości oprogramowania, których nie można zapewnić, jeśli produkt zostanie opracowany zgodnie z innymi wymaganiami
Jeżeli potrzebę stworzenia produktu uzasadnia dokument taki jak plan wydania produktu, plan wydania serii czy opis zadania, wówczas przytacza się albo konkretny fragment każdego dokumentu, albo
Lista wymagań użytkownika
Wskazani są klienci produktu i wyjaśnione, dlaczego go potrzebują. W tej części podano również przewidywany okres użytkowania produktu. Zwykle będzie to okres użytkowania sprzętu
Rozważane alternatywy
Pokrótce opisano alternatywy dla tego projektu, które zostały rozważone i odrzucone, a także powody odrzucenia. Jeśli programy muszą zostać zakupione, wyjaśniono, dlaczego tak nie jest
Zwrot z inwestycji
Zysk, jaki przyniesie stworzenie produktu, określa się w kategoriach odpowiadających zamierzony cel organizacje.
Przykład. ABC Services spodziewa się, że sprzedaż w Finlandii będzie taka sama
Oprogramowanie systemowe Systemowe oprogramowanie - to całe inne oprogramowanie, w tym systemy operacyjne, kompilatory, narzędzia, pakiety programy aplikacyjne
itp. To oprogramowanie
Ogólna charakterystyka funkcji
Należy potraktować cały produkt jako jeden moduł funkcjonalny, tak aby ilość podsekcji była niewielka. Jeśli nie da się odpowiednio opisać produktu bez rozbicia go na osobne funkcjonalności
Ograniczenia zewnętrzne
Wymienione są wszystkie ograniczenia, których zakres jest szerszy niż zakres ST; Obejmuje to na przykład ograniczenia branżowe lub dotyczące linii produktów. Może być dozwolone
Ograniczenia kompatybilności
Należy zawsze wziąć pod uwagę kilka aspektów kompatybilności: język źródłowy, język maszynowy, formaty danych i komunikatów, formaty raportów, formaty list i formaty języka kontroli zadań (JL).
Ograniczenia oprogramowania
Wskaż, jeśli to konieczne, system operacyjny, z którym proponowane oprogramowanie powinno współpracować, a także inne oprogramowanie, z którym powinno zostać połączone w procesie
Ograniczenia sprzętowe
Dołączona jest tabela urządzeń wykorzystywanych w działaniu oprogramowania. Dla każdego urządzenia wskazana jest wymagana liczba minimalna, nominalna i maksymalna. Wartość nominalna jest optymalna
Wyniki pracy
Wszystkie dane wyjściowe oprogramowania lub modułu funkcjonalnego są opisane pod kątem ich zawartości i przeznaczenia - raporty, pliki, rekordy, pola danych, komunikaty, tabele, pola wyboru. Powinien
Opisuje operacje wykonywane przez oprogramowanie, które jest traktowane jako całość lub moduły funkcjonalne jako czarna skrzynka (lub zestaw czarnych skrzynek). Przynajmniej po zainstalowaniu
Niezawodność
Niezawodność oprogramowania odnosi się do zdolności do odzyskiwania normalne działanie w przypadku błędów i awarii sprzętu. Ochrona danych użytkowników jest sprawą najwyższej wagi. DC
Uruchom ponownie
Wskazano możliwości, które zapewniają zapisanie danych i ich wykorzystanie podczas wznawiania pracy po awaryjnej przerwie, na przykład podczas ponownego uruchamiania z punktu kontrolnego.
Przykład 1. Program
Spełnienie wymagań klienta
Określono właściwości, które umożliwiają produktowi programowemu lub jego wynikowi spełnienie określonych wymagań. Jeśli to możliwe, wyświetla listę modułów, które mogą nie spełniać wymagań.
Charakterystyka wydajności
Podano główną zmienną lub podstawową zasadę, według której należy mierzyć skuteczność programu; określa odpowiednią wartość lub zakres wartości dla tej zmiennej. gl
Łatwość użycia
Opisano właściwości, które sprawiają, że interakcja „człowiek-maszyna” jest wygodna dla człowieka. Przykładami są dowolny format wejściowy, tryb dialogowy, możliwa zgodność składniowa
Łatwość konserwacji
Opisano środki zapewniające identyfikowalność modułów, jeśli norma nie uwzględnia tego problemu.
Przykład 1. Każdy moduł źródłowy i obiektowy zostanie dostarczony z szyfrem programowym
Ponowne uruchomienie interfejsu użytkownika
Przykład. Stan systemu wszystkich aktywnych użytkowników (również tych odłączonych, ale nadal obsługiwanych) jest okresowo zapisywany na dysku (w odstępie czasu określonym w definicji czasów
Funkcje interfejsu użytkownika
Przykład. Zakładając, że na komputerze wykonywany jest tylko ASK i że parametr odzyskiwania charakteryzuje się jednym punktem kontrolnym na minutę, każde polecenie musi zostać wykonane lub
Zakres interfejsu użytkownika
Przykład. W typowej sesji z ASK użytkownik bez doświadczenia programistycznego łączy się z systemem za pomocą terminala i wchodzi w dialog, w którym definiuje:
Wskaż, jeśli to konieczne, system operacyjny, z którym proponowane oprogramowanie powinno współpracować, a także inne oprogramowanie, z którym powinno zostać połączone w procesie
Przykład. Oprócz urządzeń potrzebnych do VSOS ILSAM (patrz sekcja 2.4.1, b i c), procesor korekcji będzie potrzebował urządzeń wymienionych w tabeli 2.3.
Tabela 2.3 – Urządzenia
Ograniczenia wewnętrzne
Ważne jest, aby określić nie tylko, jaki produkt będzie, ale także czym nie będzie. Ograniczenie to cecha (lub możliwość), której użytkownik logicznie by się spodziewał, ale która
Dokumenty referencyjne
Każdy dokument planistyczny lub techniczny, o którym mowa w ST, jest wskazany osobno. Każdy taki dokument musi faktycznie istnieć (a nie być sugerowany w przyszłości) i
Zasoby wspierające wdrożenie
Określane są zasoby niezbędne do zainstalowania systemu oraz zasoby opisane w punkcie 2.5.3 (mam tu na myśli czas maszynowy, koszty pracy i niezbędne kwalifikacje).
Nośniki pamięci
Rodzaj urządzeń pamięci masowej jest określany dla wszystkich rozproszonych komponentów oprogramowania (na przykład taśma magnetyczna, charakteryzująca się liczbą ścieżek i gęstością zapisu
Wymagane relacje Określono wymagania stawiane przez to oprogramowanie innym projektom lub funkcjom. Dany krótki opis
każdego wymagania i wskazuje etap, na którym można je ustalić
Obsługiwane połączenia wzajemne
Ta sekcja ma podobną strukturę do poprzedniej, ale zawiera wymagania nałożone przez inne produkty na ten produkt. Każde wymaganie z sekcji 2.6.1.2 musi być spełnione przez wymaganie
Komisja Audytu Technicznego
Każdy ST powinien zalecić utworzenie komisji audytu technicznego (TRC), wskazując miejsce pracy każdego członka komisji i jego imię i nazwisko, jeśli to możliwe, a także powołanie
Poziomy testowe
Testowanie programów można podzielić na trzy etapy, przeprowadzić w trzech trybach i podzielić na dziesięć kategorii (patrz rozdział 5 „Testowanie”). Informacje te są prezentowane w formie tabeli. Dla ka
Standardy dla porównania
Określa się systemy odniesienia, względem których należy dokonać porównania. Charakterystyki tego systemu są podawane w jednostkach względnych. Jeśli nie ma standardu do porównania
Zawiadomienie o zmianie dat kalendarzowych
Przykład. Nazwa projektu: Rozwój produktu ASK Kod projektu: C013. Kod produktu: L301A.
Nazwa produktu: ZAPYTAJ
Pisanie specyfikacji
Faza testowania stanowi zwykle połowę kosztów finansowych stworzenia systemu. Źle zaplanowane testowanie prowadzi do znacznego wydłużenia czasu rozwoju.
Organizacja testów oprogramowania
Testowanie nie oznacza debugowania, którego celem jest ustalenie, dlaczego w programie pojawia się konkretny błąd i wyeliminowanie jego przyczyn, ale proces ustalenia samego faktu istnienia defektów
Rodzaje testowania oprogramowania. Etapy testów
Generalnie badania przeprowadza się w kilku etapach oddzielonych czasem.
Pierwszy etap obejmuje testy klasy A, które przeprowadzane są na koniec fazy programowania.
Tryby testowe programu
Testy różnią się w zależności od tego, kto je przeprowadza. Główną ideą jest niezależność funkcji testującej od funkcji programistycznej.
Tryb testowy oznacza, że został ukończony
Kategorie testowania oprogramowania
Etapy testu wskazują, kiedy testy są przeprowadzane, a tryby określają, kto przeprowadza testy. Kategorie testów określają charakter i cel testów. Przemyślany podział i
Technologia testowania, klasy równoważności
Jednym ze sposobów zbadania tego pytania jest zbadanie strategii testowania zwanej testowaniem czarnej skrzynki, testowaniem opartym na danych lub testo.
Testy budowlane
Proces konstrukcji testu obejmuje: 1) przypisanie każdej klasie równoważności unikalnego numeru;
2) projektowanie nowych testów, z których każdy obejmuje
Postanowienia ogólne 1.1. Strukturę i format dokumentu ustala się zgodnie z GOST 19.105-78. 1.2. Podręcznik programisty systemu powinien zawierać następujące sekcje: –
Struktura programu
Program „Automatyczny miejsce pracy czytnik” składa się z następujących komponentów: 1) zcon – aplikacja realizująca funkcje klienta Z39.50; 2) zgate -CGI- Instalowanie programu
W tym dokumencie do nadawania nazw plikom używana jest składnia zdefiniowana w normie ISO/IEC 9945-1. W tamtych
systemy operacyjne
, które nie obsługują
określoną metodę nazewnictwo plików w aplikacjach Sprawdzanie programu Program sprawdzany jest pod kątem sposobu jego wykonania. Ze względu na to, że specyficzne warunki korzystania z programu (adresy serwerów Z39.50, nazwy baz danych, obsługiwane punkty
Wiadomości do programisty systemu
Tabela 5.1 przedstawia komunikaty, które można odebrać programista systemowy podczas konfiguracji, testowania programu, a także użytkownika podczas wykonywania programu.
System oprogramowania musi zapewniać ochronę danych przed przypadkowym usunięciem i modyfikacją. Dostęp do danych powinien mieć wyłącznie upoważniony administrator bazy danych lub pracownik naukowy, który jest zalogowany na serwerze bazy danych i ma odpowiednie role.
Aby system szkoleniowy był niezawodny, musi spełniać następujące wymagania:
opracowany program musi posiadać środki zabezpieczające przed błędnymi działaniami użytkownika;
wszystkie błędy powinny być wyświetlane z komentarzami lub wskazówkami dotyczącymi ich usunięcia;
gwarantują bezpieczeństwo danych na wypadek awarii w działaniu urządzeń zewnętrznych.
Aby poprawić niezawodność, należy podjąć następujące środki:
konfigurować sprzęt i oprogramowanie zgodnie z wymaganiami technicznymi;
okresowo twórz kopie zapasowe informacji;
regularnie sprawdzaj integralność bazy danych;
Utrzymuj dobry stan sprzętu sieciowego.
Wymagania dotyczące składu i parametrów środków technicznych
Minimalna konfiguracja sprzętowa systemu zapewniająca normalne funkcjonowanie systemu szkoleniowego nie może być niższa niż:
RAM 128 MB lub więcej.
Co najmniej 150 MB wolnego miejsca na dysku twardym.
Wymagania dotyczące komputera wykorzystywanego do opracowywania konfiguracji:
Procesor AMD Athlon 900 MHz lub wyższy.
RAM 256 MB lub więcej.
Co najmniej 250 MB wolnego miejsca na dysku twardym.
W przypadku korzystania ze zautomatyzowanego systemu w sieci lokalnej, na jednym z komputerów musi być zainstalowany i uruchomiony serwer Firebird 1.5.3 z preinstalowaną bazą danych. Na innych komputerach należy zainstalować aplikację kliencką systemu rozliczania sprzętu.
Wymagania dotyczące kompatybilności informacji i oprogramowania
Aby móc korzystać z oprogramowania, potrzebne są następujące komponenty:
System operacyjny z rodziny Microsoft®Windows® (co najmniej 2000).
Zainstalowane i skonfigurowane oprogramowanie MicrosoftSQLServer, IBExpert2004, Borland®C++Builder™ 6.0, Microsoft.NETFrameworkSDKv2.0.
warunki użytkowania
Program musi być wykonany na działającym sprzęcie. Wymagania dotyczące warunków pracy komputera PC i innego sprzętu wykorzystywanego w kompleksie określone są w dokumentach technicznych zawartych w pakiecie dostaw urządzeń.
Wymagania dotyczące dokumentacji oprogramowania
Dokumentacja programu powinna zawierać następujące dokumenty.
Podręcznik administratora systemu.
Przewodnik nauczyciela.
Przewodnik ucznia.
Podręcznik administratora systemu powinien zawierać opisy funkcji konfiguracyjnych tego systemu.
System oprogramowania musi zawierać kompletny podręcznik instruktorski opisujący scenariusze pracy instruktora.
System oprogramowania musi zawierać kompletny podręcznik ucznia opisujący scenariusze pracy ucznia.
Etapy rozwoju systemu oprogramowania
Rozwój systemu oprogramowania powinien przebiegać w następujących etapach.
opracowanie planu wdrożenia;
opracowanie planu testów;
opracowanie planu wdrożenia.
Projekt:
logiczne projektowanie architektury systemu oprogramowania;
opracowanie struktury bazy danych;
projekt interfejsu użytkownika.
Realizacja:
wdrożenie opracowanego interfejsu użytkownika;
realizacja głównych funkcji systemu oprogramowania.
Testowanie systemu:
badania strukturalne;
testy funkcjonalne;
poprawki błędów i ulepszenia.
Wdrożenie systemu:
sprawdzanie dostępności niezbędnego sprzętu;
instalacja systemu;
szkolenie personelu.
Konserwacja systemu.
Na życzenie klienta oprogramowanie to jest rozwijane na platformę Windows. Program musi działać pod głównymi wersjami tej platformy: Windows98, Windows 2000, Windows XP. Ponadto część serwerowa programu dla wersji WinNT powinna działać jako usługa (działać w tle).
Konieczne jest zapewnienie możliwości dalszego rozszerzania funkcji systemu (otwartość na rozwój i sposoby łączenia nowych zadań).
Wymagania dotyczące transportu i przechowywania
Opracowywany system zarządzania będzie dostarczany w formie zestawu po sprzedaży kontrolera RAID. Musi być nagrany na osobnej płycie CD, która będzie zawierała sterowniki systemowe oraz niezbędną dokumentację do sprzedawanego sterownika. W tym celu należy upewnić się, że rozmiar plików instalacyjnych nie przekracza około 2/3 standardowej płyty CD (700 MB).
Specjalne wymagania
Część serwerowa programu analizująca działanie RAID musi zawsze działać na komputerze z systemem RAID. Jeżeli moduł ten zostanie wyłączony, to bez niego nie będzie możliwe połączenie się z systemem RAID i monitorowanie pracy RAID (wysyłanie powiadomień o usterkach oraz przechowywanie plików historii działania RAID).
Schemat blokowy programu
Cały projekt oprogramowania opiera się na dwóch niezależnych modułach. Jak już wspomniano, jeden z nich działa osobno na komputerze z systemem RAID, a drugi na komputerze administratora. Dla zwięzłości nazwiemy pierwszy moduł Agent, a drugie – Menedżer.
Menedżer– strona użytkownika programu, która zawiera interfejs programu, kreator pierwszej instalacji oraz sekcję pomocy. Menedżer będzie zarządzać systemem RAID poprzez Agent.
Agent służy głównie do przesyłania poleceń z Menedżer w systemie RAID i odwrotnie. Również Agent będzie monitorować RAID (prowadzić plik dziennika) i powiadamiać administratora w przypadku błędów.
Internet
Ryż. 1.2. Podstawowa struktura programu GUIRAIDManager
Podstawową strukturę całości pracy przedstawiono na ryc. 1.2. Pokazuje różne opcje działania obu modułów. Agent I Menedżer:
Agent(C3 ) jest uruchamiany na komputerze i analizuje działanie macierzy RAID R2 ;
Menedżer Z komputer zdalny (C2 Lub C4) można podłączyć poprzez sieć do A dżentelmen(C3) do kontrolowania działania macierzy RAID R2 ;
Menedżer I Agent uruchamiany na jednym komputerze C1 w celu sterowania pracą macierzy RAID R2 . Dzięki tej opcji nie jest wymagane połączenie sieciowe.
Struktura danych wejściowych i wyjściowych
Główna wymiana danych w całym systemie odbywa się dwoma kanałami:
między Menedżer I Agent przez sieć przy użyciu protokołu TCP/IP (polecenia Menedżer i odpowiedzi Agent);
między Agent i kontrolerem RAID poprzez interfejs RS-232 (odpytywanie kontrolera i odpowiedzi z niego).
Ogólny schemat wymiany danych w projekcie ilustruje rys. 1.3.
Ryż. 1.3. Wymiana danych w programie GUIRAIDManager
Format danych pomiędzy Menedżer I Agent, a także pomiędzy Agent i kontrolera RAID opisano w paragrafie „Format danych modułu Agent» tej sekcji.
Moim zadaniem w tym projekcie jest opracowanie modułu Agent. Przyjrzyjmy się zatem bliżej wymianie danych w module Agent między Menedżer i kontroler RAID. Struktura modułowa Agent pokazany na ryc. 1.4
Ryż. 1.4. Wymiana danych w module Agenta
Ten diagram pokazuje, że dane pomiędzy Menedżer I Agent przechodzić przez moduł do odbierania i przesyłania danych przez sieć. Aby sprawdzić połączenie Menedżer moduł ten wykorzystuje blok autoryzacyjny. Wszystkie odebrane dane są analizowane w bloku procesora poleceń Menedżer. W zależności od rodzaju polecenia informacja trafia albo do bloku ustawień, do bloku pliku historii, albo do modułu odpytywania stanu RAID. Ten ostatni służy do wysyłania poleceń do kontrolera RAID i otrzymywania od niego odpowiedzi. Jeżeli w trakcie żądania wystąpi błąd lub odpowiedź kontrolera będzie zawierała komunikat krytyczny, moduł powiadomień powiadomi administratora o tym błędzie.