Software Engineering reading assignment 2-Team Project understanding and experiences

The Alpha version of the software engineering team has been basically completed. Our project is a Web uidesign-Xueba online learning website. The team applied C #, ASP. NET, SQL and other languages throughout the project and made great efforts for this project.

When the project is about to be released, we read some blogs, papers, and books recommended by our teachers, and have a new understanding of the concept and theory of software engineering. I will summarize articles such as "no silver bullet", "Waterfall Model", "big mud ball", "church and market", and "Agile development methods" based on my own team projects. understanding and experience.

We are familiar with the Silver Bullet concept. Silver bullets that can kill almost invincible werewolf. If used in software project development, they will naturally be invincible, and some difficult development problems will be solved. However, it is a pity that the so-called silver bullet does not exist in terms of the current software development. Just likeAlbert SteinLike the unified field theory committed during his lifetime, it is impossible to create a solution or tool that can cover all aspects of the problem.Frederick P. Brooks, Jr.The words mentioned in this article are expected to become the language and concept of software development, as shown in figureAdaLanguage and so on. These are considered as excellent software development solutions, but they still cannot become silver bullets. The features of the software themselves also make it unlikely that there will be any invention or innovation-the same way as electronic devices, transistors, and large-scale integration in the computer hardware industry-to improve the productivity, reliability, and conciseness of the software.

We must see that this malformed state is not due to the slow development of software, but to the fast development of computer hardware. Since the beginning of human civilization, there is no cost-effectiveness of other industrial technologies, and it can be improved by six orders of magnitude within 30 years, no industry can make such progress in improving performance or reducing costs. These advances come from the transformation of the computer manufacturing industry from the assembly industry to the assembly line industry.

For software development, a conceptual structure with mutual restraint and association is an essential part of software entities, including data sets, relations between data entries, algorithms, and function calls. These elements are abstract, and the conceptual structures are the same in different forms. However, it is still rich in content and highly accurate. The difficult part of software development is the structure of the concept of Specification Description, design, and testing, rather than expressing the concept and verifying the degree of realism. Of course, we will still make some syntax errors, but they are insignificant compared to the Conceptual errors in most systems.

If this is the truth, software development is always very difficult and naturally there is no silver bullet.(If this is true, building software will always be hard. There is inherently no silver bullet.)

Our team has not yet taken the silver bullet into consideration when developing this project. Because many of the things we need are completely new, we need to learn by doing new knowledge, it is far from considering its advantages and disadvantages and whether it is possible to become a silver bullet. Programmers have always had high expectations for Object-Oriented Programming, but although we have also written a certain number of object-oriented programs, we still do not really grasp the essence. It is too far-fetched to associate the technologies involved in this small-scale Team Project with the silver bullet, however, from this limited technical means, we have realized the many difficult challenges faced by programming. We cannot expect that the silver bullet is born to eliminate all obstacles for us. Learning as many programming techniques as possible within the scope of our own capabilities may be the only way to complete the project.

In 1970, Dr. Winston W. Royce proposed the waterfall model. Based on his past experiences in the analysis project of space missions in the spacecraftManaging the development of large software systemsThis article describes the view on computer software development.

Any computer program development, regardless of the size, has two parts: analysis and programming. However, for software implementation, analysis and programming are not static. Because the implementation, functions, and usage of small software used by software developers or software development departments do not have to meet high standards as they do for all customers. It is enough to simply implement the required functions by analyzing and writing programs. Those users pay for more widely used and larger types of software, these details must be taken into account. Simple analysis and coding obviously cannot meet the implementation requirements of large projects.

To implement a larger scale of software, more implementation steps should be derived from the initial analysis and programming to form a complete Waterfall Model:

System Requirements-software requirements-software analysis-programming-code implementation-software testing-Operation and Maintenance

Although it is called the waterfall model, the whole development phase is not just like the waterfall. They are closely linked, and each step is implemented based on the previous step and the next step. The previous step is the basis for the next step, and the next step is the feedback from the previous step. Although each step is mutually dependent, the non-adjacent two steps are not closely related. In order to ensure the correct implementation of each step, we hope that each step has a certain degree of interaction. However, unfortunately, during testing, we often find problems with design and even requirements, so we have to rework. To solve this problem well, we should take several steps to solve it.

1) Preliminary Design: Program Design first. Make sure that our outline Design is complete before entering the requirement analysis.

2) Document the Design, write the Design Document, and confirm that our Design is complete.

3) Do it Twice, double insurance, and try to read the documents in advance to see if they can become the final product.

4) Plan, control and monitor testing Plan, control and monitor test.

5) the customer involved in the Involve review process.

Finally, a complete waterfall model is complete.

Now, when you are using waterfall to develop software, you know why it is so painful. It was already 40 years ago.

The project of our team has not completed the last part of the waterfall model, but we have fully learned the "rework" mentioned in the model. We didn't think much about the demand analysis before. We kept adding, deleting, and modifying the Code while writing it, and finally formed the current work. According to feedback on changes to the preliminary work of the program design, this is itself a complementary process forward, but because of the incomplete consideration at the beginning of the major functional changes, this should be a taboo in the development process. My teacher used to learn new things like this: learning new things is just like steaming steamed bread. It's not the first time I steam it, and then I get back to the cage. Similarly, when developing new software, there is no good foundation when writing it for the first time. In the future, it will be hard to escape the fate of a crash.

As for the big mud ball, this is too close to our development process. I think that the smooth completion of software development in the cloud should be the dream of every programmer, but it is too difficult for us to encounter no confusion or embarrassment during the development process. Despite the various development methods that encourage and promote code with good structures, the software skill movement is also growing, but the big ball seems to be the most common way to design the software architecture. Even though people have learned something from the bad design in the past, the huge mud ball still does not disappear in the new development process. There are many examples of messy and complex code in our project team, which also adds a lot of difficulties for the final integration.

The main reasons for the occurrence of large mud balls are as follows:

• One-time code
• Fragmented Growth
• To keep the software intact
• Copy/paste leads to issue transfer (problematic code is copied to many places and continues to spread)

The agility we often mention is one of the ways to solve this problem, but it is worth noting that Agility works not because of its process, it is because many practices allow people to constantly focus on the excellence, review, face-to-face communication of technology, and individuals who are motivated. When software quality declines, simple refactoring and testing are adopted. Therefore, it does not seem that the process can help reduce the size of the ball. In the end, a responsible programmer is willing to take responsibility and be vigilant. Unless so, whether it is agile or not agile, the big mud ball will always be lingering.

When it comes to agility, our projects also use some agile development methods. I have read the Agile Software Development Declaration (Manifesto for Agile Software Development), We also understand these principles in development: individuals and interactions are better than processes and tools; software that can work is better than all-around documents; response to changes is better than compliance with plans. Software at work is the first standard of Progress Measurement-a basic principle that we will never waver in. We also practice the methods of Pair Programming and SCRUM well.

In our previous discussions, we also talked about not to be agile and agile. In my opinion, in the current software development, most of the methods are still code and fix, so introducing some disciplinary constraints will certainly be better than chaos. The main advantage of the agile path is that it requires a lot of steps. If you are used to no-process, it is easier to follow a simple process than to follow a complicated process. You need to evaluate any new process so that you can see if it is suitable for your environment. Although our group has only six people, the agile attitude in the development process is basically supported. Agile development is difficult to adjust. At present, our projects have gained a lot from agile development. Whether or not we will continue to work in software development in the future, the spirit of mutual learning and cooperation learned from the soft engineering team project, it will be an important tool to help us realize personal value in our team in any field.