Engenharia de Software

Apresentação em tema: "Engenharia de Software"— Transcrição da apresentação:

1 Engenharia de Software
Gustavo Semaan

2 Projetos de Software

3 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

4 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

5 Processos de Engenharia Requisitos
O processo de engenharia de requisitos inclui: Estudo de viabilidade: direcionado que se destina a responder as perguntas: O sistema contribui para os objetivos gerais da organização? O sistema pode ser implementado com a utilização de tecnologia atual dentro das restrições de custo e de prazo? O sistema pode ser integrado com outros sistemas já em operação?

6 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.

7 Levantamento e análise de requisitos
Geralmente um engenheiro de software depara-se com importantes questões: Entre os muitos relatórios, formulários e documentos gerados pelos membros de uma organização, quais deverão ser investigados? Pode haver um grande número de pessoas afetadas pelo sistema de informação proposto. Quais delas devem ser entrevistadas, observadas ou questionadas? Quem são os personagens principais? Stakeholders parte interessada ou interveniente Podem existir diferentes pontos de vista. Quais serão importantes no desenvolvimento?

8 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.

9 Brainstorming

10 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.

11 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.

12 Entrevista Pontos a serem observados Etapas
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.

13 Entrevista Tipos de Questões Subjetivas Objetivas
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?

14 Entrevista Estruturas 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.

15 Entrevista Como registrar: Como conduzir Gravador, anotações, filmagem
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.

16 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.

17 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.

18 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

19 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.

20 Questionário Estilo (cont.) Ordem das Questões
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.

21 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 ( ). 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

22 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.

23 Observação Direta Antes Durante
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.

24 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.

25 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.

26 Processos de Engenharia Requisitos
Validaçã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)

27 Processos de Engenharia Requisitos
Validaçã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.

28 Processos de Engenharia Requisitos
Validaçã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.

29 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.

30 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

31 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.

32 Engenharia de Requisitos bem feita reduz a instabilidade
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

33 Análise de Requisitos Requisitos Funcionais: descrevem uma
Uma 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.

34 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.

35 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.

36 Requisitos Não-Funcionais

37 Especificação de Requisitos (Padrão IEEE 830)
Estrutura do documento de requisitos

38 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, , 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).

39 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.

40 Requisitos Funcionais (Exemplos)
O sistema deve permitir à secretaria cadastrar professores, contendo matrícula, nome, data de nascimento, data de admissão, , 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.

41 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.

42 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.

43 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.

44 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.

45 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

46 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

47 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.

48 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.

49 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.)

50 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.

51 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, REZENDE, D. A. Engenharia de Software e Sistemas de Informação. 3a Edição. Editora Brasport, 2005.