Parabéns, você é um desenvolvedor independente competente . Desde o seu início humilde, talvez trabalhando como um testador, você progrediu para um desenvolvedor de equipe, depois um desenvolvedor sênior, e agora você deu outro salto, o maior de todos, para trabalhar diretamente com os clientes.

Mas onde as outras transições foram lineares, esta última foi exponencial. Enquanto no passado você recebia ordens de um empregador que trabalhava com clientes ou estava no negócio de software, agora todas as responsabilidades que antes eram distribuídas entre testes de especialistas, gerenciamento de programas, etc., são todas suas. E agora você está trabalhando com clientes que não estão no negócio de software; eles estão em outro negócio que precisa de um software e não têm uma visão clara e precisa do que querem de você. Este é um desafio muito maior do que parece.

* Nota: * Aqui, estou descrevendo clientes menores que querem um exército de um homem de seu desenvolvedor. Não é o único caminho que um freelancer pode seguir, e esses não são os únicos clientes com quem trabalhamos no ApeeScape, mas é o caminho que mais gosto. Claro, se você está trabalhando em equipe e não por si só , alguns dos itens abaixo não se aplicam. Por exemplo, se você estiver usando Metodologias ágeis ou Scrum , você provavelmente desejará estruturar seus marcos de maneira um pouco diferente.

Desde seu começo humilde, talvez trabalhando como testador, você progrediu para um desenvolvedor de equipe, depois um desenvolvedor sênior, e agora deu outro salto, o maior de todos, para trabalhar diretamente com os clientes.

Todos vocês já ouviram sobre a suprema importância da comunicação. Você não pode trabalhar obtendo algumas frases de descrição concisa no Skype e dizendo 'Vejo você em três meses, quando eu terminar.' Você tem que estar em comunicação com o seu cliente e, em cada fase do seu trabalho, certifique-se de ter ideias congruentes sobre o objetivo, porque é raro um cliente enviar wireframes e uma especificação funcional detalhada. Você terá uma ideia muito geral do que o software deve fazer, se parecer e fluir. Se você escrever um aplicativo com base na descrição superficial com a qual costuma começar, quase não há chance de que seu cliente fique satisfeito com o resultado. Em cada estágio, você deve iterar seu caminho mais perto de um acordo.

Você não pode trabalhar obtendo algumas frases de descrição concisa pelo Skype e dizendo 'Vejo você em três meses, quando terminar'.

Tendo trabalhado por anos em empresas que estavam no negócio de software, onde todos na equipe eram da mesma cultura, falavam a mesma língua nativa, trabalhavam no mesmo corredor, encontravam-se diariamente, etc., era notável que o companhia ainda não conseguiu o que queria na metade das vezes. Não se engane: o desafio aqui é enorme.

Por que os documentos de design de software são importantes

Então, quando você assume um novo projeto, antes mesmo de abrir o Xcode ou Visual Studio, você precisa ter objetivos de design claros e combinados . E essas metas devem ser estabelecidas em um documento de especificação. Se o cliente não escreveu um, você deve escrevê-lo e enviá-lo para revisão antes mesmo de abrir seu IDE. E se você encontrar um cliente que diz: 'Não temos tempo para documentos de design', francamente, você deve sair do projeto porque você tem problemas pela frente. A especificação não precisa ser particularmente longa; pode ter apenas algumas páginas, mas no mínimo deve definir a interface do usuário, incluir wireframes (se houver um componente de IU) e definir marcos de conclusão.

Sem este documento, você acabará em um loop de equívocos amargos, clientes contestando o que eles disseram a você ou o que você disse a eles, com raiva enviando recortes e pastas de comunicações anteriores, interpretando e argumentando até chegar o momento em que o cliente exige que você faz alterações para deixar o aplicativo em conformidade com “o que eles realmente pediram” e espera que você faça essas alterações sem pagar.

Com Neste documento de design de software, você terá uma resposta para qualquer reclamação: quando surgirem divergências, você pode consultar a especificação que o cliente concordou e assinou, apontando que você a cumpriu à risca. Em vez de argumentos raivosos, você fará alterações e esclarecimentos ao documento. Na verdade, o cliente pedirá desculpas por deixar a imprecisão passar.

Todos nós queremos clientes satisfeitos. Todos nós queremos uma relação de trabalho amigável. E todos nós queremos o orgulho de um trabalho bem executado. Mas isso não pode ser alcançado se houver alguma imprecisão sobre o que o trabalho realmente é . Se o seu cliente disser que um documento de design é muito trabalho extra, é seu trabalho explicar a eles que o real trabalho extra surgirá quando revisões precisarem ser feitas devido a algum tipo de mal-entendido. Se o cliente ainda insiste em que você avance sem tal documento, você deve aceitar o fato de que tem um relacionamento inviável e ir embora.

O que a especificação de design de software deve realmente especificar?

No mínimo, deve ser uma descrição da aplicação desejada, critérios de conclusão e marcos. Lembre-se de que você está compartilhando o que é melhor descrito como um documento de requisitos e funções, não uma especificação de implementação. E, a menos que uma implementação específica seja um objetivo declarado do cliente, você decide como fazê-la funcionar.

Interface de usuário

A maioria dos projetos são aplicativos, não bibliotecas ou estruturas. Mas se acontecer de você ter um desses como entrega, considere-se com sorte porque a interface do usuário é de longe o componente mais problemático do seu modelo de documento de design , e quase sempre leva a mal-entendidos. Muitos clientes enviarão a você ilustrações perfeitas criadas em um editor gráfico por um designer gráfico que não é um programador. Mas o problema é: essas ilustrações não dizem nada sobre animações, estados de controle (por exemplo, este botão está desativado? Ele desaparece quando inutilizável?) Ou mesmo quais ações devem ser executadas quando um botão é pressionado.

Muitos clientes enviarão a você ilustrações perfeitas criadas em um editor gráfico por um designer gráfico que não é um programador. Mas essas ilustrações não dizem nada sobre animações, estados de controle ou até mesmo quais ações executar quando um botão é pressionado.

Antes de começar a escrever o código por trás dessas ilustrações, você deve ser capaz de responder a todas essas perguntas. Especificamente, você deve saber:

1. Os controles estão sempre visíveis e / ou ativados? Sob quais condições seus estados mudam?
2. Parece um bitmap - é um botão?
3. Que transições ocorrem entre esses estados e visões? E como eles devem ser animados?

Se depender de você gerar a IU para a simultaneidade do cliente, faça o mesmo ao contrário: use uma ferramenta wireframe e crie um conjunto completo de layouts de tela, incluindo quaisquer variantes que as visualizações mostrem em diferentes estados do aplicativo. Isso pode ser um trabalho exaustivo e tedioso, mas você não vai se arrepender - pode evitar que você reescreva grandes quantidades de código e recrie interfaces devido a um pequeno mal-entendido com grandes implicações. Se você estiver criando um aplicativo duplo (por exemplo, para ambos Iphone e iPad), crie wireframes separados para ambos.

As dimensões da tela também são importantes. Existem (no momento) três tamanhos de telas do iPhone. Wireframes separados para telas de 3,5 ”e 4” são provavelmente excessivos, mas você pode ter que criá-los; na maioria dos casos, você pode simplesmente alterar as proporções.

Se o seu cliente fornecer gráficos, certifique-se de que eles sejam dimensionados corretamente com as proporções adequadas; transformar qualquer bitmap que contenha texto ou objetos (como círculos) introduzirá distorções. Se eles não corresponderem, diga ao cliente para recriá-los com tamanhos correspondentes. Não presuma que você pode esticar uma tela inicial de 3,5 'em uma abertura de 4' e apenas rolar com ela.

Funcionalidade

Principais perguntas a serem feitas no documento de design do aplicativo:

• O que o aplicativo faz e com que rapidez?
• Quais são as possíveis condições de falha e como são tratadas?
• Quais operações únicas são feitas na primeira execução (ou seja, após a instalação)?
• Se o usuário criar entradas de qualquer tipo (por exemplo, favoritos), quais são as limitações?

Generalize essas ideias e seja o mais detalhado e completo possível - porque erros ou mal-entendidos aqui significarão reescrever o código.

Milestones

Seu modelo de especificação deve apresentar marcos claros. Se o seu cliente escrever o design funcional e de interface do usuário, você deverá concordar posteriormente com um conjunto de marcos. Às vezes, esses também são limites de faturamento, mas pelo menos fornecem uma métrica clara para a conclusão. Os marcos podem ser em termos de funcionalidade e / ou componentes; eles podem até ser aplicativos separados se o show envolver um conjunto de produtos. Quando possível, os marcos devem ter aproximadamente a mesma duração.

Exemplo de especificação de design de software

Aqui, vou fazer o layout da estrutura de exemplo de um documento de design adequado. Claro, este modelo deve ser ajustado conforme necessário. Para outro exemplo, veja Amostra de especificação de Joel Spolsky , baseado em este artigo . Ele aborda o documento de maneira um pouco diferente, mas compartilha um sentimento semelhante.

que cores fazem as pessoas se sentirem

Declaração de Metas

Inclua um pequeno parágrafo descrevendo o projeto e seu público-alvo.

Descrição Funcional

O que o aplicativo Faz ? Quais estados do aplicativo (descrições de alto nível dos principais cenários do usuário) o usuário encontrará?

Por exemplo, sua descrição funcional pode ser assim:

• Primeira corrida
• Criação de um novo _____ (jogo, pesquisa, etc.)
• Operações
• Comportamento de segundo e primeiro plano

Interface de usuário

Inclua wireframes para cada página, com descrições detalhadas de:

• Cada controle, incluindo estados (habilitado / desabilitado / destacado) e operações.
• Orientações e transições com suporte entre eles.
• Funcionalidade representada.
• Manipulação de erros.
• Dimensões e restrições.

Aqui estão os wireframes relacionados ao meu aplicativo iOS mais recente, NotifEye:

Se você estiver interessado, fiz essas maquetes usando Ferramenta de wireframe de Balsamiq .

Por exemplo, seu Descrição da interface do usuário pode ser parecido com:

• Barra de navegação
  • Controle de navegação esquerdo: retornar à página inicial
  • Barra de título: tela atual ou nome da operação
  • Novo botão: criar uma nova coisa
• Vista de mesa
  • Seção 0: título da seção
  • Seção 0 linhas:
    • Controle de linha 0 (por exemplo, imagem)
    • Linha de Texto 0
    • Linha de Texto 2

Milestones

Conforme descrito acima, prazos para conclusão e resultados esperados.

Por exemplo, a seção de marcos em seu modelo de documento de design pode ser semelhante a:

1. Aplicativo de fachada mostrando tela e com transições temporárias e imagens / texto de exemplo
2. Protocolo de comunicação: o aplicativo se conecta à rede / servidor
3. Marco funcional 1: ...
4. Aplicativo Alpha (com funcionalidade total)
5. Estabilidade
6. Lançamento

Certificando-se de que a documentação do software continua relevante

Não quero dizer que a fase de design acabou depois que você e seu cliente concordaram com um documento de especificação. Sempre haverá detalhes que nenhum de vocês considerou, e você e o cliente irão, ao olhar para os resultados intermediários, encontrar novas ideias, mudanças de design, falhas de design inesperadas e sugestões impraticáveis.

O design irá evoluir e as alterações devem ser capturadas em seu documento. Em meus 25 anos de experiência, nunca trabalhei em um projeto onde isso não acontecesse - e isso inclui meus próprios aplicativos (ou seja, onde eu era meu próprio cliente). Mesmo assim, criei um documento de design com especificações detalhadas e ajustei conforme necessário.

Acima de tudo, mantenha contato. Pelo menos várias vezes por semana, entre em contato com seu cliente, relate seu progresso, peça esclarecimentos e certifique-se de compartilhar visões idênticas. Como um teste decisivo para sua comunicação, tente e certifique-se de que você e seu cliente dão o mesmo respostas a estas três perguntas:

1. No que o desenvolvedor estava trabalhando?
2. No que o desenvolvedor está trabalhando atualmente?
3. No que o desenvolvedor trabalhará a seguir?

Compreender o básico

O que significa a sigla SDD?

SDD significa documento de design de software ou descrição de design de software.

O que é um documento de design funcional?

Um documento de design funcional descreve os recursos, a aparência e as funções de um produto de software de que ele precisa para executar. Os documentos de design também são chamados de especificações funcionais ou documentos de especificações funcionais (FSDs) ou especificações de requisitos funcionais.

O que é um documento de design de alto nível?

Um documento de design de alto nível (HLDD) descreve a arquitetura usada no desenvolvimento de um produto de software específico. Geralmente inclui um diagrama que representa a estrutura prevista do sistema de software. Como este é um documento de alto nível, frequentemente é usada linguagem não técnica.

O que está em um documento de design de software?

O documento de design de software (SDD) geralmente descreve o design de dados de um produto de software, design de arquitetura, design de interface e design de procedimento. O conteúdo e a organização de um SDD são especificados pelo padrão IEEE 1016.