Cody Codes Code

This week, we learned about software requirements in the context of Agile, how they are created and changed throughout the software life cycle, and methods of tracking them. In Agile or behavior-driven design, requirements take the form of user stories, which are basic high level statements, often short, that describe functions in a program. User stories are accessible to both stakeholders and developers and can theoretically change and update often due to continual conversations between stakeholders and developers. A acronym to follow for writing good user stories is SMART, which stands for: Specific - User stories should state application/program behaviors clearly without any vagueness.  Measurable - Each user story should be testable, with expected outputs for a given set of inputs. These can also be performance requirements as well. Achievable - Ideally, each user story should be completed in one Agile sprint. If not, stories should be split into smaller ones. Relevant -

This week, we learned about basic project management and the basics of team collaboration in software engineering, including using VCS services such as git, GitHub, and BitLocker.  We also continued our discussion on test-driven development, including test automation. At work, I know several of my team members who have been working on automation efforts for certain tests for a long time, yet as far as I know it has not been an easy effort due to how complex some of these software items are. Five key principles in creating automated tests are FIRST, which is an acronym that stands for the following: F ast: Test cases and test subsets should be relatively quick and easy to run, as well as relevant to current coding tasks. I ndependent: Tests should not rely on preconditions created by other tests so only the subsets needed can be run. R epeatable: Tests should not rely on external factors that cannot be controlled, or values that cannot be controlled. S elf-checkin

This week, we learned about test-driven development, different phases of software testing and methods, and how to write unit tests for Java programs using JUnit.  Test-driven development is about creating requirements for a piece of software, writing tests to pass those requirements, and then developing said software. If the software does not pass these tests, then development resumes until it does or requirements change, which means both tests and software will change. Compared to more traditional methods of "build now, test later", test-driven development ensures software meets requirements and quality standards for customer usage. In JUnit, "MOCKs" are simulated objects or variables that allow program testing without reading or writing real data, which could cause problems. They are also useful for testing invalid inputs without actually crashing a deployed application or live server (which nobody wants). 

I'm back to writing journal entries again! For all my readers who have missed me, it's good to be back. Currently, I am taking CST 438, which is the Software Engineering course. This week, we learned about the principles of software engineering, SaaS (Software as a Service), RESTful APIs, and wrote a program as an introduction to Spring boot with Java. Before taking this class, I was aware of some commonly used software engineering methodologies used today, such as Agile and Waterfall - in fact I believe most of the software development teams at work I know of use Waterfall, while I have heard of other groups in separate divisions following Agile practices. However, I was unaware of other ones such as RUP and Spiral, and I didn't fully understand how SaaS became widespread across the industry. After this first week's assignment and reading, I now understand that software engineering is more than just following Agile or Waterfall practices - the industry has chan