Software Engineering Practices - Assignment Example

Running Head: ​​software engineering ​​ Software engineering Name School / University Professor Date The issue created on GitLab the issue created on GitLab, is sandwiched bread. The screenshot for the project is Wiki page The Wiki Page on GitLab output is shown and code is HTML and CSS. The code has description of the issue which is sandwich. The other part covers ingredients and cooking and serving directions. There are images of the product. UML class diagram of the main classes in code writing for sandwich The sketch diagram of the code writing for the issue is shown below, in the sketch diagram it will be noted that there are writing of code, code testing, QA application, bugs however, what the diagram fails to show is that the sensors are at both the windows and the doors. It is important to design a pictorial representation of the entire features. The main importance of this approach towards feature design is that it provides a simplified view towards analysis. One can use the rich diagram to understand all the components of design just at a glance. This representation should be designed in the simplest way possible to make it easy to interpret for the users. In the case, the representation has to be made to capture all the feature floor from the allocation of time to time of debugging. The entities are the main elements in the software diagrammatic representation. In the case of rich diagram representation, there are flow lines that are used to depict the flow of information across the design. UML sequence diagram A short video the video showing how to make sandwich is shown in “ https://www.youtube.com/watch?v=NoMMh9CbxXE” Contribution summary I participated in writing HTML code as well as creating both wiki page and creating an issue on GitLab. I had great knowledge in code writing and team members. I made sure that the team was never limited to only one idea be that of the team member but also we did enough research. In this way the team was able to make sure that it was not heading in the wrong direction at any given instant. Due to her idea generation qualities, I was given the role of monitoring and evaluating the overall team performance. Debugging was most difficulty activity we carried. As you gain experience with programming, you will no doubt develop your own personal style of debugging favorite techniques, tricks, tools, and so forth. You will also learn to use a source-level debugger. A source-level debugger integrated into a software is a powerful tool for tracking down bugs. However, the most important point to remember is that the key to effective debugging is to follow a disciplined process. Implementation would involve writing up detailed user instructions and documentation, determining optimum operational procedures and providing training for the program users. One will try to come up with the smallest amount of code that still exhibits the error. You can do this by removing calls to methods that are unnecessary and removing statements that should have no bearing on the problem. Anything one can do to reduce the complexity of the code for the package can be helpful. As one are removing code, should probably want to periodically run the code to make sure the fault or bug is still there. If it is discovered, the information can be used to reason about the cause of the error or faulty. As you remove code, be sure to retain a copy of the original code. Along these same lines, you should produce the smallest inputs that still cause the bug. If the program is interactive, try to find the shortest sequence of commands that cause the error to occur. Knowing the precise input that causes the problem is useful information. Bugs that occur sporadically are some of the hardest to track down. If the bug does not happen consistently, work to make the bug appear reliably. If the bug is a hard one to track down, you will probably be running the program over and over again. In this case, you want each run to be productive. If the bug only occurs after the program has been running a long time. Figure out ways to simulate that behavior. Perhaps the bug only occurs when data structures grow large. Simulate this behavior by writing a function that builds large dummy data structures. Call the function at the beginning of the program to simulate the effect of the program running a long time. Try to determine what function or section of code is causing the problem. To do this, Print data values and observe at what point in the execution incorrect values are produced. It also helps to try different input values and observe the effect on the code. Sometimes with the right input you can “triangulate” the location of the error in the code. Explain the bug to someone else.- In the file stats example, explaining the code to someone else could have caught the error. Hopefully, the person you explain the code to has a different mindset or different mental model of what’s going on and will immediately see the problem that you were blind to. If you have worked at a help desk, you have probably experienced the phenomena known as “confessional debugging” a person is explaining the problem and as they do so, it suddenly dawns on them what the problem is. The act of explaining the code to someone makes you think a little more clearly, not skip steps, and on. Confessional debugging is surprisingly effective. Many compilers allow the programmer to control the level at which error and warning messages are issued. Setting the compiler to the strictest level can sometimes yield information that is helpful in searching for a bug. Fix bugs as you find them. It often happens that when you are looking for a bug, you discover another bug. This bug seems unrelated to the bug you are trying to find. It is tempting to put off doing something about the bug just discovered since you are in the middle of tracking down the original bug. You do not want the trail to go cold. Most experienced programmers have war stories about bug hunts. A common story is the “debugger`s epiphany.’’ The story goes something like this. Sally has been hunting a particularly nasty bug for days. None of the tried-and-true techniques for finding the bug have worked. Sally decides to take a break and hit the hills for some mountain biking action. When sally is flying down a hill with trees whizzing by, the last thing she is thinking about is the elusive bug in the web browser. After a great afternoon, sally heads home for a shower. As she showers, she starts to think about the bug again, and it hits her- the solution to the browser problem suddenly becomes crystal clear. Sally heads to work to run an experiment to validate her hypothesis, but she’s confident she’s got it. References: McNell, Patrcik. (2008). The Web Designer's Idea Book: The Ultimate Guide To Themes, Trends & Styles In Website Design. The How Publication. Read More