One of the study notes of quick software development is taken from cnblogs.

Document directory

• Chapter 4 software development strategies
• Chapter 4 typical errors

Chapter 2 Software Development Policy 1st four-dimensional Software Development

Http://www.cnblogs.com/lijia821130/archive/2012/03/04/2379610.html

Any software project has four important dimensions: People, Process, ProductAND TECHNOLOGY.To make the project smooth, the software manager must make full use of this four-dimensional role. The following table summarizes the four dimensions.

Table 1-1 four-dimensional Software Development

Dimension

How to optimize

People

L select competent members for the team

L select a proper team structure

L use appropriate personnel incentives

Process

L use standard software engineering practices to avoid losing control of the development process

L risk management

L select an appropriate life cycle model for the project

L forming a Good Quality Assurance Mechanism

L select a customer-oriented development method so that the developed products can truly meet customer needs

Product

L accurately estimate the product size (product scale) and effort (workload), so as to develop a real schedule

L take appropriate measures to prevent the product size or product scope from being out of control during software development

L set reasonable product characteristic (such as memory usage, stability, and reliability) for the product ).

Technology

L select appropriate tools that can improve productivity (including new programming languages, new development practices, and new code libraries)

Many software managers tend to focus only on one dimension of the four dimensions, while high-level software managers try to optimize the four dimensions of the project at the same time.

1.2 Overall Software Development Strategy

A software project should follow the following 4 steps:Point Policy:

1. Avoid classic mistakes. (avoid typical errors)

2. Apply development fundamentals. (using basic software development practices)

3. Manage risks to avoid catastrophic setbacks. (manage risks to avoid catastrophic results)

4. Apply schedule-oriented practices. (use progress-oriented practices)

These four strategies can be used for image representation.

These four strategies are like four pillars to jointly support a successful software project. In particular, the preceding three strategies are critical to the efficient implementation of each software project.

Chapter 4 typical errors

Michael Jackson once sang: "A child, don't break down the whole basket of apples ". But in the software development field, a bad apple can destroy a basket of apples! The software manager must remember:As long as a software project makes a typical mistake, it will slide into the abyss of slow development; to achieve rapid development, it is "necessary" to avoid all the typical errors.

How can software managers avoid all these typical mistakes? Use the "typical Error List ".

Best Practice: Typical error list

1. Use table 2-1 as the initial typical error list.

2. Check the list of Typical errors every day from the first day when you invest in a project to check whether you or your team have made typical mistakes. If so, think about how to change.

3. After each project is completed, analyze and summarize the typical mistakes made in the project. If the Error List does not exist, add it to the error list for use in the next project.

Table 2-1 Typical error list

Related Dimensions

Typical errors

Solution

People

1. undermined motivation)

Inspire developers. For details, see Chapter 10th.

2. Weak personnel. (personnel cannot be competent)

To recruit competent personnel, see Chapter 11th.

3. Uncontrolled problem employees. (out of control over problematic employees)

Handle the problem as soon as possible. For details, see chapter 11th.

4. heroics. (heroism)

Team leaders or members are too confident in their own abilities.

Objectively understand your own abilities and avoid blind self-confidence.

5. Adding people to a late project. (add people to projects that are lagging behind)

Do not add personnel to projects that are lagging behind. If you want to increase the number of administrative staff, you can increase the number of administrative staff to help technicians handle chores.

6. Noisy, crowded offices. (The office environment is crowded and noisy)

To create a quiet and clean office environment, see section 10.3.1.

7. Friction between developers and MERs. (friction between developers and customers)

Maintain good customer relationships. For details, see chapter 9th.

8. unrealistic expectations. (unexpected)

For more information, see Chapter 7th and Chapter 8th.

9. Lack of valid tive project category sorship. (lack of effective support from senior management for the Project)

Request high-level support for the project.

10. Lack of stakeholder buy-in. (The stakeholders are not fully engaged in the project)

Request the full commitment of stakeholders.

11. Lack of user input. (lack of user intervention)

User feedback is emphasized throughout the software project. For details, see chapter 9th.

12. Politics placed over substance. (playing politics)

Implement effective measures to ensure project and team success is higher than individual success. For details, see chapter 11th.

13. Wishful thinking. (full of imagination)

Determine the project status based on subjective desires rather than objective facts.

Break the wishful thinking and put the project on the ground.

Process

14. overly optimistic schedules. (too optimistic Schedule)

For more information, see Chapter 7th and Chapter 8th.

15. Insufficient risk management. (risk management is not in place)

For full risk management, see Chapter 4th.

16. Contractor failure. (Outsourcing Contractor defaults)

For details about how to effectively manage risks of outsourcing projects, see chapter 16th.

17. Insufficient planning. (The project planning is not in place)

Complete effective project planning. For details, see section 3.1.1.

18. Abandonment of planning under pressure. (abandon project planning under pressure)

Under pressure, we must stick to the planning, but we need to adjust and re-plan the project in a timely manner based on the progress of the project.

19. Wasted time during the fuzzy front end. (wasting time in the early stage of the project)

It is not a waste of time in the early stage of the project. We strive to establish the project as soon as possible and enter the implementation stage.

20. successfully changed upstream activities. (Sample upstream task)

Completes requirement analysis, outline design, and detailed design.

Perform requirement analysis, outline design, detailed design, and perform technical review.

21. Inadequate design. (poor software design)

High-quality software design.

22. Lost changed quality assurance. (Sample Quality Assurance)

Cancel Design Review, code review, and test planning.

The requirements for software quality are not relaxed at any time. For details, see section 3.6.

23. Insufficient management controls. (management control is not in place)

Strengthen management and monitoring of major milestone and miniature milestone projects. For details, see section 3.1.2.1.

24. Premature or overly frequent convergence. (finishing work too early or too frequently)

Do not close the project too early or too frequently.

25. Omitting necessary tasks from estimates. (missing necessary tasks in project estimation)

List the tasks that are easily missed in project estimation in a prominent position to prevent omission. For details, see section 7.2.

26. Planning to catch up later. (try to catch up with the progress)

When the progress lags behind, do not try to catch up with the progress, but re-develop the progress plan based on the new situation of the project. For details, see section 7.3.

27. Code-like-hell programming)

The project adopts a rigid, free and casual programming model where code is written.

Avoid chapter-based programming. Any code must undergo strict quality assurance measures. For details, see section 3.6.

Product

28. Requirements gold-plating. (gold-plated upon request)

The project requirement specification has complex requirements that are not required by users.

Do not add unnecessary requirements to the Requirement Specification.

29. Feature creep. (function spread)

The project needs to be changed frequently during the process ).

Take measures to prevent function spreading. For details, see section 13.2.

30. developer gold-plating. (developer gold plating)

To learn new technologies, developers add unnecessary features to products.

Do not add unnecessary features to help developers learn new technologies.

31. Push-me, pull-me negotiation.

The software Manager approves the delay and adds new requirements to the delayed project.

If the project has been delayed, the demand must be stabilized and new requirements are not added. For details, see section 15.1.3.

32. Research-oriented development. (research-oriented development)

Consider Software Research (such as new algorithms) as engineering projects.

Do not engage in Software Research in software engineering projects.

Technology

33. Sliver-bullet syndrome. (silver bullet syndrome)

The project places the hope of solving the problem on a new practice, new technology or new development methodology.

To break the silver bullet syndrome, see section 14.2.

34. overestimated savings from new tools or methods. (the benefits of new technologies or methods are overestimated)

Have a rational understanding of the benefits of new technologies or methods. For details, see chapter 14th.

35. Switching tools in the middle of a project. (change the development tool during the project)

Continuous use of proven old tools. For details, see chapter 14th.

36. Lack of automatic source-code control. (lack of automatic source code control)

You must use an automated source code control system.

Best Practice: source code control system

Select a source code control system for the entire project and the entire company. This source code control system can be a commercial software system (such as clearcase and perforce) or a free software system. Start your project only after the source code control system is ready.