Lecture 1 of Software Construction

SOFTWARE CONSTRUCTION LECTURE 1
Engr. Huma Ayub huma.ayub@uettaxila.edu.pk

05/05/12 Software Construction 1
Course outline
Module 1: Requirement engineering: structural and behavioral modeling using state machines 1. Introduction to requirements modeling 2. Behavioral modeling 3. Communicating state machines Module 2: Languages, grammars and analyzers 1. Introduction to languages and compilers 2. Lexical analysis (formal languages, regular expressions and accepting automata) 3. Syntax analysis Module 3: Concurrency, implementation design and performance issues 1. Concurrency 2 .Implementation design and performance issues
05/05/12
Software Construction
Books (Reference Material )

Code Complete - A Practical Handbook of Software Construction (2nd Edition) [Steve McConnell] (2004) Object-Oriented Software Construction, by Bertrand Meyer, Second Edition, Published by, Prentice Hall in 1997 Formal Methods in computing by M. Ferenczi, and Andras Pataricza , Sep 2004 Software Engineering by Ian Sommerville, 8th edition, Addison & Wesley. 2006 Software engineering a practitioners approach by Roger S. Pressman
05/05/12
Todays Lecture and Coming Up

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
05/05/12
Software Processes
A Software Process is A set of activities (e.g. requirements, analysis, design, coding, testing) combined and sequenced in a particular fashion to produce software Recent trend: Agile Software Development Customer needs evolve with time Satisfying customers at delivery time (rather than at project initiation) is more important than conforming to initial customer requirements
Software Development Phases

Requirements Requirements
What needs to be What needs to be done done
Testing
Check that the code Check that the code does what it is does what it is supposed to supposed to (functionality, (functionality, performance, performance, reliability, ) reliability, )
Analysis Analysis Project Project Management Management
How it should be How it should be done done
Devise a plan, Devise a plan, manage resources, manage resources, costs, time, costs, time,
Coding Coding
Design Design
Fill in the Fill in the software software structure with structure with code code
Create a software Create a software structure structure (architecture) (architecture) around which code around which will be built will be built
6
Software Phases Related to this Course
Coding Coding
Design Design
Create a software Create a software structure structure (architecture) (architecture) around which code around which will be built will be built
Fill in the Fill in the software software structure with structure with code code
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
05/05/12
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
05/05/12
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
05/05/12
10
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
Software Construction 11
05/05/12
Introduction - 5
Anticipating Change Software changes over time Anticipation / hope of change affect how software is constructed This can effect Use of control structures Handling of errors Source code organization Code documentation Coding standards
05/05/12
12
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
05/05/12
13
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
05/05/12
14
References
[IE04] IEEE Computer Society, Guide to the Software Engineering Body of Knowledge (SWEBOK), IEEE Computer Society Press, Los Alamitos, CA 20001, June 2004 link :
05/05/12
15
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 dont 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
05/05/12
16
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
05/05/12
17
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
05/05/12
18
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!
05/05/12
19
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 (sufficiently) is a key to project success
05/05/12
20
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
05/05/12
21
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
05/05/12
22
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
05/05/12
23
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
05/05/12
24
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 projects 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?
05/05/12
25
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?
05/05/12
26
Construct the Team For small development efforts Self managed Everyone is a peer For mid-size development efforts Role Single team Lead For large development efforts Detailed designer Multiple teams Coder
Integrator Unit tester System tester Buildmeister Configuration manager
# / Team* 1 1 to 4 5 to 10 1 to 2 Same as coder 1 1 1
* Individuals will play multiple roles
Table 1: Team Composition 05/05/12 Software Construction 27
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
05/05/12
28
SOFTWARE CONSTRUCTION LECTURE 2

Engr. Huma Ayub huma.ayub@uettaxila.edu.pk
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
05/05/12
30
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
05/05/12
31
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
05/05/12
32
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
05/05/12
33
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
05/05/12
34
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
05/05/12
35
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
05/05/12
36
B. Code Design - 8
Level 1 Software System The entire system Concern of the architect, not detailed designer Unless system is extremely small
05/05/12
37
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
05/05/12
38
B. Code Design - 10
Level 3 Classes Identify all classes by subsystem Define class relationships Generalizations Dependencies Associations For each class, define its interface
05/05/12
39
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
05/05/12
40
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
05/05/12
41
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
05/05/12
42
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
05/05/12
43
B. Code Design - 15
Design Approaches Iterate Dont 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
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.
05/05/12
45
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.
05/05/12
46
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 1. Logical Refinement of the conceptual model into more detailed logical entities 1. Physical Detailed and optimized phyiscal database table designs
05/05/12
47

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
05/05/12
48

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
05/05/12
49

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

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
05/05/12
51

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
CustID 2332 4048 6301 4893 2943
Name Mary Martin Joe Denver Peg Thrush Amy Meyer Curt Sanchez
Phone (931) 488-2384 (231) 821-8322 (721) 239-2001 (818) 291-8113 (319) 455-8638
Email mmartin01@sbcnet.com jd23@aol.com thrushpa@hotmail.com meyer34@spint.com csanch5@gteconnect.com
Zip 23993 64412 49921 83845 73814
05/05/12
52

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
05/05/12
53

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

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
05/05/12
55

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
05/05/12
56

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

Define Storage Characteristics Design space allocation Design disk page organization
Tablespaces Take advantage of block disk I/O Allow specification of physical data layout
05/05/12
58

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
05/05/12
59

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
05/05/12
60
C. References
[RS04] IBM Rational Software, The Rational Unified Process v2003.06.13, 2004 [UT04] University of Texas at Austin, Introduction to Data Modeling, http://www.utexas.edu/its/windows/database/ -datamodeling, 2004
05/05/12
61
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
05/05/12
62
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
05/05/12
63
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
05/05/12
64
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
05/05/12
65
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
05/05/12
66
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.
05/05/12
67
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
05/05/12
68
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
05/05/12
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
05/05/12
70
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
05/05/12
71
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.
05/05/12
72
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
05/05/12
73
E. References
McConnell, Steve, Code Complete: A Practical Handbook of Software Construction, Microsoft Press, Redmond, WA, 1983. Chapter 13, Pages 302-309
05/05/12
74
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
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 -- Operators manual (most recently combined with Users 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
05/05/12
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 10161998 -- Unit development folder -- Based on work by Frank Ingrassia originally written in 1977
05/05/12
77
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
05/05/12
78
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.
05/05/12
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 lowlevel software units, tasks, work packages, or modules
05/05/12
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.
05/05/12
Commenting Code Useful comments: -- Summary of the code module -- Description of the codes intent -- Use commenting styles that dont 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.
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
05/05/12
83
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
05/05/12
84
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
05/05/12
85
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
05/05/12
86
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.
05/05/12
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
05/05/12
88
Defect Detection Rates
Detection Technique Personal checking of design documents Informal group design reviews Formal design inspections Formal code inspections Modeling or prototyping Personal desk-checking of code Unit testing (single routine) Function testing (Related routine) Integration testing (Complete system) Field testing (live data) Cumulative effect of complete series Lowest Rate (%) Model Rate (%) Highest Rate (%) 15 30 35 30 35 20 10 20 25 34 93% 35 40 55 60 65 40 25 35 45 50 99% 70 60 75 70 80 60 50 55 60 65 99%
05/05/12
89
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
05/05/12
90
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
05/05/12
91
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
05/05/12
92
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
05/05/12
93
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
05/05/12
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 Lets put the power to it and see where the smoke rises
Unfortunately there is no smoke to indicate a fault in 05/05/12 software Software Construction
95

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
05/05/12
96

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)
05/05/12
97

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
05/05/12
98

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)

System Integration VII Top-Down vs. Bottom-Up Integration
05/05/12
100

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
05/05/12
101
H. References
[RT04] Thayer, Richard, 2004 Certified Software Development Professional (CSDP) Preparation Course, Chapter 6: Software Construction
05/05/12
102
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.
05/05/12
103
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]
05/05/12
104
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
05/05/12
105
I.
1. 2. 3.
Code Tuning 3
4. 5. 6.
In Summary [RT04, p. 6-42] Develop the software using a good design with highly modular code that is easy to understand and modify If performance is poor, measure the system to find the trouble spots Determine whether the real performance comes form: design, data structures, or algorithms and whether code tuning is appropriate Tune the bottleneck identified Measure each improvement; remove it of it does not work Repeat steps 1-5
05/05/12
106
I.
References
05/05/12
107
I. Quiz
1. Which of the following is least likely to be considered a source of inefficiency with respect to code tuning? A. B. C. D. Lines of code System calls Paging Input/output operations
05/05/12
108
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
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
05/05/12
110
Source Code Tools [RT04, p. 6-26] EditorsSupport for adding, eliminating, and moving items in a document File comparatorsCompares two files and identifies areas that are different Source-code beautifiersImprove the look of code so that it appears consistent TemplatesDevelop macro steps to save time and improve quality BrowsersUseful for finding and modifying coding elements (strings) Cross-reference toolsLists variables, routines, and each place they are used
05/05/12
Analyzing Code Quality Tools [RT04, p. 6-27] Call-structure generatorsProduces information about routines that call each other Picky syntax and semantics checkerDoes a more thorough job than the compiler Metrics reporters Report on selected quality and quantity metrics RestructurersConvert spaghetti code to structured code Code translatorsTranslate code form one language to another Data dictionaryA database of variable names with descriptions
05/05/12
112
Executable-Code Tools [RT04, p. 6-28] LinkersSupports the connecting and compacting of object files Code librariesPrepackaged software systems Code generatorsTools that write code from design inputs.. Also used to develop prototypes Macro preprocessorsAllow the creation of simple named constants with no run-time penalty DebuggersAssist in finding system errors Execution profilersWatch code while running, tabulating how many times each statement is executed and/or how much time the program spends on each statement Assembler listingConverts assembler code to the machine code that the computer can use
05/05/12
J. References
05/05/12
114
J. Quiz
1. Which of the following considered a source code tool? A. B. C. D. File comparators Restructurers Code-translators Debuggers
05/05/12
115

Lecture 1 of Software Construction

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Lecture 1 of Software Construction

Caricato da

Copyright:

Formati disponibili

SOFTWARE CONSTRUCTION LECTURE 1

Engr. Huma Ayub huma.ayub@uettaxila.edu.pk

Books (Reference Material )

Todays Lecture and Coming Up

Software Development Phases

Analysis Analysis Project Project Management Management

How it should be How it should be done done

Software Phases Related to this Course

# / Team* 1 1 to 4 5 to 10 1 to 2 Same as coder 1 1 1

* Individuals will play multiple roles

Table 1: Team Composition 05/05/12 Software Construction 27

SOFTWARE CONSTRUCTION LECTURE 2

C. Data Design And Management

C. Data Design And Management - 2

C. Data Design And Management - 3

C. Data Design And Management - 4

C. Data Design And Management - 5

C. Data Design And Management - 6

C. Data Design And Management - 7

CustID 2332 4048 6301 4893 2943

Email mmartin01@sbcnet.com jd23@aol.com thrushpa@hotmail.com meyer34@spint.com csanch5@gteconnect.com

Zip 23993 64412 49921 83845 73814

C. Data Design And Management - 8

C. Data Design And Management - 9

C. Data Design And Management - 10

C. Data Design And Management - 11

C. Data Design And Management - 12

C. Data Design And Management - 13

C. Data Design And Management - 14

C. Data Design And Management - 15

E. Source Code Organization

E. Source Code Organization - 2

H. System Integration and Deployment

H. System Integration and Deployment 2

Unfortunately there is no smoke to indicate a fault in 05/05/12 software Software Construction

H. System Integration and Deployment 3

H. System Integration and Deployment 4

H. System Integration and Deployment 5

H. System Integration and Deployment 6

H. System Integration and Deployment 7

H. System Integration and Deployment 8

Potrebbero piacerti anche