EXN QA Internship

Software development methodologies

Belgium Session name: Software development methodologies

Matenstraat 214 (a)
2845 Niel
+32 32 130 383 (t) Main objective: interns learn about software development methodologies (with focus on Agile)
+32 32 131 454 (f) Secondary objectives: get an overview regarding
Romania - Waterfall model
Barbu Lautaru 11 (a)
700399 Iasi - V model
+40 332 808 044 (t) - Agile/Scrum
+40 332 811 504 (f)
- Agile/Kanban
office@expertnetwork.eu
www.expertnetwork.eu
Pre-requisites:
Logistics requirements:
Information sources:

Training time:
Working time:
 page 2 of 4

Waterfall model
It is very simple to understand and use. In a waterfall model, each phase must be completed before the next phase can
begin and there is no overlapping in the phases.

Requirement gathering and analysis: all possible requirements of the system to be developed are captured in this phase
and documented in a requirement specification document.
System design: the requirement specifications from first phase are studied in this phase and the system design is prepared.
This system design helps in specifying hardware and system requirements and helps in defining the overall system
architecture.
Implementation: with inputs from the system design, the system is first developed in small programs called units, which
are integrated in the next phase. Each unit is developed and tested for its functionality, which is referred to as Unit Testing.
Integration and testing: all the units developed in the implementation phase are integrated into a system after testing of
each unit. Post integration the entire system is tested for any faults and failures.
Deployment of system: once the functional and non-functional testing is done; the product is deployed in the customer
environment or released into the market.
Maintenance: there are some issues which come up in the client environment. To fix those issues, patches are released.
Also to enhance the product some better versions are released. Maintenance is done to deliver these changes in the
customer environment.

Advantages:
- simple and easy to understand and use
- easy to manage due to the rigidity of the model. Each phase has specific deliverables and a review process
- phases are processed and completed one at a time
- works well for smaller projects where requirements are very well understood
- clearly defined stages
- well understood milestones
- easy to arrange tasks
- process and results are well documented

Disadvantages:
- no working software is produced until late during the life cycle
- high amounts of risk and uncertainty
- not a good model for complex and object-oriented projects
- poor model for long and ongoing projects
- not suitable for the projects where requirements are at a moderate to high risk of changing. So, risk and uncertainty is
high with this process model
- it is difficult to measure progress within stages
- cannot accommodate changing requirements
- adjusting scope during the life cycle can end a project
- integration is done as a "big-bang”, at the very end, which doesn't allow identifying any technological or business
bottleneck or challenges early

V model
 page 3 of 4

V model means Verification and Validation model. Just like the waterfall model, the V shaped life cycle is a sequential
path of execution of processes. Each phase must be completed before the next phase begins. V model is one of the many
software development models. Testing of the product is planned in parallel with a corresponding phase of development in
V model.

Requirements like BRS and SRS begin the life cycle model, in this model before development is started, a system test plan
is created.

The high-level design (HLD) phase focuses on system architecture and design.

The low-level design (LLD) phase is where the actual software components are designed.

The implementation phase is, again, where all coding takes place. Once coding is complete, the path of execution continues
up the right side of the V where the test plans developed earlier are now put to use.

Coding is at the bottom of the V shape model. Module design is converted into code by developers. Unit testing is
performed by the developers on the code written by them.

Advantages:
- simple and easy to use
- testing activities like planning, test designing happens well before coding. This saves a lot of time. Hence higher chance
of success over the waterfall model
- proactive defect tracking – that is defects are found at early stage
- avoids the downward flow of the defects
- works well for small projects where requirements are easily understood.

Disadvantages:
- very rigid and least flexible
- software is developed during the implementation phase, so no early prototypes of the software are produced
- if any changes happen in midway, then the test documents along with requirement documents has to be updated

Agile/Kanban
Kanban (means ‘Visual Signal’ in Japanese) is based on 3 basic principles:
- visualize what you do today (workflow): seeing all the items in context of each other can be very informative
- limit the amount of work in progress (WIP): this helps balance the flow-based approach so teams don’t start and
commit to too much work at once
- enhance flow: when something is finished, the next highest thing from the backlog is pulled into play

How Kanban is different from Scrum?

Both Kanban and Scrum focus on releasing software early and often. Both require highly collaborative and self managed
teams. There are, however, differences between the approaches:
- no prescribed roles vs pre-defined roleas of Scrum Master, Product owner and team member
- continuous delivery vs timeboxed sprints
- work is “pulled” through the system (single piece flow) vs work is “pulled” through the system in batches (the sprint
backlog)
- changes can be made at any time vs no changes allowed mid sprint
- cycle time vs velocity
- more appropriate in operational environments with a high degree of variability in priority vs more appropriate in
situations where work can be prioritized in batches that can be left alone

Agile/Scrum
 page 4 of 4

At its core, Expert Network Delivery Model is built on Scrum, an iterative, incremental and adaptive framework for
building complex software aiming to deliver working software in fixed iterations of 2 weeks, according to what the
business needs most and fostering a process of continuous improvement.

Apart from the Team itself, two specialized roles are identified: the Product Owner (PO) and the Scrum Master (SM).
The Product Owner is a single person appointed by the client, owning the Product Backlog and involved in User Story
creation and review, business value assignment, attending Refinement and Review sessions, and budget approval. The
Scrum Master is one of the team members, who makes sure the Scrum process is followed, identifies and removes
impediments driving continuous improvement.

Product requirements are described as User Stories and discussed between the PO and the Team in Refinement sessions.
Once stories are sufficiently clear, they are estimated by the Team. At the same time, the PO is responsible for assigning
business value to each of the stories. Together, business value and estimates usually determine the order in which
development occurs. As such, the Product Backlog becomes an order list of stories that will be picked up by the Team in
development Sprints.

Before starting a new Sprint, the Team commits on a number of stories from the top of the Product Backlog that they think
they can handle in the coming iteration. This takes place in the Sprint Planning ceremony and at the end of a Sprint, the
Team presents to the PO (and optionally other stakeholders) the functionality which was realized in the Sprint Review
ceremony. Short feedback cycles are achieved by having the team conduct a Daily Meeting where they synchronize:
review progress, decide on next tasks to work on and see if there are any impediments. It is encouraged that the Product
Owner also participate in this ceremony.

Every iteration is concluded by a Sprint Retrospective, where the Team evaluates what went well, what held the team back
and what can be improved. The result of this ceremony should be a list of actionable items where at least the most
important one is tackled in the next Sprint.

At its nature, Scrum has a very dynamic model. It allows the Product Owner to construct and constantly update a Product
Backlog in sync with the business requirements and market changes. High productivity is also based on the fact that the
Team discusses functionality over several Refinement sessions, breaks them down into tasks in the Planning meeting and
reaches momentum in the course of the Sprint when they implement it. Therefore this needs to be a stable period, where
significant items may not change, otherwise it will have a negative impact. This is achieved by having a shared
understanding of Ready (Stories not ready should not enter in a Sprint) and Done (at the end of the Sprint, only Stories
fulfilling this criteria are regarded as completed).

The following should also be discussed:

- Roles
- Ceremonies
- Estimations
- Definition of ready
- Definition of done

Useful URLs
https://wildstream.atlassian.net/wiki/spaces/BOO/pages/61210664/Delivery+Model