domingo, 29 de abril de 2012

Engenharia de Software para Concursos - Parte 4 - Metodologias Ágeis

Existia a visão predoimante que o desenvolvimento de software deveria ser cuidadosamente planejado. A aplicação de todos os métodos de controle no desenvolvimento de softwares pequenos ou médios causava mais problemas do que solução. O desenvolvimento ficava muito demorado e caro. A insatisfação com o excesso de métodos tradicionais deu origem ao processo de desenvolvimento ágil.

Os métodos ágeis buscam flexibilizar o desenvolvimento de software, diminuir a burocracia, tornar o desenvolvimento mais rápido e permittir respostas rapidas às mudanças, que são o grande fator de falha nos projetos tradicionais.


Focam no código e não no projeto.
São baseados em abordagens iterativas.
Entrega-se o software de qualidade funcionando o mais breve possível.

Manifesto Ágil (2001) - Filosofia de qualquer método ágil
"Estamos evidenciando maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse trabalho passamos a entender que:

Indivíduos e interações são mais importantes que processos e ferramentas.
Software funcionando é mais importante do que documentação completa e detalhada.
Colaboração com o cliente é mais importante do que negociação de contratos .
Adaptação a mudanças é mais importante do que seguir o plano incial.

Ou seja, mesmo tendo valor os itens à direita, valorizamos mais os itens à esquerda."

A comunicação entre as pessoas é muito mais importante do que seguir uma linha de comando, processos burocráticos ou ferramentas específicas. A comunicação entre a equipe e os clientes é fundamental.

Sistemas que sofrem muita pressão por alteração atrasam pela demora em manter a documentação atualizada ou até mesmo para que ela seja criada. Depois de pronta, as vezes já está defasada.

"A verdade está no código"

Existem os processos orientados a planos e os processos de desenvolvimentos orientados ao valor agregado (métodos ágeis são value-driven e não plan-driven). O plano detalhado não funciona quando o sistema sofre muita pressão por mudança, então, não adianta ter um plano detalhado e um contrato todo amarrado. É melhor que exista colaboração mútua entre as partes e que o projeto seja adaptável, já que as mudanças são inevitáveis.

Para o manifesto ágil, detalhes de processos, documentação, contratos e planos e etc são importantes, claro, mas são menos importantes do que os itens colocados em negrito e explicados acima.

Hoje, sabe-se que os métodos ágeis podem ser adaptados e utilizados em projetos de qualquer tamanho, mas quanto maior o projeto, maior serão as adaptações "burocráticas" (itens da direita).

Métodos ágeis não são caóticos, são flexíveis. Existem controles, métricas, regras e etc. O foco é direcionado para as coisas que agregam valor e não para o que é determinado por um contrato ou processo de gerencia. Você pode ter documentação, mas somente sobre o que é importante.

Principais modelos ágeis (são considerados uma família de métodos)

Extreme Programing (XP)
Scrum
FDD
Lean Software Development
Crystal Family

Extreme Programing (XP)
Kent Beck utilizou o XP pela primeira vez para fazer a folha de pagamento da Chrysler e ele disse:

"Trata-se de uma metodologia ágil para equipes pequenas e médias desenvolvendo software com requisitos vagos e em constante mudança."

Em grande projetos as equipes costumam crescer e ter a comunicação prejudicada, dessa forma criam-se várias equipes pequenas e médias.

A melhor maneira de esclarecer requisitos vagos é implementando e mostranto ao clinte. A palavra  Extreme, no XP, trás a ideia de levar TODAS as boas práticas ao EXTREMO. NO XP, se algo é bom, deve ser feito sempre.

Práticas do XP

Metáforas
Utilizar uma estória e termos que todos os programadores, clientes e gerentes possam contar para explicar como o sistema funciona. Facilita a comunicação entre os interessados. Conceitos complicados devem ser explicados por analogia utilizando-se metáforas.

Exemplo:  Planejar um projeto XP é como dirigir um carro, a todo momento você corrige o rumo ao volante. É preciso corrigir a rota a todo momento.


Projeto Simples
O código está, a qualquer momento na forma mais simples que passe todos os testes. O programador deve se perguntar: Existe uma forma mais simpels para atender o requisito? Para fazer o código passar no teste? Se não estiver da forma mais simples possível, deve ser feito refactoring.

Pequenas Versões
As entregas são feitas em pequenos releases de software funcionando. A verdade está no código, não existe documentação entregue sem software. Isso dá confiança ao cliente em relação ao progresso do sistema. Tipicamente as iterações são de um mês.

Refactoring
O código deve ser constantemente melhorado tornando-o mais simples e mais genérico, removendo redundâncias e duplicidades. Melhorar a estrutura interna de um código sem alterar o funcionamento externo. Para que o projeto seja simples é necessário refatoração para que haja evolução do projeto, de outra forma, o código ficaria com problemas arquiteturais ou coisas do tipo.

Programação em Pares
Os programadores trabalham em pares e validam o trabalho um do outro. Aqui entra o conceito de REVISÃO AO EXTREMO, a todo momento. Uma máquina, um mouse, um monitor e dois programadores. Assim o código é revisado a todo momento e diversos erros são corrigidos dessa forma.

Propriedade Coletiva do Código
Todos são responsáveis por todo o código e qualquer pessoa está autorizada a alterá-lo. Isso evita as ilhas de conhecimento. O conhecimento fica compartilhado por toda equipe.

Padrão de Codificação
Todo código é gerado seguindo um estilo e formato consistente. É criado um padrão de codificação. A linguagem java já possui muitos padrões, o que facilita. No XP isso é ampliado também aos padrões de projeto e arquitetura.

Ritmo Sustentável
Cada programador trabalha 40 horas por semana, no MÁXIMO. Quando o programador trabalha muitas horas por semana a longo prazo, fica cansado e a qualidade do código é reduzida por causa do cansaço.

Reuniões em Pé
Reuniões rápidas e diárias com a equipe, em pé, para discutir apenas o essencial a respeito do projeto. Os programadores falam sobre os problemas que estão acontecendo e sobre soluções. A recomendação é que as reuniões ocorram sempre no mesmo horário e não passem de 15 minutos. Isso garante que não haverá enrolação.


Cliente Sempre Presente
Um representante do cliente, com conhecimento do negócio, deve estar presente em tempo integral para a equipe do desenvolvimento. O cliente integra a equipe de desenvolvimento.

Desenvolvimento Orientado a Testes (TDD)
Os testes unitários e automatizados são implementados antes mesmo das funcionalidades. Os testes já podem ser escritos a partir do momento em que se conhece os requisitos. Dessa forma, o código é que deve passar no teste. Um teste feito para aprovar um código possui mais chances de ser feito de forma mais relaxada.

Integração Contínua
Os códigos são integrados o mais cedo possível para evitar problemas de integração no futuro. Na prática, a cada commit (envio de código), os testes rodam automaticamente. Isso evita que um código escrito hoje quebre algo que foi feito ontem

Planejamento Incremental
O XP é um método iterativo e incremental. Os requisitos e funcionalidades são registrados como estórias dos usuários e são priorizados para serem incluídos em uma iteração futura. Cada iteração implementa alguns desses requisitos. Você não detalha e especifica tudo antes da hora, detalha apenas o que for escolhido para a próxima iteração.


Valores do XP

Comunicação - valorizar a comunicação criando formas de construir e disseminar conhecimento.
Simplicidade - começar sempre pela solução mais simples que funcione.
Feedback - receber retorno do cliente e da equipe.
Coragem - coragem para aplicar as práticas do XP, como design simples e refatoração. Não são coisas fáceis de fazer e damanda coragem da equipe.
Respeito - entre a equipe e os usuários. Se o membros da equipe não se importam com o projeto nem com os outros membros do time, o XP não vai funcionar.

Desenvolvimento Ágil com SCRUM
Derivado de uma atividade em um jogo de Rugby.

"É um framework de processo dentro do qual podem ser empregados outros processos e técnicas variadas." Em provas de concurso o Scrum é tratado como metodologia ou processo de desenvolvimento e não como framework de processo.

Framework é uma estrutura básica e incompleta por trás de um conceito, algo que precisa ser extendido e adaptado para funcionar em alguma realidade. Metodologia é algo mais prescritivo, diz o que deve ser feito.

Por ser um framwork de processo é possível adicionar papéis, artefatos, atividades e outros tipos de controle de acordo com a necessidade e pode ser aplicado em qualquer contexto em que pessoas trabalhem juntas para atingir um objetivo

É um framework mais gerencial do que técnico, não existe prática de engenharia de software (ESW) propriamente dita descrita no Scrum, por isso, se adqua a qualquer técnica de ESW. Normalmente o é utilizado em conjunto como XP. O Scrum foca no gerenciamento e o XP na parte técnica.

Características do Scrum

As equipes se auto-organizam para melhorar a comunicação e dimunir a supervisão. A equipe escolhe a melhor forma de realizar o trabalho. Isso não é ditado por alguém de fora. Equipes de 5 a 9 pessoas (número cabalistico).

É iterativo e incremental e o produto evolui de uma série de sprints. Uma iteração é chamada de Sprint. Um período delimitado que dura de duas a quatro semanas (outro número cabalístico) para incremento do produto.

Os requisitos são listados em um backlog do produto. É uma lista de funcionalidades. Tudo o que deve ser feito no produto fica listado neste backlog. Para levantar os requisitos, pode ser usada a técnica do XP (estórias do usuário), mas também é possível usar casos de uso ou qualquer outra técnica para que seja determinado o backlog do produto.

O Scrum não define nenhuma prática de engenharia específica. É um framework gerencial que pode ser adaptado a qualquer processo de engenharia de software.


Funcionamento



Tudo começa com o backlog do produto, que é a lista de coisas a fazer. Com isso em mãos você faz uma reunião que é chamada de Planejamento do Sprint. Nessa reuião é selecionado o Backlog do Sprint, que são as tarefas a serem implementadas durante o Sprint. As tarefas são DERIVADAS
do Backlog do Produto. Cada item do backlog do produto pode gerar uma ou mais tarefas para no Backlog do Sprint.

Depois de definido o Backlog do Sprint, a equipe executa este Sprint em um "timebox" de duas a quatros semanas com reuniões diárias para um balanço do que está acontecendo naquela iteração.

As Reuniões acontecem no mesmo horário, no mesmo local e de pé. O que foi feito ontem? O que você fará hoje? Existe algum problema no seu caminho? São as perguntas respondidas nesta reunião.

O Scrum Master é a pessoas responsável por resolver os problemas que estejam atrapalhando o bom andamento do projeto, caso existam. No final é gerado um incremento potêncialmente utilizável (implantável) do produto.

Backlog do Produto
Lista ordenada de tudo o que é necessário para o produto (funcionalidades) e para gerar essa lista você pode usar qualquer ténica de engenharia de software. Desde estórias do cliente (xp) até casos de uso conforme UML.

A ordenação é feita de acordo com a prioridade DO CLIENTE. Essas prioridades devem ser dadas de acordo com o valor que o software ira produzir para o usuário.

O Backlog do Produto é um artefato dinâmico, nunca está completo. A priorização pode mudar. Ele pode aumentar ou diminuir de acordo com a necessidade e vontade do cliente. Acontece um replanejenamento do Backlog no início de cada Sprint, afinal, se os requisitos mudam, as prioridades também mudam.

Backlog do Sprint
Uma lista de TAREFAS que a equipe se compromete a terminar dentro do Sprint. Não são funcionalidades, são tarefas. O cliente não tem acesso a este backlog. É algo muito técnico. Essas tarefas são derivadas do Backlog do Produto. São propostas pelo cliente e aceitas pela equipe durante o planejamento do Sprint. Cada funcionalidade do produto pode gerar uma ou mais atividades.

São considerados: a prioridade que o cliente deu aos itens, o tempo e esforço estimados pela equipe de desenvolvimento para completar as tarefas. É a equipe que estima o tempo e o esforço para os itens e não o cliente, nem o Scrum Master.

Papéis do Scrum

Product Owner (PO) - É o dono do produto, define funcionalidades (scopo) do produto (backlog). É o representante do cliente. É ele quem prioriza o Backlog do Produto de acordo com as prioridades da empresa e aceita ou rejeita o resultado do Sprint. Reponsável por todo o macro-gerencimanto de um projeto Scrum. É uma pessoa específica e não um comitê ou um grupo.

Team (Equipe)
Cuida do micro-gerenciamento do projeto: atividades técnicas, reuniões diárias e coisas do tipo. Contém de 5 a 9 pessoas, é multi-funcional e auto-ogrnizável. As pessoas somadas devem ter todas as habilidades para gerar o produto do Sprint e os membros precisam de dedicação integral ao projeto. É aceitável que apenas DBA seja compartilhado. Não existem títulos dentro da equipe, todos podem fazer tudo, os profissionais devem ser multi-disciplinares e por se auto-organizável, a equipe é quem decide como trabalhar.

A troca de membros da equipe só deve ocorrer durante a mudança de Sprints e nunca no meio de um. O Sprint costuma ser muito focado e uma troca iria atrapalhar o progesso.


Scrum Master
Reponsável pelo processo: aplicação dos valores, regras e práticas do Scrum. Esse framework possui poucas regras, mas elas são rígidas. É esse cara quem remove os obstáculos e facilita trabalho da equipe. O Scrum Master NÃO é um gerente de projeto, ele não possui autonomia para interferir na forma de funcionamento interno da equipe. Ele também é responável por blindar a equipe em relação ao ambiente externo e assim garantir o pleno funcionamento do time.

Exemplos de obstáculos a serem removidos:

"Meu PC quebrou, preciso de um novo"
"Preciso de ajuda para configurar o ambiente, que parou de funcionar"
"Preciso de ajuda para aprender tal coisa"
"O cliente não está disponível, existe uma dúvida e estou parado porque não sei o que deve ser feito"
"Um gerente de outro projeto quer remover uma pessoa da equipe para outro projeto"

Ele precisa arruma um jeito para resolver o problema. Não precisa ser a pessoa mais capacitada técnicamente, mas precisa achar alguém que entenda dos problemas técnicos que ele não sabia como resolver. Se alguém não sabe fazer tal coisa, ele pode ir atrás de quem saiba para ensinar, pode marcar as reniões com o cliente, procurar um cliente que saiba sanar uma dúvida e coisas do tipo.

Eventos do Scrum

1) Planejamento do Sprint
Os itens do Backlog do Produto são selecionados para serem feitos neste momento. As tarefas são identificadas e estimadas. Planeja-se tudo que deve ser feito no Sprint.

Para um Sprint de 4 semanas, um reunião colaborativa com toda a equipe (PO, Scrum Master e Equipe) costuma levar 8 horas. Na primeira parte da reunião acontece o planejamento estratégico define-se O QUE deve ser feito. O PO propõe uma meta (itens do backlog do produto) para a equipe fazer.

Na segunda parte acontece o planejamento tático, define-se COMO FAZER. É um trabalho focado na equipe de desenvolvimento, mas todos os papéis participam. O PO fica disponível para dúvidas. A equipe discute como fazer o que foi proposto e se é possível fazer tudo que foi proposto pelo PO.

2) Reuniões Diárias (Daily Scrums)
Reuniões diárias apenas com os membros da equipe, necessariamente sem o PO. Acontecem todos os dias, no mesmo lugar, na mesma hora e em pé, no máximo por 15 minutos. Pergunta-se: O que você conseguiu fazer? O que você vai fazer? Existe algum obstáculo prejudicando suas atividades?

3) Revisão do Sprint
No fim do Sprint acontece a apresentação dos resultados obtidos. Por resultado entende-se: aquilo que foi IMPLEMENTADO e pode ser demonstrado para o cliente. É um evento informal e o time inteiro participa. A preparação para o evento não deve demorar mais do que duas horas. O foco é em mostrar as coisas funcionando. Se algo não foi terminado, se existe um débito técnico, deve ser dito neste momento e pode ser necessário ajustar o Backlog do Produto, o que não foi terminado terá que retornar para lá.

Não utilizar apresentações em slides (PPT).

4) Retrospectiva do Sprint
Acontece depois da revisão do Sprint e antes da próxima reunião de planejamento. Inspeciona-se o processo e não o produto. O produto foi inspecionado na Revisão do Sprint.

A equipe verifica as relações entre as pessoas, os processos e ferramentas que foram utilizadas, analisa se o tempo escolhido para o Sprint está bom, se a equipe precisa de pessoas com habilidades diferentes e etc.

sábado, 28 de abril de 2012

Engenharia de Software Para Concursos - Parte 3 - Métodos Formais, Iterativos e Incrementais


Modelos de Ciclo de Vida - Continuação
A primeira parte sobre modelos de ciclo de vida de desenvolvimento de software, modelo em cascata e prototipagem, ficou no poste anterior, na parte 2. Quem quiser pode clicar aqui para ler.

Quem acompanha o blog já sabe. Esses são os meus resumos, usem a vontade, mas não me culpem por alguma erro.

Métodos Formais
São modelos baseados em técnicas matemáticas para especificar, desenvolver e verificar o software. São usados em sistemas críticos, onde uma falha pode colocar pessoas em risco. Softwares de avião, de hospitais, usinas nucleares e etc.

O software é especificado usando técnicas formais (matemáticas). Existem várias especificações que são realizadas em sequência e após todas elas, uma prova matemática é gerada. O código só é implementado quando as especificações passam no teste matemático. (Sommerville classifica esses métodos como uma evolução do cascata, porque as fazes são sequênciais.)

- O processo de desenvolvimento garante que o programa faz o que foi especificado.
- É possível gerar programas corretos e completos por construção.

A especificação do software é feita através de matemática e existe uma linguagem de programação específica para implementação. Não existe a análise subjetiva de especialistas que utilizam a experiência para especificar os requisitos. O código é matematicamente correto.

Desvantagens:
O processo é MUITO CARO, demanda mão de obra extremamente especializada e muito bem treinada, com forte base matemática.

É praticamente impossível mostrar a especificação do sistema para um cliente normal e receber um OK da especificação.

Métodos Iterativos
Os requisitos do sistema sempre evoluem durante o projeto. Sempre existem mudanças. Os modelos iterativos surgiram para tratar os riscos causados pelas mudanças dos requisitos.

Iteração é uma passagem pelas disciplinas de desenvolvimento. Sendo assim, a cada passagem (iteração) pelas disciplinass você entrega um parte do software e aumenta a compreensão do que está sendo feito. É uma técnica de dividir para conquistar.

Um grande projeto é dividido em pequenos projetos. A cada iteração você seleciona um conjunto de requisitos menor do que o todo, passa por todas as disciplinas e depois seleciona mais requisitos para implementar e assim vai.

A grande vantagem desse modelo é o gerenciamento de riscos. Como existe entrega do produto a cada iteração, existe feedback do cliente e a equipe de desenvolvimento tem condição de fazer os ajustes logo em estapas iniciais do projeto. O risco diminui conforme o projeto avança no tempo.


Existem duas abordagens:
Desenvolvimento Incremental e Desenvolvimento Espiral

Desenvolvimento Incremental
Este modelo é muito usado nos dias de hoje. RUP, XP, Scrum e métodos ágeis em geral.
Desenvolve-se e entrega-se o software em incrementos, com cada iteração entregando parte das funcionalidades requeridas.

Os requisitos são definidos antes do desenvolvimento da iteração e os mais críticos possuem prioridade. Você define com precisão APENAS os requisitos daquela iteração e não do sistema todo. A cada iteração os analistas e desenvolvedores adiquirem mais conhecimento do negócio, o que facilita a próxima passagem.

Frase de efeito: "Jogue fora um pouco do trabalho durante o caminho para não precisar jogar fora todo o trabalho ao final".

Existem erros em cada fase, mas como o trabalho foi pequeno, é fácil refazer. Perde-se pouca coias a cada iteração. Com o aprendizado da equipe a cada entrega, menos erros acontecem nas próximas passagens.

No RUP, um mini projeto em cascata é executado em cada iteração, progredindo até a entrega final do produto.


Diferença entre o processo Iterativo e o Incremental
A diferença abaixo é conceitual e só deve ser levada em consideração caso a pergunta da prova seja EXPLÍCITA, de outra forma, os processos costumam ser iterativos e incrementais ao mesmo tempo.

Incremental : São adicionados pedaços completos. São adicionados incrementos a cada iteração. Um pedaço implantável e funcionando.

Iterativo: esboços ou pedaços incompletos do produto são melhorados a cada iteração. Pense na pintura de uma parede. Cada demão é uma iteração.

Veja a figura abaixo para ficar mais fácil de entender:


Vantagens: 

O cliente pode receber e avaliar as entregas do produto mais cedo, desde a primeira iteração.
Os desvios são identificados e é possível replanejar as próximas iterações.
O risco de fracasso do projeto diminui.

Desenvolvimento em Espiral
Também é um modelo iterativo e o processo é representado como uma espiral em vez de uma sequência de atividades. Cada volta na espiral representa uma etapa no processo de desenvolvimento.

Não existem fases fixas, como Especificação, Projeto e etc. Os loops são escolhidos de acordo com a necessidade. O Desenvolvimento em Espiral foi o primeiro a acrescentar aspectos gerenciais ao desenvolvimento de software.

Cita Análise de Riscos explicitamente. Os outros modelo não previam essa análise, por mais que isso fosse feito na prática. Para concursos, a diferença deste modelo para o outro é essa.

A prototipagem é uma técnica muito utilizada durante a Análise de Riscos do modelo em espiral, mas existe um problema: essa análise acrescenta complexidade ao projeto e requer experiência das pessoas envolvidas para avaliação dos riscos.

Abaixo a representação do Desenvolvimento em Espiral do Boehm, que é a ideia original e mais cobrada nos concursos.

No Planejamento é feito um plano, são geradas estimativas e coisas do tipo. Depois, é feita uma Análise de Riscos onde você se pergunta se o projeto é tecnica e economicamente viável. Depois disso decide-se se o projeto continua ou não. Se for necessário aborta-se o projeto neste ponto.

Dentro do quadrante de engenharia é onde acontecem as atividades técnicas do desenvolvimento de software, as fases dos modelos de processo que vimos até agora. No final existe o quadrande de feedback do seu cliente.

A espiral começa de dentro para fora, com loops pequenos e vai crescendo.

Aqui, temos um problema. Existem autores que enxergam 4 fazes diferentes do modelo de Boehm e isso pode ser cobrado, já vi algumas questões sobre isso:

  • Definição de objetivos - São definidos os objetivos para a fase do projeto.

  • Avaliação e redução de risco - é realizada uma análise detalhada para cada risco identificado e são tomadas providencias para reduzir esses riscos.

  • Desenvolvimento e validação - é escolhido o modelo de desenvolvimento do sistema, e o sistema é então desenvolvido e validado.

  • Planejamento - O projeto é revisto e é tomada uma decisão sobre continuar com o próximo loop, e se for o caso é traçado o planejamento para a próxima fase.


Desenvolvimento em Espiral do Pressman
É muito parecido com modelo original, apenas com algumas diferenças. Existe a comunicação (requisitos) antes do planejamento e existe a fase de construção e release, que foi separada da parte de engenharia. No final das contas, a ideia é a mesma do modelo anterior.
O loop inicial e mais escuro seria uma fase de conceito do seu produto.  Depois, no segundo loop, um pouco menos cinza, entra a fase de desenvolvimento do produto. Na sequência, melhoria do produto e por último, uma fase de manutenção. Então, cada loop pode ser considerado uma FASE DO PROCESSO DE DESENVOLVIMENTO.

quinta-feira, 26 de abril de 2012

Engenharia de Software Para Concursos - Parte 2 - Modelos de Ciclo de Vida, Cascata e Prototipagem


Modelos de Ciclo de Vida ou Modelos de Processos
Um modelo de ciclo de vida é uma representação abstrata e simplificada do processo de desenvolvimento de software, apresentada a partir de uma perspectiva específica.
Para desenvolver software, existem muitas coisas a serem consideradas, mas no modelo de ciclo de vida você abstrai uma série de coisas e foca no essencial para aquele modelo. No modelo em cascata por exemplo, temos uma perspectiva baseada nas atividades que precisam ser realizada.

Poderia ser utilizada uma perspectiva baseada em papéis (envolvidos) ou de artefatos que estão sendo gerados, mas normalmente o foco fica nas etapas (atividades) a serem executadas.

O modelo de ciclo de vida é a base (esqueleto) do processo. Ele dita a ordem das atividades, os principais artefatos e produtos gerados.

Principais Modelos:

Cascata ou Clássico
Prototipagem
Métodos Formais
Espiral
Incremental

Modelo em Cascata
É o modelo clássico.  Funciona como uma linha de produção. As etapas são executadas de forma sistemática e sequêncial. Em princípio, você só pode passar para a próxima fase quando a fase anterior tiver sido completamente terminada. É um modelo orientado a planos, você planeja tudo que é necessário para uma etapa antes de começar. Cada fase prevê a entrega de algum artefato que marca seu fim. Não existe feedback e replanejamento.


Apesar de ser raro hoje em dia, este modelo pode ser aplicado em sistemas com requisitos muito bem conhecidos e simples. É necessário planejar as atividades e executar tudo de uma vez. A verdade é que o negócio de uma empresa não costuma ser estável e os requisitos sempre mudam durante o desenvolvimento e o modelo em cascata não prevê suporte para isso.

Foi a primeira abordagem estruturada para o desenvolvimento de software.

Fases do Modelo em Cascata do Pressman

1) Comunicação - Iniciação do projeto e levantamento de requisitos
2) Planejamento - Estimativas, cronograma e monitoramento
3) Modelagem - Análise e projeto
4) Construção - Codificação e teste
5) Implantação - Entrega, manutenção e feedback

Fases do Modelo em Cascata do Sommerville
1) Definição de Requisitos
2) Projeto de Software e Sistema
3) Codificaçào e Testes Unitários
4) Integração e Testes de Sistema
5) Operação e Manutenção (costuma ser a etapa de maior duração)

O analista levanta todos os requisitos na primeira fase e volta para a fábrica de software para o planejamento. O processo de desenvolvimento segue sem feedback até a implantação, o que pode demorar muito tempo, até mais de uma dezena de meses. Nesse tempo, normalmente o negócio já mudou.

Vantagens
- De fácil planejamento, organiza as atividades em uma sequênciaa com entraga bem definida.
- Funciona bem para requisitos estáveis, bem definidos e bem compreendidos.
- Fácil de aplicar a eqiupes inexperientes, porque é só fazer tudo em uma sequência simples.

Desvantagens
Acumula riscos. É um modelo não realista e simplista. No mundo real os requisitos mudam, erros acontecem no levantamento de requisitos e nada disso é percebido até que o produto seja testado ou recebido pelo cliente, lá no final. Os problemas começam a aparecer na fase de integração, quando é tarde demais. No modelo cascata clássico, que é o que foi tratado aqui, só existe uma entrega para o cliente, que acontece no final.

Na pratica, o modelo em cascata pode ser adequado a um replanejamento é possível voltar de uma fase para a fase anterior.

Fases Genéricas do Ciclo de Vida do Software
Cada autor possui a sua denominação de cada fase do ciclo de vida, mas existe uma ideia por trás de cada etapa. Abaixo, uma ideia das etapas genéricas.

- Planejamento:
Faz-se as estimativas sobre escopo, recursos, custos e prazos. Esboça-se os requisitos do sistema para poder fazer as estimativas, que são pouco precisas, mas já dão uma ideia razoável do todo.

- Análise e Especificação de Requisitos
Entende-se melhor os requisitos e o escopo, que são refinados neste momento. Não existe código gerado. Entende-se o domínio do problema. Pensa-se no comportamento e nas funcionalidades do sistema. Não existe preocupação com tecnologia. O foco é no problema e não na solução.

- Projeto ou Design
Define-se os requisitos tecnológicos do sistema. Aqui pensa-se na solução, gera-se a arquitetura do software.

- Implementação
Gera o código do programa de acordo com o projeto. É onde existe mais gente trabalhando ao mesmo tempo.

- Testes
Realizar diversos níveis de teste para satisfazer a verificação do software. O objetivo é encontrar erros no software. Testes nunca garantem que o programa está livre de erros. Os testes apenas mostram que ainda existem erros, mas não dá para mostrar que não existe erro nenhum.

 - Implantação, Operação e Manutenção
Colocar o software em produção, treinamento, manutenção e gerenciamento dos serviços do software.

Prototipagem 
Protótipo é uma versão inicial de um software que é utilizada para demonstrar conceitos ou descobrir informações e soluções a respeito de um determinado problema. É uma prova de conceito para saber se o rumo escolhido é viável tanto do ponto de visto técnico, como do ponto de vista do usuário.

Prototipagem Evolucionária

Trabalhar junto aos cliente para evoluir o protótipo a partir de uma especificação inicial bem resumida. Foca em entregar algum resultado o mais rápido possível e o protótipo evolui até que o software esteja de acordo com as necessidades do cliente.


Deve-se começar com os requisitos mais bem compreendidos. Novas funcionalidades são adicionadas a cada versão, de acordo com propostas do cliente. É aplicável a sistemas pequenos ou médios.

Esse modelo de ciclo de vida gera uma falta de visibilidade do progresso do sistema como um todo, que está sempre evoluíndo e nunca está terminado. Os sistemas crescem sem uma arquitetura adequada, porque os programadores estão preocupados em entregar rapidamente e acabam não se preocupando com boas práticas ou refactoring.

A documentação pode ser esquecida e provavelmente será, já que o foco é na entrega rápida. A cada nova versão acontecem mudanças que não são documentadas.

Prototipagem Descartável
Pequenas versões prototipadas são disponibilizadas aos clientes para compreensão e clarificação dos requisitos do sistema. Deve-se começar com os requisitos mais difíceis e menos compreendidos.

Com a utilização do protótipo o cliente tem mais condições de determinar o que ele realmente quer e a equipe pode entender melhor os requisitos. Depois o protótipo é descartado.

É útil para sistemas grandes e complicados, ou quando o cliente não sabe o que quer exatamente. Parece perda de tempo, mas os requisitos ficam bem mais claros do que se estivessem apenas escritos em um papel, de forma teórica.

Protótipos descartáveis podem ser aplicados no contexto de qualquer modelo de processo (cascata, espiral, iterativo/incremental). Funciona como uma técnica utilizada nos outros modelos de ciclo de vida.

Na prática os modelos de desenvolvimento de software se misturam. O modelo em cascata pode ser usando dentro do modelo incremental, como mini-projetos e outras combinações são possíveis.

Os protótipos podem ser visuais, para os clientes avaliarem, mas também existem protótipos não visuais para validação de conceitos, estudo de viabilidade ou arquitetura, etc.

terça-feira, 24 de abril de 2012

Engenharia de Software Para Concursos - Parte 1 - Introdução e Contextualização

Eu já havia feito alguns resumos de Engenharia de Software (ESW) segundo o Sommerville, mas como ESW é cobrada de forma genérica e de forma individual por autores, resolvi fazer 3 estudos separados. Este é da aula do professor Fernando Pedrosa, que incluem conceitos gerais importantes para as provas.

Lembrando que este é o meu resumo. Fique a vontade para usar, mas não me culpe se algo estiver errado. 

Engenharia de Software (ESW) é uma disciplina de ENGENHARIA (assim como todas as outras engenharias) preocupada com todos os aspectos sobre a produção de software, incluíndo:

Processos, Métodos e Ferramentas.

Os processos racionalizam o desenvolvimento de Software. Diz quem faz o que e quando.
Os métodos são os conhecimentos técnicos (know how). Dizem como fazer.
As ferramentas dão suporte automatizado ou semi-automatizado para processos e métodos (ferramentas case)

Desenvolver software não é só programar. Utiliza-se processos, métodos, ferramentas, aspectos de gestão e outras coisas.

As taxas de sucesso em desenvolvimento de software sempre foram muito baixas e a ESW veio para racionalizar a forma de produção e trazer uma abordagem moderna com qualidade nos artefatos e produtos entregues ao cliente, mesmo assim, a ESW ainda é muito imatura, possui taxas de sucesso muito baixas quando compradas às outras engenharias. 

Objetivos da Engenharia de Software:

Obter software de qualidade - atender as expectativas e deixar os usuários satisfeitos. Obter produtividade no desenvolvimento, manutenção e operação dentro de custos, prazos e níveis de qualidade controlados. Qualidade consome tempo, baixa a produtividade e impõe custos. Logo é preciso achar o melhor custo-benefício entre qualidade e produtividade. 

Engenharia de Software e Engenharia de Sistemas:

Na prática, no dia a dia, são a mesma coisa, mas conceitualmente são coisas diferentes.

A Engenharia de Sistemas está preocupada com todos os apectos de sistemas: software, hardware, processos, pessoas, outros sistemas e etc.

Engenharia de Software é apenas uma parte da Engenharia de Sistemas, que se preocupa somente com o software e que foi criada durante a crise do software no final da década de 60 quando se percebeu um problema de custo e qualidade.

O problema básico era o uso indiscriminado de Go To, que dificultava muito o entendimento e manutenibilidade do código.

Na década de 70 criaram a programação estruturada (linguagens com estrutura de controle) e o projeto estruturado. Foram as primeiras soluções para mitigar os problemas da crise do software (que não terminou até hoje). O projeto estruturado cuidava basicamente da organização do código utilizando os conceitos de coesão e acoplamento.

A partir da década de 80 surgiram as técnicas de análise estruturada e a percepção de que o problema a ser tratado vai além da programação. É preciso entender o problema antes de aplicar uma solução. Surgiram também as primeiras ferramentas CASE.

Eduard Yourdon publicou algumas ténicas muito usadas que abstraiam a tecnologia. A ideia era compreender o domínio. Mas hoje não são muito cobradas porque a Análise Estruturada foi substituída pela Análise OO. Existiam os seguintes artefatos.

Diagrama de Fluxo de Dados (DFD)
Dicionário de Dados
Diagrama de Entidade-Relacionamento
Diagrama de Estados

O paradígma estruturado considerava os dados e o compotamento do sistema separadamente.

Na década de 90 surgiram Análise e Projeto OO, Java, UML e o Processo Unificado. Já existiam as linguagens OO, mas elas se tornaram o padrão do mercado de desenvolvimento de software nesta época. Na orientação a objetos existe uma aproximação maior do mundo real. Os objetos são entidades que encapsulam dados e comportamento em um local só.

Nos anos 2000 as metodologias ágeis ganharam força, assim como novos paradigmas, como SOA, Aspectos e Arquitetura Dirigida a Modelos (MDA), etc.

O que é um Software?
Programa de computador com documentação associada. Desenvolvido para um cliente ou software de prateleira. Podem ser criados do zero ou reutilizar software existente.

O que é um processo?
Uma série de ações para satisfazer um objetivo. Define quem (papeis) está fazendo o quê (atividades), quando e como. Recebe uma entrada, transforma e produz uma saída.

Processo de software:
Conjunto estruturado de atividades para desenvolver um sistema de software.

Especificação, Projeto, Validação, Evolução.

domingo, 22 de abril de 2012

CMMI para Concursos - Parte 3 - Representações Contínua e por Estágios

Existem duas representações no CMMI

Contínua (Níveis de Capacidade) e por Estágios (Níveis de Maturidade)


Representação Contínua 
Oferece a maior flexibilidade possível. Permite selecionar a área de processo a ser melhorada ou a ordem em que as melhorias serão feitas. Entretanto, existem processos que dependem de outros e por isso a flexibilidade não é de 100%. Para ter o processo de Desenvolvimento de Requisitos implementado é preciso ter o processo de Gestão de Requisitos.

Uma organização pode possui necessediades específicas, por exemplo: Foco em requisitos e gerenciamento de projetos e não estar preocupada com desenvolvimento e testes, porque será tercerizado. Essa empresa pode focar nas áreas que importam para ela, deixando outras áreas de lado.

Cada processo tem o seu próprio nível de CAPACIDADE. Vai do nível de capacidade 0 até o 5. Com isso, uma organização pode, inclusive, trabalhar algumas áreas mais do que outras de acordo com a estratégia da empresa. (ver figura acima)

Essa representação é indicada quando se conhece bem os problemas da organização. Sabe-se quais são os processos que precisam ser melhorados e as dependências entre eles são bem conhecidas.

Mapear quais são as áreas de risco e de maior necessidade da sua organização não é tarefa simples. Muitas empresas não possuem essa maturidade e não sabem nem por onde começar.

O que determina os níveis de capacidade dos processos são as METAS GENÉRICAS. Para um processo alcançar o nível de capacidade 1, o processo deve satisfazer a meta genérica 1. Para alcançar o nível de capacidade 2, este deve atender a meta genérica 1 e 2. Existem 5 metas genéricas, uma para cada nível de capacidade.

Existem 6 (SEIS) níveis de CAPACIDADE, que são acumulativos. Um processo em nível mais alto exige a satisfação dos níveis mais baixo.

OS NÍVEIS DE CAPACIDADE

0 - INCOMLPETO - Processo que não é executado ou é executado parcialmente. Talvez a organização nem tenha conhecimento da necessidade do processo em questão.

1 - EXECUTADO - O processo satisfaz às metas específicas da área de processo.

2 - GERENCIADO - O processo é executado (nível 1) e planejado de acordo com cada projeto. Neste caso, o processo é planejado e executado de formas diferentes em projetos diferentes, não exsite um padrão institucionalizado.

3 - DEFINIDO - O processo é adaptado a partir do padrão da organização. O processo segue um padrão, independentemente do projeto.

4 - GERENCIADO QUANTITATIVAMENTE - Processos controlados por meio de técnicas estatísticas. Controle matemático das variações do processo. Sem um padrão institucional, não seria possível fazer medições porque os processos poderiam variar muito de um projeto para outro.

5 - EM OTIMIZAÇÃO - Melhoria contínua a partir do entendimento das variações medidas no nível 4.

Benefícios da Representação Contínua
1) Oferece a máxima flexibilidade possível na utilização do modelos para melhoria dos processos.
2) Permite comparação com outras organização, mas somente processo a processo.

Dificuldades
1) Os processos da organização precisam ser conhecidos, mas normalmente, as empresas não fazem nem ideia dos processos que precisam ser melhorados
2) Não existe flexibilidade total porque existem dependências entre as áreas.
3) Difícil comprovar o retorno sobre investimento (ROI) porque cada empresa escolhe uma abordagem diferente e é difícil comparar e medir coisas diferentes.

Na representação contínua os processo são separados em quatro categorias, conforme abaixo:

Gestão de Processos (palavra chave: organização) : processos que traram de processos

    Foco nos Processos da Organização
    Definição dos Processos da Organização + IPPD
    Treinamento na Organização
    Desempenho dos Processos da Organização
    Implantação de Inovações na Organização

Gestão de Projetos (palavra chave: projeto)
    Planejamento de Projeto
    Monitoramento e Controle do Projeto
    Gestão de Contratos com Fornecedores
    Gestão Integrada de Projeto + IPPD
    Gestão de Riscos
    Gestão Quantitativa de Projeto

Engenharia: processos mais técnicos

    Desenvolvimento de Requisitos
    Gestão de Requisistos
    Solução Técnica
    Integração de Produto
    Verificação
    Validação

Suporte (palavra chave: análise): processos que apoiam outros processos

    Gestão de Configuração
    Garantia de Qualidade do Processo e Produto
    Medição e Análise
    Análise e Tomada de Decisões
    Análise e Resolução de Causas

Representação por Estágios
Provê uma sequência bem definida (rígida) de melhoria, cada um servindo como base para o próximo. Oferece uma forma sistemática e estruturada para melhoria dos processos. Os níveis de MATURIDADE da organização vão do nível 1 ao 5.

Um determinado nível de maturidade é definido pelo CONJUNTO DE ÁREAS DE PROCESSO dentro do nível em questão. São 7 áreas de processo para se alcançar o nível 2, 11 áreas de processo para o nível 3, 2 áreas para o nível 4 e 2 áreas para o nível 5. Total de 22 áreas de processo.

A ordem de melhoria é rígida e os estágios são cumulativos e dependentes dos anteriores. Para se alcançar o nível de maturidade 3 uma empresa precisa ter implementado todos os 7 processos do nível 2 e eles precisam estar no nível de capacidade 3 e todos os 11 processos do nível 3 também.

Um processo possui um determinado nível de capacidade, uma organização possui maturidade. Mesmo na representação por estágios é necessário medir os níveis de capacidade dos processos.

Nível de Maturidade é um platô bem definido de melhoria de processos na organização. As conquistas de cada estágio representam o amadurecimento de um subconjunto de processos e dizem quais processos devem ser implementados.

OS NÍVEIS DE MATURIDADe

1 - INICIAL ou AD-HOC - Os processos são imprevisíveis e caóticos. A organização não fornece um ambiente estável para apoiar os processos, são pouco controlados e reativos. O sucesso depende do heroísmo e da competência individual. A organização se compromete além da sua capacidade e abandona qualquer processo ou metodologia em momentos de crise e são incapazes de repetir os sucessos. Se a organização não foi avaliada, ela começa neste nível.

2 - GERENCIADO - Os 7 processos deste nível são caracterizados por projeto e as ações são frequentemente reativas. São planejados e executados de acordo com uma política. Já existem políticas organizacionais, mas não padrões definidos. Recursos adequados e pessoas experientes são envolvidas para produzir saídas controladas. Inclui medição, controle e revisão dos processos. O nível é alcançado pelas metas específicas das 7 áreas de processo de nível 2 e a meta genérica 2.

PS: No nível 2 já existe medição, mas não é uma medição formal, matematicamente constituída.

3 - DEFINIDO - Os 7 processos do nível 2 e os 11 processos do nível 3 (18 no total) são caracterizados por padrões formais da organização e são descritos em padrões, procedimentos, ferramentas e métodos. No nível 2, cada projeto tinha seus procedimentos, aqui existe um padrão geral da organização e os projetos estabelecem seus processos a partir da adaptação do padrão. O nível é alcançado pelas métas específicas das 18 áreas de processo no nível 2 e 3 e metas genéricas 2 e 3.

4 - GERENCIADO QUANTITATIVAMENTE - Processos medidos e controlados por meio de técnicas estatísticas e matemáticas. Aqui são 20 processos (7 + 11 + 2). Objetivos quantitativos são estabelecidos para a qualidade dos processos. Medições são feitas através de técnicas estatísticas e quantitativas, APENAS para os processo ou subprocessos mais relevantes.

Este nível é alcançado pelas metas específicas das áres de processo de nível 2, 3 e 4 e metas genéricas 2 e 3. Só os processos mais relevantes vão atingir a meta genérica 4.

5 - EM OTIMIZAÇÃO - Melhoria contínua a partir do entendimento das variações medidas no nível 4. 22 processos. As melhorias são escolhidas e comparadas ao seu custo e impacto na organização. Se aplica também aos processos ou subprocessos mais relevantes.

Este nível é alcançado pelas metas específicas das áreas de processo de nível 2, 3, 4 e 5 e metas genéricas 2 e 3.

Benefícios da Representação por Estágios

Oferece uma sequência bem definida de melhoria de processos. Não é preciso pensar a respeito de quais processos escolher. Quando você não sabe por onde começar e quais processos escolher para a sua empresa, o mais adequado é escolher a representação por estágios, que indica a ordem de melhoria dos processos.

A representação por estágios facilita a comparação entre empresas diferentes, porque todas precisam ter obrigatóriamente os mesmos processos implementados em determiando nível. Além disso a empresa recebe uma certificação que alcançou o nível de maturidade X.

Problemas da Representação por Estágios
Rigidez na escolha das áres de processos a serem melhoradas e o custo da representação por estágios poderá ser maior que o custo da representação contínua. A empresa será obrigada a implementar algumas áreas de processo que talvez não tenha interesse.

As áreas de processo ficam distribuídas por categorias e por níveis de maturidade e é preciso saber o local de cada uma delas na tabela abaixo.


O que está abaixo são dicas de memorização para mim, que talvez não façam sentido para você. Não está escrito em lugar nenhum, é coisa da minha cabeça.

Gestão de Processos: foca na organização, são coisas de mais alto nível, por isso, não possui nada no início, a palavra-chave é organização.

Gestão de Projetos: foca nos projetos, o último nível (5) está além dos projetos, a palavra-chave é projeto.

Engenharia: é mão na massa, então, são os níveis mais baixos. Muito técnica. Lembrar de engenharia de software para verificação e validação. É a única categoria só de dois níveis. Palavra-chave é requisitos

Suporte: deveria estar em todos os níveis, mas não tem no nível 4, que é onde a gestão de projetos termina. Palavra-chave: análise

Processos com IPPD são processos de Integração, logo, de nível 3. No nível 2, gerenciado, ainda não existe institucionalização formal, existem apenas políticas institucionalizadas, não se pode falar integração.

sábado, 21 de abril de 2012

CMMI para Concursos - Parte 2 - Componentes do Modelo

Clique aqui para ver a Parte 1 do resumo de CMMI. Lembre-se que este é um resumo meu e sugestões de melhoria são bem vindas

O CMMI possui 22 áreas de processo e seus componentes são dividos em 3 tipos diferentes: em retângulos arredondados estão os componente requeridos (obrigatórios),  em losangos estão os esperados e elipses os informativos.

As Áreas de Processo (PA) podem ser referidas simplesmente como processos. "Conjunto de práticas em uma área que quando implementadas CONJUNTAMENTE (e não individualmente) satisfazem a um conjunto de metas consideradas importantes para realizar melhorias significativas naquela área"

Todas as áreas de processo são comuns às representações contínua e por estágios.

Cada área de processo possui metas específicas (SG - Specific Goals) e metas genéricas (Generic Goals).

Metas e Práticas Específicas

As metas específicas (SG), como nome diz, se aplicam espeficicamente a uma área de processo e descrevem os resultados que devem ser alcançados para satisfazer a área de processo. Os processos do CMMI possuem de 1 a 3 metas específicas por processo. São componentes requeridos.

Abaixo das metas específicas, existem as práticas específicas (SP - Specific Practice) que descrevem atividades importantes para satisfazer .as metas específicas. São componentes esperados. São as atividades (praticas) que devem ser feitas.

Metas e Práticas Genéricas
As metas genéricas (GG) são chamas assim porque são utilizadas em várias áreas de processo. Existem metas genéricas para os níveis de CAPACIDADE de 1 a 5 e para os níveis de MATURIDADE 2 e 3. São componentes requeridos.

Abaixo das metas genéricas existemas praticas genéricas (GP) que descrevem as atividades para que seja possível alcançar as metas genéricas. São componentes esperados.

Como exemplo, temos a meta genérica Institucionalizar um Processo Perenciado, que possui uma prática genérica chamada Estabelecer uma Política Organizacional.

Classificação dos Componentes

Componentes Obrigatórios - Metas específicas e metas genéricas. Devem ser alcançados e serão utilizados em uma avaliação da organização. 

Componentes Esperados - Práticas específicas e práticas genéricas. Dizem o que PODE ser feito para satisfazer um componente requerido, mas é possível substituir por práticas alternativas. Em uma avaliação da organização é esperado que esses componentes tenham sido implementados conforme descritos. A execução da prática pode ser substituída por uma prática alternativa aceitável (que gere os mesmos resultados). 

Componentes Informativos - Os outros componentes são informativos, auxiliares e até mesmo dispoensáveis. Auxiliam no entendimento das metas e práticas. Exemplos: objetivos e descrições das áreas de processo, produtos de trabalho típicos, subpráticas, notas introdutórias. 

O glossário não é um componente requerido, esperado nem informativo. Os termos do glossário devem ser interpretados no contexto do modelo de componente em que aparecem.

CMMI para Concursos - Parte 1 - Introdução e Constelações

Atenção! Este é o meu resumo sobre CMMI. Não me culpe caso algo esteja errado, faça bom proveito e se encontrar erros, por favor me avise. Conforme for estudando, vou melhorando os resumos. 

Capability (capacidade): Qualidade de ser capaz ou apto a realizar uma tarefa ou ação. É a capacidade de alcançar determinado resultado. 

Maturity (maturidade): O quanto uma empresa está madura em determinada área de interesse. É possível ter a capacidade de entregar determinado resultado sem ter a maturidade suficiente para repetí-lo com segurança. Maturidade é o atingimento de boas práticas.

Model (modelo): Representação simplificada e abstrata de algo sob diferentes pontos de vista. Observa-se apenas o que é essencial para solução de determinada questão em determinado contexto. 

Integration (integração): O CMMI é um framework que integrou diversos outros modelos CMM para desenvolvimento, produtos de software e etc.

Modelo Integrado de Capacidade e Maturidade - É um modelo de melhores práticas para se definir, implantar e melhorar processos. Assim com o ITIL, CMMI não é uma metodologia, não é uma receita de bolo, não existe passo a passo. Descreve as características que os processos devem ter para se tornarem efetivos.

O CMMI foca na seguinte questão: "O que fazer" e não "como fazer" ou "quem deve fazer". Não existem papéis pré-definidos para os processos:

O CMMI trará melhoria na pervisão de custos e tempo a ser gasto no desenvolvimento e manutenção de produtos e serviços de software. Os processos que dizem às pessoas o que fazer e mapeiam as características importantes a serem atendidas, sendo assim, a equipe já sabe o que fazer para alcançar as metas, o que aumenta a agildade da equipe e portanto, a produtividade.

Colocando em prática o que foi dito anteriormente, a consequência é a melhoria na qualidade dos produtos. Tudo isso também trará maior retorno sobre o investimento.

Antes existiam diversos modelos CMM (Engenharia de Software - SW, Engenharia de Aquisições - SA, Engenharia de Sistemas - SE, IPD e People). Diversas areas de interesse tiveram seus modelos criados o que gerou sobreposição de assuntos, gerando processos redundantes ou em oposição dentro de uma mesma empresa que adotasse mais de um modelo. Com a criação do modelo integrado, esses problemas foram resolvidos.

Então  o CMMI serve para implantar e melhorar os processos de uma organização com foco em desenvolvimento e manutenção de software de forma integrada. (CMMI-DEV)

Constelações CMMI
Conjunto de componentes (modelos, material de treinamento e documentos de avaliação) para atender uma área de interesse específica de uma organização.

Existem 3 constelações atualmente (versão 1.2):

CMMI-ACQ - Processos para aquisições de suprimentos e terceirização.
CMMI-SVC - Processos para entregar e suportar serviços. (processos parecidos com ITIL)
CMMI-DEV - Processos para desenvolver produtos e serviços.

Mesmo existindo 3 constelações diferentes, existe uma integração entre elas. 16 processos são comuns a todas as constelações. O framework é flexível o suficiente para receber novas constelações no futuro.

Neste resumo, estou estudando apenas o CMMI-DEV (é o que é cobrado)

Disciplinas do CMMI-DEV
Dentro das constelações existem áreas de conhecimento específicas:

Engenharia de Software (SW): Foco na aplicação de métodos para o desenvolvimento e manutenção de sistemas de software.

Engenharia de Hardware (HW): Técnicas e tecnlogogias para manter e implementar um produto concreto.

Engenharia de Sistemas (SE): Cobre o desenvolvimento de sistema como um todo. Pode ou não incluir softwares. Tranforma expectativas em soluções completas. Exemplo: o desenvolvimento de um IPOD, envolve a criação de um hardware, um software para o hardware e ainda um outro software para atualizar as músicas do aparelho através de um PC. Além disso ainda existe o loja virtual de venda de músicas.

Atenção: Assim como nos livros de engenharia de software, existe diferença entre software e sistema. O software é um programa, o sistema é algo maior, que inclui software, documentação, hardware e etc. O caso citado do IPOD mostra a diferença. Dentro do IPOD roda um software, mas o todo é o sistema e inclui desde o hardware até à loja de música.

Existem dois modelos CMMI for Development e CMMI for Development + IPPD (Desenvolvimento Integrado de Produtos e Processos). IPPD é apenas um complemento opcional do CMMI-DEV. Você pode escolher aplicar as praticas dele se quiser.

É muito comum empresas gerenciarem os processos, mas tercerizarem o desenvolvimento em outras empresas com níveis de CMMI. Para isso é necessário uma integração entre as partes, aí entra o IPPD (Não confiar muito nessa definição).

O CMMI-DEV possui 22 processos.
Quando nada for dito em uma questão, considere sempre que está se falando de CMMI-DEV.

quinta-feira, 19 de abril de 2012

Engenharia de Software Para Concursos - Parte 2 - Sommerville - Processos e Modelos de Processos de Software


Processo de Software

Processo de software é um conjunto de atividades que levam à produção de um produto de software. Essas atividades podem envolver a criação de novo software do zero ou extensão e modificação de sistemas existentes. Podem envolver ainda a configuração e integração de softwares de prateleira ou componentes prontos com os sistemas em desenvolvimento.

Todos os processos de software possuem 4 atividades fundamentais:

Especificação do software, design (projeto) e implementação, validação e evolução

Quando se fala em processos, discute-se as atividades que serão feitas e em que ordem elas serão feitas. Além de atividades, as descrições dos processos de software também incluem: produtos, papéis, pré e pós-condiçòes.

1) Produtos: são as saídas produzidas pelas atividades dos processos.
2) Papeis (roles): refletem as responsabilidades das pessoas envolvidas
3) Pré e Pós-condições: são "declarações / questões / condições" que devem ser verdadeiras antes e depois da realização do produto. Exemplo: antes da elaboração da arquitetura, uma pré-condição seria ter todos os requisitos aprovados pelo cliente. Uma pós-condição poderia ser ter todos os modelos UML que drescrevem a arquitetura revisados.

As vezes os processos de software são classificados de duas formas: Orientados a planos (estratégias) e os ágeis. Os primeiros são aqueles onde todas as atividades são planejadas antecipadamente e o progresso é comparado ao plano.  Nos ágeis o planejamento é incremental (ou evolucionário) e é fácil de mudar o processo para refletir as necessidades de mudança do cliente. Cada abordagem é apropriada para um tipo de software. Normalmente é recomendado um equilíbrio entre os dois casos.

Embora não exista processo de software ideal, existem pontos que podem ser melhorados. Os processos podem estar usando técnicas ultrapassadas ou não utilizar as melhores praticas da ESW. O processo de software também pode ser aprimorado através de pradronização. Isso melhora a comunicação e reduz o tempo de treinamento. Os processos automatizados se tornam mais econômicos.

Modelos de Processo de Software

São representações simplificadas do processo de software. Util para abordar o processo de uma determinada perspectiva focando no que é necessário para a abordagem em questão.

Os modelos genéricos são abstrações usadas para explicar diferentes abordagens para o desenvolvimento de software. Podem ser pensados como frameworks para criação de processos de ESW mais específicos.

Vamos falar de 3 modelos diferentes que NÃO são mutuamente exclusivos e as vezes são utilizados em conjunto:

1) Modelo em Cascata - coloca as atividades dos processos fundamentais de especificação, desenvolvimento, validação e evolução em fases sequênciais separadas.

2) Desenvolvimento Incremental (ou evolucionário) - essa abordagem intercala as atividades dos processos de especificação, desenvolvimento e validação. Cada nova versão trás um incremento em relação a versão anterior.

3) Engenharia de Software Orientada a Reuso - essa abordagem é baseada na existência de grande número de componentes prontos. O desenvolvimento do sistema é focado na integração destes componentes em um sistema.
 
Modelo em Cascata
O modelo em cascata é um exemplo de processo orientado a plano (estratégia). A princípio deve-se planejar e agendar todas as atividades do processo antes de começar a trabalhar com elas de fato. Abaixo, as etapas:

1) Análise de requisitos e definição: Os serviços do sistema, restrições e objetivos são estabelecidos em conjunto com os usuários. São definidos em detalhes e servem como especificação do sistema.

2) Design do software e do sistema: O processo de design (projeto) de sistemas define uma arquitetura para o sistema de forma a contemplar todos os requisitos de hardware e software. O design  (projeto) de software envolve definir as abstrações fundamentais do software do sistema e seus relacionamentos

3) Implementação e teste unitário: O projeto é implementado como um conjunto de programas ou unidades de programas. Teste unitário é a verificação de cada unidade de acordo com as especificações.

4) Integração e teste de sistema: As unidades individuais ou programas são integrados e testados como um sistema completo. Depois de assegurado que tudo funciona conforme requisitos, o sistema é entregue ao cliente.

5) Operação e manutenção: Normalmente esta é a maior fase do ciclo de vida. O sistema é colocado em produção. Envolve a correção de erros não descobertos anteriormente, melhorias na implementação das unidades do sistema e evolução do sistema através de novos requisitos.

Em pincípio, uma nova fase não deve começar antes do fim da fase anterior. Na prática essas fases ficam em sobreposição. O processo de software não é linear e depende do feedback de uma fase para a outra.

Normalmente os requisitos são congelados em determinado momento para evitar os custos de mudanças. Por isso, muitas vezes os sistemas não fazem o que o usuário quer ou possuem problemas de projeto que são resolvidos com gambiarras durante implementação (programação).

O processo em cascata é fácil de ser utilizado, gera documentos em cada fase e por isso é visível e controlável pelos gerentes. Por outro lado, a divisão das fases é inflexível e compromissos precisam ser assumidos prematuramente no processo. Isso dificulta mudanças de acordo com a vontade do cliente. Só deveria ser usado quando os requisitos fossem bem conhecidos e não tiverem tendência de mudanças (PS: ou seja, nunca!)

O modelo formal de desenvolvimento é uma variação do modelo em cascata e usa uma abordagem matemática para demonstrar aos clientes que o sistema é seguro e está de acordo com os requisitos. Usado apenas para sistemas críticos.

Desenvolvimento Incremental ou Evolucionário
Desenvolve-se uma implementação inicial, mostra-se ao cliente e através do feedback o sistema é evoluído em diversas versões até se tornar um sistema adequado. Especificação, desenvolvimento e testes são atividades intercaladas.

O modelo incremental (ou evolucionário) é a base das metodologias ágeis e é melhor que o modelo em cascata para a maioria dos sistemas negociais e pessoais. É mais barato e mais fácil fazer as alterações no software enquanto ele está sendo desenvolvido.

A cada nova versão o sistema incorpora novas funcionalidades desejadas pelo cliente. As funcionalidades mais importantes e urgentes do sistema costumam ser desenvolvidas primeiro, assim o cliente já pode avaliar o funcionamento do software no início e mudar se quiser.


Abaixo, três importantes benefícios do Modelo Incremental:

1) O custo de mudanças é reduzido. A quantidade de documentação e analise a ser refeita é muito menor que no modelo em cascata.

2) É mais fácil obter feedback do cliente porque ele pode ver como o software funciona e o quanto já foi implementado.

3) É possível entregar software funcionando mais rápidamente gerando valor para o cliente mais cedo.

O desenvolvimento evolucionário possui seus problemas: empresas grandes possuem possuem procedimentos burocráticos que evoluíram com o tempo e estes existem por motivos fortes. As vezes, até mesmo procedimentos definidos em leis. Assim, processos menos formais podem ser difíceis de ser implementados.

Essa é a abordagem mais comum no desenvolvimento de software atualmente, seja de forma ágil ou  dirigida a planos. No último caso, as iterações são definidas com antecedência.

Os Gerentes (sempre eles) enxergam dois tipos de problemas:

1) O processo não é visível. Para medir o progresso é necessário entregas regulares. Com entregas muito regulares o custo de atualização de documentação não é viável.

2)  Quando não existe refactoring de código - o que gera custos e gasta tempo - a estrutura do sistema tende a se degradar. Neste caso, incorporar novo software ao que já existe custa mais caro com o passar do tempo.

Os problemas do desenvolvimento incremental são acentuados em sistemas grandes e longos, principalmente quando equipes diferentes desenvolvem o sistema.

Engenharia de Software orientado a reúso
A abordagem orientada a reuso conta com uma larga base de componentes de software reutilizáveis e um framework de integração para fazer a composição destes componentes. Na maioria dos projetos de software acontece o reuso, mas normalmente de modo informal.

Os estágios de requisitos e de validação são semelhantes aos estágios dos outros modelos, mas as outras frases são diferentes.

1) Análise de Componentes - procura-se componentes que atendam os requisitos especificados. Normalmente, os componentes não atendem a necessidade completamente e são usados parcialmente.

2) Modificação de requisitos - Os requisitos são analisados de acordo com os componentes e modificados de acordo com as possibilidades dos componentes encontrados. Se a modificação for impossível deve-se retornar para Análise de Componentes para busca de soluções alternativas.

3) Design (projeto) do sistema com reuso - O framework é projetado para o sistema ou um framework é reutilizado. Os projetistas levam em consideração os componentes e organizam o framework de forma compatível. Alguns programas pode ser escritos caso não exista componentes disponíveis.

4) Desenvolvimento e integração - Softwares que não podem ser obtidos são desenvolvidos e os componentes ou softwares de prateleira (COTS) são integrados para criar um novo sistema. Nesse caso, a integração faz parte do desenvolvimento.

Existem 3 tipos de componentes que podem ser reutilizados:

1) Web services
2) Coleção de objetos desenvolvidos como pacotes para ser integrados a um framework de componentes (.NET or JEE são exemplos de frameworks deste tipo)
3) Sistemas de softwares stand-alone

Esse modelo de processo reduz a quantidade de software a ser desenvolvido, reduzindo assim custos e riscos, levando a um desenvolvimento teóricamente mais rápido. Por outro lado, os requisitos sempre ficam prejudicados de alguma forma, o que pode levar a um sistema que não supre as necessidades reais do cliente. Também não se tem pleno controle a respeito da evolução do sistema, já que novas versões dos componentes não estão sob controle.

quarta-feira, 18 de abril de 2012

ITIL V3 para Concursos (Parte 2) - Visão Geral dos Cinco Livros

Service Strategy 
Integra a TI com o negócio através de requisitos identificados e resultados esperadas. Atua no nível gerencial mais alto de todos, que é o nível estratégico. O foco está nas estratégias (plano, visão) de sobreviência da organização a longo prazo. Trata de questões anteriores ao gerenciamento de serviços de TI propriamente ditas.

Saída: Service Level Package - SLP (nível definido de utilidade e garantia para um pacote de serviço específico) Pacote de serviço é uma requisição para gerar um serviço. Valor no ITIL V3 = Utilidade + Garantia - O serviço serve para alguma coisa e existem garantias de uso para este serviço. Existem especificações que garantem o funcionamento do serviço.

A fase anterior trata de questões de alto nível e anteriores a TI. Mercado, competição, prospecação, trata de estratégia. Na saída (Service Leval Package) teremos os principais requisitos definidos e as principais características que o serviço precisa ter para funcionar bem.

Service Design
Transforma objetivos estratégicos em um projeto (design) de serviço, para levá-lo à próximas fases do ciclo de vida.


Baseado na saída do Service Strategy, deve-se desenhar os serviços. É similar ao projeto na engenharia de software. Eu preciso desenhar a arquitetura do meu serviço. Definir topologia, infra-estrutura, capacidades, continuidade, desempenho e etc.

O conjunto de especificações detalhadas com as características do serviço para atender a demanda solicitada é o Service Design Package (SDP - Conjunto de especificações), que será encaminhado para as próximas fazes do ciclo de vida.



Define níveis de serviço, estratégia de transição, equipe necessária para o serviço e etc.



Saída: Service Design Package - SDP


Service Transition
Avalia testa e valida o serviço, para levá-lo ao ambiente de produção de maneira efetiva. Tudo o que foi feito antes está no papel, são denifições, características e especificações. Aqui acontece a mão na massa. Os diversos aspectos do serviços são implantados. O serviço deve estar funcionando, documentado e em conformidade com todos os requisitos elaborados antes desta fase.

Não existe saída específica no papel. As saídas são os serviços rodando em produção de maneira efetiva. 

O foco é no gerênciamento de mudanças porque muita coisa acontece ao mesmo tempo. É preciso controlar os riscos gerados pelas mudanças de versões e implantações de ambientes. Se a implantação de uma nova versão falhar, pode ser preciso voltar a alguma configuração anterior e etc.

Service Operation
Opera os serviços de forma eficiente e efetiva, de acordo com o SLA (nível de serviço) estabelecido, garantindo entrega de valor para o cliente. É aqui que o ITIL atua mais fortemente. É onde o cliente percebe o valor do serviço, durante a operação. É onde acontece o atendimento ao usuário. Dá suporte ao serviço que está em produção.

Continual Service Improvement
Localiza oportunidades para a melhoria de fraquezas ou falhas identificadas dentro de qualquer um dos estágios do ciclo de vida. Fono na melhoria contínua do serviço. Contém alguns processos para avaliar todos os outros processos em qualquer momento do ciclo de vida ITIL. Por isso atua em todos os outros ciclos de vida.

 

terça-feira, 17 de abril de 2012

Introdução (Parte 1) ao ITIL V3 para Concursos

Atenção, este é o meu resumo de Introduçào ao ITIL V3 pra concursos. Fique a vontade para consultar, mas se algo estive errado, ou incompleto, não me culpe. Conforme for estudando, volto aqui e coloco mais coisas.

ITIL significa Information Technology Infrastructure Library - É uma biblioteca (ou guia) das melhores práticas para gerenciamento de serviços de TI. É composta por 5 livros e como se classifica como biblioteca, não se classifica como uma metodologia (não é uma receita de bolo, não é um passo a passo). Não define forma de implementação e não utiliza procedimentos.

Antes as empresas em geral não dependiam muito da TI, hoje o setor de TI é fator critíco para sucesso da organização. Normalmente, essa é area que mais consome dinheiro em uma empresa e precisa agir em conjunto com o todo. TI faz parte do negócio e deve ser uma parceira estratégica da organização.

Desafios da TI segundo ITIL:
1) Alinhar os serviços de TI com as necessidades de negócio.
2) Gerenciar a complexidade dos diversos ambientes de TI.
3) Gerar resultados para o negócio (ROI), que é dependente da TI.
4) Melhorar a qualidade e redução de custos da prestação de serviços no longo prazo.

Soluções propostas:
1) Compreender as necessidades do negócio (a razão de ser da organização).
2) Se relacionar DIRETAMENTE com as áreas do negócio.
3) Medir a contribuição da TI ao negócio.
4) Prover SERVIÇOS da TI para a organização.
5) Manter os serviços estáveis e confiáveis.
6) Orientar a organização por processos (26 processos). São os processos que vão dizer quem faz o quê , quando e para quê.

ITIL atua formente depois que os sistemas/serviços estão implantados e operacionais. O foco é no gerenciamento dos serviços que estão funcionando.

Definição de Serviço: "É um MEIO de fornecer algo que um cliente perceba como tendo certo VALOR, facilitando a obtenção de resultados que os clientes desejam, sem que eles tenham que arcar com a propriedade de determinados custos e riscos."

Resumindo: Serviço é um meio de fornecer valor ao cliente sem que ele se preocupe diretamente com os custos e riscos.

O cliente paga pelo serivço, mas não cuida da complexidade e nem dos riscos desse serviço. É como você quando pega um taxi. Você paga pelo serviço, mas não se preocupa se o taxi está abastecido, no máximo, você escolhe o caminho e pede para o taxista ir mais rápido ou mais devagar e ele vai até a velocidade que é possível ir.

Gerenciamento de serviços: "Conjunto especializado de habilidade organizacionais para fornecer valor ao clientes na forma de serviços" 


Essas habilidades organizacionais são divididas em 4: Processos, Funçòes, Atividades e Papéis.

O ITIL parte do Service Strategy como núcleo de definição dos serviços. Depois segue para o Service Design, em seguida a Service Transition e chega no Service Operation. A todo momento existe o Continual Service Improvement (ver figura). O movimento é cíclico.


Então, existem 5 fases do CICLO DE VIDA ITIL - Service Strategy, Service Design, Service Transition, Service Operation e Continual Service Improvement e cada uma das fase constitui um livro.

sexta-feira, 13 de abril de 2012

Engenharia de Software Para Concursos - Sommerville - Parte 1

Este é um resumo meu sobre Engenharia de Software segundo as palavras de Sommerville. Conforme eu estudo, venho aqui e acrescento mais coisas. Fique a vontade para consultar, mas não me culpe se algo estiver errado ou faltando. Se quiser, deixe comentários.

Introdução

Engenharia de Software (ESW) é a disciplina que cuida de todos os aspectos da produção de software.

Sistemas de software são abstratos e intangíveis. Não são governados e limitados por materiais, leis físicas ou processos de manufatura. Por isso eles podem facilmente se tornar muito complexos, de difícil compreensão e com alto custo de alteração.

Diferentes tipos de software requerem diferentes tipos de abordagens, ferramentas e técnicas, que devem variar de acordo com o tipo de sistema. Existem pouquíssimos, talvez nenhum disign e técnica de implementação que sejam aplicáveis a todos os tipos de sistemas.

As atuais falhas na construção de sistemas são devidas a dois fatores:

Aumento e novos tipos de demanda:

Com o avanço da engenharia de software e ferramentas de desenvolvimento, aquilo que é possível fazer muda com o tempo, por isso as demandas mudam e evoluem. As coisas que antes eram impossíveis, agora podem ser feitas. Novos métodos de ESW precisam ser desenvolvidos para se adequar à nova realidade.

Baixa expectativa:
Escrever softwares é inicialmente simples. Muitas empresa NÃO usam técnicas de ESW e por isso produzem softwares caros e pouco confiáveis.

O processo de software inclui todas as atividade envolvidas no desenvolvimento de software. Especificação, desenvolvimento, validação e evolução são partes de TODOS os processos de software.

Software não é apenas um programa de computador, mas também toda a documentação e configuração necessária para fazer o programa funionar corretamente. Atributos essenciais da produção de software são manutenibilidade, confiabilidade, segurança, eficiência e aceitabilidade.

Um sistema normalmente é composto por vários programas, arquivos de configuração, documentação do sistema, que descreve a estrutura do sistema, documentação do usuário e até web sites para os usuários buscarem informações novas sobre o sistema.

Um bom software deve entregar as funcionalidades solicitadas, com a performance desejada, deve ser manutenível, confiável e com boa usabilidade.

As atividade fundamentais da engenharia de software são:  especificação, desenvolvimento, validação e evolução.

Existem dois tipos de produtos que software (que podem ser vendidos). Os genéricos e os customizados, mas muitos softwares vem sendo construídos com uma base genérica que depois é adequado ao cliente. Esse é o casos dos sistemas ERP como os da SAP.

Qualidade de software inclui o comportamento do software durante execução, a estrutura e organização do sistema inteiro e da documentação. Existe também a qualidade dos atributos não funcionais, como é o caso do tempo de resposta e a facilidade de compreensão do código fonte.

São cinco as caracteristicas fundamentais para um sistema de software profissional:

Manutenibilidade, Confiabilidade, Segurança, Eficiência (sem desperdício de recursos) e Aceitabilidade.

Engenharia de Software

A ESW se preocupa com todos os aspectos da produção do software, desde o início até a manutenção. Aplica ou desenvolve teorias, métodos e ferramentas apropriadas de acordo com restrições financeiras e da organização. Se preocupa em conseguir os resultados no prazo e dentro do orçamento considerando a confiabilidade necessária e as necessidades dos usuários.

A longo prazo costuma ser mais barato usar métodos de ESW porque na maioria dos casos, os maiores custos estão relacionados à manutenção após entrada em produção.
Processo de Software é uma sequência de atividade que conduz à produção do software. Existem quatros atividades fundamentais e comum aos processos de software.

Especificação, desenvolvimento, validação e evolução.

Não existem nenhum método ou técnica universal que sejam aplicáveis ao desenvolvimento de todos os tipos de software, mas existem 3 tipos de problemas que afetam muitos softwares diferentes.

Heterogenidade do software, Mudanças de negócio e social, Segurança e confiabilidade.

O tipo de uma aplicação é fator importante para escolha das técnicas de ESW. Abaixo existem alguns tipo importantes, mas muitos sistemas se enquadram em mais de uma categoria.

Stand-Alone:
Interativos baseados em transação: (web, aplicativos em nuvens e etc)
Controle embutido: controlam hardware
Processamento em batch:
Entretenimento:
Modelagem e simulação:
Coleta de dados:
Sistema de sistemas:

Mesmo com esses tipo citados, existem noções fundamentais que se aplicam a todos os tipos de sistema: Por exemplo: processo de software, confiabilidade, segurança, engenharia de requisitos e reuso.


Devem ser desenvolvidos usando um processo gerenciável e entendível. Deve-se ter uma clara ideia de tudo que será produzido.

Confiabilidade e performance são importantes. O sistema deve se comportar como esperado, sem falhas e estar disponivel sempre que o usuário for utilizá-lo. Deve ser seguro e funcionar de forma efeiciente, sem desperdício de recursos.

Entendimento e manutenção dos requisitos e especificação do software: é importante saber o que cada usuário espera e atender as espectativas dentro do tempo e do orçamento.

Fazer uso efetivo dos recursos: Quando apropriado, deve reutilizar software já pronto ao invés de escrever um novo que faça a mesma coisa.

Com o advento da web os sistemas deixaram de ser programas isolados em maquinas locais e passaram a ser softwares altamente distribuídos, as vezes em vários locais pelo mundo. Com isso, o reuso de software se tornou importante é a base do desenvolvimento web.

Hoje compreende-se que é impraticável especificar todos os requisitos de um sistema web antecipadamente e eles devem ser desenvolvidos e entregues de forma incremental.

ESW é como um framework que limita a liberdade das pessoas que trabalham com isso.

Atributos essenciais de um produto de software são: manutenibilidade, confiabilidade, segurança, eficiência e aceitabilidade.