Sam Lemon CSCI 362 Blog

Ex 24.6  Explain why program inspections are an effective technique for discovering errors in a program. What types of error are unlikely to be discovered through inspections? Program inspections are an effective technique for discovering errors in a program because getting another person to look over your code is invaluable. After working on the same code for a while and looking at it for so long, you become so accustom to it that you are blinded in a way. Someone who has never see the code before and has fresh eyes may see problems that you have over looked. Also this person may know of techniques or code that can make you code more efficient or effective. Two minds are better than one as they say. It is always a good idea for a program inspection to make sure your code it high quality. Some errors that may be discovered are bugs or defects. Or maybe you are using a component of your code ineffectively or they can maybe show you how to do something in a better way.

Since last team progress report, we have finished up all test cases and have also fixed the problem we had that was talked about during the last progress report. Wright and I have been working really hard meeting up all the time and working at his house together with his two cats. We are already to deep to turn back now but if I were to do this class again, I would not be doing OpenMRS. It just does not have enough of the methods that we need for this assignment. Also the structure of the OpenMRS-core repository is a little strange and we are having trouble getting dependencies to be seen by our machines. Also the OpenMRS-core relies on dependencies from other OpenMRS repositories. OpenMRS is made up of 6 different repositories. So this has definitely slowed us down but we are going to keep pushing forward. Communication and organization between Wright and I has been much better since we lost a group member. Losing Ryan made us realize that we got to really get to work to make this hap...

Ex 23.6 Figure 23.14 shows the task durations for software product activities. Assume that a serious, unanticipated setback occurs, and instead of taking 10 days, task T5 takes up to 40 days. Draw up new bar chart showing how the project might be reorganized.

Ex 22.6 Fixed-price contracts, where the contractor bids a fixed price to complete a system development, may be used to move project risk from client to contractor. If anything goes wrong, the contractor has to pay. Suggest how the use of such contracts may increase the likelihood that product risks will arise. Fixed-price contracts are not a good idea if you want high quality code from this contract. Fixed budget put a bunch of pressure on the contractor to get the job done. If the contractor runs in to any kind of problem such as developing code, losing a team member, illness, or family emergency, this is going to greatly affect the code. Since no extra money will be made to spend more time on the product problems my be fixed poorly or parts of the code is rushed and not high quality.

Ex 21.4 Explain why an object-oriented approach to software development may not be suitable for real-time systems. Object-oriented approach is not suitable for real-time systems because real-time systems need to respond very quickly and accurately and objects may over complicate it and not run fast enough. Any kind of delays would make a real-time system not "real-time." Object-oriented design is just too complex and not fast enough for real-time systems.

The team project has been an experience. We have changed projects twice but we are happy with OpenMRS right now. Last week we lost one of our group members and even though Wright and I are having to pick up his slack, communicating and meeting up is much easier and simpler for our team now. It must be destiny or fate that Ryan would drop this class and leave our group because now team 2 is back to two members as it was in the beginning. We started off the project with poor file organization. We did not have everyone linked to our github repo correctly so we all did not have uniform code. Now we have that all straight and have our repo organized and uniform between all members. Wright and I have made a lot of progress since losing a group member. We have a driver set up to run our test cases right now but we are considering having a super driver in the testAutomation folder and having sub drivers inside the OpenMRS project in the correct packages to run and test the OpenMRS methods. Rig...