Laboratório de Desenvolvimento de Software

(1)

FEUP/MIEIC ● Nuno Flores ● Laboratório de Desenvolvimento de Software, 2010/11

Laboratório de

Desenvolvimento de Software

FEUP/MIEIC, 2010/11 Nuno Flores nuno.flores at fe.up.pt Rosaldo Rossetti rossetti at fe.up.pt Filipe Correia filipe.correia at fe.up.pt http://paginas.fe.up.pt/~nflores/dokuwiki/doku.php?id=teaching:1011:ldso

(2)

MIEIC/LDSO, 2010/11

 

4º Ano/ 1º Semestre

 

ECTS:

• 7 (189h)

 

Horas/Semana:

• 2h teóricas, 3h práticas

 

Aulas Teóricas:

• Nuno Flores (NHF)

 

Aulas Práticas: 5 turmas

• Nuno Flores (4MIEIC1)

• Rosaldo Rossetti (4MIEIC2, 4MIEIC4) • Filipe Correira (4MIEIC3, 4MIEIC5)

(3)

Pré-requisitos

 

Mínimos

• Conhecimentos de engenharia de software • Experiência de desenvolvimento de software

 

Preferenciais

(4)

Objectivos Gerais

  Aplicação dum processo de Engenharia de Software ao

desenvolvimento completo de uma aplicação abrangendo a

especificação de requisitos, desenho de software, implementação, integração, teste e documentação.

  Dotar os participantes com conhecimentos e experiência prática sobre as práticas de desenvolvimento ágil de software: planeamento de

iterações, testes unitários, refactoring, pattern-based design, autoria colectiva de código, programação em pares, integração contínua.

  Utilização de ferramentas de desenvolvimento de software adequadas à metodologia em uso e que permitam o acompanhamento do

desenvolvimento do produto durante todo o seu ciclo de vida.

  Análise das variantes mais conhecidas de processos ágeis.

  Apreensão dos conhecimentos primordialmente através da sua

aplicação prática num caso de estudo real a desenvolver ao longo do semestre.

  Os participantes aprenderão a trabalhar em equipa, a integrar outros intervenientes do projecto em decisões de desenho e planeamento, e a delegar, negociar e rever estas decisões em grupo.

(5)

Objectivos Específicos

  Aplicação dos conhecimentos anteriormente adquiridos pelos alunos em disciplinas nas áreas de Engenharia de Software, Bases de Dados, Interfaces Gráficas, Sistemas Operativos, Linguagens de Programação e Inteligência Artificial.

  Utilização de APIs de grande escala contendo pacotes de classes, introduzir a computação baseada em componentes e problemas relacionados com a integração aplicacional.

  Análise e configuração de um processo de desenvolvimento de software adaptado às características de um projecto específico.

(6)

Avaliação

 

Avaliação distribuída sem exame final.

 

Componentes de Avaliação

• Projecto - resultados da fase I – 17/Outubro, peso 15%; • Projecto - resultados da fase II – 14/Novembro, peso 15%; • Projecto - resultados das fases III –17/Dezembro, peso 35%; • Projecto – integração, peso 10%;

• Projecto - avaliação contínua do sítio web - 5%; • Processo de desenvolvimento – 10%

• Avaliação contínua do desempenho individual - 10%.

 

A classificação a qualquer componente de avaliação pode

variar de elemento para elemento do mesmo grupo, tendo

como base a opinião dos docentes e a auto-avaliação

(7)

Obtenção de Frequência

 

É exigida uma nota mínima de 40% a qualquer dos itens

da avaliação.

 

Avaliação Especial (TE, DA, ...)

• Alunos de regimes especiais (incluindo trabalhadores-estudantes e militares) são abrangidos pelos mesmos métodos de avaliação.

 

Melhoria de Classificação Final/Distribuída

• Melhorias de classificação envolverão um trabalho adicional, contendo todas as parcelas atrás referidas, e uma prova oral adicional; melhorias de classificação pedidas no ano lectivo

seguinte envolverão a realização de todos os trabalhos previstos para os alunos desse ano lectivo.

(8)

Bibliografia

  Extreme Programming Explained by Kent Beck, Addison-Wesley Pub Co; 1st edition

(October 5, 1999), ISBN:0201616416

  Extreme Programming Installed, by Ron Jeffries, Ann Anderson, Chet Hendrickson,

Ronald E. Jeffries, Addison-Wesley Professional; 1st edition (October 13, 2000), ISBN: 0201708426

  Planning Extreme Programming, by Kent Beck, Martin Fowler, Addison-Wesley

Professional; 1st edition (October 13, 2000), ISBN:0201710919

  Refactoring, by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts,

Addison-Wesley Pub Co; 1st edition (June 28, 1999), ISBN:0201485672

  Adaptive Software Development: A Collaborative Approach to Managing Complex Systems, by James A. Highsmith III, Dorset House Publishing Company, Incorporated

(December 1, 1999), ISBN:0932633404

  Agile Software Development, by Alistair Cockburn, Addison-Wesley Pub Co; 1st edition

(December 15, 2001), ISBN:0201699699

  Agile Software Development, Principles, Patterns, and Practices, by Robert C. Martin,

Prentice Hall; 1st edition (October 15, 2002), ISBN:0135974445

  Test Driven Development, by Kent Beck, Addison-Wesley Professional; 1st edition

(November 8, 2002), ISBN:0321146530

(9)

Questões?

(10)

(11)

“Agile”

 

In Merriam-Webster dictionary, “agile” means:

• 1 : marked by ready ability to move with quick easy grace

• 2 : having a quick resourceful and adaptable character <an agile mind>

 

In “agile software development”, it means “ability to

respond to change”.

(12)

Changes

 

from Requirements and Priorities

• We learn from the solution: our true needs and how to communicate them better

• Business environment and conditions change • Business processes are re-engineered

 

from Technology and Tools

• We often learn new things on the fly

• Actual features may vary from expectations • Combinations create compatibility issues • New versions are released

(13)

Changes...

 

from People

• Teams change over time

• Team interactions may come complex • Individual behavior can be unpredictable

 

from software complexity

• too much dependencies

• Solutions need recursive feedback and validation • difficulty to predict activities and dependencies

(14)

Key Concepts about Processes

 

The challenge is to help on achieving:

•  “high quality” of the developed product •  “high productivity” of development •  “good predictability" of process results

 

Define who? what? when? why? how?

•  Roles, artefacts, activities, techniques, practices and tools

 

Means to an End

•  Suggest practices to help improve team capabilities •  Introduce formalities to improve team discipline

•  Force documenting to improve team comunication and knowledge

 

Which practices, formalities and documentation to use?

• No “silver bullet”!

• It depends on the project... • Balance them to your needs...

(15)

Heavyweight

Processes

 

“heavyweight” processes are often based on a lot of

documentation and bureaucracy.

 

Very preventive; try to avoid expensive situations instead of

optimizing them.

 

The alternatives to avoid such situations are most of the time

 

The requirements must be exaustively analysed.

 

Search and removal of errors before appearing in the code.

 

Code is not considered very important, but only a translation

from models.

 

Problems:

•  reduced feedback •  over-engineering

(16)

Agile Process advantages

 

Respond to change and leverage learning

 

Deliver the highest business value (ROI)

 

Decrease time-to-delivery

 

Increase productivity and efficiency

 

Produce better quality solutions

(17)

Discipline vs Agility

 

Both have pros and cons.

 

We should adopt the most simple process that guarantees

the success of the project, considering the its

characteristics in terms of requirements dynamism, team

size, expertise and culture, product criticality, etc.

(18)

Controlling Software Projects

 

Four control variables require balancing

• Resources • Time

• Scope • Quality

 

It is not advisable to set a priori the value of all variables

simultaneously, if we want a successful project.

(19)

The Resource Variable

 

Staffing is usually the least effective variable to

adjust.

• Staffing increases have long lead times. • Increased intensity has diminishing returns. • Team culture requires some degree of stability.

 

Tools and technology can provide benefits.

• Effective tools provide continuing benefits.

• Front-end costs need to be carefully amortized. • The wrong tools and technology increase friction.

(20)

The Time Variable

 

Can be the most painful variable to adjust

• Early commitments are usually date-based. • Target dates are often the most important

objective.

• Within a date boundary, there’s only so much time.

(21)

The Scope Variable

 

Can be the most effective variable to adjust

• Can adjust scope breadth – what’s included. • Can adjust scope depth – refinement.

• Partial scope can often generate immediate returns.

• It is often preferable to reach a date with

partial scope completely finished, rather than complete scope partially finished.

(22)

Project Balance in an Agile Process

 

Sustainable resource management

• Stable teams • Steady pace

• Favor high ROI tools and technology

 

Fixed time management

• Time-boxed development cycles

 

Adaptive scope management

(23)

“Heroic” vs. “Collaborative”

 

Heroic development emphasizes individuals

• Activities assigned to individuals • Project results heavily dependent on

individual performance • Increases “keyhole” risks

 

Collaborative development emphasizes teams

• Teams self-organize activities to meet goals • Teams leverage diverse skills

(24)

Management by Facilitation

 

Traditional “Command and Control Strategy”

• Decisions made by central authorities • Activities delegated

• Manager controls activities

 

Replaced by “Facilitation and Empowerment Strategy”

• Decisions made by those with the most info • Activities accepted

• Team self-manages and adapts

(25)

(26)

Examples

 

Adaptive Software Development (ASD)

 

Agile Modeling

 

Crystal methods

 

Dynamic System Development Methodology (DSDM)

 

eXtreme Programming (XP)

 

Feature Driven Development

 

Lean Development

 

Scrum

 

Open source software development.

(27)

The Agile Alliance

 

2001 – representatives from agile processes meet in

Snowbird, Utah.

 

Agreed on a “manifesto” of values and principles:

• Individuals and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation

• Responding to change over following a plan

 

“That is, while there value in the items on the right, we

value the items on the left more.”

(28)

“The Agile Manifesto – I”

We are uncovering better ways of developing software by

doing it and helping others to do it.

Through this work we have come to value:

• Individuals and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation

• Responding to change over following a plan

That is, while there is value in the items on

the right, we value the items on the left more.

(29)

“The Agile Manifesto – II”

 

Our highest priority is to satisfy the customer

through early and continuous delivery

of valuable software.

 

Welcome changing requirements, even late in

development. Agile processes harness change for

the customer's competitive advantage.

 

Deliver working software frequently, from a

couple of weeks to a couple of months, with a

preference to the shorter timescale.

 

Business people and developers must work

together daily throughout the project.

(30)

“The Agile Manifesto – III”

 

Build projects around motivated individuals. Give them the

environment and support they need, and trust them to get

the job done.

 

The most efficient and effective method of conveying

information to and within a development team is

face-to-face conversation.

 

Working software is the primary measure of progress.

 

Agile processes promote sustainable development. The

sponsors, developers, and users should be able to

(31)

“The Agile Manifesto – IV”

 

Continuous attention to technical excellence and good

design enhances agility.

 

Simplicity – the art of maximizing the amount of work not

done – is essential.

 

The best architectures, requirements, and designs

emerge from self-organizing teams.

 

At regular intervals, the team reflects on how to become

more effective, then tunes and adjusts its behavior

(32)

Agile vs Heavyweight processes

 

Both have advantages and disadvantages.

 

We should adopt the most simple process capable of

achieving project’s success.

 

We should find the perfect balance between “discipline”

and “agility”.

 

Five factors must be analysed before decision:

• Criticality (errors impact)

• Dimension (number of team elements)

• Culture (more suitable to success in a “chaotic” or “ordered” context)

• Dinamism (frequency of requirements change) • Team technical capabilities

(33)

Processo de

Desenvolvimento em LDSO

 

papéis, artefactos, actividades, técnicas, práticas e

ferramentas

(34)

Papéis

  Gestor: responsável máximo pelo projecto (docentes).

  Engenheiro: analista, arquitecto, programador, testes, designer de interfaces pessoa-computador (alunos).

  “Coach”: lidera a equipa técnica, lidera a execução do projecto, ao nível micro (alunos).

  “Webmaster”: responsável pelo sítio no wiki (alunos).

  Gestor de comunicação: funções de gestão e comunicação de informação (alunos).

  Cliente: tem uma visão clara do valor relativo das diversas funcionalidades do produto em desenvolvimento (docentes).

(35)

Artefactos

 

Relatório de Especificação de Requisitos

 

Protótipo da Interface com o Utilizador

 

Plano de Testes de Aceitação

 

Relatório de Projecto Alto Nível

 

Protótipo Vertical

 

Produto

 

Manual do Utilizador

 

Relatório de Testes de Aceitação

(36)

Técnicas, práticas e ferramentas

 

Planeamento

• (Re)planeamento iterativo no início de cada fase (equipa e cliente). • Testes de aceitação pelo cliente (ideia-chave).