Informacja

Drogi użytkowniku, aplikacja do prawidłowego działania wymaga obsługi JavaScript. Proszę włącz obsługę JavaScript w Twojej przeglądarce.

English (EN)·Polski (PL)·Yкраїнський (UK)
Przejdź do strony domowej biblioteki Centralna Biblioteka Wojskowa Link otwiera się w nowym oknie Logo biblioteki Prolib Integro - strona głównaCentralna Biblioteka Wojskowa

Wyszukujesz frazę "inżynieria wymagań" wg kryterium: Temat

  Lista filtrów
Wyrównaj
    Wyświetlanie 1-4 z 4
    Tytuł:
    Inżynieria wymagań w metodach Agile
    Requirements Engineering in Agile Software Development
    Autorzy:
    Lipski, A.
    Powiązania:
    https://bibliotekanauki.pl/articles/1396866.pdf
    Data publikacji:
    2010
    Wydawca:
    Wojskowa Akademia Techniczna im. Jarosława Dąbrowskiego
    Tematy:
    Agile
    inżynieria wymagań
    inżynieria oprogramowania
    agile
    requirements engineering
    software engineering
    Opis:
    "Zwinne" wytwarzanie oprogramowania (Agile Software Development) stało się bardzo popularne na przestrzeni kilku ostatnich lat. Metody Agile zostały wymyślone w celu szybszego dostarczenia działającego oprogramowania do klienta oraz dostosowania się oprogramowania do zmiennych potrzeb klienta. Można zauważyć, że istnieje wiele technik i praktyk wymyślonych oraz opracowanych w kontekście tradycyjnej inżynierii wymagań, które obecnie wykorzystywane są z dobrym rezultatem przez metody Agile. Celem tego artykułu jest pokazanie, w jaki sposób techniki inżynierii wymagań są wykorzystywane przez metody Agile oraz w jaki sposób metody te mogą być udoskonalone za pomocą tych technik.
    Agile Software Development approaches have become increasingly popular during the last few years. Agile practises have been developed with the aim to deliyer software faster and to ensure that the software meets changing needs of customers. We can find out that there are a lot of practices and approaches which are created and developed in context of traditional Requirements Engineering and which are used by Agile methods with a good result. The goal of this article is to show how the Requirements Engineering technics are used by Agile methods and how this methods can be improved by them.
    Źródło:
    Biuletyn Instytutu Systemów Informatycznych; 2010, 5; 47-53
    1508-4183
    Pojawia się w:
    Biuletyn Instytutu Systemów Informatycznych
    Dostawca treści:
    Biblioteka Nauki
    Artykuł
    Tytuł:
    Analiza porównawcza witryn internetowych w skali pomiarowej HHS
    Comparative analysis of websites based on a HHS (U. S. Department of Health and Human Services) measurement scale
    Autorzy:
    Pieczyński, S.
    Susłow, W.
    Powiązania:
    https://bibliotekanauki.pl/articles/151823.pdf
    Data publikacji:
    2012
    Wydawca:
    Stowarzyszenie Inżynierów i Techników Mechaników Polskich
    Tematy:
    inżynieria wymagań
    użyteczność stron www
    analiza porównawcza
    requirements engineering
    websites usability
    comparative analysis
    Opis:
    Artykuł przedstawia technikę analizy porównawczej jako narzędzie inżynierii wymagań. Wytyczne HHS tworzą obiektywną porządkową skalę pomiarową, przydatną do porównywania jakości użytkowej witryn internetowych o zbliżonej tematyce. Kompletowanie zestawu wytycznych zgodnie z celem analizy zwiększa praktyczne znaczenie uzyskiwanego rankingu witryn internetowych. Technika analizy porównawczej opartej o skalę pomiarową HHS okazała się skuteczna w ramach projektów dydaktycznych i kwalifikacyjnych.
    This paper presents a comparative analysis technique as a tool for requirements engineering. HHS guidelines form an objective ordinal measuring scale which is useful for comparing the usability of web-sites with similar themes. Each guideline is described in a study using the relative weights (called Relative Importance) and probative force (called Strength of Evidence). Completing a set of guidelines in accordance with the objective of the project increases practical significance of the obtained ranking of IT products. The comparative analysis technique based on the measuring scale HHS proved to be effective for qualification projects. Section 2 of the paper describes a set of guidelines and a grading scale of HHS. Section 3 presents the authors' proposal concerning the order of selection guidelines for a particular study (see Fig. 1). Section 4 describes a case study on the comparative analysis of selected music vortals in the master's diploma project (it was the pioneering work for the Department of Electronics and Computer Science of the Koszalin University of Technology).
    Źródło:
    Pomiary Automatyka Kontrola; 2012, R. 58, nr 5, 5; 475-479
    0032-4140
    Pojawia się w:
    Pomiary Automatyka Kontrola
    Dostawca treści:
    Biblioteka Nauki
    Artykuł
    Tytuł:
    User requirements for mission-critical application - the SECRICOM case
    Wymagania użytkownika dotyczące systemu krytycznego - przypadek SECRICOM
    Autorzy:
    O'Neill, S.
    Strother, J.
    Zych, J.
    Wojciechowicz, W.
    Powiązania:
    https://bibliotekanauki.pl/articles/298324.pdf
    Data publikacji:
    2012
    Wydawca:
    Uniwersytet Warmińsko-Mazurski w Olsztynie
    Tematy:
    SECRICOM
    interoperacyjność
    zarządzanie kryzysowe
    inżynieria wymagań
    system krytyczny
    interoperability
    crisis management
    requirements engineering
    critical system
    Opis:
    The SECRICOM Project as a communication system for operational crisis management, requires paying significant attention to the requirements engineering phase. Any mistakes made during the requirements gathering phase may affect the subsequent software development phases, which creates excessive operational risks for the users of the system. These types of risks - as in any other critical systems - could have serious consequences, such as inefficiency of rescue actions and loss of lives. This article presents the requirements engineering process, which was defined and carried out for the needs of the SECRICOM project. It describes the system's environment (the crisis management reference structure and the main organizational rules) and its impact on the developed. As a result, a requirements engineering process for SECRICOM is proposed. Finally, main points of gathered requirements are presented.
    W systemie SECRICOM, ze względu na tworzenie systemu komunikacji do operacyjnego zarządzania kryzysowego, szczególnie ważne było położenie szczególnego nacisku na etap gromadzenia wymagań. Błędy popełnione na etapie specyfikacji wymagań mogą rzutować na kolejne etapy wytwarzania systemu, co w rezultacie generuje nadmiarowe ryzyka dla użytkowników systemu. Ryzyka te - jak w przypadku innych systemów krytycznych - mogą spowodować poważne konsekwencje, w tym obniżenie skuteczności akcji ratunkowych, a nawet straty po stronie ludności. W artykule przedstawiono proces inżynierii wymagań, który zdefiniowano oraz przeprowadzono na potrzeby projektu SECRICOM. Przedstawiono środowisko systemu (zarówno referencyjną strukturę zarządzania kryzysowego, jak i główne zasady organizacji) oraz określono wpływ na budowany system. Na zakończenie przedstawiono główne wnioski z zebranych wymagań.
    Źródło:
    Technical Sciences / University of Warmia and Mazury in Olsztyn; 2012, 15(1); 81-99
    1505-4675
    2083-4527
    Pojawia się w:
    Technical Sciences / University of Warmia and Mazury in Olsztyn
    Dostawca treści:
    Biblioteka Nauki
    Artykuł
    Tytuł:
    Agile effort estimation in software development projects – case study
    Zwinne szacowanie pracochłonności w projektach programistycznych – studium przypadków
    Autorzy:
    Łabędzki, Maciej
    Promiński, Patryk
    Rybicki, Adam
    Wolski, Marcin
    Powiązania:
    https://bibliotekanauki.pl/articles/14495622.pdf
    Data publikacji:
    2017-11-22
    Wydawca:
    Wyższa Szkoła Bankowa we Wrocławiu
    Tematy:
    software development
    estimation
    effort
    measurement
    requirements engineering
    story points
    Scrum
    wytwarzanie oprogramowania
    szacowanie
    pracochłonność
    miary
    inżynieria wymagań
    Opis:
    Cel: Celem niniejszej pracy jest wskazanie powszechnych błędów i pułapek, a także sprawdzonych praktyk w zakresie estymacji pracochłonności w projektach programistycznych. Jakość oszacowań w mniej doświadczonych zespołach jest często niezadowalająca, wskutek czego estymacja jako element procesu wytwarzania oprogramowania jest porzucana. Decyzja zwykle uzasadniana jest błędnie rozumianą „zwinnością”. Artykuł wpisuje się w dyskusję nad bieżącymi trendami w zakresie szacowania, w szczególności w kontekście nowego podejścia „no estimates”.   Metodyka badań: Publikacja ma formę studium przypadków opartego o doświadczenia dojrzałego zespołu programistycznego. Autor, na podstawie znanych z literatury technik estymacji, wskazuje dobre i złe praktyki oraz często popełniane błędy w myśleniu i postępowaniu.   Wnioski: Kluczowe dla poprawnej estymacji okazują się: zrozumienie różnicy pomiędzy pracochłonnością i czasochłonnością, umiejętność monitorowania wydajności, a także sposób analizowania wymagań i sytuacja kadrowa zespołu.   Wartość artykułu: Publikacja pomaga opanować techniki podnoszące poziom zaufania do wszelkich oszacowań (czasu trwania, a pośrednio – kosztu wytwarzania oprogramowania) tam, gdzie znane są wymagania, jednak głównie na etapie realizacji projektu (projekt i implementacja).  Ograniczenia: Praca nie porusza problemów wstępnej estymacji przedsięwzięć, tj. estymacji dokonywanej na wczesnych etapach planowania.
    Aim:Aim: The purpose of this paper is to identify common mistakes and pitfalls as well as best practices in estimating labor intensity in software projects. The quality of estimations in less experienced teams is often unsatisfactory, as a result of which estimation as part of the software development process is abandoned. The decision is usually justified by misunderstanding "agility". This article is part of the discussion on current trends in estimation, especially in the context of the new "no estimates" approach.Design / Research methods: The publication is a case study based on the experience of a mature development team. The author, on the basis of literature-based estimation techniques, shows good and bad practices, as well as common mistakes in thinking and behavior.Conclusions / findings: The key to correct estimation is: understanding the difference between labor intensity and time, ability to monitor performance, as well as how to analyze staff requirements for the team.Originality / value of the article: The publication helps to master confidence-boosting techniques for any estimation (duration, and indirectly, the cost of software development) where requirements are known, but mainly at the stage of project implementation (design and implementation).Limitations of the research: The work does not address the problems of initial estimation of projects, i.e. the estimation made in the early stages of planning.
    Źródło:
    Central European Review of Economics and Management; 2017, 1, 3; 135-152
    2543-9472
    Pojawia się w:
    Central European Review of Economics and Management
    Dostawca treści:
    Biblioteka Nauki
    Artykuł
      Wyświetlanie 1-4 z 4

      Ta witryna wykorzystuje pliki cookies do przechowywania informacji na Twoim komputerze. Pliki cookies stosujemy w celu świadczenia usług na najwyższym poziomie, w tym w sposób dostosowany do indywidualnych potrzeb. Korzystanie z witryny bez zmiany ustawień dotyczących cookies oznacza, że będą one zamieszczane w Twoim komputerze. W każdym momencie możesz dokonać zmiany ustawień dotyczących cookies