Robert is a regular speaker at conferences, meetups and corporate software events and can be found speaking about topics as diverse as behavioural microeconomics in software development to implementing web services on 8-bit microcontrollers. He is organiser of the Oslo Python group and holds a Ph.D. in a natural science.
Hilsen fra fornøyd deltaker:
" Fenomenalt å ta et steg ut av koden og bedre forstå viktigheten og forventningene til en arkitektrolle. Et veldig bra kurs som kan anbefales til alle utviklere"
- I’m not sure what software architecture is about, and how it’s any different from design.
- My manager has told me that I’m the software architect on our new project, but I’m not sure what that actually means.
- I want to get involved in designing software but I’m not sure what I should learn.
- I’ve been given some requirements and asked to design some software, but I’m not sure where to start.
- I’ve been asked to write a software architecture document but I’m not sure what to include in it.
- I’m not sure who to talk to in my organisation about how best to integrate what we’re building.
- I understand what software architecture is all about, but I’m not sure how to tackle it on my project.
- My project seems like a chaotic mess; everybody is doing their own thing and there’s no shared vision. Help!
Is this the course for you?
Designing software given a vague set of requirements and a blank sheet of paper is a good skill to have, although not many people get to do this on a daily basis. However, with agile methods encouraging collective ownership of the code, it’s really important that everybody on the team understands the big picture. In order to do this, you need to understand why you’ve arrived at the design that you have.
In a nutshell, everybody on the team needs to be a software architect.
This is a two-day training course about pragmatic software architecture, designed by software architects that code. It will show you what “just enough” up front design is, how it can be applied to your software projects and how to communicate the big picture through a collection of simple, effective sketches. Aimed at software developers, it fills the gap between software development and high-level architecture that probably seems a little “enterprisey” for most developers.
Day 1 – The Design Role
- Introductions and setting the scene
- What is software architecture?
- Architecture and software architecture
- Design versus architecture
- The importance of software architecture
- The software architect role
- Software architects in the development team
- Software architecture role versus lead developer role
- The role and responsibilities
- Coding architects
- Soft skills
- Avoiding “ivory towers”: collaboration and coaching
- Designing software
- Quality attributes
- Designing software given a blank sheet of paper
- Software design exercise (iteration one)
Day 2 – Visualising Software
- Visualising software
- Reviewing the diagrams from the software design exercise
- UML versus informal sketches
- Ineffective sketches
- A lightweight approach for effective NoUML sketches
- Software design exercise (iteration two)
- Documenting software
- The importance of documentation
- Project and documentation stakeholders
- A lightweight approach for software documentation
- Alternative approaches for documenting software
- Software architecture in the development lifecycle
- Software architecture in waterfall, iterative and agile approaches
- “Just enough” up front design
- Evaluating software architecture and prototypes
- Guidance for doing “just enough” in the real world
Our Approach to Training
The course is interactive, with a combination of presentation, group discussion and group working. Throughout the course you’ll solidify everything you learn by defining the architecture for a small software system through a series of exercises focused around a software design exercise and case study.
Is there a practical element?
Yes, you’ll be broken up into groups and asked to design a small software system from nothing but a set of requirements and a whiteboard. This includes:
- Defining the architecture for the case study solution.
- Deciding on the technologies that would be used to implement it.
- Drawing up different views of the architecture to illustrate the software components and their interactions.
- Assessing and justifying that the architecture will satisfy the functional and non-functional requirements.
- Comparing and reviewing what each of the groups has come up with; discussing the choice of technologies, diagram notation and process used to define the architecture.