MODULE 1. INTRODUCTION TO SOFTWARE ENGINEERING Definition of Software Software is not just computer program.

It includes all documentation necessary to develop, install, use and maintain a complete software system. Therefore, software includes computer programs, procedures, rules and possibly associated documentation and data pertaining to operation of a computer system. Components of a Software Product(Developed by Software Engineers) Requirements Documents Design Specifications Source Code Test Plans Principles of Operation Quality Assurance Procedures Software Problem Reports Maintenance Procedures Users Manuals Installation Instructions Training Aids Types of Software Products Generic Products. These are stand-alone systems, which are produced by development organization and sold on the open market to any customer who is able to buy them. Examples are databases, word processors, drawing packages, project management tools. Bespoke (customized) Products. These are systems, which are commissioned by a particular customer and developed specially by a software contractor. Example: are systems for electronic devices, air traffic control systems, systems written to support a particular business process like Payroll, Accounting, etc. Characteristics of Software Software is developed or engineered, not manufactured in the classical sense. Software does not wear out. It is not susceptible to environmental maladies that cause hardware to break out. Most software are custom-built, rather than being assembled from existing software. There is no catalogs of software components that can be re-assembled into new programs, only complete units or off-the-shelf programs. Software is intangible: it has no mass, no volume, no color, no odor no physical properties. Software does not degrade with time as hardware does. Software failures are caused by design and implementation errors, not by degradation.

Categories of Software Applications System Software. This is a collection of software written to service other programs and is characterized by heavy interaction with computer hardware, resource sharing, multiple users, complex data structures and multiple external interfaces. Examples are compilers, editors, drivers, OS components, file management utilities, IDEs. Real-time Software. It monitors/analyzes/controls real-world events as they occur and responds within strict time constraints. Examples are CAD/CAM, electronic billboard, barcoding system. Business Software. It restructures existing data in a way that facilitates business operations or management decision-making. Examples are Transaction Processing systems, Point-of-Sale Systems, Management Information systems, Executive Information System. Engineering and Scientific Software. It is characterized by number-crunching algorithms. Examples are software for astronomy, volcanology, space shuttle orbital dynamics, molecular biology, and engineering. Embedded Software. It resides in read-only memory and is used to control products and systems for the consumer and industrial markets. This software can perform very limited and obscure functions

such as keypad control for microwave oven, or provide significant function and control capability such as digital functions in automobile like fuel control, dashboard displays, braking systems. Other examples are Barcode, BIOS, IC in electronic parts. Personal Computer Software. Usually called household software, these are software for personal use. Examples are Word processing, spreadsheets, computer graphics, entertainment, database management, personal and business financial applications, external network, or database accesses. Artificial Intelligence Software. It makes use of non-numerical algorithms to solve complex problems that are not amenable to computation or straightforward analysis. Areas of Artificial Intelligence include Expert Systems, Intelligent CAIs, image and voice recognition, theorem proving, game playing, neural networks, Robotics.

Attributes of Good Software Maintainability. Software should be written in such a way that it may evolve to meet the changing needs of customers. This is a critical attribute because software change is an inevitable consequence of a changing business environment. Dependability. Software dependability includes reliability, security and safety. Dependable software should not cause physical or economic damage in the event of system failure. Efficiency. Software should not make wasteful use of system resources such as memory and processor cycles. Efficiency includes responsiveness, processing time, memory utilization, etc. Usability. Software should have an appropriate user interface and adequate documentation. Questions Related to Software A. Industry Perspective 1. Why does it takes so long to get programs finished? 2. Why are costs so high? 3. Why cant we find all errors before we give the software to customer? 4. Why do we have difficulty in measuring progress as software is being developed? B. Specific/Technical Perspective 1. How do we develop software? 2. How do we maintain a growing volume of existing software? 3. How can we keep pace with growing demand for more software? What Is A Quality Software Quality software satisfies the needs of the users and programmers involved with it. We can consider software to be of high quality if: It does what the user wants to do. It uses computer resources correctly and efficiently. It is easy for the user to learn and use. The developers can design, code, test, and maintain the system with relative ease. The challenge for software engineers is to produce high quality software using a finite number of resources and within a predictable amount of time. What is Software Engineering Software Engineering is a top-down strategy for producing quality software. It uses engineering principles in the development, creation and maintenance of software, which means it is a systematic and disciplined approach in solving problems related to software. Software Engineering is the technological and managerial discipline concerned with systematic production and maintenance of software products that are developed and modified on time and within cost estimates. It is considered as an engineering discipline where software engineers use methods and theory from computer science and apply this cost effectively to solve difficult problems. Software engineering is concerned with large and complex software systems built by teams of developers and programmers. But even simple software systems have high inherent complexity so engineering principles have to be used in their development.

Computer systems are economically critical in industrialized and developing countries. The effective functioning of modern economic and political systems depends in the ability to produce software in a costeffective way. This is another reason for the need to study software engineering. Problems Which Afflict Software Development Customer dissatisfaction with the completed system is frequently encountered. Software development is undertaken often with only a vague notion of customers requirements. Software quality is inadequate. Often there is no systematic, complete software testing and only recently have solid quantitative concepts of software reliability and quality assurance begun to emerge. Existing software can be difficult to maintain. Although software maintenance accounts for the majority of all software budgets, software maintainability has not been emphasized as an important criteria for software acceptance. Schedule and cost estimates are inaccurate. People in-charge of managing the software project (Project Manager) lack the competence and tools in arriving at accurate project cost and schedule. Productivity of software people is low VS demand or service. Often, the software development staff is engaged in other projects or works where their expertise and effort is required. * software absorbs large % of total devt cost of a computer-based system Software Development Myths Management Myths 1.1 Standards and procedures already exist for producing software. The truth is Standards are rarely used. Developers rarely know about the standards Standards are often out-of-date and incomplete. 1.2 State-of-the-art hardware is the essential ingredient for successful software production. The truth isSoftware, not hardware tools are usually more important for achieving quality and productivity. 1.3 If we get behind schedule, we can always add more programmers and thus catch up. The truth is Software development is not a mechanistic process like manufacturing. Adding people to a late software project makes it later (as discovered by F. Brooks in 1975). Newcomers must be educated (usually by those already working on the project) thereby reducing the amount of time spent on productive development effort. 2. Customer Myths 2.1 A general statement of objectives is sufficient to begin writing programs; details can be filled in later. The truth is Insufficient knowledge about requirements is the major cause of failed software efforts. Formal and detailed descriptions of data, functionality, design constraints, and validation criteria are essential. Communication between customer and developer is vital. 2.2 Project requirements continually change, but change can be easily accommodated because software is flexible. The truth is The impact of change varies with the time at which it is introduced. Early requests for change can be accommodated easily and more cheaply. Changes made during design, implementation and installation have a severe impact on cost. 3. Practitioner Myths 3.1 Once the program is written and it works, then the job is done. The truth isbetween 50 to 70 percent of all efforts expended on a program will be expended after it is delivered to the customer. 3.2 Until the program is running, there is no way to assess its quality. The truth isFormal Technical Review, which is one of the most effective software quality assurance mechanism can be applied from the inception of the project.

3.3

The only deliverable is the working program(s). The truth isa working program is only one part of a software configuration that includes requirements and specification documents, testing information and other developmental and maintenance information.

Software Engineering Paradigm / Software Development life-cycle Strategies A paradigm/strategy for software engineering is chosen based on the nature of the project and application, the methods and tools to be used, and the controls and deliverables required. The software engineering processes can be modeled through these paradigms which can be classified into three categories: 1. Linear Models and Variants Classic Software Development Life Cycle(SDLC) or Waterfall Approach. Because of the cascade from one phase to another, this model is known as the waterfall model and sometimes called the Software Life Cycle, and also known as the Linear Sequential Model. It demands a systematic, sequential approach to software development that begins at the system level and progresses through analysis, design, coding, testing, and maintenance. The principal stages of the model mapped onto the fundamental product activities are: Requirements Definition/Analysis. In this stage, the system services, constraints and goals are established by consultations with the system users. These requirements are analyzed and represented before proceeding to other processes. The output of this phase is the Requirements specification Document. System and Software Design. This process establishes an overall system architecture, where a solution is planned for the problem specified in the requirements document. It involves postulating, modeling and evaluating a solution against the original requirements and after some iteration of these activities, results in a Design Specifications Document. Development/Implementation. The system and software design is translated into set of programs or program units using a suitable programming language. Testing. The individual program units or programs are tested(Unit Test), then these are tested as a complete system(Integration and System Test) to ensure that the software requirements have been met. Then the users test the systems usability and applicability (User Acceptance Test). Testing is called validation when performed against the original requirements. When performed against design specifications, it is called verification. Operation and Maintenance. The system is installed and put into practical use.

1.

2.

3. 4.

5.

Characteristics Project development phases are sequential and generally one-way Deadlines are determined very early in the project Required project results are completely and unambiguously determined A milestone document suite concludes each project phase May be applied to large and small projects Ideal when resources are available Applicable when standard procedures are fully documented Advantages Divides a large and/or complex task into smaller, manageable tasks Every project can be carefully planned Authorities and responsibilities can be clearly delineated Clear and distinctive phases with milestones allow management to assess project progress and take corrective action if necessary Easy to apply and understand

Disadvantages Real projects rarely follow the sequential flow that the model uses since it does not reflect the problem-solving nature of software development that leads to rework and iterations. It is often difficult for the customer to state all requirements explicitly. A working version of the system will be available late in the project life cycle; it takes too long to see results. Inherently linear sequential nature discourages late changes It depends on stable and correct requirements; a major product blunder can be disastrous. Amount of documentation can be excessive Linear sequential nature may lead to blocking state Fountain Model. A variant of the waterfall model where water can flow upwards. The model recognizes that iteration to previous phases may be necessary. It is a more realistic model than waterfall but is more difficult to control. Other linear life-cycle strategies: Model Systems Ltd. used by NCC-UK Foundation used by Andersen Consulting Structured Project Life-cycle used by Yourdon group

The RAD Model. A linear sequential software development process model that emphasizes an extremely short development cycle achieved by using a componentbased construction approach. Each major function in a project can be addressed by a separate RAD team and then integrated to form a whole. It encompasses the following phases: Business Modeling. The information flow among business functions is modeled in a way that answers the following questions: What information drives the process? What information is generated? Who generates it? Where does the information go? Who processes it? Data Modeling. The information flow defined as part of the business modeling phase is refined into a set of data objects that are needed to support the business. The characteristics(attributes) of each object are identified and the relationships between these objects are defined. Process Modeling. The data objects defined in the modeling phase are transformed to achieve the information flow necessary to implement a business function. Processing descriptions are created for adding, modifying, deleting, or retrieving data object. Application Generation. RAD assumes the use of fourth generation techniques. Rather than creating software with the use of 3rd generation programming languages, the RAD process works to reuse existing program component or create reusable components and automated tools are used to facilitate construction of the software. Testing and Turnover. Since the RAD process emphasizes reuse, many of the program components have already been tested thus reducing overall testing time. However, new components must be tested and all interfaces must be fully exercised. Problems With RAD For large, but scalable projects, RAD requires sufficient human resources to create the right number of RAD Teams. It requires customers and developers who are committed to the rapid-fire activities necessary to complete a system in a much shorter time frame, otherwise, the project would fail. It is not appropriate in the following cases: (1) when system cannot be properly modularized, (2) when high performance(achieved through tuning the interfaces to system components) is an issue, (3) when technical risks are high like when new software requires high degree of interoperability with existing computer programs or new technology. 2. Iterative or Prototyping It is a process that enables the developer to create a model of the software that must be built to be able to understand customer requirements before delivering the final system. The process proceeds in the form of iterations. In every iteration, a prototype is created based on initial

customer requirements. For every iteration from the prototype onwards, the customer gives feedbacks about the model, and this continues until the customer is satisfied with the model developed. This model can be: A PC-model that depicts human-machine interactions A working software that implements a subset of the functions required of the system, or An existing program that performs all or parts of the functions desired but will be improved in the development effort. Characteristics Development starts with incomplete requirements Full requirements are derived from user interaction on a prototype There are three types, depending on the amount of code retained in the final system: Prototyping with disposable system tests the adequacy of proposed solution; requirements are formalized after they are sufficiently determined through reactions on prototypes; prototypes are disposed after formalizing requirements then further development is done according to linear sequential model Prototyping with working system A prototype of most critical functions is built; after acceptance, the prototype is extended to a working system Evolutionary prototype adapts to changing requirements; subsequent prototypes of the systems evolve to the eventual operational system; prototype is used for deployment Prototyping could be used to see how users respond: Exploratory clarifies requirements and desirable features; used to explore alternative design possibilities Experimental tests the adequacy of proposed solution Ideal for systems where requirements may be defined but human-computer interface suitability(users response) is not yet known Useful when developing a system the developer has not known/seen before Advantages System requirements dont have to be uniquely determined System requirements can be changed during the project Delivers clear and understandable system definition and specifications to the end user; more effective to gather requirements Enhances communication regarding suitability of human-computer interfaces; Increases end user involvement and satisfaction Development environment can be tested quickly Can be used to demonstrate technical, economic, and political feasibility Disadvantages Rising expectations of the end user. The user sees what appears to be the working version of the software unaware that overall software quality and maintainability has not been considered, so that customer demands just a few fixes for the product to be completed into a full working system. Danger of never-ending development because of user-developer interactions during development Danger of neglecting planning, verification, validation, backup procedures and documentation Danger of modeling before sufficient analysis of the current and desired results Danger of making design and implementation compromises in order to get a prototype working quickly. 3. Evolutionary Model This iterative approach enables software engineers to develop increasingly more complete versions of the software. The starting point of the evolutionary software process model is the problem domain that needs to be solved by means of a software system or a manual system that needs to

be automated. The evolutionary software process has the following steps: (1) A clear delineation of the functional boundaries of the desired system is first set. (2) Then the desired system is split up into Microsystems. (3) The microsystem is developed and put into production in 6 months or less. (4) Long term goals and planning are reassessed and subsequent Microsystems are adjusted if necessary. Steps (3) and (4) are repeated until planned system is realized. Characteristics: Product-oriented instead of project-oriented Iterative approach every system goes through all the phases(from analysis to integration) Continuous testing and re-planning based on long term goals Advantages Developers see the results faster End users and management get fast response and see the product evolve Fast reaction to changed goals Better manageability of the development process through: (1) incremental construction (2) continuous control of the system Disadvantages No recursion to previous microsystem scheduled Changing environments might obliterate long-term goals Could be costly Examples of the evolutionary development approach are: The Incremental Model. This model combines elements of the linear sequential model with the iterative philosophy of prototyping. Each linear sequence produces a deliverable increment of the software[McDE93]. The first increment is often the core product where basic requirements are addressed but many supplementary features remain undelivered. After the core product is used and evaluated by the customer, a plan is developed for the next increment, which addresses the modification of the core product and the delivery of additional features and functionality. This plan is repeated following the delivery of each increment, until the complete product is produced. This approach is useful when technical requirements or staffing is unavailable for a complete implementation by the business deadline that has been established for the project. Advantages Operational product is produced with each intermediate progress/version Risk of failure and changing requirements is reduced User can adjust to new technology in incremental steps Disadvantages Lack of process visibility; cannot determine how far the product is from the final version Systems are often poorly structured Special skills(e.g. in languages for rapid prototyping) may be required Recommendation Applicable for small company in a growing stage Good only for small systems and never for large systems Useful when budget is limited / critical Requirements should be clearly defined Produce specifications document before coding The Spiral Model. This model couples the iterative nature of prototyping with the controlled and systematic aspects of the linear sequential model. Software is developed in a series of incremental releases. The model is divided into typically

three or six framework activities, also called task regions: (1) Customer communication tasks required to establish effective communication between customer and developer (2) planning tasks required to define resources, timeliness, and other project related information (3) risk analysis tasks required to assess both technical and managerial risks (4) engineering tasks required to build representations of the application (5) construction and release tasks required to construct, test, install and provide user support (6) customer evaluation tasks required to obtain customer feedback based on evaluation of software representations created and implemented. Each pass through the planning region results in adjustments to the project plan while cost and schedules are adjusted based on feedback derived from customer evaluation. The customer and developer better understand and react to risks at each evolutionary level where prototyping could be applied at any stage of the evolution. This model demands and relies on risk assessment expertise for success. It is characterized with many throw-away prototypes as a risk reduction mechanism. These prototypes may or may not be required in each phase. The model is relatively new and has not been widely used. Advantages Splits a potentially large development effort into small chunks in which critical, high-risk functions can be done first Takes advantage of incremental release, cumulative costs may be assessed Rapid application development can be used (through 4th Generation tools) Disadvantages Model is complex, and may be too complicated and costly to use (many intermediate stages) No clear, distinct phase can prove to be difficult to manage (because of high integration of phases) Additional internal and external documentation are needed to follow up the large number of intermediate stages Recommendation Ideal for large scale systems and never for small projects (because its is too costly) Applicable in the following situations: There is too much risks involved Procedures and technology are dynamic (due to environmental factors) There is lack of expertise/knowledge Requirements are not well-defined The system could be broken down into sub-systems The Concurrent Development Model. This model sometimes called Concurrent Engineering allows tracking of status of extremely complex sets of activities especially those that occur at the same time during any one phase. It can be represented schematically as a series of major technical activities, tasks, and their associated states. It defines a series of events that will trigger transitions from one state to state for each of the software engineering activities. Rather than confining software engineering activities to a sequence of events it defines a network of activities that exist simultaneously with other activities. This model is often used as a paradigm for the development of client/server applications although it is applicable to all type of software development and provides an accurate picture of the current state of the project.

4. Other Models Fourth Generation Techniques. It encompasses a broad array of software tools that enables the software engineer to specify some characteristics of software at a high level.

These tools include some or all of the following: non-procedural languages for database query, report generation, data manipulation, screen interaction and definition, code generation; high-level graphics capability; spreadsheet capability. It focuses on the ability to specify software using specialized language forms or a graphic notation that describes the problem to be solved in terms that the customer can understand. For small applications, it may be possible to move directly from requirements gathering step to implementation using a nonprocedural fourth generation language (4GL). Advantages of this paradigm include dramatic reduction in software development time and greatly improved productivity for people who build the software. When coupled with component assembly approaches, the 4GT paradigm may become the dominant approach to software development. However opponents claim that the resultant source code produced by such tools are inefficient and that the maintainability of large software systems developed using 4GT is open to question and demands as much or more analysis, design, and testing to obtain the substantial time saving that can be achieved through the elimination of coding. Component Based Development Model. This object-oriented paradigm incorporates many of the characteristics of the spiral model but composes applications from prepackaged re-usable software components sometimes called classes. These components (classes) created in past software engineering projects are stored in a class library or repository and later extracted. Candidate class not in the library is engineered using object-oriented method. This model leads to software reuse that provides software engineers with a number of measurable benefits such as reduction in development cycle time, project cost and increase in productivity index. The unified software development process is representative of a number of component-based development models that have been proposed in the industry. Using the Unified Modeling Language(UML), the unified process defines the components that will be used to build the system and the interfaces that will connect the components. Using a combination of iterative and incremental development, the unified process defines the function of the system by applying a scenario-based approach (from the user point of view). It then couples function with an architectural framework that identifies the form that the software will take. This is an iterative model with static framework or architecture Characteristics: A project plan is a plan of contingencies rather than a plan of actions It has four(4) phases: 1. Inception shared understanding between developers and users 2. Elaboration a framework architecture is produced 3. Construction UML is used to construct the system 4. Transition system implementation It has two forms of modeling: (1) Architectural - a static model or architecture which is developed during elaboration (2) Structural dynamic model where the requirements in each iteration will be used for construction It is well-matched to OOP Recommendation: Useful when present system is not tied to the new system More applicable when replacing a system rather than converting to a higher version Applicable when users are open to object-oriented language / representation and the development team is object-oriented trained Formal Transformation or Formal Methods. This approach is based on producing a formal mathematical system specification and transforming this specification using mathematical methods, to a program. Normally, specifications are written using the English language or using some diagrammatic method. The programs are written based on either the textual or diagrammatic specifications. The specifications are done using a mathematical notation, such as Petri Nets or the Z Notation. Another software (like a compiler) will generate the program based on the specifications. A variation on this approach, called Cleanroom Software Engineering[MIL87, DYE92], is currently applied by some software development organizations. This model provides a mechanism for eliminating

many of the problems that are difficult to overcome using other software engineering paradigms. The formal methods can also be used to verify systems developed in a rigorous manner using mathematical techniques. Although not yet a mainstream approach, the formal methods offer the promise of defect-free software and therefore will gain adherents among software developers that must build safety critical software and developers that would suffer severe economic hardship should software error occurs. Concerns on this model are the following: Its development is currently quite time-consuming and expensive. Extensive training is required because few developers have the necessary background to apply formal methods. It is difficult to use as a communication mechanism for technically unsophisticated customers. Extreme Programming. This is also an iterative model where several releases are produced until the user is satisfied. It stresses on customer satisfaction and operates on (1) communication; (2) simplicity (in terms of function/component); (3) feedback; (4) empowerment of developers (not constrained by phase) Advantages Addresses problems of project risk Manager, developer, users work together very closely Disadvantages For small group of programmers only (between 2-12) Must be able to create automated unit and functional test while some domains will be disqualified by it Recommendation Applicable to small projects only because developers are so empowered(from analysis to deployment) Useful for conversion of projects Most applicable for web-based applications Well-matched to component-based programming Programmers should be component-based trained Problems should be definable into smaller functions (details are known; framework defined already) Each component must be elementary (single function only) so that it will be easy to add or remove Generic View of Software Engineering The software development process contains three generic phases regardless of the software engineering paradigm that is chosen. The three phases, definition, development, and maintenance are encountered in all software development regardless of application area, project size, or complexity. Definition Phase. Focuses on what. The key requirements of the system and the software are identified: What information is to be processed What functions and performance are desired What interfaces are to be established What design constraints exist What validation criteria are required 3 Steps in Definition Phase 1. Systems Analysis. Defines the role of each element in the computer-based system 2. Software Project Planning. Risks are analyzed, resources are allocated, costs are estimated, and work tasks and schedules are defined. 3. Requirement Analysis. More detailed definition of the information domain and function of the software.

Development Phase. Focuses on how. How data structure and software architecture are to be designed How procedural details are to be implemented How the design will be translated into programming language How testing will be performed 3 Steps in Development Phase 1. Software Design. Describes data structure, architecture, algorithmic procedure, and interface characteristics 2. Coding. Design representations are translated into an artificial language. 3. Testing. To uncover defects in function, in logic, and in implementation. Maintenance Phase. Focuses on change. Associated with error correction Adaptations required as the softwares environment evolves Enhancements brought about by customer requirements 3 Types of Change 1. Corrective Maintenance. Changes the software to correct defects 2. Adaptive Maintenance. Modifications to the software to accommodate changes to its external environment 3. Perfective Maintenance. Extends the software beyond its original function requirements