Моделирование требований к системе 29 icon

Моделирование требований к системе 29


2 чел. помогло.

Смотрите также:
Моделирование бизнес-процессов спецификация требований на основе структурного подхода...
Лекция: Этапы проектирования ис с применением uml: Основные типы uml-диаграмм...
Реферат отчёта по нир на тему: «Разработка требований к системе отраслевых показателей...
Формулирование и анализ требований 1 Определение требований к системе 2 Пользовательские...
Формулирование и анализ требований 1 Определение требований к системе 2 Пользовательские...
Уточнение требований к системе 6 Архитектура системы 8...
Программа вступительного экзамена в магистратуру по направлению...
Руководство по системе pc4020...
“Компьютерное моделирование работы схемы усилителя”...
К минимуму содержания и уровню требований к специалистам для присвоения дополнительной...
Учебная программа. Наименование тем, их содержание...
К минимуму содержания и уровню требований к специалистам для присвоения дополнительной...



страницы: 1   2   3   4   5   6   7   8   9   ...   13
вернуться в начало
скачать
^

Группа проекта



В начале ответим на вопросы, связанные с составом команды разработчиков и распределением обязанностей внутри этой команды. Для разработки ПО так или иначе организуется некоторый коллектив. Это может быть подразделение компании или фирмы, работающей в этом сегменте рынка, или группа единомышленников, только начинающая свою деятельность в области разработки, в конце концов, это может быть просто единственный программист. Такую рабочую группу мы будем называть группой проекта. Давайте определим функциональные обязанности участников этой группы. В состав группы обычно входят следующие специалисты:

руководитель проекта - координирует все действия, организует внешнее и внутреннее взаимодействия группы проекта, обеспечивает соблюдение сроков разработки и качество разрабатываемого ПО и его соответствие требованиям заказчика, несет полную ответственность за результат работ по проекту;

системный аналитик - анализирует требования к системе, разрабатывает концепцию и логику работы системы, составляет технические задания или подобные документы, несет ответственность за соответствие предлагаемых решений требованиям заказчика;

разработчики - реализуют принятые технические задания, отвечают за качество и сроки разрабатываемого кода, за его соответствие техническим заданиям;

дизайнер - участвует в разработке концепции системы, разрабатывает ее пользовательский интерфейс и принимает участие в его реализации, несет ответственность за соблюдение фирменного стиля и требований к реализации пользовательского интерфейса;

тестер - разрабатывает программу тестирования, осуществляет ее и несет ответственность за полноту тестирования готовых модулей и системы в целом;

технический писатель - разрабатывает документацию на проект, несет ответственность за полноту и правильность описания.


Оговорим ряд замечаний. Первое, дизайнер, тестер и технический писатель могут в группу постоянно не входить, а работать над несколькими проектами и привлекаться к работе по мере необходимости. Второе, в подразделение по разработке ПО, состоящее из нескольких проектных групп, может входить технолог, который разрабатывает, внедряет и поддерживает технологию производства программных продуктов. Третье, для сложных проектов, связанных с активным применением сетевых решений, Internet технологий и т. д. в группу проекта может подключаться специалист по использованию сетей. И, наконец последнее, наш состав группы проекта включает в себя только непосредственную команду разработчиков проекта, но кроме них над проектом могут работать и другие специалисты компании: менеджеры, маркетологи и т. д. Теперь перейдем непосредственно к самому процессу разработки.

^

Жизненный цикл




Предварительные замечания



Одним из основополагающих понятий технологии разработки программного обеспечения является понятие жизненного цикла (ЖЦ). Под жизненным циклом ПО понимается совокупность процессов, связанных с последовательным изменением состояния ПО от формирования исходных требований к нему до окончания его эксплуатации. Жизненный цикл состоит из стадий - логически завершенных частей ЖЦ. Стадии характеризуются определенными состоянием ПО, видом предусмотренных работ и их результатом. Выделяют несколько основных типов ЖЦ, различающихся порядком следования стадий и взаимосвязями между ними, которые мы обсудим несколько ниже.


При создании заказного ПО выделяют пять основных стадий ЖЦ:

  • анализ и формализация требований заказчика;

  • проектирование;

  • реализация;

  • тестирование;

  • внедрение и эксплуатация.


Теперь об обещанных типах ЖЦ. В литературе описано множество типов жизненных циклов. Среди всего этого разнообразия можно выделить два основных.

^

Последовательный тип



Данный тип ЖЦ предполагает, что каждая следующая стадия может быть начата только после завершения работ на предыдущей стадии. Он применим когда:

  • требования к продукту четко определены и не меняются со временем;

  • имеется достаточно большой опыт реализации подобного рода систем;

  • время реализации проекта составляет от нескольких месяцев до года.


Реализация проекта по данному типу ЖЦ легко планируется и контролируется. Однако для этого необходимо заранее иметь все требования к продукту. Данный тип ЖЦ не приспособлен к изменениям требований к продукту. Разрабатываемый продукт не может использоваться, пока проект не будет близок к завершению. В реальности в последнее время этот тип жизненного цикла практически никогда не применяется.

^

Эволюционный тип



Функциональные возможности системы в данном случае наращиваются постепенно. В процессе разработки основные стадии ЖЦ (проектирование, реализация, тестирование) проходятся несколько раз применительно к очередной добавляемой порции возможностей системы.


Данный тип ЖЦ не требует заранее наличия всех требований к системе и позволяет заказчику активно участвовать в ее разработке, что является безусловным плюсом. Однако среди недостатков эволюционного типа:

  • сложность в управлении и контроле выполнения проекта;

  • сложность оценки затрат на разработку;

  • риск бесконечного улучшения системы.


Данный тип применим, когда требования к системе плохо определены или будут изменяться, отсутствует достаточный опыт в разработке подобных систем, используются новые технологии и (или) инструментальные средства, в ходе разработки системы необходимо иметь промежуточные версии продукта.

^

Выбор типа жизненного цикла



Выбор конкретного типа жизненного цикла зависит от ряда субъективных и объективных причин, сопутствующих проекту:

  • наличия четких и подробных требований к ПО;

  • ресурсов, имеющихся в наличии для проведения работ по проекту;

  • наличия и доступности заказчика в процессе разработки;

  • новизны используемых при разработке технологий и (или) инструментальных средств.


Обычно решение о выборе конкретного типа жизненного цикла принимается руководителем проекта. Как правило, в реальности применяется смешанный тип жизненного цикла, а в последнее время все чаще Унифицированный Процесс Разработки, но прежде чем перейти к рассмотрению этого процесса необходимо дать понятие системной архитектуры.
^

ЛЕКЦИЯ 2. Архитектура программных систем




Предварительные замечания



Для визуализации, специфицирования, конструирования и документирования программных систем необходимо рассматривать их с различных точек зрения. Все, кто имеет отношение к проекту: конечные пользователи, системные аналитики, руководители проекта, разработчики, тестеры, технические писатели, менеджеры и т.д. - преследуют собственные цели, и каждый смотрит на создаваемую систему по-разному в различные моменты ее жизненного цикла. При этом создаются самые разнообразные артефакты.

Системная архитектура является, возможно, наиболее важным артефактом, который используется для управления всевозможными точками зрения и тем самым способствует итеративной и инкрементной разработке системы на всем промежутке ее жизненного цикла. Раз уж мы ввели в использование эти два понятия, давайте дадим их точные определения, на сколько это возможно в таком предмете как программирование.

Итак, итеративным (iterative) называется процесс, который предполагает управление потоком исполняемых версий системы. Инкрементный (incremental) процесс подразумевает постоянное развитие системной архитектуры при выпуске новых версий системы, причем каждая следующая версия усовершенствована по сравнению с предыдущей. Процесс, являющийся одновременно итеративным и инкрементным, называется управляемым рисками (risk-driven), так как в при этом в каждой новой версии серьезное внимание уделяется выявлению факторов, представляющих наибольший риск для успешного завершения проекта, и сведению их до минимума.


Теперь вернемся непосредственно к понятию архитектура. Под архитектурой программной системы понимается совокупность решений относительно:

  • организации программной системы;

  • выбора структурных элементов, составляющих систему и их интерфейсов;

  • поведения этих элементов, специфицированного в кооперациях с другими элементами;

  • составления из этих структурных и поведенческих элементов все более и более крупных подсистем;

  • архитектурного стиля, направляющего и определяющего всю организацию системы: статические и динамические элементы, их интерфейсы, кооперации и способы их объединения.


Архитектура программной системы охватывает не только ее структурные и поведенческие аспекты, но и использование, функциональность, производительность, гибкость, возможности повторного применения, полноту, экономические и технологические ограничения и компромиссы, а также эстетические вопросы.





Скачать 0,92 Mb.
оставить комментарий
страница2/13
Дата30.09.2011
Размер0,92 Mb.
ТипЛекция, Образовательные материалы
Добавить документ в свой блог или на сайт

страницы: 1   2   3   4   5   6   7   8   9   ...   13
отлично
  3
Ваша оценка:
Разместите кнопку на своём сайте или блоге:
rudocs.exdat.com

Загрузка...
База данных защищена авторским правом ©exdat 2000-2017
При копировании материала укажите ссылку
обратиться к администрации
Анализ
Справочники
Сценарии
Рефераты
Курсовые работы
Авторефераты
Программы
Методички
Документы
Понятия

опубликовать
Документы

наверх