1 / 71

Introduction to Software Engineering - A Comprehensive Guide

This resource provides an introduction to software engineering, covering topics such as the nature of software, software process, agile process models, software characteristics, and more. It includes a syllabus, relevant process models, and discusses common myths in software development.

tgarner
Télécharger la présentation

Introduction to Software Engineering - A Comprehensive Guide

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. UNIT-I Introduction to Software Engineering Prof. Prasad Mahale 8600208876 https://prasadmahale.wordpress.com/

  2. Syllabus • Nature of Software • Software Process • Software Engineering Practice • Software Myths • Generic Process model • Process Assessment and Improvement • Perspective Process Models • Specialized Process Models • Personal and Team Process Models Agile Process models: • Agile process • Extreme programming

  3. Nature of Software

  4. Defining Software • Software is: • Instructions (computer programs) that when executed provide desired features, function, and performance • Data structures that enable the programs to effectively manipulate information, and • Descriptive information in both hard copy and virtual forms that describes the operation and use of the programs.

  5. software characteristics • Software is developed or engineered; it is not manufactured in the classical sense. • Although the industry is moving toward component-based construction, most software continues to be custom built. • Software doesn’t “wear out.” But it does deteriorate!

  6. Figure 1: Failure curve for hardware Figure 1.2: Failure curves for software

  7. Software Application Domains

  8. System software

  9. Embedded software

  10. Product-line software

  11. Web applications

  12. Legacy Software • Legacy software systems . . . were developed decades ago • Continually modified to meet changes • Must be adopted • Enhance to implement

  13. THE SOFTWARE PROCESS • A process is a collection of activities, actions, and tasks that are performed when some work product is to be created. • A generic process framework for software engineering encompasses five activities: • Communication • Planning • Modeling • Construction • Deployment

  14. Communication Project Initiation

  15. Planning Scheduling Tracking Estimation

  16. Modeling

  17. Construction

  18. Deployment

  19. Umbrella activities • Software project tracking and control • Risk management • Technical reviews • Measurement • Software configuration Management • Reusability management • Work product preparation and production

  20. SOFTWARE ENGINEERING PRACTICE • The Essence of Practice • 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).

  21. Understand the problem Who Stake Solution? What Unknowns? Can Compartmentalized? Can Represent Graphically

  22. Plan a solution Have u seen similar problem? Has similar problem solved? Can sub problems defined? Can represent solution effective implementation?

  23. Carry out the plan Does solution conforms plan? Is component part achieved correct?

  24. Examine the result for accuracy Is it possible to test? Does solution produce required result?

  25. General Principles

  26. SOFTWARE MYTHS • Management myths 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? Myth: If we get behind schedule, we can add more programmers and catch up (sometimes called the “Mongolian horde” concept). Myth: If I decide to outsource the software project to a third party, I can just relax and let that firm build it.

  27. 2. Customer myths Myth: A general statement of objectives is sufficient to begin writing programs—we can fill in the details later. Myth: Software requirements continually change, but change can be easily accommodated because software is flexible.

  28. Practitioner’s myths Myth: Once we write the program and get it to work, our job is done. Myth: Until I get the program “running” I have no way of assessing its quality. Myth: The only deliverable work product for a successful project is the working program. Myth: Software engineering will make us create voluminous and unnecessary documentation and will invariably slow us down.

  29. A GENERIC PROCESS MODEL A software process framework

  30. Process flow

  31. Defining a Framework Activity • Identifying a Task Set • Process Patterns • Proven solutions • Process related problems Pattern Name: Forces: Type: Task pattern: Action & work task for s/w process (Requirement Gathering) Stage pattern: Incorporates the multiple task pattern (Communication) Phase pattern: Define the sequence of framework activity (Spiral model)

  32. PROCESS ASSESSMENT AND IMPROVEMENT • Standard CMMI Assessment Method for Process Improvement (SCAMPI) • CMM-Based Appraisal for Internal Process Improvement (CBA IPI) • SPICE (ISO/IEC15504) • ISO 9001:2000 for Software

  33. PRESCRIPTIVE PROCESS MODELS 1. The Waterfall Model

  34. Advantages of waterfall model: • This model is simple and easy to understand and use. • It is easy to manage due to the rigidity of the model – each phase has specific deliverables and a review process. • In this model phases are processed and completed one at a time. Phases do not overlap. • Waterfall model works well for smaller projects where requirements are very well understood. • Disadvantages of waterfall model: • Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage. • No working software is produced until late during the life cycle. • High amounts of risk and uncertainty. • Not a good model for complex and object-oriented projects. • Poor model for long and ongoing projects. • Not suitable for the projects where requirements are at a moderate to high risk of changing.

  35. PRESCRIPTIVE PROCESS MODELS 2. Incremental Process Models

  36. Advantages of Incremental model: • Generates working software quickly and early during the software life cycle. • This model is more flexible – less costly to change scope and requirements. • It is easier to test and debug during a smaller iteration. • In this model customer can respond to each built. • Lowers initial delivery cost. • Easier to manage risk because risky pieces are identified and handled during it’d iteration. Disadvantages of Incremental model: • Needs good planning and design. • Needs a clear and complete definition of the whole system before it can be broken down and built incrementally. • Total cost is higher than waterfall.

  37. PRESCRIPTIVE PROCESS MODELS • Evolutionary Process Models • Prototyping

  38. PRESCRIPTIVE PROCESS MODELS II. The Spiral Model

More Related