Software Planning 101 - Part 1/7

-

The Plan of a Software Solution

Why Software Planning?

In this article we are going to explore the need for software planning. Software planning is a term that is introduced to describe the software architecture, design and other related activities that happen before implementing the software. The details of software planning are not discussed here, as first the need for it will be discussed.

Multiple software solutions exists

Software is delivered in response to a request for some functionality or requirements that need to be fulfilled. When we would give the same functionality request to multiple developers then all developers will come up with a solution. As experience teaches us, not all developers, actually none of them, will deliver the exact same solution. What is being pointed out here, is that a single request has multiple software solutions.

Not all solutions are equal

Since the existence of the multiple solutions, as software scientist, your brain should start asking the question: does it matter what solution we pick - are they all equal or are there “better” solutions?

From a college experience: the same assignment was provided to all the students, and each student came up with his/her own solution. When discussing the different solutions, many new insights in how to program the solution are discovered. And definitely, there where solutions that were easier to write, maintain and/or understand.

From an industry experience: software engineers work on multiple projects and some of the projects are easy to work on. But there are often a few projects that always cause headaches when alter or extending the software. The headache is most of the time not to do with the specific requirements for the software, but with the specific implementation.

Planning eliminates bad solutions

So by omitting for now the discussion of “better”, we still can draw the conclusion that not all software solutions are equal. This is why there is a need for software planning. Without software planning you may end up implementing a solution that is so much more headache and frustration generating than necessary!

Defining Software Planning

Software planning is part of the software development lifecycle. The software development lifecycle is part of the bigger product lifecycle. It can only take place after the functionality has been formulated. The next step is to develop the User Experience: the interactions and user interfaces. In short, the product architecture, and user experience architecture, comes before the software planning.

Software planning itself exists of two parts: architecture and design. Software architecture is focussed on constructing the software in such fashion that future changes can be easily accommodated. After that, software design has another goal: how can we implement the software with low effort and minimum risk while granting the software architecture. Those two steps combined are the software planning.

Comments

Post a Comment

Popular posts from this blog

Analyzing Software: Technical, Tactical and Strategic Qualities

-
Building software always comes with significant investments, but should be only a fraction of the possible long term gains. To ensure the software yields the expected outcomes, not only for the first releases, the first two years, but long term, the software must be developed with different qualities. Long term? How many systems does your organization have, that are 3+ years old and are not limiting the potential capabilities of the company [without reinvesting/rewriting them]?. In this article a small framework to assess the quality of your software is presented. To ensure software is profitable for the company during its full potential, we analyze the software on 3 different levels: Technical, Tactical and Strategic. This can be the first step to improve the earn backs of your technology/software investments. Technical Quality When people learn how to program, the syntax of the language is explained. Next in detail is explained, how to do recursion, with the termination conditi
Read more

Principles of Software Quality Management

-
Image
Poor Man's Approach To start the conversation, let's first examine a wide spread idea of quality management: Quality is a compromise between Scope, Resources and Schedule (The Iron Triangle of Projects); and, Bugs must be prioritized based on Impact and Likelihood. Based on a metaphor it shows why the above idea is a very limited and an impractical approach to software quality management, and it allows us to immediately make two conclusions: software development is a society and QA is the hospital in that society; people that get ill are sent to the hospital to get cured. Quality is non-negotiable: letting people die is always unacceptable; Prioritizing won't improve anything: it won't reduce the number of people getting ill. Principles of Software Quality Management Quality of software is measured through bugs. There is no known or set formula to quantify the software quality, but what is measured is number of bugs and this is the basis to imply the quality. T
Read more

External Services Integration Strategies

-
In today's world, the systems you are developing are not isolated, they need many different integrations with other external services. From Authentication Systems (using SAML, LDAP, OIDC) to Data and Processing Systems (Malware Analysis, CRMs, Ticketing Systems). Although the number of actual systems to integrate with is vast, luckily the Use Cases and types of integrations are manageable. Here we will discuss popular Use Cases and list integration strategies to accomplish them. Use Case 1: Transfer the User from your System to the External Service In this scenario, the User is working in your system and is now required to access specific functionality in an External Service. The following steps must happen: the service must be located, the user must be authenticated, and the right interface/data must be presented. 1.1 Service Locator Integration Your system understands how to find the specific service, the user does not need to remember the location of the external service
Read more