Twój kompleksowy przewodnik po wszystkich rzeczach związanych z tworzeniem oprogramowania

Opublikowany: 2020-08-13

Jak podobne są hala produkcyjna fabryki i biuro programistów?

Wyobraź sobie pokój pełen programistów wpisujących kod na swoich komputerach. A co, jeśli potraktujesz ich wyniki jak zmontowane widżety z fabrycznej linii montażowej? Czy tu też zadziałają rzeczy, które maksymalizują produkcję? A może proces rozwoju bardziej przypomina inne dyscypliny inżynieryjne?

Kierownicy projektów próbują rozwiązać ten problem od początku tworzenia oprogramowania. Z tych pytań wyłoniła się definicja cyklu życia oprogramowania.

Co to jest tworzenie oprogramowania?

To proces tworzenia oprogramowania od podstaw. Chociaż pisanie kodu jest podstawową działalnością, to znacznie więcej.

Proces rozwoju obejmuje wymyślanie i projektowanie przed napisaniem jakiegokolwiek kodu. Planowanie łatwo przeoczyć. Nie wydaje się, aby programowanie było tak, jak robi to pisanie kodu. Jednak odpowiedzi na kluczowe pytania najpierw wzmacniają gotowy produkt. Czy projekt jest w ogóle wart realizacji? Jeśli tak, jak najlepiej się do tego zabrać? Jakie funkcje są potrzebne, a jakie funkcje warto mieć? Odpowiedzi dają projektowi większe szanse powodzenia.

Chociaż kroki są stałe, ich zastosowanie jest różne. Powodem, dla którego rozwój oprogramowania jest nową dyscypliną. Dyscypliny inżynieryjne są dojrzałe z setkami lat historii. Rozwój oprogramowania datuje się dopiero pod koniec lat 40. XX wieku. To wciąż nowa dyscyplina. Zwinna metoda ma dopiero 20 lat. Jednak jest to jedna z najbardziej wpływowych rzeczy w teorii tworzenia oprogramowania. Niezależnie od tego, sześć faz cyklu życia oprogramowania jest wspólnych dla wszystkich systemów.

6 etapów cyklu życia oprogramowania (SDLC)

Zespół programistów może wykorzystać cykl życia oprogramowania w całym projekcie lub jednej funkcji. Ewolucja wykorzystania SDLC polegała na zmniejszeniu ryzyka poprzez skrócenie długości każdego kroku. Za chwilę przyjrzymy się bliżej różnym metodologiom. Najpierw przyjrzyjmy się samym krokom.

Warto też zauważyć, że zobaczysz warianty pod względem liczby kroków lub ich nazw. Czasami kroki są scalane, na przykład tworzenie i testowanie. Innym razem zobaczysz jeden krok podzielony na dwa, tak jak planowanie staje się planowaniem i analizą. W naszym przypadku pozostaniemy przy tych sześciu, ponieważ wyraźnie określają one fazy.

1. Planowanie

Najważniejszym krokiem jest faza planowania. Interesariusze muszą wziąć pod uwagę wszystko, w tym wykonalność samego projektu. Można tutaj zabić cały projekt. Zdrowa organizacja umożliwi interesariuszom zrobienie tego w razie potrzeby. Programiści będą mniej zaangażowani w tej fazie w środowisku przedsiębiorstwa. Właściciele produktów, analitycy biznesowi i inni interesariusze wyrażają swoje potrzeby na tym etapie.

2. Projekt

3. Rozwój

Etap projektowania obejmuje również projektowanie doświadczeń użytkownika (UX). Jeśli aplikacja ma jakieś komponenty skierowane do użytkownika, projektowanie UX jest koniecznością. Obejmuje to badania użytkowników poprzez obserwowanie interakcji prawdziwych ludzi z makietami produktów. Powodem, dla którego dzieje się to w fazie projektowania, a nie w fazie rozwoju, jest czas. Sesje użytkownika wymagają czasu. Często też na podstawie zebranych danych odbywa się więcej dyskusji w obie strony z interesariuszami biznesowymi.

4. Testowanie

Następnie zespół programistów testuje kod. Twórcą kodu i testerem powinni być różni ludzie. Jeszcze lepszy jest tester zapewnienia jakości, który nie jest deweloperem. Deweloperzy mają tendencję do myślenia wyłącznie o scenariuszach happy path. Dedykowani specjaliści ds. testów QA wydają się być lepsi w myśleniu o tym, jak mogą zepsuć oprogramowanie. Jest bardziej prawdopodobne, że znajdą błędy przed wdrożeniem w ten sposób. Rezultatem jest bardziej stabilne oprogramowanie w momencie wydania.

Testowanie zautomatyzowane a testowanie ręczne

Testy jednostkowe i testy integracyjne są często zautomatyzowane. Często platforma DevOps uruchamia te testy na nowym kodzie przed scaleniem go z gałęzią master.

Testowanie ręczne nie jest przestarzałe. Zautomatyzowane testy robią to samo w kółko. Jednak osoba wykonująca testowanie ręczne może przypadkowo znaleźć błędy podczas testowania. To właśnie zmienność w testowaniu manualnym jest jego siłą.

Testów jednostkowych

Test jednostkowy weryfikuje tylko metodę, nic więcej. Testowana funkcja jest granicą. Deweloper pisze testy jednostkowe, a niektóre frameworki SDLC je nakazują. Programowanie ekstremalne ich wymaga. Przepisuje również rozwój oparty na testach. Jest to praktyka pisania najpierw testów jednostkowych. Następnie napisz właściwy kod programu.

Testy integracyjne

Testy integracyjne sprawdzają sekcje lub funkcje bazy kodu. Są one zazwyczaj zautomatyzowane i obsługiwane przez platformę DevOps. To, co weryfikują, obejmuje więcej niż jedną metodę. Przykładem jest sprawdzenie, czy wywołanie API utrwaliło nowy rekord w bazie danych. Porównaj to z testem jednostkowym weryfikującym również metodę API. Test jednostkowy mógłby jedynie zweryfikować, czy powinno nastąpić wywołanie bazy danych. Test integracyjny może wykazać, że dane przepływały przez aplikację zgodnie z oczekiwaniami.

Testowanie systemu

Ostateczną formą testowania jest pełne testowanie systemu. Podsumowując, testowanie jednostkowe weryfikuje tylko funkcję. Testy integracyjne weryfikują funkcję. Jednak testowanie systemowe traktuje całą aplikację jako pojedynczą jednostkę. Testowanie dymu to lekka forma testowania systemu. W nim tester wchodzi w interakcję z systemem tak, jak może to zrobić zwykły użytkownik i zapewnia, że zachowuje się zgodnie z oczekiwaniami. W przeciwieństwie do pełnego, kompleksowego testowania systemu, które jest bardziej rygorystyczne. Pełny test systemu sprawdza wszystkie części systemu jako jedną całość. Również zestaw testów integracyjnych może służyć jako pełny test systemu.

5. Wdrożenie

Faza wdrożenia polega na wypchnięciu testowanego kodu do produkcji. Automatyzacja wdrożenia sprawia, że jest ono bardziej niezawodne. Ponadto ćwiczenie wdrożeń produkcyjnych zwiększa również szanse na płynne wdrożenie. Zespół programistów ćwiczy ze środowiskiem testowym zwanym środowiskiem przejściowym. Powinien być identyczny z produkcyjnym. Im bardziej podobne są te dwa środowiska, tym większą wartość ma wdrożenie praktyki.

6. Konserwacja

Wszystko do tego momentu w SDLC będzie stanowić tylko około jednej czwartej całkowitego kosztu posiadania. Początkowy koszt rozwoju oprogramowania to 25% tego, co firma wyda. Faza konserwacji będzie kosztować firmę około 75% całkowitego kosztu posiadania. Obrona przed kosztami utrzymania balonów polega na poświęceniu większej uwagi fazom wcześniejszym. Oznacza to lepszy projekt techniczny, rozwój i dokładniejsze testowanie. Alternatywą jest dług techniczny. Podobnie jak prawdziwy dług, z czasem staje się droższy.

5 głównych metodologii tworzenia oprogramowania

Chociaż kroki SDLC pozostają niezmienne, ich implementacja i kolejność wykonywania są różne. Przyjrzyjmy się najpopularniejszym sposobom, w jakie organizacje wykonują proces tworzenia oprogramowania.

1. Zwinny

To, co czyni Agile wyjątkowym, to skupienie się na ludziach. Metodologie Agile ponownie skupiły uwagę branży. Wcześniej skupiano się na produkcie, oprogramowaniu. Agile zakwestionował to i skoncentrował się na osobach wykonujących ten proces. Ponadto, przed Manifestem Agile, Programowanie Ekstremalne (XP) i Scrum nie miały żadnego związku. Jednak później ich praktykujący zjednoczyli się pod sztandarem Agile.

Agile sam w sobie nie jest frameworkiem. To framework dla frameworków. W istocie chodzi o skupienie się na ludziach i szybkie iteracje. To jest dokładnie to, co mówi nazwa, zwinny. Dobrze zrobione, jest elastyczność w osiąganiu wyniku. Procesy nigdy nie są wykonywane kosztem ludzi, którzy zamiast tego czerpią z nich wartość.

Kolejnym kluczowym najemcą Agile jest podejście iteracyjne. Chodzi o to, aby wykonywać bloki pracy w krótszych odstępach czasu. W ten sposób firma może szybciej dostosowywać się do zmian na rynku. Możliwość szybkiej zmiany kierunku rozwoju sprawia, że jest zwinny. Jednocześnie zespół programistów może uczyć się z tego, co zrobił w każdej iteracji i ulepszać. Zespoły zwinne robią to na spotkaniach retrospektywnych po każdej iteracji.

2. Ekstremalne programowanie

Programowanie ekstremalne (często w skrócie XP) zaczęło się na początku lat 90-tych. Martin Fowler był jednym z pierwszych sygnatariuszy Manifestu Agile. Uważa, że Agile zyskało popularność dzięki frameworkowi XP. Ponadto utrzymuje, że jest to najlepszy sposób na rozpoczęcie tworzenia oprogramowania Agile.

XP bierze swoją nazwę od swojego podejścia. Wymaga wspólnych dobrych praktyk w zakresie oprogramowania i ich wymaga. To właśnie sprawia, że jest „ekstremalny”. XP wymaga takich rzeczy jak testy jednostkowe, programowanie w parach, częstsze wydawanie.

To, co sprawia, że XP jest wyjątkową metodą, to:

Krótkie cykle iteracyjne (często od 1 do 2 tygodni)
Otwartość na zastępowanie elementów pracy w bieżącej iteracji (coś, na co Scrum nie pozwala)
Nacisk na automatyczne testowanie i programowanie w parach

3. Szczupła

Z technicznego punktu widzenia Lean nie był zwinny, ale w praktyce ma podobne odczucia. Teraz jest przez większość akceptowany jako część Agile. Jego cel różni się od tradycyjnego Agile. Zgodnie z manifestem Agile „Osoby i interakcje ponad procesami i narzędziami”. Lean skupia się bardziej na oprogramowaniu niż na producentach.

Jej korzenie tkwią w zasadach Lean Manufacturing od Toyoty. Oto siedem części, które to definiują. Jeśli jesteś zaznajomiony z produkcją Lean, będą one brzmieć podobnie. Oni są:

Eliminować śmieci
Wzmocnij naukę
Zdecyduj tak późno, jak to możliwe
Dostarcz tak szybko, jak to możliwe
Wzmocnij zespół
Buduj integralność w
Zoptymalizuj całość

4. Scrum

Scrum to najpopularniejsza metoda Agile. Według 14. raportu State of Agile, 58% firm programistycznych używa Scrum. Jeśli uwzględnisz hybrydy Szumowiny, odsetek ten wzrasta do 84%. Co nasuwa pytanie, dlaczego jest najbardziej popularny?

Odpowiedź brzmi: Scrum polega na wykonaniu większej ilości pracy w krótszym czasie. To przemawia do firm. Każda iteracja w Scrumie to „sprint”. Nazwa wzmacnia ideę szybkości. Zwykle sprint trwa od 2 do 3 tygodni. Kiedy zespół Scrumowy zaplanuje sprint, nikt nie powinien go zmieniać. Nowa praca musi poczekać do rozpoczęcia kolejnego sprintu. Wymaga to dyscypliny ze strony interesariuszy biznesowych. W praktyce ta zasada Scrum jest często łamana. Dlatego zespoły często zgłaszają stosowanie hybrydy Scrum.

Kolejną cechą Scrum jest Scrum Master. To jeden z członków zespołu nominowany do kierowania sprintem na cel. Często Scrum Master jest deweloperem z zespołu programistów.

Najpopularniejszym wariantem Scrum jest ScrumBan, który jest połączeniem Scrum i Kanban. Kanban ma swoje korzenie w japońskim procesie produkcyjnym Toyoty, takim jak Lean. To system pracy na czas.

Każdy element pracy jest jak własna iteracja. Programista pracuje tylko nad jedną rzeczą na raz. Reguła to jeden element „w toku” na programistę. Ten ścisły limit prac w toku rzuca światło na wszelkie wąskie gardła. Deweloperzy śledzą elementy pracy w toku za pomocą tablicy Kanban. Na marginesie, stąd pochodzi nazwa. Po japońsku Kanban oznacza „szyld”.

5. Wodospad

Metoda kaskadowa jest najwcześniejszą ze wszystkich praktyk tworzenia oprogramowania. Co najmniej o kilka dekad wyprzedza Agile. Ta metoda jest również starsza niż jej nazwa.

To naturalny sposób, w jaki firmy zawsze wykonywały swoją pracę. To proces liniowy i zaczynasz od początku. Po pierwsze, interesariusze opracowują wymagania. Nie robią tego dla jednej lub dwóch funkcji. Nie, interesariusze biznesowi od razu wyznaczają cały projekt. Potem zaczyna się praca. Deweloperzy wykonują całą pracę bez żadnych iteracji aż do zakończenia.

Droga wodospadu jest najłatwiejsza do zrozumienia pojęciowo. Ludzie robią jedną rzecz na raz. To powiedziawszy, jest to najbardziej ryzykowne dla sukcesu biznesowego. Jeśli coś jest poza celem, interesariusze nie mogą tego poprawić do czasu zakończenia projektu. Powodem jest to, że nie zostanie to nawet zauważone do czasu zakończenia projektu.

3 podstawowe podtypy oprogramowania

Gotowe oprogramowanie jest jednym z trzech typów. Te typy to oprogramowanie systemowe, programistyczne i aplikacyjne. Aby to zilustrować, oto analogia do pieczenia ciasta. Mikser lub szpatułka to oprogramowanie do programowania. W tej analogii umożliwia tworzenie większej liczby ciastek lub większej liczby aplikacji. Podczas składania ciasta dolną warstwą jest oprogramowanie systemowe. To podstawa. Bez niego nie można mieć ciasta warstwowego. Najwyższą warstwą będzie wtedy oprogramowanie aplikacyjne. To jest widoczne dla większości przypadkowych obserwatorów.

Oprogramowanie systemowe

System operacyjny komputera to oprogramowanie systemowe. Ma to kluczowe znaczenie dla jego użyteczności. Wyobraź sobie komputer bez systemu operacyjnego. Byłbyś w stanie wchodzić z nim w interakcję tylko za pomocą języka maszynowego. To jest czysty binarny - tylko jedynki i zera. Nie można pracować z jakimkolwiek poziomem skali. Oprogramowanie systemowe otwiera użyteczność komputera.

Windows, macOS i Linux to najpopularniejsze przykłady oprogramowania systemowego. Sterowniki urządzeń to także oprogramowanie systemowe. Rozszerzają podstawową funkcjonalność systemu operacyjnego. Inteligentne urządzenia bez systemu operacyjnego wykorzystują oprogramowanie układowe do włączania ich funkcjonalności. Jest to również oprogramowanie systemowe.

Oprogramowanie do programowania

Oprogramowanie do programowania jest podzbiorem oprogramowania użytkowego. Sklasyfikuje każdy program, którego programista używa do tworzenia nowych programów. Obejmują one zarówno proste edytory tekstu, jak i złożone zintegrowane środowiska programistyczne (IDE). Większość programistów preferuje bardziej złożone narzędzia programistyczne. Programy takie jak Microsoft Visual Studio przyspieszają rozwój.

Oprogramowanie

Najpopularniejszym typem jest oprogramowanie aplikacyjne. To oprogramowanie, które pozwala robić rzeczy z komputerem. To sprawia, że komputery są użyteczne. Popularnymi przykładami są programy takie jak Microsoft Word i Excel.

Oprogramowanie w chmurze również należy do tej kategorii. Dokumenty Google, Dropbox, a nawet Instagram to aplikacje. Jeśli kiedykolwiek poczujesz się zdezorientowany, czy coś jest oprogramowaniem użytkowym, czy nie, oto prosty test. Czy program potrzebuje czegoś innego do uruchomienia? Windows lub Android nie. Są oprogramowaniem systemowym. PowerPoint, a nawet gra taka jak Call of Duty, potrzebują innych działających rzeczy, co oznacza, że są to aplikacje. Bez sterowników urządzeń i systemu operacyjnego nie można ich wykonać.

Wniosek

Metody tworzenia oprogramowania wciąż dojrzewają. Jednak niezależnie od zastosowanej metody kroki pozostają takie same. Zespoły zwinne mogą przechodzić nad nimi szybciej, a praktycy Waterfall powoli przechodzą od jednego do drugiego. Jednak, aby zbudować lepsze oprogramowanie, musisz wzmocnić proces na każdym kroku. Opierają się na sobie. Cykl życia oprogramowania nie jest rzeczą bez jednego z jego etapów. Części tworzą całość.

Pomyśl, co by się stało, gdybyś opuścił jakikolwiek krok. Bez planowania, co robisz? Bez projektu proces rozwoju będzie przypadkowy. Pominięcie etapu rozwoju jest niemożliwe. Brak testów gwarantuje, że produkt nie będzie działał zgodnie z oczekiwaniami. W przypadku braku wdrożenia nikt nie będzie miał dostępu do produktu. Nieutrzymywana aplikacja przestaje być używana. Każdy krok ma kluczowe znaczenie dla sukcesu oprogramowania.