Systems Engineering Fundamentals by United States Government

Tak, taką książ­kę moż­na nabyć na Amazonie ;). Streszczenie na stro­nach sprze­daw­cy odda­je dobrze jej treść:

This book pro­vi­des a basic, con­cep­tu­al-level descrip­tion of engi­ne­ering mana­ge­ment disci­pli­nes that rela­te to the deve­lop­ment and life cyc­le mana­ge­ment of a sys­tem. For the non-engi­ne­er it pro­vi­des an ove­rview of how a sys­tem is deve­lo­ped. For the engi­ne­er and pro­ject mana­ger it pro­vi­des a basic fra­me­work for plan­ning and asses­sing sys­tem development.

Ogólnie książ­ka opi­su­je pod­sta­wo­wy kon­cep­cyj­ny etap inży­nie­rii sys­te­mów (i nie nale­ży tego utoż­sa­miać tyl­ko z bran­żą IT). Jest napi­sa­na przy­stęp­nym języ­kiem, adre­so­wa­na głów­nie dla mana­ge­rów (pierw­sze czę­ści) by zapo­znać ich z inży­nie­rią sys­te­mów i sys­te­mo­wym podej­ściem. Kierownikom pro­jek­tów poka­zu­je” czym (ewen­tu­al­nie ;)) zarządzają.

Tu tyl­ko kil­ka słów. Najpierw po raz kolej­ny cytat:

Problemy, w któ­rych roz­wią­za­niu mają pomóc budo­wa­ne zło­żo­ne sys­te­my są zwy­kle ?pro­ble­ma­mi zło­śli­wy­mi? (Rittel i Webber, 1973). ?Problem zło­śli­wy? to taki skom­pli­ko­wa­ny pro­blem, w któ­rym jest tak wie­le powią­za­nych ze sobą bytów, że nie ist­nie­je jego osta­tecz­na spe­cy­fi­ka­cja. Prawdziwy cha­rak­ter pro­ble­mu obja­wia się dopie­ro w mia­rę opra­co­wy­wa­nia rozwiązania.

A teraz dia­gram obra­zu­ją­cy pro­ces inży­nie­rii sys­te­mo­wej” na bazie jed­nej z ilu­stra­cji w tej książce:

Proces inżynierii systemowej

Mamy tu trzy klu­czo­we eta­py, powią­za­ne iteracyjnie:

  1. Analiza wyma­gań, cho­dzi tu o wyma­ga­nia biznesowe.
  2. Analiza funk­cjo­nal­no­ści, cho­dzi tu o usta­le­nie do jakich rze­czy» sys­tem jest potrzeb­ny (prze­zna­czo­ny).
  3. Projektowanie czy­li pró­ba opra­co­wa­nia kon­struk­cji, mecha­ni­zmu dzia­ła­nia tego systemu.

Trzeci punkt to wła­śnie klucz do suk­ce­su: zanim zacznie­my kon­stru­owa­nie (np. pisa­nie kodu) war­to opra­co­wać to roz­wią­za­nie «na papie­rze”. To po pierw­sze pozwa­la unik­nąć ogrom­nych kosz­tów roz­po­zna­nia bojem” a po dru­gie daje jako pro­dukt bar­dzo dobrą (na wyso­kim pozio­mie abs­trak­cji ale kom­plet­ną) doku­men­ta­cję dzia­ła­nia systemu.

Niedawno cyto­wa­łem arty­kuł o poraż­ce sys­te­mu e‑border, tym razem innych cytat:

The Home Office had a con­cept, not a well-deve­lo­ped set of requ­ire­ments. Concepts need a reali­ty check; other­wi­se, you could be cha­sing a dre­am! Even tho­ugh the pro­gram ran a pilot to eva­lu­ate the feasi­bi­li­ty of the con­cept, the National Audit Office report (2015) cla­ims that it did not cover all aspects of the solu­tion. Consequently, the pro­gram­me was exe­cu­ted with an unte­sted con­cept and unk­nown requ­ire­ments, which led to dispu­tes. (Źródło: Blueprints Are Not Requirements!)

Jedną z głów­nych przy­czyn poraż­ki było roz­po­czę­cie reali­za­cji pro­jek­tu wyłącz­nie na bazie wizji, bez jakich­kol­wiek ana­liz i pro­jek­to­wa­nia tego co na praw­dę ma powstać i w jakich warun­kach”. Patrząc na zobra­zo­wa­ny powy­żej pro­ces inży­nie­rii sys­te­mo­wej wyko­na­no wyłącz­nie pierw­szy etap (wyma­ga­nia biz­ne­so­we) i przy­stą­pio­no do reali­za­cji pro­jek­tu bez jakich­kol­wiek ana­liz i pro­jek­to­wa­nia, od razu zaczę­ły powsta­wać pro­to­ty­py… Projekt e‑border zakoń­czył się spek­ta­ku­lar­ną porażką.

Jedną z nota­cji OMG jest SysML. Jest to dedy­ko­wa­ny dla inży­nie­rii sys­te­mów pro­fil UML. Odnosząc się do pro­ce­su inży­nie­rii sys­te­mo­wej powy­żej, powsta­ją w tej nota­cji kolej­ne diagramy:

  1. dia­gram wyma­gań (lub ich specyfikacja),
  2. dia­gram przy­pad­ków uży­cia i ich specyfikacja,
  3. model dzie­dzi­ny (mecha­nizm dzia­ła­nia sys­te­mu: dia­gra­my kom­po­nen­tów, klas i obiek­tów) oraz mode­le zacho­wa­nia sys­te­mu (dia­gra­my sekwen­cji, komu­ni­ka­cji, sce­na­riu­sze przy­pad­ków użycia).

Powyższe to wyma­ga­ne mini­mum dla popraw­ne­go wyspe­cy­fi­ko­wa­nia sys­te­mu zanim powsta­nie choć jeden wiersz kodu czy wykop pod fundament.

Z infor­ma­cji jakie posia­dam, od lat rząd USA nie pono­si takich spek­ta­ku­lar­nych pora­żek pro­jek­to­wych jak euro­pej­skie rzą­dy, jed­nak w przy­pad­ku pro­jek­tów kor­po­ra­cyj­nych już tak różo­wo nie jest :), wpad­ki mają wszystkie:

According to an often-quoted stu­dy from the Gartner Group, 75% of IT pro­jects fail. The Standish Group con­ducts an annu­al survey of IT pro­jects. Their latest report shows a decre­ase in pro­ject suc­cess rates.

  1. 32% of all pro­jects suc­ce­eded: deli­ve­red on time, on bud­get, with requ­ired features.
  2. 44% were chal­len­ged: late, over bud­get, and/or with less than the requ­ired features.
  3. 24% failed: can­cel­led prior to com­ple­tion or deli­ve­red and never used.

When we look back, we not only see failu­res but can cle­ar­ly see the boom the softwa­re indu­stry has been given with its suc­cess. But the wor­ry­ing aspect is that the­re are failu­res that are recur­ring eve­ry year, may­be in a dif­fe­rent orga­ni­za­tion but mostly with com­mon cau­ses. (Ź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)

Inne artykuły na podobny temat

image_print(wydruk PL)

Komentarze

  1. Harnaś 28 kwietnia 2016 at 16:05

    Co z Pana książ­ką? Termin wyda­nia się przesuwa.

    • Jaroslaw Zelinski 28 kwietnia 2016 at 20:13

      Faktycznie, nie wiem 🙁 .….. zapytam…

Dodaj komentarz

Twój adres email nie zostanie opublikowany

Komentuj i zadawaj pytania autorowi.

Identyfikator *
E-mail *
Witryna internetowa

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.