Search This Blog

Software Planning 101: Part 7/7

Tangibles in Software Development

So far we have described what software decisions and trade-offs need to be made as part of creating a software solution. To make things more tangible, we will now focus on the tangibles involved in realizing a product.

Putting the Theory Together

We will also link the different topics we have discussed earlier together in this article: solution abstraction levels, code structure, execution localities and implementation technologies.

Product

The product is defined by business. A product defines the need for software and describes what functionality the software should provide. The product is defined in Business Product and Functional Product abstractions.

Software

Software represents what technology - read software solution - needs to be developed to provide the functionality of the product. This is described in Conceptual Architecture abstraction.

System

At next step the software is broken down into systems and systems into components. Each system has its own code repository and release cycle. How the breakdown happens is defined at Logical Architecture abstraction.

Module

A module is a unit used for implementing software. Modules are designed and implemented independently while remaining aligned with the logical architecture. How to implement a module is described at Technical Design abstraction.

Within a the design of a module the decisions are made about the finer code granularity scales: packages, files, classes and methods.

Code Archive

Modules are not directly exposed but assembled into useable code archives. If not done, we would hardwire our module structure of a system to external systems. Not only want we to remove the complexity of the module structuring, as they have no use of knowing, also it would prevent us to restructure a system.

A code archive makes the functionality of a system available for others to use. Therefore a code archive can include code archives of other systems to make the consumption easier. A module can be many times assembled in different code archives.

Distribution Package

A distribution package is used to leverage an existing technology to manage dependencies and track the versions of code archives present on a host. Examples are pip, apt and yum. Thus a distribution package adds extra metadata for deployment around code archives.

A distribution package contains a service definition that needs to be deployed into a service provider.

Service Provider

A service provider can host logic to perform a specific service. Examples are Apache Tomcat for which logic of a service is defined in war format, or Apache HTTPD with a PHP engine that gets the logic in php files to perform a specific service.

The operating system itself is also a service provider, you can provide your code as binary and it will provide a separate process to host a service that is described in the binary. Service provider is a broader concept and not only applicable on the application tier.

The service provider must be hosted according to the execution locality as defined by the software plan to achieve the desired performance, reliability and security. What service providers to use are part of the implementation technology dimension and needs careful weighing of multiple factors: maturity, resources, license, knowledge, control and runway.

Service

A service is created by hosting logic, code written in modules and assembled in a code archive, in a service provider. How the service is actually operating is the area of the Physical Operation abstraction. This area is where bug fixes are first explored (verified) and where the performance, reliability and security of a service are monitored.

Conclusion

Before starting implementation you would like to know if the solution will be of any quality. To do this, we need to make the right trade-offs, which are done and documented in a software plan. The software plan needs to explicitly define the systems, modules, code archives, distribution packages, service providers and services that will be created to realize a product.

Post a Comment

Popular posts from this blog

Poor Man's ApproachTo 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 ManagementQuality 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. Thus first we n…

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 QualityWhen people learn how to program, the syntax of the language is explained. Next in detail is explained, how to do recursion, with the termination condition; how t…

1. Your Toolbox: Design PatternsIn software design, design patterns are an essential toolbox to ensure your code is broken down into small independent units. This toolbox gets filled one-by-one, a single design pattern at a time. Since the tools can be used in different combinations, quickly the toolbox owner becomes more effective in creating a design that is focused on minimum effort and risk. This is especially true if you write or support software in a team. First you must ensure the tasks - and thus the code - are broken down into independent units. Common symptoms that arise when this is not properly done: engineers waiting on each other code to complete, functionality duplication, merge conflicts, the work of member "a" breaks the work of member "b" (regression bugs), incoherent interfaces - e.g. getX, doWriteX, deleteById; while much more coherent interface would be: readX-writeX-deleteX, or getX-updateX-deleteX.The second issue is in supporting (reading) th…