9.

Software development
methodologies
9.1. Present approach to software
development
Software development is a complex, human-intensive process which goal is to deliver
a product within certain period of time and budget that meets the requirements of the
client. In order to build high quality software systems, companies need to follow some
mature software development practices, which are subject to constant evolution. These
methodologies are the source of formal guidelines and instructions on how the software
development process should be managed and organized.
Presently, software development approaches can be divided into heavyweight and light-
weight (or agile) methodologies. A particular methodology is chosen on the basis of
the size of software development team, the complexity of the problem to be solved and
needs of the client.
152 English 4 IT. Praktyczny kurs jözyka angielskiego dla specjalistów IT i nie tylko

9.2. Heavyweight vs. lightweight

software development
methodologies
As far as the heavyweight approach is concerned, the most common is the waterfall
methodology. Its modifications include spiral model and v-model.
The waterfall model includes a sequential series of steps which divide software deve-
lopment life cycle (SDLC) into the following distinct phases: planning and require-
ments gathering, system design, implementation, testing, deployment and finally
software maintenance.
The waterfall approach is rather clear and one of its advantages is that the series of fixed
milestones make it easy to track progress of the project. Another advantage of this
linear software development process is that potential problems, which would have
been found during development phase, can be investigated and bottomed out during
the design phase, before implementation of the solution. The whole process is also
well documented so in the end there are no misunderstandings. This type of method-
ology is usually used in large projects in which the technology, requirements and prod-
uct definition remain unchanged. Such inflexibility and unresponsiveness to change
seem to become less popular in today’s business environment in which companies are
constantly changing their software requirements to keep up the pace of market deve-
lopment. They do not want to stay behind their competitors. Other disadvantages of
waterfall approach include susceptibility to bottlenecks and delays and possible late
product delivery as only the completion of final project phase provides a deliverable.
The Rational Unified Process (RUP) methodology is also frequently used in the soft-
ware industry. It uses iterative and incremental approach and is strongly tied to using
object-oriented modelling. In RUP, a project is divided into a number of iterations
and for each iteration the project goes through the following phases, which makes it
similar to the spiral model:
 Inception: At this stage the development team conducts the analysis of the
problem to be solved, assesses feasibility of the project and specifies high-level
requirements. A project vision is created and business case is developed.
 Elaboration: At this point the project team designs a baseline architecture
of the system, further elaborates on the requirements and conducts risk analysis.
 Construction: By the end of this phase a beta-release working system is made
available.
 Transition: This is the time to validate the product and obtain the acceptance
of intended users and stakeholders.
As far as the lightweight software development methodologies are concerned, the basis
for them is the Agile Manifesto which presents key values to the philosophy behind
them:
Rozdziaä 9. i Software development methodologies 153

 Individuals and interactions which help to get rid of any misunderstandings

between the team members, giving rooms for ideas and immediate feedback,
are more important than processes and tools.
 Having a working software given earlier to the user, even if it provides minimal
value, is preferred over development of the entire software in detail with
comprehensive documentation. Such documentation may turn out to be
a throwaway task because of the change of user requirements. It must be
pointed out that documentation should not be overlooked or disregarded but
it should exist in its basic form.
 Customer collaboration leading to full understanding of customer needs is more
important than contract negotiation which limits the evolution of software project
due to agreed-upon feature set.
 Responding to change, which should be embraced and prepared for as software
evolves, is more important than following the plan as planned features may
be reprioritized.

9.3. Agile software development

methodologies and frameworks
As it has been mentioned above, agile software methodologies replace sequential soft-
ware development approach and design upfront with incremental and iterative one.
They allow changes of requirements which are delivered by self-organizing, cross-func-
tional teams including designers, developers and testers, working on iteration of the
product over fixed time periods called timeboxes. A working software is delivered at
the end of each iteration. The most commonly used agile methodologies or software
development frameworks are the following:
 Scrum: It is a process framework with timeboxed units referred to as sprints.
Sprints are usually 1 – 4 weeks long. After the Product Owner defines a set
of requirements in Product Backlog, the Scrum Team (comprising of the
Product Owner, the Development Team and the Scrum Master) agrees on a set
of items to be addressed in a sprint and put them in a Sprint Backlog during
the Sprint Planning. The items in Product Backlog are reviewed and revised
during Backlog Refinement, also referred to as Backlog Grooming. They are
expressed in the form of user stories which are a part of one or more epics.
The relative effort to implement each user story is estimated in story points
using for example Planning Poker. After that the Development Team identifies
tasks which are needed to complete each user story, there is a time for R&D work
of developers, followed by demos of the solution and retrospectives. During
the sprint each day there are 15-minute time-boxed meetings for the Development
Team called Daily Scrums to synchronize activities and create a plan for the
next 24 hours. Each sprint ends up with a demonstration of potentially shippable
working product demonstrated to stakeholders which takes place during the
Sprint Review. After that and prior to the next Sprint Planning, a Sprint
Retrospective takes place. It is an opportunity for the Scrum Team to inspect
the results of its work and talk about the improvements to be enacted during
154 English 4 IT. Praktyczny kurs jözyka angielskiego dla specjalistów IT i nie tylko

the next Sprint. A measurement of the amount of work the Development Team
can complete during a single Sprint (velocity) can be graphically presented
using a burn-down chart. The forecasted velocity can be calculated on the
basis of Focus Factor (velocity/capacity). A simple burn-down chart of ten-day
sprint is shown in figure 9.1 below.
Figure 9.1.
A simple burn-down
chart

 DSDM Agile Project Framework: This is a more formal and well-known agile
project management framework which enables the organisations to deliver
working solutions on time and on budget. According to the framework, there
are for example the following roles of people involved in a project:
 Business Sponsor: It is a person responsible for the Business Case and project
budget who resolves business issues and makes financial decisions.
 Business Visionary: It is a person responsible for clear vision of the project
who interprets the needs of Business Sponsor and communicates them to the
team.
 Technical Coordinator: It is a person responsible for delivery of compatible
output, meeting the agreed technical quality standards.
 Solution Developer: It is a person who interprets business requirements
and translates them to deployable solution which meets the needs of solution
recipients.
 DSDM Coach: It is an independent person certified in DSDM Agile Project
Framework whose role is to help less experienced team use this approach
properly and effectively.
DSDM stands for dynamic systems development method. DSDM Agile
Project Framework integrates a project management lifecycle and a product
development lifecycle into a single framework. The project process includes
seven phases: Pre-Project, Feasibility, Foundations, Evolutionary Develop-
ment, Deployment, Post-Project. A crucial element of this method is the
Prioritized Requirements List (PRL) which includes high-level require-
ments established during Feasibility and Foundations phases, prioritized using
the MoSCoW technique. The MoSCoW technique involves prioritizing the
requirements according to the following rules: M (must have requirements
Rozdziaä 9. i Software development methodologies 155

which are the minimum usable subset), S (should have requirements

to be delivered if possible), C (could have requirements which are not critical)
and W (won’t have requirements which won’t be delivered this time, but
potentially they can be delivered later). Other DSDM Agile Project Framework
products include: Solution Architecture Definition (SAD), Feasibility
Assessment, Delivery Plan, Timebox Plan and many other.
In June 2012, the DSDM Consortium published a white paper describing the
integration of DSDM Agile Project Framework with Scrum. Figure 9.2 presents
the DSDM phases in this approach.
Figure 9.2.
The phases in the
Agile Project
Framework integrated
with Scrum

Source: Craddock A., Roberts B., Godwin J., Tudor D., Richards K., The DSDM Agile Project Framework for Scrum.
Revised and Updated — June 2014, White Paper for DSDM Consortium. Retrieved from
https://www.dsdm.org/resources/white-papers/the-dsdm-agile-project-framework-for-scrum

 Kanban: It is an iterative process method which puts emphasis on optimizing

process flow which is similar to Scrum. In Kanban a task board is used
to visualize workflow to present which tasks are pending, during analysis
phase, currently developed, in-testing and deployed. This concept is related
to just-in-time (JIT) and lean production issue. One of its goals is therefore
to limit work-in-progress and manage the workflow efficiently.
 Extreme programming (XP): It is a software development methodology which
applies such practices as pair programming, collective code ownership, short
releases, test-driven development (TDD), continuous integration, refactoring
and code reviews.
 Feature-driven development (FDD): It is a client-centric methodology which
combines the speed and flexibility of agile methods with model-driven software
development techniques. It includes 5 stages that one should follow:
 Develop an Overall Model following the JEDI (just enough design initially)
approach, rather than the derogatory BDUF (big design up front) method,
156 English 4 IT. Praktyczny kurs jözyka angielskiego dla specjalistów IT i nie tylko

in order to understand the fundamentals of the domain that the system

is addressing.
 Build a Features List instead of user stories or backlog items. The features
should be listed in a three-level hierarchy comprising of major subject areas
divided into feature sets including detailed features.
 Plan by Feature stage is about setting-up activities which constitute
a high-level plan for Chief Programmers and developers.
 Design by Feature and Build by Feature are highly iterative stages in which
a Chief Programmer selects the small group of features to be developed
over the next few days. The process can be supported by user experience
(UX) designers. The feature teams work together with the support
of a Domain Expert and analyse the details of each selected feature and
design the solution for each feature. In the next step they work on coding,
perform testing tasks and finally code inspection takes place. When each team
successfully finishes the implementation of the feature, it is validated by the
client and integrated with the main product. Then the process is repeated
for another set of features.

9.4. Vocabulary
ENGLISH — POLISH ENGLISH — POLISH
(to) address (something) — zajmowaü siĊ (czymĞ) bottleneck — wąskie gardáo
agile methodology — metodyka zwinna (to) bottom out a problem — dotrzeü do sedna
agreed-upon feature set — uzgodniony zestaw problemu
funkcji Build a Features List (in FDD) — budowanie
approach — podejĞcie listy cech

Backlog Grooming (in Scrum) — doskonalenie Build by Feature (in FDD) — realizacja cechy
backlogu (rejestru) produktu burn-down chart — wykres spalania
backlog item — element backlogu (rejestru) Business Case (in DSDM Agile Project
produktu Framework) — uzasadnienie biznesowe
Backlog Refinement (in Scrum) — doskonalenie business case — uzasadnienie biznesowe
backlogu (rejestru) produktu business issue — kwestia biznesowa
baseline architecture — architektura odniesienia Business Sponsor (in DSDM Agile Project
beta-release working system — wersja beta Framework) — Business Sponsor/sponsor biznesowy1
dziaáającego systemu Business Visionary (in DSDM Agile Project
big design up front (BDUF) — szczegóáowe Framework) — Business Visionary/wizjoner biznesu
wymagania okreĞlone z góry

1
Nazwy ról, etapów realizacji projektu oraz dokumentów m.in. w metodzie DSDM Agile Project Framework
są w niektórych publikacjach táumaczone na jĊzyk polski, a w innych pozostawiane w oryginale. Stąd dwie
propozycje przedstawione w sáowniczku. W przypadku, gdy odbiorca moĪe mieü wątpliwoĞci co do znacze-
nia polskiego terminu, jego odpowiednik w jĊzyku angielskim moĪna zamieĞciü w nawiasie w nastĊpujący
sposób: sponsor biznesowy (ang. Business Sponsor), faza przedprojektowa (ang. Pre-Project).
Rozdziaä 9. i Software development methodologies 157

ENGLISH — POLISH ENGLISH — POLISH

capacity — pojemnoĞü (zespoáu) domain — dziedzina/domena
Chief Programmer (in FDD) — gáówny DSDM Coach (in DSDM Agile Project
programista Framework) — DSDM Coach/coach DSDM
client-centric methodology — metodyka dynamic systems development method
ukierunkowana na potrzeby klienta (DSDM) — metoda tworzenia systemów
code review — przegląd kodu/inspekcja kodu dynamicznych

collective code ownership (in XP) — wspólna (to) elaborate (on something) — rozwinąü
wáasnoĞü kodu (dany temat)/podaü wiĊcej informacji

(to) combine (something with something) — Elaboration (in RUP) — opracowanie

áączyü (coĞ z czymĞ) (to) embrace — ujmowaü/obejmowaü
complex — záoĪony (to) enact — wcieliü w Īycie
comprehensive documentation — obszerna Evolutionary Development (in DSDM Agile
dokumentacja Project Framework) — faza Evolutionary
constant evolution — ciągáy rozwój Development/faza rozwoju ewolucyjnego

Construction (in RUP) — konstruowanie (to) evolve — rozwijaü siĊ/ewoluowaü

continuous integration — ciągáa integracja extreme programming (XP) — programowanie

ekstremalne
could have requirement — wymaganie, które
moĪe, ale nie musi zostaü speánione Feasibility (in DSDM Agile Project Framework)
— faza Feasibility/faza oceny wykonalnoĞci
cross-functional team — interdyscyplinarny
zespóá Feasibility Assessment (in DSDM Agile Project
Framework) — Feasibility Assessment/studium
Daily Scrum (in Scrum) — codzienny scrum wykonalnoĞci
delay — opóĨnienie feasibility — wykonalnoĞü
deliverable — produkt projektu feature team (in FDD) — zespóá programistów
Delivery Plan (in DSDM Agile Project feedback — informacja zwrotna
Framework) — Delivery Plan/plan dostarczania
focus factor — wspóáczynnik skupienia
deployable solution — rozwiązanie gotowe
do wdroĪenia forecasted velocity — prognozowana prĊdkoĞü

Deployment (in DSDM Agile Project Foundations (in DSDM Agile Project
Framework) — faza Deployment/faza wdroĪenia Framework) — faza Foundations/faza okreĞlenia
podstaw
deployment — wdroĪenie
framework — ramy postĊpowania/rama
Design by Feature (in FDD) — projekt metodyczna/struktura
implementacji cechy
(to) get rid of (something) — pozbyü siĊ
design phase — faza projektowania (czegoĞ)
design upfront — z góry ustalony projekt guideline — wytyczna
systemu
heavyweight methodology — metodyka ciĊĪka
Develop an Overall Model (in FDD) — tworzenie
ogólnego modelu high-level requirement — ogólne wymaganie

Development Team (in Scrum) — zespóá human-intensive process — proces wymagający

deweloperski duĪego zaangaĪowania ze strony czáowieka

(to) disregard — lekcewaĪyü implementation — implementacja/wdroĪenie

Domain Expert (in FDD) — ekspert dziedzinowy in detail — szczegóáowo/ze szczegóáami

158 English 4 IT. Praktyczny kurs jözyka angielskiego dla specjalistów IT i nie tylko

ENGLISH — POLISH ENGLISH — POLISH

Inception (in RUP) — rozpoczĊcie Pre-Project (in DSDM Agile Project Framework)
incremental approach — podejĞcie przyrostowe — faza Pre-Project/faza przedprojektowa

inflexibility — brak elastycznoĞci Prioritized Requirements List (PRL) (in DSDM

Agile Project Framework) — lista wymagaĔ
intended user — docelowy uĪytkownik uszeregowana wedáug priorytetów
(to) investigate a problem — przeanalizowaü process flow — przepáyw procesu
problem
Product Backlog (in Scrum) — backlog produktu/
iterative approach — podejĞcie iteracyjne rejestr produktu
just enough design initially (JEDI) — product development lifecycle — cykl rozwoju
szczegóáowe wymagania odkrywane w trakcie produktu
just-in-time (JIT) production — produkcja Product Owner (in Scrum) — wáaĞciciel produktu
dokáadnie na czas
project management lifecycle — cykl
(to) keep up the pace — utrzymaü tempo zarządzania projektem
lean production — szczupáa produkcja (to) put emphasis (on something) — poáoĪyü
lightweight methodology — metodyka lekka nacisk (na coĞ)
linear software development process — liniowy rational unified process (RUP) — metodyka RUP
proces tworzenia oprogramowania refactoring — refaktoring
maintenance — utrzymanie (to) reprioritize — dokonaü ponownej
major — waĪny/istotny priorytetyzacji/uszeregowaü ponownie pod
wzglĊdem waĪnoĞci
mature software development practice —
dojrzaáe podejĞcie do tworzenia oprogramowania requirements gathering — zbieranie wymagaĔ
milestone — kamieĔ milowy (to) resolve — rozwiązywaü
minimum usable subset — minimalny uĪyteczny risk analysis — analiza ryzyka
podzbiór Scrum Master (in Scrum) — Scrum
model-driven software development technique Master/mistrz scruma
— technika rozwoju oprogramowania w oparciu Scrum Team (in Scrum) — zespóá scrumowy
o model
self-organizing team — samoorganizujący siĊ
MoSCoW technique — technika MoSCoW zespóá
must have requirement — wymaganie, które sequential software development approach —
musi zostaü speánione sekwencyjne podejĞcie do tworzenia
object-oriented modelling — modelowanie oprogramowania
obiektowe shippable working product — dziaáający
(to) overlook (something) — przeoczyü (coĞ) i moĪliwy do przekazania produkt
pair programming (in XP) — programowanie short release — czĊste oddawanie gotowych
w parach elementów systemu
pending — w toku/oczekujący should have requirement — wymaganie, które
powinno zostaü speánione, jeĞli jest to moĪliwe
Plan by Feature (in FDD) — planowanie
implementacji cech software development life cycle (SDLC) — cykl
rozwoju oprogramowania
planning poker — technika planning poker
Solution Architecture Definition (SAD)
Post-Project (in DSDM Agile Project
(in DSDM Agile Project Framework) — Solution
Framework) — faza Post-Project/faza
Architecture Definition/definicja architektury
poprojektowa
rozwiązania
Rozdziaä 9. i Software development methodologies 159

ENGLISH — POLISH ENGLISH — POLISH

Solution Developer (in DSDM Agile Project throwaway task — wykonane zadanie, które
Framework) — Solution Developer/twórca po pewnym czasie okazuje siĊ nieprzydatne
rozwiązania Timebox Plan (in DSDM Agile Project
solution recipient — odbiorca rozwiązania Framework) — Timebox Plan/plan okienka czasu
spiral model — model spiralny timebox — ograniczenie czasowe/ramy czasowe
Sprint (in Scrum) — sprint (to) track progress — Ğledziü postĊp
Sprint Backlog (in Scrum) — backlog Transition (in RUP) — przekazanie
sprintu/rejestr sprintu unresponsiveness (to something) — brak
Sprint Planning (in Scrum) — planowanie sprintu reakcji (na coĞ)

Sprint Retrospective (in Scrum) — retrospektywa user experience (UX) designer — projektant UX/
sprintu projektant doĞwiadczeĔ uĪytkownika
user story — historyjka uĪytkownika
Sprint Review (in Scrum) — przegląd sprintu
(to) validate — potwierdzaü
stakeholder — interesariusz
velocity — prĊdkoĞü (zespoáu)
(to) stay behind the competitors — zostaü w tyle
za konkurencją v-model — model v
story point — story point/punkt historyjkowy waterfall methodology — metodyka kaskadowa
susceptibility to bottlenecks — podatnoĞü na white paper — biuletyn informacyjny/biaáa ksiĊga
bycie wąskim gardáem won’t have requirement — wymaganie, które
system design — projekt systemu nie zostanie speánione, ale moĪe zostaü wziĊte
pod uwagĊ w przyszáoĞci
task board (in Kanban) — tablica zadaĔ
workflow — przepáyw pracy
Technical Coordinator (in DSDM Agile Project
working software — dziaáające
Framework) — Technical Coordinator/
oprogramowanie
koordynator techniczny
working system — dziaáający system
test driven development (TDD) — technika
Test-Driven Development/technika TDD work-in-progress — praca w toku

9.5. Revise and expand

your knowledge
9.5.1. Did you know?
AT THE END vs. IN THE END vs. FINALLY
Definition:
At the end is used to indicate the final part of an event, period of time or activity.
Example sentence:
A working software is delivered at the end of each iteration.
Na koniec kaĪdej iteracji dostarczane jest dziaáające oprogramowanie.
168 English 4 IT. Praktyczny kurs jözyka angielskiego dla specjalistów IT i nie tylko

B. Match the word from the left with the one from the right to form full expression
and translate it into Polish.

1) gather a) story ..........................................................................

2) user b) integration ..........................................................................
3) baseline c) progress ..........................................................................
4) task d) factor ..........................................................................
5) continuous e) requirements zbieraü wymagania
6) track f) user ..........................................................................
7) user g) board ..........................................................................
8) focus h) upfront ..........................................................................
9) intended i) architecture ..........................................................................
10) design j) experience ..........................................................................

C. Fill in the prepositions in the following sentences. The first one has been done
for you.
1. Presently software development practices are subject to constant evolution.
2. Software development approaches can be divided ............ heavyweight
and lightweight methodologies.
3. In waterfall software development approach potential problems can
be investigated and bottomed ............ during the design phase, before
implementation of the solution. The process is also well documented
so ............ the end there are no misunderstandings.
4. RUP methodology is strongly tied ............ using object-oriented modelling.
5. The Scrum Team which comprises ............ the Product Owner, the
Development Team and the Scrum Master agrees ............ a set of items
to be addressed ............ a Sprint.
6. According to Agile Manifesto, individuals and interactions which help
to get rid ............ any misunderstandings between the team members are
more important than processes and tools.
7. The basis ............ lightweight software development methodologies is the
Agile Manifesto which presents key values ............ the philosophy behind
them.
8. In Agile a working software is delivered ............ the end of each iteration.
9. In FDD when each team successfully finishes the implementation of the
feature, it is validated ............ the client and integrated ............ the main
product.
10. According to Agile Manifesto, providing a working software ............ minimal
value is preferred ............ development of the entire software ............ detail.

to (x2) over of (x3) by on out with for in (x3) at into

Rozdziaä 9. i Software development methodologies 169

D. Create the opposite nouns by choosing a proper prefix and translate each of them
into Polish. The first one has been done for you.

1) in- a) understanding ..........................................................................

2) over- b) flexibility brak elastycznoĞci
3) dis- c) changed ..........................................................................
4) un- d) advantage ..........................................................................
5) mis- e) responsiveness ..........................................................................
6) dis- f) popular ..........................................................................
7) un- g) regard ..........................................................................
8) in- h) looked ..........................................................................
9) un- i) available ..........................................................................
10) un- j) valid ..........................................................................

E. What are the elements of Scrum process? Match the roles and components in the
box with the pictures in the following diagram:

a) Sprint Planning b) Backlog c) Product Backlog d) Sprint e) Product

Grooming Backlog Owner
f) Sprint g) Development h) Input from i) Daily j) Sprint
Team stakeholders/ Scrum Retrospective
users/customers
k) Potentially l) Sprint m) Scrum Master
shippable product Review
increment

F. Rewrite the following sentences replacing phrases in bold with compound

adjectives. The first one has been done for you.
1. Kanban is a concept related to Just-In-Time.
Kanban is a Just-In-Time-related concept.
2. FDD is a methodology which consists of five stages and applies techniques
driven by models.
.......................................................................................................................
170 English 4 IT. Praktyczny kurs jözyka angielskiego dla specjalistów IT i nie tylko

3. An extension of the waterfall model is the model in the shape of letter v.

.......................................................................................................................
4. Owing to software development methodologies the process is managed
and organized well.
.......................................................................................................................
5. At Plan by Feature stage of FDD, activities which constitute a plan at a high
level are set up.
.......................................................................................................................
G. Translate the following sentences into English.
1. Metodyka zwinna dopuszcza zmiany w wymaganiach realizowanych
w okreĞlonych ramach czasowych przez samoorganizujący siĊ i inter-
dyscyplinarny zespóá.
.......................................................................................................................
.......................................................................................................................
.......................................................................................................................
2. W koĔcu niektóre podejĞcia do tworzenia oprogramowania staną siĊ mniej
popularne i bĊdą rzadziej stosowane, podczas gdy inne bĊdą siĊ ciągle
rozwijaü.
.......................................................................................................................
.......................................................................................................................
.......................................................................................................................
3. Zgodnie z manifestem agile lepiej jest wczeĞniej dostarczyü uĪytkownikowi
jakąkolwiek czĊĞü dziaáającego oprogramowania z minimalną liczbą
funkcjonalnoĞci niĪ póĨniej caáy system z obszerną dokumentacją.
.......................................................................................................................
.......................................................................................................................
.......................................................................................................................
4. Jednym z gáównych produktów fazy okreĞlenia podstaw w podejĞciu DSDM
Agile Project Framework jest lista wymagaĔ uszeregowana wedáug
priorytetów, w której znajdują siĊ ogólne wymagania uszeregowane pod
wzglĊdem waĪnoĞci za pomocą techniki MoSCoW.
.......................................................................................................................
.......................................................................................................................
.......................................................................................................................