Talk at the First Israeli Conference on Software Architecture
http://www.iltam.org/sw-arch2014/
Abstract:
In this talk Hayim will present the practical aspects of the role of the Software Architect, including the architect's contribution at the diverse stages of the software development life cycle, and the cooperation with the diverse stakeholders: Developers, Team Leaders, Project Managers, QA and Technical Writers.
Bio: Hayim Makabee was born in Rio de Janeiro. He immigrated to Israel in 1992 and completed his M.Sc. studies on Computer Sciences at the Technion. Since then he worked for several hi-tech companies, including also some start-ups. Currently he is a Research Engineer at Yahoo! Labs Haifa. He is also a co-founder of the International Association of Software Architects in Israel.
3. Roles in Software Development
Software Architect
Product Owner
Developer
Tester
Technical Writer
4. Methodology Decisions
The software architect should participate in decisions about the
software development methodology.
Examples of methodology decisions:
1. Agile methods imply reduced design up-front and thus some form
of emergent or evolutionary design.
2. Test-Driven Development (TDD) reduces the risks associated to
Refactoring and thus requires less detailed design.
3. Pair Programming requires less design and code reviews.
10. Domain Modeling Decisions
Given the Requirements Specification, the software architect
should participate in Domain Modeling.
Examples of domain modeling decisions:
1. Should a relationship be represented as an object or as an
association between two objects?
2. Should an object have a fixed list of attributes or a dynamic set of
properties?
3. Should an attribute be represented as a primitive type or as an
object?
11. Planning for Software Evolution
Planning for software evolution requires a good understanding
of the application’s domain:
Modeling of the main domain entities, their attributes and
relationships.
Refinement of generalization/specialization hierarchies.
Identification of the domain aspects that are not represented in the
current requirements.
Identification of areas of volatility that are likely to change.
Domain analysis should drive the introduction of mechanisms
for flexibility and extensibility.
12. Design Reviews
Design Review:
• Several design alternatives
• All alternatives satisfy FRs
• Different alternatives have
different impact on NFRs
• Discuss trade-offs