Моделирование требований к системе 29
2 чел. помогло. вернуться в начало
| скачать ^ В начале ответим на вопросы, связанные с составом команды разработчиков и распределением обязанностей внутри этой команды. Для разработки ПО так или иначе организуется некоторый коллектив. Это может быть подразделение компании или фирмы, работающей в этом сегменте рынка, или группа единомышленников, только начинающая свою деятельность в области разработки, в конце концов, это может быть просто единственный программист. Такую рабочую группу мы будем называть группой проекта. Давайте определим функциональные обязанности участников этой группы. В состав группы обычно входят следующие специалисты: руководитель проекта - координирует все действия, организует внешнее и внутреннее взаимодействия группы проекта, обеспечивает соблюдение сроков разработки и качество разрабатываемого ПО и его соответствие требованиям заказчика, несет полную ответственность за результат работ по проекту; системный аналитик - анализирует требования к системе, разрабатывает концепцию и логику работы системы, составляет технические задания или подобные документы, несет ответственность за соответствие предлагаемых решений требованиям заказчика; разработчики - реализуют принятые технические задания, отвечают за качество и сроки разрабатываемого кода, за его соответствие техническим заданиям; дизайнер - участвует в разработке концепции системы, разрабатывает ее пользовательский интерфейс и принимает участие в его реализации, несет ответственность за соблюдение фирменного стиля и требований к реализации пользовательского интерфейса; тестер - разрабатывает программу тестирования, осуществляет ее и несет ответственность за полноту тестирования готовых модулей и системы в целом; технический писатель - разрабатывает документацию на проект, несет ответственность за полноту и правильность описания. Оговорим ряд замечаний. Первое, дизайнер, тестер и технический писатель могут в группу постоянно не входить, а работать над несколькими проектами и привлекаться к работе по мере необходимости. Второе, в подразделение по разработке ПО, состоящее из нескольких проектных групп, может входить технолог, который разрабатывает, внедряет и поддерживает технологию производства программных продуктов. Третье, для сложных проектов, связанных с активным применением сетевых решений, Internet технологий и т. д. в группу проекта может подключаться специалист по использованию сетей. И, наконец последнее, наш состав группы проекта включает в себя только непосредственную команду разработчиков проекта, но кроме них над проектом могут работать и другие специалисты компании: менеджеры, маркетологи и т. д. Теперь перейдем непосредственно к самому процессу разработки. ^ Предварительные замечанияОдним из основополагающих понятий технологии разработки программного обеспечения является понятие жизненного цикла (ЖЦ). Под жизненным циклом ПО понимается совокупность процессов, связанных с последовательным изменением состояния ПО от формирования исходных требований к нему до окончания его эксплуатации. Жизненный цикл состоит из стадий - логически завершенных частей ЖЦ. Стадии характеризуются определенными состоянием ПО, видом предусмотренных работ и их результатом. Выделяют несколько основных типов ЖЦ, различающихся порядком следования стадий и взаимосвязями между ними, которые мы обсудим несколько ниже. При создании заказного ПО выделяют пять основных стадий ЖЦ:
Теперь об обещанных типах ЖЦ. В литературе описано множество типов жизненных циклов. Среди всего этого разнообразия можно выделить два основных. ^ Данный тип ЖЦ предполагает, что каждая следующая стадия может быть начата только после завершения работ на предыдущей стадии. Он применим когда:
Реализация проекта по данному типу ЖЦ легко планируется и контролируется. Однако для этого необходимо заранее иметь все требования к продукту. Данный тип ЖЦ не приспособлен к изменениям требований к продукту. Разрабатываемый продукт не может использоваться, пока проект не будет близок к завершению. В реальности в последнее время этот тип жизненного цикла практически никогда не применяется. ^ Функциональные возможности системы в данном случае наращиваются постепенно. В процессе разработки основные стадии ЖЦ (проектирование, реализация, тестирование) проходятся несколько раз применительно к очередной добавляемой порции возможностей системы. Данный тип ЖЦ не требует заранее наличия всех требований к системе и позволяет заказчику активно участвовать в ее разработке, что является безусловным плюсом. Однако среди недостатков эволюционного типа:
Данный тип применим, когда требования к системе плохо определены или будут изменяться, отсутствует достаточный опыт в разработке подобных систем, используются новые технологии и (или) инструментальные средства, в ходе разработки системы необходимо иметь промежуточные версии продукта. ^ Выбор конкретного типа жизненного цикла зависит от ряда субъективных и объективных причин, сопутствующих проекту:
Обычно решение о выборе конкретного типа жизненного цикла принимается руководителем проекта. Как правило, в реальности применяется смешанный тип жизненного цикла, а в последнее время все чаще Унифицированный Процесс Разработки, но прежде чем перейти к рассмотрению этого процесса необходимо дать понятие системной архитектуры. ^ Для визуализации, специфицирования, конструирования и документирования программных систем необходимо рассматривать их с различных точек зрения. Все, кто имеет отношение к проекту: конечные пользователи, системные аналитики, руководители проекта, разработчики, тестеры, технические писатели, менеджеры и т.д. - преследуют собственные цели, и каждый смотрит на создаваемую систему по-разному в различные моменты ее жизненного цикла. При этом создаются самые разнообразные артефакты. Системная архитектура является, возможно, наиболее важным артефактом, который используется для управления всевозможными точками зрения и тем самым способствует итеративной и инкрементной разработке системы на всем промежутке ее жизненного цикла. Раз уж мы ввели в использование эти два понятия, давайте дадим их точные определения, на сколько это возможно в таком предмете как программирование. Итак, итеративным (iterative) называется процесс, который предполагает управление потоком исполняемых версий системы. Инкрементный (incremental) процесс подразумевает постоянное развитие системной архитектуры при выпуске новых версий системы, причем каждая следующая версия усовершенствована по сравнению с предыдущей. Процесс, являющийся одновременно итеративным и инкрементным, называется управляемым рисками (risk-driven), так как в при этом в каждой новой версии серьезное внимание уделяется выявлению факторов, представляющих наибольший риск для успешного завершения проекта, и сведению их до минимума. Теперь вернемся непосредственно к понятию архитектура. Под архитектурой программной системы понимается совокупность решений относительно:
Архитектура программной системы охватывает не только ее структурные и поведенческие аспекты, но и использование, функциональность, производительность, гибкость, возможности повторного применения, полноту, экономические и технологические ограничения и компромиссы, а также эстетические вопросы.
|
отлично
3 