Ещё по теме

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

«Новая концепция ра­сши­ре­ний как метод со­ве­рше­нство­ва­ния программ SAP без их мо­ди­фи­ка­ции»
Дмитрий Воронин:
Отличная статья, но желательно, чтобы в статье использовались примеры с реально существующими расширениями в системе SAP.
«Создание объе­ктно­-о­ри­е­нти­ро­ва­нных ко­рпо­ра­ти­вных при­ло­же­ний и отделение доступа к базе данных от при­кла­дной логики при помощи сервисов объектов ABAP»
Дмитрий Воронин:
Следовало бы добавить в статью пример небольшого приложения, которое можно было бы скопировать и использовать как стартовый плацдарм для дальнейшего изучения.
«Пример. Способы ра­сши­ре­ния по­льзо­ва­те­льско­го инте­рфе­йса Web Dynpro ABAP в SAP Business Suite 7.0»
Дмитрий Воронин:
Отличная статья. Желательно, что-бы статьи дополнительной информации в \"Примечании\" сопровождались ссылками на соответствующие материалы.

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

Бурк Ла-Шелл
2489
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.