Материал: DO178 Учебное пособие_в183

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам

Тема 6. Сквозной пример для единого каркаса разработки приложений

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

Квалификационные требования. Знание основных этапов и моделей жизненного цикла разработки ПО, умение выявлять и анализировать неформальные требования к программному продукту, знание основных подходов к созданию и анализу программных документов, средств для их представления. Знание средств XML, подхода Twiki. Владение средствами представления результатов анализа и принятия решений.

Ожидаемый результат. 2-3 сквозных примера разработки приложения, охватывающие полный цикл разработки. Набор снимков с прототипа графического интерфейса, иллюстрирующих различные этапы разработки, для их включения в документацию по единому каркасу. Автоматизированная система получения сквозного ряда таких иллюстраций при изменении начальных данных. Средства синхронизации такого ряда с документом, в который вставляются его элементы, все или частично.

Трудоемкость. 6 человеко-месяцев.

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

    1. Темы, связанные применением формальных методов перечень тем

Тема 1. Сравнительный анализ систем верификации

Тема 2. Формализация протоколов связи краткое описание каждой темы

Тема 1. Сравнительный анализ систем верификации

Задача. Провести сравнительный анализ нескольких представительных систем верификации формальных моделей программных систем.

Квалификационные требования. Знание основных этапов и моделей жизненного цикла разработки ПО, умение выявлять и анализировать неформальные требования к программному продукту, знание средств для представления формальных моделей и систем формализации требований. Владение средствами представления результатов анализа и принятия решений. Наличие доступа к заявленным системам верификации.

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

Трудоемкость. 6 человеко-месяцев.

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

Тема 2. Формализация протоколов связи

Задача. Выполнить формализацию известных протоколов связи и проверить их свойства.

Квалификационные требования. Знание основных этапов и моделей жизненного цикла разработки ПО, умение выявлять и анализировать неформальные требования к программному продукту, знание средств для представления формальных моделей и систем формализации требований. Владение средствами представления результатов анализа и принятия решений. Наличие доступа к заявленным системам верификации.

Ожидаемый результат. Документ «Верификация протоколов связи», содержащий описание формальной модели протокола связи в выбранном формализме, результаты его верификации каким-либо известным методом. Значения релевантных метрик по трудозатратам на реализацию и исследование разработанной формализации, их обоснование, выводы и рекомендации по применению данных протоколов.

Трудоемкость. 6 человеко-месяцев.

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

10.Литература

  1. Boehm B.W. Software Engineering Economics. - Englewood Cliffs: Prentice Hall, 1981. - 767 p. – Русский перевод: Боэм Б.У. Инженерное проектирование программного обеспечения: Пер. с англ. - М.: Радио и связь, 1985. - 512 с.

  2. Brooks F.P.jr. The Mythical Man-Month. - S.L.: Addison-Wesley, 1975. – Русские переводы: Брукс Ф.П.мл. Как проектируются и создаются программные комплексы. (Серия: "Библиотечка программиста"). - М.: Наука, 1979. - 152 с.; СПб.: Символ, 2000. – 298 с.

  3. DeMarco T. Controlling Software Projects. - Englewood Cliffs: Prentice Hall, 1982. - 284 p.

  4. Humphrey W.S. Managing the Software Process – Reading: Addison-Wesley, 1989. - 494 p.

  5. Ruskin A.M., Estes W.E. What Every Engineer Should Know about Project Management. - New York: Marcel Dekker, Inc., 1994. - 276 p.

  6. Florac W.A., Carlton A.D. Measuring the Software Process – Addison-Wesley, 1999. – 272 p.

  7. Баранов С.Н., Домарацкий А.Н., Ласточкин Н.К., Морозов В.П. Процесс разработки программных изделий – М.: Наука, 2000. – 176 с.

  8. Jones C. Software Assessments, Benchmarks, and Best Practice – Addison-Wesley, 2000. – 688 p.

  9. Липаев В.В. Тестирование компонентов и комплексов программ: учебник. РАН. Институт системного программирования. – М.: Синтег, 2010. – 392 с.

  10. Хант Э., Томас Д. Программист-прагматик: путь от подмастерья к мастеру / пер. с англ. А. Алексашин. – М.: ЛОРИ, 2009. – 270 с.

  11. Гласс Р. Креативное программирование 2.0 / пер. с англ. С. Маккавеев. – СПб.; М.: Символ, 2009. – 350 с.

  12. Гласс Р. Факты и заблуждения профессионального программирования / пер. с англ. В. В. Овчинников. – СПб.; М.: Символ, 2008. – 232 с.

  13. Хамбл Д., Фарли Д. Непрерывное развертывание ПО: автоматизация процессов сборки, тестирования и внедрения новых версий программ = Continuous Delivery / пер. с англ. А. Г. Сысонюк ; ред.: В. Р. Гинзбург, А. Г. Сысонюк. – М. и др.: Вильямс, 2011. – 428 с.

  14. Репин В.В., Елиферов В.Г. Процессный подход к управлению. Моделирование бизнес-процессов/ 6-е изд. – М.: Стандарты и качество, 2008. – 408 с.

  15. Управление проектом. Основы проектного управления: учебник/ М. Л. Разу [и др.]; ред. М. Л. Разу; Гос. ун-т. упр. – 3-е изд., перераб. и доп. – М.: КноРус, 2011. – 755 с.

  16. Maslow A. H. Motivation and Personality. – New York: Harpaer & Row, 1954.

  17. Холстед М.Х. Начала науки о программах. – Пер.с англ. – М.: Финансы и статистика, 1981. – 128 с.

  18. Watson A.H., McCabe Th.J., Dolores R. Structured Testing: a Testing Methodology Using the Cyclomatic Complexity Metric. – National Institute of Standards and Technology Special Publication 500-235, September 1996. – 123 p.

  19. Тейер Т., Липов М., Нельсон Э. Надежность программного обеспечения: Пер.с англ. – М.: Мир, 1981. – 325 с.

  20. Putnam L.H. A General Empirical Solution in the Macro Software Sizing and Estimation Problem. – IEEE Transactions on Software Engineering, vol.4, num.4 (July 1978), pp.345-361.

  21. Beyer D., Henzinger T., Jhala R., Majumdar R. The Software Model Checker BLAST. – International Journal of Software Tools Technology Transfer, 2007, issue 9, pp. 505-525.

  22. Ben-Ari M. Principles of Spin. – Springer Verlag, 2008. – 216 p.

  23. Buhr R.J.A. and Casselman R.S. Use Case Maps for Object-Oriented Systems. – Prentice Hall: London, 1996.

  24. CBMC – Bounded Model Checking for ANSI-C. (electronic) http://www.cs.cmu.edu/~modelcheck/cbmc

  25. Cimatti A., Clarke E. M., Giunchiglia E., et al. NuSMV 2: An OpenSource Tool for Symbolic Model Checking. – Proceeding of International Conf. on Computer-Aided Verification, Copenhagen, Denmark, 2002, pp.359-364.

  26. Godefroid P. Software Model Checking: the VeriSoft Approach. – Formal Methods in System Design. – Springer science: Netherlands, 2005, vol. 26, pp.77-101.

  27. ITU-T Recommendation Z.120: Message Sequence Chart (MSC). – Geneva, Switzerland, October, 1996. – (electronic) http://eu.sabotage.org/www/ITU/Z/Z0120e.pdf

  28. ITU-T Recommendation Z.151: User Requirements Notation (URN) – Language Definition. – Geneva, Switzerland, September, 2003. – (electronic) http://www.itu.int/rec/T-REC-Z.151-200811-I/en

  29. Ануреев И.С., Баранов С.Н. и др. Средства поддержки интегрированной технологии для анализа и верификации телекоммуникационных приложений. – Труды СПИИРАН, №3(26), 2013, с.349-383.

  30. Баранов С.Н., Вайгерт Т.,и др. Спецификация систем с помощью базовых протоколов. – Кибернетика и системный анализ, 2005, № 4, с.3-21.

  31. The Coq Proof Assistant. – (electronic) http://coq.inria.fr

  32. Isabelle. – (electronic) http://www.cl.cam.ac.uk/research/hvg/Isabelle

  33. Vampire Theorem Proving. – (electronic) http://www.voronkov.com/vampire.cgi

  34. Ambler S. W. The Object Primer: Agile Model Driven Development with UML 2. – Cambridge University Press, 2004. – 545 p.

  35. Jacobson I., Booch G., Rumbaugh J. The Unified Software Development Process, -- Addison-Wesley, 1999. – 512 p.

  36. Z3 Theorem Prover. – (electronic) http://z3.codeplex.com/

  37. Simplify: A Theorem Prover for Program Checking. – (electronic) http://www.hpl.hp.com/techreports/2003/HPL-2003-148.html

  38. Ratzer A.V., Wells L., et al. CPN Tools for Editing, Simulating, and Analysing Coloured Petri Nets. – (electronic) http://student.cse.fau.edu/~jsloan11/CEN6076/258_CpnToolsHowTo.pdf

  39. Баранов С.Н., Тележкин А.М. Метрическое обеспечение программных разработок. // Труды СПИИРАН, №5(36), . 2014, с.5-27.

11.Приложения

    1. Шаблон для одностраничного экрана проекта

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

<АКРОНИМ проекта> – <Полное название проекта>

Аннотация. <текст аннотации>

Начало: <дата> Окончание: <дата> Размер: <KAELOC>

ЗАКАЗЧИК: <организация или лицо> Контактное лицо из руководства: <ФИО> <эл.почта>, <тел.> Контактное лицо по техническим вопросам: <ФИО> <эл.почта>, <тел.>

ПРОЕКТНАЯ ГРУППА: Руководитель: <ФИО> Отв.разработчик: <ФИО> Рук.тестирования: <ФИО> Разработчик: <ФИО> ….. Тестировщик: <ФИО> Инж.по качеству: <ФИО>

<Кол-во>

ПРОГРАММНЫЕ РЕСУРСЫ: <название>: <кол-во> <название>: <кол-во> ….. <название>: <кол-во>

<Кол-во>

 

 

ТЕХНОЛОГИИ/ ИНСТРУМЕНТЫ: <название> <название> ….. <название>

АППАРАТНЫЕ РЕСУРСЫ: Сервера: <кол-во> Персон.комп.: <кол-во> Платы: <кол-во> Другое: <кол-во>

<Кол-во>

ЦЕЛИ: 1. 2. …

 

ЗАВИСИМОСТИ: 1. 2. …..

Содержание этого экрана обычно достаточно стабильно и меняется относительно редко по ходу проекта.

    1. Примерная структура положения о работе и тз

Положение о работе (Statement of Work) оформляется в соответствии с принятым шаблоном и включает, как правило, следующие разделы:

1. Introduction – Введение, краткое описание и обоснование проекта

2. Abbreviations and Acronyms – Сокращения и акронимы в документе

3. References – Ссылки на источники, документы, литература, сайты

4. Problems, Goals, Tasks – Проблемы, цели, задачи данного проекта

5. Organizational Boundaries – Организационные рамки проекта

5.1. Organizational Structure – Организационная структура проекта

5.2. Major Deliverables and Tentative Schedule – Основные поставки и примерный график выполнения работ

6. Resources – Ресурсы, запрашиваемые для выполнения проекта

6.1. Required Hardware – Необходимое аппаратное обеспечение

6.2. Required Software – Необходимое программное обеспечение

6.3. Required Special Components – Необходимые специальные компоненты

6.4. Tentative Budget – Примерный бюджет

7. Risks – Риски

8. Results – Результаты

8.1. Expected Results – Ожидаемые результаты

8.2. Acceptance Criteria – Критерии приемки

9. Export Control and Protection of Intellectual Proprietary – Экспортный контроль и защита интеллектуальной собственности

Техническое задание оформляется в соответствии с рядом ГОСТов и требований ЕСПД и ЕСКД как ТЗ на проведение опытно-конструкторских работ (ОКР). Типичная структура ТЗ для ОКР по государственному заказу содержит следующие разделы:

Источник: https://studfile.net/preview/16431019/