Common causes of failure of basic software projects (academic) Risk caused by insufficient understanding of customer requirements. It mainly includes requirement change risk, involved risk, process risk, installation and maintenance risk.
All kinds of risks caused by inadequate management personnel, lack of experience, poor communication and unreasonable assignment of tasks mainly include schedule risk, budget risk, management ability risk and information security risk.
Risks caused by insufficient technical force and development environment tools. It mainly includes technical risk, quality risk, software design tool risk, software development tool risk and employee skill risk.
Risks caused by changes in the internal and external environment of the company or project team, mainly including human resource risks, policy risks, market risks and marketing risks.
Risk in a software project cannot be eliminated, only avoided, mitigated, and accepted.
A common cause of failure for software projects (the practical) is that the market window closes. This is no good way, timely stop loss, the earlier the project is stopped, the smaller the loss.
Intrigue. Each stage outputs corresponding documents as the basis for cooperation.
Too many or too few team members. Hiring and training takes time, so when defining the scope of a project, consider manpower constraints.
Inappropriate, advanced or outdated technology was chosen. Inappropriate technology can increase costs and decrease quality. Advanced technology greatly increases uncertainty. Outdated technology degrades quality.
Core function changes. Let the marketing staff, sales staff most of the work into nothing.
The priority is not set properly. Good steel goes to the blade.
Poor architectural design. Increase qualified software architects.
Rush for success. More haste, less speed.
Unrealistic deadlines. It is often caused by clients or management being too optimistic.
I failed the project in 2003 spare time to do a website
A few months later, I arrived at 2000IP. At that time, the mainstream view was that “2000IP is the profit point”, but I did not know how to make profit, nor how to analyze the profit model. There was no profit model for a few years, and the IP was down to 1000IP, so they shut down the site.
Summary after 10 years:
A,IP can reach 2000 quickly because I wrote a semi-automatic Posting tool, so I have the advantage of promotion. When commercial Posting tools came out, my strengths became weaknesses, and there was no going back. At that time semi-automatic Posting will improve perfect automation, selling products on the hair.
B) failed to focus on finding a profit model.
C,2000IP can indeed be profitable. The company I worked for before had more than 30 people with 5000IP.
Dean purchase, sale and storage
In 2010, I spent a month making a purchase, sale and storage model, but I didn’t know who to sell to or how to find a buyer, so I gave up!
Conclusion 7 years later: The difficulty of the product is much greater than that of the project, and the project has evolved into a relatively safe product.
Professional Online learning
Before 2010, I took one or two courses online in my spare time. 2010 Full-time online classes for a period of time, two students signed up. In the process of communicating with potential “students”, I found that freshmen and sophomores are not keen on extracurricular learning. I expect that they will come to me when they find a job soon. It came true, but I couldn’t get away from the game development.
Summary of 7 years later: The only project barely qualified in the market among the 4 start-ups.
Wisdom in The Three Kingdoms
From September 2010 to February 2014, I developed and operated a micro terminal game.
It got better and better every year, but in the last year it was only half to a third of what I was working for. There is a peer, the software quality is worse than me (repeatedly large data damage), but the income is higher than me. So, I decided to work another contract to think about this problem.
Post hoc summary:
1. There are many improvements in development technology, which led me to pass the “Software Architect” exam.
2. The class library needs to be accumulated. By October 2017, the class library has been basically formed.
3. It’s hard to understand the player’s mind. I love playing games, and I’ve been playing for 10 years, but when I do it, I don’t understand the hearts of players. Knowing the player’s heart requires obsession, not liking.
4. I have been working on a miniature game for more than 3 years, and the usual practice is half a year. Later, the historical burden becomes heavier and heavier. A better way is to do 3 different demos within 3 months, focusing on developing the ones with the best response from users. Spend a month every year or six months creating a new demo, and if the new demo is well received, the new demo will dominate.
5. Although I often communicated with players (more than an hour a day on average), I rejected most opinions due to different core cognition. There are two main reasons for the difference in core cognition: A) My game is not for the player. B, the player is not suitable for my game. Either way, it needs to be addressed.
Summary of four startups
1, appropriate capital reserves, otherwise, the pressure of survival makes you unable to calm down to think.
2. Before starting my own business, I knew the importance of demand analysis, but I didn’t personally experience it. These several entrepreneurship deepened my experience.
3. Recognize the importance of feasibility analysis.
4, do not avoid difficulties, to analyze how to solve: learning? Outsourcing? A detour? History shows: technical problems, I solve; Market issues, I’m easy to avoid.
niuniu
The summary above was completed in 2018. In 2018, there was another project, the board game niuniu. $50,000 reward, $8,000 deposit, delivery date, feature complete but defective, the user asked for a refund, we agreed. The project failed, but we still gained something. Wei Jiayu and I cocoded for the first time, I backend, he front-end. We use a new technology, WebServer, and encapsulate it into a class library. The “Print Master” THAT I later did at The Smart House used this library directly. This is also the way to complete The Three Kingdoms of Wisdom ii in 2020.
Definition of problems at each stage of software development: determine objectives and feasibility.
Requirements analysis: System analysts determine business-level functionality, business-level quality, business-level constraints, user-level functionality, user-level constraints, and development-level requirements. The architect determines user-level quality.
Design: Architectural design identifies development-level qualities, development-level constraints, and ensures that all functionality, qualities, and constraints are translated into development-level requirements or executable policies. Outline design makes division coding feasible. Detailed design guides coding.
Encoding: Output software that can be executed on a computer.
Software testing: Find problems before users do.
IBM estimation model :(total gravity 10)
Software Project: 1
Requirement analysis: 1.5
Design: 3.0
Code: 1.0
Test: 3.5
Note:
The maintenance workload of large projects is twice that of development. The larger the project, the larger the maintenance workload is. The worse the product, the more maintenance. So maintainability is important.
Division of Labor and Types of work Why to division of labor
Division of labor can greatly improve the productivity of labor, for the following reasons:
Because division of labor can improve the skills, proficiency and judgment of personnel in a particular link. Reduces the time spent switching back and forth between different types of work. Proficiency also enables people to create more and better tools, thus improving labor efficiency. Adam Smith described the production of the pin in The Wealth of Nations: “… The main process of the pin will be divided into 18 different processes. Smith pointed out that if these workers worked alone, they would produce no more than 20 pins a day, and this division of labor allowed them to produce 48,000 pins per person per day.
Division of software
Project Manager: Lead the project team to complete the project on time and with high quality.
Product people: Requirements analyst, system analyst. Collect, sort out requirements and analyze system.
Developers: Architects define quality goals, designers guide coding, software development engineers code.
Tester: Tests the product.
Configuration Manager: Version control.
Operation and maintenance personnel: Manage servers and databases.
Delayed project additional personnel delayed even more severe peach garden peach trees, 6000 years to bloom, 6000 years to bear fruit. So does one peach tree, so does 1200 peach trees. Reasons why additional staff of delayed projects are delayed more severely:
The cost of learning is high. Newcomers need to be familiar with multiple modules, while others only need to be familiar with the modules they are responsible for. After learning, lack of practice, low efficiency, output can be ignored. Introduced defects can also drag down others. New staff often need guidance and guidance from existing staff in the project, which will reduce the work efficiency of existing staff in the project. Unless there are special training personnel. The more people, the more communication costs. Communication costs are proportional to people squared. Software Capability Maturity model (CMM) is divided into five levels: initial level, repeatable level, defined level, managed level and optimized level. Repeatable: disciplined; Defined level: standard consistency; Managed level: foreseeable; Optimization level: continuous improvement. For small and medium-sized companies, repeatable level is already very powerful, this article only focuses on repeatable level (CMM2). CMM2 consists of six key process areas (KPA) : Requirements Management (RM), Software Project Planning (SPP), Software Project Tracking and Monitoring (SPTO), software sub-contract Management (SSM), Software Quality Assurance (SQA), and software Configuration Management (SCM).
Demand management includes: first, demand collection, demand sorting, demand analysis. Second, demand review. Third, establish a baseline. Fourth, requirements change, requirements change to rewrite the review, establish a new baseline. Fifth, demand backtracking. A baseline is a “snapshot” of each artifact version in the project repository at a specific time. What baselines do: First, roll back. In a common scenario, users still require the same scheme as a few months ago. Two, branching. In a common scenario, the user requires a change from the version one year ago. Third, communication. Development and testing are often at loggerhead over whether or not defects should be fixed because of inconsistent versions. Similar arguments are common between implementers and customers.