PROFESSOR: CRISTIANO MARIOTTI

Transcrição

1 PROFESSOR: CRISTIANO MARIOTTI

2 Conjunto de atividades, parcialmente ordenadas, com a finalidade de obter um produto de software; Considerado um dos principais mecanismos para se obter software de qualidade e cumprir corretamente os contratos de desenvolvimento; Uma das respostas técnicas adequadas para resolver a Crise do software.

3 Na Engenharia de Software, são muitos os modelos sugeridos para desenvolvimento, mas para TODOS são necessários a existência de três componentes para que o processo caminhe: MÉTODO Define-se sob qual concepção ou abordagem tecnológica / mercadológica o software será desenvolvido; PROCESSOS Define-se o encadeamento das atividades que irão compor as etapas para desenvolvimento; FERRAMENTAS Define-se quais serão as plataformas de software e a ambientação de hardware a ser utilizada para o desenvolvimento.

4 Além desses três primordiais conceitos, é missão do engenheiro de software utilizar os modelos de desenvolvimento visando abranger tarefas de fundamental importância para desenvolvimento do software: documentação técnica, definição do escopo, medição, seleção de ferramentas CASE, elicitação de requisitos, programação do código, verificações, testes, validações e outras revisões no intuito de aprimorar o software já existente.

5 Modelo Cascata (Clássico); Modelo de Prototipação; Modelo RAD (Rapid Application Development); Modelos Evolutivos: Modelo Incremental; Modelo Espiral; Técnicas de Quarta Geração (4GT).

6

7 Utilizado principalmente quando os requisitos de um determinado problema são bem compreendidos; Utilizado, também, quando o modelo cascata quando um software necessita de uma nova funcionalidade e os requisitos estão bem definidos e são estáveis; Sugere uma abordagem sequencial e sistemática para o desenvolvimento de software;

8 Trata-se do paradigma mais antigo da engenharia de software. Porém, mesmo sendo bastante antigo e ainda utilizado na indústria esse processo recebe muitas críticas que gerou questionamentos sobre a sua eficácia até mesmo pelos seus maiores defensores; Os principais problemas encontrados no modelo cascata são: Os projetos de software reais construídos e evoluídos na indústria de software raramente seguem o fluxo sequencial que o modelo prega;

9 É muito raro e difícil para o cliente saber e estabelecer explicitamente todas as suas necessidades. O modelo cascata é muito fortemente baseado nisso e tem dificuldade para adequar a incerteza natural que existem no inicio dos projetos; O cliente precisa ter muita paciência, o que raramente acontece. Uma versão operacional (pronta para ser executada no cliente) não estará disponível até estarmos próximo ao final do projeto. Se tivermos um erro grave nas etapas iniciais, como uma especificação mal compreendida e mal especificada, podemos ter um resultado desastroso.

10 Análise Econômica: visa a estabelecer se o projeto de Software gerará lucro, e se a receita gerada será o suficiente para cobrir os custos; Análise de Requisitos do Software: visa a extração dos requisitos através de interações e técnicas empregadas para com o cliente contratante do processo;

11 Especificação: é a tarefa de descrever precisamente o software que será escrito, preferencialmente de uma forma rigorosa, a fim de abranger a todos os detalhes necessários para a equipe de desenvolvimento; Arquitetura de sistema: remete a uma representação abstrata; é concernente à garantia de que o sistema de software irá ao encontro de requisitos do produto, como também assegurar que futuros requisitos possam ser atendidos; A etapa da arquitetura também direciona as interfaces entre os sistemas de software e outros produtos de software, como também com o hardware básico ou com o sistema operacional.

12 Implementação / Codificação: a transformação de um projeto para um código deve ser a parte mais evidente do trabalho da engenharia de software, mas não necessariamente a sua maior porção; Teste de partes do software: diversas atividades de testes são executadas a fim de se validar o produto de software, testando cada funcionalidade de cada módulo, buscando, levando em consideração a especificação feita na fase de projeto. O principal resultado é o relatório de testes, que contém as informações relevantes sobre erros encontrados no sistema, e seu comportamento em vários aspectos.

13 Testes de Software: Caixa Preta: O analista não tem acesso ao código fonte e desconhece a estrutura interna do sistema; Também conhecido como teste funcional, pois é baseado nos requisitos funcionais do software; O foco, nesse caso, é nos requisitos da aplicação, ou seja, nas ações que ela deve desempenhar; Caixa branca: O analista tem acesso ao código fonte, conhece a estrutura interna do produto sendo analisado e possibilita que sejam escolhidas partes específicas de um componente para serem avaliadas; Também conhecido como teste estrutural, é projetado em função da estrutura do componente e permite uma averiguação mais precisa do comportamento dessa estrutura;

14 Testes de Software: Caixa Cinza: Testa-se um ou mais componentes combinados funcionam de maneira satisfatória; Combinam-se os conceitos dos testes de caixa preta e de caixa branca, pois o analista possui tanto conhecimento interno e externo do sistema quanto possui, também, a obrigação de testar a interface e realizar a correção no código, tendo para tanto capacidade para isso. Outros testes de software: de configuração; de instalação; de integridade; de segurança; de unidade; de volume; de desempenho; de usabilidade; de regressão e de manutenção (Fonte:

15 Suporte / Treinamento: Grande porcentagem dos projetos de software falham pelo fato de o desenvolvedor não perceber que não importa quanto tempo a equipe de planejamento e desenvolvimento irá gastar na criação do software se ninguém da organização irá usá-lo; As pessoas ocasionalmente resistem à mudança e evitam aventurar-se em áreas pouco familiares; Como parte da fase de desenvolvimento, evidencia-se a necessidade do treinamento para os usuários do software, alternando o treinamento entre usuários neutros e usuários favoráveis ao software; Usuários irão ter muitas questões e problemas de software os quais conduzirão para a próxima fase.

16 Manutenção e melhoria: Lidam com a descoberta de novos problemas e requisitos; Normalmente, toma mais tempo que o gasto no desenvolvimento inicial do mesmo; Não somente pode ser necessário adicionar códigos que combinem com o projeto original, mas determinar como o software trabalhará em algum ponto depois da manutenção estar completa; Requer um significativo esforço por parte de um engenheiro de software;

17 Manutenção e melhoria: Uma pequena parte dos engenheiros de software trabalha na correção de erros; A maioria das manutenções é para ampliar os sistemas para novas funcionalidades, as quais, de diversas formas, podem ser consideradas um novo trabalho; São previstas, para esta etapa, manutenções corretivas, preventivas e preditivas.

18 MEDEIROS, H., Introdução ao modelo cascata; disponível em: Pressman, R. Engenharia de Software: Uma abordagem Profissional. 7º edição. Editora Bookman.