Powrót inżynierii oprogramowania

Inżynieria oprogramowania jest znowu w ofensywie. Ułatwia dbanie o jakość kodu i zarządzanie projektami. To może prowadzić do nieporozumień przy jednoczesnym wykorzystaniu metodyk agile oraz architektury korporacyjnej.

Wpisując słowa „inżynieria oprogramowania” w wyszukiwarkę, dostajemy w odpowiedzi przede wszystkim liczne linki do… studiów podyplomowych. Szukanie frazy „szkolenia inżynierii oprogramowania” przynosi mieszankę różnych kursów, w tym wielu z dziedziny programowania. Najwyraźniej mamy do czynienia z zamętem pojęciowym, a to znaczy, że trafiliśmy na dziedzinę istotną, ale lekceważoną i pomijaną.

Plemienny świat IT

Inżynieria oprogramowania to ogólna wiedza, jak budować systemy informatyczne, więc jej rozpowszechnione utożsamianie z konkretnymi narzędziami, językami czy platformami to bzdura. Pojęciowy chaos jest tylko symptomem poważniejszego problemu – braku systematycznych metod i metodyk pracy. A tam, gdzie brakuje metod, na ich miejsce wciskają się różne pseudometody, szamanizmy i lokalne kulty cargo.

W początkach IT – lata 40. i 50. XX wieku – tworzenie programów było rodzajem rzemiosła. Rzemieślnikami byli najwyższej klasy matematycy, fizycy, inżynierowie. I to początkowo wystarczało. Z kilku powodów.

Po pierwsze, inteligencja i wysokie kwalifikacje ogólne rzemieślników IT gwarantowały, że radzili sobie dobrze, nawet gdy brakowało im metod i procedur. Umieli je stwarzać sobie na bieżąco, w miarę potrzeby. Po drugie, wynikająca z tego konieczność poprawek była do przyjęcia, gdy biznesowe znaczenie IT było małe, a konkurencja niemal nie istniała. Pomyłki były łatwe i mało kosztowne do poprawiania w porównaniu z branżami realizującymi swoje produkty w innej formie niż instrukcje maszyny Turinga.

Od końca lat 50., odkąd kosztowne, energochłonne i gorące lampy próżniowe zostały wyparte przez tranzystory, sytuacja szybko się zmieniała. Komputery taniały i wzrastały w siłę, więc możliwości i znaczenie programów gwałtownie rosły. Wcześniejsze założenia przestały być prawdziwe. Programistów potrzeba było coraz więcej, programy stawały się coraz większe i bardziej skomplikowane, ale coraz łatwiejsze do tworzenia, dzięki realizacji maszyny wirtualnej oraz pojawieniu się kompilowanych języków programowania. Ciężar trudności w realizacji projektów IT przeniósł się na sprawy architektury, koordynacji i logistyki działań. Do budowy systemu konieczna była współpraca zespołu osób o różnych kompetencjach.

Sprawy architektury, koordynacji i logistyki działań to właśnie inżynieria oprogramowania.

Sposoby ograniczania kosztów zapewnienia jakości w projektach IT będą przedmiotem zorganizowanych przez Computerworld warsztatów „Agile vs Waterfall- ekonomika zapewnienia jakości oprogramowania”, które odbędą się 23 czerwca 2014 w Warszawie w hotelu Sound Garden, ul. Żwirki i Wigury 18.

Szczegóły i rejestracja na stronie: http://www.computerworld.pl/konferencja/ekonomika/index

Inżynieria blisko psychologii

Ponieważ szybkość ewolucji branży IT była i jest znacznie większa niż w innych nurtach technicznej cywilizacji, wiele zjawisk następowało w ciągu miesięcy niemal; stąd ich większa zmienność i chaotyczność, znaczny rozrzut wyników. To trwa do dziś, dlatego wszystkie nazwy i terminy bywają tak nieostre, jak nazwa inżynieria oprogramowania; dlatego pojawiło się tak wiele subkultur posługujących się dialektami.

Ulegamy złudzeniu, że jako dziedzina tkwiąca jedną nogą w matematyce oraz informatyce, a drugą w fizyce i elektronice, IT powinno być logiczne, uporządkowane, odporne na zjawiska psychologiczne, społeczne i kulturowe. Jest odwrotnie: szybkość i zmienność rozwoju branży spowodowały, że wiele wyborów i procedur można skuteczniej wyjaśnić, odwołując się do badającej obyczaje plemienne antropologii kulturowej niż do logiki czy teorii zarządzania.


TOP 200