Introduction of software architecture to project management

Introduction of software architecture to project management

 

Many of my friends have or are managing one or more software projects, so my article begins with this question, what are the biggest problems exposed during the software project management process?

 

Different people may have different answers, but I think most people will agree on the answer, that is, "delay ". Progress delay is of course one of the representations. Other factors, such as poor quality and incomplete functions, are closely related to progress delay. Many project managers want to do things that are considered necessary, such as planning and testing, but "no time ". Why is there no time? When the project is summarized, we will always list a lot of reasons to persuade ourselves, persuade the company or even persuade the customer. However, if the project manager is limited to finding the cause from himself, it will not be difficult to find the problem.

 

Here, I use the "five times why" method of "Toyota" to ask this question, and I think it is possible to answer:

I. Why is the project progress delayed? Because it is not in accordance with the Project Plan!

2. Why not follow the project plan? Because there will always be delays in progress, and the buffer time will always be used up.

3. Why isn't the plan more detailed and more realistic? There will always be extra work.

4. Why do we fail to fully assess every job and minimize unexpected work? Because it is indeed impossible to assess, many think that it is atomic level work will produce various problems.

5. Are there any project plans for other projects that can be referenced? Because there are too many differences between the two projects, it is difficult to reuse them.

 

When asked, I think the core issues of general projects will be shown in front of us. We will not talk about this issue now. We will use a few simple examples to make it more vivid.

 

We use a non-Software case as an example to let everyone make a detailed project plan for this example and evaluate the most accurate time.

 

Example 1: Evaluate the time for each article to repeat it.

This example is the simplest. For myself, I can type at a speed of 30 Chinese characters per minute. So the time for this article to repeat is the total number of words in the article: 3000/30 = 100 minutes. In addition, the period of rest in the middle is 120 minutes at most.

 

The answer is quite accurate. I don't think too many people disagree, but the next example may be different.

Example 2: solve the following equation: x2 + px + q = 0, p = 2, q = 1

In junior high school, many people may forget its general formula, but we suppose everyone knows this formula:-p/2 ± sqrt (p2/4-q ). When evaluating the time, we first need to know the time when we open the calculator, enter the data time, and copy the results. In order to ensure accurate calculation, we need to check the time. Well, the authority of time estimation is probably not as convincing as in Example 1, and we often need to re-calculate because of miscalculation. It is difficult to avoid timeout.

 

Example 3: rewrite an article based on my introduction and project practices.

Success! If you can accurately estimate the time, you should be a master. Let's take a look at how much we need to do to complete Example 3: Develop a writing outline, outline the writing content, evaluate the typing speed and the amount of each content... In my opinion, the progress of this job will still be delayed without calculation and calculation.

 

Are there any differences between the three examples? Of course! We have mastered the estimation method in Example 1 and have the least variable in the execution process, because we do not need to do any exploration process (I guess the five-stroke font of a word is not counted, at least I use Microsoft pinyin ). The difference in example 2 is that the problem-solving method requires the intervention of external factors, and this technology is not mastered by everyone (or remember ), the most important feature is that we need to estimate the time it takes to complete each step. If we have calculated it once, of course the second time will be more accurate. However, projects in real life rarely give you the opportunity to redo it. After you complete the project, various methods related to the specific project will lose its role. Its only value is to dive into your memory and become the so-called "project experience ", this "experience" is often unacceptable in the next project. In comparison, Example 2 is actually a visible and tangible action, which provides a basis for evaluation. Example 3 is almost a pure brain movement, to Let Everyone assemble a good-looking article out of thin air, I think it is too difficult to estimate the progress. Who knows how long it takes for us to repeat or even wait for a piece of content ?!

 

Let's pull the topic back to the first five times. The most important thing for software projects and other projects to be completed on time is to make a "plan". Planning a project plan that conforms to the actual conditions is the biggest barometer of project success or failure.

 

To bring the project plan closer to reality, we first need to list all the work in the project, and then divide the work in every step into atomic levels ", that is, it cannot be further divided. From the software project perspective, it is divided into "Files", "classes", or even "functions. Then, we will evaluate these "atomic level" tasks, accumulate and combine them, and multiply them by a coefficient (generally 2), which is the time the final project will spend.

 

Easy to say and difficult to do! It is enough to break down a large number of project managers to the atomic level.

 

Let's look back at Example 2. If the person who solves the problem forgets the formula for solving the problem, do you need to adjust the progress of the previous estimation? The answer is yes. In such a time calculation, we need to consider the time for finding data. As long as we find the formula, the calculation result is not a problem. However, the time spent in finding the formula is in the case of a smooth network connection, it takes only an hour to search and ask colleagues!

 

If it takes an additional hour to find a formula, modify the Example 2 to calculate "Fourier"

How long does Transformation (non-programming computing) take? Obviously, it is not an order of magnitude to solve the binary equation. In addition to searching for information, most people still need to learn. People without the foundation of advanced mathematics may need to join the study.

 

From example 2, we can summarize the following phenomena: there can be a hierarchical relationship between work and work. A seemingly simple job may have a huge workload, this is especially true when there are some prerequisites or insufficient preparation. To accurately estimate the time spent on a job, we must first "Expand" the collapsed "Work tree as much as possible ", second, we must curb the workload of "Learning", "research", and "Search" at work. In short, we should try our best to make all work simple, predictable, and eliminate uncontrollable and unreliable factors during actual project development.

In other words, the relationship between each project's work and time must be "linear. If "non-linear" tasks cannot be ruled out, they must also be within the "controllable" scope. The project cannot contain "uncontrollable" non-linear factors.

One sentence:The more brains you use, the slower you get.!
 

How many factors in the project are "uncontrollable? Which of the following are "controllable? What are the "linear" factors? To answer this question, let's first take a look at our current software development methods and processes:

(1) sign the contract

(2) demand Investigation and Analysis

(3) Architecture Design and summary Design

(4) Detailed Design

(5) coding and Testing

(6) delivery and maintenance

There are six steps, of which three or five are associated with the development process we talked about (I will discuss the other part in a series of articles in the future ). First, let's look at the third and fourth points. They are collectively referred to as "design". The goal of the "design" phase given in reference to document 2 is to solve four problems: data structure, software Architecture, process details, interface nature.

 

As I can see from experienced readers, a considerable part of the problems solved by the traditional "design" should be summarized into the current "architecture. The scope of the software architecture is as follows:

(1) Application hierarchy (such as interface layer and storage layer ),

(2) Division of some application modules (such as initialization modules, configuration modules, and permission modules ),

(3) Implementation of some application modules (permission, user, organization management, etc ),

(4) Implementation of the function library,

(5) interaction and communication mechanisms between modules and layers,

(6) related data structure definitions.

It can be seen that the most important and basic work of the third and fourth points above is basically within the scope of the "architecture". The rest of the work is basically related to specific businesses.

 

In the above three "xx designs", it is difficult to control and estimate the time required for architecture design. The outline design and detailed design are derived directly from the evolution of demand entries, it is also easy to refine (I will discuss it in the future), so although it is a non-linear task of "design", "controllability" is much better than "architecture. From the perspective of personal project maintenance experience, a considerable part of the problems arising during the maintenance process are due to the fact that user needs have broken through the capabilities of the original architecture. This is the problem that is the longest delay, it is also the most painful and headache for maintenance personnel. Therefore, "Architecture Design" is classified as "non-linear" and is a "difficult" task.

 

I have seen that many software departments are called "R & D departments". In English, they are research and development departments. However, I rarely see companies that separate research and development into two departments. What is the relationship between them? From the above, we can see that the research is a very resource-consuming job, and the risks (especially technical risks) are very high, it is likely that the entire architecture is overturned because a small technical problem cannot be broken through, and the development risk is much lower and controllable. Another major difference is that research does not directly create value, development is closely related to the company's revenue. For these two reasons, it is enough to split "research" and "development" into two departments. There are many other differences, such as assessment methods.

 

How to allocate work after separation? It is easy to put the "Software Architecture" and other difficult "non-linear" work to the "research" department gathered by experts; business and implementation ("linear" Work) related to specific projects are handled by the "Development" department because they have low technical requirements and low costs. Speaking of this, do I claim that every company needs a dedicated person to "study" the technology? On the contrary, I hold that most companies do not need to set up research departments. At least most companies do not want to develop or even try to develop the so-called "own" software architecture. Because the software architecture is independent from the specific business, there is no "Software Architecture" that is "especially suitable" for a certain business, it should be tested by M years of N projects before it will appear (N * M> 10 years ). I believe that SAP has such an architecture, but there are basically no domestic companies (maybe, but please understand my doubts ). There are many open-source architectures on the market now. Select one and then train your employees to continuously train and instruct them to skillfully apply this architecture to projects, even so, your total cost is far less than the investment of a "master" to develop a failed architecture.

 

How to choose a ready-made architecture is no longer within the scope of the Article, because I will talk about "how to develop a self-built architecture", but don't worry, if your development language is java, congratulations. Many of the useful open-source architectures are java, such as spring MVC, struts/webwork, and tapestry.. net petshop or Duwamish architecture.

 

Next, let's talk about the role of software architecture in project management.

 

 

References:

I. Software Project Failure Factor Analysis http://pm.aura.cn/newsarticle/project-app/214748834.html

2. Software Engineering (edited by Yang Wenlong) Electronic Industry Press Co., ISBN7-5053-4058-1.