Introduction to Software Engineering

Transcription

1 Chapter 1 Introduction to Software Engineering

2 Content 1. Introduction 2. Components 3. Layered Technologies 4. Generic View of Software Engineering 4. Generic View of Software Engineering 5. Study of Different Models 6. Process Technology

3 1. Introduction What is Software? Software is nothing but a collection of computer programs and related documents that are intended to provide desired features, functionalities and better performance. Software products may be: 1.Generic-That means developed to be sold to range of different customers. 2.Custom-That means developed for a single customer according to their specifications.

4 Evolution of Software Engineering Early Computer Programming High level language Programming Control flow-based design Data structure-oriented design Data flow-oriented design Object-oriented design Web-based design

5 2. Components Any software consist of three major components Programs, Documents, Operating Procedure. Programis one part of entire software. Documentationconsists of various Manuals.(SRS and Different diagrams) Procedurerepresent instructions for initial setup.(user guide, Installation guide)

6 3. Layered Technologies Softwareengineering is discipline in which theories, methods and tools are applied to develop professional software product. SoftwareEngineering Layers

7 Layered Technologies (Continued..) A qualitymanagement is a backbone of software engineering technology. Processdefines the framework for timely delivery of software Here Actual Methodof implementation is carried out with the help of analysis, design, coding and testing. Toolsare used to bring automation in software development process.

8 Software Characteristics Software is engineered, not manufactured. -In software development process, problems can be rectified. Software does not ware out. -Software cant be replaced by another components like Hardware. Most software is custom built rather than being assembled from components. -In Hardware components such as ICs, capacitors and registers are assembled according to design but this is not done while building software.

9 4. Generic View of Software Engineering Common Process Framework: It is characterized by Process Framework Activities, Task sets and Umbrella Activities. Process Framework Activities: 1.Communication 4. Constructions 2.Planing 5. Deployment (feedback of customer) 3.Modeling Task Set: The task set defines the actual work done in order to achieve the software objective. It is divided to : 1.Collection of software engineering work task 2. Project milestones 3. Software quality assurance points

10 Common Process Framework (Continued) Umbrella Activities : 1.Software project tracking and control (Progress and schedule) 2.Risk Management (may affect project outcomes) 3. SQA (to maintain quality) 4. Formal technical review (remove errors) 5. Software configuration management 6. Work product preparation and production (to create models, log, documentation) 7. Reusability management 8. Measurement.

11 5. Study of Different Models Software Development Life Cycle (SDLC): A framework that describes the activities performed at each stage of a software development project.

12 Phases of SDLC 1. Software Requirement Analysis 2. System Analysis and Design 3. Code Generation 4. Code Testing 5. Implementation 6. Maintenance

13 Phases of SDLC (1) Software Requirement Analysis: This process is also known as feasibility study. In this phase, the development team visits the customer and studies their system. They investigate the need for possible software automation in the given system. By the end of the feasibility study, the team furnishes a document that holds the different specific recommendations for the candidate system. It also includes the personnel assignments, costs, project schedule, target dates etc... The requirement gathering process is intensified and focused specially on software. To understand the nature of the program(s) to be built, the system engineer or "Analyst" must understand the information domain for the software, as well as required function, behavior, performance and interfacing. The essential purpose of this phase is to find the need and to define the problem that needs to be solved

14 Phases of SDLC (2) System Analysis and Design: 1. High Level Design (HLD) List of modules and a brief description of each module. Brief functionality of each module. Interface relationship among modules. Dependencies between modules (if A exists, B exists etc). Database tables identified along with key elements. Overall architecture diagrams along with technology details. 2. Low Level Design (LLD) Detailed functional logic of the module, in pseudo code. Database tables, with all elements, including their type and size. All interface details. All dependency issues Complete input and outputs for a module. A software development model is thus created. Analysis and Design are very crucial in the whole development cycle. Any glitch in the design phase could be very expensive to solve in the later stage of the software development. The logical system of the product is developed in this phase.

15 Phases of SDLC (3) Code Generation: The design must be translated into a machine-readable form. The code generation step performs this task. If the design is performed in a detailed manner, code generation can be accomplished without much complication. Programming tools like compilers, interpreters, debuggers etc... are used to generate the code. Different high level programming languages like C, C++, Pascal, Java are used for coding. With respect to the type of application, the right programming language is chosen.

16 Phases of SDLC (4) Testing: Once the code is generated, the software program testing begins. Different testing methodologies are available to detect the bugs that were committed during the previous phases. Different testing tools and methodologies are available. Some companies build their own testing tools that are tailor made for their own development operations.

17 Phases of SDLC (5) Installation : Installation of the product in its operational environment.

18 Phases of SDLC (6) Maintenance: After the software is released and the client starts using the software, maintenance phase is started. 3 things happen - Bug fixing, Upgrade, Enhancement Bug fixing bugs arrived due to some untested scenarios. Upgrade Upgrading the application to the newer versions of the software. Enhancement - Adding some new features into the existing software.

19 Types of Process flows Linear Process flow Iterative Process flow Evolutionary Process flow Parallel Process flow

20

21 SOFTWARE LIFE CYCLE MODELS Waterfall Model / Linear Sequential Model Prototype Model Rapid Application Development (Rad) Model Evolutionary Process Models: Incremental Model Spiral Model Concurrent Development Model

22 Waterfall Model

23 Waterfall Model The project is divided in to separate distinct phases Each next phase starts after finishing the previous phase. Each phase communicate to next through pre specified output When an error is detected or revision is required it is traced back to one previous phase at a time, until it gets resolved at some earlier phase

24 Waterfall Strengths Easy to understand, easy to use Provides structure to inexperienced staff Milestones are well understood Sets requirements stability Good for management control (plan, staff, track) Works well when quality is more important than cost or schedule

25 Waterfall deficiencies All requirements must be known upfront Deliverables created for each phase are considered frozen(unmoving) reduce flexibility Can give a false impression of progress Does not reflect problem-solving nature of software development iterations of phases Integration is one big bang at the end Little opportunity for customer to preview the system (until it may be too late)

26 When to use the Waterfall Model Requirements are very well known Product definition is stable i.e. Deliverables of each Phase can be frozen. Technology is understood New version of an existing product Porting an existing product to a new platform.

27 Prototyping Model Co m m un icat ion communication Quick plan Q u ick p lan Modeling Quick design Mo d e lin g Q u ick d e sig n Deploym ent Deployment D e live r y delivery & Fe e db& ack feedback Con st r u ct io n Construction o f pof r prototype o t e

28 Prototyping Model This model uses constant user interaction, early in the requirements gathering stage to produce a prototype. Developers build a prototype during the requirements phase Prototype is evaluated by end users Users give corrective feedback Developers further refine the prototype Whentheuserissatisfied,theprototypecode is brought up to the standards needed for a final product.

29 Prototyping Steps A preliminary project plan is developed An partial high-level paper model is created The model is source for a partial requirements specification A prototype is built with basic and critical attributes to show how the eventual software system look like, how input screens and output reports would look like. The designer builds the database user interface algorithmic functions Continue.

30 Prototyping Steps (continued) The designer demonstrates the prototype, the user reviews and evaluates for problems, more features and suggests improvements. Based on feedback the prototype is improved and sent for review. This loop continues until the user is satisfied Finally software product is created based on the prototype.

31 Prototyping Strengths Customers can see the system requirements as they are being gathered Developers learn from customers Amoreaccurateendproduct Unexpected requirements accommodated Allows for flexible design and development Steady, visible signs of progress produced Interaction with the prototype stimulates awareness of additional needed functionality

32 Prototyping Weaknesses The customer may want the prototype delivered. Insufficient analysis User confusion of prototype and finished system Developer misunderstanding of user objectives Excessive development time of the prototype Expense of implementing prototyping

33 When to use Prototyping Requirements are unstable or have to be clarified Where we have a user who can give feedback. Can be used as the requirements clarification stage of a waterfall model Develop user interfaces New, original development

34 Evolutionary Process models Incremental model Spiral model Concurrent Development model

35 Incremental SDLC Model Combines elements of Linear and Parallel process flows Construct a partial implementation of a total system Then slowly add increased functionality The incremental model prioritizes requirements of the system and then implements them in groups. Each subsequent release of the system adds function to the previous release, until all designed functionality has been implemented.

36 Incremental SDLC Model increment # n C o m m u n i c a t i o n P l a n n i n g M o d e l i n g analysis design C o n s t r u c t i o n code t est D e p l o y m e n t d e l i v e r y f e e d b a c k increment # 2 delivery of nt h increment C o m m u n i c a t i o n P l a n n i n g increment # 1 M o d e l i n g analysis design C o n s t r u c t i o n code t est D e p l o y m e n t d e l i v e r y f e e d b a c k delivery of 2nd increment C o m m u n i c a t i o n P l a n n i n g M o d e l i n g analysis design C o n s t r u c t i o n code t est D e p l o y m e n t d e l i v e r y f e e d b a c k delivery of 1st increment project calendar time

37 Incremental Model Strengths Develop high-risk or major functions first Each release delivers an operational product Customercanrespondtoeachbuild Uses divide and conquer breakdown of tasks Initial product delivery is faster Customers get important functionality early Risk of changing requirements is reduced

38 Incremental Model Weaknesses Requires good planning and design Requires early definition of a complete and fully functional system to allow for the definition of increments Well-defined module interfaces are required (some will be developed long before others) Total cost of the complete system is not lower

39 When to use the Incremental Model Funding, schedule, program complexity, or need for early realization of benefits. Mostoftherequirementsareknownupfront but are expected to evolve over time A need to get basic functionality to the market early On projects which have lengthy development schedules Onaprojectwithnewtechnology

40 Spiral Model It is an evolutionary software process model that couples the iterative nature of prototyping and the controlled and systematic aspects of the linear sequential model It provides the potential for rapid development of incremental versions of the software. Software is developed in a series of incremental releases. During early iterations, the incremental release might be a paper model or prototype. During later iterations, increasingly more complete versions of the engineered system are produced.

41 Spiral Model

42 Spiral Model Task Regions 1. Customer communication tasks required to establish effective communication between developer and customer. 2. Planning tasks required to define resources, timelines, and other project related information. 3. Risk analysis tasks required to assess both technical and management risks. 4. Engineering tasks required to build one or more representations of the application. Continue

43 Spiral Model Task Regions (continued..) 5. Construction and release tasks required to construct, test, install, and provide user support (e.g., documentation and training). 6. Customer evaluation tasks required to obtain customer feedback based on evaluation of the software representations created during the engineering stage and implemented during the installation stage.

44 Alternative view of Spiral model Examine the project entry point axis Concept development project starts at the core of the spiral New development project If the concept is to be developed into an actual product Product enhancement project when process is inactive, but starts when change is initiated Product maintenance project using customer feedback

45 Alternative view of Spiral model

46 Spiral Model Strengths Provides early indication of risks, without much cost Users see the system early because of rapid prototyping tools Critical high-risk functions are developed first The design does not have to be perfect Users can be closely tied to all lifecycle steps Early and frequent feedback from users Cumulative costs assessed frequently

47 Spiral Model Weaknesses Time spent for evaluating risks too large for small or low-risk projects Time spent planning, resetting objectives, doing risk analysis and prototyping may be excessive The model is complex Risk assessment expertise is required Spiral may continue indefinitely Developers must be reassigned during nondevelopment phase activities May be hard to define objective, verifiable milestones that indicate readiness to proceed through the next iteration

48 When to use Spiral Model When creation of a prototype is appropriate When costs and risk evaluation is important For medium to high-risk projects Long-term project commitment unwise because of potential changes to economic priorities Users are unsure of their needs Requirements are complex New product line Significant changes are expected (research and exploration)

49 Concurrent Development model Also called concurrent engineering Constitutes a series of framework activities, software engineering action, tasks and their associated states All activities exist concurrently but reside in different states It defines a network of activities. Each activity on the network exists simultaneously with other activities Event generated at one point in the process trigger transitions among the states

50 Concurrent Development model n o n e M o d e lin g a c t iv it y U n d e r d e v e lo p m e n t r e p r e s e n t s t h e s t at e o f a s o f t w a r e e ng i n ee r in g a c t iv i t y o r t as k A w a it in g c h a n g e s U n d e r r e v ie w U n d e r r e v is io n B a s e lin e d D o n e

51 Concurrent Development model Usage Often used as the paradigm for the development of client/server applications A client/server system is composed of a set of functional components. When applied to client/server, the concurrent process model defines activities in two dimensions A System dimension -issues are addressed using three activities: design, assembly, and use A Component dimension -addressed with two activities: design and realization Applicable to all types of software development

52 Rapid Application Development Model (RAD) An incremental software process model Having a short development cycle High-speed adoption of the waterfall model using a component based construction approach Creates a fully functional system within a very short span time of 60 to 90 days Multiple software teams work in parallel on different functions Modeling encompasses three major phases: Business modeling, Data modeling and process modeling Construction uses reusable components, automatic code generation and testing

53 Rapid Application Development (RAD) Model Team # n Mo d e lin g business modeling data modeling process modeling Communicat ion Team # 2 Modeling business modeling dat a modeling process modeling Co n st ru ct io n component reuse automatic code generation testing Planning Team # 1 Modeling business modeling dat a modeling process modeling Const ruct ion component reuse aut omat ic code generat ion t est ing Deployment int egrat ion delivery feedback Const ruct ion component reuse aut omat ic code generat ion t est ing days

54 RAD Strengths Reduced cycle time and improved productivity with fewer people means lower costs Time-box approach reduce cost and schedule risk Customer involved throughout the complete cycle minimizes risk of not achieving customer satisfaction and business needs Focus moves from documentation to code Uses modeling concepts to capture information about business, data, and processes.

55 RAD Weaknesses Requires a number of RAD teams Requires commitment from both developer and customer for rapid-fire completion of activities Not suited when technical risks are high Accelerated development process must give quick responses to the user Hard to use with inherited systems Requires a system that can be modularized

56 When to use RAD Reasonably well-known requirements When we have CASE and other modeling tools User involved throughout the life cycle Project can be time-boxed Functionality delivered in increments High performance not required Low technical risks System can be modularized

57 Component Based Development Object-oriented technologies provide the technical framework for this type of model Incorporates many of the characteristics of the spiral model It is evolutionary in nature demanding an iterative approach The engineering activity begins with the identification of candidate classes

58 Component Based Development

59 6. Process Technology The process models must be adapted for use by a software project team For that, process technology tools have been developed to help software organizations Process technology tools allow a software organization to build an automated model of the common process framework, task sets, and umbrella activities This model (or network), can be analyzed to determine typical work flow and examine alternative process structures for reducing development time or cost

60 Process Technology (Continued..) Other process technology tools can also be used to allocate, monitor and control the tasks defined as part of the process model The process technology tool can also be used to coordinate the use of other computer-aided software engineering (CASE) tools that are appropriate for a particular work task

61 Product and Process If the process is weak, the end product will undoubtedly suffer, but an obsessive overreliance on process is also dangerous People derive as much (or more) satisfaction from the creative process as they do from the end product