Arquivo por categoria Metodologias de desenvolvimento de software

O Processo Unificado (PU)

O Processo Unificado (PU) surgiu posteriormente às metodologias citadas acima e propõe um processo de desenvolvimento iterativo e incremental como meio para sanar fragilidades das metodologias anteriores. Baseia-se em refinamentos e incrementos de um sistema por meio de múltiplas iterações contando com o feedback do cliente e com uma adaptação cíclica como principais propulsores para um sistema que se adeque bem aos interesses do cliente. Não há, no Processo Unificado, uma corrida para implementar o software e nem um longo e demorado projeto que tenta resolver todos os problemas antes da programação. Ao fim de cada iteração tem se um sistema executável, mas que ainda não está pronto para ser colocado em produção (LARMAN, 2004).

No processo unificado valoriza-se muito o feedback vindo do cliente. Segundo Larman (2004) a frase “acolha a mudança” (BECK, 2000 apud LARMAN, 2004) mostra a atitude chave do desenvolvimento iterativo. Ao invés de combater a mudança tentando especificá-la completa e corretamente e fazer com que o cliente assine embaixo de um conjunto de requisitos congelados antes da implementação. No processo unificado aceita-se a mudança e passa a considera-la não um problema, mas sim uma realidade.

Essa realimentação contínua vale ouro, ao invés de se especular sobre requisitos ou projetos corretos, aproxima-se com maior precisão do que o cliente realmente precisa. Todavia isso não é uma justificativa para o desenvolvimento caótico e reativo em que continuamente muda-se a direção, é necessário, sempre, manter um meio termo. No Processo Unificado o desenvolvimento progride através de uma série de ciclos estruturados que envolvem construção-realimentação-adaptação. Frequentemente as primeiras iterações de um projeto tendem a ser maiores visto que os requisitos ainda não estão corretamente refinados (LARMAN, 2004).

Larman (2004) enumera uma série de benefícios tragos pelo processo iterativo:

  • Mitigação precoce de erros, ao invés de tardiamente e de forma arriscada;
  • Progresso visível desde o início do projeto;
  • Realimentação, envolvimento do cliente e adaptação imediatos refinando o sistema.
  • Administra-se melhor a complexidade evitando uma sobrecarga da equipe de desenvolvimento.
  • O aprendizado de uma iteração pode ser aplicado para melhorar o processo de desenvolvimento como um todo.

O processo unificado recomenda pequenas iterações que podem variar de duas a seis semanas. As ideias centrais do processo unificado são, dar pequenos passos, obter feedback rápido e fazer adaptações. Iterações com grandes intervalos de tempo podem prejudicar a motivação da equipe além de aumentarem o risco do projeto.

De acordo com Pressman (2006) é razoável caracterizar as metodologias adotadas nas duas primeiras décadas da Engenharia de Software como a era do “pensamento linear”. A Engenharia de Software, até então, era abordada como uma atividade linear onde a execução de diferentes etapas sequenciais poderia ser utilizada para resolver problemas complexos. Embora essa abordagem seja coerente ela não pode ser empregada sem acarretar nos problemas apontados acima. Para Pressman (2006), apesar das falhas apresentadas por essas metodologias, muitos conceitos criados nesse período são válidos e continuarão sendo utilizados e/ou incorporados em metodologias futuras.

Referências:

LARMAN, Craig. Utilizando UML e Padrões: Uma Introdução à Análise e ao Projeto Orientados a Objetos e ao Processo Unificado. 2 ed. Porto Alegre: Bookman, 2004.

PRESSMAN, Roger S. Engenharia de Software : 6 ed. São Paulo: McGraw Hill/Nacional, 2006.

Tags: , ,

As Metodologias Tradicionais de Desenvolvimento de Software

As metodologias tradicionais são também chamadas de pesadas ou orientadas a documentação. Elas foram muito utilizadas no passado em um contexto de desenvolvimento de software muito diferente do atual, baseado apenas em um mainframe e terminais burros Naquela época, o custo de fazer alterações e correções era muito alto, uma vez que o acesso aos computadores eram limitados e não existiam modernas ferramentas de apoio ao desenvolvimento do software, como depuradores e analisadores de código. Por isso o software era todo planejado e documentado antes de ser implementado. Uma das metodologias tradicionais mais utilizadas até hoje é o modelo Clássico ou Cascata (SOARES, 2004).

Cascata

Uma das primeiras metodologias criadas para minimizar os problemas destacados acima foi a metodologia Cascata. Ela representava um grande avanço no desenvolvimento de software. Principalmente se levar em conta que antes do surgimento das primeiras metodologias existia o que ficou vulgarmente conhecido como “codifica arrebenta”. Onde o mal ou nenhum levantamento de requisitos levava a sucessivas correções, debugs e muitas vezes ao fracasso do projeto.

O Ciclo de Vida da Metodologia Cascata

Fonte: PRESSMAN, 2006

A Figura acima representa a metodologia cascata, também conhecida como sequencial, ou linear, por se basear em uma sucessão de etapas onde uma só é iniciada após o fim da imediatamente anterior a ela. Como se pode ver o desenvolvimento flui da parte de cima – Engenharia de sistemas – em direção à manutenção. Nessa metodologia, inicialmente procura-se compreender completamente o problema, a ser resolvido, seus requisitos e suas restrições; depois projeta-se soluções que atendam a todos os requisitos e restrições. Feito isto inicia-se a implementação do projeto e quando toda a etapa de implementação é concluída verifica-se junto ao cliente se a solução atende aos requisitos estabelecidos e por fim é efetuada a entrega do produto (KROLL e KRUCHTEN, 2003 apud LOURENÇO, 2011).

A abordagem adotada pela metodologia cascata acaba trazendo alguns problemas. Dentre estes problemas merece destaque o fato de que os projetos reais dificilmente seguem o fluxo sequencial, o cliente quase sempre não consegue exprimir todas as suas necessidades além de ser exigida dele muita paciência visto que o software só estará pronto para uso num ponto tardio do cronograma. E o maior dos problemas é que se ocorrer um erro em qualquer uma das etapas o resultado pode ser desastroso e frequentemente caro (PRESSMAN, 2006).

Algumas vezes o cliente define um conjunto de objetivos gerais que não esclarecem consistentemente os requisitos. Outras vezes o desenvolvedor não tem certeza da eficiência de parte do código, da adaptação da aplicação ao sistema operacional ou mesmo da forma que interação homem-máquina deve ter. Visando fornecer melhores soluções à casos assim surgiu a metodologia conhecida como prototipação.

Prototipação

A Prototipação é uma metodologia surgida posteriormente à Cascata. Ela possibilita a equipe de desenvolvimento a criar uma aplicação protótipo que pode assumir três formas distintas. A primeira delas é um protótipo em papel ou mesmo no computador que retrate a interação homem-máquina. A segunda opção é implementar uma funcionalidade que já está no escopo do software a ser desenvolvido. Por fim existe a possibilidade de utilizar-se de um software já pronto que tenha parte ou todas as funcionalidades desejadas. Esta forma é mais comumente adotada em softwares que apesar de prontos ou parcialmente prontos possuem características que precisam ser incrementadas ou melhoradas em um novo esforço de desenvolvimento (PRESSMAN, 2006).

Geralmente o protótipo serve apenas como um mecanismo para identificar requisitos de software. Isto ocorre por que na maior parte dos casos o primeiro sistema construído não é completamente usável. Normalmente ele possui uma série de problemas que só serão corrigidos em uma versão reprojetada na qual as deficiências sejam corrigidas (BROOKS,1975 apud PRESSMAN, 2006).

Assim como a metodologia Cascata a Prototipação também apresenta os seus pontos negativos. Um deles, é que o cliente pode acreditar que o protótipo já é o software pronto ou em fase de término e começar pressionar para que se faça pequenos ajustes e entregue o software rapidamente. Diante de um quadro assim, muitas vezes, a equipe de desenvolvimento cede e a qualidade final, bem como a manutenibilidade podem ficar comprometidas. Outro ponto negativo é que algumas vezes a equipe de desenvolvimento pode  fazer concessões temporárias a fim de colocar o protótipo em funcionamento que acabam permanecendo no software final.

Apesar desses problemas, a prototipação ainda é uma eficiente metodologia de desenvolvimento de software. A fim de se obter sucesso no projeto, tanto cliente quanto desenvolvedor devem chegar a um consenso de que o protótipo servirá apenas para ajudar na definição dos requisitos (PRESSMAN, 2006). Apesar de resolverem muitos dos problemas do desenvolvimento de software alguns parâmetros ainda não eram fornecidos pelas metodologias existentes.

Espiral

A metodologia espiral foi concebida para englobar as melhores práticas tanto do ciclo de vida clássico quanto da prototipação. Essa metodologia inovou ao trazer também um novo elemento, a análise de riscos. Além disso, foi uma das primeiras metodologias a adotar o conceito de iteração. Sucessivas iterações moldam aos poucos soluções mais completas do software (PRESSMAN, 2006).

Na primeira iteração, os objetivos, alternativas e restrições são definidos e os riscos são identificados e analisados. O cliente avalia o resultado da iteração e baseado nos apontamentos do mesmo a próxima iteração é iniciada. Isso possibilita ao cliente e ao desenvolvedor perceber e reagir a riscos em cada uma das etapas evolutivas. Entretanto a metodologia espiral exige considerável experiência para avaliar os riscos e se baseia nela para obter sucesso. Encara-se que se um grande risco não for detectado indubitavelmente ocorrerão problemas.

Referências:

LOURENÇO, Marcelo. Obtendo Qualidade de Software com o RUP. Disponível em: < http://qualidade-de-software.blogspot.com/2010/03/obtendo-qualidade-de-software-com-o-rup.html >  acesso em 05 mar. 2011.

PRESSMAN, Roger S. Engenharia de Software : 6 ed. São Paulo: McGraw Hill/Nacional, 2006.

SOARES, Michel dos Santos. Comparação entre Metodologias Ágeis e Tradicionais para o Desenvolvimento de Software. 2004. Disponível em: < http://www.dcc.ufla.br/infocomp/artigos/v3.2/art02.pdf > acesso em: 04 abr. 2011.

SOMMERVILLE, Ian. Engenharia de Software : 8 ed. Rio de Janeiro: Prentice-Hall, 2008.

Tags: , , , ,

Engenharia De Software

A Engenharia de Software é uma área da engenharia que se propõe a fornecer parâmetros para o desenvolvimento de softwares. Ela está relacionada a todos os aspectos do desenvolvimento de software, abrangendo desde aspectos iniciais como a especificação de requisitos até processos de manutenção (SOMMERVILLE, 2008). A Engenharia de Software engloba três elementos – métodos, ferramentas e procedimentos – que permite controlar o processo de desenvolvimento e oferece uma base sólida para a implementação de softwares de forma produtiva e com qualidade. Os métodos fornecem os detalhes do que fazer para se construir o software, as ferramentas fornecem apoio automatizado ou semi-automatizado aos métodos e por fim os procedimentos formam um elo que conecta os métodos e as ferramentas permitindo assim o desenvolvimento do software de forma racional e oportuna (PRESSMAN, 2006).

O termo Engenharia de Software surgiu no final dos anos 60 durante uma conferência em que se discutia a “crise do software”. A crise do software por sua vez era um resultado direto da evolução tecnológica empregada na fabricação do hardware de computador baseado em circuitos integrados. Essa evolução viabilizou a implementação de softwares antes considerados impossíveis de serem desenvolvidos. Os softwares resultantes tornavam-se cada vez maiores e o desenvolvimento informal mostrava-se cada vez mais inviável. Projetos de grande porte apresentavam, muitas vezes, anos de atraso. Os custos frequentemente superavam as previsões, o software resultante não era confiável além de ser difícil de manter e de desempenho insatisfatório (SOMMERVILLE,2008) .

Esse quadro tornou evidente a necessidade de se criar novos processos de gestão e desenvolvimento de software. Inicialmente os processos de desenvolvimento de software mantinham conceitos típicos da Engenharia. Eles ajudaram a sistematizar o processo de desenvolvimento de software e mais tarde deu origem a Engenharia de Software (SOUZA NETO, 2004). Desses processos surgiram as primeiras metodologias de desenvolvimento de software, como a metodologia cascata, a prototipação, o espiral e outros.

Referências:

PRESSMAN, Roger S. Engenharia de Software : 6 ed. São Paulo: McGraw Hill/Nacional, 2006.

SOMMERVILLE, Ian. Engenharia de Software : 8 ed. Rio de Janeiro: Prentice-Hall, 2008.

SOUZA NETO, Oscar Nogueira de. Análise Comparativa das Metodologias de Desenvolvimento de Softwares Tradicionais e Ágeis. Belém: Unama – Universidade da Amazônia, 2004.

Tags: , , , , ,

Medição e Métricas de Software

O papel da medição de software é quantificar alguns atributos de um produto ou de um processo de software. Comparando essas informações é possível tirar conclusões sobre a qualidade do software. Possibilita ainda mensurar se mudanças organizacionais – adoção de novas ferramentas, metodologias dentre outros – estão sendo positivas ou não para os processos de desenvolvimento da mesma. Nesse caso são feitas medições antes e depois da mudança a fim de verificar se a mesma foi positiva ou não para a organização (SOMMERVILLE, 2008).

Majoritariamente, as métricas têm sido adotadas para melhorar processos de gerenciamento da qualidade. Por esse motivo as métricas são utilizadas para mensurar defeitos de programas e processos de verificação e validação.

Todavia, o uso de métricas ainda é relativamente incomum e muitas organizações relutam em adotá-las pois os benefícios não são bem definidos. Isso acontece por que a organização dos processos de software ainda é precária e ainda não estão aperfeiçoados de forma suficiente para usar métricas. Outro motivo é a falta de padrões para as métricas e o fato de muitas empresas não estarem preparadas para introduzir medições sem que padrões e ferramentas sejam antes criadas.

Nesse sentido, Paula Filho (2000)  afirma que escolher medidas adequadas, e ser capaz de coletar, normalizar e analisar estas medidas requer um grau mais avançado de capacitação. Ressalta também que sem medidas, os processos não podem ser avaliados e muito menos melhorados. Por isso mesmo que as medidas sejam rudimentares elas podem ser úteis.

Uma métrica de software é qualquer tipo de medição que se refira a um sistema de software, processo ou documentação relacionada. Alguns exemplos são a medição do tamanho pela quantidade de linhas de código, grau de facilidade de leitura de um trecho de código, numero de defeitos relatados e numero de pessoas-dia necessárias para desenvolver um software (SOMMERVILLE, 2008).

As métricas podem ser classificadas em de controle ou preditivas e ambas podem influenciar na tomada de decisões. As métricas de controle estão associadas a processos de software, já as preditivas estão associadas a produtos de software. Visto que  é quase impossível medir atributos da qualidade de software como facilidade de manutenção, complexidade e facilidade de compreensão, os engenheiros de software medem então atributos internos como o tamanho. Com essas medidas em mãos eles supõe que existam relações entre o que se pode medir e o que se deseja saber. Além disso para que o processo de medição seja confiável, é exigido também, profissionais com grande experiência em estatística.

1.1 O Processo de Medição

A medição de software muitas vezes pode fazer parte de um processo de controle de qualidade. Componentes de um sistema são analisados separadamente, e os diferentes valores de métricas são comparados entre si e com dados históricos de projetos precedentes. As medições anômalas encontradas nesse processo são usadas para enfatizar o esforço de garantia de qualidade.

De acordo com Sommerville (2008) os principais estágios desse processo são:

  • Escolha das medições a serem feitas onde devem ser formuladas questões as quais as medições se destinam a responder e definir as medições importantes para responder essas questões. Medições não relevantes para responder essas questões não precisam ser coletadas.
  • Seleção dos componentes a serem avaliados nem todos os componentes precisam ser necessariamente avaliados, sendo assim é preciso fazer-se uma seleção representativa de componentes realmente importantes.
  • Medição de características dos componentes os componentes selecionados são medidos e os valores e métricas são computados.
  • Identificação de medições anômalas deve-se então procurar por valores incomuns para cada métrica pois eles sugerem a existência de problemas com o componente        que apresenta esses valores.
  • Analise de componentes anômalos os componentes com valores anômalos devem ser examinados para constatar se a qualidade do componente está ou não comprometida. Apesar disso pode haver ainda outros motivos para essa anomalia mas que não comprometam a qualidade.

Os dados coletados devem ser mantidos como um recurso organizacional assim como os registros históricos dos projetos. Quando um banco de dados de medição se torna suficientemente grande ele passa a servir de base para comparações entre projetos e métricas específicas podem ser aprimoradas, de acordo com as necessidades organizacionais.

1.2 Métricas de Produto

O foco das métricas de produto são as características do próprio software. Pelo fato de as características facilmente mensuráveis do software não terem uma relação clara e universal com os atributos de qualidade, a organização precisa analisar seu banco de dados para descobrir como atributos do produto de software se relacionam com as qualidades desejadas pela organização.

Nesse sentido Sommerville (2008) divide as métricas de produtos em duas classes:

  • Métricas dinâmicas são aquelas coletadas de um programa em execução. Ajudam a avaliar a eficiência e a confiabilidade de um programa. Quase sempre estão relacionadas com atributos da qualidade de software.
  • Métricas estáticas são aquelas coletadas em representações do sistema como projeto, programa ou documentação. Ajudam a mensurar a complexidade e a facilidade de compreensão e manutenção de um sistema de software. Possuem uma relação indireta com os atributos de qualidade.

Um dos maiores problemas da coleta de dados sobre software e projetos de software reside no fato de que os dados podem ser interpretados de forma equivocada levando a resultados incorretos. A interpretação dos dados sobre um produto ou processo é um método incerto. Os elementos focados pela medição não estão isolados de seus ambientes, e mudanças nesse ambiente podem invalidar as comparações de dados. Além disso, as métricas variam de acordo com o projeto, com as metas da equipe de gerencia de qualidade, com o tipo de software que está em desenvolvimento.

Referências:

SOMMERVILLE, Ian. Engenharia de Software : 8 ed. Rio de Janeiro: Prentice-Hall, 2008.

PMBOK. Um guia do conhecimento em gerenciamento de projetos (Guia PMBOK). 4 ed. Pennsylvania: Project Management Institute, Inc., 2008.

PAULA FILHO, Wilson de Pádua. Engenharia de Software:fundamentos, métodos e padrões. São Paulo: LTC Editora, 2000.

Tags: , , ,

Qualidade de Software

Atingir um alto nível de qualidade de produto ou serviço é uma exigência inerente ao mercado. Quando se trata de qualidade de software não se foge a regra e não é aceitável entregar produtos com baixa qualidade e descobrir as deficiências e problemas após entregar o produto ao cliente.

1.1 A Importância da Qualidade de Software

Quando se trata de software, o conceito de qualidade é algo complexo e adotar a mesma definição de qualidade que se aplica a produtos manufaturados não pode ser aplicada sem inconsistência. Para Sommerville (2008) a noção de que o produto desenvolvido deve cumprir com sua especificação quando aplicada ao desenvolvimento de software torna-se ineficaz:

  • A especificação deve considerar as características desejadas pelo cliente e a organização de desenvolvimento pode ter requisitos não incluídos na especificação.
  • Certas características de qualidade não podem ser especificadas sem se tornar ambíguas.
  • É muito difícil descrever uma especificação completa de software. Nesse sentido, mesmo que um produto atenda sua especificação os usuários podem não considerá-lo de alta qualidade.

Evidentemente deve haver um esforço para melhorar as especificações, mas devemos aceitar que elas serão imperfeitas. Devem-se reconhecer os problemas com as especificações impostas e adotar técnicas para melhorar sua qualidade dentro das restrições impostas. Atributos de software como facilidade de manutenção, portabilidade ou eficiência podem ser fundamentais, mas que não são especificados explicitamente, entretanto podem afetar a qualidade percebida do sistema (SOMMERVILLE, 2008). Para Bezerra (2006) algumas das formas de se medir a qualidade de um sistema de software é através de seu desempenho, sua confiabilidade e da utilidade do mesmo.

Nesse sentido cabe aos gerentes de projeto garantir que o nível de qualidade seja atingido. Definir procedimentos e padrões, e garantir que eles sejam seguidos, já são um bom começo, mas não é o suficiente. Gerentes de qualidade reconhecem que existem aspectos intangíveis de qualidade que não se encaixam em padrões. Alémdisso, é importante criar uma “cultura da qualidade” na qual todos se comprometam a atingir um alto nível de qualidade (SOMMERVILLE, 2008).

Para Sommerville (2008) o gerenciamento de qualidade de software pode ser dividido em ter atividades principais:

  • Garantia de qualidade que consiste em estabelecer procedimentos e padrões que conduzam ao desenvolvimento de software de alta qualidade.
  • Planejamento de qualidade selecionar os procedimentos e padrões adequados e adaptá-los a um projeto de software específico o que vai de encontro com recomendações do PMBOK (2008).
  • Controle de qualidade definir e aprovar processos que garantam que os procedimentos e padrões de qualidade sejam seguidos.

O gerenciamento de qualidade fornece uma verificação independente sobre o processo de desenvolvimento de software. Ele deve ser separado do gerenciamento de projeto, para que a qualidade não seja comprometida pelas responsabilidades de gerenciamento relacionadas a prazos e orçamentos. A equipe de qualidade não deve ficar associada à um grupo específico de desenvolvimento, mas sim assumir um compromisso pela qualidade na organização. Os procedimento de garantia de qualidade devem ser documentados em um manual que define o processo de qualidade (SOMMERVILLE, 2008).

1.2 Garantia e Padrões de Qualidade

As atividades de garantia de qualidade definem uma estrutura para atingir a qualidade de software. O que envolve definir ou selecionar os padrões a serem aplicados no desenvolvimento de um produto de software. Sommerville (2008) estabelece dois tipos de padrões que podem ser estabelecidos como parte do processo de garantia de qualidade:

  • Padrões de produto se aplicam ao produto de softwareem desenvolvimento. Podem incluir padrões de documentos, padrões de documentação e padrões de codificação. Aplicam-se as saídas do processo de software.
  • Padrões de processo definem os processos a serem seguidos durante o desenvolvimento do software. Podem incluir definições de especificação, processos de projeto e validação e uma descrição dos documentos a serem gerados no curso de desenvolvimento. Além disso asseguram que os padrões de produto sejam seguidos.

Sommerville (2008) enumera uma série de motivos pelos quais os padrões de software são importantes:

  • Envolvem as práticas mais adequadas. Adquire-se mais conhecimento através de erros e acertos o que evita que os erros se repitam no futuro. Registram a sabedoria que tem valor para a organização.
  • Fornecem uma infraestrutura em torno da qual o processo de garantia de qualidade pode ser implementado.
  • Reduzem o esforço de aprendizados quando um novato entra na equipe e garante que todos adotem as mesmas praticas.

Desenvolver padrões de projeto de Engenharia de Software é difícil e demorado. Equipes de garantia de qualidade que estejam desenvolvendo seus padrões de projeto de Engenharia de Software deverão se basear em padrões nacionais, internacionais e organizacionais. Com base nesses padrões a equipe de garantia de qualidade deve elaborar um manual de padrões, adaptado às necessidades apropriadas a sua organização.

Entretanto, não raramente engenheiros de software julgam esses padrões não são necessariamente apropriados a um projetoem particular. Segundo Sommerville(2008) para evitar esses problemas engenheiros de qualidade que estabelecem os padrões precisam seguir as seguintes etapas:

  • Envolver os engenheiros de software no desenvolvimento de padrões e fazer com que compreendam e se comprometam com eles.
  • Revisar e modificar regularmente os padrões para que eles reflitam as constantes evoluções tecnológicas.
  • Fornecer ferramentas de software que apoiem a adoção dos padrões.

Nesse sentido criar padrões de documentação é uma boa solução e facilita a comunicação entre membros da equipe de desenvolvimento e os clientes.

1.3 Qualidade de Produto e Qualidade de Processo

A qualidade do processo de desenvolvimento afeta diretamente a qualidade dos produtos fornecidos. Isto se deve ao fato de a qualidade de produto estar diretamente relacionada ao processo de produção. É difícil medir atributos de software sem utilizá-lo por um longo período. Os processos por sua vez são relativamente simples de monitorar e padronizar. A melhoria de qualidade focaliza então a identificação de produtos de boa qualidade e nos processos utilizados no seu desenvolvimento. Entretanto, devido a complexidade entre produtos de software e os processos de software, uma mudança no processo não necessariamente conduz a melhoria da qualidade.

O software não é um produto manufaturado, mas projetado. Seu desenvolvimento é um processo criativo e não mecânico tornando-o significativamente influenciado por habilidades, experiências individuais e fatores externos que afetam diretamente na sua qualidade (SOMMERVILLE, 2008).

Referências:

BEZERRA, Eduardo. Princípios de Análise e Projeto de Sistemas com UML: Um guia prático para modelagem de sistemas orientados a objetos através da Linguagem de Modelagem Unificada. Rio de Janeiro: Elsevier e Campus, 2006.

SOMMERVILLE, Ian. Engenharia de Software : 8 ed. Rio de Janeiro: Prentice-Hall, 2008.

PMBOK. Um guia do conhecimento em gerenciamento de projetos (Guia PMBOK). 4 ed. Pennsylvania: Project Management Institute, Inc., 2008.

Tags: , , ,

Metodologias de Desenvolvimento de Software

Estamos começando o desenvolvimento do software ERUDIO – Sistema de Gestão Educacional. O ERUDIO é meu projeto de TCC e de outros dois colegas meus. Os requisitos centrais foram levantados e agora começaremos construir o banco de dados. Além disso precisamos definir qual metodologia vamos adotar no processo de implementação. Após um profundo estudo de várias metodologias estamos com uma certeza, adotaremos uma metodologia de desenvolvimento ágil. Em contrapartida temos uma dúvida qual delas. Estamos empolgados com o eXtreming Programming, com Scrum e um pouco com a novíssima OpenUP. Já verificamos os pontos positivos e negativos de cada uma delas e a duvida permanece. Vamos ver se até o fim da semana resolvemos isso.

Tags: , , ,