Introdução a Engenharia de Software
Título : B1 - Introdução a Engenharia de Software
Conteúdo :
O que é software?
Muitas pessoas atualmente ainda possuem um conceito errado a respeito de software, o que é então para vocês software???? (Resposta da classe para debate).
Segundo o Autor Roger Pressman, software de computador é o produto que os profissionais de software (quais são os profissionais), constroem e mantêm ao longo do tempo. Esse software abrange programas que executam em computadores de qualquer tamanho e arquitetura, conteúdo que é apresentado ao programa a ser executado e documentos tanto de forma impressa quanto virtual que combinam todas as formas de mídias eletrônicas.
Podemos concluir dessa forma que software, não é como muitos pensam apenas o programa, mas sim todo o resto que esta envolvido na sua fabricação (requisitos, analise, documentação, prototipação, testes, manuais de sistema, manuais do usuário).
O que é Engenharia de Software?
Como agora já vimos conceitualmente o que é realmente software, vamos entender o que é a engenharia de software.
Da mesma maneira que debatemos o software, faremos com a Engenharia, sendo assim o que é para vocês engenharia de Software?? (Breve debate com a turma).
Segundo Sommerville, Engenharia de software é uma disciplina de engenharia relacionada com todos os aspectos da produção de software, desde os estágios iniciais de especificação do sistema até sua manutenção, depois que este entrar em operação.
Nessa definição dada por Sommerville temos duas frases importantes que vamos discutir a seguir:
ü Disciplina de Engenharia – É dito uma disciplina, porque os engenheiros estão sempre aplicando teorias, métodos e ferramentas sempre aonde as mesmas forem mais apropriadas e usando-as de modo seletivo, além disso os engenheiros estão sempre estudando novas maneiras e métodos de solucionar os problemas.
ü Todos os aspectos da produção de software – Isso significa dizer que a Engenharia não esta relacionada apenas com os processos técnicos de desenvolvimento de software, mas também com atividades como o gerenciamento e desenvolvimento de ferramentas, métodos e teorias que apóiem a produção de software.
Quais os objetivos?
Vamos fechar então dizendo de forma bem resumida qual o objetivo da ES. O que veremos durante todo o nosso curso.
O objetivo da Engenharia está em produzir softwares de boa qualidade dentro do prazo e custo previsto no projeto.Título : B1 - Papel Evolutivo do Software/ Software Produto/ Natureza Mutável do Software
Conteúdo :
Ø Papel Evolutivo do Software
Podemos dizer que o software atualmente pode ser visto como tendo dois papeis: Software Produto e software como veículo de entrega do produto, um pouco confuso no começo, porém tudo ficará mais claro quando virmos o que é o software produto.
No papel evolutivo do software, podemos dizer que a importância do mesmo vem passando por mudanças significativas há pelo menos 50 anos.
Para ficar mais fácil a visualização dessa importância vamos montar uma linha do tempo.
Importante: Essa linha do tempo e o papel evolutivo do software, diz respeito a como a sociedade reagiu ao seu surgimento e o que os pensadores escreveram a respeito disso, não o que foi feito ao longo do tempo em termos de produtos.
(desenhar em forma de linha do tempo no quadro)
1970 – 1980: Período visto como o surgimento do software, foi visto pela sociedade e pelos pensadores da época como uma nova revolução industrial, outros pensadores disseram que essa era a terceira onda de mudanças da história humana.
-Transformação de uma sociedade industrial em uma sociedade da informação
- A informação e o conhecimento como centro do poder.
1990 : Houve o que os pensadores descreveram como a mudança do poder, agora com os computadores houve uma democratização do conhecimento(antigamente o conhecimento estava restrito a um nucleo de pessoas que se mantinham no poder , principalmente a economia militar).
- Surgiram uma série de livros anti-computadores, que enfatizavam diversas preocupações, mas não colocavam os benefícios.
- Veio na segunda metade dos anos 90 a ascenção e a ressureição dos programadores.
2000 : Comentários a respeito da bomba relógio - O Bug do Milênio, aonde todos os autores escreveram sobre a parada de todos os sistemas, o fim do mundo, baseado em sistemas.
2001 até dias atuais : A industria do software tornou-se e vem se afirmando como o fator dominante na econômia do mundo industrializado.
Ø Software / Software Produto
Para que fique mais fácil compreender o que realmente é software (definição dada na primeira aula do curso) é importante conhecer suas características, pois são essas que o torna, diferente de todas as outras coisas que podem ser construídas. E essas características são também relativamente diferentes das encontradas nos hardwares.
1. O software é desenvolvido por um processo de Engenharia e não é fabricado no sentido clássico
(O que significa o sentido classico da produção, seria imaginar uma linha de produção de um produto qualquer, por exemplo de um carro,aonde em cada etapa, são encaixados peças e o produto vai caminhando pela fábrica, até que tudo fique pronto e passe por uma aprovação de qualidade, o software diferente disso não tem peças que vão sendo agregadas e não caminha por uma linha de produção, sua fabricação independe de maquinas e depende muito mais das pessoas e sua especialização no assunto, sua qualidade envolve outros indicadores e seus problemas apesar de serem mais fácil de solucionar são de outras proporções).
2. O software não se desgasta
Para verificar que o software não se desgasta é interessante fazer uma analise da curva de falhas entre o hardware e o software.
Curva de falhas do Hardware
O gráfico conhecido como o gráfico da banheira, representa a curva de desgastes do hardware, notem que a quantidade de falha de um hardware é muito grande no momento de sua criação podendo acontecer o que chamamos de mortalidade infantil do hardware, depois que essa taxa de erros se estabiliza ela permanece um tempo inalterada, porém a medida que o tempo passa e os males ambientais (pó, umidade, calor) vão ocorrendo as falhas do hardware voltam a ocorrer e o mesmo tem então um índice de desgaste grande e precisa ser retirado de uso.
Curvas de falha do Software
A curva ideal do software, seria uma curva que começaria com grandes quantidades de falhas, pois o software estaria no seu surgimento, portanto, conteria muitos acertos e ajustes, e correções de bug e depois essa curva iria se achatando e não mais subiria ficando assim o software em pleno uso.Porém essa curva não é ideal ela contém vários picos aonde os erros aumentam e diminuem, é conhecida como curva dentada, isso ocorre porque a cada alteração que é solicitada no software o mesmo sofre alterações e é passível de novos defeitos, nem sempre essa curva de erros chega a se estabilizar e novas demandas são necessárias, fazendo com o que o software não se desgaste mas sim se deteriore com o tempo.
3. A produção é sobre encomenda
Apesar de a algum tempo muitos software serem produzidos empacotados para diversos publicos alvos e a produção de componentes ser uma vertente em crescimento, a grande maioria dos softwares ainda são feitos sobre encomenda, ou senão se transformam para atender as necessidades do cliente, diferente de um automóvel ou de um hardware, de um microondas, etc.
Sofware Produto
Atualmente os engenheiros de software estão envolvidos no desenvolvimento de produto de software, ou seja,software que pode ser vendido para seus clientes.
Existem dois tipos de softwares produtos fundamentais:
1- Produtos Genéricos: São os softwares do tipo stand-alone, produzidos por uma organização de desenvolvimento e vendido no mercado para qualquer cliente que esteja disposto a comprar.
2- Produtos sob encomenda: São os sistemas encomendados por um cliente. O software é desenvolvido especialmente para aquele cliente com as características voltadas para apenas um cliente.
Ø A Natureza Mutável do Software
Hoje em dia sete amplas categorias de softwares de computadores apresentam desafios contínuos para os engenheiros de software, a partir dessas verificamos o porquê de dizer a natureza mutável do software.
ü Software de Sistemas: Software de sistema é uma coleção de programas escritos para servir a outros programas. A área de software de sistemas é caracterizada por interação intensa com o hardware, uso intenso de usuários, possui estrutura de dados complexas ( Exemplos: SO, Sistemas de rede)
ü Software de Aplicação: O software de aplicação consiste em programas isolados que resolvem uma necessidade específica do negócio da empresa ( Exemplo: Software de sistema de tempo real, de pontos de vendas).
ü Softwares Científicos ou de Engenharia: Antigamente esses eram caracterizados por algoritmos que processavam grandes quantidades de números. Hoje em dia essas aplicações estão mais próximas de software de sistemas. Exemplo (software de controle de riscos – Astronômicos, Vulcanologicos, da NASA).
ü Softwares Embutidos: O software embutido reside dentro de um produto ou sistema e é usado para implementar e controlar características e funções para o usuário final e para o próprio sistema. Os softwares embutidos podem realizar tarefas muito limitadas e também tarefas da mais alta capacidade de um software. (controles remotos).
ü Software para linha de produto: Projetado para fornecer uma capacidade específica a ser usada por muitos clientes diferentes, esse software pode focar para um mercado limitado e especial ou dirigir-se ao mercado de consumo em massa. (pacote Office, Windows)
ü Aplicações da WEB: Dos mais variados tipos.
ü Software para inteligência artificial: O softwares de IA faz uso de algoritmos não numéricos para resolver problemas complexos que não são passíveis de computação e analise direta.
Outros novos desafios que vem entrando para os engenheiros de computação são^
ü Computação ubíqua- Computação distribuída (aplicações em palm, celulares), devido a crescente onda da rede sem fio.
ü Net Sourcing – WWW.
ü Software Aberto
Conteúdo :
É importante verificar que as tarefas de orçamento do projeto, cronograma do projeto e planejamento do projeto, são tarefas que devem ser realizadas para todos os projetos em questão e as mesmas devem ser realizadas pelos seus gerentes de projetos.
O gerenciamento de projeto de software é uma parte essencial da engenharia de software. Um bom gerenciamento não pode garantir o sucesso do projeto, no entanto, um mau gerenciamento geralmente resulta em falhas do projeto: o software é entregue com atraso, custa mais do que foi estimado originalmente e falha ao atender os requisitos mínimos do cliente.
Os gerentes de softwares são responsáveis pelo desenvolvimento de planos, cronogramas e estimativa de custos do projeto. Eles supervisionam o trabalho para garantir que ele esteja sendo realizado dentro dos padrões exigidos e monitoram o progresso para verificar se o desenvolvimento esta no prazo e dentro do orçamento. O gerenciamento de projeto é necessário, pois a engenharia de software esta sempre sujeita às restrições de orçamento e de cronograma da organização.
Os gerentes de projetos fazem o mesmo trabalho que gerentes de outra engenharias, no entanto, a engenharia de software é diferente das outras engenharias de uma série de maneiras. Algumas das diferenças são:
· O produto é intangível: Ou seja, o software é intangível, não pode ser visto ou tocado, os gerentes de projeto de software não podem ver seu progresso. Eles contam e devem confiar em outras pessoas para produzir a documentação necessária para examinar o progresso.
· Não existe processo padrão em software: O processo de software varia drasticamente de uma empresa para outra, não existe um padrão na sua construção, uma linha de produção como produtos manufaturados.
· Projetos de software de grande porte são geralmente projetos “únicos”: Esses projetos de alguma forma são sempre diferentes dos anteriores, portanto, mesmo gerentes experientes podem considerar difícil prever problemas.
Atividades do Gerenciamento
A maioria dos gerentes assume a responsabilidade por algumas ou todas das seguintes tarefas:
· Elaboração de proposta
· Planejamento e Desenvolvimento do cronograma do projeto
· Custo do projeto
· Monitoração e revisão do projeto
· Seleção e avaliação de pessoal
· Elaboração de relatórios e apresentações.
Planejamento de Projeto
O gerenciamento eficiente de um projeto de software depende de um planejamento minucioso do progresso do projeto. Os gerentes devem prever problemas que podem ocorrer e preparar soluções experimentais para esses problemas. Um plano elaborado no início de um projeto deve ser usado como guia. Esse plano inicial deve ser o melhor possível em face das informações disponíveis. Ele deve evoluir à medida que o projeto progride e melhores informações se tornem disponíveis.
O planejamento é um processo interativo, apenas concluído quando o projeto é concluído. À medida que as informações se tornam disponíveis durante o projeto, o plano deve ser regularmente revisado. As metas da empresa constituem um importante fator que deve ser considerado na formulação do plano do projeto. À medida que essas metas mudam, as metas do projeto também mudam e, portanto, são necessárias mudanças no plano de projeto.
No inicio do processo de planejamento deve ser avaliado as restrições que afetam o projeto. Junto com isso deve ser estimado os parâmetros do projeto, como sua estrutura, tamanho e distribuição de funções.
As maiorias dos planos devem incluir as seguintes seções:
- Introdução: Descreve brevemente os objetivos do projeto e estabelece as restrições que afetam o gerenciamento do projeto.
- Organização do projeto: Descreve o modo como a equipe de desenvolvimento está organizada, as pessoas envolvidas e seus papeis na equipe.
- Analise de riscos: Descreve os possíveis riscos do projeto, e as estratégias adotadas se os mesmos ocorrerem.
- Requisitos de recursos de hardware e software: Especifica os recursos necessários para o desenvolvimento.
- Estrutura analítica: Especifica a estrutura analítica de um projeto
- Cronograma do projeto: Apresenta as dependências entre as atividades, o prazo estimado necessário para atingir cada marco e a alocação de pessoas nas atividades.
- Mecanismo de monitoração e relatório: Definem os relatórios de gerenciamento que devem ser produzido, quando devem ser produzidos e o mecanismo de monitoração utilizado.
Cronograma do Projeto
O desenvolvimento do cronograma do projeto é um dos trabalhos mais difíceis para um gerente de projeto Os gerentes estimam o tempo e recurso necessários, organizando-as em uma seqüência coerente.A menos que o projeto cuja o cronograma esteja sendo desenvolvido seja similar a um projeto anterior, as estimativas anteriores constituem uma base incerta para o desenvolvimento do cronograma do novo projeto. A estimativa de cronograma é mais complicada pelo fato de que projetos diferentes podem usar métodos e linguagens de implementações diferentes.
Os cronogramas devem ser constantemente atualizados à medida que mais informações sobre o progresso se tornem disponíveis.
O desenvolvimento do cronograma do projeto envolve a divisão do trabalho total de um projeto em atividades separadas e a avaliação do tempo necessário para completar essas atividades. Em geral algumas das atividades podem ser realizadas simultaneamente.
Ao estimar o cronograma não podemos desconsiderar que todos os estágios do cronograma estarão livres de problemas, afinal de contas trabalhamos com pessoas e elas podem adoecer. Além do calendário o gerente de projeto deve prestar atenção também nos recursos necessários para realizar uma tarefa sendo que o principal dele é o esforço humano necessário.
Custo do Projeto
Existem três parâmetros envolvidos no calculo do custo total de um projeto de software:
- Custo de hardware e software, incluindo a manutenção
- Custo de viagens e treinamentos
- Custo de esforços
O custo mais representativo nos projetos são os custos dos esforços, pois os custos dos esforços não são apenas salários dos engenheiros de software que estão envolvidos no projeto. As organizações calculam os custos dos esforços em termos indiretos nos quais são considerados o custo total de operação da organização e este é dividido pelo número de pessoal produtivo. Portanto os seguintes custos são parte do custo total de esforços:
· Custo de subsistência, aquecimento e iluminação no espaço de escritório
· Custo de pessoal de apoio como contadores, administradores, gerentes de sistemas, faxineiros e técnicos.
· Custo de operações de rede de comunicações
· Custo de instalações centrais, como de biblioteca ou recreação
· Custo de seguridade social e benefícios dos empregados, como pensões e seguros
Uma vez que o projeto esteja em andamento, os gerentes de projetos devem atualizar regularmente suas estimativas de custo. Isso ajuda no processo de planejamento e uso eficiente de recursos. Se as despesas reais são significantemente maiores do que as estimadas, o gerente de projeto deve tomar alguma providência. Isso pode envolver a aplicação de recursos adicionais para o projeto ou a modificação do trabalho a ser realizado.
Qualidade de software
A qualidade de software tem se aprimorado significativamente nos últimos 15 anos. Uma razão para isso é o fato de as empresas terem adotado novas técnicas e tecnologias, como o uso do desenvolvimento orientado a objeto e de ferramentas de apoio CASE, e também teve uma crescente conscientização da importância da qualidade de software.
Entretanto, qualidade de software é um conceito complexo que não é diretamente comparável com a qualidade na manufatura. Na manufatura, a noção de qualidade tem sido aquela de que o produto desenvolvido deve atender às especificações. Em um mundo ideal essas definições deveriam ser aplicadas a todos os produtos, mas, para sistemas de software há problemas com isso, embora existam algumas medidas de programas.
Bons gerentes de qualidade têm por objetivo desenvolver uma cultura de qualidade na qual todos os responsáveis por desenvolvimento de produto estão comprometidos em atingir um alto nível de qualidade de produto. Eles encorajam as equipes a assumirem a responsabilidade pela qualidade de seu trabalho e a desenvolverem novas abordagens para aprimoramento da qualidade.
O gerenciamento de qualidade formalizada é particularmente importante para as equipes que estão desenvolvendo sistemas amplos e complexos. A documentação de qualidade é um registro do que tem sido feito por cada grupo no projeto. Isso ajuda as pessoas a verificarem se tarefas importantes não foram esquecidas ou se uma parte da equipe não fez suposições incorretas sobre o que outras equipes fizeram. A documentação de qualidade é também um meio de comunicação ao longo da existência de um sistema. Para sistemas menores a gerencia de qualidade é ainda importante, mas a mesma pode ser adotada de uma maneira mais informal.
No desenvolvimento de software a qualidade de projeto abrange os requisitos, as especificações e o projeto do sistema.
Satisfação do usuário = produto adequado + máxima qualidade + entrega no prazo dentro do orçamento
Para a qualidade de um projeto existem três tarefas de suma importância:
Controle de Qualidade
O controle da variação pode ser equiparado ao controle da qualidade. O controle da qualidade envolve a série de inspeções, revisões e testes usada ao longo do processo de software para garantir que cada produto de trabalho satisfaça os requisitos para ele estabelecidos.
Um conceito chave do controle de qualidade é que todos os produtos de trabalho tem especificações mensuráveis e definidas com as quais nós podemos comparar os resultados de cada processo.
Garantia da Qualidade
Garantia da qualidade consiste em um conjunto de funções para auditar e relatar que avalia a efetividade e completeza das atividades de controle de qualidade. A meta da garantia da qualidade é fornecer a gerencia os dados necessários para que fique informada sobre a qualidade do produto, ganhando assim compreensão e confiança de que a qualidade do produto esta satisfazendo as suas metas.
Custo da Qualidade
O custo da qualidade inclui todos os custos decorrentes da busca da qualidade ou da execução das atividades relacionadas à qualidade. Estudos de custo de qualidade são conduzidos para obter um referencial para o custo de qualidade. Esse custo de qualidade pode ser dividido em custos associados com a prevenção, com a avaliação e com as falhas. Os custos de prevenção incluem planejamento da qualidade, revisões técnicas formais, equipamentos de teste e treinamentos. Os custos de avaliação incluem atividades para obter entendimento da condição do produto na primeira execução de cada projeto.
Os custos de falhas são aqueles que desapareciam se nenhum defeito aparecesse antes de se entregar um produto ao cliente. Os custos de falhas podem ser subdivididos em custos de falhas internas e custo de falhas externas. Sendo o custo de falhas internas aqueles que ocorrem quando detectamos um defeito no nosso produto antes do embarque. Os custos de falhas internas incluem refazer, reparar e analisar o modo como a falha ocorreu. O custo de falha externa é associado com os defeitos encontrados depois que o produto já esta com o cliente, geralmente são os mais caros.
Modelos de Qualidade de Software
De maneira mais resumida vamos conhecer alguns modelos de qualidade:
· CMMI
· MPSBr
· ISO
CMMI
Antes de surgir o modelo CMMI, surgiu o modelo SW – CMM (Capability Maturity Model for software) é um modelo de capacitação de processos que foi patrocinado pelo departamento de defesa dos EUA, para avaliação da capacidade dos seus fornecedores de software.O CMM baseou-se em algumas idéias importantes do movimento de qualidade industrial.
Com o sucesso do SW-CMM , outros modelos foram sendo criados , o P-CMM(People CMM para recursos humanos), o SA-CMM (para aquisição de software) e o SE-CMM para engenharia de sistemas, com o surgimento de todas essas vertentes de modelos começou a ser causada uma certa confusão de quando usar um e outro, para isso foi criado então o CMMI que integrou todos esses e pode ser aplicado para a empresa como um todo.
O objetivo do CMMI é servir de guia para melhoria de processos na organização e também na habilidade dos profissionais em gerenciar o desenvolvimento, a aquisição e manutenção de produtos e serviços.
O CMMI um pouco diferente do seu originário SW-CMM, pode ser abordado por níveis ou então em melhoria contínua, atuando com níveis de capacidade.
Os níveis do CMMI são:
· Inicial – Ad hoc
· Nível Gerenciado – Processos disciplinados
· Nível Definido – Processos padronizados
· Nível gerenciado Quantativamente – Processos medidos e controlados
· Nível Otimizado – Processos melhorados continuamente.
MPSBr
O MPSBr foi criado por pesquisadores brasileiros para melhoria de processos de desenvolvimento de softwares em empresas brasileiras.É um modelo recente e ainda em desenvolvimento.
O MPSBr atende à necessidade de implantar os princípios de engenharia de software de forma adequada ao contexto das empresas brasileiras, seguindo as principais abordagens internacionais para definição, avaliação e melhoria de software.
A definição desse processo baseia-se em três guias: Guia Geral, Guia de aquisição e Guia de Avaliação.
O MPSBr assim como o CMMI também define níveis de maturidade, porém esses níveis são sete compreendidos de A a G sendo:
A – Em otimização
B – Gerenciado Quantitativamente
C – Definido
D – Largamente Definido
E - Parcialmente Definido
F – Gerenciado
G – Parcialmente Gerenciado
ISO
As normas ISO 9000 é uma referencia em sistemas de qualidade, tendo influência em diversas outras normas e metodologias.
A ISO9000 tornou-se sinônimo de preocupação com qualidade em todo o mundo, a sigla é conhecida por consumidores dos mais diversos produtos e funciona muitas vezes como um apelo de marketing muito eficiente. A série teve origem na norma britânica BS570, baseada em padrões militares ainda mais antigos.
A ISO9000 é, na realidade, uma família de normas e tem um caráter genérico.Serve aos propósitos de qualquer organização, em qualquer ramo de atividade,que queria realizar o controle de qualidade dos produtos ou serviços oferecidos.
A norma ISO/IEC 15504 guarda estreita relação com o modelo CMMI.Essa norma apresenta estrutura para a realização de avaliações de processos em organizações, pode ser aplicada em situações como:
- Uma empresa que busca melhorias internas;
Título : B1 - Etapas do Processo Pessoal e de Equipe (PSP/ TSP)
Conteúdo :
Modelos de Processo Pessoal e de Equipe
O melhor processo de software é aquele que se aproxima do pessoal que fará o serviço. Se um modelo de processo de software tiver sido desenvolvido no nível da empresa ou organização, ele pode ser efetivo apenas se for suscetível a adaptações significativas de modo a satisfazer às necessidades da equipe de projeto que esta realmente fazendo o trabalho de engenharia de software.
- PSP (Personal Software Process – Processo Pessoal de Software)
Todo desenvolvedor usa algum processo para construir software de computador. O processo pode ser aleatório ou ad hoc, pode modificar-se diariamente, pode não ser eficiente, efetivo ou mesmo, bem-sucedido, mas existe um processo.
O PSP enfatiza a medição pessoal tanto do produto do trabalho que é produzido quanto a qualidade resultante do produto do trabalho. Além disso, o PSP torna o profissional responsável pelo planejamento do projeto e dá poder ao profissional para controlar a qualidade de todos os produtos do trabalho de software, por ele desenvolvido.
O modelo PSP define cinco atividades: planejamento, projeto de alto nível, revisão do projeto de alto nível, desenvolvimento e pós-conclusão.
Planejamento: Essa atividade, isola os requisitos e, com base neles, desenvolve estimativas tanto de tamanho quanto de recurso. Toda métrica é registrada em planilhas e gabaritos. Finalmente, as tarefas de desenvolvimento são identificadas e um cronograma de projeto é criado.
Projeto de alto nível: São desenvolvidas especificações externas para cada componente a ser construído e é criado um projeto dos componentes, Protótipos são construídos quando existe incerteza. Todos os itens são registrados e monitorados.
Revisão do Projeto de alto nível: Métodos de verificação formal são aplicados para descobrir erros no projeto.
Desenvolvimento: O projeto em nível de componentes é refinado e revisado. O código é, revisado, compilado e testado.
Pós- conclusão: Usando as medidas e as métricas coletadas, a efetividade do processo é determinada.
O PSP enfatiza a necessidade de cada engenheiro de software identificar logo os erros, e igualmente importante, entender os tipos de erros que ele tende a fazer. Isso é conseguido por meio de uma atividade de avaliação rigorosa desenvolvida em todos os produtos de trabalho produzidos pelo Engenheiro de Software.
O PSP representa uma abordagem disciplinada, baseada na métrica, da engenharia de software que pode levar a um choque de cultura em muitos profissionais, quando o mesmo é usado pela engenharia de software o aperfeiçoamento resultante na produtividade e qualidade é significativo.
- TSP (Team Process Software – Processo de Equipe de Software)
Como muitos projetos de software de nível industrial são desenvolvidos por uma equipe de profissionais, Watts Humphrey estendeu as lições aprendidas com a introdução do PSP e propôs o TSP. O objetivo do TSP é construir uma equipe de projeto “autodirigida” que se organize para produzir um software de alta qualidade. Para isso foi definido os seguintes objetivos:
- Construir equipes autodirigidas que planejem e monitorem seu trabalho, estabelecem metas, e possuam seus próprios processos e planos.
- Mostrar aos gerentes como acompanhar e motivar suas equipes,e como ajudá-las a manter seu desempenho de pico,
- Acelerar o aperfeiçoamento do processo de software tornando o comportamento de nível 5 do CMMI normal e esperado,
- Facilitar o ensino as habilidades de equipe de nível industrial.
O TSP define as seguintes atividades: lançamento, projeto de alto nível, implementação, integração e teste, pós-conclusão.
Essas atividades permitem que a equipe planeje, projete e construa softwares de modo disciplinado e, ao mesmo tempo, meça quantitativamente o processo e o produto. A pós-conclusão prepara o cenário para aperfeiçoamento do processo.
O TSP usa uma grande variedade de documentos, formulários e normas que servem para guiar os membros da equipe em seus trabalhos.
O TSP reconhece que as melhores equipes de software são as autodirigidas. Os membros da equipe estabelecem objetivos do projeto, adaptam o processo para satisfazer às suas necessidades, têm controle sobre o cronograma e, por meio de medições e analise da métrica coletada, trabalham continuamente para melhorar a abordagem da equipe do ponto de vista da Engenharia de software.
O TSP é uma abordagem rigorosa de Engenharia e fornece benefícios distintos e quantificáveis em produtividade e qualidade. A equipe deve estabelecer um total comprometimento com o processo e deve passar por treinamentos para garantir que a abordagem seja propriamente aplicada.
Título : B1 - Modelos de Processo de Software (Codifica-Remenda, Waterfall e Incremental)
Conteúdo :
Modelos de Processo de Software
Título : B1 - Modelo RAD e Prototipação Conteúdo :
Modelos de Processo de Software
Um modelo de processo de software é uma representação abstrata de um processo de software, lembrando que um processo de software é um conjunto de atividades que leva à produção de um produto de software.
Cada modelo de processo representa um processo sobre determinada perspectiva e, dessa forma, fornece somente informações parciais sobre esse processo.
Esses modelos não são descrições definitivas de processo de software, como já dito anteriormente, são abstrações do processo que podem ser usadas pra explicar diferentes abordagens para o desenvolvimento de software.
Modelo Caixa-Preta ou Codifica – Remenda
A figura que caracteriza esse processo é:
- Neste modelo com muita sorte existe uma especificação por escrito.
- A codificação é iniciada imediatamente e os erros são corrigidos na medida em que são encontrados.
- Este modelo não oferece nenhum mecanismo de gerenciamento, a não ser liberar um produto depois que os volumes de defeitos críticos tenham sido reduzido a níveis aceitáveis.
- A garantia da qualidade do software é restrita a teste de níveis de sistema (testes do tipo caixa –preta, aquele que você entra com um dado e espera um resulado).
- Essa abordagem é inaceitável para alguns cenários:
o Requisitos que implicam na segurança de vidas humanas;
o Existência de requisitos de qualidade;
o Previsão de custo e cronograma preciso.
Modelo Waterfall – Cascata
O primeiro modelo de processo de desenvolvimento de software publicado originou-se dos processos mais gerais de engenharia de sistemas. Devido ao encadeamento de uma fase com a outra, esse modelo é conhecido como modelo cascata ou modelo de ciclo de vida de software.
Para ocasiões em que os requisitos de um problema são razoavelmente bem compreendidos – quando o trabalho flui de modo razoavelmente linear, isso algumas vezes acontece em uma adaptação bem definidas de sistemas já existentes ou aperfeiçoamento dos mesmos.O modelo cascata pode ser melhor utilizado.
Os principais estágios desse modelo demonstram as atividades fundamentais de desenvolvimento:
- Analise e definição de requisitos: Os serviços, restrições e objetivos são definidos em conjunto com os usuários.
- Projeto de sistema de software: Divide os requisitos em hardware e software, estabelece uma arquitetura geral do sistema.
- Implementação e teste de Unidade: O projeto de software é realizado, e testes unitários são realizados.
- Integração e teste de sistema: As unidades individuais do sistema são integrados e testados como um sistema completo para garantir que os requisitos foram atendidos.
- Operação e Manutenção: Geralmente é a fase mais longa. O sistema é instalado e colocado em operação.
Em princípio o resultado de cada fase resulta em um ou mais documentos aprovados. A fase seguinte não pode começar sem que a anterior tenha terminado. Porém na pratica esses estágios se sobrepõem e trocam informações entre si.
Devido aos custos de produção e aprovação de documentos, as iterações são onerosas e envolvem um retrabalho significativo. É norma que depois de algumas iterações suspender parte dos desenvolvimentos com as especificações e prosseguir com os estágios posteriores do desenvolvimento.
Durante a fase final do ciclo de vida o software é colocado em uso. Erros e omissões nos requisitos originais de software são descobertos.Os erros de programação e projeto emergem e a necessidade de novas funcionalidades é identificada.
A vantagem do modelo cascata consiste na documentação produzida em cada fase e a sua aderência a outros modelos. Seu maior problema é a divisão inflexível do projeto em estágios distintos.
Hoje em dia com o ritmo rápido dos desenvolvimentos de software e as grandes torrentes de modificações de requisitos que os softwares sofrem o modelo cascata é inviável.
Modelo Incremental
O modelo Incremental combina elementos do modelo cascata aplicado de maneira iterativa. O modelo incremental aplica seqüências lineares de uma forma racional à medida que o tempo passa.
Com o modelo incremental é possível entregar parte do projeto, ou chamada parte de funcionalidades básicas de um projeto, antes que o mesmo seja concluído na sua totalidade.
Quando um módulo incremental é usado, o primeiro incremento é freqüentemente chamado de núcleo do produto.Isto é os requisitos básicos são satisfeitos, mas muitas características suplementares deixam de ser elaboradas.
O processo de desenvolvimento incremental tem uma série de vantagens:
- Os clientes não precisam esperar até a entrega do sistema inteiro para se beneficiarem dele.
- Os clientes podem usar incrementos iniciais como protótipos e ganhar experiência, obtendo informações sobre os incrementos posteriores.
- Existe um risco menor de falha geral do projeto
No entanto, existem problemas com a entrega incremental. Os incrementos devem ser relativamente pequenos e cada um deve entregar alguma funcionalidade do sistema. Pode ser difícil mapear os requisitos do cliente em incrementos do tamanho adequado.
Como os requisitos não são definidos detalhadamente até que um incremento seja implementado, pode ser difícil identificar os recursos comuns exigidos por todos os incrementos.
Conteúdo :
O Modelo RAD
ü O RAD(Rapid Application Development, Desenvolvimento Rápido de Aplicação) é um modelo de processo de software incremental que enfatiza um ciclo de desenvolvimento curto.
ü O Modelo RAD é uma adaptação de “alta velocidade” do modelo em cascata, no qual o desenvolvimento rápido é conseguido com o uso de uma abordagem de construção baseada em componentes.
ü No modelo RAD a comunicação trabalha para entender os problemas do negócios e as características informais que o software precisa acomodar.
ü O planejamento é essencial, porque várias equipes de software trabalham em paralelo em diferentes funções do sistema.
ü A modelagem abrange três das fases principais – modelagem de negócios, modelagem dos dados e modelagem dos processos.
ü A construção enfatiza o uso de componentes de software preexistentes e a aplicação de geração de códigos automática.
ü A implantação estabelece a base das iterações subseqüentes se necessárias.
ü Se uma aplicação comercial pode ser modularizada de modo a permitir que cada função principal possa ser completada em menos de três meses é uma candidata ao RAD.
A abordagem RAD tem desvantagens:
1. Para projetos grandes, mas passíveis de sofrer aumento, o RAD exige recursos humanos suficientes para criar um número adequado de equipes RAD.
2. Se desenvolvedores e clientes não estiverem comprometidos com as atividades continuamente rápidas, para completar o sistema em curtíssimo espaço de tempo, o projeto RAD falhará.
3. Se o sistema não puder ser adequadamente modularizado, as construções dos componentes necessários ao RAD serão problemáticas.
4. O RAD pode não ser ajustado quando os riscos técnicos são altos
A seguir segue modelo RAD
Modelo – Prototipação
ü Em casos aonde o desenvolvedor esta inseguro da eficiência do seu algoritmo, da adaptabilidade de um sistema operacional ou da forma de interação homem/máquina o paradigma da prototipagem pode oferecer a melhor abordagem.
ü Apesar de a prototipagem poder ser usada como um modelo de processo independente ela é mais comumente usada como uma técnica que pode ser implementada dentro do contexto de qualquer modelo apresentado.
ü A prototipagem auxilia o engenheiro de software e o cliente a entenderem melhor o que deve ser construído quando os requisitos estão confusos.
ü O projeto rápido concentra-se na representação daqueles aspectos dos softwares que estarão visíveis para o cliente. O projeto rápido leva à construção de um protótipo que é implantado e depois avaliado pelo cliente.
ü O protótipo pode servir como “o primeiro sistema”,aquele que se recomenda a ser descartado.
ü Tanto os clientes como os analistas gostam do modelo de prototipagem. Os clientes porque tem um sistema real nas mãos e os desenvolvedores porque conseguem construir algo imediatamente.
A prototipagem pode ser problemática pelas seguintes razões:
ü O cliente vê o que parece ser uma versão executável do software, ignorando que o protótipo apenas consiga funcionar precariamente.
ü Quando informamos que o produto deve ser refeito para que altos níveis de qualidade possam ser atingidos o cliente reclama e exige alguns acertos para transformar o protótipo em executável.
ü O desenvolvedor freqüentemente faz concessões na implementação a fim de conseguir rapidamente um protótipo executável.
Título : B1 - Modelo Espiral e Modelos Especializados
Conteúdo :
Modelo Espiral
ü O modelo espiral combina a natureza iterativa da prototipagem com os aspectos controlados e sistemáticos do modelo cascata. Ele fornece desenvolvimento rápido de versões cada vez mais completas.
ü Em vez de representar o processo de software como seqüências de atividades com algum retorno entre uma atividade e outra, o processo é representado por uma espiral, onde cada loop da espiral representa uma fase do processo de software.
Cada loop da espiral esta dividido em quatro setores:
o Definição dos objetivos: Os objetivos específicos dessa fase do projeto são definidos, as restrições são identificadas e um plano de gerenciamento detalhado e elaborado. Os riscos do projeto são identificados.
o Avaliação e redução de riscos: Para cada risco do projeto identificado uma analise detalhada é realizada e providências são tomadas para reduzir os riscos.
o Desenvolvimento e Validação: Após a avaliação do risco um modelo de desenvolvimento para o sistema é selecionado
o Planejamento: O projeto é revisado e uma decisão é tomada para prosseguimento ao próximo loop da espiral. Se o próximo loop for começar então são elaborados planos para a próxima fase do projeto.
ü Diferente dos outros modelos, o modelo espiral reconhece o risco.
ü O modelo espiral não termina quando o software é entregue, ele pode ser adaptado para aplicação ao longo da vida do software que foi construído.
ü O modelo espiral é uma abordagem realista do desenvolvimento de sistema e softwares de grande porte.Como o software evolui à medida que o processo avança, o desenvolvedor e o cliente entendem melhor e reagem ao riscos de cada nível evolucionário.
ü O modelo espiral usa a prototipagem como um mecanismo de redução de riscos, porém, mais importante,permite ao desenvolvedor aplicar prototipagem em qualquer estagio da evolução do produto.
Modelos Especializados de Processos
Os modelos especializados tendem a ser aplicados quando uma abordagem de engenharia de software estreitamente definida é escolhida.
Desenvolvimento Baseado em Componentes
Os componentes de software comercial de prateleira, desenvolvidos por vendedores que os oferecem como produtos, podem ser usados quando o software precisa ser construído. Esses componentes fornecem funcionalidades-alvo com interfaces bem definidas que permitem ao componente ser integrado no software.
O modelo de desenvolvimento baseado em componentes incorpora muitas das características do modelo espiral, demanda uma abordagem iterativa para criação de software.
O modelo compõe aplicações a partir de componentes de software previamente preparados. As atividades de modelagem e construção começam com a identificação dos componentes candidatos.
Independente da tecnologia usada para criar os componentes, o modelo de desenvolvimento baseado em componentes incorpora os seguintes passos:
- Produtos baseados em componente disponíveis são pesquisados e avaliados para o domínio da aplicação em questão.
- Tópicos de integração de componentes são considerados.
- Uma arquitetura de software é projetada para acomodar os componentes.
- Componentes são integrados a arquitetura.
- Testes abrangentes são realizados para garantir a funcionalidade adequada.
O modelo de desenvolvimento baseada em componentes leva ao reuso do software, e a reusabilidade fornece aos engenheiros vários benefícios mensuráveis.
ü Redução de 70% do prazo do ciclo de desenvolvimento.
ü Redução de 84% do custo do projeto
ü Um índice de produtividade de 26,2.
O Modelo de Métodos Formais
O modelo de métodos formais abrange um conjunto de atividades que levam à especificação matemática formal do software de computador. Os métodos formais permitem ao engenheiro de software especificar, desenvolver e verificar um sistema baseado em computador pela aplicação rigorosa de uma notação matemática.
Quando métodos formais são usados durante o desenvolvimento, eles fornecem um mecanismo para eliminação de muitos problemas que são difíceis de resolver usando outros paradigmas de engenharia de software.
Quando usados durante o projeto, métodos formais servem de base para a verificação do programa e, assim, permite que o engenheiro descubra e corrija erros que poderiam passar despercebidos.
As desvantagens desse método são:
- O desenvolvimento de modelos formais é atualmente muito lento e dispendioso.
- Como poucos desenvolvedores de software têm o preparo necessário para aplicar métodos formais, torna-se necessário um treinamento extensivo.
- É difícil usar os modelos como um mecanismo de comunicação, com clientes despreparados tecnicamente.
Esse modelo é muito utilizado para construção de softwares críticos.
Desenvolvimento de Software Orientado a Aspectos
Quando as preocupações diversas de um sistema entrecortam várias funções, características e informações do sistema, elas são freqüentemente referidas como preocupações transversais. Requisitos referentes a aspectos definem essas preocupações que têm impacto em toda a arquitetura do software. O desenvolvimento de software orientado a aspecto é um paradigma relativamente novo na engenharia que fornece um processo e abordagem metodológica, para definir, especificar, projetar e construir aspectos.
Conteúdo :
Processos Unificados
O processo unificado reconhece a importância da comunicação com o cliente e dos métodos diretos para escrever a visão do cliente de um sistema (o caso de uso).
Ele enfatiza importantes papeis da arquitetura de software e ajuda o arquiteto a se concentrar nas metas corretas.
Ele sugere um fluxo de processo de software que é iterativo e incremental, dando a sensação evolucionária, que é essencial no desenvolvimento moderno de software.
O processo unificado de software possui 5 fases:
- Fase da Concepção: Abrange atividades de comunicação com os clientes e de planejamento. Em colaboração com os clientes e usuários finais , os requisitos de negócio para o software são identificados, um rascunho de arquitetura é proposto. Os requisitos de negócios são escritos por meio de casos de uso preliminares. Um caso de uso descreve uma seqüência de ações que são realizadas por um ator.
- Fase de elaboração: Refina e expande os casos de uso preliminares que foram desenvolvidos como parte da fase de concepção e expande a representação arquitetural para incluir cinco visões diferentes do software – o modelo de caso de uso, o modelo de analise, o modelo de projeto, o modelo de implementação e o modelo de implantação;
- A fase da construção: É idêntica as atividades de construção definidas pelos modelos genéricos, essa fase desenvolve ou adquire componentes de software que vão tornar cada caso de uso operacional para os usuários finais. Todas as características e funções necessárias e requeridas do incremento de software serão implementadas no código fonte. À medida que os componentes são implementados , testes unitários são realizados.
- Fase de Transição: Abrange os últimos estágios da vida genérica de construção e a primeira parte genérica da atividade de implantação.O software é dado ao usuário final para testes beta e relatórios de feedback do usuário sobre defeitos e modificações necessárias.
- Fase de Produção: Coincidem com as atividades do processo genérico de implantação, durante essa fase o uso do software é monitorado, é fornecido suporte para o ambiente de operação e os relatórios de defeitos e solicitações de modificações são submetidos e avaliados.
Rational Unified Process (RUP)
O RUP é um exemplo de modelo de processo moderno que foi derivado do trabalho sobre a UML e do Processo Unificado de desenvolvimento de software (UP).
O RUP reconhece que os modelos convencionais de processo apresentam uma visão única de processo. Por outro lado, o RUP e descrito a partir de três perspectivas:
- Uma perspectiva dinâmica, que mostra fases do modelo ao longo do tempo.
- Uma perspectiva estática, que mostra as atividades realizadas no processo.
- Uma perspectiva pratica que sugere as boas práticas a serem usadas durante o processo.
O RUP é um modelo constituído por fases que identifica quatro fases discretas no processo de software. As fases do RUP estão relacionadas mais estritamente aos negócios do que aos assuntos técnicos. São elas:
· Concepção: O objetivo dessa fase de concepção é estabelecer um business case para o sistema. Você deve identificar todas as entidades externas (pessoas e sistemas) que irão interagir com o sistema, e definir essas interações. Depois essas informações são usadas para avaliar a contribuição do sistema com o negócio.
· Elaboração: Os objetivos dessa fase é desenvolver um entendimento do domínio do problema, estabelecer um framework de arquitetura para o sistema, desenvolver o plano de projeto e identificar os riscos principais do projeto. (UML)
· Construção: A fase de construção esta essencialmente relacionada ao projeto, programação e teste de sistema. As partes do sistema são desenvolvidas paralelamente e integradas durante essa fase.
· Transição: A fase final do RUP esta relacionada à transferência do sistema da comunidade de desenvolvimento para a comunidade dos usuários e com a entrada do sistema em funcionamento em ambiente real.
Cada fase do RUP pode ser realizada de forma iterativa, com os resultados desenvolvidos incrementalmente, além disso o conjunto total de fases pode ser realizada de forma incremental.
A visão estática do RUP enfoca as atividades que ocorrem durante o processo de desenvolvimento. Elas são chamadas de workflow, dos quais existem seis.
- Modelagem de Negócio;
- Requisitos;
- Análise de Projeto;
- Implementação;
- Teste;
- Implantação;
- Gerenciamento de Configuração;
- Gerenciamento de Projetos;
- Ambiente
- Título : B1 - Inconix, Praxis e Clearoom
Conteúdo :IconixIconix é um processo de desenvolvimento de software- Modelo de Engenharia de Software desenvolvido pela Iconix Software Engineering . Trata-se de uma metodologia prática e simples, mas também poderosa e com um componente de análise e representação de problemas sólidos e eficazes.É um processo não tão burocrático quanto o RUP, ou seja, não gera tanta documentação, mas também não pode ser considerado tão simples como o XP .O Iconix é um processo que está adaptado ao padrão UML, possuindo uma característica exclusiva chamada Rastreabilidade dos Requisitos , que através dos seus mecanismos permite checar em todas as fases se os requisitos estão sendo atendidos.Os principais diagramas usados no processo do Icoxis,são:· Modelo de Domínio: é uma parte essencial do Iconix, ele constrói uma porção estática inicial de um modelo que é essencial para dirigir a fase de design a partir dos casos de uso.Basicamente o modelo de domínio consiste em descobrir objetos de um problema do mundo real. Para realizar o modelo de domínio é preciso tentar descobrir o maior número possível de classes existentes no problema para o qual se pretende desenvolver o software.· Modelo de Caso de Uso:Esse modelo é usado para representar as exigências dos usuários, seja para um sistema novo,ou partindo de um já existente. Ele deve detalhar de forma clara e legível todos os cenários que os usuários executarão para realizar alguma tarefa.· Diagrama de Robustez: Essa fase tem como objetivo conectar a fase de analise com a parte de projeto assegurando que a descrição dos casos de uso está correta, além de descobrir novos objetos através do fluxo de ação.· Diagrama de Seqüência: Tem como objetivo construir um modelo dinâmico entre o usuário e o sistema. Para isso é necessário usar os objetos e suas iterações identificados na analise robusta, porém detalhando todo o fluxo de ação.· Diagrama de Classe: Nada mais é do que o modelo de domínio que foi atualizado ao longo de todas as fazes do processo e representa todas as funcionalidades do sistema de modo estático sem as iterações com o usuário.O Iconix é dividido em dois grandes setores, modelo estático e modelo dinâmico, esses podem ser desenvolvidos paralelamente e de forma recursiva, o modelo estático é formado pelo diagrama de domínio e de classe e o dinâmico pelos demais.
O Iconix trabalha a partir de um protótipo de Interfaces onde se desenvolvem os diagramas de caso de uso baseados nos requisitos levantados. A partir do diagrama do caso de uso, se faz analise robusta para cada caso de uso. Com os resultados obtidos é possível desenvolver o diagrama de seqüência e posteriormente complementar o domínio com novos métodos e atributos descobertos.PraxisO Praxis é um processo de software, baseado no Processo Unificado (UP), desenhado para dar suporte a projetos didáticos. A sigla Praxis significa Processo para Aplicativos e Extensíveis Interativos, refletindo em uma ênfase no desenvolvimento de aplicativos gráficos interativos, baseados na tecnologia orientada a objeto.O Praxis propõe um ciclo de vida composto por fases que produzem um conjunto precisamente definido de artefatos (documentos e modelos). Para construir cada um dos artefatos, o usuário de processo (estudante ou Engenheiro) precisa exercitar um conjunto de praticas recomendáveis. Na construção desses artefatos, o usuário do processo é guiado por padrões e auxiliado pelos modelos de documentos e exemplos constantes de material de apoio.O Praxis adota as mesmas fases e os mesmos fluxos do Processo Unificado. Os principais elementos que constituem o práxis são: - Passo: Divisão formal de um processo, com pré-requisitos, entradas, critérios de aprovação e resultados definidos.
- Fase: Divisão maior de um processo, para fins gerenciais, que corresponde aos pontos principais de aceitação por parte do cliente.
- Interação: Passo constituinte de uma fase, no qual se atinge um conjunto bem definido de metas parciais de um projeto.
- Script: Conjunto de instruções que define como uma iteração deve ser executada.
- Fluxo: Subprocesso caracterizado por um tema Técnico ou Gerencial.
- Subfluxo: Conjunto de atividades mais estreitamente correlatas faz parte de um fluxo maior.
- Atividade: Passo constituinte de um fluxo
- Técnica: Método ou prática aplicável à execução de um conjunto de atividades.
Clearoom
O desenvolvimento de software Cleanroom é uma filosofia de desenvolvimento de software que usa métodos formais para apoiar inspeção rigorosa de software.
O objetivo dessa abordagem para o desenvolvimento de software é o software com defeito zero. O nome Cleanroom foi derivado por analogia com unidades de fabricação de semicondutores, em que os defeitos são evitados na manufatura em uma atmosfera ultralimpa.
A abordagem Cleanroom para desenvolvimento de software baseia-se em cinco estratégias principais:
1. Especificação formal – O software a ser desenvolvido é especificado formalmente. Um modelo de estado e transição que mostra resposta dos sistemas por estímulos é usado para especificar.
- Desenvolvimento Incremental – O software é particionado em incrementos desenvolvidos e validados separadamente, por meio de processo Cleanroom.
- Programação Estruturada – Somente um numero limitado de construções abstratas de controle de dados são usados. Um número limitado de construções é usado e o objetivo é transformar sistematicamente a especificação para criar o código de programa.
- Verificação estática – O software desenvolvido é verificado estaticamente por meio de inspeções rigorosas de software.
- Testes estáticos do sistema – O incremento de software integrado é testado estaticamente.
Há três equipes de software envolvidas quando o processo Cleanroom é usado para desenvolvimento de sistema de grande porte.
· A equipe de Especificação – Esse grupo é responsável pelo desenvolvimento e manutenção das especificações de sistema.
· A equipe de desenvolvimento – É a equipe responsável pelo desenvolvimento e pela verificação do software.
· A equipe de certificação – É responsável pelo desenvolvimento de um conjunto de testes estatísticos para exercitar o software depois de desenvolvido. Os testes baseiam-se em especificações formal.
O uso da abordagem Cleanroom tem conduzido geralmente a um software com poucos ou nenhum erro.
A abordagem para desenvolvimento incremental no processo Cleanroom é entregar a funcionalidade crítica do cliente em incrementos mais cedo. As funções de sistema menos importantes são incluídas em incrementos mais tarde.
A inspeção rigorosa de programa é parte fundamental do processo Cleanroom. A abordagem baseia-se em transformações bem definidas que tentam preservar a correção, a cada transformação, para uma representação mais detalhada. A cada estágio a nova representação é inspecionada e argumentos matematicamente rigorosos são desenvolvidos e demonstrando que a saída da transformação é consistente com a entrada.
O desenvolvimento do Cleanroom funciona quando é praticado por engenheiros habilidosos e comprometidos.
Título : B2 - Processos Ageis e XP
Conteúdo :
Processo Ágil
A metodologia de desenvolvimento que vimos até os dias de hoje são métodos bem complexos usados geralmente para desenvolvimento de softwares grandes e aplicados para empresas geralmente grandes com equipes de desenvolvimento bastante volumosas e que nem sempre ficavam localizados no mesmo lugar, por essa causa os métodos eram complexos e envolviam grandes documentações.
Porém quando essas mesmas metodologias foram aplicadas em sistemas pequenos e empresas que não possuíam um grande volume de desenvolvedores, percebeu-se que o tempo perdido com as especificações e com a documentação era muito dispendioso e o tempo gasto com o desenvolvimento era muito menor, pensando nisso foi que surgiu o que chamamos de métodos ágeis.
Os métodos ágeis contam com uma abordagem interativa para especificação, desenvolvimento e entrega de software, e foram criados principalmente para apoiar o desenvolvimento de aplicações de negócios nas quais os requisitos de sistema mudam rapidamente durante o processo de desenvolvimento. Eles destinam-se a entregar um software de trabalho rapidamente aos clientes, que podem então propor novos requisitos e alterações a serem incluídos nas iterações posteriores do sistema.
Os princípios dos métodos ágeis são:
Ø Envolvimento do cliente: Clientes devem ser profundamente envolvidos no processo de desenvolvimento. Seu papel é fornecer e priorizar novos requisitos do sistema e avaliar as iterações do sistema.
Ø Entrega Incremental: O software é desenvolvido em incrementos e o cliente especifica os requisitos a serem incluídos em cada incremento.
Ø Pessoas, não processos: As habilidades da equipe de desenvolvimento devem ser reconhecidas e exploradas. Os membros da equipe devem desenvolver suas próprias maneiras de trabalhar sem processos prescritos.
Ø Aceite as mudanças: Tenha em mente que os requisitos do sistema vão mudar, por isso projete o sistema para acomodar essas mudanças.
Ø Mantenha a Simplicidade: Concentre-se na simplicidade do software que esta sendo desenvolvido e do processo de desenvolvimento. Sempre que possível, trabalhe ativamente para eliminar a complexidade do sistema.
Extreme Programming (XP)
O extreme programming é talvez o mais conhecido e mais amplamente usado método ágil.
Na extreme programming, todos os requisitos são expressos como cenários, que são implementados diretamente como uma série de tarefas. Os programadores trabalham em pares e desenvolvem testes para cada tarefa antes da escrita do código. Todos os testes devem ser executados com sucesso quando o código é integrado ao sistema.
O extreme programming envolve praticas que se enquadram nos princípios dos métodos ágeis.
Em um processo XP, os clientes estão intimamente envolvidos na especificação e priorização dos requisitos do sistema, o cliente é parte da equipe de desenvolvimento e discute cenários com os outros membros da equipe. Junto eles desenvolvem um “cartão de histórias” que engloba as necessidades do cliente.
Após o desenvolvimento dos cartões de histórias, a equipe de desenvolvimento os dividirá em tarefas e estimará o esforço e os recursos necessários para a implementação. O cliente então prioriza as histórias para implementação, escolhendo as que podem ser usadas imediatamente para proporcionar apoio útil ao negócio.
A extreme programming exige uma abordagem “extrema” para o desenvolvimento iterativo. Novas versões de software podem ser compiladas varias vezes por dia e os incrementos são entregues para os clientes aproximadamente a cada duas semanas.
A extreme programming defende que os softwares devem passar por refactoring constantemente. Isso significa que a equipe de programação procura por possíveis melhorias no software, implementando-as imediatamente, portanto o software deve ser sempre fácil de compreender e alterar quando novas histórias são implementadas.
Título : B2 - SCRUM, FDD e ASD
Conteúdo :
SCRUM
O SRUM é um modelo ágil de processo que foi desenvolvido na década de 1990 e é consistente com o manifesto ágil nos seguintes itens:
· Pequenas equipes de trabalho são organizadas de modo a “maximizar “ a construção, minimizar a supervisão e maximizar o compartilhamento de conhecimento informal.
· O processo precisa ser adaptável tanto a modificações técnicas quanto de negócios para garantir que o melhor produto possível seja produzido.
· O processo produz freqüentes incrementos de software que podem ser inspecionados, ajustados, testados, documentados e expandidos.
· O trabalho de desenvolvimento e o pessoal que o realiza é dividido em partições claras de baixo acoplamento ou em pacotes.
· Testes e documentações constantes são realizados à medida que o produto é produzido.
· O processo SCRUM fornece a habilidade de declarar o produto como pronto sempre que necessário.
Os princípios do Scrum são usados para guiar as atividades de desenvolvimento dentro de um processo que incorpora as seguintes atividades: requisitos, análise, projeto, evolução e etrega. Em cada atividade as tarefas de trabalho ocorrem dentro de um padrão de processos chamados de sprint. O trabalho conduzido dentro de um sprint é adaptado ao problema em mãos e é definido e freqüentemente, modificado em tempo real pela equipe do SCRUM.
No Srum temos:
Ø Pendências: Uma lista priorizada de requisitos ou características do projeto que fornecem valor de negócio para o cliente.
Ø Sprint: Consiste de unidades de trabalho que são necessárias para satisfazer a um requisito definido na pendência que precisa ser cumprido num intervalo de tempo predefinido. Durante o sprint, os itens em pendências a que as unidades de trabalho do sprint se destinam são congelados
Ø Reuniões Scrum: São reuniões curtas feitas diariamente pela equipe Scrum. Três questões chaves são formuladas e respondidas por todos os membros.
o O que você fez desde a ultima reunião?
o Que obstáculo você esta encontrando?
o O que você planeja realizar até a próxima reunião da equipe?
Um líder de equipe chamado Scrum máster que lidera essas reuniões e avalia as respostas de cada membro.
· Demos: Entregas incremental de software ao cliente de modo que a funcionalidade implementada possa ser demonstrada e avaliada pelo cliente.
FDD (Feature Driven Development – Desenvolvimento Guiado por Características)
O FDD surgiu a principio como um modelo prático de processos para engenharia de softwares orientado a objetos, depois esse modelo foi melhorado e adaptado para ser aplicado a projetos de softwares de tamanho moderado e grande.
No contexto do FDD, uma característica é uma função valorizada pelo cliente que pode ser implementada em duas semanas ou menos. A ênfase na definição de característica fornece os seguintes benefícios.
· Como as características são pequenos blocos de funcionalidades passíveis de entrega, os usuários podem descrevê-las mais facilmente, entender como elas se relacionam uma com a outra mais prontamente e revisá-las melhor.
· As características podem ser organizadas em agrupamento hierárquico relacionados ao negocio.
· Como uma característica é um incremento de software passível de entrega do FDD, a equipe desenvolve características operacionais a cada duas semanas.
· Como características são pequenas, suas representações de projeto e de código são mais fáceis de serem inspecionadas.
· Planejamento de projeto, conogramação e monitoração são guiados pela hierarquia de característica em vez de por um conjunto de tarefas de engenharia de software.
ASD- (Adaptative Software Development- Desenvolvimento Adaptativo de Software)
O DAS ou ASD foi proposto como uma técnica para a construção de softwares complexos. O DAS se concentra na colaboração humana e na auto-organização da equipe.
Ele define um ciclo de vida que incorpora três fazes:
ü Especulação: Durante a especulação o projeto é iniciado e o planejamento de um ciclo adaptativo é conduzido. Planejamento do ciclo adaptativo usa informações de iniciação do projeto, a declaração de missão é feita pelo cliente,as restrições do projeto e requisitos básicos são definidos e também é definido a quantidade de ciclos que serão realizados.
ü Colaboração: Pessoal motivado trabalha junto de um modo que multiplica seus talentos e resultados criativos além de seus números absolutos. A colaboração não é fácil. Pessoas que trabalham juntas precisam confiar uma nas outras para: criticar sem animosidade, ajudar sem ressentimentos, trabalhar tão duro ou mais duro do que costumam, ter um conjunto de habilidades para contribuir e comunicar problemas e preocupações de modo efetivo.
ü Aprendizado:A medida que os membros da equipe DAS começam a desenvolver os componentes que fazem parte de um ciclo adaptativo,a ênfase esta tanto no aprendizado quando no desenvolvimento do ciclo.
Título : B2 - DSDM,Crystal e AM
Conteúdo :
Conteúdo :
DSDM (Dynamic Systems Development Method – Metodo de desenvolvimento dinâmico de sistemas)
O DSDM é uma abordagem ágil de desenvolvimento de software que fornece um arcabouço para construir e manter sistemas que satisfazem às restrições de prazos apertadas por meio do uso de prototipagem incremental em um ambiente controlado de projeto.
A abordagem DSDM a cada iteração segue a abordagem dos 80%, isto é , apenas um certo trabalho é necessário para que cada incremento facilite o avanço para o incremento seguinte. Os detalhes restantes podem ser completados depois.
O ciclo de vida do DSDM define três ciclos iterativos diferentes, precedidos por duas atividades adicionais de ciclo de vida:
ü Estudo de viabilidade: Estabelece os requisitos básicos e restrições do negócio associados à aplicação em construção.
ü Estudo de Negócio: Estabelece os requisitos funcionais e de informação que permitirão à aplicação fornecer valor ao negócio.
ü Iteração do modelo funcional: Produz um conjunto de protótipos incrementais que demonstram a funcionalidade para o cliente. O intuito durante esse ciclo iterativo é obter requisitos adicionais.
ü Iteração de projeto e construção: Revisita os protótipos construídos durante a iteração do modelo funcional para garantir que cada um tenha passado por engenharia de modo que seja capaz de fornecer valor de negócio operacional para os usuários finais.
ü Implementação: Coloca o ultimo incremento de software, deve-se notar que o incremento não precisa estar 100% completo, modificações podem ser feitas enquanto o incremento é colocada em ação.
Crystal
Crystal na verdade é uma família de métodos ágeis que possui uma abordagem de desenvolvimento de software que premia a manobrabilidade, caracteriza-se como um jogo cooperativo de invenção e comunicação de recursos limitados, com o principal objetivo de entregar softwares úteis funcionando.
A família crystal possui elementos centrais a todos os tipos de crystal e outros particulares a cada componente da família, esses são escolhidos conforme a adaptabilidade do software a ser construído.
Modelagem Ágil (AM)
A modelagem Ágil foi inspirada para a utilização em softwares muito grandes.
Apesar da AM sugerir uma ampla gama de princípios de modelagem centrais e suplementares os eu tornam AM peculiar são:
ü Modelar com uma finalidade: Um desenvolvedor que usa AM deve ter uma meta especifica em mente antes de criar o modelo. Uma vez identificada a meta do modelo, o tipo de notação a ser usada e o nível de detalhes a ser exigido serão óbvios.
ü Usar modelos múltiplos: Há muitos modelos e notações diferentes que podem ser usados para descrever software. Apenas um pequeno subconjunto é essencial para a maioria dos projetos. A AM sugere que, para fornecer a visão necessária, cada modelo apresente um aspecto diferente do sistema e que apenas aqueles modelos que ofereçam valor seja usados.
ü Viajar leve: À medida que o trabalho de engenharia de software prossegue, conserve apenas aqueles modelos que fornecerão valor ao longo do prazo e livre-se do resto.
ü O conteúdo é mais importante que a representação: Um modelo sistematicamente perfeito que leva pouco conteúdo útil não são tão valioso com um modelo com notação defeituosa, mas que fornece conteúdo valioso .
ü Conhecer os modelos e ferramentas que você usa para criá-los: Entenda os pontos fortes e fracos de cada modelo e das ferramentas que são usadas para criá-los
ü Adaptar localmente: A abordagem de modelagem deve ser adaptada às necessidades da equipe ágil.
ítulo : B2 - Princípios Centrais, Comunicação e Planejamento Conteúdo :
De modo genérico, a prática é uma coleção de conceitos, princípios, métodos e ferramentas da qual um engenheiro de software faz uso diariamente.A pratica preenche um modelo de processo de software com as receitas técnicas e gerenciais necessárias para fazer o serviço.
A essência da pratica da engenharia de software baseou-se na essência da resolução de problemas que é:
1. Entenda o problema (comunicação e análise)
2. Planeje uma solução (modelagem e projeto de software)
3. Execute o plano (geração do código)
4. Examine o resultado quanto à precisão (teste e garantia da qualidade).
Princípios Centrais
Existem 7 princípios centrais para a prática da engenharia de software:
O Primeiro Principio: A razão por que tudo existe
Um sistema de software existe por uma razão: para fornecer valor aos seus usuários. Todas as decisões devem ser tomadas com isso em mente. A pergunta deve ser feita: Isso adiciona valor real ao sistema? Se a resposta for não, não faça. Todos os outros princípios se apóiam nesse.
O Segundo Princípio: KISS(Keep it Simple,Stupid – Mantenha a coisa simples)
Todo projeto deve ser tão simples quanto possível. Isso facilita ter um sistema mais fácil de entender e de mater, mas não quer dizer que características internas, devam ser descartadas em nome da simplicidade. Simples também não significa rápido e sujo.
O Terceiro principio: Mantenha a Visão
Uma visão clara é essencial para o sucesso de um projeto de software. Ter um arquiteto fortalecido que possa manter a visão e exige que ela seja respeitada ajuda a garantir um projeto de software muito bem sucedido.
O Quarto Principio: O que você produz outros vão consumir
De um modo ou de outro alguém mais vai usar,manter, documentar ou precisará entender o seu sistema. Assim, sempre especifique, projete e implemente sabendo que mais alguém terá de entender o eu você esta fazendo.
O Quinto Principio:Esteja Aberto para o Futuro
Os sistemas de software com verdadeira “força industrial” precisam durar muito mais. Para fazer isso com sucesso, eles precisam estar prontos para se adaptar a essas e outras modificações. Sistemas que fazem isso com sucesso são aqueles que foram projetados dessa forma desde o início.
O Sexto Principio: Planeje com Antecedência o Reuso
Reuso poupa tempo e esforço. O reuso de código e de projetos tem sido proclamado como um importante beneficio do uso de tecnologia orientada a objetos.
Planejar o reuso com antecedência reduz custo e aumenta o valor tanto dos componentes reusáveis quanto do sistema ao qual será incorporado.
O Sétimo Principio: Pense!
Raciocinar clara e completamente antes da ação quase sempre produz melhores resultados.Quando você pensa sobre algo é mais provável que o faça corretamente. Você também adquire conhecimento sobre como fazê-lo novamente.
Prática da Comunicação
Antes que os requisitos do cliente possam ser analisados, modelados ou especificados, eles precisam ser coletados por meio de uma atividade de comunicação. O caminho da comunicação para o entendimento é freqüentemente cheio de buracos.
A comunicação efetiva esta entre as atividades mas desafiadoras com as quais se confronta um engenheiro de software.
Os princípios da comunicação é :
Principio 1: Escute
Tente se concentrar nas palavras do intelocutor em vez de na formulação de sua resposta a essas palavras. Peça esclarecimento se algo estiver obscuro. Evite interrupções constantes.
Principio 2: Prepare-se Antes de se comunicar
Gaste tempo em entender o problema antes de se encontrar com os outros, pesquise a respeito para entender a “linguagem” do usuário.
Principio 3:Alguém deve facilitar a atividade
Toda reunião de comunicação deve ter um líder(facilitador) para manter a conversa se movendo em uma direção produtiva, para mediar qualquer conflito e para garantir que os outros princípios sejam seguidos.
Principio 4:Comunicação face a face é melhor
Costuma funcionar melhor quando alguma outra representação da comunicação relevante é apresentada.
Principio 5: Faça anotações e documente as decisões
As coisas têm um modo de escorrer por entre os dedos. Alguém que participe da comunicação deve servir como um registrador e anotar todos os pontos importantes.
Principio 6: Busque Colaboração
Colaboração e consenso ocorrem quando o conhecimento coletivo dos membros da equipe é combinado para descrever funções e características do sistema.
Principio 7: Conserve-se focado, modularize sua discussão
Quanto mais pessoas estiverem envolvidas em uma comunicação, mais provavelmente aquela discussão vai ficar saltando de um tópico para o outro. O facilitador deve manter a conversa modular, abandonando um tópico apenas depois que estiver resolvido.
Principio 8:Se algo não esta claro desenhe uma figura
A comunicação verbal vão só até um certo ponto, um esboço ou um desenho pode freqüentemente fornecer esclarecimento.
Principio 9: Prossiga
A comunicação, como qualquer atividade de engenharia leva tempo. Em vez de iterar sem fim, as pessoas que participam devem reconhecer que muito tópicos requer discussão e devem prosseguir com a reunião sem se prender a eles nesse momento.
Principio 10:Negociação
Existem muitas instancias em que os engenheiros de software e os clientes devem negociar funções e características, isso deve ser feito de modo que ambas as partes saiam ganhando, assim sendo negociação exige comprometimento de ambas as partes.
Praticas do Planejamento
A atividade de planejamento inclui um conjunto de praticas gerenciais e técnicas que permitem a equipe de software definir um roteiro enquanto ela se move em direção a sua meta estratégica e seus objetivos táticos.
Em muitos projetos o planejamento excessivo consome tempo e não produz frutos, mas a falta de planejamento é uma receita para o caos. O planejamento deve ser conduzido com moderação.
Independente do rigor com o qual o planejamento é conduzido os princípios a seguir se aplicam:
Principio 1: Entenda o escopo do Projeto
É impossível usar um roteiro se você não souber para onde está indo. O escopo fornece a equipe de software um destino
Principio 2: Envolva o cliente na atividade de planejamento
O cliente que define as prioridades e oferece as restrições do projeto, por isso ele deve ser envolvido no planejamento.
Principio 3: Reconheça que o planejamento é iterativo
Um plano de projeto nunca é gravado em pedra. Quando o trabalho tem início, é muito provável que as coisas se modifiquem, como conseqüência o plano deve ser ajustado para acomodar as modificações.
Principio 4: Estime com base no que é sabido
A intenção de uma estimativa é fornecer uma indicação de esforço, o custo, a duração de tarefas com base no entendimento atual da equipe quanto ao trabalho a ser feito.
Principio 5: Considere riscos à medida que você define o plano
Se a equipe tiver definido riscos que têm grande impacto e alta probabilidade, é necessário planejamento e contingência.
Principio 6: Seja realista
As pessoas não trabalham 100% do tempo do dia, sempre há ruídos em qualquer comunicação humana, omissões, ambigüidade.
Principio 7: Ajuste a granularidade a medida que você define o plano
Granularidade refere-se ao nível de detalhes introduzido à medida que um plano de projeto é desenvolvido.
Principio 8: Defina como você pretende garantir a qualidade
O plano deve identificar como a equipe de software pode garantir a qualidade.
Principio 9: Descreva como você pretende acomodar as modificações
Mesmo o melhor planejamento pode ser comprometido por modificações descontroladas. A equipe de software deve identificar como as modificações devem ser acomodadas a medida que o trabalho prossegue.
Principio 10: Acompanhe o plano com freqüência e faça os ajustes necessários
Projetos de software se atrasam um dia de cada vez. Assim faz sentido acompanhar o progresso diariamente, procurando áreas problemáticas e situações em que o trabalho não esta de acordo com o programado.
Título : B2 - Modelagem, Construção e Implantação
Conteúdo :
Conteúdo :
Prática da Modelagem
No trabalho de engenharia de software, duas classes de modelos são criadas: modelos de análise e modelos de projeto. Os modelos de analise representam os requisitos do cliente mostrando o software em três domínios diferentes: o domínio de informação, o domínio funcional e o domínio comportamental. Os modelos de projeto representam características de software que ajudam os profissionais a construí-lo efetivamente: a arquitetura, a interface com o usuário e detalhes em nível de componentes.
Princípios da Modelagem de Análise
Princípio 1: O domínio da informação de um problema precisa ser representado e entendido
O domínio de informação abrange os dados que fluem para dentro do sistema, os dados que fluem para fora do sistema e os depósitos de dados que coletam e organizam os objetos de dados persistentes.
Principio 2: As funções a serem desenvolvidas pelo software devem ser definidas.
As funções do software fornecem benefícios diretos aos usuários finais. Algumas funções transformam os dados que fluem para dentro do sistema. Em outros casos, as funções efetuam algum nível de controle sobre o processamento interno do software.As funções podem ser descritas em vários níveis de abstração diferentes que vão desde uma declaração geral até uma descrição detalhada.
Princípio 3: O comportamento do software precisa ser representado
O comportamento do software do computador é guiado por suas iterações com o ambiente externo. Entradas fornecidas pelos usuários finais, dados de controle fornecidos por um sistema externo ou monitoramento de dados coletados em uma rede, todos fazem com que o software se comporte de um modo específico.
Princípio 4: Os modelos que mostram informação, função e comportamento devem ser particionados de um modo que revele detalhes em forma de camadas.
A modelagem de analise é o primeiro passo na solução de um problema de engenharia de software. Ela permite que os profissionais entendam melhor o problema e estabelece uma base para a solução. Um problema complexo, e grande é dividido em subproblemas. Esse é o conceito chamado de particionamento e é uma estratégia chave na modelagem de analise.
Princípio 5: A tarefa de analise deve ir da informação essencial até os detalhes de implementação.
A modelagem de análise começa descrevendo o problema na perspectiva do usuário final. A “essência” do problema é descrita sem qualquer consideração de como uma solução será implementada.Os detalhes de implementação indicam como a essência será implementada.
Princípios de modelagem de Projeto
O modelo de projeto é equivalente às plantas de engenharia de uma casa. Ele começa com a representação da totalidade do objeto a ser construído e lentamente refina o objeto.
Princípio 1: O projeto deve estar relacionado ao modelo de analise.
O modelo de projeto traduz essa informação em uma arquitetura: um conjunto de subsistemas que implementam as funções principais e um conjunto de projetos em nível de componentes que são a realização das classes de analise.
Principio 2: Sempre considere a arquitetura do sistema a ser construído.
A arquitetura de software é o esqueleto do sistema a ser construído. Ela afeta as interface, estruturas de dados, fluxo de controle e comportamento do programa. Por todas essas razões o projeto deve começar com considerações arquiteturais.
Principio 3: O projeto dos dados é tão importante quanto o projeto de funções de processamento.
Os projetos de dados é um elemento essencial no projeto arquitetural. Um projeto de dados bem estruturado ajuda a simplificar o fluxo do programa e torna a implementação mais fácil.
Principio 4: As interfaces precisam ser projetadas com cuidado.
A maneira como os dados fluem entre os componentes de um sistema tem muito a ver com a eficiência do processamento, a programação de erros e a simplicidade do projeto. Uma interface bem projetada torna a implementação mais fácil.
Princípio 5: O projeto de interface do usuário deve estar sintonizado com as necessidades dos usuários finais.
A interface do usuário é a manifestação visível do software. Não importa quão sofisticada sejam suas funções interna quão abrangente suas estruturas de dados, quão bem projetada sua arquitetura, um projeto de interface pobre conduz, muitas vezes, à percepção de que o software é ruim.
Principio 6: O projeto em nível de componentes deve ser funcionalmente independente.
A independência funcional é uma medida da objetividade de um componente de software.
Principio 7: Os componentes devem ser fracamente acoplados uns aos outros e ao ambiente externo.
O acoplamento é conseguido de muitos modos – Via interface de componentes, por mensagem, por meio de dados globais. À medida que o nível de acoplamento aumenta a probabilidade de programação com erros também aumenta.
Principio 8: Representação de projeto deve ser facilmente compreendida.
O objetivo do projeto é comunicar a informação para os profissionais que vão gerar o código, para aqueles que vão testar o código, e para outros que podem vir a manter o software no futuro, portanto a mesma deve ser de fácil entendimento para todos.
Princípio 9: O projeto deve ser desenvolvido iterativamente. A cada iteração o projetista deve lutar por maior simplicidade.
Como quase todas as atividades criativas, o projeto ocorre iterativamente. As primeiras iterações trabalham para refinar o projeto e corrigir erros, mas as últimas iterações devem procurar tornar o projeto o mais simples possível.
Práticas da Construção
A prática da construção compreende um conjunto de tarefas de codificação e teste que levam ao software operacional que está pronto para ser entregue ao cliente ou ao usuário final.
Os princípios e conceitos que dirigem a tarefa de codificação são estilo de programação, linguagem de programação e métodos de programação rigorosamente definidos.
Princípios de Preparação. Antes de escrever uma linha de código certifique-se de:
- Entender o problema que esta tentando resolver.
- Entender os princípios e conceitos básicos do projeto
- Escolher uma linguagem de programação que satisfaça as necessidades do software a ser construído e do ambiente que vai operar.
- Selecionar um ambiente de programação que fornece ferramentas para facilitar o seu trabalho.
- Criar um conjunto de testes unitários que será aplicado tão logo componente que você está codificando for completado.
Princípios de codificação: Quando começar a escrever o código certifique-se de:
- Restringindo seus algoritmos seguindo a pratica de programação estruturada.
- Selecionar estruturas de dados que atendam as necessidades do projeto.
- Entender a arquitetura do software e criar interfaces que sejam consistentes com ela.
- Conservar a lógica condicional tão simples quanto possível.
- Criar ciclos aninhados de modo que sejam facilmente testáveis.
- Selecionar nomes significativos de variáveis e seguir outras normas locais de codificação.
- Escrever códigos que é autodocumentado.
- Criar uma disposição visual que auxilie o entendimento.
Princípios de validação: Depois de completar seu primeiro passo de codificação, certifique-se de:
- Conduzir uma inspeção de código quando adequado
- Realizar testes unitários e descobrir os erros encontrados
- Refabricar o código quando necessário.
Praticas da Implantação
A implantação não ocorre uma única vez, mas várias vezes, à medida que o software caminha para ficar completo.
A entrega de um incremento de software apresenta um marco importante para qualquer projeto de software. Alguns princípios chave devem ser seguidos à medida que a equipe se prepara para entregar um incremento.
Princípio 1: As expectativas do cliente quanto ao software devem ser geridas
Muito freqüentemente, o cliente espera mais do que a equipe prometeu entregar e o desapontamento é imediato, isso resulta em feedback não produtivo e arruína o moral da equipe. Um engenheiro de software deve ser cuidadoso com o envio de mensagens conflitantes ao cliente.
Principio 2: Um pacote completo de entrega deve ser montado e testado.
Um CD ou outra mídia contendo todo o software executável, arquivos de dados de suporte, documentos de suporte e ouras informações relevantes deve ser montado e rigorosamente testado por testes beta com usuários reais.
Princípio 3: Um regime de suporte deve ser estabelecido antes do software ser entregue.
Um usuário final espera receptividade e informação segura quando uma questão ou um problema surge. Se o suporte é ad hoc ou, pior, inexistente, o cliente ficará insatisfeito imediatamente.
Principio 4: Materiais institucionais adequados devem ser fornecidos aos usuários finais.
A equipe de software entrega mais do que um software em si. Ajuda de treinamento adequado deve ser desenvolvida, diretrizes de depuração deve ser fornecida e uma descrição de “o que é diferente nesse incremento de software” deve ser publicada.
Principio 5: Software defeituoso deve ser corrigido primeiro e depois entregue
Pressionados pelo tempo, algumas organizações de software entregam incrementos de baixa qualidade com um aviso ao cliente que defeitos serão consertados na versão seguinte. Isso é um erro.
0 comentários