Princípios de Engenharia de Software. Garantia de Qualidade:

Princípios de Engenharia de Software.
Resumo da semana 4.
Grupo: MagicLAMP
Responsável: Guilherme Martins
Secretário: Bernardo Vinhosa
Tópicos Envolvidos
- Garantia de Qualidade
- Gerência
Atenção: formato está fora do padrão (cabeçalho e rodapé)
Garantia de Qualidade:
A preocupação com qualidade na industria, começou por volta dos anos 80. Foi um
movimento que teve inicio no Japão e logo chegou nos EUA refletindo em vários ramos da
industria. Algumas empresas investiam grande parte de seus recursos na qualidade de seus
produtos. Um exemplo claro foi a Ford que crio o “slogan” “Quality is Job number one”,
que demonstra o como estas empresas se preocupam com a qualidade.
A garantia de qualidade na Engenharia de Software está diretamente ligada com
atender os requisitos funcionais e não-funcionais envolvidos no sistema. Esta ligação define
o nível de confiabilidade do software.
Nos dias de hoje, as formas mais utilizadas para garantir a qualidade do software é
fazendo testes e verificações no sistema em questão. Estes testes e verificações são gerados
pelos próprios requisitos, sendo assim, sendo implementados e verificados corretamente,
validam os requisitos e sua implementação. Os Testes são feitos executando determinada
funcionalidade passando uma certa massa de dados e avaliando o comportamento do
software. Isto que dizer que para executar testes, o módulo em questão já deve ter alguma
implementação apresentando um determinado comportamento. Já a verificação do software
pode (e em geral é feita) ser feita sem necessariamente ter uma implementação. Algumas
verificações se baseiam nas definições dos requisitos avaliando redundâncias nas mesmas e
podem ser testadas através de provas lógicas ou matemáticas. Outra forma de verificação é
instrumentação de código por meio de assertivas estruturais e até a própria verificação
gramatical das linguagens utilizadas para especificar e implementar o software, exemplo
Diagrama de Classe , Java , DFD, DER, ... . Em resumo, os testes estão mais ligados a
coerência e a verificação a consistência dos dados.
Pc elaborado. Foram dados exemplos em sala onde fica claro, pelo menos outros grupos
assim entenderam, a diferença entre verificação e validação.
PDCA – Plan -> Do -> Check -> Act
PERGUNTAS AO PROF.
“ O PDCA é um sistema de gerência de Qualidade?” Pode ser entendido assim. Na
verdade o PDCA é um esquema genérico que enfatiza a necessidade de se assegurar que o
Deleted: ontrol
que foi desejado (plano) esta sendo realizado (controle sobre a execução). Não existe
qualidade em processo que não empregam esse sistema de feedback.
“O PDCA não foi algo tão simples de se definir .Para nós até o paralelo feito com a
Prototipagem não ficou muito claro no momento de descrever o assunto. Assim então
gostaríamos de conversarmos com o Sr. Para desenvolver melhor o tema e fazer o paralelo
com o modelo de desenvolvimento em espiral e o em cascata.”
OK, sem problemas. Podem me procurar na sala 514 do RDC. Ramal 4307.
“Esperamos poder ter a chance de depois de nos esclarecer as dúvidas, inserimos o
assunto no resumo de forma a ele ser apreciado pelo prof novamente.”
“A diference entre testes e verificações ficou clara mas esta parte de PDCA que não
encaixou muito no assunto.”
Gerência
TAREFAS INERENTES À GERÊNCIA DE S.D.S (não só! Esse modelo (4 tarefas de
gerência) é um modelo básico derivado dos princípios básicos de administração)
Organizar: Consiste em atribuir papéis e funções a cada um dos membros da equipe de
desenvolvimento (arquitetos, programadores, peritos técnicos) e em tomar as decisões de
infra-estrutura relativas ao projeto: plataformas de hardware e software e espaço físico onde
haverá o desenvolvimento. A organização é uma tarefa com um alcance de longo prazo.
Planejar: consiste em prever as tarefas necessárias ao desenvolvimento do sistema e
também identificar os produtos gerados ao longo desse processo (documentação, base de
dados, etc). Existe uma ferramenta freqüentemente utilizada na gerência de projetos
chamada PERT / CPM que será abordada em breve.
Deleted: gerenciar
Deleted: gerenciar
Coordenar: consiste em ajudar, motivar e liderar a equipe, como o objetivo de fazer com
que a equipe siga o plano com os recursos disponíveis
Controlar: Certificar-se que o planejado (plano) está sendo seguido. Caso desvios sejam
identificados eles serão um feedback para que os responsáveis pela coordenação (gerentes)
tomem as providências necessárias. Eventualmente desvios podem ocorrer em função da
não adequação do plano a realidade, nesse caso, então, faz necessário um re-planejamento.
PERT / CPM (FERRAMENTA DE GERÊNCIA DE PROJETOS)
A sigla PERT significa Project Evaluation Review Technique, enquanto CPM quer dizer
Critical Path Method. As duas técnicas foram desenvolvidas em paralelo (o PERT no meio
militar, e o CPM na iniciativa privada) na metade do século 20 nos EUA. Essas
ferramentas, que inicialmente tinham algumas pequenas diferenças entre si, depois se
fundiram numa só a ponto de podermos usar qualquer uma das duas siglas
indiscriminadamente.
Deleted: re-planejar,
eventualmente alterar a
organização do projeto devido ao
não cumprimento de metas
intermediárias ou à iminência desta
situação.¶
¶
A ferramenta PERT/CPM consiste em modelar o projeto como um diagrama de rede, muito
parecido com um grafo. Os nós deste grafo seriam eventos/marcos do projeto e os vértices
representam tarefas, com uma duração associada (justamente por ser um caminho entre
etapas). Tarefas que podem ser feitas em paralelo (ou seja, não dependem de recursos
comuns) são chamadas de tarefas paralelas ou concorrentes. Tarefas que utilizam recursos
em comum, ou seja, não podem ser executadas ao mesmo tempo são chamadas de seriais
ou dependentes. A dependência entre eventos determina o caminho crítico, que é definido
como o caminho mais longo entre o “marco inicial” e o “marco final”, comprimento esse
dado pela soma das durações (e não a quantidade) das tarefas. As tarefas que estão no
caminho crítico são, conseqüentemente, aquelas cujo atraso atrasaria o fim do projeto, por
isso, são priorizadas na alocação de recurso deste.
Deleted: <sp>
Fig 1. Exemplo de fluxograma PERT tirado de
http://whatis.techtarget.com/definition/0,289893,sid9_gci331391,0
OK. Bom trabalho de pesquisa. Veja que o PERT vai caracterizar o plano. A medida que
o projeto é executado eu tenho que controlar para ter certeza que as tarefas estão sendo
cumpridas e que os prazos (duração) estão de acordo com o que se previu inicialmente.
Portanto um PERT é importante tanto para Planejar como para Controlar.