The Major Continuing Software Development Project Ronald J. Leach Copyright Ronald J. Leach, 1997, 2009, 2014,

The Major Continuing Software Development Project - Requirements Elicitation Copyright Ronald J. Leach, 1997, 2009, 2014,

Requirements Elicitation Several stakeholders develop a problem statement after several iterations. Eliminate vague and unsustainable words – Standard, as simple as possible, flexible enough, should have a common interface, treated as library requirements They produce some examples of how the system should work. Copyright Ronald J. Leach, 1997, 2009, 2014,

Requirements Traceability Create a preliminary RTM. If no test can be determined for a particular requirement, it should be rewritten or discarded. Copyright Ronald J. Leach, 1997, 2009, 2014,

Sample designs of screens Copyright Ronald J. Leach, 1997, 2009, 2014, Such mockups can help explain proposed systems

Review Review the requirements Copyright Ronald J. Leach, 1997, 2009, 2014,

The Continuing Major Software Engineering Project: Design Copyright Ronald J. Leach, 1997, 2009, 2014,

One possible physical architecture Copyright Ronald J. Leach, 1997, 2009, 2014,

Alternative physical architecture Copyright Ronald J. Leach, 1997, 2009, 2014,

Initial set of six subsystems Copyright Ronald J. Leach, 1997, 2009, 2014, Subsystem for the user interface. Subsystem for obtaining files and analyzing file types. Subsystem for passing input files to data collection subsystem. Subsystem for collecting data for each input file. Subsystem for sending data to spreadsheet or database. Spreadsheet or database program.

Final set of four subsystems 1.Subsystem for the user interface, obtaining files and analyzing types 2.Subsystem for collecting data for each input file 3.Subsystem for sending data to spreadsheet or database 4.Spreadsheet or database program Copyright Ronald J. Leach, 1997, 2009, 2014,

High-level system archtecture Copyright Ronald J. Leach, 1997, 2009, 2014,

Prelim. Procedurally Oriented Design Copyright Ronald J. Leach, 1997, 2009, 2014,

Prelim. Data Flow Diagram (DFD 0) Copyright Ronald J. Leach, 1997, 2009, 2014,

Attributes of objects AttributeTypical Value NameCharacter string SizeInteger Module in which locatedCharacter string Copyright Ronald J. Leach, 1997, 2009, 2014, For “Function Objects” in the input data files

Attributes of objects Copyright Ronald J. Leach, 1997, 2009, 2014, For “source code files” in the input data files AttributeTypical Value NameCharacter string SizeInteger Number of functionsInteger List of functionsLinked list of character strings Subsystem in which located Character string

Attributes of objects Copyright Ronald J. Leach, 1997, 2009, 2014, For “Subsystem Objects” in the input data files AttributeTypical Value NameCharacter string SizeInteger Number of source code files Integer List of source code filesLinked list of character strings

Requirements Traceability Matrix # RequirementDesignCodeTest 1. Intel-basedY 2. Windows 8Y 3. Windows 8 UIY 4. Consistent With Excel 14.0Y 5. System One Size OnlyY MB System MB Disk Space 8. CD 9. Includes InstallationY 10. No Decompression UtilityY 11. One input file at a timeY Copyright Ronald J. Leach, 1997, 2009, 2014,

Requirements Traceability Matrix # RequirementDesignCodeTest 12. Size of each functionY 13. Size of each fileY 14. Size of systemY 15. Compute totalsY 16. Develop std for C,C++,AdaY 17. Batch-oriented systemY 18. Precisely define LOCY 19. Measure separatelyY 20. No error checking of inputY 21. Front end in C or C++Y Copyright Ronald J. Leach, 1997, 2009, 2014,

Requirements Traceability Matrix # RequirementDesignCodeTest 22. Batch processingY 23. File names limited to 32 char. Y 24. Wild cards can be usedY 25. Dead code ignoredN 26. No special compilers needed Y Copyright Ronald J. Leach, 1997, 2009, 2014,

Interfaces with Windows Copyright Ronald J. Leach, 1997, 2009, 2014,

System Output Copyright Ronald J. Leach, 1997, 2009, 2014,

System Output Copyright Ronald J. Leach, 1997, 2009, 2014,

System Output Copyright Ronald J. Leach, 1997, 2009, 2014,

The Continuing Major Software Development Project: Coding Copyright Ronald J. Leach, 1997, 2009, 2014,

Coding standards Have we followed them? Have we been consistent with naming conventions? Copyright Ronald J. Leach, 1997, 2009, 2014,

Requirements Traceability Have we listed our source code in the RTM? Has every requirement been implemented? Copyright Ronald J. Leach, 1997, 2009, 2014,

Coding and Project Management, Cont. Perform a status check. Are we ahead of schedule (unlikely), behind schedule (likely), or approximately on target? Have there been any unpleasant surprises, any portions of the system that were more difficult than we expected? Copyright Ronald J. Leach, 1997, 2009, 2014,

Coding and Project Management Does any portion of the system require extra attention, perhaps additional resources? Have technology or market pressures rendered any portion of the system obsolete? Copyright Ronald J. Leach, 1997, 2009, 2014,

Coding and Project Management Perform a status check. Are we ahead of schedule (unlikely), behind schedule (likely), or approximately on target? Have there been any unpleasant surprises, any portions of the system that were more difficult than we expected? Does any portion of the system require extra attention, perhaps additional resources? Have technology or market pressures rendered any portion of the system obsolete? (Recall that we did this status check earlier.) Copyright Ronald J. Leach, 1997, 2009, 2014,

Use a RTM List the requirements, documentation, and all delivered items in the RTM to adhere to quality standards. (Our RTM was vague on this, so it needs to be fixed.) Use the RTM as a status check. Copyright Ronald J. Leach, 1997, 2009, 2014,

Improve the development process Enter data about the project’s cost, schedule, and quality into a database for further analysis. This is a good time to consider process improvement. Copyright Ronald J. Leach, 1997, 2009, 2014,

The Major Continuing Software Project: Testing Copyright Ronald J. Leach, 1997, 2009, 2014,

A high-level view The entire software system is comprised of modules, many obtained from other sources. Software utilities are considered as black boxes Only interfaces need to be checked. The same approach when testing the “glueware” used to combine these utilities. Black-box testing is a natural choice for this. Copyright Ronald J. Leach, 1997, 2009, 2014,

White-box testing? This is appropriate when there are many execution paths and complex internal logic. This describes the software interfacing to the operating system for the linking of names of input files to later routines. This was to be done using command-line arguments. Copyright Ronald J. Leach, 1997, 2009, 2014,

Choices For small units, choose one of: White-box testing Black-box testing For subsystems (larger units): Choose procedural testing for procedurally developed subsystems Choose object-oriented testing for O-O developed subsystems Copyright Ronald J. Leach, 1997, 2009, 2014,

Oobject-oriented methods Must be applied to the back end of the system. The main testing for this subsystem are completeness of the objects and the proper assignment of default values to member functions. Copyright Ronald J. Leach, 1997, 2009, 2014,

The Major Continuing Software Project: Integration Copyright Ronald J. Leach, 1997, 2009, 2014,

Top-down or bottom-up or other? Start with a top-down approach. Check user interface to see if file names are handled properly. Check to see if the first subsystem recognizes the names of input files and the appropriate directories. Copyright Ronald J. Leach, 1997, 2009, 2014,

Integrate objects bottom-up The back end of the software system consists of O-O modules for output data storage and for display. Integrate these objects bottom up Copyright Ronald J. Leach, 1997, 2009, 2014,

Combine the system’s front and back ends A hybrid integration approach. Ideally, very few steps are necessary. Copyright Ronald J. Leach, 1997, 2009, 2014,

Check the RTM for completeness The Requirements Traceability Matrix lists each requirement and a test for it. Make sure that all requirements are actually implemented and tested for. Copyright Ronald J. Leach, 1997, 2009, 2014,

The Major Continuing Software Development Project: Delivery, Installation and Documentation Copyright Ronald J. Leach, 1997, 2009, 2014,

Use a RTM List the requirements, documentation, and all delivered items in the RTM to adhere to quality standards. (Our RTM was vague on this, so it needs to be fixed.) Use the RTM as a status check. Copyright Ronald J. Leach, 1997, 2009, 2014,

Improve the development process Enter data about the project’s cost, schedule, and quality into a database for further analysis. This is a good time to consider process improvement. Copyright Ronald J. Leach, 1997, 2009, 2014,

Maintenance of the Major Continuing Software Development Project Copyright Ronald J. Leach, 1997, 2009, 2014,

Maintenance occurs after delivery What happens next in a software engineering course after the semester is over? New features Improved design Increased security … Copyright Ronald J. Leach, 1997, 2009, 2014,

Suggested new features Migrate to a new operating system Move to a new platform Copyright Ronald J. Leach, 1997, 2009, 2014,

Suggested new design Move to a Macintosh Move to a Linux or UNIX system Move some data to a tablet or smart phone Improve visualization Copyright Ronald J. Leach, 1997, 2009, 2014,

Improve security Always! Copyright Ronald J. Leach, 1997, 2009, 2014,

An opportunity The major continuing software development project used a particular software development process, perhaps different ones for different teams using other methods. How can we tell what worked best? Copyright Ronald J. Leach, 1997, 2009, 2014,

The solution Use maintenance information to analyze quality and other metrics on different types of software development processes. The goal is process improvement. NOTE: this analysis of maintenance data is a critical part of software engineering! Copyright Ronald J. Leach, 1997, 2009, 2014,