Resumo - Seminários integrados em SI - aula 10

Prévia do material em texto

SEMINÁRIOS INTEGRADOS EM SISTEMA DE INFORMAÇÃO 
Aula 10
Processos de desenvolvimento 
O processo de desenvolvimento de software (PDS) pode ser definido como um conjunto de
atividades coerentes e ordenadas com o objetivo de se produzir ou melhorar um software com
qualidade. Esse processo também é conhecido como ciclo de vida, em que as atividades são
agrupadas em fases, as quais orientam o desenvolvimento do produto de software. A importância de
adoção de um PDS encontra-se no fato da organização da criação do referido produto, a qual
permite o acompanhamento, em todas as fases, do estado de desenvolvimento, fornecendo subsídios
para o controle de custos e de prazos.
O Ciclo de Vida do Desenvolvimento de Sistemas
É uma descrição abstrata do processo de desenvolvimento que mostra as principais
atividades e dados usados na produção e manutenção de software, bem como a ordem em que as
atividades devem ser executadas. As atividades presentes no ciclo de vida de software não são um
padrão; elas dependem da metodologia utilizada no desenvolvimento de um projeto de software.
Tomemos como exemplo o modelo clássico apresentado por Roger S. Pressman:
Qual o melhor modelo de ciclo de vida?
O melhor modelo a ser adotado em um PDS depende, geralmente, de dois aspectos: a natureza da
organização (empresa); e a natureza do projeto.
*Modelo em cascata = Esse modelo também tende a funcionar bem em organizações com uma
estrutura hierárquica bem definida.
* Modelo de prototipagem = Este modelo, se combinado com o modelo em espiral, pode ser usado
em subprojetos em um desenvolvimento em espiral.
* Conclusão
Segundo Pressman (2007): Não há necessidade de se ser dogmático em relação à escolha de
paradigmas para a engenharia de software. A natureza da aplicação deve ditar a abordagem a ser
tomada. Ao combinarmos abordagens, o todo pode ser maior do que a soma das partes.
 
Repare que, nessa citação, os modelos de ciclo de vida são referenciados como paradigmas.
RUP (rational unified process)
O RUP é um processo unificado para desenvolvimento de software, criado e comercializado pela
empresa pela Rational Software Corporation.
 
O processo contém um conjunto de atividades a serem realizadas para produzir ou evoluir
softwares, tendo como principais características: orientado a objetos, guiado por casos de uso,
centrado na arquitetura, e desenvolvimento iterativo e incremental.
Ciclo de vida
São repetidos vários ciclos até sua finalização, onde cada ciclo gera um produto liberado para uso.
Cada ciclo possui quatro fases. 
Estrutura:
Apresenta quatro fases e nove disciplinas.
Suas fases são: concepção, elaboração, construção e transição.
1) Fase – Concepção
 
É estabelecido o business case (caso de negócio) para:
• Delimitar o escopo do projeto;
• Formular a arquitetura candidata.
• Identificar critérios de sucesso (justificativa);
• Identificar e eliminar riscos;
• Planejamento (estimando recursos, cronograma, custos, retorno esperado);
• Criação de um protótipo executável, onde este serve como teste para a concepção;
• Decisão de prosseguir ou não.
2) Fase – Elaboração
 
• Análise do domínio do problema;
• Estabelecimento de uma arquitetura sólida, baseada na compreensão de todo o sistema. Assim, é
aconselhável executar os use cases mais significativos (críticos) como forma de verificar a
arquitetura;
• Desenvolvimento do plano de projeto;
• Eliminação dos elementos de maior risco do projeto;
• Verificação do escopo e os objetivos detalhados do sistema, a escolha de arquitetura e a solução
para os principais riscos, além de decisão de prosseguir ou não.
3) Fase – Construção
 
• Desenvolvimento de forma interativa e incremental, um produto completo, pronto para a
apresentação de seus usuários;
• Este protótipo implica numa descrição dos requisitos restantes e de critérios de aceitação;
• Identificar, se o software, ambientes e usuários estão todos prontos para se tornarem operacionais.
4) Fase – Transição
É considerada versão beta, para depois ser substituída pelo sistema de produção;
Verifica se os objetivos foram alcançados;
Verifica se inicia um novo ciclo de vida;
Equaciona as lições aprendidas para o aproveitamento no próximo projeto.
 
Torna o software disponível para a comunidade de usuários, onde acarretam em implementações
adicionais com a finalidade de:
 
• Ajustar o sistema;
• Corrigir alguns problemas identificados;
• Concluir algumas características propostas.
Metodologias ágeis (agile software development ecosystems – ASDEs)
Manifesto ágil (princípios)
Extreme Programming (XP) é um processo de desenvolvimento que possibilita a criação de
software de alta qualidade, de maneira ágil, econômica e flexível. Vem sendo adotado com enorme
sucesso na Europa, nos Estados Unidos e, mais recentemente, no Brasil. Cada vez mais as empresas
convivem com ambientes de negócios que requerem mudanças frequentes em seus processos, as
quais afetam os projetos de software.
Os processos de desenvolvimento tradicionais são caracterizados por uma grande quantidade de
atividades e artefatos que buscam proteger o software contra mudanças. Isto faz pouco ou nenhum
sentido, visto que os projetos devem se adaptar a tais mudanças, em vez de evitá-las.
 
O XP concentra os esforços da equipe de desenvolvimento em atividades que geram resultados
rapidamente na forma de software intensamente testado e alinhado às necessidades de seus usuários.
Além disso, simplifica e organiza o trabalho, combinando técnicas comprovadamente eficazes e
eliminando atividades redundantes. Por fim, reduz o risco dos projetos desenvolvendo softwares de
forma iterativa e reavaliando permanentemente as prioridades dos usuários.
Características dos processos ágeis
Adaptabilidade X previsibilidade
 
• A Engenharia de Software e as demais Engenharias;
• A diferença entre as fases de projeto e construção;
• Negócios atuais: mudança constante de requisitos;
• Adaptabilidade exige um ciclo iterativo;
• Adaptabilidade exige participação extrema do cliente.
Padrões de projeto
Conhecido pelo termo original em inglês, design pattern, descreve uma solução geral reutilizável
para um problema recorrente no desenvolvimento de sistemas de software orientados a objetos.
 
Não é considerado um código final, é uma descrição ou modelo de como resolver o problema do
qual trata, que pode ser usada em muitas situações diferentes.
 
Os padrões de projeto normalmente definem as relações e interações entre as classes ou objetos,
sem especificar os detalhes das classes ou objetos envolvidos, ou seja, estão num nível de
generalidade mais alto.
Principais aplicações de padrões de projeto
Toolkits - Conjunto de classes relacionadas e reutilizáveis, projetadas para oferecer funcionalidades
úteis e de finalidade geral.
 
Exemplo: classes coleções para manipular listas, conjuntos e pilhas. Os toolkits não impõem um
projeto específico; eles simplesmente fornecem funcionalidades para auxiliar aplicações.
Framework - É um conjunto de classes que cooperam para a construção de um software de uma
determinada categoria. Ex. Construção de compiladores, site de venda etc.
Nesse caso, a customização se dá através da criação de classes específicas para a aplicação,
derivadas de classes abstratas do framework. Neste caso, o framework dita a arquitetura da
aplicação.
Um framework enfatiza a reutilização do projeto em relação à reutilização do código. Quando se
utiliza um framework, você reutiliza o corpo principal e escreve o código que este chama.
Dessa forma, podem-se escrever aplicações mais rapidamente e com estruturas similares. Por outro
lado, fica-se preso às decisões de projeto já tomadas pelo framework.Padrões GoF
Os padrões "GoF" são organizados em três famílias:
Padrões GRASP
Os padrões GRASP, sigla para general responsibility assignment software patterns (ou principles),
consistem de um conjunto de práticas para atribuição de responsabilidades a classes e objetos em
projetos orientados a objeto.
 
Os padrões utilizados pelo GRASP são:
• Controlador (Controller);
• Criador (Creator);
• Indireção (Indirection);
• Especialista na informação (Information expert);
• Alta coesão (High Cohesion);
• Baixo acoplamento (Loose coupling);
• Polimorfismo (Polymorphism);
• Variações protegidas (Protected variations);
• Invenção pura (Pure fabrication).
Todos esses padrões servem para a resolução de problemas comuns e bastante típicos de
desenvolvimento de software orientado a objeto. 
Portanto, tais técnicas apenas documentam e normatizam as práticas já consolidadas, testadas e
conhecidas no mercado.
 
Os padrões GRASP estão mais como uma ferramenta mental ou uma filosofia de design, mas que
ainda assim são úteis para o aprendizado e desenvolvimento de um bom design de software.
Aspectos de qualidade de software / métricas de desenvolvimento
Em desenvolvimento de sistemas, uma preocupação constante é utilizar métodos e ferramentas que
minimizem erros e tragam maior qualidade ao produto tanto no aspecto estrutural quanto no
atendimento ao cliente.
 
Aspectos de manutenibilidade, construção, uso de metodologias são tão importantes quanto a
usabilidade, acessibilidade e operabilidade.
Atualmente, a busca pela qualidade vem desenvolvendo um processo de validação constante em
todas as etapas do desenvolvimento. Por isso, deve-se atentar para os conceitos, princípios e
práticas necessárias para que se tenha o melhor resultado.
 
Para reconhecer a qualidade, é preciso usar parâmetros que tragam de alguma forma medidas para
análise. Para isto, são propostas métricas que podem ser aplicadas em várias partes do
desenvolvimento para identificar focos de desvios de padrão ou sinais de melhorias.
Com o crescimento de produção de software, tornou-se necessária a criação de processos que
pudessem aferir o nível de qualidade que o software oferece. A esses processos, denomina-se
“Processos de Certificação”, que tem como objetivo avaliar o software desde o processo de
desenvolvimento, passando por construção dos programas até aspectos de usabilidade,
acessibilidade, operabilidade, manutenibilidade e segurança. Os processos de certificação de
alguma forma oferecem uma garantia em relação à eficiência do software certificado.
* A certificação atualmente não é uma opção para as empresas, mas parte de uma estratégia de
sobrevivência em um mercado cada vez mais exigente e competitivo.
 
O que é qualidade de software?
Disciplina da Engenharia de Software aplicada para definir padrões e aferir seu cumprimento, com
o objetivo de garantir a satisfação dos usuários. A qualidade está relacionada tanto a processos
quanto a produtos.
 
Por processo, entende-se o conjunto de atividades realizadas para desenvolvimento e produto
representa a definição implementada e finalizada.
ISO (International Organization for Standardization) e SEI (Software Engineering Institute)
são os órgãos responsáveis por criar modelos de certificação para diferentes áreas da organização.
 
Definem alguns modelos que devem ser seguidos no processo de certificação: ISO 9000, SPICE,
ISO 12207, ISO 15504, ISO 9126, CMM e CMMI.
 
A certificação é conduzida por empresas autorizadas a atestarem a qualidade do produto/ serviço e
até conhecimento dos profissionais, gerando confiabilidade no mercado.
Nos dias atuais, não é uma opção para as empresas, mas parte de uma estratégia de sobrevivência
em um mercado cada vez mais exigente e competitivo.
 
Deve-se avaliar tanto os processos desenvolvidos pela empresa quanto os pacotes adquiridos em
função da necessidade de saber se os requisitos do negócio estão sendo atendidos.
Testes de software
A necessidade de se obter qualidade fez com que os testes de software tornassem essenciais no
processo de desenvolvimento de software.
 
Com isso, foram definidos modelos de maturidade de processo de teste para dar suporte às
organizações na melhoria do processo de testes e, também com o intuito de dar confiabilidade ao
processo.
Existem outros modelos, como: TPI - Teste Process Improvement e TCMM - Test Capability
Maturity Model.
 
Possui as seguintes premissas:
• É um modelo complementar ao CMM com o qual mantém compatibilidade;
• É uma linha para a melhoria contínua do processo de testes;
• É baseado na avaliação da situação atual do processo de testes através de regras claras e objetivas.
Medição e métricas
A medição de um software consiste na apuração de um valor numérico que será comparado a
padrões definidos para verificar a qualidade.
 
A aplicação das métricas ainda não é muito utilizada, em função da falta de padrão e organização
adotados pelas empresas, além do alto custo para implantação.
 
A métrica de software se refere ao tamanho do produto (linhas de código), grau de facilidade, nº de
defeitos e/ou nº de pessoas/dia requerido para desenvolvimento do software.
As métricas podem ser de controle ou preditivas. As métricas de controle estão associadas a
processo de software, como: tempo gasto para manutenção.
 
As métricas preditivas estão associadas ao produto de software, como: complexidade ciclomática e
comprimento médio de indicadores.
As métricas preditivas e controle podem influenciar nas decisões de projeto, conforme apresentado
no fluxo:
A medida do atributo interno deve ser uma previsão útil da característica externa do software e
devem prevalecer três condições (Kitchenham, 1990).
 
• Atributo interno deve ser medido precisamente;
• Deve existir uma relação entre o que podemos medir e o atributo de comportamento externo;
• A relação pode ser expressa em uma fórmula ou modelo.
 
A figura representa a relação entre os atributos internos e os atributos externos:
As medições podem ser de dois tipos: dinâmicas e estáticas. As dinâmicas os valores são extraídos
em tempo de execução e, as estáticas são extraídas a partir da representação do software.
 
Alguns exemplos de métricas:
* Os caminhos independentes correspondem às estruturas internas do código, criadas para atender
as regras condicionais. 
Portanto, aplica-se no processo de qualidade, e também na disciplina teste de software.
O cálculo é desenvolvido a partir da definição do número de nós, arestas, nós predicativos e região,
analisada na formação da lógica em grafos, considerando os fluxos sequenciais, condicionais e
repetição:
* Um vértice representa um nó, que representa a atividade do processo. A aresta é o caminho de um
nó para o outro.
 
Os nós que possuem uma condição embutida são denominados nós predicativos, o que acontece nos
fluxos: condicional e repetição. 
Quando se trata dos fluxos condicional e repetição, os nós delimitam uma área fechada formando
uma região. O grafo completo também forma uma região.
* Para cálculo da complexidade ciclomática, conta-se o número de regiões, o número de nós, o
número de nós predicativos e o número de arestas. Em seguida, determina-se a complexidade.
* Fórmula para cálculo da complexidade ciclomática:
Complexidade ciclomática = 
Nº de Regiões =
(Qtde. Nós Predicativos + 1) =
(Nº de Arestas – Nº de Nós + 2)
Os valores devem ser iguais. Caso contrário, algum erro ocorreu!
A figura abaixo apresenta os elementos do grafo:
Caminhos independentes
São definidos pelo valor computado pela complexidade ciclomática e oferece-nos um limite
máximo para o número de testes a realizar.
Segue um roteiro para definir acomplexidade ciclomática:
1. Desenhe o fluxograma ou escreva o Português estruturado da lógica do programa;
2. Elabore o grafo;
3. Conte as regiões;
4. Conte o número de arestas;
5. Conte o número de nós;
6. Calcule o nº de nós preditivos ( não são consideradas definições de variáveis, início e fim de
algoritmo);
7. Calcule a complexidade ciclomática;
8. Indique os caminhos independentes.