Preferencje help
Widoczny [Schowaj] Abstrakt
Liczba wyników

Znaleziono wyników: 3

Liczba wyników na stronie
first rewind previous Strona / 1 next fast forward last
Wyniki wyszukiwania
help Sortuj według:

help Ogranicz wyniki do:
first rewind previous Strona / 1 next fast forward last
EN
Acceptance tests are usually created by a client after a part of a system is implemented. However, some methodologies propose the elaboration of test cases before implementing a system. This approach increases the probability of system implementation that fulfills requirements, but may be problematic for customers and testers. To allow acceptance testing in such conditions, we propose to define test cases by recording them on an interactive mockup (a low detailed user-interface prototype). The paper focuses on Test Description Language, a notation used to store test cases.
PL
Wiele specyfikacji wymagań (SRS) zwiera niepoprawnie spisane wymaganie. Jakość produktu wynika z jakości każdego z komponentów. Posiadając złe wymagania nie jesteśmy w stanie stworzyć wysokiej jakości produkt. W celu zwiększenia jakości specyfikacji wymagań, stosujemy przeglądy, ponieważ jesteśmy opłacani za to co tworzymy. Obie strony muszą jednakowo rozumieć spisane wymagania. Kolejnym aspektem jest koszt takiego przeglądu. Znaczenie tego kryterium jest jeszcze większe, w przypadku gdy zespół pracuje zdalnie. Rozwiązaniem tych problemów jest propozycja asynchronicznych przeglądów. Proces ten składa się z czterech faz: przygotowanie, przegląd, oczyszczanie oraz analiza ryzyka. Faza przeglądu jest oparta na metodzie przeglądów n-częściowych. W celu oszacowania liczby defektów pozostających w specyfikacji stosuje się metodę podwójnego łowienia. Jeśli ta liczba jest akceptowalna, proces przechodzi do następnej fazy. W ostatnim rozdziale opisano prototyp rozwiązania - aplikację która wspiera proces asynchronicznych przeglądów.
EN
Many software requirements specifications (SRS) are filled with badly written requirements. Quality of the products base on quality of all components, with bad requirements we are not able to write good software. To increase SRS quality requirements reviews can be used. We are also expected to write what our customers paid for. We must assure that both sides understand requirements specification the same way. Another aspect is cost of requirements review meeting. This is essential when team members works remotely on the project. To address these problems asynchronous requirements review process was proposed. This process consist of four phases: preparation, review, data cleaning and risk analysis. Review phase is build on N-fold reviews method. Capture-recapture method was used to estimate number of defect left in specification after review. If this number is acceptable we can move to the next phase of project. In the last chapter prototype of software that can support asynchronous reviews process was described.
EN
The following article describes the portfolio management solution developed by students of Poznań University of Technology. ProCons is a versatile, simple system designed to work in agile environments with a minimal overweight. ProCons is thought as a help to run Software Development Studio projects on Poznań University of Technology, but can be easily used anywhere else.
PL
Artykuł prezentuje system typu portfolio management stworzony przez studentów Politechniki Poznańskiej. ProCons jest uniwersalnym, prostym systemem zaprojektowanym do wykorzystania w projektach prowadzonych wg zwinnych podejść. ProCons powstał z myślą o Studiu Rozwoju Oprogramowania, ale może zostać z łatwością użyty w innych zastosowaniach.
first rewind previous Strona / 1 next fast forward last
JavaScript jest wyłączony w Twojej przeglądarce internetowej. Włącz go, a następnie odśwież stronę, aby móc w pełni z niej korzystać.