Jump to content

Talk:Software Development Lifecycle: Difference between revisions

From HEIN+FRICKE
Artha.kadamb@heinfricke.team (talk | contribs)
No edit summary
Artha.kadamb@heinfricke.team (talk | contribs)
No edit summary
Line 27: Line 27:


== Purpose & Scope ==
== Purpose & Scope ==
The purpose of this document is to define and standardize the software development lifecycle process to ensure efficient, high-quality, secure, and audit-compliant project delivery.
This SDLC applies to all software development projects undertaken by Hein Fricke, including internal tools, client-facing applications, automation systems, and embedded software solutions.
== Project Management Guidelines ==
* All development activities are structured around agile principles with sprint-based planning.
* Each developer must take '''complete ownership''' of their assigned feature or task — including delivery, quality, and communication.
* Task understanding, requirement clarification, and impact analysis are prerequisites to any design or implementation work.
== Requirement Analysis & Task Ownership ==
* Understand and '''document the user needs''' using documents like Business Requirement Document (BRD) or Functional Requirements Specification (FRS)
* Understand the '''assigned task/feature''' along with its expected outcome.
* Discuss with stakeholders and peers to clarify '''requirements, assumptions, and dependencies'''.
* Perform '''code impact analysis''' — identify affected components and modules.
* Document expected code changes clearly in the associated task/story.
== Planning & Estimations ==
* Define the project scope, timeline, and resources
* Provide '''realistic estimates''' covering:
** Development
** Unit testing
** Functional testing
** Regression testing
* Avoid both over- and under-estimation; validate estimates with your lead.
* Update estimates as the understanding of the feature evolves.
== Task Management in Odoo ==
* Create a new '''story''' with proper ID and a clear, self-explanatory description.
* Break the story into '''sub-tasks''', each representing a functional block or logical unit.
* Follow task progression: '''Todo → In Progress → Complete'''.
* Ensure not too many tasks remain under ''In Progress''; this should reflect actual work in progress.
* Reassign completed tasks to testers only after meeting all acceptance criteria.
== Time Bookings & Dashboard ==
* Book time '''daily''' with descriptive, meaningful comments.
* Complete time logs '''before logging off''' every day.
* Update the '''client dashboard''' (e.g., JIRA) regularly to reflect weekly progress.
* If access is restricted, coordinate with a peer to ensure updates are made.
== Design & Implementation Best Practices ==
* Code the application based on design documents.
* Do not start coding immediately — begin with:
** Data model design
** Algorithm planning
** Peer discussion for design validation
* Document assumptions and Q&A threads in the '''ODOO story''' for transparency.
* Prioritize '''root cause analysis via data inspection''' before code review for bugs.
== Source Code Management ==
* Create a '''feature branch''' from the latest develop branch.
* Commit changes '''daily''' with messages starting with the ODOO Story ID.
* Push changes once tested and stable.
* Follow Java and organizational coding standards.
* Perform thorough unit testing before marking the task as complete.
== Testing & Quality Assurance ==
* Verify the software functions as expected and meets requirements.
* Test '''both best-case and worst-case''' scenarios.
* Keep '''unit test cases updated''' and ensure they cover all core logic.
* Get your '''code peer-reviewed''' — it is the developer’s responsibility to initiate and complete this early, especially for large features.
* After review and testing, merge the feature branch into '''staging''' for final testing.
* Ensure '''minimum rework''' — this reflects strong initial analysis and testing quality.
== Finalization & Release ==
* Fix identified bugs and get confirmation they don’t introduce regressions.
* Limit rework by validating changes during the SDLC, not post-QA.
* Once ready for release, merge changes into the '''develop''' branch in time for the next delivery cycle.

Revision as of 11:20, 10 December 2025

Version History

Introduction

This document defines the Software Development Lifecycle (SDLC) followed at Hein Fricke. It provides standardized guidelines for managing software development projects, ensuring clarity, accountability, and consistency across teams.

Purpose & Scope

The purpose of this document is to define and standardize the software development lifecycle process to ensure efficient, high-quality, secure, and audit-compliant project delivery.

This SDLC applies to all software development projects undertaken by Hein Fricke, including internal tools, client-facing applications, automation systems, and embedded software solutions.

Project Management Guidelines

  • All development activities are structured around agile principles with sprint-based planning.
  • Each developer must take complete ownership of their assigned feature or task — including delivery, quality, and communication.
  • Task understanding, requirement clarification, and impact analysis are prerequisites to any design or implementation work.

Requirement Analysis & Task Ownership

  • Understand and document the user needs using documents like Business Requirement Document (BRD) or Functional Requirements Specification (FRS)
  • Understand the assigned task/feature along with its expected outcome.
  • Discuss with stakeholders and peers to clarify requirements, assumptions, and dependencies.
  • Perform code impact analysis — identify affected components and modules.
  • Document expected code changes clearly in the associated task/story.

Planning & Estimations

  • Define the project scope, timeline, and resources
  • Provide realistic estimates covering:
    • Development
    • Unit testing
    • Functional testing
    • Regression testing
  • Avoid both over- and under-estimation; validate estimates with your lead.
  • Update estimates as the understanding of the feature evolves.

Task Management in Odoo

  • Create a new story with proper ID and a clear, self-explanatory description.
  • Break the story into sub-tasks, each representing a functional block or logical unit.
  • Follow task progression: Todo → In Progress → Complete.
  • Ensure not too many tasks remain under In Progress; this should reflect actual work in progress.
  • Reassign completed tasks to testers only after meeting all acceptance criteria.

Time Bookings & Dashboard

  • Book time daily with descriptive, meaningful comments.
  • Complete time logs before logging off every day.
  • Update the client dashboard (e.g., JIRA) regularly to reflect weekly progress.
  • If access is restricted, coordinate with a peer to ensure updates are made.

Design & Implementation Best Practices

  • Code the application based on design documents.
  • Do not start coding immediately — begin with:
    • Data model design
    • Algorithm planning
    • Peer discussion for design validation
  • Document assumptions and Q&A threads in the ODOO story for transparency.
  • Prioritize root cause analysis via data inspection before code review for bugs.

Source Code Management

  • Create a feature branch from the latest develop branch.
  • Commit changes daily with messages starting with the ODOO Story ID.
  • Push changes once tested and stable.
  • Follow Java and organizational coding standards.
  • Perform thorough unit testing before marking the task as complete.

Testing & Quality Assurance

  • Verify the software functions as expected and meets requirements.
  • Test both best-case and worst-case scenarios.
  • Keep unit test cases updated and ensure they cover all core logic.
  • Get your code peer-reviewed — it is the developer’s responsibility to initiate and complete this early, especially for large features.
  • After review and testing, merge the feature branch into staging for final testing.
  • Ensure minimum rework — this reflects strong initial analysis and testing quality.

Finalization & Release

  • Fix identified bugs and get confirmation they don’t introduce regressions.
  • Limit rework by validating changes during the SDLC, not post-QA.
  • Once ready for release, merge changes into the develop branch in time for the next delivery cycle.