Upslis faculty tenure lecture presentation
0 likes311 views
The document presents a tenure lecture by Sonia M. Pascua, detailing her academic and professional background in library and information studies, as well as software engineering. It discusses her research on quantifying software entropy through measuring control structures and cohesion, aiming to help software designers enhance the stability and robustness of their products. The study explores methodologies for measuring functional cohesion and proposes future work in automating these calculations.
Upslis faculty tenure lecture presentation
- 1. Tenure Lecture Presentation Sonia M. Pascua Faculty School of Library and Information Studies
- 2. Biography Sonia M. Pascua Faculty School of Library and Information Studies
- 3. Academic Background B. S. in Library and Information Science, School of Library and Information Science University of the Philippines – UP Diliman
- 4. Academic Background Master of Science in Computer Science, Department of Computer Science, College of Engineering University of the Philippines – UP Diliman. (June 26, 2016)
- 5. Academic Background Certified Librarian – Board for Librarian (November 2007) One Year Full-Time Certificate in Information Technology, Specialization: Applications Development, University of the Philippines Information Technology Training Center – UP Diliman • UPITTC Scholar
- 6. Professional Experiences in the Academe Faculty, University of the Philippines School of Library and Information Studies (UP SLIS), June 2013 – Present QMS Lead, eUP Project, March 2016 - December 2016 Program Developer Associate, eUP Project, June 2015 - July 2017 Project Manager, UPITDC – CHED Project, January 7, 2013 – March 7, 2013 Project Manager, UP ITDC - Technical and Professional Services for the Rehabilitation of CHED’s Internet, Website and Email Services, April 10 – 27, 2012 Software Analyst, UP ITDC - CATT CSharpMigration_ChartGui Project of Fujitsu Ten Solutions Philippines, UP ITTC, February 2012 - April 2012 Project Manager, Youth Conference in IT (YCIT) 2010. February 17 and 18 2010
- 7. Professional Experiences in the Academe Sr. Applications Development Training Officer, University of the Philippines IT Training Center (UPITTC), February 2010 – May 2013 Deputy Training Manager, University of the Philippines IT Training Center (UPITTC), February 2009 – May 2013 Deputy Quality Management Representative, ISO 9001-2008 QMS, University of the Philippines IT Training Center, February 2010 – April 2013 Speaker and Trainer • Software Quality Assurance • Systems Thinking • Project Management • Embedded Indexing • Understanding Digital Preservation • Cloud Computing: Web Technologies • Careers in IT
- 8. Professional Experiences in the Corporate Industry Faculty, University of the Philippines School of Library and Information Studies (UP SLIS), June 2013 – Present IT Project Manager, Telus House McKinley West Buildout Telus International Philippines, January 2016 - Present QMS Lead, eUP Project, March 2016 - December 2016 Program Developer Associate, eUP Project, June 2015 - July 2017 Project Manager, UPITDC – CHED Project, January 7, 2013 – March 7, 2013 Project Manager, UP ITDC - Technical and Professional Services for the Rehabilitation of CHED’s Internet, Website and Email Services, April 10 – 27, 2012 Software Analyst, UP ITDC - CATT CSharpMigration_ChartGui Project of Fujitsu Ten Solutions Philippines, UP ITTC, February 2012 - April 2012
- 9. A Control Structure - Token Based Metric for Software Functional Cohesion, Entropy and Re-engineering
- 10. A Control Structure - Token Based Metric for Software Functional Cohesion, Entropy and Re-engineering
- 12. Theoretical Framework My study is categorized under the field of Software Engineering
- 13. Theoretical Framework My topic falls under the Software Configuration Management.
- 14. Theoretical Framework In software engineering, software configuration management (SCM) is the task of tracking and controlling changes in the software
- 15. Theoretical Framework In softwar A field under Software Quality Assurance (SQA) which is task to measure and maintain the quality of the software. Evoke Technologies
- 16. Background of the Study • When companies use technology such as software in process control and management, two of many possible objectives for continuous growth they have are (1) efficiency in resource utilization and productivity, and (2) an overhead amount of time and related cost in updating and managing this technology.
- 17. Background of the Study • When companies use technology such as software in process control and management, two of many possible objectives for continuous growth they have are (1) efficiency in resource utilization and productivity, and (2) an overhead amount of time and related cost in updating and managing this technology. Sometimes the existence of the second may be contradictory to achieving the first one
- 18. Background of the Study • When companies use technology such as software in process control and management, two of many possible objectives for continuous growth they have are (1) efficiency in resource utilization and productivity, and (2) an overhead amount of time and related cost in updating and managing this technology. Proper and pro-active environment on enterprise management maintains that the cost of the overhead does not supersede overall system (enterprise) efficiency.
- 19. Background of the Study • When companies use technology such as software in process control and management, two of many possible objectives for continuous growth they have are (1) efficiency in resource utilization and productivity, and (2) an overhead amount of time and related cost in updating and managing this technology. Furthermore unfortunate it may be but it is readily recognizable in companies when their software eventually becomes hindrance, sometimes the cause of paralysis, in achieving overall enterprise efficiency.
- 20. Introduction A work on software engineering by IVAR JOCOBSON describes software entropy as follows… The second law of thermodynamics, in principle, states that a closed system's disorder cannot be reduced, it can only remain unchanged or increased. A measure of this disorder is entropy.
- 21. Introduction A work on software engineering by IVAR JOCOBSON describes software entropy as follows… The second law of thermodynamics, in principle, states that a closed system's disorder cannot be reduced, it can only remain unchanged or increased. A measure of this disorder is entropy. This law also seems plausible for software systems; as a system is modified, its disorder, or entropy, always increases. This is known as software entropy.
- 22. Topic This paper proposes a quantification of software entropy in terms of measuring control structures to variables cohesion.
- 23. Introduction Within software development, there are similar theories; Lehman (1985) suggested a number of laws, of which aid in the quantification of software entropy • A computer program that is used will be modified • When a program is modified, its complexity will increase, provided that one does not actively work against this. The process of code refactoring can result in stepwise reductions in software entropy.
- 24. Introduction Within software development, there are similar theories; Lehman (1985) suggested a number of laws, of which aid in the quantification of software entropy • A computer program that is used will be modified • When a program is modified, its complexity will increase, provided that one does not actively work against this. The process of code refactoring can result in stepwise reductions in software entropy. Topic This paper proposes a quantification of software entropy in terms of measuring control structures to variables cohesion.
- 25. Cohesion • is the measure of the strength of functional association of elements within a procedure We strive for the highest possible cohesion – i.e. make elements of a procedure as strongly related to one another as possible source
- 26. Why High Cohesion • High cohesion usually means low coupling – the degree to which each program module relies on each other • It insures that the functional breakdown of the program reflects the functional organization of the original problem • High cohesion has been shown to be a good predictor of maintainability
- 27. Correlations this study traces
- 28. Correlations this study traces
- 29. Correlations this study traces
- 30. Correlations this study traces
- 31. Correlations this study traces Thermodynamics – Closed System
- 32. Topics Covered • Rationalization for quantification of software entropy • Related studies and researches on quantification of software entropy – Chidamber and Kemerer 1991 , Quantifying Methods Complexity by introducing Cyclomatic Complexity – Chidamber and Kemerer 1994, Lack of Cohesion of Methods (LCOM) – Beiman and Ott 1994, examined functional cohesion of procedures using data slice abstraction – Derived measurements from these study is Yourdon and Constantine’s • Strong Functional Cohesion (SFC) • Weak Functional Cohesion (WFC) – Beiman and Kang 1997, introduced Measuring Design-Level Cohesion by using association-based and sliced-based approaches • Code-level Cohesion Measurement A CONTROL STRUCTURE-TOKEN-BASED METRIC FOR SOFTWARE FUNCTIONAL COHESION, ENTROPY AND RE-ENGINEERING My Paper
- 33. METHODOLOGY Enhancement of Existing Works
- 34. Related Works • As a related study, the Measuring Design-Level Cohesion of Beiman and Kang showed that an analytical and empirical analysis on the design level measurement corresponded closely with the code-level cohesion measurement. • Therefore Input Output Dependence Graph (IODG) which was adapted from Lakhotia’s variable dependence graph defined the relationship between input and output components of a module causal to cohesion measurement.
- 35. Related Works • Aside from deriving calculation for cohesion, Steven, Myers, and Constantine introduced module cohesion (SMC Cohesion) that is measurement of cohesiveness represented on an ordinal scale approach • In this study modules are categorized among – Coincidental cohesion – Logical cohesion – Temporal cohesion – Procedural cohesion – Communicational cohesion – Sequential cohesion – Functional cohesion • Thus stating coincidental cohesion regarded as the weakest and functional cohesion the strongest cohesion
- 36. SMC Ordinal Types of Cohesion
- 37. The Objective • The contribution of this study, therefore, focuses on building a metric to enhance the real world implementation of sound engineering theories and practices by formulating and quantitatively measuring the concept known as Software Entropy by measuring control structures to variables cohesion.
- 38. The Objective •This aims to help software designers, developers, and system managers to pinpoint when their update in LOCs causes entropy to the stability and robustness of their current software.
- 39. The Objective •This could also help in rationalizing software update, partial or total re-engineering and /or migration.
- 40. The Methodology • This study will run both the IODG methods and the SMC ordinal cohesion scale but – Unlike IODG that accounts Input and Output variables only – Unlike Data Slices approach that accounts all variables only • This research will consider all variables and control structures in a module in computing cohesion
- 41. The Methodology • Then the computed cohesion will be compared against the SMC ordinal cohesion scale to determine the COHESION METRIC
- 42. Visualization
- 43. Visualization
- 44. CONTROL STRUCTURE – TOKEN DEPENDENCIES
- 45. Definition of Terms • Token Let component y be a variable or a constant, • Control Structure Let control structure c be either if, while or do-while,
- 46. ALGORITHMS NINE (9) DATA DEFINITIONS
- 47. Data Definition
- 48. Data Definition
- 49. Data Definition
- 50. Data Definition
- 51. Data Definition
- 52. CONTROL STRUCTURE – TOKEN DEPENDENCE GRAPH CSTDG
- 53. CSTDG
- 56. Data Slice Profile for IF
- 57. Data Slice Profile for IF • Functional Cohesion is measured based from the procedure output and the components of the procedure that contribute to the said output.
- 58. Data Slice Profile for IF • Using this approach, it is ensured that maximum functional cohesiveness is achieved. • For the cases of multiple outputs in a procedure, each components contributing to different outputs will be considered together with how they are bound.
- 59. Results and Findings • To apply the Data Slice Abstraction, the above table shows several data tokens contributing to a data slice, which is the Output z • and where data tokens are the components or the statements in the above tables.
- 61. Table below shows Glueness of the data token for IF procedure
- 62. Data Slice Profile for WHILE
- 63. Data Slice Profile for DO WHILE
- 64. Conclusions • Clearly, by incorporating these 9 types of relationships among control structures and tokens, we augment the information we can derive regarding the cohesiveness of the elements within a module m. • However, knowing when and how to refactor codes is an issue of the skill of the designer and/or programmer to discern. • This paper would measure cohesion within a procedure and compare it to the SMC Cohesion ordinal scale. • However entire code should undergo repetitive computation to really see the exact SMC Cohesion level.
- 65. Future Works • Automation of the computation of the functional cohesion • An Assembly-Level Procedural Cohesion (Hardware)
- 66. Acknowledgements This research work is a result of the partnership of the University of the Philippines Information Technology Development Center (UP ITDC) and Fujitsu Ten Limited represented by Fujitsu Ten Solutions Philippines, Inc.
- 67. References