The document discusses several software process models:
- The Linear Sequential (Waterfall) Model is a simple, systematic approach where each phase must be completed before moving to the next. It is best for small, well-defined projects.
- The Incremental Model applies the Linear Sequential Model iteratively to increments, delivering working software in stages. This allows for early delivery and flexibility.
- The Prototyping Model involves building prototypes to refine requirements through client feedback in iterations. This helps establish clear objectives.
- Rapid Application Development (RAD) is a fast version of the Linear Sequential Model using a component-based approach to accelerate delivery of fully functional projects.
This document discusses software metrics and measurement. It describes how measurement can be used throughout the software development process to assist with estimation, quality control, productivity assessment, and project control. It defines key terms like measures, metrics, and indicators and explains how they provide insight into the software process and product. The document also discusses using metrics to evaluate and improve the software process as well as track project status, risks, and quality. Finally, it covers different types of metrics like size-oriented, function-oriented, and quality metrics.
The document provides an overview of the Software Engineering course for the second semester of the second year (B.Tech IT/II Sem-II). It includes details about the term, text books, unit syllabus, index of topics, and slides covering introductions to software engineering, the changing nature of software, software myths, generic views of process, the Capability Maturity Model Integration and personal and team software processes.
The document discusses several process models for software development projects, including code and fix, waterfall, incremental/iterative, spiral, rapid application development (RAD), and concurrent development models. Each model has advantages and disadvantages depending on factors like project size, requirements stability, and team expertise. Combinations of models may also be suitable in some cases.
Software development process models
Rapid Application Development (RAD) Model
Evolutionary Process Models
Spiral Model
THE FORMAL METHODS MODEL
Specialized Process Models
The Concurrent Development Model
Following presentation answers:
- Why do we need evolution?
- What happens if we do not evolve the software?
- What are the types of software evolution?
- What are Lehman's laws
- What are the strategies for evolution?
This document provides an overview of software testing concepts and processes. It discusses the importance of testing in the software development lifecycle and defines key terms like errors, bugs, faults, and failures. It also describes different types of testing like unit testing, integration testing, system testing, and acceptance testing. Finally, it covers quality assurance and quality control processes and how bugs are managed throughout their lifecycle.
Introduction to Software Project ManagementReetesh Gupta
This document provides an introduction to software project management. It defines what a project and software project management are, and discusses the key characteristics and phases of projects. Software project management aims to deliver software on time, within budget and meeting requirements. It also discusses challenges that can occur in software projects related to people, processes, products and technology. Effective project management focuses on planning, organizing, monitoring and controlling the project work.
This document summarizes key concepts from the first chapter of Ian Sommerville's Software Engineering textbook. It introduces software engineering as an engineering discipline concerned with all aspects of software production. It discusses the objectives of software engineering, topics covered like frequently asked questions and professional responsibility. It also summarizes concepts like the software development process, methods, costs and challenges in the field.
This document discusses software metrics and measurement. It describes how measurement can be used throughout the software development process to assist with estimation, quality control, productivity assessment, and project control. It defines key terms like measures, metrics, and indicators and explains how they provide insight into the software process and product. The document also discusses using metrics to evaluate and improve the software process as well as track project status, risks, and quality. Finally, it covers different types of metrics like size-oriented, function-oriented, and quality metrics.
The document provides an overview of the Software Engineering course for the second semester of the second year (B.Tech IT/II Sem-II). It includes details about the term, text books, unit syllabus, index of topics, and slides covering introductions to software engineering, the changing nature of software, software myths, generic views of process, the Capability Maturity Model Integration and personal and team software processes.
The document discusses several process models for software development projects, including code and fix, waterfall, incremental/iterative, spiral, rapid application development (RAD), and concurrent development models. Each model has advantages and disadvantages depending on factors like project size, requirements stability, and team expertise. Combinations of models may also be suitable in some cases.
Software development process models
Rapid Application Development (RAD) Model
Evolutionary Process Models
Spiral Model
THE FORMAL METHODS MODEL
Specialized Process Models
The Concurrent Development Model
Following presentation answers:
- Why do we need evolution?
- What happens if we do not evolve the software?
- What are the types of software evolution?
- What are Lehman's laws
- What are the strategies for evolution?
This document provides an overview of software testing concepts and processes. It discusses the importance of testing in the software development lifecycle and defines key terms like errors, bugs, faults, and failures. It also describes different types of testing like unit testing, integration testing, system testing, and acceptance testing. Finally, it covers quality assurance and quality control processes and how bugs are managed throughout their lifecycle.
Introduction to Software Project ManagementReetesh Gupta
This document provides an introduction to software project management. It defines what a project and software project management are, and discusses the key characteristics and phases of projects. Software project management aims to deliver software on time, within budget and meeting requirements. It also discusses challenges that can occur in software projects related to people, processes, products and technology. Effective project management focuses on planning, organizing, monitoring and controlling the project work.
This document summarizes key concepts from the first chapter of Ian Sommerville's Software Engineering textbook. It introduces software engineering as an engineering discipline concerned with all aspects of software production. It discusses the objectives of software engineering, topics covered like frequently asked questions and professional responsibility. It also summarizes concepts like the software development process, methods, costs and challenges in the field.
Design and Implementation in Software EngineeringKourosh Sajjadi
These slides were presented to the software engineering class held in IAUN. The main context is provided from the "Software Engineering" book authored by Sommerville.
Most of the icons used in the slides are provided in the flaticon.com website.
Thanks to our professor Habib Seifzadeh.
A cooperation with Mohammad Mostajeran.
The document discusses different software development process models including waterfall, evolutionary development, incremental development, and spiral models. The waterfall model involves sequential phases of requirements, design, implementation, testing and maintenance. However, it does not handle changes well. Evolutionary and incremental models incorporate feedback loops and iterative development. The spiral model is risk-driven and guides teams to adopt elements of other models based on a project's risk assessment.
S.D.L.C (Software Development Life Cycle.)Jayesh Buwa
The document discusses the Software Development Life Cycle (SDLC), which provides an overall framework for managing the software development process. There are two main approaches to the SDLC - predictive and adaptive. All projects use some variation of the SDLC, which typically includes phases like requirements definition, design, development, testing, deployment, and maintenance. Common SDLC models discussed include waterfall, incremental, spiral, and agile methods. The strengths and weaknesses of different models are compared.
The document outlines topics related to quality control engineering and software testing. It discusses key concepts like the software development lifecycle (SDLC), common SDLC models, software quality control, verification and validation, software bugs, and qualifications for testers. It also covers the quality control lifecycle, test planning, requirements verification techniques, and test design techniques like equivalence partitioning and boundary value analysis.
The document discusses various topics related to software quality assurance including:
1) It defines key terms like correctness, reliability, testing, failure, error, fault, debugging, verification, and validation.
2) It describes the differences between quality assurance (focusing on processes) and quality control (focusing on products), and lists some common quality assurance/control activities like testing, inspections, and reviews.
3) It provides an overview of a software development lifecycle including requirements, planning, design, coding, testing phases.
Verification ensures software meets specifications, while validation ensures it meets user needs. Both establish software fitness for purpose. Verification includes static techniques like inspections and formal methods to check conformance pre-implementation. Validation uses dynamic testing post-implementation. Techniques include defect testing to find inconsistencies, and validation testing to ensure requirements fulfillment. Careful planning via test plans is needed to effectively verify and validate cost-efficiently. The Cleanroom methodology applies formal specifications and inspections statically to develop defect-free software incrementally.
The document provides an introduction to software engineering. It discusses that software has a dual role as both a product and vehicle to deliver functionality. It defines software as a set of programs, documents, and data that form a configuration. The document outlines different types of software applications and categories. It also discusses software engineering practices such as communication, planning, modeling, construction, and coding principles.
Risk management involves identifying potential problems, assessing their likelihood and impacts, and developing strategies to address them. There are two main risk strategies - reactive, which addresses risks after issues arise, and proactive, which plans ahead. Key steps in proactive risk management include identifying risks through checklists, estimating their probability and impacts, developing mitigation plans, monitoring risks and mitigation effectiveness, and adjusting plans as needed. Common risk categories include project risks, technical risks, and business risks.
Process Improvement in Software Engineering SE25koolkampus
The document discusses software process improvement. It explains the principles of process improvement and introduces the SEI Capability Maturity Model. It discusses process analysis, modeling, measurement, and classification. It addresses the applicability and limitations of the SEI model and different process choices based on factors like project size.
The document discusses software quality and defines key aspects:
- It explains the importance of software quality for users and developers.
- Qualities like correctness, reliability, efficiency are defined.
- Methods for measuring qualities like ISO 9126 standard are presented.
- Quality is important throughout the software development process.
- Both product quality and process quality need to be managed.
The document discusses software testing concepts like verification, validation, whitebox testing, and blackbox testing. Verification ensures the product satisfies specifications, while validation ensures it meets customer requirements. Whitebox testing uses internal knowledge to test code, while blackbox testing treats the system as a black box without internal knowledge. The document also covers different types of testing like unit, integration, and functional testing.
Stepwise Project planning in software developmentProf Ansari
The following activities are:
Identify objectives and practical measures of the effectiveness in meeting those objectives.
Establish a project authority
Stakeholder analysis – identify all stakeholders in the project and their interests
Modify objectives in the light of stakeholder’s analysis
Establish methods of communication with all parties
2.4
The document discusses different types of software metrics that can be used to measure various aspects of software development. Process metrics measure attributes of the development process, while product metrics measure attributes of the software product. Project metrics are used to monitor and control software projects. Metrics need to be normalized to allow for comparison between different projects or teams. This can be done using size-oriented metrics that relate measures to the size of the software, or function-oriented metrics that relate measures to the functionality delivered.
This document discusses software documentation testing. It notes that documentation has become a major part of software systems and testers must cover both code and documentation. Different types of documentation are described, from user manuals to help systems. The document provides a checklist for documentation testing, including checking that content is appropriate, terminology is suitable, and examples work as intended. It also discusses using tools to auto-generate documentation from source code comments.
The document discusses formal approaches to software quality assurance (SQA). It states that SQA can be improved through software engineering practices like technical reviews, multi-tiered testing, controlling work products and changes, and following standards. It also argues that a more rigorous mathematical approach is needed for SQA since programs can be viewed as mathematical objects with rigorous syntax and semantics defined for languages, allowing proofs of correctness.
UML (Unified Modeling Language) is a standard modeling language used to visualize, specify, construct, and document software systems. It uses graphical notation to depict systems from initial design through detailed design. Common UML diagram types include use case diagrams, class diagrams, sequence diagrams, activity diagrams, and state machine diagrams. UML provides a standard way to communicate designs across development teams and is supported by many modeling tools.
The Waterfall model is a popular sequential model of the software development life cycle where each phase must be completed before the next begins. It consists of requirements, design, implementation, verification, and maintenance phases. Though simple to understand and manage, the Waterfall model works best for smaller, well-defined projects as it is inflexible to changes and produces no working software until late in the cycle.
This document discusses different types of software metrics including process, product, and project metrics. It defines metrics as quantitative measures of attributes and discusses how they can be used as indicators to improve processes and projects. Process metrics measure attributes of the development process over long periods of time. Product metrics measure attributes of the software at different stages. Project metrics are used to monitor and control projects. The document also discusses size-oriented and function-oriented metrics for normalization and comparison purposes. It provides examples of calculating function points and deriving metrics like errors per function point.
1. The document discusses various software engineering process models including waterfall, prototyping, RAD, incremental, and spiral models. It describes the key phases and advantages/disadvantages of each.
2. It also covers system engineering and how software engineering occurs as part of developing larger systems. Business process engineering and product engineering are introduced for developing information systems and products respectively.
3. Key aspects of developing computer-based systems are outlined including the elements of software, hardware, people, databases, documentation and procedures.
The document discusses different software engineering process models including:
1. The waterfall model which is a linear sequential model where each phase must be completed before moving to the next.
2. Prototyping models which allow requirements to be refined through building prototypes.
3. RAD (Rapid Application Development) which emphasizes short development cycles through reuse and code generation.
4. Incremental models which deliver functionality in increments with early increments focusing on high priority requirements.
5. The spiral model which has multiple iterations of planning, risk analysis, engineering and evaluation phases.
Design and Implementation in Software EngineeringKourosh Sajjadi
These slides were presented to the software engineering class held in IAUN. The main context is provided from the "Software Engineering" book authored by Sommerville.
Most of the icons used in the slides are provided in the flaticon.com website.
Thanks to our professor Habib Seifzadeh.
A cooperation with Mohammad Mostajeran.
The document discusses different software development process models including waterfall, evolutionary development, incremental development, and spiral models. The waterfall model involves sequential phases of requirements, design, implementation, testing and maintenance. However, it does not handle changes well. Evolutionary and incremental models incorporate feedback loops and iterative development. The spiral model is risk-driven and guides teams to adopt elements of other models based on a project's risk assessment.
S.D.L.C (Software Development Life Cycle.)Jayesh Buwa
The document discusses the Software Development Life Cycle (SDLC), which provides an overall framework for managing the software development process. There are two main approaches to the SDLC - predictive and adaptive. All projects use some variation of the SDLC, which typically includes phases like requirements definition, design, development, testing, deployment, and maintenance. Common SDLC models discussed include waterfall, incremental, spiral, and agile methods. The strengths and weaknesses of different models are compared.
The document outlines topics related to quality control engineering and software testing. It discusses key concepts like the software development lifecycle (SDLC), common SDLC models, software quality control, verification and validation, software bugs, and qualifications for testers. It also covers the quality control lifecycle, test planning, requirements verification techniques, and test design techniques like equivalence partitioning and boundary value analysis.
The document discusses various topics related to software quality assurance including:
1) It defines key terms like correctness, reliability, testing, failure, error, fault, debugging, verification, and validation.
2) It describes the differences between quality assurance (focusing on processes) and quality control (focusing on products), and lists some common quality assurance/control activities like testing, inspections, and reviews.
3) It provides an overview of a software development lifecycle including requirements, planning, design, coding, testing phases.
Verification ensures software meets specifications, while validation ensures it meets user needs. Both establish software fitness for purpose. Verification includes static techniques like inspections and formal methods to check conformance pre-implementation. Validation uses dynamic testing post-implementation. Techniques include defect testing to find inconsistencies, and validation testing to ensure requirements fulfillment. Careful planning via test plans is needed to effectively verify and validate cost-efficiently. The Cleanroom methodology applies formal specifications and inspections statically to develop defect-free software incrementally.
The document provides an introduction to software engineering. It discusses that software has a dual role as both a product and vehicle to deliver functionality. It defines software as a set of programs, documents, and data that form a configuration. The document outlines different types of software applications and categories. It also discusses software engineering practices such as communication, planning, modeling, construction, and coding principles.
Risk management involves identifying potential problems, assessing their likelihood and impacts, and developing strategies to address them. There are two main risk strategies - reactive, which addresses risks after issues arise, and proactive, which plans ahead. Key steps in proactive risk management include identifying risks through checklists, estimating their probability and impacts, developing mitigation plans, monitoring risks and mitigation effectiveness, and adjusting plans as needed. Common risk categories include project risks, technical risks, and business risks.
Process Improvement in Software Engineering SE25koolkampus
The document discusses software process improvement. It explains the principles of process improvement and introduces the SEI Capability Maturity Model. It discusses process analysis, modeling, measurement, and classification. It addresses the applicability and limitations of the SEI model and different process choices based on factors like project size.
The document discusses software quality and defines key aspects:
- It explains the importance of software quality for users and developers.
- Qualities like correctness, reliability, efficiency are defined.
- Methods for measuring qualities like ISO 9126 standard are presented.
- Quality is important throughout the software development process.
- Both product quality and process quality need to be managed.
The document discusses software testing concepts like verification, validation, whitebox testing, and blackbox testing. Verification ensures the product satisfies specifications, while validation ensures it meets customer requirements. Whitebox testing uses internal knowledge to test code, while blackbox testing treats the system as a black box without internal knowledge. The document also covers different types of testing like unit, integration, and functional testing.
Stepwise Project planning in software developmentProf Ansari
The following activities are:
Identify objectives and practical measures of the effectiveness in meeting those objectives.
Establish a project authority
Stakeholder analysis – identify all stakeholders in the project and their interests
Modify objectives in the light of stakeholder’s analysis
Establish methods of communication with all parties
2.4
The document discusses different types of software metrics that can be used to measure various aspects of software development. Process metrics measure attributes of the development process, while product metrics measure attributes of the software product. Project metrics are used to monitor and control software projects. Metrics need to be normalized to allow for comparison between different projects or teams. This can be done using size-oriented metrics that relate measures to the size of the software, or function-oriented metrics that relate measures to the functionality delivered.
This document discusses software documentation testing. It notes that documentation has become a major part of software systems and testers must cover both code and documentation. Different types of documentation are described, from user manuals to help systems. The document provides a checklist for documentation testing, including checking that content is appropriate, terminology is suitable, and examples work as intended. It also discusses using tools to auto-generate documentation from source code comments.
The document discusses formal approaches to software quality assurance (SQA). It states that SQA can be improved through software engineering practices like technical reviews, multi-tiered testing, controlling work products and changes, and following standards. It also argues that a more rigorous mathematical approach is needed for SQA since programs can be viewed as mathematical objects with rigorous syntax and semantics defined for languages, allowing proofs of correctness.
UML (Unified Modeling Language) is a standard modeling language used to visualize, specify, construct, and document software systems. It uses graphical notation to depict systems from initial design through detailed design. Common UML diagram types include use case diagrams, class diagrams, sequence diagrams, activity diagrams, and state machine diagrams. UML provides a standard way to communicate designs across development teams and is supported by many modeling tools.
The Waterfall model is a popular sequential model of the software development life cycle where each phase must be completed before the next begins. It consists of requirements, design, implementation, verification, and maintenance phases. Though simple to understand and manage, the Waterfall model works best for smaller, well-defined projects as it is inflexible to changes and produces no working software until late in the cycle.
This document discusses different types of software metrics including process, product, and project metrics. It defines metrics as quantitative measures of attributes and discusses how they can be used as indicators to improve processes and projects. Process metrics measure attributes of the development process over long periods of time. Product metrics measure attributes of the software at different stages. Project metrics are used to monitor and control projects. The document also discusses size-oriented and function-oriented metrics for normalization and comparison purposes. It provides examples of calculating function points and deriving metrics like errors per function point.
1. The document discusses various software engineering process models including waterfall, prototyping, RAD, incremental, and spiral models. It describes the key phases and advantages/disadvantages of each.
2. It also covers system engineering and how software engineering occurs as part of developing larger systems. Business process engineering and product engineering are introduced for developing information systems and products respectively.
3. Key aspects of developing computer-based systems are outlined including the elements of software, hardware, people, databases, documentation and procedures.
The document discusses different software engineering process models including:
1. The waterfall model which is a linear sequential model where each phase must be completed before moving to the next.
2. Prototyping models which allow requirements to be refined through building prototypes.
3. RAD (Rapid Application Development) which emphasizes short development cycles through reuse and code generation.
4. Incremental models which deliver functionality in increments with early increments focusing on high priority requirements.
5. The spiral model which has multiple iterations of planning, risk analysis, engineering and evaluation phases.
Structured system analysis and design Jayant Dalvi
The document discusses four common software development models: Waterfall, Spiral, Prototyping, and RAD (Rapid Application Development). It describes the key phases and characteristics of each model. The Waterfall model follows a linear sequence of phases from requirements to maintenance without iteration. The Spiral model is iterative with a risk-analysis focus. Prototyping emphasizes early customer feedback through prototypes. RAD prioritizes rapid delivery of high priority functionality through reuse and automated tools. Each model has advantages for certain types of projects depending on requirements clarity, budget, and risks.
SE_Unit 2.pdf it is a process model of it studentRAVALCHIRAG1
The document discusses various process models for software engineering including waterfall, incremental, RAD, evolutionary (prototyping and spiral), concurrent, component-based, aspect-oriented, and reuse-oriented models. It also covers project metrics, software measurement approaches including size-oriented metrics like lines of code and function-oriented metrics like function points. Key aspects of each model are defined along with their applicability and limitations.
This document provides an overview of software engineering concepts including different types of software, software classification, software attributes, and common software development process models. It describes system software and application software, and distinguishes between generic/off-the-shelf software and custom software. Popular process models covered include waterfall, prototyping, and rapid application development (RAD). The waterfall model and its stages are explained in detail.
The document discusses software engineering and provides definitions and explanations of key concepts. It defines software, engineering, and software engineering. It explains that software engineering uses scientific principles and methods to develop reliable and efficient software products. The document also summarizes different software life cycle models including waterfall, incremental, prototyping, spiral and agile models. It explains the various phases in the software development life cycle such as requirements gathering, design, coding, testing etc.
Software development life cycle (SDLC) ModelsAOmaAli
The document discusses various software development life cycle (SDLC) models. It describes the waterfall model process with distinct phases of requirements, design, implementation, testing and maintenance. It also covers the V-model which incorporates testing at each phase. Other models discussed include prototyping, iterative/incremental and when each may be used based on project characteristics and requirements stability.
This document outlines the topics covered in five units of a Software Engineering course. Unit I introduces software engineering paradigms like waterfall and spiral models. Unit II covers software design concepts like abstraction and modularity. Unit III discusses software testing and maintenance. Unit IV covers software metrics and quality assurance. Unit V focuses on software configuration management. Key concepts covered include software development lifecycles, risk analysis, requirements engineering, and project planning techniques.
This document outlines the topics covered in a software engineering course across 5 units: introduction, software design, software testing and maintenance, software metrics, and software configuration management. The introduction unit discusses software engineering paradigms like waterfall and spiral models. Software design covers concepts like abstraction, modularity, and design notations. Software testing and maintenance examines strategies, tools, and maintenance. Software metrics focuses on process and product measurement. Software configuration management needs and version control are also introduced.
The document discusses various software process models including prescriptive models like waterfall model and incremental process model. It also covers evolutionary models like prototyping and spiral process model. Specialized models covered are component based development, formal methods model, aspect oriented development and unified process model. The key highlights are that different models are suited for different situations based on project needs and each model has advantages and disadvantages to consider.
This document discusses various process models for software engineering:
- The waterfall model defines sequential phases of requirements, design, implementation, testing, and maintenance. It is inflexible to change.
- Iterative models allow repetition of phases to incrementally develop software. The incremental model delivers functionality in increments.
- Evolutionary models like prototyping and spiral development use iterative evaluation and refinement of prototypes to evolve requirements and manage risk.
- Other models include component-based development, formal methods, aspect-oriented development, and the Unified Process with iterative development of use cases. Personal and team software processes focus on self-directed teams, planning, metrics, and process improvement.
ISTQB - Software development life cycleHoangThiHien1
The document discusses various software development lifecycle models and when each is best used. It describes the waterfall, V-shaped, incremental, RAD, agile, iterative, spiral and prototype models. For each model, it provides advantages, disadvantages and considerations for when the model should be used. Testing is recommended throughout the development lifecycle, with test activities corresponding to each development phase.
The document discusses various software development life cycle (SDLC) models including waterfall, V-shaped, prototyping, rapid application development (RAD), incremental, spiral, and agile models. It provides details on the key steps, strengths, weaknesses, and scenarios for using each model. It also discusses quality assurance plans and techniques to ensure quality like defect tracking, unit testing, code reviews, integration testing, and system testing.
Software Lifecycle Models / Software Development Models
Types of Software development models
Waterfall Model
Features of Waterfall Model
Phase of Waterfall Model
Prototype Model
Advantages of Prototype Model
Disadvantages of Prototype model
V Model
Advantages of V-model
Disadvantages of V-model
When to use the V-model
Incremental Model
ITERATIVE AND INCREMENTAL DEVELOPMENT
INCREMENTAL MODEL LIFE CYCLE
When to use the Incremental model
Rapid Application Development RAD Model
phases in the rapid application development (RAD) model
Advantages of the RAD model
Disadvantages of RAD model
When to use RAD model
Agile Model
Advantages of Agile model
Disadvantages of Agile model
When to use Agile model
The document discusses several software development life cycle (SDLC) models including the Capability Maturity Model (CMM), Waterfall model, V-shaped model, Rapid Application Development (RAD) model, Incremental model, and Spiral model. It provides an overview of the key stages and characteristics of each model as well as their strengths and weaknesses to help determine when each model is best applied.
The document discusses various software development life cycle (SDLC) models including waterfall, V-shaped, prototyping, rapid application development (RAD), incremental, spiral, and agile models. For each model, the key steps or phases are described along with strengths and weaknesses. When each model is most applicable is also discussed. The document then covers quality assurance planning and activities that should be included like defect tracking, testing at various levels, and technical reviews.
The document discusses several software development life cycle (SDLC) models including the Capability Maturity Model (CMM), Waterfall model, V-shaped model, Rapid Application Development (RAD) model, Incremental model, and Spiral model. It provides an overview of the key stages and characteristics of each model as well as their strengths and weaknesses to help determine when each model is best applied.
The document discusses several software development life cycle (SDLC) models including the Capability Maturity Model (CMM), Waterfall model, V-shaped model, Rapid Application Development (RAD) model, Incremental model, and Spiral model. It provides an overview of the key stages and characteristics of each model as well as their strengths and weaknesses to help determine when each model is best applied.
Similar to Soft engg introduction and process models (20)
Data Communication and Computer Networks Management System Project Report.pdfKamal Acharya
Networking is a telecommunications network that allows computers to exchange data. In
computer networks, networked computing devices pass data to each other along data
connections. Data is transferred in the form of packets. The connections between nodes are
established using either cable media or wireless media.
Sachpazis_Consolidation Settlement Calculation Program-The Python Code and th...Dr.Costas Sachpazis
Consolidation Settlement Calculation Program-The Python Code
By Professor Dr. Costas Sachpazis, Civil Engineer & Geologist
This program calculates the consolidation settlement for a foundation based on soil layer properties and foundation data. It allows users to input multiple soil layers and foundation characteristics to determine the total settlement.
Sri Guru Hargobind Ji - Bandi Chor Guru.pdfBalvir Singh
Sri Guru Hargobind Ji (19 June 1595 - 3 March 1644) is revered as the Sixth Nanak.
• On 25 May 1606 Guru Arjan nominated his son Sri Hargobind Ji as his successor. Shortly
afterwards, Guru Arjan was arrested, tortured and killed by order of the Mogul Emperor
Jahangir.
• Guru Hargobind's succession ceremony took place on 24 June 1606. He was barely
eleven years old when he became 6th Guru.
• As ordered by Guru Arjan Dev Ji, he put on two swords, one indicated his spiritual
authority (PIRI) and the other, his temporal authority (MIRI). He thus for the first time
initiated military tradition in the Sikh faith to resist religious persecution, protect
people’s freedom and independence to practice religion by choice. He transformed
Sikhs to be Saints and Soldier.
• He had a long tenure as Guru, lasting 37 years, 9 months and 3 days
Online train ticket booking system project.pdfKamal Acharya
Rail transport is one of the important modes of transport in India. Now a days we
see that there are railways that are present for the long as well as short distance
travelling which makes the life of the people easier. When compared to other
means of transport, a railway is the cheapest means of transport. The maintenance
of the railway database also plays a major role in the smooth running of this
system. The Online Train Ticket Management System will help in reserving the
tickets of the railways to travel from a particular source to the destination.
This is an overview of my current metallic design and engineering knowledge base built up over my professional career and two MSc degrees : - MSc in Advanced Manufacturing Technology University of Portsmouth graduated 1st May 1998, and MSc in Aircraft Engineering Cranfield University graduated 8th June 2007.
3. Biggest Software Failures
• 1. Hackers Target Indian Debit Cards : total loss of Rs 1.3 crores in
fraudulent transactions
• 2. The BlueCross BlueShield Association System Failure
:resulting in almost 25,000 consumers being enrolled with incorrect
health insurance
• 3 Bangladesh Banks Heist :$81 million of Bangladesh’s money was
siphoned off by hackers that remain unknown. they caused about
$870 million in transfers to be canceled.
• 4. Satellite Failure Sends Global Software for a Toss :All over the
world, GPS systems were thrown off for several hours before the
operations were once again restored to normalcy.
• 5. Yahoo! Data Theft :The first was in September, which ended
up affecting over 500 million Yahoo
• 6.Hive Thermostat App Sets Users’ Homes to 32° C (90° F)
• 7. Mark Zuckerberg Hack , Foxmeyer , Hershey …….
4. 1.Introduction To Software Engineering and
Process Models
• Nature of Software, Software Engineering, Software
Process, Capability Maturity Model (CMM)
• Generic Process Model
• Prescriptive Process Models:
• The Waterfall Model,
• V-model, Incremental Process Model, Prototype Model
• Evolutionary Process Models,: RAD , Spiral
• Concurrent Model
• Agile process, Agility Principles,
• Extreme Programming (XP),
• Scrum,
• Kanban model
5. 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 - developed to be sold to a range of different
customers
• Bespoke (custom) - developed for a single customer
according to their specification
6. What is software engineering?
Software engineering is an engineering discipline which
is concerned with all aspects of software production
Software engineers should
• adopt a systematic and organised approach to their work
• use appropriate tools and techniques depending on
• the problem to be solved,
• the development constraints and
• the resources available
7. Why Software Engineering?
Used w. extensive rework,
but later abandoned 20%
Used as delivered 2%
Usable w. rework 3%
9 software projects totaling $96.7 million: Where The Money Went??
Delivered, but never
successfully used
45%
Paid for, but
not delivered
30%
8. What is the difference between software engineering and
computer science?
Computer Science Software Engineering
is concerned with
theory
fundamentals
the practicalities of developing
delivering useful software
9. Nature of Software : Wear vs. Deterioration
9
Hardware
curve
Bathtub Curve
10. 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.
10
13. Software engineering models
13
“There are two ways of constructing a
software design: One way is to make it
so simple that there are obviously no
deficiencies, and the other way is to
make it so complicated that there are
no obvious deficiencies. The first
method is far more difficult.”
14.
15. Software Process
• Process consists of activities/steps to be carried out in a
particular order
• Software process deals with both technical and
management issues
• Consists of different types of process
• Process for software development: produces software as
end-result
16. Software Process Model
The software engineers has five choices for the selection of software process
models. The models are :
• Linear Sequential Model (LSM)
• V-model
• The Prototype Model (PRM)
• The Rapid Application Development Model (RAD)
• The Incremental Model (INS)
• The Boehm Spiral Model (BMS)
• Concurrent Models
• Agile Methodology
In all models , core activities are Analysis, Design , Code, Test are common .
However their execution differs from model to model.
17. The Linear Sequential Model (LSM)
• It is one of the earliest development models.
• In this approach ,the process of software development is
represented by a sequence of steps.
• The sequential phases are what make this model linear, simple
and systematic in nature.
• Each phase must be completed before you can move to next
phase.
• This model is also known as the Waterfall Model or classical
life cycle .
18. Phases of Linear Sequential Model
Analysis
•Functional
req. doc
Designing •Req. Transform
into detail design
Coding •Implementation
Testing •Test the
system
Maintenan
ce
•Maintain System ,post
implementation
19. Advantages of Linear Sequential Model
The Linear Sequential model offers the following
advantages:
• It is easy to understand and implement.
• It prohibits skipping any phase in the sequence.
• It is ideal for small projects and when the requirements and
goals of the project are well established in advance.
20. Disadvantages of Linear Sequential Model
The following are the disadvantages using Linear sequential
model:
• The working version of the software is available to the customer
after testing. Therefore, if there is any major error during the
coding it will till end of the testing.
• Due to linear nature is any phase is not completed , the software
analyst and developers cannot proceed further.
21. Incremental Model (INM)
• The incremental model is the combination of the features
of linear sequential model and the iterative approach of the
prototyping model.
• The software is developed and delivered in small
increments and the linear sequential model is applied to
each increment.
• In an incremental model ,the prototyping methodology is
applied to each process flow of each increment.
• In the case of the incremental model , the first increment
that is delivered is the core product.
• The core product addresses the primary needs of the final
product.
• It is evaluated and reviewed by the client.
22. Incremental Model (INM)
1-1 1-2 1-4 Final System1-3
Basic process
1 Increment process S/w Solution
Design
Req.
Analysis
CodingCoding Test
Next Increment
23.
24. This model has following advantages:
• Compared to RAD, it requires less human resources,
especially for the first few increments.
• It guarantees early delivery of the final products each
increment leads to the development of the software.
• The incremental model is therefore ideal for those projects
in which sufficient manpower is not available to meet
difficult project deadlines.
Advantages of using the Incremental
Model (INM)
25. Prototyping Model
• In this model the developer and client interact to established the
requirements of the software.
• Define the broad set of objectives.
• This is follow up by the quick design, in which the visible
elements of the software, the input and the output are designed.
• The quick design stresses the clients view of the software .
• The final product of the design is a prototype.
• The client the evaluates the prototype and provides its
recommendations and suggestion to the analyst.
• The process continues in an iterative manner until the all the
user requirements are met.
27. Advantages of Prototyping Model
The following are the advantages of Prototyping model:
• Due the interaction between the client and developer right from
the beginning , the objectives and requirements of the software
is well established.
• Suitable for the projects when client has not clear idea about his
requirements.
• The client can provide its input during development of the
prototype.
• The prototype serves as an aid for the development of the final
product.
28. Disadvantages of Prototyping Model
The prototyping model has the following disadvantages.
• The quality of the software development is compromised in the
rush to present a working version of the software to the client.
• The client look at the working version of the product at the
outset and expect the final version of the product to be deliver
immediately. This cause additional pressure over the developers
to adopt shortcut in order to meet the final product deadline.
29. Rapid Application Development:
• RAD is a high speed version of linear sequential model. It is
characterized by a very short development life cycle, in which
the objective is to accelerate the development.
• The RAD model follows a component based approach.
• In this approach individual components developed by different
people are assembled to develop a large software system.
31. Phases of Rapid Application Development:
The RAD model consist of the following phases.
• Business Modeling:
In this phase, define the flow of information within the
organization, so that it covers all the functions. This helps
in clearly understand the nature, type ,source and process
of information.
• Data Modeling:
In this phase, convert the component of the information
flow into a set of data objects. Each object is referred as an
Entity.
32. Phases of Rapid Application
Development:
• Process Modeling:
In this phase, the data objects defined in the previous phase
are used to depict the flow of information . In addition adding ,
deleting, modifying and retrieving the data objects are included
in process modeling.
• Application Designing:
In this phase, the generation of the application and coding take
place.
• Testing:
In this phase, test the new program components.
33. Advantages of Using RAD Model:
The RAD has following advantages:
• Due to emphasis on rapid development , it results in the
delivery of fully functional project in short time period.
• It encourages the development of program component
reusable.
34. Disadvantages of Using RAD Model:
The RAD model has following disadvantages :
• It requires dedication and commitment on the part of the
developers as well as the client to meet the deadline..
• It is not suitable for the applications that have a high degree of
technical risk.
• It is not suitable for the large projects because they require more
manpower for creating multiple RAD groups.
36. Advantages of the V-Model
• This is a highly-disciplined model and Phases are
completed one at a time.
• Works well for smaller projects where
requirements are very well understood.
• Simple and easy to understand and use.
• Easy to manage due to the rigidity of the model.
Each phase has specific deliverables and a
review process.
37
37. Disadvantages of the V-Model
• High 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.
• Once an application is in the testing stage, it is
difficult to go back and change a functionality.
• No working software is produced until late during
the life cycle.
38
38. The Spiral Model
• The spiral model developed by Boehm combines the philosophy
of INM,RAD and LSM models with the use of prototyping.
• The spiral model is recommended where the requirements and
solution call for developing full-fledge , large, complicated
system with lots of features and facilities from the scratch.
• It is used when experimenting on technology , trying out new
skills and when the user is not able to offer requirements in clear
terms.
• It emphasis at the quick development of the software, which is
released in increments.
39. The Spiral Model
This model consists of a number of activities called task
regions.
The number of task regions varies from three to six.
A spiral model consist of the following task regions.
• Communication
• Planning
• Risk analysis
• Engineering
• Construction and release
• Evaluation
41. Advantages of Using Spiral Model
The spiral model has the following advantages :
• This model is more in tune with large real-life project
development.
• Prototyping can be applied at any level in evaluation process.
• This helps to reduce technical risk.
• It is suitable for application that can be use an object oriented
approach to develop software.
42. Disadvantages of Using Spiral Model
The spiral model has the following disadvantages:
• It requires considerable experience in risk management for the
project to be successful.
• It requires a lot of patience and time in years before this model’s
effectiveness can be assessed accurately.
43. Concurrent Model
• Early in the project the communication
activity has completed its first iteration
and exists in the awaiting changes
state.
• The modeling activity which existed in
the none state while initial
communication was completed now
makes a transition into
underdevelopment state.
• If, however, the customer indicates the
changes in requirements must be
made, the modeling activity moves from
the under development state into the
awaiting changes state.
45
Under review
Baselined
Done
Under
revision
Await ing
changes
Under
development
none
Modeling act ivit y
represents the state
of a software engineering
activity or task
44. Advantages & Disadvantages of the concurrent
development model
• This model is applicable to all types of software
development processes.
• It is easy for understanding and use.
• It gives immediate feedback from testing.
• It provides an accurate picture of the current state of a
project.
• It needs better communication between the team
members. This may not be achieved all the time.
• It requires to remember the status of the different
activities.
46
46. traditional approach
to software development
REQUIREMENTS
DESIGN
DEVELOPMENT
TESTING
MAINTENANCE
Waterfall Development is
another name for the more
Waterfall Development
47. Waterfall Development (contd..)
You complete one phase (e.g. design) before moving
on to the next phase (e.g. development)
You rarely aim to re-visit a ‘phase’ once it’s
completed. That means, you better get whatever
you’re doing right the first time!
48. This approach is highly risky, often more costly and
generally less efficient than Agileapproaches
REQUIREMENTS
DESIGN
DEVELOPMENT
TESTING
MAINTENANCE
Takes too long
Changes
SkippedYou don’t realize any value until
the end of the project
You leave the testing until the end
You don’t seek approval from the
stakeholders until late in the day
But…
50. What is “Agility”?
• Effective (rapid and adaptive) response to
change
• Effective communication among all
stakeholders
• Drawing the customer onto the team
• Organizing a team so that it is in control
of the work performed
Yielding …
• Rapid, incremental delivery of software 52
51. Agile Process Models
• Extreme Programming (XP)
• Adaptive Software Development (ASD)
• Dynamic Systems Development Method
(DSDM)
• Scrum
• Crystal
• Feature Driven Development (FDD)
• Agile Modeling (AM)
52. Individuals and interactions over
processes and tools
Working software over comprehensive
documentation
Customer collaboration over
contract negotiation
Responding to change over
following a plan
Agile Manifesto
54. Extreme Programming (XP)
• The most widely used agile process,
originally proposed by Kent Beck
• XP Planning
• Begins with the creation of “user stories”
• Agile team assesses each story and assigns a
cost
• Stories are grouped to for a deliverable
increment
• A commitment is made on delivery
date
56
55. Extreme Programming (XP)
57
unit t est
cont inuous int egrat ion
accept ance t est ing
pair
programming
Release
user st ories
values
accept ance t est crit eria
it erat ion plan
simple design
CRC cards
spike solut ions
prot ot ypes
refact oring
software increment
project velocity computed
56. Extreme Programming (XP)
• XP Design
– Follows the KIS principle
– Encourage the use of CRC cards (class responsibility collaborator)
– For difficult design problems, suggests the creation of —a design prototype
• XP Coding
– Encourages “pair programming”
• XP Testing
– All unit tests are executed daily
– “Acceptance tests” are defined by the customer and executed to assess
customer visible functionality
58
57. ScrumA light-weight agile process tool
Split your organization
into small, cross-functional, self-
organizing teams.
Split your work into a list of small, concrete deliverables.
Sort the list by priority and estimate the relative effort of each
item.
Scrum Team
Scrum Master
Product/ Project
Owner
58. Split time into short fixed-length iterations/ sprints (usually 2 – 4
weeks), with potentially shippable code demonstrated after each
iteration.
Scrum (contd..)
January May
Optimize the release plan and update priorities in
collaboration with the customer, based on insights gained by
inspecting the release after each iteration.
Optimize the process by having a retrospective after each
iteration.
61. Things we do in Scrum
The project/ product is described as a list of features: the backlog.
The features are described in terms of user stories.
The scrum team estimates the work associated with each story.
Features in the backlog are ranked in order of importance.
Result: a ranked and weighted list of product features, a
roadmap.
Daily scrum meeting to discuss What did you do y’day? What
will you do today? Any obstacles?
a.k.a Scrum terminologies
62. Scrum in a nutshell
So instead of a large group spending a long time building a
big thing, we have a small team spending a short time
building a small thing.
But integrating regularly to see the whole.
64. KanbanLean approach to agile development
Similar to Scrum in the sense that you focus on features as
opposed to groups of features – however Lean takes this
one step further again.
You select, plan, develop, test and deploy one
feature (in its simplest form) before you select, plan,
develop, test and deploy the next feature.
Aim is to eliminate ‘waste’ wherever possible…
65. Kanban (contd…)
Visualize the workflow
Limit WIP (work in progress)
Split the work into pieces, write each
item on a card and put on the wall
Use named columns to illustrate where
each item is in the workflow
Assign explicit limits to how many items may be in progress at each stage
Measure the lead time (average time to complete one item,
sometimes called “cycle time”)
Optimize the process to make lead time as small and predictable as possible
70. Outline
Why CMM matters
What is CMM ?
How you can use CMM
Details about CMM
Problems with CMM
71. Why CMM matters…
It is the most widespread and detailed software
development model
It is a standard for much DoD work, which is a
lot of software projects
It is being used by many non-DoD businesses
72. Background
Begun in 1986 by DoD to help improve
government software contractors.
Work started at Mitre, then at Software
Engineering Institute (SEI) at Carnegie Mellon
Univ.
Watts Humphrey was initial author, then Mark
Paulk, Bill Curtis, and others.
Borrows heavily from general Total Quality
Management (TQM) and work of Philip Crosby.
73. Describes an evolutionary improvement path for
software organizations from an ad hoc, immature
process to a mature, disciplined one.
Provides guidance on how to gain control of
processes for developing and maintaining software
and how to evolve toward a culture of software
engineering and management excellence.
What is CMM?
74. What are the CMM Levels?
(The five levels of software process
maturity)
Maturity level indicates level of process capability:
Initial
Repeatable
Defined
Managed
Optimizing
77. What is CMM?
In the same way, high-quality SW organizations
are different from low-quality orgs.
CMM tries to capture and describe these
differences.
CMM strives to create software development
organizations that are “mature”, or more mature
than before applying CMM.
Describes five levels of SW process maturity.
Includes lots of detail about each level
78. Summary of levels
Level 1 – Initial. Anything at all. Ad-hoc and
chaotic. Will have some successes, but will also
have failures and badly missed deadlines.
Level 2 – Repeatable. SW processes are
defined, documented, practiced, and people are
trained in them. Groups across an organization
may use different processes.
79. Summary of levels
Level 3 – Defined. SW processes are consistent
and known across the whole organization.
Level 4 – Managed. SW processes and results
are measured quantitatively, and processes are
evaluated with this data.
Level 5 – Optimizing. Continuous process
improvement. Experimenting with new methods
and technologies. Change processes when find
something that works better.
80. Level 1: Initial
Initial : The software process is characterized
as ad hoc, and occasionally even chaotic. Few
processes are defined, and success depends
on individual effort.
At this level, frequently have difficulty making
commitments that the staff can meet with an orderly
process
Products developed are often over budget and
schedule
Wide variations in cost, schedule, functionality and
quality targets
Capability is a characteristic of the individuals, not
of the organization
81. Level 2: Repeatable
Basic process management processes are
established to track cost, schedule, and
functionality. The necessary process
discipline is in place to repeat earlier
successes on projects with similar
applications.
Realistic project commitments based on results
observed on previous projects
Software project standards are defined and
faithfully followed
82. Level 3: Defined
The software process for both management and
engineering activities is documented, standardized, and
integrated into a standard software process for the
organization.
All projects use an approved, tailored version of the
organization’s standard software process for developing
an maintaining software.
83. Level 4: Managed
Detailed measures of the software process
and product quality are collected. Both the
software process and products are
quantitatively understood and controlled.
Narrowing the variation in process performance to
fall within acceptable quantitative bounds
When known limits are exceeded, corrective
action can be taken
predictable
predict trends in process and product quality
84. Level 5: Optimizing
Continuous process improvement is enabled by
quantitative feedback from the process and from
piloting innovative ideas and technologies.
Goal is to prevent the occurrence of defects
Causal analysis
Data on process effectiveness used for cost
benefit analysis of new technologies and
proposed process changes
85. Level 2 KPAs
Requirements Management
Establish common understanding of customer
requirements between the customer and the
software project
Requirements is basis for planning and managing
the software project
Not working backwards from a given release date!
Software Project Planning
Establish reasonable plans for performing the
software engineering activities and for managing
the software project
87. Level 2 KPAs
Software Project Tracking and Oversight
Establish adequate visibility into actual progress
Take effective actions when project’s performance
deviates significantly from planned
Software Subcontract Management
Manage projects outsourced to subcontractors
Software Quality Assurance
Provide management with appropriate visibility into
process being used by the software projects
work products
88. Level 2 KPAs
Software Configuration Management
Establish and maintain the integrity of work products
Product baseline
Baseline authority
89. Level 3 KPAs
Organization Process Focus
Establish organizational responsibility for software
process activities that improve the organization’s
overall software process capability
Organization Process Definition
Develop and maintain a usable set of software
process assets
stable foundation that can be institutionalized
basis for defining meaningful data for quantitative process
management
90. Level 3 KPAs
Training Program
Develop skills and knowledge so that individual
can perform their roles effectively and efficiently
Organizational responsibility
Needs identified by project
Integrated Software Management
Integrated engineering and management activities
Engineering and management processes are
tailored from the organizational standard
processes
Tailoring based on business environment and
project needs
91. Level 3 KPAs
Software Product Engineering
technical activities of the project are well defined
(SDLC)
correct, consistent work products
Intergroup Coordination
Software engineering groups participate actively
with other groups
Peer Reviews
early defect detection and removal
better understanding of the products
implemented with inspections, walkthroughs, etc
92. Level 4 KPAs
Quantitative Process Management
control process performance quantitatively
actual results from following a software process
focus on identifying and correcting special causes
of variation with respect to a baseline process
Software Quality Management
quantitative understanding of software quality
products
process
93. Level 5 KPAs
Process Change Management
continuous process improvement to improve quality,
increase productivity, decrease cycle time
Technology Change Management
identify and transfer beneficial new technologies
tools
methods
processes
Defect Prevention
causal analysis of defects to prevent recurrence
94. What are the benefits ?
Helps forge a shared vision of what software
process improvement means for the
organization
Defines set of priorities for addressing software
problems
Supports measurement of process by providing
framework for performing reliable and consistent
appraisals
Provides framework for consistency of
processes and product
95. Questions
• Describe in brief SDLC.
• Comparison of any two models.
• Short note on Agile development. (May 2018)
• What is Agility in context with software engineering?
Explain XP with suitable diagram. (May 2017)
• What is agile process and its advantages. Explain any
one agile process in detail. (May 2016)
• Write suitable application for different software models.
(May 2015)
• What is Agile methodology? Explain it with the principles
used and give example of any such software model. (May
2015)
100
97. Software Applications
• 1. System software: such as compilers, editors, file management utilities
• 2. Application software: stand-alone programs for specific needs.
• 3. Engineering/scientific software: Characterized by “number
crunching”algorithms. such as automotive stress analysis, molecular biology,
orbital dynamics etc
• 4. Embedded software resides within a product or system. (key pad control of a
microwave oven, digital function of dashboard display in a car)
• 5. Product-line software focus on a limited marketplace to address mass
consumer market. (word processing, graphics, database management)
• 6. WebApps (Web applications) network centric software. As web 2.0 emerges,
more sophisticated computing environments is supported integrated with remote
database and business applications.
• 7. AI software uses non-numerical algorithm to solve complex problem. Robotics,
expert system, pattern recognition game playing 102
98. Hookers General Principles for Software Engineering
Practice: important underlying law
Help you establish mind-set for solid software engineering
practice (David Hooker 96).
•1: The Reason It All Exists: provide values to users
•2: KISS (Keep It Simple, Stupid! As simple as possible)
•3: Maintain the Vision (otherwise, incompatible design)
•4: What You Produce, Others Will Consume (code with concern
for those that must maintain and extend the system)
•5: Be Open to the Future (never design yourself into a corner as
specification and hardware changes)
•6: Plan Ahead for Reuse
•7: Think! Place clear complete thought before action produces
better results.
103
99. Software Myths
Erroneous beliefs about software and the process that is
used to build it.
•Affect managers, customers (and other non-technical
stakeholders) and practitioners
•Are believable because they often have elements of truth,
but …
•Invariably lead to bad decisions,
therefore …
•Insist on reality as you navigate your way through
software engineering
104
100. Software Myths Examples
• Myth 1: Once we write the program and get it to work, our job is done.
• Reality: the sooner you begin writing code, the longer it will take you to get done. 60% to
80% of all efforts are spent after software is delivered to the customer for the first time.
• Myth 2: Until I get the program running, I have no way of assessing its quality.
• Reality: technical review are a quality filter that can be used to find certain classes of
software defects from the inception of a project.
• Myth 3: software engineering will make us create voluminous and unnecessary
documentation and will invariably slow us down.
• Reality: it is not about creating documents. It is about creating a quality product. Better
quality leads to a reduced rework. Reduced work results in faster delivery times.
105
101. FAQ about software engineering
106
Question Answer
What is software? Computer programs, data structures and associated
documentation. Software products may be developed for a
particular customer or may be developed for a general market.
What are the attributes of good software? Good software should deliver the required functionality and
performance to the user and should be maintainable,
dependable and usable.
What is software engineering? Software engineering is an engineering discipline that is
concerned with all aspects of software production.
What is the difference between software
engineering and computer science?
Computer science focuses on theory and fundamentals;
software engineering is concerned with the practicalities of
developing and delivering useful software.
What is the difference between software
engineering and system engineering?
System engineering is concerned with all aspects of computer-
based systems development including hardware, software and
process engineering. Software engineering is part of this more
general process.
102. Essential attributes of good software
107
Product characteristic Description
Maintainability Software should be written in such a way so that it can evolve to meet the
changing needs of customers. This is a critical attribute because software
change is an inevitable requirement of a changing business environment.
Dependability and security Software dependability includes a range of characteristics including
reliability, security and safety. Dependable software should not cause
physical or economic damage in the event of system failure. Malicious
users should not be able to access or damage the system.
Efficiency Software should not make wasteful use of system resources such as memory
and processor cycles. Efficiency therefore includes responsiveness,
processing time, memory utilisation, etc.
Acceptability Software must be acceptable to the type of users for which it is
designed. This means that it must be understandable, usable and
compatible with other systems that they use.