Презентацията се зарежда. Моля, изчакайте

Презентацията се зарежда. Моля, изчакайте

Методология на разработката

Сходни презентации


Презентация по темата: "Методология на разработката"— Препис на презентация:

1 Методология на разработката
Качествен програмен код изборен курс към ФМИ на СУ, летен семестър, 2004/2005 г. За коментари и препоръки: Николай Манчев nikolay.manchev at devbg.org nick at manchev.org Copyright (c) 2005 Nikolay Manchev. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License". Управление на процеса на конструиране на кода

2 План на темата Осигуряване качество на кода Управление на промените
Изграждане на график Статистика за проекта Отношение към хората Управление на по-висшестоящите

3 Осигуряване качество на кода
Поне двама души работят по всяка отделна част в проекта Разработчиците преглеждат взаимно кода си Кодът се подписва Добрия код се показва на всички Съществено значение за успеха на един проект играе качеството на кода му. Схемите, които помагат за поддържането на качествено ниво на кода са както следва: Поне двама души работят по всяка отделна част в проекта – Така и поне двама са се уверили, че кодът работи коректно. Разработчиците преглеждат взаимно кода си – Преглеждането на кода обикновено изисква двама проверяващи за работата на всеки програмист. Така поне трима души четат кода, а и пишещият се съобразява и генерира по-четлив код. Кодът се подписва – Честа практика в някои компани : Преди кодът да се приеме, той се подписва от старши програмист, който го е прегледал и смята, че е чист и без грешки. Добрия код се показва на всички – Едно добре направено решение на даден проблем може да се публикува или разпрати до всички разработчици. Така се показва търсеното качество и се дава пример, който другите да следват.

4 Осигуряване качество на кода
Трябва да е ясно, че кодът принадлежи на всички разработчици Добрият код носи награди Съществува единен стандарт Трябва да е ясно, че кодът принадлежи на всички разработчици - Кодът не е собственост на програмиста. Той трябва да е достъпен за неговите колеги, а не те да преоткриват колелото, защото нямат достъп до вече решени проблеми. Добрият код носи награди – Разработчиците могат да получават награди за добре свършена работа. Важно е обаче, човекът който ги награждава да има авторитет пред тях. Наградата трябва да се дава по точни критерии. Лоша практика е, най-лошият програмист да получи награда за добра работа, само защото идва навреме в офиса. Съществува единен стандарт – Стандартен трик е, вие като мениджър да се декларирате, че не разбирате сложен код. По този начин, всички ще са принудени да пишат чисто.

5 План на темата Осигуряване качество на кода Управление на промените
Изграждане на график Статистика за проекта Отношение към хората Управление на по-висшестоящите

6 Какво е “Управление на промените”
Оценка на предложените промени в системата Следене на извършени в миналото промени Възможност, системата да бъде върната във състоянието, в което била преди дадена промяна

7 Названия Концепцията за управление на промените е известна под няколко имена: Change Control Configuration Management SCM – Software Configuration Management

8 Управление на промените
Над 30% от програмистите не разбират концепцията за Управление на промените Под 20% от компанните, разработващи софтуер имат адекватна система за Управление на промените

9 Изисквания и промени в дизайна
Трябва да има единна процедура за контрол на промените Добре е промените да се организират в групи Всяка промяна има цена – тя трябва да се оцени правилно Трябва да се внимава, когато възникне нужда от много промени Трябва да има единна процедура за контрол на промените – Когато броят заявки за промяна нарастне, добре е те да са организирани, за да може всяка промяна да се разглежда в контекст. Добре е промените да се организират в групи – Една не много съществена промяна може да се извърши, когато проекта на 25%. Друга, много по-съществена промяна може да се пропусне, когато проектът е напреднал (например на 80%). Всички идеи за променя трябва да се документират и да се оценяват по-важност. Всяка промяна има цена – тя трябва да се оцени правилно – Когато клиент или колега поиска промяна, трябва да се направи внимателна оценка на цената й. Факторите, които трябва да се разгледат са : извършване на промяната, преглед на кода, тестване, промяна на документацията и разбира се – странични ефекти, които могат да окажат влияние по другите нива на проекта (дори и самата архитектура). Трябва да се внимава, когато възникне нужда от много промени – Това може да е индикация за грешка в изискванията и/или дизайна. Понякога е по-добре тази грешка да се коригира (въпреки цената й), отколкото цялото приложение да се пренаписва няколко пъти в последствие.

10 Изисквания и промени в дизайна
Добре е да се организира Група за контрол на промените Трябва да се внимава с бюрокрацията около промените Добре е да се организира Група за контрол на промените – Групата получава всички заявки за промяна и оценява кои са важни и кои не. Обикновено групата се формира от няколко души, които си организират периодични срещи за обсъждане на предложните промени. По този начин, промените се държат консистентни и техните последващи ефекти могат да бъдат оценявани от няколко души. Трябва да се внимава с бюрокрацията около промените – Липсата на адекватно управление на промените е един от най-големите проблеми в съвременните софтуерни компании. Една утежнена процедура по контрол на промените е толкова лоша, колкото и изобщо липсата на процедура. Въпреки това, страха от бюрократщината, не трябва да отказва никой от имплементирането на система за управление на промените.

11 Система за контрол на версиите
Няколко души могат да работят върху едни и същи части на системата Всеки разработчик лесно актуализира копието, върху което работи Всяка версия, на всеки файл е достъпна по всяко време За управление на промените в кода, обикновено се използва Система за контрол на версиите. Съществуват множество продукти, които реализират тази функционалност, както комерсиални (Microsoft Visual Source Safe), така и безплатни (CVS).

12 Система за контрол на версиите
По всяко време може да се получи списък с промените направени за всеки файл Не е нужно разработчиците да се грижат за backup-и

13 План на темата Осигуряване качество на кода Управление на промените
Изграждане на график Статистика за проекта Отношение към хората Управление на по-висшестоящите

14 Планиране и графици Статистиката показва, че всеки софтуерен проект закъснява средно с около година от планирания график и надхвърля бюджета си с над 100%

15 Как да планираме - подходи
Софтуер за планиране Алгоритъм за планиране Външни консултанти Оценка на компонентите и обединяване на резултата Индивидуална оценка и обобщение Софтуер за планиране – Голяма част от системите за управление на софтуерни проекти имат такива възможности. Алгоритъм за планиране – Съществуват модели, чрез които може да се правят предварителни оценки (например Cocomo II и Boehm’s estimation model). Външни консултанти – Има експерти, които специализират в оценката и планиране на софтуерни проекти. Те могат да бъдат наети като външни консултанти. Оценка на компонентите и обединяване на резултата – Екипа прави приблизителна оценка за всеки един компонент и обединява резултата. Обратната методология също е приложима. Индивидуална оценка и обобщение – Всеки разработчик оценява нужното му време индивидуално, а на базата на тези оценки се прави общото планиране на проекта.

16 Как да планираме - подходи
Опит от предишни проекти Обновяване на вече използвани модели Опит от предишни проекти – Ако подобен проект е правен преди, той може да послужи за база. Обновяване на вече използвани модели – Ако е използвана методология за оценка и планиране, която се е оказала добра за предишен проект, то може би тя може да бъде адаптирана и за следващи проекти.

17 Как да планираме - насоки
Ясни очаквания Планиране на време за планиране Точни очаквания за софтуера Оценка в детайлност Използване на разнородни техники за оценка Ясни очаквания – Колко точно трябва да е планирането, за да отговораря на нуждите ни? Колко сигурни трябва да сме, че планирането е вярно? Планиране на време за планиране – Прибързаното планиране, не е планиране. Ако правим оценка на голям проект, по-добре да разглеждаме самото планиране като отделен, цялостен проект. Точни очаквания за софтуера – Никой не може да направи вярно и точно планиране “по принцип” или за “един голям проект”. Всичко свързано с поректа, трябва да е точно и прецизно дефиниране. Оценка в детайлност – Колкото по-детайлно е направено планирането, толкова по-точно е то. Навлизане в проекта и оценка на дребните детайли е добра практика, нищо че отнема повече време. Използване на разнородни техники за оценка – Един проект може да се оцени по няколко различни техники, след което резултатите да бъдат сравнени. Ако се използват три подхода, при което два дадат близки резултати, а третият силно се разминава спрямо тях, вероятно може да се направи извода, че някъде в третия подход има грешка.

18 Фактори, влияещи върху планирането и оценяването
+ - Качество на програмистите -24% 34% Опит на екипа в дадената област -19% 22% Сработеност на екипа -10% 11% Текучество на персонала 20% Документация на проекта 23% Други важни фактори са : мотивация на екипа, качество на мениджмънта, качествени отношения с клиента, участие на клиента в проекта, опит с езика за програмиране и инструментите му, сложност на самия продукт, изисквана надеждност за продукта, изисквания за преизползваемост на компонентите и т.н.

19 Ако изостанем от плана Какво да правим, ако изостанем от графика?
Статистиката показва, че плановете подценяват нужното време средно с 20÷30%

20 Ако изостанем от плана Компенсация на закъснението
Разширяване на екипа Съкращаване на изискванията Компенсация на закъснението – Никога не се случва. Изследване върху 300 софтуерни проекта показва, че с напредване на проекта, закъснението единствено се увеличава. Разширяване на екипа – Не помага, всъщност даже води до по-голямо закъснение. Новите хора се нуждаят от обучение, за да навлязат в проекта и обикновено вече работещите трябва да ги обучават, което губи много от времето им и като цяло общата продуктивност спада. Съкращаване на изискванията – Най-добрия начин за наваксване на закъснението. Ако се премахне един компонент, то натоварването спада не само за конструиращите кода, но и за дизайнери, тестери, хора пишещи документация и т.н. Именно по тази причина е добре още в началото да се дефинира кои изисквания са задължителни, кои е добре да присъстват и кои са опционални. По този начин, в последствие лесно могат да се премахнат някои от тях, които няма да влиаят сериозно на проекта.

21 План на темата Осигуряване качество на кода Управление на промените
Изграждане на график Статистика за проекта Отношение към хората Управление на по-висшестоящите

22 Статистика за проекта Липсата на статистика за проекта е липса на идея какво се случва с проекта като цяло Принципно могат да се измерват всякакви аспекти на проекта. Обикновено, различните характеристики се групират, според аспекта върху който влиаят – големина, качество, продуктивност, леснота на поддръжка, дефекти и т.н. Съществуват редица инструменти, които могат да направят такава статистика автоматично.

23 Измерване големината на проекта
Редове код Редове коментари Брой класове и методи Брой декларации Брой празни редове

24 Оценка на качеството Общ брой грешки Брой грешки на клас или метод
Брой грешки на реда код MTBF Грешки докладвани от компилатора

25 Продуктивност Часове работа върху проекта
Часове работа върху всеки клас/метод Брой преправяния на метод Разходи по проекта Цена на ред код Цена за поправяне на грешка

26 Леснота на поддръжка Брой public променливи за всеки клас
Брой параметри предавани на всеки метод Брой декларации за клас/метод Брой методи извиквани от други методи или класове и т.н.

27 Проследяване на грешките
Тежест на всяка грешка Място на възникване на грешка (клас, метод) Произход на грешката (код, дизайн, изисквания и т.н.) Програмист, отговорен за грешката Брой грешки, възникващи от корекция на грешки и т.н.

28 Създаване на статистика - насоки
Няма смисъл да се следят всички възможни показатели Статистиката се прави с цел Пикове в статистическите параметри за един метод или клас, обикновено показват проблем в реализацията му

29 План на темата Осигуряване качество на кода Управление на промените
Изграждане на график Статистика за проекта Отношение към хората Управление на по-висшестоящите

30 Отношение към хората Как програмистите прекарват времето си?

31 Разпределение на времето в проценти
Дейност Код По работа Лично Сре-щи Обучение Поща Техн. Документация Дискусия 4 17 7 3 Разгвор с мениджър 1 Телефон 2 Четене 14 Писане 13

32 Разпределение на времето в проценти
Дейност Код По работа Лично Сре-щи Обучение Поща Техн. Документация Навън 4 1 6 Ходене 2 Други 3 Общо 35 29 13 7 5

33 Любопитно Програмистите прекарват във ходене толкова време, колкото отделят за обучение

34 Производителност Мащабни изследвания в разработката на софтуер показват, че 80% от работата се извършва от 20% от работещитете по проекта програмисти Тези 20% са най-квалифицираните служители участващи в проекта

35 Извод По-добре да се наемат малко, но високо квалифицирани хора, вместо много с по-ниска квалификация

36 Друг фактори Програмистите са силно религиозни

37 Друг фактори Програмистите са силно религиозни. Сред тях непрекъснато възникват спорове на религиозна основа. Например...

38 Спорни теми... Език за програмиране Отмествания на кода
Място на скобите Избор на IDE Стил на коментарите Ефикасност срещу лесна четимост

39 ...и още спорни теми Методология Използвани инструменти
Конвенции за имената Употреба на goto Глобални променливи Статистика за продуктивността

40 Опасна зона! Опитите за контрол над програмистите по тези теми трябва да са много внимателни По добре е да се правят “предложения”, вместо да се налагат “правила”

41 Опасна зона! По-добре програмистите да се разберат сами. Дори собствено измисления стандарт е по-добър от липсата на какъвто и да е стандарт Опитите за насилствено налагане на решния по темите водят единствено до проблеми в проекта

42 Условия за работа Проведени изследвания показват, че разработчиците, които присъстват в TOP 25% по продуктивност имат по-големи, спокойни и комфортни работни места

43 Влияние на работното място върху качеството на работа
Условия Най-добри Най-лоши Пространство 78 кв. м. 46 кв. м. Тихо ли е работното място? 57% 29% Спокойно ли е? 62% 19% Може ли да се изключва телфона? 52% 10% Може ли да се пренасочва? 76% Има ли много безмислени прекъсвания от колеги? 38% Работното място кара ли служетля да се чувства “оценен”? Таблицата показва отговорите “ДА” от TOP 25 процентa за “най-добри” и BOTTOM 25% за “най-лоши” по критерий производителност.

44 Извод Подобряването на работното място на служителя увеличава неговата продуктивност с най-малко 100%

45 План на темата Осигуряване качество на кода Управление на промените
Изграждане на график Статистика за проекта Отношение към хората Управление на по-висшестоящите

46 Мениджъри Технически грамотен мениджър е рядко срещано явление.
В стандартната ситуация, трябва да се развие изкувство за “управление на мениджъра”

47 Методи за управление Решението се дава на малки порции, за да може мениджърът да го “открие” сам Мениджърът се обучава, как да се правят нещата Решението се дава на малки порции, за да може мениджърът да го “открие” сам – Или познатата одавна стратегия “При шефа се влиза с моите идеи, а се излиза с идеите на шефа”. Мениджърът се обучава, как да се правят нещата – Много дълъг и сложен процес, но най-добрия в дългосрочен план. За беда, мениджърското място е много “ветровито” – тях непрекъснато ги повишават, преместват, уволняват и т.н.

48 Методи за управление Енкапсулацията е добър подход в комуникацията с мениджъра Грубата съпротива рядко води до добри резултати Ако нищо не помогне, смяната на работата винаги остава като възможност

49 Въпроси?


Изтегли ppt "Методология на разработката"

Сходни презентации


Реклама от Google