(Parte 1 de 6)

1 Apostila Engenharia de Software

Elielder Berwanger

1. Processo de Software4
1.1 Definição de Processos4
2. Ciclo de vida5
3. Gerência de Projetos de Software6
3.1 Atividades Típicas da Gerência de Projetos:7
3.2 O Planejamento e o Acompanhamento do Projeto7
3.3 Estimativas7
4. Gerência da Qualidade8
4.1 Documentação8
4.2 Controle e Garantia da Qualidade9
4.3 Padrões Organizacionais9
4.4 Revisões10
4.5 Gerência de Configuração1
5. Levantamento/Análise de Requisitos1
5.1 Requisito e Tipos de Requisitos12
5.2 O Processo da Engenharia de Requisitos12
5.3 Levantamento de Requisitos13
5.4 Análise de Requisitos13
5.5 Especificação da Lógica dos Processos14
6. Modelo Entidade-Relacionamento15
6.1 Entidades15
6.2 Atributos15
7. Dicionário de Dados16
8. UML16
8.1 Diagrama de Casos de Uso17
8.2 Descrição de caso de uso18
8.3 Diagrama de Classes20
8.4 Diagrama de Objetos21
8.5 Diagrama de Seqüência21
8.6 Diagrama de Colaboração2
8.7 Diagramas de Estado23
8.8 Diagrama de Atividades23
8.10 Diagrama de Implantação25

1. Processo de Software

Um processo de software pode ser visto como o conjunto de atividades, métodos, práticas e transformações que guiam pessoas na produção de software. Um processo eficaz deve, claramente, considerar as relações entre as atividades, os artefatos produzidos no desenvolvimento, as ferramentas, os procedimentos necessários, a habilidade, o treinamento e a motivação do pessoal envolvido.

1.1 Definição de Processos

Há vários aspectos a serem considerados na definição de um processo de software. No centro da arquitetura de um processo de desenvolvimento estão algumas atividades chaves: análise e especificação de requisitos, projeto, desenvolvimento e testes, que são a base sobre a qual o processo de desenvolvimento deve ser construído. Entretanto, a definição de um processo envolve a escolha de um modelo de ciclo de vida, o detalhamento (decomposição) de suas macro-atividades, a escolha de métodos, técnicas e roteiros (procedimentos) para a sua realização e a definição de recursos e artefatos necessários e produzidos.

Um processo de software não pode ser definido de forma universal. Para ser eficaz e conduzir à construção de produtos de boa qualidade, um processo deve ser adequado ao domínio da aplicação e ao projeto específico. Deste modo, processos devem ser definidos caso a caso, considerando-se as especificidades da aplicação, a tecnologia a ser adotada na sua construção, a organização onde o produto será desenvolvido e o grupo de desenvolvimento.

Em suma, o objetivo de se definir um processo de software é favorecer a produção de sistemas de alta qualidade, atingindo as necessidades dos usuários finais, dentro de um cronograma e um orçamento previsível.

A escolha de um modelo de ciclo de vida (ou modelo de processo) é o ponto de partida para a definição de um processo de desenvolvimento de software. Um modelo de ciclo de vida organiza as macroatividades básicas, estabelecendo precedência e dependência entre as mesmas.

Um modelo de ciclo de vida pode ser entendido como passos ou atividades que devem ser executados durante um projeto. Para a definição completa do processo, a cada atividade, devem ser associados técnicas, ferramentas e critérios de qualidade, entre outros, formando uma base sólida para o desenvolvimento. Adicionalmente, outras atividades tipicamente de cunho gerencial, devem ser definidas, entre elas atividade de gerência e de controle e garantia da qualidade.

São fatores que influenciam a definição de um processo:

• Tipo de software (sistema de informação, sistema de tempo real, etc.); • Paradigma (estruturado, orientado a objetos, etc.);

• Domínio da aplicação;

• Tamanho;

• Complexidade;

• Características da equipe

Embora diferentes projetos necessitem de processos com características específicas para atender às suas particularidades, é possível estabelecer um conjunto de ativos de processo (sub-processos, atividades, sub-atividades, artefatos, recursos e procedimentos) a ser utilizado na definição de processos de software de uma organização. Essas coleções de ativos de processo de software constituem o chamado processo padrão de desenvolvimento de software. Processos para projetos específicos podem, então, ser definidos a partir da instanciação do processo de software padrão da organização, levando em consideração suas características particulares. Esses processos instanciados são ditos processos de projeto.

De fato, o modelo de definição de processos baseado em processos padrão pode ser estendido para comportar vários níveis. Primeiro, pode-se definir um processo padrão da organização, contendo os ativos de processo que devem fazer parte de todos os processos de projeto da organização. Esse processo padrão pode ser especializado para agregar novos ativos de processo, considerando aspectos, tais como tecnologias de desenvolvimento, paradigmas ou domínios de aplicação. Assim, obtêm-se processos mais completos, que consideram características da especialização desejada. Por fim, a partir de um processo padrão ou de um processo especializado, é possível instanciar um processo de projeto, que será o processo a ser utilizado em um projeto de software específico. Para definir esse processo devem ser consideradas as particularidades de cada projeto.

Para apoiar a definição de processos, diversas normas e modelos de qualidade de processo de software foram propostas, dentre elas: ISO9001, ISO/IEC 12207, ISO/IEC 15504, CMM, CMMI e MPS.BR. O objetivo dessas normas e modelos de qualidade é apontar características que um bom processo de software tem de apresentar, deixando a organização livre para estruturar essas características segundo sua própria cultura.

2. Ciclo de vida De maneira geral, o ciclo de vida de um software envolve as seguintes fases:

• Planejamento: O objetivo do planejamento de projeto é fornecer uma estrutura que possibilite ao gerente fazer estimativas razoáveis de recursos, custos e prazos. Uma vez estabelecido o escopo de software, uma proposta de desenvolvimento deve ser elaborada, isto é, um plano de projeto deve ser elaborado configurando o processo a ser utilizado no desenvolvimento de software. À medida que o projeto progride, o planejamento deve ser detalhado e atualizado regularmente. Pelo menos ao final de cada uma das fases do desenvolvimento (análise e especificação de requisitos, projeto, desenvolvimento e testes), o planejamento como um todo deve ser revisto e o planejamento da etapa seguinte deve ser detalhado. O planejamento e o acompanhamento do progresso fazem parte do processo de gerência de projeto.

• Análise e Especificação de Requisitos: Nesta fase, o processo de levantamento de requisitos é intensificado. O escopo deve ser refinado e os requisitos identificados. Para entender a natureza do software a ser construído, o engenheiro de software tem de compreender o domínio do problema, bem como a funcionalidade e o comportamento esperados. Uma vez identificados os requisitos do sistema a serem desenvolvidos, estes devem ser modelados, avaliados e documentados. Uma parte vital desta fase é a construção de um modelo descrevendo o que o software tem de fazer (e não como fazê-lo).

• Projeto: Esta fase é responsável por incorporar requisitos tecnológicos aos requisitos essenciais do sistema, modelados na fase anterior e, portanto, requer que a plataforma de desenvolvimento seja conhecida. Basicamente, envolve duas grandes etapas: projeto da arquitetura do sistema e projeto detalhado. O objetivo da primeira etapa é definir a arquitetura geral do software, tendo por base o modelo construído na fase de análise de requisitos. Esta arquitetura deve descrever a estrutura de nível mais alto da aplicação e identificar seus principais componentes. O propósito do projeto detalhado é detalhar o projeto do software para cada componente identificado na etapa anterior. Os componentes de software devem ser sucessivamente refinados em níveis de maior detalhamento, até que possam ser codificados e testados.

• Implementação: O projeto deve ser traduzido para uma forma passível de execução pela máquina. A fase de desenvolvimento realiza esta tarefa, isto é, cada unidade de software do projeto detalhado é escrita.

• Testes: Inclui diversos níveis de testes, por exemplo: teste de unidade, teste de integração e teste de sistema. Inicialmente, cada unidade de software implementada deve ser testada e os resultados documentados. A seguir, os diversos componentes devem ser integrados sucessivamente até se obter o sistema. Finalmente, o sistema como um todo deve ser testado.

• Entrega e Implantação: Uma vez testado, o software deve ser colocado em produção. Para tal, contudo, é necessário treinar os usuários, configurar o ambiente de produção e, muitas vezes, converter bases de dados. O propósito desta fase é estabelecer que o software satisfaça os requisitos dos usuários. Isto é feito instalando o software e conduzindo testes de aceitação (validação). Quando o software tiver demonstrado prover as capacidades requeridas, ele pode ser aceito e a operação iniciada. • Operação: Nesta fase, o software é utilizado pelos usuários no ambiente de produção.

• Manutenção: Indubitavelmente, o software sofrerá mudanças após ter sido entregue para o usuário. Alterações ocorrerão porque erros foram encontrados, porque o software precisa ser adaptado para acomodar mudanças em seu ambiente externo, ou porque o cliente necessita de funcionalidade adicional ou aumento de desempenho. Muitas vezes, dependendo do tipo e porte da manutenção necessária, essa fase pode requerer a definição de um novo processo, onde cada uma das fases precedentes é re-aplicada no contexto de um software existente ao invés de um novo.

3. Gerência de Projetos de Software A Gerência de Projetos de Software envolve o Produto, o Processo e as Pessoas envolvidas no projeto.

• Produto: No que se refere ao produto, a primeira coisa a se fazer é definir o escopo do projeto.

Para tal, é necessário fazer um levantamento de requisitos inicial. A idéia é decompor o problema, em uma abordagem “dividir para conquistar”. Inicialmente, o sistema deve ser decomposto em subsistemas que são, por sua vez, decompostos em módulos. Os módulos podem, ainda, ser recursivamente decompostos em sub-módulos ou funções, até que se tenha uma visão geral das funcionalidades a serem tratadas no projeto.

• Processo: visto anteriormente.

• Pessoas: Em um projeto de software, há várias pessoas envolvidas, exercendo diferentes papéis, tais como: gerente de projeto, analistas, projetistas, engenheiro de software, programadores, engenheiros de testes, gerente da qualidade, clientes e usuários. O número de papéis e suas denominações podem ser bastante diferentes dependendo da organização e até mesmo do projeto. As pessoas trabalhando em um projeto são organizadas em equipes. Assim, o conceito de equipe pode ser visto como um conjunto de pessoas trabalhando em diferentes tarefas, mas objetivando uma meta comum. Para a boa formação de equipes, devem ser definidos os papéis necessários e devem ser considerados aspectos fundamentais, a saber, liderança, organização (estrutura da equipe) e coordenação. Além disso, há diversos fatores que afetam a formação de equipes: relacionamentos interpessoais, tipo do projeto, criatividade etc. Por fim, na formação de equipes deve-se levar em conta o tamanho da equipe. Quanto maior o número de membros da equipe, maior a quantidade de caminhos possíveis de comunicação, o que pode ser um problema, uma vez que o número de pessoas que podem se comunicar com outras pode afetar a qualidade do produto resultante.

Uma boa gerência de projetos começa com a fusão das visões de Produto, Processo e Pessoas. Cada função ou módulo a ser desenvolvido pela equipe do projeto deve passar pelas várias atividades definidas no processo de software. Essa pode ser uma base bastante efetiva para a elaboração de estimativas, incluindo a alocação de recursos, já que é sempre mais fácil estimar porções menores de trabalho.

3.1 Atividades Típicas da Gerência de Projetos: A gerência de projetos envolve a realização de diversas atividades, abaixo relacionadas:

• Determinação do escopo do software; • Definição do processo de software do projeto;

• Realização de estimativas;

• Estimativa de tamanho;

• Estimativa de esforço;

• Estimativa (alocação) de recursos;

• Estimativa de tempo (elaboração do cronograma do projeto);

• Estimativa de custos;

• Gerência de riscos;

• Elaboração do plano de projeto.

3.2 O Planejamento e o Acompanhamento do Projeto

As atividades acima relacionadas são realizadas diversas vezes ao longo do projeto. Tipicamente, no início do projeto, elas têm de ser realizadas para produzir uma primeira visão gerencial sobre o projeto, quando são conjuntamente denominadas de planejamento do projeto. À medida que o projeto avança, contudo, o plano do projeto deve ser revisto, uma vez que problemas podem surgir ou porque se ganha um maior entendimento sobre o problema.

Essas revisões do plano de projeto são ditas atividades de acompanhamento do projeto e tipicamente são realizadas nos marcos do projeto. O marcos de um projeto é estabelecido durante a definição do processo e tipicamente correspondem ao término de atividades importantes do processo de desenvolvimento, tais como análise e especificação de requisitos, projeto e implementação. O propósito de um marco é garantir que os interessados tenham uma visão do andamento do projeto e concordem com os rumos a serem tomados.

Em uma atividade de acompanhamento do projeto, o escopo pode ser revisto, alterações no processo podem ser necessárias, bem como devem ser monitorados os riscos e revisadas as estimativas (de tamanho, esforço, tempo e custo).

3.3 Estimativas

Antes mesmo de serem iniciadas as atividades técnicas de um projeto, o gerente e a equipe de desenvolvimento devem estimar o trabalho a ser realizado, os recursos necessários, o tempo de duração e, por fim, o custo do projeto. Apesar das estimativas serem um pouco de arte e um pouco de ciência, esta importante atividade não deve ser conduzida de forma desordenada. As estimativas podem ser consideradas a fundação para todas as outras atividades de planejamento de projeto. Para alcançar boas estimativas de prazo, esforço e custo, existem algumas opções:

• Postergar as estimativas até o mais tarde possível no projeto; • Usar técnicas de decomposição;

• Usar um ou mais modelos empíricos para estimativas de custo e esforço;

(Parte 1 de 6)

Comentários