I'm a student in Computer Science and Engineering 💻 at the Alma Mater Studiorum - University of Bologna.
- Requirements engineering
- which behaviour? Specification document
- Design
- Architectural
- which macro structure? System architecture document
- Detailed
- which micro structure? Detailed design document
- Architectural
- Implementation
- which runnable code? Working code repository
- Testing and Maintenance
- which requirements are met? Satisfying and tested code repository
- Deployment
- is the system successfully online? Running system
Take a look at the Agile Manifesto initiative of 2001.
Do not refuse change, rather embrace it.
Rigour & formality, separation of concerns, modularity, abstraction, anticipation of change, generality, incrementality
DRY (don't repeat yourself): Ensure that all code is unique and avoid duplication.
KISS (keep it simple, stupid): Prioritize understandability! In most cases, simplicity is best.
SRP (single responsability principle): "Software entities (ex. classes) should have only one reason to change."
OCP (open/closed principle): "Software entities should be open for extension but closed for modification."
LSP (Liskov's substituability principle): "Extended code must be substituable for their base version."
ISP (Interface segregation principle): "Make fine grained abstractions that are client specific."
DIP (dependency inversion principle): "High-level modules should not depend on low-level modules. Both should depend on abstractions."
