Lesson 2 Software Processes.

Lesson 2 Software Processes

Objectives To introduce software process models
To describe a number of different process models and when they may be used To describe outline process models for requirements engineering, software development, testing and evolution To introduce CASE technology to support software process activities

Topics covered Software process models Process iteration
Software specification Software design and implementation Software validation Software evolution Automated process support

The software process A structured set of activities required to develop a software system 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

The software process Although there are many different software processes, there are fundamental activities which are common to all software processes. These are: Software specification The functionality of the software and constraints on its operation must be defined. Software design and implementation The software to meet the specification must be produced. Software validation The software must be validated to ensure that it does what the customer wants. Software evolution The software must evolve to meet changing customer needs.

Generic software process models
The waterfall model Separate and distinct phases of specification and development Evolutionary development Specification and development are interleaved Formal systems development A mathematical system model is formally transformed to an implementation Reuse-based development The system is assembled from existing components

Generic software process models
The Waterfall Model Evolutionary development An initial system is rapidly developed from abstract specifications. This is then refined with customer input to produce a system which satisfies the customer’s needs. Formal systems development This approach is based on producing a formal mathematical system specification and transforming this specification, using mathematical methods, to construct a program. Reuse-based development This approach is based on the existence of a significant number of reusable components. The system development process focuses on integrating these components into a system rather than developing them from scratch

CMM Software Engineering Institute (SEI) has developed a comprehensive model to determine an organization’s current state of process maturity The grading scheme determines compliance with a capability maturity model (CMM). CMM defines key activities required at different levels of process maturity. Five point assessment grading scheme. CMM provides measure of the global effectiveness of a company’s software engineering practices.

CMM Level 1: Initial Level 2: Repeatable Level 3: Defined
Level 4: Managed Level 5: Optimizing Note: The grading scheme defined by the SEI were derived as a consequence of evaluating responses to the SEI assessment questionnaire. Key Process Areas (KPAs) have been associated with each of the maturity levels. Each KPA is described by identifying the following characteristics (Eighteen KPAs) - Goals, Commitments, Abilities, Activities, Methods for monitoring implementation, and Methods for verifying implementation.

Waterfall model

Waterfall model phases
Requirements analysis and definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance The drawback of the waterfall model is the difficulty of accommodating change after the process is underway

Requirements analysis and definition The system’s services, constraints and goals are established by consultation with system users. They are then defined in detail and serve as a system specification. System and software design The system’s design process partitions the requirements to either hardware or software systems. It establishes an overall system architecture. Software design involves identifying and describing the fundamental software system abstractions and their relationships. Implementation and unit testing During this stage, the software design is realised as a set of programs or program units. Unit testing involves verifying that each unit meets its specification.

Integration and system testing The individual program units or programs are integrated and tested as a complete system to ensure that the software requirements have been met. After testing, the software system is delivered to the customer. Operation and maintenance Normally this is the longest life-cycle phase. The system is installed and put into practical use. Maintenance involves correcting errors which were not discovered in earlier stages of the life cycle, improving the implementation of system units and enhancing the system’s services as new requirements are discovered.

Waterfall model problems
Inflexible partitioning of the project into distinct stages This makes it difficult to respond to changing customer requirements Therefore, this model is only appropriate when the requirements are well-understood

Real projects rarely follow the sequential flow that the model proposes. Changes can cause confusion as the project team proceeds. It is often difficult for the customer to state all requirements explicit. A working version of the program(s) will not be available until late in the project-span. The model leads to “blocking states.” Note: The linear model is better than a haphazard approach to software development.

Evolutionary development
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 Throw-away prototyping Objective is to understand the system requirements. Should start with poorly understood requirements

Customer defines a set of general objectives for software but does not identify detailed input, processing, or output requirements. Developer and customer meet and define the overall objectives for the software: - Quick design leads to the construction of a prototype. - Iteration occurs as the prototype is tuned to satisfy the needs of the customer. Note: Both developer and customer like the prototyping paradigm. Users get a feel for the actual system.

The prototype is held together “with chewing gum and bailing wire” : software quality. The developers make implementation compromises in order a quick design working. (operating system, programming languages, …). The less-than-ideal chance has become an integral part of the software system. Note: The key is to define the rules of the games at the beginning in particular in long-term maintainability and quality.

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

For small systems (less than 100,000 lines of code) or for medium-sized systems (up to 500,000 lines of code) with a fairly short lifetime, I think that the evolutionary approach to development is the best approach. However, for large, long-lifetime systems, the problems of evolutionary development become particularly acute. For these systems, I recommend a mixed process that incorporates the best features of the waterfall and the evolutionary development models.

This may involve developing a throw-away prototype using an evolutionary approach to resolve uncertainties in the system specification. This system may then be re-implemented using a more structured approach. Parts of the system which are well understood can be specified and developed using a waterfall-based process. Other parts of the system, such as the user interface, which are difficult to specify in advance, should be developed using an exploratory programming approach.

The spiral model couples the iterative nature of prototyping with the controlled and systematic aspect of the linear sequential model. Using the spiral model, software is developed in a series of incremental releases. A spiral model is divided into a number of framework activities: task regions - Customer communication - Planning - Risk analysis - Engineering - Construction and release - Customer evaluation

Formal systems development
Formal systems development is an approach to software development which has something in common with the waterfall model but where the development process is based on formal mathematical transformation of a system specification to an executable program.

Based on the transformation of a mathematical specification through different representations to an executable program Transformations are ‘correctness-preserving’ so it is straightforward to show that the program conforms to its specification Embodied in the ‘Cleanroom’ approach to software development

Formal transformations

The best known example of this formal development process is the Cleanroom process, which was originally developed by IBM Both the Cleanroom approach and another approach to formal development based on the B method (Wordsworth, 1996) have been applied successfully.

Problems Need for specialised skills and training to apply the technique Difficult to formally specify some aspects of the system such as the user interface Applicability Critical systems especially those where a safety or security case must be made before the system is put into operation

Reuse-oriented development
Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems Process stages Component analysis Requirements modification System design with reuse Development and integration This approach is becoming more important but still limited experience with it

Component analysis Given the requirements specification, a search is made for components to implement that specification. Usually, there is not an exact match Requirements modification During this stage, the requirements are analysed using information about the components which have been discovered. They are then modified to reflect the available components. System design with reuse During this phase, the framework of the system is designed or an existing framework is reused. Some new software may have to be designed if reusable components are not available. Development and integration The components and COTS systems are integrated to create the system.

The reuse-oriented model has the obvious advantage that it reduces cost and risks. It usually also leads to faster delivery of the software. However, requirements compromises are inevitable and this may lead to a system which does not meet the real needs of users.

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 development Spiral development

Process iteration Incremental development where the software specification, design and implementation is broken down into a series of increments which are developed in turn; Spiral development where the development of the system spirals outwards from an initial outline through to the final development system.

Process iteration Incremental development is an in-between approach
which combines the advantages of both of these models. The incremental approach to development was suggested by Mills as a means of reducing rework in the development process and giving customers some opportunities to delay decisions on their detailed requirements until they had some experience with the system.

Incremental development
Rather than deliver the system as a single delivery, the development 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

In an incremental development process, customers identify, in outline, the services to be provided by the system. They identify which of the services are most important and which are least important to them. The allocation of services to increments depends on the service priority. The highest priority services are delivered first to the customer.

Incremental development 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

Extreme programming New approach to 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 pairwise programming

Spiral development The spiral model couples the iterative nature of prototyping with the controlled and systematic aspect of the linear sequential model. Using the spiral model, software is developed in a series of incremental releases. A spiral model is divided into a number of framework activities: task regions - Customer communication - Planning - Risk analysis - Engineering - Construction and release - Customer evaluation

Spiral development Note:
Each task region is populated by a set of work tasks called a task set. In all cases, the umbrella activities are applied. Unlike classical process models that end when software is delivered, the spiral model can be adapted to apply throughput the life of the computer software. The spiral model is a realistic approach to the development of large-scale systems. Technical risks are applied at all stages. It should reduce risks. The spiral model is not mature process yet.

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

Spiral model of the software process

Spiral model of the software process
Each loop in the spiral represents a phase of the software process. Thus, the innermost loop might be concerned with system feasibility, the next loop with system requirements definition, the next loop with system design and so on.

Spiral model sectors Objective setting Risk assessment and reduction
Specific objectives for the phase are identified Risk assessment and reduction Risks are assessed and activities put in place to reduce the key risks Development and validation A development model for the system is chosen which can be any of the generic models Planning The project is reviewed and the next phase of the spiral is planned

Software specification
The process of establishing what services are required and the constraints on the system’s operation and development Requirements engineering process Feasibility study Requirements elicitation and analysis Requirements specification Requirements validation

Feasibility study an estimate is made of whether the identified user needs may be satisfied using current software and hardware technologies. The result should inform the decision of whether to go ahead with a more detailed analysis. Requirements elicitation and analysis This is the process of deriving the system requirements through observation of existing systems, discussions with potential users and procurers, task analysis, etc. This may involve the development of one or more different system models and prototypes. These help analyst understand the system to be specified.

Requirements specification Requirements specification is the activity of translating the information gathered during the analysis activity into a document that defines a set of requirements. Two types of requirements : User requirements, System requirements Requirements validation This activity checks the requirements for realism, consistency and completeness.

The requirements engineering process

The requirements engineering process
Note : Of course the activities in the requirements process are not simply carried out in a strict sequence. Therefore, the activities of analysis, definition and specification are interleaved.

Software design and implementation
The process of converting the system specification into an executable system Software design Design a software structure that realises the specification Implementation Translate this structure into an executable program The activities of design and implementation are closely related and may be inter-leaved

Design process activities
Architectural design Abstract specification Interface design Component design Data structure design Algorithm design

The software design process

Architectural design The sub-systems making up the system and their relationships are identified and documented. Abstract specification For each sub-system, an abstract specification of its services and the constraints under which it must operate is produced. Interface design For each sub-system, its interface with other sub-system is designed and documented. This interface specification must be unambiguous as it allows the sub-system to be used without knowledge of the sub-system operation.

Component design Services are allocated to different components and the interfaces of these components are designed. Data Structure design The data structures used in the system implementation are designed in detail and specified. Algorithm design The algorithms used to provide services are designed in detail and specified.

In many software development projects, software design is still an ad hoc process. Starting from a set of requirements, usually in natural language, an informal design is prepared. A more methodical approach to software design is proposed by “structured methods” which are sets of notations and guidelines for software design.

Design methods Systematic approaches to developing a software design
The design is usually documented as a set of graphical models Possible models Data-flow model Entity-relation-attribute model Structural model Object models

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

The debugging process

Software validation Verification and validation 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 to be processed by the system

The testing process

Testing stages Unit testing Module testing Sub-system testing
Individual components are tested Module testing Related collections of dependent components are tested Sub-system testing Modules are integrated into sub-systems and tested. The focus here should be on interface testing System testing Testing of the system as a whole. Testing of emergent properties Acceptance testing Testing with customer data to check that it is acceptable

Intruder alarm system

Component types in alarm system
Sensor Movement sensor, door sensor Actuator Siren Communication Telephone caller Co-ordination Alarm controller Interface Voice synthesizer

Testing phases

Testing phases Unit testing and module testing are usually the
responsibility of the programmers developing the component. Programmers make up their own test data and incrementally test the code as it is developed. Later stages of testing involve integrating work from a number of programmers and must be planned in advance. An independent team of testers should work from pre- formulated test plans which are developed from the system specification and design. Above Figure illustrates how test plans are the link between testing and development activities.

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

System evolution

Automated process support (CASE)
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

Case technology Case technology has led to significant improvements in the software process though not the order of magnitude improvements that were once predicted Software engineering requires creative thought - this is not readily automatable Software engineering is a team activity and, for large projects, much time is spent in team interactions. CASE technology does not really support these

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

Functional tool classification

Activity-based classification

CASE integration Tools Workbenches Environments
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

Tools, workbenches, environments

Key points Software processes are the activities involved in producing and evolving a software system. They are represented in a software process model General activities are specification, design and implementation, validation and evolution Generic process models describe the organisation of software processes Iterative process models describe the software process as a cycle of activities

Key points Requirements engineering is the process of developing a software specification Design and implementation processes transform the specification to an executable program Validation involves checking that the system meets to its specification and user needs Evolution is concerned with modifying the system after it is in use CASE technology supports software process activities

INFORMATION ENGINEERING INSTITUTE (IEI)
NSF Industry/University Cooperative Research Center IMS SJSU Site IAB IMS Center: IEI Presentation on April 10, Detroit. NSF I/UCRC: IEI Presentation on June 2002 Current Industry Members Estimated Budget Starting Date: June 1, 2002 ???

INFORMATION ENGINEERING INSTITUTE (IEI)
Rename the IEI Institute: NISA Center: Networked-Intelligent Software Agents N: Networked I: Intelligent S: Software A: Agents Other Names? Themes of the Center: No More than three focus research groups Research Focus Groups ???

Intelligent Software Agent (ISA)
The ISA functional architecture consists of four basic agent types: Interface agents -- interact with users, receive user input, and display results. Task agents -- help users perform tasks, formulate problem-solving plans and carry out these plans by coordinating and exchanging information with other software agents. Information agents -- provide intelligent access to a heterogeneous collection of information sources. Middle agents -- help match agents that request services with agents that provide services.

Each ISA agent has four reusable modules for communicating, planning, scheduling, and monitoring the execution of tasks and requests from other agents. The Communication and Coordination module accepts and interprets messages and requests from other agents. The Planning module takes as input a set of goals and produces a plan that satisfies the goals. The Scheduling module uses the task structure created by the planning module to order the tasks. The Execution module monitors this process and ensures that actions are carried out in accordance with computational and other constraints.

Goal: How J2EE EJB application servers can be the basis to build reliable and scalable agent-based business applications that are compatible and interfaceable with current non-agent systems and technologies. Focus: The ISA technologies will be among the key concepts of future software and network infrastructure

Activity Areas: Industrial Research Product & Solution Development Consulting ISA Strategic Path: Horizontal: Platforms & Tools Vertical: communications & Networks e-finance e-commerce Logistics Etc…

Lesson 2 Software Processes.

Similar presentations

Presentation on theme: "Lesson 2 Software Processes."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Lesson 2 Software Processes.

Similar presentations

Presentation on theme: "Lesson 2 Software Processes."— Presentation transcript:

Similar presentations

About project

Feedback