"Design Management" in an hour!

Introduction

Design management is concerned with the integration of design into management and vice versa. Simply put, design management is the business side of design. Design management encompasses the ongoing processes, business decisions, and strategies that enable innovation and create effectively-designed products, services, communications, environments, and brands that enhance our quality of life and provide organizational success.

On a deeper level, design management seeks to link design, innovation, technology, management and customers to provide competitive advantage across the triple bottom line: economic, social/cultural, and environmental factors. It is the art and science of empowering design to enhance collaboration and synergy between “design” and “business” to improve design effectiveness.

The architectural design and detailed design stage of the SDLC can be called the solution stage.

The architecture design is complete when the architectural design document is signed off by the PM and QA representative. Customer’s signature is also necessary if mentioned in the contract.
The detailed design describes the project implementation in the detailed design document. This includes coding conventions, screen, class and data storage specifications.

Architecture Design

1. Assimilate Documentation: Collect white papers, prototypes, case study and workshop results from both the client and the vendor for analyzing alternative solutions for the design.
   
2. Evaluate Alternate Solutions for Architecture Design: This is the make, buy and reuse stage. Following are the factors that drive the decisions here.
   
   -Product Functioning
   -Available resources and skills
   -Cost of acquiring versus developing internally
   -Critical deliver and integration dates
   -Strategic business alliance, including high level business requirements
   -Market research of available products, including COTS products
   -Functionality and quality of available products
   -Skills and capability of potential suppliers
   -Impact on core competencies
   -Product availability
   -Licenses, warrantees, responsibilities, and limitations of the product being acquired
   -Proprietary issues
   -Risk reduction


3. Define the selection criteria before evaluating the alternate solution: This encompasses Cost (Time, People, and Money), Benefits (Performance, Capability, and Effectiveness) and Risks. Important things to consider are as follows.
   
   -Type of the product
   -Reuse of existing components
   -Future plans of extending/enhancing the product
   -User interface
   -Hardware and software requirements
   -Error detection, reporting and recovery mechanism
   -Memory management policies
   -External database, storage management and persistence
   -Distributed data or control over the network
   -Concurrency and synchronization
   -Communication mechanism
   -Management of other resources
   -Performance requirements


4. Identify criteria for selection of physical organization: Following are the inputs to this stage:
   
   -Storage space
   -Operational efficiency
   -Response time
   -Costs
   -Database security and integrity
   -Identification of constraints and limitations


5. Construct Object Model: For almost all the projects, except for smaller ones, usage of CASE tools is highly recommended for building the Object Model/Domain Model.


6. Evolve Other Specific Requirements: These are the operational concepts such as,
   
   -Conversion Modules
   -Archive and Purge Module
   -Backup and Recovery Design
   -Security Architecture
   -System Interfaces
   -Batch Jobs
   -Performance and Response Time Considerations
   -Platform Dependencies and Installation Considerations
   -Localization Considerations
   
   
7. Prepare Architectural Design and Operation Scenario: We need to define following items to complete this stage.
   
   -Domain model
   -Functions
   -Behavior
   -Data
   -Design Model
   
   
8. Prepare Architecture Design Document: There are 10 steps to draft the architecture design document.
   
   -Derive functional definitions of the components
   -Define data structures
   -Describe user interface
   -Define control flow
   -Define the response requirement
   -Detailed data flow diagrams
   -Data dictionary
   -Entity relationship diagram
   -Define interface requirements
   -Define reusable components
   
   
9. Review and approve Architecture Design Document: First step is to conduct formal and technical review of the document, close all action items, get signoffs from the PM and the customer, and baseline the document.
   
10. Prepare Integration Test Plan: This stage is broken down as follows.
    
    -Identification of integration sequence, ensuring availability of tools and setting up test environment
    -Plan for resource and access permissions
    -Perform product integration after setting up the environment
    -Prepare integration test data
    -Prepare integration test plan

Detailed Design

1. Assimilate Documentation: Collection functional specifications, detailed customer requirement specification, architecture design, and data model documentation.
   
2. Frame the Selection Criteria for Evaluation of Solution Alternatives:
   
   -Type of the product
   -Reuse of existing components
   -Future plans of extending/enhancing the product
   -User interface
   -Hardware and software requirements
   -Error detection, reporting and recovery mechanism
   -Memory management policies
   -External database, storage management and persistence
   -Distributed data or control over the network
   -Concurrency and synchronization
   -Communication mechanism
   -Management of other resources
   -Performance requirements


3. Decompose Lower Level Components:
   
   -Start from the interface and interface specification
   -Concentrate on the control flow
   -Defer data declaration until the coding stage
   -Keep step of refinement small for easy verification
   -Review each step as and when completed
   
   
4. Prepare Detailed Design: Steps involved in detailed design are as follows.
   
   -Presentation
   -Naming programs, files, variables and data
   -Limiting the size of modules
   -Using library routines
   -Defining constraints
   -Defining constants
   -Using compiler specific features
   -Error handling
   -Definition of standards for development


5. Review and Approve Detailed Design Document: We need to define following items to complete this stage.
   
   -Domain model
   -Functions
   -Behavior
   -Data
   -Design Model
   
   
6. Review and Approve Test Plan
   
7. Component Reuse

Design Models

1. Static Object Model: Such as Use Case and Class diagrams
2. Dynamic Object Model: Such as Activity and State diagrams
3. Storage Object Model: Such as Entity Relationship diagrams

Service Design

This include activities such as below.

1. Data Migration
2. Training
3. System Deployment and Management

Alternate Design Evaluation

During SDLC the following structured design methods can be adopted.

1. Architecture Tradeoff Analysis Method (ATAM):
   Inputs: System’s business/mission drivers, existing architectural documents
   Outputs: List of architectural approaches, scenarios, attributes, utility tree, risks, non-risks, risk themes


2. Cost-Benefit Analysis Method (CBAM):
   Inputs: System’s business/mission drivers, list of scenarios, existing architectural documents
   Outputs: List of architectural strategies with cost-benefits-schedule-ROI, risks related to each architectural strategy


3. Active Review for Intermediate Designs (ARID):
   Inputs: List of seed scenarios, existing architectural documents
   Outputs: List of issues and problems preventions


4. Attribute Driven Design (ADD)
   Inputs: Requirements, Constraints, Quality Attribute documents
   Output: Module decomposition, concurrency and deployment documents

Reviews

Reviews are conducted on the design process and documentation. Following are types of review conducted.

1. Formal Technical Review
   
   -Prepare the work product
   -Identify review team and their roles and responsibilities
   -Plan review
   -Review work product
   -Rework
   -Signoff work product


2. Internal Peer Review
   

Templates created at the organizational level

• General Design
• Object Oriented Design
• Feasibility Study
• Program Specification
• Proof of Concept
• Signoff
• Tool Evaluation
  

Types of Checklists created at the organizational level

• Design checklist
• Program specification checklist