Tarkvaratehnika 3 variant (0)

 
Сравнить Канбан и Скрам 
Scrumikokkuvõte 
 
The Product Owner   sets  the Product Backlog 
During the Sprint Planning, the Product Owner  
determines a piece of the top of that list –the Sprint Backlog –and decide how to mplement 
itThe Team  has a time-box to  reach this  goal : the sprint 
Each day, the Team  measures  its progress during a 15 minutes  meeting :  
the Daily   Scrum  Meeting 
During the whole project, the Scrum Master ensures that the Team is still focused on its 
objective  
At the end of the Sprint, the completed  work has to be potentially shippable 
 
The Sprint ends with the Sprint Review and the Retrospective. 
The Scrum  process  is completed when all Stories  making up the Product Backlog are 
implemented, or the budget is consumed, or when the time is over. 
 
Kanbani võimalikud eelised Scrumi ees 
 
Lihtsus 
Puudub suurte Backlogide  haldamine  Puudub“time boxing” Sprint Backlogide jaoks 
Puuudub arendamise edukuse hindamine ja mõõtmine 
Scrum  Board is reset between each iteration 
Scrum prescribes crossfunctional teams, while   Kanban   could  have specialised teams 
Scrum backlog items  must fit in a Sprint, while Kanbancan have long  running items 
Kanbandaily meetings focus on changes  on the board, while  
Kanbanfocuses on assignments of each person ( yesterday , today , problems) 
Scrum estimates and measures progress, while this is  optional in Kanban 
 
Scrum более директивный, чем Kanban, поскольку он предусматривает такие вещи, как 
итерации и кросс-функциональные команды. Scrum предписывает наличие 3-х ролей: 
Product Owner (отвечает за видение продукта и приоритеты), Команда (отвечает за 
реализацию продукта) и Scrum Master (устраняет препятствия в работе и руководит 
Scrum-процессом). Kanban же не предписывает вообще никаких ролей, чем меньше, тем 
лучше! Нужен один Product Owner с основной задачей – выставление приоритетов. 
В Kanban-е ограниченные по времени итерации не обязательны, можно выпускать релиз 
каждый понедельник, либо же по реализации какой-нибудь новой крутой фичи. 
Доска в Канбан может никогда не быть пустой во время проекта, в то время, доску Scrum надо 
очищать после каждого спринта.  Доска в Канбан может быть поделена по функциям, а в Scrum 
команды кросс-функциональные. 
 
Клин код 12лоенг 
Correct  english, ne bolshe 3 peremennih, ponjatnie nazvanija, o 4em idet re4, funkcija delaet 
tolko odnu vesh,kommentarii ne nuzni, 
 
Виртулизация virtualiseerimine konfiguratsiooni haldused 
•Arendus mitmele operatsioonisüsteemile  
•Arendus  
• Testimine   
•Erinevatele operatsioonisüsteemidele kompileerimine  
( continuous integration) 
 
Spiral evolution  of software 15loeng 
 
 
Model developing vaatepunktide  raamistik  5 loeng-2 loeng 
Vaatepunkide raamistik: 
 
  Analüüs 
 
Käitumise analüüs  Eesmärgimudelid, tegevus- diagrammid , kasutuslood 
 
 
Interaktsioonide analüüs Konteksti-diagrammid, klassi-diagrammid 
 
 
Struktuuri analüüs Konteksti-diagrammid, klassi-diagrammid 
 
 
 
Siin(bus) architecturemodel +- 6loeng 
 
  Siinipõhise arhitektuuri eelised ja  
  puudused 
 
  Eelised: 
 
  Kommunikatsioon 
 
  Nõrgalt seotud komponendid 
 
  Puudused: 
 
   Single -point-of- failure  
 
 
Funktsionaalsed ja mitte nõuded, 3 priznaka hea nõue 
Functional   requirements  
Kirjeldus, kuidas süsteem peaks käituma  
kasutajapoolsete või teisest süsteemist   
pärinevate sisendite peale 
 
Describe  functionality or system services . 
 
Depend on the type of software,  expected users  
and the type of system where the software is used. 
 
Functional user requirements may be high 
level statements of what the system should  
do.Functional system requirements should describe  
the system services in detail. 
Functional requirements 
 
Statements of services the system should provide ,  
how the system should react to particular inputs and  
how the system should behave in particular  
situations. 
May state what the system should not do. 
 
Non-functional requirements 
These  define system properties and constraints   
e.g. reliability, response time and storage   
requirements. Constraints are I/O device   
capability, system representations, etc. 
Process requirements may also be specified  
mandating a particular 
IDE, programming language or development  method 
 
Non-functional requirements(FURPS+ Functionality Usability reliability 
Performance  Supportability) 
 
Constraints on the services or functions offered by  
the system such as timing constraints, constraints  
on the development process, standards, etc. 
Mayapply to the system as a whole  
aswellastoindividual features or services 
 
Nõude kolm baasomadust: 
Ühene kontrollitavus 
küsimusele „kas nõue on täidetud?“ peab saama võimalikult üheselt vastata “jah”  
või “ei” 
Kerge kontrollitavus  
nõude kontroll ei tohi võtta  
palju aega 
Sõnastuse lihtsus ja lühidus nõude  sisutekst ei  
tohiks olla pikem kui ~30 sõna 
 
 
 
 
 
 
4 sotware engineer objazannosti 1loeng 49 
Professionaalse vastutuse aspektid 
 
Konfidentsiaalsus   
 
Tarkvarainsener peab respekteerima oma  
tööandja  ja klientide konfidentsiaalsust, sõltumata sellest, kas  formaalne  leping 
konfidentsiaalsuse kohta on alla kirjutatud 
Kompetents  
 
Tarkvarainsener ei tohi anda väära ettekujutust oma kompetentsist. Ta ei tohi võtta 
teadlikult vastu tööd, mis on väljaspool tema kompetents 
Intellektuaalne omand  
Tarkvarainsener peab olema teadlik kohalikest seadustest ja määrustest, mis sätestavad  
intellektuaalse omandi kasutamise näiteks patentide ja kopeerimisõiguse näol. Ta peab olema 
ettevaatlik, et tööandjate ja klientide intellektuaalne omand oleks  
kaitstud 
Arvuti väärkasutus 
Tarkvarainsener ei tohi kasutada oma tehnilisi oskusi teiste inimeste arvutite 
väärkasutamiseks. Väärkasutus katab vahemiku suhteliselt triviaalsest (näiteks mängude 
mängiminetööandja  arvutil ) kuni äärmiselt tõsiseni (viiruste levitamine ja teiste arvutite 
ründamine) 
 
RUP  Rational Unified Process 
Rational Unified Process (RUP) — методология разработки программного обеспечения, созданная 
компанией Rational Software., итеративная модель разработки. В конце каждой итерации (в идеале 
продолжающейся от 2 до 6 недель) проектная команда должна достичь запланированных на 
данную итерацию целей, создать или доработать проектные артефакты и получить 
промежуточную, но функциональную версию конечного продукта. Полный жизненный цикл 
разработки продукта состоит из четырех фаз, каждая из которых включает в себя одну или 
несколько итераций: 
RUPi faaside selgitused  
Inception: äriline analüüs В фазе начальной стадии: 
  Формируются видение и границы проекта. 
  Создается экономическое обоснование (business case ). 
  Определяются основные требования, ограничения и ключевая функциональность 
продукта. 
 
 
Elaboration: nõuete analüüs, arhitektuuriline  
disain , arendusplaan В фазе «Уточнение» производится анализ предметной области и 
построение исполняемой архитектуры. Это включает в себя: 
  Документирование требований (включая детальное описание для большинства 
прецедентов). 
  Спроектированную, реализованную и оттестированную исполняемую архитектуру. 
 
 
Construction : detailne kavandamine,  
realiseerimine ja testimine 3. Построение (Construction) 
В фазе «Построение» происходит реализация большей части функциональности продукта 
 
 
Transition: süsteemi käitamine 4. Внедрение (Transition) 
В фазе «Внедрение» создается финальная версия продукта и передается от разработчика к 
заказчику.  
 
4 test levels 
Unit  test( module  test, verify  the functionality of a specific section  of code), Integration testing (verify 
the  
interfaces between  components  against a software design), System testing( testing a completely 
integrated   
system to verify that it meets its requirements), Acceptance testing(testing  delivered to user) 
Waterfall gde nuzno naiti owibku 2loeng 9 
Tarkvaraprobleemi lahendamine varajastes disainietappides on on 100  
korda odavam kui... 
 
Extreme programming XP 
short iterations(1-2 weeks), short  release  cycles(1-2 months),user stories(customer perspective), 
customer  
sets priorities( can and will always change ), co-located team(open workspace), customer is always  
available ( active communication), daily stand-up meetings(developers sign up for stories), pair   
programming(all  production code is pair programmed), continuous learning(take time to improve  
team's  
skills ), retrospective( look   back  and improve) 
3 вещи в рукводстве проекта(?)3 фактора при разработке квалитетного ПО 
Too välja 3 kvaliteetse tarkvarasüsteemi  atribuuti (üks kliendi, üks arendaja, üks äri vaatest) ning  
selgita, kuidas nad mõjutavad arhitektuurilise kavandamise valikut. 
Hooldatavus:  Tarkvara peab arenema, et vastata muutuvatele vajadustele;  Usaldusväärsus : Tarkvara peab  
olema töökindel; Efektiivsus: Tarkvara ei tohi raisata süsteemi ressursse; Vastuvõetavus: Tarkvara peab 
olema  
aktsepteeritud kasutajate poolt, kelle jaoks ta on loodud. See tähendab, et tarkvara peab olema arusaadav,  
kasutatav ja ühilduv teiste süsteemidega