Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×
Nächste SlideShare
Wird geladen in …3

Hier ansehen

1 von 56 Anzeige

Weitere Verwandte Inhalte

Diashows für Sie (20)

Ähnlich wie I (20)



  2. 2. Group Members 2  MS.RUSAIK RUSNI (0080)  ARM.RUSAN (0081)  MT.AHAMED NAFAIS (0084)  SM.LAREEF (0086)  A.ATHHARUL HAQ (0087)  SI.IHJAS (0088)
  3. 3. What is a process model? 3  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.
  4. 4. The software design process 4
  5. 5. The debugging process 5
  6. 6. The testing process 6
  7. 7. Waterfall model (classic lifecycle) 7  Requirements analysis and definition  System and software design  Implementation and Coding  Integration and system testing  Operation and maintenance  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.
  8. 8. The waterfall model 8
  9. 9. 9  The water fall model is easy to implementation.  For implementation of small systems water fall model is use full.  The project requires the fulfillment of one phase, before proceeding to the next.  It is easier to develop various software through this method in short span of time.
  10. 10. 10  The requirement analysis is done initially and sometimes it is not possible to state all the requirement explicitly in the beginning.  The customer can see working model of the project only at the end.  If we want to go backtrack then it is not possible in this model.  It is difficult to follow the sequential flow in software development process.
  11. 11. What is prototyping 11  The Prototyping Model is a systems development method (SDM) in which a prototype (an early approximation of a final system or product) is built, tested, and then reworked as necessary until an acceptableprototype is finally achieved from which the complete system or product can now be developed
  12. 12. Why prototype? •Evaluation and feedback are central to interaction design •Stakeholders can see, hold, interact with a prototype more easily than a document or a drawing •Team members can communicate effectively •You can test out ideas for yourself •Is quick, cheap and easily changed
  13. 13. Types of prototyping  Throw-away Prototyping  Evolutionary Prototyping  Low Fidelity Prototyping  High Fidelity Prototyping
  14. 14. Journey of the Prototyping process Goals Functionality Evaluate Develop
  15. 15. Prototyping model 15  Advantages  Users can try the system and provide feedback during development  An operational prototype can be produced in weeks.  Prototyping enables earlydetection of errors  Problems  Lack of process visibility.  Management is required.  It’s a expensive method in creating.  System performance and security issues can be overlooked
  16. 16. Introduction of RAD  RAD-based methodologies adjust the SDLC phases to get some part of system developed quickly and into the hands of the users.  Rapid Application development focuses on gathering customer requirements through  workshops or focus groups,  early testing of the prototypes by the customer using iterative concept,  reuse of the existing prototypes (components),  continuous integration and rapid delivery.
  17. 17. What is RAD?  Rapid application development (RAD) is a software development methodology that uses minimal planning in favor of rapid prototyping. A prototype is a working model that is functionally equivalent to a component of the product.  In RAD model the functional modules are developed in parallel as prototypes and are integrated to make the complete product for faster product delivery.  The most important aspect for this model to be successful is to make sure that the prototypes developed are reusable.
  18. 18. RAD Vs. Waterfall  RAD-based methodologies are well suited for projects with short time schedules as they increase speed.  Waterfall-based methodologies are the worst choice when time is essential as they do not allow for easy schedule changes.
  19. 19. RAD Model Design Phases Following are the phases of RAD Model:  BusinessModeling:  The business model for the product under development is designed in terms of flow of information and the distribution of information between various business channels.  A complete business analysis is performed to find the vital information for business,  how it can be obtained,  how and when is the information processed and what are the factors driving successful flow of information.  Data Modeling:  The information gathered in the Business Modeling phase is reviewed and analyzed to form sets of data objects vital for the business.  The attributes of all data sets is identified and defined.  The relation between these data objects are established and defined in detail in relevance to the business model.
  20. 20.  Process Modeling:  The data object sets defined in the Data Modeling phase are converted to establish the business information flow needed to achieve specific business objectives as per the business model.  The process model for any changes or enhancements to the data object sets is defined in this phase.  Process descriptions for adding , deleting, retrieving or modifying a data object are given.  Application Generation:  The actual system is built and coding is done by using automation tools to convert process and data models into actual prototypes.  Testing and Turnover:  The overall testing time is reduced in RAD model as the prototypes are independently tested during every iteration.  However the data flow and the interfaces between all the components need to be fully tested with complete test coverage.  Since most of the programming components have already been tested, it reduces the risk of any major issues.
  21. 21.  Following images illustrates the RAD Model:
  22. 22. When to Use RAD  RAD is used when  The team includes programmers and analysts who are experienced with it  There are pressing reasons for speeding up application development  The project involves a new ecommerce application and needs quick results  Users are modern and highly engaged with the goals of the company
  23. 23. Advantage & Disadvantage of RAD Advantage Disadvantage  Changing requirements can be accommodated.  Progress can be measured.  Iteration time can be short with use of powerful RAD tools.  Productivity with fewer people in short time.  Reduced development time.  Increases reusability of components  Encourages customer feedback  Dependency on technically strong team members for identifying business requirements.  Only system that can be modularized can be built using RAD.  Requires highly skilled developers/designers.  High dependency on modeling skills.  Inapplicable to cheaper projects as cost of modeling and automated code generation is very high.  Management complexity is more.
  24. 24. Incremental development] 24  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
  25. 25. Incremental development 25
  26. 26. Incremental development advantages 26  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.
  27. 27. Spiral development 27  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.
  28. 28. Spiral model sectors 28  Objective setting  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.
  29. 29. Spiral model of the software process 29
  30. 30. Rapid software development 30  Because of rapidly changing business environments, businesses have to respond to new opportunities and competition.  Rapid software development and delivery is now often the most critical requirement for software systems.  Businesses may be willing to accept lower quality software if rapid delivery of essential functionality is possible.
  31. 31. Requirements 31  Because of the changing environment, it is often impossible to arrive at a stable, consistent set of system requirements.  Therefore a waterfall model of development is impractical and an approach to development based on iterative specification and delivery is the only way to deliver software quickly.
  32. 32. Characteristics of rapid software development process 32  The processes of specification, design and implementation are concurrent. There is no detailed specification, and design documentation is minimized.  The system is developed in a series of increments. End users evaluate each increment and make proposals for later increments.  System user interfaces are usually developed using an interactive development system.
  33. 33. An iterative development process 33
  34. 34. Advantages of incremental development 34  Accelerated delivery of customer services. Each increment delivers the highest priority functionality to the customer.  User engagement with the system. Users have to be involved in the development which means the system is more likely to meet their requirements and the users are more committed to the system.
  35. 35. Problems with incremental development  Management problems 35  Progress can be hard to judge and problems hard to find because there is no documentation to demonstrate what has been done.  Contractual problems  The normal contract may include a specification; without a specification, different forms of contract have to be used.  Validation problems  Without a specification, what is the system being tested against?  Maintenance problems  Continual change tends to corrupt software structure making it more expensive to change and evolve to meet new requirements.
  36. 36. Prototyping 36  For some large systems, incremental iterative development and delivery may be impractical; this is especially true when multiple teams are working on different sites.  Prototyping, where an experimental system is developed as a basis for formulating the requirements may be used. This system is thrown away when the system specification has been agreed.
  37. 37. Incremental development and prototyping 37
  38. 38. Conflicting objectives 38  The objective of incremental development is to deliver a working system to end-users. The development starts with those requirements which are best understood.  The objective of throw-away prototyping is to validate or derive the system requirements. The prototyping process starts with those requirements which are poorly understood.
  39. 39. Agile methods 39  Dissatisfaction with the overheads involved in design methods led to the creation of agile methods. These methods:  Focus on the code rather than the design;  Are based on an iterative approach to software development;  Are intended to deliver working software quickly and evolve this quickly to meet changing requirements.  Agile methods are probably best suited to small/medium-sized business systems or PC products.
  40. 40. Principles of agile methods 40 Principle Description Customer involvement The customer should be closely involved throughout the development process. Their role is provide and prioritise new system requirements and to evaluate the iterations of the system. Incremental delivery The software is developed in increments with the customer specifying the requirements to be included in each increment. People not process The skills of the development team should be recognised and exploited. The team should be left to develop their own ways of working without prescriptive processes. Embrace change Expect the system requirements to change and design the system so that it can accommodate these changes. Maintain simplicity Focus on simplicity in both the software being developed and in the development process used. Wherever possible, actively work to eliminate complexity from the system.
  41. 41. Problems with agile methods 41  It can be difficult to keep the interest of customers who are involved in the process.  Team members may be unsuited to the intense involvement that characterizes agile methods.  Prioritizing changes can be difficult where there are multiple stakeholders.  Maintaining simplicity requires extra work.  Contracts may be a problem as with other approaches to iterative development
  42. 42. Extreme programming 42  Perhaps the best-known and most widely used agile method.  Extreme Programming (XP) takes an ‘extreme’ approach to iterative development.  New versions may be built several times per day;  Increments are delivered to customers every 2 weeks;  All tests must be run for every build and the build is only accepted if tests run successfully.
  43. 43. The XP release cycle 43
  44. 44. Extreme programming practices 1 44 Incremental planning Requirements are recorded on Story Cards and the Stories to be included in a release are determined by the time available and their relative priority. The developers break these Stories into development ‘Tasks’. Small Releases The minimal useful set of functionality that provides business value is developed first. Releases of the system are frequent and incrementally add functionality to the first release. Simple Design Enough design is carried out to meet the current requirements and no more. Test first development An automated unit test framework is used to write tests for a new piece of functionality before that functionality itself is implemented. Refactoring All developers are expected to refactor the code continuously as soon as possible code improvements are found. This keeps the code simple and maintainable.
  45. 45. Extreme programming practices 2 45 Pair Programming Developers work in pairs, checking each otherÕs work and providing the support to always do a good job. Collective Ownership The pairs of developers work on all areas of the system, so that no islands of expertise develop and all the developers own all the code. Anyone can change anything. Continuous Integration As soon as work on a task is complete it is integrated into the whole system. After any such integration, all the unit tests in the system must pass. Sustainable pace Large amounts of over-time are not considered acceptable as the net effect is often to reduce code qualit y and medium term productivity On-site Customer A representative of the end-user of the system (the Customer) should be available full time for the use of the XP team. In an extreme programming process, the customer is a member of the development team and is responsible for bringing system requirements to the team for implementation.
  46. 46. 2.11. Rapid Application Development (RAD) 46  Agile methods have received a lot of attention but other approaches to rapid application development have been used for many years.  These are designed to develop data-intensive business applications and rely on programming and presenting information from a database.
  47. 47. RAD environment tools 47  Database programming language  Interface generator  Links to office applications  Report generators
  48. 48. A RAD environment 48
  49. 49. 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 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.
  50. 50. Evolutionary development
  51. 51. 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.
  52. 52. FORMAL METHODS MODEL 52  Comprises set of activities that leads to formal  mathematical specification of computer software.  Enables a software engineer to specify, develop and  verify a computer based system by applying  mathematical notation.  Problems of ambiguity, incompleteness and  inconsistency can be managed by this method.  Provides a base for verification therefore enable a
  53. 53. UNIFIED PROCESS MODEL 53  Comprises best features and characteristics of conventional  software process models.  Emphasize importance of customer communication and  streamlined methods for describing the customers view of  system.  Phases of Unified Process  Inception = Involves customer communication and  planning activities.  Elaboration = Encompasses the customer  communication and modeling activities of the generic  process model. Architectural representation using Use  Case Model, Analysis Model, Design Model,  Implementation Model and Deployment Model. 
  55. 55. 55  Construction = Develops or acquires the software  components that will make each use case operational for  end users.  Transition = Software is given to end user for beta testing  and user feedback reports both defects and necessary  changes.  Production = Coincides with the deployment activity of  process. The on going use of software is monitored,  support for the operating environment is provided, and  defect reports and requests for changes are submitted  and evaluated.
  56. 56. 56 Thank you...