Tools for decentralized requirement engineering

Requirement engineering in an enterprise context can be a pretty tough problem, especially at discussing with ever participants and stake and stockholder of the project and achieving a common decision. It will be even more difficult in the context of a consortium blockchain solution as not only a participants of one but several companies should be taken into account. Achieving a common decision in such a situation might be a nightmare. What we would need are tools for the decentralized requirement and process engineering. Like a common dashboard on the process or requirements must be presented with several possible governance algorithms where the participants can vote or modify the process or the requirements based on different interest. Based on the outcome of the decentralized process engineering, the final blockchain system can be designed. The requirement or process engineering can be itself supported by blockhain and of course everything that has anythin to do with on-chain governance will help a lot. 

Blockchain development and project management

Blockchain development requires a new way of project management, let we call it SF-Agile, meaning that if it is possible agile, but basically Security First: security is the highest priority, agile is only the second. From a practical point of view until we are on a test network, the development itself can be agile, however as soon as we want to deploy to the live network, the requirements have to be fixed, everything has to be unit tested and possibly formally analyzed and verified. So in the last step Security First has to very strongly dominate, in this sense this step is similar to waterfall project.

Notes on Software Project Management

Having spending a decade with different software projects and development methodologies, I would conclude that they are somehow not really optimal in many real life Scenarios, independently if we speak about classical waterfall style software development, or about a rather modern agile or scrum method. In the following I just try to summarise a couple of points that I see important based on my experience.

1. Specification: Most software project methodology suppose that there is some kind of a specification for the software; it is relative good specified at waterfall however much more flexible at agile. However in life the first question of the customer if you already have something ready ? The second question is if you have at least something half-ready for prototyping. And the reason for that is that even creating a relative good specification even if it is agile takes time and money. Certainly it can be supported by the business analyst role, so it takes more money and time. As a consequence, custom software development is ususally the last choice for any corporate purchasing process. Customers usually prefer to get something ready or at least-half ready and making modification on that.

2. Architecture: There are a lot of general frameworks that delivers a lot of use-cases out of the box, other frameworks provide self service use-case development even by people without prior development knowledge. In this sense one of the most important step for every software development project is to choose the right software architecture.

3. Agility: Agility can be interpreted only within a certain software architecture. Each architecture can provide several use-cases out of the box or easy to set up, however others are very difficult to implement. One of the biggest problem of each project if the basic architecture should be redesigned during the project.

4. Lean software development: Lean software development can be  interpreted as a way for delivering usable software for the end customer as fast and as efficient as possible. In this sense it makes sense to evaluate if part of the specification or respecification at a new release and the related development can be supported by machine learning algorithms. Certainly the architecture hat to support such an improvement as well, however it is not difficult to imagine that for instance the user interface structure is automaticaly adapted just by analysing the usage of the software itself. There are  initiatives for that for exmape The Grid.

5. Resue - Resell: Most software companies do not want to sell a project only once but several times, even if it is not meant to be develpped as a product for the first run. In this sense one of the most important question for each software project is reuse and resell: How can be the software project sold for several customers, how can be an implemented business-case used in several projects or even on several platforms.   

    

Notes on SCRUM and agile project management

Scrum is an agile project methodology that helps you deliver a software project in a more efficient way. Sometimes the methodology is pretty much overvalued. Basically the classical truth are not changed: either you know what you should deliver, or you do not have a clue

.

1. If you know what you should delivery, you can deliver with SCRUM in a fast and more efficient way.

2. If you do not know what you should delivery, you are going with SCRUM to the wall in a fast and more efficient way.

Notes on the Logic of IT Project Management

As in a normal communication there are two answers for a question :"yes", or  "no". In IT Project management there are usually three ones: "yes", "no" or "let we create an excel table". And surprisingly, the answer in most cases : "let we create an excel table".