Реферат по практике

Студента Лактюшина Данилы

306 группы

Модели и стадии ЖЦ ПС

Под моделью ЖЦ ПС понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении ЖЦ ПС. Модель ЖЦ зависит от специфики, масштаба и сложности проекта и специфики условий, в которых система создается и функционирует. Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПС. Его положения являются общими для любых моделей ЖЦ, методов и технологий разработки ПС. Стандарт описывает структуру процессов ЖЦ ПС, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

Модель ЖЦ любой конкретной ПС определяет характер процесса ее создания, который представляет собой совокупность упорядоченных во времени, взаимосвязанных и объединенных в стадии (фазы) работ, выполнение которых необходимо для создания ПС, соответствующей заданным требованиям.

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

• 
  1) формирование требований к ПС;
  
• 
  2) проектирование (разработка системного проекта);
  
• 
  3) реализация (может быть разбита на подэтапы: детальное проектирование, кодирование);
  
• 
  4) тестирование (может быть разбито на автономное и комплексное тестирование и интеграцию);
  
• 
  5) ввод в действие (внедрение);
  
• 
  6) эксплуатация и сопровождение;
  
• 
  7) снятие с эксплуатации.
  

Некоторые специалисты, например Б. Боэм [6], вводят дополнительно начальную стадию - анализ осуществимости системы, что следует считать оправданным, особенно при создании достаточно сложных систем. Здесь имеется в виду программно-аппаратная система, для которой создается, приобретается или модифицируется ПС.

Стадия формирования требований

---

 к ПС является одной из важнейших и определяет в значительной (даже решающей!) степени успех всего проекта. Началом этой стадии является получение одобренной и утвержденной архитектуры системы с включением основных соглашений о распределении функций между аппаратурой и программами. Этот документ должен также содержать подтверждение общего представления о функционировании ПС с включением основных соглашений о распределении функций между человеком и системой.

Стадия формирования требований к ПС включает в себя следующие этапы.

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

• 
  г) создание и обучение совместной рабочей группы.
  
• 
  2. Проведение обследования деятельности автоматизируемой организации (объекта), в рамках которого осуществляются:
  
  • 
    а) предварительное выявление требований к будущей системе;
    
  • 
    б) определение структуры организации;
    
  • 
    в) определение перечня целевых функций организации;
    
  • 
    г) анализ распределения функций по подразделениям и сотрудникам;
    
  • 
    д) выявление функциональных взаимодействий между подразделениями;
    
  • 
    е) установление информационных потоков внутри подразделений и между ними;
    
  • 
    ж) выявление внешних по отношению к организации объектов и внешних информационных воздействий;
    
  • 
    з) анализ существующих средств автоматизации деятельности организации.
    
• 
  3. Построение модели деятельности организации (объекта), предусматривающее обработку материалов обследования и построение двух видов моделей:
  
  • 
    а) модели AS - IS (как есть), отражающей существующее на момент обследования положение дел в организации и позволяющей понять, каким образом работает данная организация, а также выявить узкие места и сформулировать предложения по улучшению ситуации;
    
  • 
    б) модели ТО - BE (как должно быть), отражающей представление о новых технологиях работы организации.
    

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

---

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

Стадия проектирования включает следующие этапы.

1. Разработку системного проекта ПС. На этом этапе дается ответ на вопрос «Что должна делать будущая система?», а именно: определяются архитектура системы, ее функции, внешние условия функционирования, интерфейсы и распределение функций между пользователями и системой, требования к программным и информационным компонентам, состав исполнителей и сроки разработки, план отладки ПО и контроль качества.

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

2. Разработку детального (технического) проекта. На этом этапе осуществляется собственно проектирование ПС, включающее в себя проектирование архитектуры системы и детальное проектирование. Таким образом, дается ответ на вопрос: «Как построить систему, чтобы она удовлетворяла требованиям?»

Результатом детального проектирования является разработка верифицированной спецификации ПС, включающей в себя [6, 20]:

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

Завершением стадии детального проектирования является сквозной контроль проекта, или критический поблочный анализ проекта.

Стадия реализации предусматривает выполнение следующих работ.

---

1. Разработку верифицированной детальной спецификации каждой подпрограммы (блока не более чем из 100 исходных команд языка высокого уровня).

Внешние спецификации должны содержать следующие сведения:

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

• 
  5. Описание базы данных до уровня отдельных параметров, символов и битов.
  
• 
  6. Разработку плана приемных испытаний.
  
• 
  7. Разработку руководства пользователя.
  
• 
  8. Предварительный план комплексирования и отладки.
  

Пошаговое и монолитное тестирование

Реализация процесса тестирования модулей опирается на два ключевых положения:

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

Рассмотрим два подхода к комбинированию модулей: пошаговое и монолитное тестирование.

Метод монолитного тестирования (.монолитный метод «большого удара») предполагает выполнение по отдельности тестирования каждого модуля, их комбинирования и формирование рабочей программы.

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

---

Сравнительный анализ данных методов выявил следующие особенности.

• 
  1. Монолитное тестирование требует больших затрат труда.
  
• 
  2. Расход машинного времени при монолитном тестировании меньше.
  
• 
  3. Использование монолитного метода предоставляет большие возможности для параллельной организации работы на начальной фазе тестирования (тестирования всех модулей одновременно). Это имеет важное значение при выполнении больших проектов, в которых много модулей.
  
• 
  4. При пошаговом тестировании раньше обнаруживаются ошибки в интерфейсах между модулями, поскольку раньше начинается сборка программы. При монолитном тестировании модули «не видят друг друга» до последней фазы процесса тестирования.
  
• 
  5. Отладка программ при пошаговом тестировании легче. Если есть ошибки в межмодульных интерфейсах, то при монолитном тестировании они могут быть обнаружены лишь тогда, когда собрана вся программа. В этот момент локализовать ошибку довольно трудно, поскольку она может находиться в любом месте программы. При пошаговом тестировании ошибки такого типа в основном связаны с тем модулем, который подключается последним.
  
• 
  6. Результаты пошагового тестирования более совершенны.
  

Пункты 1, 4, 5, 6 демонстрируют преимущества пошагового тестирования, а п. 2 и 3 — его недостатки. Поскольку для современного этапа развития вычислительной техники характерны тенденции к уменьшению стоимости аппаратуры и увеличению стоимости труда, последствия ошибок в математическом обеспечении весьма серьезны, а стоимость устранения ошибки тем меньше, чем раньше она обнаружена; преимущества, указанные в п. 1, 4, 5, 6, выступают на первый план. В то же время ущерб, наносимый недостатками (п. 2 и 3), невелик. Следовательно, пошаговое тестирование является предпочтительным.

История создания UML

Разработка UML началась в октябре 1994 года, когда Гради Буч и Jim Rumbaugh из Rational Software Corporation приступили к совместной работе по унифицированию методов Booch и OMT (Object Modeling Technique). Оба метода развивались независимо друг от друга и были по праву названы одними из лучших методов объектно-ориентированного подхода при разработке программных систем. Было принято решение об объединении этих двух методов, и в октябре 1995 вышла бета-версия, которая получила название Unified Method.

К концу 1996 года выяснилось, что ряд крупных компаний готовы рассмотреть UML в качестве основной стратегии своего бизнеса. Был создан некоммерческий консорциум OMG (Object Modeling Group), который объединил таких ведущих производителей ПО, как DEC, HP, IBM, Microsoft, Oracle, Rational Software и др. В январе 1997 был выдан UML 1.0. Вскоре к OMG примкнули такие компании, как IBM, Objectime, Platinum Technology и Softeam. Как результат этого сотрудничества появилась версия UML 1.1. В 2003 была принята версия 1.5. 2004 г. – принята версия 2.0

---

Смотрите также файлы

• Техника ведения мяча в баскетболе. Техника ведения, ловли, передача мяча.docx

• Планконспект проведения занятий с группой личного состава дежурных караулов 72 псч, оп 72 псч 4 псо фпс гпс главного управления мчс россии по ХантыМансийскому автономному округу Югре. Тема 1 Организация гарнизонной и караульной службы.docx

• Тип урока Урок открытия нового знания Тема урока Сказка о мёртвой царевне и о семи богатырях А. С. Пушкина. Истоки рождения сюжета. Народная мораль.docx

• Фактор A замкнутость общительность.docx

• Тема технологія створення екскурсії.doc