Software Engineering: Understanding the Software Lifecycle and Designing Chart Maker - Pro, Study notes of Electrical and Electronics Engineering

Download Software Engineering: Understanding the Software Lifecycle and Designing Chart Maker - Pro and more Study notes Electrical and Electronics Engineering in PDF only on Docsity! Basic Embedded Software Engineering: The Software Lifecycle Se weCaariorre Learning Objectives Based on requirements specifications, develop – high-level design specs with tests – detailed design specs with tests – other testing as needed Understand how to provide and verify traceability across the V throughout the process Learn how to perform design reviews and code walkthroughs Capability Maturity Model (CMM) CMM developed by CMU’s Software Engineering Institute (SEI) to define maturity of software development processes Level 1: Initial. – Ad hoc and occasionally even chaotic. – Few processes defined. – Success often requires “heroes”. Overtime, weekends, no vacation. Level 2: Repeatable. – Basic project management processes track cost, schedule and functionality. Level 3: Defined. – Processes for management and engineering are documented, standardized, and integrated into overall organization software process. Level 4: Managed. – Software process and product quality are measured quantitatively. – Metrics are used to adjust process. Level 5: Optimizing. – Continuous process improvement is performed. – Innovative ideas are applied and evaluated using metrics. Real World: CIMM What could possibly be worse than Level 1 (ad hoc and chaotic)? Capability Im-Maturity Model, developed by Capt. Tom Schorsch, U.S. Air Force The CIMM adds maturity levels below Level 1 Level 0: Negligent – “Indifference: • Failure to allow successful development process to succeed. • All problems are perceived to be technical problems. • Managerial and quality assurance activities are deemed to be overhead and superfluous to the task of software development process. • Reliance on silver pellets.” Level -1: Obstructive – “Counterproductive: • Counterproductive processes are imposed. • Processes are rigidly defined and adherence to the form is stressed. • Ritualistic ceremonies abound. • Collective management precludes assigning responsibility. • Status quo forever.” Real World: CIMM Level -2: Contemptuous – “Arrogance: • Disregard for good software engineering institutionalized. • Complete schism between software development activities and software process improvement activities. • Complete lack of a training program.” Level -3: Undermining – “Sabotage: • Total neglect of own charter, • conscious discrediting of peer organizations software process improvement efforts. • Rewarding failure and poor performance.” http://www.stsc.hill.af.mil/crosstalk/1996/11/xt96d11h.asp Finkelstein, "A Software Process Immaturity Model," ACM SIGSOFT, Software Engineering Notes, Vol. 17, No. 4, October 1992, pp. 22-23. Requirement Analysis V Model Overview Requirements Specification Functional Testing Architectural Design Integration Testing Detailed Design Integration Testing Validation provided by testing Review Review Themes: – Link front and back ends of life-cycle for efficiency – Provide “traceability” to ensure nothing falls through the cracks Coding S/W UnitTesting Code Review Review Implementing the V 1. Requirements specification n Define what the system must do 2. Architectural (high-level) module and test design (state- based, control-flow-based) 3. Detailed module and test design 4. Coding and Code Inspections 1. Requirements Spec. & Validation Plan Result of Requirements Analysis Should contain: – Introduction with goals and objectives of system – Description of problem to solve – Functional description • provides a “processing narrative” per function • lists and justifies design constraints • explains performance requirements – Behavioral description shows how system reacts to internal or external events and situations • State-based behavior • General control flow • General data flow – Validation criteria • tell us how we can decide that a system is acceptable. (Are we there yet?) • is the foundation for a validation test plan – Bibliography and Appendix refer to all documents related to project and provide supplementary information
 Chart Maker General Requirements
             
     !
"#  Three operating modes – Standby – Record • Get depth information from Sonar via RS232 • Get position information from GPS via RS232 • Store most recent depth from each position in DataFlash – Download • Download depth and position information from DataFlash $%%&#
 '()
))'  Chart Maker SW&HW Requirements Specification 1.Input data 1.Accept NMEA-0183 format data sentences from GPS receiver and extract time, date, position, speed over ground and bearing information while discarding sentences with CRC errors 2.Accept NMEA-0183 format data sentences from depth sounder (SONAR) and extract depth, battery voltage, speed through water, and water temperature information while discarding sentences with CRC errors 2.Data storage 1.Every two seconds, record most recent extracted data to data flash memory in the following human readable text form: 1. Depth data shall be stored as DXX.X, measured in feet 2. Latitude position data shall be stored as [N|S]XX.YYYY, with XX measuring degrees and YYYY measuring thousandths of minutes 3. Longitude position data shall be stored as [E|W]XXX.YYYY, with XX measuring degrees and YYYY measuring thousandths of minutes 4. Battery voltage shall be stored as BXX.X, measured in volts. 5. etc. Chart Maker SW&HW Requirements Specification 3.User interfaces 1. Primary user interface 1. The primary user interface shall have a push-button momentary switch and a text LCD. 2. Pressing the switch shall toggle between enabling (RECORD) and disabling (STANDBY) data recording. 3. Disabling recording shall allow power to be turned off after no more than one second without any data loss. 4. The LCD shall display amount of data flash memory used, and certain data received from the GPS (position, speed over ground, time) and depth sounder (depth, speed through water, battery voltage) 2. Secondary (remote) user interface 1. This interface shall be accessed through a serial port (19200 baud, 8 data bits, no parity, one stop bit) 2. This interface shall provide the following functions to the user 1. Erase all data flash memory contents 2. Download all data flash memory contents 4.Robustness 1. A watchdog timer shall be used to detect an out-of-control program within 100 ms. 2. If data is detected from both NMEA sources, the device will automatically switch to record mode. 5.Power 1. Power shall be supplied to the chart maker at 12 V. 2. Maximum current consumption in RECORD and STANDBY modes shall be no more than 100 mA Architectural Styles for Software Several general styles or patterns exist Each describes – Components which perform some function – Connectors with which components communicate, coordinate and cooperate – Constraints which define how components fit together – Semantic Models which allow designer to determine system behavior by composing component and connector behavior Architectural Patterns Concurrency—applications must handle multiple tasks in a manner that simulates parallelism – operating system process management pattern – task scheduler pattern Persistence—Data persists if it survives past the execution of the process that created it. Two patterns are common: – a database management system pattern that applies the storage and retrieval capability of a DBMS to the application architecture – an application level persistence pattern that builds persistence features into the application architecture Distribution— the manner in which systems or components within systems communicate with one another in a distributed environment – A broker acts as a ‘middle-man’ between the client component and a server component. Data-Flow Architectures Transforms input data into output data Pipes and filters – Pipes communicate data – Filters transform data Filters operate independently of each other Commonly used for signal processing Call and Return Architectures Represents hierarchical nesting of control in program – “main calls get_data which calls convert_input…” Scalability and modification straightforward Sub-types of Call and Return architectures – main program/subprogram: single processor – remote procedure call: subprograms may be distributed across remote processors Data Design Important data should be clearly specified and described Principles – Use Data Dictionary to define data and program design – Defer low-level decisions until late in design process – Use abstraction and information hiding to separate logical and physical views of system – Develop a library of useful data structures and operations for reuse Chart Maker Thread and Data Architecture  
  
     !   "
 
"#  "$ %#   & &  '  '$     !  (   ( )  
     * ( " *  
  +
#  "$ %# &  $ ,  High-Level Design for Chart Maker 4. Threads 1. Process_NMEA_Data 1. This thread shall decode incoming data from both UART 2. This thread shall detect corrupted sentences by computing a checksum on received data and comparing it with the received checksums. Corrupted sentences shall be discarded without additional processing. 3. This thread shall decode valid sentences and update relevant global variables. 4. This thread shall run often enough so that UART receive data buffers can never overflow 2. Format_and_Save_Data 1. This thread shall run approximately every two seconds (+/- 10%). 2. This thread shall be disabled when the system is in STANDBY mode. 3. This thread shall be enabled when the system is in RECORD mode, 4. This thread shall read all relevant variables to be recorded, format them into ASCII text according to RS 2.1 and write them to the data flash SRAM buffer via the SPI interface. 5. When the buffer is nearly full (it is possible for the next thread invocation to overflow the buffer), the thread shall send the data flash controller the SPI command to write the buffer contents to the current flash page. High-Level Design for Chart Maker 4. Threads 3. Primary_User_Interface 1. This thread shall run ten times per second. 2. This thread shall read the switch and debounce it, requiring it to be active three times in a row before responding to it. 3. This thread shall use the debounced switch value to toggle the system between RECORD and STANDBY modes. 4. Upon switching to RECORD mode, this thread shall enable the Format_and_Save_Data task. 5. Upon switching to STANDBY mode, this thread shall diable the Format_and_Save_Data task. 4. Secondary User Interface 1. etc. High-Level Design for Chart Maker 5. Global Data 1. Logged Data Variables 1. The CurDepth variable shall be a float, measured in feet, and shall hold the most recently received depth information. 2. The CurVelG variable shall be a float, measured in knots, and shall hold the most recently received velocity over ground speed information. 3. etc. 2. Communication Queues 1. U0RxQ 1. This queue shall be implemented as a circular buffer sized large enough to handle all possible incoming NMEA-0183 data while being serviced every two seconds. 2. Data shall be enqueued by the UART 0 receive character ISR. 3. Data shall be dequeued by the Process_NMEA_Data thread. 4. If data arrives when the queue is full, that data should be discarded. 2. etc. Example: Detailed Design for Chart Maker 4.1: Threads: Process_NMEA_Data – Code to process received NMEA data will implement the flowchart FC4.1. 4. Coding and Code Inspections Coding driven directly by Detailed Design Specification Use a version control system while developing the code Follow a coding standard – Eliminate stylistic variations which make understanding code more difficult – Avoid known questionable practices – Spell out best practices to make them easier to follow Perform code reviews Test effectively – Automation – Regression testing Version Control Use a version control system – “Time machine” for coding – Procedure • Check out code module • Do your programming and testing • Update the module (in case anyone else has changed it) • Check code module into the repository when the code works (commit) – Examples: CVS, RCS, SourceSafe Use regression tests – Verify the code works before checking it into the repository • Use test cases which exercise as much of the code as possible • Include – Automation extremely useful • Shell scripts, etc. • Can even automate finding the bugs sometimes Types of Peer Code Review (2) E-mail pass-around – Author emails files/change logs to reviewers for discussion (by email) – Can use version control system to determine automatically what has changed – Advantages • Easy to implement, easy to add reviewers • Simple scheduling – Disadvantages • Scales badly – gets hard to track threads and changes for large projects • Email slows down communication • Doesn’t ensure all changes are reviewed • Doesn’t ensure all fixes are made and are correct Tool-assisted reviews – Use special review tool • Automatically gathers files, integrated with version control system • Provides combined display of file differences, comments and defects • Automatically collects metrics (e.g. lines inspected per hour, defects found per hour, defects found per thousand lines of code) • Allows monitoring of which changes have been reviewd, and which bugs have been fixed • Presents efficient specialized interfaces for coders, reviewers and managers Types of Peer Code Review (3) Pair-programming – Two developers sit at one workstation – Only one types at a time – Advantages • Very effective at finding bugs and transferring knowledge • Reviewer is very familiar with code, given long-term involvement with development – Disadvantage • Reviewer may be too involved to see big-picture issues (may need other form of review) • Takes a lot of time (two whole programmers, full-time) • Doesn’t work well with remote developers Testing: Integrate Test Definition with Designing We now revisit specification and design documents to insert testing plan. In practice, we would do them concurrently. Levels – Requirements Specification and Validation Plan – High-Level Design and Test Plan – Detailed Design and Test Plan Approaches to Testing Incremental Testing – Code a function and then test it (module/unit/element testing) – Then test a few working functions together (integration testing) • Continue enlarging the scope of tests as you write new functions – Incremental testing requires extra code for the test harness • A driver function calls the function to be tested • A stub function might be needed to simulate a function called by the function under test, and which returns or modifies data. • The test harness can automate the testing of individual functions to detect later bugs Big Bang Testing – Code up all of the functions to create the system – Test the complete system • Plug and pray Why Test Incrementally? Finding out what failed is much easier – With Big Bang, since no function has been thoroughly tested, most probably have bugs – Now the question is “Which bug in which module causes the failure I see?” – Errors in one module can make it difficult to test another module • Errors in fundamental modules (e.g. kernel) can appear as bugs in other many other dependent modules Less finger pointing = happier SW development team – It’s clear who made the mistake, and it’s clear who needs to fix it Better automation – Drivers and stubs initially require time to develop, but save time for future testing Example Write NMEA decoder functions Configure U0, U2 for Rx at NMEA speed Configure ISRs t use UART que Write code to extract sentences from Rx queue Test harness to feed canned NMEA data into Rx queues Define use Write read switch task ae LNOCHARIOITE In-Class Exercise: Test Plan Definition Create test plans for Chart Maker – Requirements + acceptance tests – High-level design + integration test plans – Detailed design + unit tests Perform Project Postmortems Goals – improve your engineering processes – extract all useful information learned from the just-completed project – provide “virtual experience” to others – provide positive non-confrontational feedback – document problems and solutions clearly and concisely for future use Basic rule: problems need solutions – A postmortem is not… • a forum for assigning blame to engineers • a way to complain about management • a place to whine Often small changes improve performance, but are easy to forget Example Postmortem Structure Product – Bugs – Software design – Hardware design Process – Code standards – Code interfacing – Change control – How we did it – Team coordination Support – Tools – Team burnout – Change orders – Personnel availability