Top 10 desafios na engenharia de software - Blog CMMI & MPS.Br

Top 10 desafios na engenharia de software

By on August 25, 2012

1. Relacionando requisitos e arquiteturas

É evidente que a arquitetura não pode ser diretamente derivada (por refinamento ou outros meios) a partir de uma especificação de requisitos. Por outro lado, a identificação e preparação de uma arquitetura adequada não é independente das necessidades dos requisitos que ela deve servir. A relação acontece em ambos com a arquitetura agindo como um quadro para a elicitação de requisitos e moldando o espaço de possibilidades que são oferecidas pelo sistema. Este complexo e entrelaçado co-desenvolvimento de arquitetura e requisitos está no cerne do desenvolvimento de software e, embora a observamos, não a entendemos ainda. Este é o primeiro grande desafio para a engenharia de software.

2. Aprender a evidenciar as coisas

Para boa parte da comunidade de software, isto parece meio surrerreal, é quase que um palavrão. O que é mais aceito é uma adaptação como “algumas evidências”, onde cada um define o seu “algumas”. Poucas decisões importantes como a definição da arquitetura se baseia em fundamentos e evidências. As pessoas lembram-se das “evidências” apenas na hora dos problemas como “eu não pedi isso que você fez” ou “pra mim isso estava pré-entendido” e outros. De uma certa forma, podemos dizer que a não há muita cultura em documentar e aprovar na engenharia de software. Isso é inaceitável em uma disciplina que aspira a ciência da engenharia. Temos de reconstruir a engenharia de software em torno de uma prática baseada em evidências.

3. Escalabilidade

Cada vez mais somos obrigados a construir “em escala Internet” serviços que devem lidar com variações muito grandes e rápidas na demanda por recursos. O que é feito hoje é bem pobre. O sistema é colocado em produção e “arrumado” toda vez que cai. Arruma-se um código, coloca-se mais memória, um novo servidor, enfim como muitos dizem: as coisas “vão acontecendo”. Obviamente isso sai muito mais caro do que planejar o sistema, sua carga e projeção de crescimento.

4. Tratando divergência semântica

Operamos em um contexto em que os padrões de modelagem e troca de informações é muito importante. Infelizmente padrões de engenharia de software, principalmente promulgada pela OMG, e padrões web, principalmente promulgadas pelo W3C, foram movendo-se em diferentes direções incompatíveis. A ideia de que as representações (semântica) em “tempo de execução” deve ser diferente para as representações (semântica) em “tempo de desenvolvimento” parece errado e perda de tempo. É precisamos tratar essa divergência.

5. Estimativas confiáveis

Somos péssimos quando respondemos a primeira pergunta de nossos clientes: “quanto isto vai me custar”. A engenharia de software já resolveu este assunto há muito tempo, mas não nos sentimos seguros em passar uma estimativa de custo e prazo, aliás, muitos de nós tem pré-definido que um projeto de software não tem escopo ou custo definido. Até podemos ser felizes quando desenvolvendo algum sistema simular ao que já foi desenvolvido no passado, mas quando é diferente as estimativas normalmente falham. A análise de pontos por função, que é o estado da arte nas estimativas de software ainda é pouco usada. Há outros métodos mas que normalmente só tem êxito em pequenos projetos. A parte financeira é extremamente ligada ao tamanho do software e é por isso que precisa ser totalmente repensado. As estimativas precisam ser confiáveis e terem um nível de precisão mais adequado. Por fim, integrar a gerencia de custos a engenharia de software irá definir um novo padrão.

6. Engenharia de software na nuvem

Nós sabemos como construir Software-as-a-Service (SaaS), vemos como “mais um programa”. No entanto, não sabemos como: comprar, gerenciar QoS (Quality of Service) ou alcançar a interoperabilidade entre as ofertas de SaaS. SaaS não é simplesmente “mais uma arquitetura de software”, está vinculada e um novo conjunto de modelos de negócio e exige uma abordagem diferente da engenharia.

7. Criação de “Apps”

A mobilidade já é uma realidade e a engenharia de software evoluiu muito neste novo mundo. Não se vendem mais celulares e sim smartphones. Os tablets, liderados pelo iPad são cada vez mais comuns no nosso cotidiano e com isso se abriu um mercado enorme para Apps (Aplicativos para Smartphones e Tablets). Essa nova onda, iniciada praticamente com o iPhone, mudou substancialmente o jeito com que os serviços são consumidos. Os serviços podem ser acessados à qualquer momento, em qualquer lugar e com isso vem a necessidade de alta disponibilidade, multi-plataforma e user interface agradável. Novos modelos de remuneração foram criados, mas tudo ainda é muito novo. Há muitos desafios para a engenharia de software e por ser um “mundo novo” requer atenção e quem fizer primeiro se destaca.

8. Desenvolver sistemas “adaptáveis”

Temos problemas em desenvolver sistemas robustos em um ambiente de constante mudança onde você pode disponibilizar um sistema sob COTS e ainda assim, permitir a abertura para scripts, plug-ins e componentes externos por exemplo. Em suma, podemos dizer que o problema é desenvolver o tipo de sistemas que somos chamados para desenvolver todo dia. Nossa engenharia precisa desenvolver modelos e métodos para a montagem de sistemas que possam se adaptar dinamicamente ao contexto.

9. Reconstruindo Governança

Basicamente a governança é a gestão da gestão, é garantir que estamos fazendo aquilo que dissemos que iriamos fazer e é impressionante como temos a tendência de repetir os mesmos erros do passado. Mais especificamente em repedir os erros que já entendemos como erros e já temos conhecimento mais do que necessário para evitar tais erros (exemplos do conhecimento: PMI, CMMI, MPS.Br, Cobit, etc). Somos levados a isso muitas vezes pelo desalinhamento entre a engenharia de software e o negócio, e é neste ponto que há a colisão. Não há “bala de prata”, basta usar o conhecimento da comunidade.

10. Repensar a produção de software

O desenvolvimento de software não é mais uma coisa amadora (pelo menos não deveria ser) onde o usuário fala “quero isso” e você já sai programando. A maioria dos sistemas acessa informações em uma rede complexa de interdependências entre vários fornecedores de informação. Deve-se levar em conta que o sistema será uma parte de um “ecossistema” e para isso é necessário planejamento e estruturação.
Repensar o desenvolvimento de software requer uma nova disciplina que enderece o relacionamento entre o modelo de negócios e a engenharia de software.

About Washington Souza

Black Belt, Washington Souza tem mais de 10 anos de experiência com gestão. Participou de implantações em todos os níveis CMMI e MPS.Br A. Gosta muito de Six Sigma e gestão como um todo.

Leave a Reply

Your email address will not be published. Required fields are marked *