01 fse software&sw-engineering


Published on

Published in: Education
  • 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

01 fse software&sw-engineering

  1. 1. B. Computer Sci. (SE) (Hons.) CSEB233: Fundamentals of Software Engineering Software & Software Engineering
  2. 2. Lesson Objectives  Define  ‗Software‘ Discuss issues related to Software  Define ‗Software Engineering‘ (SE)  Describe Polya‘s Four Essence of SE Practices  Explain Hooker‘s Seven SE Principles  Discuss several myths of SE
  3. 3. Software & Software Engineering What is Software?
  4. 4. What is Software?  Software is developed or engineered, it is not manufactured in the classical sense  Software does not "wear out"  Although the industry is moving toward component-based construction, most software continues to be custom-built
  5. 5. Wear vs. Deterioration
  6. 6. Software Applications  System software  Application software  Engineering/scientific software  Embedded software  Product-line software  WebApps (Web applications)  AI software
  7. 7. Software — New Categories  Open world computing   pervasive, distributed computing   wireless networks Netsourcing the Web as a computing engine Open source  Ubiquitous computing     ―free‖ source code open to the computing community a blessing, but also a potential curse! Also     Data mining Grid computing Cognitive machines Software for nanotechnologies
  8. 8. Legacy Software  Why     must it change? Software must be adapted to meet the needs of new computing environments or technology Software must be enhanced to implement new business requirements Software must be extended to make it interoperable with other more modern systems or databases Software must be re-architected to make it viable within a network environment
  9. 9. Characteristics of WebApps - I  Network Intensiveness   Concurrency   A large number of users may access the WebApp at one time Unpredictable load   A WebApp resides on a network and must serve the needs of a diverse community of clients The number of users of the WebApp may vary by orders of magnitude from day to day Performance  If a WebApp user must wait too long (for access, for serverside processing, for client-side formatting and display), he or she may decide to go elsewhere
  10. 10. Characteristics of WebApps - II  Availability   Data driven   The primary function of many WebApps is to use hypermedia to present text, graphics, audio, and video content to the end-user. Content sensitive   Although expectation of 100 percent availability is unreasonable, users of popular WebApps often demand access on a ―24/7/365‖ basis. The quality and aesthetic nature of content remains an important determinant of the quality of a WebApp. Continuous evolution  Unlike conventional application software that evolves over a series of planned, chronologically-spaced releases, Web applications evolve continuously.
  11. 11. Characteristics of WebApps - III  Immediacy   Security   Although immediacy—the compelling need to get software to market quickly—is a characteristic of many application domains, WebApps often exhibit a time to market that can be a matter of a few days or weeks Because WebApps are available via network access, it is difficult, if not impossible, to limit the population of end-users who may access the application Aesthetics  An undeniable part of the appeal of a WebApp is its look and feel
  12. 12. Software & Software Engineering What is Software Engineering?
  13. 13. Software Engineering  Some     realities: a concerted effort should be made to understand the problem before a software solution is developed design becomes a pivotal activity software should exhibit high quality software should be maintainable
  14. 14. Software Engineering The Seminal Definition  Software  engineering is The establishment and use of sound engineering principles in order to obtain economically, software that is reliable and works efficiently on real machines
  15. 15. Software Engineering The IEEE Definition  Software   Engineering The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software The study of approaches as described above
  16. 16. A Layered Technology tools methods process model a “quality” focus Software Engineering
  17. 17. A Process Framework  Framework     activities work tasks work products milestones & deliverables QA checkpoints  Umbrella Activities
  18. 18. Framework Activities Communication  Planning  Modeling     Construction    Analysis of requirements Design Code generation Testing Deployment
  19. 19. Umbrella Activities  Software project management  Formal technical reviews  Software quality assurance  Software configuration management  Work product preparation and production  Reusability management  Measurement  Risk management
  20. 20. Adapting a Process Model the overall flow of activities, actions, and tasks and the interdependencies among them  the degree to which actions and tasks are defined within each framework activity  the degree to which work products are identified and required  the manner which quality assurance activities are applied  the manner in which project tracking and control activities are applied 
  21. 21. Adapting a Process Model  the overall degree of detail and rigor with which the process is described  the degree to which the customer and other stakeholders are involved with the project  the level of autonomy given to the software team  the degree to which team organization and roles are prescribed
  22. 22. Software & Software Engineering Four Essence of SE Practices
  23. 23. The Essence of SE Practices  Polya     suggests: Understand the problem ♦ communication and analysis Plan a solution ♦ modeling and software design Carry out the plan ♦ code generation Examine the result for accuracy ♦ testing and quality assurance
  24. 24. The Essence of SE Practices 1. Understand the Problem  Who has a stake in the solution to the problem?   What are the unknowns?   What data, functions, and features are required to properly solve the problem? Can the problem be compartmentalized?   Who are the stakeholders? Is it possible to represent smaller problems that may be easier to understand? Can the problem be represented graphically?  Can an analysis model be created?
  25. 25. The Essence of SE Practices 2. Plan the Solution  Have you seen similar problems before?    Has a similar problem been solved?   If so, are elements of the solution reusable? Can sub-problems be defined?   Are there patterns that are recognizable in a potential solution? Is there existing software that implements the data, functions, and features that are required? If so, are solutions readily apparent for the subproblems? Can you represent a solution in a manner that leads to effective implementation?  Can a design model be created?
  26. 26. The Essence of SE Practices 3. Carry Out the Plan  Does  the solution conform to the plan? Is source code traceable to the design model?  Is each component part of the solution provably correct?  Has the design and code been reviewed, or better, have correctness proofs been applied to algorithm?
  27. 27. The Essence of SE Practices 4. Examine the Result  Is it possible to test each component part of the solution?  Has a reasonable testing strategy been implemented?  Does the solution produce results that conform to the data, functions, and features that are required?  Has the software been validated against all stakeholder requirements?
  28. 28. Software & Software Engineering Seven General Principles of SE
  29. 29. Hooker’s General Principles  The Reason It All Exists  KISS (Keep It Simple, Stupid!)  Maintain the Vision  What You Produce, Others Will Consume  Be Open to the Future  Plan Ahead for Reuse  Think!
  30. 30. Hooker’s General Principles 1. The Reason It All Exists  Software exists to provide value to its users  All decisions should be made with this in mind
  31. 31. Hooker’s General Principles 2. Keep It Simple (KISS)  There are many factors to consider in any design effort  Thus, all software design should be as simple as possible but not simpler to ease understanding and maintenance of the software
  32. 32. Hooker’s General Principles 3. Maintain the Vision A clear vision is essential to the success of a software project  Compromising the architectural vision of a software system weakens and break even well-designed systems
  33. 33. Hooker’s General Principles 4. What You Produce, Others Will Consume  Consume  use, maintain, document or depend on  Always specify, design, and implement knowing others will have to understand what you are doing
  34. 34. Hooker’s General Principles 5. Be Open to the Future  True ―industrial-strength‖ software must endure long lifetime  Hence, design the software to:    solve the general problem, not just the specific one, be ready to adapt to changes (in hardware, computing platform etc.), and be reused
  35. 35. Hooker’s General Principles 6. Plan Ahead for Reuse  Reuse reduces the cost and increases the value of the reused components and the systems into which they are incorporated
  36. 36. Hooker’s General Principles 7. Think  When you think about something (placing clear, complete thought before action), you are more likely to do it right (more importantly, the first time).
  37. 37. Software & Software Engineering Software Myths
  38. 38. Software Myths Software myths – erroneous beliefs about software and the process that is used to build it  Misleading attitudes that have caused serious problems for managers and practitioners  Classifications of software myths:     Management Customer Practitioner
  39. 39. Software Myths Management  Myth:    We already have a book that‘s full of standards and procedures for building software Won‘t that provide my people with everything they need to know? Reality:     The book of standards may exist, but is it used? Are practitioners‘ aware of its existence? Does it reflect modern SE practices? Is it complete? Is it adaptable?
  40. 40. Software Myths Customer  Myth:   Software requirements continuously change, but change can be easily accommodated because software is flexible Reality:    The impact of change varies with the time at which it is introduced The cost of impact of changes in early stage of software project is relative small However, changes introduced at a later development stage may require a lot of resources and major design modification
  41. 41. Software Myths Practitioner  Myth:  ―Once we write the program and get it work, our job is done.‖  Reality:  Somebody once said the ―the sooner you begin ‗writing the code‘, the longer it‘ll take you to get done.‖
  42. 42. How It all Starts  Every software project is precipitated by some business need     the need to correct a defect in an existing application; the need to adapt a ‗legacy system‘ to a changing business environment; the need to extend the functions and features of an existing application, or the need to create a new product, service, or system.
  43. 43. Summary Definitions of software and software engineering  Software deteriorates but never wear out  Several software application domain – system software, engineering/scientific software, AI software, embedded software, etc.  The Polya‘s Four Essence of SE Practices   Understand the problem; Plan a solution; Execute the plan; Examine the result for accuracy
  44. 44. Summary  Seven  SE Principles The Reason It All Exists; KISS; Maintain the Vision; What You Produce, Others Will Consume; Be Open to the Future; Plan Ahead for Reuse; Think!  Software myths have caused problems for the software industry serious
  45. 45. THE END Copyright © 2013 Mohd. Sharifuddin Ahmad, PhD College of Information Technology