Файл: Частное учреждение профессионального образования краснознаменский городской колледж.doc

Вывод

Таким образом, целями создания системы:

1. Повысить успеваемость за счет:

• 
  повышения уровня прозрачности учебного процесса;
  
• 
  автоматизации учетных функций;
  
• 
  повышения объективности оценивания учебных достижений обучающихся;
  
• 
  удобства ведения учета и анализа учебной деятельности повышение надежности хранения информации;
  
• 
  технологического развития учебного процесса.
  

2. Обеспечить предоставление государственной услуги «Предоставление информации о текущей успеваемости учащегося, ведения электронного дневника и электронного журнала успеваемости».

2. Проектная часть

2.1. Этапы жизненного цикла проекта автоматизации

Жизненный цикл информационной системы – это период создания и использования ЭИС, охватывающий её различные состояния, начиная с момента возникновения необходимости в данной ЭИС и заканчивая моментом её полного выхода из употребления у пользователей [9].

На данный момент, наиболее распространенными стандартами, регламентирующими жизненный цикл информационных систем, являются:

• 
  серия стандартов ГОСТ 34 (ГОСТ 34.601-90 «Автоматизированные системы Стадии создания»),
  
• 
  ISO 12207 «Standard for Information Technoiogy - Software Life Cycle Processes»,
  
• 
  ISO 15288 «Standard for Information Technoiogy - System Life Cycle Processes».
  

Стандарт ГОСТ 34.601-90 на создание и развитие автоматизированных систем достаточно обобщенный, однако предъявляет жесткие требования к структуре жизненного цикла информационной системы, а так же к количеству, свойствам и составу проектной документации. Кроме того, серия стандартов ГОСТ 34 является достаточно устаревшей, во многом упуская особенности современных информационных систем и методов их разработки.

Стандарты ISO 12207 и ISO 15288 - это международные стандарты регламентирующие структуру жизненного цикла. Они являются более новыми, по сравнению с ГОСТ 34. Различия этих стандартов состоит в том, что ISO 12207 применяется для разработки исключительно программного обеспечения, а ISO 15288 нацелен на рассмотрение автоматизированных систем в целом, как их программной, так и аппаратной составляющих.

Таким образом, в процессе дипломного проектирования будет использоваться стандарт жизненного цикла ISO 12207. Этот стандарт является основным нормативным документом, регламентирующим состав процессов жизненного цикла ПО. Он определяет структуру жизненного цикла, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО. Каждый процесс разделен на набор действий, каждое действие - на набор задач. Каждый процесс, действие или задача инициируется и выполняется другим процессом по мере необходимости, причем не существует заранее определенных последовательностей выполнения. Связи по входным данным при этом сохраняются.

---

Рассмотрим этапы жизненного цикла разрабатываемой информационной системы, в соответствии с выбранным стандартом жизненного цикла:

• 
  Этап разработки и внедрения состоит из работ и задач, выполняемых разработчиком (на начальных этапах и заказчиком). Основными целями данного этапа является: разработка технического задания (ТЗ) на информационную систему; преобразование требований ТЗ в детальные спецификации информационной системы; собственно, разработка и тестирование программного продукта.
  

Рассмотрим основные работы, выполняемые на данном этапе:

• 
  подготовка процесса;
  
  • 
    Разработчик должен определить или выбрать модель жизненного цикла программных средств, соответствующую области реализации, величине и сложности проекта. При этом должны быть выбраны и структурированы в модели жизненного цикла программных средств работы и задачи процесса разработки.
    
  • 
    Разработчик должен:
    
    • 
      документально оформить выходные результаты в соответствии с процессом документирования;
      
    • 
      документально оформить и решить возникающие проблемы и устранять несоответствия, обнаруженные в программных продуктах и задачах, в соответствии с процессом решения проблем;
      
  • 
    Разработчик должен выбрать, адаптировать и использовать стандарты, методы, инструментарий, языки программирования.
    
  • 
    Разработчик должен разработать планы проведения работ процесса разработки. Планы должны охватывать конкретные стандарты, методы, инструментарий, действия и обязанности, связанные с разработкой и квалификацией всех требований, включая безопасность и защиту. При необходимости могут разрабатываться индивидуальные планы (по конкретным требованиям или исполнителям). Все планы должны быть документально оформлены и выполнены.
    
• 
  анализ требований к системе;
  
  • 
    Разработчик, при необходимости, должен выполнить анализ области применения разрабатываемой системы с точки зрения определения требований к ней. Технические требования к системе должны охватывать: функции и возможности системы; коммерческие и организационные требования; требования пользователя; требования безопасности и защиты; эргономические требования; требования к интерфейсам; эксплуатационные требования; требования к сопровождению; проектные ограничения и квалификационные требования. Технические требования к системе должны быть документально оформлены.
    
• 
  проектирование системной архитектуры;
  
  • 
    Должна быть определена общая архитектуры системы. В архитектуре должны быть указаны объекты технических и программных средств. Должно быть обеспечено распределение всех требований к системе между объектами архитектуры. Затем должны быть определены объекты конфигурации технических и программных средств и ручных операций на основе объектов архитектуры. Должна быть документально оформлена привязка системной архитектуры и требований к системе относительно установленных объектов.
    
• 
  анализ требований к программным средствам;
  
  • 
    Разработчик должен установить и документально оформить следующие требования к программным средствам, включая технические требования к характеристикам качества
    
• 
  проектирование программной архитектуры;
  
  • 
    Разработчик должен трансформировать требования к программному объекту в архитектуру, которая описывает общую структуру объекта и определяет компоненты программного объекта. Должно быть обеспечено распределение всех требований к программному объекту между его компонентами и дальнейшее их уточнение с точки зрения облегчения технического проектирования. Архитектура программного объекта должна быть документально оформлена.
    
  • 
    Разработчик должен разработать и документально оформить общий (эскизный) проект внешних интерфейсов программного объекта и интерфейсов между компонентами объекта; проект базы данных; предварительные версии документации пользователя; требования к испытаниям (тестированию) программного объекта и график сборки программного продукта.
    
• 
  техническое проектирование программных средств;
  
  • 
    Разработчик должен разработать технический проект для каждого компонента программного объекта. Компоненты программного объекта должны быть уточнены на уровне программных модулей, которые можно программировать (кодировать), компилировать и тестировать независимо. Должно быть обеспечено распределение технических требований к компонентам программного объекта между программными модулями. Технический проект должен быть документально оформлен.
    
• 
  программирование и тестирование программных средств;
  
  • 
    Разработчик должен разработать и документально оформить каждый программный модуль и базу данных
    
• 
  сборка программных средств;
  
  • 
    Разработчик должен разработать план сборки для объединения программных модулей и компонентов в программный объект. План должен включать требования к испытаниям (тестированию), процедуры тестирования, контрольные данные, обязанности исполнителя и программу испытаний. План должен быть документально оформлен.
    
  • 
    Разработчик должен собрать программные модули и компоненты и протестировать их как продукты, разработанные в соответствии с планом сборки. Результаты сборки и тестирования должны быть документально оформлены.
    
• 
  квалификационные испытания программных средств;
  
  • 
    Разработчик должен проводить квалификационные испытания (тестирование) на соответствие квалификационным требованиям к программному продукту. При проведении испытаний должно быть обеспечено, чтобы реализация каждого установленного требования к программному объекту была проверена на соответствие. Результаты квалификационных испытаний должны быть документально оформлены.
    
  • 
    Разработчик, при необходимости, должен уточнить документацию пользователя.
    
• 
  ввод в действие программных средств. Основной задачей этого этапа является выбор стратегии внедрения информационной системы. Разрабатываемая система будет внедряться по стратегии пилотного проекта, т.е. первоначальное использование системы будет проводиться лишь для некоторых предметов школьной программы, недельная нагрузка которых составляет 1-2 учебных часа в неделю (география, экономика, МХК и др.). Это позволит учителю-предметнику сократить нагрузку на тиражирование и проверку контрольно-измерительных материалов. Кроме того, уже на первоначальных этапах использования можно будет судить о достоверности выдаваемых системой результатах, при этом, не оказывая существенного влияния на процесс выставления итоговых оценок учащимся по наиболее значимым предметам (русский язык, математика, алгебра).
  
  • 
    Разработчик должен разработать план по вводу в действие программного продукта в среде эксплуатации. Должны быть определены и иметься в наличии ресурсы и информация, необходимые для ввода в действие программного продукта. Разработчик должен провести работы по установке (инсталляции) программного продукта.
    
  • 
    Разработчик должен ввести в действие программный продукт, в соответствии с планом по вводу его в действие.
    
• 
  обеспечение приемки программных средств.
  
  • 
    Разработчик должен обеспечить проведение оценки готовности к приемке и приемочным испытаниям программного продукта.
    
• 
  Этап эксплуатации состоит из работ и задач оператора. Этап охватывает эксплуатацию программного продукта и поддержку пользователей в процессе эксплуатации.
  

---

Данный этап состоит из следующих работ:

• 
  подготовка процесса;
  
  • 
    Оператор должен разработать план эксплуатации и определить набор стандартов по эксплуатации для выполнения работ и задач данного процесса. План должен быть документально оформлен и выполнен.
    
  • 
    Оператор должен установить процедуры для: получения и документирования сведений о возникающих проблемах; решения и контроля проблем и обеспечения обратной связи с пользователем. Всякий раз, когда возникают проблемы, они должны быть документально оформлены и введены в процесс решения проблем.
    
  • 
    Оператор должен установить процедуры для: тестирования программного продукта в эксплуатационной среде; ввода сообщений о проблемах и предложений об изменениях в процесс сопровождения; ввода программного продукта в эксплуатацию.
    
• 
  эксплуатационные испытания;
  
  • 
    Для введенного в опытную эксплуатацию программного продукта оператор должен провести эксплуатационные испытания и при соответствии результатов испытаний установленным требованиям ввести программный продукт в промышленную эксплуатацию.
    
  • 
    Оператор должен обеспечить, чтобы программы и базы данных устанавливались в исходное состояние (инициализировались), выполнялись (эксплуатировались) и завершались в соответствии с планом эксплуатации.
    
• 
  эксплуатация системы;
  
  • 
    Система должна эксплуатироваться в установленной для нее эксплуатационной среде в соответствии с документацией пользователя.
    
• 
  поддержка пользователя.
  
  • 
    Оператор должен обеспечить помощь и консультации пользователям в установленном порядке. Запросы пользователей и последующие ответные действия должны быть документально оформлены и контролируемы.
    
  • 
    Оператор должен, при необходимости, направлять запросы пользователя для анализа и ответа в процесс сопровождения. Данные запросы должны быть приняты, а ответы по планируемым и выполняемым ответным действиям должны быть направлены инициаторам запросов. Все принимаемые решения должны контролироваться вплоть до их выполнения.
    
  • 
    Если поставленная проблема имеет промежуточное (временное) решение, то инициатору поставленной проблемы должны быть предложены варианты ее временного решения. Принятые окончательные поправки и изменения, содержащие ранее пропущенные функции или средства, а также усовершенствования системы должны вноситься в эксплуатируемый программный продукт с использованием процесса сопровождения.
    
• 
  Этап сопровождения состоит из работ и задач, выполняемых персоналом сопровождения. Данный этап реализуется при изменениях (модификациях) программного продукта и соответствующей документации, вызванных возникшими проблемами или потребностями в модернизации или настройке. Целью этапа является изменение существующего программного продукта при сохранении его целостности. Данный этап охватывает вопросы переносимости и снятия программного продукта с эксплуатации. Заканчивается этап снятием программного продукта с эксплуатации.
  

---

Данный этап состоит из следующих работ:

• 
  подготовительный;
  

• 
  Персонал сопровождения должен разработать, документально оформить и выполнить планы и процедуры для проведения работ и задач процесса сопровождения.
  
• 
  Персонал сопровождения должен определить процедуры для: получения, документирования и контроля сообщений о возникающих проблемах и заявок на внесение изменений от пользователей; обеспечения обратной связи с пользователями. Всякий раз, когда возникают проблемы, они должны быть документально оформлены и введены в процесс решения проблем.
  

• 
  анализ проблем и изменений;
  

• 
  Персонал сопровождения должен проанализировать сообщение о проблеме или заявку.
  
• 
  Персонал сопровождения должен продублировать или верифицировать возникшую проблему.
  
• 
  На основе проведенного анализа персонал сопровождения должен разработать варианты изменений.
  
• 
  Персонал сопровождения должен документально оформить: сообщение о проблеме или заявку на внесение изменений; результаты их анализа и варианты реализации изменений.
  

• 
  внесение изменений;
  

• 
  Персонал сопровождения должен провести анализ и определить, какие документы, программные модули или их версии требуют изменения. Полученные результаты должны быть документально оформлены.
  

• 
  снятие с эксплуатации.
  

• 
  Должен быть разработан, документально оформлен и реализован план снятия с эксплуатации при прекращении активной поддержки объекта эксплуатирующими и сопровождающими организациями. К запланированным работам должны привлекаться пользователи.
  
• 
  Пользователи должны получить уведомление о планах и работах по снятию с эксплуатации программного обеспечения.
  

---

2.1.1. Ожидаемые риски на этапах жизненного цикла и их описание

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

• 
  Этапы разработки и внедрения.
  
  • 
    Риск нарушения методологии ведения проекта. Причиной возникновения данного риска может служить необдуманное описание и утверждение документов, содержащих информацию о состоянии проекта.
    

• 
  четкое определение прав и обязанностей рабочей группы;
  
• 
  обучение рабочей группы и ключевых пользователей;
  
• 
  документирование и согласование технических условий проекта;
  
• 
  документальное подтверждение вносимых изменений в проект;
  
  • 
    Риск ведения проекта:
    
• 
  неправильное определение рамок и масштабов проекта;
  
• 
  проектирование ошибочных функций и интерфейсов будущей системы;
  
• 
  выбор неправильных технологий и методов решения поставленных задач;
  
• 
  несоблюдение требований при проектирование будущей системы или постоянное изменение требований.
  

В качестве мер предотвращения обозначенных выше моментом можно назвать:

• 
  обеспечение стабильности границ проекта, определенных на начальном этапе;
  
• 
  качественное планирование работ;
  
• 
  обеспечение проекта необходимыми ресурсами;
  
• 
  обязательное утверждение и согласование по проектным решениям;
  
• 
  дополнительный анализ функций и целей проекта, тщательная формулировка концепции;
  
  • 
    Риск неверного планирования:
    
• 
  плохая проработка плана внедрения системы;
  
• 
  срыв сроков выполнения;
  

Мерами предотвращения данных обстоятельств может служить следующее:

• 
  укомплектование проектной команды наиболее талантливыми и квалифицированными проектировщиками;
  
• 
  распределение работ соответственно способностям членов проектной команды;
  
• 
  документирование всех работ на этапе проектирования и обеспечение доступности данных для всех участников проекта;
  
  • 
    Технический и программный риски вызывают:
    
• 
  частичную или полную приостановку этапа разработки из-за ошибок в используемом программном обеспечении;
  
• 
  частичная или полная потеря программного кода;
  
• 
  контрольный пример не учитывает всех особенностей системы, то есть недостаточно проработан;
  
• 
  документация по системе не включает в себя подробного описания всего функционала системы.
  

---