Software Engineering

Planning Changes

Planning changes is part of overall change management and should be viewed as a continuous process aimed at refining and improving your software product

  • Things to consider when planning changes include the need for change
  • The amount and complexity of the changes which is related to the time and resources needed for the changes
  • Implementation of the changes
  • Reviewing and adjusting the changes for optimal results
  • The benefits of effective change planning include:
  • Increased project success rates
  • Improved efficiency and reduced costs
  • Better risk management
  • Improved software quality

Checklists

The use of checklists is considered a best practice that:

  • Prevents the omission of vital steps (due to human error/forgetfulness)
  • Keeps the project more focused and reduce scope creep
  • Facilitates communication between team members

You should try to come up with more realisitic/managable tasks for each change or addition you want to make. Here’s an example of a previous burndown checklist I made.

https://github.com/zoe-coding123/zoe_2025_2/issues/13

This is not the best example as in this case I have too many tasks and maybe not all of them are the most realisitic. But this is the general idea.

Burndown Charts

Burndown charts help teams visualize progress and predict the time needed to reach specific goals

  • Sprint burndown charts help monitor short term goals
  • Release burndown charts help track long term progress across multiple sprints
  • Coding with comments
  • There are several benefits when coding with comments including:
  • Enhanced readability and maintainability
  • Comments can help explain complex logic
  • Facilitate collaboration between team members
  • Provide context for design/coding decisions

Some best practices for writing code comments include:

  • Using comments strategically and purposefully
  • Updating comments as needed
  • Using proper grammar and spelling
  • Making sure comments are written so that people other than the original developer can understand

Development Help Documentation includes:

Product Documentation such as:

  • Requirements and Architecture Descriptions which provide system details
  • User Documentation such as tutorials and troubleshooting manuals

Process Documentation such as:

  • Coding Standards, Backlogs, and Roadmaps which describes how the team works when developing the software
  • Building a Lesson

When building a lesson meant to teach software engineering skills, consider incorporating elements that:

  • Provide guidance and support
  • Use real-world examples
  • Emphasize collaboration
  • Allows for feedback

Lessons should be structured to

  • Focus on fundamentals
  • Learn through hands-on exercises

Building a Lesson

When building a lesson meant to teach software engineering skills, consider incorporating elements that:

  • Provide guidance and support
  • Use real-world examples
  • Emphasize collaboration
  • Allows for feedback

Lessons should be structured to

  • Focus on fundamentals
  • Not be too hard to understand
  • Learn through hands-on exercises