Online Tv Music Channel Presentation


Published on

Online Tv, Music Channel

  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Online Tv Music Channel Presentation

  1. 1. Online TV Music Channel 2MIN504 - Commercial Environments Miguel Rodrigues Student Number: 11511645
  2. 2. Overview • The project consists of an online TV music channel which content can be broadcasted online with a computer or a mobile device like Apple iPhone or the new phone from google Android G1 • The channel will broadcast Video clips from unsigned bands, as well as festivals and other music events from 3 capitals of Europe: London, Lisbon and Madrid. As well interviews from the artists.
  3. 3. • For the content to be broadcasted the user needs to install first a plug-in (i.e. Preferably our own plug-in but we can use other plug-ins such as sopcast, TVU Networks, Veetle Networks and so on) • The artists can submit the files through a submission form in .mp4 or .mov movie file formats and they will be converted to our own video format
  4. 4. Stakeholders Power = Authority = Stakehoders Responsability Budget holder Sometimes can be the Influence budget holder but not always Note: It is very important to understand what and how to communicate to each of the key stakeholders, making them feel confortable with the project and how it is progressing.
  5. 5. Stakeholders External Analisys Record Labels Independent Artists Consumers (music fans and mobile companies
  6. 6. Stakeholders Internal Analisys Programmer Grafic Designer (in a later stage of the implementation of the project)
  7. 7. Lifecycle Initiation Planning Execution Closure
  8. 8. Methods for large projects (SSADM, UML) Waterfall SSADM UML
  9. 9. Waterfall This is the classical system development model Concept Requirements Design Development Detailed design Testing implementation
  10. 10. Waterfall Strengths Weaknesses • Minimizes planning overhead • Inflexible since it can be done up front. • Only the final phase produces a • Structure minimizes wasted non-documentation deliverable. effort, so it works well for technically weak or inexperienced • Backing up to address mistakes staff. is difficult.
  11. 11. SSADM Structured Systems Analysis and Design Method developed in the early 1980s for systems analysis and application design widely used for government computing projects in the United Kingdom. combination of text and diagrams throughout the whole life cycle of a system design
  12. 12. SSADM Tecniques 1. Logical Data Modelling 3. Data Flow Modelling 5. Entity Behaviour Modelling
  13. 13. SSADM This is the classical system development model Feasibility Requirements Analysis Requirements Specification Logical System Specification Physical Design
  14. 14. SSADM Weaknesses • Adopts a structured, rigorous, project led approach to the development of data structures and processes (fail to recognise that data structures are largely stable and many processes dynamic) • requirements will not change during the development of a project •Following each step of SSADM rigorously can be time consuming and there may be a considerable delay between inception and delivery (which is typically the first time the users see a working system).
  15. 15. UML Unified Modeling Language modeling syntax aimed primarily at creating models of software-based systems, but can be used in a number of areas.
  16. 16. UML Features of UML Methodology: Syntax only - UML is just a language Comprehensive Language independent Process independent Tool independent Well documented It is a generic modeling language and needs to be adapted by the user to particular applications.
  17. 17. Prototyping methods for large and small projects RAD DSDM Evolutionary Throwaway prototyping
  18. 18. RAD es i nvolv iterative development RAD co m ns erg t ru ct e io structured techniques n prototypes
  19. 19. RAD - Stages Planning Design Construction Implementation
  20. 20. RAD Pros Cons • Promotes strong collaborative • Dependency on strong cohesive atmosphere and dynamic teams and individual commitment gathering of requirements to the project • Business owner actively • Success depends on disciplined participates in prototyping, writing developers and their exceptional test cases and performing unit technical skills and ability testing • Decision making relies on the functionality and less degree of centralized engineering authority.
  21. 21. DSDM 1. Active user involvement. 3. Empowered teams with authority to make decisions. 5. A focus on frequent delivery of products. 7. Using suitability for business purpose as the essential criteria for acceptance of deliverables. 5. Iterative and incremental development to ensure convergence on an accurate business solution. 13. Reversible changes during development. 15. Requirements that are base lined at a high level. 17. Integrated testing throughout the life cycle. 9. Collaboration and cooperation between all stakeholders.
  22. 22. DSDM Weaknesses DSDM does not concentrate on the fundamental importance of corporate data management DSDM adopts a dynamic, project led approach to both data structures and processes Like SSADM fails to recognize that data structures are largely stable and many processes dynamic
  23. 23. Evolutionary  uses multiple iterations of requirements gathering and analysis, design and prototype development iteration Analysis design Next level of requirements Prototype The result is analized by the costumer Costumer Development Nex iteration
  24. 24. Evolutionary Strengths Weaknesses Customers can see steady It is impossible to know at progress. the outset of the project how long it will take. This is useful when There is no way to know the requirements are changing number of iterations that will rapidly, when the customer be required. is reluctant to commit to a set of requirements, or when no one fully understands the application area.
  25. 25. Throwaway Prototyping Is a technical mechanism to reduce project risk by exploring critical factors to the project success  Main Benefits  Can significantly reduce risk  Commit to throwing the prototype away  When to use  It can be used at any time and by any person on a project.  Individual projects can realize some benefit by prototyping risky areas within their individual areas of responsability.  Main Risks  Not throwing it away  Inefficient use of prototyping time
  26. 26. Solo project or large team? 2/3 Programmers Grafic Designer TEAM: Database Manager Accountant
  27. 27. Which Methodology? Selecting the most appropriate methodology the pros and cons should be evaluated according to environment, cultural and technological development.
  28. 28.  Evolutionary Methodology – to deliver a working system to the users  RAD – because it promotes a strong collaborative atmosphere and dynamic gathering of requirements. Business owner actively participates in prototyping, writing test cases and performing unit testing RAD is suitable for applications which are interactive, with clear functionality at the user interface, have a clearly defined user group, are not computationally complex and have requirements which are not too detailed and fixed. It is possible, during the implementation of the plug-in and, mainly, on the development of the new Video format, to use a different methodology such as Throwaway methodology.
  29. 29. Evolutionary Methodology TV channel upload Website Videos Development of the plug-in Database RAD Methodology Development of the new Compressed video format Always regarding compression/quality issues Use of the Throwaway Methodology & Testing