Группа проекта пс.
Ответ: Для быстрой и эффективной разработки программных систем требуется привлечь достаточно квалифицированную рабочую силу, выбрать правильные инструменты и определить верное направление работы.
Для разработки ПО так или иначе организуется некоторый коллектив. Такую рабочую группу называют группой проекта.
В группу проекта входят следующие специалисты:
1) руководитель проекта – координирует все действия, организует внешнее и внутреннее взаимодействие группы проекта, обеспечивает соблюдение сроков разработки и качество разрабатываемой ПС и его соответствие требованиям заказчика, несет полную ответственность за результат работ по проекту.
2) системный аналитик – анализирует требования к системе, разрабатывает концепцию и логику работы системы, составляет техническое задание или подобные документы, несет ответственность за соответствие предлагаемых решений требованиям заказчика;
3) разработчики – реализуют принятые технические задания, отвечают за качество и сроки разрабатываемого кода, за его соответствие техническому заданию;
4) дизайнер – участвует в разработке концепции системы, разрабатывает ее пользовательский интерфейс и принимает участие в его реализации, несет ответственность за соблюдение фирменного стиля и требований к реализации пользовательского интерфейса;
5) тестер или тестировщик – разрабатывает программу тестирования, осуществляет ее и несет ответственность за полноту тестирования готовых модулей и системы в целом;
6) технический писатель – разрабатывает документацию на проект, несет ответственность за полноту и правильность описания.
Ряд замечаний.
Первое, дизайнер, тестер и технический писатель могут в группу постоянно не входить, а работать над несколькими проектами и привлекаться к работе по мере необходимости.
Второе, в подразделение по разработке ПО, состоящие из нескольких проектных групп, может входить технолог, который разрабатывает, внедряет и поддерживает технологию производства программных продуктов.
Третье, для сложных проектов, связанных например с применением сетевых решений, в группу может подключаться соответствующий специалист.
И, наконец, это только команда разработчиков проекта, но кроме них над проектом могут работать и другие специалисты компании: менеджеры, маркетологи и т.д.
Жизненный цикл программных систем.
Ответ: Процесс разработки программных систем состоит из последовательности шагов, называемых жизненным циклом (ЖЦ) программной системы. Выполнение этих шагов гарантирует систематический, упорядоченный подход к промышленной разработке, использованию, сопровождению и окончанию эксплуатации программных систем.
В литературе описано множество типов жизненных циклов. Среди всего этого разнообразия можно выделить:
I Классический последовательный тип ЖЦ
Старейшим типом ЖЦ является классический жизненный цикл (автор Уинстон Ройс, 1970).
Очень часто классический жизненный цикл называют каскадной или водопадной моделью, подчеркивая, что разработка рассматривается как последовательность этапов-стадий. Каждая следующая стадия может быть начата только после завершения работ на предыдущей стадии.
Рис. 1 Классический жизненный цикл разработки ПО
Основные этапы данного типа ЖЦ:
– системный анализ;
– анализ требований;
– проектирование;
– кодирование;
– тестирование;
– сопровождение.
Подразумевается, что разработка начинается на системном уровне и проходит через анализ, проектирование, кодирование, тестирование и сопровождение. При этом моделируются действия стандартного инженерного цикла.
Системный анализ задает роль каждого элемента в компьютерной системе, взаимодействие элементов друг с другом. Поскольку программное обеспечение является лишь частью большой системы, то анализ начинается с определения требований ко всем системным элементам и назначения подмножества этих требований программному “элементу”. Необходимость системного подхода явно проявляется, когда формируется интерфейс программного обеспечения с другими элементами (аппаратурой, людьми, базами данных). На этом же этапе начинается решение задачи планирования проекта программного обеспечения. В ходе планирования проекта определяются объем проектных работ и их риск, необходимые трудозатраты, формируются рабочие задачи и план-график работ.
Анализ требований относится к программному элементу – программному обеспечению (ПО). Уточняются и детализируются его функции, характеристики и интерфейс. На этом этапе проектировщик должен ответить на вопрос: “Что система должна делать?”.
Все определения документируются в спецификации анализа. Здесь же завершается решение задачи планирования проекта.
Проектирование состоит в создании представлений:
архитектуры ПО;
модульной структуры ПО;
алгоритмической структуры ПО;
структуры данных;
входного и выходного интерфейса (входных и выходных форм данных).
Исходные данные для проектирования содержатся в спецификации анализа, то есть в ходе проектирования выполняется трансляция требований к ПО во множество проектных представлений. При решении задач проектирования основное внимание уделяется качеству будущего программного продукта.
Кодирование состоит в переводе результатов проектирования в текст на языке программирования.
Тестирование – выполнение программы для выявления дефектов в функциях, логике и форме реализации программного продукта.
Сопровождение – это внесение изменений в эксплуатируемое ПО.
Цели изменений:
исправление ошибок;
адаптация к изменениям внешней для ПО среды;
усовершенствование ПО по требованиям заказчика.
Данный тип ЖЦ применим, когда:
– требования к системе четко определены и не меняются со временем;
– имеется достаточно большой опыт реализации подобного рода систем;
– время реализации проекта составляет от нескольких месяцев до года.
Реализация проекта по данному типу ЖЦ легко планируется и контролируется. Однако для этого необходимо заранее иметь все требования к продукту, реально в начале проекта требования заказчика определены лишь частично. Данный тип ЖЦ не приспособлен к изменениям требований к системе. Результаты проекта доступны заказчику только в конце работы. В силу приведенных выше недостатков, на данный момент классический последовательный тип ЖЦ не применяется.
II Эволюционный тип ЖЦ
Функциональные возможности системы в данном случае наращиваются постепенно. В процессе разработки основные стадии ЖЦ (проектирование, реализация, тестирование) проходят несколько раз применительно к очередной добавляемой порции возможностей системы.
Данный тип ЖЦ не требует заранее наличия всех требований к системе и позволяет заказчику активно участвовать в ее разработке, что является безусловным плюсом. Cреди недостатков эволюционного типа можно назвать:
– сложность в управлении и контроле выполнения проекта;
– сложность оценки затрат на разработку;
– риск бесконечного улучшения системы.
Данный тип применим, когда требования к системе плохо определены или будут изменяться, отсутствует достаточный опыт в разработке подобных систем, используются новые технологии и (или) инструментальные средства, в ходе разработки системы необходимо иметь промежуточные версии продукта.