SE.pdf

UNIT-1 INTRODUCTION TO SOFTWARE ENGINEERING 1.1 Software  Software is a collection of computer programs that when executed together with data provide desired outcomes.  There exist several definitions of software in the software engineering literature.  IEEE defines software as:  ”Sof...

UNIT-1 INTRODUCTION TO SOFTWARE ENGINEERING 1.1 Software  Software is a collection of computer programs that when executed together with data provide desired outcomes.  There exist several definitions of software in the software engineering literature.  IEEE defines software as:  ”Software is a collection of computer programs, together with data, procedures, rules, and associated documentation, which operate in a specified environment with certain constraints to provide the desired outcomes.”  The view of computer software is shown in figure given below. Data Procedures Software Programs Rules Documentation Fig :Software View  A program can be simple input-process-output statements, a function, a component, or program libraries.  Software is developed by software engineers for an organization on the requirement of a customer and it is used by the end users.  The general attributes of software are efficiency, maintainability, interoperability, portability, usability, performance, understandability, and reliability. 1.1.1 Characteristics of software : (I)Software has logical properties rather than physical  Software is an intangible product and has no physical properties.  Ithas no shape, no volume, no color, and no odor.  Therefore, it is not affected by the physical environment.  Software logically consists of several programs connected through well-defined logical interfaces. 1  In spite of having no physical properties, software products can be measured (e.g., size) estimated (e.g., cost, time, and budget), and their performance (e.g., reliability, usability) can be calculated. (II) Software is produced in an engineering manner rather than in a classical manner  Unlike other products which are manufactured in the classical manner, software is produced in an engineering manner. (III)Software is mobile to change  Software is a too much flexible product that it can easily be changed. (IV)Software becomes obsolete but does not wear out or die  Software becomes obsolete due to the increasing requirements of the users and rapidly changing technologies.  Software products do not wear out as they do not have any physical properties.  Hardware products can wear out due to environmental maladies and high failure rate.  Software does not die but it can be made to retire after reengineering of the existing software milestones and the product becomes alive again. (V) Software has a certain operating environment, end user, and customer  Software products run in a specified environment with some defined constraints.  Some software products are platforms independent while others are platform specific. (VI) Software development is a labor-intensive task 1.1.2 Software Classifications  Software can be either generic or customized.  Generic software products are developed for general purpose, regardless of the type of business.  Word processors, calculators, database software, are the examples of generic software.  Customized software products are developed to satisfy the need of a particular customer in an organization.  Order processing software, inventory management software, patient diagnosis software are the examples of customized software. 2   Generic and customized software products can again divided into several categories depending upon the type of customer, business, technology, and computer support.  A category of software products is shown in Figure given below Software Generic Software Customized Software System Application Programming AI Engineering/ Web Product-line software Software Software software Scientific software software software Fig: Software Classification softwarw System Software:  It is the computer software that is designed to operate the computer hardware manage the functioning of the application software running on it.  Examples of system software are device drivers, boot program, operating systems, servers, utilities, and so on. Such software reduces the burden of application programmers. Application Software  Application Softwareis designed to accomplish certain specific needs of the end user.  Sale transaction software, educational software, video editing software, word processing software, database software aresome examples of application software. Programming Software:  Programming software is the class of system software that assists programmers in writing computer programs using different programming languages in a convenient manner. 3 Artificial Intelligence(AI) software  AI software is made to think like human beings and therefore it is useful in solving complex problems automatically.  Game playing, speech recognition,understanding natural language. Computer vision, expert systems, robotics are some applications of AI software. Embedded software  Embedded software is a type of software that is built into hardware systems.  Controllers, real-time operating systems, communication protocols are some examples of embedded software. Engineering /Scientific software  Engineering problems and quantitative analysis are carried out using automated tools.  Scientific software is typically used to solve mathematical functions and calculations.  Computer-aided design and computer-aided manufacturing software (CAD/CAM) , electronic design automation (EDA), embedded system software (ESS), statistical process control software (SPCS), civil engineering and architectural software, math calculation software, modeling and simulation software, etc.., are the examples of engineering scientific software. Web software  Web applications are base on client server architecture, where the client request information and the server stores and retrieves information from the web software.  Examples include HTML 5.0,JSp,ASP,PHP etc Product-Line software  Product-line software is a set of software intensive systems that share a common, managed set of features to satisfy the specific needs of a particular market segment or mission.  Some common applications are multimedia, database software, word processing software, etc,. 4 1.2 Software Crisis  It is a term coined in 1960’s to indicate financial losses in software industry due to catastrophic (unrecoverable) failures of software, inefficientsoftware, low quality software, delivering software after scheduled dates or with errors etc.  The causes of software crisis are: i. Projects running over-budget. ii. Projects running over-time. iii. Delivering inefficient software, low quality software, unreliable software etc iv. Software’s not satisfying requirements of customer. v. Software failures. vi. Malfunctioning of software systems.  Standish Group has disclosed a report in 2003 which shows the percentage of successful projects is 28, cancelled projects is 23, and challenged projects is 49.  Most of the projects were cancelled and challenged because they were running behind schedule and exceeded the budget.  There are several such problems in the software industry.  Software products become costly,are delivered late, are unmanaged, have poor quality, decrease the productivity of the programmers, increase the maintenance cost and rework, and lack mature software processes in a complex project.  The solution to these software crisis is to introduce systematic software engineering practices for systematic software development, maintenance, operation, retirement, planning, and management software. 1.3 What Is Software Engineering  “Software engineering is an engineering, technological, and managerial discipline that provides a systematic approach to the development, operation, and maintenance of software”.  In this definition, the keywords have some specific meanings.  Engineering provides a step-by-step procedure for software engineering that is project planning, problem analysis, architecture and design, programming, testing and integration, deployment and maintenance, and project management.  These activities are performed with the help of technological tools that ease the execution of above activities. 5  For example, project management tools, analysis tools, design tools, testing tools coding tools and various CASE tools.  Systematic approach means the methodological and pragmatic way of development , operation, and maintenance of software.  Development means the construction of software through a series of activities that is analysis, design, coding, testing and deployment.  Maintenanceis required due to existence of errors and faults, modification of existing features, addition of new features and technological advancements.  IEEE defines software engineering as “The systematic approach to the development, operation, maintenance, and retirement of software”.  The main goal of software engineering is to understand customer needs and develop software with improved quality, on time and within budget  The view of software engineering is shown in Figure given below Satisfies quality criteria Customer needs Software Systematic approach Fig: Software engineering view 1.4 EVOLUTION OF SOFTWARE ENGINEERING METHODOLOGIES  A software engineering methodology is a set of procedures followed from the beginning to the completion of the development process.  The most popular software are methodologies are:  Exploratory methodology  Structure-oriented methodology  Data-structure-oriented methodology  Object oriented Methodology  Component-based development methodology 6 The evolution of software engineering methodology is shown in the figure given below Programming Technology Component Programming Component Oriented Object oriented Programming CBD Parallel Programming Object Oriented Models Data Structure Oriented OOA/OOD High level Programming Models JSD Models Structure oriented SA\SD Models Unstructured Programming Exploratory Methodology State Models Programming Complexities FIG: Evolution of Software engineering methodologies Exploratory Methodology:  Exploratory style uses unstructured programming or design heuristics for program writing, where the focus is given on global data items.  Unstructured languages ,such as assembly or low-level languages, BASIC, etc., consists of a sequence of commands or statements ,such as labels, GOTO ,etc.,  State-oriented models, such as flow charts, finite state machines (for example, DFAs, NFAs, PDAs,),Turing machines, etc., are used for the design of algorithms STRUCTURE ORIENTED METHODOLOGY  Structured methodology focuses on procedural approach, which, concentrates on developing functions or procedures.  It uses the features of the unstructured programming and provides certain improvements.  It has three basic elements, namely, Sequence: The order in which instructions are executed is the sequence of programming 7  Selection: If else condition statements and other forms of selection from the second element.It is because of selection that a program react to choices Iteration: The use of loops and other forms of repetitive sets of instructions forms the last building block of procedural programming.  Structure oriented methodology uses a variety of notations, such as data flow diagrams (DFD),data dictionary ,control flow graphs(CFG),entity relationship(ER)diagrams ,etc., to design the solutions to the problem.  Structured –oriented approach is preferred in scripts and embedded systems with small memory requirements and high speed. DATA-STRUCTURE-ORIENTED METHODOLOGY  Data-structure-oriented methodology concentrates more on designing data structures rather than on procedures and control.  Jackson structured design(JSD) methodology developed by Michael Jackson in 1970 is a famous Data-structure-oriented methodology that expresses how functionality fits in with the real world.  It describes the real world in terms of entities, actions, and ordering of actions.  JSD-Based development proceeds in two stages: firstly, specifications that determines “what”, and secondly, implementation that determines “How”.  JSD is a useful methodology for concurrent software, real time software, micro code, and for parallel computers. OBJECT-ORIENTED-METHODOLOGY  Object oriented methodology emphasizes the use of data rather than functions.  Object oriented methodology has three important concepts: Modularity, Abstraction and Encapsulation.  Object oriented analysis(OOA)and Object oriented design (OOD) Techniques are used in Object oriented methodology.  OOA is used to understand the requirements by identifying the objects and classes, their relations to other classes, their attributes, and the inheritance relations ship among them  OODcreates object models and maps the real world situation into the software structure. 8 COMPONENT-BASED DEVELOPMENT METHODOLOGY(CBD)  Component-based development(CBD) becomes significant methodology for communication among different stake holders and for large-scale reuse.  CBD is a system analysis and design methodology that has evolved from the Object oriented methodology.  CBD employs are architectural elements, such as user interface layer: business layer that includes process components business domain components and the business infrastructure components and technical infrastructure components and technical infrastructure layer 1.5 SOFTWARE ENGINEERING CHALLENGES We will briefly discuss some software engineering challenges: (1) PROBLEM UNDERSTANDING  There are several issues involved in problem understanding.  Usually customers are from different backgrounds and they do not have a clearunderstanding of their problems and requirements.  Also, the customers don’t have technical knowledge, especially those who are living in remote areas.  Similarly, software Engineers do not have the knowledge of all application domains and detailed requirements of the problems and the expectations of the customer.  The lack of communication among software engineers and customers causes problems for the software engineers in clearly understanding the customer needs.  Sometimes the customers do not have the sufficient time to explain their problems to development organization (2) QUALITY AND PRODUCTIVITY  Quality products provide customer satisfaction.  A good quality products implements features that are required by the customer.  Systematic software engineering practices produce products that have certain quality attributes, such as reliability, usability, efficiency, maintainability, portability and functionality.  Production of software is measured in terms of KLOC per person month(PM).  Software companies focus on improving the productivity of the software, i.e., increasing the number of KLOC per PM. 9  Higher productivity means that cycle time can be reduced with the low cost of the product.  But the productivity and the quality of the software depend on several factors, such as programmer’s ability ,type of technology, level of experience, nature of the projects and their complexity, available time, development and maintenance approach, stability of requirements , managerial skills , required resources, etc. (3) CYCLE TIME AND COST  Software companies put efforts to reduce the cycle time of product delivery and minimize the product cost.  The cost of the software product is generally the cost of the software, hardware and manpower resources.  It is calculated on the basis of the number of the person engaged in a project and for how much time. The cost of the product also depends on the project size and nature.  There are some other factors that can affect the time to market and cost, such as level of technology , application experience, and the availability of the required resource.  Higher the cycle time higher the product cost.  The cost is finally converted into a dollar amount for standard representation. (4) RELIABILITY:  Verification and the validation techniques are used to ensure the reliability ratio in the product.  Defect Detection and the prevention is the prerequisite to high reliability in the product.  Software becomes unreliable due to logical errors present in the programs of the software.  Project complexity is the major issue cause of software unreliability.  Due to unreliable software more than hundred failures were reported in a day at a single air traffic control location in 1989; 22 fatal crashes of the fly-by-wire UH-60 helicopter took place; patients were given the fatal doses by malfunctioning hospital computers.  Therefore Software engineers spend more than 75% of time on development in keeping the computer and software up to date. (5) CHANGE AND MAINTENANCE:  Change and maintenance in software come when the software is delivered and deployed at the customer site. 10  They occur if there is any change in the business operations, errors in the software, addition of some new features.  Due to repeated maintenance and change, software deteriorates its operational life and quality.  Thus to accommodate increasing requirements and stream line the modern technology ,software is needed to be reengineered on to a modern platform. (6) USABILITY AND REUSABILITY  Usability means the ease of use of a product in terms of efficiency ,effectiveness, and customer satisfaction.  Reuse of the existing software components and their development has become an institutional business in the modern software business scenario.  The analysis of domain knowledge ,development of reusable library ,and integration of reusable of components in software development are some important issues in reuse based development.  Reusability increases reliability because reusable components are well tested before integrating them into software development (7) REPEATABILITY AND PROCESS MATURITY  Repeatability maintains the consistency of product quality and productivity.  Repeatability can help to plan project schedule ,its deadlines for product delivery ,manage configuration, and identify locations of bug occurrences.  Repeatability promotes process maturity.  A maturity software process produces quality products and improves software productivity.  There are several standards , such as CMM,ISO and Six sigma ,which emphasize process maturity and guidelines. (8) ESTIMATION AND PLANNING  Present estimation methods, such as lines of codes(LOC),function point(FP),and objective point(OP),are sometimes enable to accurately estimate project efforts.  It is observed that the project failure ratio is greater the success rates.  Most of the projects fail due to underestimation of budget and time to complete the project 11 Software Myths : 1. Management myths. 2. Customer myths 3. Practitioner’s myths 1. Management myths Myth 1 : We already have a book that’s full of standards and procedures for building software. Won’t that provide my people with everything they need to know? Myth 2: If we get behind schedule, we can add more programmers and catch up (sometimes called the “Mongolian horde” concept). Myth 3: If I decide to outsource the software project to a third party, I can just relax and let that firm build it. 2.Customer myths Myth 1 : A general statement of objectives is sufficient to begin writing programs—we can fill in the details later Myth2 : Software requirements continually change, but change can be easily accommodated because software is flexible. 3. Practitioner’s myths Myth 1 : Once we write the program and get it to work, our job is done. Myth 2 : Until I get the program “running” I have no way of assessing its quality. Myth 3: The only deliverable work product for a successful project is the working program. Myth 4: Software engineering will make us create voluminous and unnecessary documentation and will invariably slow us down. 12  1.6 SOFTWARE PROCESS  A software process is a set of ordered activities carried out to produce a software product.  Each activity has well-defined objective,task, and outcome.  An activity is a specified task performed to achieve the process objectives.  Each activity of a software process involves tools and technologies( for example CASE tools, compiler,.Net etc), procedures, ( for example algorithms, installation procedure etc)and artifacts(theintermediate or final outcomes).  A software project is an entity , with defined start and end, in which a software process is being used.  Software project is a cross functional entity which is developed through a series of projects using the required resource.  A successful project is the one that conforms with the project constraints (cost, schedule, and quality criteria).  A product is the outcome of a software project produced through processes.  Thus, process, project, product are interrelated to each other for the development of software.  The relationship between process, project and product is shown in the figure below: Figure: Process, project and product Process Used Needs of client Converted into Produces Project Product Used in Resources 1.6.1 SOFTWARE PROCESS MODEL  A software process model is a generic representation of a software process instantiated for each specific project. 13  A project model is a set of activities that have to be accomplished to achieve the process objectives.  Process models specify the activities, work products, relationships, milestones, etc.  Some examples of process models are data flow models, life cycle model, Quality model, etc.  A generic view of the software process model is shown in fig given below Fig: Generic representation of a process model Definition Phase Umbrella Activities Development Phase Implementation Phase  The Generic process model has three phases that are coordinated and supported by umbrella activities.  The phases in a process model are (i) Definition Phase  This phase concentrates on understanding the problem and planning for the process model  The activities may include Problem formulation, Problem Analysis, System engineering, and project planning for the process. (ii) Development Phase:  This phase focuses on determining the solutions of the problem with the help of umbrella activities.  The main activities of this phase are designing the architecture and algorithms of the system,writing codes , and testing the software. (iii) Implementation Phase  Deployment, Change Management, Defect Removal, and Maintenance activities are performed in this Phase. 14  Reengineering may takes over due to the changes in the technology and business. 1.6.2 ELEMENTS OF SOFTWARE PROCESS:  A software process comprises various essential elements.  These elements are discussed as follows: (1) ARTIFACTS:  Artifacts are tangible work products produced during the development of software.  Examples of artifacts include software architecture, project plan, etc. (2) ACTIVITY:  Activity specifies the task to be carried out implicitly or explicitly each activity uses some procedures , rules, policies and guidelines to produce required artifacts.  Examples for Activity include analysis, design, tracking and monitoring etc. (3) CONSTRAINTS:  Constraints refers to the criteria or condition that must be met or processed by a software product.  Examples include, a machine allows five users to login at a time, permits seven transaction per nanoseconds etc. (4) PEOPLE:  People are persons or stakeholders who are directly or indirectly in the process.  Stakeholders play important role in achieving project goals, software tester quality checker etc.  Examples of stakeholders include software engineers, system analyst, project managers, designers, Architects, Release Managers etc. (5) TOOLS AND TECHNOLOGY:  Tools and technology provides technical support to the methods are techniques to be used for performed the activites.  Examples include FORTRAN is suitable for scientific problems, CASE tools support in software development. (6) METHOD OR TECHNIQUE:  Methods or techniques specifies the way to perform an activity using tools and technology to accomplish the activity.  It Provides detail mechanism to carry out an activity. 15   Examples include object oriented analysis (OOA), binary search etc. (7) RELATIONSHIP:  Relationship specifies the link among various activities or entities.  Examples include, maintenance followed by implementation,debugging is required after error detection etc. (8) ORGANIZATIONAL STRUCTURE:  Organizational structure specifies the team of people that should be coordinated and managed during software development.  Examples include, the project leader monitors the work flow of various activites which are assigned to the software engineers. 1.6.3 CHARACTERISTICS OF A SOFTWARE PROCESS:  There are certain common characteristics of a software process, which are discussed below. (1) UNDERSTANDABILITY:  The process specification must be easy to understand, easy to learn,and easy to apply. (2) EFFECTIVENESS:  Effectiveness of a product depend s on certain performance indicators,such as programmer’s, skills,fund availability,quality of work products, etc. (3) PREDICTABILITY:  It is about forecasting the outcomes before the completion of a process.  It is the basis through which the cost,quality,and resource requirements are specified in a project. (4) MAINTAINABILITY:  It is the flexibility to maintain software through change requirements, defect detection and correction, adopting it in new operating environments.  Maintainability is a life-long process.  It is one of the primary objectives of a process to reduce the maintenance task in software.  Reduction inmaintenance definitely reduces a project cost. (5) RELIABILITY:  It refersto the capability of performing the intended tasks.  Unreliability of a process causes product failures and unreliable process waste time and money. (6) CHANGEABILITY:  It is the acceptability of changes done in software. 16  Changeability is classified asrobustness, modifiability, and scalability.  Robustness means that a process does not change the product quality due to its internal and external changes.  Scalability is the ability to change the attributes so that a process can be used in smaller to larger software development.  Modifiability is the ability of adoptability of change occurrence. (7) IMPROVEMENT:  It concentrates on identifying and prototyping the possibilities (strengths and weakness) for improvements in the process itself.  Improvement in a process helps to enhance quality of the delivered products for providing more satisfactory services to the users.  Process improvements is performed through quality attributes of a process and product development experiences from the process.  There are various process improvement standards, such as quality improvement paradigm(QIP),capability Maturity Integration(CMMI),etc. (8) MONITORING AND TRACKING:  Monitoring and tracking a process in a project can help to determine predictability and productivity.  It helps to monitor and track the progress of the project based up on past experiences of the process. (9) RAPIDITY:  Rapidity is the speed of a process to produce the products under specifications for its timely completion. (10) REPEATABILITY:  It measures the consistency of a process so that it can be used in various similar projects.  A process is said to be repeatable if it is able to produce an artifact number of times without the loss of quality attributes. There are various other desirable features of a software process, such as quality, adoptability, visibility, supportability, and so on. 1.7 PROCESS CLASSIFICATION:  Software processes may be classified as (1) Product development process (2) Project management process 17  (3) Change management process (4) Process improvements,and (5) Quality management process.  In this chapter, we will discuss various software development processes in detail.  The classified processes are discussed below in brief. PRODUCT DEVELOPMENT PROCESS  Product development processes focus mainly on producing software products.  These processes involve various techniques, tools and technologies for developing software.  Such processes include various activities like conceptualization, designing, coding, testing, and implementation of new or existing system.  These are certain work products of these activities, such as software requirement specifications(SRS), design models, source codes, test reports and documentation.  The most widely used software development process models are the waterfall model, prototyping model, spiral model, agile model, RUP, and so on.  Customer feedback, reusability, co-ordination, communication and documentation are some factors that help to decide the application of development process models PROJECT MANAGEMENT PROCESS  Project management processes concentrate on planning and managing projects in order to achieve the project objectives.  The goal of these processes is to carry out the development activities with in time, budget and resources.  Initiating, Planning, coordinating, controlling, executing, and terminating are the main activities of a general project management process.  The project manager is the key person for handling all the above activities in an organization.  The project manager designs teams, allocate the tasks and monitors the progress of the project team members so that the project could be completed on time and within budget. PROCESS IMPROVEMENT PROCESS  The ultimate goal of improvement in a process is to enable the organization to produce more quality products. 18  Sometimes, it becomes very difficult to apply an improved software process to achieve the specified results due to short delivery span, insufficient knowledge of the process and context, insufficient managerial support, and many other factors.  There exists various process improvement process model,such as CMMI,QIP, continuous quality improvement (CQI), total quality management (TQM),six sigma, band so on. CONFIGURATION OR CHANGE MANAGEMENT PROCESS:  Changes may occur in projects, processes, and products as these entities are evolutionary in nature.  Changes may arise due to either change in the customer requirements or discrepancies in the work products or procedures from the developer’s side.  Thus, identifying, evaluating, and finally implementing changes is the main function of software configuration management (SCM) process. configuration management includes various activities for performing changes , such as identification of configuration items, devising mechanisms for performing changes, controlling changes, and tracking the status of those changes QUALITY MANAGEMENT PROCESS:  A quality management process provides metrics, feedback, and guidelines for the assurance of product quality.  Software quality organization gives information and expertise to development and management process for quality production.  The main activities of software quality groups are verification and validation, acceptance testing, measurement and metrics, process consulting, and so on.  ISO 9000 is a framework that provides certain guidelines for the quality system. 1.8 PHASED DEVELOPMENT LIFE CYCLE:  A product development process is carried out as a series of certain activities for software production.  Each activity in the process is also referred to as phase.  *The standard outputs obtained at the end of every phase is called work products.*  Collectivity, these activity are called the software development lifecycle(SDLC)or simply software lifecycle and each of these activities is called life cycle phase. 19  These have been various software development life cycle models proposed for software development, based on the activities involved in developing and maintaining software.  Some of these models are waterfall, prototyping, spiral, incremental, agile process, RUP process model, and so on. 1.8.1 PHASED LIFE CYCLE ACTIVITIES:  The general development process activities which are covered in software development life cycle models are feasibility study, requirements analysis, and design, codingtesting, deployment, operation, and maintenance.  The software development life cycle various activities is pictorially represented in the figure given below. Client Needs SDLC Fig: Software Development Life Cycle Activities PROJECT INITIATION:  The main activities or work products of this phase are i. Studying, determining the feasibility (possibility) of anew system; and 20  ii. Define the scope, key elements, and a plan for the successful completion of the project. iii. Preliminary Investigation. iv. Feasibility Study. v. Project plan vi. Feasibility Report vii. Plan for schedule, cost, scope and objectives, expected risks, project charter, stakeholders, and sponsors, and resources.  Project initiation involves preliminary investigation, feasibility and a project plan.  Preliminary investigation(PI) is the initial step that gives a clear picture of what actually the physical system is.  PI goes through problem identification,background of the physical system,and the system proposal for a candidate system.  On the basis of this study,a feasibility study is performed.  The purpose of the feasibility study is to determine whether the implementation of the proposed system will support the mission and objectives of the organization.  Feasibility study ensure that the candidate system is able to satisfy the user needs; promotes operational, effective use of resources; and is cost effective.  There are various types of feasibility study performed, such as technical, economical, operational, and so on.  Technical feasibility:It refers to the availabilityof and expertise on technology in terms of hardware and software for the successful completion of a project.  Economic feasibility: It is used to evaluate the effectiveness of a system in terms of benefits and cost saving in a candidate system.  Cost/benefit analysis is carried out to determine economic feasibility.  If benefits of the candidate system outweigh its costs, then a decision is made to design and implement the system.  Operational feasibility: It states the system will meet the scope and problem of the users.  There are certain other feasibility studies,such as legal, schedule, resources, behavioral, cultural, and so on. REQUIREMENT ANALYSIS  The main activities or work productsof this phase are i. Requirements gathering 21  ii. Requirements Organization iii. Requirements documenting or specification iv. Requirements verification and validation.  Requirements analysis is the process ofcollecting factual data, understanding the process involved, defining the problem, and providing documents for further software development.  Requirements analysis is a systematic approach to elicit, organizes, and document requirements of a system.  The requirements analysis phase consist of three main activities: i. Requirements elicitation, ii. Requirements specification, iii. Requirements verification and validation.  Requirements elicitation is about understanding the problem.  Once the problem has been understood, it is described in the requirements specification documents, which is referred to as software requirement specification(SRS).  This document describes the product to be delivered, not the process of how it is to be developed.  Requirements verification and validation ascertain that correct requirements are stated (validation) and that these requirements are stated correctly (verification). SOFTWARE DESIGN  The goal of design phase is to transform the collected requirements into a structure that is suitable for implementation in programming languages.  The design phase has two aspects: Physical design and logical design.  Physical design is also called high-level design.  A high level design concentrates on identifying the different modules or components in system that interact with each other to create the architecture of the system.  In logical design, which is also known as detailed design, the internal logic of a module or component is described in a pseudo code or in an algorithmic manner.  The main activities or work productsof this phase are i. Developing architecture of a software system. ii. Developing algorithms for each component in the system. iii. Outlining the hierarchical structure. 22  iv. Developing E-R diagrams, DFD’s, UML diagrams etc. CODING  The coding phase is concerned with the development of the source code that will implement the design.  The main activities or work productsof this phase are i. Developing Source code using programming languages. TESTING  Testing is performed to remove the defects in the developed system.  The main activities or work productsof this phase are i. Detecting design errors, Requirements errors, Coding errors(syntax errors and logical errors). ii. Fixing/correcting/Removing errors iii. Preparing test cases, test plans, test reports etc DEPLOYMENT  The purpose of software deployment is to make the software available for operational use.  The main activities or work productsof this phase are i. Delivery of software to the customer. ii. Installing software at customer site. iii. Training employees at customer site. iv. Providing user manuals and documentation to the customer. MAINTENANCE  Software maintenance is performed to adapt to changes in a new environment, correct bugs, and enhance the performance by adding new features.  The main activities or work productsof this phase are i. Adding new features to existing software. ii. Changing the software environment. iii. Collecting new user requirements. iv. Fixing errors which are detected after software delivery. v. Preventing problems in the future. 1.9 SOFTWARE DEVELOPMENT PROCESS MODELS 23   Software development organizations follow some development process models when developing a software product.  The general activities of the software life cycle models are feasibility study, analysis, design, coding, testing, deployment, and maintenance.  We will discuss the following development process models  Classical waterfall model  Iterative waterfall model  Prototyping model  Incremental model  Spiral model  Agile process model  RUP process model 1.9.1 CLASSICAL WATERFALL MODEL  The waterfall model is a classical development process model proposed by R.W Royce in 1970.  In this model, software development proceeds through an orderly sequence of transitions from one phase to the next in order( like a waterfall).  There is no concept of Backtracking in this model. Feasibility Study Feasibility Report Requirements Analysis Requirement Document Software Design Document Design Coding Programs Testing and Integration Test Reports Deployment Release Reports Operation and Maintenance 24  Fig: Classical Waterfall Model  Using the waterfall model, it is observed that the maintenance effort in a software product is higher than the overall development effort.  From the experiences of past projects and literatures, the relative phase-wise efforts distribution in the waterfall model is  Requirements analysis 10%  Design 15%  Coding 10%  Testing 25%  Maintenance 40%  This result shows that the testing and maintenance phase requires more efforts than analysis, design, and coding.  The classical waterfall model is illustrated in the fig given below. Advantages of Classical waterfall model  Simple and easy to understand and use.  Easy to manage due to the rigidity of the model.  Works well for smaller projects where requirements are very well understood.  The amount of resources required to implement this model are minimal.  Development processed in sequential manner so very less chance to rework.  Due to straightforward organization of phases, it is fit for other engineering process models, such as civil, mechanical etc.  It is a document-driven process that can help new people to transfer knowledge. Disadvantages of Classical waterfall model  The model assumes that the requirements will not change during the project.  Once an application is in the testing stage, it is very difficult to go back and change something that was not well-constructed in the earlier stages.  No working software is produced until late during the life cycle.  It is very difficult to estimate time and cost in the waterfall model.  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. 25   Less effective if requirements are not very clear at the beginning. Projects where Classical Waterfall Method is suitable for SDLC:- (*Applicability*) 1) In development of database-related software, eg commercial projects. 2) In development of E-commerce website or portal. 3) In Development of network protocol software. Some situations where the use of Classical Waterfall model is most appropriate are(*Applicability*)  Requirements are very well documented, clear and fixed.  Product definition is stable or when changes in the project are stable.  Technology is understood and is not dynamic.  There are no ambiguous requirements.  Ample resources with required expertise are available to support the product.  The project is short or small.  For low budget projects. 1.9.2 ITERATIVE WATERFALL MODEL  Classical Waterfall model was enhanced with a feedback process, which is referred to as an iterative model.  The iterative waterfall model is an extended waterfall model with backtracking at each phase to its preceding phases.  This idea was also proposed by R W Royce in 1970.  The life cycle phases are organized similar to those in the classical waterfall model.  The development activities such as feasibility study, analysis, design, coding, testing, operation and maintenance are performed in a linear fashion.  The only difference between classical and iterative models is backtracking of phases on detection of errors at any stages.  The iterative waterfall model is shown in the figure given below: Feasibility Study Feasibility Report Requirements Analysis Requirement Document Software Design Document Design Coding Programs 26  Testing and Integration Test Reports Deployment Release Reports Operation and Maintenance Backtracking Fig: Iterative Waterfall Model Advantages of Iterative waterfall model  In iterative model we are building and improving the product step by step. Hence we can track the defects at early stages. This avoids the downward flow of the defects.  In iterative model we can get the reliable user feedback.  In iterative model less time is spent on documenting and more time is given for designing.  Waterfall model is simple to implement and also the amount of resources required for it are minimal.  In this model, output is generated after each stage (as seen before), therefore it has high visibility. Disadvantages of Iterative waterfall model  Each phase of iteration is rigid with no overlaps.  Costly system architecture or design issues may arise because not all requirements are gathered up front for the entire lifecycle.  Real projects rarely follow the sequential flow and iterations in this model are handled indirectly. These changes can cause confusion as the project proceeds.  It is often difficult to get customer requirements explicitly. Some situations where the use of Iterative Waterfall Method is most appropriate are (*Applicability*)  This model is most suitable for simple projects where the work products are well defined and their functioning is understood.  This methodology is preferred in projects where quality is more important as compared to schedule or cost. 27 1.9.3 PROTOTYPING MODEL  Prototyping is an alternative in which partial working software (i.e. a prototype) is initially developed instead of developing the final product.  IEEE defines Prototyping as a type of development in which emphasis is placed on developing prototype early in the development process to permit early feedback and analysis in support of the development process.  Prototype development is a toy implementation, which provides a chance to the customer to give feedback for final product development.  The Prototyping model is shown in figure Information Gathering Quick Design Refine Requirements Build Prototype Customer Evaluation Incorporate Customer Suggestions Customer Satisfied Design Coding Testing Deployment Maintenance FIG: Prototyping Model  This model starts with initial known requirements that may have been in the mind of customer.  A quick design is made and a prototype is developed.  The working prototype is evaluated by the customer.  Based on the customer feedback, the requirements are refined and the modified requirements are incorporated in the working prototype. 28  The development cycle of working prototype is continued until the customer is satisfied with the requirements that will be implemented in the final system.  Finally the software requirement specification(SRS) document is prepared,which clarifies all the requirements. Advantages of Prototyping model  It minimizes the change requests from the customer side and the associated redesign and redevelopments costs.  The overall development cost might turn out to be lower than that of an equivalent software development using the waterfall model.  Using the prototype model, customer can get a feeling of the prototype version of the final product very early. Disadvantages of Prototyping model  This model requires exclusive involvement of the customer, this is not always possible.  Sometimes bad design decisions during prototype development may propagate to the real product.  Software development in this way might include extra cost for prototype development. Some situations where the use of Prototyping model is most appropriate are (*Applicability*)  The prototype model is well suited for projects where requirements are difficult to understand and the customer is not confident about illustrating and clarifying the requirements.  It fits best where the customer risks are related to the changing requirements (software and hardware requirements) of the project. 1.9.4 INCREMENTAL MODEL  In incremental model the whole requirement is divided into various builds.  Multiple development cycles take place here, making the life cycle a“multi-waterfall” cycle.  Cycles are divided up into smaller, more easily managed modules.  Each module passes through the requirements, design, implementation and testingphases. 29  A working version of software is produced during the first module, so you have working software early on during the software life cycle.  Each subsequent release of the module adds function to the previous release.  The process continues till the complete system is achieved.  The process of Incremental model is shown in the figure given below: Iteration 1 Release 1 Design Coding Testing Deployment Iteration 2 Release 2 Requirements Design Coding Testing Deployment Operation and Analysis Maintenance Iteration N Release N Design FIG:Coding TestingMODEL INCREMENTAL Deployment Advantages of Incremental model:  Generates working software quickly and early during the software life cycle.  This model is more flexible – less costly to change scope and requirements.  It is easier to test and debug during a smaller iteration.  In this model customer can respond to each built.  Lowers initial delivery cost.  Easier to manage risk because risky pieces are identified and handled during it’d iteration. Disadvantages of Incremental model:  Needs good planning and design.  Needs a clear and complete definition of the whole system before it can be broken down and built incrementally.  Total cost is higher than waterfall. When to use incremental model: 30  This model can be used when the requirements of the complete system are clearly defined and understood.  Used when major requirements must be defined; however, some details can evolve with time.  Used when there is a need to get a product to the market early.  Used when a new technology is being used.  Used when resources with needed skill set are not available.  Used when there are some high risk features and goals. 1.9.5 SPIRAL MODEL  The spiral model is an iterative software development approach which was proposed by Boehm in 1988.  The spiral model is shown in the figure given below FIG: SPIRAL MODEL  In this model, activities are organized as a spiral with many loops.  Each loop in the spiral represents Phase of software development. 31   The main focus of this model is identification and resolution of potential risks(product risks, project risks, and process risks).  Each loop in the spiral is split into four quadrants.  Each of these quadrants is used for the development of each phase. i. Determine objectives, alternatives, and constraints:  In this quadrant, objectives of a specific phase are determined within the project scope.  The product and process constraints( for example, cost, schedule, interface, etc) are also defined.Alternative strategies for performing the phases are planned. ii. Evaluate alternatives; identify and resolve risks:  The aspects of uncertains that are sources of possible risks(product risks, project risks, and process risks) are identified.  Alternative solutions are evaluated to resolve those risks.  This may involve prototyping, benchmarking, simulation, analytic modeling, etc. iii. Develop, verify the next level product  If the prototype is functionally and there is less possibility of risks, the product evolution begins(i.e writing specifications, modeling design, coding, testing and implementation) using the development model.  The work product is verified and validated for its correctness and reliability. iv. Plan for the next phase  Upon the successful completion of the phase, a plan is proposed for initiating the next phase of the project.  The plan of phase may also include partitionof the product or components into cycle for successive development by the engineers  The spiral model has two dimensions namely (i) Radial dimension (ii) Angular dimension  Radial dimension represents the cumulative cost incurred so far for the development of phases in a project.  Angular dimension indicates the progress made so far in completing each cycle.  The spiral model incorporates the features of all other models which are the waterfall, prototyping,incremental,simulation and performance models.  Therefore, it is considered as a metamodel. 32  Advantages of Spiral model: o High amount of risk analysis hence, avoidance of Risk is enhanced. o Good for large and mission-critical projects. o Strong approval and documentation control. o Additional Functionality can be added at a later date. o Software is produced early in the software life cycle. o Project estimates in terms of schedule, cost etc become more and more realistic as the project moves forward and loops in spiral get completed. Disadvantages of Spiral model: o Can be a costly model to use. o Risk analysis requires highly specific expertise. o Project’s success is highly dependent on the risk analysis phase. o Doesn’t work well for smaller projects. o It is not suitable for low risk projects. o May be hard to define objective, verifiable milestones. o Spiral may continue indefinitely. When to use Spiral model: o It is suitable for high risk projects, where business needs may be unstablebut the architecture must be realized well enough to provide high loading and stress ability. A highly customized product can be developed using this. o This model is most suitable for projects having high risks and also for large, complex, ambitious projects. o The military had adopted the spiral model for its Future Combat Systems program. o Usedwhen releases are required to be frequent. o Used when creation of a prototype is applicable. o Usedwhen risk and costs evaluation is important. o Usedfor medium to high-risk projects. o When requirements are unclear and complex. o When changes may require at any time. o Used when long term project commitment is not feasible due to changes in economic priorities. 1.9.6 AGILE PROCESS MODEL 33  The agile process model is a group of software development methodologies based on iterative and incremental development.  The most popular agile methods are extreme programming(XP), Scrum, Dynamic Systems Development Method (DSDM), Adaptive Software Development (ASD), Crystal, Feature-driven Development(FDD), Test-Driven Development(TDD), pair programming, refactoring, agile modeling, Internet speed development, and so on.  Here, we discuss only Extreme Programming (XP) and the Scrum process. EXTREME PROGRAMMING(XP)  Extreme Programming is one of several popular agile processes.  It was initially formulated by Kent Beck.  It focuses mostly on customer satisfaction by communicating with the customers on a regular basis.  It improves software development through communication, simplicity, feedback, respect and courage.  Common XP practices are planning game, small releases, metaphor, simple design, testing, refactoring, part programming, collective ownership, continuous integration, 40- hour week, onsite customer, coding standards, open workspace, daily schema migration, and so on.  XP process is an iterative development process which consists of planning, design, coding and test phases.  The process of Extreme Programming is shown in the figure given below: 34  FIG: Extreme Programming Process ADVANTAGES OF EXTREME PROGRAMMING (1) This practice produces good quality products for the regular involvement of customers. DISADVANTAGES OF EXTREME PROGRAMMING (1) It is difficult to get representatives of customers who can sit with the team and work with them daily. (2) There is a problem of architectural design because the incremental style of development means that inappropriate architectural decisions are made at an early stage of process WHENTOUSE EXTREME PROGRAMMING (1) The XP process is the most suitable practice for dynamically changing requirements, projects having risks, small developer groups, and non-fixed scope or price contract. SCRUM:  Scrum is another popular agile framework with a set of roles and practices.  It is also an iterative process with the idea of timeboxing, which is known as sprint.  There are two roles in the scrum process: pigs and chickens.  Pigs group includes product owner, scrum master, and a scrum team.  A scrum team usually has 5-9 people who do the work.  The group “chickens” involves users, stakeholders, and managers.  A typical scrum process is shown in the figure given below: 35  FIG: THE SCRUM PROCESS ADVANTAGES OF SCRUM PROCESS: (1) It is a completely developed and tested feature in short iterations. (2) It is a simple process with clearly defined rules. (3) It increases productivity and the self-organizing team member carries a lot of responsibility. (4) I improves communication and combination extreme programming DISADVANTAGES OF SCRUM PROCESS: (1) It has no written documentation and sometimes there is violation of responsibilities. WHEN TO USE SCRUM PROCESS: (1) The scrum is specially used in conditions when requirements are not fully mature initially and are to evolve with time called Rolling Wave process. (2) Scrum is great for projects with little baggage 1.9.7 RUP PROCESS MODEL(RATIONAL UNIFIED PROCESS)  The Rational Unified Process (RUP) is a use-case driven, architecture-centric, iterative, and incremental process model.  It is a process, product, developed and maintained by Rational software.  The RUP focuses on creating and maintaining models rather than documentation. 36  It is derived from Unified Modeling Language (UML), which is an industry-standard language that helps to clearly communicate requirements, architectures, and designs.  The RUP divides the development cycle into four consecutive phases, namely (2) Inception (3) Elaboration (4) Construction (5) Transition  The RUP process model is shown in the figure given below: FIG: The RUP Process Model INCEPTION PHASE:  The goal of this phase is to establish the business case for the system and delimit the project scope.  Inceptionis the first phase of the process, where the seed idea for the development is brought up.  Various work products developed during inception phase are: i. Initial Business case ii. Initial use case model 37  iii. Project plan iv. Vision document v. Initial Project Glossary vi. Initial risk assessment vii. Business model. ELABORATION PHASE  The goal of this phase is to analyze the problem domain, establish an architectural framework, develop the project plan, and eliminate the highest risk elements of the project.  Elaborationis the second phase of the process, when the product vision and its architecture are defined.  Various work products developed during elaboration phase are: i. Requirements articulation ii. Requirements prioritization iii. Risk list preparation iv. Supplementary requirements including non functional requirements v. Analysis model vi. Software architecture description vii. Executable architectural prototype viii. Preliminary design model ix. Revised risk list x. Preliminary user manual CONSTRUCTION PHASE  During the construction phase, all the application features are developed, integrated, and thoroughly tested sometimes.  Constructionis the third phase of the process, when the software is brought from an executable architectural baseline to being ready to be transitioned to the user community.  Various work products developed during construction phase are: i. Coding 38  ii. Test cases iii. Design model iv. Software components v. Integrated software vi. Test plan and procedure vii. Support documentation viii. User manuals ix. Installation manuals TRANSITION PHASE  The goal of this phase is to move the software product to the user community for working.  Transitionis the fourth phase of the process, when the software is turned into the hands of the user community.  Various work products developed during transition phase are: i. Software delivery status ii. Feedback report from end users iii. Beta test reports  Each phase in the RUP can be further broken down into iterations.  Each iteration in the RUP mitigates risks, manages changes, provides reuse, and produces better quality products as compared to the traditional waterfall model.  The RUP is suitable for small development teams as well as for large development organizations.  It can be found in a simple and clear process architecture that provides commonality across a family of processes.  Work flow represents the sequence of activities that produces a results of the observable value.  Workflows are divided into six core workflows i. Business Modeling Workflow ii. Requirements Workflow iii. Analysis and design Workflow 39  iv. Implementation Workflow v. Test Workflow vi. Deployment Workflow  There are three supporting workflows vii. Project Management Workflow viii. Configuration and change management Workflow ix. Environment Workflow  Business Modeling Workflow focuses on documenting business process using business use cases.  Requirements Workflow describes what the system should do and allow the developers and the customer to agree upon the document.  The goal of analysis and design workflow is to show how the system will be realized in the implementation phase.  The purpose of implementation workflow is to produce code, objects, and classes that can be implemented.  Testing workflow focuses on the verification of codes and integration of various components.  The product is released, and delivered to the end users in the deployment workflow.  Software project management workflow concentrates on balancing competing objectives, managing risks, and overcoming constraints to deliver a product successfully that meets the needs of both the customers and the users.  Configuration and change management Workflow provides guidelines for managing multiple variants of evolving software system.  The purpose of the environment work flow is to provide software development environment needs to support the development team. Advantages of RUP model 1. The development time required is less due to reuse of components. 40 2. RUP allows developers to control the development process satisfactorily and givers users a high level of security, proponents. 3. RUP was designed to work in a stable organizational environment and offers a multitude of applications for its users. 4. The Rational Unified Process is a Software Engineering Process 5. It provides a disciplined approach to assigning tasks and responsibilities within a development organization. Disadvantages of RUP model(applicability) 1. The team members need to be expert in their field to develop a software under this methodology. 2. The development process is too complex and disorganized. When to use RUP MODEL  It is beneficial for larger companies that have teams spread across different geographic locations or smaller companies that need to access RUP support from a distance. THE UNIQUE NATURE OF WEBAPPS In the early days of the World Wide Web (circa 1990 to 1995), websites consisted of little more than a set of linked hypertext files that presented information using text and limited graphics. Network intensiveness. A WebApp resides on a network and must serve the needs of a diverse community of clients. The network may enable worldwide access and communication (i.e., the Internet) or more limited access and communication (e.g., a corporate Intranet). Concurrency. A large number of users may access the WebApp at one time. In many cases, the patterns of usage among end users will vary greatly. 41 Unpredictable load. The number of users of the WebApp may vary by orders of magnitude from day to day. One hundred users may show up on Monday; 10,000 may use the system on Thursday. Performance. If a WebApp user must wait too long (for access, for serverside processing, for client-side formatting and display), he or she may decide to go elsewhere. Availability. Although expectation of 100 percent availability is unreasonable, users of popular WebApps often demand access on a 24/7/365 basis. Users in Australia or Asia might demand access during times when traditional domestic software applications in North America might be taken off-line for maintenance. Data driven. The primary function of many WebApps is to use hypermedia to present text, graphics, audio, and video content to the end user. In addition,WebApps are commonly used to access information that exists on databases that are not an integral part of the Web-based environment (e.g.,e-commerce or financial applications). Content sensitive. The quality and aesthetic nature of content remains animportant determinant of the quality of a WebApp. Continuous evolution. Unlike conventional application software that evolves over a series of planned, chronologically spaced releases, Web applications evolve continuously. It is not unusual for some WebApps (specifically,their content) to be updated on a minute-by-minute schedule or for content to be independently computed for each request. Immediacy. Although immediacy—the compelling need to get software to market quickly— is a characteristic of many application domains, WebApps often exhibit a time-to-market that can be a matter of a few days or weeks. Security. Because WebApps are available via network access, it is difficult, if not impossible, to limit the population of end users who may access the application. In order to protect sensitive content and provide secure modes of data transmission, strong security measures must be implemented throughout the infrastructure that supports a WebApp and within the application itself. Aesthetics. An undeniable part of the appeal of a WebApp is its look and feel. When an application has been designed to market or sell products or ideas, aesthetics may have as much to do with success as technical design. However, WebApps almost always exhibit all of them. 42 SOFTWARE ENGINEERING PRACTICE Introducing a generic software process model composed of a set of activities that establish a framework for software engineering practice. Generic framework activities—communication, planning, modeling, construction, and deployment—and umbrella activities establish a skeleton architecture for software engineering work. But how does the practice of software engineering fit in? In the sections that follow, you’ll gain a basic understanding of the generic concepts and principles that apply to framework activities. The Essence of Practice: It outlined the essence of problem solving, and consequently, the essence of software engineering practice: 1. Understand the problem (communication and analysis). 2. Plan a solution (modeling and software design). 3. Carry out the plan (code generation). 4. Examine the result for accuracy (testing and quality assurance). In the context of software engineering, these commonsense steps lead to a series of essential questions. Understand the problem Who has a stake in the solution to the problem? That is, who are the stakeholders? What are the unknowns? What data, functions, and features are required to properly solve the problem? Can the problem be compartmentalized? Is it possible to represent smaller problems that may be easier to understand? Can the problem be represented graphically? Can an analysis model be created? Plan the solution. Now you understand the problem (or so you think) and you can’t wait to begin coding. Before you do, slow down just a bit and do a little design: Have you seen similar problems before? Are there patterns that are recognizable in a potential solution? Is there existing software that implements the data, functions, and features that are required? Has a similar problem been solved? If so, are elements of the solution reusable? 43  Can sub problems be defined? If so, are solutions readily apparent for the sub problems? Can you represent a solution in a manner that leads to effective implementation? Can a design model be created? Carry out the plan. The design you’ve created serves as a road map for the system you want to build. There may be unexpected detours, and it’s possible that you’ll discover an even better route as you go, but the “plan” will allow you to proceed without getting lost. Does the solution conform to the plan? Is source code traceable to the design model? Is each component part of the solution provably correct? Have the design and code been reviewed, or better, have correctness proofs been applied to the algorithm? Examine the result. You can’t be sure that your solution is perfect, but you can be sure that you’ve designed a sufficient number of tests to uncover as many errors as possible. Is it possible to test each component part of the solution? Has a reasonable testing strategy been implemented? Does the solution produce results that conform to the data, functions, and features that are required? Has the software been validated against all stakeholder requirements? It shouldn’t surprise you that much of this approach is common sense. In fact, it’s reasonable to state that a commonsense approach to software engineering will never lead you astray. SOFTWARE MYTHS Software myths—erroneous beliefs about software and the process that is used to build it— can be traced to the earliest days of computing. Myths have a number of attributes that make them insidious. Managers with software responsibility, like managers in most disciplines, are often under pressure to maintain budgets, keep schedules from slipping, and improve quality. Like a drowning person who grasps at a straw, a software manager often grasps at belief in a software myth, if that belief will lessen the pressure (even temporarily). Myth: We already have a book that’s full of standards and procedures for building software. Won’t that provide my people with everything they need to know? Reality: The book of standards may very well exist, but is it used? Are software practitioners aware of its existence? Does it reflect modern software engineering practice? Is it complete? Is it adaptable? Is it streamlined to improve time-to-delivery while still maintaining a focus on quality? In many cases, the answer to all of these questionsis “no.” 44 Myth: If we get behind schedule, we can add more programmers and catch up (sometimes called the “Mongolian horde” concept). Reality: Software development is not a mechanistic process like manufacturing.In the words of Brooks [Bro95]: “adding people to a late software project makes it later.” At first, this statement may seemcounterintuitive. However, as new people are added, people who were working must spend time educating the newcomers, 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: 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 outsources software projects. Customer myths. A customer who requests computer software may be a personat the next desk, a technical group down the hall, the marketing/sales department, or an outside company that has requested software under contract. In many cases, the customer believes myths about software because software managers and practitioners do little to correct misinformation. Myths lead to false expectations (by the customer) and, ultimately, dissatisfaction with the developer. Myth: A general statement of objectives is sufficient to begin writing programs—we can fill in the details later. Reality: Although a comprehensive and stable statement of requirements is not always possible, an ambiguous “statement of objectives” is a recipe for disaster. Unambiguous requirements (usually derived iteratively) are developed only through effective and continuous communication between customer and developer. Myth: Software requirements continually change, but change can be easily accommodated because software is flexible. Reality: It is true that software requirements change, but the impact of change varies with the time at which it is introduced. When requirements changes are requested early (before design or code has been started), the cost impact is relatively small.16 However, as time passes, the cost impact grows rapidly—resources have been committed, a design framework has been established, and change can cause upheaval that requires additional resources and major design modification. Practitioner’s myths. Myths that are still believed by software practitioners have been fostered by over 50 years of programming culture. During the early days, programming was viewed as an art form. Old ways and attitudes die hard. 45 Myth: Once we write the program and get it to work, our job is done. Reality: Someone once said that “the sooner you begin ‘writing code,’ the longer it’ll take you to get done.” Industry data indicate that between 60 and 80 percent of all effort expended on software will be expended after it is delivered to the customer for the first time.Myth: Until I get the program “running” I have no way of assessing its quality. Reality: One of the most effective software quality assurance mechanisms can be applied from the inception of a project—the technical review. Software reviews (described in Chapter 15) are a “quality filter” that have been found to be more effective than testing for finding certain classes of software defects. Myth: The only deliverable work product for a successful project is the working program. Reality: A working program is only one part of a software configuration thatincludes many elements. A variety of work products (e.g., models, documents, plans) provide a foundation for successful engineering and, more important, guidance for software support. Myth: 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 is about creating a quality product. Better quality leads to reduced rework. And reduced rework results in faster delivery times. PROCESS ASSESSMENT AND IMPROVEMENT The existence of a software process is no guarantee that software will be delivered on time, that it will meet the customer’s needs, or that it will exhibit the technical characteristics that will lead to long-term quality characteristics The existence of a software process is no guarantee that software will be delivered on time, that it will meet the customer’s needs, or that it will exhibit the technical characteristics that will lead to long-term quality characteristics. Standard CMMI Assessment Method for Process Improvement (SCAMPI)—provides a five-step process assessment model that incorporates five phases: initiating, diagnosing, establishing, acting, and learning. The SCAMPI method uses the SEI CMMI as the basis for assessment CMM-Based Appraisal for Internal Process Improvement (CBA IPI)— provides a diagnostic technique for assessing the relative maturity of a software organization; uses the SEI CMM as the basis for the assessment. 46 SPICE (ISO/IEC15504)—a standard that defines a set of requirements for software process assessment. The intent of the standard is to assist organizations in developing an objective evaluation of the efficacy of any defined software process. ISO 9001:2000 for Software—a generic standard that applies to any organization that wants to improve the overall quality of the products, systems, or services that it provides. Therefore, the standard is directly applicable to software organizations and companies SPECIALIZED PROCESS MODELS 1.Component-Based Development Commercial off-the-shelf (COTS) software components, developed by vendors who offer them as products, provide targeted functionality with well-defined interfaces that enable the component to be integrated into the software that is to be built. The component-based development model incorporates many of the characteristics of the spiral model. It is evolutionary in nature demanding an iterative approach to the creation of software. However, the component-based development model constructs applications from prepackaged software components. 1. Available component-based products are researched and evaluated for the application domain in question. 2. Component integration issues are considered. 3. A software architecture is designed to accommodate the components. 47 4. Components are integrated into the architecture. 5. Comprehensive testing is conducted to ensure proper functionality. The component-based development model leads to software reuse, and reusability provides software engineers with a number of measurable benefits. Your software engineering team can achieve a reduction in development cycle time as well as a reduction in project cost if component reuse becomes part of your culture. 2.The Formal Methods Model 1.The formal methods model encompasses a set of activities that leads to formal mathematical specification of computer software. Formal methods enable you to specify, develop, and verify a computer-based system by applying a rigorous, mathematical notation. A variation on this approach, called cleanroom software engineering. 2. hen formal methods are used during development, they provide a mechanism for eliminating many of the problems that are difficult to overcome using other software engineering paradigms. Ambiguity, incompleteness, and inconsistency can be discovered and corrected more easily—not through ad hoc review, but through the application of mathematical analysis. 3. When formal methods are used during design, they serve as a basis for program verification and therefore enable you to discover and correct errors that might otherwise go undetected. DISADVATAGES: The development of formal models is currently quite time consuming and expensive. Because few software developers have the necessary background to apply formal methods, extensive training is required. It is difficult to use the models as a communication mechanism for technically unsophisticated customers. 3. Aspect-Oriented Software Development Regardless of the software process that is chosen, the builders of complex software invariably implement a set of localized features, functions, and information content. These localized software characteristics are modeled as components (e.g., object oriented classes) and then constructed within the context of a system architecture. 48 As modern computer-based systems become more sophisticated (and complex), certain concerns—customer required properties or areas of technical interest—span the entire architecture. Some concerns are high-level properties of a system (e.g., security, fault tolerance). Other concerns affect functions (e.g., the application of business rules), while others are systemic (e.g., task synchronization or memory management). Aspectual requirements define those crosscutting concerns that have an impact across the software architecture. Aspect-oriented software development (AOSD) Aspect-oriented programming (AOP), is a relatively new software engineering paradigm that provides a process and methodological approach for defining, specifying, designing, and constructing aspects—“mechanisms beyond subroutines and inheritance for localizing the expression of a crosscutting concern” A distinct aspect-oriented process has not yet matured. However, it is likely that such a process will adopt characteristics of both evolutionary and concurrent process models. The evolutionary model is appropriate as aspects are identified and then constructed. The parallel nature of concurrent development is essential because aspects are engineered independently of localized software components and yet, aspects have a direct impact on these components 49  UNIT II ( 2ND Part) SOFTWARE DESIGN The activities carried out during the design phase (called as design process ) transform the SRS document into the design document. The design process starts using the SRS document and completes with the production of the design document. The design document produced at the end of the design phase should be implementable using a Programming language in the subsequent (coding) phase. 5.1 OVERVIEW OF THE DESIGN PROCESS The design process essentially transforms the SRS document into a design document. The following items are designed and documented during the design phase. Different modules required Control relationships among modules Interfaces among different modules Data structures of the individual modules Algorithms required to implement the individual modules Different modules required: The different modules in the solution should be clearly identified. Each module is a collection of functions and the data shared by the functions of the module. Each module should accomplish some well-defined task out of the overall responsibility of the software. Each module should be named according to the task it performs.  Control relationships among modules: A control relationship between two modules essentially arises due to function calls across the two modules. The control relationships existing among various modules should be identified in the design document. Interfaces among different modules: The interfaces between two modules identifies the exact data items that are exchanged between the two modules when one module invokes a function of the other module. Data structures of the individual modules: Each module normally stores some data that the functions of the module need to share to accomplish the overall responsibility of the module. Suitable data structures for storing and managing the data of a module need to be properly designed and documented. Algorithms required to implement the individual modules: Each function in a module usually performs some processing activity.  The algorithms required to accomplish the processing activities of various modules need to be carefully designed and documented with due considerations given to the accuracy of the results, space and time complexities. 5.1.2 Classification of Design Activities A good software design is seldom realised by using a single step procedure, rather it requires iterating over a series of steps called the design activities. Let us first classify the design activities before discussing them in detail. Depending on the order in which various design activities are performed, we can broadly classify them into two important stages. Preliminary (or high-level) design, and Detailed design. Through high-level design, a problem is decomposed into a set of modules. The control relationships among the modules are identified, and also the interfaces among various modules are identified. The outcome of high-level design is called the program structure or the software architecture. High-level design is a crucial step in the overall design of a software. When the high-level design is complete, the problem should have been decomposed into many small functionally independent modules that are cohesive, have low coupling among themselves, and are arranged in a hierarchy.  Many different types of notations have been used to represent a high-level design. A notation that is widely being used for procedural development is a tree-like diagram called the structure chart. Another popular design representation techniques called UML that is being used to document object-oriented design, involves developing several types of diagrams to document the object-oriented design of a systems. Though other notations such as Jackson diagram or Warnier-Orr [1977, 1981] diagram are available to document a software design, we confine our attention in this text to structure charts and UML diagrams only. Once the high-level design is complete, detailed design is undertaken During detailed design each module is examined carefully to design its data structures and the algorithms. The outcome of the detailed design stage is usually documented in the form of a module specification (MSPEC) document. After the high-level design is complete, the problem would have been decomposed into small modules, and the data structures and algorithms to be used described using MSPEC and can be easily grasped by programmers for initiating coding. In this text, we do not discuss MSPECs and confine our attention to high-level design only. 5.1.3 Classification of Design Methodologies The design activities vary considerably based on the specific design methodology being used. A large number of software design methodologies are available. We can roughly classify these methodologies into procedural and object-oriented approaches. These two approaches are two fundamentally different design paradigms Does a design techniques result in unique solutions? Unless we know what a good software design is and how to distinguish a superior design solution from an inferior one, we can not possibly design one. Analysis versus design Analysis and design activities differ in goal and scope. The goal of any analysis technique is to elaborate the customer requirements through careful thinking and at the same time consciously avoiding making any decisions regarding the exact way the system is to be implemented. The analysis results are generic and does not consider implementation or the issues associated with specific platforms. The analysis model is usually documented using some graphical formalism. In case of the function-oriented approach that we are going to discuss, the analysis model would be documented using data flow diagrams (DFDs), whereas the design would be documented using structure chart. On the other hand, for object-oriented approach, both the design model and the analysis model will be documen