Book Image

Hands-On Software Engineering with Python

By : Brian Allbee, Nimesh Verma
Book Image

Hands-On Software Engineering with Python

By: Brian Allbee, Nimesh Verma

Overview of this book

Software Engineering is about more than just writing code—it includes a host of soft skills that apply to almost any development effort, no matter what the language, development methodology, or scope of the project. Being a senior developer all but requires awareness of how those skills, along with their expected technical counterparts, mesh together through a project's life cycle. This book walks you through that discovery by going over the entire life cycle of a multi-tier system and its related software projects. You'll see what happens before any development takes place, and what impact the decisions and designs made at each step have on the development process. The development of the entire project, over the course of several iterations based on real-world Agile iterations, will be executed, sometimes starting from nothing, in one of the fastest growing languages in the world—Python. Application of practices in Python will be laid out, along with a number of Python-specific capabilities that are often overlooked. Finally, the book will implement a high-performance computing solution, from first principles through complete foundation.
Table of Contents (21 chapters)
Free Chapter
1
Programming versus Software Engineering

Architecture, both logical and physical

The goal of both logical and physical architecture specifications is to define and document the logical and physical components of a system, respectively, in order to provide clarity around how those component elements relate to one another. The artifacts resulting from either effort could be text documentation, or diagrams, and both have their own advantages and drawbacks.

Text documentation is usually quicker to produce, but unless there is some sort of architectural documentation standard that can be applied, the formats can (and probably will) vary from one system team to another, at a minimum. That sort of variance can make it difficult for the resulting artifacts to be understandable outside the team that it originated with. If there is not a lot of movement of developers between teams, or a significant influx of new developers to...