Projekt aplikacji – przykład

Wstęp

Napisałem o orien­ta­cji na doku­men­ty w toku analiz:

Często jestem i ja pyta­ny o to ??Jak wyja­śnić zło­żo­ne roz­wią­za­nie tech­nicz­ne inte­re­sa­riu­szom nie­tech­nicz­nym?? Jak wie­lu mi podob­nych odpo­wia­dam: roz­ma­wiaj doku­men­ta­mi. Sponsor pro­jek­tu, przy­szli użyt­kow­ni­cy, postrze­ga­ją swo­ją pra­cę poprzez doku­men­ty: ich treść i układ. (Wymagania na for­mu­la­rze czy­li dia­gra­my struk­tur zło­żo­nych i XML)

Dzisiaj pój­dzie­my dalej, omó­wi­my to gdzie i jak zacho­wać tę infor­ma­cję. Posłużę się pro­stym przy­kła­dem przy­chod­ni wete­ry­na­ryj­nej. Artykuł będzie opi­sem meto­dy podej­ścia do ana­li­zy zorien­to­wa­nej na pro­ce­sy i dokumenty. 

Tekst ma dwie czę­ści: pierw­sza jest opi­sem dro­gi jaka pro­wa­dzi nas do zde­fi­nio­wa­nia tego jakie doku­men­ty, jaką mają (mieć) zawar­tość i struk­tu­rę. Praktycznie jest to opis ana­li­zy i pro­jek­to­wa­nia. Druga – krót­ka – to przy­kła­do­wa archi­tek­tu­ra logi­ki reali­za­cji apli­ka­cji, poka­zu­ją­ca miej­sce doku­men­to­wej bazy danych w archi­tek­tu­rze i pro­jek­cie, czy­li tak­że projektowanie. 

Celem tego wpi­su jest poka­za­nie czym może być ana­li­za oraz jej pro­dukt jakim jest Techniczny Projekt Oprogramowania.

(wię­cej…)

Czytaj dalejProjekt aplikacji – przykład

MDA – Cztery produkty czyli dwa etapy: wymagania i produkt

Ten artykuł można czytać na dwa sposoby: analitycy czytają od dechy do dechy po kolei ;). Menedżerowie i tak zwany biznes czytają od razu koniec, to jest część Na zakończenie, gdy uznają, że nie wierzą w te wnioski (wyrok) to zaczynają od początku czyli czytają uzasadnienie :). Niedawno napisałem: Pomiędzy pojęciami abstrakcja i model jest pewna kluczowa różnica: abstrakcja to pojęcie zaś model to opis mechanizmu, jego konstrukcja, działanie, budowa. Prosty przykład: nazwane prostokąty na typowym diagramie struktury organizacyjnej to abstrakcje komórek organizacyjnych i osób w nich zatrudnionych, prostokąty te…

Czytaj dalejMDA – Cztery produkty czyli dwa etapy: wymagania i produkt
Read more about the article Produkt analizy jako twierdzenie naukowe
praca grupowa,

Produkt analizy jako twierdzenie naukowe

Znakomita większość programów zawiera ponad 10 krotnie więcej kodu niż mogła by mieć, bo programiści często implementują warianty zachowań a nie ich mechanizmy (co powoduje, że systemy te są tyleż razy droższe niż mogły by być). Prawie za każdym razem, gdy mówię (ale nie robię tego jednak zbyt często ;) ), że stosuję metody naukowe w analizie, spotykam się z zarzutem, że przesadzam. Zapewne nie ma sensu epatowanie w projektach biznesowych akademickim słownictwem, nie ma znaczenia dobór słownictwa w nazwaniu metody pracy, bo znaczenie ma skuteczność. Wprowadzenie Ludzie i ich praca…

Czytaj dalejProdukt analizy jako twierdzenie naukowe

Systems Engineering Fundamentals by United States Government

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,…

Czytaj dalejSystems Engineering Fundamentals by United States Government

Zdalna analiza wymagań

Wprowadzenie Całkiem niedawno wpadł mi w oczy artykuł na temat zdalnego prowadzenia analizy,  ostatni jego akapit brzmi: Virtual communication and facilitation skills will remain a key competency for BAs for years to come. Stop torturing your stakeholders with boring, ineffective conference calls. Find new and creative ways to alleviate the common pain points. Please share your virtual facilitation tips in the comments below! (Business Analyst | Virtual Requirements Meetings: Painful or Practical?). (w uproszczeniu: zdalnie prowadzona analiza to kluczowa przyszła kompetencja analityków, warto przestać torturować ludzi wielogodzinnymi nudnymi spotkaniami, znajdź…

Czytaj dalejZdalna analiza wymagań

Visual-Paradigm czyli pokaż czym pracujesz a powiem Ci kim jesteś…

Pakiet którego używam (Visual-Paradigm) po ostatnich zmianach ma szanse stać się w moich oczach ideałem :).  O jego nowej wersji pisałem tu: Visual-Paradigm v.11.1. Pisałem tez, że jest w 100% zgodny ze specyfikacjami notacji zarządzanych przez OMG, co jest bardzo ważne. Tu zwrócę uwagę na kilka przydatnych cech. Moim zdaniem cechą dobrego projektu jest nie tylko dobra metodyka ale także to czy dysponujemy narzędziami, które ją wspierają. Tymi narzędziami są nie tylko notacje i systemy pojęciowe ale także oprogramowanie CASE, które powinno spełniać trzy kluczowe warunki: wspierać (a przynajmniej nie ograniczać) metodykę,…

Czytaj dalejVisual-Paradigm czyli pokaż czym pracujesz a powiem Ci kim jesteś…

Utopia – czyli model ideału pomaga w projektach

Ten wpis adresuję przede wszystkim menedżerom nie tylko IT. Analitycy i programiści spokojnie mogą go pominąć, chyba, że ...;) chcą wiedzieć dlaczego powinny powstawać idealne projekty, kiedy mogą czasem wykonać niekoniecznie idealną implementację i dlaczego nie należy pomijać etapu idealnego projektowania. [...] Na zakończenie przyznam, że wśród moich niedoszłych klientów i programistów mam wielu wrogów. To Ci, którzy uważają, że analizy i projektowanie całości (co by tu słowo całość nie miało oznaczać) na samym początku są bez sensu, bo i tak wymagania biznesu się zmienią, więc i program będzie się zmieniał. Ja wtedy pytam: zmieniał czy rozszerzał? Jeżeli wymagania się zmieniają to raczej sygnał, że nie zostały na początku przemyślane... Biznes także ma skłonności do zaciągania opisywanego długu... Na koniec w kwestii wrogów pół żartem i pół serio: Chińczycy hołdują powiedzeniu: ?jak posiedzisz wystarczająco długo nad brzegiem rzeki, to zobaczysz trupy swoich wrogów płynące z prądem". No więc sobie siedzę. ... i nie raz je oglądam... a siedzę sobie analizując i projektując... ;) i nie jestem tu sam...

Czytaj dalejUtopia – czyli model ideału pomaga w projektach

Nowy paradygmat systemowy

Podstawową wyższością, dającą przewagę na rynku, jest zwinność organizacji. SOA to nic innego jak taka właśnie struktura systemu informatycznego: specjalizowane aplikacje, komponenty, instalowane (wdrażane) do realizacji konkretnych potrzeb zasobów takich jak pracownicy księgowości, pracownicy sprzedaży, pracownicy produkcyjni, itp.. Co więc robić? Opisać strategie rynkową firmy, Przeanalizować i opisać model biznesowy (sposób powstawania i źródło głównych dochodów), Uszczegółowić model biznesowy do opisu procesów kluczowych biznesowych i reguł biznesowych, Wskazać procesy, których wsparcie metodami informatycznymi przyniesie mierzalne korzyści, Zaprojektować (udokumentować) architekturą systemu informatycznego ukierunkowana na zasoby i usługi. Jeżeli pogodzimy się z faktem, że SOA to usługowa architektura systemu informatycznego firmy, zaś wszelkie webserwisy, szyny itp. to tylko możliwa implementacji (ale nie jedyna!) tej architektury to już będzie z górki. (W co inwestować w kryzysie c.d. - SOA) Tak więc, jak mawia mój znajomy profesor filozofii: gdy dwóch mówi to samo to nie jest to samo. Tu, o SOA, komponentach, analizie i projektowaniu zorientowanym na usługi mówi wielu. Dostawcy systemów ERP o zwartej, zintegrowanej architekturze będą tu z natury zachowywali bezwładność: SOA powoduje, że żaden ERP (system i jego dostawca) nie będzie miał monopolu u raz pozyskanego klienta.

Czytaj dalejNowy paradygmat systemowy

Koniec treści

Nie ma więcej stron do załadowania