Resumo: Engenharia de Software II - P01
Everton H. P. Custódio
09/24/10
Desenvolvimento de Software Conceitos importantes Artefato → qualquer produto gerado durante uma atividade no processo de software, pode ser um documento, um modelo, um arquivo executável, um diagrama... Processo → uma maneira de coordenar de forma disciplinada as tarefas, responsabilidades, técnicas e métodos para o desenvolvimento de software, ou seja, um conjunto de atividades e resultados que associados geram um produto de software. Um processo possui uma documentação do que é feito, quando é feito, por quem é feito, os recursos necessários e o que é produzido. Projeto → um trabalho a ser realizado. Visão Genérica Um processo de software pode ser considerado tendo três fases principais: Definição → onde é decidido o que será produzido. Envolve a Engenharia do Sistema, Planejamento do Projeto e Análise de Requisitos; Desenvolvimento → onde é decidido como o software será criado. Envolve o Projeto, Implementação e Teste. Manutenção → onde será dado o suporte necessário para o correto funcionamento do sistema. Há ainda atividades que dão suporte a todas as fases do processo de software, são elas: Controle e Rastreamento do Projeto; Revisões Técnicas Formais; Garantia de Qualidade; Gerenciamento de Configuração; Produção e Preparação de Documentos; Gerenciamento de Reusabilidade; Medição; Gerenciamento de Riscos; Modelos de processo Modelo Sequencial Linear (Cascata) → um modelo onde as atividades de Análise, Projeto, Codificação e Testes são seguidas de forma linear. Muitos aplicam este modelo de forma estritamente linear, ou seja, realizando apenas uma iteração, porém o modelo original prevê a volta as primeiras fases até que o software resultante seja o esperado. Modelo RAD (Rapid Application Development) → um modelo também linear que enfatiza o desenvolvimento extremamente rápido, isso é possível através da abordagem de construção baseada em componente, onde o software é dividido em componente e são alocadas equipes que trabalham paralelamente no desenvolvimento dos componentes. Prototipação → modelo onde o desenvolvedor cria protótipos do sistema que ajudam na identificação de novos requisitos. Modelo Incremental → modelo onde o sistema é entregue em incrementos que atendem os requisitos considerados de maior prioridade. A cada entrega um novo requisito é atendido. Modelo Espiral → modelo que engloba a natureza iterativa da Prototipação e do Modelo Linear proporcionando assim um potencial para o desenvolvimento rápido de versões incrementais do software. O processo passa várias vezes pelas fases de Planejamento, Definição de Objetivos, Avaliação e redução de Riscos e Desenvolvimento e Validação.
evertonhenrique8@gmail.com
Página
1/6
Resumo: Engenharia de Software II - P01
Everton H. P. Custódio
09/24/10
Especificação de Requisitos Um documento de requisitos geralmente é feito em dois níveis de detalhe, um nível com linguagem natural para que o cliente possa compreender e validar, e um nível com linguagem mais técnica, contendo detalhes de implementação que servirá de base para os desenvolvedores. A identificação de requisitos é feita em quatro partes: Estudo de viabilidade → avaliar se a construção do sistema é possível tanto financeira quanto tecnologicamente. Levantamento e análise de requisitos → identificar tudo que o software deverá disponibilizar, todo o escopo do sistema. Especificação de requisitos → detalhar mais tecnicamente os requisitos encontrados na fase anterior para que os programadores possam implementá-los. Validação de requisitos → validar todas as informações e requisitos levantados durante a fase de análise com o cliente, de modo a garantir que o sistema especificado seja realmente o que o cliente deseja.
Rational Unified Process – RUP O que é Um processo de software que fornece uma abordagem disciplinada para delegar tarefas e responsabilidades dentro de uma organização de desenvolvimento. Tem como objetivo a produção de software de alta qualidade que satisfaz as necessidade do cliente dentro dos prazos e orçamentos previstos. Conceitos importantes Papel → a junção de comportamento e responsabilidades de um indivíduo, exemplo de papeis: especificador de requisitos, analista de teste, arquiteto de software, gerente de projeto. Atividade → uma unidade de trabalho, algo que um indivíduo que possui um papel pode fazer. Fluxo de trabalho → uma sequencia a qual as atividades devem obedecer. Disciplina → um conjunto de atividades que estão relacionada a uma determinada área de interesse, exemplos de áreas de interesse: requisitos, implementação, teste. O principal objetivo de separar as atividades em disciplinas é a facilitação da compreensão do projeto. Artefato → produto de um trabalho. Papeis usam/produzem artefatos ao desempenhar suas atividades. Um artefato possui apenas um papel como dono, porém outros papeis pode utilizar ou alterar um artefato que não seja seu. Os artefatos podem ser: um modelo, um elemento de um modelo, um documento, código fonte e executáveis. Exemplos de artefatos: Modelo de casos de Uso, um Ator para o Modelo de casos de Uso, Documento de arquitetura de software, Plano de Teste, Lista de Problemas, Regras de Negócio. Diretriz → como utilizar um artefato específico. Template → modelo para a criação de um artefato vinculado a uma ferramenta que será usada. evertonhenrique8@gmail.com
Página
2/6
Resumo: Engenharia de Software II - P01
Everton H. P. Custódio
09/24/10
Exemplo: um modelo de um documento do Microsoft Word utilizado para gerar o artefato Documento de Requisitos. As quatro fases do processo Concepção → fase onde é feita a especificação da visão do produto final, seu domínio de negócio e a extensão do projeto (o escopo). Elaboração → fase onde são planejadas as atividades necessárias, recursos exigidos, características e arquitetura do projeto. Construção → fase onde o produto é construído e evolui até estar pronto para a entrega ao usuário. Transição → fase onde o produto é entregue ao usuário, inclui também o treinamento e apoio do produto até que o cliente esteja satisfeito. As nove disciplinas Modelagem de negócio → entender a organização e seus problemas para identificar possíveis soluções e assegurar que todos os envolvidos tenham conhecimento comum da organização. Para que assim possam ser definidos os processos, papéis e responsabilidades dos envolvidos em um modelo de casos de uso de negócios e em um modelo de objetos de negócios. Requisitos → estabelecer uma concordância comum entre os envolvidos sobre o que o sistema deve fazer, definir as fronteiras do sistema, fornecer a base necessária para o planejamento técnico das iterações, fornecer base para estimar o custo e tempo do desenvolvimento do sistema. Análise de Projeto → transformar os requisitos em um design (modelo) do sistema a ser criado, desenvolver a arquitetura que será usada no sistema e adaptar o design ao ambiente de implementação a fim de ganhar desempenho. Implementação → definir a organização do código em subsistemas de implementação organizados em camadas, implementar as classes e objetos, testar os componentes desenvolvidos como unidades e integrar os subsistemas produzidos ao sistema executável principal. Teste → avaliar principalmente a qualidade do produto, para tornar isso possível é preciso localizar e documentar os defeito que podem afetar a qualidade do software, alertar os envolvidos sobre a qualidade observada, validar as funções conforme projetadas e verificar se os requisitos foram implementados corretamente. Distribuição → descrever as atividades que garantem que o produto de software será disponibilizado corretamente ao seus usuários finais. Configuração e Gerenciamento de Mudança → controlar as mudanças realizadas nos artefatos do projeto e organizá-las. Para isso é necessário identificar os itens a serem modificados, o que pode ser modificado nestes itens e registrar as modificações. Gerenciamento de Projeto → organizar de maneira eficiente o projeto, fornecer as diretrizes para planejar, montar a equipe, executar, monitorar e gerenciar os riscos. Ambiente → organizar o ambiente de desenvolvimento do projeto e criar as diretrizes necessárias para o suporte de um projeto.
evertonhenrique8@gmail.com
Página
3/6
Resumo: Engenharia de Software II - P01
Everton H. P. Custódio
09/24/10
Unified Modelling Language – UML Diagrama de Casos de Uso O Diagrama de Casos de Uso é formado por casos de uso, atores e relacionamentos envolvendo estes elementos. Tem como objetivo apresenta a visão geral de uma funcionalidade ou um grupo de funcionalidades do sistema. Conceitos Ator → uma entidade externa que interage com o software a ser modelado. Representado por um boneco de palito (stickman). Caso de uso → uma funcionalidade que o sistema disponibiliza. Representado por uma elipse com o nome do caso no centro. Relacionamento → a maneira como um ator é associado a um caso de uso, como um ator é associado a outro ator ou como um caso de uso é associado a outro caso de uso. Representado por uma reta ligando os envolvidos. Tipos de Relacionamentos Generalização → a herança de orientação a objetos, geralmente usado entre atores. Include → caso de uso X inclui caso de uso Y: representa a obrigatoriedade de executar o caso de uso Y toda vez que o caso de uso X for executado. Extends → caso de uso X extends caso de uso Y: representa a execução do caso de uso Y quando uma condição for verdadeira e o caso de uso X for executado. Documentação de Caso de Uso Com apenas a representação do Diagrama de Casos de Uso não é possível especificar todos os detalhes necessários para a implementação daquela funcionalidade, então para ajudar na implementação dos casos de uso são criadas as tabelas de documentação destes, que apresentam todas as informações necessárias ao programador. As tabelas geralmente apresentam informações referentes a: Identificação do caso de uso e da funcionalidade que é representada, descrição da função exercida pelo caso de uso, os atores envolvidos, as entradas e origens necessárias para iniciar a funcionalidade, as saídas e respectivos destinos do que é gerado pelo caso de uso, a descrição do curso normal e exceções que podem ocorrer na execução da funcionalidade, a descrição de tarefas que serão executadas na funcionalidade, pré-condição que dá inicio a execução da funcionalidade e pós-condição que será atendida ao final da funcionalidade. Exemplo de tabela: ID do Caso de Uso Função
evertonhenrique8@gmail.com
Página
4/6
Resumo: Engenharia de Software II - P01
Everton H. P. Custódio
09/24/10
Atores Descrição Entradas Origem Saídas Destino Exceções Curso normal Curso alternativo Requer Pré-condição Pós-condição
evertonhenrique8@gmail.com
Página
5/6
Resumo: Engenharia de Software II - P01
Everton H. P. Custódio
09/24/10
REFERENCIAS Engenharia de Software I, Prof: Silvia Helena de Oliveira Santos. Anotações de Aula. FATEC Ourinhos. Engenharia de Software II, Prof: Rogério Marinke. Anotações de Aula. FATEC Ourinhos. KRUCHTEN, Phillipe. Introdução ao RUP – Rational Unified Process. Rio de Janeiro: Editora Ciência Moderna Ltda., 2003. WThreeX/RUP . RUP 2002.05.00 Portugues. http://www.wthreex.com/rup/portugues/index.htm. Acesso em: 24/09/2010.
evertonhenrique8@gmail.com
Disponível
Página
em:
6/6