want to contact me login to www.stqa.org


Published on

Published in: Technology
  • Be the first to 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
  • want to contact me login to www.stqa.org

    2. 2. <ul><li>Objectives </li></ul><ul><li>Have a basic understanding of the origins of Software development, in particular the problems faced in the Software Crisis </li></ul><ul><li>Knowledge of the concepts of Software Engineering </li></ul><ul><li>Definition of Software Engineering, and the desired Software Characteristics </li></ul><ul><li>The paradigms. For each paradigm, know the associated diagram, description of the steps involved in it </li></ul><ul><li>Ability to read a given scenario and recommend with justification the paradigm for it </li></ul><ul><li>Ability to identify the continually changing nature of software development </li></ul>
    3. 3. The emergence of software engineering The early years (50-60) Second Era (60-Mid70s) Third Era (70-mid80) Fourth Era (80's and beyond) Batch orientation The system handles the job at once in sequence Multiprogramming and Multi - User Systems. Personal Computers came to be widely used. Increased use of desktop systems Limited Distribution Computers were not widely used. Software become distributed - this was the start of the software crisis. Micro Computers also were used in other products   Object Oriented Technologies They were highly customized - they were produced only to meet specific needs.   Therefore there was a greater need for software Expert System AI Parallel Computing Software Crisis
    4. 4. The emergence of software engineering <ul><li>The task description and the requirements frequently change even during the program design phase, and continue to change even after the software system has long since been in use. </li></ul>
    5. 5. The major problems <ul><li>Correctness </li></ul><ul><li>Efficiency </li></ul><ul><li>Mastery of Complexity </li></ul><ul><li>Interface specification </li></ul><ul><li>Reliability     </li></ul><ul><li>Flexibility </li></ul><ul><li>Documentation </li></ul><ul><li>Maintainability </li></ul><ul><li>Project organization. </li></ul>
    6. 6. DEFINITION OF SOFTWARE <ul><li>Instructions (computer programs) on execution provide desired function and performance </li></ul><ul><li>  Data structures that enable programs to adequately manipulate information </li></ul><ul><li>  Documents that describes the operation and use of the programs </li></ul>
    7. 7. Software and Hardware <ul><li>When hardware is built the human creative process (Analysis, Design, Construction, testing) is ultimately transferred into a physical form </li></ul><ul><li>  Software is logical rather than physical system element. </li></ul><ul><li>Software is engineered (or developed) – it is not manufactured. </li></ul><ul><li>Software does not wear out. </li></ul>
    8. 8. Software Applications. <ul><li>Software may be applied in any situation for which a set of procedural – steps (algorithm) has been defined. </li></ul><ul><li>Information content and determinacy are important factions in determining the nature of software application. </li></ul><ul><li>Content refers to the meaning and form of incoming and outgoing information. </li></ul><ul><li>Information determinacy refers to the predictability of the order of timing of information. </li></ul>
    9. 9. Software Engineering paradigms. <ul><li>Software Engineering is the technological, managerial discipline concerned with systematic production and maintenance of software products that are developed and modified one time. </li></ul><ul><li>The primary goals of software engineering are to improve the quality of software products and to increase the productivity and job satisfaction of persons involved. </li></ul><ul><li>Software Engineering being labor-intensive activity, requires both technical and managerial control. </li></ul>
    10. 10. Software Engineering paradigms. <ul><li>In very real sense , the software engineer creates models of physical situation in software. The mapping between model and reality being modeled – has been called intellectual distance between problem and computerized solution. The fundamental principle of software engineering is to design software products that minimize the intellectual distance between problem and solution. </li></ul>
    11. 11. Software Engineering paradigms <ul><li>Software engineering is layered technology – An approach that must rest on organizational commitment to quality. </li></ul><ul><li>The layers are </li></ul><ul><ul><ul><li>Tools </li></ul></ul></ul><ul><ul><ul><li>Methods </li></ul></ul></ul><ul><ul><ul><li>Process </li></ul></ul></ul><ul><ul><ul><li>A quality focus </li></ul></ul></ul>
    12. 12. <ul><li>The bedrock that supports software engineering is a quality focus. </li></ul><ul><li>The foundation for Software Engineering is the process layer. </li></ul><ul><li>Software Engineering methods provides the technical know how-to for building software. </li></ul><ul><li>Software Engineering Tools provide automated or semi automated support for the – process and methods.   </li></ul>
    13. 13. Generic Phases <ul><li>1.     Formal technical reviews </li></ul><ul><li>2.     Software QA </li></ul><ul><li>3.     Software Configuration Management. </li></ul><ul><li>4.     Document preparation & production </li></ul><ul><li>5.     Reusability management </li></ul><ul><li>6.     Measurement </li></ul><ul><li>7.     Risk Management. </li></ul>
    14. 14. Software Development Life Cycle <ul><li>Classic life cycle suggests a systematic , sequential approach that begins at system level and progresses through </li></ul><ul><ul><ul><li>Analysis </li></ul></ul></ul><ul><ul><ul><li>Design </li></ul></ul></ul><ul><ul><ul><li>Verification and Validation </li></ul></ul></ul><ul><ul><ul><li>Support. </li></ul></ul></ul>
    15. 15. Software Development Life Cycle <ul><li>Specification Phase </li></ul><ul><li>Object-Oriented Analysis Phase </li></ul><ul><li>Design Phase </li></ul><ul><li>Implementation Phase </li></ul><ul><li>Implementation and Integration Phase </li></ul><ul><li>Maintenance Phase </li></ul>
    16. 16. Software requirement Analysis <ul><li>Focused specially on software </li></ul><ul><li>Analyst must understand the information domain to understand the nature of programs to be developed. </li></ul><ul><li>The requirements for system and software are to be documented and reviewed by the customer. </li></ul>
    17. 17. Software Design <ul><li>Software Design is a multi step process focuses on four distinct attributes of a program. </li></ul><ul><ul><ul><li>Data Structure </li></ul></ul></ul><ul><ul><ul><li>Software architecture </li></ul></ul></ul><ul><ul><ul><li>Interface representation </li></ul></ul></ul><ul><ul><ul><li>Procedural logic </li></ul></ul></ul>
    18. 18. Code Generation <ul><li>Design is translated into machine readable form. </li></ul><ul><li>Can be automated </li></ul>
    19. 19. Testing <ul><li>Code Testing </li></ul><ul><li>Specification testing </li></ul><ul><li>Uncovers errors </li></ul>
    20. 20. Support <ul><li>Software may undergo change after delivery due to errors. </li></ul><ul><li>Software must be adaptable to new environment </li></ul><ul><li>Due to functional or performance enhance suggested by customer </li></ul>
    21. 21. Project size categories <ul><li>Based on level of management control and types of tools and techniques </li></ul>
    22. 22. Trivial project <ul><li>One programmer working, sometimes part time for few days, for exclusive use. </li></ul><ul><li>  Less than 500 statements & 10 - 20 sub routines.  </li></ul><ul><li>Eg. PC Software, a little need for analysis documentation </li></ul><ul><li>No Extensive test planning essential.  </li></ul>
    23. 23. Small Projects <ul><ul><li>1 - 6 months effort of 1 programmer. </li></ul></ul><ul><ul><li>1000 - 2000 lines of code.25 - 50 sub routines </li></ul></ul><ul><ul><li>Less interaction between programmers </li></ul></ul><ul><ul><li>Scientific calculations for engineering on small </li></ul></ul><ul><ul><li>Commercial applications </li></ul></ul><ul><ul><li>Little interaction between customers and developers. </li></ul></ul>
    24. 24. Medium Size Projects <ul><li>2 - 5 Programmer’s team. </li></ul><ul><li>1- 2 years </li></ul><ul><li>10,000 – 50,000 lines </li></ul><ul><li>250 - 1000 routines </li></ul><ul><li>medium project size </li></ul>
    25. 25. Large Projects <ul><li>5 - 20 programmer’s team </li></ul><ul><li>2 - 3 years duration </li></ul><ul><li>50,000 to 1,00,000 lines of code </li></ul><ul><li>Package in several system </li></ul><ul><li>Eg. Large compilers </li></ul>
    26. 26. Very large Projects <ul><li>100 - 1000 programmers </li></ul><ul><li>4 - 5 years </li></ul><ul><li>1 million source instructions </li></ul><ul><li>Consists of several major sub systems </li></ul><ul><li>0S/360 – 5000 programmers worked for 5 years </li></ul>
    27. 27. Extremely large projects <ul><li>2000 - 5000 Programmers </li></ul><ul><li>duration up to 10 years </li></ul><ul><li>100 million lines of code </li></ul><ul><li>Often distributed processing, Multitasking </li></ul><ul><li>Requires high reliability </li></ul><ul><li>Eg. Telecomm ,defense, air traffic control </li></ul>
    28. 28. Problems in Software Engineering <ul><li>Potential business problems or occurrences that may cause the project </li></ul><ul><li>Potential project problems or occurrences that may cause the project </li></ul><ul><li>Technical problems or occurrences that may cause the project </li></ul><ul><li>Conform to changes in its external environment analysis </li></ul>
    29. 29. Software Productivity factors <ul><li>Individual ability </li></ul><ul><li>Team communication </li></ul><ul><li>Product complexity </li></ul><ul><li>Appropriate notations </li></ul><ul><li>Systematic approaches </li></ul><ul><li>Change control </li></ul><ul><li>Level of technology </li></ul><ul><li>Required reliability </li></ul>
    30. 30. Software Productivity factors <ul><li>Available time </li></ul><ul><li>Problem understanding </li></ul><ul><li>Stability of requirements </li></ul><ul><li>Facilities and resources </li></ul><ul><li>Management skills </li></ul><ul><li>Appropriate goals </li></ul><ul><li>Rising expectations </li></ul>
    31. 31. Project Structure <ul><li>Project format. </li></ul><ul><li>Use of a project format involves assembling a team of programmers who conduct a project from start to finish; project team members do product definition, design the product, implement it, test it, conduct project reviews, and prepare the supporting documents. </li></ul>
    32. 32. Project Structure <ul><li>Functional format. </li></ul><ul><li>In the functional approach to organization, a different team of programmers performs each phase of the project, and the work products pass from team to team as they evolve. </li></ul>
    33. 33. Project Structure <ul><li>Matrix format. </li></ul><ul><li> In matrix organizations, each of the functions described above has its own management team and a group of specialist personnel who are concerned only with that function </li></ul>