150 likes | 169 Views
Reflecting on the CSSE 477 architecture course, discussing software engineering principles, project experiences, and key learnings for designing complex software systems effectively. Analyzing the importance of architectural skills and applying them to real-world projects in the software engineering program.
E N D
Right – Sunset at the Louvre, in Paris From http://weheartit.com/entry/7831741/via/patyperez. CSSE 477: Swre Arch –This year’s course… Steve Chenoweth Tuesday, 11/8/11 Week 10, Day 2 Reflections!
Today – Ta Da (almost)! • What was in this course? • Architecture – What was the point? • All those pesky Projects!
What was in this course? • Syllabus • Exercises on architecture • Schedule • Project intensive • We used Bass’s book (“SA”) Book nickname – Tweety
The point – How was this important to your SE program of study? Software Engineering Student Outcomes: • Apply software engineering theory, principles, tools and processes, as well as the theory and principles of computer science and mathematics, to the development and maintenance of complex, scalable software systems. • Design and experiment with software prototypes • Select and use software metrics • Participate productively on software project teams involving students from a variety of disciplines • Communicate effectively through oral and written reports, and software documentation • …
Projects – plan was: • Continue same projects where you were designers in 374 and developers in 375, as vehicle for arch studies. • Or some alternative project you proposed (and a team goes for!) • Occasionally work with the clients you had before, if appropriate: • E.g., If scope turns out not to be big enough, get more req from the clients • I think nobody did that this term, but there’s a chance on some of the projects to turn-in new versions for open source, etc.
Main theme throughout projects • Learn about some architectural skill & • Applied it to your project • We also covered general topics to go with, as you worked on these skills. E.g. • First week: Worked on a performance skill, but also heard about “what architecture is.” • Next week: Architectural styles. • Then: Designing an arch, reconstructing, analyzing. • Then: Wrote an architecture document. • Finished with: What are product lines? What’s SOA?
Course style • More like real projects! • You get theory & try to apply it • Some things work better than others! • You contribute by describing your results • Also more like senior project • More like grad school SE
Arch – What was the point? • Get the things right about a whole system: • Overall functionality • Quality attributes (QA’s) • … both to meet the needs of the stakeholders, • especially the client and the users! • I.e., the architecture enables the solution to meet the acceptance criteria in an economical and socially acceptable way
In CSSE… • A course is like an experiment. • We try new things and document those. • Discover what works and what doesn’t. • Checkpoints – • How you do on assignments & overall • How you liked it, right about now • How you liked it, after you have been doing it
How’d you do? • As of the end of week 9, • Doing things like technical leaders do…
What did last year’s class recommend? • Even the spread of assignment due dates (e.g., homework versus project work). • Did a lot of that this year • Try fewer separate pieces to the project, with more depth on those. • Didn’t do, but will be interested in your views • Less homework. • Did some of that • Continue trying some variant of the term paper (but perhaps a different flavor). • Looking at what you did as additional options
And what do our alums recommend for this course? • Software leadership experience, like understanding diverse clients and users • Solving the harder problems of large systems, like distributed development, and product lines • “Current architectures” – patterns, OO, agile methods, SOA • Relationships to other fields – like hardware, other kinds of engineering
What else plays a role? • What you knew before this class? • Should we do a pre-course survey? • Your preferred learning styles, and mine: Systems experience promotes this shift! Sec 1 Sec 2
And who was the software architect? • The designer who gets up in front of the client and says, “This is how we’re going to solve your problem, and I’m responsible for it.” • The designer who gets up in front of the implementers and says, “Here’s how it works and here’s what each of you has to do, technically, to make that happen.” • It’s essence of technical leadership! • You, these past 10 weeks!
You learned that functionality and QA goals are… • Way harder on larger systems • Tricky to do for diverse audiences • Partly still art forms • But we do have generally accepted heuristics and best practices. E.g., • “Find out what the user thinks the system is.” • “Systems designed with good OO practices are way easier to grow.” • “Paying attention to cohesion and coupling makes a system much easier to test and maintain.”