engenharia de software gustavo semaan [email protected]
TRANSCRIPT
Projetos de Software
Processo de Desenvolvimento Define o modelo que será utilizado para o desenvolvimento do produto Estabelece um conjunto de atividades a serem desempenhadas, contendo:
Pré-Atividades Sub-Atividades Artefatos Consumidos Artefatos Produzidos Recursos Alocados Ferramentas Utilizadas Pós-Atividades
Desenvolvimento Orientado a Objetos Atividades
Levantamento dos requisitos Identificação de candidatos a classes/objetos Identificação das interações entre objetos e
classes Projeto Codificação Testes
Processos de Engenharia Requisitos O processo de engenharia de requisitos inclui:
Estudo de viabilidade: direcionado que se destina a responder as perguntas:
1. O sistema contribui para os objetivos gerais da organização?
2. O sistema pode ser implementado com a utilização de tecnologia atual dentro das restrições de custo e de prazo?
3. O sistema pode ser integrado com outros sistemas já em operação?
Processos de Engenharia Requisitos O processo inclui (cont):
Levantamento e análise de requisitos: membros da equipe técnica de desenvolvimento de software trabalham com o cliente e com os usuários finais para descobrir mais informações: Serviços que o sistema deve fornecer. Desempenho exigido do sistema. Restrições de hardware entre outros.
Para apoiar este trabalho, diversas técnicas podem ser empregadas.
Levantamento e análise de requisitos Geralmente um engenheiro de software
depara-se com importantes questões:1. Entre os muitos relatórios, formulários e
documentos gerados pelos membros de uma organização, quais deverão ser investigados?
2. Pode haver um grande número de pessoas afetadas pelo sistema de informação proposto. Quais delas devem ser entrevistadas, observadas ou questionadas?
3. Quem são os personagens principais? Stakeholders parte interessada ou interveniente
4. Podem existir diferentes pontos de vista. Quais serão importantes no desenvolvimento?
Levantamento e análise de requisitos Brainstorming Técnica básica para geração de idéias. Princípio básico:
Reunir um grupo de pessoas onde cada um possa inspirar ao outro a criação de idéias e contribuir para a resolução do problema.
As idéias sugeridas e exploradas não devem ser criticadas ou julgadas.
A técnica pode ser aplicada no início da fase do desenvolvimento quando pouco do projeto é conhecido e são necessárias novas idéias.
Podem existir uma ou mais reuniões.
Brainstorming
Levantamento e Análise de Requisitos Workshop de requisitos
É uma reunião estruturada onde stakeholders e analistas trabalham, em conjunto, para definir, criar e refinar requisitos.
São lideradas por um facilitador neutro que se prepara intensivamente.
A participação é intensa e variada e os participantes realizam atividades individuais ou em grupo.
Os participantes criam e verificam documentos como, por exemplo, diagramas de casos de uso.
São fortemente utilizados meios visuais tais como: slides, transparências, pôsters entre outros.
Levantamento e Análise de Requisitos Entrevista
Levantamento de informações sobre o sistema. Conversa direcionada, que utiliza o formato
“pergunta-resposta”. Objetivos
Obter as opiniões do entrevistado (descoberta dos problemas-chave a serem tratados).
Conhecer os sentimentos do entrevistado sobre o estado atual do sistema.
Obter metas organizacionais e pessoais.
Entrevista Pontos a serem observados
Construa, rapidamente, uma base de confiança e entendimento.
Mantenha o controle da entrevista. Venda a “idéia do sistema”, provendo ao
entrevistado as informações necessárias. Etapas
Estudar material existente sobre os entrevistados e suas organizações.
Estabelecer objetivos Preparar a entrevista: quem entrevistar, definir
tipos de questões, a estrutura e como registrar.
Entrevista Tipos de Questões
Subjetivas O que você acha de...? Explique como você...?
Objetivas Quantos...? Quais...? Quanto tempo...? Quem...? Qual das seguintes informações...?
Questões de aprofundamento Podem ser objetivas ou subjetivas: Por que? Você
poderia dar um exemplo?
EntrevistaEstruturas
Pirâmide (abordagem indutiva) Inicia com questões bastante detalhadas
(objetivas) e à medida que à medida que a entrevista progride, são colocadas questões gerais (subjetivas).
Funil (abordagem dedutiva) Inversa a estrutura de pirâmide.
Diamante Combinação das duas anteriores.
Não estruturada Não há definição da seqüência das questões.
Entrevista Como registrar:
Gravador, anotações, filmagem Como conduzir
Confirme o horário e o local um dia antes. Chegue um pouco antes do horário. Apresente-se e esboce brevemente os objetivos
da entrevista. A entrevista deve durar cerca de 45 minutos a
uma hora. Relembre o entrevistado de que você estará
registrando pontos importantes.
Entrevista Informe o que será realizado com as anotações
coletadas. Quando estiver incerto sobre uma questão, peça para o
entrevistado das definições, exemplos ou outros esclarecimentos.
Use questões de aprofundamento. Ao término, pergunte se há algo mais sobre o assunto
que o entrevistado ache importante. Faça um resumo da entrevista e dê suas impressões
globais. Informe o entrevistado sobre os passos seguintes. Pergunte se há outra pessoa com a qual você deveria
conversar. Quando for necessário, agende outra entrevista.
Entrevista O relatório da entrevista deve capturar a sua
essência. Escreva-o tão rápido quanto possível para
assegurar qualidade. Registre entrevistado, entrevistador, data,
assunto e objetivos. Informe se objetivos foram alcançados e aponte
objetivos para entrevistas futuras. Registre os pontos importantes da entrevista e
sua opinião. Remeta-o ao(s) entrevistado(s) para autenticar
as informações.
Levantamento e análise de requisitos Questionário
Técnica de levantamento de informações que permite ao engenheiro de software obter de várias pessoas afetadas pelo sistema informações, tais como: Posturas: o que as pessoas na organização dizem querer. Crenças: o que as pessoas pensam ser realmente
verdade. Comportamento: o que as pessoas fazem. Características: propriedades de pessoas ou coisas.
Etapas Planejamento Redação das questões
Questionário Tipos de questões: subjetivas e objetivas Linguagem utilizada
Use o vocabulário das pessoas que irão responder. Prime pela simplicidade. Evite redação tendenciosa. Construa, se possível, questões tecnicamente
precisas. Estilo
Deixe espaço suficiente para as respostas das questões subjetivas.
Em questões com escala, peça para fazer um círculo na resposta.
Questionário Estilo (cont.)
Use os objetivos do questionário para ajudar a determinar o formato (inclusive instruções).
Seja consistente no estilo. Coloque instruções sempre no mesmo local em relação ao layout do questionário.
Ordem das Questões Considere os objetivos. As primeiras questões devem ser de interesse dos
respondedores. Agrupe itens de conteúdo similar e observe
tendências de associação. Coloque os itens de menor controvérsia primeiro.
Questionário Métodos de Aplicação
Reunir todos os respondedores em um mesmo local. Entregar e recolher cada questionário
individualmente. Por correspondência (e-mail).
Como ocorre com a entrevista, o desenvolvedor deve elaborar um relatório contendo todas as informações conseguidas e enviar ao solicitante do sistema para a validação das informações.
Estudo de caso: Google Docs Forms ou www.surveymonkey.com
Levantamento e análise de requisitos Observação Direta
Processo e confirmação dos resultados de uma entrevista e/ou questionário.
Identificação de documentos que devem ser coletados para a análise posterior.
Esclarecimento do que está sendo realizado no ambiente atual e de que forma.
O analista observa sem intervir diretamente no processo, mas deve interagir com a pessoa que esta sendo observada.
Na medida do possível, o analista deve executar as atividades do usuário para entender como ele opera seu próprio ambiente.
Observação Direta Antes
Identificar as áreas de usuário a serem observadas. Obter aprovação das gerências apropriadas. Obter nomes e funções das pessoas-chave que serão
envolvidas no estudo da observação. Explicar para as pessoas observadas o que será feito e
por quê. Durante
Familiarizar-se com o local de trabalho que está sendo observado. Observar os agrupamentos organizacionais atuais. Observar as facilidades manuais e automatizadas em
uso.
Observação Direta
Durante (cont.) Coletar amostras de documentos e procedimentos
escritos. Informações estatísticas das tarefas: freqüência que
ocorrem, estimativas de volumes, tempo de duração etc.
Ser objetivo e não comentar as formas de trabalho de maneira não construtiva.
Observar as exceções que podem ocorrer e não são citadas por não serem operações normais de negócio.
Quando completar a observação, agradeça às pessoas pelo apoio.
Documente as descobertas. Consolide os resultados.Reveja os resultados consolidados com as pessoas observadas e/ou com superiores.
Levantamento e análise de requisitos Prototipagem
Feito em diversas fases do processo de engenharia de requisitos.
Trata-se de uma versão inicial do sistema, baseada em requisitos ainda pouco definidos, mas que pode ajudar a encontrar desde cedo falhas.
Neste tipo de abordagem são desenvolvidas algumas funcionalidades, dando ênfase àquelas que são mais fáceis de compreender por parte do usuário e que podem trazer melhores resultados (principalmente no desenvolvimento evolucionário).
O uso de protótipos deve ser considerado apenas mediante uma análise custo-benefício.
São úteis em situações onde a interface com os usuários é um aspecto crítico.
Processos de Engenharia RequisitosValidação de Requisitos
Nesta fase pretende-se demonstrar que o documento de requisitos produzido corresponde, de fato, ao sistema que o cliente pretende.
É especialmente importante em sistemas de grandes dimensões uma vez que erros encontrados demasiado tarde no documento de requisitos têm repercussões proporcionais à dimensão do projeto.
Principais técnicas: revisões de requistos (equipe de revisores), Prototipação (usuários finais e clientes)
Processos de Engenharia RequisitosValidação de Requisitos Devem ser verificados os seguintes atributos
dos requisitos Validade: a especificação resulta da análise dos
requisitos identificados junto das diversas partes interessadas envolvidas.
Consistência: não devem existir conflitos entre os requisitos identificados.
Compreensibilidade/Ambigüidade: os requisitos devem poder ser compreendidos de forma inequívoca pelas partes interessadas.
Completude: todas as funcionalidades retendidas devem fazer parte da especificação do sistema.
Processos de Engenharia RequisitosValidação de Requisitos Realismo: dadas as restrições do projeto
(tecnológicas, financeiras e temporais) o sistema especificado tem de ser implementável.
Verificabilidade: de forma a evitar futuras discordâncias quanto à concretização dos requisitos especificados.
Rastreabilidade: a origem dos requisitos, em relação ao cliente, deve estar claramente identificada.
Conformidade com normas: para além dos aspectos funcionais dos requisitos, a sua especificação deve obedecer às normas usadas ao longo de todo o documento.
Gerenciamento de requisitos As modificações organizacionais, técnicas e
de negócios inevitavelmente levam a mudanças nos requisitos.
O gerenciamento de requisitos é o processo de gerenciar e controlar essas mudanças.
Inclui: Planejamento do Gerenciamento: especificados os
procedimentos e as políticas para o gerenciamento de requisitos.
Gerenciamento de Mudanças: mudanças são analisadas e seu impacto é avaliado.
Análise de Requisitos Uma especificação de requisitos é importante
porque: Estabelece uma base de concordância entre o
cliente e o fornecedor sobre o que o software fará Fornece uma referência para a validação do
produto final Uma especificação de requisitos de alta qualidade
é um pré-requisito para um software de alta qualidade
Reduz o custo do desenvolvimento
Análise de Requisitos Podem ser:
Explícitos: descrito em documentos. Normativos: Apresentados em leis, regulamentos,
padrões. Implícitos: expectativa do cliente e usuário (não
documentada). Não desejáveis. Uma boa especificação e validação junto ao cliente
pode evitá-los.
Análise de Requisitos Instabilidade dos Requisitos
Mudanças na legislação. Novas funcionalidades. Alterações no ambiente (tecnológicos). Alto custo
Engenharia de Requisitos bem feita reduz a instabilidade
Análise de RequisitosUma condição ou capacidade necessária para um usuário resolver um problema ou alcançar um objetivo. Deve ser
alcançada ou estar presente em um sistema.
Requisitos Funcionais: descrevem uma interação entre o sistema e seu ambiente. Requisitos Não Funcionais: descrevem uma
restrição para o sistema que limita as possíveis escolhas de solução para o problema
Requisitos Não Técnicos: requisitos não relacionados ao software, como materiais para divulgação (eventos, publicações).Estão fora do escopo do documento de requisitos.
Requisitos Funcionais Declarações de funções que o sistema deve
fornecer, como o sistema deve reagir a entradas específicas e como o sistema deve se comportar em situações particulares.
Requisitos funcionais: do usuário podem ser declarações de alto nível
daquilo que o sistema deve fazer. do sistema devem descrever em detalhes as
funções do sistema. Requisitos ambíguos podem ser interpretados
de maneiras diferentes por desenvolvedores e usuários.
Requisitos Não-Funcionais Restrições nas funções oferecidas pelo sistema, tais como
confiabilidade, tempo de resposta e requisitos de armazenamento. Podem ser mais críticos que requisitos funcionais. Se eles não forem satisfeitos, o sistema pode ser inútil.
Requisitos Não-Funcionais
Especificação de Requisitos (Padrão IEEE 830) Estrutura do documento de requisitos
Requisitos Funcionais (Exemplos) O sistema deve permitir à secretaria cadastrar cursos,
contendo código, descrição, carga horária, professor coordenador, quantidade de períodos e tipo de curso (Graduação, Especialização, Mestrado e Doutorado).
O sistema deve permitir à secretaria cadastrar alunos contendo matrícula, nome, data de nascimento, curso, ano de início, semestre de início, email, telefone residencial, telefone comercial, telefone celular, fotografia, endereço completo (logradouro, número, complemento, bairro, cidade, UF, CEP), CPF, documento de identidade (número, órgão expedidor, UF e data expedição).
Requisitos Funcionais (Exemplos) O sistema deve permitir à secretaria cadastrar disciplinas,
contendo curso, código da disciplina, descrição, período, número de aulas, ementa e bibliografia, bem como seus pré-requisitos.
O sistema deve permitir à secretaria cadastrar turmas, contendo curso, disciplina, ano, semestre, descrição da turma, número máximo de alunos, horários e professor responsável.
O sistema deve permitir à secretaria cadastrar turmas, contendo curso, disciplina, ano, semestre, descrição da turma, número máximo de alunos, horários e professor responsável.
Requisitos Funcionais (Exemplos) O sistema deve permitir à secretaria cadastrar professores,
contendo matrícula, nome, data de nascimento, data de admissão, e-mail, telefone residencial, telefone comercial, telefone celular, fotografia, endereço completo (logradouro, número, complemento, bairro, cidade, UF, CEP), CPF, documento de identidade (número, órgão expedidor, UF e data expedição), titulação máxima (graduação, especialização, mestrado e doutorado), tipo de contrato (substituto, auxiliar, assistente ou adjunto), benefícios (vale transporte e/ou vale alimentação) e alocação
O sistema deve permitir à secretaria cadastrar disciplinas, contendo curso, código da disciplina, descrição, período, número de aulas, ementa e bibliografia, bem como seus pré-requisitos.
Requisitos Funcionais (Exemplos) O sistema deve permitir à secretaria matricular alunos em
turmas específicas.
O sistema deve permitir ao professor cadastrar avaliações e freqüência de alunos de uma turma específica.
O sistema deve calcular a aprovação de alunos, considerando 75% de freqüência mínima. Além disso, média menor do que 3 (três), implica em reprovação, média maior ou igual a 3 (três) e menor que 7 (sete) implica em prova final e média igual ou superior à 7 (sete) implica em aprovação. Para a prova final, a média desta nota com a média anterior menor que 5 (cinco) implica em reprovação, caso contrário, em aprovação.
Requisitos Funcionais (Exemplos) O sistema deve permitir ao professor a emissão da relação
de alunos por turmas, contendo descrição do curso, nome da disciplina, ano, semestre, turma, nome do professor, matrícula do aluno e nome do aluno.
O sistema deve permitir à secretaria a emissão da relação de disciplinas por curso, contendo nome do curso, nome das disciplinas, total de disciplinas por curso e total de todas as disciplinas.
O sistema deve permitir à secretaria a emissão do histórico escolar, contendo matrícula do aluno, nome do aluno, ano, semestre, nome das disciplinas, número de aulas, número de faltas e avaliações.
Requisitos Não Funcionais (Exemplos) O sistema deve possibilitar que todos os relatórios sejam
pré-visualizados antes do envio para a impressora.
O sistema deve apresentar o recurso de ajuda on-line sensível ao contexto.
O sistema deve processar matrículas em, no máximo, 5 segundos.
O sistema deve funcionar em Windows 2000 ou superior.
Ciclo de Vida A OO incentiva o desenvolvimento através de
um processo incremental e interativo, com refinamento crescente do software.
Essa abordagem é facilitada pela utilização de um modelo homogêneo para a representação das etapas de desenvolvimento do software.
Meta-Modelo: qualquer ciclo de vida pode ser utilizado na fase de desenvolvimento.
Ciclo de Vida A medida que componentes são
desenvolvidos. Os componentes são avaliados O desenvolvimento futuro é replanejado Riscos são avaliados O ciclo termina com o produto pronto
Análise Orientada à Objetos Análise Orientada à Objetos (OOA - Object
Oriented Analysis).
Em OO, um modelo é construído utilizando classes, e não objetos do mundo real (as instâncias). Etapas: Encontrar classes Identificar relacionamentos Definir atributos Definir métodos
Projeto Orientado à Objetos Projeto Orientado à Objetos(OOD - Object
Oriented Design)
O projeto OO utiliza as mesmas ferramentas da análise, resultando num gap semântico muito menor entre as fases de desenvolvimento de sistemas, possibilitando uma transição da análisepara o projeto mais eficiente.
Projeto Orientado à Objetos O projeto OO transforma as abstrações do
domínio em classes implementáveis, embora nem todas as classes venham do domínio. Basta acrescentar ao modelo de análise as classes que irão tratar da interação humana e de aspectos computacionais.
Os sistemas devem ser construídos em camadas, isolando os objetos de interface dos objetos de domínio, e estes da camada de acesso ao banco de dados.
Projeto Orientado à Objetos Etapas
Refine o modelo (verificar herança simples e múltipla, incluir classes para o sistema e para conjuntos de objetos, caso necessário).
Projete o gerente de dados (persistência). Projete o gerente de interface. Projete o(s) gerente(s) de tarefas (relatórios,
consultas, estatísticas, etc.)
Programação Orientada à Objetos Programação Orientada à Objetos (OOP - Object
Oriented Programming).
Deixar a OO limitada à programação será extremamente limitante e de poucos ganhos quanto à produtividade. É importante “pensar” em objetos desde a análise
Principais Linguagens: Puras: forçam o uso do paradigma OO: Smalltalk, Java,
Eiffel Híbridas: permitem a utilização de diferentes
paradigmas: C++, Object Pascal, OOCobol.
Referências Notas de aula / compilação da profa. Myrna Amorim e do
prof. Leonardo Murta
SOMMERVILLE, Ian. Engenharia de Software. 8a Edição. Ed. Pearson Education/Addison Wesley, 2007.
PRESSMAN, R. S. Engenharia de Software. 5a Edição. Editora McGraw Hill, 2002.
REZENDE, D. A. Engenharia de Software e Sistemas de Informação. 3a Edição. Editora Brasport, 2005.