ESOF

Preâmbulo: Inovação

• Engenharia de software é a base da inovação;
  
  Estratégia de Avaliação:
• Trabalhos semanais: 5-10 pontos. (40 pontos)
• Trabalho final: 60 pontos.
• ESOF envolve métodos e técnicas para
• O desenvolvimento de software:
• especificação, modelagem, arquiteturas, verificação e testes de software;
• planejamento e gerenciamento do processo de desenvolvimento.
• ESOF:
• Sistematizar o desenvolvimento através de modelos, técnicas e ferramentas para o produto e para o processo.

Num primeiro momento, deve-se entender, junto com o cliente o problema a ser solucionado e os requisitos para isso.

Investimento balanceado em equipe, material e metodologia garantirá o sucesso na engenharia de software.

Aula 2

Escopo: Fronteira que define o que é objetivo do software e o que não é.

Causas para falhas:

• Não dedicamos tempo para coletar dados sobre o desenvolvimento, resulta em estimativas "a olho";
• Comunicação fraca entre cliente e desenvolvedor

Processo de Software Genérico:

Ciclo de vida clássico ("Waterfall" ou cascata)

Abordagem Inicial:

• Análise
• Especificação
• Design
• Implementação
• Teste
• Operação

→ Impossibilidade de volta, se falhar é necessário recomeçar todo o processo.

→ Só se consulta o cliente no início do processo e não ao longo de todo o processo.

Abordagem Incremental:

• O autor executa múltiplas fases de projeto, testes e manutenção

Abordagem Evolucionária:

Foco na análise de risco (produto muito inovador)

Trabalho - Paradigmas, mitos, crise de software.

1) Qualifique as etapas do processo de desenvolvimento de software, com uso do modelo cascata. Explique cada fase e os documentos resultantes de cada etapa.

Eng. Sistemas → Estabelecimento de requisitos com envolvimento de diversos profissionais.

Análise → Compreensão do domínio da informação para o software, função/desempenho e interface exigidos. Ocorre a documentação de requisitos.

Projeto → Concentração em estrutura de dados, arquitetura do SW, detalhes procedimentais e caracterização da interface.

Codificação → Tradução do projeto em código, legível para o computador.

Testes → Concentração em aspectos lógicos do software, garantia da execução, análise de aspectos funcionais externos e detecção de erros.

Manutenção → Mudanças para adequação/correção de erros/melhorias/acréscimos funcionais.

2) Apresente, por meio de um texto, as características da Engenharia de Requisitos (comente sobre escopo, domínio do problema etc).

Ao primeiramente contatar um usuário e nos informarmos da ideia para o software, temos uma ideia do domínio do problema. Essa primeira ideia é geral, muitas vezes confusa e com funcionalidades que muitas vezes o próprio cliente não sabe definir. Usamos os processos de engenharia de requisitos para fazer o levantamento de requisitos e dividir todo esse domínio do problema em múltiplas funcionalidades, denominadas requisitos. O conjunto de todas as funcionalidades e requisitos do programa é chamado de escopo e ao terminarmos de definir todos esses passos, saímos do domínio do problema e entramos no domínio da solução.

3) Um gerente-geral de uma cadeia de lojas de presentes acredita que o único objetivo da construção de um protótipo é entender os requisitos do usuário e que depois esse protótipo será descartado. Portanto, ele acha bobagem gastar tempo e recursos em algo que será desprezado mais tarde. Considerando essa relutância, resolva as seguintes questões: a ) Compare brevemente o protótipo descartável com o desenvolvimento espiral (ou com o modelo cascata) de forma que o gerente compreenda o que um protótipo pode significa? b) Na sua opinião, o que poderia ser utilizado para convencer o gerente que a prototipação é uma estratégia eficiente?

a) No desenvolvimento em cascata, temos várias etapas subsequentes e, após análise, fazemos um projeto que se tornará futuramente código. Dessa forma, o cliente só terá acesso ao software em sua fase final. Usando o modelo de prototipação, logo após a coleta de requisitos, temos uma etapa de projeto rápido, construção de protótipo e avaliação do protótipo pelo cliente, fazendo com que o cliente se torne mais presente no processo de desenvolvimento, aumentado as chances do projeto ser bem-sucedido.

b) Na minha opinião, para provar que a prototipação é uma estratégia eficiente, basta mostrar algumas estatísticas de usabilidade. Alguns exemplos são:

88% dos consumidores online alegam menos chance de retornar a um site depois de uma experiência de uso negativa.

Julgamentos dos usuários sobre a credibilidade de um site estão 75% baseados na qualidade estética do site.

Dessa forma, tendo em vista que essas estatísticas são similares para outros tipos de software e que as taxas de sucesso em projetos de TI é baixa, devemos tomar todos os cuidados e fazer todas as validações de usabilidade possíveis para garantir uma experiência melhor para o usuário e, consequentemente, mais lucro por conta da retenção.

4) Os acidentes relacionados com o Boeing 737Max, ocorridos há pouco tempo, evidenciam problemas com o Software. Sugira um outro exemplo de "crise de software", com cunho temporal próximo.

Outro bom exemplo de crise de software foi um software de radiação, em meados dos anos 2000, desenvolvido pela empresa Multidata. Ele calculou mal a dosagem de radiação que deveria ser enviada, expondo pacientes a níveis fatais de radiação. Os físicos que foram indicados para checar as máquinas foram condenados a morte. A causa foi que o software calculava a dosagem de radiação baseando-se na ordem de entrada dos dados, e algumas vezes enviava o dobro da dose do que deveria. Nesse desastre, 8 pessoas foram mortas e 20 pessoas ficaram seriamente feridas.

1) Sobre o Rational Unified Process – RUP, caracterize e explique a importância dos elementos relacionados aos símbolos que aparecem a figura abaixo:

Na figura, temos diversos aspectos essenciais para o desenvolvimento de software feito com qualidade. Começamos com a captura de um vocabulário comum entre cliente e stakeholders fazendo um glossário para podermos, futuramente, desenvolver um plano de gerenciamento dos requisitos. O plano de gerenciamento dos requisitos vai conter as solicitações de funcionamento do software, ou seja, tudo o que o software precisa para funcionar idealmente, de acordo com o cliente.

Iniciamos com uma busca de modelos de caso de uso, onde sistemas e aplicações similares foram feitas. Após isso, temos a criação da visão inicial, um primeiro esboço sobre como será a ferramenta, feito para o cliente analisar, sugerir mudanças e ser refinado.

Com a visão refinada, inicia-se a fase de desenvolvimento, sempre junto ao cliente para garantir que os aspectos desejados pelo cliente serão totalmente cobertos.

2) A figura representa o fluxo de trabalho do RUP, divido em fases iterativas. Caracterize cada uma das fases, destacando seus produtos, papéis e atividades, quando possível.

Concepção → Define o escopo do software juntamente aos stakeholders. É realizada em um curto período e orienta a equipe para uma análise de viabilidade e primeiros passos.

Elaboração → Planeja o projeto, especifica features define e valida a arquitetura. Aqui temos o levantamentos de casos, documentação, estudos bases e outros modelos possíveis para orientar o projeto. Após a busca, temos a elaboração de um plano de projetos, com todas as características e especificações de forma bem detalhada.

Construção → Constrói o produto. Nessa etapa, além do código, são realizados os primeiros testes para que a base esteja pronta para a próxima etapa.

Transição → Implementação do software. Esse é o ponto onde o software passa da fase de testes e entra na implementação. Além disso, temos a entrega do projeto, disponibilizando-o para o usuário final.

Evolução → Aprimora e mantém o software atualizado e funcionando. Aqui, depois de certo tempo acompanhando o funcionamento do software, são realizadas melhorias para manter a estabilidade e aprimoramentos funcionais caso o cliente deseje, reiniciando as etapas para um escopo menor.

3) Elabore, para a proposta apresentada pelo grupo, o conjunto de casos de uso relacionado com o sistema a ser desenvolvido.

Atores do Projeto

Usuário

Casos de Uso

Gravação do Áudio

Modificar Áudio

Escolher a Modificação Atribuida ao Áudio

Reproduzir o Áudio

Reproduzir Múltiplos áudios simultaneamento

Listar Áudios

Importar áudios já existentes

Exportar algum áudio

Salvar o Áudio

Exceções do Projeto

Para (Reproduzir o áudio) é necessário que exista um áudio na lista ou seja originário da (Gravação do Áudio)

Para (Reproduzir Múltiplos áudios simultaneamento) é necessário que exista mais de um áudio gravado

Para (Modificar o áudio) é necessário que exista um audio na lista ou seja originario da (Gravação do Áudio)

Para (Exportar algum áudio) é necessário que exista um áudio na lista ou seja originário da (Gravação do Áudio)