Software process
Upcoming SlideShare
Loading in...5
×
 

Software process

on

  • 1,582 views

Software process

Software process

Statistics

Views

Total Views
1,582
Views on SlideShare
1,582
Embed Views
0

Actions

Likes
2
Downloads
60
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Software process Software process Presentation Transcript

  • Software Processes Loganathan R Prof. Loganathan R., CSE, HKBKCE 1
  • Objectives• Understand the concept of software process models• Understand three generic process models and when they may be used• Understand the activities involved in requirements engineering, software development, testing and evolution• Understand the Rational Unified Process model• Introduce the CASE technology to support software process activities Prof. Loganathan R., CSE, HKBKCE 2
  • The Software Process• Common fundamental activities to all Software processes are: – Specification; – Design; – Validation; – Evolution.• A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective. Prof. Loganathan R., CSE, HKBKCE 3
  • Generic software process models• The waterfall model – Separate and distinct phases of specification and development.• Evolutionary(Iterative) development – Specification, development and validation are interleaved.• Component-Based Software Engineering – The system is assembled from existing components.• There are many variants of these models e.g. formal development where a waterfall-like process is used but the specification is a formal specification that is refined through several stages to an implementable design. Prof. Loganathan R., CSE, HKBKCE 4
  • Waterfall ModelRequirements Definition System and Software Design Implementation and Unit Testing Integration and System Testing Operation and Maintenance Prof. Loganathan R., CSE, HKBKCE 5
  • Waterfall Model phases• Requirements analysis and definition • Services, constraints & goals are established & Defined• System and software design • Establishes overall System architecture ,identifies & describes the software system abstractions & their relationships• Implementation and unit testing • Design is realised as program units. Unit testing involves verifying each unit meets its specification• Integration and system testing • Program unit are integrated and tested as a system to ensure it meets the requirement specification.• Operation and maintenance • System is installed & put in use. Maintenance involves correcting errors, improving implementation & enhancing with new requirements as discovered Prof. Loganathan R., CSE, HKBKCE 6
  • Waterfall model problems• 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.• Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements.• Therefore, 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. Prof. Loganathan R., CSE, HKBKCE 7
  • Evolutionary development Concurrent activities Specification Initial Version OutlineDescription Development Intermediate Versions Final Validation Version Prof. Loganathan R., CSE, HKBKCE 8
  • Evolutionary development• Develop an initial implementation and expos to user comment and then refine it through many versions.• Types: • Exploratory development – Objective is to work with customers and to evolve a final system from an initial outline specification. Should start with well-understood requirements and add new features as proposed by the customer. • Throw-away prototyping – Objective is to understand the system requirements. Should start with poorly understood requirements to clarify what is really needed. Prof. Loganathan R., CSE, HKBKCE 9
  • Evolutionary development• Problems – Lack of process visibility; – Systems are often poorly structured; – Special skills (e.g. in languages for rapid prototyping) may be required.• Applicability – For small or medium-size interactive systems; – For parts of large systems (e.g. the user interface); – For short-lifetime systems. Prof. Loganathan R., CSE, HKBKCE 10
  • Component-based software engineeringRequirements Component Requirements System DesignSpecifications Analysis Modifications with Reuse Development System and Integration Validation Prof. Loganathan R., CSE, HKBKCE 11
  • Component-based software engineering• Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the- shelf) systems.• Process stages – Component analysis :- Search for components for given specification – Requirements modification :- Analyse the requirements using the discovered component information and modify to reflect the available components – System design with reuse :- Framework of the system is designed or existing framework is reused – Development and integration :- non available components are developed and integrated with COTS system to create the required system• This approach is becoming increasingly used as component standards have emerged. Prof. Loganathan R., CSE, HKBKCE 12
  • Process Iteration• System requirements ALWAYS evolve in the course of a project so, process iteration where earlier stages are reworked is always part of the process for large systems.• Iteration can be applied to any of the generic process models.• Two (related) approaches – Incremental delivery; – Spiral development. Prof. Loganathan R., CSE, HKBKCE 13
  • Incremental delivery Define Outline Assign Requirements Design System Requirements to Increments ArchitectureDevelop system Validate Integrate Validate Increment Increment Increment System Final System System Incomplete Prof. Loganathan R., CSE, HKBKCE 14
  • Incremental delivery• Rather than deliver the system as a single delivery, the development (Specification, design & implementation) and delivery is broken down into increments with each increment delivering part of the required functionality.• User requirements are prioritised and the highest priority requirements are included in early increments.• Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve. Prof. Loganathan R., CSE, HKBKCE 15
  • Incremental delivery• Advantages – Customer value can be delivered with each increment so system functionality is available earlier. – Early increments act as a prototype to help elicit requirements for later increments. – Lower risk of overall project failure. – The highest priority system services tend to receive the most testing. Prof. Loganathan R., CSE, HKBKCE 16
  • Extreme programming• Variant of incremental delivery.• Based on the development based on the development and delivery of very small increments of functionality.• Relies on constant code improvement, user involvement in the development team and pair wise programming. Prof. Loganathan R., CSE, HKBKCE 17
  • Spiral development• Process is represented as a spiral rather than as a sequence of activities with backtracking.• Each loop in the spiral represents a phase in the process.• No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required.• Risks are explicitly assessed and resolved throughout the process. Prof. Loganathan R., CSE, HKBKCE 18
  • Spiral model of the software process Deter mine objecti ves, Evalua te alterna tives, alterna tives and identify , resolv e risks constr aints Risk analysis Risk anal ysis Risk Oper a- anal ysis Prototype 3 tional Prototype 2 pr otoype Risk REVIEW anal ysis Proto- type 1 Requir ements plan Simula tions , models , benchmarks Life-cycle plan Concept of Oper ation S/W requir ements Product design Detailed Requir ement design Development plan validation Code Unit test Integ ration Design V&V Integ ration and test plan Plan ne xt phase test Acceptance Service test Develop , verify next-le vel pr oduct Prof. Loganathan R., CSE, HKBKCE 19
  • Spiral model Sectors• Objective setting – Define the Specific objectives for that phase. Identify the constraints on the process/product and project risk. Plan for constraints & find alternate for risk or resolve.• Risk assessment and reduction – Risks are analysed & assessed and take steps to reduce the risks.• Development and validation – A development model for the system is chosen which can be any of the generic models. Example for UI risk use evolutionary prototyping, for safety risk use formal transformation, for sub- system risk Waterfall model• Planning – The project is reviewed and the next phase of the spiral is planned. Prof. Loganathan R., CSE, HKBKCE 20
  • Process activities• 1. Software specification• 2. Software design and implementation• 3. Software validation• 4. Software evolution Prof. Loganathan R., CSE, HKBKCE 21
  • 1. Software specification• Software Specification or requirements engineering is the process of understanding and defining what services are required and identifying the constraints on the system’s operation and development.• Requirements engineering process – Feasibility study:- Estimate whether the current h/w & s/w technology will satisfy user needs & cost-effective. Feasibility study should be cheap &quick. – Requirements elicitation and analysis :- Derive the requirements by observing existing system, discussing with users, task analysis & so on. Produce system models & prototypes – Requirements specification :- Translate the previous activity information into requirements document. Types of requirements: • User requirements :- for customer & end user • System requirements : - detailed description of the required functionality – Requirements validation :- Checks the requirements for realism consistency & completeness. Prof. Loganathan R., CSE, HKBKCE 22
  • The requirements engineering process RequirementsFeasibility Elicitation and Study Analysis Requirements SpecificationFeasibility Requirements Report Validation System Models User and System Requirements Requirements Document Prof. Loganathan R., CSE, HKBKCE 23
  • 2. Software Design and Implementation• The process of converting the system specification into an executable system.• Software design – is a description of software structure, data, interfaces and algorithms used in the system that realises the specification;• Implementation – Translate design structure into an executable program;• The activities of design and implementation are closely related and may be inter-leaved. Prof. Loganathan R., CSE, HKBKCE 24
  • The software design process Requirement Specification Design activitiesArchitectural Abstract Interface Component Data Algorithm Design Specificatio Design Design Structure Design n Design System Software Interface Component Data AlgorithmArchitecture Specification Specification Specification Structure Specification Specification Design products Prof. Loganathan R., CSE, HKBKCE 25
  • Software Design process activities• Architectural design Subsystem making up the system & their relationships are identified & documented• Abstract specification Abstract specification of subsystem services & its operating constraints are produced• Interface design Subsystem interfaces with other subsystem is designed unambiguously & documented• Component design Component services are allocated & its interfaces also designed• Data structure design The data structures used in the implementation is designed & specified• Algorithm design Algorithm to provide services are designed & specified Prof. Loganathan R., CSE, HKBKCE 26
  • Design methods• In Agile method, design process output is represented in the code of the program• The Structured methods produces graphical models and code generated automatically from that. Includes design process model, design notations, report formats & design guidelines.• Structured methods supports the following models: – Object model :Shows object classes & their dependencies – Sequence model :Shows how objects interact when system is executing – State transition model :Shows system states & triggers for transition from one state to another – Structural model :System Components & their aggregations are documented – Data-flow model :System is modelled using transformations that takes place as it is processed Prof. Loganathan R., CSE, HKBKCE 27
  • Programming and Debugging• Translating a design into a program and removing errors from that program.• Programming is a personal activity - there is no generic programming process.• Programmers carry out some program testing to discover faults in the program and remove these faults in the debugging process. Prof. Loganathan R., CSE, HKBKCE 28
  • The Debugging ProcessLocate Design Error Repair Retest Error Repair Error Program Prof. Loganathan R., CSE, HKBKCE 29
  • 3. Software validation• Verification and validation (V & V) is intended to show that a system conforms to its specification and meets the requirements of the system customer.• Involves checking and review processes and system testing.• System testing involves executing the system with test cases that are derived from the specification of the real data(customer data) to be processed by the system. Prof. Loganathan R., CSE, HKBKCE 30
  • The Testing ProcessComponent System Acceptance Testing Testing Testing Prof. Loganathan R., CSE, HKBKCE 31
  • Testing process stages• Component or unit testing – Individual components are tested independently for correct operation; – Components may be functions or objects or coherent groupings of these entities.• System testing – Testing of the system as a whole to validate functional & non-functional requirements. Testing of emergent properties is particularly important.• Acceptance testing – Testing with customer data to check that the system meets the customer’s needs & performance. Prof. Loganathan R., CSE, HKBKCE 32
  • Testing phases in a Software processRequirements System System DetailedSpecification Specification Design Design System Sub-system Acceptance Module / Unit Integration Integration Test Plan Code and Test Test Plan Test Plan Acceptance System Sub-system Service Test Integration Test Integration Test • Alpha testing : Acceptance testing • Beta testing : For marketed products, involves delivering system to potential customers who agree to use Prof. Loganathan R., CSE, HKBKCE 33
  • 4. Software evolution• Software is inherently flexible and can change.• As requirements change through changing business circumstances, the software that supports the business must also evolve and change.• Although there has been a demarcation between development and evolution (maintenance) this is increasingly irrelevant as fewer and fewer systems are completely new. Prof. Loganathan R., CSE, HKBKCE 34
  • System evolutionDefine system Assess existing Propose system Modifyrequirements systems changes systems Existing New systems system Prof. Loganathan R., CSE, HKBKCE 35
  • The Rational Unified Process• A modern process model derived from the work on the UML and associated Unified Software Development process.• It is a Hybrid process model : Combines the elements of generic process models, supports iteration & illustrates good practices in specification & design• Normally described from 3 perspectives – A dynamic perspective that shows phases over time; – A static perspective that shows process activities; – A practice perspective that suggests good practice. Prof. Loganathan R., CSE, HKBKCE 36
  • RUP phase model Phase iterationInception Elaboration Construction Transition Prof. Loganathan R., CSE, HKBKCE 37
  • RUP phases• Inception – Establish the business case for the system.• Elaboration – Develop an understanding of the problem domain and the system architecture.• Construction – System design, programming and testing.• Transition – Deploy the system in its operating environment. Prof. Loganathan R., CSE, HKBKCE 38
  • RUP good practice• Develop software iteratively• Manage requirements• Use component-based architectures• Visually model software• Verify software quality• Control changes to software Prof. Loganathan R., CSE, HKBKCE 39
  • Static workflowsWorkflow DescriptionBusiness modelling The business processes are modelled using business use cases. Actors who interact with the system are identified and use cases areRequirements developed to model the system requirements. A design model is created and documented using architectural models,Analysis and design component models, object models and sequence models. The components in the system are implemented and structured intoImplementation implementation sub-systems. Automatic code generation from design models helps accelerate this process. Testing is an iterative process that is carried out in conjunction withTest implementation. System testing follows the completion of the implementation. A product release is created, distributed to users and installed in theirDeployment workplace.Configuration and This supporting workflow managed changes to the systemChange managementProject management This supporting workflow manages the system development This workflow is concerned with making appropriate software toolsEnvironment available to the software development team. Prof. Loganathan R., CSE, HKBKCE 40
  • Computer-aided software engineering• Computer-aided software engineering (CASE) is software to support software development and evolution processes.• Activity automation – Graphical editors for system model development; – Data dictionary to manage design entities; – Graphical UI builder for user interface construction; – Debuggers to support program fault finding; – Automated translators to generate new versions of a program. Prof. Loganathan R., CSE, HKBKCE 41
  • Case technology• Case technology has led to significant improvements in the software process. However, these are not the order of magnitude improvements that were once predicted – Software engineering requires creative thought - this is not readily automated; – Software engineering is a team activity and, for large projects, much time is spent in team interactions. CASE technology does not really support these. Prof. Loganathan R., CSE, HKBKCE 42
  • CASE classification• Classification helps us understand the different types of CASE tools and their support for process activities.• Functional perspective – Tools are classified according to their specific function.• Process perspective – Tools are classified according to process activities that are supported.• Integration perspective – Tools are classified according to their organisation into integrated units. Prof. Loganathan R., CSE, HKBKCE 43
  • Functional tool classificationTool type ExamplesPlanning tools PERT tools, estimation tools, spreadsheetsEditing tools Text editors, diagram editors, word processorsChange management tools Requirements traceability tools, change control systemsConfiguration management tools Version management systems, system building toolsPrototyping tools Very high-level languages, user interface generatorsMethod-support tools Design editors, data dictionaries, code generatorsLanguage-processing tools Compilers, interpreters Cross reference generators, static analysers, dynamicProgram analysis tools analysersTesting tools Test data generators, file comparatorsDebugging tools Interactive debugging systemsDocumentation tools Page layout programs, image editorsRe-engineering tools Cross-reference systems, program re-structuring systems Prof. Loganathan R., CSE, HKBKCE 44
  • Activity-based tool classificationRe-engineering toolsTesting toolsDebugging toolsProgram analysis toolsLanguage-processing toolsMethod support toolsPrototyping toolsConfiguration managementtoolsChange management toolsDocumentation toolsEditing toolsPlanning tools Specification Design Implementation Verification & Prof. Loganathan R., CSE, HKBKCE Validation 45
  • CASE integration• Tools – Support individual process tasks such as design consistency checking, text editing, etc.• Workbenches – Support a process phase such as specification or design, Normally include a number of integrated tools.• Environments – Support all or a substantial part of an entire software process. Normally include several integrated workbenches. Prof. Loganathan R., CSE, HKBKCE 46
  • Tools, workbenches, environments Case Technology Tools Workbenches Environments Integrated Process-centred Editors Compilers File Comparators Environments Environments Analysis and Programming Testing Design Multi-method Single-method General-purpose Language-specific Workbenches Workbenches Workbenches Workbenches Prof. Loganathan R., CSE, HKBKCE 47