Leia um pouco sobre a Introdução: UML?

Introdução: UML

UML

     A UML é um meio formal para representar um projeto. Não é um processo de software, é apenas uma maneira de documentar o projeto formalmente. Os vários estilos de diagramas da UML oferecem diferentes pontos de vista do design.

A Unified Modeling Language, ou UML, como é popularmente conhecido é a linguagem que pode ser usada para modelar sistemas e torná-los legíveis. Isto significa basicamente que UML oferece a capacidade de capturar as características de um sistema utilizando notações. UML oferece uma grande variedade de notações para sistemas orientados a objetos, fácil de entender e documentar. Estas notações são chamadas de diagramas da UML.

Por usar a UML como linguagem de modelagem?

     Pela padronização.  Diferentes linguagens foram usados ​​para modelar sistemas orientado a objeto. Destacam-se as metodologias de Rumbaugh, Booch e Jacobson. O problema era que, apesar de cada metodologia ter suas vantagens, eles eram incompletas. Por isso, se você tivesse que trabalhar em diferentes projetos que usavam qualquer destas metodologias, você tinha que conhecer bem cada uma dessas metodologias. A UML unifica todas estas metodologias em uma única norma, uma linguagem que pode ser facilmente aplicada de forma generalizada para todos os sistemas orientados a objetos. Mas, ao contrário das diferentes metodologias que tendiam mais para a concepção e projeto detalhado de sistemas, a UML abrange toda a fase de requisitos, análise e projeto e implementação. A vantagem da UML está no fato de que qualquer um dos diagramas da UML pode ser utilizado para modelagem e documentação de um projeto. Por exemplo, se você precisa modelar requisitos para um determinado sistema, você pode usar os diagramas de casos de uso sem ter que necessariamente usar outros diagramas da UML.

      A UML não tem nenhuma dependência com relação a quaisquer tecnologias ou linguagens. Isto significa que você pode usar UML para modelar aplicações e sistemas baseados em qualquer uma das atuais tecnologias orientada a objetos, como por exemplo, J2EE e NET. Todos os esforços foram feitos para manter a UML como linguagem de modelagem clara e concisa, sem estar amarrado a qualquer tecnologia.

Diagramas UML

     De acordo com a UML cada diagrama pode capturar diferentes elementos de um sistema. A UML possui um conjunto de diagramas que pode ser usado para modelar um sistema em diferentes pontos do tempo no ciclo de vida do software. 

Alguns diagramas em destaque:

Diagrama de Caso de Uso(Use case): O diagrama de caso uso é usado para identificar os elementos primários e processos que constituem o sistema. Os elementos principais são denominados como "atores" e os processos são chamados de "casos de uso." O diagrama de caso de uso mostra que os atores interagem com cada caso de uso.

Diagrama de classes: O diagrama de classes é usado para refinar o diagrama de caso de uso e definir um projeto detalhado do sistema. O diagrama de classes classifica os atores definidos no diagrama de caso de uso em um conjunto de classes inter-relacionadas. A relação ou associação entre as classes podem ser "é-um" ou "tem-um" relacionamento. Cada classe no diagrama de classes pode ser capaz de fornecer funcionalidades. Estas funcionalidades oferecidas pela classe são designadas por "métodos" da classe. Além disso, cada classe pode ter "atributos" que identificam a classe.

Diagrama de objeto: O diagrama de objeto é um tipo especial de diagrama de classe. Um objeto é uma instância de uma classe. Isto significa basicamente que um objeto representa o estado de uma classe em um determinado ponto do tempo, enquanto o sistema está funcionando. O diagrama de objeto captura o estado de diferentes classes no sistema e suas relações ou associações em um determinado ponto do tempo.

Diagrama de Estado: um diagrama de estado, como o nome sugere, representa os diferentes estados que os objetos no sistema sofrem durante o seu ciclo de vida. Objetos nos estados de alteração do sistema em resposta a eventos. Além disso, um diagrama de estado também capta a transição de estado do objeto a partir de um estado inicial para um estado final, em resposta a acontecimentos que afetam o sistema.

Diagrama de atividades: O diagrama de atividades serve para documentar os processos que ocorrem no sistema. Semelhante a um diagrama de estado, um diagrama de atividades também é composto de atividades, ações, transições, estados inicial e final.

Diagrama de sequência: Um diagrama de sequência representa a interação entre os diferentes objetos no sistema. O aspecto importante de um diagrama de sequência é que ele é ordenado no tempo. Isto significa que a sequência exata das interações entre os objetos é representado passo a passo. Diferentes objetos no diagrama de sequência interagem uns com os outros, através de "mensagens".

Diagrama de colaboração: U diagrama de colaboração são interações entre diferentes objetos. As interações são listadas como interações numeradas que ajudam a rastrear a sequência das interações. O diagrama de colaboração ajuda a identificar todas as possíveis interações que cada objeto tem com outros objetos.

Diagrama de componente: O diagrama de componentes representa as partes de alto nível que compõem o sistema. Este diagrama mostra, em alto nível, o que os componentes fazem no sistema e como eles estão interligados. 

Diagrama de implantação: O diagrama de implantação captura a configuração dos elementos em tempo de execução da aplicação. Este diagrama é muito importante  quando um sistema está pronto para ser implantado.

Leia um pouco sobre Orientação a Objetos?

Orientação a Objetos

            A programação orientada a objetos é uma técnica de programação baseada em modelos ou objetos do mundo real. Isto que dizer que dentro do programa (executável) deve ter um objeto representando os objetos do mundo real de acordo com a área a qual foi projetado o sistema.

            Por exemplo, se o sistema foi projetado para atender um consultório médico, onde este sistema deve gerenciar a agenda de consultas dos médicos da clinica, então eu preciso criar dentro deste sistema objetos que representem os médicos, os pacientes, os funcionários etc.

            Para isso precisamos entender melhor o que significa estes “objetos”. Se pensarmos em um grupo de pessoas unidas a um bem comum (uma sociedade, por exemplo) vamos verificar claro que este grupo é formado por varias pessoas onde cada uma assume uma função dentro do grupo para atingir o tal bem comum. Cada pessoa do grupo é especialista em alguma coisa que pode ajudar o grupo a andar ao encontro do objetivo traçado. Cada elemento deste grupo executa a sua tarefa e ao mesmo tempo se comunicando com outros elementos do grupo. Ao se comunicar uns com os outros, ele estabelece um relacionamento entre si que vai auxiliar na conclusão de suas tarefas. Esta comunicação serve para simplesmente avisar que a sua tarefa foi concluída ou para pedir auxilio na conclusão da tarefa, pois a casos em que algumas atividades das tarefas delegadas ao elemento não são de total domínio dele, sendo assim ele precisa da ajuda de um elemento mais especializado naquele momento.

     Da mesma forma, é um programa orientado a objetos. Onde o grupo é o programa (executável), os elementos do grupo são os objetos do programa.

     Cada objeto dentro do programa é como um elemento do grupo (sociedade) que possui funções especifica dentro do programa. Cada objeto desempenha uma função dentro do programa para que o programa atinja o seu objetivo. Estes objetos também se relacionam entre si da mesma forma que os elementos de um grupo também se relacionam.

     Dentro do paradigma orientado a objeto, existem algumas regras para que o cenário exemplificado acima possa ser implementado como um projeto orientado a objetos. Para que um objeto possa ser criado dentro de um POO (Programa Orientado a Objeto), é preciso descrevê-lo de uma forma que fique bem detalhado como será este objeto, suas características e como ele vai se comportar dentro do POO ou seja, o que exatamente ele vai fazer dentro do sistema. Para isso existe o conceito de Classe. A classe é a maneira adotada na POO para descrever os objetos, é dentro de uma classe que definimos tudo o que o objeto pode fazer quais os dados ele vai poder manipular e com quem ele pode se relacionar.

     Por exemplo, vamos imaginar uma receita de bolo. Para fazer um bolo, é preciso conhecer a receita do mesmo, pois lá estão definidos os ingredientes que vamos usar e o modo de preparar. Quando usamos esta receita, estamos nos baseando nela para criar um bolo. Desta forma fica claro que vamos comer o bolo e não a receita, então usamos uma descrição de como se deve fazer um bolo, e o resultado é o bolo assado. O bolo só existe por que tem uma receita dizendo como deve ser um bolo e alguém foi lá e o criou com base nesta descrição.

            Para projetarmos sistemas orientado a objetos precisamos conhecer e aprender a usar ferramentas de modelagem que utilizem uma linguagem padrão para descrevermos os objetos do projeto. Ésta linguagem é a UML.

  

Leia um pouco sobre o Ciclo de Vida de Desenvolvimento de Software?

Ciclo de Vida de Desenvolvimento de Software

     Para começarmos a falar sobre projeto orientado a objeto, vamos relembrar alguns conceitos da engenharia de software.

      No mundo real, é importante abordar projetos de desenvolvimento de software de uma forma estruturada e sistemática para garantir que a solução atende plenamente as necessidades do usuário final. Vamos fazer um breve estudo sobre o ciclo de desenvolvimento de software.

     Mesmo os projetos de software mais simples podem ser divididos em várias fases. A quantidade e os nomes dessas fases podem ser diferentes de um autor para outro, mas a maioria das descrições do ciclo de vida de desenvolvimento de software compartilham os mesmos elementos comuns:

1. Determinar os requisitos do software desejado (Fase de analise).
2. Produzir um projeto que atenda aos requisitos (Fase de projeto).
3. Construir (programar) o software projetado (Fase de construção).
4. Verifique se o software atende aos requisitos (Fase de testes).
5. Manter o software ao longo de sua vida (Fase de manutenção).

     Muitos desenvolvedores de software, especialmente os novatos, saltam imediatamente para a fase 3 sem dedicar tempo suficiente para as duas primeiras e últimas fases. 

     O modelo de ciclo de vida clássico no campo de Sistemas de Informação é o modelo cascata. Esta abordagem é normalmente usada em grandes projetos envolvendo muitos desenvolvedores. O projeto progride através de cada fase em uma sequência precisa. Os membros da equipe de desenvolvimento pode realizar uma revisão no final de cada fase para determinar se o projeto deve continuar para a próxima fase. O modelo cascata distingue-se como um processo dirigido a documento. Os documentos são as saídas de uma fase, e as entradas para a próxima fase, é um registro de que o trabalho numa fase foi devidamente concluída.

     Uma das desvantagens do modelo cascata é que ele é muito inflexível. Como resultado, uma abordagem mais recente substituiu o modelo em cascata pelo modelo de Prototipagem Rápida. Este modelo tem as mesmas fases básicas, mas coloca uma ênfase na criação de um protótipo. Isto torna possível identificar deficiências no projeto antes de um grande esforço ter sido dispendido no projeto. O protótipo na verdade não faz nada de útil; ele da ao cliente uma visualização mais útil do produto final baseado nos requisitos. Para software que tem uma interface gráfica do usuário, uma boa quantidade de código de programação do aplicativo depende da configuração dos controles de interface. Neste modelo, o desenvolvedor terá a certeza de obter o modelo aprovado pelo cliente antes de escrever muito código.

     Embora haja uma série de outros modelos de ciclo de vida lá fora, o modelo de Prototipagem Rápida é, provavelmente, o mais adequado para pequenas e médias projetos. 

Requisitos fase de estudo

      A primeira parte da fase de requisitos se discute com o cliente sobre o produto e o que se espera do mesmo. Neste ponto, é importante identificar eventuais problemas que possam aparecer no caminho do pprojeto. Estas restrições podem incluir prazos de entrega do produto final, as limitações técnicas (por exemplo, se o cliente tem o hardware / software necessário para utilizar o produto), e as restrições orçamentais (O cliente pode pagar para o desenvolvimento do produto?) .

Fase de Projeto

      Na fase de projeto, o desenvolvedor produz um modelo que atenda aos requisitos enunciados na descrição do produto. Esta é a fase em que o desenvolvedor cria um protótipo, que pode começar como um esboço simples de uma interface de usuário. O objetivo da fase de projeto é a de criar um esqueleto do produto final, com o objetivo de apresentar ao cliente para obter feedback. 

      Ao projetar um protótipo, uma série de fatores devem ser considerados:

• Como dados de entrada exigidos seja a partir de um banco de dados, através de um formulário web ou através de caixas de entrada.
• Como as entradas devem ser processadas para se chegar ao resultado desejado.
• Qual é o formato da saída, um relatório, exportação para um arquivo etc.

      Durante o processo de design, o desenvolvedor deve resistir à tentação de escrever muito código. A única codificação que deve ser feito nesta fase é que o que é necessário para dar ao cliente uma ideia de como o produto final irá operar. Por exemplo, os botões podem ser codificados para abrir formulários ou para exibir caixas de mensagens que descrevem o que os botões vão fazer quando a aplicação estiver concluída, o código pode ser adicionado para preencher caixas de listagem, etc.

Leia um pouco sobre os Conceitos básicos de Sistemas Operacionais?

Conceitos básicos de Sistemas Operacionais

 PROCESSOS 

Como trabalhar com vários programas em um mesmo tempo de execução ???

Ao iniciar o computador você pode acessar vários softwares ao mesmo tempo, como exemplo, um editor de texto, uma planilha eletrônica, ou qualquer outro.

E ainda, dentro destes softwares, é possível executar várias funções praticamente ao mesmo tempo em um único processador!!!

Então, como isso pode ser possível ???

Para isso, o computador pode contar com o gerenciamento de um sistema operacional

Na realidade, se o computador possui apenas um processador, ele executará somente uma instrução em um determinado instante

O que acontece, é que uma execução é muito rápida, o que significa que em menos de 1 segundo diversas instruções podem ser executadas.

Com essa velocidade é possível ter a execução de vários programas ao mesmo tempo.

Nesse contexto, um sistema (software) possui vários tipos de tarefas que são chamadas de PROCESSOS.

Um processo pode ser entendido como um programa em execução, e para sua execução serão necessários alguns recursos, como: CPU, memória, arquivos, entre outros. Dessa forma,

Um processo é representado no sistema operacional por um bloco de controle de processo (PCB — Process Control Block).

PCB

Ponteiros

Estado do Processo

Nome do Processo

Prioridade do Processo

Registradores

Limites de memória

Lista de arquivos abertos

.    .    .

O sistema operacional reserva uma área da memória onde coloca informações sobre cada processo a ser executado.

As alocações das informações em um PCB (bloco de controle de processos) estão divididas em duas classes:

No contexto de hardware contém basicamente uma cópia dos registradores.

Quando um processo está em execução, seu contexto de hardware está armazenado nos registradores do processador; quando o processo perde o controle do processador, os dados dos registradores são salvos no contexto de hardware.

Dessa forma, o processo que está deixando o processador será salvo para liberar a entrada de um novo processo.

O contexto de software contém informações como a identificação do processo:

-  QUOTAS (número de arquivos que pode utilizar, tamanho máximo de memória, número máximo de operações de E/S pendentes etc.)

-  PRIVILÉGIOS

Estados do processo

O estado do processo indica o que está acontecendo com aquele processo num determinado instante de tempo.

Um processo pode estar em um dos seguintes estados:

• novo: o processo está sendo criado;

• pronto: o processo está esperando a liberação do processador para que possa executar;

• em execução: as instruções estão sendo executadas;

• em espera: o processo está esperando pela ocorrência de algum evento (por exemplo, o término de uma operação de E/S);

• terminado: o processo terminou sua execução.

Mudanças de estado

À medida que um processo vai sendo executado, ele passa pelos diversos estados.

As mudanças de estado acontecem nas seguintes situações:

• Novo → pronto: logo após o programa ser criado.

• Pronto → execução: o programa é selecionado para ganhar o controle do processador, e recebe uma fatia de tempo do processador.

• Execução → pronto: terminou a fatia de tempo do processo, mas ele ainda não encerrou.

• Execução → espera: o processo que estava em execução solicitou uma operação de E/S.

• Espera → pronto: o processo que estava esperando por um evento teve esse evento concluído.

• Execução → terminado: o processo encerrou.

Quando um processo está em execução, parte dos seus dados está armazenada nos registradores da UCP.

Entre esses registradores está o PC (Program Counter), que é o registrador que aponta para a próxima instrução a ser executada.

À medida que cada instrução é executada, o IP vai sendo incrementado, de maneira a apontar para a instrução seguinte.

Para conseguir executar diversos processos ao mesmo tempo, o processador tem seu tempo compartilhado (Time Sharing).

Isso quer dizer que cada processo tem direito a utilizar o processador durante uma determinada fatia de tempo. Então, quando acaba a fatia de tempo de um processo, ele volta ao estado de pronto e aguarda a sua vez de ganhar uma nova fatia.

Além disso, quando um processo necessita de algum outro recurso além da CPU, por exemplo, precisa aguardar uma operação de E/S, ele libera o processador para que outro processo o utilize.

Nesse caso, ele sai da execução para o estado de espera.

Quando ocorre a troca de processos na utilização do processador, dizemos que ocorreu uma “mudança de contexto”.

Na mudança de contexto os registradores da UCP são salvos no PCB do processo que está saindo da execução, e são carregados os valores salvos no PCB do processo que irá entrar em execução.

Vamos ver passo a passo:

1. Um novo processo é criado (o usuário solicitou a execução de um programa). Durante a sua criação ele está no estado de novo, e nessa hora o sistema operacional cria o seu PCB, com os registradores inicializados.

2. Após a criação, o processo passa para o estado de pronto, e entra na fila para ganhar uma fatia de tempo do processador.

3. Quando a CPU está desocupada, esse processo passa do estado de pronto para execução. Nesse momento os valores dos registradores armazenados no PCB são copiados para os registradores da UCP. Como um desses registradores é o PC (Program Counter), a próxima instrução que o processador irá executar será a primeira instrução desse processo.

4. A cada instrução executada o PC vai sendo incrementado.

5. Caso se esgote o tempo do processador, ou o processo necessite de algum recurso, o conteúdo dos registradores da UCP é copiado para o PCB, e então o sistema operacional carrega o próximo processo da fila de pronto, voltando ao passo 3.

Leia um pouco sobre a Tecnologias de Informação (TI)

Tecnologias de Informação (TI)

A TI (Tecnologia da Informação) oferece recursos tecnológicos para a tratar dados e/ou informações. E, os sistemas de informação desenvolvidos com base nessa tecnologia  coletam, manipulam e disseminam  as  informações geradas  em uma organização potencializando sua capacidade no mercado competitivo. Os componentes da TI são:  Hardware, software, dados, redes e Telecomunicações.

Batista (2006, p.59), define: 

“Tecnologia da informação é todo e qualquer dispositivo que tenha a capacidade de tratar  dados e/ou informações  tanto de forma sistêmica como esporádica, independentemente da maneira como é aplicada”

 Hardware

É sabido que um computador é um equipamento eletrônico que possui grande capacidade de manipular grandes quantidades de informações com uma velocidade extremamente rápida.

O computador pode ser definido como o conjunto de componentes e acessórios eletrônicos que tem como função principal receber dados de entrada, executar os processamentos requeridos de acordo com a necessidade do usuário e apresentar as informações de saída no formato desejado.

Software 

Para Laudon e Laudon (2001, p.128):

[...] software são as instruções detalhadas que controlam a operação de um sistema de computador. Sem o software, o hardware de computador não poderia executar as tarefas que associamos a eles.

O  computador necessita do software para executar as tarefas. Segundo Boghi e Shitsuka (2005, p.107) “software é o combustível do computador, é a parte lógica, é o conjunto de instruções cuja finalidade é a realização de tarefas pelo computador”.

Gerenciamento de  dados

O sucesso de uma organização depende  da sua capacidade de  processar e distribuir seus dados.  Por isso,   deve-se definir corretamente o banco de dados  de uma organização pois, ele tem  um impacto direto sobre todo o sistema de informação.

Os sistemas de informação organizam  os dados  segundo a hierarquia de banco de dados como caracteres, campos, registros etc...

Hierarquia de Bancos de Dados:

Caracter: O caracter é o elemento lógico mais simples dos dados, possível de ser  observado e manipulado. Consiste em um único símbolo alfanumérico.

Campo: Consiste em um conjunto de caracteres agrupados que podem representar um atributo de uma entidade.

Registro: Consiste em um conjunto de campos agrupados . Um registro,  representa uma coleção de atributos que descrevem uma entidade.

Arquivo: É um  conjunto  de registros afins agrupados. Um arquivo contém  registros de todas  as  operações em um determinado período de tempo.

Banco de dados: é um agrupamento lógico de arquivos relacionados.

Dessa forma podemos observar que o banco de dados de uma organização tem grande valor e importância para uma empresa. Pois, todos os dados que são transformados em informação estão lá armazenados.

Ao administrador cabe a tarefa de assegurar que estes dados sejam bem cuidados.

Metodologias de Desenvolvimento de Software - Principais!

         Metodologias Ágeis (principais)

     Dentre as metodologias ágeis para desenvolvimento de software podemos citar: Scrum (para gestão de projetos e que pode ser aliada a outra metodologia ágil), eXtreme Programming, Feature Driven Development (FDD), Test Driven Development (TDD), Dynamic Systems Development Method (DSDM), Adaptive Software Development, Crystal e Pragmatic Programming. Nas descrições a seguir, citaremos as quatro primeiras metodologias.

1.   Scrum

     Scrum é um framework simples para colaboração em equipe eficaz em projetos complexo, fornecendo um pequeno conjunto de regras que criam uma estrutura para que as equipes sejam capazes de concentrar seus esforços na resolução de problemas. Apoia o aproveitamento de competências de cada membro do time.

     Para a construção de produtos complexos para os clientes é uma tarefa inerentemente difícil fornece uma base para permitir que equipes para lidem com essa dificuldade [17]. 

Podemos elencar as seguintes características do Scrum:

•          clientes se tornam parte da equipe de desenvolvimento;
•          entregas frequentes e parciais de funcionalidades 100% desenvolvidas;
•          planos de mitigação de riscos desenvolvidos pela equipe;
•          reuniões diárias de status com a equipe;
•          A reunião diária na qual cada membro da equipe responde às seguintes perguntas:

ü  O que fiz desde ontem?

ü  O que estou planejando fazer hoje?

ü  Existem impedimentos?

•          transparência no planejamento e desenvolvimento;
•          reuniões frequentes com os stakeholders (todos os envolvidos no processo) para monitorar o progresso;
•          problemas não são ignorados e ninguém é penalizado por reconhecer ou descrever qualquer problema não visto.

Os principais papéis atuantes no Scrum são:

      i.        product owners: responsável por determinar o que precisa ser construído;

    ii.        time: responsável por construir o que é necessário e, em seguida, demonstrar o que o que foi construído. Com base nesta apresentação, o Product Owner determina as demais prioridades.

   iii.        scrum master: responsável por garantir que esse processo aconteça da melhor forma possível, e deve ajudar na sua melhora contínua.

Na figura a seguir, visualize os detalhes do Scrum.

Figura 5 – Scrum

      Dentre as vantagens do Scrum podemos citar: velocidade, motivação do time de desenvolvimento, redução de surpresas com os resultados, diminuição de defeitos, revisão de prioridades, etc.. Em relação às desvantagens, pode-se elencar: sensação de informalidade, diferença entre a ideia inicial e a final, alteração de prazo de entrega do produto final em decorrência da constante mudança de escopo e falta de planejamento do escopo [17] [18] [19] .

2. eXtreme Programming (XP)

     A XP é uma metodologia ágil para equipes pequenas e médias que desenvolvem software baseado em requisitos vagos e que se modificam rapidamente. Seus cinco valores fundamentais XP são: comunicação, simplicidade, feedback, coragem e respeito. Com base nesses valores, possui como princípios básicos: feedback rápido, presumir simplicidade, mudanças incrementais, abraçar mudanças e trabalho de qualidade.

      A XP segue uma abordagem orientada a objetos como paradigma de desenvolvimento e envolve quatro atividades metodológicas:

•          Planejamento;
•          Projeto;
•          Codificação;
•          Testes.

Para aplicar os valores e princípios durante o desenvolvimento de software, XP propõe uma série de práticas:

•          planejamento (Planning games): são definidas as prioridades e estimativas. Nesta prática são determinadas as histórias que descrevem funcionalidades a serem implementadas;
•          pequenas entregas (Small Releases): pequenas versões funcionais do projeto são liberadas com o intuito de auxiliar no processo de aceitação por parte do cliente, que já pode testar uma parte do sistema que está adquirindo;
•          testes de aceitação (Customer Tests): foco na validação do projeto durante todo o processo de desenvolvimento. São testes elaborados pelo cliente, sendo os critérios de aceitação do software;
•          integração contínua (Continuous Integration): ao produzir uma nova funcionalidade, esta deve ser integrada a versão atualizada do sistema. Assim, minimizará possíveis conflitos e erros no código fonte;
•          metáfora (Metaphor): descrições de um software sem a utilização de termologia técnica com o objetivo de orientar o desenvolvimento;
•          refatoração(Refactoring): foco na melhoria contínua do projeto e está presente em todo o ciclo de desenvolvimento;
•          design Simples (Simple Design): simplicidade na codificação;
•          desenvolvimento Orientado a Testes (Test Driven Development): primeiramente, são criados os testes unitários e depois, o código é criado para que os testes funcionem;
•          40 horas de trabalho semanal (Sustainable Pace): foco no trabalho com qualidade e com ritmo saudável. Horas extras são permitidas quando trouxerem produtividade para a execução do projeto.
•          padronização do código (Coding Standards): padronização na arquitetura do código para que este possa ser compartilhado entre todos os desenvolvedores;
•          propriedade coletiva: o código pertence a todos os integrantes do time, sendo que toda contribuição de melhoria será benéfica para o projeto;
•          programação em pares (Pair Programming): o desenvolvimento é realizado em pares, obtendo uma melhor qualidade de testes, códigos e design.

     As principais vantagens da XP são: agilidade e flexibilidade no desenvolvimento, ideal para os casos que o cliente não sabe exatamente quais são os requisitos do software, feedback constantes, adaptações às mudanças e entregas constantes.

     Dentre as desvantagens estão: não existe avaliação de riscos, a análise de requisitos é informal, Refatoração pode ser vista como irresponsabilidade e incompetência, barreira cultural empresarial e a falta de documentação.

1. Feature Driven Development (FDD) 

A FDD - Desenvolvimento Guiado por Funcionalidades - é uma metodologia ágil para gerenciamento e desenvolvimento de software. Combina as melhores práticas do gerenciamento ágil de projetos com uma abordagem completa para Engenharia de Software orientada por objetos, considerando os três principais públicos de um projeto de software: clientes, gerentes e desenvolvedores. 

A FDD apresenta algumas características peculiares: 

•          planejamento detalhado e guias para métricas;
•          bloco bem pequenos de funcionalidades valorizadas pelos cliente, chamados “Features”;
•          resultados úteis a cada iteração;
•          rastreabilidade e relatórios precisos;
•          monitoramento detalhado dentro do projeto, com resumos de alto nível para clientes e gerentes. 

Basicamente, essa metodologia é bem objetiva, possuindo apenas duas fases:  

•          concepção e planejamento: reflexão e planejamento do que vai ser feito;
•          construção: desenvolvimento de forma iterativa.

 A imagem a seguir, apresenta uma visão detalhada da FDD. 

Figura 6 – FDD

 

Os cinco processos são bem definidos e integrados: 

• DMA (Desenvolver um Modelo Abrangente): o produto é um modelo de objetos (e/ou de dados) de alto nível, que conduzirá a equipe durante os ciclos de construção;
• CLF (Construir a Lista de Funcionalidades): decomposição funcional do modelo do domínio, resultando em uma hierarquia de funcionalidades que representa o produto a ser construído;
• PPF (Planejar por Funcionalidade): o resultado é um plano de desenvolvimento, com os pacotes de trabalho na sequência adequada para a construção;
• DPF (Detalhar por Funcionalidade): criação de um modelo de domínio mais detalhado e os esqueletos de código prontos para serem preenchidos;
• CPF (Construir por Funcionalidade): codificação, testes e inspeções, resultando em um incremento do produto integrado ao repositório principal de código, com qualidade e potencial para ser utilizado pelo usuário. 

Dentre as principais vantagens da FDD estão: recomendada para qualquer tipo de desenvolvimento, foco nos aspectos que agregam valor ao cliente, possui requisitos formais, entre outros.

As principais desvantagens são: questionamentos sobre eficácia da metodologia, desconhecimento sobre o tamanho exato do time FDD e manutenções.

 2. Test Driven Development (TDD) 

     O Test Driven Development (TDD) - Desenvolvimento orientado a testes - é uma técnica de desenvolvimento de software que baseia em um ciclo curto de repetições, em que primeiramente, são criados os testes e somente depois é escrito o código necessário para passar por eles.

Um desenvolvimento TDD proporciona alguns benefícios, tais como:

• melhor entendimento do negócio do sistema: antes de começar a implementar algum código, o engenheiro deve entender o problema/funcionalidade e projetar a solução. Baseando nessa metodologia, precisamos projetar os testes antes;
• criação de testes ricos: o código deve passar no teste previamente implementado;
• confiança no código: possibilidade de confiança no código entregue;
• maior valor agregado ao produto: entregar um produto ao cliente já com os testes implementados, representa uma entrega de maior valor agregado ao produto.

 A figura a seguir, mostra as etapas da TDD. 

 Figura 7 – TDD

 

As vantagens do TDD são: 

•          facilidade na criação de código com alta coesão e baixo acoplamento;
•          mantém alta cobertura do código
•          facilidade do Refactoring;
•          pode ser entendida como documentação;
•          reduz o tempo de identificação e correção de defeitos.

 Como principais desvantagens, podemos citar: 

•          desenvolvimento inicial mais lento;
•          custo mais elevado de manutenção dos códigos de teste, além do código fonte.

Metodologias de Desenvolvimento de Software - Tradicionais e Clássicos!

Modelos Tradicionais ou Clássicos

1.   Modelo Cascata

      O modelo cascata é o mais antigo modelo utilizado e representou um avanço no desenvolvimento de software, foi proposto por Royce em 1970.  Até meados da década de 1980 foi o único modelo com aceitação geral. Comparado com outros modelos de desenvolvimento de software, este é mais rígido e menos administrativo, pois: inicialmente, é necessário compreender completamente o problema a ser resolvido, requisitos e restrições; após, projeta-se soluções que atendam a todos os requisitos e restrições. Na sequência, inicia-se a implementação do projeto e ao ser finalizada, o produto é verificado e validado junto ao cliente e por fim, a entrega final é efetuada. Na figura a seguir, é possível visualizar o modelo segundo.

Figura 1- Modelo em Cascata

 

As principais vantagens desse modelo são: 

•  tornar o processo de desenvolvimento estruturado, sequenciando cada fase e criando dependência entre elas;
•  todas as atividades são identificadas nas fases do modelo;
•  avança para a tarefa seguinte quando o cliente valida e aceita os produtos finais da tarefa atual.

As principais desvantagens do modelo cascata são: 

• não fornece feedback entre as fases e não permite a atualização ou redefinição das fases anteriores;
• não prevê a manutenção;
• as atividades são sincronizadas e inflexíveis;
• o produto é entregue somente no final do projeto;
• não suporta modificações de requisitos;
• dependência entre as fases compromete o projeto como um todo, caso haja um atraso.

2. Modelo Iterativo e Incremental

O modelo iterativo e incremental foi criado em resposta às fraquezas do modelo cascata. Podemos entendê-lo como: 

• incremental: gerar novas versões incrementadas a cada release;
• iterativo: ter várias iterações na linha do tempo do projeto. A saída de uma iteração é examinada para modificação, e especialmente para revisão dos objetivos das iterações sucessivas. 

A ideia base da abordagem iterativa é desenvolver um sistema de software incremental, permitindo ao desenvolvedor extrair benefícios daquilo que foi aprendido durante a fase inicial de desenvolvimento de uma versão do sistema. O aprendizado ocorre simultaneamente tanto para o desenvolvedor, quanto para o usuário do sistema [11]. Na figura 2, o modelo é ilustrado:

Figura 2 - Modelo Iterativo e Incremental 

 

As principais vantagens do modelo são: 

• baseia-se fortemente na participação e uma boa comunicação entre desenvolvedores e usuários;
• envolvimento do usuário e do cliente. Caso ocorram divergências, elas são rapidamente tratadas;
• apresentação de resultados rápidos;
• a cada ciclo do sistema os usuários e cliente poderão utilizar o sistema diretamente, eles são os "testadores" no processo de desenvolvimento e eles estarão interagindo com o sistema durante o desenvolvimento;
•  administração de riscos por ciclo do sistema;
•  feedback ao final de cada iteração permite que ações rápidas sejam tomadas em caso de mudanças no sistema;
•  alterações nos requisitos podem ser rapidamente incorporada no processo de desenvolvimento;
•  versões são geradas após cada iteração;
•  flexibilidade e facilidade para gerenciar processo mais administráveis e fazer um software melhor com uma melhor estrutura;
•  simplicidade dos testes.

As principais desvantagens do modelo iterativo e incremental são: 

• necessidade de  adaptação e refinamento do sistema pode acarretar mudança da ideia original ao final do desenvolvimento;
• aumento de escopo constante;
• inexperiência de gerentes que não estão acostumados com essa forma de trabalho;
• necessidade de conhecimento para iniciar a utilização do modelo;
• podem surgir problemas relacionados à arquitetura do sistema, pois não há uma visão completa dos requisitos;
• as releases do sistema devem ser pequenas.

 3. Modelo Prototipação 

     Este modelo é baseado em uma visão evolutiva do desenvolvimento de software, afetando o processo como um todo. Abrange a produção de versões iniciais – protótipos (comparável às maquetes para a arquitetura) - de um sistema futuro com o qual é possível realizar verificações e experimentos, com o objetivo de avaliar algumas de suas características antes de sua construção definitiva [12] [13]. A figura (Figura 3) a seguir apresenta a visão do modelo.

  

Figura 3 - Modelo Prototipação

 

As vantagens desse modelo são:  

• diferenças entre as percepções do cliente e dos desenvolvedores são clarificadas;
• um sistema funcional é mostrado antecipadamente;
• o protótipo pode servir de base para especificação do sistema;
• identificação de necessidade de treinamento dos usuários e esquema de testes;
• contribuição para desenvolvimento de partes complexas do sistema;
• envolvimento do cliente na avaliação do protótipo.

As principais desvantagens do modelo são:  

•  questões gerenciais, tais como esquemas menos estruturados e dificuldade de planejamento de competências do time para o desenvolvimento do sistema;
• problemas de manutenção ocasionadas pelas constantes mudanças na estrutura do sistema;
• problemas contratuais.

3. Modelo Espiral  

       O modelo em espiral foi proposto por Boehm em 1988 como forma de integrar os diversos modelos existentes à época, abrangendo as melhores características tanto do ciclo de vida clássico como da prototipação, adicionando, ao mesmo tempo, um novo aspecto - a análise de riscos - que falta a esses modelos. Este modelo assume que o processo de desenvolvimento ocorre em ciclos, cada um contém fases de avaliação e planejamento, onde a escolha de abordagem para a próxima fase (ou ciclo) é determinada. 

O modelo espiral está dividido em quatro atividades principais: 

1. Planejamento: determinação dos objetivos, alternativas e restrições;
2. Análise dos riscos: análise de alternativas e identificação/resolução de problemas e riscos;
3. Engenharia: desenvolvimento do produto e verifica-lo no próximo nível;
4. Avaliação feita pelo cliente: avaliação dos resultados da engenharia.
    

Na figura a seguir, é possível visualizar todos os detalhes do ciclo desse modelo.
 

Figura 4 - Modelo Espiral

 

As vantagens do modelo são:  

• permite que ao longo de cada iteração se obtenham versões do sistema cada vez mais completas, recorrendo à prototipação para  redução de riscos;
• permite o refinamento seguido pelo modelo cascata, mas que incorpora um desenvolvimento iterativo.

As desvantagens do modelo são:  

• necessidade de conhecimento e experiência na avaliação de riscos;
• não tem sido amplamente utilizado;
• desenvolvimento em paralelo de múltiplas partes do projeto, cada uma sendo abordada de modo diferenciado, por isso é necessário o uso de técnicas específicas para estimar e sincronizar cronogramas, bem como para produzir os indicadores de custo e progresso mais apropriados.