Tak, taką książkę można nabyć na Amazonie ;). Streszczenie na stronach sprzedawcy oddaje dobrze jej treść:

This book provides a basic, conceptual-level description of engineering management disciplines that relate to the development and life cycle management of a system. For the non-engineer it provides an overview of how a system is developed. For the engineer and project manager it provides a basic framework for planning and assessing system development.

Ogólnie książka opisuje podstawowy koncepcyjny etap inżynierii systemów (i nie należy tego utożsamiać tylko z branżą IT). Jest napisana przystępnym językiem, adresowana  głównie dla managerów (pierwsze części) by zapoznać ich z inżynierią systemów i systemowym podejściem. Kierownikom projektów “pokazuje” czym (ewentualnie ;)) zarządzają.

Tu tylko kilka słów. Najpierw po raz kolejny cytat:

Problemy, w których rozwiązaniu mają pomóc budowane złożone systemy są zwykle ?problemami złośliwymi? (Rittel i Webber, 1973). ?Problem złośliwy? to taki skomplikowany problem, w którym jest tak wiele powiązanych ze sobą bytów, że nie istnieje jego ostateczna specyfikacja. Prawdziwy charakter problemu objawia się dopiero w miarę opracowywania rozwiązania.

A teraz diagram obrazujący “proces inżynierii systemowej” na bazie jednej z ilustracji w tej książce:

Mamy tu trzy kluczowe etapy, powiązane iteracyjnie:

1. Analiza wymagań, chodzi tu o wymagania biznesowe.
2. Analiza funkcjonalności, chodzi tu o ustalenie do jakich “rzeczy’ system jest potrzebny (przeznaczony).
3. Projektowanie czyli próba opracowania konstrukcji, mechanizmu działania tego systemu.

Trzeci punkt to właśnie klucz do sukcesu: zanim zaczniemy konstruowanie (np. pisanie kodu) warto opracować to rozwiązanie ‘na papierze”. To po pierwsze pozwala uniknąć ogromnych kosztów “rozpoznania bojem” a po drugie daje jako produkt bardzo dobrą (na wysokim poziomie abstrakcji ale kompletną) dokumentację działania systemu.

Niedawno cytowałem artykuł o porażce systemu e-border, tym razem innych cytat:

The Home Office had a concept, not a well-developed set of requirements. Concepts need a reality check; otherwise, you could be chasing a dream! Even though the program ran a pilot to evaluate the feasibility of the concept, the National Audit Office report (2015) claims that it did not cover all aspects of the solution. Consequently, the programme was executed with an untested concept and unknown requirements, which led to disputes. (Źródło: Blueprints Are Not Requirements!)

Jedną z głównych przyczyn porażki było rozpoczęcie realizacji projektu wyłącznie na bazie wizji, bez jakichkolwiek analiz i projektowania tego “co na prawdę ma powstać i w jakich warunkach”. Patrząc na zobrazowany powyżej proces inżynierii systemowej wykonano wyłącznie pierwszy etap (wymagania biznesowe) i przystąpiono do realizacji projektu bez jakichkolwiek analiz i projektowania, od razu zaczęły powstawać prototypy… Projekt e-border zakończył się spektakularną porażką.

Jedną z notacji OMG jest SysML. Jest to dedykowany dla inżynierii systemów profil UML. Odnosząc się do procesu inżynierii systemowej powyżej, powstają w tej notacji kolejne diagramy:

1. diagram wymagań (lub ich specyfikacja),
2. diagram przypadków użycia i ich specyfikacja,
3. model dziedziny (mechanizm działania systemu: diagramy komponentów, klas i obiektów) oraz modele zachowania systemu (diagramy sekwencji, komunikacji, scenariusze przypadków użycia).

Powyższe to wymagane minimum dla poprawnego wyspecyfikowania systemu zanim powstanie choć jeden wiersz kodu czy wykop pod fundament.

Z informacji jakie posiadam, od lat rząd USA nie ponosi takich spektakularnych porażek projektowych jak europejskie rządy, jednak w przypadku projektów korporacyjnych już tak różowo nie jest :), wpadki mają wszystkie:

According to an often-quoted study from the Gartner Group, 75% of IT projects fail. The Standish Group conducts an annual survey of IT projects. Their latest report shows a decrease in project success rates.

1. 32% of all projects succeeded: delivered on time, on budget, with required features.
2. 44% were challenged: late, over budget, and/or with less than the required features.
3. 24% failed: cancelled prior to completion or delivered and never used.

When we look back, we not only see failures but can clearly see the boom the software industry has been given with its success. But the worrying aspect is that there are failures that are recurring every year, maybe in a different organization but mostly with common causes. (Źródło: Blueprints Are Not Requirements!)

Polecam książkę 😉

Systems Engineering Fundamentals Kindle Edition by United States Government US Army (Author) (Źródło: Amazon.com: Systems Engineering Fundamentals eBook: United States Government US Army: Kindle Store)