Aula 2 Revisão 1. Ciclo de Vida. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW

Transcrição

1 Ciclo de Vida Aula 2 Revisão 1 Processo de Desenvolvimento de Software 1 O Processo de desenvolvimento de software é um conjunto de atividades, parcialmente ordenadas, com a finalidade de obter um produto de software. O Processo de desenvolvimento de software é uma das respostas técnicas adequadas para resolver a Crise do Software, termo utilizado nos anos 70, quando a Engenharia de Software era praticamente inexistente. É estudado dentro da área de Engenharia de Software e é considerado um dos principais mecanismos para obter software de qualidade e cumprir corretamente os contratos de desenvolvimento. O termo expressava as dificuldades do desenvolvimento de software, frente ao rápido crescimento da demanda por software, da complexidade dos problemas a serem resolvidos e da inexistência de técnicas estabelecidas para o desenvolvimento de sistemas que funcionassem adequadamente ou pudessem ser validados. Na década de 70, a atividade desenvolvimento de software era executada de forma desorganizada, desestruturada e sem planejamento, gerando um produto final de má qualidade, pois não existia documentação ou era entregue fora do prazo ou o levantamento de tempo e esforço não correspondia à real necessidade. Muitas vezes, esta atividade não satisfazia às necessidades do cliente, desperdiçando recursos da empresa e aumentando gastos, que não viriam a ser compensadores para o cliente, demandando tempo, esforço e dinheiro, daí o termo Crise do Software. A partir deste cenário, com a necessidade de tornar o desenvolvimento de software um processo estruturado, planejado e padronizado, ele vem evoluindo para que erros que caracterizaram esta crise, como a má qualidade do que foi desenvolvido, não ocorram com projetos atuais. Para isso linguagens para modelagem do sistema, como a UML, foram criadas. 1

2 Além das linguagens, principalmente, foram desenvolvidas metodologias de desenvolvimento de software, onde passos eram detalhados para que o processo de desenvolvimento seguisse um padrão e assim atingisse a qualidade necessária. Com o tempo, as metodologias se tornaram mais complexas e distintas melhorando a qualidade do produto, independente do foco do sistema sempre haveria uma metodologia para manter a qualidade. Problemas relacionados com o SW O avanço constante do hardware supera nossa capacidade de produzir software que explore esse potencial. Nossa habilidade para construir novos produtos de software não acompanha a demanda, pela quantidade de passos a serem seguidos. 100 _ 80 _ 60 _ 40 _ 20 _ Hardware Desenvolvimento SW Manutenção SW 1 - Levantamento e Análise de Requisitos de SW A extração dos requisitos de um desejado produto de software é a primeira tarefa na sua criação. Embora o cliente provavelmente acredite conhecer o que o software deve fazer, esta tarefa requer habilidade e experiência em Engenharia de Software. 2 - Definição (Especificação e Arquitetura do SW) A arquitetura de um sistema de software remete a uma representação abstrata de sua especificação. Arquitetura é concernente à garantia de que o sistema de software irá ao encontro dos requisitos do produto, como também assegura que futuros requisitos possam ser atendidos. 3 - Implementação ou Codificação A transformação de um projeto para um código, geralmente, é a parte mais evidente do trabalho da Engenharia de Software, mas não necessariamente a sua maior porção. Consiste na programação do que foi definido na especificação e representado na arquitetura do software. 4 - Testes Teste de partes do software, especialmente onde tenha sido codificado por mais de uma pessoa da equipe, trabalhando junto, é um papel importante da Engenharia de Software para garantir sua qualidade. O método de caixa preta (black Box), também chamado teste funcional, testa o sistema do ponto de vista do usuário, isto é, não considera a estrutura interna ou a forma de implementação do sistema, tendo como objetivo determinar se os requisitos foram total ou parcialmente satisfeitos. O método de caixa branca (white Box), por outro lado, procura exercitar todas as partes do código de um sistema. 2

3 5 - Documentação A documentação que recebe mais importância é a das interfaces externas, ou seja, da interação com o sistema. Uma importante tarefa (frequentemente desprezada) é a documentação do projeto interno do software para facilitar futuras manutenções e aprimoramentos. 6 - Suporte e Treinamento Uma grande parte dos projetos de SW falham porque o desenvolvedor não percebe que não importa quanto tempo a equipe gaste na criação do SW se ninguém usá-lo. As pessoas são resistentes à mudança e evitam aventurar-se em áreas pouco familiares. Então, como uma parte da fase de desenvolvimento, é muito importante o treinamento, que conduzirá para a próxima fase do software. Ciclo de Vida independente da Metodologia 7 - Manutenção A manutenção e melhoria de SW lidam com a descoberta de novos problemas e requisitos. Pode tomar mais tempo que o gasto no desenvolvimento inicial do software. Requer um significativo esforço por parte de um Engenheiro de Software. A maior parte da manutenção é para ampliar os sistemas para novas funcionalidades, o que pode ser considerado um novo trabalho. Metodologias e Ciclos de Vida O ciclo de vida de um sistema varia, de acordo com a metodologia utilizada: - Clássica - Semi-Estruturada - Estruturada - Orientada a Objetos Ciclo de Vida Clássico Método sistemático e sequencial, em que o resultado de uma fase se constitui na entrada da outra fase. Foi modelado de acordo com o ciclo da engenharia convencional e abrange as seguintes fases: - Levantamento de Requisitos - Análise de Requisitos - Projeto - Implementação - Testes - Manutenção 3

4 Ciclo de Vida Semi-Estruturado Possui algumas características distintas das do Ciclo de Vida Clássico em relação à fase de Projeto, Implementação e Testes. Na fase de Projeto, essa foi a primeira vez que se utilizou uma ferramenta de Projeto Estruturado. O principal conceito da fase de Projeto Estruturado é dado pelo conceito de modularização. Um módulo é uma parte do sistema que deve desempenhar uma função específica de maneira que: Ciclo de Vida Estruturado O Ciclo de Vida Estruturado marca a utilização efetiva de ferramentas estruturadas de Análise e Projeto. As ferramentas de Análise Estruturada como o DFD (Diagrama de Fluxo de Dados), dividem o sistema em processos, de forma que cada processo constitui uma função a ser desempenhada pelo sistema. O funcionamento de um módulo deve estar oculto a outros módulos e deve ser dedicado à uma função específica; A interface de um módulo deve precisar somente das informações necessárias para que o módulo complete a tarefa; A abordagem Bottom-up das fases de Implementação e Testes foi substituída por uma abordagem Top-Down. Fases do ciclo de vida OO (UML) Existem cinco fases no desenvolvimento de sistemas de software OO: - Análise de requisitos - Análise - Design (projeto) Estas cinco fases não devem ser executadas na ordem apresentada, mas concomitantemente, de forma que problemas detectados numa certa fase modifiquem e melhorem as fases desenvolvidas anteriormente, de forma que o resultado global gere um produto de alta qualidade e performance. - Implementação (programação) - Testes Análise de Requisitos Análise Esta fase captura as intenções e necessidades dos usuários do sistema a ser desenvolvido, através do uso de funções chamadas casos de uso, onde as entidades externas ao sistema (em UML chamados de "atores ) interagem e possuem interesse no sistema; são modelados entre as funções. Cada caso de uso modelado é descrito através de um texto que especifica os requerimentos do ator que o utilizará. O Diagrama de Casos de Uso mostra o que os atores externos deverão esperar do aplicativo, conhecendo toda sua funcionalidade, sem importar como esta será implementada. 23 A fase de análise está preocupada com as primeiras abstrações (classes e objetos) e mecanismos que estarão presentes no domínio do problema. As classes são modeladas e ligadas através de relacionamentos com outras classes, e são descritas no Diagrama de Classes. As colaborações entre classes também são mostradas nesse diagrama para desenvolver os casos de uso modelados anteriormente, sendo criadas através de modelos dinâmicos em UML. Na análise, só serão modeladas classes que pertençam ao domínio principal do problema do software, ou seja, classes técnicas que gerenciem banco de dados, interface, comunicação, concorrência e outros não estarão presentes nesse diagrama, nessa fase. 24 4

5 Design (Projeto) Programação Na fase de design, o resultado da análise é expandido em soluções técnicas. Novas classes são adicionadas para prover uma infra-estrutura técnica: a interface do usuário e de periféricos, gerenciamento de banco de dados, comunicação com outros sistemas, dentre outros. As classes do domínio do problema modeladas na fase de análise são mescladas nessa nova infra-estrutura técnica, tornando possível alterar tanto o domínio do problema quanto a infra-estrutura. O design resulta no detalhamento das especificações para a fase de programação do sistema. 25 A programação é uma fase separada e distinta, onde os modelos criados nas fases de análise e design são convertidos em código da linguagem orientada a objetos escolhida. Dependendo da capacidade da linguagem usada, essa conversão pode ser uma tarefa fácil ou muito complicada. No momento da criação de modelos de análise e design em UML, é melhor evitar traduzi-los mentalmente em código, pois, nessas fases, os modelos criados são o significado do entendimento e da estrutura do sistema. Senão, no momento da geração do código onde o analista concluiu antecipadamente sobre modificações em seu conteúdo, seus modelos não estarão mais demonstrando o real perfil do sistema. 26 Testes Nos dias atuais... Um sistema normalmente é rodado em testes de unidade, integração e aceitação. Os testes de unidade ( caixa branca ) são para classes individuais ou grupos de classes e são geralmente feitos pelo programador. Os testes de integração ( caixa branca ) são aplicados já usando as classes e componentes integrados, para se confirmar se estão cooperando umas com as outras, como especificado nos modelos. Os testes de aceitação observam o sistema como uma "caixa preta" e verificam se ele está funcionando como o especificado nos primeiros Diagramas de Casos de Uso. Entretanto, a Crise do Software perdura até hoje, onde, mesmo com técnicas avançadas de desenvolvimento e padrões consolidados na área de criação de software, ainda existem características da época da Crise como: projetos atrasados, erros de estimativa de custos e de tempo, que tornam o processo, ainda que sistematizado, passível de muitos erros. Nos testes de aceitação, o sistema será testado pelo usuário final, que verificará se os resultados mostrados estão realmente de acordo com as intenções do usuário final