Metodologia Ágil: Feature Driven Development

Tamanho: px
Começar a partir da página:

Download "Metodologia Ágil: Feature Driven Development"

Transcrição

1 Metodologia Ágil: Feature Driven Development António Barbosa 1, Bruno Azevedo 2, Bruno Pereira 3, Pedro Campos 4, Pedro Santos 5 1 Estudante da LEIC 2 Estudante da LEIC 3 Estudante da LEIC 4 Estudante da LEIC 5 Estudante da LEIC Resumo. Feature Driven Development(FDD) é uma metodologia ágil de desenvolvimento de software. Esta metodologia permite desenvolver um sistema de forma rápida e permite facilmente introduzir novas features (funcionalidades) a este. Uma nova feature demora entre duas horas a duas semanas a ser concluída. O facto de no FDD usar-se processos simples proporciona uma rápida exposição do projecto a novos elementos que venham a fazer parte da equipa, assim como torna o trabalho menos monótono, uma vez que se esta sempre a iniciar/acabar um processo. 1.Metodologias Ágeis 1.1. O aparecimento das metodologias ágeis As metodologias ágeis surgiram em resposta ao problema dos atrasos do desenvolvimentos software, e aos cancelamentos por obsolescência, ou seja um programa que demore muito tempo a ser desenvolvido, tem tendência a ficar desactualizado se seguir os objectivos propostos no seu planeamento. Houve outros avanços que se esperavam resolver os problemas anteriores, como os métodos estruturados em 1980 ou as metodologias orientadas a objectos, mas os problemas mantinham-se. Também se achou que a solução passaria pelo melhorar o processamento do software, mas só a introdução das metodologias de desenvolvimento ágil trouxeram solução aos problemas, visto a chave era a adaptabilidade e não apenas o aperfeiçoamento dos métodos existentes.

2 Assim, esta metodologia veio a reduzir a taxa de abandono dos projectos a meio e proporcionou um rápido desenvolvimento e um cumprir sistemático dos objectivos Introdução às metodologias ágeis. A definição de metodologias ágeis de desenvolvimento de software foi criada durante os anos 90 como reacção contra os métodos de desenvolvimento "pesados", tipificados pelo modelo em cascata. Estes métodos eram então vistos como burocráticos e lentos e criavam uma contradição em relação à ideia que o trabalho dos engenheiros de software é eficaz. Inicialmente, as metodologias ágeis eram denominadas como métodos de desenvolvimento "leves", mas em 2001 alguns elementos da comunidade encontraram-se na estância de sky de Snowbird e criaram o "The Agile Manifesto" no qual adoptaram o nome Métodologias Ágeis. Este Manifesto foi criado com o intuito de fazer a união entre as diferentes metodologias ágeis, e é apresentado como sendo a definição canónica do desenvolvimento ágil. O Manifesto é apresentado a seguir na sua forma original: Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others 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. Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas 2001, the above authors this declaration may be freely copied in any form, but only in its entirety through this notice.

3 1.3.Comparação com outros tipos de metodologias É comum afirmar-se que os métodos ágeis de desenvolvimento de software são o oposto de metodologias disciplinadas e planeadas; no entanto tal afirmação é uma má interpretação da adaptabilidade pedida. Uma distinção mais precisa pode ser feita através da disposição dos métodos seguindo uma linha desde "Adaptáveis" a "Preditivas" <--Ágil--> <--Iterativa--> <--Cascata--> < > Adaptável Preditiva Métodos adaptáveis focam-se na adaptação a constantes mudanças. Uma equipa sabe o trabalho que lhe cabe na fase actual do projecto mas desconhece o passo seguinte, que vai sendo decidido durante o decorrer de cada fase. Métodos preditivos fazem o planeamento detalhado do futuro. Uma equipa preditiva define exactamente que tarefas irão ser desempenhadas e que características irão ser desenvolvidas durante toda a duração do processo de desenvolvimento e a sequência de fases a passar. Uma equipa preditiva tem dificuldades em lidar com mudanças, pois normalmente o plano foi optimizado tendo em conta o destino original, sendo que qualquer alteração pode fazer com que determinado trabalho terá que ser feito de maneira completamente distinta. As equipas preditivas geralmente instituem uma comissão de controlo de mudanças, constituída por elementos com responsabilidades altas para o projecto, tais como clientes, gestores ou líderes de equipas, que asseguram que apenas as mudanças mais importantes serão feitas. Desenvolvimento iterativo Os métodos ágeis partilham o objectivo dos métodos iterativos de criar partes do software que possam ser lançadas em curtos períodos tempo. Diferem na duração dos períodos de tempo, sendo que nos métodos ágeis o tempo é medido em semanas e nos métodos iterativos é medido em meses. A maioria dos métodos ágeis diferem também pois têm em conta estritamente o tempo, ao invés de um objectivo planeado. Modelo em cascata O modelo em cascata é o mais preditivo de todos, consiste em seguir a sequência rígida e planeada de recolher requisitos, analisar, desenhar, codificar e testar. O progresso é medido no cumprimento dos requisitos, planos de testes e revisões de código. O modelo em cascata pode resultar num esforço substancial de integração no fim do ciclo, que se estende por um período de tempo que pode ir de vários meses a vários anos. O tamanho e a dificuldade deste esforço é uma das causas do falhanço do projecto em cascata. Contrariamente, os métodos ágeis produzem aplicações completamente funcionais (mas a uma pequena percentagem do total) a cada semana. A ideia é obter uma aplicação inacabada mas funcional antes da final, que vai sendo continuamente desenvolvida.

4 Algumas equipas ágeis usam uma das ideias do modelo em cascata: o repetir de um ciclo em cada iteração. Análise do risco de utilização de Métodos Ágeis e Preditivos Para diminuir o risco na utilização de métodos ágeis e preditivos pode-se verificar onde os diferentes métodos se enquadram melhor: Métodos ágeis - Pouca crítica à implementação - Equipa de desenvolvimento constituída por elementos experientes - Grandes mudanças nos requisitos - Equipa de desenvolvimento constituída por poucos elementos - Cultura que prospera na falta de organização. Métodos preditivos - Muita crítica à implementação - Equipa de desenvolvimento constituída por elementos inexperientes - Poucas mudanças nos requisitos - Equipa de desenvolvimento constituída por muitos elementos - Cultura que exige ordem e organização. Ao analisar o projecto tendo em conta estes enquadramentos pode-se avaliar o risco de utilização de métodos ágeis ou preditivos. 2.Feature Driven Development 2.1. Agentes/Actores desta metodologia. No FDD existem vários papéis que os membros da equipa podem assumir. O mesmo papel pode ser assumido por vários membros e cada membro pode assumir vários papais simultaneamente. Existem três tipos de papéis: papéis principais, papéis secundários e papéis adicionais. Os papéis principais são: Gestor de Projecto, Chefe de Design, Gestor de Desenvolvimento, Programador Chefe, Dono de Classe, Especialista da Área. Gestor do Projecto O gestor do projecto é quem trata das questões financeiras e administrativas do projecto. É ele que tem a última palavra sobre os objectivos, o pessoal e a calendarização do projecto. Cabe-lhe também assegurar as condições de trabalho óptimas, para aumentar o rendimento e evitar as distracções.

5 Chefe de Design O chefe de design é responsável por toda a arquitectura do projecto e dá as sessões de design, onde expõe as suas decisões às equipas. Gestor de Desenvolvimento O gestor de desenvolvimento lidera as actividades de desenvolvimento do código do dia-a-dia. É responsável por resolver os problemas de recursos ou conflitos entre a equipa que venham surgindo. É um papel bastante ligado aos de gestor do projecto e pode ser executado pelo mesmo membro. Programador Chefe O programador chefe é o responsável por uma equipa pequena e pela divisão e atribuição de trabalho entre os membros dela. Deve ser um programador experiente pois cabe-lhe a escolha das features a implementar em cada iteração e as respectivas classes e métodos necessários. Para este efeito deve colaborar com o chefe de design. Vai ser ele também que faz o relatório da actividade da equipa semanalmente e trata dos problemas técnicos e de recursos com os outros programadores chefe. Dono de Classe O dono de classe é um membro de uma equipa sob o comando de um programador chefe e está responsável pela arquitectura, implementação, teste e documentação de uma determinada classe. Em cada iteração fará parte das equipas cujas features envolvam a sua classe. Especialista da Área O especialista da área é alguém que conhece o assunto sobre o qual a aplicação actua. Está envolvido na decisão do preço do programa e é ele que assegura que o sistema seja competente dentro da área, passando a quem desenvolve o programa os conhecimentos necessários. O especialista da área pode ser um cliente, um analista de negócio, um patrocinador ou um utilizador. Os papéis secundários são: Gestor de Actividade, Guru da Linguagem, Engenheiro de Builds e Administrador de Sistema. Gestor de Actividade O gestor de actividade recebe os relatórios de actividade os vários programadores chefe e vai mantendo o gestor do projecto informado. Guru da Linguagem O guru da linguagem é um papel importante quando se trabalho com linguagens ou tecnologias novas. Ele é responsável por dominá-las. Engenheiro de Builds O engenheiro de builds é o responsável por criar e manter o processo de build para as várias versões incluindo a documentação respectiva.

6 Administrador do Sistema O administrador do sistema configura, gere e resolve problemas nos servidores e redes usadas. Os papéis adicionais são: Tester, Suporte, Documentador Tester O Tester deve experimentar todos os casos de utilização exaustivamente e verificar se o sistema é sólido, resistente a erros e se preenche os requisitos do cliente. Suporte O trabalho de suporte consiste em converter a informação para o formato necessário a um novo sistema e a novas releases do programa. Documentador O documentador cria os manuais técnicos e de utilização. 2.2Descrição dos processos Esta metodologia FDD consiste em cinco processos sequenciais. O uso de processos tem várias vantagens: - O facto de nos FDD s usarem processos simples e bem definidos faz com que o mover novas utilidades (features) para projectos grandes seja fácil. Pois é como fazer algo simples várias vezes. No desenvolvimento de processos complexos, deve-se dividir em N processos simples, o permite que o progresso do projecto seja mais rápido. - A integração de novos elementos nas equipas é rápida, pois o facto de os processos serem simples faz com que seja fácil a compreensão destes por parte dos novos membros. - O facto de os processos serem simples, faz com que a equipa esteja sempre concentrada no trabalho uma vez que estão constantemente a acabar/iniciar um novo processo. Não causa uma monotonia do trabalho. Como tinha sido referido acima esta metodologia consiste em cinco processos sequenciais sendo estes: 1. Develop an Overall Model (Trata-se de utilizar os requisitos e funcionalidades pedidas pelo cliente e fazer o estudo destas de forma a fazer a estrutura do sistema. Baseia-se no desenho do sistema); 2. Build by Features list (Constrói uma lista de features detalhada e ordenada por ordem hierárquica); 3. Plan By Feature (Trata-se de planear como devem ser desenvolvidas as features); 4. Design by Feature (Analisa uma feature em particular e estuda-a de forma a criar-se um detalhado diagrama sequencial, que será os passos a seguir para construir uma feature);

7 5. Build By Feature (Faz todas as alterações necessárias para ser possível construir uma feature). Em baixo esta uma descrição detalhada destes processos Develop an Overall Model Este processo inicia-se quando o cliente está pronto para dar início ao projecto. Este tem de alguma forma uma lista de requerimentos, que poderão estar ou não anotados. O cliente indica quais os requisitos que quer ver compridos pelo sistema. Cabe às equipas de desenvolvimento analisar o sistema anterior e verificar se todos os requisitos foram especificados pelo cliente, sugerir novos requisitos e colocar todas as questões que possam ainda não ter sido respondidas, ou que tenham sido esquecidas. O cliente chega com os seus requisitos e apresenta-os ao desenvolvedores. Estes em conjunto com os especialistas da área e sobre a liderança de um modelador de componentes e/ou de objectos experiente (chefe de design), trabalham em conjunto neste processo. Os especialistas da área apresentam um guia inicial e preçário do sistema e do seu contexto. Que em conjunto com os desenvolvedores criam a estrutura inicial do sistema, que deve ser seguido desde o início. Depois de desenvolvido este esqueleto os especialistas da área voltam a fazer o guia inicial, sendo desta vez mais detalhado. Entretanto sempre que os membros deste processo trabalham em conjunto em pequenas equipas, ou seja, quando trabalham em áreas mais especificas a determinado grupo, e que a participação de outros membros seria desnecessária, os resultados desse trabalho são adicionados ao modelo comum, que sofre os respectivos ajustes para se manter sempre viável ao longo de todo o processo. Neste processo é necessário de compreender perfeitamente o que o cliente deseja, e de o explicar a todo o grupo de trabalho. Para que todos saibam o que tenham de o fazer e como o devem fazer. Este plano é descrito mais detalhadamente nos processos seguintes. Para melhor compreender o sistema e para mais facilmente o explicar ao grupo de trabalho, constrói-se um relatório de requisitos, assim como um diagrama de classes, preferencialmente ordenado por ordem descendente de importância, classes, ligações, métodos e os atributos. As classes e as ligações são o conteúdo da estrutura do sistema. Os métodos expressam as funcionalidades e são o material para construir a lista de features a desenvolver. Também são tomadas notas acerca de diferentes modelos que poderiam ser tomados como alternativas Build a Feature List A equipa de desenvolvimento identifica todas as features, e agrupa-as por ordem hierárquica. Nesta ordem é tomada em conta a prioridade de cada feature, sendo

8 prioritária uma feature que o cliente pediu ou que se ache que lhe agradará ver feita e uma feature de que outras dependam. As features definidas com baixa prioridade são muitas vezes features extra, mas que certamente iriam valorizar o projecto. Estas poderão ser desenvolvidas no futuro. Ainda neste processo também se dividem pequenas equipas especialidades em cada uma das áreas de cada conjunto de features. Os especialistas da área poderão participar em algumas das sessões referentes a este processo. A divisão das features é feita com base em certos critérios: divide-se as features por áreas em que estas se enquadrem, e de acordo com as classes envolvidas. Se estes conjuntos de features demorarem mais de duas semanas a serem desenvolvidos este conjunto de features ou uma feature individual, são divididos em pequenos passos. Isto para de duas em duas semanas se poder analisar o projecto e ver os progressos. Chama-se de feature (funcionalidade) uma acção com o seguinte formato: <action> the <result><by for of to> a(n)<objecto> Conjunto de features: - <action><-ing>a(n)<object> Um maior conjunto de features: <object> management Nota: Quando um objecto é uma pessoa, lugar, ou coisa, inclui-se papeis, datas, ou intervalos de tempo, ou catalogo entrada/descrição. Em resumo: Neste processo, entra a provisória lista de features desenvolvidas no processo anterior e sai uma detalhada lista de features agrupada em maiores conjuntos de features e conjuntos de features. Lista esta que terá de ser revista e aprovada pelo desenvolvedor assim como pelo arquitecto chefe Plan by feature Usando a lista detalhada e ordenada por prioridade das features, criada no processo anterior, o chefe do projecto, o chefe de design e o chefe dos programadores estabelecem a estrutura para o método Desenho por Funcionalidade, Construção por Funcionalidade /Design by Feature, Build by Feature. Isto é, este grupo de planeamento, determinam a sequência, e o conjunto inicial de datas para dar como terminada cada conjunto de features e do mais importante conjunto de features. Este planeamento é repartido, atribuindo de acordo com o desenvolvimento sequencial e o peso de cada feature como guia e associa as classes do sistema aos responsáveis pelas classes. A cada chefe de programação é fornecida a lista de features a desenvolver. Como temos vindo a observar esta abordagem à construção de sistemas é um planeamento top-down, em que os desenvolvedores têm a oportunidade de aceder aos planos. Há que ter em conta que cada feature a desenvolver não devera demorar mais de duas semanas. E que nesta atribuição de trabalhos certos desenvolvedores poderão estar de desacordo com este método, pois certamente prefeririam ter uma data para entregar todo o trabalho, mas esta é uma metodologia ágil e não se baseia nesse

9 método. À que portanto convence-los a apresentar os resultados assim como eles estão planeados. Em contraste, outros desenvolvedores poderão aceitar muito bem isto, pois estão desejosos de apresentar trabalho, mas não avaliam de uma forma cuidada o trabalho que terão pela frente. Ou seja poderão atrasar-se com o desenvolvimento de determinada feature. À que ter em atenção de no processo anterior ter sido dividido todas as features que darão mais complexas em features mais simples. Isto para de duas em duas semanas ser possível ter sempre conteúdo novo, de forma a mostrar o nosso trabalho. No final deste processo deveremos ter um plano já revisto e aprovado pelo desenvolvedor chefe e pelo chefe de design. Deveremos ter também já uma previsão de quando o projecto estará terminado. Assim como uma data em que os conjuntos de features deverão estar completas. O mesmo para cada classe. Existe um truque que se pensa que acelera o desenvolvimento das features. Este truque consiste em criar um grupo denominado Future Feature Boar (FFB). Este truque faz com que os desenvolvedores sejam como que os bons da fita, enquanto que os FFB são os maus da fita. O truque consiste em incentivar os bons da fita, de maneira a que a sua motivação esteja alta e desta maneira desenvolvam o seu trabalho de uma maneira mais rápida Design by Feature (DBF) Este processo ira ser repetido tantas vezes quantas o número de features a desenvolver. Isto porque é necessário fazer o desenho da estrutura para cada feature. Iremos analisar este processo com algum cuidado, isto porque apesar de o que ele faz ser fácil de entender, este tem de analisar vários documentos construídos noutros processos, assim como trocar informação com outros AGENTES. Comecemos então a analisar este processo, o programador chefe começa por identificar as classes que estão envolvidas nestas features. E contacta os respectivos responsáveis dessas classes, estes escrevem/actualizam a classe e os protótipos dos métodos que esta contém, actualizando o diagrama sequencial. Estes responsáveis incluem tipo de parâmetros, tipo de valores retornados, excepções e mensagens enviadas. Dependendo da complexidade da feature o programador chefe poderá consultar os especialistas da área para que estes lhe dêem uma visão acerca da área de domínio que esta feature engloba, esta informação será incluída na construção do diagrama, mas não fará necessariamente parte da implementação. A equipa de programadores poderá também consultar documentos da lista de features ou de outro documento, de forma a extrair informação detalhada acerca desta feature. Depois de consultar todos os documentos que se ache necessário para a compreensão da feature, o programador consulta o diagrama sequencial construído num processo anterior, e com base em toda a informação recolhida este constrói um diagrama de sequência detalhado e formal para esta feature. Este diagrama é adicionado ao projecto modelo.

10 A equipa de programadores toma nota de todas as alternativas, decisões e notas que achem relevantes. Antes de dar por terminado este processo é necessário garantir que o programador chefe assim como arquitecto chefe revejam e aprovem: - O diagrama sequencial e o de classes actualizado; - As classes e os métodos actualizados; - As notas de consideração da equipa de programadores; - Os documentos de referências de features, caso haja necessidade. Caso todos estes documentos sejam aprovados passamos ao último processo Build By Feature Build by Feature (BBF) Tal como no processo anterior, este processo ira ser repetido para cada feature, pois todas as features terão de ser construídas. Este processo começa por estudar a informação proveniente do processo anterior e seguidamente começa a construção da feature. Nomeadamente começam os responsáveis pelas classes associadas a esta feature a construir os métodos que esta feature ira necessitar. Estes responsáveis irão também estender os testes de uso desta classe assim como os testes unitários da mesma. A equipa de desenvolvimento desta feature inspecciona o código, antes ou depois de estruturados os testes unitários. Quando o código é implementado com sucesso e inspeccionado, o responsável da classe verifica a classe assim como as configurações de manutenção do sistema. Quando todas as classes referentes a esta feature forem verificadas, o programador chefe indica que o código para desenvolver esta feature esta disponivel. Esta alteração é registada na lista de features. Para dar este processo como terminado o programador chefe devera rever e aprovar: - A implementação, inspecção e teste dos métodos; - Os testes unitários para cada método; - A verificação das classes por parte dos seus responsáveis; - A promoção das features; - A actualização da lista de features realizada por si próprio. 2.3.Ferramentas de aplicações A utilização do FDD num projecto, torna recomendável o uso de uma ferramenta que permita organizar todas as implementações que se deseja criar sendo possível a inclusão e discriminação de todas as componentes necessárias para as novas funcionalidades. Uma ferramenta deste tipo deve ter alguns requisitos necessários para facilitar a utilização de FDD.

11 Como já foi referido, é necessário que este apresente uma discriminação de todas as features a ser implementadas como também das suas respectivas componentes, encontrando-se estas devidamente documentadas, no sentido de facilitar a equipa do projecto, como também por equipas futuras, após estas features se encontrem concluídas. Como tal, proporciona uma visão da arquitectura geral do programa, o que permite a tomada de consciência da estrutura do futuro programa, permitindo a não ocorrência da repetição de features semelhantes, ou mesmo a criação de componentes em duplicado. A visão da arquitectura do programa também permite que as novas implementações se possam inserir em packages já existentes, ou mesmo em novos packages. Estas ferramentas também devem incorporar a indicação do tempo necessário para a sua implementação, como também da equipa ou as pessoas responsáveis pela sua implementação. Esta visão geral, permite que cada grupo possa opinar sobre a implementação das novas features sugerindo outras soluções, ou mesmo o refinamento das mesmas. Nesta fase, torna-se possível a apresentação ao cliente do futuro programa que permita concordar, ou discordar da sua implementação, como também do seu tempo necessário e obviamente dos custos a si associados. A utilização destas ferramentas permite maximizar as vantagens do FDD, essencialmente, no sentido de evitar custos extra, como também de tempo gasto em criação de componentes desnecessárias. Este tipo de ferramentas é normalmente utilizado nas primeiras três fases da utilização do FDD, permitindo a sua planificação. Outras funcionalidades que se podem incluir neste tipo de ferramentas é a descrição de todos os testes necessários para testar cada feature, como também a sua duração e o seu resultado. Isto permite, que quando se interligar as implementações, se possa obter os mesmos resultados que se obtinham quando as features se encontravam desligadas entre si. A implementação de um sistema de prioridades, que permite maximizar o tempo num projecto, deixando para trás as implementações menos importantes. Outra funcionalidade, possível é um gráfico de decorrência de tempo, entre a percentagem de trabalho previsto com a percentagem de trabalho realizado, permitindo a verificação do trabalho, se encontrar dentro dos prazos previstos, ou se por outro lado é necessário a reverificação do tempo necessário para o desenvolvimento da nova implementação. Uma funcionalidade pouco usual, mas também útil, é a possibilidade de, a dado momento, ser possível obter o número de features já criadas, permitindo a obtenção de indicadores de performance no sentido de avaliar os grupos ou as pessoas, da equipa do projecto, permitindo a sua futura reorganização para futuros projectos, maximizando os recursos humanos. Este tipo de ferramentas apresenta um senão. A sua máxima utilização, na planificação de novos projectos, torna-se eficaz, quando todas as implementações, desde o início do projecto, se encontram descritas, não fazendo parte do actual desenvolvimento. O nome de algumas ferramentas que podem ser utilizadas é o FDD Manager, MagicDraw, OptimalJ, Poseidon, Rose, Simply Objects, Together, Enterprise

12 Architect, entre outras. Algumas destas ferramentas são bastantes simples, outras mais complicadas, sendo também open source, ou mesmo de utilização paga. 2.4.Comparação entre FDD e XP Após um breve estudo das metodologias ágeis mais conhecidas, verificamos que a que se assemelhava a FDD era extreme Programming (XP), sendo esta a mais interessante de comparar. Vamos então apresentar as semelhanças entre FDD e XP. Tanto FDD como XP, foram desenhadas de modo a que as equipas possam mostrar resultados mais rapidamente sem comprometer a qualidade. São processos altamente iterativos e orientados a resultados. São ainda metodologias que acabam com a separação entre os analistas, os desenhadores e implementadores. Estes novos processos em conjunto com novas ferramentas, vão permitir que a analise, concepção, código, teste e desenvolvimento sejam feitos em simultâneo. Quais são então as diferenças entre FDD e XP? Tamanho das Equipas O XP foi desenhado para projectos com equipas de dois a dez programadores. FDD foi inicialmente usado com equipas de 16 a 20 colaboradores com diferentes habilitações, ambientes culturais e experiência. A FDD foi desenhada para ser aplicável a equipas bastante maiores, sendo esse tamanho limitado pelo número de Programadores Chefe existentes. Modelo Em FDD, quando os developers tomam conhecimento dos requisitos, começam a formar uma imagem mental do sistema, assumindo e estimando partindo dessa base. Desenvolvendo um objecto modelo domínio global, força essas assumpções a serem expostas, de modo a que os erros sejam corrigidos e uma melhor compreensão comum seja formada XP usa a analogia de conduzir um carro. Conduzir requer uma continuidade de pequenos ajustes de percurso. Não se pode simplesmente orientar o carro na direcção correcta e carregar no acelerador. Um objecto modelo de domínio é o mapa que nos guia no percurso. Pode prevenir-nos de andarmos em círculos. O objecto modelo domínio dá-nos uma forma sobre a qual se vão adicionar funções, funcionalidade por funcionalidade.

13 Código colectivo, ou classe colectiva. XP promove que o código seja colectivo. Cada developer pode adicionar ou alterar qualquer parte do código à medida que ai sendo necessário. Mas geralmente este colectivismo degenera num código sem proprietários. Para projectos pequenos resulta bastantes vezes, mas para projectos de maior dimensão raramente funciona. XP garante 3 benefícios derivados do colectivismo do código. 1. Não é necessário esperar por alguém para fazer a alteração necessária ao código. 2. Código demasiado complexo é eliminado, pois se alguém que o encontre, vai tentar simplifica-lo. Posto isto, os programadores deixam de criar código cuja complexidade não consigam justificar. 3. Código colectivo espalha o conhecimento do sistema por toda a equipa, reduzindo o risco caso um membro critico da equipa saia. Em FDD, também se resolveu estes problemas, enquanto se manteve as vantagens do código individual. 1. Por definição, todos os donos de classes que necessitam de updates para o desenvolvimento de uma determinada feature, são membros da equipa de features. Por outras palavras, a equipa de features controla todo o código que necessita ser mudado para uma determinada feature, o que minimiza o tempo de espera para que alguém altere esse código. 2. Em FDD todo o desenho de baixo nível é feito dentro das equipas de features. O problema do desenvolvimento por surpresa, quando um developer entrega código do que foi acordado, é detectado nas inspecção de código pela equipa de features. Código demasiado complexo é também detectado da mesma maneira, antes de entrar no sistema. 3. Apesar dos donos de classes trabalharem apenas nas classes que lhes pertencem, donos de classes próximas, trabalham geralmente na mesma equipa de features. Todos têm conhecimento das classes que lhes estão próximas. O conhecimento é separado em blocos bem definidos e estruturados, e não espalhado ao calhas. Inspecção e Programação em pares Inspecções ao desenho e ao código, quando bem feitas são mais eficazes do que a fase de teste. Outras vantagens são: 1. Os developers aprendem técnicas uns com os outros, e o código tem tendência a seguir um standard. 2. XP usa programação em pares, para garantir um nível contínuo de desenho e inspecção de código.

14 Todo o desenho de baixo nível, assim como o código é feito em pares. Isto revela-se bastante mais eficaz do que um único developer criar código sem nenhum tipo de inspecção. Em FDD promove-se as inspecções pela equipa de features. O nível de formalidade é deixado ao cargo do chefe de programação. Este processo é mais demorado, mas tem algumas vantagens em relação à programação em pares. 1. O código é inspeccionado por outra pessoa, que detecta falsos pressupostos feitos pelo programador. 2. Um programador chefe está presente para garantir que as técnicas usadas são boas técnicas. 3. Dá um certo tempo de descanso ao developer, enquanto o código está as ser inspeccionado. Não há razão para os elementos de uma equipa de features não se organizarem em pares. É comum ver-se dois elementos a trabalhar juntos, quando tal é vantajoso. Uma vantagem das equipas de features é que uma feature só está completa quando a equipa acaba o trabalho. É do interesse dos seus elemento ajudarem-se mutuamente. Testes Em FDD o teste das unidades é garantido como uma parte da fase Build by Feature. Não estão definidos os mecanismos ou os níveis de formalidade para o teste das unidades. Deixa-se ao cargo do programador chefe definir o que é apropriado. É aceitável usar técnicas de teste de unidades de XP em FDD. Quando novas builds são criadas regularmente ou até continuamente, faz sentido haver um maior número de testes que possam ser usados. Em FDD, não se especificou isto, visto que a tecnologia e os recursos diferem muito de projecto para projecto. Em muitos casos é muito difícil criar um grupo isolado de testes independentes que possam ser corridos num intervalo de tempo razoável. Referências Artigos sobre metodologias ágeis e outros mais específicos sobre FDD s, nomeadamente: E ainda a consulta a página respectiva a esta metodologia:

Métodos Ágeis de Desenvolvimento de Software

Métodos Ágeis de Desenvolvimento de Software Conteúdo Métodos Ágeis de Desenvolvimento de Software Engenharia de Software Profa. Elisa Yumi Nakagawa 2. Semestre 2005 Material inicialmente elaborado por André Figueiredo e mantido por pesquisadores

Leia mais

INTRODUÇÃO A PROJETOS

INTRODUÇÃO A PROJETOS INTRODUÇÃO A PROJETOS Professor: Rômulo César romulodandrade@gmail.com www.romulocesar.com.br GESTÃO DE PROJETOS Gestão Ágil de projetos Gestão de projetos com PMBOK GESTÃO ÁGIL DE PROJETOS GESTÃO ÁGIL

Leia mais

extreme Programming extreme Programming (XP) Metodologia Ágil Partes do XP Communication (comunicação) 1. Valores do XP

extreme Programming extreme Programming (XP) Metodologia Ágil Partes do XP Communication (comunicação) 1. Valores do XP extreme Programming extreme Programming (XP) Metodologia ágil para equipes pequenas a médias desenvolvendo software com requesitos vagos ou que mudam freqüentemente. [Beck 2000] Em XP, codificação é principal

Leia mais

Desenvolvimento Ágil com XP e Scrum. Guilherme Chapiewski guilherme.chapiewski@gmail.com http://gc.blog.br

Desenvolvimento Ágil com XP e Scrum. Guilherme Chapiewski guilherme.chapiewski@gmail.com http://gc.blog.br Desenvolvimento Ágil com XP e Scrum Guilherme Chapiewski guilherme.chapiewski@gmail.com http://gc.blog.br WTF?!? Porque ágil? Quem usa isso? Google Yahoo! Electronic Arts Lockheed Martin Phillips Siemens

Leia mais

2012. Quinta Conferência de Qualidade de Software ASR Consultoria

2012. Quinta Conferência de Qualidade de Software ASR Consultoria 1 Visão CMMI do Ágil 2 Visão CMMI do Ágil 3 Visão Ágil do CMMI 4 Visão Ágil do CMMI 5 Visão Ágil do CMMI 6 Manifesto para Desenvolvimento Ágil de Software Estamos descobrindo maneiras melhores de desenvolver

Leia mais

Daniel Wildt -dwildt@gmail.com

Daniel Wildt -dwildt@gmail.com Metodologias Ágeis e Software Livre Daniel Wildt -dwildt@gmail.com Bacharel em Informática (PUCRS) Professor Universitário (FACENSA) Mais de 10 anos de experiência em Desenvolvimento de Software, hoje

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Metodologias para Desenvolvimento de Software XP e SCRUM Prof. MSc. Edilberto Silva prof.edilberto.silva@gmail.com http://www.edilms.eti.br Agenda Desenvolvimento Ágil de Software

Leia mais

SCRUM e Requisitos Ágeis

SCRUM e Requisitos Ágeis SCRUM e Requisitos Ágeis Régis Simão /44 Agenda Métodos Ágeis SCRUM Modelo de Negócio Definição do Produto Planejamento e Execução de uma Release 2 /44 Agenda Métodos Ágeis SCRUM Modelo de Negócio Definição

Leia mais

Modelo Cascata ou Clássico

Modelo Cascata ou Clássico Modelo Cascata ou Clássico INTRODUÇÃO O modelo clássico ou cascata, que também é conhecido por abordagem top-down, foi proposto por Royce em 1970. Até meados da década de 1980 foi o único modelo com aceitação

Leia mais

Desenvolvimento ágil de software

Desenvolvimento ágil de software Desenvolvimento ágil de software Desenvolvimento ágil de software (do inglês Agile software development) ou Método ágil é um conjunto de metodologias de desenvolvimento de software. O desenvolvimento ágil,

Leia mais

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Desenvolvimento Ágil Modelos Ágeis. Profª Esp.: Maysa de Moura Gonzaga

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Desenvolvimento Ágil Modelos Ágeis. Profª Esp.: Maysa de Moura Gonzaga DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Desenvolvimento Ágil Modelos Ágeis Profª Esp.: Maysa de Moura Gonzaga 2º Semestre / 2011 Extreme Programming (XP); DAS (Desenvolvimento Adaptativo de Software)

Leia mais

Estudo sobre Desenvolvimento de Software Utilizando o Framework Ágil Scrum

Estudo sobre Desenvolvimento de Software Utilizando o Framework Ágil Scrum Estudo sobre Desenvolvimento de Software Utilizando o Framework Ágil Scrum Andre Scarmagnani 1, Fabricio C. Mota 1, Isaac da Silva 1, Matheus de C. Madalozzo 1, Regis S. Onishi 1, Luciano S. Cardoso 1

Leia mais

abraçando a mudança extreme Programming Helder da Rocha www.argonavis.com.br

abraçando a mudança extreme Programming Helder da Rocha www.argonavis.com.br abraçando a mudança extreme Programming Helder da Rocha www.argonavis.com.br 1 Desenvolvimento de software no passado Engenharia de software tradicional Analisar, projetar, e só depois começar a construir

Leia mais

Análise de Sistemas. Conceito de análise de sistemas

Análise de Sistemas. Conceito de análise de sistemas Análise de Sistemas Conceito de análise de sistemas Sistema: Conjunto de partes organizadas (estruturadas) que concorrem para atingir um (ou mais) objectivos. Sistema de informação (SI): sub-sistema de

Leia mais

Processo de análise estruturada - Abordagem clássica

Processo de análise estruturada - Abordagem clássica Processo de análise estruturada - Abordagem clássica Desenvolver modelo físico actual Modelo físico actual Modelos a desenvolver tendo em conta a abordagem clássica Desenvolver modelo lógico actual Modelo

Leia mais

MANIFESTO ÁGIL. Esses conceitos aproximam-se melhor com a forma que pequenas e médias organizações trabalham e respondem à mudanças.

MANIFESTO ÁGIL. Esses conceitos aproximam-se melhor com a forma que pequenas e médias organizações trabalham e respondem à mudanças. METODOLOGIAS ÁGEIS SURGIMENTO As metodologias ágeis surgiram em resposta ao problema dos atrasos no desenvolvimento de software e aos cancelamentos, devido ao fato dos sistemas demorarem muito tempo para

Leia mais

MÓDULO 9 METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS

MÓDULO 9 METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS MÓDULO 9 METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS O termo metodologia não possui uma definição amplamente aceita, sendo entendido na maioria das vezes como um conjunto de passos e procedimentos que

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Curso de Sistemas de Informação Karla Donato Fook karladf@ifma.edu.br DESU / DAI 2015 Desenvolvimento Rápido de Software 2 1 Para quê o Desenvolvimento Rápido de Software? Os negócios

Leia mais

5. Métodos ágeis de desenvolvimento de software

5. Métodos ágeis de desenvolvimento de software Engenharia de Software 5. Métodos ágeis de desenvolvimento de software Nuno Miguel Gil Fonseca nuno.fonseca@estgoh.ipc.pt Desenvolver e entregar software o mais rapidamente possível é hoje em dia um dos

Leia mais

GESTÃO DO CONHECIMENTO PARA O DESENVOLVIMENTO DE SOFTWARE COM MÉTODOS ÁGEIS

GESTÃO DO CONHECIMENTO PARA O DESENVOLVIMENTO DE SOFTWARE COM MÉTODOS ÁGEIS GESTÃO DO CONHECIMENTO PARA O DESENVOLVIMENTO DE SOFTWARE COM MÉTODOS ÁGEIS Jeandro Maiko Perceval 1 Carlos Mario Dal Col Zeve2 Anderson Ricardo Yanzer Cabral ² RESUMO Este artigo apresenta conceitos sobre

Leia mais

Processo de Desenvolvimento de Software. Unidade V Modelagem de PDS. Luiz Leão luizleao@gmail.com http://www.luizleao.com

Processo de Desenvolvimento de Software. Unidade V Modelagem de PDS. Luiz Leão luizleao@gmail.com http://www.luizleao.com Processo de Desenvolvimento de Software Luiz Leão luizleao@gmail.com http://www.luizleao.com Conteúdo Programático desta aula Modelo Cascata (Waterfall) ou TOP DOWN. Modelo Iterativo. Metodologia Ágil.

Leia mais

Quais são as características de um projeto?

Quais são as características de um projeto? Metodologias ágeis Flávio Steffens de Castro Projetos? Quais são as características de um projeto? Temporário (início e fim) Objetivo (produto, serviço e resultado) Único Recursos limitados Planejados,

Leia mais

Metodologias Ágeis. Aécio Costa

Metodologias Ágeis. Aécio Costa Metodologias Ágeis Aécio Costa Metodologias Ágeis Problema: Processo de desenvolvimento de Software Imprevisível e complicado. Empírico: Aceita imprevisibilidade, porém tem mecanismos de ação corretiva.

Leia mais

CURSO DE ANÁLISE DE SISTEMAS. ENGENHARIA DE SOFTWARE Prof. Giuliano Prado de Morais Giglio

CURSO DE ANÁLISE DE SISTEMAS. ENGENHARIA DE SOFTWARE Prof. Giuliano Prado de Morais Giglio UNIVERSIDADE SALGADO DE OLIVEIRA CURSO DE ANÁLISE DE SISTEMAS ENGENHARIA DE SOFTWARE Prof. Giuliano Prado de Morais Giglio UNIDADE 03 MÉTODOS ÁGEIS DE DESENVOLVIMENTO DE SOFTWARE O Desafio do Desenvolvimento

Leia mais

METODOLOGIA ÁGIL. Lílian Simão Oliveira

METODOLOGIA ÁGIL. Lílian Simão Oliveira METODOLOGIA ÁGIL Lílian Simão Oliveira Fonte: Pressman, 2004 Aulas Prof. Auxiliadora Freire e Sabrina Schürhaus Alexandre Amorin Por quê???? Principais Causas Uso das Funcionalidades Processos empírico

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Desenho de Software Departamento de Matemática Universidade dos Açores Hélia Guerra helia@uac.pt desenho Desenho (dicionário Priberam on-line) do Lat.! designu s. m., arte de representar

Leia mais

CAPÍTULO 6 AS ETAPAS DO PROJECTO

CAPÍTULO 6 AS ETAPAS DO PROJECTO Processos de Gestão ADC/DEI/FCTUC 1999/2000 Cap. 6. As etapas do projecto 1 6.1. As etapas básicas CAPÍTULO 6 AS ETAPAS DO PROJECTO IDEIA!!! FORMULAÇÃO ANÁLISE DE VIABILIDADE DECISÃO PLANIFICAÇÃO EXECUÇÃO

Leia mais

PRIMAVERA BUSINESS SOFTWARE SOLUTIONS, SA

PRIMAVERA BUSINESS SOFTWARE SOLUTIONS, SA PRIMAVERA BUSINESS SOFTWARE SOLUTIONS, SA Introdução Nesta edição do Catálogo de Serviços apresentamos os vários tipos de serviços que compõe a actual oferta da Primavera na área dos serviços de consultoria.

Leia mais

05/05/2010. Década de 60: a chamada Crise do Software

05/05/2010. Década de 60: a chamada Crise do Software Pressman, Roger S. Software Engineering: A Practiotioner s Approach. Editora: McGraw- Hill. Ano: 2001. Edição: 5 Introdução Sommerville, Ian. SW Engineering. Editora: Addison Wesley. Ano: 2003. Edição:

Leia mais

Gestão dos Níveis de Serviço

Gestão dos Níveis de Serviço A Gestão dos Níveis de Serviço (SLM) Os sistemas e tecnologias de informação e comunicação têm nas empresas um papel cada vez mais importante evoluindo, hoje em dia, para níveis mais elevados de funcionamento

Leia mais

DSI é o processo cujo objetivo é introduzir mudanças num sistema de informação, com objetivo de melhorar o seu desempenho.

DSI é o processo cujo objetivo é introduzir mudanças num sistema de informação, com objetivo de melhorar o seu desempenho. - DSI DSI é o processo cujo objetivo é introduzir mudanças num sistema de informação, com objetivo de melhorar o seu desempenho. Preocupação: Problema técnicos Mudança na natureza e conteúdo do trabalho

Leia mais

Manifesto Ágil - Princípios

Manifesto Ágil - Princípios USP UNIVERSIDADE DO ESTADO DE SÃO PAULO Métodos Ágeis Alunos: Rogério Guaraci dos Santos - rgsantos@ime.usp.br Giulian Dalton Luz - gdaltonl@ime.usp.br Manifesto Ágil - Princípios Indivíduos e interações

Leia mais

Estrutura da Norma. 0 Introdução 0.1 Generalidades. ISO 9001:2001 Sistemas de Gestão da Qualidade Requisitos. Gestão da Qualidade 2005

Estrutura da Norma. 0 Introdução 0.1 Generalidades. ISO 9001:2001 Sistemas de Gestão da Qualidade Requisitos. Gestão da Qualidade 2005 ISO 9001:2001 Sistemas de Gestão da Qualidade Requisitos Gestão da Qualidade 2005 Estrutura da Norma 0. Introdução 1. Campo de Aplicação 2. Referência Normativa 3. Termos e Definições 4. Sistema de Gestão

Leia mais

Órgão / Unidade: Tribunal Regional Eleitoral do Rio de Janeiro (TRE-RJ) / Seção de Desenvolvimento de Sistemas (SEDSIS) E-mail:

Órgão / Unidade: Tribunal Regional Eleitoral do Rio de Janeiro (TRE-RJ) / Seção de Desenvolvimento de Sistemas (SEDSIS) E-mail: Órgão / Unidade: Tribunal Regional Eleitoral do Rio de Janeiro (TRE-RJ) / Seção de Desenvolvimento de Sistemas (SEDSIS) E-mail: sonia.moreira@tre-rj.jus.br, avelino.gomes@tre-rj.jus.br, carlos.willians@tre-rj.jus.br

Leia mais

Gestão de Projectos. Processos e Aproximações de Desenvolvimento de Projectos. Informáticos. Selecção da Aproximação de Projectos

Gestão de Projectos. Processos e Aproximações de Desenvolvimento de Projectos. Informáticos. Selecção da Aproximação de Projectos Gestão de Projectos Informáticos Processos e Aproximações de Desenvolvimento de Projectos Informáticos Prof. Alberto Silva & Dra. RosárioBernardo Departamento de Engenharia Informática Selecção da Aproximação

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Processos de software Departamento de Matemática Universidade dos Açores Hélia Guerra helia@uac.pt Processo Um processo é uma série de etapas envolvendo actividades, restrições e

Leia mais

Metodologias Ágeis. Gerenciando e Desenvolvendo Projetos de forma eficiente. Gabriel Verta 0767948 Rafael Reimberg 0767701 Vinicius Quaiato - 0767697

Metodologias Ágeis. Gerenciando e Desenvolvendo Projetos de forma eficiente. Gabriel Verta 0767948 Rafael Reimberg 0767701 Vinicius Quaiato - 0767697 Metodologias Ágeis Gerenciando e Desenvolvendo Projetos de forma eficiente Gabriel Verta 0767948 Rafael Reimberg 0767701 Vinicius Quaiato - 0767697 Introdução Ao longo dos anos a indústria de desenvolvimento

Leia mais

1 Serviços de Planeamento e Transformação Empresarial Os Serviços de Planeamento e Transformação Empresarial da SAP incluem:

1 Serviços de Planeamento e Transformação Empresarial Os Serviços de Planeamento e Transformação Empresarial da SAP incluem: Descrição de Serviços Serviços de Planeamento e Empresarial Os Serviços de Planeamento e Empresarial fornecem serviços de consultoria e prototipagem para facilitar a agenda do Licenciado relativa à inovação

Leia mais

Sistemas de Informação no sector da Construção. João Poças Martins, FEUP/GEQUALTEC, 2011 1

Sistemas de Informação no sector da Construção. João Poças Martins, FEUP/GEQUALTEC, 2011 1 Sistemas de Informação no sector da Construção João Poças Martins, FEUP/GEQUALTEC, 2011 1 Sistemas de Informação no sector da Construção 1. SI na Construção. Introdução 2. ERP 3. BIM 4. Outras aplicações

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Processos de software Departamento de Matemática Universidade dos Açores Hélia Guerra helia@uac.pt Processo Um processo é uma série de etapas envolvendo actividades, restrições e

Leia mais

Plataforma de Gestão de Actualizações de Software Descrição do Problema

Plataforma de Gestão de Actualizações de Software Descrição do Problema Plataforma de Gestão de Actualizações de Software Descrição do Problema Pedro Miguel Barros Morgado Índice Introdução... 3 Ponto.C... 4 Descrição do Problema... 5 Bibliografia... 7 2 Introdução No mundo

Leia mais

Gestão de Configurações II

Gestão de Configurações II Gestão de Configurações II Bibliografia Livro: Software Configuration Management Patterns: Effective Teamwork, Practical Integration Gestão de Projecto 14 Padrões de Gestão Os padrões de gestão de configurações

Leia mais

Metodologias Ágeis de Desenvolvimento de Software

Metodologias Ágeis de Desenvolvimento de Software "Antes de imprimir pense em sua responsabilidade e compromisso com o MEIO AMBIENTE." Engenharia de Software de Desenvolvimento de Software Givanaldo Rocha de Souza givanaldo.rocha@ifrn.edu.br http://docente.ifrn.edu.br/givanaldorocha

Leia mais

Manual Prático de Avaliação do Desempenho

Manual Prático de Avaliação do Desempenho Tendo em conta o planeamento das actividades do serviço, deve ser acordado conjuntamente entre o superior hierárquico e o trabalhador, o plano individual e os objectivos definidos para o período em avaliação.

Leia mais

Universidade Fernando Pessoa

Universidade Fernando Pessoa Objectivos da cadeira reconhecer, criar e explorar um recurso de informação usar tecnologias de informação emergentes para a gestão eficaz do recurso informação discutir o impacto das tecnologias de informação

Leia mais

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Introdução Modelos de Processo de Desenvolvimento de Software Os modelos de processos de desenvolvimento de software surgiram pela necessidade de dar resposta às

Leia mais

PHC TeamControl CS. A gestão de equipas e de departamentos

PHC TeamControl CS. A gestão de equipas e de departamentos PHC TeamControl CS A gestão de equipas e de departamentos A solução que permite concretizar projectos no tempo previsto e nos valores orçamentados contemplando: planeamento; gestão; coordenação; colaboração

Leia mais

Com metodologias de desenvolvimento

Com metodologias de desenvolvimento Sociedade demanda grande quantidade de sistemas/aplicações software complexo, sistemas distribuídos, heterogêneos requisitos mutantes (todo ano, todo mês, todo dia) Mas, infelizmente, não há gente suficiente

Leia mais

Feature-Driven Development

Feature-Driven Development FDD Feature-Driven Development Descrição dos Processos Requisitos Concepção e Planejamento Mais forma que conteúdo Desenvolver um Modelo Abrangente Construir a Lista de Features Planejar por

Leia mais

Livraria dos Mestres

Livraria dos Mestres Gestão de Projectos Informáticos Livraria dos Mestres 3ª Entrega Empresa B Grupo nº 11 João Maurício nº 53919 Ricardo Carapeto nº 53942 Nuno Almeida nº 53946 Page 1 of 28 Índice 1. Sumário para a Gestão

Leia mais

Engenharia de Software LEIC/LERC, 3 o Ano, 2 o Semestre, Ano lectivo de 2009/2010

Engenharia de Software LEIC/LERC, 3 o Ano, 2 o Semestre, Ano lectivo de 2009/2010 UNIVERSIDADE TÉCNICA DE LISBOA INSTITUTO SUPERIOR TÉCNICO Engenharia de Software LEIC/LERC, 3 o Ano, 2 o Semestre, Ano lectivo de 2009/2010 Segundo Exame 16 de Julho de 2010, 9:00H 11:30H (Versão A) Nome:

Leia mais

Carta de Segurança da Informação

Carta de Segurança da Informação Estrutura Nacional de Segurança da Informação (ENSI) Fevereiro 2005 Versão 1.0 Público Confidencial O PRESENTE DOCUMENTO NÃO PRESTA QUALQUER GARANTIA, SEJA QUAL FOR A SUA NATUREZA. Todo e qualquer produto

Leia mais

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO Santa Maria, 10 de Outubro de 2013. Revisão aula anterior Documento de Requisitos Estrutura Padrões Template Descoberta

Leia mais

PHC TeamControl CS. A gestão de equipas e de departamentos

PHC TeamControl CS. A gestão de equipas e de departamentos PHC TeamControl CS A gestão de equipas e de departamentos A solução que permite concretizar projetos no tempo previsto e nos valores orçamentados contemplando: planeamento; gestão; coordenação; colaboração

Leia mais

Este sistema é sustentado por 14 pilares: Elemento 1 Liderança, Responsabilidade e Gestão

Este sistema é sustentado por 14 pilares: Elemento 1 Liderança, Responsabilidade e Gestão Este sistema é sustentado por 14 pilares: Elemento 1 Liderança, Responsabilidade e Gestão Como as pessoas tendem a imitar os seus líderes, estes devem-se empenhar e comprometer-se com o QSSA, para servirem

Leia mais

PRD Tecnologia de Gestão Ltda. Julho/2008

PRD Tecnologia de Gestão Ltda. Julho/2008 O Processo de Desenvolvimento Telescope Julho/2008 Página 1 Sumário Introdução...3 O desenvolvimento de software tradicional...3 O problema da produtividade...3 O problema da portabilidade...6 O problema

Leia mais

Um Modelo de Gestão de Projectos

Um Modelo de Gestão de Projectos 3 Um Modelo de Gestão de Projectos 3.1 Fases do Modelo de Gestão de Projectos Dois reputados consultores e investigadores em gestão de projectos de software Joseph Weiss e Robert Wysocki descobriram que

Leia mais

Iteração 2 Design inicial

Iteração 2 Design inicial Universidade de Aveiro Departamento de Electrónica, Telecomunicações e Informática Engenharia de Software Iteração 2 Design inicial Projecto: FX-Center Grupo: BEDS David Pacheco (nº 32665) Cesário Lucas

Leia mais

Engenharia de Software

Engenharia de Software CENTRO UNIVERSITÁRIO NOVE DE JULHO Profº. Edson T. França edson.franca@uninove.br Software Sistemas Conjunto de elementos, entre os quais haja alguma relação Disposição das partes ou dos elementos de um

Leia mais

UTILIZAÇÃO DAS METODOLOGIAS ÁGEIS XP E SCRUM PARA O DESENVOLVIMENTO RÁPIDO DE APLICAÇÕES

UTILIZAÇÃO DAS METODOLOGIAS ÁGEIS XP E SCRUM PARA O DESENVOLVIMENTO RÁPIDO DE APLICAÇÕES UTILIZAÇÃO DAS METODOLOGIAS ÁGEIS XP E SCRUM PARA O DESENVOLVIMENTO RÁPIDO DE APLICAÇÕES Marcelo Augusto Lima Painka¹, Késsia Rita da Costa Marchi¹ ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil

Leia mais

Estrutura da Norma. 0 Introdução 0.1 Generalidades. ISO 9001:2008 Sistemas de Gestão da Qualidade Requisitos

Estrutura da Norma. 0 Introdução 0.1 Generalidades. ISO 9001:2008 Sistemas de Gestão da Qualidade Requisitos ISO 9001:2008 Sistemas de Gestão da Qualidade Requisitos Gestão da Qualidade e Auditorias (Mestrado em Engenharia Alimentar) Gestão da Qualidade (Mestrado em Biocombustívies) ESAC/João Noronha Novembro

Leia mais

O Manifesto Ágil. Formação da Aliança Ágil

O Manifesto Ágil. Formação da Aliança Ágil O Manifesto Ágil Facilitar mudanças é mais efetivo do que tentar preveni-las. Aprender a confiar nas suas habilidades para responder a eventos imprevisíveis é mais importante do que confiar nas suas habilidades

Leia mais

Controlo interno das instituições de auditoria do governo

Controlo interno das instituições de auditoria do governo SEMINÁRIO SOBRE O DESENVOLVIMENTO DE TÉCNICAS DE AUDITORIA 26 27.02.2009 Controlo interno das instituições de auditoria do governo Autor: Lau Tak Kun (Terence) Comissariado da Auditoria de Macau Índice

Leia mais

ISEL REGULAMENTO DO GABINETE DE AUDITORIA INTERNA DO INSTITUTO SUPERIOR DE ENGENHARIA DE LISBOA. Aprovado pelo Presidente do ISEL em LISBOA

ISEL REGULAMENTO DO GABINETE DE AUDITORIA INTERNA DO INSTITUTO SUPERIOR DE ENGENHARIA DE LISBOA. Aprovado pelo Presidente do ISEL em LISBOA REGULAMENTO DO DO INSTITUTO SUPERIOR DE ENGENHARIA DE LISBOA Aprovado pelo Presidente do ISEL em INTRODUÇÃO No âmbito da gestão pública a Auditoria Interna é uma alavanca de modernização e um instrumento

Leia mais

REGULAMENTO DO PERFIL DE COMPETÊNCIAS DO ENFERMEIRO DE CUIDADOS GERAIS

REGULAMENTO DO PERFIL DE COMPETÊNCIAS DO ENFERMEIRO DE CUIDADOS GERAIS ÍNDICE Regulamento do Perfil de Competências do Enfermeiro de Cuidados Gerais Preâmbulo...05 Artigo 1.º - Objecto...07 Artigo 2.º - Finalidades...07 Artigo 3.º - Conceitos...08 Artigo 4.º - Domínios das

Leia mais

Engenharia de Software. Apostila I >>> Introdução à ES - HEngholmJr

Engenharia de Software. Apostila I >>> Introdução à ES - HEngholmJr Engenharia de Software Apostila I >>> Introdução à ES - HEngholmJr Histórico de Revisões Data Versão Descrição Autor 12/08/2014 1.0 Criação da primeira versão HEngholmJr Agenda Introdução à Engenharia

Leia mais

Engenharia de Software I. Aula 15: Metodologias Ágeis. Prof. Márcio D. Puntel marcio@puntel.org

Engenharia de Software I. Aula 15: Metodologias Ágeis. Prof. Márcio D. Puntel marcio@puntel.org Engenharia de Software I Aula 15: Metodologias Ágeis Prof. Márcio D. Puntel marcio@puntel.org Março - 2008 Antes... Manifesto Mudança de contratos Foco nas premissas... 2 Algumas metodologias Extreme Programming

Leia mais

METODOLOGIA DE GERENCIAMENTO DE PROJETOS SCRUM: ESTUDO DE REVISÃO. Bruno Edgar Fuhr 1

METODOLOGIA DE GERENCIAMENTO DE PROJETOS SCRUM: ESTUDO DE REVISÃO. Bruno Edgar Fuhr 1 METODOLOGIA DE GERENCIAMENTO DE PROJETOS SCRUM: ESTUDO DE REVISÃO Bruno Edgar Fuhr 1 Resumo: O atual mercado de sistemas informatizados exige das empresas de desenvolvimento, um produto que tenha ao mesmo

Leia mais

Desenvolvimento Ágil de Software

Desenvolvimento Ágil de Software Desenvolvimento Ágil de Software Métodos ágeis (Sommerville) As empresas operam em um ambiente global, com mudanças rápidas. Softwares fazem parte de quase todas as operações de negócios. O desenvolvimento

Leia mais

Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática

Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática Disciplina: INF5008 Prof.: (monalessa@inf.ufes.br) Conteúdo 8. Metodologias

Leia mais

GERENCIAMENTO ÁGIL DE PROJETOS UMA NOVA ABORDAGEM PARA OS DESAFIOS DE SEMPRE

GERENCIAMENTO ÁGIL DE PROJETOS UMA NOVA ABORDAGEM PARA OS DESAFIOS DE SEMPRE GERENCIAMENTO ÁGIL DE PROJETOS UMA NOVA ABORDAGEM PARA OS DESAFIOS DE SEMPRE LEANDRO FARIA PMP, PMI-ACP, CSM, ITIL, FCE, MCPD, MCITP, MCT WWW.LEANDROFARIA.COM.BR WWW.STEFANINI.COM 1 SOBRE LEANDRO FARIA

Leia mais

Processo do Serviços de Manutenção de Sistemas de Informação

Processo do Serviços de Manutenção de Sistemas de Informação Processo do Serviços de Manutenção de Sistemas de Informação 070112=SINFIC HM Processo Manutencao MSI.doc, Página 1 Ex.mo(s) Senhor(es): A SINFIC agradece a possibilidade de poder apresentar uma proposta

Leia mais

SIPTEST System Intelligent Process Testing. Estado da arte na prática de testes tendo como referência o CMMI

SIPTEST System Intelligent Process Testing. Estado da arte na prática de testes tendo como referência o CMMI SIPTEST System Intelligent Process Testing. Estado da arte na prática de testes tendo como referência o CMMI SIPTEST - System Intelligent Testing Link Consulting,SA Pág. 0 de 10 Índice 1 Introdução...

Leia mais

Curso Geral de Gestão. Pós Graduação

Curso Geral de Gestão. Pós Graduação Curso Geral de Gestão Pós Graduação Curso Geral de Gestão Pós Graduação Participamos num processo acelerado de transformações sociais, políticas e tecnológicas que alteram radicalmente o contexto e as

Leia mais

3 ao Quadrado - Agenda Web

3 ao Quadrado - Agenda Web 3 ao Quadrado - Agenda Web Relatório de Gestão de Projectos de Software - Grupo A - LEIC 2001/2002 http://gnomo.fe.up.pt/gps01a João Montenegro - ei97023@fe.up.pt André Teixeira - ei97024@fe.up.pt Carlos

Leia mais

DESENVOLVIMENTO DE SISTEMAS SOFTWARE FASE 1 GRUPO 10. Vítor Martins 47121. Rui Fonseca 47081. David Barbosa 47076. Ricardo Boas 47023

DESENVOLVIMENTO DE SISTEMAS SOFTWARE FASE 1 GRUPO 10. Vítor Martins 47121. Rui Fonseca 47081. David Barbosa 47076. Ricardo Boas 47023 DESENVOLVIMENTO DE SISTEMAS SOFTWARE FASE 1 David Barbosa 47076 Ricardo Boas 47023 Rui Fonseca 47081 Vítor Martins 47121 GRUPO 10 2009/2010 1 Índice 1. Introdução... 2 1.1 Visão Geral do Problema... 2

Leia mais

Desenvolvimento ágil de Software

Desenvolvimento ágil de Software Desenvolvimento ágil de Software Joaquim Lopes Júnior joaquim@f6sistemas.com.br Diretor PHPrime Training e F6 Sistemas Bacharel em C. Da Computação UFMG 2006 Mestrado (em andamento) UFMG 2009 Desenvolvimento

Leia mais

GESTÃO de PROJECTOS. Gestor de Projectos Informáticos. Luís Manuel Borges Gouveia 1

GESTÃO de PROJECTOS. Gestor de Projectos Informáticos. Luís Manuel Borges Gouveia 1 GESTÃO de PROJECTOS Gestor de Projectos Informáticos Luís Manuel Borges Gouveia 1 Iniciar o projecto estabelecer objectivos definir alvos estabelecer a estratégia conceber a estrutura de base do trabalho

Leia mais

4.2. UML Diagramas de classes

4.2. UML Diagramas de classes Engenharia de Software 4.2. UML Diagramas de classes Nuno Miguel Gil Fonseca nuno.fonseca@estgoh.ipc.pt Um diagrama de classes serve para modelar o vocabulário de um sistema Construído e refinado ao longo

Leia mais

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil. Profª Esp.: Maysa de Moura Gonzaga

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil. Profª Esp.: Maysa de Moura Gonzaga DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil Profª Esp.: Maysa de Moura Gonzaga 2º Semestre / 2011 O Processo Unificado dos autores Ivar Jacobson, Grady Booch e James

Leia mais

Ferramenta para Gerenciamento de Requisitos em Metodologias Ágeis

Ferramenta para Gerenciamento de Requisitos em Metodologias Ágeis Ferramenta para Gerenciamento de Requisitos em Metodologias Ágeis Eduardo dos Santos Gonçalves 1, Heitor Boeira dos Reis Filho 1 1 Universidade Luterana do Brasil (ULBRA) Av. Itacolomi, 3.600 Bairro São

Leia mais

Enquadramento e Conceitos Gerais

Enquadramento e Conceitos Gerais Análise e Conc epç ão de Sist em as de Inform aç ão,qwurgxomr Carla Ferreira carla.ferreira@dei.ist.utl.pt Sistemas de Informação Arquitectura de Sistemas de Informação Planeamento Estratégico de Sistemas

Leia mais

7 Conclusões. 7.1 Retrospectiva do trabalho desenvolvido. Capítulo VII

7 Conclusões. 7.1 Retrospectiva do trabalho desenvolvido. Capítulo VII Capítulo VII 7 Conclusões Este capítulo tem como propósito apresentar, por um lado, uma retrospectiva do trabalho desenvolvido e, por outro, perspectivar o trabalho futuro com vista a implementar um conjunto

Leia mais

Padrões de Desenho (Design Patterns)

Padrões de Desenho (Design Patterns) Padrões de Desenho (Design Patterns) O que são padrões de desenho Porque são úteis Conhecer alguns padrões 1 Padrões (Patterns) Design Patterns Explained: A New Perspective on Object-Oriented Design, Alan

Leia mais

O que é Domain-Driven Design

O que é Domain-Driven Design O que é Domain-Driven Design Desenvolvimento Software é mais freqüentemente aplicado a automatizar processos que existem no mundo real, ou fornecimento de soluções para problemas reais de negócios; Os

Leia mais

extreme Programming Joaquim Filipe Patrícia Macedo Engenharia de Software 2005/06 EST, Setúbal Metodologias de Desenvolvimento de Software

extreme Programming Joaquim Filipe Patrícia Macedo Engenharia de Software 2005/06 EST, Setúbal Metodologias de Desenvolvimento de Software extreme Programming Joaquim Filipe Engenharia de Software 2005/06 EST, Setúbal Metodologias de Desenvolvimento de Software Agenda Metodologia PREDITIVAS (tradicionais) UP MSF Metodologias Adaptativas(Ageis)

Leia mais

A Importância das Inspecções Periódicas na Manutenção de Edifícios

A Importância das Inspecções Periódicas na Manutenção de Edifícios A Importância das Inspecções Periódicas na Manutenção de Edifícios Luís Viegas Mendonça Engenheiro Civil Spybuilding Lda. - Director Geral Miguel Martins do Amaral Engenheiro Civil Spybuilding Lda. - Director

Leia mais

Uma plataforma estratégica

Uma plataforma estratégica Publicado: Fevereiro 2007 Autor: Rui Loureiro Sénior Partner Implementar o Help Desk Quando simplesmente pensamos em implementar um Help Desk, isso pode significar uma solução fácil de realizar ou algo

Leia mais

Escola Superior de Gestão de Santarém. Instalação e Manutenção de Redes e Sistemas Informáticos. Peça Instrutória G

Escola Superior de Gestão de Santarém. Instalação e Manutenção de Redes e Sistemas Informáticos. Peça Instrutória G Escola Superior de Gestão de Santarém Pedido de Registo do CET Instalação e Manutenção de Redes e Sistemas Informáticos Peça Instrutória G Conteúdo programático sumário de cada unidade de formação TÉCNICAS

Leia mais

Trabalho de Grupo Gestão de Projecto e Gestão de Processos de Negócio

Trabalho de Grupo Gestão de Projecto e Gestão de Processos de Negócio 1 Trabalho de Grupo Gestão de Projecto e Gestão de Processos de Negócio João Caixinha, 5946, Pedro Moreira, 10015, 2.º Ano (2011/2012) Resumo Este trabalho é composto por duas partes, uma elaborada no

Leia mais

T&E Tendências & Estratégia

T&E Tendências & Estratégia FUTURE TRENDS T&E Tendências & Estratégia Newsletter número 1 Março 2003 TEMA deste número: Desenvolvimento e Gestão de Competências EDITORIAL A newsletter Tendências & Estratégia pretende ser um veículo

Leia mais

E se conseguisse reduzir os seus custos de energia até 20%?

E se conseguisse reduzir os seus custos de energia até 20%? E se conseguisse reduzir os seus custos de energia até 20%? Uma solução eficaz de Gestão Energética para o Retalho Eficiência Energética no Retalho Será que está a gastar mais em energia do que necessita?

Leia mais

Gestão de Carreiras Escola Secundária de Emídio Navarro 2002/2003 Estruturas, Tratamento e Organização de Dados

Gestão de Carreiras Escola Secundária de Emídio Navarro 2002/2003 Estruturas, Tratamento e Organização de Dados Gestão de Carreiras Durante muito tempo, a gestão de carreiras não fez parte das preocupações dominantes dos gestores de pessoal. Nos últimos anos, porém, tem-se assistido a um crescendo de interesse relativamente

Leia mais

Análise real de dados

Análise real de dados Análise real de dados Para tacógrafos analógicos e digitais www.siemensvdo.com 1 Maximize todas as potencialidades dos tacógrafos digitais Novas obrigações, novas opções de análise Para si e para a sua

Leia mais

Informática II Cap. 3

Informática II Cap. 3 Cap. 3 1 Tradicionalmente, programar significava apenas a escrita de um programa, que resolvesse o problema pretendido de uma forma aparentemente correcta. Problema Problema Programa Programa Desvantagens:

Leia mais

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 05 PROFª BRUNO CALEGARO

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 05 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 05 PROFª BRUNO CALEGARO Santa Maria, 24 de Setembro de 2013. Revisão aula anterior Processos de Software Engenharia de Requisitos, Projeto,

Leia mais

GIBDQA: GESTÃO INTEGRADA DE BASES DE DADOS DA QUALIDADE DA ÁGUA

GIBDQA: GESTÃO INTEGRADA DE BASES DE DADOS DA QUALIDADE DA ÁGUA GIBDQA: GESTÃO INTEGRADA DE BASES DE DADOS DA QUALIDADE DA ÁGUA Sandra CARVALHO 1, Pedro GALVÃO 2, Cátia ALVES 3, Luís ALMEIDA 4 e Adélio SILVA 5 RESUMO As empresas de abastecimento de água gerem diariamente

Leia mais

ANÁLISE DA UTILIZAÇÃO DE PRÁTICAS DO EXTREME PROGRAMMING PARA A PREVENÇÃO DO DÉBITO TÉCNICO DE PROJETOS DE SOFTWARE

ANÁLISE DA UTILIZAÇÃO DE PRÁTICAS DO EXTREME PROGRAMMING PARA A PREVENÇÃO DO DÉBITO TÉCNICO DE PROJETOS DE SOFTWARE CENTRO UNIVERSITÁRIO UNA DIRETORIA DE EDUCAÇÃO CONTINUADA, PESQUISA E EXTENSÃO CURSO DE PÓS GRADUAÇAO EM ENGENHARAIA DE SOFTWARE CENTRADA EM MÉTODOS ÁGEIS ANÁLISE DA UTILIZAÇÃO DE PRÁTICAS DO EXTREME PROGRAMMING

Leia mais

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia.

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia. 1 Introdução aos Sistemas de Informação 2002 Aula 4 - Desenvolvimento de software e seus paradigmas Paradigmas de Desenvolvimento de Software Pode-se considerar 3 tipos de paradigmas que norteiam a atividade

Leia mais

SOBRE GESTÃO * A Definição de Gestão

SOBRE GESTÃO * A Definição de Gestão SOBRE GESTÃO * A Definição de Gestão Chegar a acordo sobre definições de qualquer tipo pode ser uma tarefa de pôr os cabelos em pé, e um desperdício de tempo. Normalmente requer compromissos por parte

Leia mais