Introduction to software engineering and project management methodologies like Waterfall and Agile. In addition to discussing some practices and tools like Version Control Systems, CI/CD, Code reviews and testing strategies.
2. ● Programming Effort vs. Software
Engineering
● Waterfall Methodology
● Agile Methodology
● Practices and Tools in SWE
○ Version Control Systems
○ CI/CD
○ Code Review
○ Testing
● References and Resources
Today’s Agenda
4. ● Programming is concerned only about
writing functional code.
● The result is usually a prototype not a
full product.
● We don’t give care much thought about
documentation.
● The team size is limited in number
Programming Effort VS. Software Engineering
5. The application of a systematic,
disciplined, quantifiable
approach to the development,
operation, and maintenance of
software; that is, the application
of engineering to software.
6. ● Time
● Scale
● Complexity
Programming Effort VS. Software
Engineering
7. ● What is the expected lifespan
of your code?
● The shorter the lifespan of the
code the less it’s affected by
time.
Programming Effort VS. Software Engineering
8. ● How many people are involved?
What role do they play in the
development and maintenance?
● As we scale, complexity emerge in
team organization, system
components and policies and
practices.
Programming Effort VS. Software Engineering
9. Programming Effort VS. Software Engineering
● In SWE we're always forced to
evaluate the trade-offs between
several paths forward.
● The stakes are sometimes high,
and often with imperfect value
metrics
12. Project Management Methodologies
● Waterfall is a linear sequential model.
● Development process is divided into
distinct phases.
● Each phase is well documented.
15. Project Management Methodologies
● No room for change.
● Working software is produced late in
the process.
● High amount of risk and uncertainty.
Requirements
Design
Implementation
Verification
Deployment
Maintenance
16. Project Management Methodologies
● When the requirements are well
defined, clear and fixe.
● The project is short.
● When time and money are secondary
considerations.
● When the technology is understood
17. In software, we rarely have meaningful
requirements. Even if we do, the only
measure of success that matters is
whether our solution solves the
customer’s shifting idea of what their
problem is.
18. Project Management Methodologies
● Software by nature is not tangible.
● Different Background.
● Time:
○ Unknown requirements.
○ Changes in the industry.
○ New competitors.
○ New regulations.
○ Different decision makers.
19. Project Management Methodologies
● Individuals and interactions over
processes and tools.
● Working software over
comprehensive documentation.
● Customer collaboration over
contract negotiation.
● Responding to change over
following a plan.
20. ● Our highest priority is to satisfy the
customer through early and
continuous delivery of valuable
software.
● Welcome changing requirements,
even late in development. Agile
processes harness change for the
customer's competitive advantage.
Project Management Methodologies
21. ● Deliver working software frequently,
from a couple of weeks to a couple
of months, with a preference to the
shorter timescale.
● Business people and developers
must work together daily
throughout the project.
Project Management Methodologies
22. ● Build projects around motivated
individuals. Give them the
environment and support they
need, and trust them to get the job
done.
● The most efficient and effective
method of conveying information to
and within a development team is
face-to-face conversation.
Project Management Methodologies
23. ● Working software is the primary
measure of progress.
● Agile processes promote
sustainable development. The
sponsors, developers, and users
should be able to maintain a
constant pace indefinitely.
Project Management Methodologies
24. ● Continuous attention to technical
excellence and good design
enhances agility.
● Simplicity--the art of maximizing the
amount of work not done--is
essential.
Project Management Methodologies
25. ● The best architectures,
requirements, and designs emerge
from self-organizing teams.
● At regular intervals, the team
reflects on how to become more
effective, then tunes and adjusts its
behavior accordingly.
Project Management Methodologies
31. Grand principles that generate no
action are mere vapor. Conversely,
specific practices in the
absence of guiding principles are
often inappropriately used.
34. Practices and Tools
● Enhances development speed.
● Reduce errors and conflicts.
● Team members can contribute
from anywhere.
● Helps in recovery in case of any
disaster.
● Tracks who, what, when, why
changes have been made.
35.
36. Practices and Tools
● Branching and merging.
● Committing.
● Diffing (reviewing differences).
● Conflicts.
37. ● Continuous Integration (CI): a set of
scripts executed every time a
change is made.
● Continuous Delivery (CD): the app is
also deployed continuously.
However, you trigger the
deployments manually.
● Continuous Deployment: similar to
CD. The difference is that changes
are deployed automatically
Practices and Tools
38.
39. ● Does this code change do what it
is supposed to do?
● Can this solution be optimized?
● Can a library, API or framework be
used or un-necessarily used?
● Does the change follow best
practices and architecture?
● Is there any logical errors?
Practices and Tools
40. ● Written in the programming
language of the system.
● Specifies the system at the
lowest level.
● Written before production code
(TDD).
● Executed as part of CI.
Practices and Tools
System Tests
Exploratory
Component Tests
Integration Tests
Unit Tests
41. Practices and Tools
● Written against individual component of
the system.
● Each component encapsulate business
rule(s).
● It passes input data to the component and
gathers the output. other components are
decoupled by mocking.
● IT covers the happy-path situation and
obvious corner cases.
System Tests
Exploratory
Component Tests
Integration Tests
Unit Tests
42. Practices and Tools
● These tests are for larger systems that have
many components.
● Specifies how well the components
communicate with each other.
● Any other components are decoupled
● They don not test business rules.
● They include performance and stress
testing.
● Executed infrequently.
System Tests
Exploratory
Component Tests
Integration Tests
Unit Tests
43. ● Tests the system as a whole.
● Written by system architects and
tech leads
● Executed infrequently.
● Testing coverage is about 10% as
it test the system construction not
the behavior.
Practices and Tools
System Tests
Exploratory
Component Tests
Integration Tests
Unit Tests
44. ● Manual tests (not automated
nor scripted).
● Explores the system for
unexpected behavior.
● Tests the system against
human interactions
Practices and Tools
System Tests
Exploratory
Component Tests
Integration Tests
Unit Tests
46. References and Resources
● Learning Agile - Andrew Stellman &
Jennifer Greene.
● Software Engineering at Google – Titus
Winters, Tom Manshreck and Hyrum
Wright.
● The Clean Coder – Robert C. Martin
● Peopleware: Productive Projects and
Teams - Tom DeMarco and Timothy Lister