ppt_se.bdfhrfykjyftiktgdukhydiyiuoyu8otrfu
- 2. UNIT I - INTRODUCTION • Software Engineering paradigms – Waterfall Life cycle model – Spiral Model – Prototype Model – Fourth Generation Techniques – Planning – Software Project – Requirements – Risk analysis and and Scheduling, management Specification
- 3. UNIT II - SOFTWARE DESIGN • Abstraction – Modularity – Software Architecture – Cohesion – Coupling – Various Design Concepts and notations – Real time and Distributed System Design – Documentation – Dataflow Oriented design – Jackson System development – Designing for reuse – Programming standards – Case Study for Design of any Application Project.
- 4. UNIT III - SOFTWARE TESTINGAND MAINTENANCE • Software Testing Fundamentals – Software testing strategies – Black Box Testing – White Box Testing – System Testing – Object Orientation Testing – State based Testing - Testing Tools – Test Case Management – Software Maintenance Organization – Maintenance Report – Types of Maintenance
- 5. UNIY IV - SOFTWARE METRICS • Scope – Classification of metrics – Measuring Process and Product attributes – Direct and Indirect measures – Cost Estimation - Reliability – Software Quality Assurance – Standards – COCOMO model.
- 6. UNIT V - SCM • Need for SCM – Version Control – SCM process – Software Configuration Items – Taxonomy – CASE Repository – Features – Web Engineering
- 7. UNIT I - INTRODUCTION: • Software is more than just a program code. • A program is an executable code, which servers some computational purpose. • Software is the collection of computer programs, procedures rules and associated documentation and data. • Software is an information transformer- producing, managing, modifying, displaying or transforming information that can simple as a single bit or a complex as a multimedia application.
- 8. Software Products: • Software products may be developed for a particular customer or may be developed for a general market. • Software products may be: • Generic • Bespoke • What are the attributes of good software? • Maintainability. • Dependability • Efficiency • Usability
- 9. What is the difference between software engineering and computer science?
- 10. Software Engineering Paradigms: Software Characteristics: • Software is developed or engineered, it is not manufactured in the classical sence. • Software doesn’t “wear out”. • Although the industry is moving towards component based assembly, most software continues to be custom to built.
- 12. Software Applications Types: • System Software. • Real-time Software. • Business Software. • Engineering and Scientific Software. • Embedded Software. • Personal Computer Software. • Web-based Software. • Artifical Intelligence Software.
- 13. Software Engineering -A layered Technology: • Application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software that is, the application of engineering software.
- 14. What are the five generic process framework activities? • The following generic process framework is applicable to the majority of software projects. • Communication. • Planning. • Modeling. • Construction. • Deployment.
- 15. Process Models: • Every software engineering organization should describe a unique set of framework activities for the software process it adopts. • Waterfall Life Cycle Model. • Iterative Waterfall Life Cycle Model. • Prototyping Model. • Incremental Model. • Sprial Model. • RAD Model. • Sprial Model.
- 16. Waterfall Life Cycle Model. • It is called classic life cycle or Linear model. • Requirements are well defined and stable. • It suggests a systematic, sequential approach to software development. • It begins with customer specification of requirements and progresses. • Planning. • Modeling. • Construction and • Deployment.
- 18. Advantages: • Easy to understand. • Each phase has well defined input and output. • Helps project manger in proper planning of project. • Provides a templates into which methods of analysis, design, code and support can be placed. Disadvantages: • One way street. • It lack overlapping and interactions among support delivery of system in phases. • Model doesn’t pieces.
- 19. Phases of the Classical Waterfall Model:
- 20. Feasibility Study: • It involves analysis of the problem and collection of allrelevant information relating to the product. • The collected data are analysed. – Requriments of the Customer. – Formulations of the different strategies for solving the problem. – Evaluation of different solution strategies. Requriments Analysis and Specification: • It is understand the exact requriments of the customer and to document them properly. – Requirements gathering and analysis. – Requirements specification.
- 21. Design: • The deign phase is to transform the requirements specified in the document into a structure that is suitable for implementation in some programming languaage. • Traditional Design Approach. • Object-Oriented Design Approach. Coding and Unit Testing: • The purpose mof the coding and unit testing phase of software development is to translate the software design into source code. Integration and System Testing: • ‘Integration of different modules is coded and unit tested. • 𝛼 − 𝑇𝑒𝑠𝑡𝑖𝑛𝑔 • 𝛽 − 𝑇𝑒𝑠𝑡𝑖𝑛𝑔 • Accsptance Testing.
- 22. Maintenance: • Maintenance of a typical software products requires much more than the effort necessary to develope the product itself. Iterative Waterfall life cycle model: • The main changes is done by providing feedback paths from every phase to its preceding phase.
- 24. Prototype Model: • Prototyping Model is a software development model in which is built, and until an is prototype tested, reworked acceptable prototype achieved.
- 25. Advantages: • Clarity. • Risk Identification. • Good Environment. • Take less time to complete. Disadvantages: • High cost. • Slow process. • Too many changes.
- 26. RAD Model: • Rapid Application Development(RAD) is an incremental software model that a short development cycle. • The RAD model is a “high-speed” of the waterfall model. • The RAD process enables a development team to create a fully functional system within a very short time period.
- 28. Contents of RAD Pakages: • Graphical user development environment. • Reusable Components. • Code generator. • Programming Language. Advantages: • Fast products. • Efficient Documentation. • Interaction with user. Disadvantages: • User may not like fast activities. • Not suitable for technical risks.
- 29. Sprial Model : • This Spiral model is a combination of iterative development process model and sequential linear development model i.e. the waterfall model with a very high emphasis on risk analysis. • The spiral model has four phases: Planning, Design, Construct and Evaluation.
- 30. Quadrants in sprial model :
- 31. Advantages : • Risk Identification at early stage. • Suitable for high rk projects. • Flexibility for adding functionaility. Disadvantages: • Costly. • Risk dependent. • Not suitable for smaller projects. • Difficult to meeting budget.
- 32. Win-Win Sprial Model: • The customer wins by getting the system satisfying most of thier requirements and developers winsby working on achievable budgets and deadlines. • Advantages: • Lieghtweight methods suit small-medium size project. • Produces good team. • Test based approach to requirements and quality assurance Diadvantages: • Programming pairs is costly. • Difficult to scale up to large projects where documentation.
- 34. Fourth Generation Techniques: • Introduction: • The tools in automatically generate ource code based on the developers specification. Software development environment that supports the 4GT paradigm includes some or all of the following tools: • 1) Non-procedural languages for database query • 2) Report generation • 3) Data manipulation • 4) Screen interaction and definition • 5) Code generation and High-level graphics capability • 6) Spreadsheet capability • 7) Automated generation of HTML and similar languages used for Web-site creation using advanced software tools.
- 35. Advantages: • Reduction in software development. • Improved productivity of software engineers. • 4GT helped by CASE tools and code generators. Disadvantages: • Some 4GT are not at all easier than are sometimes programming languages. • Generated source code inefficient. • Time is reduced for only small and medium projects.
- 36. Planning: • Software planning process include steps to estimate the size of the software work products and the resources needed produces a schedule identify and access software risks. • During planning a project is split into several activities : • How much efforts is required to complete each activities? • How much calender time is needed? • How much will the completed activity cost?
- 37. Planning Objectives: • Understand the scope of the problem. • Make use of past historical data. • Estimate effort or function or size. • Define a project schedule. Characteristics of software project planning: •Scope. •Resource. •Time. •Quality. •Risk.
- 39. Project Plan: • The biggest single problem that afflicts software developing is that of underestimating resources required for a project. • According to the project management body of knowledge. • According to PRINCE(PRojects IN Controlled Environments). Project Cluster Planning Process Project Plan
- 40. Types of Project Plan: • Software development plan. • Quality Assurance Plan. • Validation Plan. • Configuration Management Plan. • Maintenance Plan. • Staff development plan. Structure of a software project management plan: Project summary. Project planning.
- 41. Major issues in planning a software project: • Software requiremments are frequently incorrect and incomplete. • Planning schedule and cost are not updated and are based on marketing needs, not system requirements. • Cost and schedule are not re-estimated when requirements or development environment change.
- 42. Software Project Scheduling: • Introduction: • Software project scheduling is an distributes estimated effort across the planned project. • Project schedulinginvolves seperating the total work involved in a project in seperate activities and judging the time required to complete the activities.
- 44. Basic principles of software project scheduling: • Compartmentalization. • Interdependency. • Time Allocation. • Effort Validation. • Defined Responsibilities. • Defined outcomes. • Defined Milestones.
- 45. Relationship between people and effort: • The PNR curve provides an indication of the relationship between effort applied and delivery time for a software project.
- 46. Effort Distribution: • A recommended distribution of effort the software process is often referred to as the 40- 20-40 rule. Defining a task set for the software project: • A task set is a collection of software engineering work tasks, milestones, and work products that must be acomplished to complete a particular project. • Concept Development projects. • New application development projects. • Application enhancement projects. • Application maintenance projects. • Re-Engineering projects.
- 47. Example of a task set: • Concept Scoping: It determines the overall scope of the project. • Preliminary concept planning: It establishes the organization ability to undertake the work implied by the project scope. • Technology Risk Assessment: It evaluates the risk associated with the technology to be implemented as part of project scope. • Concept Implementation: It implement the concept representation in a manner that can be reviewed by a customer and is used marketing purposes.
- 48. • Customer Reaction: Customer reaction to the concept feedback on a new technology concept and target specific customer applications. Scheduling Techniques: • Scheduling of a software project does not differ greatly from scheduling of any multitask engineering effort. • Work Breakdown Structure(WBS). • Activity Charts. • Project Evaluation Review Techniques(PERT). • Grant Charts. • Critical Path Method(CPM).
- 49. Work Breakdown Structure(WBS): • A Work Breakdown Structure is a hierarcical decomposition or breakdown of a project or major activity into successive levels. Project Design Imple menta tion Testing Testing UI Design Data Design Module Testing Data Design Design Site
- 50. Features of WBS: • Structure. • Description. • Coding. • Depth. • Level of Detail. Activity Charts : Representation of WBS: • Network of boxes and arrows. • Shows different tasks making up a project. • Represents the ordering among the tasks.
- 52. Project Evaluation Review Technique(PERT): • PERT chart is a project management tool used to schedule, organize and coordinate tasks within the project. • PERT methonology developed by the U.S. Navy in the 1950’s to manage the polaris submarine program. • PERT is an event-oriented technique • PERT is a probabilistic model • Grantt chart, PERT can be both a cost and a time management system.
- 53. Grantt Chart: A grantt chart is a horizontal bar chart developedas a production control tool named after Henry L, Grantt an american engineer and social scientist ferquently used in project management.
- 54. Critical Path Method(CPM): • CPM acts as the basic both for perparation of a schedule and of resource planning. • The critical path determine the total duration of the project. • CPM is an activity-oriented technique • CPM is a deterministic model
- 55. Risk Analysis & Management: • Risk analysis and management are a series of steps that help a software team to understand and manage uncertainty during the development process.. • A risk is a potential problem. • Managers, Software enginners and customers participate in risk analysis & management.
- 56. Software Risk: • According to webster risk is the possibility of suffering loss. • Risk in a project or program is a measure of the ability to achieve objectives within cost, schedule and constraints. • Types of software risk: Classification I Classification II
- 57. Classification I • Project Risks • Technical Risks. • Business Risks. Classification II: •Known Risks. •Predictable Risks. •Unperdictable Risks.
- 58. Classification I: • Project Risks: The projct schedule will slip and that costs will incnrease.Project risks identify schedule, resource, customer and requirements problem. • Technical Risks:The product quality and the timeliness of the schedule if a technical risks is real then implementation may become difficult or implssible. • If identify potential design, implementation, interface, verfication and maintenance problems.
- 59. Business Risks: • Market Risk. • Strategic Risk. • Management Risk. • Budget Risk. Classification II: • Known Risks: That can be uncovered after careful evaluation of the project plan. •Predictable Risks:Predictable Risks are extrapolated from past project experience.
- 60. •Unperdictable Risks: Unperdictable Risks are the joker in the desk, they can extremely difficult to identify in advance. Risk Principles: • Global Perspective. • Forward looking view. • Open communication. • Integrated management. • Continuous process. • Shared product vision. • Team work.
- 61. Risk Strategies: • Reactive Risk Strategies. • Proactive Risk Strategies. Risks in software development projects: • Poorly defined requirements. • Client requirements changes. • Poor techniques for cost estimation. • Dependence on skills of individual developers.
- 62. Risk Management Process: • The risk management activities includes identify, analysis, plan, track and control risks. • Risk Assessment. • Risk Control. Risk Assessment: • Risk assessment is the determination os qualitative value of risk related to a concrete situation and recognized the risk.
- 63. • Risk identification. • Risk analysis. • Risk Prioritization. Risk Identification: • Risk identification is a systematic attempt to specify to the project plan. Risk Item Checklist: • Product Size. • Bussiness Impact. • Customer Characteristics. • Process definition. • Development environment.
- 64. Activities in risk identification phase: • Identify Risks. • Define Risk Attributes. • Document. • Communicate. Risk Analysis: • The risk identify all items are analysed using different criterias. • Activities in risk analysis: • Group similar risks. • Determine risk derivers. • Determine sources of risks. • Estimate risk.
- 65. Risk Prioritization: • The project focus on its most server risks by assessing the risk. • Let (r) is the likehood of a risk coming trace. • (s) is the consequence of the problem associated with that risk. • P=r*s. Risk Control: • Risk control is the process of managing risks should outcomes.
- 66. • Risk Management Planning. • Risk Resolution. • Risk Monitoring. Risk Management Planning: • It is a plan for delaing with each significant risk. Strategies in risk management planning: • Risk Avoidance. • Risk monitoring. • Risk management and contingency planning.
- 67. Risk Resoution: • Risk resolution is the execution of the plan for dealing with each risk. • The risk has triggered the project manager need to execute the action plan. Outputs of risk resolution phase: • Risk status. • Acceptable risks. • Reduced rework. • Corrective actions. • Problem prevention.
- 68. Risk Monitoring: • Risk monitoring reassessing of is the continually risks as the project proceeds and conditions change. • RMMM Plan: • Risk Mitigation , Monitoring and management in the software project plan or the risk management steps are organized.
- 69. Requirement Engineering Process: • Introduction: • Requirement engineering is the sub- discipline of software engineering that is with determine the goal, and constraints of software concerned functions system. Requirements: • Requirements management is a systematic approach to eliciting organizing and documenting the requirements of the systems.
- 70. Types of Requirements: • System Requirements. • User Requirements. System Requirements: • System requirements set out the systems functions, services and operational constraints in detail. • It may be part of the constract betwwen the system buyer and the software developer.
- 71. Types of system requirements: • Functional requirements. • Non-functional Requirements. • Domain Requirements. Functional Requirements: • The customer should provide statement of service. It should be clear how the system should react to particular inputs and how a particular system. Problem of Functional Requirements: • User Intention. • Developer Interpretation. • Requirements completness and consistency:
- 72. Non-Functional Requirements: • The system properties and constraints various properties of a system can be: realiability, response tiime, storage requirements. Types of Non-Functional Requirements: • Product Requirements. • Organizational Requirements. • External Requirements.
- 73. Domain Requirements: • Requirements can be application domain of the system, reflecting, characteristics of the domain. Problem of Domain Requements: • Understandability. • Implicitness. User Requirements: • User requirements are defined using natural language lables and diagrams because these are the representation that can be undestood by all users.
- 74. • Client Managers. • System End Users. • Client Engineers. • Contract Managers. Problem of User Requirements: • Lack of Clarity. • Requirements Confusion. • Requirements Mixture.
- 75. Software Requirement Specification: • Software Requirements document is the specification of the system. • It is not a design document. • Requirements document is called SRS. Users of SRS: • Users, Customer and marketing Personnel. • Software Developers. • Test Engineers. • Project Managers.