HW13: Chapter 8

8.7 > Write a scenario that could be used to help design tests for the wilderness weather station system.

Billy works for a wilderness weather station out in Lander, WY. He spends a lot of time at work because he often gets snowed in and has to spend the night. This gives him plenty of time to test the weather station software. First, he has to log onto the system using his weatherman username and password. 

Billy usually first checks the status of the satellitle communcations (SatComm) and the regular communications (Commslink) link to ensure that the summary is being collected from up-to-date data. He then will request a weather data summary report from satellite communications and receive an acknowledgement of this request. 

Billy knows the weather station will send him a report if it is unable to collect data via the Commslink and it will also acknowledge that he requested a report. Always alone and drinking coffee, Billy looks forward to receiving the summary report of the weather data to give him something to do on long snowy days at work. 

8.10 > A common approach to system testing is to test the system until the testing budget is exhausted and then deliver the system to the customers. Discuss the ethics of this approach for systems that are delivered to external customers. 

This is not a very ethical approach. Testing is time-intensive and often leads to changes in software as the tests reveal issues. The testing period should have plenty of time devoted to it to ensure that a customer is getting, if not a totally bug-free product, at least a product that has undergone extensive testing before it was deemed appropriate to receive money for. A testing budget should also be a little bit larger because of its importance to a project. 

If a software company develops and delivers software to an external customer without putting in significant testing time, then how can the software company be sure that they will get that customer back? A company can only ensure returning customers if they have put the time and effort into making their product the best it can be for the requirements asked for and tested it effectively to the best of their abilities.

HW12: Mythical Man Month

+Readings:

>Reflections:

Chapters 1 through 4 of Mythical Man Month by Computer Science Professor Frederick Brooks of the University of North Carolina at Chapel Hill revel in topics ranging from the joys of programming to the challenge of determining what makes a good programmer versus a weak one. The main concept of Chapter 2 is Brooks’ Law of the Mythical Man Month.

A man month, according to Brooks, is a unit of measurement that is often used in software engineering to measure the amount of time a project will take if one person is working on it for a month. Interesting concept - since it depends so much on the actual man (or woman!) themselves. According to the Agile Manifesto, software developers must trust each other to get work done: “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done” (Agile Manifesto, clause 5). Perhaps this is the kind of worker Brooks refers to in man-month-units. I used to find it hard to just blindly trust that others in the team will get work done without some micromanaging, but I think the last couple of years have taught me that encouraging people to work hard right from the very beginning and setting an example are usually enough to spur self-motivation. 

The Mythical Man Month is mythical, according to Brooks, because it is not a reliable unit of measurement for software engineering. If you have a problem that cannot be solved in one Man Month, adding more men to the project will surely slow it down (Brooks 17). He claims that, because the medium with which we work with is intangible, adding more people to a project does not speed up the process of coming up with a solution (also, is there a spelling error on page 13’s quote or is it just me??). I really enjoyed how Brooks explains the connections between programmers, the medium of software, and how optimistic we are about working through problems:

“The programmer builds from pure thought-stuff: concepts and very flexible representations thereof. Because the medium is tractable, we expect few difficulties in implementation; hence our pervasive optimism. Because our ideas are faulty, we have bugs; hence our optimism is unjustified” (Brooks 16)

I also think the point he makes about our ideas being defective is a good one - because we work with “pure thought-stuff”, we are more likely to introduce errors in our programs because there are errors in our thought processes (especially if you are trying to get an entire team the think the same way). 

Even though Brooks seems to indicate that there are many flaws to software engineering techniques and some of those flaws are actually not correctable (like in Brooks’s No Silver Bullet) nor will ever be correctable, he remains optimistic about our progress. How could you not?? The feats that have been accomplished with software in the last 50 years are magnificent!

I’ll end with a nice quote: “Perhaps it is merely that computers are young, programmers are younger, and the young are always optimists” (Brooks 14). Yes we are!

HW11: Chapter 6

6.4 > Draw diagrams showing a conceptual view and a process view of the architectures of the following systems:

A ticket machine used by passengers at a railway stations.

A computer-controlled video conferencing system that allows video, audio, and computer data to be visible to several participants at the same time.

A robot floor-cleaner that is intended to clean relatively clear spaces such as corridors. The cleaner must be able to sense walls and other obstructions.

All flowcharts made with www.gliffy.com

Update on Team Progress

Why not discuss our class project on my blog? Blogging is supposed to reflect changes in learning experiences, so maybe I will occasionally write about how my team is progressing with the class project. 

This semester we work in teams of three to download an open source project and run tests on it. My team (Team International) consists of me and classmates Tony Tang and Gui Costa. The three of us did not know each other when the semester started - I think Gui and Tony maybe had classes together before, though. 

At first, we chose the open source mWater project - this is an app that you can download on Android and it tells you what the quality of the water nearby is like - this is particularly useful for third world country users. Documentation for the mWater app (whose repo can be found on GitHub) is not helpful and there is not a lot of it. The GitHub repo has some information in it, but not much in the way of instructions for downloading, compiling, and running the code. Most of all, there are a lot of dependencies for the source code and it was impossible to figure out what was going on (especially since I had never used GitHub, the Terminal, the Linux Ubuntu OS or Android Studio) before this project started. After meeting with our professor, Dr. Bowring, we decided to change our project to the much better documented Celestia project.

Celestia is a space simulation application that has been around for years. The last update was in 2011 by the original engineers, but we were able to find a recent version of the software in a GitHub account that was trying to bring the project back to life. This revival of the Celestia application is extremely well explained and, although it took us until 3:30am one Monday night, we successfully cloned the repo, installed dependencies, compiled, and ran the application (to much exhausted cheering).

Today, we worked on writing out very plain instructions that anyone can follow as long as they have a fresh Virtual Box running a 64-bit Ubuntu OS. We were tired of navigating around browsers trying to find the installation commands for everything - so we just consolidated it.

Here is a link to our repository - it is a work in progress! Overall, our team is moving along nicely - next comes the testing and becoming experts in C++ in order to even understand the testing. More on that later!

HW10: Chapter 5

5.3 > You have been asked to develop a system that will help with planning large-scale events and parties such as weddings, graduation celebrations, and birthday parties. Using an activity diagram, model the process context for such a system that shows the activities involved in planning a party (booking a venue, organizing invitations,,etc. ) and the system elements that might be used at each stage.

 

5.5 > Develop a sequence diagram showing the interactions involved when a student registers for a course in a university. Courses may have limited enrollment, so the registration process must include checks that places are available. Assume that the student accesses an electronic course catalog to find out about available courses.

 

5.7 > Based on your experience with a bank ATM, draw an activity diagram that models the data processing involved when a customer withdraws cash from the machine.

 

5.8 > Draw a sequence diagram for the same system. Explain why you might want to develop both activity and sequence diagrams when modeling the behavior of a system.

It is better to have both representations of the system so that the developers and clients have a very clear idea of how everything works together. Having multiple viewpoints of a process leads to less misunderstandings later on.