Trabalho - Paradigmas, mitos, crise de software
Conteúdos
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.
- Testes → Concentração em aspectos lógicos do software, garantia da execução, análise de aspectos funcionais externos e detecção de erros.
- Codificação → Tradução do projeto em código, legível para o computador.
- Projeto → Concentração em estrutura de dados, arquitetura do SW, detalhes procedimentais e caracterização da interface.
- 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.
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.
Nome: Lucas Lima do Nascimento
Nº: 11721EMT014