Akwizycja wymagań może być określona jako rdzeń inżynierii wymagań. Akwizycja wymagań polega na pozyskiwaniu wymagań z dostępnych źródeł (np. interesariuszy) za pomocą różnych technik (np. burza mózgów). Podstawą dla akwizycji wymagań jest wiedza zdobyta w trakcie definiowania kontekstu dla tworzonego systemu, który obejmuje źródła wymagań, które w procesie akwizycji wymagań będą dalej analizowane i badane. […]
Akwizycja wymagań Czytaj dalej »
W tym wpisie kontynuuję opis zmian w menu głównym Enterprise Architect, które się pojawiły w wersji 12 tego narzędzia. Pierwszą część znajdziecie we wpisie Enterprise Architect 12 – Zmiany w menu głównym aplikacji – cześć 1. W tej części opis kolejnych pozycji menu: Diagram, Element, Tools, Analyzer i Extensions. Menu Diagram: New – nowa funkcja w menu, która pozwala
Enterprise Architect 12 – Zmiany w menu głównym aplikacji – cześć 2 Czytaj dalej »
Do głównych zadań inżynierii wymagań należy m.in. akwizycja i dokumentacja wymagań na system. Aby tego dokonać należy zidentyfikować te części świata rzeczywistego, które będą miały wpływ na wymagania dotyczące systemu. Ta część rzeczywistości, która ma wpływ na definiowanie wymagań systemu nazywa się kontekstem systemu. Nieprawidłowe lub niepełne określenie kontekstu systemu podczas inżynierii wymagań prowadzi do
Wymagania na system – kontekst i granica systemu Czytaj dalej »
12 lutego firma Sparx Systems udostępniła wersję 12 (zbieg okoliczności daty i numerku wersji?) systemu Enterprise Architect. Wśród zmian znalazły się m.in. zmiany w wyglądzie aplikacji oraz nowe zestawy narzędzi. Zmiany zaszły także w głównym menu aplikacji. Moje pierwsze wrażenie jest pozytywne. Poszczególne elementy menu znalazły się w bardziej intuicyjnych miejscach. Cześć nazw została skrócona. Nawigacja po
Enterprise Architect 12 – Zmiany w menu głównym aplikacji – część 1 Czytaj dalej »
W poprzednim wpisie określiłem kilka definicji, którymi będę się posługiwał w cyklu tekstów o inżynierii wymagań. Czas podział wymagań. Wymagania dzielę na wymagania funkcjonalne i wymagania niefunkcjonalne (zwane także wymaganiami jakościowymi). Ponadto identyfikuję ograniczenia. Wymagania funkcjonalne określają funkcjonalność tworzonego oprogramowania. Wymagania funkcjonalne mogą być podzielone na wymagania funkcjonalne, wymagania dotyczące zachowania systemu oraz wymagania dotyczące
Rodzaje wymagań Czytaj dalej »
Sparx Systems opublikował kilka dni temu 12 wersję kultowego Enterprise Architect. Wstępna analiza wykazała, że aktualizacja narzędzia może doprowadzić do problemów w starych repozytoriach. Podobne wpisy Zintegrowane środowisko wytwarzania aplikacji web’owych na platformie .NET W artykule przedstawiono opis pakietu narzędziowego VS.NET (Microsoft) z Rational XDE (IBM) do wytwarzania aplikacji webowych pracujących w środowisku urządzeń
Enterprise Architect 12 – nie instaluj pochopnie Czytaj dalej »
Wpisy na temat inżynierii wymagań zacznę od podstawowych definicji. Definicja: Wymaganie 1.Ograniczenie lub zdolność potrzebna użytkownikowi do rozwiązania problemu lub osiągnięcia określonego celu. 2.Ograniczenie lub zdolność, które musi być spełnione lub zrealizowane przez system lub składnik systemu w celu spełnienia warunków umowy, standardu, specyfikacji lub innych formalnych dokumentów. 3.Udokumentowana reprezentacja ograniczeń i zdolności określonych w
Wprowadzenie do zarządzania wymaganiami–podstawowe definicje Czytaj dalej »
Enterprise Architect na polskim rynku wypiera skutecznie inne narzędzia. Na blogu ArchitekturaKorporacyjna.pl praktycznie pojawiło się bardzo sensowny opis pozycji tego narzędzia. Zapraszam do lektury Raport Gartnera o repozytoriach architektonicznych. Podobne wpisy Zintegrowane środowisko wytwarzania aplikacji web’owych na platformie .NET W artykule przedstawiono opis pakietu narzędziowego VS.NET (Microsoft) z Rational XDE (IBM) do wytwarzania aplikacji webowych pracujących w
Raport Gartnera o repozytoriach architektonicznych Czytaj dalej »
Proces tworzenia oprogramowania można traktować jako rurociąg z żądaniami funkcji wchodzącymi z jednej strony i lepszym oprogramowaniem wychodzącym z drugiej. Wewnątrz rurociągu, istnieje pewien rodzaj procesu, który może wahać się od nieformalnego procesu ad hoc do bardzo formalnego etapowego procesu. W tym artykule, założymy prosty proces fazowy: (1) analiza wymogów, (2) opracowanie kodu i (3)
Kanban i wykrywanie wąskich gardeł Czytaj dalej »
Kanban jest procesem ewolucyjnym lub sposobem dokonywania zmian ewolucyjnych w celu poprawy obecnie stosowanych procesów, nawet Scrum!Mimo tego, iż Scrum cieszy się wielkim powodzeniem i zastosowaniem na całym świecie, wiele zespołów i organizacji miało problemy z wdrożeniem wszystkich jej aspektów. Problemy te mogły być związane ze zmianami organizacyjnymi i ról lub niemożnością sprostania iteracji lub
Scrumban czyli scrum i kanban Czytaj dalej »
