Tworzenie oprogramowania dla Windows i wsparcie techniczne KomuraSoft

Wykorzystanie istniejących zasobów i wsparcie migracjiWykorzystać zgromadzone zasoby i przejść do nowej architektury.

Komponentów z logiką biznesową lub specyfiką urządzeń nie należy odrzucać hurtowo. Badamy zasoby COM, ActiveX i C++ i migrujemy, łącząc trzy działania: zachować, połączyć, wymienić.

Dokumentacja specyfikacji nie jest wymagana. Konsultację można zacząć od tego, co jest znane.

  • Bezpośredni kontakt z inżynierem
  • Konsultacja możliwa przed ustaleniem wymagań
  • Zlecenie tylko w potrzebnym zakresie

Można skonsultować się z nami na takich etapach

Zacznijmy od tego, co sprawia Państwu problem.

Stare komponenty zawierają ważną specyfikację i nie można ich wymienić

Badamy rolę komponentów i warunki dalszego użytkowania oraz jasno określamy, dlaczego należy je zachować.

Zasoby w C++ i 32-bitowe utrudniają aktualizację

Rozważamy połączenie z nową częścią, na przykład przez wrappery lub wydzielenie do osobnego procesu.

Pełna przebudowa jest trudna, ale nie można też zostawić tego tak, jak jest

Porządkujemy kolejność aktualizacji na podstawie zależności i wpływu na eksploatację.

Z kimś, z kim można porozmawiać o technice wprost, bez upraszczania.

Zdjęcie profilowe Go Komury

Przedstawiciel i inżynier

Go Komura

Inżynier wyspecjalizowany w systemie Windows zajmuje się sprawą od poznania problemu, przez diagnozę i projekt, aż po implementację. Także to, czego nie potrafią Państwo jeszcze w pełni opisać, uporządkujemy, wychodząc od kwestii technicznych.

Zobacz doświadczenie i technologie / Zobacz informacje o firmie

Opublikowany artykuł techniczny

Jak dziś postępować z ActiveX / OCX

W artykułach technicznych można zapoznać się z kwestiami, którym przywiązujemy wagę w tej dziedzinie, oraz z naszym podejściem do projektowania. Publikujemy je oddzielnie od zrealizowanych zleceń.

Czytaj artykuły techniczne

Zakres wsparcia

Od wybranej części prac po całość: zakres dobieramy do potrzeb.

Od pojedynczej diagnozy lub modyfikacji po rozwój całej aplikacji. Zakres zlecenia ustalamy zgodnie z Państwa aktualną sytuacją.

Analiza istniejących zasobów i zależności

Badamy role i zależności komponentów COM / ActiveX / OCX, zasobów w C++ i innych elementów oraz porządkujemy warunki ich dalszego użycia.

Projekt etapowej architektury migracji

Określamy specyfikację, która musi zostać zachowana, a następnie projektujemy architekturę łączącą istniejące komponenty z nową aplikacją oraz kolejność migracji.

Wsparcie migracji środowisk mieszanych 32-bitowych i 64-bitowych

Rozważamy sposób migracji dopasowany do ograniczeń poszczególnych komponentów, obejmujący przeniesienie do osobnego procesu i implementację warstwy integracji.

Przykłady tego, co sprawdzamy i przekazujemy

  • Uporządkowane zasoby, zależności i ograniczenia
  • Porównanie sposobów integracji i wyniki weryfikacji
  • Plan migracji etapami i implementacja miejsc połączenia

To przykłady zależne od zakresu zlecenia. Zakres i formę rezultatów uzgadniamy przy sporządzaniu wyceny.

Jeśli któryś z tych problemów brzmi znajomo, prosimy najpierw opisać swoją sytuację.

Dokumentacja specyfikacji nie jest wymagana. Konsultację można zacząć od tego, co jest znane.

Koszty i przebieg współpracy

Nie trzeba od razu ustalać wszystkiego.

Zaczynamy od inwentaryzacji zasobów i ustalenia kierunku migracji

Można zlecić nawet sam etap oceny, które komponenty da się zachować i od czego zacząć aktualizację.

Orientacyjne koszty

Wycena zależna od zakresu analizy zasobów, połączeń i migracji

Sprawdzamy zależności i ograniczenia, a następnie proponujemy zakres weryfikacji i sposób prowadzenia migracji etapami.

Zakres bezpłatnej wstępnej diagnozy i usługi płatne

Wstępna diagnoza w zakresie potrzebnym do sporządzenia wyceny i podjęcia decyzji o przyjęciu zlecenia jest co do zasady bezpłatna, przy założeniu, że w przypadku uznania realizacji za możliwą zlecą Państwo właściwe prace rozwojowe. Długotrwała weryfikacja, budowa dedykowanego środowiska, prototypy i PoC (dowód koncepcji), dostarczenie szczegółowych raportów z diagnozy i podobne prace mogą być płatne.

Jeśli zlecają Państwo samą diagnozę lub przegląd, wyceniamy je jako odrębną usługę płatną. Za każdym razem, gdy usługa jest płatna, przed rozpoczęciem prac informujemy o zakresie i kosztach.

  1. Opis sytuacji

    Prosimy opisać cel, problem i środowisko, którego dotyczy sprawa, w zakresie, w jakim są znane.

  2. Ustalenie zakresu i kosztów

    Przedstawiamy potrzebną diagnozę, zakres wsparcia, rezultaty prac, koszty i sposób prowadzenia prac.

  3. Start po uzgodnieniach

    W trakcie diagnozy lub prac rozwojowych przekazujemy postępy, potwierdzone ustalenia i pozostałe ograniczenia.

  4. Sprawdzenie wyników i przekazanie

    Sprawdzamy wyniki w uzgodnionych warunkach i przygotowujemy wdrożenie lub kolejny krok.

Dla osób, które chcą poznać szczegóły techniczne

Rozwiń obsługiwane technologie i szczegóły przebiegu prac

Zachowujemy cenne istniejące zasoby i prowadzimy Państwa do kolejnej architektury.

W komponentach używanych od lat zgromadziły się decyzje biznesowe i specyfikacje właściwe dla urządzeń. KomuraSoft nie wymienia ich hurtowo, lecz bada ich role i zależności, a następnie wspiera migrację, łącząc dalsze użycie, zmianę sposobu połączenia i wymianę.

Problemy, z którymi można zwrócić się do nas o konsultację

  • Ważna specyfikacja znajduje się w COM / ActiveX / OCX i nie można tych komponentów od razu wymienić.
  • Komponent 32-bitowy utrudnia aktualizację aplikacji lub środowiska uruchomieniowego.
  • Chcą Państwo używać funkcji napisanych w C++ z nowej aplikacji .NET.
  • Pełna wymiana jest trudna, ale utrzymywanie obecnej architektury również budzi obawy.
  • Przed przyszłą wymianą chcą Państwo najpierw uporządkować zależności i kolejność migracji.

Porządkujemy, co zostawić, co połączyć i co wymienić

Ocena zasobów, które zostają

Sprawdzamy, czy dany komponent jest elementem interfejsu, zawiera logikę biznesową, czy odpowiada za komunikację z urządzeniem. Badamy kod źródłowy, warunki użycia i środowisko zależności, a następnie porządkujemy wartość dalszego użycia i związane z nim ograniczenia.

Projekt połączenia z nową częścią

Rozważamy m.in. opakowanie w C++/CLI, współpracę przez COM oraz przeniesienie do osobnego procesu. Uwzględniając środowisko 32-bitowe i 64-bitowe, uprawnienia, wątki i obsługę błędów, jasno określamy rolę warstwy integracji.

Ustalenie kolejności wymiany etapowej

Sprawdzamy zależne funkcje i wpływ na bieżącą działalność, a następnie rozdzielamy elementy, które aktualizujemy w pierwszej kolejności, od tych, które wymienimy później. Sposób weryfikacji istniejącej specyfikacji i warunki wycofania zmian włączamy do planu migracji.

Jak prowadzimy zlecenie

  1. Badamy zasoby i ograniczenia. Porządkujemy rolę poszczególnych komponentów, zależności wywołań oraz środowisko programistyczne i uruchomieniowe.
  2. Porównujemy metody. Sprawdzamy zalety i koszty dalszego użycia, budowy warstwy integracji, przeniesienia do osobnego procesu i wymiany.
  3. Weryfikujemy połączenie. Najpierw sprawdzamy elementy niepewne, a następnie konkretyzujemy niezbędne modyfikacje i kolejność migracji.
  4. Implementujemy i migrujemy w uzgodnionym zakresie. Sprawdzając dotychczasowe działanie, przechodzimy do nowej architektury.

Naszym celem nie jest samo przedłużanie życia starych komponentów, lecz stan, w którym wiadomo, co zachowujemy i które miejsca można zmienić w następnej kolejności.

Zakres prac dostosowujemy do głównego tematu konsultacji

Jeśli rozmowa dotyczy głównie tworzenia lub poprawiania konkretnego komponentu, zapraszamy na stronę Tworzenie komponentów COM, a jeśli głównie przepisania całej aplikacji, na stronę Wymiana aplikacji dla systemu Windows.

Jeśli nie znają Państwo architektury komponentów, prosimy zacząć od tego, co jest wiadome: nazwy aplikacji, języka programowania i powodu, dla którego chcą Państwo coś zmienić.

Najczęstsze pytania przed zleceniem

Czy można zasięgnąć konsultacji, jeśli nie da się od razu wymienić komponentów COM lub ActiveX?

Tak. Zakładamy, że w komponentach pozostała specyfikacja biznesowa lub przetwarzanie właściwe dla urządzeń, i porządkujemy, które elementy zostają w użyciu, a które się zmieniają. Określamy powody pozostawienia komponentów i warunki ich przyszłej wymiany, a następnie rozważamy architekturę etapową.

Czy migracja jest możliwa, jeśli pozostały komponenty 32-bitowe?

Badamy, w jakim zakresie i jaką metodą można przeprowadzić migrację. Sprawdzamy ograniczenia aplikacji wywołującej i komponentów oraz rozważamy takie rozwiązania jak przeniesienie do osobnego procesu. To, czy wystarczy dodanie warstwy integracji, oceniamy po weryfikacji.

Czy można zlecić samą inwentaryzację zasobów i strategię migracji?

Tak. Można zlecić uporządkowanie istniejących zasobów, porównanie metod i rozważenie kolejności wymiany. Po sprawdzeniu zakresu badań i potrzebnych materiałów przystępujemy do pracy.

Kontakt

Wystarczy kilka zdań o Państwa sytuacji.

Nie potrzebują Państwo szczegółowej dokumentacji specyfikacji ani terminologii technicznej. Prosimy o podanie poniższych informacji w zakresie, w jakim są znane.

  • Problem lub cel, który chcą Państwo osiągnąć
  • Oprogramowanie, urządzenia i środowisko, których sprawa dotyczy
  • Preferowany termin (może być jeszcze nieustalony)

W pierwszej wiadomości nie trzeba dołączać poufnych dokumentów ani haseł.

Przykład wiadomości z prośbą o konsultację

Chcemy przenieść się do nowej aplikacji .NET, zachowując zasoby C++ i COM. Chcielibyśmy porozmawiać o tym, co należy rozdzielić podczas migracji.

Dokumentacja specyfikacji nie jest wymagana. Konsultację można zacząć od tego, co jest znane.

Przycisk konsultacji otwiera polską stronę kontaktową ze sposobami nawiązania kontaktu. „Skonsultuj się e-mailem” tworzy wiadomość e-mail z nazwą usługi.