2 Objectives To introduce software process models To describe a number of different process models and when they may be usedTo describe outline process models for requirements engineering, software development, testing and evolutionTo introduce CASE technology to support software process activities
3 Topics covered Software process models Process iteration Software specificationSoftware design and implementationSoftware validationSoftware evolutionAutomated process support
4 The software processA structured set of activities required to develop a software systemSpecificationDesignValidationEvolutionA software process model is an abstract representation of a process. It presents a description of a process from some particular perspective
5 The software processAlthough 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.
6 Generic software process models The waterfall modelSeparate and distinct phases of specification and developmentEvolutionary developmentSpecification and development are interleavedFormal systems developmentA mathematical system model is formally transformed to an implementationReuse-based developmentThe system is assembled from existing components
7 Generic software process models The Waterfall ModelEvolutionary 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
8 CMMSoftware Engineering Institute (SEI) has developed a comprehensive model to determine an organization’s current state of process maturityThe 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.
9 CMM Level 1: Initial Level 2: Repeatable Level 3: Defined Level 4: ManagedLevel 5: OptimizingNote: 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.
11 Waterfall model phases Requirements analysis and definitionSystem and software designImplementation and unit testingIntegration and system testingOperation and maintenanceThe drawback of the waterfall model is the difficulty of accommodating change after the process is underway
12 Waterfall model phases 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.
13 Waterfall model phases 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.
14 Waterfall model problems Inflexible partitioning of the project into distinct stagesThis makes it difficult to respond to changing customer requirementsTherefore, this model is only appropriate when the requirements are well-understood
15 Waterfall model phases 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.
16 Evolutionary development Exploratory developmentObjective is to work with customers and to evolve a final system from an initial outline specification. Should start with well-understood requirementsThrow-away prototypingObjective is to understand the system requirements. Should start with poorly understood requirements
18 Evolutionary development 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.
19 Evolutionary development 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.
20 Evolutionary development ProblemsLack of process visibilitySystems are often poorly structuredSpecial skills (e.g. in languages for rapid prototyping) may be requiredApplicabilityFor small or medium-size interactive systemsFor parts of large systems (e.g. the user interface)For short-lifetime systems
21 Evolutionary development 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.
22 Evolutionary development 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.
23 Evolutionary 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
24 Formal systems development Formal systems development is an approach to softwaredevelopment which has something in common with thewaterfall model but where the development process isbased on formal mathematical transformation of a systemspecification to an executable program.
25 Formal systems development Based on the transformation of a mathematical specification through different representations to an executable programTransformations are ‘correctness-preserving’ so it is straightforward to show that the program conforms to its specificationEmbodied in the ‘Cleanroom’ approach to software development
28 Formal systems development The best known example of this formal developmentprocess is the Cleanroom process, which was originallydeveloped by IBMBoth the Cleanroom approach and another approach toformal development based on the B method (Wordsworth,1996) have been applied successfully.
29 Formal systems development ProblemsNeed for specialised skills and training to apply the techniqueDifficult to formally specify some aspects of the system such as the user interfaceApplicabilityCritical systems especially those where a safety or security case must be made before the system is put into operation
30 Reuse-oriented development Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systemsProcess stagesComponent analysisRequirements modificationSystem design with reuseDevelopment and integrationThis approach is becoming more important but still limited experience with it
31 Reuse-oriented development Component analysis Given the requirements specification, a search is made for components to implement that specification. Usually, there is not an exact matchRequirements 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.
33 Reuse-oriented development The reuse-oriented model has the obvious advantagethat it reduces cost and risks. It usually also leads to fasterdelivery of the software. However, requirementscompromises are inevitable and this may lead to a systemwhich does not meet the real needs of users.
34 Process iterationSystem 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 systemsIteration can be applied to any of the generic process modelsTwo (related) approachesIncremental developmentSpiral development
35 Process iterationIncremental 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.
36 Process iteration Incremental development is an in-between approach which combines the advantages of both of these models.The incremental approach to development wassuggested by Mills as a means of reducing rework in thedevelopment process and giving customers someopportunities to delay decisions on their detailedrequirements until they had some experience with the system.
37 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 functionalityUser requirements are prioritised and the highest priority requirements are included in early incrementsOnce the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve
39 Incremental development In an incremental development process, customersidentify, in outline, the services to be provided by thesystem. They identify which of the services are mostimportant and which are least important to them. Theallocation of services to increments depends on the servicepriority. The highest priority services are delivered first tothe customer.
40 Incremental development advantages Customer value can be delivered with each increment so system functionality is available earlierEarly increments act as a prototype to help elicit requirements for later incrementsLower risk of overall project failureThe highest priority system services tend to receive the most testing
41 Extreme programmingNew approach to development based on the development and delivery of very small increments of functionalityRelies on constant code improvement, user involvement in the development team and pairwise programming
42 Spiral developmentThe 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
43 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.
44 Spiral developmentProcess is represented as a spiral rather than as a sequence of activities with backtrackingEach 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 requiredRisks are explicitly assessed and resolved throughout the process
46 Spiral model of the software process Each loop in the spiral represents a phase of thesoftware process. Thus, the innermost loop might beconcerned with system feasibility, the next loop with systemrequirements definition, the next loop with system designand so on.
47 Spiral model sectors Objective setting Risk assessment and reduction Specific objectives for the phase are identifiedRisk assessment and reductionRisks are assessed and activities put in place to reduce the key risksDevelopment and validationA development model for the system is chosen which can be any of the generic modelsPlanningThe project is reviewed and the next phase of the spiral is planned
48 Software specification The process of establishing what services are required and the constraints on the system’s operation and developmentRequirements engineering processFeasibility studyRequirements elicitation and analysisRequirements specificationRequirements validation
49 Software specification 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.
50 Software specification 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 requirementsRequirements validation This activity checks the requirements for realism, consistency and completeness.
52 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.
53 Software design and implementation The process of converting the system specification into an executable systemSoftware designDesign a software structure that realises the specificationImplementationTranslate this structure into an executable programThe activities of design and implementation are closely related and may be inter-leaved
56 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.
57 The software design process 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.
58 The software design process In many software development projects, software designis still an ad hoc process. Starting from a set ofrequirements, usually in natural language, an informaldesign is prepared.A more methodical approach to software design isproposed by “structured methods” which are sets ofnotations and guidelines for software design.
59 Design methods Systematic approaches to developing a software design The design is usually documented as a set of graphical modelsPossible modelsData-flow modelEntity-relation-attribute modelStructural modelObject models
60 Programming and debugging Translating a design into a program and removing errors from that programProgramming is a personal activity - there is no generic programming processProgrammers carry out some program testing to discover faults in the program and remove these faults in the debugging process
62 Software validationVerification and validation is intended to show that a system conforms to its specification and meets the requirements of the system customerInvolves checking and review processes and system testingSystem testing involves executing the system with test cases that are derived from the specification of the real data to be processed by the system
64 Testing stages Unit testing Module testing Sub-system testing Individual components are testedModule testingRelated collections of dependent components are testedSub-system testingModules are integrated into sub-systems and tested. The focus here should be on interface testingSystem testingTesting of the system as a whole. Testing of emergent propertiesAcceptance testingTesting with customer data to check that it is acceptable
69 Testing phases Unit testing and module testing are usually the responsibility of the programmers developing thecomponent. Programmers make up their own test data andincrementally test the code as it is developed.Later stages of testing involve integrating work from anumber 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 systemspecification and design. Above Figure illustrates how testplans are the link between testing and developmentactivities.
70 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 changeAlthough there has been a demarcation between development and evolution (maintenance) this is increasingly irrelevant as fewer and fewer systems are completely new
72 Automated process support (CASE) Computer-aided software engineering (CASE) is software to support software development and evolution processesActivity automationGraphical editors for system model developmentData dictionary to manage design entitiesGraphical UI builder for user interface constructionDebuggers to support program fault findingAutomated translators to generate new versions of a program
73 Case technologyCase technology has led to significant improvements in the software process though not the order of magnitude improvements that were once predictedSoftware engineering requires creative thought - this is not readily automatableSoftware engineering is a team activity and, for large projects, much time is spent in team interactions. CASE technology does not really support these
74 CASE classificationClassification helps us understand the different types of CASE tools and their support for process activitiesFunctional perspectiveTools are classified according to their specific functionProcess perspectiveTools are classified according to process activities that are supportedIntegration perspectiveTools are classified according to their organisation into integrated units
77 CASE integration Tools Workbenches Environments Support individual process tasks such as design consistency checking, text editing, etc.WorkbenchesSupport a process phase such as specification or design, Normally include a number of integrated toolsEnvironmentsSupport all or a substantial part of an entire software process. Normally include several integrated workbenches
79 Key pointsSoftware processes are the activities involved in producing and evolving a software system. They are represented in a software process modelGeneral activities are specification, design and implementation, validation and evolutionGeneric process models describe the organisation of software processesIterative process models describe the software process as a cycle of activities
80 Key pointsRequirements engineering is the process of developing a software specificationDesign and implementation processes transform the specification to an executable programValidation involves checking that the system meets to its specification and user needsEvolution is concerned with modifying the system after it is in useCASE technology supports software process activities
81 INFORMATION ENGINEERING INSTITUTE (IEI) NSF Industry/University Cooperative Research Center IMS SJSU SiteIAB IMS Center: IEI Presentation on April 10, Detroit.NSF I/UCRC: IEI Presentation on June 2002Current Industry MembersEstimated BudgetStarting Date: June 1, 2002 ???
82 INFORMATION ENGINEERING INSTITUTE (IEI) Rename the IEI Institute:NISA Center: Networked-Intelligent Software AgentsN: NetworkedI: IntelligentS: SoftwareA: AgentsOther Names?Themes of the Center:No More than three focus research groupsResearch Focus Groups ???
83 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.
84 Intelligent Software Agent (ISA) 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.
85 Intelligent Software Agent (ISA) 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