Scope of software engineering

3,679 views
3,454 views

Published on

Published in: Software, Technology, Business
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,679
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
78
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide
  • Short for commercial off-the-shelf, an adjective that describes software or hardware products that are ready-made and available for sale to the general public
  • Scope of software engineering

    1. 1. Scope of Software Engineering
    2. 2. Muhammad Naveed Zafar Educational Background BS in Computer Science (Bahria University) MS in Software Project Management (FAST University)* Professional Experience Project Manager (NevTech) Faculty Member (Aptech MSG) Project Coordinator AMI Software Engineer GoSafe Systems
    3. 3. Agenda  What, Why and Aspects of Software Engineering ?  Horror Software Failure Stories  Software Engineer Line of Actions  Software Engineering Stakeholders  Engineering Approach  Roles and Members of Development Team  Problem Solving Paradigms  SDLC Models  Best Practices to be Adopt  Scrum Methodologies
    4. 4. What is software? • Computer programs and associated documentation • Software products may be developed for a particular customer or may be developed for a general market • Software products may be – Generic/COTS - developed to be sold to a range of different customers – Custom- developed for a customer according to their specification
    5. 5. What is Engineering? • Engineering is … – The application of scientific principles and methods to the construction of useful structures. Examples: – Mechanical engineering – Computer engineering – Civil engineering – Chemical engineering – Electrical engineering – Nuclear engineering – Aeronautical engineering
    6. 6. What Actually “Software Engineering”? • A discipline whose aim in the production of software that – meets the client‟s needs – fault-free – delivered on time – delivered within budget – easy to modify
    7. 7. Why the need for Software Engineering? Software Crisis: Unacceptable low quality of software, exceeds deadline and budget. Canceled, 23% Successful, 28% *Completed with Faults, 49% *Completed late, over budget, and/or with features missing
    8. 8. Why Software Engineering ? • The problem is complexity • Many sources, but size is a key: – Mozilla contains 3 Million lines of code – UNIX contains 4 million lines of code – Windows 2000 contains 108 lines of code • Second is roles define • Third is uncertainty of “inputs” and their timing • Fourth is the continuing changing “environment” and demands. Software engineering is about managing all the sources of complexity to produce effective software.
    9. 9. Software Engineering Aspects • Historical Aspects: – , a NATO group coined the term “Software Engineering” – NATO Software Engineering Conference concurred that “Software production should be an engineering-like activity” – Using philosophies and paradigms of established engineering disciplines to solve Software Crisis that the quality of software was generally unacceptably low and that deadlines and cost limits were not being met”
    10. 10. • Economic Aspects – Software Engineering v.s. Computer Science • The computer scientist investigates several ways to produce software, some good and some bad • But the software engineer is interested in only those techniques that make sound economic sense. For example: A coding technique that can execute very efficiently but with higher maintenance cost may not be a good choice, since maintenance occupies a lot of resources of the whole life cycle. Software Engineering Aspects…
    11. 11. • Maintenance Aspects – Software Life Cycle / Software Process • Requirements Phase • Specification (Analysis) Phase • Planning Phase • Design Phase • Implementation Phase • Integration Phase • Maintenance Phase highest cost among all these phases) • Retirement Software Engineering Aspects…
    12. 12. Requirement 2% Specification 4% Planning 1% Design 6% Module Coding 5% Module Testing 7% Integration 8% Maintenance 67% Maintenance Aspects Maintenance Approximate relative costs of the phases of the software life cycle. Maintenance is so important that a major aspect of software engineering consists of techniques, tools, and practices that lead to a reduction in maintenance cost
    13. 13. Horror Software Failure Stories • Patients died as a consequence of severe overdoses of radiation. • US Treasury Department mailed incorrectly printed Social Security Checks. • Interest miscalculated on student loans resulting in higher monthly payments. • Mars Climate Orbiter spacecraft crashes into the surface of Mars because of measurement conversion error. Consequences of software failures range from inconvenience to death!
    14. 14. Software Engineer Line of Actions Software Engineers should – adopt a systematic and organised approach to all aspects of software development. – use appropriate tools and techniques depending on • the problem to be solved, • the development constraints and • the resources available – Understand and communicate processes for improved software development within their organization – Be effective team members and/or leaders. – Can be very technical or more managerial depending on organizational need.
    15. 15. Where Does the Software Engineer Fit In? • Computer Science: focusing on computer hardware, compilers, operating systems, and programming languages • Software Engineering: a discipline that uses computer and software technologies as a problem-solving tools
    16. 16. Where Does the SW Engineer Fit in?... Relationship between Computer Science and Software Engineering
    17. 17. Qualities of Good Software? • Good software engineering must always include a strategy for producing quality software • Three ways of considering quality – The quality of the product – The quality of the process – The quality of the product in the context of the business environment
    18. 18. Who Does Software Engineering? • Customer: the company, organization, or person who pays for the software system • Developer: the company, organization, or person who is building the software system • User: the person or people who will actually use the system
    19. 19. Who Does Software Engineering? (continued) Participants (stakeholders) in a software development project
    20. 20. Engineering Approach Building a System • Requirement analysis and definition • System design • Program design • Writing the programs • Unit testing • Integration testing • System testing • System delivery • Maintenance
    21. 21. Members of the Development Team • Requirement Analysts: work with the customers to identify and document the requirements • Designers: generate a system-level description of what the system us supposed to do • Programmers: write lines of code to implement the design • Testers: catch faults • Trainers: show users how to use the system • Maintenance Team: fix faults that show up later • Librarians: prepare and store documents such as software requirements • Configuration Management Team: maintain correspondence among various artefacts.
    22. 22. Members of the Development Team (continued) Typical roles played by the members of a development team
    23. 23. Secrets of Successful Projects
    24. 24. Problem Solving Paradigms  Several techniques have been suggested to help solve the software crisis – ~ - : Structured Paradigm • Structured Systems Analysis, Composite/Structured Design, Structured Programming, Structured Testing • Lead to major improvements for software industry • But only good for small programs (say, , - , lines of codes) • Not so good in software maintenance aspects, (for instance, because of the separation of action-oriented and data-oriented in structured paradigm) – Object-Oriented Paradigm • An object is a unified software component that incorporates both data and actions that operate of those data --> More Promising!
    25. 25. Why use Object Oriented Paradigm? • Classical Structured Paradigm – Focus on functions of system • Object-Oriented Paradigm – Focus on objects – Implementation details are local to the object • Regression fault (fault produced by seeming unrelated change) is greatly reduced. – Encapsulation: well-designed independent units – Potential Reuse of objects reduces time and cost
    26. 26. The Software Process • A structured set of activities required to develop a software system – Specification; – Design; – Validation; – Evolution. • A software process model is an abstract representation of a process. • It presents a description of a process from some particular perspective.
    27. 27. Waterfall Model System Engineering Analysis Design Code Testing Maintenance
    28. 28. Waterfall Model Characteristics • The classic life cycle - oldest and most widely used paradigm • Activities „flow‟ from one phase to another • If there are corrections, return to a previous phase and „flow‟ from there again • Major advantages: Good for planning and well defined/repeated projects
    29. 29. Problems of Waterfall Model • Real projects often follow the sequence • All requirements may not be stated explicitly by customer • Customer only sees the results after some time • Developers are often delayed at certain phases
    30. 30. Rapid Application Development (RAD) Business Modeling Data Modeling Process Modeling Application Generation Testing & Turnover Team #1 Business Modeling Data Modeling Process Modeling Application Generation Testing & Turnover Team #2 Time period
    31. 31. RAD Characteristics • “High-speed” version of waterfall model • Primarily for information systems applications • Requirements well-understood, fully functional system produced in short time • The application modularized - major functions can be completed in 3 months • Separate teams complete the functions, then integrated as a whole • Requires human resource and commitment
    32. 32. Scrum Agile Methodologies
    33. 33. Importance of Continual Planning, Testing, Documentation • After customer has signed off on the specifications, continue to monitor and adjust plan. • Software must be fault-free as possible at all times. • At all times, documentation must be complete, correct and up-to-date. – personnel overturn – incomplete implementation – inaccurate testing – impossible to maintain
    34. 34. Conclusion • Tips to Solve a problem – Analyse Problems – Synthesize a solution • Understand that requirements may change • Must view quality from several different perspectives • Use fundamental software engineering concepts • Keep system boundary in mind
    35. 35. Thank you

    ×