1 / 120

CSDP Preparation Course Module IV: Software Construction

CSDP Preparation Course Module IV: Software Construction. Specifications. The exam specific topics covered in this module are listed below, and are the basis for the outline of its content Construction Planning Code Design Data Design and Management Error Processing

jaden
Download Presentation

CSDP Preparation Course Module IV: Software Construction

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CSDP Preparation CourseModule IV: Software Construction

  2. Specifications The exam specific topics covered in this module are listed below, and are the basis for the outline of its content • Construction Planning • Code Design • Data Design and Management • Error Processing • Source Code Organization • Code Documentation • Construction Quality Assurance • System Integration and Deployment • Code Tuning • Construction Tools Module IV - Software Construction

  3. 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 Objectives Module IV - Software Construction

  4. 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 Module IV - Software Construction

  5. Design Construction Testing 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 Module IV - Software Construction

  6. 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 Introduction - 2 Module IV - Software Construction

  7. 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 Module IV - Software Construction

  8. 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 Module IV - Software Construction

  9. 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 Module IV - Software Construction

  10. 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 Module IV - Software Construction

  11. 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 Module IV - Software Construction

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

  13. 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 Module IV - Software Construction

  14. 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 Module IV - Software Construction

  15. 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 Module IV - Software Construction

  16. 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! Module IV - Software Construction

  17. 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 Module IV - Software Construction

  18. 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 Module IV - Software Construction

  19. 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 Module IV - Software Construction

  20. 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 Module IV - Software Construction

  21. 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 Module IV - Software Construction

  22. 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? Module IV - Software Construction

  23. 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? Module IV - Software Construction

  24. 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 Table 1: Team Composition Module IV - Software Construction

  25. 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 Module IV - Software Construction

  26. 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 Module IV - Software Construction

  27. 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 Module IV - Software Construction

  28. 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 Module IV - Software Construction

  29. 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 Module IV - Software Construction

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

  31. 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 Module IV - Software Construction

  32. 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 Module IV - Software Construction

  33. 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 Module IV - Software Construction

  34. B. Code Design - 4 Desirable Design Characteristics Steve McConnell suggests achievement of the following: • Minimal complexity • Ease of maintenance • Loose coupling • Extensibility • High fan-in • Low-to-medium fan-out • Portability • Leanness • Stratification • Standard techniques Module IV - Software Construction

  35. 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 Module IV - Software Construction

  36. 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” Module IV - Software Construction

  37. 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 Module IV - Software Construction

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

  39. 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 • Partition the program into major subsystems • Define subsystem interfaces Module IV - Software Construction

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

  41. 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 Module IV - Software Construction

  42. 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 Module IV - Software Construction

  43. 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 Module IV - Software Construction

  44. 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 Module IV - Software Construction

  45. 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 Module IV - Software Construction

  46. 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. Module IV - Software Construction

  47. 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 Module IV - Software Construction

  48. 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 Module IV - Software Construction

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

  50. 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 Module IV - Software Construction

More Related