Комплексные или интегрированные бухгалтерские системы
Дальнейшее развитие бизнеса, деловых процессов, происходящих внутри предприятий, потребовало от бухгалтерских ИС расширенных возможностей и перехода от упрощенного учета к универсальному. Поэтому потребовались бухгалтерские системы, работающие в сети.
В этой связи появились комплексные или интегрированные бухгалтерские системы, такие, как “ABACUS”, рассчитанные на бухгалтерию в 50-60 человек. К этому классу относятся программы, объединяющие и поддерживающие ведение всех основных учетных функций и разделов. Интегрированные бухгалтерские ИС в основном ориентированы на средний бизнес и служат для работы на одном компьютере, хотя возможны варианты их использования на нескольких компьютерах, а также в локальной сети. При этом на каждом персональном компьютере отображается, как правило, вся система. Наиболее распространены программные пакеты фирм ПАРУС (“Парус-предприятие” – вариант для крупных и средних предприятий), ИНФОСОФТ (“Интегратор”), “Интеллект Сервис” (“БЭСТ” – для комплексной автоматизации предприятий), “Ланкс” (“Суперменеджер”), “Диц” (“Турбобухгалтер”) и других.
Данный класс бухгалтерских систем относится к системам, которые легко настраиваются на специфику ведения бухгалтерского учета на промышленном предприятии и могут работать как в сети, так и на отбельных рабочих местах учетных работников. Поэтому подобные системы занимают самый большой сектор на рынке финансово-экономического программного обеспечения.
Такие системы предоставляют широчайшие возможности ведения бухгалтерского учета на предприятии; благодаря использованию различных современных информационных технологий они обеспечивают:
· возможность настройки на особенности любой бухгалтерии как для малых предприятий, так и для корпоративных структур. Это достигается, например, за счет ведения плана счетов, изменения и добавления налоговых ставок, проводок, видов начислений и удержаний, размера минимальной заработной платы;
· ведение расширенного аналитического учета за счет добавления к отдельным балансовым счетам аналитических признаков. Глубину аналитического учета можно определить по структуре плана отчетов. Некоторые программы позволяют добавлять к счету объекты аналитического учета до десятого порядка в глубину;
· регистрацию хозяйственных операций несколькими способами. Наиболее часто встречаются два подхода при регистрации хозяйственных операций – “от проводки” и “от первичного документа’. В первом случае, как правило, ведется один или несколько журналов хозяйственных операций, в которых регистрируются проводки. Во втором – ввод данных по любой хозяйственной операции осуществляется на основе заполнения первичных документов (приходных и расходных кассовых ордеров, платежных поручений, авансовых отчетов и других). Далее система автоматически формирует соответствующие проводки;
· несколько вариантов ввода информации, что облегчает и ускоряет процесс регистрации учетной информации:
o вручную с клавиатуры на основе первичного документа;
o путем копирования хозяйственной операции из журнала и ее дальнейшей корректировки;
o на основе типовых операций посредством использования справочника типовых операций;
o путем заполнения бланков первичных документов, выбранных из справочника. Одновременно при вводе информации создается первичный документ и формируются проводки в журнале хозяйственных операций;
· формирование любых отчетных первичных документов и оперативных сводок, а также форм финансовой отчетности в любой момент времени и за люобой период (от одного дня до года). Как правило, в любой системе предлагается набор стандартных форм (оборотно-сальдовая ведомость, журналы-ордера, главная книга и другие), а также ряд отчетных форм, которые бухгалтер может настраивать в соответствии с постоянно меняющимся законодательством (баланс предприятия, отчет о финансовых результатах, расчет НДС и другие). Использование встроенного текстового редактора или генератора отчетов позволяет создавать и корректировать любые бланки бухгалтерской отчетности, а также бланки, специфические для данного предприятия;
· формирование графических иллюстраций результатов финансово-хозяйственной деятельности с помощью графического редактора;
· сбор информации обо всех этапах работы для контроля за деятельносттью работников бухгалтерии. Для этого автоматически ведется журнал, в который заносятся данные о действиях пользователей системы;
· формирование оперативной информации о состоянии дел на предприятии, возможность консолидированного управления и получение консолидированных финансовых отчетов на основе использования сетевых технологий;
· надежность и сохранность информации путем определения для каждого пользователя уровня доступа (администратор, главный бухгалтер, бухгалтер, работник склада и др.); путем закрытия от изменений всех данных за определенный период; с помощью периодического резервного сохранения данных и последующего их восстановления, а также проверки целостности данных и их корректировки после возможных сбоев в системе;
· введение многовалютного бухгалтерского учета;
· ведение учета на предприятиях розничной торговли, обеспечение связи системы с электронными кассовыми аппаратами.
Западные системы.
Среди финансово-экономического программного обеспечения на российском рынке особое место занимают западные системы. Они демонстрируют комплексный подход к управлению финансами и бизнесом. Наиболее широко зарекомендовали себя программные комплексы для крупного бизнеса, такие, как “Scala”, “Sun System”, “Platinum”, “SAP”, “Avalon”, “Triton”.
Западные программные продукты относятся к классу комплексных бухгалтерских систем, в которых учет ведется в режиме реального времени. Они построены по модульному принципу; основными модулями такой системы являются:
· Главная книга и Расширенный генератор отчетов;
· Банковская книга;
· Заказчики;
· Поставщики;
· Оформление заказов;
· Расчеты с заказчиками;
· Склад;
· Расчеты с поставщиками.
Основной причиной распространения западных программ на российском рынке явилась необходимость ведения бухгалтерского учета в международных стандартах. Российские пакеты изначально создавались для российского рынка и не были предназначены для расширения своих функций до ведения западного варианта учета. Западные пакеты с момента выхода их поставщиков на российский рынок в начале 1990-х гг. сумели успешно перестроиться для удовлетворения требований российского учета. В своем большинстве они способны поддерживать два варианта учета – западный и российский, однако очень громоздки и сложны для изучения, а также очень дорогостоящи. Российские производители подобных систем мало известны широкой общественности, наиболее известным сейчас является отечественный комплекс “Галактика” (фирма “Галактика”).
11. Организация проектирования и разработки ПО [J]
| № | Билет № | Формулировка ответа | Преподаватель | Кто делает ответ | Состояние |
| 1.3., 22.3., 35.2. | Организация проектирования и разработки программного обеспечения. Стандартные элементы методологии разработки ПО. Жизненный цикл ПО, стандартные роли, компетенции, артефакты в методологиях разработки ПО. | Алексеев Пётр Сергеевич | Мила Сергеева | черновой вариант Милы |
Черновой вариант Милы
Роли:
Артефакты:
Постановка задачи – спецификация – проектирование – модель – реализация – код – тестирование/отладка – готовое приложение – использование – замечания – анализ результатов.
Процессы:
Процесс разработки состоит из множества подпроцессов, или дисциплин, некоторые из которых показаны ниже. В модели водопада они идут одна за другой, в других процессах их порядок или состав изменяется.
· Парадигма программирования
· Бизнес-моделирование
· Анализ требований
· Планирование
· Разработка архитектуры
· Кодирование
· Тестирование и отладка
· Документирование
· Внедрение
· Сопровождение
Разработка программного обеспечения может быть разделена на несколько разделов. Это:
· Требования к программному обеспечению: извлечение, анализ, спецификация и ратификация требований для программного обеспечения.
· Проектирование программного обеспечения: проектирование программного обеспечения средствами Автоматизированной Разработки Программного Обеспечения (CASE) и стандарты формата описаний, такие как Унифицированный Язык Моделирования (UML).
· Инженерия программного обеспечения: создание программного обеспечения с помощью языков программирования.
· Тестирование программного обеспечения: поиск и исправление ошибок в программе.
· Обслуживание программного обеспечения: программные системы часто имеют проблемы совместимости и переносимости, а также нуждаются в последующих модификациях в течение долгого времени после того, как закончена их первая версия. Подобласть имеет дело с этими проблемами.
· Управление конфигурацией программного обеспечения: так как системы программного обеспечения очень сложны и модифицируются в процессе эксплуатации, их конфигурации должны управляться стандартизированным и структурированным методом.
· Управление разработкой программного обеспечения: управление системами программного обеспечения имеет заимствования из управления проектами, но есть нюансы, не встречающиеся в других дисциплинах управления.
· Процесс разработки программного обеспечения: процесс построения программного обеспечения горячо обсуждается среди практиков, основными парадигмами считаются agile или waterfall.
· Инструменты разработки программного обеспечения, см. CASE: методика оценки сложности системы, выбора средств разработки и применения программной системы.
· Качество программного обеспечения: методика оценки критериев качества программного продукта и требований к надёжности.
· Локализация программного обеспечения, ветвь языковой промышленности.
Участники процесса разработки ПО
· Пользователь
· Заказчик
· Исполнитель
Модели ЖЦ ПО:
· Каскадная модель
Каскадная разработка или модель водопада (англ. waterfall model) — модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки.
Данная модель также носит название «водопад». Классическими представителями реализации данной методологии являются стандарты ISO и CMM.
Модель предполагает следующие свойства взаимодействия этапов:
· модель состоит из последовательно расположенных этапов;
· каждый этап полностью заканчивается до того, как начнется следующий;
· этапы не перекрываются во времени: следующий этап не начинается до тех пор, пока не завершится предыдущий;
· возврат к предыдущим этапам не предусмотрен либо всячески ограничен;
· исправление ошибок происходит лишь на стадии тестирования;
· результат появляется только в конце разработки.
Критерием появления результата является отсутствие ошибок и точное соответствие продукта первоначальной спецификации.
Недостатками такого подхода являются накопление возможных на ранних этапах ошибок к моменту окончания проекта и, как следствие, возрастание риска провала проекта, увеличение стоимости проекта.
· Поэтапная модель с промежуточным контролем
Итеративная разработка (англ. iteration — повторение) — выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы. Проект при этом подходе в каждой фазе развития проходит повторяющийся цикл: Планирование — Реализация — Проверка — Оценка (англ. plan-do-check-act cycle).
В ходе разработки всегда выявляются дополнительные требования или изменяются выявленные ранее. Также появляются новые ограничения, связанные с принятыми техническими решениями. В наиболее полной мере их удается учесть именно в итерационной разработке, поскольку именно при таком подходе руководство проекта в полной мере готово к изменениям. Итеративный подход сейчас является наиболее распространенным из-за своих очевидных преимуществ и различные его вариации используеются в компании ДПГруп.
Данная модель еще известна как итерационная модель или «водоворот».
Модель характеризуется следующими свойствами взаимодействия этапов:
· модель состоит из последовательно расположенных этапов (точно так же, как и «водопад»);
· каждый этап имеет обратную связь с предыдущими этапами;
· исправление ошибок происходит на каждом из этапов, сразу при выявлении проблемы — это промежуточный контроль;
· этапы перекрываются во времени по причине наличия обратной связи: следующий этап не начинается, пока не завершится предыдущий; при первом проходе по модели вниз, как только обнаружена ошибка, осуществляется возврат снизу вверх к предыдущим этапам, которые повлекли ошибку; таким образом, фактически этапы оказываются растянутыми во времени;
· результат появляется только в конце разработки, как и в модели «водопад».
Критерием появления результата является приемлемое качество продукта, то есть такое состояние продукта, когда наиболее критические для клиента ошибки устранены, а с наличием непринципиальных для жизнедеятельности системы ошибок клиент согласилcя — данные ошибки описаны в документации и фактически переведены таким образом в разряд особенностей системы.
Итеративные методы разработки программного обеспечения, которые применяет ДПГруп:
· Rational Unified Process (RUP) — методология разработки программного обеспечения, созданная компанией Rational Software.
В основе RUP лежат следующие основные принципы:
o Ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков.
o Концентрация на выполнении требований заказчиков к исполняемой программе (анализ и построение модели прецедентов).
o Ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки.
o Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта.
o Постоянное обеспечение качества на всех этапах разработки проекта (продукта).
o Работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам.
· Гибкая методология разработки (англ. Agile software development).
Большинство гибких методологий нацелены на минимизацию рисков, путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся одну-две недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре, и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, кодирование, тестирование и документирование. Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается что гибкий программный проект готов к выпуску в конце каждой итерации. По окончании каждой итерации, команда выполняет переоценку приоритетов разработки.
Agile-методы делают упор на непосредственное общение лицом к лицу. Большинство agile-команд расположены в одном офисе иногда называемом bullpen. Как минимум она включает и «заказчиков» (заказчики которые определяют продукт, также это могут быть менеджеры продукта, бизнес-аналитики или клиенты). Офис может также включать тестировщиков, дизайнеров интерфейса, технических писателей и менеджеров. Одной из наиболее известных и передовых гибких методик является методололгия SCRUM, которая и применяется нашей компанией.
Преимущества итеративного подхода:
· снижение воздействия серьезных рисков на ранних стадиях проекта, что ведет к минимизации затрат на их устранение;
· организация эффективной обратной связи проектной команды с потребителем (а также заказчиками, стейкхолдерами) и создание продукта, реально отвечающего его потребностям;
· акцент усилий на наиболее важные и критичные направления проекта;
· непрерывное итеративное тестирование, позволяющее оценить успешность всего проекта в целом;
· раннее обнаружение конфликтов между требованиями, моделями и реализацией проекта;
· более равномерная загрузка участников проекта;
· эффективное использование накопленного опыта;
· реальная оценка текущего состояния проекта и, как следствие, большая уверенность заказчиков и непосредственных участников в его успешном завершении.
· Спиральная модель
т.н. модель Боэма (Барри Боэм). Рассматривается зависимость эффективности проекта от его стоимости с течением времени. На каждом витке спирали выполняется создание очередной версии продукта, уточняются требования проекта, определяется его качество и планируются работы следующего витка.
Коммерческими представителями данной методологии являются RUP (Rational Unified Process), MSF (Microsoft Consulting Services), и об этом будет рассказано в следующих частях данной публикации.
Результат появляется фактически на каждом витке спирали. Этот результат, который является промежуточным, анализируется, а затем выявленные недостатки продукта становятся поводом для инициирования следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в итоге выбирается обоснованный вариант, который доводится до реализации. Спираль завершается тогда, когда клиент и разработчик приходят к согласию относительно результата.
Модель предполагает также свойства взаимодействия этапов:
• модель состоит из последовательно расположенных этапов (как и «водопад») в пределах одного витка спирали;
• внутри витка спирали этапы не имеют обратной связи; анализ результата осуществляется в конце витка и инициирует новый виток спирали;
• исправление ошибок происходит на этапе тестирования на каждом из витков спирали; фактически часть ошибок исправляется в пределах одного витка посредством связи этапов кодирования и тестирования; ошибки, которые не могут быть исправлены и требуют более глубоких структурных изменений, инициируют новый виток спирали;
• этапы могут перекрываться во времени в пределах одного витка спирали;
• результат появляется в конце каждого витка спирали и подвергается подробному анализу, анализируются новые требования заказчика и инициируется новый виток спирали;
• при переходе от витка к витку происходит накопление и повторное использование программных средств, моделей и прототипов;
• процесс ориентирован на развитие и модификацию системы в процессе ее проектирования, на анализ рисков и издержек в процессе проектирования.
Отметим, что основная особенность данной методологии состоит в концентрации сложности на начальных этапах жизненного цикла ПО (анализ, проектирование); при этом сложность и трудоемкость последующих этапов в пределах одного витка спирали относительно невысокие. По этой методологии предлагается способ снижения затрат в целом при разработке ПО за счет предотвращения потенциальных ошибок на этапах анализа и проектирования. Этап определения стратегии присутствует на первом витке спирали либо «склеен» с этапом анализа первого витка спирали.
Каскадная модель
Спиральная модель
Поэтапная модель с промежуточным контролем
Жизненный цикл проекта (англ. Project Life Cycle) — последовательность фаз проекта, задаваемая исходя из потребностей управления проектом.
В рамках методологии Института управления проектами (англ. Project Management Institute) жизненный цикл проекта имеет 5 фаз:
· Инициация (англ. Initiating);
· Планирование (англ. Planning);
· Выполнение (англ. Executing);
· Контроль и мониторинг (англ. Controlling and Monitoring);
· Завершение (англ. Closing).
Жизненный цикл программы – это весь период ее разработки и
эксплуатации, начиная с момента возникновения замысла и заканчивая
прекращением всех видов ее использования.
Жизненный цикл программы тесно связан с жизненным циклом
проекта по разработке, особенно если в проект включают такие фазы,
как сопровождение и модификация программы во время эксплуатации.
Модель жизненного цикла удобно характеризовать в двух
измерениях – вертикальном (представляющем процессы) и
горизонтальном (представляющем стадии).
Процесс – совокупность взаимосвязанных действий,
преобразующих некоторые входные данные в выходные.
Процессы состоят из набора действий, а каждое действие из
набора задач. Вертикальное измерение отражает статические аспекты
процессов и оперирует такими понятиями, как рабочие процессы,
действия, задачи, результаты деятельности и исполнители.
Стадия — часть действий по созданию программного
обеспечения, ограниченная некоторыми временными рамками и
заканчивающаяся выпуском конкретного продукта, определяемого
заданными для данной стадии требованиями. Конкретный продукт
называется артефактом стадии, момент его выпуска называется вехой
или контрольной точкой.
Стадия — часть процесса работы над проектом. Каждая стадия
характеризуется вехой, достижение которой знаменует завершение
стадии.
Стадии состоят из этапов, которые обычно имеют итерационный
характер. Иногда стадии объединяют в более крупные временные рамки,
называемые фазами.
Следует подчеркнуть, что деление процесса на этапы, стадии и
фазы носит объективный характер, поскольку определяется
объективными событиями — вехами — выпуском тех или иных
артефактов.
Веха — одномоментное идентифицируемое событие,
сопровождающееся появлением и фиксацией некоторого отчуждаемого
материала (документа, программы, протокола), который называется
артефактом вехи.
Итак, горизонтальное измерение представляет время, отражает
динамические аспекты процессов и оперирует такими понятиями, как
фазы, стадии, этапы, итерации и контрольные точки.
Модель (или технологический подход) определяется спецификой
комбинации стадий и процессов, ориентированной на разные классы
программного обеспечения и на особенности коллектива разработчиков.
Классификация технологических подходов:
Выделим основные группы технологических подходов и укажем
область применения для каждой из них.
• Подходы со слабой формализацией. Эти подходы не
используют явных технологий и их можно применять только
для очень маленьких проектов, как правило, завершающихся
созданием демонстрационного прототипа. К подходам со
слабой формализацией относятся так называемые ранние
технологические подходы, например подход «кодирование и
исправление».
• Строгие (классические, жесткие, предсказуемые)
подходы. Данную группу подходов рекомендуется
применять для средних, крупномасштабных и гигантских
проектов с фиксированным объемом работ. Одно из
основных требований к таким проектам — предсказуемость.
В эту группу входят подходы, перечисленные ниже.
· Каскадные технологические подходы.
§ Классический каскадный подход.
§ Каскадно-возвратный подход.
§ Каскадно-итерационный подход.
§ Каскадный подход с перекрывающимися
§ процессами.
§ Каскадный подход с подпроцессами.
§ Спиральная модель.
· Каркасные подходы.
§ Рациональный унифицированный процесс.
· Генетические подходы.
§ Синтезирующее программирование.
§ Сборочное (расширяемое) программирование.
§ Конкретизирующее программирование.
· Подходы на основе формальных преобразований.
§ Технология стерильного цеха.
§ Формальные генетические подходы.
· Гибкие (адаптивные, легкие) подходы. Подходы этой
группы рекомендуется применять для небольших или
средних проектов в случае неясных или изменяющихся
требований к системе. Команда разработчиков должна быть
ответственной и квалифицированной, а заказчики должны
быть согласны принимать участие в разработке. В данную
группу входят подходы, перечисленные ниже.
· Ранние технологические подходы быстрой разработки.
§ Эволюционное прототипирование.
§ Итеративная разработка.
§ Постадийная разработка.
· Адаптивные подходы.
§ Экстремальное программирование.
§ Адаптивная разработка.
· Подходы исследовательского программирования.
§ Компьютерный дарвинизм.
Классификация технологических процессов
Мы будем рассматривать два набора (множества) технологических
процессов. Первый набор — классический, включающий основные
процессы, сложившиеся исторически в результате практического опыта
разработки программного обеспечения. Второй набор — стандартный,
т. е. основанный на стандарте ISO 12207:1995. Процессы классического
набора фактически являются подмножеством стандартного, выступая
там как процессы или действия процессов.
В классическом наборе выделим девять технологических
процессов.
• Возникновение и исследование идеи.
• Управление.
• Анализ требований.
• Проектирование.
• Программирование.
• Тестирование и отладка.
• Ввод в действие.
• Эксплуатация и сопровождение.
• Завершение эксплуатации.
Процессы жизненного цикла, определяемые международным
стандартом
ISO 12207 [ISO/IEC 12207:1995], делятся на три группы.
• Основные процессы.
o Приобретение.
o Поставка.
o Разработка.
o Эксплуатация.
o Сопровождение.
• Вспомогательные процессы.
o Документирование.
o Управление конфигурацией.
o Обеспечение качества.
o Верификация.
o Аттестация.
o Совместная оценка.
o Аудит.
o Разрешение проблем.
• Организационные процессы.
o Управление.
o Создание инфраструктуры.
o Усовершенствование.
o Обучение.
Стадии разработки согласно ГОСТ 19.102-77
Примечания:
1. Допускается исключать вторую стадию разработки, а в
технически обоснованных случаях — вторую и третью стадии.
Необходимость проведения этих стадий указывается в техническом
задании.
2. Допускается объединять, исключать этапы работ и (или) их
содержание, а также вводить другие этапы работ по согласованию с
заказчиком.
Международные стандарты:
Ø ISO/IEC 15504
Оценка процессов разработки ПО. Данный стандарт предназначен для оценки процессов, так или иначе связанных с разработкой программного обеспечения (ПО).
Стандарт содержит рекомендации по оценке (rating) процессов и представлению результатов оценки, то есть позволяет «измерять» их качество, для чего используются, в том числе, различные атрибуты процессов. На основании оценки вырабатываются рекомендации по улучшению.
Ø ISO/IEC 12207
Процессы жизненного цикла разработки ПО. Стандарт описывает структуру жизненного цикла программного обеспечения, заказа, поставки, разработки, работы и поддержки ПО. Дополнительно описывает структуру управления, контроля и совершенствования действий, участвующих в этом процессе.
Ø ISO/IEC 14598-4:1999
Информационная технология. Разработка программных средств. Процессы для заказчика.
Ø MIL-STD-498:1994
Разработка и документирование программного обеспечения.
Стадии разработки ПО можно описать с помощью ГОСТа 19.102-77, который устанавливает стадии разработки программ и программной документации для вычислительных машин, комплексов и систем независимо от их назначения и области применения
§ ГОСТ 34.601-90 – распространяется на автоматизированные системы и устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится описание содержания работ на каждом этапе. Стадии и этапы работы, закрепленные в стандарте, в большей степени соответствуют каскадной модели жизненного цикла.
§ ISO/IEC 12207:1995 – стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не содержит описания фаз, стадий и этапов.
§ Custom Development Method (методика Oracle) по разработке прикладных информационных систем – технологический материал, детализированный до уровня заготовок проектных документов, рассчитанных на использование в проектах с применением Oracle. Применяется CDM для классической модели ЖЦ (предусмотрены все работы/задачи и этапы), а также для технологий «быстрой разработки» (Fast Track) или «облегченного подхода», рекомендуемых в случае малых проектов.
§ Rational Unified Process (RUP) предлагает итеративную модель разработки, включающую четыре фазы: начало, исследование, построение и внедрение. Каждая фаза может быть разбита на этапы (итерации), в результате которых выпускается версия для внутреннего или внешнего использования. Прохождение через четыре основные фазы называется циклом разработки, каждый цикл завершается генерацией версии системы. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова минует те же фазы. Суть работы в рамках RUP – это создание и сопровождение моделей на базе UML.
§ Microsoft Solution Framework (MSF) сходна с RUP, так же включает четыре фазы: анализ, проектирование, разработка, стабилизация, является итерационной, предполагает использование объектно-ориентированного моделирования. MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес-приложений.
§ Extreme Programming (XP). Экстремальное программирование (самая новая среди рассматриваемых методологий) сформировалось в 1996 году. В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС, а разработка ведется с использованием последовательно дорабатываемых прототипов.
В соответствии с базовым международным стандартом ISO/IEC 12207 все процессы ЖЦ ПО делятся на три группы:
1. Основные процессы:
§ приобретение;
§ поставка;
§ разработка;
§ эксплуатация;
§ сопровождение.
2. Вспомогательные процессы:
§ документирование;
§ управление конфигурацией;
§ обеспечение качества;
§ разрешение проблем;
§ аудит;
§ аттестация;
§ совместная оценка;
§ верификация.
3. Организационные процессы:
§ создание инфраструктуры;
§ управление;
§ обучение;
§ усовершенствование.
12. Организация проектирования и разработки ПО [J]
| № | Билет № | Формулировка ответа | Преподаватель | Кто делает ответ | Состояние |
| 2.3., 23.3., 36.2. | Организация проектирования и разработки программного обеспечения. Примеры методологий разработки ПО. Водопадная модель, спиральная модель, Scrum, RUP. Основные идеи различных методологий разработки ПО, граничные условия, избранные роли и практики. | Алексеев Пётр Сергеевич | Дина Чубарева | Готовый ответ Дины |
Готовый ответ Дины
На протяжении нескольких десятилетий стоит задача поиска повторяемого, предсказуемого процесса или методологии, которая бы улучшила продуктивность, качество и надежность разработки. Одни пытались систематизировать и формализовать этот, по-видимому, непредсказуемый процесс. Другие применяли к нему методы управления проектами и методы программной инженерии. Третьи считали, что без постоянного контроля со стороны заказчика разработка ПО выходит из-под контроля, съедая лишнее время и средства.
Модели процесса разработки ПО (абстрактное представление процесса):
· Модель водопада (Каскадная модель)
- структурное проектирование
- тестирование программ
- сертификация программ
- Итеративный процесс
- Гибкие методологии разработки
- Экстремальное программирование
· Формальные методы
- логическое программирование
- доказательное программирование
· На основе ранее созданного ПО
- Интеграция
Каскадная модель
Жизненный Цикл:
- Анализ и формирование требований
- проектирование системы и ПО
- кодирование и тестирование модулей
- сборка и тестирование
- эксплуатация и сопровождение
Фазы:
1. Определение требований
2. Проектирование
3. Конструирование (также «реализация» либо «кодирование»)
4. Интеграция
5. Тестирование и отладка (также «верификация»)
6. Инсталляция
7. Поддержка
Результат каждого этама – документ
Негибкое разбиение на этапы
Ошибке вначале приводят к огромным расходам 
Итеративная
Итеративный подход (англ. iteration — повторение) — выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы. Проект при этом подходе в каждой фазе развития проходит повторяющийся цикл: Планирование — Реализация — Проверка — Оценка (англ. plan-do-check-act cycle).
Преимущества итеративного подхода:
§ снижение воздействия серьезных рисков на ранних стадиях проекта, что ведет к минимизации затрат на их устранение;
§ организация эффективной обратной связи проектной команды с потребителем (а также заказчиками, стейкхолдерами) и создание продукта, реально отвечающего его потребностям;
§ акцент усилий на наиболее важные и критичные направления проекта;
§ непрерывное итеративное тестирование, позволяющее оценить успешность всего проекта в целом;
§ раннее обнаружение конфликтов между требованиями, моделями и реализацией проекта;
§ более равномерная загрузка участников проекта;
§ эффективное использование накопленного опыта;
§ реальная оценка текущего состояния проекта и, как следствие, большая уверенность заказчиков и непосредственных участников в его успешном завершении.
Примеры итеративных методологий –
· Пошаговая разработка
· Спиральная одель
· RUP rational unified process
RUP
В основе RUP лежат следующие принципы:
§ Ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков.
§ Концентрация на выполнении требований заказчиков к исполняемой программе (анализ и построение модели прецедентов (вариантов использования)).
§ Ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки.
§ Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта.
§ Постоянное обеспечение качества на всех этапах разработки проекта (продукта).
§ Работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам.
Фазы :
· начало,
· уточнение,
· построение (Фаза Построение завершается первым внешним релизом системы и вехой начальной функциональной готовности),
· внедрение ( создается финальная версия продукта и передается от разработчика к заказчику).
Спиральная модель,
предложенная Барри Боэмом в 1988 году, стала существенным прорывом в понимании природы разработки ПО. Она представляет собой процесс разработки программного обеспечения, сочетающий в себе как проектирование, так и постадийное прототипирование с целью сочетания преимуществ восходящей и нисходящей концепции, делающая упор на начальные этапы жизненного цикла: анализ и проектирование. Отличительной особенностью этой модели является специальное внимание рискам, влияющим на организацию жизненного цикла. Боэм формулирует десять наиболее распространённых (по приоритетам) рисков:
1. Дефицит специалистов.
2. Нереалистичные сроки и бюджет.
3. Реализация несоответствующей функциональности.
4. Разработка неправильного пользовательского интерфейса.
5. «Золотая сервировка», перфекционизм, ненужная оптимизация и оттачивание деталей.
6. Непрекращающийся поток изменений.
7. Нехватка информации о внешних компонентах, определяющих окружение системы или вовлечённых в интеграцию.
8. Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
9. Недостаточная производительность получаемой системы.
10. «Разрыв» в квалификации специалистов разных областей знаний.
Каждый виток спирали соответствует созданию фрагмента или версии программного обеспечения, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации. Каждый виток разбит на 4 сектора:
§ оценка и разрешение рисков,
§ определение целей,
§ разработка и тестирование,
§ планирование.
На каждом витке спирали могут применяться разные модели процесса разработки ПО. В конечном итоге на выходе получается готовый продукт. Модель сочетает в себе возможности модели прототипирования и водопадной модели. Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная задача — как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований. Основная проблема спирального цикла — определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.
Scrum
— методология управления развитием информационных систем для гибкой разработки программного обеспечения. Scrum чётко делает акцент на качественном контроле процесса разработки.
это набор принципов, на которых строится процесс разработки, позволяющий в жёстко фиксированные небольшие промежутки времени (спринты от 2 до 4 недель) предоставлять конечному пользователю работающее ПО с новыми возможностями, для которых определён наибольший приоритет.
По методике Scrum в производственном процессе есть определенные роли, разбитые на 2 группы «свиней» и «цыплят». Эти названия были использованы из-за шутки. .. Так что свиньи создают продукт, тогда как цыплята заинтересованы, но не настолько — ведь им всё равно, будет ли проект удачным или нет, на них это мало отразится. Требования, пожелания, идеи и влияние цыплят принимаются во внимание, но им не разрешают непосредственно включаться в ход Scrum-проекта.
Артефакты
Product backlog (бэклог)— это документ, содержащий список требований к функциональности, которые упорядочены по степени важности. Product backlog представляет собой список того, что должно быть реализовано. Элементы этого списка называются «историями» (user story) или элементами backlog’a (backlog items). Product backlog открыт для редактирования для всех участников Scrum-процесса.
Sprint Backlog — содержит функциональность, выбранную Product Owner из Product Backlog. Все функции разбиты по задачам, каждая из которых оценивается командой. Каждый день команда оценивает объем работы, который нужно проделать для завершения задач.
Burndown chart — показывает, сколько уже исполнено и сколько ещё остаётся сделать.
Planning Meeting - Планирование спринтапроисходит в начале итерации
Daily Scrum
Demo Meeting – демонстрация
Retrospective Meeting - Ретроспектива
13. Организация проектирования и разработки ПО [J]
| № | Билет № | Формулировка ответа | Преподаватель | Кто делает ответ | Состояние |
| 3.3., 24.3., 37.2. | Организация проектирования и разработки программного обеспечения. Принципы, практики, граничные условия методологии экстремального программирования (XP). | Алексеев Пётр Сергеевич | Аня Курманова | Готовый ответ Тони |
Готовый ответ Тони
Экстремальное программирование (XP) – это упрощенная методология организации разработки программ для небольших и средних по размеру команд разработчиков, занимающихся созданием программного продукта в условиях неясных или быстро меняющихся требований.
Цели XP
Основными целями XP являются повышение доверия заказчика к программному продукту путем предоставления реальных доказательств успешности развития процесса разработки и резкое сокращение сроков разработки продукта. При этом XP сосредоточено на минимизации ошибок на ранних стадиях разработки. Это позволяет добиться максимальной скорости выпуска готового продукта и даёт возможность говорить о прогнозируемости работы. Практически все приемы XP направлены на повышение качества программного продукта.
Принципы XP
Основными принципами являются:
Итеративность. Разработка ведется короткими итерациями при наличии активной взаимосвязи с заказчиком. Итерации как таковые предлагается делать короткими, рекомендуемая длительность – 2-3 недели и не более 1 месяца. За одну итерацию группа программистов обязана реализовать несколько свойств системы, каждое из которых описывается в пользовательской истории. Пользовательские истории (ПИ) в данном случае являются начальной информацией, на основании которой создается модуль. Они отличаются от вариантов использования (ВИ). Описание ПИ короткое – 1-2 абзаца, тогда как ВИ обычно описываются достаточно подробно, с основным и альтернативными потоками, и дополняются моделью. ПИ пишутся самими пользователями, которые в XP являются частью команды, в отличие от ВИ, которые описывает системный аналитик. Отсутствие формализации описания входных данных проекта в XP стремятся компенсировать за счет активного включения в процесс разработки заказчика как полноправного члена команды.
Простота решений. Принимается первое простейшее рабочее решение. Экстремальность метода связана с высокой степенью риска решения, обусловленного поверхностностью анализа и жестким временным графиком. Реализуется минимальный набор главных функций системы на первой и каждой последующей итерации; функциональность расширяется на каждой итерации.
Интенсивная разработка малыми группами (не больше 10 человек) и парное программирование (когда два программиста вместе создают код на одном общем рабочем месте), активное общение в группе и между группами. Все это нацелено на как можно более раннее обнаружение проблем (как ошибок, так и срыва сроков). Парное программирование направлено на решение задачи стабилизации проекта. При применении XP методологии высок риск потери кода по причине ухода программиста, не выдержавшего интенсивного графика работы. В этом случае второй программист из пары играет роль «наследника» кода. Немаловажно и то, как именно распределены группы в рабочем пространстве – в XP используется открытое рабочее пространство, которое предполагает быстрый и свободный доступ всех ко всем.
Обратная связь с заказчиком, представитель которого фактически вовлечен в процесс разработки.
Достаточная степень смелости и желание идти на риск.
Приемы XP (практики)
Обычно XP характеризуют набором из 12 правил (практик), которые необходимо выполнять для достижения хорошего результата. Ни одна из практик не является принципиально новой, но в XP они собраны вместе.
Планирование процесса. Вся команда разработчиков собирается вместе, принимается коллективное решение о том, какие свойства системы будут реализованы в ближайшей итерации. Трудоемкость реализации каждого свойства определяется самими программистами.
Тесное взаимодействие с заказчиком. Представитель заказчика должен быть членом XP-команды. Он пишет ПИ, выбирает истории, которые будут реализованы в конкретной итерации, и отвечает на вопросы, касающиеся бизнеса. Представитель заказчика должен быть экспертом в автоматизируемой предметной области. Необходимо наличие постоянное обратной связи с представителем заказчика.
Общесистемные правила именования. Хорошие системные правила именования предполагаютпростоту именования классов и переменных. Команда разработчиков должна иметь единые правила именования.
Простая архитектура. Любое свойство системы должно быть реализовано как можно проще. Программисты в XP-команде работают под девизом: «Ничего лишнего!». Принимается первое простейшее работающее решение, реализуется необходимый уровень функциональности на данный момент. Тем самым экономится время программиста.
Рефакторинг. Это оптимизация существующего кода с целью его упрощения, Такая работа должна вестись постоянно. Сохраняя код прозрачным и определяя его элементы всего один раз, программисты сокращают число ошибок, которые впоследствии придется устранять. При реализации каждого нового свойства системы программист должен подумать над тем, можно ли упростить существующий код и как это поможет реализовать новое свойство. Кроме того, нельзя совмещать рефакторинг с дизайном: если создается новый код, рефакторинг следует отложить.
Парное программирование. Все программисты должны работать в парах: один пишет код, другой смотрит. Таким образом, необходимо размещать группу программистов в одном месте. XP наиболее успешно работает в нераспределенных коллективах программистов и пользователей.
40-часовая рабочая неделя. Программист не должен работать более 8 часов в день. Необходимость сверхурочной работы – это четкий индикатор проблемы на данном конкретном направлении разработки. Поиск причин сверхурочной работы и их скорейшее устранение – одно из основных правил.
Коллективное владение кодом. Каждый программист в коллективе должен иметь доступ к коду любой части системы и право вносить изменения в любой код. Обязательное правило: если программист внес изменения и система после этого работает некорректно, то именно этот программист должен исправить ошибки.
Единые стандарты кодирования. Стандарты кодирования нужны для обеспечения других практик: коллективного владения кодом, парного программирования и рефакторинга. Без единого стандарта выполнять эти практики как минимум сложнее, а в реальности вообще невозможно: группа будет работать в режиме постоянной нехватки времени. Команда работает над проектом продолжительное время. Люди приходят и уходят. Никто не кодирует в одиночку и код принадлежит всем. Всегда будут моменты, когда необходимо будет понять и скорректировать чужой код. Разработчики будут удалять дублирующий код, анализировать и улучшать чужие классы и т. п. Со временем нельзя будет сказать, кто автор конкретного класса. Следовательно, все должны подчиняться общим стандартам кодирования – форматирование кода, именование классов, переменных, констант, стиль комментариев. Вышесказанное означает, что все члены команды должны договориться об общих стандартах кодирования. Неважно каких, но все обязаны им подчиняются.
Небольшие релизы. Минимальная итерация – один день, максимальная – месяц; чем чаще осуществляются релизы, тем больше недостатков системы будет выявлено. Первые релизы помогают выявить недостатки на самых ранних стадиях, далее функциональность системы расширяется на основании ПИ. Поскольку пользователь включается в процесс разработки начиная с первого релиза, то он оценивает систему и выдает пользовательскую историю и замечания. На основании этого определяется следующая итерация, то есть, каким будет новый релиз. В XP все направлено на обеспечение непрерывной обратной связи с пользователями.
Непрерывная интеграция. Интеграция новых частей системы должна происходить как можно чаще, как минимум раз в несколько часов. Основное правило интеграции следующее: интеграцию можно производить, если все тесты проходят успешно. Если тесты не проходят, то программист должен либо внести исправления и тогда интегрировать составные части системы, либо вообще не интегрировать их. Правило это – жесткое и однозначное. Если в созданной части системы имеется хотя бы одна ошибка, то интеграцию производить нельзя. Частая интеграция позволяет быстрее получить готовую систему, вместо того чтобы тратить на сборку неделю.
Тестирование. В отличие от большинства остальных методологий тестирование в XP – одно из важнейших составляющих. Экстремальный подход предполагает, что тесты пишутся до написания кода. Каждый модуль обязан иметь unit test – тест данного модуля. Таким образом, в XP осуществляется регрессионное тестирование, «неухудшение качества» при добавлении функциональности. Большинство ошибок исправляются на стадии кодирования. Тесты пишут сами программисты, любой из них имеет право написать тест для любого модуля. Еще один важный принцип: тест определяет код, а не наоборот (test-driven development), то есть кусок кода кладется в хранилище тогда и только тогда, когда все тесты прошли успешно, в противном случае данное изменение кода отвергается.
Процесс XP является неформальным, но требует высокого уровня самодисциплины. Если это правило не выполняется, то XP мгновенно превращается в хаотичный и неконтролируемый процесс. XP не требует от программистов написания множества отчетов и построения массы моделей. В XP каждый программист считается квалифицированным работником, который профессионально и с большой ответственностью относится к своим обязанностям. Если в команде этого нет, то внедрять XP абсолютно бессмысленно – лучше для начала заняться перестройкой команды. Риск разработки снижается только в команде, которой XP подходит идеально, во всех остальных случаях XP – это процесс разработки с наиболее высокой степенью риска, поскольку другие методы снижения коммерческих рисков, кроме человеческого фактора, в XP просто отсутствуют.
Граничные условия.
- коммуникация большого количества команд (по 6-10 человек)
- живут по схеме times-material, а не по четкому плану
- проверяемые требования
- высокий уровень программ
- четкая поддержка со стороны менеджера
14. Организация проектирования и разработки ПО [J]
| № | Билет № | Формулировка ответа | Преподаватель | Кто делает ответ | Состояние |
| 4.3., 25.3., 38.2. | Организация проектирования и разработки программного обеспечения. Планирование разработки ПО. Принципы планирования, типы планов, основные риски, учет рисков, планирование в различных методологиях (XP, Scrum), коррекция планов, расчет срока разработки. | Алексеев Пётр Сергеевич | Валя Берницына | Готовый ответ Вали |
Готовый ответ Вали
Назначение процесса планирования ПО состоит в том, чтобы определить методы создания такого ПО, которое позволить реализовать системные требования и обеспечить требуемый уровень качества.
Планирование позволяет:
- создавать планы информационных систем, поддерживающие бизнес-направление фирмы;
- ориентировать разработчиков на конечные бизнес-результаты, а не на окончание проектов информационных систем;
- эффективнее использовать ресурсы информационной системы;
- закладывать большую управляемость и лучшую интеграцию существующих и будущих систем;
- быть уверенным в том, что ИС будет соответствовать общему направлению развития организации;
- учесть мнение конечных пользователей;
- создавать условия для правильного реагирования на непредвиденные ситуации.
Принципы планирования
Планирование осуществляется в соответствии с рядом принципов, т.е. правил, каковыми сегодня считаются:
1) Необходимость
2) Непрерывность
3) Эластичность и гибкость
4) Единство и полнота
5) Экономичность
6) Детализация и точность
7) Оптимальность
8) Связь уровней управления
9) Участие
Они определяют содержание и ориентацию плановой работы на всех стадиях проекта и на последующей реализации. Правильное соблюдение принципов планирования создает предпосылки эффективной работы и уменьшает риск отрицательных результатов.
2) НЕПРЕРЫВНОСТЬ – смысл непрерывности планирования заключается в том, что процесс планирования на предприятии должен осуществляться постоянно в рамках жизненных циклах проектов.
3) ГИБКОСТЬ – в понятии гибкости связано с непрерывностью планирования, в придании плану и процессу способность менять свою направленность в связи с возникшей ситуацией и непредсказуемыми обстоятельствами. Для осуществления данного принципа планы следует составлять так, чтобы в них можно было внести коррективу. Поэтому в планы обычно включают резервы.
4) ТОЧНОСТЬ – все планы должны быть составлены с наивысшей точностью, т.е. конкретизированные и детализированы в той степени, в которой позволят внутренние и внешние условия фирмы.
5)УЧАСТИЕ - он говорит о том, что каждый член организации становиться участником плановой деятельности, не зависимо от занимаемой должности и выполняемых функций.
Основные риски, учет рисков: