Prior to gaining independence Robert has worked in senior architecture and technical management roles for several software companies providing... [+]
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
Avoiding “ivory towers”: collaboration and coaching
Designing software given a blank sheet of paper
Software design exercise (iteration one)
Day 2 – Visualising Software
Reviewing the diagrams from the software design exercise
UML versus informal sketches
A lightweight approach for effective NoUML sketches
Software design exercise (iteration two)
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 TrainingThe 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.