Engenharia de Software I

Transcrição

1 Engenharia de Software I Prof. André Castro Garcia Aula2

2 1.4 Mitos do Software Muitos de nossos problemas com software podem remeter-se a uma mitologia que surgiu nos primórdios de seu desenvolvimento. Hoje, a maioria dos profissionais experientes reconhece os mitos por aquilo que eles são, atitudes enganosas que têm causado sérios problemas tanto a gerentes como ao pessoal técnico.

3 Mitos Administrativos Os gerentes frequentemente se encontram sob pressão para manterem orçamentos, evitarem que os prazos saiam do controle e melhorarem a qualidade. Mito: Já temos um manual repleto de padrões e procedimentos para a construção do software. Isso não oferecerá ao meu pessoal tudo o que eles precisam saber? Realidade: O manual de padrões pode muito bem existir, mas será que ele é usado? Os profissionais de software têm conhecimento de sua existência? Ele reflete a moderna prática de desenvolvimento de software? É completo?

4 Mitos Administrativos Mito: Meu pessoal tem ferramentas de desenvolvimento de software de última geração; afinal de contas lhe compramos os mais novos computadores. Realidade: É preciso muito mais do que o último modelo de mainframe, estação de trabalho ou PC para se fazer um desenvolvimento de software de alta qualidade. As ferramentas de engenharia de software auxiliada por computador são mais importantes do que o hardware para se conseguir boa qualidade e produtividade; contudo, a maioria dos desenvolvedores de software não as usa ainda.

5 Mitos do Cliente Os mitos levam a falsas expectativas (por parte do cliente) e, em última análise, à insatisfação com o desenvolvedor. Mito: Uma declaração geral dos objetivos é suficiente para se começar a escrever programas podemos preencher os detalhes mais tarde. Realidade: Uma definição inicial ruim é a principal causa de fracasso dos esforços de desenvolvimento de software. Uma descrição formal e detalhada do domínio da informação, função, desempenho, interfaces, restrições de projetos e critérios de validação é fundamental. Essas características pode ser determinadas somente depois de cuidados comunicação entre o cliente e o desenvolvedor.

6 Mitos do Cliente Mito: Os requisitos de projeto modificam-se continuamente, mas as mudanças podem ser facilmente acomodadas, porque o software é flexível. Realidade: É verdade que os requisitos de software se modificam, mas o impacto da mudança varia de acordo com o tempo em que ela é introduzida. O cliente pode rever as exigência e recomendar modificações sem causar grande impacto sobre os custos. A mudança pode causar sublevações que exijam recursos adicionais e grandes modificações de projeto, isto é, custo adicional.

7 Mitos do Profissional Velhas maneiras e atitudes dificilmente morrem. Mito: Assim que escrevermos o programa e o colocarmos em funcionamento nosso trabalho estará completo. Realidade: Os dados da indústria indicam que entre 50 e 70% de todo o esforço gasto num programa serão despendidos depois que ele for entregue pela primeira vez ao cliente. Mito: Enquanto não tiver o programa funcionando, eu não terei realmente nenhuma maneira de avaliar sua qualidade. Realidade: Um dos mecanismos mais efetivos de garantia da qualidade de software pode ser aplicado desde o começo de um projeto, a revisão técnica formal.

8 1.5 Paradigmas da Engenharia de Software A aflição que contaminou o desenvolvimento do software não desaparecerá da noite para o dia. Reconhecer os problemas e suas causas e desmascarar os mitos do software são os primeiros passos em direção às soluções. Combinar métodos abrangentes para todas as fases de desenvolvimento do software, melhores ferramentas para automatizar esses métodos, blocos de construção mais poderosos para a implementação do software, melhores técnicas para a garantia da qualidade do software e uma filosofia de coordenação predominante, controle e administração, podemos conseguir uma disciplina para o desenvolvimento de software disciplina esta chamada Engenharia de Software.

9 1.5.1 Engenharia de Software: Uma Definição O estabelecimento e uso de sólidos princípios de engenharia para que se possa obter economicamente um software que seja confiável e que funcione eficientemente em máquinas reais. Fritz Bauer A engenharia de software abrange um conjunto de três elementos fundamentais, métodos, ferramentas e procedimentos.

10 Métodos Proporcionam os detalhes de como fazer para construir o software. Os métodos envolvem um amplo conjunto de tarefas que incluem: planejamento e estimativa do projeto, análise de requisitos de software e de sistemas, projetos da estrutura de dados, arquitetura de programas e algoritmos de processamento, codificação teste e manutenção.

11 Ferramentas Proporcionam apoio automatizado ou semi-automatizado aos métodos. Atualmente, existem ferramentas para sustentar cada um dos métodos anotados anteriormente. Um sistema de suporte ao desenvolvimento de software é chamado engenharia de software auxiliada por computador(case Computer Aided Software Engineering). O CASE combina software, hardware e um banco de dados de engenharia de software para criar um ambiente de engenharia de software.

12 Procedimentos Constituem o elo de ligação que mantém juntos os métodos e as ferramentas e possibilita o desenvolvimento racional e oportuno do software de computador. Os procedimento definem a sequencia em que os métodos serão aplicados, os produtos que se exige que sejam entregues, os controles que ajudam a assegurar a qualidade e a coordenar as mudanças, e os marcos de referência que possibilitam aos gerentes de software avaliar o progresso. Estas etapas que envolve métodos, ferramentas e procedimentos, chamamos de paradigmas da engenharia de software.

13 1.5.2 Processos de software Os processos de software ou processos de desenvolvimento de software tem conceitos equivalentes a metodologia de desenvolvimento e manutenção de software, pois ambos são roteiros de elaboração de software que devem contemplar fases, subfases, produtos externados e pontos de avaliação de qualidade. Na engenharia de software, processos podem ser definidos para atividades como desenvolvimento, manutenção, aquisição e contratação de software. O ponto de partida para a arquitetura de um processo é a escolha de um modelo de ciclo de vida.

14 Ciclos de Vida Codifica-remenda: Com ou sem especificações dos requisitos funcionais, os desenvolvedores de software codificam ou programam os processos. Ciclo mais caótico; Utiliza-se uma ou até nenhuma especificação; Estilo codifica/remenda; Modelo de alto risco não permite assumir compromissos confiáveis.

15 Ciclos de Vida Cascata: Os processos obedecem a uma sequência obrigatória de desenvolvimento de software com demarcações predefinidas de avaliação. Se esse processo não permitir a flexibilidade do retorno nas sequências, ele torna o desenvolvimento do software altamente engessado e com consequências danosas para seu usuário final. Requisitos Análise Desenho Implementação Testes

16 Ciclos de Vida Espiral: Esse processo permite uma série de interações entre as fases do desenvolvimento. Cada interação implica numa volta no modelo espiral. Dessa forma a equipe desenvolvedora pode obter produtos ou resultados em prazos mais curtos. Esse modelo requer atenção especial dos seus gestores no seu processo interativo, principalmente quanto à qualidade de seus produtos gerados.

17 Ciclos de Vida

18 Ciclos de Vida Prototipação Evolutiva: Basicamente inicia com a concepção do sistema e emprega diversos ciclos de re-projeto, reimplementação e re-avaliação até a aceitação final do software. Cada novo protótipo confirma, refina ou adiciona novos requisitos até atingir a totalidade de requisitos do sistema.

19 Ciclos de Vida Prototipação Rápida Descartável: Difere do modelo evolutivo pelo fato de descartar o protótipo. No entanto assemelha-se em alguns aspectos quanto a sua estratégia.

20 Ciclos de Vida Diferentes projetos de desenvolvimento possuem diferentes necessidades que devem orientar a seleção do ciclo de vida mais adequado. McCONNEL (1996, p. 154), considerando as diferenças entre projetos de desenvolvimento, apresenta diversas questões que devem ser respondidas ao selecionar um modelo de ciclo de vida:

21 Ciclos de Vida 1. Qual o nível de compreensão do usuário e desenvolvedores em relação aos requisitos no início do projeto? É provável que a compreensão mude significativamente durante o desenvolvimento do projeto? 2. Qual o nível de compreensão dos desenvolvedores em relação a arquitetura do sistema? É provável que mudanças na arquitetura do sistema ocorram no meio do caminho? 3. Qual nível de confiança é necessário? 4. O quanto é necessário planejar e projetar durante o projeto prevendo mudanças em versões futuras? 5. Qual o nível de riscos implícitos no projeto? 6. Pode ser limitado em um cronograma? 7. É necessário habilidade para realizar correções no meio do projeto? 8. É necessário mostrar ao cliente o progresso durante o projeto? 9. É necessário demonstrar ao usuário aspetos gerenciais durante o projeto?

22

23 1.6 Resumo A engenharia de software é uma disciplina que integra métodos, ferramentas e procedimentos para o desenvolvimento de software de computadores. Uma série de diferentes paradigmas da engenharia de software foram propostos, cada um exibindo potencialidades e fragilidades, mas todos tendo uma série de fases genéricas em comum. São os passos dessas fases genéricas e os métodos aplicados a cada etapa que compreendem o desenvolvimento dessa disciplina.

24 2.Gerência de Projetos: Métricas de Software A seguir consideraremos os conceitos fundamentais que levam à administração efetiva de projetos de software. Vamos considerar o papel da administração e das métricas de software e o impacto das mesmas sobre a gerência de projetos.

25 2.1 O processo de gerência de projetos A gerência de projetos é a primeira camada do processo de engenharia de software. Ela abrange todo o processo de desenvolvimento, do começo ao fim. Uma vez que a gerência de projetos de software é tão importante para o sucesso de um projeto, seria razoável presumir-se que todos os gerentes de projetos entendem como colocá-la em prática.

26 2.1.1 Iniciando um projeto de software Antes que um projeto possa ser planejado, os objetivos e o escopo devem ser estabelecidos, soluções alternativas devem ser consideradas e as restrições administrativas e técnicas, identificadas. O desenvolvedor e o cliente devem reunir-se para definir os objetivos e o escopo do projeto. Os objetivos identificam as metas globais e o escopo identifica as funções primárias que o software deve realizar.

27 2.1.2 Medidas métricas Na maioria dos empreendimentos técnicos, as medições e as métricas ajudam-nos a entender o processo técnico usado para se desenvolver um produto. As métricas de software foram desenvolvidas a fim de oferecer a gerentes e profissionais técnicos à devida compreensão sobre o processo de engenharia de software e sobre o produto que ele produz.

28 2.1.3 Estimativa Uma das atividades fundamentais do processo de gerenciamento de projetos de software é o planejamento. Quando o projeto de software é planejado, estimativas do esforço humano exigido, duração cronológica do projeto devem ser derivadas. Uma série de técnicas de estimativas foram disponibilizadas para o desenvolvimento de software, todas têm os seguintes atributos em comum: O escopo deve ser estabelecido antecipadamente ao projeto; Métricas são utilizadas e históricos do passado são usados como base; O projeto é dividido em pequenas partes, que são estimadas individualmente;

29 2.1.4 Análise dos riscos Sempre que um programa de computador for construído haverá áreas de incerteza. A análise de riscos é crucial para um bom gerenciamento de projeto de software e, contudo, muitos projetos são levados a efeito sem nenhuma consideração específica de riscos. A análise de risco é, de fato, uma série de passos de administração de riscos que nos possibilita atacar o risco. Esses passos são aplicados em todo o processo de engenharia de software.

30 2.1.5 Determinação de Prazos Todo software tem uma programação de atividades para sua realização, mas nem todos os programas são criados igualmente. A programação se desenvolve por si mesma ou foi planejada antecipadamente? Os gerentes se concentraram somente na data final de entrega ou um curso bem definido foi identificado e monitorado para garantir que o prazo final seja cumprido? A programação do projeto de software não é, de fato, absolutamente diferente de qualquer projeto de engenharia. Uma rede de tarefas é criada.

31 2.1.6 Monitoração e controle Logo que a programação de desenvolvimento for estabelecida, iniciar-se-á a atividade de monitoração e controle. Cada tarefa anotada no programa é então rastreada pelo gerente de projetos. Dessa forma, o desenvolvimento de software pode ser mais bem controlado.

32 2.2 Métricas de produtividade e qualidade de software Medir é fundamental em qualquer disciplina de engenharia, e a engenharia de software não é exceção. Métricas de software referem-se a uma ampla variedade de medidas de software de computador. Dentro do contexto de gerenciamento de projetos de software, estamos preocupados primeiramente com métricas de produtividade e de qualidade.

33 2.3 Medidas do software O software é medido por muitas razões: (1) indicar a qualidade do produto; (2) avaliar a produtividade das pessoas que produzem o produto; (3) avaliar os benefícios derivados de novos métodos e ferramentas de software; (4) formar uma linha básica para estimativas; (5) ajudar a justificar os pedidos de novas ferramentas ou treinamento adicional. As divisões do mundo físico podem ser divididas em duas categorias: medidas diretas (comprimento de um parafuso) e medidas indiretas (qualidade do parafuso produzido, medida pela contagem dos parafusos rejeitados). As métricas de software podem ser divididas em categorias de maneira idêntica.

34 2.3 Medidas do software Entre as medidas do processo de engenharia de software incluem-se o custo e o esforço aplicados. As medidas diretas do produto incluem as linhas de código (LOC) produzidas, velocidade de execução, tamanho de memória e defeitos registrados ao longo de certo espaço de complexidade.