Unit 1 OOSE

19IT204T - OBJECT ORIENTED SOFTWARE ENGINEERING MRS.D.SARAL JEEVA JOTHI ASST. PROFESSOR DEPT OF CSE VELAMMAL ENGINEERING COLLEGE

OBJECTIVES To understand the phases in a software project To understand fundamental concepts of requirements engineering and Analysis Modeling. To understand the basics of object oriented concept To understand the major considerations for enterprise integration and deployment. To learn various testing and project management techniques

COURSE OUTCOMES CO. NO. COURSE OUTCOME BLOOMS LEVEL At the end of the course students will be able to CO 1 Compare different process models. C4 CO 2 Formulate Concepts of requirements engineering and Analysis Modeling. C4 CO 3 To understand the fundamentals of object oriented concept C3 CO 4 Apply systematic procedure for software design C4 CO 5 Find errors with various testing techniques C4 CO6 Evaluate project schedule, estimate project cost and effort required C5

SYLLABUS UNIT-I Software Process and Agile Development 9 Introduction to Software Engineering, Software Process, Perspective and Specialized Process Models – Introduction to Agility – Agile process – Extreme programming – XP process - Estimation-FP,LOC and COCOMO I and II,Risk Management, Project Scheduling. UNIT-II Requirements Analysis and Specification 9 Software Requirements: Functional and Non-Functional, User requirements, Software Requirements Document – Requirement Engineering Process: Feasibility Studies, Requirements elicitation and analysis, requirements validation, requirements management-Classical analysis: Structured system Analysis, Petri Nets UNIT III- Object Oriented Concepts 9 Introduction to OO concepts, UML Use case Diagram,Class Diagram-Object Diagram-Component Diagram-Sequence and Collaboration-Deployment-Activity Diagram-Package Diagram

UNIT-IV Software Design 9 Design Concepts- Design Heuristic – Architectural Design – Architectural styles, Architectural Design, Architectural Mapping using Data Flow- User Interface Design: Interface analysis, Interface Design – Component level Design: Designing Class based components. UNIT-V Testing and Management 9 Software testing fundamentals- white box testing- basis path testing-control structure testing-black box testing- Regression Testing – Unit Testing – Integration Testing – Validation Testing – System Testing And Debugging – Reengineering process model – Reverse and Forward Engineering. Total: 45 Periods

LEARNING RESOURCES: TEXT BOOKS 1.Roger S. Pressman, “Software Engineering – A Practitioner’s Approach”, Eighth Edition, McGraw-Hill International Edition, 2019.(Unit I,II,IV,V) 2. Ian Sommerville , “Software Engineering”, Global Edition, Pearson Education Asia, 2015.(Unit I,II,III) 3.Bernd Bruegge & Allen H. Dutoit Object-oriented software engineering using UML, patterns, and Java ,Prentice hall ,3 rd Edition 2010.(Unit III) REFERENCES 4.Titus Winters,Tom Manshreck & Hyrum Wright, Software Engineering at Google,lessons learned from programming over time, O’ REILLY publications,2020. (Unit I,II,IV,V) 5.Rajib Mall, “Fundamentals of Software Engineering”, Third Edition, PHI Learning Private Limited, 2009. (Unit I,II,IV,V) 6.PankajJalote , “Software Engineering, A Precise Approach”, Wiley India, 2010 (Unit I,II,IV,V ) ONLINE LINKS 1.http://www.nptelvideos.in/2012/11/software-engineering.html 2. https://nptel.ac.in/courses/106/101/106101061 /

Introduction to Software Engineering

A software is a computer programs along with the associated documents and the configuration data that make these programs operate correctly . A program is a set of instructions (written in form of human-readable code) that performs a specific task. Engineering is the application of scientific and practical knowledge to invent, design, build, maintain, and improve frameworks, processes, etc. Software encompasses: (1) instructions (computer programs) that when executed provide desired features, function, and performance; (2) data structures that enable the programs to adequately store and manipulate information and (3) documentation that describes the operation and use of the programs.

Software Engineering Software engineering is an engineering discipline that’s applied to the development of software in a systematic approach (called a software process). It’s the application of theories, methods, and tools to design build a software that meets the specifications efficiently, cost-effectively, and ensuring quality. It’s not only concerned with the technical process of building a software, it also includes activities to manage the project, develop tools, methods and theories that support the software production. The IEEE definition : The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software.

Computer Science Vs Software Engineering Computer science focuses on the theory and fundamentals, like algorithms, programming languages, theories of computing, artificial intelligence, and hardware design Software Engineering is concerned with the activities of developing and managing a software.

11 Hardware vs. Software Hardware Software Manufactured Wears out Built using components Relatively simple Developed/Engineered Deteriorates Custom built Complex

Why is Software Engineering required? Software Engineering is required due to the following reasons: To manage Large software For more Scalability To minimize software cost To make reliable software For better quality Management

Software Engineers The job of a software engineer is difficult. It has to balance between different people involved, such as: Dealing with users : User don’t know what to expect exactly from the software. The concern is always about the ease of use and response time. Dealing with technical people : Developers are more technically inclined people so they think more of database terms, functionality, etc. Dealing with management : They are concerned with return on their investment, and meeting the schedule.

Characteristics of a good software engineer The features that good software engineers should possess are as follows: Exposure to systematic methods, i.e., familiarity with software engineering principles. Good technical knowledge of the project (Domain knowledge). Good programming abilities. Good communication skills. These skills comprise of oral, written, and interpersonal skills. High motivation. Ability to work in a team, etc.,

A Layered Technology 15 a “ quality ” focus process model methods tools

Process layer : The foundation for software engineering is the process layer. Provides the glue that holds the layers together enables balanced and timely development It defines a framework that must be established for effective delivery of software engineering technology. 2. Method: It provides technical how-to for building software. It encompasses many tasks including communication, requirement analysis, design modeling , program construction, testing and support.

3. Tools: It provide automated or semi-automated support for the process and methods. When tools are integrated the information created by one tool can be used by another for software development. Example: Rational Rose, CASE tools 4. Quality Focus: Quality Focus Engineering approach must rely on quality, Total Quality Management (TQM), six sigma leads to continuous improvement in culture. This culture ultimately helps to develop more effective approaches to SE.

TYPES OF SOFTWARE PRODUCTS: Generic products Stand-alone systems that are marketed and sold to any customer who wishes to buy them. Examples – PC software such as editing, graphics programs, project management tools; CAD software; software for specific markets such as appointments systems for dentists. Customized products Software that is commissioned by a specific customer to meet their own needs. Examples – embedded control systems, air traffic control software, traffic monitoring systems.

Software costs Software costs often dominate computer system costs. The costs of software on a PC are often greater than the hardware cost. Software costs more to maintain than it does to develop. For systems with a long life, maintenance costs may be several times development costs. Software engineering is concerned with cost-effective software development.

Types of software : Software is a set of programs, which is designed to perform a well-defined function. A program is a sequence of instructions written to solve a particular problem. System Software Application Software

1.System Software The system software is a collection of programs designed to operate, control, and extend the processing capabilities of the computer itself. System software is generally prepared by the computer manufacturers. These software products comprise of programs written in low-level languages, which interact with the hardware at a very basic level. System software serves as the interface between the hardware and the end users. E xamples : Operating System Compilers Interpreter Assemblers , etc.

2. Application Software Application software products are designed to satisfy a particular need of a particular environment. Application software may consist of a single program, such as Microsoft's notepad for writing and editing a simple text. It may also consist of a collection of programs, often called a software package, which work together to accomplish a task, such as a spreadsheet package. Examples : Student Record Software Railways Reservation Software Microsoft Office Suite Software Microsoft Word Microsoft Excel Microsoft PowerPoint

However, there also exists another classification of the software. They can easily be classified on the basis of their availability as well as sharability . 1. Freeware S oftware are available free of cost. A user can easily download them from the internet and can easily use them without paying any charges or fees. examples : Adobe Reader Skype Team Viewer Yahoo Messenger

2. Shareware This software is distributed freely to users on a fixed trial basis . It generally comes with a set time limit, and on the expiration of the time limit, the user is finally asked to pay a fixed fee for the continued services . Example: Adobe PHP Debugger WinZip Getright

3. Open-source Such types of software are usually available to users along with their source code which means that the user can easily modify and distribute the software as well as add additional features to them . They can either be chargeable or free. examples : Mozilla Firefox Apache Web Server

Types of Software Applications 1.Real time software: -It interacts with the user. Eg : video conferencing 2.Business System software: -It users one or more database for business information storage Eg : library management, HR management 3 .System software: - It interacts with hardware components so t hat other application software can run on it Eg : compilers , editors, file management utilities 4. Embedded software: -resides within a product or system. (key pad control of a microwave oven, digital function of dashboard display in a car).

5.Personal computer software: -This includes database management,entertainment,computer graphics, multimedia and so on. Eg : CAD programs 6.Web based software: -These are applications that executes on a remote computer and that are accessed by users from their own PC’s Eg : e-commerce application 7.AI software: -It uses algorithms to solve problems that are not open to simple computing and analysis. Eg : pattern matching(voice or image) 8.Engineering/scientific software: -Characterized by “ number crunching ” algorithms. such as automotive stress analysis, molecular biology, orbital dynamics etc

Program vs. Software Software is more than programs. Any program is a subset of software, and it becomes software only if documentation & operating procedures manuals are prepared. There are three components of the software:

1. Program: Program is a combination of source code & object code. 2. Documentation: Documentation consists of different types of manuals. Examples of documentation manuals are: Data Flow Diagram, Flow Charts, ER diagrams, etc.

3. Operating Procedures: Operating Procedures consist of instructions to set up and use the software system and instructions on how react to the system failure. Example of operating system procedures manuals is: installation guide, Beginner's guide, reference guide, system administration guide, etc .

SOFTWARE PROCESS

Software Process The term software specifies to the set of computer programs, procedures and associated documents (Flowcharts, manuals, etc.) that describe the program and how they are to be used. A software process (also knows as software methodology) is a set of related activities that leads to the production of the software. These activities may involve the development of the software from the scratch, or, modifying an existing system. Any software process must include the following four activities : 1.Software specification 2.Software development 3.Software verification and validation 4.Software evolution

1.Software specification (requirements analysis/planning): -Where the customers and engineers define the software that is to be produced and the constraints on its operation -Define the main functionalities of the software and the constrains around them. 2.Software development (design and implementation/coding): -Where the software is designed and programmed. - The software to meet the requirement must be produced. 3.Software verification and validation (testing) : -Where the software is checked to ensure that it is what the customer required. ( The software must be validated to ensure that it does what the customer wants) 4.Software evolution ( software maintenance ): -Where the software is being modified to meet changing customer and market requirements. In practice, they include sub-activities such as requirements validation, architectural design, unit testing, …etc.

Improvement of software development processes: ISO 9000 Software Process Improvement and Capability Determination(SPICE) Capability Maturity Model(CMM) Personal Software Process(PSP) Team Software Process(TSP )

THE SOFTWARE PROCESS MODEL A software process model is a specified definition of a software process, which is presented from a particular perspective . Process models may contain activities, which are part of the software process, software product, and the roles of people involved in software engineering . Examples of the types of software process models: Workflow Model Dataflow Or Activity Model Role/Action Model

1.Workflow model: This shows the series of activities in the process along with their inputs, outputs and dependencies. The activities in this model perform human actions. 2. D ataflow or activity model: This represents the process as a set of activities, each of which carries out some data transformations. It shows how the input to the process, such as a specification is converted to an output such as a design. The activities here may be at a lower level than activities in a workflow model. They may perform transformations carried out by people or by computers. 3. R ole/action model: This means the roles of the people involved in the software process and the activities for which they are responsible.

GENERIC PROCESS MODEL A process was defined as a collection of work activities, actions and tasks that are performed when some work product is to be created. Each of this activities, action, tasks resides within a “framework or model” that defines their relationship with the process and with one another.

Five Activities of a Generic Process Framework Communication : communicate with customer to understand objectives and gather requirements Planning : creates a “ map ” defines the work by describing the tasks, risks and resources, work products and work schedule. Modeling : Create a “ sketch ” , what it looks like architecturally, how the constituent parts fit together and other characteristics. Construction : code generation and the testing. Deployment : Delivered to the customer who evaluates the products and provides feedback based on the evaluation. In addition a set of “umbrella activities” for project tracking and control, quality assurance are applied through out the process.

SOFTWARE PROCESS FRAMEWORK

PROCESS FLOW 1.Linear process flow It executes each of the five framework activities in sequence beginning with the communication and ends with deployment. 2.Iterative process flow Repeats one or more of the activities before proceeding to the next level. 3.Evolutionary process flow It executes the activities in a circular manner. 4.Parallel process fl ow Executes one or more activities in parallel with other activities.

Each phase has three components: Set of activities - This is what you do Set of deliverables - This is what you produce. Quality Control Measures - This is what you use to evaluate the deliverables. C o m m u n i c a t i o n Planning M o d e l i n g C o n s t r u c t i o n D e p l o y m e n t a n a l y s i s d e s i g n c o d e t e s t p r o j e c t i n i t i a t i o n r e q u i r e m e n t g a t h e r i n g estimating scheduling tracking d e l i v e r y s u p p o r t f e e d b a c k

Software Development Life Cycle (SDLC) A software life cycle model (also termed process model) is a pictorial and diagrammatic representation of the software process. It describes entry and exit criteria for each phase. Without SDLC it becomes tough for software project managers to monitor the progress of the project. It aims to produce successful software products. Each process model follows a series of phase unique to its type to ensure success in the steps of software development.

Need of SDLC When a team is developing a software product, there must be a clear understanding among team representative about when and what to do. Otherwise, it would point to chaos and project failure. Software life cycle model describes entry and exit criteria for each phase. A phase can begin only if its stage-entry criteria have been fulfilled. So without a software life cycle model, the entry and exit criteria for a stage cannot be recognized. Without software life cycle models, it becomes tough for software project managers to monitor the progress of the project.

SIX PHASES IN SOFTWARE DEVELOPMENT LIFE CYCLE MODEL There are following six phases in every Software development life cycle model 1. Requirement gathering and analysis 2. Design 3. Implementation or coding 4. Testing 5. Deployment 6. Maintenance

Stage1 : Requirement gathering and analysis Requirement Analysis is the most important and necessary stage in SDLC . Business requirements are gathered in this phase . This phase is the main focus of the project managers and stake holders . Meetings with managers, stake holders and users are held in order to determine the requirements like Who is going to use the system ? How will they use the system? What data should be input into the system? What data should be output by the system? These are general questions that get answered during a requirements gathering phase . After requirement gathering these requirements are analyzed for their validity Finally , a Software Requirement Specification (SRS) document is created which serves the purpose of guideline for the next phase of the model.

Stage2: Design In this phase the system and software design is prepared from the requirement specifications which were studied in the first phase . System Design helps in specifying hardware and system requirements helps in defining overall system architecture . The system design specifications serve as input for the next phase of the model.

Stage 3: Implementation / Coding On receiving system design documents, the work is divided in modules/units and actual coding is started . In this phase the code is produced so it is the main focus for the developer. This is the longest phase of the software development life cycle.

Stage 4: Testing After the code is developed it is tested against the requirements to make sure that the product is actually solving the needs addressed and gathered during the requirements phase. During this phase unit testing, integration testing, system testing, acceptance testing are done.

Stage 5: Deployment After successful testing the product is delivered / deployed to the customer for their use . Stage 6 : Maintenance Once when the customers starts using the developed system then the actual problems comes up and needs to be solved from time to time. This process where the care is taken for the developed product is known as maintenance.

SDLC Models Software Development life cycle (SDLC) is a spiritual model used in project management that defines the stages include in an information system development project, from an initial feasibility study, to the maintenance of the completed application. There are different software development life cycle models specify and design, which are followed during the software development phase. These models are also called " Software Development Process Models ." Each process model follows a series of phase unique to its type to ensure success in the step of software development.

P hases of SDLC life cycle:

PRESCRIPTIVE AND SPECIALIZED PROCESS MODELS

PRESCRIPTIVE PROCESS MODELS A process model provides a specific roadmap for software engineering work. It defines the flow of all activities, actions and tasks , the degree of iteration, the work products, and the organization of the work that must be done. The purpose of process models is to try to reduce the chaos present in developing new software products. P rescriptive process model prescribe a set of process elements —framework activities , software engineering actions, tasks, work products, quality assurance, and change control mechanisms for each project. Each process model also prescribes a process flow (also called a work flow )—that is, the manner in which the process elements are interrelated to one another. Defines a distinct set of activities, actions, tasks, milestones, and work products that are required to engineer high-quality software The activities may be linear, incremental, or evolutionary Prescriptive process models define a prescribed set of process elements and a predictable process work flow .

PRESCRIPTIVE PROCESS MODEL types 1. Waterfall/linear sequential/classic life cycle model -V-model 2. Incremental model -RAD model 3. Evolutionary model -Prototyping model -Spiral model/Risk driven process model 4. Concurrent Development model

1. Waterfall process model Oldest software lifecycle model and best understood by upper management Used when requirements are well understood and risk is low Work flow is in a linear (i.e., sequential) fashion Used often with well-defined adaptations or enhancements to current software The waterfall model, sometimes called the classic life cycle , suggests a systematic, sequential approach to software development that begins with customer specification of requirements and progresses through planning, modeling , construction, and deployment

A dvantage Disciplined approach Simple and easy to understand and use Easy to manage Requirements are very well understood Clearly defined stages Phases are processed and computed one at a time Testing in each phase. Documentation available at the end of each phase . Careful checking by the Software Quality Assurance (SQA) Group at the end of each phase.

D isadvantage The main drawback of the waterfall model is the difficulty of accommodating change after the process is underway. One phase has to be complete before moving onto the next phase. Each phase terminates only when the documents are complete and approved by the SQA group. Maintenance begins when the client reports an error after having accepted the product. It could also begin due to a change in requirements after the client has accepted the product Doesn't support iteration, so changes can cause confusion. Requires customer patience because a working version of the program doesn't occur until the final phase Note: linear nature of the classic life cycle leads to “blocking states” in which some project team members must wait for other members of the team to complete dependent tasks. In fact, the time spent waiting can exceed the time spent on productive work! The blocking state tends to be more prevalent at the beginning and end of a linear sequential process.

Waterfall model problems: It is difficult to respond to changing customer requirements. • This model is only appropriate when the requirements are well understood and changes will be fairly limited during the design process. • Few business systems have stable requirements. • The waterfall model is mostly used for large systems engineering projects where a system is developed at several sites. • The customer must have patience. A working version of the program will not be available until late in the project time-span • Feedback from one phase to another might be too late and hence expensive .

V-model A variation in the representation of the waterfall model is called the V-model V-model describes the relationship of quality assurance actions to the actions associated with communication, modeling , and early construction activities . As a software team moves down the left side of the V , basic problem requirements are refined into progressively more detailed and technical representations of the problem and its solution . Once code has been generated , the team moves up the right side of the V, essentially performing a series of tests (quality assurance actions) that validate each of the models created as the team moves down the left side . In reality, there is no fundamental difference between the classic life cycle and the V-model. The V-model provides a way of visualizing how verification and validation actions are applied to earlier engineering work.

Verification: It involves a static analysis method (review) done without executing code. It is the process of evaluation of the product development process to find whether specified requirements meet. Validation: It involves dynamic analysis method (functional, non-functional), testing is done by executing code. Validation is the process to classify the software after the completion of the development process to determine whether the software meets the customer expectations and requirements.

There are the various phases of Validation Phase of V-model: Unit Testing: In the V-Model, Unit Test Plans (UTPs) are developed during the module design phase. These UTPs are executed to eliminate errors at code level or unit level. A unit is the smallest entity which can independently exist, e.g., a program module. Unit testing verifies that the smallest entity can function correctly when isolated from the rest of the codes/ units. Integration Testing: Integration Test Plans are developed during the Architectural Design Phase. These tests verify that groups created and tested independently can coexist and communicate among themselves. System Testing: System Tests Plans are developed during System Design Phase. Unlike Unit and Integration Test Plans, System Tests Plans are composed by the client?s business team. System Test ensures that expectations from an application developer are met. Acceptance Testing: Acceptance testing is related to the business requirement analysis part. It includes testing the software product in user atmosphere. Acceptance tests reveal the compatibility problems with the different systems, which is available within the user atmosphere. It conjointly discovers the non-functional problems like load and performance defects within the real user atmosphere.

2. Incremental Process Models Used when requirements are well understood Multiple independent deliveries are identified Work flow in a linear (i.e., sequential) and increment fashion Iterative in nature and focuses on an operational product with each increment It combines linear and parallel process flow Each linear sequence produces deliverable increments of the software

The incremental model combines the linear and parallel process flows For example : word-processing software developed using the incremental paradigm might deliver basic file management, editing, and document production functions in the first increment more sophisticated editing and document production capabilities in the second increment spelling and grammar checking in the third increment advanced page layout capability in the fourth increment It should be noted that the process flow for any increment can incorporate the prototyping paradigm

When we use the Incremental Model? When the requirements are superior. A project has a lengthy development schedule. When Software team are not very well skilled or trained. When the customer demands a quick release of the product. You can develop prioritized requirements first. Advantage of Incremental Model Errors are easy to be recognized. Easier to test and debug More flexible. Simple to manage risk because it handled during its iteration. The Client gets important functionality early. Disadvantage of Incremental Model Need for good planning Total Cost is high. Well defined module interfaces are needed.

RAD model RAPID APPLICATION DEVELOPMENT It is the extension of incremental model that emphasizes on extremely short development cycle ( ie ., 60 to 90 days) Phases in RAD model: Communication Planning Modeling Business modeling Data modeling Process modeling Construction Deployment

Any one modelling techniques can be used or all the techniques can be used. Uses multiple teams on scalable projects It requires heavy resources Requires developers and customers who are heavily committed Performance can be a problem

Waterfall Model Incremental Model Need of Detailed Documentation in waterfall model is Necessary. Need of Detailed Documentation in incremental model is Necessary but not too much. In waterfall model early stage planning is necessary. In incremental model early stage planning is also necessary. There is high amount risk in waterfall model. There is low amount risk in incremental model. There is long waiting time for running software in waterfall model. There is short waiting time for running software in incremental model. Waterfall model can’t handle large project. Incremental model also can’t handle large project. Flexibility to change in waterfall model is Difficult. Flexibility to change in incremental model is Easy. Cost of Waterfall model is Low. Cost of incremental model is also Low. Testing is done in waterfall model after completion of all coding phase. Testing is done in incremental model after every iteration of phase. Returning to previous stage/phase in waterfall model is not possible. Returning to previous stage/phase in incremental model is possible. In waterfall model large team is required. In incremental model large team is not required. In waterfall model overlapping of phases is not possible. In incremental model overlapping of phases is possible. There is only one cycle in waterfall model. There is multiple development cycles take place in incremental model.

3. Evolutionary Process Models Evolutionary process models produce an increasingly more complete version of the software with each iteration. Evolutionary models are iterative . It is used when Business and product requirements often change as development proceeds. To deliver a working system to end users the development starts with those requirements which are best understood Types: Prototyping model Spiral model

( i ) Prototyping Model Multiple iterations are used After each iteration the result is evaluated by the customer The prototype model requires that before carrying out the development of actual software, a working prototype of the system should be built. In many instances, the client only has a general view of what is expected from the software product. In such a scenario where there is an absence of detailed information regarding the input to the system, the processing needs, and the output requirement, the prototyping model may be employed.

Steps of Prototype Model Requirement Gathering and Analyst Quick Decision Build a Prototype Assessment or User Evaluation Prototype Refinement Engineer Product

ADVANTAGES: Customer can see steady progress This is useful when requirements are changing rapidly Reduce the risk of incorrect user requirement Good where requirement are changing/uncommitted Support early product marketing Reduce Maintenance cost. Errors can be detected much earlier as the system is made side by side .

DISADVANTAGES: It is impossible to know how long it will take to produce software (Difficult to know how long the project will last ) There is no way to know the number of iterations will be required An unstable/badly implemented prototype often becomes the final product. Require extensive customer collaboration Costs customer money Needs committed customer Difficult to finish if customer withdraw May be too customer specific, no broad market Prototyping tools are expensive.(Special tools & techniques are required to build a prototype) It is a time-consuming process.

(II) The Spiral Model The spiral model is an evolutionary software process model that couples the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model. The spiral model can be adapted to apply throughout the entire life cycle of an application, from concept development to maintenance . The spiral development model is also called as risk -driven process model Each p hase in spiral model begins with design goal and ends with client reviewing Software is developed in a series of incremental releases. It has two main distinguishing features. A CYCLIC APPROACH T he software team performs activities that are implied by a circuit/loop/task region around the spiral in a clockwise direction, beginning at the centre.

2. A SET OF ANCHOR POINT MILESTONES A combination of work products and conditions that are attained along the path of the spiral— are noted for each evolutionary pass . the first circuit around the spiral might represent a concept of developing product specification ” that starts at the core of the spiral and continues for multiple iterations until concept development is complete . Second circuit around the spiral might represent a product development Third circuit around the spiral might represent a product enhancement Fourth circuit around the spiral might represent a System maintenance

When to use spiral model? When project is large When releases are required to be frequent When risk and cost estimation is important When changes may required at any time For medium to high risk projects

Advantages The spiral model is a realistic approach to the development of large-scale systems and software . Because software evolves as the process progresses, the developer and customer better understand and react to risks at each evolutionary level . The spiral model uses prototyping as a risk reduction mechanism The spiral model demands a direct consideration of technical risks at all stages of the project and, if properly applied, should reduce risks before they become problematic .

Disadvantages It may be difficult to convince customers (particularly in contract situations) that the evolutionary approach is controllable. It demands considerable risk assessment expertise and relies on this expertise for success . If a major risk is not uncovered and managed, problems will undoubtedly occur . If your management demands fixed-budget development ( generally a bad idea ), the spiral can be a problem . As each circuit is completed, project cost is revisited and revised.

4. CONCURRENT MODELS It allows a software team to represent iterative and concurrent elements of any of the process models For example, the modeling activity defined for the spiral model is accomplished by invoking one or more of the following software engineering actions: prototyping, analysis, and design . Concurrent modeling defines a series of events that will trigger transitions from state to state for each of the software engineering activities, actions, or tasks.

SPECIALIZED PROCESS MODEL Take on many of the characteristics of one or more of the conventional models Tend to be applied when a narrowly defined software engineering approach is chosen SPECIALIZED PROCESS MODEL TYPES: Components based development(Promotes reusable components) The Formal Methods Model(Mathematical formal methods are backbone here) Aspect oriented software development(AOSD) (Uses crosscutting technology)

1. Component based development 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 . The process to apply when reuse is a development object. The model focuses on pre-packaged software components. It promotes software reusability.

Modeling and construction activities begin with the identification of candidate components . Candidate components can be designed as either conventional software modules or object oriented packages. Component based development has the following steps: 1. Available component based products are researched and evaluated for the application domain. 2. Component integration issues are considered. 3. A software architecture is designed to accommodate the components. 4. Components are integrated into the architecture. 5. Comprehensive testing is conducted to ensure proper functionality.

ADVANTAGES: - Leads to software reuse -70% reduction in development cycle DISADVANTAGES: -Components library must be robust -performance may be degrade

Problems in Component based development Component trustworthiness - how can a component with no available source code be trusted ? Component certification - who will certify the quality of components? Requirements trade-offs - how do we do trade-off analysis between the features of one component and another?

2. The formal methods model Formal methods provide a basis for software verification and therefore enable software engineer to discover and correct errors that might otherwise go undetected. Encompasses a set of activities that leads to formal mathematical specification of computer software Enables a software engineer to specify, develop, and verify a computer-based system by applying a rigorous mathematical notation ADVANTAGES: Ambiguity , incompleteness, and inconsistency can be discovered and corrected more easily through mathematical analysis When mathematical methods are used during software development, they provide a mechanism for eliminating many of the problems that are difficult to overcome using other software engineering paradigms . Offers the promise of defect-free software Used often when building safety-critical systems

Problems/Challenges/Disadvantages: The development of formal models is currently time-consuming and expensive. Because few developers have the necessary background knowledge to apply formal methods, extensive training is required to others. It is difficult to use this model as a communication mechanism for technically unsophisticated people.

3. Aspect oriented Software Development Aspect Oriented Software Development (AOSD) often referred to as aspect oriented programming (AOP), a relatively new paradigm that provides process and methodology for defining, specifying designing and constructing aspects. It addresses limitations inherent in other approaches, including object-oriented programming. AOSD aims to address crosscutting concerns by providing means for systematic identification, separation, representation and composition . This results in better support for modularization hence reducing development, maintenance and evolution costs . Example “concerns ”: Security, Fault Tolerance, Task synchronization, Memory Management. When concerns cut across multiple system functions, features, and information, they are often referred to as crosscutting concerns

Advantages -increases modularity and reusability -increases maintainability Disadvantage -reduce efficiency due to increase overhead aspects -security risks involving aspects

UNIFIED PROCESS

The Unified Process The Unified Process (UP) is an attempt to draw on the best features and characteristics of conventional software process models, but characterize them in a way that implements many of the best principles of agile software development. The Unified Process recognizes the importance of customer communication and streamlined methods for describing the customer’s view of a system. It helps the architect to focus on the right goals, such as understand ability, reliance to future changes, and reuse. It is completely a diagrammatic representation . Some UML ( unified modelling language) modelling approaches are used.

Phases of the Unified Process Consists of five phases: inception, elaboration, construction, transition, and production Inception phase : encompasses both customer communication and planning activities. Elaboration phase : encompasses planning and modeling activities. Construction phase : is identical to the construction activity. Transition phase : encompasses latter stages of construction activity and first part of the generic deployment activity . Production phase : coincides with the deployment activity of the generic process.

1. Inception Phase • Encompasses both customer communication and planning activities of the generic process • Business requirements for the software are identified Fundamental business requirements are described through preliminary use cases – A use case describes a sequence of actions that are performed by a user • A rough architecture for the system is proposed • A plan is created for an incremental, iterative development • 2. Elaboration Phase Encompasses both customer planning and modelling activities of the generic process Here the UML diagram will be generated Elaboration for the usecase to analyse, design, implement, development in UML Architectural model is created in this phase

3. Construction Phase • Encompasses the construction activity of the generic process • Uses the architectural model from the elaboration phase as input • Develops or acquires the software components that make each use-case operational • Analysis and design models from the previous phase are completed to reflect the final version of the increment • Use cases are used to derive a set of acceptance tests that are executed prior to the next phase

4 . Transition Phase • Encompasses the last part of the construction activity and the first part of the deployment activity of the generic process • Software is given to end users for beta testing and user feedback reports on defects and necessary changes • The software teams create necessary support documentation (user manuals, troubleshooting guides, installation procedures ) • At the conclusion of this phase, the software increment becomes a usable software release 5 . Production Phase • Encompasses the last part of the deployment activity of the generic process • On-going use of the software is monitored • Support for the operating environment (infrastructure) is provided • Defect reports and requests for changes are submitted and evaluated

Major Workflow Produced for Unified Process

Advantages: -It covers the complete s/w development life cycle -The best practise foe s/w development are supported by UP model -It encourages designing in UML Disadvantages: -Could be complex to implement -Experts are need for it

PERSONAL PROCESS MODELS (PPM) AND TEAM PROCESS MODELS (TPM)

PERSONAL PROCESS MODELS (PPM) What Is Personal Software Process (PSP )? The Personal Software Process ( PSP ) is a structured software development process that is intended to help software engineers understand and improve their performance, by using a "disciplined, data-driven procedure“ The PSP was created by Watts Humphrey to apply the underlying principles of the Software Engineering Institute ’s (SEI ) , Capability Maturity Model (CMM) to the software development practices of a single developer. It claims to give software engineers the process skills necessary to work on a Team Software Process (TSP) team. • The Personal Software Process (PSP) shows engineers how to - manage the quality of their projects - make commitments they can meet - improve estimating and planning - reduce defects in their products

PSP emphasizes the need to record and analyse the types of errors you make, so you can develop strategies to eliminate them. • Because personnel costs constitute 70 percent of the cost of software development, the skills and work habits of engineers largely determine the results of the software development process. • Based on practices found in the CMMI, the PSP can be used by engineers as a guide to a disciplined and structured approach to developing software. The PSP is a prerequisite for an organization planning to introduce the TSP. What is the need/use for PSP? Improve their estimating and planning skills. Make commitments they can keep. Manage the quality of their projects. Reduce the number of defects in their work.

PSP Framework Activities Planning High level Design High level Design Review Development Postmortem

PSP strucure PSP training follows an evolutionary improvement approach: an engineer learning to integrate the PSP into his or her process begins at the first level - PSP0 - and progresses in process maturity to the final level - PSP2.1 . Each Level has detailed scripts, Checklists Templates to guide the engineer through required steps and helps the engineer improve his own personal software process . Humphrey encourages proficient engineers to customize these scripts and templates as they gain an understanding of their own strengths and weaknesses.

PSP0,PSP 0.1 -Introduces process discipline and measurement PSP 1,PSP 1.1 -Introduces process estimation and planning PSP 2,PSP 2.1 -Introduces process quality management and design

TEAM PROCESS MODELS (TPM) What Is Team Software Process (TSP)? In combination with the Personal Software Process (PSP), the Team Software Process (TSP) provides a defined operational process framework that is designed to help teams of managers and engineers organize projects and produce software products that range in size from small projects of several thousand lines of code (KLOC) to very large projects greater than half a million lines of code . The TSP is intended to improve the levels of quality and productivity of a team's software development project The Team Software Process (TSP), along with the Personal Software Process, helps the high performance engineer to ensure quality software products create secure software products improve process management in an organization

How TSP Works Before engineers can participate in the TSP, it is required that they have already learned about the PSP, so that the TSP can work effectively. Training is also required for other team members, the team lead, and management. The coach role focuses on supporting the team and the individuals on the team The team leader role is different from the coach role in that, - team leader are responsible to management for products and project outcomes - coach is responsible for developing individual and team performance TSP Framework Activities Launch high level design Implementation Integration Test Postmortem

PSP Framework Activities TSP Framework Activities Planning Launch high level design High level Design Implementation High level Design Review Integration Development Test Postmortem Postmortem

AGILE PROCESS

Agile Software Development " Agile process model " refers to a software development approach based on iterative development. Agile methods break tasks into smaller iterations, or parts do not directly involve long term planning. The project scope and requirements are laid down at the beginning of the development process. Plans regarding the number of iterations, the duration and the scope of each iteration are clearly defined in advance. Each iteration is considered as a short time "frame" in the Agile process model, which typically lasts from one to four weeks . The division of the entire project into smaller parts helps to minimize the project risk and to reduce the overall project delivery time requirements. Each iteration involves a team working through a full software development life cycle including planning, requirements analysis, design, coding, and testing before a working product is demonstrated to the client. AGILE methodology is a practice that promotes continuous iteration of development and testing throughout the software development lifecycle of the project. In the Agile model, both development and testing activities are concurrent, unlike the Waterfall model.

Phases of Agile Model: Requirements gathering Design the requirements Construction/ iteration Testing/ Quality assurance Deployment Feedback

1. Requirements gathering: In this phase, you must define the requirements . You should explain business opportunities and plan the time and effort needed to build the project. Based on this information, you can evaluate technical and economic feasibility. 2. Design the requirements: When you have identified the project, work with stakeholders to define requirements. You can use the user flow diagram or the high-level UML diagram to show the work of new features and show how it will apply to your existing system .

3. Construction/ iteration: When the team defines the requirements, the work begins . Designers and developers start working on their project, which aims to deploy a working product. The product will undergo various stages of improvement, so it includes simple, minimal functionality. 4. Testing: In this phase, the Quality Assurance team examines the product's performance and looks for the bug . 5 . Deployment: In this phase, the team issues a product for the user's work environment. 6. Feedback: After releasing the product, the last step is feedback. In this, the team receives feedback about the product and works through the feedback.

Agile Testing Methods: Scrum Crystal Methodologies Dynamic Software Development Method(DSDM) Feature Driven Development(FDD) Lean Software Development eXtreme Programming(XP) XP process

1. SCRUM SCRUM is an agile development process focused primarily on ways to manage tasks in team-based development conditions. There are three roles in it, and their responsibilities are: Scrum Master: The scrum can set up the master team, arrange the meeting and remove obstacles for the process Product owner: The product owner makes the product backlog, prioritizes the delay and is responsible for the distribution of functionality on each repetition. Scrum Team: The team manages its work and organizes the work to complete the sprint or cycle.

Product Backlog This is a repository where requirements are tracked with details on the number of requirements(user stories) to be completed for each release . It should be maintained and prioritized by Product Owner, and it should be distributed to the scrum team. Team can also request for a new requirement addition or modification or deletion

Scrum Practices

Process flow of Scrum Methodologies: Process flow of scrum testing is as follows: Each iteration of a scrum is known as Sprint Product backlog is a list where all details are entered to get the end-product During each Sprint, top user stories of Product backlog are selected and turned into Sprint backlog Team works on the defined sprint backlog Team checks for the daily work At the end of the sprint, team delivers product functionality

2. eXtreme Programming(XP) This type of methodology is used when customers are constantly changing demands or requirements, or when they are not sure about the system's performance . The XP develops software keeping customer in the target .

Business requirements are gathered in terms of stories. All those stories are stored in a place called the parking lot. In this type of methodology, releases are based on the shorter cycles called Iterations with span of 14 days time period. Each iteration includes phases like coding, unit testing and system testing where at each phase some minor or major functionality will be built in the application.

Phases of eXtreme programming: There are 6 phases available in Agile XP method, and those are explained as follows: 1.Planning Identification of stakeholders and sponsors Infrastructure Requirements Security related information and gathering Service Level Agreements and its conditions 2.Analysis Capturing of Stories in Parking lot Prioritize stories in Parking lot Scrubbing of stories for estimation Define Iteration SPAN(Time) Resource planning for both Development and QA teams

3.Design Break down of tasks Test Scenario preparation for each task Regression Automation Framework 4.Execution Coding Unit Testing Execution of Manual test scenarios Defect Report generation Conversion of Manual to Automation regression test cases Mid Iteration review End of Iteration review

5.Wrapping Small Releases Regression Testing Demos and reviews Develop new stories based on the need Process Improvements based on end of iteration review comments 6.Closure Pilot Launch Training Production Launch SLA Guarantee assurance Review SOA strategy Production Support

There are two storyboards available to track the work on a daily basis, and those are listed below for reference. Story Cardboard This is a traditional way of collecting all the stories in a board in the form of stick notes to track daily XP activities. As this manual activity involves more effort and time, it is better to switch to an online form. Online Storyboard Online tool Storyboard can be used to store the stories. Several teams can use it for different purposes.

3. Crystal Methodologies: There are three concepts of this method- a . Chartering : Multi activities are involved in this phase such as making a development team, performing feasibility analysis, developing plans, etc. b . Cyclic delivery : under this, two more cycles consist, these are: -Team updates the release plan. - Integrated product delivers to the users. c . Wrap up : According to the user environment, this phase performs deployment, post-deployment.

4. Dynamic Software Development Method(DSDM): DSDM is a rapid application development strategy for software development and gives an agile project distribution structure. The essential features of DSDM are that users must be actively connected, and teams have been given the right to make decisions . The techniques used in DSDM are: Time Boxing MoSCoW Rules Prototyping The DSDM project contains seven stages: Pre-project Feasibility Study Business Study Functional Model Iteration Design and build Iteration Implementation Post-project

5. Feature Driven Development(FDD ) This method focuses on "Designing and Building" features. In contrast to other smart methods, FDD describes the small steps of the work that should be obtained separately per function . It includes domain walkthrough, design inspection, promote to build, code inspection and design. FDD develops product keeping following things in the target Domain object Modeling Development by feature Component/ Class Ownership Feature Teams Inspections Configuration Management Regular Builds Visibility of progress and results

6. Lean Software Development: Lean software development methodology follows the principle "just in time production .“ The lean method indicates the increasing speed of software development and reducing costs . Lean development can be summarized in seven phases Eliminating Waste Amplifying learning Defer commitment (deciding as late as possible) Early delivery Empowering the team Building Integrity Optimize the whole

When to use the Agile Model? When frequent changes are required. When a highly qualified and experienced team is available. When a customer is ready to have a meeting with a software team all the time. When project size is small.

Agile Model Waterfall Model Agile method proposes incremental and iterative approach to software design Development of the software flows sequentially from start point to end point. The agile process is broken into individual models that designers work on The design process is not broken into an individual models The customer has early and frequent opportunities to look at the product and make decision and changes to the project The customer can only see the product at the end of the project Agile model is considered unstructured compared to the waterfall model Waterfall model are more secure because they are so plan oriented Small projects can be implemented very quickly. For large projects, it is difficult to estimate the development time. All sorts of project can be estimated and completed. Error can be fixed in the middle of the project. Only at the end, the whole product is tested. If the requirement error is found or any changes have to be made, the project has to start from the beginning Development process is iterative, and the project is executed in short (2-4) weeks iterations. Planning is very less. The development process is phased, and the phase is much bigger than iteration. Every phase ends with the detailed description of the next phase. Documentation attends less priority than software development Documentation is a top priority and can even use for training staff and upgrade the software with another team Every iteration has its own testing phase. It allows implementing regression testing every time new functions or logic are released. Only after the development phase, the testing phase is executed because separate parts are not fully functional. In agile testing when an iteration end, shippable features of the product is delivered to the customer. New features are usable right after shipment. It is useful when you have good contact with customers. All features developed are delivered at once after the long implementation phase. Testers and developers work together Testers work separately from developers At the end of every sprint, user acceptance is performed User acceptance is performed at the end of the project. It requires close communication with developers and together analyze requirements and planning Developer does not involve in requirement and planning process. Usually, time delays between tests and coding

Advantage(Pros) of Agile Method: Frequent Delivery Face-to-Face Communication with clients. Efficient design and fulfils the business requirement. Anytime changes are acceptable. It reduces total development time.

Disadvantages(Cons) of Agile Model: Due to the shortage of formal documents, it creates confusion and crucial decisions taken throughout various phases can be misinterpreted at any time by different team members. Due to the lack of proper documentation, once the project completes and the developers allotted to another project, maintenance of the finished project can become a difficulty.

Software Cost Estimation

Software Cost Estimation For any new software project, it is necessary to know how much it will cost to develop and how much development time will it take. These estimates are needed before development is initiated, but how is this done? Several estimation procedures have been developed and are having the following attributes in common. Project scope must be established in advanced. Software metrics are used as a support from which evaluation is made. The project is broken into small pieces which are estimated individually. To achieve true cost & schedule estimate, several option arise. Acquire one or more automated estimation tools.

Uses of Cost Estimation During the planning stage, one needs to choose how many engineers are required for the project and to develop a schedule. In monitoring the project's progress, one needs to access whether the project is progressing according to the procedure and takes corrective action, if necessary.

Cost Estimation Models A model may be static or dynamic. In a static model , a single variable is taken as a key element for calculating cost and time . In a dynamic model , all variable are interdependent, and there is no basic variable .

Static, Single Variable Models: When a model makes use of single variables to calculate desired values such as cost, time, efforts, etc. is said to be a single variable model. The most common equation is : C= aL b Where C = Costs L= size a and b are constants The Software Engineering Laboratory established a model called SEL model, for estimating its software production. This model is an example of the static, single variable model. E=1.4L 0.93 DOC=30.4L 0.90 D=4.6L 0.26 Where E= Efforts (Person Per Month) DOC=Documentation (Number of Pages) D = Duration (D, in months) L = Number of Lines per code

Static, Multivariable Models: These models are based on method (1), they depend on several variables describing various aspects of the software development environment. In some model, several variables are needed to describe the software development process, and selected equation combined these variables to give the estimate of time & cost. These models are called multivariable models. WALSTON and FELIX develop the models at IBM provide the following equation gives a relationship between lines of source code and effort : E=5.2L 0.91 In the same manner duration of development is given by D=4.1L 0.36

The productivity index uses 29 variables which are found to be highly correlated productivity as follows Where, W i is the weight factor for the i th variable and X i ={-1,0,+1} the estimator gives X i one of the values -1, 0 or +1 depending on the variable decreases, has no effect or increases the productivity .

Example: Compare the Walston -Felix Model with the SEL model on a software development expected to involve 8 person-years of effort. Calculate the number of lines of source code that can be produced. Calculate the duration of the development. Calculate the productivity in LOC/PY Calculate the average manning

Solution: The amount of manpower involved = 8PY=96persons-months (a)Number of lines of source code can be obtained by reversing equation to give: Then L (SEL) = (96/1.4)1⁄0.93=94264 LOC L (SEL) = (96/5.2)1⁄0.91=24632 LOC (b)Duration in months can be calculated by means of equation D (SEL) = 4.6 (L) 0.26 = 4.6 (94.264)0.26 = 15 months D (W-F) = 4.1 L 0.36 = 4.1 (24.632)0.36 = 13 months

(c) Productivity is the lines of code produced per persons/month (year) ( d)Average manning is the average number of persons required per month in the project

Currently three metrics are popularly being used widely to estimate size : LINES OF CODE (LOC) FUNCTION POINT (FP) CONSTRUCTIVE COST ESTIMATION MODEL (COCOMO 1 AND 2) The usage of each of these metrics in project size estimation has its own advantages and disadvantages.

1. Lines of Code (LOC) LOC is the simplest among all metrics available to estimate project size. This metric is very popular because it is simplest to use. Using this metric, the project size is estimated by counting the number of source instructions in the developed program. Obviously , while counting the number of source instructions, lines used for commenting the code and the header lines should be ignored. Determining the LOC count at the end of a project is a very simple job . However, accurate estimation of the LOC count at the beginning of a project is very difficult . In order to estimate the LOC count at the beginning of a project, project managers usually divide the problem into modules, and each module into submodules and so on, until the sizes of the different leaf-level modules can be approximately predicted. To be able to do this, past experience in developing similar products is helpful. By using the estimation of the lowest level modules, project managers arrive at the total size estimation.

Program to Add Two Integers #include < stdio.h > int main() { int number1, number2, sum; printf ("Enter two integers: "); scanf ("%d %d", &number1, &number2); // calculating sum sum = number1 + number2; printf ("%d + %d = %d", number1, number2, sum); return 0; } Total 11 lines 11-2=9 loc

2. Functional Point (FP) Analysis Allan J. Albrecht initially developed function Point Analysis in 1979 at IBM and it has been further modified by the International Function Point Users Group (IFPUG). FPA is used to make estimate of the software project, including its testing in terms of functionality or function size of the software product. However , functional point analysis may be used for the test estimation of the product. The functional size of the product is measured in terms of the function point, which is a standard of measurement to measure the software application.

Objectives of FPA The basic and primary purpose of the functional point analysis is to measure and provide the software application functional size to the client, customer, and the stakeholder on their request. Further , it is used to measure the software project development along with its maintenance, consistently throughout the project irrespective of the tools and the technologies . One of the important advantages of using the function point metric is that it can be used to easily estimate the size of a software product directly from the problem specification. This is in contrast to the LOC metric, where the size can be accurately determined only after the product has fully been developed.

Various functions used in an application can be put under five types, as shown in Table: Types of FP Attribute Measurements Parameters Examples 1.Number of External Inputs(EI) Input screen and tables 2. Number of External Output (EO) Output screens and reports 3. Number of external inquiries (EQ) Prompts and interrupts. 4. Number of internal files (ILF) Databases and directories 5. Number of external interfaces (EIF) Shared databases and shared routines.

The FPA functional units are shown in Fig :

Following are the points regarding FPs 1. FPs of an application is found out by counting the number and types of functions used in the applications 2. FP characterizes the complexity of the software system and hence can be used to depict the project time and the manpower requirement. 3. The effort required to develop the project depends on what the software does. 4. FP is programming language independent. 5. FP method is used for data processing systems, business systems like information systems. 6. The five parameters mentioned above are also known as information domain characteristics. 7. All the parameters mentioned above are assigned some weights that have been experimentally determined and are shown in Table

Weights of 5-FP Attributes Measurement Parameter Low Average High 1. Number of external inputs (EI) 7 10 15 2. Number of external outputs (EO) 5 7 10 3. Number of external inquiries (EQ) 3 4 6 4. Number of internal files (ILF) 4 5 7 5. Number of external interfaces (EIF) 3 4 6

The functional complexities are multiplied with the corresponding weights against each function, and the values are added up to determine the UFP (Unadjusted Function Point) of the subsystem.

The Function Point (FP) is thus calculated with the following formula. FP = Count-total * [0.65 + 0.01 * ∑(f i )] w.k.t CAF = [0.65 + 0.01 *∑(f i )] FP = Count-total * CAF where Count-total is obtained from the above Table.

9 . FP metrics is used mostly for measuring the size of Management Information System (MIS) software. 10. But the function points obtained above are unadjusted function points (UFPs). These (UFPs) of a subsystem are further adjusted by considering some more General System Characteristics (GSCs). It is a set of 14 GSCs that need to be considered. The procedure for adjusting UFPs is as follows: (a)Degree of Influence(DI)for each of these 14 GSCs is assessed on a scale of 0 to 5 . (b) If a particular GSC has no influence, then its weight is taken as 0 and if it has a strong influence then its weight is 5. (b)The score of all 14 GSCs is totalled to determine Total Degree of Influence (TDI). (c)Then Value Adjustment Factor (VAF) is computed from TDI by using the formula: VAF = (TDI * 0.01) + 0.65

Remember that the value of VAF lies within 0.65 to 1.35 because When TDI = 0, VAF = 0.65 When TDI = 70, VAF = 1.35 VAF is then multiplied with the UFP to get the final FP count: FP = VAF * UFP

Example: Compute the function point, productivity, documentation, cost per function for the following data: Number of user inputs = 24 Number of user outputs = 46 Number of inquiries = 8 Number of files = 4 Number of external interfaces = 2 Effort = 36.9 p-m Technical documents = 265 pages User documents = 122 pages Cost = $7744/ month Various processing complexity factors are: 4, 1, 0, 3, 3, 5, 4, 4, 3, 3, 2, 2, 4, 5.

Solution: Measurement Parameter Count Weighing factor 1. Number of external inputs (EI) 24 * 4 = 96 2. Number of external outputs (EO) 46 * 4 = 184 3. Number of external inquiries (EQ) 8 * 6 = 48 4. Number of internal files (ILF) 4 * 10 = 40 5. Number of external interfaces (EIF) Count-total → 2 * 5 = 10 378

So sum of all fi ( i ← 1 to 14) = 4 + 1 + 0 + 3 + 5 + 4 + 4 + 3 + 3 + 2 + 2 + 4 + 5 = 43 FP = Count-total * [0.65 + 0.01 *∑(fi)] = 378 * [0.65 + 0.01 * 43] = 378 * [0.65 + 0.43] = 378 * 1.08 = 408 Total pages of documentation = technical document + user document = 265 + 122 = 387pages Documentation = Pages of documentation/FP = 387/408 = 0.94

Differentiate between FP and LOC FP LOC 1. FP is specification based. 1. LOC is an analogy based. 2. FP is language independent. 2. LOC is language dependent. 3. FP is user-oriented. 3. LOC is design-oriented. 4. It is extendible to LOC. 4. It is convertible to FP (backfiring)

3. COCOMO MODEL Boehm proposed COCOMO (Constructive Cost Estimation Model) in 1981.COCOMO is one of the most generally used software estimation models in the world. COCOMO predicts the efforts and schedule of a software product based on the size of the software. The necessary steps in this model are: Get an initial estimate of the development effort from evaluation of thousands of delivered lines of source code (KDLOC). Determine a set of 15 multiplying factors from various attributes of the project. Calculate the effort estimate by multiplying the initial estimate with all the multiplying factors i.e., multiply the values in step1 and step2. The initial estimate (also called nominal estimate) is determined by an equation of the form used in the static single variable models, using KDLOC as the measure of the size. To determine the initial effort E i in person-months the equation used is of the type is shown below E i =a*(KDLOC)b The value of the constant a and b are depends on the project type.

In COCOMO, projects are categorized into three types: Organic Semidetached Embedded 1.Organic: A development project can be treated of the organic type, if the project deals with developing a well-understood application program, the size of the development team is reasonably small, and the team members are experienced in developing similar methods of projects. Examples of this type of projects are simple business systems, simple inventory management systems, and data processing systems. 2. Semidetached: A development project can be treated with semidetached type if the development consists of a mixture of experienced and inexperienced staff. Team members may have finite experience in related systems but may be unfamiliar with some aspects of the order being developed. Example of Semidetached system includes developing a new operating system (OS), a Database Management System (DBMS), and complex inventory management system. 3. Embedded: A development project is treated to be of an embedded type, if the software being developed is strongly coupled to complex hardware, or if the stringent regulations on the operational method exist. For Example: ATM, Air Traffic control.

For three product categories, Bohem provides a different set of expression to predict effort (in a unit of person month)and development time from the size of estimation in KLOC(Kilo Line of code) efforts estimation takes into account the productivity loss due to holidays, weekly off, coffee breaks, etc. According to Boehm, software cost estimation should be done through three stages: Basic Model Intermediate Model Detailed Model

1. Basic COCOMO Model: The basic COCOMO model provide an accurate size of the project parameters. The following expressions give the basic COCOMO estimation model: Effort=a 1 *(KLOC) a 2 PM Tdev =b 1 *(efforts)b 2 Months Where KLOC is the estimated size of the software product indicate in Kilo Lines of Code, a 1 ,a 2 ,b 1 ,b 2 are constants for each group of software products, Tdev is the estimated time to develop the software, expressed in months, Effort is the total effort required to develop the software product, expressed in person months (PMs) . Estimation of development effort For the three classes of software products, the formulas for estimating the effort based on the code size are shown below: Organic: Effort = 2.4(KLOC) 1.05 PM Semi-detached: Effort = 3.0(KLOC) 1.12 PM Embedded: Effort = 3.6(KLOC) 1.20 PM

Estimation of development time For the three classes of software products, the formulas for estimating the development time based on the effort are given below: Organic: Tdev = 2.5(Effort) 0.38 Months Semi-detached: Tdev = 2.5(Effort) 0.35 Months Embedded: Tdev = 2.5(Effort) 0.32 Months Some insight into the basic COCOMO model can be obtained by plotting the estimated characteristics for different software sizes. Fig shows a plot of estimated effort versus product size. From fig, we can observe that the effort is somewhat superliner in the size of the software product. Thus, the effort required to develop a product increases very rapidly with project size.

The development time versus the product size in KLOC is plotted in fig . From fig it can be observed that the development time is a sub linear function of the size of the product, i.e . when the size of the product increases by two times, the time to develop the product does not double but rises moderately. This can be explained by the fact that for larger products, a larger number of activities which can be carried out concurrently can be identified. The parallel activities can be carried out simultaneously by the engineers. This reduces the time to complete the project. Further, from fig, it can be observed that the development time is roughly the same for all three categories of products. For example, a 60 KLOC program can be developed in approximately 18 months, regardless of whether it is of organic, semidetached, or embedded type.

From the effort estimation, the project cost can be obtained by multiplying the required effort by the manpower cost per month. But, implicit in this project cost computation is the assumption that the entire project cost is incurred on account of the manpower cost alone. In addition to manpower cost, a project would incur costs due to hardware and software required for the project and the company overheads for administration, office space, etc. It is important to note that the effort and the duration estimations obtained using the COCOMO model are called a nominal effort estimate and nominal duration estimate. The term nominal implies that if anyone tries to complete the project in a time shorter than the estimated duration, then the cost will increase drastically. But, if anyone completes the project over a longer period of time than the estimated, then there is almost no decrease in the estimated cost value.

Example1: Suppose a project was estimated to be 400 KLOC. Calculate the effort and development time for each of the three model i.e., organic, semi-detached & embedded. Solution: The basic COCOMO equation takes the form: Effort=a 1 *(KLOC) a 2 PM Tdev =b 1 *(efforts)b 2 Months Estimated Size of project= 400 KLOC ( i )Organic Mode E = 2.4 * (400)1.05 = 1295.31 PM D = 2.5 * (1295.31)0.38=38.07 PM (ii)Semidetached Mode E = 3.0 * (400)1.12=2462.79 PM D = 2.5 * (2462.79)0.35=38.45 PM (iii) Embedded Mode E = 3.6 * (400)1.20 = 4772.81 PM D = 2.5 * (4772.8)0.32 = 38 PM

Example2: A project size of 200 KLOC is to be developed. Software development team has average experience on similar type of projects. The project schedule is not very tight. Calculate the Effort, development time, average staff size, and productivity of the project. Solution: The semidetached mode is the most appropriate mode, keeping in view the size, schedule and experience of development time. Hence E=3.0(200)1.12=1133.12PM D=2.5(1133.12)0.35=29.3PM COCOMO Model P = 176 LOC/PM

2. Intermediate Model : The basic Cocomo model considers that the effort is only a function of the number of lines of code and some constants calculated according to the various software systems . The intermediate COCOMO mod el recognizes these facts and refines the initial estimates obtained through the basic COCOMO model by using a set of 15 cost drivers based on various attributes of software engineering . It is an extension of basic cocomo It contains a set of 15 cost drivers/predictors/multipliers Boehm requires the project manager to rate these 15 different parameters for a particular project on a scale of one to three. Then , depending on these ratings, he suggests appropriate cost driver values which should be multiplied with the initial estimate obtained using the basic COCOMO.

Classification of Cost Drivers and their attributes : In general, the cost drivers can be classified as being attributes of the following items: Product attributes – The characteristics of the product that are considered include the inherent complexity of the product, reliability requirements of the product, etc. Required software reliability extent (RELY) Size of the application database The complexity of the product (CPLX) (ii) Hardware/computer attributes – Characteristics of the computer that are considered include the execution speed required, storage space required etc. Run-time performance constraints Memory constraints The volatility of the virtual machine environment Required turn around time (TURN)

(iii)Personnel attributes – The attributes of development personnel that are considered include the experience level of personnel, programming capability, analysis capability, etc. Analyst capability Software engineering capability Applications experience Virtual machine experience Programming language experience (iv)Project/development environment attributes – Development environment attributes capture the development facilities available to the developers. An important parameter that is considered is the sophistication of the automation (CASE) tools used for software development. Use of software tools Application of software engineering methods Required development schedule

The cost drivers are divided into four categories:

Intermediate COCOMO equation: E=a i (KLOC) b i *EAF D=c i (E)d i Coefficients for intermediate COCOMO Project a i b i c i d i Organic 2.4 1.05 2.5 0.38 Semidetached 3.0 1.12 2.5 0.35 Embedded 3.6 1.20 2.5 0.32

3. Detailed COCOMO Model : In detailed cocomo , the whole software is differentiated into multiple modules, and then we apply COCOMO in various modules to estimate effort and then sum the effort . The complete COCOMO model considers differences in characteristics of the subsystems and estimates the effort and development time as the sum of the estimates for the individual subsystems. The cost of each subsystem is estimated separately. This approach reduces the margin of error in the final estimate.

EXAMPLE The following development project can be considered as an example application of the complete COCOMO model. A distributed Management Information System (MIS) product for an organization having offices at several places across the country can have the following sub-components: • Database part • Graphical User Interface (GUI) part • Communication part Of these, the communication part can be considered as embedded software. The database part could be semi-detached software, and the GUI part organic software. The costs for these three components can be estimated separately, and summed up to give the overall cost of the system.

The Six phases of detailed COCOMO are: Planning and requirements System structure Complete structure Module code and test Integration and test Cost Constructive model The effort is determined as a function of program estimate, and a set of cost drivers are given according to every phase of the software lifecycle.

COCOMO-II It is the revised version of the original Cocomo (Constructive Cost Model) and is developed at University of Southern California . It is the model that allows one to estimate the cost, effort and schedule when planning a new software development activity. It consists of three sub-models:

1. End User Programming: Application generators are used in this sub-model. End user write the code by using these application generators. Example – Spreadsheets, report generator, etc. 2. Intermediate Sector:

(a). Application Generators and Composition Aids – This category will create largely pre packaged capabilities for user programming. Their product will have many reusable components . Typical firms operating in this sector are Microsoft, Lotus,Oracle , IBM, Borland, Novell. (b). Application Composition Sector – This category is too diversified and to be handled by pre packaged solutions. It includes GUI, Databases, domain specific components such as financial, medical or industrial process control packages. (c). System Integration – This category deals with large scale and highly embedded systems.

3. Infrastructure Sector: This category provides infrastructure for the software development like Operating System, Database Management System, User Interface Management System, Networking System, etc. Stages of COCOMO II:

Stage-I: It supports estimation of prototyping . For this it uses Application Composition Estimation Model . This model is used for the prototyping stage of application generator and system integration. Stage-II: It supports estimation in the early design stage of the project, when we less know about it. For this it uses Early Design Estimation Model . This model is used in early design stage of application generators, infrastructure, system integration. Stage-III: It supports estimation in the post architecture stage of a project. For this it uses Post Architecture Estimation Model . This model is used after the completion of the detailed architecture of application generator, infrastructure, system integration.

Difference between COCOMO 1 and COCOMO 2 COCOMO 1 Model: The Constructive Cost Model was first developed by Barry W. Boehm. The model is for estimating effort, cost, and schedule for software projects. It is also called as Basic COCOMO. This model is used to give an approximate estimate of the various parameters of the project. Example of projects based on this model is business system, payroll management system and inventory management systems. COCOMO 2 Model: The COCOMO-II is the revised version of the original Cocomo (Constructive Cost Model) and is developed at the University of Southern California. This model calculates the development time and effort taken as the total of the estimates of all the individual subsystems. In this model, whole software is divided into different modules. Example of projects based on this model is Spreadsheets and report generator.

COCOMO I COCOMO II COCOMO I is useful in the waterfall models of the software development cycle. COCOMO II is useful in non-sequential, rapid development and reuse models of software. It provides estimates pf effort and schedule. It provides estimates that represent one standard deviation around the most likely estimate. This model is based upon the linear reuse formula. This model is based upon the non linear reuse formula This model is also based upon the assumption of reasonably stable requirements. This model is also based upon reuse model which looks at effort needed to understand and estimate. Effort equation’s exponent is determined by 3 development modes. Effort equation’s exponent is determined by 5 scale factors. Development begins with the requirements assigned to the software. It follows a spiral type of development. Number of submodels in COCOMO I is 3 and 15 cost drivers are assigned In COCOMO II, Number of submodel are 4 and 17 cost drivers are assigned Size of software stated in terms of Lines of code Size of software stated in terms of Object points, function points and lines of code

RISK MANAGEMENT

What is Risk? Risk Management is the system of identifying addressing and eliminating problems before they can damage the project . We need to differentiate risks, as potential issues, from the current problems of the project.

Risk Management A software project can be concerned with a large variety of risks. In order to be adept to systematically identify the significant risks which might affect a software project, it is essential to classify risks into different classes. The project manager can then check which risks from each class are relevant to the project. There are three main classifications of risks which can affect a software project: Project risks Technical risks Business risks 1. Project risks: Project risks concern differ forms of budgetary, schedule, personnel, resource, and customer-related problems. A vital project risk is schedule slippage. Since the software is intangible, it is very tough to monitor and control a software project. It is very tough to control something which cannot be identified. 2 . Technical risks: Technical risks concern potential method, implementation, interfacing, testing, and maintenance issue. It also consists of an ambiguous specification, incomplete specification, changing specification, technical uncertainty, and technical obsolescence . Most technical risks appear due to the development team's insufficient knowledge about the project. 3. Business risks: This type of risks contain risks of building an excellent product that no one need, losing budgetary or personnel commitments, etc .

Other risk categories 1. Known risks: Those risks that can be uncovered after careful assessment of the project program, the business and technical environment in which the plan is being developed, and more reliable data sources (e.g., unrealistic delivery date) 2. Predictable risks: Those risks that are hypothesized from previous project experience (e.g., past turnover) 3. Unpredictable risks: Those risks that can and do occur, but are extremely tough to identify in advance.

Principle of Risk Management Global Perspective: In this, we review the bigger system description, design, and implementation. We look at the chance and the impact the risk is going to have. Take a forward-looking view: Consider the threat which may appear in the future and create future plans for directing the next events. Open Communication: This is to allow the free flow of communications between the client and the team members so that they have certainty about the risks. Integrated management: In this method risk management is made an integral part of project management. Continuous process: In this phase, the risks are tracked continuously throughout the risk management paradigm.

Risk Management Activities

Risk Assessment The objective of risk assessment is to division the risks in the condition of their loss, causing potential. For risk assessment, first, every risk should be rated in two methods: The possibility of a risk coming true (denoted as r). The consequence of the issues relates to that risk (denoted as s). Based on these two methods, the priority of each risk can be estimated : p = r * s Where p is the priority with which the risk must be controlled, r is the probability of the risk becoming true, and s is the severity of loss caused due to the risk becoming true. If all identified risks are set up, then the most likely and damaging risks can be controlled first, and more comprehensive risk abatement methods can be designed for these risks.

Risk Identification: The project organizer needs to anticipate the risk in the project as early as possible so that the impact of risk can be reduced by making effective risk management planning. A project can be of use by a large variety of risk. To identify the significant risk, this might affect a project. It is necessary to categories into the different risk of classes. There are different types of risks which can affect a software project: Technology risks: Risks that assume from the software or hardware technologies that are used to develop the system. People risks: Risks that are connected with the person in the development team. Organizational risks: Risks that assume from the organizational environment where the software is being developed. Tools risks: Risks that assume from the software tools and other support software used to create the system. Requirement risks: Risks that assume from the changes to the customer requirement and the process of managing the requirements change. Estimation risks: Risks that assume from the management estimates of the resources required to build the system

2. Risk Analysis: During the risk analysis process, you have to consider every identified risk and make a perception of the probability and seriousness of that risk. There is no simple way to do this. You have to rely on your perception and experience of previous projects and the problems that arise in them. It is not possible to make an exact, the numerical estimate of the probability and seriousness of each risk. Instead, you should authorize the risk to one of several bands: The probability of the risk might be determined as very low (0-10%), low (10-25%), moderate (25-50%), high (50-75%) or very high (+75%). The effect of the risk might be determined as catastrophic (threaten the survival of the plan), serious (would cause significant delays), tolerable (delays are within allowed contingency), or insignificant.

Risk Control It is the process of managing risks to achieve desired outcomes. After all, the identified risks of a plan are determined; the project must be made to include the most harmful and the most likely risks. Different risks need different containment methods. In fact, most risks need ingenuity on the part of the project manager in tackling the risk. There are three main methods to plan for risk management: Avoid the risk: This may take several ways such as discussing with the client to change the requirements to decrease the scope of the work, giving incentives to the engineers to avoid the risk of human resources turnover, etc. Transfer the risk: This method involves getting the risky element developed by a third party, buying insurance cover, etc. Risk reduction: This means planning method to include the loss due to risk. For instance, if there is a risk that some key personnel might leave, new recruitment can be planned.

Risk Leverage: To choose between the various methods of handling risk, the project plan must consider the amount of controlling the risk and the corresponding reduction of risk. For this, the risk leverage of the various risks can be estimated. Risk leverage is the variation in risk exposure divided by the amount of reducing the risk. Risk leverage = (risk exposure before reduction - risk exposure after reduction) / (cost of reduction)

Risk planning : The risk planning method considers each of the key risks that have been identified and develop ways to maintain these risks. For each of the risks, you have to think of the behavior that you may take to minimize the disruption to the plan if the issue identified in the risk occurs. You also should think about data that you might need to collect while monitoring the plan so that issues can be anticipated. Again, there is no easy process that can be followed for contingency planning. It rely on the judgment and experience of the project manager. 2. Risk Monitoring: Risk monitoring is the method king that your assumption about the product, process, and business risks has not changed.

PROJECT SCHEDULING

Project Scheduling Project-task scheduling is a significant project planning activity. It comprises deciding which functions would be taken up when. To schedule the project plan, a software project manager wants to do the following: Identify all the functions required to complete the project. Break down large functions into small activities. Determine the dependency among various activities. Establish the most likely size for the time duration required to complete the activities. Allocate resources to activities. Plan the beginning and ending dates for different activities. Determine the critical path. A critical way is the group of activities that decide the duration of the project.

The work breakdown structure formalism helps the manager to breakdown the tasks systematically after the project manager has broken down the tasks The dependency among the activities is represented in the form of an activity network. Resource allocation is typically done using a Gantt chart . The PERT chart representation is suitable for program monitoring and control. The end of each activity is called milestone The scheduling can be represented using Work Breakdown Structure (WBS) Activity networks critical path method ( CPM) Gantt chart PERT chart

1. Work Breakdown Structure Work Breakdown Structure (WBS) is used to decompose a given task set recursively into small activities. The root of the tree is labelled by the problem name . Each node of the tree is broken down into smaller activities that are made the children of the node. Each activity is recursively decomposed into smaller sub-activities until at the leaf level, the activities requires approximately two weeks to develop.

Activity networks Each activity is represented by a rectangular node Managers can estimate the time durations for the different tasks in several ways. One possibility is that they can empirically assign durations to different tasks. This however is not a good idea, because software engineers often resent such unilateral decisions . A possible alternative is to let engineer himself estimate the time for an activity he can assigned to. However, some managers prefer to estimate the time for various activities themselves. A good way to achieve accurately in estimation of the task durations without creating undue schedule pressures is to have people set their own schedules.

Critical Path Method (CPM) From the activity network representation following analysis can be made. This tools is useful in recognizing interdependent tasks in the project . It also helps to find out the shortest path or critical path to complete the project successfully . Like PERT diagram, each event is allotted a specific time frame . This tool shows dependency of event assuming an event can proceed to next only if the previous one is completed. The events are arranged according to their earliest possible start time. Path between start and end node is critical path which cannot be further reduced and all events require to be executed in same order.

ACTIVITY DURATION DEPENDENCIES T1 8 - T2 15 - T3 15 T1(M1) T4 10 - T5 10 T2,T4(M2)

Gantt Chart Gantt charts was devised by Henry Gantt (1917 ). It represents project schedule with respect to time periods . It is a horizontal bar chart with bars representing activities and time scheduled for the project activities.

PERT Chart PERT (Program Evaluation & Review Technique) chart is a tool that depicts project as network diagram. It is capable of graphically representing main events of project in both parallel and consecutive way. Events , which occur one after another, show dependency of the later event over the previous one . Events are shown as numbered nodes. They are connected by labeled arrows depicting sequence of tasks in the project.

PERT (Project Evaluation and Review Technique) charts consist of a network of boxes and arrows . The boxes represent activities and the arrows represent task dependencies. A critical path in a PERT chart is shown by using thicker arrows . PERT charts are a more sophisticated form of activity chart . In a ctivity diagrams only the estimated task durations are represented . Gantt chart representation of a project schedule is helpful in planning the utilization of resources PERT char t is useful for monitoring the timely progress of activities. Also, it is easier to identify parallel activities in a project using a PERT chart. Project managers need to identify the parallel activities in a project for assignment to different engineers.

About This Presentation

Slide Content

Tags

Categories

Download

Quick Actions

Statistics

Related Slideshows

Unit 1 OOSE

About This Presentation

Slide Content

Slide 1

Slide 2

Slide 3

Slide 4

Slide 5

Slide 6

Slide 7

Slide 8

Slide 9

Slide 10

Slide 11

Slide 12

Slide 13

Slide 14

Slide 15

Slide 16

Slide 17

Slide 18

Slide 19

Slide 20

Slide 21

Slide 22

Slide 23

Slide 24

Slide 25

Slide 26

Slide 27

Slide 28

Slide 29

Slide 30

Slide 31

Slide 32

Slide 33

Slide 34

Slide 35

Slide 36

Slide 37

Slide 38

Slide 39

Slide 40

Slide 41

Slide 42

Slide 43

Slide 44

Slide 45

Slide 46

Slide 47

Slide 48

Slide 49

Slide 50

Slide 51

Slide 52

Slide 53

Slide 54

Slide 55

Slide 56

Slide 57

Slide 58

Slide 59

Slide 60

Slide 61

Slide 62

Slide 63

Slide 64

Slide 65

Slide 66

Slide 67

Slide 68

Slide 69

Slide 70

Slide 71

Slide 72

Slide 73

Slide 74

Slide 75

Slide 76

Slide 77