Termin software house pojawia się w ofertach i przetargach oraz w rozmowach o outsourcingu, ale bywa używany zamiennie z określeniami producent oprogramowania, agencja interaktywna czy dostawca IT. Rozróżnienie ma znaczenie praktyczne, bo od typu wykonawcy zależy, kto jest właścicielem kodu, jak przebiega rozwój systemu i kto odpowiada za utrzymanie po wdrożeniu.
Ta strona porządkuje pojęcia. Pokazuje, czym jest software house, czym różni się od producenta gotowego produktu oraz od działu IT wewnątrz firmy, i w jakich sytuacjach każda z tych form ma sens. Wersje tematu rozszerzone o lokalizację opisują strony o zakresie usług software house w Poznaniu, o stosie technologicznym i o współpracy zespołowej.
Definicja software house
Software house jest firmą, której podstawową działalnością jest wytwarzanie oprogramowania na zlecenie. Klient przychodzi z problemem procesowym, a wykonawca projektuje i buduje aplikację, która ten problem rozwiązuje. Zespół zwykle tworzą analitycy i programiści, jakość sprawdzają testerzy, a rezultat pracy jest dostosowany do jednego zamawiającego, a nie do rynku masowego.
Cechy charakterystyczne
Kilka cech odróżnia software house od innych dostawców IT. Praca ma charakter projektowy: zaczyna się analizą i kończy odbiorem wraz z przekazaniem dokumentacji. Zakres wynika z wymagań zamawiającego, więc żadne dwa projekty nie są identyczne. Wycena opiera się na pracochłonności, a nie na cenniku licencji.
- Zlecenie - wykonawca buduje rozwiązanie dla określonego klienta na podstawie jego wymagań.
- Zespół projektowy - ludzie dobierani są do zadania, a po odbiorze przechodzą do następnych projektów.
Co software house dostarcza
Rezultatem pracy jest działająca aplikacja z dokumentacją i kodem źródłowym, a często także z usługą utrzymania. Najczęstszym produktem są aplikacje webowe, czyli programy działające na serwerze i dostępne z przeglądarki. Odrębną kategorię stanowią aplikacje mobilne i integracje między systemami. Szerzej o oprogramowaniu pisanym pod potrzeby jednej firmy traktuje strona o dedykowanym oprogramowaniu na zamówienie.
Software house a producent produktu
Producent produktu tworzy jeden program lub rodzinę programów i sprzedaje je wielu klientom. Kod należy do producenta, klient kupuje licencję i korzysta z funkcji, które producent zaplanował w mapie rozwoju. Zmiany specyficzne dla jednej firmy są możliwe wyłącznie w granicach konfiguracji albo za osobną opłatą. Software house działa odwrotnie: kod powstaje pod zamawiającego, a prawa do niego strony ustalają w umowie.
| Kryterium | Software house | Producent produktu |
|---|---|---|
| Punkt wyjścia | wymagania jednego klienta | potrzeby wielu klientów zebrane w produkcie |
| Własność kodu | ustalana w umowie, często przekazywana klientowi | pozostaje u producenta, klient dostaje licencję |
| Rozwój funkcji | według zamówień klienta | według mapy rozwoju produktu |
| Model kosztów | wycena projektu i usługi utrzymania | licencja lub abonament z opłatą za wdrożenie |
| Czas do uruchomienia | dłuższy, bo system powstaje od podstaw | krótszy, bo produkt już istnieje |
W praktyce granica jest płynna. SoftwareStudio pełni obie role: rozwija własne systemy z rodziny Studio WMS.net, VSS.net, RMA.net, TCS.net i PWS.net, a jednocześnie wykonuje aplikacje na zamówienie. Więcej o modelu producenta opisuje strona o producencie oprogramowania oraz tekst o producencie oprogramowania dla firm.
Reguła: jeśli proces firmy mieści się w gotowym produkcie z konfiguracją, przemawia za nim niższy koszt oraz krótszy czas wdrożenia. Zamówienie od podstaw ma sens, gdy przewaga firmy leży w procesie, którego rynkowy program nie obsłuży.
Software house a dział IT w firmie
Dział IT jest częścią organizacji i odpowiada za ciągłość działania istniejących systemów. Jego pracownicy znają firmę i jej historię oraz nieformalne zasady, a cel jest długoterminowy: utrzymać infrastrukturę oraz zapewnić wsparcie użytkownikom. Software house ma inny horyzont, bo koncentruje się na projekcie z początkiem i końcem, a wiedzę o organizacji poznaje w trakcie analizy.
| Kryterium | Dział IT | Software house |
|---|---|---|
| Horyzont pracy | stały, ciągłość działania | projektowy, z terminem zakończenia |
| Znajomość firmy | wysoka, budowana latami | zdobywana w analizie |
| Wiedza specjalistyczna | szeroka, ale mało pogłębiona w pojedynczych technikach | wąska, ale pogłębiona w wybranym stosie |
| Elastyczność mocy | ograniczona etatami | zespół dopasowany do zadania |
| Koszt | stały (wynagrodzenia oraz narzędzia) | zmienny, zależny od zakresu |
Obie formy często współistnieją. Dział IT pozostaje właścicielem środowiska i wymagań bezpieczeństwa, a software house dostarcza aplikację, którą ten dział potem utrzymuje albo przekazuje do serwisu. Warunkiem dobrej współpracy jest uzgodnienie granic odpowiedzialności: kto zarządza serwerem, kto uprawnieniami w bazie i kto przyjmuje zgłoszenia od użytkowników.
Kiedy brakuje mocy własnych
Typowo chodzi o projekt jednorazowy, do którego firma nie zatrudnia zespołu na stałe. Przykładem jest nowa aplikacja dla handlowców albo integracja z systemem klienta. Zatrudnienie kilku programistów na czas jednego projektu jest nieopłacalne, więc zamawia się wykonawcę zewnętrznego. Po odbiorze aplikacja trafia do utrzymania, a w razie zmian firma ponownie zleca prace.
Druga typowa sytuacja dotyczy wiedzy specjalistycznej. Dział IT utrzymujący dziesiątki systemów rzadko ma w zespole osobę, która na co dzień projektuje indeksy w bazie danych albo pisze aplikacje mobilne na terminale. Software house wnosi taką wiedzę na czas projektu i przekazuje ją w postaci dokumentacji oraz kodu, który dział IT potrafi potem utrzymywać.
Software house a agencja i outsourcing IT
Agencje interaktywne budują strony na szablonach i gotowych systemach CMS. Wykorzystują podstawowe funkcje takich rozwiązań, często bez rozbudowy, i osiągają atrakcyjny efekt wizualny. Kiedy jednak potrzebna jest interakcja z bazą danych oraz zaawansowana logika biznesowa, a nie tylko wygląd, konieczne stają się usługi software house.
Osobną kategorią jest outsourcing IT. Jego przedmiotem jest zwykle infrastruktura, czyli serwery z macierzami i sprzęt sieciowy oraz oprogramowanie używane w firmie, a nie wytwarzanie nowych aplikacji. W opisie oferty SoftwareStudio outsourcing obejmuje opiekę nad centrum danych i dział bezpieczeństwa informatycznego, przy czym stacje klienckie wspiera się w ograniczonym zakresie. Szczegóły tej usługi opisuje strona o outsourcingu informatycznym.
| Forma | Główny przedmiot | Typowy rezultat |
|---|---|---|
| Software house | kod aplikacji | działający system z dokumentacją |
| Agencja interaktywna | strona i komunikacja | witryna na szablonie lub CMS |
| Outsourcing IT | infrastruktura i wsparcie | stabilne środowisko pracy |
| Producent produktu | gotowy program | licencja i wdrożenie |
Typy projektów zlecanych software house
Zamówienia kierowane do software house dzielą się na kilka powtarzalnych typów. Rozróżnienie pomaga oszacować pracochłonność, bo każdy typ ma inny profil ryzyka i inne zadania w harmonogramie.
| Typ projektu | Charakter prac | Główne ryzyko |
|---|---|---|
| Nowy system | analiza, projekt, wytworzenie od podstaw | zmiana wymagań po zobaczeniu pierwszych ekranów |
| Rozbudowa istniejącej aplikacji | nowe funkcje w działającym kodzie | niedokumentowane zależności w starym kodzie |
| Migracja | przeniesienie danych i funkcji na nową platformę | jakość danych i różnice w zachowaniu programów |
| Integracja | połączenie dwóch lub więcej programów | zależność od dostawcy zewnętrznego interfejsu |
Rozbudowa cudzego kodu wymaga innych umiejętności niż pisanie od zera. Programista musi zrozumieć decyzje podjęte przed laty, często bez dokumentacji, i dopisać funkcje w sposób, który nie zepsuje działających części. Z tego powodu wyceny takich zadań opierają się na krótkim przeglądzie kodu, zanim wykonawca zobowiąże się do terminu.
Integracje mają własną specyfikę, opisaną na stronie o integrowaniu aplikacji webowych. Przy migracjach największy wysiłek pochłania zwykle nie sam kod, ale porównanie wyników starego i nowego systemu na tych samych danych, dlatego wykonawca przygotowuje zestaw kontrolny raportów do zestawienia przed i po przeniesieniu.
Prawa do kodu i odpowiedzialność za utrzymanie
Dwie kwestie najczęściej wywołują nieporozumienia po zakończeniu projektu: kto ma prawa do kodu i kto odpowiada za jego dalszy rozwój. Odpowiedzi zależą od treści umowy, dlatego przed rozpoczęciem prac zamawiający powinien poprosić o jednoznaczny zapis. Interpretacja przepisów o prawie autorskim należy do prawnika, a ten tekst opisuje wyłącznie stronę techniczną tematu.
Wymogi techniczne przekazania
Od strony technicznej przekazanie kodu ma sens tylko wtedy, gdy zamawiający może go zbudować i uruchomić. Wymaga to repozytorium z historią zmian, opisu środowiska programistycznego, skryptów tworzących schemat bazy i listy zależności. Sam pakiet źródeł bez tych elementów przypomina schemat maszyny bez instrukcji montażu.
- Repozytorium - pełna historia zmian kodu z opisami, a nie sama migawka ostatniej wersji.
- Skrypty bazy - polecenia tworzące schemat i dane słownikowe, wykonywane w tej samej kolejności co na produkcji.
- Opis środowiska - wersje serwera i bazy danych oraz bibliotek potrzebnych do zbudowania aplikacji.
- Dokumentacja architektury - opis modułów i przepływu danych oraz punktów integracji.
Utrzymanie po wdrożeniu
Po uruchomieniu aplikacji internetowej ważne jest monitorowanie jej wydajności i sprawdzanie, czy spełnia potrzeby użytkowników. Służą do tego narzędzia analityczne, a okresowe zadania konserwacyjne obejmują łatanie luk w zabezpieczeniach i aktualizację do nowych wersji oprogramowania. Kto te zadania wykonuje, wynika z umowy serwisowej, a nie z samego faktu, że aplikację napisał software house.
Zależność od jednego wykonawcy
Każda forma zlecenia oprogramowania niesie ryzyko zależności od dostawcy. W przypadku producenta produktu jest ono oczywiste, bo klient nie ma kodu. W przypadku software house ryzyko jest mniej widoczne: kod należy do klienta, ale wiedza o jego działaniu pozostaje w zespole wykonawcy. Jeśli dokumentacja jest uboga, zmiana wykonawcy oznacza kosztowne odtwarzanie wiedzy.
Reguła: zależność od wykonawcy ogranicza się nie zapisami w umowie, tylko przekazywaniem repozytorium i skryptów bazy wraz z dokumentacją przy każdym odbiorze etapu.
Praktyczne zabezpieczenie polega na okresowym sprawdzaniu, czy aplikację da się zbudować i uruchomić na czystym środowisku według samej dokumentacji. Taka próba, wykonana raz na jakiś czas przez osobę spoza zespołu, ujawnia brakujące kroki znacznie wcześniej niż nagła zmiana wykonawcy. Podobną rolę pełni przegląd kodu prowadzony przez zamawiającego lub jego doradcę technicznego.
Aplikacje webowe jako typowy produkt software house
Większość zamówień trafiających do software house dotyczy aplikacji webowych. Ich zalety dla firmy są konkretne: obsługa nie wymaga instalacji na urządzeniu, dostęp jest możliwy z dowolnego komputera z przeglądarką, a aplikacja może wyświetlać powiadomienia bezpośrednio na urządzeniu. Więcej informacji podaje strona o aplikacjach webowych.
Wdrożenie na serwerze
Po opracowaniu aplikacja trafia na serwer sieciowy, na przykład Microsoft IIS albo Apache. Może działać na hostingu współdzielonym lub na serwerze dedykowanym, a wybór zależy od obciążenia i wymagań bezpieczeństwa. Opis konfiguracji aplikacji ASP.NET na serwerze IIS zawiera dokumentacja hostowania w IIS.
Integracja ze stroną internetową firmy
Coraz częściej aplikację łączy się ze stroną firmową, na przykład tak, aby klient mógł przejść od opisu produktu wprost do wersji demonstracyjnej. Przykładem jest demo online systemów SoftwareStudio, dostępne bez rejestracji. Techniczne aspekty takiego połączenia opisuje strona o integrowaniu aplikacji webowych.
Języki programowania
Aplikacje webowe można pisać w różnych językach, na przykład w Pythonie, PHP, JavaScript czy Javie. Mechanizm działania pozostaje taki sam: przeglądarka wysyła żądanie, serwer wykonuje kod i zwraca odpowiedź. Wybór języka zależy od środowiska klienta i umiejętności zespołu, dlatego nie jest kryterium jakości wykonawcy.
Jak ocenić wykonawcę
Przy wyborze między software house a producentem oraz rozbudową własnego działu IT pomaga kilka pytań kontrolnych. Odpowiedzi ujawniają, czy potrzebna jest unikalna funkcjonalność, czy wystarczy konfiguracja, i kto będzie właścicielem rozwiązania za kilka lat.
| Pytanie | Jeśli odpowiedź brzmi tak |
|---|---|
| Czy proces jest specyficzny dla firmy i daje jej przewagę? | rozważyć software house |
| Czy istnieje produkt obsługujący ten proces po konfiguracji? | rozważyć producenta produktu |
| Czy potrzebne jest stałe utrzymanie infrastruktury? | rozważyć dział IT lub outsourcing |
| Czy firma nie ma kompetencji do rozwijania kodu? | uzgodnić serwis z wykonawcą |
Ocenę wykonawcy ułatwiają materiały, o które można poprosić przed podpisaniem umowy. Nie zastępują rozmowy o zakresie, ale pokazują, jak firma pracuje na co dzień.
- Demo działającego systemu - pozwala ocenić układ ekranów i szybkość działania na przykładowych danych.
- Opis procesu wytwarzania - obejmuje repozytorium z przeglądami kodu oraz środowiska testowe.
- Wzór umowy serwisowej - pokazuje czasy reakcji oraz zakres wsparcia i sposób zgłaszania.
- Próbka dokumentacji - fragment z wcześniejszego projektu, udostępniony za zgodą klienta.
Do wskazówek praktycznych należy sprawdzenie, czy wykonawca jest jednocześnie producentem własnych systemów. Taka firma zna cykl życia oprogramowania z własnego doświadczenia, a to zwykle przekłada się na dojrzałość procesu wsparcia. Sama informacja o tym nie zastępuje jednak analizy umowy i przeglądu przykładowych rozwiązań. Ogólny opis dostawcy usług informatycznych zawiera strona oprogramowania na zamówienie, a przykład systemu dla logistyki pokazuje artykuł o systemie WMS.
