UNIT 1 SOFTWARE ENGINEERING INTRODUCTION TO SOFTWARE ENGINEERING

Software is defined as systematic, disciplined and quantifiable approach for the development, operation and maintenance of software.(6th edition pressman ) Software engineering is an engineering discipline that is concerned with all aspects of software production from the early stage of system specification to maintaining the system after it has gone into use.In this definition ,there arer two key phrases(8th edition sommer viille) i)Engineering discipline :It make things work ,they apply theories,method and tools where these are appropriate but use them selectively and always try to discover solutions to problem even there are no applicable theories and method. ii)All aspects of software production:Software engineering is not concerned with the technical processes of software development but also with activities such as software project management and with the development of tools method and theories to support software production. The Evoling Role Of Software: Software takes on a dual (two) roles ,as a product and as a vehicle for delivery a product. As a product: It delivers the computing potential denote by computer hardware or by a network of computers that are accessible by a local hardware.Software resides within a cellular phone Or operates inside a mainframe computer.It is an information transformer-producing,managing ,acquiring,modifying,displaying or transmitting information that can be as simple as single bit or as complex as a mulitimedia presentation. As a vehicle:It for delivering the product ,software acts as the basis for the control of the computer(operating systems),the communication of information(networks) and the creation and control of other programs(software tools and environments). Software also delivers the most important product of our time information.It transforms personal data that can be more useful in a local context(eg.an individuals financial transaction),it manages businesss information to enhance competitiveness,it provides a world wide information to access in network(internet) and acquiring information in all of its forms. Software : Software is not just the programs but also all associated document and configuration data that is needed to make these programs operate correctly. (refer 8th edition Ian.Sommer Ville) Two fundamentals types of software product: i)Generic product
1

ii)Customised product i)Generic product: These are stand-alone system that produced by a development organization ,sold on the open market to any customer who is able to buy them (eg) software for PCs such as data base,word processor. ii)Customised product(bespoke): These are systems which are commissioned by a particular customer.A software contractor develops the software especillly for systems for electronic devices,system written to support a particular business process and air traffic control system. Defintion of Software: (6th ed pressman book) Software is (1) instruction (computer programs) that when executed provide desired features,function and performance. 2)data structures thar enable the programs to adequately manipulateinformation. 3)documents that describe the operation and use of the program. Characteristics of Software:

Software is developed or engineered, it is not manufactured in the classical sense. In both activities software development and hardware manufacturing some similarities exist between them such as high quality is achieved through good design and require construction of product but approaches are different ie the manufacturing phase for hardware can introduce quality problems that are easily corrected for software. Software costs are concentrated in engineering ie that software projects cannot be managed as if they were manufacturing projects.

Software does not wear out. However it deteriorates due to change. Hardware to wear out in the figure failure rate as a function of time for hardware,the failure curve for hardware called to bathtub curveindicates that hardware show high failure rates are often to design or manufacturing defects.

Figure .Failure curve for Hardware

2

Defects are then corrected and failure rate go down to a steady-state level for some period of time again the failure rate rises due to hardware components suffer from the affects of dust,vibration,abuse,temperature extremes and many other environmental problem the hardware begin to wear out thus software is not focus to environmental problem ,so it doesnt wear out ,but it does deteriorate.

Figure. Failure curve for Software In the figure the failure rate curve for software should take the form of the idealized curve.The undiscovered defects or error in the program will cause high failure rates ,however these defects are corrected or without introducing other errors and the curve as flatten. The idealized curve is a gross over simplification of actual failure models for software ,thus software doesnt wear out but it does deteriorate, though software engineering methods try to reduce the magnitude(level) of the spikes and slope of the actual curve. In fact that the customer required changes from the long before delivered of the first version of software will undergo change,as changes are made that errors will be introduced,causing the failure rate curve to spike ,another change is requested causing the curve to spike again ,slowly the minimum failure rate level begins to rise thus the software is deteriorating due to change. Another aspect of wear ,when a hardware components wears out ,it is replaced by a spare part but no spare part for software .Every failure indicate an error in design which was translated into machine-executable code.Therefore software maintenance involves more complexity than hardware maintenance.

Software is custom built rather than assembling existing components.Although the industry is moving towards component based construction, most software continues to be custom built

In the majority of software project there is some software reuse.Asoftware component should be designed and implemented that it can be reused in many different programs.

Modern reusable component encapsulate both data and the processing that is applied to the data,enabling the software engineering to create new applications from reusable part Example:Todays user interface are built with reusable components that enable the creation of graphics windows,pull down menus and a wide variety of interaction mechanisms. The data structures and processing detail required to build the interface are contained within a library of reusable components for interface construction. The Changing Nature Of Software Seven Broad Categories of software are challenges for software engineers System software Embedded software Artificial intelligence software Engineering and scientific software
Application software

Web-applications Product-line software Ubiquitous computing Netsourcing

System software: System software is a collection of programs written to service other programs.Typical programs in this category are compiler,editors and assemblers.The purpose of the system software is to establish a communication with the hardware. Embedded software:It consists of program that can reside within a product or system .Such a softwarecan be used to implement and control features and functions for the enduser and for the system itself. Artificial intelligence software: Artificial intelligence (AI) software is based on knowledge based expert systems, makes use of non-numeric algorithms to solve complex problems that are not agreeable to computation or straightforward analysis.It is useful in robotics,expert systems,image and voice recognition,artificial neural networks, theorem proving and game playing. Engineering and scientific software: Engineering and scientific software have been characterized by "number crunching" algorithms and scientific software applications range from astronomy to volcanology from automotive stress analysis to space shuttle orbital dynamics and from molecular biology to automated manufacturing,computer-aided design and system simulation.
4

Application software:It consists of stand alone programs that are developed for specific business need.This software may be supported by database systems. Web application: It consists of various web page a set of linked hypertext files that iformation using text and limited graphics that can be retrieved by a browser.WebApplications can computing functions ,content to the end user but also integrated with corporate databases and business applications. Product line software: It provide a specific capability for use by many different customers,esoteric(dense) marketplace(e.g.inventory control products) or consumer markets(e.g.wordprocessing,spreadeets,computergraphics,multimedia,entertainment,databa se management,personal and business financial applications. Ubiquitous computing:It consists of wireless networking lead to distributed computing.The challenge for software engineers will be to develop systems and application software that will allow devices ,personal computers and business enterprise system to communicate across vast networks.

LEGACY SOFTWARE:
Legacy software are older programs that are developed decades ago and have been continually modified to meet chance in business requirements and computing platform,such a system for large organization is to find them costly to maintain and risky toevolve The quality of legacy software: The quality of legacy software is poor because it has inextensible design,convoluted code,poor and nonexistent documentation,test cases and results that are not achieved. As time passes legacy systems evolve(changes) due to following reasons: Types of changes are made to legacy systems:

The software must be adapted to meet the needs of new computing environment or technology. The software must be enhanced to implement new business requirements. The software must be extended to make it interoperable with more modern systems or database The software must be re-architected to make it viable within a network environment

Software Evolution:The software is modified to adapt it to changing customer and

market requirements.

Laws of unified theory for software evolution :

5

The Law of Continuing Change E-type systems must be continually adapted or else become progressively less satisfactory.

The Law of Increasing Complexity E-type system evolves its complexity increasing unless work is done to maintain or reduce it.

The Law of Self-Regulation E-type system evolution process is self-regulating with distribution of product and process measures to normal.

The Law of Conservation of Organizational Stability The average effective global activity rate in an evolving E-type system is invariant over product lifetime.

The Law of Conservation of Familiarity E-type systems evolves all associated with it ,developers,sales personnel and user.

The Law of Continuing Growth The functional content of E-type systems must be continually increased to maintain user satisfaction over the systems lifetime.

The Law of Declining Quality The quality of E-type systems will appear to be declining unless they are rigorously maintained and adapted to operational environment changes.

The Feedback System Law E-type evolution processes constitute multilevel,multiloop,multiagent feedback systems and must be treated as such to achieve significant improvement over any reasonable base.

SOFTWARE MYTHS:

Widely held but false view Propagate misinformation and confusion Three types of myths

- Management myth - Customer myth - Practitioners myth

6

MANAGEMENT MYTHS Myth(1) -The

available

standards

and

procedures

for

software

are

enough

Myth(2)

-Each organization feel that they have state-of-art software development tools since they have latest computer. Myth(3)

-Adding more programmers when the work is behind schedule can catch up. Myth(4)

-Outsourcing the software project to third party, we can relax and let that party build it. CUSTOMER MYTH Myth(1)

- General statement of objective is enough to begin writing programs, the details can be filled in later. Myth(2)

-Software is easy to change because software is flexible PRACTITIONERS MYTH Myth(1)

-Once the program is written, the job has been done. Myth(2)

-Until the program is running, there is no way of assessing the quality. Myth(3)

-The only deliverable work product is the working program Myth(4)

-Software Engineering creates voluminous and unnecessary documentation and invariably slows down software development.

SOFTWARE ENGINEERING PARADIGM

Software Engineering Paradigm:
7

Software engineering paradigm or process model is an abstract representation of a process.

Software Engineering A Layered Technology:

Software engineering is a layered technology,Any software can be developed using these layered approaches ,consists of various layers in which technology is based on quality focus layer, process layer,methods layer and tools layer. Software engineering quality focus: Any engineering approach on an organizational responsibility to quality focus is the bedrock or foundation of software engineering technology that lead to the development of more effective approaches. Software engineering process: It is a foundation for software engineering that holds the technology layers together and enables rational and timely development and defines a framework for timely delivery of software. It forms the basis for management control of software projects and establishes the context in which technical methods are applied,work products(models,documents,data,reports,form) are produced,milestones are established ,quality is ensured and change is properly managed. Software engineering method: It provide the technical for building software.In the layer the actual method of implementation is carried out with the help of reauirement analysis,designing,coding using desired programming constructs and testing. Software engineering tools: It provide automated or semiautomated support for the process and the methods. When tools are integrated so that information created by one tool can be used by another,a system for the software development called computer aided software engineering .
8

A GENERIC PROCESS MODEL Definition:Software process as a framework for the tasks that are reqired to build high quality
software A process is a colletion of activities ,actions and tasks that are performed when some work product is to be created. An activity strives to achieve a objectives(e.g. communication with stakeholders) and is applied even if the application domain,size of the project,complexity of the effort with which software engineering is to be applied . An action (e.g.requirements gathering) encompasses a set of tasks that produce a mjor work product(e.g.document,report). A task focuses on a small ,but well-defined objective(e.g. conducting a unit test) that produces a tangible outcome.These are the elements of a software process.

A Process Framework:
Defintion: A process framework establishes the foundation for a complete software process by identifies a number of framework activities that are applicable to all software projects ,regardless of their size or complexity and also include a set of umbrella activities that are applicable across the entire software process. Diagramatic Representation of a software process framework:
Softwareprocess

process framework umbrella activities

Work tasks Work products Quality ssurancepoints Project mile stones

Work tasks Work products Quality ssurancepoints Project mile stones

Work tasks Work products Quality ssurancepoints Project mile stones g Work tasks Work products Quality ssurancepoints Project mile stones

Defining a Framework Activity: Each framework activity is populated by a set of software engineering actions represented by a number of different task sets that identifies the work tasks that are to be completed,the work products that will be produced,the quality assurance points that will be required and the milestones that will be used to indicate progress. The following generic process framework activities applicable for software projects:
Communication:Before any technical work can start,it is important to communicate and

collaborate with custromer(and other stakeholders).The goal is to understand stakeholders objectives for the project and to gather requirements that help define software features and functions.
Planning:This activity creates a software project plan that helps guide the team as it makes

the work.It defines the software engineering work plan by describing the technical risks,the resources reqirement,the work products to be produced and defines a work schedule.
Modeling:This activity includes the creation of models that allow the software engineer

and the customer to better understand software requirements and the design that will achieve those requirements.
10

 Construction:The software design is mapped into combines code generation(either manual

or automated) and the testing is required to uncover errors in the code.

Deployment:The software is delivered to the customer the delivered product should

evaluate and provide feedback based on the evaluation. Umbrella activities: Software engineering process framework activites are complemented by a number of umbrella activities,that are applied throughout a software project and help a software team manage and control progress,quality change and risk. Characteristic or Feature or Typical umbrella activities in this category:

Software project tracking and control:The activity allows the software team to assess progress through the project plan and take any necessary action to maintain the schedule. Risk management:To assesses risks that may affect the outcomes of the project or the qualitiy of the product. Software quality assurance:These activities are defines and conducts the activities required to ensure software quality. Technical reviews:It is required to assess software engineering work product in an effort to uncover and remove errors before they are transferred to the next activity. Measurement: In this activity defines and collect process,project and product measures that assit the team in delivering software that meets stakeholders needs can be used in conjuction with all other framework and umbrella activities. Software configuration management:Manages the effects of change throughout the software process. Reusability management: It defines criteria for work product reuse including software components and establishes mechanisms to achieve reusable components. Work product preparation and production:The activities required to create work products such as models ,documents,logs,forms and lists.

Identifying a Task set: A task set defines a collection of software engineering work tasks,related work products,quality assurance points and project milestones that the actual work to be done to accomplish the objectives of a software engineering action.Different projects demand different task sets.The software team chooses the task set based on problem and project characteristic. For example:Frame activity:communication Software engineering action:requirements gathering

11

requirements gathering software engineering action that occurs during the communication activity.The goal of requirements gathering is to understand what various stakeholders want from the software that is to be built. For a small,simple project,the taskset for requirement gathering might look like this. 1.Make a list of stakeholders for the project. 2.Invite all stajeholders to an informal meeting 3.Ask each stakeholder To make alist of features and functions required. 4.Discuss requirements aaaaand build afinal list. 5.Prioritize requirements 6.Note areas of uncertainty. THE CAPABILITY MATURITY MODEL INTEGRATION(CMMI): The Software Engineering Institute (SEI) has developed a comprehensive process metamodel emphasizing process maturity.It is predicated on asset of system and software capabilities that should be present when organizations reach different levels of process capability and maturity. The CMMI is a process meta-model is used in assessing how well an organizations processes allow to complete and manage new software project. It is significant achievement in software engineering.and provides a wide-ranging discussion of the activities and action when an organization builds computer software. Even if software organization chooses not to adopt its details,every software team should hold its function and get from its discussion of software engineering process and practice. The CMMI represents a process meta-model in two different ways 1)Continuous model 2)Staged model 1)Continuous model: - Describe a process in two dimensions,each process area(e.g.project planning or requirement management) is assessed by specific goals and practices and is rated according to the capability levels. - Lets organization select specific improvement that best meet its business objectives and minimize risk. The followings are CMMI capability levels:

12

Level 0 Incomplete: The process area (e.g.requirements management) is either not performed or does not achieve all goals and objectives defined by the CMMI for level 1 capability. Level 1 Performed:All of the goals of the process area defined by CMMI have been satisfied .Work tasks produce defined work products are the process being carried out. Level 2 Managed: All level 1 criteria have satisfied,all work tasks and work products aremonitored ,controlled and reviewed and are evaluated for performance to the process description. Level 3 Defined:All level 2 criteria have been achieved,the process is tailored or adapted from the organizations set of standard processes according to the organizations adapting guidelines and contributes work products,measures and other process improvement information to the organizational process assets. Level 4 Quantitavely managed:All level 3 criteria have been achieved ,the process area is controlled and improved using measurement and quantitative assessment.Quantitative established for quality and process performance and used as criteria in managing the process. Level 5 Optimized:All capability lvel 4 criteria have been achieved ,the process area is adapted and optimized using quantitative (statistical) to meet changing customer needs and to continually improve the effectiveness of the process area under consideration. The CMMI defines each process area in the terms of specific goals and the specific practices required to achieve these goals,Specific goals establish the characteristics that must exist if the activities implied by a process area are to be effective.Specific practices refine a goal into set of process related activities. Example:Project planning is the process areas defined by the CMMI for the project managementcategory.The specific goals (SG)and the associated specific practices (SP) defined for project planning are SG 1 Establish estimates SP 1.1-1 Estimate the scope of the project SP 1.2-1 Estblish estimates of work product and task attributes SP 1.3-1 Define project life cycle SP 1.4-1 Determine estimates of effort and cost SG 2 Develop a Project Plan SP 2.1-1 Establish the budget and schedule SP 2.2-1 Identify project risks SP 2.3-1 Plan for data management
13

SP 2.4-1 Plan for project resources SP 2.5-1 Plan for needed knowledge and skills SP 2.6-1 Plan stakeholder involvement SP 2.7-1 Establish the project plan SG 3 Obtain communication to the plan SP 3.1-1 Review plans that affect the project SP 3.2-1Reconcile work and resource levels SP 3.3-1 Obtain plan commitment The CMMI also defines a set of five generic goals (GG) and related generic practices (GP)for the project planning each process area are GG 1 Achieve specific goals GP 1.1 Perform base practices GG 2 Institutionalize a managed process GP 2.1 Establish an organizational policy GP 2.2 Plan the process GP 2.3 Provide resources GP 2.4 Assign responsibility GP 2.5Train people GP 2.6 Manage configurations GP 2.7 Identify and involve relevant stakeholders GP 2.8 Monitor and control the process GP 2.9 Objectively evaluate adherence (performance) GP 2.10 Review status with higher level management GG 3 Institutionalize a defined process GP 3.1 Establish a defined process GP 3.2 Collect improvement information GG 4 Institutionalize a quatitatively managed process GP 4.1 Establish quantitative objectives for the process
14

GP 4.2 Stabilize subprocess performance GG 5 Institutionalize an optimizing process GP 5.1 Ensure continuous process improvement GP 5.2 Correct root causes of problems 2)Staged model:
This model is used if you have no clue of how to improve the process for quality software.

- It gives a suggestion of what things other organizations have found helpful to work first - Levels are called maturity levels -To achieve a maturity level ,specfic goal and practices associated with a set of process areas must be achieved.

Maturity level: Optimizing Continuous process improvement Quantitatively management Organisational Innovation and Deployment causal Analysis and Resolution Organization Process performance Quantitative Project management

Quantitatively managed

15

Defined

Process standardization

Requirement Development Technical solution Product integration Verification Validation Organizational Process Focus Organizational Process Defintion Organizational Training Integrated Project Management Integrated Supplier management Risk Management Decision Analysis and Resolution Organizational Environment for Integration Integrated teaming

Managed

Basic project management

Requirements Management Project planning Project Monitoring and Control Supplier Agreement Management Measurement and Analysis Process and Product Quality Assurance Configuration Management

16

Performed

Process patterns:
A process pattern describes a process related problem that is encountered during software engineering work,identifies the environment in which the problem has been encountered and suggests one or more proven solutions to the problem. Definition Stated in general terms[Amb98] a process pattern provides us with a template-a consistent method for describing problem solutions within the context of the software process.By combining patterns,a software team can solve problems and construct a process that best meets the needs of a project. Patterns can be defined at any level of abstraction or concept: -a pattern might be used to describe a problem associated with a complete process model(e.g.prototyping). -patterns can be used to describe a problem associated with a framework activity(e.g.planning)or an action or a task within a frame activity(e.g. project estimating). The following template for describing a process pattern has pproposed by Ambler[AMB98]: Pattern Name:Describes its function within software process(e.g.customer-communication) Intent:The objective of the pattern is described briefly (e.g.)customer-communication is to make mutual relationship with customer to define project scope,business requirements and other constraints. Type:The pattern type is specified .Ambler[AMB98] imply three types:

Task patterns define a software engineering action or work task that is part of the process e.g.requirements gathering is a task pattern. Stage pattern define a framework activity for the process ,it include multiple work tasks,a stage pattern combine multiple task patterns that are related to the stage(framework activity) .e.g.stage pattern be communication,this pattern would incorporate the task pattern requirements gathering Phase Pattern define the sequence of framework activities that occur with the process,even when the overall flow of activites is iterative in nature e.g.phase pattern might be a spiral model or prototyping.

Initial Context The pattern applies are described under the conditions ,before to the initiation of the pattern (1) what organizational or team related activities have already occurred.
17

(2) what is the entry state for the process and (3) what software engineering information or project information already exists. e.g.planning pattern(a stage pattern) requires that (1)customers and software engineers have established a mutual communication (2) number of specified task patterns make successful completion for the customercommunication pattern has occurred (3) project scope,basic business requirements and project constraints are known Problem The problem to be solved by the pattern is described e.g. the problem to be solved by customer-communication ,described in the followings: -an effective format for eliciting (obtain) information is not accepted - a useful mechanism for recording it is not created and meaningful review is not conducted - the communication between the developer and the customer is often not enough. Solution The implementation of the pattern is described.It is describes how the engineering information or project information that is available before the beginning of the pattern is transformed as a result of the successful execution of the pattern. Resulting Context once the pattern has been successfully implemented are described the conditions that will provide result ,depend on completion of the pattern (1) what organizational or team related activities must have ocured (2) what is the exit state for the process (3) what software engineering information or project information has been developed Related Patterns A list of all process patterns that are directly related to this one are provided -as a hierarchy or diagrammatic form . e.g.The stage pattern is communication include the task patterns project-team assembly,collaborative-guideline definition,scope-isolation,requirements gathering,constraintdescription and model creation. PROCESS ASSESSMENT

The existence(life) of software process does not specify the quality of the software or whether the software will be delivered on time or will it stand up to the user requirements. Assessment attempts to keep a check on the current state of the software process with the intention of improving it.

18

Different approaches to Software Assessment or formal techniques for assessing the software process:

Standard CMMI Assessment method for Process Improvement(SCAMPI): It provides a five step process assessment initiating,diagnosing,establishing,acting and learning. model that are

CMM based appraisal for internal process improvement(CBA IPI): It provide a diagnostic technique for assessing the relative maturity of a software organization.

SPICE(ISO/IEC 15504): It defines a set of requirements for software process assessment . To assist organizations in developing an objective evaluation of the efficacy(effectiveness) of any defined software process.

ISO 9001:2000 for software: It is standard assessment applies directly to software organization that wants to improve the overall quality of the products,systems or services.

PROCESS MODELS
Help in the software development Guide the software team through a set of framework activities Process Models may be linear, incremental or evolutionary

Process model goal: (B. Boehm 1988) "determine the order of stages involved in software development and evolution, and to establish the transition criteria for progressing from one stage to the next. These include completion criteria for the current stage plus choice criteria and entrance criteria for the next stage.
19

Problems

The assumption is that requirements can be fully understood prior to development Interaction with the customer occurs only at the beginning (requirements) and end (after delivery) Unfortunately the assumption almost never holds. Advantages:

Reduce risks by improving visibility Allow project changes as the project progresses based on feedback from the customer. The main activities of software production:

They must be performed independently of the model The model simply affects the flow among activities PRESCRIPTIVE MODELS: A prescriptive process model populate(block of) a process framework with a set of software engineering actions and define each action in terms of a task set that identifies the work to be accomplished to meet the development goals. The Waterfall Model

In the begins of the process the customer specification of requirements specified well understood,the work flow from communication through deployment in a linear fashion. The waterfall model called classic life cycle. This Model suggests a systematic, sequential approach to software development that begins at the system level and progresses through analysis, design, code and testing.

Diagram of waterfall model:

20

Waterfall Model Assumptions: 1. The requirements are knowable in advance of implementation. 2. The requirements have no unresolved, high-risk implications e.g., risks due to COTS choices, cost, schedule, performance, safety, security, user interfaces, organizational impacts

3. The nature of the requirements will not change very much during development; during evolution

4. The requirements are compatible with all the key system stakeholders expectations e.g., users, customer, developers, maintainers, investors

5. The right architecture for implementing the requirements is well understood. 6. There is enough calendar time to proceed sequentially.

Problems Or sometime fail in Waterfall Model (Disadvantages):

Real projects rarely follow the sequential flow since they are always iterative, changes can cause confusion as the project team proceeds. It is often difficult for the customer to state all requirements to be unambiguously specified in the beginning of many project. A working model is not available until late in the project time plan.the customer should be patient. In analysis of actual projects ,Bradac[BRA 94] found that the linear way of the waterfall model leads to blocking states in which some project team member must wait for other
21

members of the team to complete dependent tasks so time spenting for waiting exceed the time for productive work .Thus blocking state to be more common at the beginning and end of linear sequential process. it is inflexible partitioning of the project into distinct stage. -reqirements must be made at an early stage in the process,which makes it difficult to respond to changing customer requirements. Advantage of waterfall: -documentation is produced at each phase and that it fits with other engineering process models. THE INCREMENTAL PROCESS MODEL:

Initial software requirements are well-defined,but overall scope of the development li Functionality expanded further in later releases Software is developed in increment near process and compelling need to provide limited functionality quickly

The Incremental Model The Incremental model combines elements of the waterfall model applied in an iterative process. Diagram of Incremental model: The Incremental model applies linear sequences in a staggered fashion as calendar time progress,Each linear sequence produces deliverable increments of software. Software releases in increments the first increment constitutes Core product that basic requirements are addressed and Core product undergoes detailed evaluation by the customer. As a result, plan is developed for the next increment,plan addresses the modification of core product to better meet the needs of customer.Process is repeated until the complete product is produced The increment model focuses on

22

The Incremental Model

Communication Planning Modeling Construction Deployment
Increment#2
Communication Planning

Increment # n
Communication Planning

Modeling
Analysis design

Construction
Code test

Deployment
Delivery Support feedback

delivery of nth increment

Increment # 1
Communication Planning

Modeling
Analysis design

Construction
Code test

Deployment
Delivery Support feedback

Delivery of 2nd increment

Modeling
Analysis design

Construction
Code test

Deployment
Delivery Support feedback

delivery of 1ST increment

w t f o S i a s d y l c n u e r

Project calendar time

.

Increments can be planned to manage technical risks for major system require the availability of new hardware that is under development whose deleivery date is uncertain .It might impossible to plan increment thereby enabling partial functionality to be delivered to end users without inordinate delay. The RAD Model(Rapid Application Development) An incremental software process model Having a short development cycle High-speed adoption of the waterfall model using a component based construction approach Creates a fully functional system within a very short span time of 60 to 90 days

Diagram of The RAD Model:

23

The RAD Model

Team # n
Modeling
Business modeling Data modeling Process modeling

Team # 2 Communication Modeling

Business modeling Data modeling Process modeling

Construction
Component reuse automatic code generation testing

Planning

Construction

Team # 1 Modeling
Business modeling Data modeling Process modeling

Component reuse automatic code generation testing

Deployment
integration delivery feedback
Component reuse automatic code generation testing

Construction

Multiple software teams work in parallel on different functions Modeling encompasses three major phases: Business modeling, Data modeling and process modeling Construction uses reusable components, automatic code generation and testing Problems in RAD

Requires a number of RAD teams Requires commitment from both developer and customer for rapid-fire completion of activities Requires modularity Not suited when technical risks are high EVOLUTIONARY PROCESS MODEL Software evolves over a period of time Business and product requirements often change as development proceeds making a straight-line path to an end product unrealistic Evolutionary models are iterative and as such are applicable to modern day applications Types of evolutionary models Prototyping Spiral model
24

Concurrent development model

Prototyping: Mock up or model( throw away version) of a software product Used when customer defines a set of objective but does not identify input,output,or processing requirements Developer is not sure of: efficiency of an algorithm adaptability of an operating system human/machine interaction

Diagram of Prototype:

Evolutionary Models: Prototype

Communication Quick Plan Modeling Quick design

Deployment delivery & feedback

Construction of prototype

STEPS IN PROTOTYPING: Begins with requirement gathering Identify whatever requirements are known Outline areas where further definition is mandatory A quick design occur Quick design leads to the construction of prototype Prototype is evaluated by the customer Requirements are refined Prototype is turned to satisfy the needs of customer
25

Limitation Of Prototyping In a rush to get it working, overall software quality or long term maintainability are generally overlooked Use of inappropriate OS or PL Use of inefficient algorithm The Spiral Model: An evolutionary model which combines the best feature of the classical life cycle and the iterative nature of prototype model Include new element : Risk element,starts in middle and continually visits the basic tasks of communication, planning,modeling,construction and deployment. Uses Framework activites 1.COMMUNICATION *Tasks required are establish effective communication between developer 2.PLANNING *Estimation *Scheduling *Risk analysis 3.MODELING *Analysis *Design 4.CONSTRUCTION *Code *Test 5.DEPLOYMENT *Delivery *Feedback Diagram

26

Evolutionary Models: The Spiral

Realistic approach to the development of large scale system and software Software evolves as process progresses Better understanding between developer and customer The first circuit might result in the development of a product specification Subsequent circuits develop a prototype And sophisticated version of software

The Concurrent Development Model Also called concurrent engineering Constitutes a series of framework activities, software engineering action, tasks and their associated states All activities exist concurrently but reside in different states Applicable to all types of software development Event generated at one point in the process trigger transitions among the states

THE UNIFIED PROCESS

Evolved by Rumbaugh, Booch, Jacobson combines the best features their OO models And adopts additional features proposed by other experts

Resulted in Unified Modeling Language(UML) Unified process developed Rumbaugh and Booch
27

A framework for Object-Oriented Software Engineering using UML Phases Of Unified Process Inception Phase, Elaboration Phase, Construction Phase, Transition Phase

The Unified Process (UP)

Unified Process Work Products Tasks which are required to be completed during different phases Inception Phase:Vision document,Initial Use-Case model,Initial Risk assessment,Project Plan ElaborationPhase:Use-Casemodel,Analysis,model,Software,Architecture description,Preliminary design model,Preliminary model Construction Phase:Design model,System components,Test plan and procedure,Test cases,Manual Transition Phase:Delivered software increment,Beta test results,General user feedback

VERIFICATION AND VALIDATION

Assuring that a software system meets a user's needs Objectives: To introduce software verification and validation and to discuss the distinction between them To describe the program inspection process and its role in V & V To explain static analysis as a verification technique To describe the Cleanroom software development process
28

Verification vs. Validation

Verification: "Are we building the product right" The software should conform to its specification

Validation: "Are we building the right product" The software should do what the user really requires

V & V must be applied at each stage in the software process Two principal objectives Discovery of defects in a system Assessment of whether the system is usable in an operational situation

Static and dynamic verification

STATIC Software inspections

Concerned with analysis of the static system representation to discover problems May be supplement by tool-based document and code analysis

DYNAMIC Software testing Concerned with exercising and observing product behaviour The system is executed with test data and its operational behaviour is observed

Static and dynamic V&V

Static verification

Requirements specification

High-level design

F ormal specification

Detailed design

Program

Prototype

Dynamic validation

29

Program testing
Can reveal the presence of errors, not their absence

A successful test is a test which discovers one or more errors The only validation technique for non-functional requirements Should be used in conjunction with static verification to provide full V&V coverage

Types of testing
Defect testing Tests designed to discover system defects. A successful defect of defects in a system. test is one which reveals the presence

Statistical testing Tests designed to reflect the frequency of user inputs Used for reliability estimation

V & V goals
Verification and validation should establish confidence that the software is fit for purpose This does not mean completely free of defects Rather, it must be good enough for its intended use The type of use will determine the degree of confidence that is needed

V & V confidence
Depends on systems purpose, user expectations and marketing environment Software function The level of confidence depends on how critical the software is to an organisation

User expectations Users may have low expectations of certain kinds of software
30

Marketing environment

Getting a product to market early may be more important than finding defects in the program

Testing and debugging

Defect testing and debugging are distinct processes Verification and validation is concerned with establishing the existence of defects in a program Debugging is concerned with locating and repairing these errors Debugging involves formulating hypotheses about program behaviour then testing these hypotheses to find the system error

V & V planning
Careful planning is required to get the most out of testing and inspection processes Planning should start early in the development process The plan should identify the balance between static verification and testing Test planning is about defining standards for the testing process rather than describing product tests

The V-model of development

R equirements specifica tion System specification System de gn si D etailed de sign

A cceptance te plan st

System inte gration te plan st

Sub-system inte gration te plan st

M odule and unit code and tess

Service

A cceptance te st

System inte gration test

Sub-system inte gration test

The structure of a software test plan The testing process Requirements traceability Tested items
31

Testing schedule Test recording procedures Hardware and software requirements ConstraintsSoftware inspections

Software inspections
Involve people examining the source representation with the aim of discovering anomalies and defects Do not require execution of a system May be used before implementation

May be applied to any representation of the system Requirements, design, test data, etc.

Very effective technique for discovering errors Many different defects may be discovered in a single inspection In testing, one defect may mask another so several executions are required

Reuse of domain and programming knowledge Reviewers are likely to have seen the types of error that commonly arise

Inspections and testing

Inspections and testing are complementary and not opposing verification techniques Both should be used during the V & V process Inspections can check conformance with a specification but not conformance with thecustomers real requirements Inspections cannot check non-functional characteristics such as performance, usability, etc. Program inspections Formalised approach to document reviews Intended explicitly for defect DETECTION (not correction)Defects may be logical errors anomalies in the code that might indicate an erroneous condition (e.g. an uninitialized variable)
32

non-compliance with standards

Inspection procedure System overview presented to inspection team Code and associated documents are distributed to inspection team in advance Inspection takes place and discovered errors are noted Modifications are made to repair discovered errors Re-inspection may or may not be required Automated static analysis Static analysers are software tools for source text processing. They parse the program text and try to discover potentially erroneous conditions and bring these to the attention of the V & V team. Very effective as an aid to inspections. A supplement to but not a replacement for inspections.

SYSTEM ENGINEERING
System engineering is the activity of specifying,designing,implementing,validating,deploying and maintaining socio-technical systems.It is not concerned with software but also with hardware and the systems interaction with users and its environment.

The System Engineering Hierarchy

Good system engineering begins with a clear understanding of context (characteristics) the world view and then progressively focus until technical detail is understood. It encompasses a collection of top-down and bottom-up method to follow the hierechy Diagram of the system hierarchy It begin with a world view ie the entire business or product domain is examined to ensure that the proper business or technology context be established. The world view is to focus within specifis domain ,the need for targeted system elements are data,software,hardware,people is analyzed. Finally the analysis ,design and construction of a targeted system element is initiated At the top of the hierarchy a very broad context is established and at the bottom technical activities performed by the relevant engineering discipline e.g. hardware or software engineering. Formal state:
33

The world view(WV) is composed of a set of domains (Di),which can each be a system WV=(D1,D2,Dn) Each domain is composed of specific elements(Ei) each of which serves some role in accomplishing the objective and goals of the domain or component Di={E1,E2,Em} Finally,each element is implemented by specifying the technical components(C1) ,the function for an element. Ei={C1,C2Ck} In the software context ,a component could be a program,reusable program component,a module a class or even a programming language

Business or Product Domain

World view

Domain of interest

Domain view

System element

Element view

Detailed view

34

. It is important that the system engineer narrows the focus of work as moves downward that will the engineer enable to understand the domain and finally the product or system in the proper context.

System Modeling
define the processes that serve the needs of the view under consideration. represent the behavior of the processes and the assumptions on which the behavior is based. explicitly define both exogenous and endogenous input to the model. exogenous inputs link one constituent of a given view with other constituents at the same level of other levels; endogenous input links individual components of a constituent at a particular view. represent all linkages (including output) that will enable the engineer to better understand the view.

Business Process Engineering(BPE)

Defintion:Business process engineering(BPE) is to define architectures that will enable a business to use information effectively,is one approach for creating an overall plan for implementing the computing architecture. t uses an integrated set of procedures, methods, and tools to identify how information systems can best meet the strategic goals of an enterprise t focuses first on the enterprise and then on the business area t creates enterprise models, data models and process models t creates a framework for better information management distribution, and control Three different architectures must be analyzed and designed within the context of business objectives and goals:

data architecture applications architecture technology infrastructure

data architecture provides a framework for the information needs of a business or business function application architecture encompasses those elements of a system that transform objects within the data architecture for some business purpose technology infrastructure provides the foundation for the data and application architectures
35

The BPE Hierarchy:

Information strategy planning (ISP) t strategic goals defined t success factors/business rules identified t enterprise model created Business area analysis (BAA) t processes/services modeled t interrelationships of processes and data Application Engineering t a.k.a ... software engineering t modeling applications/procedures that address (BAA) and constraints of ISP Construction and delivery t using CASE and 4GTs, testing

Information Strategy Planning:

Management issues t define strategic business goals/objectives t isolate critical success factors t conduct analysis of technology impact t perform analysis of strategic systems Technical issues t create a top-level data model t cluster by business/organizational area t refine model and clustering

Business Area Analysis:

define naturally cohesive groupings of business functions and data (Martin) perform many of the same activities as ISP, but narrow scope to individual business area
36

identify existing (old) information systems / determine compatibility with new ISP model t define systems that are problematic t defining systems that are incompatible with new information model t begin to establish re-engineering priorities

Product Engineering
Defintion:Product engineering is to translate the customer s desire for a set of defined capabilities into a working product ,to achieve this goal must derive architecture and infrastructure. Architecture includes of Four Distinct System Components Software Hardware Data People Support infrastructure is established and technology tie the components together and information e.g.documents,CD-ROM that is used to support the components. Product Engineering hierarchy:

37

The complete product

System analysis (World view)

capabilities

hardware

software

Component engineering (Domain view)

Processing requirement

data

function

behavior

Analysis & Design Modeling (Element view)

program component

Software Engineering

Construction & Integration (Detailed view)

The overall requirements of the product are obtain from customer encompass information and control needs,product function and behavior ,overall product performance design and interfacing constraints.

38