Глава II. Проектная часть
2.1 Разработка проекта автоматизации
2.1.1 Этапы Жизненного Цикла проекта автоматизации
Жизненный цикл разработки программного обеспечения (ЖЦ) — это процесс, используемый индустрией программного обеспечения для проектирования, разработки и тестирования высококачественного программного обеспечения. ЖЦ нацелен на производство высококачественного программного обеспечения, которое соответствует ожиданиям клиентов или превосходит их, в кратчайшие сроки завершает работу и оценивает затраты.
- ЖЦ является аббревиатурой жизненного цикла разработки программного обеспечения.
- Это также называется процессом разработки программного обеспечения.
- ЖЦ — это структура, определяющая задачи, выполняемые на каждом этапе процесса разработки программного обеспечения.
- ГОСТ Р ИСО/МЭК 12207-2010 является международным стандартом для процессов жизненного цикла программного обеспечения. Он призван стать стандартом, определяющим все задачи, необходимые для разработки и обслуживания программного обеспечения.
ЖЦ это процесс, которому следует программный проект в рамках организации программного обеспечения. Он состоит из подробного плана, описывающего, как разрабатывать, поддерживать, заменять и изменять или улучшать конкретное программное обеспечение. Жизненный цикл определяет методологию улучшения качества программного обеспечения и общего процесса разработки. [9]
Custom Development Method (методика Oracle) по разработке прикладных информационных систем под заказ — конкретный материал, детализированный до уровня заготовок проектных документов, рассчитанных на использование в проектах с применением Oracle. Степень адаптивности CDM ограничивается тремя моделями ЖЦ: «классическая» (предусмотрены все работы/задачи и этапы), «быстрая разработка» (Fast Track), «облегченный подход», рекомендуемый в случае малых проектов и возможности быстро прототипировать приложения.
RUP был разработан на основе результатов сотни различных проектов по разработке программного обеспечения и идеи некоторых из наиболее влияющих на людей в программной инженерии дисциплины. XP представляет гибкие модели процесса. MSF была разработана на основе большого опыта Microsoft собранном на протяжении десятилетий.
RUP, процесс доступен как продукт, становится объектом частой практики в отрасли за последние годы и был расширен для поддержки элементов XP.
Microsoft продвигает свою Framework систему, включив ее в предстоящем выпуске системы Visual Studio Team и следует примеру Rational, предоставляя не только описание процесса, но и полный продукт для его поддержки.
Rational Unified Process является наиболее часто используемым процессом разработки программного обеспечения в промышленности. Основными преимуществами являются поддержка через Rational Software, которая постоянно совершенствует процесс, поддержка инструмента и плотно соединенную инструмент документацию, а также поддержку Rational для наставничества в реализации процесса. RUP обеспечивает хорошо структурированную основу, разделенную на фазы и рабочие процессы, что обеспечивает легкую навигацию в рамках структуры. Обеспечивает команде разработчиков свободный доступ к базе знаний с инструкциями для использования программных средств. Процесс включает в себя комплексные меры по обеспечению качества. Минимальные стандарты к требованиям проектирования и разработке программного итерационного обеспечения включены, а также тестирование, управление конфигурациями и взаимодействие с клиентом в течение всего процесса.
Framework Microsoft Solution обеспечивает глубокое понимание разработки программного обеспечения практикуемого в Microsoft. MSF представляет собой попытку распространять компанией Microsoft свои знания в области разработки программного обеспечения. MSF является одной из двух дополняющих друг друга структур (кроме Microsoft Operations Framework (MOF)), образуя комплексное решение для крупных софтверных компаний, занятых в средних и крупных проектах. Тем не менее, MSF может применяться самостоятельно. Она не зависит от финансового отдела, что обеспечивает легкую реализацию в средних компаниях. Благодаря своей гибкости, масштабируемости и отсутствию жестких инструкций MSF способен удовлетворить нужды организации или проектной группы любого размера. Оба принципа не только улучшают качество программного обеспечения, но и то, как оно построено. Microsoft предоставляет несколько моделей шаблонов, рекомендованных в MSF. Поскольку MSF не включает в себя огромный набор рекомендуемых средств (которые будут меняться с следующей версией Visual Studio), она может быть легко интегрирована в существующую среду разработки. [10]
Экстремальное программирование представляет собой совершенно новый подход к разработке программного обеспечения. Для небольших проектов, XP предлагает хороший подход для достижения высокого качества программного обеспечения. Тесное вовлечение клиента, основное внимание на тестировании, и подход к снижению ИКР поддержки этой цели. Тем не менее, XP может привести к организационным проблемам при применении в больших проектах. Для большинства проектов, трудно достичь тесную интеграцию клиента в процессе разработки.
Основные критерии для выбора стандарта ЖЦ будут в таблице 2.1.
Итерация – для того, чтобы установить более высокое качество программного обеспечения, процесс разработки ПО должен использовать итеративный и инкрементный подход к развитию. Итерационные циклы включают все виды деятельности в области развития анализа, проектирования, реализации, тестирования и, наконец, развертывания. Контроль качества может применяться более эффективно в течение всего процесса. При использовании итеративного подхода, процесс приобретает большую гибкость при работе с изменяющимися требованиями или областью. Выпуски продукта ранней обратной связи от клиентов и заинтересованных сторон, которая имеет жизненно важное значение для улучшения общего качества программного обеспечения. Однако, итеративная разработка должна быть поддержана управлением рисками и ранним вовлечением конечных пользователей для достижения своего полного потенциала. XP основывается на очень строгом итеративном подходе, требующем ежедневную сборку всех компонентов. Это ограничивает время, необходимое для обнаружения ошибок разработчиками и своевременного решения этих проблем. Конечно, неполные компоненты или отдельные методы исключены из ежедневной сборки. Структура декомпозиции работ должна рассмотреть эти вопросы, чтобы позволить интеграцию мелких компонентов каждый день. Использование этого подхода требует тщательного планирования, но, безусловно, обеспечивает высокое качество программного обеспечения.
Качество как цель – в процессе разработки программного обеспечения необходимо определить качество как основную цель улучшения общего качества программного обеспечения. Целевые показатели качества должны быть определены и задокументированны с участием команды проекта и клиента. Это гарантирует, что цели и качество станут достижимыми и измеримыми. MSF определяет качественные цели проекта в начале и подчеркивает выполнение этих целей в качестве основной части проекта.
Непрерывная проверка качества – это набор процедур, которые документируют каждое изменение в ходе проекта, необходимое, чтобы окончательно гарантировать качество. Не только отчеты о состоянии проекта, но и оценки текущей деятельности и возможных изменений необходимых для выявления проблем, как можно скорее. Для поддержки этих процедур, каждый проект нуждается в определенном процессе управляемых изменений. Все эти действия могут быть реализованы в виде поддерживающих действий рабочих процессов. Непрерывная проверки качества включает в себя тщательное тестирование. Кроме внутреннего тестирования, внешние приемочные испытания с клиентом необходимы также для того, чтобы убедиться, что продукт отвечает потребностям и требованиям заказчика. Поэтому процесс разработки программного обеспечения должен включать в себя рабочий процесс тестирования на протяжении всего процесса, в том числе внешних испытаний с конечными пользователями, чтобы обеспечить высокое качество программного обеспечения.
Требования заказчика – процесс разработки программного обеспечения основывается на четкой структуре и методологии требовать с заказчика документ. Он также должен интегрировать эти требования в полном процессе. Выявление требований является одним из наиболее сложных программных обеспечений инженерных дисциплин. Потребности и пожелания клиента, которые обычно не имеют глубоких технических знаний, должны быть документированы, так чтобы разработчики могли создавать приложения на основе этой информации. Таким образом, необходимо, чтобы команда проекта понимала клиента и его бизнес. В противном случае будет невозможно правильно реализовать потребности клиентов. Процесс разработки программного обеспечения должен сосредоточиться на требованиях на протяжении всего проекта. Выявление и документирование требований в начале не является достаточным. Кроме того, процесс разработки программного обеспечения должен гарантировать, что не только клиент, но и конечные пользователи участвуют в процессе формирования требований. Успех проекта сильно зависит от этих двух групп: первая покупка продукта, а вторая, его использование. Процесс разработки программного обеспечения должен определить процедуры для подготовки конечных пользователей использовать конечный продукт.
Архитектура системы – в современных разработках программного обеспечения, архитектура системы оказывает значительное влияние на общее качество продукта. Одной из причин этого является интеграция в существующие системы программной среды, как большая часть сегодняшнего развития программного обеспечения. Повторное использование приобретает все большее значение в связи с увеличением времени и давления на затраты.
Фокус на команде – команда должна рассматриваться как совокупность равноправных лиц, которые вместе несут ответственность за качество и успешность проекта. Когда ответственность за неудачи может быть отнесена к одному человеку, успех проекта не может быть гарантирован. Сосредоточение на совместную работу повышает мотивацию участников проекта, так как все это рассматривается как столь же важной частью проекта. Это в конечном итоге приводит к высокой идентификации членов команды с продуктом. Очевидно, что мотивированные члены команды способствуют высокому качеству, поскольку они работают более концентрированно и добросовестно. Процесс разработки программного обеспечения должен включать четко определенную структуру команды, в том числе эффективной постановки задач и четких руководящих принципов коммуникации. MSF присваивает значение равного по каждому члену команды и роли: полная команда имеет шесть целей для достижения и может рассматриваться как мощная реализация принципа фокуса команды. В большинстве проектов некоторые цели имеют более высокое значение, чем другие. Менеджеры решают самостоятельно или возлагают ответственность за неспособность членов своей команды. MSF «команда коллег» концепция позволяет избежать этих проблем и позволяет проекту получить прибыль от всех возможностей коллективной работы.
Парное программирование – парное программирование тесно связано с акцентом на команды, но было выбрано в качестве другого критерия оценки, поскольку оно было недооценено за свой вклад в высокое качество в прошлом. XP демонстрирует, как два разработчика могут дополнять друг друга, а не мешать друг другу. Один разработчик реализует текущий метод, а другой работает над вопросами интеграции. Такой подход экономит время и минимизирует количество ошибок. Лучшее решение, более вероятно, так как два человека, скорее всего, имеют разные точки зрения той же проблемы и, следовательно, дополняют друг друга в ее решении.
Управление требованиями – процесс разработки программного обеспечения должен быть определен и формализован на пути относительно его применения к широкому набору проектов. Процесс, который концентрируется на небольшом или специализированном наборе проектов гарантирует высокое качество в конкретной среде. Основной целью процесса является применение многих проектов внутри компании, не снижая его прочности. Процесс должен быть адаптирован к различным проектам на основе ее основных элементов. Для того, чтобы охватить всю сложность типовых проектов, заданный набор основных элементов должен быть сохранен. Большое количество основных элементов, не обязательно улучшат качество конечного продукта. Поэтому процессы разработки программного обеспечения должны опираться на основные элементы. Основываясь на этих основных элементах, необходимо определить методы интегрирования процесса к типу проекта и размер проекта.
Конфигурация и управление изменениями – хорошо функционирующая конфигурация и управление изменениями (КЗУ) является важной частью обеспечения качества программного обеспечения. Существование или не существование КЗУ оказывает наибольшее влияние при обслуживании программного обеспечения и развития, все же основы для КЗУ (надлежащей документации, кода архивов источника и т.д.) должны быть установлены в процессе разработки.
Управление рисками – это процесс принятия и выполнения управленческих решений, направленных на снижение вероятности возникновения неблагоприятного результата и минимизацию возможных потерь, вызванных его реализацией. В рамках управления рисками осуществляется количественная и качественная оценка вероятности достижения предполагаемого результата, неудачи и отклонения от цели.. MSF представляет свою собственную модель управления рисками. Она, следовательно, делает акцент на дисциплине, придавая этому важное значение для поддержания проекта на пути улучшения общего качества разработки. Управление рисками, как собственная дисциплина, является критерием для любого процесса разработки программного обеспечения с акцентом на улучшение качества программного продукта. Управление рисками в рамках встреч и других дисциплин предполагает, что идентификация и управление рисками становится менее важным, поскольку проектная группа занята другими проблемами. Проект становится восприимчивым к факторам риска.
Microsoft Solutions Framework является наиболее сбалансированной технологией, ориентированной на проектные группы малых и средних размеров. MSF не накладывает никаких ограничений на используемый инструментарий и содержит рекомендации весьма общего характера. Однако, эти рекомендации могут быть использованы для построения конкретного процесса, соответствующего потребностям коллектива разработчиков. [10]
Наш проект является небольшим, включает в себя 2 человека и этапы разработки и тестирования проводятся в среде разработки C#. Кроме того, основным преимуществом MSF является итерационная модель одновременно с уточняющими вехами (аналог каскадной модели). Таким образом, реализация MSF попыталась объединить каскадную и итерационную модель разработки и внедрения ПО.
По описанным выше преимуществам, мною был выбран стандарт MSF как наиболее гибкий и удобный для реализации моего проекта.
Одним из преимуществ этого стандарта является возможность управлять одновременно и проектом разработкой приложения, а также внедрением инфраструктуры.
Этапы
Предвидение, фаза процесса MSF начинается с фазы выработки концепции. Предвиденье может быть определено как создание широкого описания целей и ограничений проекта. На этом этапе определена команда и то, что команда должна выполнить для клиента. Цель фазы выработки концепции заключается в создании общей концепции проекта среди всех ключевых заинтересованных сторон проекта.
Методология разработки во время фазы выработки концепции команда управления программой определяет задачи и ожидаемые результаты, которые учитывают потребности и цели проекта. Эта фаза завершается видением. Этот этап означает, что клиент и команда договариваются о цели и направлении проекта.
Фаза планирования, на этапе планирования, команда определяет, что нужно для разработки плана, как создать решение. Команда готовит функциональную спецификацию, создает дизайн решения, и готовит планы работы, сметы расходов и графики для различных результатов.
Этап планирования включает анализ требований. Эти требования могут быть классифицированы как бизнес-требования, требования пользователей, эксплуатационные требования и требования к системе. Эти требования используются для разработки решения и в особенности для проверки правильности конструкции.
После сбора и анализа требований, команда создает дизайн решения. Команда создает профили пользователей, которые определяют различные пользовательские решения их роли и обязанности. Затем команда создает ряд сценариев использования. Сценарий использования определяет деятельность, выполняемую определенным типом пользователя. Таким образом, команда должна создать сценарии использования для всех профилей пользователей. После создания сценариев использования, команда создает случаи использования для сценариев использования. Прецедент определяет последовательность шагов, которые пользователь будет выполнять в сценарии использования.
Разработка фазы во время фазы разработки, команда проекта создает решение. Этот процесс включает в себя создание кода, который реализует решения и документирование кода. В дополнение к разработке кода, команда также развивает инфраструктуру для решения.
В процессе разработки команда выполняет следующие основные задачи на данном этапе:
- Начало цикла разработки. Проверка того, что все задачи, выявленные в ходе выработки концепции и планирования этапов были завершены, так что команда может приступить к разработке решения.
- Создание приложения прототипа. Проверка концепций проекта решения в среде, которая напоминает среду, в которой решение будет в конечном счете развернуто. Эта среда является как можно более близкой к производственной среде. Эта задача будет завершена до начала разработки.
- Разработка компонентов решения. Разработка основных компонентов решения, и расширение этих компонентов к конкретным потребностям решения.
- Построение решения. Серия ежедневных и частых тестов, которые достигают высшей точки когда команда разработчиков выявляет ключевые особенности решения.
- Закрытие фазы разработки. Завершение всех функций, а также поставка кода и документации. Решение считается завершенным, и команда входит в процесс утверждения проекта.
Методология разработки
Стабилизирующая фаза, во время фазы стабилизации, команда выполняет интеграцию, нагрузку, и бета-тестирование решения. Кроме того, команда тестирует сценарии развертывания для решения. Команда сосредоточена на выявлении, приоритизации в решении вопросов, с тем, что решение может быть подготовлено к выпуску. На этом этапе решение переходит от состояния всех функций, являющихся полными, как это определено в функциональной спецификации для этой версии в состоянии удовлетворения определенных уровней качества. Кроме того, решение готово к развертыванию в бизнесе.
Результатами стабилизирующей фазы заключаются в следующем:
- окончательный релиз
- заметки о выпуске
- поддержка производительности элементов
- результаты испытаний и инструменты тестирования
- исходный код и исполняемые файлы
- проектные документы
- обзор решения
Развертывание фазы, на этом этапе команда развертывает технологию решения и компоненты сайта, стабилизирует развертывание, передает проект на операцию и поддержку, и получает окончательное одобрение от клиента по проекту. После развертывания команда проводит обзор проекта и исследование удовлетворенности клиентов. Фаза развертывания достигает кульминации в развертывании полной вехи.
Под моделью жизненного цикла понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении жизненного цикла. Модель жизненного цикла зависит от специфики информационной системы и специфики условий, в которых последняя создается и функционирует. [11]
К настоящему времени наибольшее распространение получили следующие основные модели жизненного цикла:
- Модель водопада
- V-образная модель
- Модель эволюционного прототипирования
- Спиральный метод
- Итеративный и инкрементальный метод
Модель водопада на рис. 2.1 представляет собой линейный последовательный поток. В котором прогресс рассматривается как непрерывно нисходящий (как водопад) через фазы реализации программного обеспечения. Это означает, что любой этап в процессе разработки начинается, только если предыдущий этап завершен. Водопадный подход не определяет процесс возврата к предыдущему этапу для обработки изменений в требованиях. Водопадный подход является самым ранним и наиболее широко известным подходом, который использовался для разработки программного обеспечения.
Рисунок 2.1 – Водопадная модель
Проекты, которые не ориентированы на изменение требований, например, проекты, инициированные по запросу предложений когда у клиента есть ряд очень четко задокументированных требований.
Таблица № 2.2
Преимущество и недостатки водопадной модели
V-образная модель на рис. 2.2 это расширение модели водопада. Вместо линейного перемещения ступени процесса после фазы реализации и кодирования изгибаются вверх, чтобы сформировать типичную V-образную форму. Основное различие между V-образной моделью и моделью водопада заключается в раннем планировании испытаний в V-образной модели. Требования к программному обеспечению четко определены и известны. Технологии и инструменты разработки программного обеспечения хорошо известны.
Модель прототипирования на рис. 2.3 относится к деятельности по созданию прототипов программных приложений, например, неполных версий разрабатываемой программы. Это действие, которое может происходить при разработке программного обеспечения, и оно используется для визуализации некоторого компонента программного обеспечения, чтобы ограничить разрыв в неправильном понимании требований заказчика командой разработчиков. Это также уменьшит количество итераций, которые могут возникнуть в подходе с водопадом, и их трудно реализовать из-за негибкости подхода с водопадом. Таким образом, при разработке окончательного прототипа требование считается замороженным.
Спиральная модель (SDM) на рис. 2.4 она объединяет элементы как проектирования, так и поэтапного создания прототипа, чтобы объединить преимущества концепций сверху вниз и снизу вверх. Эта модель развития сочетает в себе особенности модели прототипа и модели водопада. Спиральная модель предпочтительна для больших, дорогих и сложных проектов. Эта модель использует многие из тех же этапов, что и модель водопада, в основном в том же порядке, разделенных планированием, оценкой риска и созданием прототипов и симуляций.
Рисунок 2.4 – Спиральная модель
Он используется в крупных приложениях и системах, которые встроены в небольшие фазы или сегменты.
Таблица № 2.5
Преимущества и недостатки спиральной модели
Итерационная и инкрементная модель на рис. 2.5 она разработана для преодоления слабых сторон модели водопада. Она начинается с первоначального планирования и заканчивается развертыванием с циклическими взаимодействиями между ними. Основная идея этого метода состоит в том, чтобы разработать систему с помощью повторяющихся циклов (итеративно) и меньшими порциями за один раз (постепенно), позволяя разработчикам программного обеспечения использовать преимущества того, что было изучено при разработке более ранних частей или версий системы. Может состоять из мини-водопадов или мини-V-образной модели.
Рисунок 2.5 — Итерационная и инкрементная модель
Он используется в больших системах, в которые встроены небольшие фазы или сегменты. Также может использоваться в системе отдельные компоненты, например, система ERP. Например, мы можем начать с модуля бюджета в качестве первой итерации, а затем мы можем начать с модуля инвентаризации и так далее.
Для преодоления перечисленных проблем была выбрана спиральная модель жизненного цикла.