1 / 18

DT22 8 /3

DT22 8 /3. Software and Knowledge Engineering Lecturer: Deirdre Lawless. Traditional Systems Development. What are the phases ? What roles are there ? Who does what ? What are the difficulties ?. Software/Systems Development/Engineering. Methodology ? What is a methodology?

zahir-melendez
Download Presentation

DT22 8 /3

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. DT228/3 Software and Knowledge Engineering Lecturer: Deirdre Lawless

  2. Traditional Systems Development • What are the phases ? • What roles are there ? • Who does what ? • What are the difficulties ?

  3. Software/Systems Development/Engineering • Methodology ? • What is a methodology? • How did it start ? • Why use one ? • Types of methodology ? • What methodologies are you familiar with ? • Key aspects of methodologies ? • Problems of methodologies ?

  4. Early Methodology Era • The SDLC (Waterfall) model • Methodology :”…a recommended collection of philosophies, phases, rules, procedures, techniques, tools and training for developers of information systems” • Well tried and tested • Reduces likelihood of unexpected cost/time blowouts • Ensures continuity of standards

  5. Methodology Era • Alternative “methodologies” emphasise different approaches to documentation, data, human, or process aspects • Packaged product which may include: • Manuals • Education and training • Consultancy support • CASE tools • Pro-forma documents • Model-building templates

  6. Aims of Methodologies • Aims • A better end product • A better development process • A standardised process • Easier maintenance and enhancement • Categories • Structured • Data oriented • Strategic • Participative • Prototyping • Object-oriented • Tools • Systems

  7. Methodology “Backlash” • Productivity failure • Complexity • ‘Gilding the lily’ • Skills • Tools • Not contingent • One-dimensional • Goal-displacement • No improvements

  8. Criticisms of Methodologies • Structured decomposition is simplistic approach failing to identify linkages between systems • Data analysis may not solve business problems • Participation can be inefficient • Prototyping “makes poor systems palatable”

  9. Why Agile methods? • IT is seen to overpromise and underdeliver • Organizations need quality working software even though they face constant change • Agile methods stress quality in design • still plan – but understand the limits of planning

  10. What is agility? • Quickness – act rapidly • Lightness – do the minimum needed • Nimbleness – adapt to change

  11. Agile Manifestowww.agilemanifesto.org

  12. Agile (lightweight) Methodologies • Reaction to bureaucracy of large rigourous methodologies • Attempt to provide “just enough process to provide a reasonable payoff” • Agile methods are adaptive rather than predictive • Agile methods are people-oriented rather than process-oriented • “Agile methods derive much of their agility by relying on the tacit knowledge embodied in the team, rather than writing the knowledge down in plans” • Barry Boehm

  13. The Agile attitude focuses on: 1. Talent & Skill (fewer better people) 2. Proximity (developers - developers - users) 3. Communication (morale, daily standup) 4. Just-in-time requirements and design 5. Frequent Delivery (incremental development) 6. Reflection 7. Less paper, more tacit / verbal communication 8. Tools 9. Quality in work 10. Different strategies for different projects

  14. Agile Methodologies Methodologies share common principles, but differ in practices eXtreme Programming (XP) Scrum Evolutionary Project Management (Evo) Unified Process (UP) Crystal Lean Development (LD) Adaptive Software Development (ASD) Dynamic System Development Method (DSDM) Feature Driven Development (FDD)

  15. Agile Development Process • Agile Development Process • Iterative and evolutionary development • Timeboxing • –Set amount of time for iteration • –Adapt future iteration based on the realities • Adaptive planning • Incremental delivery • Agility • More focused on success than sticking with a plan • Working software is valued and considered measure of progress

  16. Agile Principles Highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Harness change for the customer's competitive advantage. Deliver working software frequently from a couple of weeks to a couple of months with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Promote sustainable development. Sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity is essential. the art of maximizing the amount of work not done The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

  17. Extreme Programming in a Nutshell • Extreme Programming: • Lightweight: little documentation or administration overhead • Agile: able to adapt quickly to changes in user requirements • Best for small scale projects with uncertain or evolving requirements • Style: • Iterative development (about a dozen iterations of 1-3 weeks each) of a complete system on each iteration • Just in time planning (does not plan much beyond the current iteration) • Emphasis on testing (unit tests are written before functionality) • Carefully considers people issues (stand-up meetings, pair programming, no overtime) • http://www.extremeprogramming.org • Started by Kent Beck at DaimlerChrysler in 1996 • But there is still not enough evidence to determine if XP is the ‘holy grail’ of SE

  18. Essence of XP • Four variables in software development : • Cost, Time, Quality, Scope • Four Values • Communication, Simplicity, Feedback, and Courage • Five Principles • Provide feedback, assume simplicity, make incremental changes, embrace change, quality work • 12 Practices (or fewer) • Planning game, small releases, simple designs, automated testing, continuous integration, refactoring, pair programming, collective ownership, 40-hour week, on-site customer, coding standard, metaphor

More Related