SOFTWARE ENGINEERING: I-M.

Tech(CSE) I-Sem
UNIT I SOFTWARE, SOFTWARE ENGINEERING, AND PROCESS The Nature of Software: * There are seven broad categories of computer software, that continuing challenges for software engineers are: (1) System Software: * It is a collection of programs written to service other programs => Some system software processes complex, but determinate information structure and some other processes largely indeterminate data Ex: => Compilers, editors and file management utilities Characteristics: => Heavy interaction with computer hardware => Heavy usage by multiple users => Complex data structures => Multiple external interfaces => Concurrent operation (2) Application Software: * It is a standalone program, that solve a specific business need * This software process business (Or) Technical decision making. In addition it is used to control business functions in real time Ex: => Point of sale transaction processing => Real time manufacturing process control (3) Engineering / Scientific Software: * This software used in various applications such as; => Astronomy => Molecular biology => Automated Manufacturing etc. * Modern application within the scientific / engineering area is moving away from conventional numerical algorithm * Computer aided design, system simulation and other interactive application, begun to take on real time (4) Embedded Software: * This Software resides within a product (Or) System * It is used to implement and control features and functions for the end user and for the system itself Ex: => Keypad control for a microwave oven => Digital Functions in an automobile such as fuel control, dash board Displays and braking system etc., (5) Product-line Software: * It is designed to provide a specific capability , for use by many different customers * This software focuses on esoteric market place and address mass consumer market
R.G.Kumar/Asst.,Prof/CSE/SIETK Page 1

SOFTWARE ENGINEERING: I-M.Tech(CSE) I-Sem

Ex: => Word processing => Spread sheets => Computer Graphics => Multimedia and entertainment etc., (6) Web Applications: * This Software span a wide array of applications * Web applications are evolving into sophisticated computing environment, that not only provide stand alone features, computing functions and content to end users, but also integrate corporate database and business application (7) Artificial Intelligence Software: * This software makes use of non numerical algorithms, to solve complex problems * Applications with in this area include; => Robotics => Expert Systems => Pattern recognition =>Theorem proving and game playing The Unique Nature of WebApps: A Web application (Web app) is an application program that is stored on a remote server and delivered over the Internet through a browser interface. Web-based application is any application that uses a web browser as a client. The term may also mean a computer software application that is coded in a browser-supported programming language (such as JavaScript, combined with a browser-rendered markup language like HTML) and reliant on a common web browser to render the application executable. Web applications are popular due to the ubiquity of web browsers, and the convenience of using a web browser as a client, sometimes called a thin client. The ability to update and maintain web applications without distributing and installing software on potentially thousands of client computers is a key reason for their popularity, as is the inherent support for cross-platform compatibility. Common web applications include webmail, online retail sales, online auctions, wikis and many other functions. Some of the unique nature of webapps: Network intensive Concurrency Unpredictable load Availability (24/7/365) Data driven Content sensitive Continuous evolution Immediacy (short time to market) Security Aesthetics Network Intensive It is a property of Webapps which means that it is a physical property of a system that does not depend on the system size or the amount of material in the system.
R.G.Kumar/Asst.,Prof/CSE/SIETK Page 2

SOFTWARE ENGINEERING: I-M.Tech(CSE) I-Sem

Concurrency
Concurrency is a property of systems in which several computations are executing simultaneously, and potentially interacting with each other. The computations may be executing on multiple cores in the same chip, preemptively time-shared threads on the same processor, or executed on physically separated processors. Ex: The "Dining Philosophers", a classic problem involving concurrency and shared resources

Availability (24/7/365) Availability is a general term that is used to describe the amount of time over a oneyear period that the system resources are available in the wake of component failures in the system. Availability, in the content of a computer system, refers to the ability of a user to access information or resources in a specified location and in the correct format. Data driven Data driven means that progress in an activity is compelled by data, rather than by intuition or personal experience. Data-driven programming is a programming paradigm in which the program statements describe the data to be matched and the processing required rather than defining a sequence of steps to be taken. Data driven programming is a programming model where the data itself controls the flow of the program and not the program logic. It is a model where you control the flow by offering different data sets to the program where the program logic is some generic form of flow or of state-changes. Ex: If you have program that has four states: UP - DOWN - STOP - START You can control this program by offering input (data) that represents the states: set1: DOWN - STOP - START - STOP - UP - STOP set2: UP - DOWN - UP - DOWN The program code stays the same but data set (which is not of a dynamic input type but statically given to the computer) controls the flow Content Sensitive Content sensitive is one which can automatically choose from a multiplicity of options based on the current or previous state(s) of the program operation. Content sensitivity is almost ubiquitous in current graphical user interfaces, usually in the form of content menus. Content sensitivity, when operating correctly, should be practically transparent to the user. Ex: Clicking on a text document automatically opens the document in a word processing environment. The user does not have to specify what type of program opens the file under standard conditions. Continuous Evolution Software Evolution is the term used in software engineering (specifically software maintenance) to refer to the process of developing software initially, then repeatedly updating it for various reasons. Immediacy It is the quality of bringing the content into direct and instant involvement with clients request, giving rise to a sense of urgency or excitement.
R.G.Kumar/Asst.,Prof/CSE/SIETK Page 3

SOFTWARE ENGINEERING: I-M.Tech(CSE) I-Sem

Security It encompasses measures taken throughout the application's life-cycle to prevent exceptions in the security policy of an application or the underlying system (vulnerabilities) through flaws in the design, development, deployment, upgrade, or maintenance of the application. Applications only control the use of resources granted to them, and not which resources are granted to them. They, in turn, determine the use of these resources by users of the application through application security. Aesthetics It is a set of principles concerned to retrieve the data as per user requirements from the server side. Software Engineering A Layered Technology:
TOOLS METHODS PROCESS A QUALITY FOCUS

(i) Quality Focus: * Any engineering approach [including software engineering] must rest on an organizational commitment to quality * Total quality management promote a continuous process improvement, this leads to development of effective approaches to software engineering * The bedrock that supports software engineering is a quality focus (ii) Process: * The process layer is the foundation for software engineering * It is the glue that holds the technology layers together and enables rational and timely development of computer software * It defines a framework that must be established for; => Effective delivery of software engineering technology * The software process forms the basis for management control * It establishes the context in which => Technical methods are applied =>Work products are produced [i.e. models, documents, data, reports, forms etc..] => Milestones are established => Quality is ensured and change is probably managed
R.G.Kumar/Asst.,Prof/CSE/SIETK Page 4

SOFTWARE ENGINEERING: I-M.Tech(CSE) I-Sem

(iii) Methods: * It contains a broad array of tasks that include; => Communication => Requirement analysis => Design modeling => Program Construction => Testing and support * It depends on a set of basic principles that => Govern each area of the technology => Include modeling activities and other descriptive techniques (iv) Tools: * It provide automated (Or) semi automated support for the process and the methods * When tools are integrated information created by one tool can be used by another The Essence and Principles of Software Engineering Practice *A practice is way of doing something. *Preparing Concepts, principles, methods, and tools * The Essence of SE Practice is 1. Understanding the problem 2. Devising the plan 3. Executing the plan 4. Examine the results 1. Understanding the Problem What are the unknowns? What are the data? What is the condition? Who involves? Can the problem be divided? Can the problem be represented graphically? 2. Devising the plan Are there any similar problems? Have they been solved? How? Can sub problems be defined? Can we develop a solution? Are there any alternative solutions? 3. Executing the plan Taking action Tracking the result Is the plan being followed? Can the solution be traced to the model?
R.G.Kumar/Asst.,Prof/CSE/SIETK Page 5

SOFTWARE ENGINEERING: I-M.Tech(CSE) I-Sem

Does the solution conform to the plan? 4. Examine the results Can we check the results? Can the solution be derived differently? Can we reuse the solution? Dose the solution satisfied the stakeholders? Seven Core Principles for Software Engineering 1) Remember the reason that the software exists The software should provide value to its users and satisfy the requirements 2) Keep it simple, stupid (KISS) All design and implementation should be as simple as possible 3) Maintain the vision of the project A clear vision is essential to the projects success 4) Others will consume what you produce Always specify, design, and implement knowing that someone else will later have to understand and modify what you did 5) Be open to the future Never design yourself into a corner; build software that can be easily changed and adapted 6) Plan ahead for software reuse Reuse of software reduces the long-term cost and increases the value of the program and the reusable components 7) Think, then act Placing clear, complete thought before action will almost always produce better results The Essence of SE Principle is Communication Principles 1) Listen to the speaker and concentrate on what is being said 2) Prepare before you meet by researching and understanding the problem 3) Someone should facility the meeting and have an agenda 4) Face-to-face communication is best, but also have a document or presentation to focus the discussion 5) Take notes and document decisions 6) Strive for collaboration and consensus 7) Stay focused on a topic; modularize your discussion 8) If something is unclear, draw a picture 9) Move on to the next topic a) after you agree to something, b) if you cannot agree to something, or c) if a feature or function is unclear and cannot be clarified at the moment 10) Negotiation is not a contest or a game; it works best when both parties win Planning Principles 1) Understand the scope of the project
R.G.Kumar/Asst.,Prof/CSE/SIETK Page 6

SOFTWARE ENGINEERING: I-M.Tech(CSE) I-Sem

2) Involve the customer in the planning activity 3) Recognize that planning is iterative; things will change 4) Estimate based only on what you know 5) Consider risk as you define the plan 6) Be realistic on how much can be done each day by each person and how well 7) Adjust granularity as you define the plan 8) Define how you intend to ensure quality 9) Describe how you intend to accommodate change 10) Track the plan frequently and make adjustments as required Analysis Modeling Principles 1) The information domain of a problem (the data that flows in and out of a system) must be represented and understood 2) The functions that the software performs must be defined 3) The behavior of the software (as a consequence of external events) must be represented 4) The models that depict information, function, and behavior must be partitioned in a manner that uncovers detail in a layered (or hierarchical) fashion 5) The analysis task should move from essential information toward implementation detail Design Modeling Principles 1) The design should be traceable to the analysis model 2) Always consider the software architecture of the system to be built 3) Design of data is as important as design of processing functions 4) Interfaces (both internal and external) must be designed with care 5) User interface design should be tuned to the needs of the end-user and should stress ease of use 6) Component-level design should be functionally independent (high cohesion) 7) Components should be loosely coupled to one another and to the external environment 8) Design representations (models) should be easily understandable 9) The design should be developed iteratively; with each iteration, the designer should strive for greater simplicity Coding Principles (Preparation before coding) 1) Understand the problem you are trying to solve 2) Understand basic design principles and concepts 3) Pick a programming language that meets the needs of the software to be built and the environment in which it will operate 4) Select a programming environment that provides tools that will make your work easier 5) Create a set of unit tests that will be applied once the component you code is completed
R.G.Kumar/Asst.,Prof/CSE/SIETK Page 7

SOFTWARE ENGINEERING: I-M.Tech(CSE) I-Sem

Coding Principles (As you begin coding) 1) Constrain your algorithms by following structured programming practices 2) Select data structures that will meet the needs of the design 3) Understand the software architecture and create interfaces that are consistent with it 4) Keep conditional logic as simple as possible 5) Create nested loops in a way that makes them easily testable 6) Select meaningful variable names and follow other local coding standards 7) Write code that is self-documenting 8) Create a visual layout (e.g., indentation and blank lines) that aids code understanding Coding Principles (After completing the first round of code) 1) Conduct a code walkthrough 2) Perform unit tests (black-box and white-box) and correct errors you have uncovered 3) Refactor the code Testing Principles 1) All tests should be traceable to the software requirements 2) Tests should be planned long before testing begins 3) The Pareto principle applies to software testing 80% of the uncovered errors are in 20% of the code 4) Testing should begin in the small and progress toward testing in the large Unit testing --> integration testing --> validation testing --> system testing 5) Exhaustive testing is not possible Deployment Principles 1) Customer expectations for the software must be managed Be careful not to promise too much or to mislead the user 2) A complete delivery package should be assembled and tested 3) A support regime must be established before the software is delivered 4) Appropriate instructional materials must be provided to end users 5) Buggy software should be fixed first, delivered later A Generic Process Model (Framework): * It identifying a small number of framework activities that are applicable to all software projects, regardless of their size (or) complexity * The process framework include a set of umbrella activities, that are applicable across the entire software process Framework Activity: * It contains a set of software engineering actions [A collection of related tasks that produces a major software engineering work product] Ex: Design is a software engineering action * Each action contain individual work tasks * The work tasks accomplish some part of the work implied by the action
R.G.Kumar/Asst.,Prof/CSE/SIETK Page 8

SOFTWARE ENGINEERING: I-M.Tech(CSE) I-Sem

Generic Framework Activities: (1) Communication: * It involves heavy communication and collaboration with the customer * Also it includes requirement gathering and related activities (2) Planning: * It describes the => Technical tasks to be conducted => The risks that are expected => Resources that will be required => Work products to be produced => Work Schedule (3) Modeling: * It describes the creation of models that allow the developer and the customer to understand software requirements and design for those requirements (4) Construction: * It combines => Code generation [either manual (Or) automated] => Testing [Required uncovering errors in the code]
R.G.Kumar/Asst.,Prof/CSE/SIETK Page 9

SOFTWARE ENGINEERING: I-M.Tech(CSE) I-Sem

(5) Deployment: * The software is delivered to customer * Customer evaluates the delivered product * Customer provides feedback based on the evaluation * These generic framework activities can be used during the; => Development of small programs => Creation of large web applications => Engineering of large complex computer based systems * The software process is different in each case, but framework activities remain same Umbrella Activities: (1) Software project tracking and control: * Allow the software team to progress against the project plan * If necessary take action to maintain schedule (2) Risk Management: * Find risks that may affect the outcome of the project (or) quality of the product (3) Software quality assurance: * It defines and conducts the activities required to ensure software quality (4) Formal Technical Reviews: * Before propagated to the next action (Or) activity, remove uncover errors (5) Measurements: * It defines and collects process, projects and product measures that help the team in delivering software * It can be used in conjunction with other framework and umbrella activities (6) Software configuration management: * It manages the effects of change throughout the software process (7) Reusability management: * It establishes mechanism to achieve reusable components * It defines criteria for work product reuse (8) Work product preparation and production: * It includes the activities required to create work products such as, => Models => Documents => Logs, forms and lists Process Patterns: Definition: * It is defined as set of activities, actions, work tasks, work products and related behaviors required to develop computer software * In general terms it provides a template [i.e. a consistent method for describing an important characteristic of the software process] * By combining patterns a process meets the need of a project * Patterns can be defined at any level of abstraction.
R.G.Kumar/Asst.,Prof/CSE/SIETK Page 10

SOFTWARE ENGINEERING: I-M.Tech(CSE) I-Sem

For example it might be used to describe => a complete process [ex: Prototyping] => an important framework activity [ex: Planning] => a task with in a frame work activity [ex: Project Estimating] Templates for describing a process pattern (1) Pattern Name: It gives a meaningful name that describes its function within the software process Ex: Customer Communication (2) Intent: The objective of the pattern is described Ex: The intent of customer communication is => to establish a collaborative relationship with the customer, in an effort to define project scope, business requirements etc.. (3) Type: The pattern type is specified, it suggests three types: (a) Task patterns: It define a software engineering action that is part of the process and relevant to successful software engineering practice Ex: Requirements gathering (b) Stage pattern: It defines a frame work activity for the process [i.e. a stage pattern incorporates multiple task patterns that are relevant to the stage] Ex: Communication This pattern would incorporate the task pattern requirement gathering and others (c) Phase patterns: It define the sequence of frame work activity that occur with the process, even when the overall flow of activities is iterative in nature Ex: Spiral model (Or) Prototyping (4) Initial context: It describes the conditions under which the pattern applies. Some queries asked prior to ignition of the pattern. They are => What organizational (Or) team related activities have already occurred? => What is the entry state for the process? =>What software engineering information (Or) project information already exists? Ex: Planning pattern [a stage pattern] * It requires that; => Customer and software engineer have establish a collaborative communication => Successful completion of a number of task patterns has occurred => Project scope, basic business requirements and project constraints are known (5) Problem: It described the problem to be solved by the pattern Ex: The problem to be solved by customer communication might be in
R.G.Kumar/Asst.,Prof/CSE/SIETK Page 11

SOFTWARE ENGINEERING: I-M.Tech(CSE) I-Sem

=> Communication between developer and customer is inadequate because an effective format for eliciting information is not established => A useful mechanism for recording is not created => Meaningful reviews are not conducted (6) Solution: It describes the implementation of the pattern. It also discusses; => How the initial state of the process that exist before the pattern is implemented => How software engineering information (Or) project information that is available before initiation of the pattern (7) Resulting Context: It describe the condition that will result, once the pattern has been successfully implemented * After the completion of the pattern we ask; => What team related activities must have occurred? => What is the exit state of the process? => What project information has been developed? (8) Related patterns: A list of process pattern, that are directly related to this one are provided as a hierarchy (Or) in some other diagrammatic form Ex: The stage pattern communication includes the task patterns such as => Project team assembly => Collaborative guideline definition => Scope Isolation => Requirement gathering => Constraint description and => Model creation (9) Known uses / examples: It indicates the specific instances in which the pattern is applicable Ex: Communication is mandatory at the beginning of every software project, it is recommended throughout software project Conclusion: * Process patterns provide an effective mechanism for describing any software process * It enables a software organization to develop hierarchical process description * Once process patterns have been developed, they can be reused for definition of process variants [i.e. a customized process model can be defined by a software team, using the patterns as building blocks for the process model] Process Assessment and Improvement: * The software process gives no guarantee that; => Software will be delivered on time => It will meet the customer needs * In addition the process should be accessed to ensure that it meets a set of basic process criteria that have been essential for a software engineering
R.G.Kumar/Asst.,Prof/CSE/SIETK Page 12

SOFTWARE ENGINEERING: I-M.Tech(CSE) I-Sem

* The relationship between the software process and methods applied for assessment and improvement are shown below

Software Process Assessment Different approaches (1) Standard CMMI Assessment Methods for Process Improvement [SCAMPI] * It provides a five step process assessment model. They are i. Initiating ii. Diagnosing iii. Establishing iv. Acting v. Learning (2) CMM Based Appraisal for Internal Process Improvement [CBAIPI] * It provides a diagnosing techniques for assessing the relatively maturity of a software organization (3) SPICE [ISO / IEC 15504] * It defines a set of requirements for software process assessment * This standard helps the organization in developing an objective evaluation of any defined software process (4) ISO 9001: 2000 for Software * This standard is applied to any organization that wants to improve; => the over all quality of the products, systems, services it provides * This standard is directly applicable to software organizations and companies * This standard uses a Plan do Check act cycle that is applied to quality management elements of software projects Plan => It establishes the process objectives, activities and tasks necessary to achieve high quality software and resultant customer satisfaction Do => It implements the software products [including both framework and umbrella activities] Check => It monitors are measures the process to ensure that all requirements established for quality management have been achieved Act => It initiates the software process improvement activities that continually work to improve the process
R.G.Kumar/Asst.,Prof/CSE/SIETK Page 13

SOFTWARE ENGINEERING: I-M.Tech(CSE) I-Sem

The Capability Maturity Model Integration [CMMI] Purpose: The purpose of CMMI is to provide guidance for improving organizations processes and your ability to manage the development, acquisition, and maintenance of products or services. * It is developed by Software Engineering Institute [SEI] * It is a comprehensive process meta-model that is predicated on a set of system * A organization can reach a different levels of process capability and maturity by develop a process model based on CMMI guidelines * The CMMI represents a process meta-model in two different ways: => Continues Model => Staged Model (1) Continuous CMMI Model: * Lets organization select specific improvement that best meet its business objectives and minimize risk * Levels are called capability levels. * Describes a process in 2 dimensions * Each process area is assessed against specific goals and practices and is rated according to the following capability levels.

R.G.Kumar/Asst.,Prof/CSE/SIETK

Page 14

SOFTWARE ENGINEERING: I-M.Tech(CSE) I-Sem

Level 1: Initial Processes are usually ad hoc and chaotic Organization usually does not provide a stable environment Maturity level organizations often produce products and services that work Maturity level organizations are characterized by: o Tendency to over commit o Abandon processes in the time of the crisis o Not be able to repeat their past successes Level 2: Managed Organization has achieved all the specific and generic goals Projects of the organization have ensured that: o Requirements are managed o Processes are planned o Performed, measured, and controlled Level 3: Defined Processes are well characterized, and understood, are described in standards, procedures, tools and methods The organizations set of standard processes, is established and improved over time Establishing consistency across the organization
R.G.Kumar/Asst.,Prof/CSE/SIETK Page 15

SOFTWARE ENGINEERING: I-M.Tech(CSE) I-Sem

Level 4: Quantitatively Managed Sub processes are selected that significantly contribute to overall process performance As criteria in managing process the quantitative objects for quality are established Quantitative objectives are based on: o Needs of a customer o End users o Organization o Process implements For these processes, detailed measures of process performance are collected and statistically analyzed Level 5: Optimizing Focuses on continually improving process performance through: o Incremental technological improvements o Innovative technological improvements Both processes are the organizations set of measurable improvement activities Four Categories of CMMI Process Areas 1. Process Management process areas contain the cross-project activities related to defining, planning, resourcing, deploying, implementing, monitoring, controlling, appraising, measuring, and improving processes. 2. Project Management process areas cover the project management activities related to planning, and controlling the project. 3. Engineering process areas cover the development and maintenance activities that are shared across engineering disciplines. 4. Support process areas cover the activities that support product development and maintenance. Behaviors at the Five Levels

R.G.Kumar/Asst.,Prof/CSE/SIETK

Page 16

SOFTWARE ENGINEERING: I-M.Tech(CSE) I-Sem

(2) Staged CMMI Model: * It defines the same process area, goals and practices as continuous model * This model is used if you have no clue of how to improve the process for quality software. * It gives a suggestion of what things other organizations have found helpful to work first * Levels are called maturity levels

Software Myths: * It is beliefs about software * The process used to built it, can be traced to the earliest days of computing * The myth have a number of attributes that have made them insidious [i.e. proceeding inconspicuously but harmfully] * For instance myths appear to be reasonable statements of facts [Sometimes containing elements of truth] (1) Management Myths: * Managers in most disciplines are often under pressure to maintain budget, keep schedules from slipping and improve quality * A software manager often grasp at belief in a software myth, if that belief will lessen the pressure Myth 1: We already have a book that is full of standards and procedures for building software..Wont that provide my people with everything they need to know? Reality: => The book of standards may well existsBut is it used? => Are software practitioners aware of its existence? => Does it reflect modern software engineering practices? => Is it complete? Is it adaptable? => Is it streamlined to improve time to delivery while still maintaining a Focus on quality?
R.G.Kumar/Asst.,Prof/CSE/SIETK Page 17

SOFTWARE ENGINEERING: I-M.Tech(CSE) I-Sem

* In many cases the answer to all of these questions is NO Myth 2: If we get behind schedule, we can add more programmers and catch up [Some times called Mongolian horde Concept] Reality: * Adding people to a late software project makes it later * As new people are added, people who were working must spend time in educating the new comers, thereby reducing the amount of time spent on productive development effort * People can be added, but only in a planned and well coordinated manner Myth 3: If I decide to outsource the software project to a third party, I can just relax and let that firm build it Reality: * If an organization does not understand, how to manage and control software projects internally, it will invariably struggle when it out sources software projects (2) Customer Myths: * The customer who requests computer software may be, => a person => a technical group => a marketing / sales department (or) => an outside company * In many cases customer believes myths about software * Myths lead to false expectations (by the customer) and ultimately, dissatisfaction with the developer Myth 1: A general statement of objectives is sufficient to begin writing programs We can fill in the detail later Reality: * An ambiguous statement {i.e. having two meanings} leads to a serious of problems *But Unambiguous statements are developed only through effective and continuous communication between customer and developer * So comprehensive and stable statements of requirements is not always possible Myth 2: Project requirements continually change, but changes can be easily accommodated because software is flexible Reality: * When requirements changes are requested early [before design (Or) code has been started] cost impact is relatively small * When requirement changes are requested after design (Or) code has been started cost impact is too high

R.G.Kumar/Asst.,Prof/CSE/SIETK

Page 18

SOFTWARE ENGINEERING: I-M.Tech(CSE) I-Sem

* The change can cause upheaval [i.e. Violent change (Or) disturbance] that require additional resources and major design modification (3) Practitioners Myth: Myth 1: Once we write the program and get it to work our job is done Reality: * Industry data indicate that between 60 and 80 percent of all efforts expended on software will be expanded after it 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: * Apply any one of the effective software quality mechanism, from the beginning of the project * Software quality reviews are more effective than testing for finding certain classes of software errors Myth 3: The only deliverable work product for a successful project is the working program. Reality: * A work program is part of software configuration that includes many elements. * But documentation only provides a foundation for successful engineering and support for software Myth 4: Software engineering will make us create voluminous and unnecessary documentation and will invariably slow us down Reality: * Software engineering is not about creating documents, it about creating quality * So better quality leads to reduced rework * Reduced rework leads to faster delivery times Conclusion: * Many software professionals recognizes the fallacy [ i.e. mistaken belief] of software myths, this will indirectly promote the poor management and technical practices * But recognition of software realities is the first step toward formulation of practical solutions for software engineering

R.G.Kumar/Asst.,Prof/CSE/SIETK

Page 19