W 1987 roku Siły Powietrzne Stanów Zjednoczonych utworzyły Centrum Wsparcia Technologii Oprogramowania (STSC). Jego misją było „pomaganie organizacjom w identyfikowaniu, ocenianiu i wdrażaniu technologii, które poprawiają jakość produktów programistycznych, wydajność produkcji i przewidywalność” (Źródło). Aby osiągnąć ten cel, STSC założyło publikację internetową zatytułowaną CrossTalk: Czasopismo o defensywnym wytwarzaniu oprogramowania, którą publikowało na swojej stronie internetowej (Stsc.hill.af.mil) od 1996 do 2016 roku.
Później STSC utworzyło stronę Crosstalkonline.org, na której nadal publikowano CrossTalk. Jednak od 2017 roku witryna nie jest dostępna.
Co mogło się z nią stać? Próbujemy się tego dowiedzieć, analizując historię publikacji. Następnie kończymy ten artykuł, przyglądając się 10 najważniejszym artykułom, które opublikowano.
Historia CrossTalk
CrossTalk rozpoczął publikację w 1988 roku, aby zachęcać do stosowania technik zapewniających tworzenie wysokiej jakości oprogramowania. Według STSC celem publikacji było „zwiększenie niezawodności, łatwości utrzymania i responsywności naszych zdolności bojowych oraz instruowanie, informowanie i edukowanie czytelników na temat aktualnych decyzji dotyczących polityki i nowych technologii inżynierii oprogramowania” (Źródło).
Pod kierownictwem Reuela Aldera (wydawcy), Tracy Stauder (redaktorki naczelnej) i Sandi Gaskin (starszej redaktorki) liczba prenumeratorów CrossTalk wzrosła z około 200 do 29 000 (Źródło).
Stsc.hill.af.mil, strona, na której początkowo publikowano CrossTalk, została uruchomiona w grudniu 1996 roku. Wcześniejsze tomy można znaleźć tutaj.
Stsc.hill.af.mil zawierała formularz subskrypcji, wytyczne dla potencjalnych autorów oraz ogłoszenia dotyczące tematyki. Zawierała również stronę z danymi kontaktowymi pełnoetatowych pracowników publikacji.
CrossTalk pozostawał w witrynie STSC do listopada 2010 roku, kiedy przeniósł się na własną stronę: Crosstalkonline.org. Ostatni numer CrossTalk zarejestrowany w internecie pochodzi z sierpnia 2017 roku.
Dostępnych jest bardzo niewiele informacji o tym, co stało się zarówno ze stroną internetową, jak i publikacją po sierpniu 2017 roku.
10 najważniejszych artykułów opublikowanych przez CrossTalk
Ku pamięci CrossTalk zidentyfikowaliśmy 10 najważniejszych artykułów opublikowanych w całej historii tego czasopisma.
Aby zidentyfikować te artykuły, skupiliśmy się na liczbie linków, które każdy z nich otrzymał od webmasterów i redaktorów. Artykuły przyciągające więcej linków (cytowań) prawdopodobnie mają większe znaczenie niż artykuły, które przyciągają ich mniej.
1. Edukacja w zakresie informatyki: gdzie są przyszli inżynierowie oprogramowania?
Pracownicy naukowi Robert Dewar i Edmond Schonberg, wówczas obaj profesorowie informatyki na Uniwersytecie Nowojorskim, wykorzystują ten artykuł, aby argumentować, że edukacja informatyczna (w 2008 roku) zaniedbywała niezbędne umiejętności.
Autorzy obwiniają za tę sytuację powszechne przyjęcie „Javy jako pierwszego języka programowania”. Przedstawili zestawienie umiejętności, które ich zdaniem muszą należeć do podstawowego warsztatu każdego specjalisty ds. oprogramowania: języki programowania, narzędzia do zarządzania testami służące do tworzenia wielkoskalowych, godnych zaufania programów oraz formalne metody dowodzenia (źródło).
Have an account? Log In
2. Skalowanie zwinnego wytwarzania: tworzenie produktów na dużą skalę i w wielu lokalizacjach za pomocą skalowanego Scrum
Konsultanci Craig Larman i Bas Vodde wykorzystali ten artykuł, napisany w 2013 roku, do podsumowania treści swojej dwutomowej serii książek na temat zwinnego rozwoju o bardzo dużej skali. Opisali, jak współpracowali z klientami przy wprowadzaniu dwóch skalowalnych struktur Scrum w dużych globalnych grupach. Przykłady firm, z którymi współpracowali, obejmują Bank of America i Erickson, dostawcę sprzętu dla infrastruktury telekomunikacyjnej.
Larman i Vodde informują, że ich doświadczenia skłoniły ich do opublikowania dwóch tomów. Tom 1 to Narzędzia myślenia i organizacji dla Scrum o dużej skali. Koncentruje się na przywództwie i projektowaniu organizacji. Drugi tom to Praktyki skalowania rozwoju Lean i Agile: rozwój produktów w wielu lokalizacjach i poza siedzibą firmy z wykorzystaniem Scrum o dużej skali. Zawiera praktyczne sugestie dotyczące skalowania w różnych okolicznościach.
3. Wykorzystanie zarówno rozwoju przyrostowego, jak i iteracyjnego
Autor tego artykułu z 2008 roku, dr Alistair Cockburn (opisany przez CrossTalk jako ekspert w dziedzinie projektowania obiektowego (OO), metodyk tworzenia oprogramowania, przypadków użycia i zarządzania projektami), koncentruje się na rozwoju przyrostowym i iteracyjnym w obszarze oprogramowania.
Dr Cockburn wskazuje wyzwania, z którymi mierzą się zespoły podczas pracy z rozwojem przyrostowym i iteracyjnym: próbę zarządzania nimi w ten sam sposób lub przekonanie, że gdy stosuje się jedno z nich, nie należy stosować drugiego. Kończy, podsumowując swoje poglądy: „Słowo increment oznacza dodać, a słowo iterate oznacza wykonać ponownie” (Źródło).
4. SmartCam3D zapewnia nowy poziom świadomości sytuacyjnej
W tym artykule z 2005 roku Janis White (konsultantka statystyczna), Frank Delgado (pracujący dla NASA) i Mike Abernathy (specjalista ds. oprogramowania) koncentrują się na systemie SmartCam3D (SC3D). Jest to „hybrydowy syntetyczny system wizyjny, który łączy informacje z aktywnych czujników z danymi syntetycznego systemu wizyjnego, aby stworzyć wirtualne okno kokpitu”.
Autorzy przedstawiają hybrydowy syntetyczny system wizyjny (HSVS). Opisują go jako system łączący „dane z aktywnych czujników z informacjami z syntetycznego systemu wizyjnego (SVS), aby tworzyć bogate w informacje obrazy w czasie rzeczywistym”. Kończą stwierdzeniem, że SC3D był pierwszym systemem HSVS działającym w czasie rzeczywistym, sugerując, że „to oprogramowanie będzie ratować życie” (Źródło).
5. CMMI wspiera doskonalenie procesów w całym przedsiębiorstwie
Podpułkownik Joe Jarzombek, pracujący wówczas jako dyrektor w Earth Science Information Partners (ESIP), społeczności działającej na rzecz zwiększenia dostępności danych naukowych, wykorzystał ten artykuł do przedstawienia koncepcji modeli dojrzałości zdolności (CMM). Odnosi się ona do zbiorów modeli dotyczących procedur organizacyjnych i kompetencji przekrojowych dla różnych dziedzin.
Jarzombek przedstawia koncepcję zespołów CMMI, oznaczającą „wspólny wysiłek na rzecz integracji modeli CMM”. Jak twierdzi, takie jednostki tworzyłyby zestaw zintegrowanych produktów wspierających doskonalenie procesów i produktów w obszarze tworzenia oprogramowania (Źródło).
6. Dlaczego duże projekty informatyczne kończą się niepowodzeniem: 12 kluczowych pytań
W tym artykule z 2005 roku, którego autorem jest Watts S. Humphrey z Software Engineering Institute (SEISM) Uniwersytetu Carnegie Mellon, skupiono się na 12 kluczowych pytaniach dotyczących przyczyn niepowodzeń dużych projektów informatycznych.
Zdaniem Humphreya odpowiedzi na pytania postawione w artykule pomogą twórcom oprogramowania udoskonalać ich projekty. Uważa on, że główne problemy wiążą się z przyczynami, dla których zarządzanie dużymi projektami informatycznymi jest często trudne, rodzajem wymaganych systemów zarządzania oraz tym, co należy zrobić podczas wdrażania tych systemów (Źródło).
7. Wyjaśnienie chmury obliczeniowej
Rozważając zmiany, które zachodziły w 2011 roku w tworzeniu oprogramowania, Qusay F. Hassan z Wydziału Komputerów i Informatyki Uniwersytetu Mansoura w Egipcie koncentruje się na chmurze obliczeniowej.
W artykule próbuje zmierzyć się z ideą, że określenie „chmura obliczeniowa” jest często nadużywane przez ludzi, którzy odnoszą je do rzeczy, które mogą nie mieć związku z jego rzeczywistą definicją i zakresem. Czy chodzi tylko o hosting internetowy? — pyta. Następnie definiuje kilka pojęć, takich jak hosting internetowy, dostawca usług aplikacyjnych (ASP), obliczenia ochotnicze i internetowe udostępnianie plików, a także wiele innych (Źródło).
8. Poprawność poprzez konstrukcję: manifest oprogramowania o wysokiej integralności
„Systemy oprogramowania o wysokiej integralności są często tak duże, że konwencjonalne procesy tworzenia nie są nawet bliskie osiągnięcia akceptowalnych wskaźników defektów” — twierdzą Martin Croxford i dr Roderick Chapman na początku tego tekstu. Gdy obaj autorzy go napisali, pracowali dla Praxis High Integrity Systems, brytyjskiej firmy zajmującej się inżynierią systemów, specjalizującej się w systemach o znaczeniu krytycznym (Źródło).
W tym artykule z 2005 roku autorzy obiecują przedstawić podejście, które pozwoliło w opłacalny sposób tworzyć „oprogramowanie o bardzo niskim wskaźniku defektów”. Opisywana przez nich metoda to poprawność poprzez konstrukcję (CbyC). Jest to podejście do tworzenia oprogramowania, które dobrze dostosowuje się do zmian w całym cyklu życia, a jego wskaźniki defektów były niższe niż w ówczesnych praktykach komercyjnych (Źródło).
More Articles
9. Wady projektowe interfejsu użytkownika przeglądarek: wykorzystywanie niewiedzy użytkowników
Ten artykuł został napisany przez Adityę Sooda, wówczas doktoranta na Uniwersytecie Stanowym Michigan, oraz Richarda Enbody’ego, profesora nadzwyczajnego w Katedrze Informatyki i Inżynierii, również na Uniwersytecie Stanowym Michigan, w 2011 roku. W streszczeniu artykułu autorzy zauważają, że „wady projektowe przeglądarek stanowią poważne zagrożenie dla bezpieczeństwa, prywatności i integralności użytkowników”.
Tekst koncentruje się na wadach projektowych graficznego interfejsu użytkownika (GUI)
elementów przeglądarek. Autorzy sugerują, że to właśnie te wady wykorzystują oszuści, gdy nakłaniają użytkowników do wykonywania czynności zagrażających ich bezpieczeństwu (Źródło).
10. Problemy starzejącego się oprogramowania
Capers Jones, pracujący wówczas w obszarze badań nad produktywnością tworzenia oprogramowania, koncentruje się na problemach związanych ze starzejącym się oprogramowaniem w sektorze biznesowym i publicznym. W tym tekście z 2007 roku Jones informuje, że znalezienie podmiotów korzystających z oprogramowania starszego niż 10 lat, w tym aplikacji mających nawet 25 lat, nie było wówczas zaskoczeniem.
Jones omawia również konsekwencje starzenia się oprogramowania, zauważając, że utrzymanie takiego oprogramowania staje się trudne, ponieważ aktualizacje często niszczą pierwotną strukturę aplikacji. Zwiększa to entropię (brak przewidywalności i porządku). Zauważa, że wraz ze starzeniem się oprogramowania problem nazywany wstrzykiwaniem poprawek prowadzi do „przypadkowego wprowadzania nowych defektów jako produktu ubocznego naprawiania wcześniejszych defektów” (Źródło).
