Software design

If we had planned an article that would not be of interest to anyone, then we would probably write about the importance of designing buildings before building them. But, fortunately, any person understands why you should not build houses by eye, adding features right during the construction process. When developing software, it is still useful to remind that it should be started with design - i.e. with full planning of what we need to develop directly, at what time, with what source data and the expected result.

Over 13 years of experience of the company "Edison" in outsourcing development for medium and large companies from Russia, USA, Europe and Australia, we have developed our own software design scheme, which we will discuss in this post.

Why do you need software design

Having determined the software requirements, the developer gets an agreed clear action plan, payment schedule and deadlines, reduces development time and improves its quality, and also allows for any other nuances of development, for example, legal ( in particular, transfer of software copyright to software ).

By designing software in advance, the developer is able to:

estimate the cost and development time of a software product,
eliminate the loss of time and money on unnecessary actions, forced modifications, long coordination,
avoid disagreements and dissatisfaction of the client and the performer.

Preparatory stage

Depending on the specifics of the project, the order of software development may differ, but in general, it is:

In preparing for the design, organizational issues are resolved:

what the client can provide (TK, layouts, design), how sufficient the source code is and what stages close - this is how the scope of work is determined,
budget and deadlines: based on the available materials, the estimated cost, the duration of the entire project, as well as the deadline and exact cost of the next stage are approved.

Now you can sign a contract, receive a prepayment and all the necessary materials for the work.

Stages and results of design

Description: Customer collaboration (talking about product benefits, performance requirements, and appearance) and EDISON (offering technical and algorithmic solutions).
Architecture: programming language, database, servers, and frameworks are established.
Technical task: compiled by the architect on the basis of the description and answers of the customer to the questions, agreed with the project manager, then transferred to the client, edits are made.
Layouts (added to the technical task): interfaces, schematic diagrams of the device, diagrams of the database structure, diagrams of the interaction of components.
Control: the architect eliminates the comments of the project manager.
Approval: the customer checks and changes the TK independently or informs the list of edits to the project manager, the comments are eliminated, the TK is approved and attached to the contract.

As a result of the design, we get a technical task with clear and unambiguous for the customer and the contractor (project manager, programmers, testers, designers and other participants in the development process) by illustrating the answers to the questions:

What do we do (description of the product, functionality, users)?
How are we doing (architecture)?
How to verify that the goal is achieved (testing, evaluation criteria)?

Theoretically, if at the preparatory stage the client can immediately provide the design result in accordance with these requirements, the design phase can be omitted and immediately proceed to the free evaluation of the project . However, so far there have been no such cases in our practice.

Requirements for software specifications

The minimum sufficient TK should:

describe the future software product completely, clearly (instructionally, without water, the possibility of discrepancy) and structured (how it should look, how and with what to work, what requirements to meet) and the process of its development so that the architect has no questions about implementation,
exclude conflicting information
to be legally accurate (follow GOST 34.602-89), since, together with the contract and other documents, TK acquires legal force.

Terms of Reference should contain:

general information about the project (the name of the product, by whom and for what it will be used);
general software requirements (for the structure, functions, in particular, attach an architecture diagram and describe the connection of subsystems, the types of interfaces of all components for each of the user roles - the finished design or its concept);
detailed work plan (list of stages, deadlines for them);
the order of testing and acceptance (types and composition of tests of the product as a whole and of individual parts);
list of actions to launch the product;
requirements for documenting the process and outcome of development.

As part of the TZ should pay attention to the description:

details:
- users of the software product: roles, rights and functions
- description of data processing algorithms,
- list of open and closed protocols,
- data security requirements throughout the life cycle,
- list of components (paid, free) to be used in the development,
examples:
- in the presence of analogs, integrable systems, references to them are indicated,
- In the description of the system, a description is given of typical scenarios of user interaction with it,
- examples of incoming data and data format of the interaction of subsystems (tables, databases, pages, etc.),
- examples of outgoing data (types of reports and exported files),
performance and reliability:
- indication of system load levels (day, month, maximum),
- performance requirements, security,
- justification of the choice of equipment for launching software,
- indication of server hosting.

Examples of technical specifications for software development

Naturally, the more complex the project, the longer and more expensive the preparation for it. Designing small projects takes from a week to a month. To make the process go faster and cost less, we provide customers with on-demand instructions for drawing up the technical specifications and examples of finished technical tasks. We give examples here.

TK software Protector

Object TZ: development and integration with the existing system of modular software for monitoring remote security devices
Customer: VTIMB LLC

Terms of Reference for the security platform Protector from EDISON Software Development Center

Option in pdf

Scenarios for the use of the educational system

Object TK: the creation of an educational system

Usage scenarios from EDISON Software Development Center

Option in pdf

TZ for software development SMPP-gateway

Object TZ: software development SMPP-gateway
Customer: IMT

TZ on SMPP gateway from EDISON Software Development Center

Option in pdf

During the development of TK, as in the last case, we will necessarily visualize the main points in the form of diagrams, diagrams, model business processes, create interface layouts, perform TK in Russian or English at the request of the client.

Design - for big guys

Over the years we have written hundreds of technical specifications for software development of varying degrees of complexity, and we understand that the role of developing detailed TK is difficult to overestimate. Sometimes, we worked with the TK on more than 1000 pages, and for large projects this is justified and necessary. Nevertheless, we should not forget about the principle of expediency - it makes no sense to write a TK of 20 pages for a two-day product development.

Any comments on our methodology or would you like to share your experience? We will be glad to talk in the comments, in our group on Facebook or Vkontakte .