# data[].attributes.headline
Modelo de Produção de Software – Cascata

# data[].attributes.subject
Modelo de Produção de Software – Cascata

# data[].attributes.body
O modelo de produção em cascata possui esse nome devido o encadeamento que ocorre entre uma fase e a próxima.

É um processo que deve sempre ser planejado antes de começar a trabalhar nele.

Os passos a serem seguidos são:

1. Definição de requisitos: É onde andava de consulta ao usuário se define as metas, serviços e restrições.

2. Projeto de sistemas e software: neste ponto se define os principais requisitos de hardware e software.

3. Implementação e teste unitário: neste momento se desenvolve como um conjunto ou unidade de programa, o teste unitários envolve a verificação de que cada uma das unidades atendem as especificações definidas anteriormente.

4. Integração e teste de sistema: neste processo as partes do programa é integrada e testada como um sistema completo, e neste momento se o sistema atende as especificações do cliente então será entregue a ele.

5. Operação e manutenção: essa é a fase mais longa pois engloba correções, implementações e melhorias para adequar a novas e pequenas especificações.

A ordem deve ser respeitada e um passo só pode ser inicializado mediante a finalização do passo anterior.

No modelo de definição em cascata, em cada uma de suas fases é gerado uma documentação, tornando visível o estágio que está o desenvolvimento conforme o mesmo avança.

A principal desvantagem deste modelo é a impossibilidade de se dividir em estágios distintos.

O modelo de desenvolvimento em cascata só deve ser usado quando compreendemos exatamente as especificações do cliente.

# data[].attributes.headline
Modelo de Produção de Software – Espiral

# data[].attributes.subject
Modelo de Produção de Software – Espiral

# data[].attributes.body
Foi criado por Barry Boehm;

O modelo espiral é, assim como prototipação, considerado um modelo evolucionário, por serem iterativos e apresentarem características que possibilitem desenvolvermos versões cada vez mais completas do software;

É um modelo que engloba as características dos outros processos criados anteriormente, prevendo prototipação, desenvolvimento evolutivo e cíclico, e as principais atividades do modelo cascata.

É desenvolvido a partir de análises de riscos e planejamento. São exemplos de riscos: pessoas que abandonam a equipe de desenvolvimento, ferramentas que não podem ser utilizadas, etc.

Tem modelo cíclico e evolutivo, o qual é constituído de 4 partes:

1. São determinados os principais objetivos, restrições do projeto e soluções alternativas;

2. São analisados os riscos da etapa anterior e modelos e/ou simulações podem começar a ser feitas no software;

3. Consiste basicamente na parte de desenvolvimento do software, especificação de requisitos, do software, da arquitetura, da interface de usuário e dos algoritmos e dados;

4. Revisão das etapas anteriores e planejamento da próxima fase com base nos resultados obtidos anteriormente. Com esses resultados, pode-se optar por seguir o desenvolvimento em diferentes modelos.

Diferentemente de outros tipos de modelos, o espiral permite que o software seja modelado a cada conclusão. O projeto é finalizado quando o cliente fica satisfeito.

# data[].attributes.headline
RUP (Rational Unified Process - Processo Unificado da Rational)

# data[].attributes.subject
RUP (Rational Unified Process - Processo Unificado da Rational)

# data[].attributes.body
É um processo de desenvolvimento de software com uma abordagem a orientação a objetos.

Foi criado pela Rational Software Corporation e adquirida pela IBM ganhando o nome de IRUP.

Projetado e documentado utilizando notação UML para abstrai os processos em ação.

O RUP define as seguintes linhas-mestras e templantes:

Gestão de requisitos.

Arquitetura baseada em componentes.

Software de modelos visuais.

Verificação da qualidade de software.

Gestão e controle de mudanças de software.

É dividido em 4 fases de projeto:

Concepção: ênfase no escopo do sistema.

Elaboração: ênfase na arquitetura.

Construção: ênfase no desenvolvimento.

Transição: ênfase na implantação.

# data[].attributes.body
O Manifesto Ágil é uma declaração de valores e princípios essenciais para o desenvolvimento de software.

Ele foi criado em fevereiro de 2001, onde se reuniram 17 profissionais que já praticavam métodos ágeis como XP, DSDM, SCRUM, FDD e etc.

Os 17 autores

Kent Beck, criador do XP;

Mike Beedle, CEO, Enterprise Scrum Inc.;

Arie van Bennekum;

Alistair Cockburn;

Ward Cunningham, desenvolveu o primeiro Wiki;

Martin Fowler, Chief Scienist da ThoughtWorks;

James Grenning;

Jim Highsmith;

Andrew Hunt;

Ron Jeffries, um dos criadores do XP;

Jon Kern;

Brian Marick;

Robert C. Martin;

Steve Mellor;

Ken Schwaber, co-criador do Scrum e Head da Scrum.org;

Jeff Sutherland, co-criador do Scrum e CEO da Scrum Inc.;

Dave Thomas;

# data[].attributes.body
No Scrum, os projetos são dividos em ciclos (iterações) chamados de Sprints. O Sprint representa um Time Box dentro do qual um conjunto de atividades deve ser executado. Possuem um prazo de tempo definidos (geralmente de um mês).

Scrum possui seu foco no gerenciamento e projeto da organização onde é difícil planejar à frente.

Incorpora as seguintes atividade estruturais: requisitos, análise, projeto, evolução e entrega.

Utiliza um conjunto de padrões de processo de software que se provaram eficazes para projetos com prazo de entrega apertado, requisitos mutáveis e críticos de negócio.

Há 3 componentes essenciais quando se quer aplicar o SCRUM:

1) Os Papeis: No Scrum há três papeis principais.

Product Owner: representa a voz do cliente e é responsável por garantir que a equipe agregue valor ao negócio. O Product Owner escreve centrado nos itens do cliente (histórias tipicamente do usuário), os prioriza e os adiciona para o product backlog.

Scrum Master: é responsável pela remoção de impedimentos à capacidade da equipe para entregar o objetivo da sprint. Ele garante que o processo Scrum seja usado como pretendido. O Scrum Master é o responsável pela aplicação das regras.

Equipe (Development Team): A equipe de desenvolvimento é responsável pela entrega do produto. É tipicamente composta entre 5 a 9 pessoas com habilidades multifuncionais que fazem o trabalho real.

2) Backlog: É uma lista com as prioridades dos requisitos ou funcionalidades que fornecem valor comercial ao cliente.

Product Backlog: é mantido pelo Product Owner e é uma lista de requisitos que tipicamente vêm do cliente. Podem ser alteradas a qualquer momento.

Sprint Backlog: é uma lista de itens selecionados do Product Backlog e contém tarefas concretas que serão realizadas durante a próxima Sprint para implementar tais itens selecionados.

2) Eventos Scrum:

Reuniões Scrum (Daily Scrum Meeting): Reuniões curtas realizadas diariamente pela equipe Scrum, ondem devem ser respondidos três questões-chave: o que foi feito ontem, encontrou algum obstáculo e o que será feito ainda hoje.

Ao final de um Sprint, a equipe apresenta as funcionalidades implementadas em uma Sprint Review Meeting. Finalmente, faz-se uma Sprint Retrospective e a equipe parte para o planejamento do próximo Sprint (Sprint Planning Meeting).

* Ao completar uma sprint a Equipe Scrum deve ser capaz de apresentar um “entregável”, um incremento ou uma nova funcionalidade ao projeto.

# data[].attributes.body
Prototipação é uma técnica que procura simular ao usuário o funcionamento do sistema que será desenvolvido. Por meio de um esboço o protótipo simula ao usuário as funcionalidades que o sistema terá. É caracterizada como um modelo evolucionário.

A prototipação tem por objetivo refinar os requisitos funcionais, técnicos e estéticos dos usuários, objetiva também, dar ao usuário uma noção de como seus requisitos serão implementados e mostrar uma prévia do que será seu sistema sem que haja desenvolvimento.

A prototipação é utilizada quando o desenvolver não tem certeza quanto à eficiência de um algoritmo, ou quanto à adaptabilidade de um sistema operacional ou ainda quanto à forma em que deva ocorrer a interação entre o cliente e o sistema. Quando temos essa situação a prototipação é uma excelente alternativa.

Vale ressaltar que a prototipação pode ser utilizada em qualquer processo de software, visto que a prototipação auxilia os interessados a compreender melhor o que está para ser construído.

Uma iteração de prototipação deve ser planejada rapidamente e dessa forma ocorre a modelagem na forma de um projeto rápido, da seguinte forma:

1. O projeto rápido foca na representação dos aspectos do software que serão visíveis aos usuários como layout da interface e os formatos de exibição.

2. Esse projeto rápido leva à construção de um protótipo que será avaliado pelo cliente.

3. O cliente por sua vez retornará um feedback á equipe de software que irá aprimorar os requisitos.

# data[].attributes.body
Extreme Programming (XP) é uma metodologia de desenvolvimento de software, nascida nos Estados Unidos ao final da década de 90. Vem fazendo sucesso em diversos países, por ajudar a criar sistemas de melhor qualidade, que são produzidos em menos tempo e de forma mais econômica que o habitual. Tais objetivos são alcançados através de um pequeno conjunto devalores, princípios e práticas, que diferem substancialmente da forma tradicional de se desenvolver software

Criado por Kent Beck, nos anos 1997.

Cobre diversos aspectos do desenvolvimento do software:

Codificação

Design

Testes

O XP é considerado uma proposta de desenvolvimento de software simples, que visa entregar o que o cliente solicitou, no prazo acordado com ele. Ele define uma equipe única de trabalho, e considera que os gerentes, clientes e desenvolvedores devem também formar uma equipe, dedicada e destinada a entregar software com mais qualidade.

# data[].attributes.body
Pair Programming

Quando duas pessoas trabalham em uma única máquina. Um colaborador codifica e o outro faz sugestões pertinentes, trocando de funções em determinado momento. Essa troca garante uma comunicação mais fácil, garantindo maior produtividade e um projeto de alta qualidade.

Projeto simples

Design simples e que permite a realização de testes. Essa prática garante que a criação em excesso de generalizações dentro do código fonte seja evitada e prepara o sistema para possíveis mudanças.

Teste

Cada funcionalidade de um projeto possui um teste antes de ser codificado, isso garante que não exista retrabalho entre os colaboradores e mantém a qualidade dos projetos.

Refatoração

É a mudança e melhoria do código, sem que seu comportamento e sua funcionalidade sejam alterados.

Propriedade coletiva

Qualquer colaborador pode modificar códigos e mexer em todas as partes do projeto. Isso garante que, caso alguém saia da equipe, o projeto não seja prejudicado.

Interação contínua

Os códigos são integrados e testados constantemente, para caso algum problema for detectado, seja corrigido imediatamente.

Cliente presente

O cliente deve estar presente para aprovação, definição de prioridade e auxiliar no desenvolvimento do projeto.

Semana de 40 horas

Evita-se trabalhar mais de 40 horas semanais, visando o bem-estar da equipe para manter o projeto em alta qualidade.

Padrões de código

O fato de todos os colaboradores participarem de todos os processos requer que um padrão na codificação seja mantido.

Metáfora

Uma linguagem comum garante que o entendimento de ideias seja simplificado, o intuito é que ideias complexas sejam passadas de forma simples.

Reunião diária

Nela se discutem o que foi feito anteriormente, o que está sendo feito no dia atual e o que ainda tem que ser feito.