CS Learning Journal

WELCOME TO WEEK 8 Learning Journal -  This week I reflected on the five most important things I’ve learned in this course and why they stood out to me. The SDLC Phases Understanding the software development life cycle helped me see how projects are structured from start to finish. Breaking work into phases like requirements, design, implementation, and testing makes it easier to stay organized and avoid skipping critical steps. This gave me a better framework for thinking about my own assignments. Agile vs. Plan and Document Learning the differences between Agile and traditional Plan and Document (Waterfall) processes showed me that there is no “one size fits all” approach. Agile focuses on iterations and continuous customer feedback, while Plan and Document emphasizes stability and complete specifications. I chose this because our labs showed how Agile aligns better with frequent testing and changing requirements, which is closer to real-world software. However, it was also...

  WELCOME TO WEEK 7 Learning Journal - CST 438 Describe some of the differences between using an Agile process and using a  Plan and Document (or Waterfall) process.        This week I reviewed the differences between using an Agile process and a Plan and Document (Waterfall) process. In a Plan and Document approach, requirements are written as a detailed SRS during a dedicated requirements phase, with the expectation that they remain complete and stable for the rest of the project. Changes are handled through a formal change control process, which involves evaluating the impact on cost and schedule before updating documents, code, and tests. Design is completed after requirements and is intended to be stable, while cost estimates are based on person-weeks from past experience. Scheduling uses tools like PERT charts with periodic status meetings, and testing is split between developers writing unit tests and QA handling system and acceptance tests. Howeve...

WELCOME TO WEEK 6 Learning Journal - CST 438 Write a weekly entry describing important things you learned this week.        This week I read Chapter 25 on Compute as a Service and learned how Google turned running code into an automated system. For example, instead of rebooting machines by hand when they fail, engineers set up policies to kill and recreate a container or virtual machine automatically after a health check fails. I saw why treating servers as cattle not pets matters. When one node goes down, the system simply stamps out a new instance without any human intervention. Using Linux control groups and namespaces made it possible to safely share machines among different workloads. Writing software for this environment means dividing tasks into small units, storing all important state in durable services such as Spanner or Bigtable, and designing retries so they can run more than once without causing errors. Finally I was struck by the description of the Code...