Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
- он более для программистов, имхо.
Да, вполне реально, но сложно. Сначала производится сбор требований, проектирование архитектуры, оценка трудоёмкости и планирование "в общем". Затем проект разделяется на подпроекты. На подпроекты выделяются SCRUM-команды, максимум по 5-6 чел, и уже ПМ, аналитик и архитектор являются для них product owner'ами.Да, пришел к такому же выводу, только вы все четко расписали. Спасибо
В подпроектах первый (первые) спринты - проектирование и фиксация интерфейсов между компонентами, разрабатываемыми каждой из групп (эти интерфейсы стараются не менять, а если менять - обсуждать и оповещать об этом всех), и создание "заглушек" с такими интерфейсами, последний (последние) - интеграция.
А вообще нафих системному аналитику UML?Нафих не нужен
. Но иногда спасает картинка, хотя картинку можно и не в UML нотации нарисовать.
Скоординироваться надо, как на SEF (и слайдов друг у друга наворовать).
Планирую выступить по тематике Особенности сбора требований в продуктовой разработкеА чем коробочный продукт отличается от некоробочного? Ира, какие ты для себя видишь отличия?
Если я правильно понимаю, под продуктовой разработкой здесь понимается разработка коробочных продуктов.
Хочется узнать мнение форумян: актуальна ли эта тематика, и какие аспекты темы хотелось бы обсудить в рамках ReqLabs.
И все-таки он Якобсон, а не Джекобсон ... и Ивар, а не Айвар :-) ... это все американцы на свой манер хотят скандинавов называть :-). Так же как и Крухтен, а не Кратчен :-) ....Спасибо за исправления
. Будем знать
под абстрактным понимается именно esential т.е. такой, в котором описано лишь верхнеуровневое поведение системы, а детали могут быть вынесены в нижний уровень абстракции (аля наследники). Также стоит заметить, что Коберн почти не использует UML и говорит о ВИ как о текстовом описании. и наткнулся на замечательную вещь.Abstract and Concrete Use Cases
A concrete use case is a particular type of use case that is directly invoked by an actor and achieves a specific goal. It is self-contained and illustrates a complete flow of events. A concrete use case is a specific instance of using a common set of steps referred to as an abstract use case.
An abstract use case is a particular type of use case that is not directly invoked by an actor but is called by another use case.
When two or more use cases have a sequence of the same steps, these steps are extracted and put into a common use case. This common, or abstract, use case is then available to be included in any other use case within the system. Abstract use cases eliminate redundancy and promote reuse, a goal of object-oriented systems design.
Because an abstract use case contains only a subset of the steps in a flow of events, it may not make sense as a standalone use case. An abstract use case is included as part of one or more concrete use cases in order to represent a complete flow of events.
Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Third Edition by Craig Larman
30.2. Terminology: Concrete, Abstract, Base, and Addition Use Cases
A concrete use case is initiated by an actor and performs the entire behavior desired by the actor [RUP]. These are the elementary business process use cases. For example, Process Sale is a concrete use case. By contrast, an abstract use case is never instantiated by itself; it is a subfunction use case that is part of another use case. Handle Credit Payment is abstract; it doesn't stand on its own, but is always part of another story, such as Process Sale.
A use case that includes another use case, or that is extended or specialized by another use case is called a base use case. Process Sale is a base use case with respect to the included Handle Credit Payment subfunction use case. On the other hand, the use case that is an inclusion, extension, or specialization is called an addition use case. Handle Credit Payment is the addition use case in the include relationship to Process Sale. Addition use cases are usually abstract. Base use cases are usually concrete.
