Notas de Aula 02: Processos de Desenvolvimento de Software

Transcrição

1 Notas de Aula 02: Processos de Desenvolvimento de Software Objetivos da aula: Introduzir os conceitos de um processo de desenvolvimento de software Definir os processos básicos Apresentar as vantagens e desvantagens no uso das abordagens existentes Recordando... Na aula passada, você aprendeu sobre os conceitos mais elementares sobre modelagem. Aprendeu que a modelagem é uma estratégia a ser seguida para o desenvolvimento de um software. No entanto, um modelo por si só não afeta ordem de execução das tarefas a serem cumpridas. Esta disciplina não se trata dos processos, mas sim das ferramentas de modelagem. No entanto, é importante contextualizar-se com todo o mecanismo de um grande projeto de. Introdução Até agora, discutimos sobre o que é um modelo. Ao tocarmos pela primeira vez sobre o assunto, não conseguimos imaginar as diversas granularidades na qual um modelo pode ser aplicado. O exemplo da construção da casa da nota de aula anterior nos fazia refletir sobre a importância da criação de modelos que refletissem as características da realidade na qual estamos tentando entender ou da solução que estamos tentando propor. Contudo, o processo de criação de software envolve mais do que criar um modelo sobre o domínio (problema) ou o modelo de projeto de software (solução). O modo como se lida com as tarefas pertinentes a criação do software, no que tange a sequência de execução, a administração de tempo e de recursos são igualmente importantes. A maneira com o processo de criação ocorre varia de acordo com a abordagem utilizada. A escolha da abordagem depende do domínio de problemas no qual estamos trabalhando, da cultura interna da organização, dos recursos humanos e das ferramentas de suporte que dispomos atualmente.

2 Independentemente do processo adotado, a criação de s começa pela identificação das necessidades. E é sobre este assunto que versa o próximo tópico. Para desenvolver um, temos que entendê-lo primeiro. Desenvolver software, não significa, necessariamente, entender completamente o domínio ao qual o software se propõe a ser utilizado. Entretanto, como já mencionado anteriormente, compreender as partes relevantes de um domínio pode fazer com que seu modelo possua escabilidade, capacidade de reutilização e manutenibilidade aumentada. O entendimento de um domínio começa a aparecer por meios tácitos (conversas com especialistas, experiências adquiridas em tarefas anteriores, etc..) e meios explícitos (livros, manuais de referência, questionários, etc.). Nas nossas aulas, não temos à disposição uma vasta biblioteca de conhecimento sobre assuntos de domínios de terceiros (não sabemos muito sobre o funcionamento de uma usina nuclear, certo?). Assim, os nossos estudos de caso refletirão um domínio e todo o conhecimento necessário para construção do. Do domínio que estivermos tentando modelar, deveremos identificar os requisitos de um. Um requisito é aquilo é de suma importância constar como tarefa a ser desenvolvida no projeto. Identificar os requisitos pertinentes ao domínio é uma tarefa (por vezes ingrata) do analista de s. Muitas vezes, essa tarefa é desempenhada por uma analista de negócios. Mas essa é conversa para outra disciplina. Os requisitos de podem ser agrupados como requisitos funcionais e como requisitos não-funcionais. Os requisitos funcionais englobam aqueles requisitos que independem da implementação ou tecnologia utilizada. Requisitos funcionais, como a própria palavra sugere, se refere às funcionalidades do. Dada certa entrada no, um requisito funcional descreve qual a resposta que o deve fornecer ou o que deve ser feito. São exemplos de requisitos funcionais: - Cadastrar os clientes e os funcionários de uma empresa; - Gerar a folha de pagamento.

3 Já os requisitos não-funcionais englobam aqueles requisitos que se referem à confiabilidade do, o tempo de resposta, a tolerância à falha, etc.. Dada certa entrada no, um requisito não funcional descreve que parâmetros computacionais devem ser atendidos. São exemplos de requisitos nãofuncionais: - O banco de dados deve possuir níveis de segurança de acesso; - Os módulos de terceiros devem ser de código aberto (open-source). Podemos encontrar na literatura um vasto conjunto de processos de desenvolvimento propostos. No entanto, iremos discutir apenas aqueles mais conhecidos. Além disso, para explicar de uma maneira genérica as etapas de criação do software, tome como base as seguintes fases: Fase de Análise esta fase se refere ao entendimento do domínio, o levantamento de requisitos do, a criação do cronograma e a gerência de custos. Fase de Projeto esta fase se refere à criação da arquitetura do software. Entre outras tarefas, fazem parte da fase de projeto: explicitar como o será dividido entre os módulos, definir a maneira como se dá a interação entre estes módulos, quais as tecnologias e padrões a serem aplicados, quais módulos podem ser reaproveitados de terceiros, etc. Fase de Implementação nesta fase, os programadores codificam o projeto de software definido. Em muitos processos, esta fase engloba uma fase concomitante de testes. Fase de teste nesta fase os requisitos apresentados são testados pelos programadores (testes alfa) e pelos usuários do (testes beta). Fase de entrega os clientes homologam o produzido através do resultado dos testes. Os s são então instalados no ambiente do cliente. Processo em cascata Originalmente encontrado em processos de criação de hardware, o processo cascata é mencionado pela primeira vez por Royce [1] em 1970, cuja proposta se baseava no cumprimento sequencial de fases (figura 1).

4 Análise Projeto Implementação Teste Entrega Figura 1: processo em cascata Segundo Pfleeger [2], o processo em cascata é muito útil para uma descrição simples de s, cujas tarefas a serem feitas são expressas de forma clara e concisa. Para clientes não acostumados com produtos de software, o processso em cascata ajuda ainda a ilustrar todas as etapas até a entrega do produto. Já Pressman [3], ressalta que o processo cascata é muito útil para s completamente compreendidos e de conhecimentos estáticos. Podemos encontrar na literatura muita controvérsia a respeito da utilidade prática do processo em cascata. O principal argumento encontrado diz respeito à incapacidade de reação frente às mudanças nos requisitos, o que na prática é o que mais ocorre. Pressman [3] coloca ainda que o processo em cascata pode atrasar desastrosamente a entrega do produto caso alguma falha seja encontrada tardiamente. Pfleeger [2] explica que o software é um resultado de criação e não de fabricação. A evolução do software se dá conforme os problemas são melhores entendidos e as possíveis soluções são avaliadas. Processo iterativo e o processo incremental Dada a não linearidade na construção de s, os processos subsequentes ao processo de cascata procuram ser mais realistas, criando versões ao longo do tempo de um mesmo produto. Tanto o processo iterativo quanto o processo incremental são uma evolução do processo em cascata, cujo diferencial está na aplicação repetitiva. A natureza cíclica destes processsos gera uma nova versão a cada repetição. Algumas das vantagens desta abordagem estão na possibilidade de treinamento de usuários desde as primeiras versões, a correção contínua de defeitos e a adição de recursos anteriormente não previstos.

5 Análise Entrega Projeto Teste Implementação Figura 2: processo iterativo e incremental O objetivo do processo iterativo consiste na entrega de todas as funcionalidades (degradadas) do desde o princípio, melhorando cada funcionalidade a cada iteração do ciclo de vida do, isto é, a cada nova versão. Já o processo incremental visa a entrega sistemática de uma parte das funcionalidades (totalmente operativas) do. A cada ciclo de vida, o processo incremental gerará uma nova versão que permitirá o cliente utilizar e validar uma parte dos requisitos especificados. Imagine o desenvolvimento de um software para administração escolar em duas versões. Imagine, ainda, que este software possui dois módulos: o cadastro de professores e o cadastro de disciplinas. O módulo de professores tem que cadastrar, além dos dados do professor, as disciplinas que o professor irá ministrar. Já o cadastro de aulas consiste na administração do nome da disciplina e de seus horários. Em um processo iterativo, tanto o cadastro de professores quanto o cadastro de aulas já estariam disponíveis desde o começo. Contudo, em uma avaliação preliminar da primeira versão, a associação entre os professores e as disciplinas ministradas carece de um aperfeiçoamento, uma vez que a redundância não foi tratada. Na segunda versão o será entregue com todos os requisitos implementados e aperfeiçoados. Diferentemente de um processo iterativo, em um processo incremental somente o cadastro de professores estaria disponível, mas em um nível de maturidade maior (mais confiável). Somente na segunda versão é que o cadastro de aulas estaria disponível para uso. A figura 3 demonstra as diferenças de abordagem:

6 Desenvolvimento iterativo Modelo Versão 1 Versão 2 Desenvolvimento incremental Modelo Versão 1 Versão 2 Figura 3: Diferença entre o processo iterativo e incremental. Adaptado de Pfleeger[2]. Processo por prototipagem O processo por prototipagem consiste em uma definição de objetivos gerais, a construção de protótipos e na adição de funcionalidades de forma adhoc. Os processos por prototipagem buscam em geral fazer prova de conceitos, apresentação de requisitos ou mesmo compreensão do domínio - é a política da validação iterativa. Nesta abordagem, algumas telas ou módulos são construídos e apresentados ao cliente continuamente, sem um documento formal de requisitos. Na verdade, as fases de análise e projeto caminham concomitantemente. O processo de prototipação não é normalmente utilizado de forma separada. O seu uso é comumente associado a outros processos, precisamente durante a fase de análise. Processo em Espiral Proposto por Boehm [4], o processo em espiral é um processo evolucionário cujo diferencial está na inclusão da análise de risco por mecanismos de prototipagem. O processo em espiral combina a capacidade de abstração do processo em cascata com a capacidade de explicitação e controle de risco do processo por prototipação.

7 O grande problema do processo em espiral está na sua complexidade, pois gerenciar os riscos a cada iteração é dispendioso em termos de tempo e custo. Figura 4: o processo espiral. Adaptado de Royce [1] A autora Pfleeger [2] explica que o processo em espiral começa com o levantamento dos objetivos gerais, o projeto inicial de desenvolvimento, os orçamentos, os cronogramas, os ambientes e as soluções possíveis. A cada iteração deste processo são levantadas as alternativas, as restrições e os riscos pertinentes as tarefas a serem executadas. Um artefato é gerado a cada iteração, o que não necessariamente se materializa com um software de computador. No processo em espiral, um é entregue somente na última iteração, mas é validado continuamente ao longo da criação. O produto da primeira iteração é a concepção das operações, um documento que se refere aos objetivos gerais do a ser construído. O produto da segunda iteração é o documento de requisitos, que procura assegurar em sua a completude as necessidades do cliente. O produto da terceira iteração é o projeto de software. A quarta iteração consiste em um plano de testes e na codificação do projeto de software. Podemos afirmar que a quarta iteração é a transcrição do processo clássico em cascata.

8 Exercícios 1. Pesquise e descreva o conceito por trás dos processos ágeis, seu histórico, vantagens e desvantagens. 2. Escolha um processo ágil (Xtreme Programing, Scrum, etc.) e trace um comparativo com o Processo Iterativo/Incremental. 3. Dê a sua opinião sobre a relação entre a cultura de uma organização e adoção de processo de criação. 4. Foi afirmado que o processo em cascata é útil para conhecimentos estáticos. Por que não podemos considerar um software, que deverá refletir um modelo de negócio, como estático? 5. Por que a dinamicidade afeta custos e cronograma de um desenvolvimento de software? 6. Explique, com as suas palavras, a diferença entre um requisito funcional e um requisito não-funcional 7. Por que um requisito funcional implica em um risco no processo espiral, uma vez que naturalmente este deverá ser concebido em algum momento?

9 Referências [1] W. W. Royce, Managing the development of large software systems: concepts and techniques. In: proceeding of Wescon, Agosto de [2] S. L. Pfleeger, Engenharia de Software: Teoria e Prática, Prentice Hall, [3] R. S. Pressman, Engenharia de Software (Sexta edição), McGraw-Hill, [4] B.W. Boehm, A Spiral Model of Software Development and Enhancement, Computer, vol. 21, 1988, pp