Roles and Responsibilities

Business Owner

The business owner can usually make decisions for the company and is responsible for
identifying new possible businesses and partnerships.

They are responsible also to make some sort of assessment and understand if such
partnerships will bring value to the company.

They work at an abstract business level by defining the problem, how it can be tackled,
and how to measure the success.

Another responsibility of the business owner is to negotiate the terms of the partnership or
establish the prices of a new product.

the viability of the new project itself is something that is usually run by the business owner

keep track of the business metrics and key performance indicators after the project is
done

Business owners work closely with product managers in order to come up with a concept
that can be further implemented by a technical team
 Product Manager

Common tasks of product managers include
 prioritization of tasks
 supporting non-technical teams such as marketing and content,
 gathering feedback

Preparing the road-map of a product and making sure the product meets the users’
needs are also responsibilities commonly assigned to product managers

On a daily basis, product managers are responsible for writing user stories, which are
brief descriptions of use cases usually centered around the users’ needs.

Along with that, the acceptance criteria are also commonly supplied by product
managers.

It is also common that in the end of the implementation and verification cycles, the
product manager checks if the user stories are in fact meeting the requirements
previously specified
 Designers

Designers are important because they are not only responsible for creating the
interfaces users will interact with, but also bringing some sort of identity to a
product or even a company to make it consistent among all platforms.

They are somehow the bridge that connects the users to the technology a
product exposes.

When talking about design, two major terms often appear: UI and UX. The
former stands for user interface design and the latter stands for user experience.

Once the designs are finished for some user story, they are handed out to the
product manager for approval.

Several interactions will happen among the product management, design, and
development teams during this process until a final decision is made and
handed to the development teams for further implementation.
 Backend

The backend is the entity of a software product that is responsible for receiving requests
from the client applications and handling them by running on dedicated servers typically
hosted on cloud services or server providers.

Amazon web services, Google Cloud platform, and Microsoft Azure Cloud computing are just
some examples of places you can host the backend of a product.

There are several types of backend web services (e.g., RESTful, WSDL, SOAP) that expose
a set of operations that can be used by frontend applications or even integration services.

RESTful web services is nowadays one of the most popular because it typically relies solely
on the HTTP protocol having no other complex layer, like WSDL and SOAP do, and it’s very
simple to understand and implement.

backend teams focus on exposing operations, so the frontend applications can
retrieve, store, modify, and delete data entities of an application

Another responsibility of the backend is to take care of authentication and
authorization

When the application exposes some sort of online shop or subscription-based
services, the backend is also responsible for handling the payments with the Payment
Service Providers or, also common nowadays, receiving receipts from the mobile
stores (Apple, Google, Amazon), validating those receipts, and acting accordingly.

This means that often backend services work along with other backend services. This
is often referred to as server-side communication or server-to-server communication.
 Frontend

The frontend application of a product is the one that is visible to the
end-user.

We can consider a frontend application a piece of software that runs
on the client side; this includes not only web applications but also
mobile and, more recently, TV applications.

We can split the frontend work in two main modules: representation
and logic.

Representation is what the user sees, the interface, how the
elements are rendered, and how to interact with them
 Quality Assurance (QA)

The quality assurance (QA) department is responsible for making sure
everything that gets to the end user meets the requirements and is working
properly.

There are also other types of testing, but from our experience they are not
found within QA teams but rather within development and operations teams
(DevOps).

Some of them include (1) stress testing—making sure the system performs
during heavy loads and anticipating how the system behaves if those occur;
and (2) performance testing to check if the system is performing as expected
and answering requests within accepted time frames.
DevOps (development + operations)

DevOps teams are responsible for all the operational aspects of the
development and infrastructure.

This means they are responsible for building the continuous
integration and continuous delivery pipelines, managing the servers,
performing migrations, and doing the actual deployments.

These teams are also responsible for making sure the current
infrastructure can handle the expected load and that it still performs
under it by not entering in denial of service.
 a few reasons why the waterfall-based development was
becoming difficult to use in project in recent times:

If at all any later requirement changes becomes unavoidable, then
the cost of accommodating it becomes prohibitively high.

iterative waterfall model is not suitable for development of customized
software. Since customization essentially involves reusing most of the
parts of existing application with minimal change.

Waterfall model is called a heavy weight model, since there is too
much emphasis on producing documentation and usage of tools. This
leads to more project completion time

Waterfall model prescribes almost no customer interactions after the
requirements have been specified.
 AGILE DEVELOPMENT MODELS

Over the last two decades or so, projects using iterative
waterfall-based life cycle models are becoming rare due to
the rapid shift in the characteristics of the software
development projects over time.

Two changes that are becoming noticeable are rapid shift
from development of software products to development of
customised software and the increased emphasis and
scope for reuse.

In the agile model, the requirements are decomposed into many small
parts that can be incrementally developed.

The agile model adopts an iterative approach. Each incremental part is
developed over an iteration.

Each iteration is intended to be small and easily manageable and lasting
for a couple of weeks only.

At a time, only one increment is planned, developed, and then deployed
at the customer site. No long-term plans are made.

The time to complete an iteration is called a time box.

The implication of the term time box is that the end date for an iteration
does not change.

The development team can, however, decide to reduce the delivered
functionality during a time box if necessary.

A central principle of the agile model is the delivery of an increment to
the customer after each time box.
 Essential Idea behind Agile Models

For establishing close contact with the customer during
development and to gain a clear understanding of the domain-
specific issues, each agile project usually includes a customer
representative in the team.

At the end of each iteration, stakeholders and the customer
representative review the progress made and re-evaluate the
requirements.

A distinguishing characteristics of the agile models is frequent
delivery of software increments to the customer

The agile model was primarily designed to help a project to adapt to change
requests quickly.

Thus, a major aim of the agile models is to facilitate quick project completion.

A few popular agile SDLC models are the following:
 Crystal
 Atern (formerly DSDM)
 Feature-driven development
 Scrum
 Extreme programming (XP)
 Lean development
 Unified process
 Principles behind the agile model

Working software over comprehensive documentation

Frequent delivery of incremental versions of the software to the customer in intervals
of few weeks.

Requirement change requests from the customer are encouraged and are efficiently
incorporated.

Having competent team members and enhancing interactions among them is
considered much more important than issues such as usage of sophisticated tools
or strict adherence to a documented process. It is advocated that enhanced
communication among the development team members can be realised through
face-to-face communication rather than through exchange of formal documents.

Continuous interaction with the customer is considered much more important rather
than effective contract negotiation. A customer representatives is required to be a
part of the development team, thus facilitating close, daily co-operation between
customers anddevelopers
 Advantages and disadvantages of
agile methods

The agile methods follows informal communications to clarify issues,
rather than spending significant amounts of time in preparing formal
documents and reviewing them, this eliminates some overhead.

but lack of adequate documentation may lead to several types of
following problems:
 Lack of formal documents leaves scope for confusion and important decisions
taken during different phases can be misinterpreted at later points of time by
different team members.
 In the absence of any formal documents, it becomes difficult to get important
project decisions such as design decisions to be reviewed by external experts.
 When the project completes and the developers disperse, maintenance can
become a problem.
 Extreme Programming Model

Extreme programming (XP) is an important process model under the agile
umbrella and was proposed by Kent Beck in 1999.

The name of this model reflects the fact that it recommends taking these
best practices that have worked well in the past in program development
projects to extreme levels.

This model is based on a rather simple philosophy: ”If something is known
to be beneficial, why not put it to constant use?” Based on this principle, it
puts forward several key practices that need to be practised to the extreme.

most of the key practices that it emphasises were already recognised as
good practices for some time.
 Good practices that need to be
practised to the extrem

Code review: It is good since it helps detect and correct problems most efficiently. It
suggests pair programming as the way to achieve continuous review. In pair
programming, coding is carried out by pairs of programmers. The programmers take
turn in writing programs and while one writes the other reviews code that is being
written.

Testing: Testing code helps to remove bugs and improves its reliability. XP suggests
test-driven development (TDD) to continually write and execute test cases. In the
TDD approach, test cases are written even before any code is written.

Incremental development: Incremental development is good, since it helps to get
customer feedback, and extent of features delivered is a reliable indicator of progress.
It suggests that the team should come up with new increments every few days.

Simplicity: Simplicity makes it easier to develop good quality code, as well as to
test and debug it. Therefore, one should try to create the simplest code that
makes the basic functionality being written to work. For creating the simplest
code, one can ignore the aspects such as efficiency, reliability, maintainability,
etc. Once the simplest thing works, other aspects can be introduced through
refactoring.

Design: Since having a good quality design is important to develop a good
quality solution, everybody should design daily. This can be achieved through
refactoring, whereby a working code is improved for efficiency and
maintainability.

Integration testing: It is important since it helps identify the bugs at the
interfaces of different functionalities. To this end, extreme programming suggests
that the developers should achieve continuous integration, by building and
performing integration testing several times a day
 Applicability of extreme
programming model

Projects involving new technology or research pro
jects: In this case, the requirements change rapidly
and unforeseen technical problems need to be
resolved.

Small projects: Extreme programming was
proposed in the context of small teams as face to
face meeting is easier to achieve.
 Project characteristics not suited to
development using agile models

Stable requirements: Conventional development models are
more suited to use in projects characterised by stable
requirements. For such projects, it is known that few changes, if
at all, will occur. Therefore, process models such as iterative
waterfall model that involve making long-term plans during
project initiation can meaningfully be used.

Mission critical or safety critical systems: In the development
of such systems, the traditional SDLC models are usually
preferred to ensure reliability
 Scrum Model

In the scrum model, a project is divided into small parts of work that can be
incrementally developed and delivered over time boxes that are called sprints.

The software therefore gets developed over a series of manageable chunks.

Each sprint typically takes only a couple of weeks to complete.

At the end of each sprint, stakeholders and team members meet to assess the
progress made and the stakeholders suggest to the development team any
changes needed to features that have already been developed and any overall
improvements that they might feel necessary.

In the scrum model, the team members assume three fundamental roles—
software owner, scrum master, and team member.

The software owner is responsible for communicating the customers vision of the
software to the development team.

The main principles of scrum rely on:
 Cross-functional teams
 Time boxed iterations called sprints
 Product roadmap
 Product backlog
 Sprint planning meetings
 Retrospective meetings
 Daily standup meetings
 Tasks estimations
 Burndown chart analysis and velocity calculation
 Scrum master, product owner, and business owner roles