A Metodologias e Projeto de Software

Resumo do E-book:

Metodologias e Projetos de Software

1. Ciclos de vida de um processo de desenvolvimento de software 

 “O software não se desgasta, ele se deteriora” -  torna-se obsoleto –

O que significa dizer que o software não começa a apresentar falhas por motivos de uso excessivo (como um hardware), ele continuará funcionando do jeito que foi entregue pela última vez. Porém sem atualizações que se adequem às novas tecnologias, qualquer software se torna obsoleto, com o tempo.

1. Características do processo de desenvolvimento de definem “engenharia de software”

1. Métodos:  Detalhes de como fazer.
2. Ferramentas: Dá suporte aos métodos.
3.  Procedimentos: Estabelecem a sequência das ações.

1. Modelos de desenvolvimento:

1.  Modelo Cascata: Subprocessos executados em sequência, sem regresso.
2.  Modelo em Espiral:  Série de interações com o cliente.
3.  Modelo Prototipação: São produzidas versões iniciais antes do software ser realmente construído.
4.  Modelo Incremental: O desenvolvimento evolui em versões com incrementos (pode ser utilizado com prototipação).

1. Extreme Programming (XP):

Desenvolvimento baseado em requisitos vagos e que se modificam rapidamente (Equipes pequenas).

1. Scrum (Software Development Process):

Também formado por equipes pequenas.

                Dividir o desenvolvimento em interações de 30 dias, chamadas Sprints, onde as equipes trabalham em torno dos requisitos que foram definidos no início da Sprint, com reuniões diárias.

1. Engenharia de requisitos

Requisito é uma descrição dos principais recursos, comportamentos e atributos de um produto de software.

Os critérios de aceitação são divididos em duas características principais:

• Requisitos funcionais:  representam o comportamento esperado do sistema a interações do usuário.
• Requisitos não-funcionais:  representam as características comportamentais e específicas do sistema.

         Um requisito pode ser do tipo:

• Explícito, no qual são levantadas as necessidades impostas pelo cliente;
• Implícito, no qual são levantadas as questões e não foram impostas pelo cliente (por falta de conhecimento técnico por exemplo), mas devem ser tratados nos requisitos;
• Normativo, que são os requisitos impostos por decorrência das leis;

1. Levantamento de requisitos:

Levantamento de requisitos baseia-se na interação com o cliente para que sejam esclarecidas todas as suas necessidades.

O levantamento destes requisitos pode ser adquirido das seguintes formas:

• Por entrevista: Por meio de pergunta - resposta.
• Questionário:  Perguntas mais simples e curtas.
• Observação direta: Esclarecimento da forma como os processos ocorrem no ambiente atual, utilizado como validação das entrevistas.
• Brainstorming: Por meio de discussão em grupo

1.  Especificação de requisitos

        Descrição dos requisitos que propõe uma solução para o problema imposto pelo cliente.

         Questões abordadas na especificação textual:

• Funcionalidade (o que o sistema deve suportar)
•  Interfaces externas (hardware)
•  Desempenho (velocidade)
•  Atributos (qualidade)

1.  Análise Estruturada

        Baseada na técnica de utilização de uma linguagem gráfica para construir modelos de sistemas de software.

        Análise estruturada é composta por:

• Diagrama de Fluxo de Dados (DFD)
• Dicionário de Dados
• Especificação dos Processos
• Modelagem de Dados (ER)

1. Diagrama de fluxo de dados (DFD)

Técnica de representação gráfica que permite explicar o fluxo de informações de um sistema, da entrada em direção à saída.

Onde, o nome do processo deve ser um verbo no infinitivo, e os nomes que representam o fluxo de dados, as entidades externas e o depósito de dados por substantivos.

1.  Dicionário de Dados

É basicamente a descrição precisa do item anterior, o DFD.

São listadas em tabelas as especificações de cada dado, utilizando as seguintes notações:

• Nome
• Especificação
• Utilização
•  Descrição
•  Informações Complementares

1.  Modelagem de Dados (ER)

        Também conhecido como diagrama ER (Entidade-Relacionamento).É utilizado para representar os dados a serem armazenados no sistema.

É formado por:

• Entidade;
• Atributo;
• Relacionamento;

Onde cada entidade possui seus próprios atributos, e relaciona-se com as demais.

Quando você identifica quantas vezes a instância de uma entidade pode participar de um relacionamento, você está identificando sua cardinalidade. A cardinalidade indica o número máximo e mínimo de associações possíveis em um relacionamento.

         Elas podem ser representadas das seguintes:

• 1 para 1 (1:1) = Quando cada Instância da primeira entidade pode ser relacionada com nenhuma ou apenas uma Instância da segunda entidade.
• 1 para n (1:n) = Quando a primeira entidade (sua instância)   pode  se relacionar como nenhuma até “n” instâncias de outra Entidade.
• n para n (n:n) =  Quando a Instância da primeira entidade deve relacionar-se com uma ou mais instâncias da segunda,  e também estabelece relação com uma ou mais da primeira.

1. Visão Geral da UML

1. Paradigma da orientação a objetos

Os processos da análise estruturada são compostos por dados e procedimentos basicamente. Já na orientação a objetos, os dados e procedimentos são encapsulados em um só elemento, o objeto, e pode ser identificado como Instância de uma classe (entidade representante).

        Onde objeto, pode ser identificado como abstração de um conjunto de coisas do mundo real, sendo as coisas, abstração de atributos e métodos.

         A orientação a objetos é composta por: