Software Configuration Management System (SCMS)

Wizja

Wersja 2.0

Historia Wersji

Date	Version	Description	Author
16/06/2003	1.0	Pierwsza wersja Wizji	Artur Zagoździński, Michał Kruk, Andrzej Biesiadecki, Bartłomiej Pióro
12/7/2003	2.0	Zaktualizowana wersja.	Artur Zagoździński

Spis Treści

1. Wstęp 1

1.1 Cel 1

1.2 Zakres 1

1.3 Definicje, Akronimy I Skróty 1

1.4 Referencje 1

1.5 Przegląd 1

2. Lokalizacja 1

2.1 Możliwości Biznesowe 1

2.2 Dziedzina Problemowa 2

2.3 Status Pozycji Produktu 2

3. Charakterystyka Udziałowców I Użytkowników Systemu 2

3.1 Demografia Rynku. 3

3.2 Charakterystyka Udziałowców Systemu 3

3.3 Charakterystyka Użytkowników Systemu 3

3.4 Środowisko Użytkowników 3

3.5 Kluczowe Potrzeby Użytkowników Systemu. 4

3.6 Alternatywy I Konkurencja 4

4. Przegląd Produktu 5

4.1 Perspektywa Produktu 5

4.2 Architektura Systemu 5

4.3 Założenia I Zależności 7

5. Wymagania Funkcjonalne 7

5.1 Logowanie Do Systemu 7

5.2 Przydzielenie Poziomu Dostępu Dla Użytkownika, Zespołu i Pozycji Administracyjnej 7

5.3 Tworzenie Kopii Zapasowych 7

5.4 Rejestracja Testów 7

5.5 Rejestracja Wdrożenia Zmiany 7

5.6 Wprowadzanie Raportów Okresowych (WAU) 7

5.7 Zgłoszenie, Zapoznanie Się I Zakwalifikowanie Problemu 7

5.8 Administracja 8

5.9 Zarządzanie Pozycjami Administracyjnymi 8

5.10 Zarządzanie Użytkownikami 8

5.11 Zarządzanie Zespołami 8

5.12 Zarządzanie Projektami 8

5.13 Narzędzie Analityczne : Naniesienie Zmian I Określenie Pracochłonności 9

6. Ogranieczenia 9

Wizja

1. Wstęp

1.1 Cel

Celem tego dokumentu jest zbiór, analiza i definicja wymagań wysokiego poziomu związanych z Systemem Zarządzania Konfiguracją Oprogramowania. Uwagę skupiono na aspektach Systemu związanych z jego główną funkcjonalnością. Szczegółowy ich opis znajduje się w poszczególnych specyfikacjach przypadków użycia.

Powodem powstania wersji 2.0 Wizji Systemu SCMS jest dopasowanie go do zbudowanego modelu analitycznego, oraz opracowanych specyfikacji przypadków użycia. W wyniku studium osiągalności zrezygnowano z niektórych funkcjonalności Systemu (np. związanych z Knowledge Management) uwzględnionych w wersji 1.0 Wizji.

1.2 Zakres

Dokument ten stanowi punkt wyjściowy dla zestawu specyfikacji przypadków użycia, oraz modelu analitycznego klas, stworzonych na potrzeby Systemu SCMS. Przy opracowywaniu wersji 2.0 użyto narzędzi wspomagających definicję, organizację i zarządzanie wymaganiami, takich jak Rational Administrator Ž, czy Rational RequisitePro Ž. Wersja 2.0 zmodyfikowana została na skutek prac grupy Analityczno – Projektowej, jako że wraz z zamknięciem wstępnej fazy definicji wymagań co do Systemu SCMS, grupa Definicji Wymagań przestała istnieć.

1.3 Definicje, Akronimy I Skróty

Pojęcia będą zebrine w Słowniku Pojęć, będącym oddzielnym dokumentem.

1.4 Referencje

1. Wizja Systemu SCMS wersja 1.0

2. Specyfikacje Przypadków Użycia

1.5 Przegląd

W pozostałej części dokumentu znajdują się opisy lokalizacji Systemu, charakterystyka potencjalnych użytkowników, oraz aktorów Systemu, oraz opis wymagań funkcjonalnych stawianych Systemowi.

2. Lokalizacja

2.1 Możliwości Biznesowe

Dynamika rynku wytwarzania oprogramowania wiąże się między innymi z koniecznością zapewnienia efektywnego zarządzania zarówno procesem tworzenia produktu, jak i późniejszymi jego modyfikacjami. Szybki postęp w zakresie technologii komputerowych, rosnąca konkurencja, zakres realizowanych projektów, czy rotacja pracowników to tylko niektóre czynniki stanowiące poważne zagrożenie dla utrzymania atrakcyjnego poziomu świadczonych usług. Firmy developerskie muszą więc inwestować w opracowanie takiej organizacji pracy, która pozwoli im w jak największym stopniu uniezależnić się od zagrożeń specyficznych dla rynku.

Istnieje cały szereg narzędzi i technologii, które mogą znacznie zwiększyć wydajność firm produkujących oprogramowanie a co za tym idzie - jakość oferowanych przez nich usług. Takim narzędziem jest oferowany przez nas SCMS (Software Configuration Management System). Sprawne zarządzanie artefaktami, szacowanie kosztów zmian i szybkość podejmowania słusznych decyzji ma duży wpływ na koszty ponoszone przez firmy co sprawia, że SCMS jest narzędziem bardzo atrakcyjnym.

2.2 Dziedzina Problemowa

Problem	Potrzeba zapewnienia narzędzi wspomagających proces wytwarzania oprogramowania, oraz takiej organizacji i zarządzania wytworzonymi artefaktami, które pozwolą na swobodną ich modyfikację i szacunek kosztów, bez względu na upływ czasu, czy zmianę kadry.
Dotyczy	Organizacji wytwarzających oprogramowanie.
Pod wpływem którego	Bardzo kosztowny i czasochłonny staje się proces wytwarzania oprogramowania, oraz szacowania kosztów i wprowadzania zmian jakie należy wykonać w istniejących projektach informatycznych.
Udane rozwiązanie	Udostępni narzędzia wspomagające efektywną organizację pracy przy realizowanych projektach, oraz pozwoli swobodnie zarządzać późniejszym wprowadzaniem zmian i szacunkiem ich kosztów.

2.3 Status Pozycji Produktu

Dla	Firm wytwarzających oprogramowanie średniej i dużej wielkości.
Które	Potrzebują narzędzia wspomagającego organizację procesów wytwórczych, oraz zarządzanie zmianami, które są dokonywane w wytwarzanych artefaktach.
SCMS (Software Configuration Management System)	Jest narzędziem wspomagającym funkcjonowanie firm wytwarzających oprogramowanie.
Które	Ułatwia sprawną organizację pracy przy realizowanych projektach, oraz pomoże efektywnie oszacować koszty zmian i w bezpieczny sposób zmiany te wprowadzić.
W odróżnieniu	Od obecnie używanych technik organizacji pracy i szacowania kosztów zmian w oprogramowaniu, opierających się w wielu przypadkach na ręcznej kontroli wymienionych wyżej aspektów.
Nasz produkt	Pozwoli efektywnie zorganizować pracę nad bieżącymi projektami. Zapewni sprawne zarządzanie posiadanymi przez firmę artefaktami, wspomoże proces szacowania kosztów zmian jakie należy wykonać w istniejących artefaktach.

3. Charakterystyka Udziałowców I Użytkowników Systemu

Z założenia - Organizacją Docelową jest firma wytwarzająca oprogramowanie. Przeznaczeniem Systemu jest dostarczenie narzędzi wspomagających organizację procesów wytwórczych, oraz późniejszym zarządzaniem zmianami nanoszonymi na istniejące produkty.

W przypadku projektu Systemu SCMS nie istnieją rzeczywiści Udziałowcy Systemu. Potencjalnymi Użytkownikami natomiast będą wszystkie osoby bezpośrednio związane z realizacją projektów Organizacji Docelowej, oraz osoby zaangażowane w zgłoszenie, analizę, szacunek kosztów, oraz wprowadzenie zmian do istniejących produktów.

3.1 Demografia Rynku.

Rynek docelowy charakteryzuje się dużą dynamiką. Związane jest to bezpośrednio z szybkim rozwojem technologii stosowanych zarówno w obszarze działalności Organizacji Docelowej, jak i w obszarach biznesów firm, do których Organizacja Docelowa adresuje własne produkty. Pomimo obecnej recesji obejmującej praktycznie cały rynek światowy, nie trudno jest przewidzieć stale rosnący popyt na usługi IT (w tym również Inżynierii Oprogramowania).

3.2 Charakterystyka Udziałowców Systemu

<Brak zastosowania>

3.3 Charakterystyka Użytkowników Systemu

Użytkownik	Opis
Użytkownik	Jest to każda z osób korzystających z Systemu SCMS. Może nim byc zarówno pracownik Organizacji, Ekspert zatrudniony na potrzeby konkretnego projektu, czy osoba z zewnątrz zgłaszająca problem dotyczący gotowego produktu.
Członek Zespołu Projektowego	Jak wskazuje nazwa, jest to osoba bezpośrednio zaangażowana w pracę nad realizowanym projektem, do którego realizacji używamy między innymi Systemu SCMS. Rola i uprawnienia tego Użytkownika ustalane są oddzielnie dla każdego projektu. Członkiem Zespołu Projektowgo może być zarówno pracownik Organizacji, jak i np. Ekspert Zatrudniony na potrzeby konkretnego projektu. Zakładamy, że zdarzenia będące następstwem zgłoszenia problemu i ewewntualnie wprowadzonej zmiany skutkują stworzeniem nowego projektu.
Manager	Reprezentuje użytkowników pochodzących ze szczebla zarządczego Organizacji. Osoba ta nie musi być bezpośrednio związana z żadnym ze zrealizowanych projektów.
Administrator	Jest to osoba odpowiedzialna za zarządzanie Systemem SCMS, na które składają się między innymi takie operacje, jak zarządzanie kontami użytkowników, tworzenie kopii zapasowych, itp.

3.4 Środowisko Użytkowników

Organizacja Docelowa zajmuje się Inżynierią Oprogramowania.

Większość aktywności związanych z jej wiodącą działalnością owocuje utworzeniem nowego projektu i obsadzeniem wymaganych do jego reallizacji ról Pracownikami Organizacji i/lub Ekspertami z zewnątrz.

Dwie główne aktywnośći to wytworzenie nowego produktu, oraz wprowadzenie zmiany do istniejącego produktu. Wprowadzenie zmiany poprzedzone może być zgłoszeniem problemu, zmianą technologii, potrzebą rozszerzenia funkcjonalności produktu, itp. Większość planowanych zmian wymaga analizy zawierającej między innymi szacunek kosztów wprowadzenia zmiany.

Każdy projekt jest unikalny pod względem liczby Członków Zespołu Projektowego, czasu realizacji projektu, kosztów z nim związanych, itp. Nie oznacza to jednak, że dwa, lub więcej projektów nie mogą mieć żadnych elementów wspólnych.

Przy realizacji projektu pracuje wiele osób – jenda osoba może należeć równocześnie do wielu Zespołów Projektowych.

Osoba będąca Członkiem Zespołu Projektowego dostaje unikalny zestaw uprawnień związanych z tym właśnie projektem.

3.5 Kluczowe Potrzeby Użytkowników Systemu.

Potrzeba	Priorytet	Dotyczy	Proponowane Rozwiązanie
Organizacja pracy przy realizacji projektów	Wysoki	Sprawnego i efektywnego zarządzania czasem wieloma równolegle realizowanymi projektami.	System SCMS pozwoli na łatwą i efektywną organizację zasobów zaangażowanych w realizację projektu, oraz powstałych w jego wyniku. Historia zdarzeń umożliwi identyfikację twórców artefaktów, pozwoli prześledzić przebieg prac nad realizacją projektu.
Analizy zgłaszanych problemów i wprowadzania zmian do istniejących produktów	Wysoki	Ograniczenia kosztów i czasu trwania analizy i wprowadzenia zmian.	Zależności pomiędzy konfiguracjami artefaktów, jak też ‘wycena’ złożoności artefaktów ułatiwą oszacowanie kosztów i pracochłonności wprowadzenia analizowanej zmiany. Identyfikacja twórców artefaktów podlegających zmianom może znacznie wpłynąć na ograniczenie czasu trwania wprowadzenia zmiany.

3.6 Alternatywy I Konkurencja

Rynek oferuje obecnie rozwiązania wspomagające zarówno organizację pracy, jak i szacunek kosztów zmian. Nie brakuje również (nawet darmowych) produktów nadzorujących zarządzanie wersjami i konfiguracją. Najczęściej są to jednak produkty skupiające się na jednym z powyższych aspektów, lub systemy o bardzo rozbudowanej strukturze i wielu funkcjonalnościach.

Pierwsza grupa produktów oferuje często zbyt ubogie rozwiązania, przez co wymagają uzupełnienia kolejnymi systemami. Organizacja staje przed problemem doboru zestawu narzędzi, otrzymując w rezultacie złożone środowisko, w którym ciężko zapewnić jest kompatybilność, łatwość użycia, czy wreszcie uchronić się przed stratą, lub nadmiarem przechowywanych informacji.

Drugą grupę stanowią rozbudowane systemy wymagające dużych nakładów finansowych związanych z analizą rzeczywistych potrzeb Organizacji, kupnem pakietu, dalszymi opłatami licencyjnymi i szkoleniami pracowników.

System SCMS ma stanowić ‘złoty środek’ oferując generyczne narzędzie wspomagające pracę Organizacji zajmujących się Inżynierią Oprogramowania, po przystępnej cenie.

4. Przegląd Produktu

4.1 Perspektywa Produktu

System SCMS jest samowystarczalnym produktem oferującym rozwiązanie typu ‘off-the-shelf’ dla Organizacji działających na rynku Inżynierii Oprogramowania. Łączy on w sobie następujące funkcjonalności :

- zapewnienie odpowiedniej organizacji pracy przy realizacji projektów,

- obsadzenie ról niezbędnych do realizacji projektu odpowiednimi pracownikami,

- zapewnienie mechanizmu zarządzania uprawnieniami do artefaktów,

- zapewnienie mechanizmu zarządzania wytworzonymi artefaktami i ich konfiguracjami,

- szacunek kosztów i pracochłonności planowanego naniesienia zmiany w konfiguracji,

- gromadzenie historii realizowanych projektów pozwalającej na identyfikację twórców artefaktów

4.2 Architektura Systemu

System będzie zbudowany w architekturze klient-serwer. Z tego względu wyróżniamy:

- część kliencka

- cześć serwerowa

Pomiędzy tymi częściami zaistnieje interfejs który będzie wspomniana warstwa funkcji i procedur.

Na część serwerową należy wybrać środowisko będące w stanie efektywnie i stabilnie obsłużyć współbieżny dostęp do danych, oraz zapewnić wymagany poziom bezpieczeństwa. W związku z tym, że najprawdopodobniej aplikacja będzie wykorzystywała środowisko .NET serwer powinien stać na Windows Server 3000, a jako system bazodanowy wybrać SQLSerwer 2000, który jest dedykowany i optymalizowany dla środowiska .NET.

Komponenty klienckie zostaną zrealizowane w postaci dynamicznych stron HTML dostępnych w sieci wewnętrznej Organizacji tzn. Intranet. Będzie możliwość również instalowania aplikacji interfejsowych, które również będą pełniły rolę klienta. Forma oraz funkcjonalności klienta uzależnione będą od uprawnień danego użytkownika.

Proponowane rozwiązanie: .NET (C#, ASP .NET, Visual Basic, C++).

Rysunek 1 - Struktura Logiczna

Rysunek 2 - Struktura Fizyczna

4.3 Założenia I Zależności

- Zastosowanie przeglądarki internetowej jako interfejsu użytkownika pozwoli uniezależnić się od platform sprzętowych stacji roboczych, jednak w celu przyśpieszenia i zoptymalizowania pracy będzie możliwość zainstalowania interfejsu lokalnego.

- Może zaistnieć sytuacja, w której klient nie posiada odpowiedniego zaplecza sprzętowego i/lub odpowiednio wykwalifikowanej kadry wsparcia informatycznego. Należy to uwzględnić w planach kosztorysów i specyfikacji wymagań co do obsługi / konserwacji systemu.

5. Wymagania Funkcjonalne

SCMS należy do grupy systemów wspomagających organizację pracy nad projektem i zarządzanie zmianami. Ważną funkcją systemu jest wspomaganie decyzji w sprawie nanoszenia zmian na istniejące już projekty.

Dostęp do wszystkich części systemu, oraz artefaktów przez niego zarządzanych jest oparty o system zabezpieczeń i praw dostępu.

5.1 FEAT1 Logowanie Do Systemu

Każdy z użytkowników musi zostać zidentyfikowany i zautoryzowany przez system.

5.2 FEAT2 Przydzielenie Poziomu Dostępu Dla Użytkownika, Zespołu i Pozycji Administracyjnej

System zapewnia wielopoziomowy i wielowymiarowy mechanizm przydziału i kontroli uprawnień oparty na modelu Ball-LaPadula.

5.3 FEAT3 Tworzenie Kopii Zapasowych

Użytkownicy z odpowiednim poziomem praw dostępu mają prawo dokonywania kopii zapasowej systemu na życzenie. W skład kopii zapasowej wchodzą wszystkie elementy systemu, które uległy zmianie od czasu instalacji SCMS (baza danych, pliki dyskowe).
System z definicji powinien przeprowadzać automatyczny proces tworzenia kopii w ściśle sprecyzowanym interwale czasowym (np. codziennie, co tydzień). System powinien umożliwiać dostosowanie wartości interwału do osobistych potrzeb klienta.

5.4 FEAT4 Rejestracja Testów

SCMS umożliwia przypisanie do każdego projektu zestawu testów i wyników tychże testów.

5.5 FEAT5 Rejestracja Wdrożenia Zmiany

Do każdego projektu istnieje możliwość wygenerowania raportu z wykonanych zmian. W skład takiego raportu wchodzą wszelkie informacje dotyczące dokonanej zmiany (zmienione moduły, pracochłonność, zaangażowanie fizyczne pracowników, testy i wyniki testów) oraz informacje dodatkowe dotyczące wdrożenia u klienta zmienionej wersji projektu.

5.6 FEAT6 Wprowadzanie Raportów Okresowych (WAU)

Każdy użytkownik co określoną ilość dni (standardowo tydzień) ma obowiązek złożenia raportu okresowego (WAU) na temat pracy wykonanej w trakcie danego okresu. Raport jest weryfikowany przez osobę umieszczoną wyżej w hierarchii danego projektu.

5.7 FEAT7 Zgłoszenie, Zapoznanie Się I Zakwalifikowanie Problemu

Pracownik/Użytkownik systemu ma możliwość zgłoszenia problemu dotyczącego istniejącego już oprogramowania. Zgłoszenie następuje poprzez podanie systemowi informacji tekstowej o zaistniałym problemie.

Użytkownik odpowiedzialny za fazę pielęgnacji/konserwacji systemu do którego został zgłoszony problem ma możliwość zapoznania się ze zgłoszonym problemem.

Na podstawie tych informacji może on:

a) Odrzucić zgłoszenie

b) Wygenerować raport dotyczący dodatkowego szkolenia dla użytkowników projektu (zgłoszenie problemu jest spowodowane niedostateczną znajomością użytkowanego systemu)

c) Wprowadzić dane dotyczące artefaktów/elementów systemu mogących ulec zmodyfikowaniu.

Na podstawie danych wprowadzonych w punkcie c system przeprowadza analizę i generuje raport na temat kontaminacji systemu (na skutek wprowadzonych zmian).

5.8 FEAT8 Administracja

Dla każdego elementu systemu (lub grupy funkcji systemu) powinien być dostępny odpowiedni moduł odpowiedzialny za zarządzanie tą częścią systemu. Jako zarządzanie rozumiemy modyfikowanie wprowadzonych już danych.

5.9 FEAT9 Zarządzanie Pozycjami Administracyjnymi

System pozwala wprowadzać, modyfikować i przechowywać dowolne pozycje administracyjne zarówno te wchodzące już w skład jakiegokolwiek projektu, jak i nowe nie będące jeszcze częścią żadnego projektu klienta.

SCMS służy także jako repozytorium elementów ponownego użycia. Z tego powodu przechowuje wszystkie dokumenty i pliki powiązane w jakikolwiek sposób z każdym artefaktem będącym elementem dowolnego projektu lub firmy. Przechowywane są także powiązania pomiędzy poszczególnymi artefaktami tworząc swoistą sieć zależności wykorzystywaną przez różne narzędzia analityczne dostępne w systemie.

5.10 FEAT10 Zarządzanie Użytkownikami

Jako standardową część systemu traktujemy moduł umożliwiający osobom o odpowiednio wysokim poziomie uprawnień na wprowadzanie/modyfikowanie wszelkich danych użytkowników mających wpływ na działanie systemu. Osoba z takimi uprawnieniami powinna mieć możliwość zmieniania haseł, uprawnień dostępu, jednakże nie powinna mieć wpływu na informacje skorelowane z projektami i artefaktami (dane takie są w gestii kierowników projektów).

5.11 FEAT11 Zarządzanie Zespołami

W SCMS podstawową jednostką organizacyjną jest zespół. Wszystkie operacje dotyczące projektów dokonywane są za pośrednictwem utworzonych zespołów projektowych. W skład każdego zespołu może wchodzić od 1 do teoretycznie nieskończonej liczby osób.
Zespoły projektowe oprócz powiązania z danym projektem pozwalają także na zidentyfikowanie typów i rodzajów zadań którymi obarczony był każdy pracownik. Powiązania te pozwalają podsystemom analitycznym na bieżące określanie poziomu umiejętności i wiedzy poszczególnych pracowników.

Prawo do tworzenia zespołów projektowych mają użytkownicy z odpowiednio wysokim poziomem uprawnień.

5.12 FEAT12 Zarządzanie Projektami

Użytkownik systemu ma możliwość utworzenia i modyfikowania projektów. Z każdym projektem można skorelować dowolny zespół pracowników.

5.13 FEAT13 Narzędzie Analityczne : Naniesienie Zmian I Określenie Pracochłonności

Naniesienie jakiejkolwiek zmiany na dowolny element projektu może zakłócić działanie całego projektu jako całości. W celu śledzenia poziomu kontaminacji na skutek dowolnej zmiany utworzone zostanie odpowiednie narzędzie Analityczne. Do każdego modułu (artefaktu) projektu przypisana zostaje (przez użytkownika) pracochłonność jaka została włożona w wyprodukowanie danego elementu. Dodatkowymi informacjami wymaganymi przez narzędzie Analityczne są informacje na temat typów powiązań pomiędzy poszczególnymi artefaktami. Na podstawie takich danych SCMS ma możliwość wygenerowania raportu na temat ewentualnych zmian w innych modułach wymaganych w celu utrzymania spójności projektu. Jako informacje dodatkowe system dostarcza zsumowaną maksymalną pracochłonność wymaganą do wprowadzenia zmian.

6. Ograniczenia

Zadaniem systemu SCMS jest wspomaganie pracy zarówno kadry wyższego i średniego szczebla jak i zwykłych programistów.
Założenia definiują system jako narzędzie generyczne, nie sprofilowane w kierunku konkretnego klienta. Dlatego też nie może być mowy o pełnej automatyzacji procesów wewnętrznych, większość narzędzi analitycznych wymaga wprowadzenia zestawu danych wejściowych na podstawie których dokonywana będzie analiza.