Professor: Pergentino Araújo
Complemento das aulas de Engenharia de Software
Aluno: Eron Targino da Silva
Bibliografia adotadas na disciplina e no blog:
- PRESSMAN,Roger. Engenharia de Software. Pearson Makron Books, 2009.
- REZENDE, Denis Alcides. Engenharia de Software e Sistemas de Informação. 2a Edição, Editora Brasport, 2002.
- TONSIG, Sérgio Luiz. Engenharia de Software: Análise e Projeto de Sistemas. 2a Edição, Editora Ciência Moderna, 2008.
- KOSCIANSKI, A., Soares, M. S.. Qualidade de Software. Editora Novatec, Segunda Edição, 2007.
- ALVES, Rafael Ferreira; VANALLE, Rosângela Maria. CICLO DE VIDA DE ESENVOLVIMENTO DE SISTEMAS - VISÃO CONCEITUAL DOS MODELOS CLÁSSICO, ESPIRAL E PROTOTIPAÇÃO.
- Apostila Engenharia de Software - PROF. VITÓRIO BRUNO MAZZOLA -
O que lembra a palavra Engenharia?
Planejar, construir.
O que lembra a palavra Software?
Programas, aplicativos.
Definição: Disciplina que utiliza um conjunto de métodos, técnicas e ferramentas para analisar, projetar e gerenciar desenvolvimento e manutenção de software.
Objetivos: Melhorar a qualidade do software e aumentar a produtividade e satisfação profissional de engenheiros de software.
A engenharia de software tem por objetivos a aplicação de teoria, modelos, formalismos e técnicas e ferramentas da ciência da computação e áreas afins para a produção (ou desenvolvimento) sistemática de software.
Associado ao desenvolvimento, é preciso também aplicar métodos, técnicas e ferramentas para o gerenciamento do processo de produção. Isto envolve planejamento de custos e prazos, montagem da equipe e garantia de qualidade do produto e do processo.
Finalmente, a engenharia de software visa a produção da documentação formal do produto, do processo, dos critérios qualidade e dos manuais de usuários finais.
Definição e Características de Software
No contexto da Engenharia de Software, o software deve ser visto como um produto a ser "vendido". É importante dar esta ênfase, diferenciando os "programas" que são concebidos num contexto mais restrito, onde o usuário ou "cliente" é o próprio autor. No caso destes programas, a documentação associada é pequena ou (na maior parte das vezes) inexistente e a preocupação com a existência de erros de execução não é um fator maior, considerando que o principal usuário é o próprio autor do programa, este não terá dificuldades, em princípio, na detecção e correção de um eventual "bug". Além do aspecto da correção, outras boas características não são também objeto de preocupação como a portabilidade, a flexibilidade e a possibilidade de reutilização.
Um produto de software, por outro lado, é sistematicamente destinado ao uso por pessoas outras que os seus programadores. Os eventuais usuários podem, ainda, ter formações e experiências diferentes, o que significa que uma grande preocupação no que diz respeito ao desenvolvimento do produto deve ser a sua interface, reforçada com uma documentação rica em informações para que todos os recursos oferecidos possam ser explorados de forma eficiente. Ainda, os produtos de software devem passar normalmente por uma exaustiva bateria de testes, dado que os usuários não estarão interessados (e nem terão capacidade) de detectar e corrigir os eventuais erros de execução.
Resumindo, um programa desenvolvido para resolver um dado problema e um produto de software destinado à resolução do mesmo problema são duas coisas totalmente diferentes. É óbvio que o esforço e o conseqüente custo associado ao desenvolvimento de um produto serão muito superiores.
Definição de Engenharia de Software
Os problemas apontados nas seções anteriores não serão, é claro, resolvidos da noite para o dia, mas reconhecer a existência dos problemas e definí-los da forma mais precisa e eficaz são, sem dúvida, um primeiro passo para a sua solução.
Um produto de software, por outro lado, é sistematicamente destinado ao uso por pessoas outras que os seus programadores. Os eventuais usuários podem, ainda, ter formações e experiências diferentes, o que significa que uma grande preocupação no que diz respeito ao desenvolvimento do produto deve ser a sua interface, reforçada com uma documentação rica em informações para que todos os recursos oferecidos possam ser explorados de forma eficiente. Ainda, os produtos de software devem passar normalmente por uma exaustiva bateria de testes, dado que os usuários não estarão interessados (e nem terão capacidade) de detectar e corrigir os eventuais erros de execução.
Resumindo, um programa desenvolvido para resolver um dado problema e um produto de software destinado à resolução do mesmo problema são duas coisas totalmente diferentes. É óbvio que o esforço e o conseqüente custo associado ao desenvolvimento de um produto serão muito superiores.
Definição de Engenharia de Software
Os problemas apontados nas seções anteriores não serão, é claro, resolvidos da noite para o dia, mas reconhecer a existência dos problemas e definí-los da forma mais precisa e eficaz são, sem dúvida, um primeiro passo para a sua solução.
Em primeiro lugar, é preciso estar ciente também de que não existe uma abordagem mágica que seja a melhor para a solução destes problemas, mas uma combinação de métodos que sejam abrangentes a todas as etapas do desenvolvimento de um software.
Além disto, é importante e desejável que estes métodos sejam suportados por um conjunto de ferramentas que permita automatizar o desenrolar destas etapas, juntamente com uma definição clara de critérios de qualidade e produtividade de software. São estes aspectos que caracterizam de maneira mais influente a disciplina de Engenharia de Software.
Num ponto de vista mais formal, a Engenharia de Software pode ser definida como sendo a aplicação da ciência e da matemática através das quais os equipamentos computacionais são colocados à disposição do homem por meio de programas, procedimentos e documentação associada. De modo mais objetivo, pode-se dizer que a Engenharia de Software busca prover a tecnologia necessária para produzir software de alta qualidade a um baixo custo. Os dois fatores motivadores são essencialmente a qualidade e o custo. A qualidade de um produto de software é um parâmetro cuja quantificação não é trivial, apesar dos esforços desenvolvidos nesta direção. Por outro lado, o fator custo pode ser facilmente quantificado desde que os procedimentos de contabilidade tenham sido corretamente efetuados.
Ciclo de Vida de Sistemas
Conhecimento, criatividade, competências e estratégias, este somatório caracteriza a Inteligência de uma empresa e garante relações duradouras com os clientes. É compromisso com resultados. Além disso, um forte ambiente de pesquisa, alinhado à pluralidade das competências tecnológicas e à potencialidade de produção, que assegura espaços para a melhoria dos produtos e serviços, e garante uma percepção capaz de antecipar a construção de soluções inovadoras.
A capacidade de planejamento e de resolução de problemas, compreensão de idéias e aprendizagem contínua são destaques da inteligência presente em cada atividade executada e representam o diferencial nos serviços de uma empresa.
A incerteza sobre os requisitos do sistema em desenvolvimento é a maior causa de erros ou custos em um projeto. Neste contexto, as abordagens para desenvolvimento de sistemas (clássica, espiral e prototipação), visam auxiliar o desenvolvedor na identificação das necessidades do usuário.
A abordagem clássica prevê o desenvolvimento do sistema mediante algum tipo de análise, projeto e implementação, que são realizadas seqüencialmente, ou seja, uma após o término da outra. A prototipação prevê a construção de um modelo do software que será implementado. Já o modelo espiral, além de abranger características do modelo clássico e da prototipação, inclui um novo fator que é a análise dos riscos. A seguir, procura-se delinear cada modelo, contemplando as suas fases e seus problemas.
Objetivo do ciclo de vida
Transformar informação em solução. Agregar variedades de Serviços, Tecnologias e Setores.
A importância do ciclo de vida
Ter um ciclo de vida de projeto de sistema é importante pelas seguintes razões:
* Definição das atividades a serem executadas em um projeto.
* Consistência entre muitos projetos de desenvolvimento da mesma organização.
* Introdução de pontos de verificação para o controle gerencial de decisões.
* Facilidades no gerenciamento de prazos.
Etapas do ciclo de vida de sistemas
Fábrica de Projetos
Fábrica de Testes
Centro de Sustentação de Sistemas (CSS)
Desenvolvimento e Manutenção SAP
Escritório de Gerenciamento de Projetos (PMO)
Documentação de Sistemas
Métricas de Projetos
Transformação de Sistemas Legados
CICLO DE VIDA CLÁSSICO OU CASCATA
Além disto, é importante e desejável que estes métodos sejam suportados por um conjunto de ferramentas que permita automatizar o desenrolar destas etapas, juntamente com uma definição clara de critérios de qualidade e produtividade de software. São estes aspectos que caracterizam de maneira mais influente a disciplina de Engenharia de Software.
Num ponto de vista mais formal, a Engenharia de Software pode ser definida como sendo a aplicação da ciência e da matemática através das quais os equipamentos computacionais são colocados à disposição do homem por meio de programas, procedimentos e documentação associada. De modo mais objetivo, pode-se dizer que a Engenharia de Software busca prover a tecnologia necessária para produzir software de alta qualidade a um baixo custo. Os dois fatores motivadores são essencialmente a qualidade e o custo. A qualidade de um produto de software é um parâmetro cuja quantificação não é trivial, apesar dos esforços desenvolvidos nesta direção. Por outro lado, o fator custo pode ser facilmente quantificado desde que os procedimentos de contabilidade tenham sido corretamente efetuados.
Ciclo de Vida de Sistemas
Conhecimento, criatividade, competências e estratégias, este somatório caracteriza a Inteligência de uma empresa e garante relações duradouras com os clientes. É compromisso com resultados. Além disso, um forte ambiente de pesquisa, alinhado à pluralidade das competências tecnológicas e à potencialidade de produção, que assegura espaços para a melhoria dos produtos e serviços, e garante uma percepção capaz de antecipar a construção de soluções inovadoras.
A capacidade de planejamento e de resolução de problemas, compreensão de idéias e aprendizagem contínua são destaques da inteligência presente em cada atividade executada e representam o diferencial nos serviços de uma empresa.
A incerteza sobre os requisitos do sistema em desenvolvimento é a maior causa de erros ou custos em um projeto. Neste contexto, as abordagens para desenvolvimento de sistemas (clássica, espiral e prototipação), visam auxiliar o desenvolvedor na identificação das necessidades do usuário.
A abordagem clássica prevê o desenvolvimento do sistema mediante algum tipo de análise, projeto e implementação, que são realizadas seqüencialmente, ou seja, uma após o término da outra. A prototipação prevê a construção de um modelo do software que será implementado. Já o modelo espiral, além de abranger características do modelo clássico e da prototipação, inclui um novo fator que é a análise dos riscos. A seguir, procura-se delinear cada modelo, contemplando as suas fases e seus problemas.
Objetivo do ciclo de vida
Transformar informação em solução. Agregar variedades de Serviços, Tecnologias e Setores.
A importância do ciclo de vida
Ter um ciclo de vida de projeto de sistema é importante pelas seguintes razões:
* Definição das atividades a serem executadas em um projeto.
* Consistência entre muitos projetos de desenvolvimento da mesma organização.
* Introdução de pontos de verificação para o controle gerencial de decisões.
* Facilidades no gerenciamento de prazos.
Etapas do ciclo de vida de sistemas
Fábrica de Projetos
Fábrica de Testes
Centro de Sustentação de Sistemas (CSS)
Desenvolvimento e Manutenção SAP
Escritório de Gerenciamento de Projetos (PMO)
Documentação de Sistemas
Métricas de Projetos
Transformação de Sistemas Legados
CICLO DE VIDA CLÁSSICO OU CASCATA
Conforme Yourdon (1990), todo projeto desenvolvido segundo o Ciclo de Vida Clássico é executado mediante algum método de análise de sistemas, projeto e implementação, mesmo que não seja feito conforme ilustrado pela figura 1. Assim, o número de fases varia de organização para organização e pode ter cinco, sete ou doze fases.
Pode-se observar que as fases pertencentes ao Ciclo de Vida Clássico, contemplam um conjunto seqüencial de ações de desenvolvimento, desde o diagnóstico do problema até os testes necessários à implementação.
O ciclo de vida clássico ou em cascata caracteriza-se por uma forte tendência à implementação bottom-up, onde o sistema é desenvolvido em módulos específicos os quais são testados separadamente e, somente após esses testes, todo o sistemas é integrado para ser avaliado como um todo. A insistência na progressão linear e seqüencial das fases não permite apresentar um produto até que a fase de testes esteja concluída. Um diagrama desse ciclo de vida apresentado por Royce (apud YOURDON,1992,103) pode ser visto na Figura 2 logo abaixo.
O ciclo de vida clássico ou em cascata caracteriza-se por uma forte tendência à implementação bottom-up, onde o sistema é desenvolvido em módulos específicos os quais são testados separadamente e, somente após esses testes, todo o sistemas é integrado para ser avaliado como um todo. A insistência na progressão linear e seqüencial das fases não permite apresentar um produto até que a fase de testes esteja concluída. Um diagrama desse ciclo de vida apresentado por Royce (apud YOURDON,1992,103) pode ser visto na Figura 2 logo abaixo.
O ciclo é representado pelas seguintes fases: (a) viabilidade, que tem como função a definição preliminar do escopo do sistema, restrições e conceitos alternativos; (b) análise, especificação funcional do sistema; (c) projeto, especificação completa da arquitetura de hardware e software, estruturas de controle, estruturas de dados do sistema, interfaces; (d) implementação, codificação e teste individual dos programas; (e) teste, teste dos componentes integrados do sistema; (f) implantação, implantação de maneira gradativa, a fim de evitar insatisfação e possibilitando a correção do sistema; e (g) operação e manutenção, utilização do sistema e modificações decorrentes de erros, mudanças e necessidades, etc.
Histórico
Popularizado na década de 1970
– Composto por uma seqüência de atividades
– Uma atividade começa a executar quando a outra termina
– Resultado de uma etapa é utilizado na etapa seguinte
– Guiado por documentos
– Ciclo de vida mais antigo e mais utilizado
Problemas
– Dificuldade de manter a serialização proposta pelo modelo
– Dificuldade de se concluir a etapa de análise de requisitos, devido a modificações nos requisitos do software (requisitos deveriam ser congelados ao fim da análise)
– A primeira versão do software só estará disponível após o término das fases de análise, projeto, codificação e testes, aumentando o tempo de latência entre o início do projeto e a criação de sua primeira versão
Soluções
– Alterações e expansões do modelo clássico
CICLO DE VIDA DA PROTOTIPAÇÃO
É uma variação da abordagem top-down, popularizou-se com Bernard Boar, James Martin e outros. Esse modelo é descrito por Boar em ( apud Yourdon,1992,120):
"Uma abordagem alternativa para a definição de requisitos é obter um conjunto inicial de necessidades e implementá-las rapidamente com a intenção declarada de expandi-las e refiná-las iterativamente à proporção do aumento do conhecimento mútuo do sistema por parte do usuário e do desenvolvedor. A definição do sistema ocorre através da descoberta gradual e evolutiva em oposição à previsão onisciente... Esse tipo de abordagem é chamada de prototipação. Ela também é conhecida como modelagem de sistemas ou desenvolvimento heurístico. Ela oferece uma alternativa atraente e funcional para métodos de pré-especificação para que se possa lidar melhor com a incerteza, a ambigüidade e a inconstância dos projetos do mundo real".
O modelo pode assumir três formas: - Um protótipo em papel ou sistema, apresentando apenas a interação usuário-sistema (prototipagem descartável); - Um protótipo que implementa algumas funções exigidas pelo sistema; - Um protótipo que executa superficialmente todas as funções desejadas pelo sistema, sendo que sofrerá sucessivos refinamentos (prototipagem evolucionária).
Histórico
Popularizado na década de 1970
– Composto por uma seqüência de atividades
– Uma atividade começa a executar quando a outra termina
– Resultado de uma etapa é utilizado na etapa seguinte
– Guiado por documentos
– Ciclo de vida mais antigo e mais utilizado
Problemas
– Dificuldade de manter a serialização proposta pelo modelo
– Dificuldade de se concluir a etapa de análise de requisitos, devido a modificações nos requisitos do software (requisitos deveriam ser congelados ao fim da análise)
– A primeira versão do software só estará disponível após o término das fases de análise, projeto, codificação e testes, aumentando o tempo de latência entre o início do projeto e a criação de sua primeira versão
Soluções
– Alterações e expansões do modelo clássico
CICLO DE VIDA DA PROTOTIPAÇÃO
É uma variação da abordagem top-down, popularizou-se com Bernard Boar, James Martin e outros. Esse modelo é descrito por Boar em ( apud Yourdon,1992,120):
"Uma abordagem alternativa para a definição de requisitos é obter um conjunto inicial de necessidades e implementá-las rapidamente com a intenção declarada de expandi-las e refiná-las iterativamente à proporção do aumento do conhecimento mútuo do sistema por parte do usuário e do desenvolvedor. A definição do sistema ocorre através da descoberta gradual e evolutiva em oposição à previsão onisciente... Esse tipo de abordagem é chamada de prototipação. Ela também é conhecida como modelagem de sistemas ou desenvolvimento heurístico. Ela oferece uma alternativa atraente e funcional para métodos de pré-especificação para que se possa lidar melhor com a incerteza, a ambigüidade e a inconstância dos projetos do mundo real".
O modelo pode assumir três formas: - Um protótipo em papel ou sistema, apresentando apenas a interação usuário-sistema (prototipagem descartável); - Um protótipo que implementa algumas funções exigidas pelo sistema; - Um protótipo que executa superficialmente todas as funções desejadas pelo sistema, sendo que sofrerá sucessivos refinamentos (prototipagem evolucionária).
Problemas do Ciclo de Vida da Prototipação
Como o Ciclo de Vida Clássico, a prototipação também tem alguns problemas:
* O cliente vê o protótipo e tem pressa para colocá-lo em funcionamento, não levando em consideração a qualidade global do sistema.
* Muitas vezes o desenvolvedor quer colocar o protótipo em funcionamento rapidamente, com isso, um sistema operacional ou linguagem de programação imprópria pode ser usada, simplesmente porque está à disposição e é conhecida. (Pressman, 1995).
CICLO DE VIDA ESPIRAL
O modelo Espiral, segundo Pressman (1995), abrange as melhores características do Ciclo de Vida Clássico e da Prototipação, acrescentando um novo elemento: a análise dos riscos, inexistentes nos outros dois modelos.
Esse modelo corrige (ao menos em parte) o fato do desenvolvimento de sistema ter ciclos, onde as tarefas são repetidas. Não corrige o fato de que em algumas fases apliquemos simultaneamente (ainda que em menor proporção), habilidades de outras fases, porém isso é uma limitação própria do modelo.
Um fator muito importante no modelo Espiral é que cada ciclo é completado com uma revisão, na presença de pessoas chave para o produto em desenvolvimento. Esta revisão mostra tudo o que foi desenvolvido durante o ciclo previsto, incluindo os planos para a próxima etapa a ser realizada.
O modelo em espiral é representado por um plano dividido em 4 quadrantes (figura
3), onde cada um deles contém uma fase cíclica do trabalho de desenvolvimento. Esse plano é percorrido por uma linha espiral, que nasce no centro do plano (momento zero do trabalho de desenvolvimento), e que tem prosseguimento caminhando do centro para as bordas, sempre passando pelas 4 fases cíclicas, de tal forma que um ciclo se repete após o outro, até que o trabalho seja dado como concluído. Define quatro atividades principais:
* Planejamento: é a determinação dos objetivos, alternativas e restrições do projeto.
* Análise dos Riscos: é a análise das alternativas e a resolução dos riscos.
* Execução: desenvolvimento do produto.
* Verificação feita pelo Cliente: é a avaliação dos resultados obtidos nas atividades da engenharia.
Como o Ciclo de Vida Clássico, a prototipação também tem alguns problemas:
* O cliente vê o protótipo e tem pressa para colocá-lo em funcionamento, não levando em consideração a qualidade global do sistema.
* Muitas vezes o desenvolvedor quer colocar o protótipo em funcionamento rapidamente, com isso, um sistema operacional ou linguagem de programação imprópria pode ser usada, simplesmente porque está à disposição e é conhecida. (Pressman, 1995).
CICLO DE VIDA ESPIRAL
O modelo Espiral, segundo Pressman (1995), abrange as melhores características do Ciclo de Vida Clássico e da Prototipação, acrescentando um novo elemento: a análise dos riscos, inexistentes nos outros dois modelos.
Esse modelo corrige (ao menos em parte) o fato do desenvolvimento de sistema ter ciclos, onde as tarefas são repetidas. Não corrige o fato de que em algumas fases apliquemos simultaneamente (ainda que em menor proporção), habilidades de outras fases, porém isso é uma limitação própria do modelo.
Um fator muito importante no modelo Espiral é que cada ciclo é completado com uma revisão, na presença de pessoas chave para o produto em desenvolvimento. Esta revisão mostra tudo o que foi desenvolvido durante o ciclo previsto, incluindo os planos para a próxima etapa a ser realizada.
O modelo em espiral é representado por um plano dividido em 4 quadrantes (figura
3), onde cada um deles contém uma fase cíclica do trabalho de desenvolvimento. Esse plano é percorrido por uma linha espiral, que nasce no centro do plano (momento zero do trabalho de desenvolvimento), e que tem prosseguimento caminhando do centro para as bordas, sempre passando pelas 4 fases cíclicas, de tal forma que um ciclo se repete após o outro, até que o trabalho seja dado como concluído. Define quatro atividades principais:
* Planejamento: é a determinação dos objetivos, alternativas e restrições do projeto.
* Análise dos Riscos: é a análise das alternativas e a resolução dos riscos.
* Execução: desenvolvimento do produto.
* Verificação feita pelo Cliente: é a avaliação dos resultados obtidos nas atividades da engenharia.
Analisando a figura 3, observa-se que a cada iteração ao redor da espiral, iniciando-se ao centro e avançando para fora, versões mais completas do sistema são construídas. Durante o primeiro giro ao redor da espiral são definidos os objetivos, alternativas e restrições. Também são identificados e analisados os riscos. Se a análise dos riscos detectar incertezas nos requisitos, deve-se fazer uso da prototipação no quadrante Execução, para auxiliar tanto o desenvolvedor como o usuário. Para definir ainda mais o problema e refinar os requisitos, o desenvolvedor pode utilizar simulações e outros modelos.
No quadrante de Verificação, o cliente avalia o trabalho de Execução e apresenta suas sugestões para modificações. A partir dessas sugestões ocorre a fase de Planejamento e Análise dos Riscos. A conclusão da Análise dos Riscos resulta em uma decisão de prosseguir ou não o projeto. Caso os riscos sejam muito grandes, o projeto pode até ser encerrado.
A medida que componentes são desenvolvidos:
– Os componentes são avaliados
– O desenvolvimento futuro é reavaliado
– Riscos são avaliados
– O ciclo termina com o produto pronto.
Resumo do CICLO DE VIDA INCREMENTAL
Protótipo
– Versão simplificada de um produto de software, geralmente criada sem um processo formal de desenvolvimento, utilizada para elucidar ou validar os requisitos do Produto.
Desenvolvimento incremental
– Diversas execuções do modelo clássico de ciclo de vida
– Ao fim de cada execução é gerado um produto executável
A Prototipação Incremental também conhecida como Entrega por Estágio adota como estratégia o desenvolvimento por estágios. Normalmente os requisitos mais importantes são implementados primeiro e os demais são acrescentados em novas versões. O desenvolvimento ocorre gradualmente e, ao final de cada estágio, uma versão operável é produzida e incrementada nos demais estágios até a sua conclusão final. A Prototipação Incremental pode oferecer diversas vantagens: redução de riscos, maior visibilidade sobre o processo, problemas podem ser descobertos logo no início, auxilia na estimativa de tempo do projeto entre outras. No entanto, o emprego desse modelo exige grande esforço na atualização da documentação do usuário. Além disso, o desenvolvimento por estágio requer que as dependências entre os estágios sejam bem planejadas, pois um dos problemas comuns é descobrir que o estágio 2 depende de componentes do estágio 4, por exemplo.
Tipos de incrementos:
– Evolutivos: produtos de cada etapa de desenvolvimento são aproveitados em cada nova passagem pela etapa.
– Descartáveis: produtos das etapas de desenvolvimento são descartados e cada novo protótipo é construído do início.
– Operacional: requisitos são elucidados através de protótipos e o produto final é construído paralelamente a construção dos protótipos.
QUALIDADE DE SOFTWARE
1. INTRODUÇÃO
Como foi mencionado no anteriormete, o papel da Engenharia de Software é,
principalmente, fornecer métodos e ferramentas para o desenvolvimento do software de qualidade e a baixo custo.
O fator qualidade é um dos aspectos importantes que deve ser levado em conta quando do desenvolvimento do software. Para isto, é necessário que se tenha uma definição precisa do que é um software de qualidade ou, pelo menos, quais são as propriedades que devem caracterizar um software desenvolvido segundo os princípios da Engenharia de Software.
Um outro aspecto importante é aquele relacionado à avaliação e ao aprimoramento do processo de desenvolvimento de software de uma organização. Nesta linha, foi desenvolvido pelo SEI (Software Engineering Institute) um modelo que permite efinir
parâmetros para a análise desta questão nas corporações, o modelo CMM (Capability and Maturity Model), cujas linhas gerais serão descritas na seção 5.
2. DEFINIÇÃO DE SOFTWARE DE QUALIDADE
Primeiramente, é importante discutir o conceito de software de qualidade. Segundo a
Associação Francesa de Normalização, AFNOR, a qualidade é definida como "a capacidade de um produto ou serviço de satisfazer às necessidades dos seus usuários".
Esta definição, de certa forma, é coerente com as metas da Engenharia de Software,
particularmente quando algumas definições são apresentadas. É o caso das definições de Verificação e Validação introduzidas por Boehm, que associa a estas definições as seguintes questões:
• Verificação: "Será que o produto foi construído corretamente?"
• Validação: "Será que este é o produto que o cliente solicitou?"
2.2. Fatores de Qualidade (Em desenvolvimento)
3. A METROLOGIA DA QUALIDADE DO SOFTWARE
Apresentados alguns fatores de qualidade de software, a dificuldade que se apresenta é como medir a qualidade do software. Ao contrário de outras disciplinas de engenharia, onde os produtos gerados apresentam características físicas como o peso, a altura, tensão de entrada, tolerância a erros, etc..., a medida da qualidade do software é algo relativamente novo e alguns dos critérios utilizados são questionáveis.
A possibilidade de estabelecer uma medida da qualidade é um aspecto importante para a garantia de um produto de software com algumas das características definidas anteriormente.
O Metrologia do Software corresponde ao conjunto de teorias e práticas relacionadas com as medidas, a qual permite estimar o desempenho e o custo do software, a comparação de projetos e a fixação dos critérios de qualidade a atingir.
As medidas de um software podem ser as mais variadas, a escolha da medida devendo obedecer a determinados critérios: a pertinência da medida (interpretabilidade); o
custo da medida (percentual reduzido do custo do software); utilidade possibilidade de comparação de medidas).
As medidas de um software podem ser organizadas segundo duas grandes categorias:
3.1. Medidas dinâmicas
São as medidas obtidas mediante a execução do software, como, por exemplo, os testes, as medidas de desempenho em velocidade e ocupação de memória, os traços, etc...
Estas medidas podem assumir um interesse relativamente grande pois elas permitem quantificar fatores que podem implicar em retorno econômico ou que representem informações sobre a correção do programa; por outro lado, estas medidas só podem ser obtidas num momento relativamente tardio do ciclo de desenvolvimento de um software, ou seja, a partir da etapa de testes.
3.2. Medidas estáticas
São aquelas obtidas a partir do documento fonte do software, sem a necessidade de
execução do software. Dentre as medidas estáticas, podemos destacar:
• as medidas de complexidade textual, a qual é baseada na computação do número
de operadores e do número de operandos contidos no texto do software;
• a complexidade estrutural, a qual se baseia na análise dos grafos de controle
associadas a cada componente do software;
• as medidas baseadas no texto, como o tamanho do programa, a taxa de linhas de
comentários, etc...
4 - (Em desenvolvimento)
5. O MODELO CMM
A causa mais comum do insucesso dos projetos de desenvolvimento de software é a má utilização ou a completa indiferença aos métodos e ferramentas orientados à concepção. É possível que, em empresas de desenvolvimento de software onde o uso de
metodologias consistentes não seja prática adotada, os projetos possam ter bons resultados. Mas, em geral, estes bons resultados são muito mais uma conseqüência de esforços individuais do que propriamente causadas pela existência de uma política e de uma infra-estrutura adequada à produção de software.
O modelo CMM — Capability Maturity Model — foi definido pelo SEI — Software Engineering Institute — com o objetivo de estabelecer conceitos relacionados aos níveis de maturidade das empresas de desenvolvimento de software, com respeito ao grau de evolução que estas se encontram nos seus processos de desenvolvimento.
O modelo estabelece também que providências as empresas podem tomar para aumentarem, gradualmente o seu grau de maturidade, melhorando, por conseqüência, sua produtividade e a qualidade do produto de software.
5.1. Níveis de maturidade no processo de desenvolvimento de software
O modelo CMM define cinco níveis de maturidade no que diz respeito ao processo de desenvolvimento de software adotado a nível das empresas, estabelecendo uma escala
ordinal que conduz as empresas ao longo de seu aperfeiçoamento.
Um nível de maturidade é um patamar de evolução de um processo de desenvolvimento de software, correspondendo a um degrau na evolução contínua de cada organização. A cada nível corresponde um conjunto de objetivos que, uma vez atingidos, estabilizam um componente fundamental do processo de desenvolvimento de software, tendo como conseqüência direta o aumento da capabilidade da empresa.
A figura (abaixo) apresenta os cinco níveis de maturidade propostos no modelo CMM, na qual se pode observar também o estabelecimento de um conjunto de ações que permitirão a uma empresa subir de um degrau para o outro nesta escala.
5.2.1. Nível Inicial
No nível inicial, o desenvolvimento de software é realizado de forma totalmente “ad
hoc”, sem uma definição de processos. No caso de problemas que venham a ocorrer durante a realização de um projeto, a organização tem uma tendência a abandonar totalmente os procedimentos planejados e passa a um processo de codificação e estes, onde o produto obtido pode apresentar um nível de qualidade suspeito.
A capabilidade de uma empresa caracterizada como nível 1 é totalmente imprevisível, uma vez que o processo de desenvolvimento de software é instável, sujeito a mudanças radicais freqüentes, não apenas de um projeto a outro, mas também durante a realização de um mesmo projeto.
Neste nível, estimação de custos, prazos e qualidade do produto é algo totalmente
fora do contexto e da política de desenvolvimento (que política?). Embora não se possa “assegurar” o fracasso de um projeto desenvolvido por uma empresa situada este nível, é possível dizer que o sucesso é, geralmente, resultado de esforços individuais, variando com as habilidades naturais, o conhecimento e as motivações dos profissionais envolvidos no projeto.
5.2.2. Nível Repetível
Neste nível, políticas de desenvolvimento de software e tarefas de suporte a estas políticas são estabelecidas, o planejamento de novos projetos sendo baseado na experiência obtida com projetos anteriores.
Para que uma empresa possa atingir este nível, é imprescindível institucionalizar o
gerenciamento efetivo dos seus projetos de software, de modo que o sucesso de projetos anteriores possam ser repetidos nos projetos em curso.
Neste nível, os requisitos do software e o trabalho a ser feito para satisfazê-los são planejados e supervisionados ao longo da realização do projeto. São definidos padrões de projeto, e a instituição deve garantir a sua efetiva implementação.
A capabilidade de uma empresa situada neste nível pode ser caracterizada como
disciplina, em razão dos esforços de gerenciamento e acompanhamento do projeto de
software.
5.2.3. Nível Definido (Em desenvolvimento)
5.2.4. Nível Gerenciado (Em desenvolvimento)
5.2.5. Nível Otimizado (Em desenvolvimento)
REVISÃO PARA PROVA
NOSSA SENHORA DE FÁTIMA
Atividade complementar – Engenharia de Software – 1º Semestre 2011
Nome do aluno:________________________________________________
Assinatura:____________________________________________________
Turma: TADS3 – 2º Sem 2011
Disciplina: Engenharia de Software
Data: 30 de Setembro de 2011.
1. Qual o papel da disciplina de Engenharia de Software no processo de
construção de software?
2. Comente, concordando ou discordando, as seguintes afirmações sobre engenharia de software:
a. Utiliza-se a engenharia de software para garantir software sem qualidade.
b. Não é interessante aplicar métodos de entrevistas e análise de documentos para construir o software.
c. O software, uma vez desenvolvido, deve sempre ser validado por outra empresa concorrente quanto a sua qualidade.
3. Qual a diferença entre processos Imaturos e Maduros?
4. Explique o modelo de qualidade CMMi.
5. O cliente XPTO tem um mercadinho humilde na periferia da cidade e contratou a empresa Pergentino.info para desenvolver um sistema de controle de vendas de seu mercadinho, que permite o cadastro de produtos, clientes e vendas. Apesar de ser um comércio humilde e ter apenas 1 computador para usar o sistema, o cliente gosta de resultados rápidos e quer logo o sistema para que ele possa controlar os “fiados” dos clientes. Diante deste cenário, qual o melhor ciclo de vida que a empresa pergentino.info deve adotar para desenvolver este software?
BOA PROVA TADS-3.
RESPOSTA DA ATIVIDADE COMPLEMENTAR
Observação: As respostas aqui postadas são de minha autoria, é necessário que cada aluno tente responder o questionário e juntos discutirmos no fórum do blog para melhor entedermos e garantir a resposta no que foi estudado.
1 - Garantir a qualidade do software, a conformidade às normas, e o planejamento e gerenciamento de custos e prazos.
2 -
a) Discordo. Utiliza-se a Engenharia de Software para garantir a qualidade do software através dos ciclos de vidas, normas e processos para que cada cliente, desenvolvedor (empresa) tenham satisfação do produto criado.
b) Discordo. Uma das etapas iniciais na construção do software através da engenharia de software está na análise de requisitos para todos os elementos do sistema na qual está incluso aplicar métodos de entrevistas e análise de documentos.
c) Discordo. O software uma vez desenvolvido terá sua qualidade garantida através de processos de qualidade analisados por empresas que fornecem certificações especificas para software.
3 - Processos Imaturos
* Não há maneira sitemática adotada pela empresa no desenvolvimento do software;
* Depende dos profissionais;
* Indisciplinado.
Processos Maduros
* Documentado, seguido e verificado;
* Apoio visível da gerência;
* Possibilidade de auditoria (Fidelidade ao processo);
* Responsabilidades definidas e claras;
* Expectativa de custos, funcionalidade e cronogramas, melhoria constante do processo.
4 - Uma das premissas do modelo é "A qualidade é influenciada pelo processo", e seu foco é "Melhorar processo de uma empresa".
É realizado através de níveis de maturidade.
* Inicial - (Ad-hoc) Imprevisível, mal controlado e reativo;
* Gerenciado - Projetos, reativo;
* Definido - Organizado e pró-ativo;
* Quantitativamente Gerenciado - Processos medidos e controlados;
* Otimização - Melhoria contínua do processo.
5 - Prototipação incremental, conhecida como Entrega por Estágio adota como estratégia o desenvolvimento por estágios. Normalmente os requisitos mais importantes são implementados primeiro e os demais são acrescentados em novas versões. O desenvolvimento ocorre gradualmente e, ao final de cada estágio, uma versão operável é produzida e incrementada nos demais estágios até a sua conclusão final.
GERENCIAMENTO DE PROJETOS DE SOFTWARE
BOA PROVA TADS-3.
RESPOSTA DA ATIVIDADE COMPLEMENTAR
Observação: As respostas aqui postadas são de minha autoria, é necessário que cada aluno tente responder o questionário e juntos discutirmos no fórum do blog para melhor entedermos e garantir a resposta no que foi estudado.
1 - Garantir a qualidade do software, a conformidade às normas, e o planejamento e gerenciamento de custos e prazos.
2 -
a) Discordo. Utiliza-se a Engenharia de Software para garantir a qualidade do software através dos ciclos de vidas, normas e processos para que cada cliente, desenvolvedor (empresa) tenham satisfação do produto criado.
b) Discordo. Uma das etapas iniciais na construção do software através da engenharia de software está na análise de requisitos para todos os elementos do sistema na qual está incluso aplicar métodos de entrevistas e análise de documentos.
c) Discordo. O software uma vez desenvolvido terá sua qualidade garantida através de processos de qualidade analisados por empresas que fornecem certificações especificas para software.
3 - Processos Imaturos
* Não há maneira sitemática adotada pela empresa no desenvolvimento do software;
* Depende dos profissionais;
* Indisciplinado.
Processos Maduros
* Documentado, seguido e verificado;
* Apoio visível da gerência;
* Possibilidade de auditoria (Fidelidade ao processo);
* Responsabilidades definidas e claras;
* Expectativa de custos, funcionalidade e cronogramas, melhoria constante do processo.
4 - Uma das premissas do modelo é "A qualidade é influenciada pelo processo", e seu foco é "Melhorar processo de uma empresa".
É realizado através de níveis de maturidade.
* Inicial - (Ad-hoc) Imprevisível, mal controlado e reativo;
* Gerenciado - Projetos, reativo;
* Definido - Organizado e pró-ativo;
* Quantitativamente Gerenciado - Processos medidos e controlados;
* Otimização - Melhoria contínua do processo.
5 - Prototipação incremental, conhecida como Entrega por Estágio adota como estratégia o desenvolvimento por estágios. Normalmente os requisitos mais importantes são implementados primeiro e os demais são acrescentados em novas versões. O desenvolvimento ocorre gradualmente e, ao final de cada estágio, uma versão operável é produzida e incrementada nos demais estágios até a sua conclusão final.
GERENCIAMENTO DE PROJETOS DE SOFTWARE
Quase todas as atividades que desempenhamos precisam ser planejadas e gerenciadas. Atividades de engenharia requerem um planejamento cuidadoso. Normalmente, os produtos são complexos, com muitas partes envolvidas, e as atividades são realizadas por um grupo muito grande de pessoas.
Planejamento
Planejar é estimar quais as atividades deverão ser realizadas; quem deverá realizá-las; quando devem ser realizadas e finalizadas; e quanto elas deverão custar. Tudo isto requer a elaboração de estimativas em relação ao número e à dimensão dos artefatos, do número de pessoas necessárias, dos prazos e dos custos.
Para isto, a atividade de planejamento deverá resultar:
- Na realização de estimativas
- Na elaboração da estrutura de divisão do trabalho (WBS – Work Breakdown Structure)
- Na definição da equipe e demais recursos
- Na alocação de pessoa-atividade
- Na elaboração do cronograma
- Na elaboração do orçamento
Além disso, a análise de riscos e as revisões periódicas do plano são fundamentais para garantir que ele seja cumprido.
Gerenciamento
Gerenciar é fazer cumprir o que foi planejado. O papel do gerente de projetos de software é coordenar a equipe, controlar a produção dos artefatos, fazer cumprir prazos e custos, analisar métricas de produção.
O gerenciamento de software está diretamente ligado à garantia da qualidade do processo e do produto de software. O uso de métricas de qualidade, tanto do produto como do processo, são fundamentais para o gerenciamento. Com base em métricas, o gerente tem condições de avaliar se o planejamento está sendo cumprido ou não. Neste caso, as métricas podem apontar as causas dos problemas e permitir as revisões no planejamento.
Exemplos de métricas do produto utilizadas no planejamento são: tamanho do software em linha de código fonte; número de pontos-de-função; número de diagramas de arquitetura; números de defeitos; entre outras.
Plano de Projeto de Software
O resultado de um plano de projeto de software é um documento contendo a equipe, o WBS, a alocação pessoa-tarefa, a análise de riscos, o cronograma, o orçamento entre outros.
A estrutura de um plano de projeto de software, segundo Ian Sommerville (2004) é a seguinte.
- Introdução
- Organização de projeto
- Análise de riscos
- Requisitos necessários de hardware e software
- Estrutura analítica de trabalho
- Cronograma de projeto
- Mecanismos de monitoramento e elaboração de relatórios
Esta estrutura pode variar de acordo com as características do projeto.
Diversos outros documentos podem complementar informações importantes:
- Plano de qualidade – descreve os procedimentos de testes de qualidade que serão utilizados.
- Plano de validação – descreve a abordagem, os recursos e o método utilizados pa validação.
- Plano de manutenção – prevê requisitos, custos e esforço necessário para a manutenção.
- Plano de desenvolvimento da equipe – descreve como as habilidades e a experiência serão desenvolvidas.
