Part 1: Personal Software Engineering

Chapter 1: Metaphors for Software Development
1.1 What is software?
1.1.1 Software is not a mass-produced commodity.
1.1.2 Software never wears out no matter how much you use it.
1.1.3 Most software is custom products.
1.1.4 Software must be easily upgradeable.
1.1.5 Software does not exist independently.
1.2 Comparison with other professional fields
1.2.1 The Artist's Programmer
1.2.2 The Programmer as Architect
1.2.3 Programmer as Engineer
1.2.4 Programmers as Technical Craftsmen
1.2.5 Are you more of an artist, architect, engineer, or craftsman?
1.3 Software Engineering
1.3.1 A Formal Definition of Software Engineering
1.3.2 Project Size
1.3.3 How Does Software Engineering Fail?
1.4 Software Craftsmanship
1.4.1 Education
1.4.2 Apprenticeship Training
1.4.3 Software Wanderer
1.4.4 A skilled craftsman who has reached the level of a master
1.4.5 How Does Software Craftsmanship Fail?
1.5 How to Write Great Code
1.6 References

Chapter 2 Productivity
2.1 What is productivity?
2.2 Comparing Programmer Productivity and Team Productivity
2.3 Personnel hours and actual working hours
2.4 Conceptual and practical complexity of the project
2.5 Productivity Forecast
2.6 Productivity Measurement Indicators and Their Need
2.6.1 Executable file size metrics
2.6.2 Machine Instruction Measurement Metrics
2.6.3 Code Line Metrics
2.6.4 Statement count metric
2.6.5 Function Point Analysis Method
2.6.6 McCabe Cyclomatic Complexity Metric
2.6.7 Other metrics
2.6.8 Problems with Measurement Indicators
2.7 About the survey results that say programmers write ten lines of code a day
2.8 Development Period Estimation
2.8.1 Estimating the Development Duration of Small Projects
2.8.2 Estimating the development period for medium- and large-scale projects
2.8.3 Problems with Estimating Development Periods
2.9 Project Management in Crisis Situations
2.10 The Secret to Improving Productivity
2.10.1 Careful Selection of Software Development Tools
2.10.2 Overhead Management
2.10.3 Setting clear goals and milestones
2.10.4 Motivating Yourself
2.10.5 Maintaining Focus and Eliminating Distractions
2.10.6 When you feel bored, try doing something else.
2.10.7 Create an environment conducive to self-development.
2.10.8 Ask for help when you need it
2.10.9 Revitalizing the Loose Team Mood
2.11 References

Chapter 3 Software Development Model
3.1 Software Development Life Cycle
3.2 Software Development Model
3.2.1 Abbreviated model
3.2.2 Waterfall Model
3.2.3 V model
3.2.4 Iterative Model
3.2.5 Spiral Model
3.2.6 Rapid Application Development Model
3.2.7 Incremental Model
3.3 Software Development Methodology
3.3.1 Traditional (predictive) methodologies
3.3.2 Adaptive Methodology
3.3.3 Agile Methodology
3.3.4 Extreme Programming
A Guide to Simple Design
3.3.5 Scrum
3.3.6 Target-driven development
3.4 Software Development Models and Methodologies for Great Programmers
3.5 References

Part 2 UML

Chapter 4: Overview of UML and Use Cases
4.1 UML Standard
4.2 UML Use Case Model
4.2.1 Use Case Diagram Elements
4.2.2 Use Case Package
4.2.3 Use Case Inclusion
4.2.4 Use Case Generalization
4.2.5 Use Case Extensions
4.2.6 Use Case Narrative
4.2.7 Use Case Scenarios
4.3 UML System Boundary Diagram
4.4 Areas beyond use cases
4.5 References

Chapter 5 UML Activity Diagrams
5.1 UML Activity State Symbols
5.1.1 Start State and End State
5.1.2 Activities
5.1.3 Status
5.1.4 Transition
5.1.5 Conditional Expressions
5.1.6 Merger point
5.1.7 Events and Triggers
5.1.8 Fork and Join Synchronization
5.1.9 Call sign
5.1.10 Partitions
5.1.11 Notes and Annotations
5.1.12 Connector
5.1.13 Other Activity Diagram Symbols
5.2 Extending UML Activity Diagrams
5.3 References

Chapter 6 UML Class Diagrams
6.1 Object-Oriented Analysis and Design in UML
6.2 Visibility in class diagrams
6.2.1 Visibility of public classes
6.2.2 Visibility of Private Classes
6.2.3 Visibility of Protected Classes
6.2.4 Visibility of Package Classes
6.2.5 Adding Visibility Types
6.3 Class Attribute Elements
6.3.1 Visibility of properties
6.3.2 Values ​​derived from properties
6.3.3 Attribute Names
6.3.4 Data Types of Attributes
6.3.5 Operation Data Types (Return Values)
6.3.6 Expressing the plurality of attributes
6.3.7 Default property values
6.3.8 Property Strings
6.3.9 Attribute Grammar
6.4 Class Operation Elements
6.5 Relevance of UML Classes
6.5.1 Class Dependencies
6.5.2 Class Associations
6.5.3 Class Set Relationship
6.5.4 Class Composition Relationships
6.5.5 Characteristics of Class Relevance
6.5.6 Class Inheritance Relationships
6.6 Objects
6.7 References

Chapter 7 UML Interaction Diagrams
7.1 Sequence Diagram
7.1.1 Lifeline
7.1.2 Message Types
7.1.3 Message Labels
7.1.4 Message Number
7.1.5 Protection Conditions
7.1.6 Repeated execution
7.1.7 Long Delays and Time Constraints
7.1.8 External Objects
7.1.9 Activation Bar
7.1.10 Branching
7.1.11 Alternative Flow
7.1.12 Creating and Deleting Objects
7.1.13 Sequence Fragments
7.2 Communication Diagram
7.3 References

Chapter 8: Other UML Diagrams
8.1 Component Diagram
8.2 Package Diagram
8.3 Deployment Diagram
8.4 Binding Structure Diagram
8.5 Statechart Diagram
8.6 Expanding Interest in UML
8.7 References

Part 3 Documentation

Chapter 9 System Documentation
9.1 Types of System Documentation
9.2 Change History Tracking Feature
9.2.1 Applying Traceability to Developer Documentation
9.2.2 Tag Format
9.2.3 Requirements History Traceability Matrix
9.3 Verification, Review, and Confirmation
9.4 Reducing Development Costs through Documentation
9.4.1 Cost reduction through user needs validation
9.4.2 Cost reduction through review of requirements compliance
9.5 References

Chapter 10 Documenting Requirements
10.1 Source and Traceability of Requirements
10.1.1 Recommended Requirements Format
10.1.2 Characteristics of Excellent Requirements
10.2 Design Goals
10.3 System Requirements Specification
10.4 Software Requirements Specification
10.4.1 Introduction
10.4.2 General Description
10.4.3 Detailed Requirements
10.4.4 Various support information
10.4.5 Example Software Requirements Specification
10.5 Writing Requirements
10.6 Use Cases
10.6.1 Enable/Disable Debug Mode
10.6.2 Enable/Disable Ethernet
10.6.3 RS-232 Enable/Disable
10.6.4 Enable/Disable Test Mode
10.6.5 Enable/Disable USB
10.6.6 Reading DIP Switches
10.7 Writing Use Cases as DAQ Software Requirements
10.8 Writing DAQ Software Requirements Based on SRS
10.9 RTM Updates Using Requirements Information
10.9.1 Requirements Verification by Review
10.9.2 Requirements Verification by Testing
10.10 References

Chapter 11: Documenting Software Design Specifications
11.1 IEEE Std 1016-1998 vs IEEE Std 1016-2009
11.2 IEEE 1016-2009 Conceptual Model
11.2.1 Design Considerations and Design Work Participants
11.2.2 Design Viewpoints and Design Elements
11.2.3 Design View, Design Overlay, and Design Rational
11.2.4 IEEE Std 1016-2009 Conceptual Model
11.3 SDD Required Content
11.3.1 SDD Identification Information
11.3.2 Design Participants and Design Considerations
11.3.3 Design View, Viewpoint, Overlay, and Rational
11.4 SDD Traceability and Tags
11.5 SDD Overview Proposal
11.6 Example of writing SDD
11.7 RTM Updates Using Design Information
11.8 Writing Software Design Documents
11.9 References

Chapter 12: Documenting Software Tests
12.1 Software Test Documentation in Std 829 Standard
12.1.1 Test Process Support
12.1.2 Importance Level and Risk Assessment
12.1.3 Software Development Test Levels
12.2 Test Plan
12.2.1 Master Test Plan
12.2.2 Level Test Plan
12.2.3 Documenting Level Test Design
12.3 Documenting the Software Review List
12.3.1 Example of Writing an SRL Document Outline
12.3.2 Example of writing SRL
12.3.3 Adding SRL items to RTM
12.4 Documenting Software Test Cases
12.4.1 Introduction to the STC Document
12.4.2 Details
12.4.3 Legend
12.4.4 Example of Writing Software Test Cases
12.4.5 RTM update using STC information
12.5 Documenting Software Test Procedures
12.5.1 IEEE Std 829-2009 Software Test Procedures
12.5.2 Extension of the STP Document Overview
12.5.3 Introduction to the STP Document
12.5.4 Test Procedure
12.5.5 Legend
12.5.6 Index
12.5.7 STP Writing Example
12.5.8 Updating RTM with STP Information
12.6 Level Test Log
12.6.1 Introduction to the Level Test Log Document
12.6.2 Details
12.6.3 Glossary of Terms
12.6.4 Some comments on the test log
12.7 Problem Report
12.7.1 Introduction to the Problem Report
12.7.2 Details
12.7.3 Some comments on the problem report
12.8 Test Report
12.8.1 Master Test Report Overview
12.8.2 Level Test Report
12.9 What developer documentation do you really need?
12.10 References

Review: Designing Great Code

* What this book covers

- The need to improve work efficiency through a software craftsmanship model
- How to use the tracking feature to maintain consistency between documents in your documentation work.
- How to write UML requirements based on use case analysis
- Software quality management method based on IEEE documentation standards

* Target audience for this book

It is assumed that you understand one or more procedural or object-oriented programming languages ​​such as C, C++, C#, Swift, Pascal, BASIC, Java, or assembly.
It also assumes that the problems that arise during the design and implementation of software solutions can be concretized.
If you majored in computer science at a technical college or university or completed at least one semester of related courses, you should have no difficulty reading this.
It is assumed that the reader has a basic understanding of computer organization and data representation.


* Author's Note

Before the concept of software engineering became established, software development was thought to be a secret practice carried out by a small number of software craftsmen with skills and accomplishments that were difficult to explain.
Back then, the success of a software project depended on one or two exceptional core programmers, not the team.
The software engineering conceptual model introduced later increased productivity by ensuring balanced capabilities within the development team and reduced reliance on a small number of exceptional developers.


The software engineering conceptual model has had its share of success.
Programmers working in teams can successfully complete large-scale projects that smaller organizations in the past would never have been able to accomplish, but the quality of some key elements falls short of expectations.
Software engineering emphasizes increasing productivity through team-based operations, but at the same time, the creativity, technical skills, and growth potential of individual programmers are sacrificed.
While software engineering can enhance a programmer's skills, it can also limit or reduce the chances of becoming a great programmer.
We all want programmers to reach their full potential, but the rigid rules of software engineering can conflict with their willingness to reach their full potential.

The 'Great Code' series is a small effort to restore the creativity, technical prowess, and growth potential of programmers in the era of software engineering.
This book addresses this topic under the heading of "personal software engineering" and presents ways for individual programmers to improve the quality of their code.
In particular, it introduces methods for writing 'great code' (code that is easy to maintain, enhance, test and debug, document, deploy, and delete).
Great code also means code that is free of "kludges," which are defects that result from irrational decisions or poor planning by engineers or management.
Great code is, in a word, code that the code writer can be proud of.

* Translator's Note

This book is the third book on writing great code by Randall Hyde, who started his career as a software developer (for nuclear reactor control) over 40 years ago, and can be said to be a compilation of methodologies, strategies, practical theories, and systems that have existed in the software development industry over the past 40 years.
In the first and second volumes of the Great Code series, the author introduced effective methods of communicating with hardware and methods of thinking at a low level and coding at a high level. In the third volume, he explains software as an engineering target.


This book systematically explains software development from the software development model to testing and documentation, using consistent examples and flow, so that it can explain the parts that could only be explained through empathy and sincerity, approaching software development from an engineering perspective rather than a product of authorship.


Development topics that were popular in author Randall Hyde's time (e.g., nuclear reactor control) have now shifted to topics like cloud computing, artificial intelligence, quantum computing, and blockchain, and development approaches and methodologies have also become more specialized or even completely changed in context.
But the desire for better software, great software, is something that all developers have in mind.


I think this book would be a good read for someone who started working in software development out of love and suddenly wants to look around the software industry as a whole, check out the development discourse that has existed for the past several decades, and plan how to manage their career as a developer for the next few years.
For these readers, the author meticulously explains not only software development methodology, but also how to efficiently operate a project team, why projects often deviate from their goals, and how to perform daily tasks.
It is also recommended for developers who are thinking about how to do a better job than the project they did last year.