1 Введение в программную инженерию По мотивам Ian Sommerville "Software Engineering"

2 Содержание Что такое программная инженерия? Стандарты SE Программные требования Модели систем Прототипы Архитектура ПО Дизайн интерфейса ПО Совершенствование процессов Управление изменениями Конфигурационное управление RUP

3 Что такое программная инженерия

4 Экономика ВСЕХ развитых стран зависит от программного обеспечения (ПО) Все больше систем управляются программно Программная инженерия изучает теории, методы и средства профессиональной разработки ПО Расходы на разработку ПО составляют значительную часть ВНП всех развитых стран Стоимость ПО зачастую составляет наиболее значительную часть стоимости систем. Программная инженерия

5 FAQ о программной инженерии Что такое программное обеспечение? Что такое программная инженерия? В чем разница между программной инженерией и информатикой? В чем разница между программной инженерией и системной инженерией? Что такое программный процесс? Что такое модель программного процесса?

6 FAQ о программной инженерии Из чего складывается стоимость программных продуктов? Что такое методы программной инженерии? Что такое CASE (Computer-Aided Software Engineering)? Каковы свойства хороших программ?

7 Что такое программное обеспечение? Компьютерные программы и связанная с ними документация Программные продукты могут разрабатываться для конкретного заказчика или для обобщенного рынка Программные продукты могут быть Коробочными (generic products, shrink- wrapped software), т.е. разработанными для продажи многим различным заказчикам Заказными (custom), т.е. разработанными для одного покупателя по его спецификациям

8 Что такое программная инженерия? Программная инженерия это инженерная дисциплина, которая связана со всеми аспектами производства ПО от начальных стадий создания спецификации до поддержки системы после сдачи в эксплуатацию. Программные инженеры применяют систематичные и организованные подходы к работе для достижения максимальной эффективности и качества ПО.

9 В чем разница между программной инженерией и информатикой? Информатика занимается теорией и методами компьютерных и программных систем. Программная инженерия занимается практическими проблемами создания ПО. Естественно, инженер-программист обязан в каком-то объеме знать информатику (точно так же, как электрический инженер должен в каком-то объеме знать физику). В идеале, вся программная инженерия должна быть поддержана какими-то теориями информатики, но практике все значительно сложнее. Инженеры зачастую применяют первые попавшиеся методы, а элегантные теории информатики не всегда могут быть применены к реальным большим системам.

10 В чем разница между программной инженерией и системной инженерией? Системная инженерия (а точнее компьютерная системная инженерия, computer-based systems engineering, CBSE) занимается всеми аспектами создания и эволюции комплексных систем, в которых ПО играет заметную роль. Таким образом, программная инженерия является частью системной инженерии, наряду с созданием аппаратных платформ, созданием архитектуры, системной интеграцией и т.п. В системной инженерии основной упор приходится именно на системные вопросы (спецификация системы, проектирование архитектуры, интеграция и внедрение), а не на составные части системы. Системная инженерия значительно старше программирования как дисциплина люди уже очень давно производят сложные индустриальные системы, такие как поезда, химические заводы и т.п.

11 Что такое программный процесс? Программный процесс это набор действий и связанных с ними результатов, приводящих к созданию программного продукта. Мы будем выделять четыре основных фазы программного процесса: Создание спецификации ПО – что система должна делать и ограничения на разработку Разработка ПО – производство программной системы Тестирование ПО (включает в себя validation и verification) – проверка того, что клиент хочет именно того, что прописано в спецификации, и что система соответствует спецификации Развитие или эволюция ПО (software evolution) – изменение ПО в ответ на изменение внешних требований

12 Что такое модель программного процесса? Модель программного процесса это упрощенное описание программного процесса, представленное с некоторой точки зрения. Модели всегда являются упрощениями: all models are wrong; some models are useful (E. Deming). Некоторые примеры типов моделей программного процесса: Модель технологического процесса (workflow model) показывает последовательность действий, наряду со входами, выходами и зависимостями. Действия в этой модели представляют собой действия людей. Модель потоков данных (data flow or activity model) представляет процесс в виде набора действий, каждый из которых выполняет некоторое преобразование данных. В этой модели действия могут быть более низкого уровня, чем в предыдущей модели (например, какие-то действия может выполнять компьютер). Модель роль/действие (role/action model) показывает роли людей, участвующих в программном процессе, а также действия, за которые они отвечают.

13 Традиционные модели разработки ПО Водопадная модель (Waterfall) Эволюционное развитие (в двух вариантах с доработкой прототипа и с выбрасыванием, т.е. переписыванием) Формальные преобразования основан на создании математических моделей системы и их дальнейшим преобразованиями, сохраняющими корректность Сборка из повторно используемых компонент предполагает, что части системы уже существуют, и процесс концентрируется скорее на интеграции, чем на разработке

14 Из чего складывается стоимость программных продуктов? Структура стоимости ПО может сильно отличаться для различных типов проектов и различных методологий. Для типичного проекта, распределение стоимости выглядит приблизительно следующим образом: 60% - стоимость разработки, 40% - стоимость тестирования. Для заказного ПО стоимость эволюции может превосходить стоимость разработки Чем больше система, и чем выше ее критичность, тем больший процент будет забирать тестирование. Стоимость эволюции системы очень сильно варьируется в зависимости от размера системы и сроком ее жизни. Во многих случаях стоимость сопровождения превосходит стоимость разработки в 3–4 раза. Наконец, при создании коробочных продуктов стоимость создания спецификации исчезающе мала (около 5%), на разработку (обычно эволюционным способом) уходит около 30-35% времени проекта, а все остальное тестирование системы на всевозможных конфигурациях. Для коробочных продуктов особенно трудно оценить стоимость эволюции обычно процесс создания новой версии не имеет четко выраженного начала, и, кроме того, чаще всего из маркетинговых соображений новая версия подается не как модифицированный продукт, уже купленный пользователем, а как продукт абсолютно новый (хотя и совместимый со старыми)

15 Что такое методы программной инженерии? Метод программной инженерии это структурный подход к созданию ПО, нацеленный на создание эффективного продукта наиболее прибыльным (рентабельным, cost-effective) путем Тема развивается с 1970 х: структурный анализ Тома Де Марко (1978), JSD Джексона (1983). Эти и другие методы тех времен были ориентированы на идентификацию основных функций системы; функционально-ориентированные методы до сих пор популярны. Как это ни смешно, очень часто их применяют неосознанно. В 1980 х гг. эти методы были дополнены всякой объектностью: Буч (1994), Рамбо (1991). Со временем эти методы были объединены в UML (книги начиная с 1997 г). Практически все методы построены на идее создания графических моделей системы с последующим использованием этих моделей в качестве спецификации или архитектуры системы.

16 Что такое CASE (Computer-Aided Software Engineering)? Понятие CASE включает в себя широкий комплекс программ, предназначенных для поддержки процессов создания программного продукта, включая анализ требований, моделирование, отладку и тестирование. Большинство современных методов поддержаны соответствующими CASE-средствами. Любопытное разделение: CASE-средства, поддерживающие анализ и проектирование, иногда называют CASE-средствами верхнего уровня (upper- CASE tools), а средства, поддерживающие реализацию и тестирование, такие как отладчики, средства анализа системы, генераторы тестов и редакторы программ, называют средствами нижнего уровня (lower-CASE tools).

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

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

19 Этический кодекс ACM/IEEE Профессиональные общества в США объединились для создания этического кодекса программистов Члены этих организаций принимают этот кодекс в момент вступления в организацию Кодекс содержит восемь Принципов, связанных с поведением и решениями, принимаемыми профессиональными программистами, включая практиков, преподавателей, менеджеров и руководителей высшего звена Кодекс распространяется также на студентов и «подмастерьев», изучающих данную профессию

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

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

22 Стандарты программной инженерии

23 Стандарты Software Engineering ISO/IEC Software Lifecycle Processes (1995) = ГОСТ Р ИСО/МЭК (1999) Guide to the Software Engineering Body of Knowledge (SWEBOK), IEEE 2004 (Руководство к своду знаний по программной инженерии) Software Engineering Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering (IEEE+ACM) ACM/IEEE-CS Code of Ethics and Professional Practice

24 Сертификационная программа

25 Структура SWEBOK: 10 основных областей знаний Software requirements – программные требования Software design – дизайн (архитектура) Software construction – конструирование ПО Software testing – тестирование Software maintenance – эксплуатация (поддержка) ПО Software configuration management – конфигурационное управление Software engineering management – управление в ПИ Software engineering process – процессы ПИ Software engineering tools and methods – инструменты и методы ПИ Software quality – качество ПО

26 SWEBOK: смежные области знаний Computer engineering Computer science Management Mathematics Project management Quality management Systems engineering

27 Программные требования

28 Программные требования Требования и спецификации системы - описание системных сервисов и ограничений Функциональные и нефункциональные требования Пользовательские требования Системные требования Документ, описывающий требования

29 Типы спецификаций Спецификации на естественном языке Структурированные спецификации Графические нотации Математические спецификации

30 Структура документа, описывающего требования Введение Глоссарий Определение требований пользователя Архитектура системы Системные спецификации Модели системы Эволюция системы Приложения

31 Описание сценариев Состояние системы в начале выполнения сценария Нормальный поток событий в сценарии Неправильный поток событий и его обработка Другие параллельные действия Состояние системы в конце выполнения сценария Use-cases (сценарии использования) основаны на технике UML когда определяются актеры и их взаимодействие друг с другом

32 Lending use-case

33 Library use-cases

34 Проверка требований Валидность. Выполняет ли система то, что нужно заказчику Непротиворечивость. Есть ли конфликт требований Полнота. Все ли необходимые функции включены в систему? Реализм. Можно ли создать систему в соответствии с требованиями в рамках заданного бюджета и технологий Верифицируемость. Можно ли проверить выполнение требований

35 Управление требованиями Идентификация требований Управление изменениями Отслеживание выполнения CASE инструменты

36 System Models

37 System models Abstract descriptions of systems whose requirements are being analysed

38 Topics covered Context models Behavioural models Data models Object models CASE workbenches

39 Model types Data processing model showing how the data is processed at different stages Composition model showing how entities are composed of other entities Architectural model showing principal sub-systems Classification model showing how entities have common characteristics Stimulus/response model showing the systems reaction to events

40 Process models Process models show the overall process and the processes that are supported by the system Data flow models may be used to show the processes and the flow of information from one process to another

41 Behavioural models Behavioural models are used to describe the overall behaviour of a system Two types of behavioural model are shown here Data processing models that show how data is processed as it moves through the system State machine models that show the systems response to events Both of these models are required for a description of the systems behaviour

42 Data-processing models Data flow diagrams are used to model the systems data processing These show the processing steps as data flows through a system Intrinsic part of many analysis methods Simple and intuitive notation that customers can understand Show end-to-end processing of data

43 Data flow diagrams DFDs model the system from a functional perspective Tracking and documenting how the data associated with a process is helpful to develop an overall understanding of the system Data flow diagrams may also be used in showing the data exchange between a system and other systems in its environment

44 Semantic data models Used to describe the logical structure of data processed by the system Entity-relation-attribute (ERA) model sets out the entities in the system, the relationships between these entities and the entity attributes Widely used in database design. Can readily be implemented using relational databases No specific notation provided in the UML but objects and associations can be used

45 Object models Object models describe the system in terms of object classes An object class is an abstraction over a set of objects with common attributes and the services (operations) provided by each object Various object models may be produced Inheritance models Aggregation models Interaction models

46 The Unified Modeling Language Devised by the developers of widely used object- oriented analysis and design methods Has become an effective standard for object-oriented modelling Notation Object classes are rectangles with the name at the top, attributes in the middle section and operations in the bottom section Relationships between object classes (known as associations) are shown as lines linking objects Inheritance is referred to as generalisation and is shown upwards rather than downwards in a hierarchy

47 Key points A model is an abstract system view. Complementary types of model provide different system information Context models show the position of a system in its environment with other systems and processes Data flow models may be used to model the data processing in a system State machine models model the systems behaviour in response to internal or external events

48 Key points Semantic data models describe the logical structure of data which is imported to or exported by the systems Object models describe logical system entities, their classification and aggregation Object models describe the logical system entities and their classification and aggregation CASE workbenches support the development of system models

49 Software Prototyping

50 Software Prototyping Rapid software development to validate requirements

51 Topics covered Prototyping in the software process Prototyping techniques User interface prototyping

52 System prototyping Prototyping is the rapid development of a system In the past, the developed system was normally thought of as inferior in some way to the required system so further development was required Now, the boundary between prototyping and normal system development is blurred and many systems are developed using an evolutionary approach

53 Prototyping process

54 Prototyping benefits Improved system usability Closer match to the system needed Improved design quality Improved maintainability Reduced overall development effort

55 Approaches to prototyping

56 Rapid prototyping techniques Various techniques may be used for rapid development Dynamic high-level language development Database programming Component and application assembly These are not exclusive techniques - they are often used together Visual programming is an inherent part of most prototype development systems

57 Component and application assembly Prototypes can be created quickly from a set of reusable components plus some mechanism to glue these component together The composition mechanism must include control facilities and a mechanism for component communication The system specification must take into account the availability and functionality of existing components

58 Reusable component composition

59 Visual programming Scripting languages such as Visual Basic support visual programming where the prototype is developed by creating a user interface from standard items and associating components with these items A large library of components exists to support this type of development These may be tailored to suit the specific application requirements

60 User interface prototyping It is impossible to pre-specify the look and feel of a user interface in an effective way. prototyping is essential UI development consumes an increasing part of overall system development costs User interface generators may be used to draw the interface and simulate its functionality with components associated with interface entities Web interfaces may be prototyped using a web site editor

61 Key points A prototype can be used to give end-users a concrete impression of the systems capabilities Prototyping is becoming increasingly used for system development where rapid development is essential Throw-away prototyping is used to understand the system requirements In evolutionary prototyping, the system is developed by evolving an initial version to the final version

62 Key points Rapid development of prototypes is essential. This may require leaving out functionality or relaxing non- functional constraints Prototyping techniques include the use of very high- level languages, database programming and prototype construction from reusable components Prototyping is essential for parts of the system such as the user interface which cannot be effectively pre-specified. Users must be involved in prototype evaluation

63 Architectural Design

64 Architectural Design Establishing the overall structure of a software system

65 Software architecture The design process for identifying the sub- systems making up a system and the framework for sub-system control and communication is architectural design The output of this design process is a description of the software architecture

66 Architectural models Different architectural models may be produced during the design process Each model presents different perspectives on the architecture

67 Architectural models Static structural model that shows the major system components Dynamic process model that shows the process structure of the system Interface model that defines sub-system interfaces Relationships model such as a data-flow model

68 CASE toolset architecture

69 Key points The software architect is responsible for deriving a structural system model, a control model and a sub-system decomposition model Large systems rarely conform to a single architectural model System decomposition models include repository models, client-server models and abstract machine models Control models include centralised control and event-driven models

70 Key points Modular decomposition models include data- flow and object models Domain specific architectural models are abstractions over an application domain. They may be constructed by abstracting from existing systems or may be idealised reference models

71 User Interface Design

72 Topics covered User interface design principles User interaction Information presentation User support Interface evaluation

73 Graphical user interfaces Most users of business systems interact with these systems through graphical interfaces although, in some cases, legacy text-based interfaces are still used

74 GUI characteristics

75 User interface design process

76 Interaction styles Direct manipulation Menu selection Form fill-in Command language Natural language

77 Control panel interface

78 Menu systems Users make a selection from a list of possibilities presented to them by the system The selection may be made by pointing and clicking with a mouse, using cursor keys or by typing the name of the selection May make use of simple-to-use terminals such as touchscreens

79 Form-based interface

80 Command interfaces User types commands to give instructions to the system e.g. UNIX May be implemented using cheap terminals. Easy to process using compiler techniques Commands of arbitrary complexity can be created by command combination Concise interfaces requiring minimal typing can be created

81 Natural language interfaces The user types a command in a natural language. Generally, the vocabulary is limited and these systems are confined to specific application domains (e.g. timetable enquiries) NL processing technology is now good enough to make these interfaces effective for casual users but experienced users find that they require too much typing

82 Multiple user interfaces

83 Help and message system

84 User documentation As well as on-line information, paper documentation should be supplied with a system Documentation should be designed for a range of users from inexperienced to experienced As well as manuals, other easy-to-use documentation such as a quick reference card may be provided

85 Key points Interface design should be user-centred. An interface should be logical and consistent and help users recover from errors Interaction styles include direct manipulation, menu systems form fill-in, command languages and natural language Graphical displays should be used to present trends and approximate values. Digital displays when precision is required Colour should be used sparingly and consistently

86 Key points Systems should provide on-line help. This should include help, Im in trouble and help, I want information Error messages should be positive rather than negative. A range of different types of user documents should be provided Ideally, a user interface should be evaluated against a usability specification

87 Process Improvement

88 Process Improvement Understanding, Modelling and Improving the Software Process

89 Process and product quality Process analysis and modelling Process measurement The SEI process maturity model Process classification Topics covered

90 Understanding existing processes Introducing process changes to achieve organisational objectives which are usually focused on quality improvement, cost reduction and schedule acceleration Most process improvement work so far has focused on defect reduction. This reflects the increasing attention paid by industry to quality However, other process attributes can be the focus of improvement Process improvement

91 Process attributes

92 The process improvement process

93 Process quality and product quality are closely related A good process is usually required to produce a good product For manufactured goods, process is the principal quality determinant For design-based activity, other factors are also involved especially the capabilities of the designers Process and product quality

94 Principal product quality factors

95 Wherever possible, quantitative process data should be collected Process measurements should be used to assess process improvements Process measurement

96 The SEI process maturity model

97 Initial Essentially uncontrolled Repeatable Product management procedures defined and used Defined Process management procedures and strategies defined and used Managed Quality management strategies defined and used Optimising Process improvement strategies defined and used Maturity model levels

98 The CMM and ISO 9000 There is a clear correlation between the key processes in the CMM and the quality management processes in ISO 9000 The CMM is more detailed and prescriptive and includes a framework for improvement Organisations rated as level 2 in the CMM are likely to be ISO 9000 compliant

99 Process improvement involves process analysis, standardisation, measurement and change Process models include descriptions of tasks, activities, roles, exceptions, communications, deliverables and other processes Measurement should be used to answer specific questions about the software process used The three types of process metrics which can be collected are time metrics, resource utilisation metrics and event metrics Key points

100 The SEI model classifies software processes as initial, repeatable, defined, managed and optimising. It identifies key processes which should be used at each of these levels The SEI model is appropriate for large systems developed by large teams of engineers. It cannot be applied without modification in other situations Processes can be classified as informal, managed, methodical and improving. This classification can be used to identify process tool support Key points

101 Software Change

102 Topics covered Program evolution dynamics Software maintenance Architectural evolution

103 Software change strategies Software maintenance Changes are made in response to changed requirements but the fundamental software structure is stable Architectural transformation The architecture of the system is modified generally from a centralised architecture to a distributed architecture Software re-engineering No new functionality is added to the system but it is restructured and reorganised to facilitate future changes These strategies may be applied separately or together

104 Maintenance to repair software faults Maintenance to adapt software to a different operating environment Maintenance to add to or modify the systems functionality Types of maintenance

105 Distribution of maintenance effort

106 Spiral maintenance model

107 Development/maintenance costs

108 Evolutionary software Rather than think of separate development and maintenance phases, evolutionary software is software that is designed so that it can continuously evolve throughout its lifetime

109 The maintenance process

110 Change requests Change requests are requests for system changes from users, customers or management In principle, all change requests should be carefully analysed as part of the maintenance process and then implemented In practice, some change requests must be implemented urgently Fault repair Changes to the systems environment Urgently required business changes

111 Change implementation

112 Emergency repair

113 Key points Software change strategies include software maintenance, architectural evolution and software re-engineering Lehmans Laws are invariant relationships that affect the evolution of a software system Maintenance types are Maintenance for repair Maintenance for a new operating environment Maintenance to implement new requirements

114 Key points The costs of software change usually exceed the costs of software development Factors influencing maintenance costs include staff stability, the nature of the development contract, skill shortages and degraded system structure Architectural evolution is concerned with evolving centralised to distributed architectures A distributed user interface can be supported using screen management middleware

115 Configuration Management

116 Topics covered Configuration management planning Change management Version and release management System building CASE tools for configuration management

117 New versions of software systems are created as they change For different machines/OS Offering different functionality Tailored for particular user requirements Configuration management is concerned with managing evolving software systems System change is a team activity CM aims to control the costs and effort involved in making changes to a system Configuration management

118 Concurrent development and testing A time for delivery of system components is agreed A new version of a system is built from these components by compiling and linking them This new version is delivered for testing using pre-defined tests Faults that are discovered during testing are documented and returned to the system developers

119 All products of the software process may have to be managed Specifications Designs Programs Test data User manuals Thousands of separate documents are generated for a large software system Configuration management planning

120 Defines the types of documents to be managed and a document naming scheme Defines who takes responsibility for the CM procedures and creation of baselines Defines policies for change control and version management Defines the CM records which must be maintained The CM plan

121 The CM plan Describes the tools which should be used to assist the CM process and any limitations on their use Defines the process of tool use Defines the CM database used to record configuration information May include information such as the CM of external software, process auditing, etc.

122 Software systems are subject to continual change requests From users From developers From market forces Change management is concerned with keeping managing of these changes and ensuring that they are implemented in the most cost-effective way Change management

123 Change request form

124 A major problem in change management is tracking change status Change tracking tools keep track the status of each change request and automatically ensure that change requests are sent to the right people at the right time. Integrated with systems allowing electronic change request distribution Change tracking tools

125 Invent identification scheme for system versions Plan when new system version is to be produced Ensure that version management procedures and tools are properly applied Plan and distribute new system releases Version and release management

126 Version An instance of a system which is functionally distinct in some way from other system instances Variant An instance of a system which is functionally identical but non-functionally distinct from other instances of a system Release An instance of a system which is distributed to users outside of the development team Versions/variants/releases

127 Version identification Procedures for version identification should define an unambiguous way of identifying component versions Three basic techniques for component identification Version numbering Attribute-based identification Change-oriented identification

128 Simple naming scheme uses a linear derivation e.g. V1, V1.1, V1.2, V2.1, V2.2 etc. Actual derivation structure is a tree or a network rather than a sequence Names are not meaningful. Hierarchical naming scheme may be better Version numbering

129 Releases must incorporate changes forced on the system by errors discovered by users and by hardware changes They must also incorporate new system functionality Release planning is concerned with when to issue a system version as a release Release management

130 System releases Not just a set of executable programs May also include Configuration files defining how the release is configured for a particular installation Data files needed for system operation An installation program or shell script to install the system on target hardware Electronic and paper documentation Packaging and associated publicity Systems are now normally released on CD-ROM or as downloadable installation files from the web

131 The process of compiling and linking software components into an executable system Different systems are built from different combinations of components Invariably supported by automated tools that are driven by build scripts System building

132 System building

133 CASE tools for configuration management CM processes are standardised and involve applying pre-defined procedures Large amounts of data must be managed CASE tool support for CM is therefore essential Mature CASE tools to support configuration management are available ranging from stand-alone tools to integrated CM workbenches

134 Change management tools Change management is a procedural process so it can be modelled and integrated with a version management system Change management tools Form editor to support processing the change request forms Workflow system to define who does what and to automate information transfer Change database that manages change proposals and is linked to a VM system

135 Version management tools Version and release identification Systems assign identifiers automatically when a new version is submitted to the system Storage management. System stores the differences between versions rather than all the version code Change history recording Record reasons for version creation Independent development Only one version at a time may be checked out for change. Parallel working on different versions

136 System building Building a large system is computationally expensive and may take several hours Hundreds of files may be involved System building tools may provide A dependency specification language and interpreter Tool selection and instantiation support Distributed compilation Derived object management

137 Configuration management is the management of system change to software products A formal document naming scheme should be established and documents should be managed in a database The configuration data base should record information about changes and change requests A consistent scheme of version identification should be established using version numbers, attributes or change sets Key points

138 Key points System releases include executable code, data, configuration files and documentation System building involves assembling components into a system CASE tools are available to support all CM activities CASE tools may be stand-alone tools or may be integrated systems which integrate support for version management, system building and change management

139 Методология RUP (Rational Unified Process) - основные принципы Итеративная разработка Управление требованиями Компонентная архитектура Визуальное моделирование Управление изменениями Постоянный контроль качества

140 RUP: фазы ЖЦ и процессы (дисциплины)

141 RUP: 4 фазы жизненного цикла Inception – начало проекта (эскизное проектирование) Elaboration – детализация системы (разработка технического задания) Construction – создание системы (рабочее проектирование) Transition – внедрение системы (приемо- сдаточные испытания)

142 RUP: фазы ЖЦ и процессы Каждая фаза может быть разбита на итерации (итеративный подход). Каждая итерация завершается выпуском работающего прототипа конечной системы. Это позволяет правильно оценивать риски проекта и эффективно снижать или устранять их на ранних стадиях разработки. На вертикальной оси диаграммы представлена статическая структура RUP - процессы жизненного цикла типового проекта или дисциплины RUP

143 RUP: процессы Основные процессы RUP: Бизнес моделирование Управление требованиями Анализ и проектирование Реализация Тестирование Развертывание Вспомогательные процессы RUP: Конфигурационное управление и управление изменениями Управление проектом Управление средой разработки

144 Особенности RUP Для каждого процесса разработки методология RUP определяет ролевой состав проектной команды и описывает регламент действий, потоки событий и получаемые результаты и документы (артефакты процесса). Интегральная интенсивность этих действий в зависимости от времени показана на диаграмме RUP для всех основных и вспомогательных процессов. В отличие от каскадной модели в методологии RUP все процессы выполняются практически во всех фазах жизненного цикла проекта. Однако в зависимости от фазы меняются текущие цели проекта и, соответственно, соотношение между объемами работ, соответствующих различным процессам.

145 Инструменты коллективной разработки IBM Rational

146 Rational Suite: инструменты IBM Rational ClearCase – лучшее в своем классе средство конфигурационного управления IBM Rational ClearQuest - средство для управления запросами на изменения проекта и отслеживание дефектов в проекте IBM Rational ProjectConsole – средство управления проектом, представляет метрики проекта в виде наглядного Web-сайта IBM Rational PurifyPlus – набор средств отладки программного кода IBM Rational Rapid Developer – среда быстрой разработки приложений на платформе J2EE для многозвенной архитектуры IBM Rational RequisitePro – коллективное средство управления требованиями проекта IBM Rational Robot – средство для автоматизированного функционального тестирования приложений IBM Rational Rose - CASE-средство визуального проектирования информационных систем, позволяющее моделировать как бизнес процессы, так и различные компоненты ПО IBM Rational Rose RealTime – средство визуального моделирования и проектирования встроенных систем и систем реального времени IBM Rational SoDA – автоматизация разработки и обновления проектной документации IBM Rational TeamTest – средство для автоматизированного функционального и нагрузочного тестирования приложений IBM Rational TestRealTime – набор средств для автоматизированного тестирования и отладки встроенных систем и систем реального времени IBM Rational TestManager – средство управления задачами функционального и нагрузочного тестирования IBM Rational Unified Process – практическое Web-руководство по методологии программной инженерии и обобщению лучшего мирового опыта в области промышленной разработки ПО.

147 Наборы инструментов Rational Suite IBM Rational Suite Analyst Studio – бизнес-анализ предметной области, управление требованиями, проектирование структуры баз данных IBM Rational Suite Development Studio – проектирование, разработка и отладка исходного кода ПО IBM Rational Suite Development Studio RealTime – проектирование, разработка и отладка встроенных приложений IBM Rational Suite TestStudio – функциональное, регрессионное и нагрузочное тестирование IBM Rational Suite Enterprise – полный набор инструментов для универсалов (не включает продукты семейства Rational XDE) IBM Rational Suite TeamUnifyingPlatform – набор инструментов, объединяющих проектную команду, является основой всех перечисленных выше ролевых наборов.