Software Architecture and Software Estimation | CSCI 597, Study notes of Computer Science

Download Software Architecture and Software Estimation | CSCI 597 and more Study notes Computer Science in PDF only on Docsity! Center for Systems and Software Engineering Overview of Software Architecture and Software Estimation Raffi Tikidjian Thomas Tan Joshua Garcia Vu Nguyen Daniel Popescu Center for Systems and Software Engineering Outline Overview of Software Engineering Software Architecture Software Estimation Center for Systems and Software Engineering Software Architecture Architecture is a set of principal design decisions about a software system Three fundamental understandings of software architecture 1. Every application has an architecture 2. Every application has at least one architect 3. Architecture is not a phase of development Center for Systems and Software Engineering Faithful Implementation All of the structural elements found in the architecture are implemented in the source code Source code must not utilize major new computational elements that have no corresponding elements in the architecture Source code must not contain new connections between architectural elements that are not found in the architecture Center for Systems and Software Engineering Architecture Compliance Checking Architecture compliance is the degree to which the implemented architecture conforms to the planned architecture • Late architecture evaluation (i.e., after the implementation) Dynamic compliance checking • With run-time traces • Addressing behavioral architectural views Static compliance checking • Without executing the source code • Addressing structural architectural views Center for Systems and Software Engineering Architecture Compliance Checking Approaches Three static architecture compliance checking approaches have been identified • Reflexion models • Relation conformance rules • Component access rules These approaches are a sound quality assurance instrument in architecture development • Benefits of each approach have been shown in several case studies • But • What are the commonalities, differences, advantages and drawbacks of each approach? • When choose approach A instead of approach Center for Systems and Software Engineering Case Study - TSAFE TSAFE is a prototype of the Tactical Separation Assisted Flight Environment as specified by NASA Ames Research Center • TSAFE checks aircraft flights, predicts future trajectories, and displays results on a map • TSAFE was turned into a testbed by Fraunhofer Center Maryland (FC-MD) to be used for software technology experimentation We statically evaluated two variants (original prototype and a redesigned version) of TSAFE to illustrate the three approaches • Architectural models, architectural rules, source code and documentation were available • Architects and developers could be interviewed to obtain further information (if necessary) Center for Systems and Software Engineering Reflexion Models Architectural components are mapped onto source code elements provided in a low-level source code model by human-based mapping These mapping are based on regular expressions and a high-level component typically comprises a high number of source code elements The architectural model contains the planned or intended relations among components At evaluation time, the mappings are resolved Relations among architectural components are marked as convergences, divergences or absences The original idea was introduced by [Murphy, Notkin, and Sullivan, 2001] Center for Systems and Software Engineering Reflexion Models – Compliance Checking Results TSAFE II TSAFE II – compliance checking results TSAFE II – intended subsystem dependencies Center for Systems and Software Engineering Relation Conformance Rules A relation conformance rule defines an allowed or a forbidden relation between two components A relation conformance rule contains a source component and a target component defined by regular expressions • The relation rule "A* must exist B*" defines that a relation must exist from components, which name starts with an A, to components having a name starting with B Relation conformance rules allow that leaf level components can be checked (ignoring their super components) One relation conformance rule can cover multiple relations of different, multiple components Center for Systems and Software Engineering Relation Conformance Rules – Compliance Checking Results TSAFE II TSAFE II – Conformance Rules • No classes but the ServerInterface class shall access classes in the client subsystem • No classes other than the ClientInterface class shall access classes form the server subsystem Center for Systems and Software Engineering Static Architecture Compliance Checking Static architecture compliance checking are a sound instrument in architectural development Demonstration of three approaches derived from practical experiences in industrial and academic case studies • Reflexion models • Relation conformance rules • Component access rules Center for Systems and Software Engineering An Overview of Software Estimation Center for Systems and Software Engineering What is Software Estimation Software Estimation is a process that produces effort, time, cost, etc. for developing software systems BEFORE the work has been done Estimation is a subjective process The most subjective process is GUESS-TIMATE Center for Systems and Software Engineering COCOMO II Overview COnstructive COst MOdel (COCOMO) was invented in 1981 by Dr. Barry Boehm at USC COCOMO II was developed in mid-1990s to adapt to new changes in current and future practices COCOMO II model is one of the most widely-used cost models in the industry, especially by US DoD contractors (Boeing, Northrop Grumman, Aerospace, etc.) COCOMO is continuously supported by Dr. Boehm’s teams at Center for Systems and Software Engineering: • Annual international conference in COCOMO • Emerging extensions are published regularly Center for Systems and Software Engineering COCOMO II Effort Formula N PM = A x SizeE x ∏EMi (Eq. 1) i=1 5 Where E = B + 0.01 x ∑SFj j=1 PM – Effort in person-month Size – Size of projects or modules A – Constant, currently A = 2.94 B – Constant, currently B = .91 SFj – Five scale factors, determined by estimators EMi – Effort multipliers, determined by estimators *Note: A and B can be calibrated Center for Systems and Software Engineering COCOMO II Schedule Formula TDEV = C x PMF x SCED% (Eq. 2) 5 Where F = D + 0.2 x 0.01 x ∑SFj j=1 = D + 0.2 x (E – B) TDEV – Time to develop, calendar month C – Constant, currently C = 3.67 D – Constant, currently D = .28 SCED% – Percentage of schedule compression *Note: C and D can be calibrated Center for Systems and Software Engineering Why Local Calibration? COCOMO II Model Version 2000 was calibrated on 161 data points from industry, mainly from defense contractors Different organizations have different capability and environment Different projects have different characteristics SLOC is used as a size measure. Other sizing units have to be converted to SLOC Center for Systems and Software Engineering Calibration Process Select a target project category l t t r t r j t t r Process Database Calibrated Model li t l Select projects for calibration l t r j t f r li r ti Obtain historical data t i i t ri l t Locally Calibrated Model ll li t l Evaluate the new model l t t l Approve and deploy the model r l t l Calculate A, B, C, D constants l l t , , , t t PM = A x SizeE x ∏EMi TDEV = C x PMF x SCED% Center for Systems and Software Engineering Evaluate Calibrated Model There are two criteria for evaluating cost models • Accuracy • Consistency Model Accuracy is measured by the average Magnitude of Relative Error (MRE) and Prediction Level (PRED) |EstimatedEffort – ActualEffort| MRE = ------------------------------------------------ ActualEffort PRED(p) = k / n Where, p is error level k is the number of projects in a set of n projects whose MRE <= p