Show
Part 2. Information TechnologyChapter 5. Systems Development2.5.12 Design Techniques and DeliverablesManual TransmittalDecember 16, 2021 Purpose(1) This transmits revised Internal Revenue Manual (IRM) 2.5.12, Systems Development, Design Techniques and Deliverables. This IRM was developed to describe techniques for analyzing, designing, and modeling system development software designs. Material Changes(1) Manual Transmittal signature, changed the title from Acting, Chief Information Officer signature to Chief Information Officer for Nancy A. Sieger. (2) 2.5.12.1.3 (7), Updated the role and responsibilities of the Customer Service Director (3) 2.5.12.1.7, Added resource “The Gang of Four (GoF) Design Patterns Reference. Learning Object-Oriented Design & Programming Version 2.0, January 10, 2017 (4) 2.5.12.2, Added System and Software Developer’s Best Practice Overview (5) 2.5.12.2 (1), Added IRS system development and software development teams have many responsibilities, for example:
(6) 2.5.12.2.1, Added Enterprise Architecture (EA) Application Design Overview (7) 2.5.12.2.1 (1), Added The goal of the application architecture section of the EA is to define a set of architectural patterns from which projects may select in order to build and deploy their applications in a manner that is consistent with the objectives of the IRS as an enterprise. Projects can choose from a limited set of application architecture patterns to build application systems. (8) 2.5.12.2.1 (2), Added Projects are expected to develop their own design level approaches, and documentation based on the architecture guidelines provided in the Enterprise Architecture, included updated EA hyperlink (9) 2.5.12.2.1 (9), Corrected the word "work flow" to "workflow" (10) Added explanation During 1994 four authors: Eric Gamma, Richard Helm, Ralph Johnson and John Vlissides who are jointly known as the "Gang of Four " (GOF) published a book titled Design Patterns - Elements of Reusable Object-Oriented Software which started the concept of Design Pattern in Software Development. Design patterns provide an industry standard approach to solving recurring problems standard terminology and significance to each scenario (11) 2.5.12.3.8 (1) (a - z) Added Software Design Patterns - Best Practices for Developers (12) The best practices for developers using Design Patterns are as follows:
(13) 2.5.12.3.9.1 (2), Corrected hyperlink for REPO Model Driven Requirements (14) 2.5.12.4 (1), Included punctuation (15) 2.5.12.4.1 (3 a b c), Corrected unbolded content (16) Added Figure 2.5.12-1, Software Design Principles (17) Added Figure 2.5.12-2, Top-down Design Approach (18) Added Figure 2.5.12-3, Bottom-up Approach (19) Added Figure 2.5.12-4, Illustrates Heuristic Evaluation (20) Added Figure 2.5.12-5, Illustrates Module Coupling (21) Added Figure 2.5.12-6, Iterator Pattern Implementation (22) Added Figure 2.5.12-7, Observer Pattern Implementation (23) Added Figure 2.5.12-8, Builder Pattern Implementation (24) Added Figure 2.5.12-9, Composites Pattern (25) Added Figure 2.5.12-10, Object-Oriented Analysis and Object-Oriented Design Requirements (26) Added Figure 2.5.12-11, Illustration of Object-Oriented Design (OOD) Example (27) Added Figure 2.5.12-12, Illustrates Hierarchical Structure Chart (28) Added Figure 2.5.12-13, Structure Chart 2 (29) Added Figure 2.5.12-14, Data Flow Diagram that resulted from Transform Analysis (30) Added Figure 2.5.12-15, Illustrates First-Level Module Factoring (31) Added Figure 2.5.12-16, Illustrates Structure Chart for Transform-centered System (32) Added Figure 2.5.12-17, Illustrates Transaction-Centered System Data Flow Diagram (33) Added Figure 2.5.12-18, Illustration of Transaction Processor (34) Added Figure 2.5.12-19, Illustration of Module Naming Conventions (35) Added Figure 2.5.12-20, Illustration of Module Numbering (36) Added Figure 2.5.12-21, Illustration of Multi-Page Structure Charts (37) Added Figure 2.5.12-22, Illustration of Multi-Page Structure Chart 1 (38) Added Figure 2.5.12-23, Illustration of Multi-Page Structure Chart 2 (39) Added Figure 2.5.12-24, Illustration of Module Connections (40) Added Figure 2.5.12-25, Illustration of Module Calls (41) Added Figure 2.5.12-26, Illustration of Module Iteration (42) Added Figure 2.5.12-27, Illustration of Lexical Inclusion (43) Added Figure 2.5.12-28, Illustration of Pre-Existing Module Notation used elsewhere in the system (44) Added Figure 2.5.12-29, Symbol for File Display (45) Added Figure 2.5.12-30, Illustration of RANGE-TABLE is common to modules 1 and 3 (46) Added Figure 2.5.12-31, Illustration of Data and Control Parameters (47) Added Figure 2.5.12-32, Illustration of Structure Chart with Labeled Parameters (48) Added Figure 2.5.12-33, Grouping Criteria for Packaging Effect on Other DocumentsIRM 2.5.12 dated 06-11- 2020 is superseded, and supplements IRM 2.5.1 System Development and IRM 2.5.3 System Development, Programming and Source Code Standards. AudienceThe audience intended for this transmittal is personnel responsible for engineering, developing, or maintaining Agency software systems identified in the Enterprise Architecture. This engineering, development, and maintenance include duties performed by government employees, contractors, and organizations having contractual arrangements with the Internal Revenue Service (IRS). Effective Date(12-16-2021)
2.5.12.1 (12-16-2021) Program Scope and Objectives
2.5.12.1.1 (12-16-2021) Background
2.5.12.1.2 (12-16-2021) Authority
2.5.12.1.3 (12-16-2021) Roles and Responsibilities
2.5.12.1.4 (12-16-2021) Program Management and Review
2.5.12.1.5 (12-16-2021) Acronyms/Terms
2.5.12.1.6 (12-16-2021) Terms/Definitions
2.5.12.1.7 (12-16-2021) Related Resources
2.5.12.2 (12-16-2021) System and Software Developer’s Best Practice Overview
2.5.12.2.1 (12-16-2021) Enterprise Architecture (EA) Application Design Overview
2.5.12.3 (12-16-2021) Software Design
2.5.12.3.1 (12-16-2021) Design Characteristics
2.5.12.3.2 (12-16-2021) Software Design and Structure
2.5.12.3.2.1 (12-16-2021) Software Design Levels
2.5.12.3.3 (12-16-2021) Software Modeling
2.5.12.3.4 (12-16-2021) Software Design Refinement Principles
2.5.12.3.5 (12-16-2021) Heuristic Evaluation
2.5.12.3.6 (12-16-2021) Modular Decomposition
2.5.12.3.7 (12-16-2021) Software Design Patterns Overview
2.5.12.3.8 (12-16-2021) Software Design Patterns - Best Practices for Developers
2.5.12.3.9 (12-16-2021) Object-Oriented Analysis and Design Process
2.5.12.3.9.1 (12-16-2021) Use Case Diagrams
2.5.12.4 (12-16-2021) User Interface (UI) Design Principles
2.5.12.4.1 (12-16-2021) User Interface Design Process
2.5.12.4.2 (12-16-2021) Design Wireframes and Mock-ups
2.5.12.4.2.1 (12-16-2021) Prototype Design Best Practices
2.5.12.4.2.2 (12-16-2021) Prototyping Benefits Throughout the Enterprise Life Cycle (ELC)
2.5.12.5 (12-16-2021) Structure Chart Overview
2.5.12.5.1 (12-16-2021) Structure Chart Best Practices
2.5.12.5.2 (12-16-2021) Transform Analysis/Transaction Analysis Overview
2.5.12.5.2.1 (12-16-2021) Transform Analysis Best Practices
2.5.12.5.2.2 (12-16-2021) Transaction Analysis Best Practices
2.5.12.5.2.3 (12-16-2021) Information Specification
2.5.12.5.2.4 (12-16-2021) Structure Chart Refinement
2.5.12.5.2.4.1 (12-16-2021) Cohesion
2.5.12.5.2.4.2 (12-01-2002) Coupling
2.5.12.6 (12-16-2021) Structure Chart Conventions and Standards
2.5.12.6.1 (12-16-2021) Module Numbering
2.5.12.6.1.1 (12-16-2021) Multiple Page Structure Charts
2.5.12.6.1.2 (12-16-2021) Pre-existing (Common) Modules
2.5.12.6.2 (12-01-2002) Module Notations
2.5.12.6.2.1 (12-01-2002) Special Module Call Notation
2.5.12.6.2.1.1 (12-16-2021) Decision
2.5.12.6.2.1.2 (12-16-2021) Iteration
2.5.12.6.2.2 (12-16-2021) Lexical Inclusion
2.5.12.6.2.3 (12-16-2021) Pre-Existing Module Notation
2.5.12.6.2.4 (12-16-2021) File Notation
2.5.12.6.3 (12-16-2021) Structure Chart Common Environment
2.5.12.6.4 (12-16-2021) Structure Chart Interface Parameters (Couples)
2.5.12.6.4.1 (12-16-2021) Interface Parameter Names
2.5.12.6.4.2 (12-16-2021) Identifying Data and Control Parameters
2.5.12.6.5 (12-16-2021) Sorts
2.5.12.6.6 (12-16-2021)
Analysis/Design Cross-Reference List
2.5.12.7 (12-16-2021) Structure Chart Module Specification
2.5.12.7.1 (12-16-2021) Pseudocode
2.5.12.7.1.1 (12-16-2021) Pseudocode Best Practices
2.5.12.7.2 (12-01-2002) Module Specification Development/Standards
2.5.12.7.3 (12-16-2021) Pseudocode-Conventions/Standards
2.5.12.7.3.1 (12-01-2002) Reusable (Common) Modules
2.5.12.7.3.2 (12-16-2021) Organization and Maintenance
2.5.12.8 (12-16-2021) Structure Charts Packaging and Preprogramming Considerations
2.5.12.9 (12-16-2021) Structured Design/Programming Interface - Structure Charts
2.5.12.10 (12-16-2021) Software Release/Maintenance/Evolution
Exhibit 2.5.12-2 Example of Page 1 of a Structure Chart using a Parameter TableStructure Chart Parameter Table Please click here for the text description of the image.
Exhibit 2.5.12-4 Acronym/Terms
Exhibit 2.5.12-5 Terms/DefinitionsTerms/Definitions
Page Last Reviewed or Updated: 16-Dec-2021 Which component of a structure chart is represented by an arrow with a filled circle?Control Flow
It represents the flow of control between the modules. It is represented by directed arrow with filled circle at the end.
Which of the following describes the degree of interdependence among modules?Coupling: Coupling is the measure of the degree of interdependence between the modules.
Is a type of documentations which describes inputs/outputs and processing logic for all the program modules?Program Documentation
It describes inputs, outputs, and processing logic for all the program modules.
Is the process of reviewing program code?The code review process also referred to as peer review, stands out as a tried and tested method in a large palette of applications to allow for the systematic examination of software source code. It's conducted to find bugs and improve the overall quality of the software.
|