software process n.
Skip this Video
Loading SlideShow in 5 Seconds..
Software process PowerPoint Presentation
Download Presentation
Software process

Loading in 2 Seconds...

play fullscreen
1 / 36

Software process - PowerPoint PPT Presentation

  • Uploaded on

Software process. Topics covered. Review the previous lecture Software Process RUP- Rational Unified Process. Review. Abstract representation of a process Framework of a process and hide the details of a specific activity Software process models Waterfall model

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Software process' - brant

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
topics covered
Topics covered
  • Review the previous lecture
  • Software Process
  • RUP- Rational Unified Process
  • Abstract representation of a process
    • Framework of a process and hide the details of a specific activity
  • Software process models
      • Waterfall model
      • Evolutionary development
        • Exploratory development
        • Thro-away prototyping
      • Component-based engineering
        • Based on COTS
  • Process iteration
      • Incremental delivery
      • Spiral development
process activities
Process activities
  • There are four basic process activities:
    • Software specification
    • Software design and implementation
    • Software validation
    • Software evolution
software specification or requirement engineering
Software specification or requirement Engineering
  • The process of establishing what services are required and the constraints on the system’s operation and development.
  • This process leads to the production of a requirements document( specification of the system).
  • Requirements engineering process
    • Feasibility study;
    • Requirements elicitation and analysis;
    • Requirements specification;
    • Requirements validation.
feasibility study
Feasibility study
  • is not used to solve the problem but is use to determine weather
    • the proposed system will be cost effect
    • if it can be developed with the existing budgetary
  • The result from this study is to inform the decision of whether or not to go ahead within the constrain
    • The report should be cheep and quick
requirements elicitation and analysis
Requirements elicitation and analysis
  • Discover the requirements from
    • Existing system
    • Discussion with user
    • Task analysis
  • You may use
    • System relative model
    • Prototypes
requirements specification
Requirements specification
  • In this process is about translating information gathered during the system analysis into into two documents
    • user or customer document includes abstract statements of the system requirements
    • Software developer documents includes more detailed description of the functionality to be provided.
requirements validation
Requirements validation
  • In this process, you are going to check if the requirements are
    • Real
    • Consistent
    • Complete

All these process is going to continue during definition and specification.

software design and implementation
Software design and implementation
  • The process of converting the system specification into an executable system.
  • Software design
    • Description of the structure of the software to be implemented, the data which is part of the system, interface between system component, and algorithm that realises the specification;
      • For example: library system
    • the design will be through of a number of versions. For each time you are going to add details and constrains with backtracking to correct the error in the earlier design.
    • The design process may involve developing several models of the system at different levels of abstraction.
software design and implementation1
Software design and implementation
  • Implementation
    • Translate this structure into an executable program;
  • The activities of design and implementation are closely related and may be interleaved.
design process activities
Design process activities
  • Input to design process
    • The software interface with other software system
      • OS, DB, other application program
        • For example: weather system ( real time system)- input comes from outside DB and application program to feed weather system to retrieve suitable and correct output display
      • Requirement specification is a description of the functionality the software that must provide
design process activities1
Design process activities
  • Design activities
    • Architectural design
      • Identify the overall structure includes
        • Sub-system if you used incremental development
        • Their relationship
        • How they are distributed
    • Interface design
      • Interfaces between components if you use sub-system. The interface specification should must unambiguous to implement them correctly.
    • Component design
      • Take each component and design how it will operate; simple statement of expected functionality to be implemented
    • Data structure design
      • design database structure and how these are to be presented
        • It can be existing database or create a new database
design process activities2
Design process activities
  • Output from design process
    • Set of design outputs
      • In OO approach, the output mostly be diagrams and in may cases automatically generate code
      • In agile method, the output may be represented in the code of program.
  • Possible models
    • Object model;
    • Sequence model;
    • State transition model;
    • Structural model;
    • Data-flow model.
programming and debugging
Programming and debugging
  • Programming is translating a design into a program
    • There in no general programing process that is usually followed
    • You may use software development tools (CASE TOOLS) to generate a skeleton program from a design.
    • You may start from well understood components then move less-understood components or versa vice.
    • Code the interfaces between these components
  • debugging is removing errors from that program.
  • Programmers carry out some program testing to discover faults in the program and remove these faults in the debugging process.
programming and debugging1
Programming and debugging
  • Defect testing and debugging are different processes.
  • Testing establishes the existence of defects.
  • Debugging is concerned with locating and correcting these defects.
  • Testing may involve tracing the program code manually  required new test cases to localize the problem; Or
  • You may use debugging tools to trace the code and find where are the errors.
software validation
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.
    • It is check list processing at each stage of the software process
  • 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.
testing stages
Testing stages
  • Component or unit testing
    • Individual components are tested independently;
    • Components may be functions or objects or coherent groupings of these entities.
  • System testing
    • Testing of the system as a whole. Testing of emergent properties is particularly important.
  • Acceptance testing
    • Testing with customer data to check that the system meets the customer’s needs.

If an incremental approach to development is used, each increment should be tested as it is developed,

  • Alpha vs. beta test
    • Acceptance testing is sometimes called alpha testing. Custom systems are developed for a single client.
    • When a system is to be marketed as a software product, a testing process called beta testing
      • Beta testing involves delivering a system to a number of potential customers who agree to use that system
software evolution
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(limit) between development and evolution (maintenance), this is increasingly irrelevant as fewer and fewer systems are completely new.
the rational unified process
The Rational Unified Process
  • A modern process model derived from the work on the UML -an object oriented modeling language - and associated process.
    • Takes the advantages of three generic processes
    • Good practice in specification and requirements
    • Support prototyping and incremental delivery
  • 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 of software development.
rup phases
RUP phases
  • Identify four discrete phases in software processes ( related to business point of view )
  • Phases are
    • Inception
      • Establish the business case for the system.
      • You should identify all external entities (people and systems) that will interact with the system and define these interactions.
    • Elaboration
      • Develop an understanding of the problem domain and the system.
      • establish an architectural framework for the system, develop the project plan and identify key project risks

Design use case, an architectural description and development design.

rup phases1
RUP phases
  • Construction
    • System design, programming and testing.
    • Developed in parallel an integrated
    • system sequence, state machine, and class diagram are design
    •  software system and their documentation to be ready to deliver to the user.
  • Transition
    • Deploy the system in its operating environment.
      • move the system from software development community to user community
    •  you should have a documented software system that is working correctly in its operational environment.
2 static view
2- Static view
  • RUP focuses on the activities that take place during the development process
  • It is called workflows in the RUP description.
  • There are six core process workflows identified in the process and three core supporting workflows.
3 rup good practice
3- RUP good practice
  • Develop software iteratively based on customer priority
  • Manage requirements by keep tracking of user changes to their requirements.
  • Use component-based architectures; system architecture based on component
  • Visually model software; use graphical UML models to present static and dynamic views of the software.
rup good practice
RUP good practice
  • Verify software quality;Ensure that the software meets the organizational quality standards.
  • Control changes to software; Manage changes to the software using a change management system and configuration management procedures and tools
key points
Key points
  • Software processes are the activities involved in producing and evolving a software system.
  • Software process models are abstract representations of these processes.
  • General activities are specification, design and implementation, validation and evolution.
  • Generic process models describe the organisation of software processes. Examples include the waterfall model, evolutionary development and component-based software engineering.
  • Iterative process models describe the software process as a cycle of activities.
key points1
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.
  • The Rational Unified Process is a generic process model that separates activities from phases.
  • CASE technology supports software process activities.