Presentation is loading. Please wait.

Presentation is loading. Please wait.

CSDP Preparation Course Module IV: Software Construction.

Similar presentations

Presentation on theme: "CSDP Preparation Course Module IV: Software Construction."— Presentation transcript:

1 CSDP Preparation Course Module IV: Software Construction

2 Module IV - Software Construction2 Specifications The exam specific topics covered in this module are listed below, and are the basis for the outline of its content A.Construction Planning B.Code Design C.Data Design and Management D.Error Processing E.Source Code Organization F.Code Documentation G.Construction Quality Assurance H.System Integration and Deployment I.Code Tuning J.Construction Tools

3 Module IV - Software Construction3 Objectives After completing this module, you should be able to… Define the “software construction” Discuss how to plan for software construction Examine the factors that effect the size, cost, and schedule for software construction Discuss software construction quality factors and quality assurance List and describe software construction tools Describe how to design and document code Describe what is meant by code tuning and how to do it Describe error processing Define the various types of system integration

4 Module IV - Software Construction4 Organization The organization of information for each specification topic is as follows: Topic Content Slides - detail the important issues concerning each topic and support the module objectives Topic Reference Slides - detail the sources for the topical content and provides additional references for review Topic Quiz Slides - allow students to prepare for the exam

5 Module IV - Software Construction5 Introduction Definition of Software Construction: Detailed creation of working, meaningful software through a combination of coding, verification, unit testing, integration testing, and debugging Software construction closely tied to Software design Software testing Design Construction Testing

6 Module IV - Software Construction6 Introduction - 2 More on Construction Significant detailed design occurs during construction Low-level (e.g. unit and module integration) testing occurs during construction Construction produces high volume of configuration items Thus construction linked to configuration management Construction is tool intensive Quality (or lack thereof) is very evident in the construction products Construction highly related to Computer Science due to Use of algorithms Detailed coding practices

7 Module IV - Software Construction7 Introduction - 3 Software Construction Fundamentals The fundamentals of software construction include: Minimizing complexity Anticipating change Constructing for verification Standards in construction The following slides discuss each of these fundamentals

8 Module IV - Software Construction8 Introduction - 4 Minimizing Complexity Humans are severely limited in our ability to hold complex information in our working memories As a result, minimizing complexity is one the of strongest drivers in software construction Need to reduce complexity throughout the lifecycle As functionality increases, so does complexity Accomplished through use of standards Examples: J2EE for complex, distributed Java applications UML for modeling all aspects of complex systems High-order programming languages such as C++ and Java Source code formatting rules to aid readability

9 Module IV - Software Construction9 Introduction - 5 Anticipating Change Software changes over time Anticipation of change affect how software is constructed This can effect Use of control structures Handling of errors Source code organization Code documentation Coding standards

10 Module IV - Software Construction10 Introduction - 6 Constructing for Verification Construct software that allows bugs to be easily found and fixed Examples: Enforce coding standards Helps support code reviews Unit testing Organizing code to support automated testing Restricted use of complex or hard-to-understand language structures

11 Module IV - Software Construction11 Introduction - 7 Standards in Construction Standards which directly affect construction issues include: Programming languages E.g. standards for languages like Java and C++ Communication methods E.g. standards for document formats and contents Platforms E.g. programmer interface standards for operating system calls, J2EE Tools E.g. diagrammatic standards for notations like the Unified Modeling Language

12 Module IV - Software Construction12 References [IE04] IEEE Computer Society, Guide to the Software Engineering Body of Knowledge (SWEBOK), IEEE Computer Society Press, Los Alamitos, CA 20001, June 2004

13 Module IV - Software Construction13 A. Construction Planning What is Construction Planning? Laying out the work plan (i.e. schedule) to design, implement, debug, and unit test the software Construction planning major concerns: Coders are typically not planners Schedules will be difficult to maintain unless a good architecture design is in place Many organizations to not collect project data on which to plan future projects Many managers consider planning to be a waste of time and therefore don’t encourage it Project plans may be limited to the construction plans Many organizations and projects do not use systematic cost estimating methods such as models

14 Module IV - Software Construction14 A. Construction Planning - 2 Improving Software Economics Consider reducing development costs by planning to: Reduce the size and/or complexity Improve the development process Use more highly skilled people and build better teams Use better tools Reduce quality thresholds Some actions include Use an object-oriented approach Use COTS components Use an iterative approach Provide training to development team Automate tedious tasks with tools

15 Module IV - Software Construction15 A. Construction Planning - 3 Construction Prerequisites As with building construction, much of the success or failure of the project already determined before construction begins Upstream activities such as project planning, requirements, architecture, and design are crucial to success Typical high-risk areas Project planning Requirements Architecture Preparation is a way to reduce these risks

16 Module IV - Software Construction16 A. Construction Planning - 4 Problem Definition Prerequisite The problem being solved via the application must be well defined Common names for the document containing the problem statement: Product Vision Vision Statement Product Definition Defines the problem without reference to potential solutions Helps avoid solving the wrong problem!

17 Module IV - Software Construction17 A. Construction Planning - 5 Requirements Prerequisite Requirements describe in detail what a system is supposed to do, therefore are invaluable for construction Explicit requirements: Help ensure the user drives system functionality Rather than the programmer Reduce the number of construction debates Help minimize changes after development begins Specifying requirements adequately is a key to project success

18 Module IV - Software Construction18 A. Construction Planning - 6 Architecture Prerequisite Quality of the architecture determines the conceptual integrity of the system A proper architecture: Gives structure to maintain conceptual integrity Provides guidance to programmers Partitions work Architecture-level problems are much more costly to fix than are coding errors Good architecture can make construction easy Bad architecture makes construction difficult

19 Module IV - Software Construction19 A. Construction Planning - 7 Regarding Upstream Prerequisites Time budgeted for requirements and architecture work 10 to 20 percent of manpower 20 to 30 percent of schedule If requirements are unstable Do not ignore, spend time to fix The analyst should fix if a formal project Can be fixed by the programmer for informal projects Use same heuristics for problems with the architecture

20 Module IV - Software Construction20 A. Construction Planning - 8 Choose an Approach Many software development approaches have been tried over the years Some examples (not mutually exclusive): Functional Object-Oriented Iterative Waterfall Agile Data-centric The construction team must follow some approach Chosen approach must be appropriate for the task at hand

21 Module IV - Software Construction21 A. Construction Planning - 9 Choose a Programming Language Programming language choices affect Productivity Code quality Programmers more productive using a familiar language High-level languages provided higher quality and better productivity Some languages better at expressing programming concepts than others The ways in which a programmers express themselves are affected by the chosen language

22 Module IV - Software Construction22 A. Construction Planning - 10 Choose Construction Practices Questions to answer regarding practices: How detailed will the design be? What are the coding conventions for names, comments, layout, etc.? How will the architecture be enforced? Is the project’s use of technology ahead of or behind the power curve, and is this appropriate given the circumstances? What is the integration procedure, how often is it done, and who participates? Will developers program individually, in pairs, or some combination of this? Where and when will builds occur?

23 Module IV - Software Construction23 A. Construction Planning - 11 Choose Tools Modern programming tools Are essential to maintain programmer productivity Reduce tedious and redundant tasks Must be appropriate for the task at hand Tools preparation checklist: Are all product licenses current? Are all products at current, supported revision level? Have all programmers received proper training on the tools? Does the project have a configuration management tool? Does the project have a tool to track change requests? Do project team members have sufficient workstations? Does the project have sufficient test environments? Does the project have sufficient build environments?

24 Module IV - Software Construction24 A. Construction Planning - 12 Construct the Team For small development efforts Self managed Everyone is a peer For mid-size development efforts Single team For large development efforts Multiple teams Role# / Team* Lead1 Detailed designer1 to 4 Coder5 to 10 Integrator1 to 2 Unit testerSame as coder System tester1 “Buildmeister”1 Configuration manager1 * Individuals will play multiple roles Table 1: Team Composition

25 Module IV - Software Construction25 A. References [IE04] IEEE Computer Society, Guide to the Software Engineering Body of Knowledge (SWEBOK), IEEE Computer Society Press, Los Alamitos, CA 20001, June 2004 [RS04] IBM Rational Software, The Rational Unified Process v2003.06.13, 2004 [RT03] [SM04] S. McConnell, Code Complete: A Practical Handbook of Software Construction, Second Edition, Microsoft Press, 2004. [WR01] Walker Royce, Software Project Management, A Unified Framework, Addison-Wesley, Boston, MA, 2001

26 Module IV - Software Construction26 A.Quiz – 1 According to this lesson, construction planning involves creating a schedule for all except which of the following: a) Design b) Implement c) Integrate d) Unit test 1) a 2) b 3) c 4) d

27 Module IV - Software Construction27 A.Quiz – 2 Which are valid ways to reduce development costs: a) Reduce the number of requirements b) Reduce quality c) Use more highly skilled people 1) a 2) b 3) c 4) None are valid 5) All are valid

28 Module IV - Software Construction28 A.Quiz – 3 The name given to the document that contains the problem statement is a) Product Vision b) Vision Statement c) Product Definition 1) a 2) b 3) c 4) All of the above

29 Module IV - Software Construction29 A.Quiz – 4 After the completion of construction, problems discovered with the architecture are typically a) More costly to fix than coding errors b) Less costly to fix than coding errors c) Due to incorrect requirements d) Due to missing requirements 1) a 2) b 3) c 4) d

30 Module IV - Software Construction30 A.Quiz – 5 Up to 30 percent of the schedule should be allocated to requirements and architecture activities. 1) True 2) False

31 Module IV - Software Construction31 B. Code Design Software Design The process of defining the software architecture, components, modules, interfaces, test approach, and data for a software system to satisfy specified requirements. IEEE Standard 729-1983

32 Module IV - Software Construction32 B. Code Design - 2 Importance of Managing Complexity Most technical issues are due to high complexity Users are demanding more functionality Frequent source of complexity Software Crisis: Ability to produce suitable applications is not keeping pace with demand Causing systems to be unreliable, slow, insecure, buggy “Separation of concerns” is one method to overcome complexity

33 Module IV - Software Construction33 B. Code Design - 3 How to Overcome Complexity Ineffective designs come from three sources: A complex solution to a simple problem A Simple, incorrect solution to a complex problem An inappropriate, complex solution to a complex problem 2 ways to manage complexity: Minimize the amount of essential complexity Keep accidental complexity from proliferating

34 Module IV - Software Construction34 B. Code Design - 4 Desirable Design Characteristics Steve McConnell suggests achievement of the following: 1.Minimal complexity 2.Ease of maintenance 3.Loose coupling 4.Extensibility 5.High fan-in 6.Low-to-medium fan-out 7.Portability 8.Leanness 9.Stratification 10.Standard techniques

35 Module IV - Software Construction35 B. Code Design - 5 Desirable Design Characteristics (cont.) Minimal complexity KISS: Keep it simple, stupid! Ease of maintenance Use common programming constructs and consistent naming conventions Loose coupling Reduce interdependencies within the code Extensibility Minimal ripple effect when changes are made Reusability Modules, components, & subsystems can be and are reused

36 Module IV - Software Construction36 B. Code Design - 6 Desirable Design Characteristics (cont.) High fan-in Highly utilized classes Low to medium fan-out Call tree not to large Portability Able to be redeployed in a different environment Leanness No extra parts Stratification Consistent levels of abstraction across subsystems Standard techniques Stay with the “tried and true”

37 Module IV - Software Construction37 B. Code Design - 7 Levels of Design 5 levels of abstraction in software design: Level 1 – Software System Level 2 – Subsystems Level 3 – Classes Level 4 – Routines Level 5 – Internal Routine Design

38 Module IV - Software Construction38 B. Code Design - 8 Level 1 – Software System The entire system Concern of the architect, not detailed designer Unless system is extremely small

39 Module IV - Software Construction39 B. Code Design - 9 Level 2 – Subsystems Identify all major subsystems I.e. identity the architectural layers and the contents in each layer Major design activities at this level are 1.Partition the program into major subsystems 2.Define subsystem interfaces

40 Module IV - Software Construction40 B. Code Design - 10 Level 3 – Classes Identify all classes by subsystem Define class relationships Generalizations Dependencies Associations For each class, define its interface

41 Module IV - Software Construction41 B. Code Design - 11 Level 4 – Routines Define the routines for each class Previously defined interfaces will help Need to also identify internal routines Level 4 activities may necessitate a return to Level 3 to further define the interface This is normal and encouraged in an iterative development approach

42 Module IV - Software Construction42 B. Code Design - 12 Level 5 – Internal Routine Design Lay out the detailed functionality of each routine Closest activity to programming This includes: Deciding program flow, perhaps by writing pseudocode Choosing algorithms Determining program calls Determining return points Inserting programming constructs such as loops and case statements

43 Module IV - Software Construction43 B. Code Design - 13 Design Techniques Find Real-World Objects Form Consistent Abstractions Encapsulate Implementation Details Apply Inheritance Hide Internal Information Identify Areas Likely to Change Ensure Loose Coupling Apply Design Patterns

44 Module IV - Software Construction44 B. Code Design - 14 More Techniques Aim for Strong Cohesion Build Hierarchies Formalize Class Contracts Assign Responsibilities Design for Test Avoid Failure Choose Binding Time Consciously Make Central Points of Control Consider Using Brute Force Draw a Diagram Keep Your Design Modular

45 Module IV - Software Construction45 B. Code Design - 15 Design Approaches Iterate Don’t stagnate in any one activity Instead, cycle through activities and return to the beginning Build on previous work Divide and Conquer Divide problem into more manageable chunks Prototype Create a “quick and dirty” version of the application Provides insight into the problem Collaborative Design Two (or more) heads is better than one Can be formal or informal

46 Module IV - Software Construction46 B. References [IE04] IEEE Computer Society, Guide to the Software Engineering Body of Knowledge (SWEBOK), IEEE Computer Society Press, Los Alamitos, CA 20001, June 2004 [SM04] S. McConnell, Code Complete: A Practical Handbook of Software Construction, Second Edition, Microsoft Press, 2004.

47 Module IV - Software Construction47 B. Quiz – 1 The issues related to the software crisis include: a) Ineffective development practices b) Inherent complexities of application development c) Poor application quality 1) a & b 2) a & c 3) a 4) All of the above

48 Module IV - Software Construction48 B. Quiz – 2 Levels of design deal with the: a) Levels of abstraction within an application b) Levels of abstraction within a subsystem c) Levels of abstraction within a class d) Levels of abstraction within a routine 1) a 2) b 3) c 4) d

49 Module IV - Software Construction49 B. Quiz – 3 Subsystems are synonymous with architecture layers. a) True b) False

50 Module IV - Software Construction50 B. Quiz – 4 Level 5 - Internal Routine Design includes: a) Deciding program flow b) Coding algorithms c) Writing pseudocode 1) a 2) b 3) c 4) a & c

51 Module IV - Software Construction51 C. Data Design And Management What is Data Design? A method used to define and analyze data requirements needed to support the business functions of an enterprise. These data requirements are recorded as a conceptual data model with associated data definitions. Data Design defines the relationships between data elements and structures. What is Data Management? The act of ensuring database integrity, security, performance, and recovery of data.

52 Module IV - Software Construction52 C. Data Design And Management - 2 Stages of Data Modeling The data model evolves through three stages 1.Conceptual High level key entities and their relationships 2.Logical Refinement of the conceptual model into more detailed logical entities 3.Physical Detailed and optimized phyiscal database table designs

53 Module IV - Software Construction53 C. Data Design And Management - 3 Conceptual Data Modeling Initial stage of database design High-level definition of persistent data and its storage Business model provides business and system entities Starting point in the evolution of the data model Can be represented by an Entity-Relationship (ER) model Graphically via ER diagrams

54 Module IV - Software Construction54 C. Data Design And Management - 4 Logical Data Modeling Provides idealized view of key logical data entities and relationships Independent of any software or database implementation Useful for modeling data structures to be shared across applications Obtain buy-in from relevant stakeholders in order to “get it right” Reduces risk Not always necessary, especially for small data needs Can skip the conceptual and logical model and start with physical

55 Module IV - Software Construction55 C. Data Design And Management - 5 Physical Data Design Define the detailed physical design of the database Tables Views Stored procedures Steps to create the physical data model: 1.Define domains 2.Create initial physical database design elements 3.Define reference tables 4.Create primary key and unique constraints 5.Define data and referential integrity enforcement rules 6.De-normalize database design 7.Optimize data access 8.Define storage characteristics 9.Design stored procedures

56 Module IV - Software Construction56 C. Data Design And Management - 6 Define Domains A domain is used to enforce data type standards Definitions of user-defined data types Enhances interoperation across applications Example: day_of_week column defined as: MON, TUE, WED, THU, FRI, SAT, SUN A domain would limit possible values in this column to these values

57 Module IV - Software Construction57 C. Data Design And Management - 7 Create Initial Elements Initial elements are tables and relationships Columns are defined for each table Logical entities from logical data model can be used as starting point for creating tables Or, persistent classes from the design model CustIDNamePhoneEmailZip 2332Mary Martin(931) 488-2384mmartin01@sbcnet.com23993 4048Joe Denver(231) 821-8322jd23@aol.com64412 6301Peg Thrush(721) 239-2001thrushpa@hotmail.com49921 4893Amy Meyer(818) 291-8113meyer34@spint.com83845 2943Curt Sanchez(319) 455-8638csanch5@gteconnect.com73814

58 Module IV - Software Construction58 C. Data Design And Management - 8 Define Reference Tables Reference table: Frequently-accessed tables whose data changes infrequently Used to optimize access to data in the database Examples: Standard product codes 2 character U.S. state codes Conversion rates Postal codes Reference tables can reduce disk I/O and and increase database performance

59 Module IV - Software Construction59 C. Data Design And Management - 9 Create Primary Key & Unique Constraints Purpose of primary keys: Define the one or more columns that uniquely identify a row in the table Purpose of unique constraint: Define constraints on columns that guarantee the uniqueness of the data or collection of data One primary key per table Choose a non-meaningful, non-user-entered column, if possible A unique constraint designates that the data in the column is unique per row. A Customer_ID column frequently has a unique constraint to ensure unique IDs

60 Module IV - Software Construction60 C. Data Design And Management - 10 Define Rules Purpose: To ensure the integrity of the database Data integrity rules also know as constraints Ensure data values are within allowed ranges Foreign key is one or more columns in a table that map to the primary key in another table One table could have many foreign keys Each foreign key maps to a different table Each foreign key maps to a primary key in a different table

61 Module IV - Software Construction61 C. Data Design And Management - 11 De-normalize Database De-normalizing optimized the data structures to increase performance Reduces number of table joins the DBMS has to do by combining certain tables Reduces access time but can increase update time

62 Module IV - Software Construction62 C. Data Design And Management - 12 Optimize Data Access Use indexing and database views for better data access Indexing Requires knowledge of how data will be accessed Can have large impact on performance Views A virtual table Contains data from multiple tables Decreases time to select data Especially for heavily queried tables Can increase security by restricting access to data

63 Module IV - Software Construction63 C. Data Design And Management - 13 Define Storage Characteristics Design space allocation Design disk page organization Tablespaces Take advantage of block disk I/O Allow specification of physical data layout

64 Module IV - Software Construction64 C. Data Design And Management - 14 Design Stored Procedures Stored procedure: Executable code that runs on the database server Performs database-related actions on the server Without having to transfer data across a network Triggers are a special case of stored procedures Triggers invoked implicitly based on some event

65 Module IV - Software Construction65 C. Data Design And Management - 15 Review Results The final step in a data design iteration Assesses the completeness and quality of work to date Ensure that the data model and physical implementation are in sync Discrepancies and other issues are noted and fixed If the fixes are deferred, the issue should be tracked as a change request

66 Module IV - Software Construction66 C. References [RS04] IBM Rational Software, The Rational Unified Process v2003.06.13, 2004 [UT04] University of Texas at Austin, “Introduction to Data Modeling”, - datamodeling, 2004

67 Module IV - Software Construction67 C. Quiz – 1 Which of the following is not part of data management? a) Data integrity b) Security c) User access d) Performance e) Data recovery 1) a 2) b 3) c 4) All are aspects of data management

68 Module IV - Software Construction68 C. Quiz – 2 The 3 stages of data modeling include: a) Conceptual b) Preliminary c) Detailed d) Logical e) Physical 1) b, c, & e 2) b, c, & d 3) a, d, & e 4) a, b, & c

69 Module IV - Software Construction69 C. Quiz – 3 Entity Relationship Diagrams are useful for which data modeling stage? a) Preliminary b) Detailed c) Logical 1) a & b 2) b only 3) c only 4) All stages

70 Module IV - Software Construction70 C. Quiz – 4 A database domain is used for what purpose? a) Enforce data standards b) Group frequently used tables c) Logically group tables d) Define client access 1) a 2) b 3) c 4) d

71 Module IV - Software Construction71 C. Quiz – 5 The benefit of a de-normalized database is: a) Reduce update time b) Reduce access time c) Reduce number of tables 1) a 2) b 3) a & c 4) b & c

72 Module IV - Software Construction72 D. Error Processing Software error: A human action that results in software containing a fault [ANSI/IEEE Standard 729-1983] Software fault: 1. An accidental condition that causes a functional unit to fail to perform its required function 2. A manifestation of an error in software [ANSI/IEEE Standard 729-1983] Software failure: 1. The inability of a system or system component to perform a required function within specified limits. A failure may be produced when a fault is encountered. 2. A departure of program operation from program requirements.

73 Module IV - Software Construction73 D. Error Processing - 2 Debugging Debugging: The Process of correcting syntactic and logical errors detected during coding. -- With the primary goal of obtaining and executing a piece of code, debugging shares the testing of certain techniques and strategies but differs in its usual ad hoc application and local scope. [FIPS Publication 101, 1983] The Process of locating, analyzing, and correcting suspected faults. Sometimes synonymous with unit testing. A bug is an euphemism for fault (error) Debugging is associated with coding in that it is normally done by the coder who built the code Therefore, debugging is the search for faults, i.e. testing Testing is the process of executing a computer program for the purpose of finding faults

74 Module IV - Software Construction74 D. Error Processing - 3 Learning how to debug a computer program General methods -- Learn in-depth how the program you are working on operates -- Learn the kinds of mistakes you typically make -- Learn how to solve software problems Solving software problems -- Stabilize the error : Otherwise it is almost impossible to fix -- Locate the source of the error : Through creative testing -- Fix the error : Determine the impact on other areas of the program -- Test the fix : Use regression testing -- Look for similar errors : They probably exist

75 Module IV - Software Construction75 D. References McConnell, Steve, Code Complete: A Practical Handbook of Software Construction, Microsoft Press, Redmond, WA, 1983, Chapter 26, pp. 623-649. ANSI/IEEE Standard 729-1983 FIPS Publication 101, 1983

76 Module IV - Software Construction76 D. Quiz 1) The simplest type of construction language is a) Programming language b) Toolkit language c) Configuration language d) Formal language 2) The language in which software engineers choose from a limited set of predefined options to create new or custom software installations is a) Formal language b) Configuration language c) Toolkit language d) Programming language

77 Module IV - Software Construction77 E. Source Code Organization Code that needs order Order counts if the statement must be executed in a particular order -- For example, if there is a need to read a record before it can be written Make order obvious through: -- Naming the routines so order is obvious -- Use routine parameters to reflect the execution order Document the dependency between parts of the code The strongest principle for organizing straight-line code is order dependencies Dependencies should be made obvious through the use of good routine names, parameter lists and comments.

78 Module IV - Software Construction78 E. Source Code Organization - 2 Other reasons for organizing code Keep related statements together -- That operate on the same data -- That perform similar tasks -- That depend on each other being performed in order Assign variables close to where they will be used Keep variables live for as short a time as possible -- Measure the live time of a variable -- A short live time makes your code more readable Make sure readability is consistent from top to bottom

79 Module IV - Software Construction79 E. References McConnell, Steve, Code Complete: A Practical Handbook of Software Construction, Microsoft Press, Redmond, WA, 1983. Chapter 13, Pages 302-309

80 Module IV - Software Construction80 E. Quiz 1) How many forms of testing does construction involves? a) 4 b) 3 c) 2 d) 1 2) The purpose of _________ testing is to reduce the gap between the time at which faults are inserted into the code and the time those faults are detected? a) Unit testing b) Construction testing c) Integration testing d) Design testing

81 Module IV - Software Construction81 F. Code Documentation Types of Documentation Good documentation is a sign of professional pride by the programmer (coder) Documentation might be inside or outside the source code Outside (external) documentation is classically a: -- Users’ manual -- Operator’s manual (most recently combined with User’s manuals) -- Maintenance manual Outside documentation tends to be of the high-level (more abstract) type Inside documentation tend to be of the low-level (more concrete) type

82 Module IV - Software Construction82 F. Code Documentation - 2 Inside documents are of two types: -- Online help manuals -- Commented code Outside documents are a number of different types, two of which are: -- Software design documents (SDD) – A design specification which can be based on IEEE Standard 1016- 1998 -- Unit development folder -- Based on work by Frank Ingrassia originally written in 1977

83 Module IV - Software Construction83 F. Code Documentation - 3 Detailed Design Documentation Detailed design can be a high-level design document (architectural design) or a low-level design document (detailed design document): Detailed design documents contain: --Identification –The name of the design entity. -- Type – A description of the kind of design entity -- Purpose – A description of why the design entity exists -- Function – A Statement of what the design entity does -- Subordinates – The identification of all entities composing this design entity

84 Module IV - Software Construction84 F. Code Documentation - 4 Detailed design documents contain (continued) -- Dependencies – A description of the relationships of this design entity with other entities -- Interface – A description of how other entities interact with this design entity. -- Resources – A description of the elements used by the design entity that are external to the design -- Processing – A description of the rules used by the design entity to achieve its function. -- Data – A description of data elements internal to the design entity Although not required by the standard, the software designer name or identification should be entered with each entity.

85 Module IV - Software Construction85 F. Code Documentation - 5 Unit [software] Development Folders (UDF) Definition UDF: -- A collection of material pertinent to the development of a given software module or subsystem. -- Contents typically include the requirements, design, technical reports, code listings, test plans, test results, problem reports, schedules, and notes for the module or subsystem Definition of a unit: -- In recent definition, a unit is a work package specification -- A work package specification is the amount of work that can be done by 3-4 people in 2-3 weeks A UDF provides low-level management control over low-level software units, tasks, work packages, or modules

86 Module IV - Software Construction86 F. Code Documentation - 6 Unit Development Folders (UDF) (continued) Provides an orderly and consistent approach in the development of each unit of the project Provides a uniform and visible collection point for all unit documentation and code Aids in the establishment and attainment of unit-level milestones Provides first-level management visibility and hands-on control over the development process.

87 Module IV - Software Construction87 F. Code Documentation - 7 Commenting Code Useful comments: -- Summary of the code module -- Description of the code’s intent -- Use commenting styles that don’t breakdown or discourage modification; any style that is too fancy is annoying to maintain -- Outline the code (using PDL) in comments -- Avoid cryptic comments -- Place comments about undocumented features or error “work around” -- Place comments with: dimensions with numerical data, allowable numeric variables, the use of numbers to pass a meaning, global data, etc.

88 Module IV - Software Construction88 F. References McConnell, Steve, Code Complete, Microsoft Press, Redmond, WA, 1993, pp. 453-454, 463-478 F.S. Ingrassia, “The unit Development Folder (UDF): A Ten year Perspective,” In Richard H. Thayer (ed.), Software Engineering Project Management, IEEE Computer Society Press, Los Alamitos, CA 1997. (Also see: McConnell, p.454) IEEE Std 1016-1998, IEEE Recommended Practice for Software Design Descriptions, IEEE, Inc., Piscataway NJ, 1998

89 Module IV - Software Construction89 F. Quiz 1) The only two kinds of comments that are acceptable for completed code are: a) Repetitious and Explanatory comments b) Marker and Summary comments c) Intent and Summary comments d) Intent and Marker comments

90 Module IV - Software Construction90 G. Construction QA Definitions: Software Quality Software quality assurance: A planned and systematic pattern of all actions necessary to provide adequate confidence that the software and the delivered documentation conforms to established technical requirements [ANSI/IEEE Standard 729-1983] Construction quality assurance (QA) : Those QA techniques necessary assure that coding is being done according to coding standards Quality attributes: A requirement that specifies the degree of an attribute affecting qualities that the software must possess; e.g. correctness, reliability, maintainability, portability

91 Module IV - Software Construction91 G. Construction QA -2 Software quality: 1. The totality of features and characteristics of a software product that affects its ability to satisfy given needs (for example, to conform to specifications) 2. The composite characteristics of software that determine the degree to which the software will meet the expectations of the customer [ANSI/IEEE Standard 729-1983] 3. Attributes of software that affect its perceived value, for example, correctness, reliability, maintainability, and portability 4. Software quality includes fitness for purpose, reasonable cost, reliability, ease of use in relation to those who use it, design of maintenance and upgrade characteristics, and compares well against reliable products

92 Module IV - Software Construction92 G. Construction QA -3 Internal Quality Attributes of Code Maintainability: Average effort to locate and fix a software failure Flexibility: Effort to extend the software missions, functions, or data to satisfy other requirements Portability: Effort to convert the software for use in other operating environments Reusability: Effort to convert a software component for use in another application Readability: Effort to be able to read and understand source code Verifiability: Effort to verify the delivered operations and performance of the code.

93 Module IV - Software Construction93 G. Construction QA - 4 Techniques for improving code quality To improve the quality of the product you must improve the quality of the process [#1 rule of software engineering] Institute a set of coding guidelines (standards) for the development of code Institute code walkthroughs or inspections Institute a verification and validation (V&V) process to verify code Use external audits when necessary Develop a reward structure that rewards the “good” producers of code rather that the error prone producers of code

94 Module IV - Software Construction94 G. Construction QA - 5 Defect – Detection Rates Detection TechniqueLowest Rate (%) Model Rate (%) Highest Rate (%) Personal checking of design documents153570 Informal group design reviews304060 Formal design inspections355575 Formal code inspections306070 Modeling or prototyping356580 Personal desk-checking of code204060 Unit testing (single routine)102550 Function testing (Related routine)203555 Integration testing (Complete system)254560 Field testing (live data)345065 Cumulative effect of complete series93%99%

95 Module IV - Software Construction95 G. Construction QA - 6 Defect – Detection Rates (continued) Model defect rates are not above 65% of any single technique Code inspections found a 60% model defect rate The model defect rate for [the popular] unit testing is only 25% Code reading detected more interface defects; functional testing detected more control defects To improve defect detection use more than one technique The earlier a defect is caught, the cheaper it is to fix Approximately 50% of the construction phase is spent debugging finished code and finding errors

96 Module IV - Software Construction96 G. Construction QA - 7 The Primary techniques used for construction include [SWEBOK Chapter 4] a) Unit testing and integration testing b) Test-first development c) Code stepping d) Use of assertions e) Debugging f) Technical reviews g) Static analysis

97 Module IV - Software Construction97 G. References ANSI/IEEE Standard 729-1983 “Software: A vital key to UK Competitiveness, “ACARD Working Group, 1986 Software Quality management for distributed systems, RADC-TR-83-175 (Also McConnell, pp, 557-559), 1983. McConnell, Steve, Code Complete, Microsoft press, Redmond, WA, 1993, pp. 560-561 Basili, Victor R, Richard W. Shelby, and David H. Hutchens, “Experiments in Software Engineering.” IEEE Transactions on Software Engineering, SE-12 No pp. 733-743 (Also McConnell, pp. 564

98 Module IV - Software Construction98 G. Quiz 1) ________ is a planned and systematic program of activities designed to ensure that a system has the desired characteristics? a) Software Testing b) Software Construction c) Software Quality Assurance d) Software Maintenance 2) In Software Quality Assurance, the best place to focus is on the a) Product b) Process c) Project d) People

99 Module IV - Software Construction99 H. System Integration and Deployment System Integration – I [RT04, p. 6-53-59] System Integration: The act of merging a software element or elements with another element The act of merging a hardware component or components with another hardware component The act of merging software configuration items with hardware configuration items in order to produce a total system which satisfies customer requirements Types of Integration techniques All in one integration (a.k.a. the “big bang” integration) Incremental integration Top-down integration Bottom-up integration Sandwich integration

100 Module IV - Software Construction100 H. System Integration and Deployment – 2 System Integration – II The Big Bang Integration All components, modules, and subsystems are combined and integrated at one time This is called the “big bang” because it frequently blows up If (and when) the system fails to integrate, it is next to impossible to determine the cause This is called the “smoke test” in the hardware world “Let’s put the power to it and see where the smoke rises” Unfortunately there is no smoke to indicate a fault in software

101 Module IV - Software Construction101 H. System Integration and Deployment – 3 System Integration – III Incremental Integration Incremental integration: 1.Develop a small core of the system 2.Test and debug it 3.Design, code, test, and debug another part (module, routine, etc.) 4. Integrate the new part with the core 5.Ensure that the new partial system works 6.Repeat steps 3 through 5 until finished

102 Module IV - Software Construction102 H. System Integration and Deployment – 4 System Integration – IV Benefits of Incremental Integration Errors are easy to locate – The last integration is probably at fault Incremental integration provides early evidence that progress is being made (better status information) Planning (scheduling) is more accurate Components are tested more fully and frequently Improves the development schedule by work being done in parallel Development and testing are more easily distributed Integration can be done beginning at the top or the bottom (called top-down integration an d bottom –up integration)

103 Module IV - Software Construction103 H. System Integration and Deployment – 5 System Integration – V Top-Down Integration Identify the order of development such that: When developing a routine, all higher routines are completed Harder problems are attacked first; easier problems are delayed Test stubbing is easiest

104 Module IV - Software Construction104 H. System Integration and Deployment – 6 System Integration – VI Top-Down Integration (continued) The order of development depends on the type of project Control oriented: Calling routines are higher than called routines Data oriented: Routines that primarily set data higher than routines that primarily use data Requirements oriented: Routines least sensitive to requirements or design choices are ranked higher than more sensitive routines Test oriented: Routines critically needed for testing of other routines are higher ranked than routines not needed for testing Difficulty oriented: Harder routines are ranked higher than easier routines (This is the order that is illustrated)

105 Module IV - Software Construction105 H. System Integration and Deployment – 7 System Integration – VII Top-Down vs. Bottom-Up Integration

106 Module IV - Software Construction106 H. System Integration and Deployment – 8 Software Deployment [RT04, p. 6-60] Software deployment is the delivery and implementation of a software system, usually to the customer who purchased the system Deployed systems have been factory (alpha) tested Deployment may be on a “try it and see basis” (called a beta test) or for permanent installation Deployed systems are placed under external configuration management Deployed systems may be maintained by either the original developer or a third party

107 Module IV - Software Construction107 H. References [RT04] Thayer, Richard, 2004 Certified Software Development Professional (CSDP) Preparation Course, Chapter 6: Software Construction

108 Module IV - Software Construction108 H. Quiz 1. Which of the following is not a benefit of incremental integration? A.Errors are easier to locate because the last integration is probably at fault. B.Integration can be done beginning at the top or the bottom. C.It requires less test planning than the big bang integration. D.Components are tested more fully and frequently.

109 Module IV - Software Construction109 I. Code Tuning Definition Code tuning is the practice of modifying correct code to make it run more efficiently Code tuning is the enemy if code reliability Code efficiency focuses on the following: Program design Module and routine design Operating-system interactions Code compilations Hardware Code tuning [RT04, p.6-40]

110 Module IV - Software Construction110 I. Code Tuning – 2 Elements of Code Tuning [RT04, p. 6-41] Measures the performance or size to find the trouble (inefficient) areas Measures must be precise Small parts of the program can take a disproportionate share of the run time (80-20 rule) Iteration – Repeat the optimization process to continue receiving efficiency improvements Some areas of inefficiency Input/output operations Paging System calls

111 Module IV - Software Construction111 I. Code Tuning – 3 In Summary… [RT04, p. 6-42] 1.Develop the software using a good design with highly modular code that is easy to understand and modify 2.If performance is poor, measure the system to find the trouble spots 3.Determine whether the real performance comes form: design, data structures, or algorithms and whether code tuning is appropriate 4.Tune the bottleneck identified 5.Measure each improvement; remove it of it does not work 6.Repeat steps 1-5

112 Module IV - Software Construction112 I. References [RT04] Thayer, Richard, 2004 Certified Software Development Professional (CSDP) Preparation Course, Chapter 6: Software Construction

113 Module IV - Software Construction113 I. Quiz 1. Which of the following is least likely to be considered a source of inefficiency with respect to code tuning? A.Lines of code B.System calls C.Paging D.Input/output operations

114 Module IV - Software Construction114 J. Construction Tools Defined [RT04, p. 6-24] Construction tools are used to improve productivity and software quality Construction tools include: Source-code tools Editing Browsing Analyzing code quality Restructuring source code Data dictionaries Executable-code tools Code creation Debugging Testing Code tuning

115 Module IV - Software Construction115 J. Construction Tools – 2 Design Tools [RT04, p. 6-25] Most design tools involve graphic development and drawing tools These tools support one or more of the new technologies, for example: Object-oriented design (OOD) Structured design Design entity-relationship diagrams (ERD) The tools take on the “housekeeping” task (CASE TOLS) For example, keeping the process connected in a “bubble chart” when a new level is defined

116 Module IV - Software Construction116 J. Construction Tools – 3 Source Code Tools [RT04, p. 6-26] Editors—Support for adding, eliminating, and moving items in a document File comparators—Compares two files and identifies areas that are different Source-code beautifiers—Improve the look of code so that it appears consistent Templates—Develop macro steps to save time and improve quality Browsers—Useful for finding and modifying coding elements (strings) Cross-reference tools—Lists variables, routines, and each place they are used

117 Module IV - Software Construction117 J. Construction Tools – 4 Analyzing Code Quality Tools [RT04, p. 6-27] Call-structure generators—Produces information about routines that call each other Picky syntax and semantics checker—Does a more thorough job than the compiler Metrics reporters – Report on selected quality and quantity metrics Restructurers—Convert “spaghetti code” to “structured code” Code translators—Translate code form one language to another Data dictionary—A database of variable names with descriptions

118 Module IV - Software Construction118 J. Construction Tools – 5 Executable-Code Tools [RT04, p. 6-28] Linkers—Supports the connecting and compacting of object files Code libraries—Prepackaged software systems Code generators—Tools that write code from design inputs.. Also used to develop prototypes Macro preprocessors—Allow the creation of simple named constants with no run-time penalty Debuggers—Assist in finding system errors Execution profilers—Watch code while running, tabulating how many times each statement is executed and/or how much time the program spends on each statement Assembler listing—Converts assembler code to the machine code that the computer can use

119 Module IV - Software Construction119 J. References [RT04] Thayer, Richard, 2004 Certified Software Development Professional (CSDP) Preparation Course, Chapter 6: Software Construction

120 Module IV - Software Construction120 J. Quiz 1. Which of the following considered a source code tool? A.File comparators B.Restructurers C.Code-translators D.Debuggers

Download ppt "CSDP Preparation Course Module IV: Software Construction."

Similar presentations

Ads by Google