--Originally published at That Class Blog

Software architecture provides the technical structure for a project. The time in which the software is mapped to diagrams and prototypes, and the program is partitioned into systems and subsystems.
Everything is described in the software architecture document, that contains the software organization, support for changes, reuse or purchase of components, and design of functionalities.

This document has the following categories:

• System Overview: Describe the system in general terms. Help build the developer the idea of what is he going to build. As well as a description of the design alternatives that were considered, and why were or weren’t chosen.
• Conceptual Integrity: Descriptions and diagrams of the almost obvious solution to the problem. Simple, short, and easy.
• Subsystems and Organization: Here the major clusters of functionality must be defined (Output formatting, data storage, analysis, user input…). Usually a complete system hast five to nine subsystems. The responsibilities of each subsystem are stated, and how are they intercommunicated and restricted.
• Notation: Describe the notation that will be used for the pseudocode and diagrams (Such as UML)
• Change Scenarios and Change Strategy: List what parts of the software will need (Most likely) to be changed, and how the team must approach this changes.
• Reuse Analysis and Build vs. Build Decisions: Define what components are going to be developed from scratch, reused (If available) or bought.
• Approach to Standard Functional Areas: Functional areas that the architecture must address:
  • External software interfaces: How is the software expected to communicate with other software.
  • User interfaces: How is it isolated, so that the changes made to the interface won’t affect to the system (And reverse).
  • Database organization: Organization and content of the DB.
  • Data storage: Major data structures and what isn’t stored in the DB.
  • Key algorithms: Defined, or for later definition.
  • Memory management: Allocation of memory.
  • String storage: How is the text stored and retrieved.
  • Concurrency/Threads: How is the concurrency going to be handled if the software is multithreaded.
  • Security: Is the software going to operate in a secure environment?
  • Localization: Is the software going to be translated for other countries or regions to use?
  • Networking: Network operations.
  • Portability: Handle other environments (Android/iOS, Windows/UNIX)
  • Programming language: Specific language?
  • Error handling: Strategy to handle errors.
• Requirements Traceability: Assign each of the requirements to a subsystem.
• Support for a Staged Delivery Plan: Describe how the project will adjust to support staged delivery. What is going to be delivered on each stage.

--Originally published at That Class Blog

Let’s do this fast folks, because this chapter was looooooooong.

So, first things first. What is quality? We have to thank McConnel for this simple definition: “the degree to which the software satisfies both stated and implied requirements”. Easy to understand. Perfect.

But why is this important? Because keeping defects controlled affects the development speed, cost and characteristics. A delivered low-quality software increases the cost of end-user support, among other things. McConnel emphasizes in remembering that the end-user tends to forget the delivery time of the software, but not if they liked using it. They forgive taking even taking more time than expected if they will enjoy using the software.

And how to keep the quality up at all times? Using the Quality Assurance Plan. The team must commit to the QA Plan. The activities of the QA must be planed and committed to writing, the QA must be established at least at the same time as the project requirements, a group that will take care of the quality must exist, with capable people, and finally, all the QA activities must be well funded.

And which activities conform the QA Plan?

• Defect Tracking: Keep record of every defect that is found during development. The moment of detection, and the moment where the defect was resolved (And how). Its important to keep the information public, so the team can adjust the estimates, and see progress.
• Unit Testing: Testing made by the developer who wrote the code. The unit can refer to any programming entity. It’s informal.
• Source-Code Tracing: Carried out also by the person who wrote the code. Consist in going through the code, line-by-line, using a debugger.
• Technical Reviews: This are reviews made by the peers of the code author. Usually are given by the full team, and the QA staff just makes sure this reviews are being carried out. Technical reviews have a pattern:
  • Notification and distribution: The code’s author notifies to the QA team that the work is ready to be reviewed. The material is distributed to the corresponding people.
  • Preparation: Reviewers review the work, using checklists of common errors. They schedule a review meeting.
  • Review meeting: Evaluate the work alongside the developers and a moderator. The main objective is to detect defects.
  • Review report: The results of the meeting are written to paper, committed, and added to the defect tracking.
  • Follow-up: The developer applies the changes, which are evaluated again, and if approved and passes the review, the material is added to the list of materials that have been successfully reviewed.
• Integration Testing: Test the code developed with already tested code, which has been integrated to the complete system.
• System Testing: Execute the complete software to find defects. This is by no means a complete way to find all of the defects.

Sometimes companies also use Beta Testing. Even if the book doesn’t recommend it as much as the other tactics (Which are internal), it might be helpful to consider using it, because of the great final-user feedback the developers might receive.

And that’s it. Let’s not stop the testing, until we run out of cake…