Laboratório de Desenvolvimento de...

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


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)


Pré-requisitos

  Mínimos • Conhecimentos de engenharia de software • Experiência de desenvolvimento de software

  Preferenciais • Interesse especial em processos de desenvolvimento de software


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.


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.

  Capacidade de gestão de projectos ágeis.


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 interna de cada grupo.


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.


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

  Diversos artigos.

Questões?



Introdução


“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”.


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


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


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...


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 more expensive than the original problems.

  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


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

  Create a more fulfilling development culture


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.


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.

  “scope” is often the most important variable to control


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.


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.


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.


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 • Feedback-based scope adjustments


“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 • Teams mitigate keyhole risks


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 • Organization ensures supportive environment


Agile Processes


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.

  Agile version of Rational Unified Process


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.”


“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.

http://www.agilealliance.org/


“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.


“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 maintain a constant pace indefinitely.


“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 accordingly.


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


Processo de Desenvolvimento em LDSO   papéis, artefactos, actividades, técnicas, práticas e

ferramentas


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).

  Consultor: especialista reconhecido externo à equipa (docentes, outros).


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

  Documentação Técnica de Desenvolvimento


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).

  Desenvolvimento • Incremental e iterativo.

  Comunicação • Wiki para a documentação. • CVS para o código-fonte. • Outras infras-estruturas (redes sociais, chats, etc...)


Software

  Eclipse|Visual Studio (ambiente de desenvolvimento)

  xUnit|nUnit (ferramenta para testes unitários)

  Wiki (ferramenta de documentação colaborativa)

  CVS|SVN (ferramenta de controlo de versões)

  Bugzilla|Trac (ferramenta apoio à manutenção)

  Pivotal Tracker (ferramenta de gestão/monitorização)

  Ferramentas de modelação (EclipseUML, Enterprise Architect, etc.)

  PostgreSQL|MySQL|Oracle|*

  Outras...

Laboratório de Desenvolvimento de...

Documents

Transcript of Laboratório de Desenvolvimento de...