Software Developemnt Taxonomy
Copyright © Heinz Prantner 2008, 2009
last updated: May 09 2009
This
work is licensed under a
Creative Commons Attribution-Share Alike 3.0 License.
"Every philosophical problem starts with 'I don't know'." Ludwig Wittgenstein
"The logic takes care for herself, we only have to watch how she does it." Ludwig Wittgenstein
Plate of 12 Categories, Immanuel Kant, Kritik der reinen Vernunft:
|
Functions of Mind |
Categories |
(I) QUANTITY |
1 |
Common - Allgemeine |
Unity - Einheit |
2 |
Particular - Besondere |
Multitude - Vielheit |
3 |
Singular - Einzelne |
University - Allheit |
(II) QUALITY |
4 |
Affirmative - Bejahende |
Reality - Realitaet |
5 |
Negative - Verneinende |
Negation - Negation |
6 |
Infinite - Unendliche |
Limitation - Limitation |
(III) RELATION |
7 |
Categorical - Kategorische |
Substance - Subsistenz
Inherence - Inhaerenz |
8 |
Hypotetical - Hypothetische |
Causality - Kausalitaet
Dependence - Dependenz |
9 |
Disjunctive - Disjunktive |
Community - Gemeinschaft |
(IV) MODALITY |
10 |
Problematic - Problematische |
Possibilty - Moeglichkeit
Impossibility - Unmoeglichkeit |
11 |
Assertive - Assertorische |
Existence - Dasein
Nonexistence - Nichtsein |
12 |
Indisputable - Apodiktische |
Necessity - Notwendigkeit
Chance - Zufaelligkeit |
The 7 layers of the OSI model
- application
- presentation
- session
- transport
- network
- data link
- physical layer
Table of Contents
Introduction
Software Development is the science and the art of the organization
and movements of information. When it comes to implement new
software or to analyse existing software it is not easy where to
start with and what to look for. The following shall give us a
guideline through the development phases and a generic template
for the software development topics. Our daily comfort or discomfort
strongly relate to the information architecture.
This is work in progress. Chapters vary in their extent.
Treatise
car workshop, photo HP
In everything you do:
- Be Clear! (Planning)
- Be Passionate! (Execution)
- Be Patient! (Reflection)
For SW development you need to:
- Know Thy Technology
- Know Thy System & Environment
- Know Thy Processes
- Know Thy Tools
- Know Thy People
SW Development is done in 5 phases:
- Analysis
- Design
- Implementation
- Verification
- Integration
Analysis starts with "I don't know.", "I don't understand.". Some
get stucked here. Others may jump over. Others get lost in details.
Analysis requires criteria to check against the matter to get
an understanding.
Design is about how you present your thoughts to others. It
may be blurry, funny, complicated, redundant, overloaded, not there,
superficial, wrong. All of them are not good. Design should
be clear and direct. Design requires structure for clearness.
Implementation is the deed, going beyond theory. Implementation
requires style for liability.
Verification is to go beyond pure deed, bringing quality to the
subject: it proves whether it is good or bad deed. Verification
requires strength to reach high quality.
Integration brings all together. If the above steps were the letters
in the alphabet, the integration would be the word, bringing sense
and sound to the subject. Integration requires skill for ingenuity.
(§1) Architecture
Sol Lewitt - Modular Cube - Hallesches Ufer Berlin, photo HP
- Network Architecture
- System Architecture
- Software Architecture
(§1.1) Network Architecture
- Which Services are defined - Service Provider
- Where to find the Services - Service Provider
- How to access the Services - Interfaces, Protocols
- Who is accessing the Services - Service User
(§1.1.1) Network Services
- Voice / Circuit Switching
- Data / Packet Switching
- Messaging
(§1.1.2) Networking Functions
- Initiation / Establishment
- Synchronization / Alignment
- Authentication
- Identification
- Information
- Notification
- Registration
- Ciphering / Encryption
- Transport
- Transaction
- Routing
- Session
- Streaming
- Data Bundling
- Data Fragmentation
- Load Sharing
- Load Changeover
- In Sequence Delivery
- In Time Delivery
- Retransmission
- Flow Control And Congestion Avoidance
- Termination and Graceful Shutdown
- Abortion
(§1.1.3) Communication Protocol Specification
- Definitions
- Protocol Version
- Abbreviations
- Terminology Glossary
- Timer
- Constants & Enumeratios
- States
- Configuration
- Functions
- Formats
- Header
- Trailer
- Parameter
- Messages
- APIs
- MSCs
- References
(§1.2) System Architecture
- Motherboard
- Daughtercards
- Processor
- Memory
- Interfaces
- Devices
(§1.3) Software Architecture
Strategies and Drivers
- requirements driven software model
- feature driven software model
- use case driven software model
- technology / standard driven software model
- frame / environment / system driven software model
Software Organization Topics
- Directory Structure
- Component Structure
- Memory Management
- Lists, Queues, Buffers
- Time
- Timer
- Random
- Compile Time Configuration
- Run Time Configuration
- System Command Processing
- System Management
- Platform Management
- Component Configuration Management
- Event Management
- Data Management
- Statistics Management
- Error Management
- Debug, Trace Management
- Component External Communication
- Component Internal Communication
software model diagrams (according to uml)
- ad - activity diagram
- uc - use case diagram
- cld - class diagram
- sd - sequence diagram
- cd - communication diagram
- sm - state machine diagram
- dd - deployment diagram
- pkd - package diagram
- od - object diagram
- cs - composite structure
- td - timing diagram
- iod - interaction diagram
shapes
environment |
system |
package |
platform |
board |
card
|
area
| script |
shell |
program |
component |
entity |
task |
unit |
thread |
process |
procedure |
instruction |
stream |
object |
module |
box |
container |
bus |
interface |
link |
connection |
socket |
drive |
disk |
host |
modem |
service |
server |
client |
proxy |
gateway |
hub |
router |
switch |
rack |
shelf |
table |
array |
structure |
transaction |
record |
set |
class |
queue |
buffer |
vector |
map |
tree |
iterator |
option |
origin |
destination |
argument |
key |
id |
tag |
bit |
byte |
character |
word |
string |
state |
alarm |
event |
primitive |
message |
command |
request |
indication |
configuration |
confirmation |
acknowledgement |
log |
trace |
file |
sector |
track |
volume |
action |
activity |
terminal |
display |
screen |
monitor |
computer |
controller |
handler |
device |
machine |
engine |
calculator |
generator |
motor |
driver |
tester |
mirror |
base |
floor |
desk |
world |
universe |
(§1.3.3) Design Patterns
The design patterns from Gamma, Helm, Johnson and Vlissides are the
creme of software development. For my own humble attempts on this topic see design patterns.
(§2) Requirements
Requirements purpose:
- what has to be done, what are the functions?
- how it has to be done, what are the attributes?
- when it has to be done, to which version, release it applies to
Requirements origins:
- Customer and Market Requirements; what we have heard
- Standard Requirments; what we have read
- Intern Requirements; what we know
Requirements types:
Requirements record:
- A Unique Requirement ID
- The Requirement Statement/Conformance Statement
- The Requirement Origin (Customer and Market, Standard, Intern)
- The Requirement Type (Function,Attribute,Variant)
- The Reference to Sources
- Comments
- Author
- Date of Creation
- Date Last Modified
- Program Mapping
- Component Task Mapping
Requirement program status:
- NO - not applicable
- YES - applicable
Requirement review state:
Requirement implementation state:
- GREEN, we are good, requirement covered
- YELLOW, clarification needed, review of implementation required
- RED, action required, requirement not covered
- WHITE, not applicable, no status available, status not needed
Requirements layers:
- System Level, high level requirements
- One or more Component Group Levels, intermediate requirements
- Component Level, detailed component related requirements
(§3) Analysis
- problem description
- origin
- felt
- heard of
- experienced
- document
- use case
- impact
- use case description
- analysis criteria description
- technology assessment
- architecture assessment
- use case analysis with given criteria
- proposed solution
- project management considerations
- affected components
- effort estimations
- milestones
(§4) Component Design
This chapter addresses the software layout within a software component regarding the
design principles and design documentation topics.
|
|
|
Raul Walch, "Westfrucht/Porsche", 2007, Holz, ca. 500x200x130cm, Kunstsalon Berlin 2007, Foto HP
|
- Component Design Principles
- Component Design Documentation
(§4.1) Major Software Component Design Principles
- Task List
- Data Model
- Interfaces, Service Definitions
- Object Model, Software Structure, Task Assignment
- Relations and Dependencies
(§4.1.1) Task List
The enumeration of tasks (to do's) for the software component is
crucial for the complete software development cycle (beginning with
requirements and ending in test). For the component structure the
task list provides the initial subdivision and grouping of elements.
(§4.1.2) Data Model
(§4.1.2.1) Managed Objects
The data model identifies the data objects pertaining to the
component. Each data objects (Managed Object) represents the system
view of the known outside world, which may consist of human user
input systems, user information devices, any other device, network
interfaces, network peer elements, and the like. Each data object
(managed object) has a generic set of attributes defined:
- Commands
- Configuration
- States
- Events
- Statistics
(§4.1.2.2) Commands
Specify the list of user commands and command parameter applying to the object.
- create
- modify
- display
- delete
(§4.1.2.3) Configuration
Specify the configuration parameter applying to the object.
- id
- name
- configuration state
(§4.1.2.4) States
Specify the transient state parameter for the object.
- current state
- active
- activating
- inactive
(§4.1.2.5) Events
Specify the events pertaining to the object
- connection up
- connection down
- service active
- service error
- service inactive
(§4.1.2.6) Statistics
Specify the statistics parameter for the object.
- how many
- how often
- how much
- how long
(§4.1.3) Interfaces, Service Definitions
Interface, Service Message Types:
- Request
- Confirmation
- Rejection
- Indication
- Response
Interface, Service Categories:
- Configuration
- Command
- Control
- Operation
- State
(§4.1.4) Object Model, Software Structure, Task Assignment
- Software Structure Design Criteria
- Logical View of Software Structure
- Implementation View of Software Structure
- Mapping of Logical Functions to Implementation Blocks
(§4.1.4.1) Software Structure Design Criteria
Software design criteria:
- Thematic Organization
- By Thematic content; e.g. network functions
- Initiation / Establishment
- Synchronization / Alignment
- Authentication
- Identification
- Information
- Notification
- Registration
- Ciphering / Encryption
- Transport
- Transaction
- Routing
- Session
- Streaming
- Load Sharing
- Load Changeover
- In Sequence Delivery
- In Time Delivery
- Retransmission
- Flow Control And Congestion Avoidance
- Termination and Graceful Shutdown
- Abortion
- Organism Organization
- Event Handling – Input Logic.
- State Event Machine – Control Logic.
- Data Handling, Data Manipulation – Decision Logic.
- Memory Access.
- Action – Output Logic.
- Grammatical Organization
- Local Control, Dealing with multiple input sources, output pipes.
- Causal Control, Trigger to become active.
- Modal Control, Dealing with multiple choices.
- Temporal Control, Dealing with real time.
- Categorical Organization
- Configuration
- Command
- Operation
- Control
- State
- Event
- Statistics
- Algorithm Organization
- Decision, Step Tables - Assembler Style
- Function and Condition Logic - C Style
- List Manipulation - Lisp Style
- Stack Manipulation - Forth Style
- Objects - C++ Style
- Polimorphism, Dynamic Binding
- definition i - by Stephen G. Kochan, Programming in Objective-C, Developer's Library
Polymorphism enables programs to be developed so that objects from different classes
can define methods that share the same name.
- definition ii - derived from Gamma, Helm, Johnson, Vlissides, Design Patterns, Addison-Wesley
Interfaces are fundamental in object oriented systems. Objects are known only through their
interfaces. Different objects conforming to the same interface, are free to implement identical
requests differently. The operation performed depends on both the request and the receiving object.
The run time association of a request to an object and it's method is known as dynamic binding.
Dynamic binding allows to substitute different objects with identical interface for each other at
run time. This substitutability is known as polyphormism.
- addition to above
A [protocol stack] state event machine is a classical exemplar of polymorphic behaviour.
The operation performed per request is determined at runtime by the actual state of the machine.
The polymorphism (known from object oriented systems) may not be that obvious at the first glance
in a procedural language implementation.
(§4.1.5) Relations and Dependencies
Specify the relations and dependencies of sub groups within the component.
- Association
- Aggregation - "has a"
- Inheritance/Generalization - "is a"
- Realization
(§4.2) Software Component Design Documentation
- Major Design Principles
- Task Descriptions
- State Descriptions
- Naming Conventions
- File Structure
- Internal Data Structures
- Internal Software Infrastructure
- Debug and Trace
- Technical Data
- Message Flows
(§4.2.2) Task Descriptions
A component task object is similar to a class in object oriented
languages. It is a protocol stack software component design principle and
thus is independent of any programming language. A component task
is defined by a list of attributes (given below) and is very useful for
several purposes as shown hereby.
Why do we need component task objects?
- Mapping Requirements to Component Tasks allows the bidirectional traceability of design coverage.
- Component Tasks enforce the encapsulation of software functionalities with increase in maintainability of software.
- The encapsulation of tasks enables the definition of clear responsibilites with clean interfaces.
-
- Component Tasks are the main software design criteria. The generic object approach helps to do it right with room for individual, creative solutions.
- The generic approach allows for automatic generation of design documentation.
- If Component Tasks are used for Component Task Use Case Development the Component Tests can be organized by that structure. This test case organization allows to evaluate the test coverage and to find test cases.
- Feature Analysis and Feature Design can be convenient if based on Component Tasks.
- Effort Estimation for Feature Development can be based on Component Tasks.
- Root Cause Analysis can be based on Component Tasks. High Number of issues per task justifies redesign.
Component task object types:
- data - memory control
- container - set(), get(), ...
- stack - push(), swap(), pop(), ...
- queue - add_element(), get_element(), ...
- list - insert(), sort(), delete(), ...
- message - set_parameter(), get_parameter(), encode(), decode()
- coordination task - local control
- state event machine - temporal control
- decision table - causal control
Component task object attributes:
- Name
- Requirements
- Task Internal Data
- Task States
- Task Timer
- Task Access Routines (synchronous get,set functions)
- Task Input Events (asynchronous input events) And Data
- Task Output Events And Data
- Task Activities
- Task Algorithm
- Task Use Cases
plus eventually diagrams
- State Transition Diagram
- SDL Diagram
- Message Sequence Chart
(§4.2.3) State Descriptions
- State Definitions
- State Transition Diagrams
(§4.2.9) Technical Data
- Memory Footprint
- Time Constraints
- Performance
(§5) Feature Design
- Document Information
- Revision History
- Document Review
- References
- Introduction
- (§5.1) Requirements
- (§5.2) Limitations
- (§5.3) Assumptions
- (§5.4) Problem Description
- (§5.5.1) Overview of Problems
- (§5.5.2) Discussion of Problems
- (§5.5) Solution Proposed
- (§5.6) Implementation
- (§5.6.1) Components
- (§5.6.1.1) Component Tasks
- (§5.7) Test Strategy
- (§5.8) Project Managment Considerations
- (§5.9) Problems, Open issues
(§6) Test
- Feature Test
- Regression Test
- Simulation Test
- Component Test
- Target Test
- System Test
- Conformance Test
- Load & Stress Test
- Field Test
- Interoperability Test
Component Task Use Case Definition
Component Task Use Cases may be derived from:
- Standard specification, or
- Standard test specification,
- customer test specification,
- or may be self made.
Protocol Test Cases
- network, peer initiated
- user, local initiated
- collision
- accepted, success
- rejected, denied
- timeout
- protocol error
- failure cases
Stress Cases
- throughput load threshold
- processor load threshold
- flooding attack
- message loss
- message corruption
- service loss
- network delay
- constant delay
- variable delay
Test Case Definition
Each test case must relate to one use case.
Handle with care! Do not copy paste generate wrong information just
because you are sooo in a hurry! Notice: There is exactly _one_ world, which
will be still there in the next moment. So where to do you hurry? But if you
create wrong information now, the same world will be messed up [just a little
bit more than it was already] in the next moment. It is good that you
read such text.
Test Case Header:
Mandatory Fields:
- @TaskID : the component task this test belongs to
- @UseCaseID : the use case this test case is related to
- @TestCaseID : the test case identifier
- @Description : at least a short description of what the test does
- @History : you must fill in when changing the test, say what you did.
Optional Fields:
- @Requirements: list of component requirements this test covers. leave blank
if not known.
- @References : list of references to old test case id, issue id,
standards specification, standards test specification,
customer test specification, etc.
Requirements mapping overview:
(§7) Integration
If I think of a scale from less integrated to more integrated I
would not know the criteria how to measure integration. If I
think of what is best and most integrated within itself, how the big
relates to the small, the heavy to the light, the protrusive to
the embracing, active to passive, synthetic to the organic,
integrated with outside others, room, space, urban architecture,
people, sheeps, landscape and universe, then Henry Moore sculptures
come in my mind as the perfect, perfect integration.
(§8) Software Administration
- Planning
- Issues
- Releases
- People
- Calendar
- Execution
- Documentation
- Implementation
- Verification
- Tools
- Reflection
- History
- Books & Training
- Forum
- Terminology
Issues
Defects are reported for a failure reltated to both:
- Software Functionality (per SW Functional Requirement)
- Software Component (per SW Architecture)
Issue analysis may result in the following:
- Issue Accepted for the component
- Issue Forwarded to another component
- Issue Rejected
For issues relevant to the component the following shall be evaluated
- Assign issue to one or more component tasks (per component functional requirments)
- effort estimation for resolution
- schedule planned release for the fix
- assign resource to do the fix
Over time the following may be interesting for root cause analysis:
- how many issues raised per system functionality
- how many issues accepted per system functionality
- how many issues rejected per system functionality
- how many issues forwarded to other system functionality
- how many issues raised per component
- how many issues accepted per component
- how many issues rejected per component
- how many issues forwarded to other component
- how many issues per component task
- effort spent on analysis for not accepted issues
- effort spent on analysis, documentation, implementation, patch, test, integration for accepted issues
Based on the number of issues over time a quality state can be maintained per component task:
- green
- yellow - requires a code review
- red - requires a thorough code design and architecture review
Documentation
- A--Specs-&-Standards
- B--White-Papers
- C--Analysis
- D--Architecture
- E--Requirement-Specifications
- F--Functional-Specifications
- G--Data-Dictionary
- H--Design-Specifications
- I--Feature-Design-Documents
- J--Interface-Descriptions
- K--Message-Catalogs
- M--Test-Plans
- N--Test-Results
- O--Document-Reviews
- P--Code-Reviews
- Q--Meeting-Minutes
- R--Status-Reports
- S--Manuals
- T--Project-Plans
- U--Organization-Plans
- V--Policies
- W--Legal-Works
- X--Release-Notes
- Y--User-Guides
- Z--Training
Implementation
Workflow
- Setup
- Activate
- Draft
- Review
- Accept
- Integrate
- Release
Tools
- Installation
- Synopsis
- Description
- Options
- Documentation
(§9) Project Management
- Milestones - Goals
- Priorities - Importance and Urgency
- Tasks - What
- Resources - Who
- Calendar - When
- Efforts - How Long
- Costs - How Much
(§10) Working Together
Welt der Schatten, Kunst der Suedsee - Ethnologisches Museum, Staatliche Museen zu Berlin, photo HP
Roles Overview
Roles
- Analysis - Architect
- Execution - Developer
- Verification - Tester
- Scheduling - Project Manager
- Coordination - Department Manager
- Decision - Director
- Representation - Vice President
Find your role and know where you end and someone else begins.
Roles Definitions
Administrator
Tasks
- software installation
- software configuration
Configuration Manager
Tasks
- repository layout
- environment, workspace setup
- build scripts
- release scripts
- software integration
- product configuration
- product release preparation
- product release
Documentation Manager
Tasks
- documentation repository organization
- documentation templates
Product Manager
Tasks
- product key values definition
- product features definitions
- product market requirements
- product customer requirements
- product release planning
Project Manager
Tasks
Quality Assurance
The maintenance of a desired level of quality in a service or product, esp. by
means of attention to every stage of the process of delivery or production.
Tasks
- system test
- reporting, metrics
- issue review and closing
- test environment
- debug and trace infrastructure
Architect
For me perhaps the greatest joy is, while in the process of writing, I see and
understand what belongs and fits together.Vriginia Woolf
Tasks
Business Developer
Tasks
- customer negotiations
- product definitions
Technology Developer
Tasks
- analysis
- specification
- standard
- technology
- requirements
- bugs
- design
- concept paper
- feature design
- component design
- implementation
- verification
- test specification
- component test
- integration
- component release note
- component release
Technical Writer
Tasks
Subject - Concept - Object
Be receptive
Everything we encounter exists already within us as idea or
conception we have for the matter. The real object relates to the
conception we have for that subject and from the difference our
emotions evolve.
Be clear on the subject to understand what the topic is about.
Be clear on the object, be sure to understand correctly what is said
and meant by others.
Be clear on your concept and where are the differences to what comes in.
Be clear on your emotions evolving from this relation.
Be active
State your understanding of what is the matter, subject.
State your understanding of what you have been asked to do or what you want to be done.
Deliver what you have been asked for.
Be reflective
Reflect on the subject, concept, object.
Reflect on the output and go over it from the beginning if necessary.
Reflect on the reactions.
The software implementation is a reflection of what is around it
It may be that if you try to locate the problem in the software
component implementation, that you miss the true root cause at all.
The software component implementation with its structure and
problems is a reflection of what is around the implementation: the
software architecture, the software requirements, the software documents, the
component tests, the component releases, the tools, the process, the
development organization, project management, the management.
If the structures around the software are broken then the software
will be broken.
What we observe can be of one or more of the following major character types:
- despotic, authoritarian
- formal
- nice
- chaotic
where each of them can be of low, medium or high degree.
Despotism
Authority pulls responsibility. The part under authoritarian control
is weakened and the authority over time is overloaded. This (system)
architecture is doomed to break.
Authoritativeness is a result of the wish to be better than others.
Authoritativeness also means to follow authority. Someone following
authority will take the first chance to become authoritarian him-,herself.
We have seen that in life and in software. It does not work well.
Formalism
We engage in formal activity to learn to distinguish between
Right and Wrong. The formal activity relates to a subject which we
have not mastered yet. Then the formal activitiy is a helpful utility.
If the relation to the subject is lost, the activity becomes pure
formalism without meaning and content. The formality then takes over
and controls ourselves. We no longer control the activity and we do
not learn to distinguish between right and wrong. We transition into
puppets who rely on outside judgement and control.
Formalism is a result of declination of the matter.
We have seen that in life and in software. It does not work well.
Niceness
Friendliness goes beyond the border of responsibility. You end up
doing things which others are supposed to do. This may exhaust you
over time and weaken others. If the responsibilites are not clear
the system becomes instable and hard to maintain.
Friendliness is a result of affection.
We have seen that in life and in software. It does not work well.
Chaos
Chaos is the absence of structure, the abuse of structures, the
absence of names, the abuse of names.
Chaos is a result of fear and doubt.
We have seen that in life and in software. It does not work well.
If we want to get better software we have to clean up on these
attributes. If we dont know what we need to do we at least know what
not to do:
- dont be authoritarian
- dont be formal
- dont be nice
- dont be chaotic
The qualities of a manager
Welt der Schatten, Kunst der Suedsee - Ethnologisches Museum, Staatliche Museen zu Berlin, photo HP
The qualities a manager should convey
- security - the base
- identity - the setup
- fortitude - the action
security
People working together on a subject in group should have a solid
base they can rely on.
identity
A clear determination on what is us versus to what are the
others.
fortitude
A goal oriented, pragmatic, direct attitude towards challenges.
end of document