Case tools


Published on

Anna University, Final CSE, Software Quality Management

Published in: Education, Technology, Business
1 Comment
  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Case tools

  1. 1. Software Quality Management Unit – 3 G. Roy Antony Arnold y y Asst. Professor / CSE  GRAA
  2. 2. • Computer‐Aided Software Engineering (CASE) Computer Aided Software Engineering (CASE)  is the scientific application of a set of tools  and methods to a software system which is  and methods to a software system which is meant to result in high‐quality, defect‐free,  and maintainable software products. and maintainable software products• CASE tools automate methods for designing,  documenting, and producing structured  documenting and producing structured computer code in the desired programming  language. GRAA
  3. 3. • Architecture Management – Model, design, and rapidly build Software, Systems, and  Computer Application Programs.• Change and Release Management Change and Release Management – Improve software delivery and lifecycle  traceability, from  requirements through deployment. requirements through deployment• Software Development Management – Align projects for improved productivity and predictability Align projects for improved productivity and predictability.• Quality Management – Ensure software functionality, reliability and performance Ensure software functionality, reliability and performance  throughout development and production. GRAA
  4. 4. • CASE software supports the software process  activities such as requirement engineering,  design, program development and testing. • Therefore, CASE tools include design editors,  data dictionaries, compilers, debuggers, system  building tools, etc.• The term CASE was originally coined by software  g y y company Nastec Corporation of Southfield,  Michigan in 1982 with their original integrated  g g g graphics and text editor GraphiText GRAA
  5. 5. • Supply basic functionality, do routine tasks  pp y y, automatically – Be able to support editing of code in the particular  programming language, supply refactoring tools• Enhance productivity – Generate code pieces automatically• Increase software quality• Intuitive use g• Integration with other tools – For example, code editor works with code repository
  6. 6. GRAA
  7. 7. • They classified as Upper, Lower and Integrated CASE tools.• Upper CASE Tools support strategic planning and construction of concept‐level products and ignore the design aspect, such as ER diagrams, Data flow diagram, Structure charts, Decision Trees, Decision tables, etc. E.g. Excelerator• L Lower CAS Tools concentrate on the b k end activities of CASE l h back d i ii f the software life cycle, such as physical design, debugging, construction, testing, construction testing component integration maintenance integration, maintenance, reengineering and reverse engineering. E.g. Telon• Integrated CASE Tools aim to support the whole development cycle. E.g. IEF (Information Engineering Facility) GRAA
  8. 8. Requirement  Operation &  System Design Coding Testing Analysis MaintenanceIntegrated CASE Tools (ICASE)e.g. IEFUpper CASE / Front End Lower CASE / Back Ende.g. Excelerator e.g. TelonUpper CASE Mid CASE Lower CASE / Back End GRAA
  9. 9. • It is also called as front end CASE Tools It is also called as front end CASE Tools• They assist in requirement analysis & design• They may be tied to a specific methodology or  may allow the use of the user s own  may allow the use of the user’s own methodology.• E Example: l• These tools are associated with analysis and  y design methodologies such as SAM or SSADM GRAA
  10. 10. • The typical responsibilities of an UpperCASE Tool are to  support the following tasks: – Requirement Analysis: • Application Visioning Application Visioning • Requirements Reuse • Requirements Identification • Requirements Analysis R i A l i • Requirements Specification – Design: g • Design Production • Design Refactoring • Design Reuse Design Reuse • Design Documentation GRAA
  11. 11. • These tools are concerned with the These tools are concerned  with the  implementation stages of the lifecycle,  typically coding, testing and documentation. typically coding testing and documentation• They aim to increase the reliability,  adaptability and productivity of the delivered  code.• 4GLs may be considered as back‐end CASE  Tools, such as Telon. T l h T l GRAA
  12. 12. • The typical responsibilities of a LowerCASE Tool is  The typical responsibilities of a owerCAS Tool is to support the performance of the following  tasks:  – Implementation:  • Implementation Reuse • Programming • Debugging – Integration Tasks:  • Integration Planning • C Component Integration tI t ti • Integration Reporting GRAA
  13. 13. • Aim to support the whole development cycle Aim to support the whole development cycle  and are linked to specific methodologies.• They are often complex and expensive but They are often complex and expensive, but  offer the developer the greatest integrity of all  approaches through the use of a single data  approaches through the use of a single data encyclopaedia throughout the lifecycle. • Example: IEF (Information Engineering  ( f Facility), IEW (Information Engineering  Workbench) GRAA
  14. 14. • Help standardization of notations and diagrams  p g• Productivity increases• Help communication between development team Help communication between development team  members• Automates the methodology – this improves  gy p consistency, but restricts creativity.• Reduction of time and effort• Automated tools are provided to prepare  documentation• Complexity of maintenance decreases. GRAA
  15. 15. • Cost Increases: Costs for purchase + training Cost Increases: Costs for purchase + training• Expertise needed• Training issues• Not mapping to current methods or applications.• May lead to restriction to the tool’s p capabilities• Limitations in flexibility of documentation
  16. 16. • Common CASE risks and associated controls Common CASE risks and associated controls  include: –I d Inadequate standardization d di i – Unrealistic expectations – Slow implementation – Weak repository controls Weak repository controls GRAA