+++ Software development processes according to MIL-STD-498 a) Project planning b) Establishing environment c) systems requirement analysis d) system design e) software requirement analysis f) software design g) software implementation and unit testing h) unit integration and testing i) CSCI qualification testing j) CSCI/HWCI integration and testing k) System qualification testing l) Preparing for software use m) Preparing for software transition n) Integral processes 1) Software configuration management 2) Software product evaluation 3) Software quality assurance 4) Corrective action 5) Joint technical and management reviews 6) Other activitys +++ Data Item Descriptions according to MIL-STD-498 (DIDs) and processes aplicable Software Development Plan (SDP) a Software Test Plan (STP) a Software Installation Plan (SIP) a Software Transition Plan (STrP) a Operational Concept Description (OCD) c System/Subsystem Specification (SSS) c Interface Requirements Specification (IRS) c,e System/Subsystem Design Description (SSDD) d,m Inteface Design Description (IDD) d,f Software Requirements Specification (SRS) e Software Design Description (SDD) f Database Design Description (DBDD) d,f Software Test Description (STD) i,k Software Test Report (STR) i,k Software Product Specification (SPS) l,m Software Version Description (SVD) l,m Software User Manual (SUM) l Software Input/Output Manual (SIOM) l Software Center Operator Manual (SCOM) l Computer Operation Manual (COM) l Computer Programming Manual (CPM) m Firmware Support Manual (FSM) m +++ Software development cycle according to ASP's Systems Analysis and Design SSD,preSRS,preIRS System Requirements Review Requirements Analysis SRS,IRS Design Rediness Review Preliminary Design preSDD,preIDD,STP Preliminary Design Review Detailed Design SDD,IDD,STD Critical Design Review CSU Coding and Testing Source Formal reviews, code inspection etc. CSC Integration and Testing Tests Test Readiness Review CSCI Testing STR Functional Audit +++ Software development cycle according to Booch Requirements Analysis steps ? deliverables System Charter System Function Statement Domain Analysis steps Define Classes Define Relationships Define Operations Find Attributes Define Inheritance Validate and Iterate deliverables Class diagrams Class Specifications Object Diagrams Data Dictionary System Design steps Determine initial architecture Plan executable releases Develop executable releases Refine the design deliverables Architectural descriptions Executable release descriptions Class-catagory diagrams Design class diagrams Design object-scenario diagrams New Specifications Amended class specifications +++ My opinion on required contents of a Software/Hardware IDF-Item Design File Development schedule IDP-Item development plan Design analysis/requirements IRS-Item requirements specification (interface part, pre/post/invariants) Design definition/implementation IDD-Item design document (implementation part, sub-components) ICI-Item construction instructions (compile, machine, etc) IUM-Item user manual Testing definition/implementation TDD-Test design document TCI-Test construction instructions (compile, equipment, etc) TUM-Test user manual (test procedures) Test results/analysis ITR-Item test report Design requests/changes IPR-Item problem report ICP-Item change proposal? Each item subcomponent will have its own IDF with all of the above sections/documents as they are deemed necissary. All sections shall be version controlled and will be updated regularly/iterativly during the development cycle. The total system documentation will be heavily cross referenced, and can be arranged in several different hirachys; Design hirachy - Ordered by design decomposition (item and components construction/inheritance). Version hirachy - Ordered by version history (major and minor version numbers). Content hirachy - Ordered by type of content. (plans, requirements, designs, tests etc) These hirachys are best mantained by some sort of electronic database or hypertext system so that all the different combinations of these hirachys can be viewed, ie; ITR documents of, a particular version of, all components IDD documents of, all versions of, a particular component all documents of, a particular version of, a particular component The best way to view version historys of all documents is with some sort of revision history/difference program. This way the latest version of the Design File does not explicitly contain all versions of the IDD, but this can still be viewed by examining the version history of the IDF itself. IRS Includes all requirements analysis and the results of this analysis. "Use case analysis" is a good idea, with each use case coresponding to an application method. Output according to Booch is "System Charter" outline of system responsibilitys and "System Function Statement" outline of system use cases. I suggest at least; requirements analysis, item overview, use case description. Annotate changes to requirements with reasons for change. +++ Software design procedures Procedural or Object based Software design (component decomposition, but no inheritance) 1) Identify and define need (main object). 2) Evaluate interface/design alternatives, checking library for relevant items. 3) Select alternative and define interface. 4) Subdivide item by identifying subcomponents. On the failure to subdivide item easily, back track to step 2 (1?) and try again. 5) Define item's test procedures, ie write a test program. 6) Repeat 2-7 for each subcomponent, unless it is so simple as to be trivial or already in the library. 7) Test the complete item, repeating 2-7 untill tests are passed. 8) Repeat 1-8 each time a change is requested. Refinement or Object Oriented Software design (pre-existing items are modified or inherited from) 1) Identify and define need (ie main class). 2) Evaluate library item alternatives to modify/inherit from (parent classes). 3) Select alternative and identify refinements required, defining interface. 4) Refine parent by modifying and adding features. On the failure to refine parent easily, back track to step 2 (1?) and try again. 5) Refine parent's test procedures, ie extend parent's test programs. 6) Repeat 2-7 for each changed feature, unless it is so simple as to be trivial or already in the library. 7) Test the complete item, repeating 2-7 untill tests are passed. 8) Repeat 1-8 until happy with item. +++ Software behavior requirements/constraints invariants - conditions that must always be met (mutual requirements) pre-conditions - conditions that must be met before the software starts (contractor requirements) post-conditions - conditions that must be met after the software completes (contract requirements) The pre and post conditions must be subsets of the invariants, but they need not intersect. Inheritence : invariants are intersected, pre-conditions are unioned, post-conditions are intersected. Construction : invariants are intersected, pre-conditions are intersected, post-conditions are intersected. Note that each sub-component of a system will have it's own set of these. This means that the total requirements of a system will be defined by the intersection of all the constraints of its sub-components. This means that the constraints of any component must be a superset of the constraints of it's sub-components for it to be "correct". +++ Software structure discription |name |contents --------------+---------------+------------ classes |object |data/methods var-type |variable |data proc-type |procedure |method "contents", "name", and "description" can all be either dynamic or static, but for strongly typed languages, dynamic discription (ie type casting) should be avoided. dynamic creation of any "name" is possable using pointers, but static creation is more common. Note that if dynamic creation of a "name" is possible, this will be reflected by its "discription"? "contents" can be dynamic or static (ie. VAR or CONST). Note that not only can the "contents" change value, but they can change size and structure(ie. linked lists)given that their "discription" allows it. Note that not all languages will have all the above constructs. Good object-oriented languages may have only objects and classes, but some may have procedures and proc-types. inheritance is construction of a new object using the "Parent(s)" as a base construction is building a new object out of other object "parts" +++ Software naming conventions discription - classes - caps & version no. (1 digit + 1 implied) - sub-type - mixed or caps - var-type - mixed name - object - mixed - subroutine - lows or mixed - variable - lows contents - machine dependant, un-accessable files - as per contents name (ie classes) +++ Software hirachies Software systems have many hirachies, Class hirachies based on inheritance. ie. sub-classes wheel mag-wheel white-wall Object hirachies based on construction. ie. sub-objects car body wheels Scope hirachie based on the software scopes. car mag-wheel body fittings Version hirachie based on version history. vers11 vers12 vers21 vers31 vers32 All classes must be referenced by the Class hirachie?? All objects must be referenced by the Object hirachie. +++ Data cycle construction create - put in symbol table. class creation All classes are created by inheritance and have a place in the "inheritance hyrachy". At the very least they are inherited from the Class "object". allocate- assign memory location. object creation This is one of the basic methods of the "Object" class init - initialise values. object initialisation Note that this process may infact 'create' other sub-objects. This is also another basic method of the "object" class. use note that the only data accessable in an object is the global data. With strict object orientation this is only the methods. assign - load value access - read value destruction de-init - prepare for distruction. object de-initialisation This is to ensure that object destruction has no side effects. This usualy only applies if sub-objects must also be destroyed. Another of the basic methods of the "object" class de-alocate- free memory location. object destruction This is one of the basic methods of the "Object" class destroy - remove from symbol table.class destruction The class is removed from the inheritance hirachy +++ Object cycle inherit(Class,Parent_Class..) define class (enter class into symbol table) define(object,Class) define object (enter var into symbol table, if "value" object, also allocate) object.create create object (initalize object, if "reference" object, also allocate) object.method(params) access object (execute methods) object.destroy destroy object(de-initalizes object, if "reference" object, also de-alloate) delete(object) delete object (remove object from symbol table, if "value" object, also de-allocate) erase(Class) delete class (remove class from symbol table)