Комментарии по теме

«Как улучшить архи­те­кту­ру про­гра­ммы, используя class-based exceptions»
Михаил Дутов:
Илья, добрый день!   Спасибо за статью. Тема действительно интересная, особенно с учетом нововведений последних лет.   Однако пункт с возвратными исключениями стоит дополнить...
«Как улучшить архи­те­кту­ру про­гра­ммы, используя class-based exceptions»
Илья Казначеев:
Здесь и имеется в виду, что модуль (класс, ФМ и т.п.) может использоваться в различных программах - т.е. быть вызван ими; а исключения (этого модуля) также будут обработаны вызывающей программой...
«Как улучшить архи­те­кту­ру про­гра­ммы, используя class-based exceptions»
Александр Грибов:
Илья, добрый день. Вы пишите следующее: "Модульная структура предполагает, что модуль может использоваться в различных программах — это может быть и <....> ФМ для удаленного вызова....

База знаний

Agile-разработки для SAP: освойте методику Scrum!

Бурк Ла-Шелл
4419
2

Разработчики программного обеспечения не всегда используют оптимальную и наиболее эффективную методологию, позволяющую удовлетворить все требования заказчиков или клиентов. Слишком часто разработка программного обеспечения происходит приблизительно так:

  1. Клиенты (будущие пользователи программного обеспечения) запираются в комнате на несколько дней или недель с целью разъяснения группе разработчиков всех требований, предъявляемых к функциям программного обеспечения.
  2. При этом желательно, чтобы клиенты подписали выработанные требования и пообещали, что они не изменят принятых решений. Затем, после утверждения этих требований, предпринимаются соответствующие меры, имеющие своей целью запретить какие-либо изменения требований со стороны клиента (например, создается комиссия по контролю за внесением изменений).
  3. После этого разработчики удаляются на несколько месяцев для создания соответствующего программного обеспечения, в то время как клиенты ожидают получения готового продукта.

Этот принцип является краеугольным камнем методики преподавания, принятой во многих высших школах, на котором по-прежнему базируются процессы разработки в отделах информационных технологий. К сожалению, этот подход не всегда гарантирует создание именно того программного обеспечения, которое удовлетворило бы реальным требованиям клиентов. Вполне вероятно, что к моменту подтверждения клиентом соответствия поставляемого программного обеспечения заданным требованиям изменятся бизнес-задачи компании, либо клиент начнет рассматривать проблему под другим углом зрения. Возможно даже, что сотрудники, в свое время сформулировавшие требования к программному продукту, перейдут в другую компанию, и теперь клиента будут представлять совершенно новые люди. Традиционная модель разработки, известная под названием “водопадной” модели, все чаще подвергается справедливой критике, поскольку не позволяет обеспечить соответствие постоянно изменяющимся требованиям клиентов. Наглядная иллюстрация этой модели представлена на Рис. 1.

Рис. 1 “Водопадная” модель

Вы хотели бы увидеть полную версию статьи?

Если вы являетесь подписчиком журнала SAP Professional Journal, пожалуйста, авторизируйтесь на сайте.

Если вы хотите подписаться на журнала SAP Professional Journal, пожалуйста, обратитесь в редакцию или сделайте заказ на сайте.

Правила получения тестового доступа к статьям SAP Professional Journal

Комментарии:

Сергей Передовой (Рейтинг: 120) 11:40, 22 июля 2010

Статья полезна - понравилась.

Александр Биличенко (Рейтинг: 40) 02:23, 23 июля 2010

интересная статья, но на мой взгляд слишком обременена ежедневными совещаниями. это большие затраты времени

Ирина Пащенко (Рейтинг: 30) 13:01, 26 июля 2010

Методами Agile можно ускорить поставку программного продукта, снизить уровни риска и повысить степень удовлетворенности клиента.

Любое воспроизведение запрещено.
Копирайт © «Издательство ООО «Эксперт РП» Copyright © 2010 Wellesley Information Services. All rights reserved.