Inxhinieri Softwerike, 2

Inxhinieria Softuerike
Agile Software Development-Modelet Softuerike

FAKULTETI: SHKENCA KOMPJUTERIKE DHE INXHINIERI
Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 1

Topics covered
Agile methods
Agile development techniques
Agile project management
Scaling agile methods

Kopjimi me ndryshimin

Kopjimi me ndryshimin (1)
Ndryshimi është i pashmangshëm në të gjitha projektet e mëdha të softuerit.
oNdryshimet e proceseve të biznesit çojnë në nevojen për kërkesa të reja dhe të ndryshuara
të sistemit
oTeknologjitë e reja hapin mundësi të reja për përmirësimin e implementimeve
oNdryshimi i platformave kërkon ndryshime të aplikacioneve
Ndryshimi çon në ri-punimi kështu që kostot e ndryshimit përfshijnë si ri-
punimi (p.sh. ri-analiza e kërkesave), si dhe kostot e implementimit të
funksionaliteteve të reja
30/10/2014 CHAPTER 2 SOFTWARE PROCESSES 4

Kopjimi me ndryshimin (1)
Janë dy qasje për uljen e kostos në ri-punim:
1. Shmangja e ndryshimit – dergon prototip dhe e hedh
2. Toleranca ndaj ndryshimeve – zhvillim rrites
Ekzistojnë dy lloje kryesore të kopjimit me ndryshim:
1. Modeli: Prototipimi i sistemit
2. Modeli: Dorëzimi inkremental

Reduktimi i kostove të ri-punimit
Secili ndryshim sjellë shpenzime të reja në ndërtimin e softuerit pasi që shpesh ndryshimi
nënkupton ri-bërjen e punës. Për këtë ekzistojnë dy qasje për uljen e shpenzimeve gjatë ri-
punimit së zhvillimit
1. Parashikimi i ndryshimeve, ku procesi i softuerit përfshin aktivitete që mund të parashikojnë
ndryshime të mundshme para se të kërkohet ri-përpunimi i rëndësishëm.
Për shembull, një sistem prototip mund të zhvillohet për të treguar disa karakteristika kryesore të sistemit për
klientët.
2. Toleranca ndaj ndryshimeve, ku procesi është projektuar në mënyrë që ndryshimet të mund të
vendosen me kosto relativisht të ulët.
Ky procesi softuerikë është i dizajnuar të akomodojë ndryshimet me shpenzime sa më të vogla. Kjo qasje
përfshinë disa forma të zhvillimit rritës (inkremental)

Modeli i Krijimi të prototipit (1)
Prototipi paraqet një version inicial të një sistemi softuerikë që përdoret për të
demonstruar koncepte, duke përdorë opsionet themelore dhe duke zbuluar problemet
dhe zgjidhjet e mundshme.
Zhvillimi i shpejtë ri-përsëritës i prototipit është esencial për zvogëlimin e
shpenzimeve të ri-bërjes së zhvillimit.
Prototip mund të përdoret/ndihmojë në:
o Në procesin e inxhinierisë së kërkesave dhe validon kërkesat e sistemit ;
o Në procesin e dizajnimit të sistemit, dhe për të analizuar zgjidhjen përkatëse të softuerit dhe të
ndihmojë dizajnin e ndërfaqes (interface-UI);
o Në procesin e testimit për të ekzekutura testet një-pas-një.

Procesi i krijimit të prototipit

Përparësitë e modelit të krijimit të prototipimit
Përmirësimi i cilësisë së dizajnimit
oIde të reja për zhvillim.
oNjë nderlidhje më e afërt me nevojat reale të përdoruesve.
oIde të reja për dizajn
Përmirësimi në mirëmbajtje të sistemit.
Kohë më të vogël për trajnim (Redukton përpjekje në zhvillimit).
30/10/2014 CHAPTER 2 SOFTWARE PROCESSES 9

Hedhja e prototipit
Zhvilluesit shpesh janë të detyruar të krijojnë prototipa që në fund duhet të hidhen
pasi që duhet të ripunohen.
o Kjo bëhet për arsye të vonesave gjatë projektit.
o Por kjo zakonisht është e pamatur për arsye se:
Pamundëson prototipin të përshtat kërkesave jo-funksionale si përformanca, siguria,
përshtatshmëria etj.
Nuk ka kohë për dokumentimin e ndryshimeve të shpejta dhe të shpeshta
Prishet struktura e sistemit gjatë ndryshimeve
Relaksimit të standardeve të organizatës për zhvillim të softuerit.

Modeli: Dorëzimi rritës (inkremental)
Dorëzimi rritës paraqet një qasje të zhvillimit të softuerit ku disa nga funksionet e
zhvilluara i dorëzohen klientit për përdorim.
o Në këtë proces klienti identifikon funksionet dhe i radhit ato në mënyrë që të zhvillohen sipas
radhës.
o Gjatë zhvillimin çdo funksion që ndryshon ndikon në zhvillimin e funksionit tjetër dhe në këtë mënyrë
i paraprin ndryshimeve të funksioneve të zhvilluara.
Çdo version posedon funksionet paraprake të modifikuara dhe përshtatura. Po

ashtu ndryshimet e kërkuara përfshihen në funksionet që janë në zhvillim ende pa fillua
zhvillimi

Modeli: Dorëzimi rritës (inkremental)

Dorëzimi rritës (inkremental):
Përparësitë
Klientët mund të përdorin versionet e para si prototip dhe të fitojnë eksperience që
të mundeson zhvillimin e mëtejshëm të kërkesës.
o Ndryshe nga prototipi këto versione janë pjese e sistemit real dhe për këtë arsye nuk ka ri-mësim
pasi që sistemi ka filluar të përdoret me versionet fillestare.
Klientët nuk duhet të presni derisa i tërë sistemi është implementuar para se ata
mund të përfitojnë vlerë prej tijë.
o Verzioni i parë përmbush kërkesat e tyre më të rëndësishme në mënyrë që ata mund të përdorin
softuer menjëherë.

Përparësitë e Dorëzimi rritës (inkremental):
Vlera arritet duke implementuar gjëgjsisht dorzuar funksionet e sistemit në form
rritëse, kështu që funksionaliteti i sistemit është i disponueshëm më herët si rrjedhoj
rrite vlerën për kosumatorin në form periodike.
Funksionet e sistemit sipas konceptit rritës në fazat e hershme veprojë si një prototip
për të ndihmuar nxjerrë e kërkesave për fazat e më vonëshme rritëse.
Rrezik më të ulët të dështimit të projektit në përgjithësi.
Shërbimet e sistemit me prioritet më të lartë tentohët të kenë testimin më të theksuar.

Mangësitë e Dorëzimi rritës (inkremental
Meqë kërkesat nuk janë përcaktuar në detaje përderisa një versionion është
implementuar , mund të jetë e vështirë të identifikohen lehtësishtë nevojat e
përbashkëta që nevojiten nga të gjitha verzionet.
Thelbi i proceseve iterative është se specifikimi është zhvilluar në bashkëpunim
me softuerin.
Megjithatë, kjo bie ndesh me modelin e prokurimit të shumë organizatave, ku
specifikimi i plotë i sistemit është pjesë e kontratës së zhvillimit të sistemit.

Modeli spiral i Boehm-it
Modeli i spiralës, është një model i zhvillimit të sistemeve (SDLC) që përdoret në
teknologjinë e informacionit (IT).
Ky model i zhvillimit kombinon natyre iterative të modelit prototipit dhe modelit
ujëvarë. Modeli spiral është i favorizuar për projekte të mëdha, të shtrenjta dhe të
ndërlikuara.
 Kur të përdorim modelin spiral:  Përparësitë e modelit spirale:
o Kur vlersohet kostoja dhe rrezikut është i o Feedback të hershme dhe të shpeshta nga
rëndësishëm. përdoruesit
o Kur krijimi i një prototipi është i përshtatshëm o Përdoruesit e shohin sistemin herët për shkak të
o Kërkesat janë komplekse të krijimit të prototipeve
o Për projeket nga rrisku mesëm në të lartë o Ofron tregues të hershëm të rreziqeve.
o Priten ndryshime të rëndësishme/të mëdha o Përdoruesit mund të jetë i lidhur ngushtë me të
o Përdoruesit janë të pasigurt për nevojat e tyre gjitha hapat e ciklit të jetës
Modeli spiral i Boehm-it
Modeli spiral i
Boehm-it

Modeli: RUP-Procesi i Unifikuar Racional (1)
Modeli Racional i Unifikuar (The Rational Unified Process - RUP))(Krutchen, 2003) është një
shembull i procesit modern, i cili ka derivuar nga puna në UML dhe lidhet me Procesin e
Unifikuar të Zhvillimit të Softuerit (Rumbaugh, et al., 1999; Arlow and Neustadt, 2005).
Paraqet një model hibrid që sjellë elemente nga të gjitha proceset gjenerale duke përfshi
praktikat e mira të krijimit të prototipit dhe dorëzimit rritës
RUP pranon që proceset konvecionale parqyrojnë procese nga një këndvështrim.
RUP tenton që të përshkruaj proceset nga tre përspektiva:
1. Një perspektivë dinamike, e cila tregon fazat e modelit me kalimin e kohës.
2. Një perspektivë statike, e cila tregon aktivitetet e procesit që janë miratuar.
3. Një perspektivë praktike, e cila sugjeron praktika të mira që do të përdoren gjatë procesit.

Fazat e modelit RUP
Inception (Zanafilla), ka për qëllim të vendos rastin e biznesit për sistemin. Gjatë kësaj faze
identifikohen entitetet e jashtme (njerëzit dhe sistemet) që do të ndër veprojnë me sistemin që po
e ndërtojmë
Elaboration (Përpunimi), ka për qëllim të kuptuarit e problemit, krijimin e arkitekturës së
sistemit dhe krijimin e planit të zhvillimit
Construction (Ndërtimi), është fazë ku dizajnohet, programohet dhe testohet sistemi
Transition (Trazicioni) është faza finale e RUP ku produkti kalon në shfrytëzim

Fazat e modelit RUP

Zhillimi i sipas modelit Agile

Çështjet me proceset e modeleve tradicionale
Issues With Traditional Processes
Sa kohë keni nevojë për ta përfunduar këtë?
o Vlerësimi i bazuar në asnjë të dhënë
o Pyetje pa përgjigje
Analiz  Dizajn  Implementim

o analiza dhe dizajni paraprakisht kërkojnë shumë kohë
o jo kohë të mjaftueshme për implementim
"Unë dua që kjo veçori shtesë të shtohet!"

o nuk ka kohë për të (këtë veqori)
o shkatërron dizajnin “perfect”

Zhvillimi i shpejtë (Rapid) i softuerit
Zhvillimi dhe zbatimi i shpejtë tani është shpesh kërkesa më e rëndësishme për
sistemet softuerike
o Bizneset operoj në ndryshimet të shpejtë/shëpershta të kërkesë dhe është praktikisht e pamundur të
prodhohet një grup i kërkesave të qëndrueshme të softuerit
o Softueri duhet të evoluojë shpejt për të reflektuar ndryshimet e nevojave të biznesit.
 Zhvillimi sipas model i drejtuar-në-planifikim është thelbësor për disa lloje të

sistemit, por nuk i plotëson këto nevoja të biznesit të sotshëm
Metodat e zhvillimit Aiglie u shfaqën në fund të viteve 1990, qëllimi i të cilave ishte
reduktimi rrënjësor i kohës së dorëzimit për sistemet softuerike.

Ç’ka është Agjiliteti?
Zhvillimi i Agile (shkathët): përgjigjet shpejt nevojave për
ndryshim
oModelet e biznesit nuk do të presin 6 muaj për implementim
oKushtet e tregut ndryshojnë me shpejtësi, duhet të reagojmë
shpejt

Zhvillimi i sipas modelit Agile (shkathët)
Specifikimi, dizajni dhe zbatimi i programit janë të ndërthurura
Sistemi është zhvilluar si një seri versionesh/rritës me palët e interest të
përfshir në specifikimin dhe vlerësimin e versionit
Prodhimi i shpeshtë i versioneve të reja për vlerësimin
Mbështetje e gjërë e mjeteve (p.sh. veglat e automatizuara të testimit) që
përdoren për të mbështetur zhvillimin.
Dokumentacion minimal - përqëndrimi në punën e kodimit.

Zhvillimi sipas modelit të:
drejtuar-në-planifikim dhe Agile
Zhvillimi sipas modelit:

drejtuar-në-planifikim dhe
Agile

Metodat e modelit Agile

Karakteristikat e Metodave Agile
Pakënaqësia me humbjet e përgjithshme të përfshira në metodat e dizajnimit të
softuerit të viteve 1980 dhe 1990 çun në krijimin e metodave të shkathëta (agile).
Këto metoda:
oFokusimi është në kodim sesa dizajnim
oJanë të bazuara në një qasje iterative (përsëritëse) të zhvillimit të softuerit
oKanë për qëllim për të ofruar softuerin që punon shpejt dhe për ofruar evulimin e shpejt të
sistemit duke pasur parasysh në ndryshimet të paraqituran në kërkesat e biznesit.
Qëllimi i metodave agile është të zvogëlojë humbjet e përgjithshme në procesin
e softuerit (p.sh. duke kufizuar dokumentacionin) dhe të jetë në gjendje t'i përgjigjet
shpejt ndryshimeve të kërkesave pa i përseritje të tepruar të puneve.

Manifesti Agile
(Agile manifesto)
Ne po ofrojmë mënyra më të mira për zhvillimin e softuerëve dhe duke e bërë këtë po ashtu duke
ndihmuar të tjerët të bëjë sistemin softuerike. Përmes kësaj pune kemi afruar vlerë:
oIndividët dhe ndërveprimet/ndërkomunikimi mbi proceset dhe mjetet
 Individuals and interactions over processes and tools
oSoftuer që Punon(Softuer funksional) mbi dokumentacionin gjithëpërfshirës (plotë)

 Working software over comprehensive documentation
oBashkëpunimi me klientët mbi negocimi i kontratës

 Customer collaboration over contract negotiation
oDuke iu përgjigjur ndryshimit mbi permbajtja në një plan

 Responding to change over following a plan
Kjo është, përderisa artikujt (shprehjet) në të djathtë kan vlera, ne vlerësojmë artikujt në të majtë më
shumë

12 parime të zhvillimit Agile (2)
1.Prioriteti më i lartë: të kënaqim klientin përmes ofrimit të hershëm dhe të
vazhdueshëm të softuerit funksional.
o Klientët janë më të lumtur kur marrin softuerin (aplikacionin) në intervale të rregullta, në vend që të presin periudha
të zgjatura kohore mes verzioneve.
2.Duke mirëpritur ndryshimin e kërkesave
o Aftësia për të shmangur vonesave, kur një kërkesë apo funksion kërkon ndryshime. ‘edhe në fund të projektit!’
3.Dorëzim të shpesht të softuerit (aplikacionit) për përdorim
o 2-8 javë, 2 është e preferueshme. Scrum akomodon këtë parim marrë parasysh që ekipi operon në sprinte ose
iteracionet që sigurojnë ofrimin e rregullt të aplikacionve për zbatim.
4.Klienti dhe zhvilluesit: punojnë së bashku çdo ditë gjatë gjithë projektit
o Vendime më të mira arrihen kur ekipi i biznesit dhe ai teknik janë afër.

5. Ndërtimi i projekteve rreth individëve të motivuar:
o t'u japë atyre hapësirë/mjete dhe mbështetjen;
o t'u besoni atyre në kryejnë e punës
6.Theksim të veqant të ndërveprimeve/komunikimit ballë-për-ballë
o metoda më efikase dhe më e efektshme e përcjelljes së informacionit në dhe brenda një ekipi të zhvillimi
është biseda ballë për ballë.
7.Softueri funksional: matja primare e progresit.
o Ofrimi i softuerit funksional për klientin është fakti përfundimtar që mat progresin.
8.Proceset Agile nxisin zhvillimin e qëndrueshëm. Sponsorët, zhvilluesit, dhe përdoruesit duhet
të jetë në gjendje të mbajë një ritëm konstant një kohë të pacaktuar.

9. Përsosmëri teknike dhe dizajn i mirë:
o rrit agilitetin
10. Thjeshtësia është thelbësore:

o duke maksimizuar sasinë e punës që nuk është bërë
11. Ekipet vetë-organizuar prodhojë arkitektur/kërkes/dizajn më të mire.

12. Ekipi reflekton se si të bëhet më efektiv
o Bëgetë në intervale të rregullta, për të u përshtatur sipas nevojës.

Parimet e metodave Agile (të shkathëta)
The principles of agile methods
Parimet (Principle) Përshkrimi
Përfshirja involvimi e Klientët duhet të përfshihen nga afër gjatë gjithë procesit të zhvillimit. Roli i tyre është
klientit sigurimi dhe prioritizimi i kërkesave të reja të sistemit dhe vlerësimi i iteracioneve të
Customer involvement sistemit.
Drozim rritës Softueri është zhvilluar në vazhdimisi në rritje me specifikat e kërkesave të klientin që
Incremental delivery duhet të përfshihen në çdo rritje.
Njerëzit jo proceset Aftësitë e ekipit të zhvillimit duhet të njihen dhe të shfrytëzohen (eksploatuar). Anëtarët e
People not process ekipit duhet të lihet për të zhvilluar mënyrat e tyre të punës pa përshkruese të proceseve.
Përqafo ndryshimin Ju prisni qe kërkesat e sistemit do të ndryshojn dhe kështu të dizajnoni sistemin të till për
Embrace change të akomoduar këto ndryshime.
Përqëndrohuni në thjeshtësinë në të dyja si në programet që po zhvillohen dhe procesin
Ruaje thjeshtësinë e zhvillimit. Kudo që është e mundur, punoni në mënyrë aktive për të eleminuar
Maintain simplicity
kompleksitetin nga sistemi.

Zbatueshmëria e Metodave Agile
Agile method applicability
Metodat Agile janë treguar shumë të suksesshme për disa lloje të zhvillimit të sistemit:
1. Zhvillimi i produktit ku kompania softuerike zhvillon një produkt të vogël ose
mesëm për ta shitur.
a) Pothuajse të gjitha produktet dhe aplikacionet e softuerëve tani janë zhvilluar duke përdorur një
qasje agile
2. Zhvillimi i softuerit specifik brenda organizatës, ku ka një angazhim dhe zotim të

klientit për tu përfshirë në procesin e zhvillimit

Teknika e zhvillimit Agile

Teknika e zhvillimit Agile
"Zhvillimi i Agile" është një term ombrellë për disa
metodologji iterative dhe rritjes për suftuerin.
Teknikat më të njohura të zhvillimit Agile përfshijnë:
o eXtreme Programming (XP)
o Scrum
o Adaptive Software Development(ADS)
o Dynamic Systems Development Method (DSDM)
o Feature Driven Development (FDD)
o Rational Unified Process (RUP/AUP)
o Crystal
o Kanban

Programimi eXstrem (XP)
Një metodë agile me shumë ndikim, e zhvilluar në fund të viteve 1990, që paraqiti me
sërë teknikash të zhvillimit agile.
Programimi eXtreme (XP) paraqet një qasje 'ekstreme' në zhvillimin iterativ.
oVersionet e reja mund të ndërtohen disa herë në ditë;
oVerzionet u dërgohen klientëve çdo 2 javë (rrites);
oTë gjitha testet duhet të kryhen për çdo verzion dhe verzioni pranohet vetëm nëse testet
zhvillohen me sukses.

The extreme programming release cycle
The extreme programming

release cycle

eXtreme programming practices (a)
Incremental planning - Requirements are recorded on story cards and the stories to be
included in a release are determined by the time available and their relative priority. The
developers break these stories into development ‘Tasks’. See Figures 3.5 and 3.6.
Small releases - The minimal useful set of functionality that provides business value is
developed first. Releases of the system are frequent and incrementally add functionality to the
first release.
Simple design - Enough design is carried out to meet the current requirements and no more.
Test-first development - An automated unit test framework (Junit) is used to write tests for a
new piece of functionality before that functionality itself is implemented.
Refactoring - All developers are expected to refactor the code continuously as soon as
possible code improvements are found. This keeps the code simple and maintainable.

eXtreme programming practices (b)
Pair programming - Developers work in pairs, checking each other’s work and providing the support to
always do a good job.
Collective ownership - The pairs of developers work on all areas of the system, so that no islands of
expertise develop and all the developers take responsibility for all of the code. Anyone can change
anything.
Continuous integration - As soon as the work on a task is complete, it is integrated into the whole
system. After any such integration, all the unit tests in the system must pass.
Sustainable pace - Large amounts of overtime are not considered acceptable as the net effect is often
to reduce code quality and medium term productivity.
On-site customer - A representative of the end-user of the system (the customer) should be available
full time for the use of the XP team. In an XP process, the customer is a member of the development
team and is responsible for bringing system requirements to the team for implementation.

XP and agile principles
Incremental development is supported through small,
frequent system releases.
Customer involvement means full-time customer
engagement with the team.
People not process through pair programming, collective
ownership and a process that avoids long working hours.
Change supported through regular system releases.
Maintaining simplicity through constant refactoring of
code.

Influential XP practices
eXtreme programming has a technical focus and is not easy to integrate with
management practice in most organizations.
Consequently, while agile development uses practices from XP, the method as
originally defined is not widely used.
Key practices
oUser stories for specification
oRefactoring
oTest-first development
oPair programming

User stories for requirements
In XP, a customer or user is part of the XP team and is responsible for making
decisions on requirements.
User requirements are expressed as user stories or scenarios.
These are written on cards and the development team break them down into
implementation tasks. These tasks are the basis of schedule and cost estimates.
The customer chooses the stories for inclusion in the next release based on their
priorities and the schedule estimates.

Title: Priority:
As a [type of user], I want [goal] so that
[Value]
User Story Template Notes:

Assumptions:
Constraints:
Estimate:
Title: Checkout Using Credit Card Priority: 25
As a book shopper, I can checkout using my credit

User Story Example card
So that I can purchase a selected book.
Notes: Support mc, visa, amex

Constraints: Must use SBI payment gateway
Estimate: 13pts

User Story Example

Refactoring
Conventional wisdom in software engineering is to design for change. It is worth
spending time and effort anticipating changes as this reduces costs later in the life
cycle.
XP, however, maintains that this is not worthwhile as changes cannot be reliably
anticipated.
Rather, it proposes constant code improvement (refactoring) to make changes easier
when they have to be implemented.

Refactoring
Programming team look for possible software improvements and make these
improvements even where there is no immediate need for them.
This improves the understandability of the software and so reduces the need for
documentation.
Changes are easier to make because the code is well-structured and clear.
However, some changes requires architecture refactoring and this is much more
expensive.

Examples of refactoring
Re-organization of a class hierarchy to remove duplicate code.
Tidying up and renaming attributes and methods to make them easier to understand.
The replacement of inline code with calls to methods that have been included in a
program library.

Test-first development
Testing is central to XP and XP has developed an approach where the program is
tested after every change has been made.
XP testing features:
o Test-first development.
o Incremental test development from scenarios.
o User involvement in test development and validation.
o Automated test harnesses are used to run all component tests each time that a new release is
built.

Test-Driven Development (TDD)
Writing tests before code clarifies the requirements to
be implemented.
Tests are written as programs rather than data so that
they can be executed automatically. The test includes a
check that it has executed correctly.
o Usually relies on a testing framework such as JUnit.
All previous and new tests are run automatically
when new functionality is added, thus checking that the
new functionality has not introduced errors.

Customer involvement
The role of the customer in the testing process is to help develop acceptance tests
for the stories that are to be implemented in the next release of the system.
The customer who is part of the team writes tests as development proceeds. All new
code is therefore validated to ensure that it is what the customer needs.
However, people adopting the customer role have limited time available and so
cannot work full-time with the development team. They may feel that providing the
requirements was enough of a contribution and so may be reluctant to get involved in the
testing process.

Test case description for dose checking
Test case description

for dose checking

Test automation
Test automation means that tests are written as executable components before the
task is implemented
o These testing components should be stand-alone, should simulate the submission of input to be
tested and should check that the result meets the output specification. An automated test
framework (e.g. JUnit) is a system that makes it easy to write executable tests and submit a set of
tests for execution.
As testing is automated, there is always a set of tests that can be quickly and easily
executed
o Whenever any functionality is added to the system, the tests can be run and problems that the new
code has introduced can be caught immediately.

Problems with Test-first development
Programmers prefer programming to testing and sometimes they take short cuts when
writing tests.
o For example, they may write incomplete tests that do not check for all possible exceptions that may
occur.
Some tests can be very difficult to write incrementally.

o For example, in a complex user interface, it is often difficult to write unit tests for the code that
implements the ‘display logic’ and workflow between screens.
It difficult to judge the completeness of a set of tests. Although you may have a lot of
system tests, your test set may not provide complete coverage.

Pair programming
Pair programming involves programmers working in pairs, developing code
together.
This helps develop common ownership of code and spreads knowledge across the
team.
It serves as an informal review process as each line of code is looked at by more
than 1 person.
It encourages refactoring as the whole team can benefit from improving the system
code.

Pair programming
In pair programming, programmers sit together at the same computer to develop the
software.
Pairs are created dynamically so that all team members work with each other during
the development process.
The sharing of knowledge that happens during pair programming is very important
as it reduces the overall risks to a project when team members leave.
Pair programming is not necessarily inefficient and there is some evidence that
suggests that a pair working together is more efficient than 2 programmers working
separately.

Agile project management

Agile project management
The principal responsibility of software project managers is to manage the project so
that the software is delivered on time and within the planned budget for the project.
The standard approach to project management is plan-driven. Managers draw up a
plan for the project showing what should be delivered, when it should be delivered and
who will work on the development of the project deliverables.
Agile project management requires a different approach, which is adapted to
incremental development and the practices used in agile methods.

Scrum
Scrum is an agile method that focuses on managing iterative development rather
than specific agile practices.
There are three phases in Scrum.
oThe initial phase is an outline planning phase where you establish the general objectives for
the project and design the software architecture.
oThis is followed by a series of sprint cycles, where each cycle develops an increment of the
system.
oThe project closure phase wraps up the project, completes required documentation such
as system help frames and user manuals and assesses the lessons learned from the project.

Scrum
A light-weight agile process tool
Split your organization
o into small, cross-functional, self-organizing teams.
Split your work into a list of small, concrete deliverables.

o Sort the list by priority and estimate the relative effort of each item.

Scrum

People
+ = Product
Practices Key Scrum Beliefs
Scrum requires a mental shift in the way people think
o A preference of People over Practices: understanding that solving complex problems requires
brainpower, not recipes;
o An understanding that the best Products are developed by having a Focus on User's Needs rather
than relying on a requirements document;
o The acceptance that Reality Trumps Expectations, so when reality and expectations don't match, it is
the expectations that must change;
o The preference for Self-Organizing Teams over either lone-wolf-ism or tightly controlled management;
and
o The realization that each of them is part of a Team developing Product and that they are not simply
People doing Work.

The Scrum Team
The Scrum Team is a small (ideally 5-9) group of people that provides useful Products and Results for
Stakeholders.
o Stakeholders
o The most important role involved in Scrum
o The reason a Team is developing a Product
o Business Owner (BO)
o A special stakeholder, often the Team's sponsor or champion and
controls the budget for the Team
o Product Owner (PO)
o Most important person on the Scrum Team
o Works with Stakeholders to represent their interests to the Team
o Held accountable for the value of the Team's results
o Scrum Team Members
o Do the work (analysis, design, code, test, document, data quality
checks, or whatever work is required for a desired outcome)
o Scrum Master (SM)
o Facilitator, moderator, and coach
o Manages relationship between the PO and the Scrum Team
o Focuses on team improvement

Scrum terminology (a)
Scrum - A daily meeting of the Scrum team that reviews progress and prioritizes work to be done that day. Ideally, this
should be a short face-to-face meeting that includes the whole team.
Sprint - A development iteration. Sprints are usually 2-4 weeks long.
ScrumMaster - The ScrumMaster is responsible for ensuring that the Scrum process is followed and guides the team in the
effective use of Scrum. The Scrum developers are adamant that the ScrumMaster should not be thought of as a project
manager.
Development team - A self-organizing group of software developers, which should be no more than 7 people. They are
responsible for developing the software and other essential project documents.
 Product owner - An individual (or possibly a small group) whose job is to identify product features or requirements,
prioritize these for development and continuously review the product backlog to ensure that the project continues to meet
critical business needs.
o The Product Owner can be a customer but might also be a product manager in a software company or other stakeholder representative.

Scrum terminology (b)
Product backlog - This is a list of ‘to do’ items which the Scrum team must tackle. They may be feature
definitions for the software, software requirements, user stories or descriptions of supplementary tasks
that are needed, such as architecture definition or user documentation.
Potentially shippable product increment - The software increment that is delivered from a sprint. The
idea is that this should be ‘potentially shippable’ which means that it is in a finished state and no further
work, such as testing, is needed to incorporate it into the final product. In practice, this is not always
achievable.

The Scrum sprint cycle
Sprints are fixed length, normally 2–4 weeks.
The starting point for planning is the product backlog, which is the list of work to be done on
the project.
The selection phase involves all of the project team who work with the customer to select the
features and functionality from the product backlog to be developed during the sprint.

Scrum sprint cycle
Scrum sprint cycle

The Scrum sprint cycle
Once sprints are agreed, the team organize themselves to develop the software.
During this stage the team is isolated from the customer and the organization, with all
communications channelled through the so-called ‘Scrum master’.
The role of the Scrum master is to protect the development team from external
distractions.
 At the end of the sprint, the work done is reviewed and presented to stakeholders.
The next sprint cycle then begins.

Scrum benefits
The product is broken down into a set of manageable and understandable chunks.
Unstable requirements do not hold up progress.
The whole team have visibility of everything and consequently team communication
is improved.
Customers see on-time delivery of increments and gain feedback on how the
product works.
Trust between customers and developers is established and a positive culture is
created in which everyone expects the project to succeed.

Distributed Scrum

Slide shtes

Agile methods for large systems
Large systems are usually collections of separate, communicating systems, where
separate teams develop each system. Frequently, these teams are working in different
places, sometimes in different time zones.
Large systems usually have a diverse set of stakeholders. It is practically impossible
to involve all of these different stakeholders in the development process.
Where several systems are integrated to create a system, a significant fraction of the
development is concerned with system configuration rather than original code
development.

Factors in large systems
Factors in large
systems

Multi-team Scrum
Role replication
o Each team has a Product Owner for their work component and ScrumMaster.
Product architects
o Each team chooses a product architect and these architects collaborate to design and evolve the overall
system architecture.
Release alignment
o The dates of product releases from each team are aligned so that a demonstrable and complete system
is produced.
Scrum of Scrums
o There is a daily Scrum of Scrums where representatives from each team meet to discuss progressand
plan work to be done.

Scaling agile methods

Scaling agile methods
Agile methods have proved to be successful for small and medium sized projects that
can be developed by a small co-located team.
It is sometimes argued that the success of these methods comes because of improved
communications which is possible when everyone is working together.
Scaling up agile methods involves changing these to cope with larger, longer projects
where there are multiple development teams, perhaps working in different locations.

Scaling out and scaling up
‘Scaling up’ is concerned with using agile methods for developing large software
systems that cannot be developed by a small team.
‘Scaling out’ is concerned with how agile methods can be introduced across a large
organization with many years of software development experience.
When scaling agile methods it is importaant to maintain agile fundamentals:
o Flexible planning, frequent system releases, continuous integration, test-driven development and good
team communications.

Practical problems with agile methods
The informality of agile development is incompatible with the legal approach to contract
definition that is commonly used in large companies.
Agile methods are most appropriate for new software development rather than software
maintenance. Yet the majority of software costs in large companies come from
maintaining their existing software systems.
Agile methods are designed for small co-located teams yet much software development
now involves worldwide distributed teams.

Contractual issues
Most software contracts for custom systems are based around a specification, which
sets out what has to be implemented by the system developer for the system customer.
However, this precludes interleaving specification and development as is the norm in
agile development.
A contract that pays for developer time rather than functionality is required.
o However, this is seen as a high risk my many legal departments because what has to be delivered
cannot be guaranteed.

Agile methods and software maintenance
Most organizations spend more on maintaining existing software than they do on new
software development. So, if agile methods are to be successful, they have to support
maintenance as well as original development.
Two key issues:
o Are systems that are developed using an agile approach maintainable, given the emphasis in the
development process of minimizing formal documentation?
o Can agile methods be used effectively for evolving a system in response to customer change requests?
Problems may arise if original development team cannot be maintained.

Agile maintenance
Key problems are:
o Lack of product documentation
o Keeping customers involved in the development process
o Maintaining the continuity of the development team
Agile development relies on the development team knowing and understanding what
has to be done.
For long-lifetime systems, this is a real problem as the original developers will not
always work on the system.

Agile and plan-driven methods
Most projects include elements of plan-driven and agile processes. Deciding on the
balance depends on:
o Is it important to have a very detailed specification and design before moving to implementation? If so,
you probably need to use a plan-driven approach.
o Is an incremental delivery strategy, where you deliver the software to customers and get rapid feedback
from them, realistic? If so, consider using agile methods.
o How large is the system that is being developed? Agile methods are most effective when the system can
be developed with a small co-located team who can communicate informally. This may not be possible
for large systems that require larger development teams so a plan-driven approach may have to be used.

Agile principles and organizational practice
Principle Practice
This depends on having a customer who is willing and able to spend time with the development team
and who can represent all system stakeholders. Often, customer representatives have other demands
Customer involvement on their time and cannot play a full part in the software development.
Where there are external stakeholders, such as regulators, it is difficult to represent their views to the
agile team.
Prioritizing changes can be extremely difficult, especially in systems for which there are many
Embrace change
stakeholders. Typically, each stakeholder gives different priorities to different changes.
Rapid iterations and short-term planning for development does not always fit in with the longer-term
Incremental delivery planning cycles of business planning and marketing. Marketing managers may need to know what
product features several months in advance to prepare an effective marketing campaign.
Maintain simplicity Under pressure from delivery schedules, team members may not have time to carry out desirable
system simplifications.
People not process Individual team members may not have suitable personalities for the intense involvement that is typical
of agile methods, and therefore may not interact well with other team members.

Agile and plan-based factors

System issues
How large is the system being developed?
o Agile methods are most effective a relatively small co-located team who can communicate informally.
What type of system is being developed?
o Systems that require a lot of analysis before implementation need a fairly detailed design to carry out this
analysis.
What is the expected system lifetime?
o Long-lifetime systems require documentation to communicate the intentions of the system developers to
the support team.
Is the system subject to external regulation?
o If a system is regulated you will probably be required to produce detailed documentation as part of the
system safety case.

People and teams
How good are the designers and programmers in the development team?
o It is sometimes argued that agile methods require higher skill levels than plan-based approaches in
which programmers simply translate a detailed design into code.
How is the development team organized?

o Design documents may be required if the team is dsitributed.
What support technologies are available?

o IDE support for visualisation and program analysis is essential if design documentation is not available.
30/10/2014 CHAPTER 3 AGILE SOFTWARE DEVELOPMENT 86

Organizational issues
Traditional engineering organizations have a culture of plan-based development, as this
is the norm in engineering.
Is it standard organizational practice to develop a detailed system specification?
Will customer representatives be available to provide feedback of system increments?
Can informal agile development fit into the organizational culture of detailed
documentation?

IBM’s agility at scale model
IBM’s agility at scale

model

Scaling up to large systems
A completely incremental approach to requirements engineering is impossible.
There cannot be a single product owner or customer representative.
For large systems development, it is not possible to focus only on the code of the
system.
Cross-team communication mechanisms have to be designed and used.
Continuous integration is practically impossible. However, it is essential to maintain
frequent system builds and regular releases of the system.

Agile methods across organizations
Project managers who do not have experience of agile methods may be reluctant to
accept the risk of a new approach.
Large organizations often have quality procedures and standards that all projects are
expected to follow and, because of their bureaucratic nature, these are likely to be
incompatible with agile methods.
Agile methods seem to work best when team members have a relatively high skill level.
However, within large organizations, there are likely to be a wide range of skills and
abilities.
There may be cultural resistance to agile methods, especially in those organizations
that have a long history of using conventional systems engineering processes.

Key points
Agile methods are incremental development methods that focus on rapid software
development, frequent releases of the software, reducing process overheads by
minimizing documentation and producing high-quality code.
Agile development practices include
o User stories for system specification
o Frequent releases of the software,
o Continuous software improvement
o Test-first development
o Customer participation in the development team.

Key points
Scrum is an agile method that provides a project management framework.
o It is centred round a set of sprints, which are fixed time periods when a system increment is developed.
Many practical development methods are a mixture of plan-based and agile

development.
Scaling agile methods for large systems is difficult.
o Large systems need up-front design and some documentation and organizational practice may conflict
with the informality of agile approaches.

Referencat
Kapitulli 3: Agile Software Development

Inxhinieri Softwerike, 2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Inxhinieri Softwerike, 2

Uploaded by

Copyright:

Available Formats

Inxhinieria Softuerike

Agile Software Development-Modelet Softuerike

Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 1

Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 2

Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 3

30/10/2014 CHAPTER 2 SOFTWARE PROCESSES 4

Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 5

Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 6

Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 7

Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 8

30/10/2014 CHAPTER 2 SOFTWARE PROCESSES 9

Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 10

Çdo version posedon funksionet paraprake të modifikuara dhe përshtatura. Po

Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 11

Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 12

Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 13

Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 14

Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 15

Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 17

Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 18

Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 19

Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 20

Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 21

Analiz  Dizajn  Implementim

"Unë dua që kjo veçori shtesë të shtohet!"

Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 22

 Zhvillimi sipas model i drejtuar-në-planifikim është thelbësor për disa lloje të

Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 23

Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 24

Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 25

Zhvillimi sipas modelit:

Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 26

Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 27

Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 28

oSoftuer që Punon(Softuer funksional) mbi dokumentacionin gjithëpërfshirës (plotë)

oBashkëpunimi me klientët mbi negocimi i kontratës

oDuke iu përgjigjur ndryshimit mbi permbajtja në një plan

Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 29

Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 30

Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 31

10. Thjeshtësia është thelbësore:

11. Ekipet vetë-organizuar prodhojë arkitektur/kërkes/dizajn më të mire.

Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 32

Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 33

2. Zhvillimi i softuerit specifik brenda organizatës, ku ka një angazhim dhe zotim të

Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 34

Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 35

Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 36

Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 37

The extreme programming

Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 38

Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 39

Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 40

Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 41

Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 42

Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 43

User Story Template Notes:

Title: Checkout Using Credit Card Priority: 25

As a book shopper, I can checkout using my credit

Notes: Support mc, visa, amex

Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 44

Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 45

Ramiz HOXHA & Fisnik PREKAZI © 2017 KOLEGJI UBT 46