Software development o & c
Download as PPTX, PDF2 likes1,678 views
The document discusses various topics related to software development including challenges, opportunities, and best practices. Some key points: 1. Software development involves many phases from requirements analysis to testing to maintenance. It is important to involve users, establish clear standards, and divide projects into well-defined phases and activities. 2. Developing software presents inherent challenges like changing requirements, managing frequent changes, and ensuring compatibility with existing systems. Adopting a problem-solving approach and justifying systems as investments can help address some challenges. 3. Opportunities in software development include making the process more cost-effective, improving quality, and capturing important domain knowledge. New approaches like model-driven development also offer benefits if properly
Software development o & c
- 1. Software Development Challenges & Opportunities “You’ve got to be very careful if you don’t know where you’re going, because you might not get there.” Yogi Berra
- 2. Topics Covered in Presentation Software Lifecycle – At a glance Elements and Principles of Software Development. Software Development Activities Challenges with Software Development Problem solving Approach Model driven development strategy Risk vs Opportunity assessment Software Development Lifecycle Phases in development Problems with the approach Global and Legal Challenges Opportunities in working with specific approach.
- 3. • About • Technology • Client Base • Services
- 4. Project analysis Application for buying and selling ◦ Mobile application ◦ Search Adv. ◦ Post adv. Category Country Analysis ?
- 5. Software Life Cycle Software construction goes through a progression of states: Conception PreDevelopment Childhood Adulthood Development Retirement PostDevelopment 5
- 6. Elements of Software Development User Requirements Software Requirements: target systems, languages Architectural Design: target systems Detailed Software Design: language, structure, libraries Implementation: languages, quality, version control Unit Testing Integration Testing System Testing Deployment and Acceptance Testing Maintenance: regression testing, quality control, bug tracking, version control 6
- 7. Principles of System Development Get the system users involved. Use a problem-solving approach. Establish phases and activities. Document through development. Establish standards. Manage the process and projects Justify systems as capital investments. Don’t be afraid to cancel or revise scope. Divide and conquer. Design systems for growth and change. 3-7
- 8. Possible Identification of Software Development Activities What is the problem? What is the solution? Requirements Analysis System Design Problem Domain Program Implementation What are the mechanisms that best implement the solution? Implementation How is the solution constructed? Domain Testing Is the problem solved? Program Design Delivery Can the customer use the solution? Maintenance Are enhancements needed? 8
- 9. Participants in Systems Development Who participates in the system development life cycle?
- 10. Inherent Challenges with Software Development Requirements are complex ◦ The client usually does not know all the functional requirements in advance Requirements may be changing ◦ Technology enablers introduce new possibilities to deal with nonfunctional requirements Frequent changes are difficult to manage ◦ Identifying milestones and cost estimation is difficult There is more than one software system ◦ New system must often be backward compatible with existing system (―legacy system‖) ◦ Phased development: Need to distinguish between the system under development and already released systems 10
- 11. Manage the Process and Projects Process management – an ongoing activity that documents, manages, oversees the use of, and improves an organization’s chosen methodology (the ―process‖) for system development. Process management is concerned with phases, activities, deliverables, and quality standards should be consistently applied to all projects. Project management is the process of scoping, planning, staffing, organizing, directing, and controlling a project to develop an information system at a minimum cost, within a specified time frame, and with acceptable quality. 311
- 12. Don’t Be Afraid to Cancel or Revise Scope Creeping commitment – a strategy in which feasibility and risks are continuously reevaluated throughout a project. Project budgets and deadlines are adjusted accordingly. Risk management – the process of identifying, evaluating, and controlling what might go wrong in a project before it becomes a threat to the successful completion of the project or implementation of the information system. Risk management is drive by risk analysis or assessment. 312
- 13. Where Do Systems Development Projects Come From? Problem – ◦ an undesirable situation that prevents the organization from fully achieving its purpose, goals, and/or objectives. Opportunity – ◦ a chance to improve the organization even in the absence of an identified problem. Directive – ◦ a new requirement that is imposed by management, government, or some external influence. 313
- 14. Where Do Systems Development Projects Come From? Planned Projects ◦ An information systems strategy plan has examined the business as a whole to identify those system development projects that will return the greatest strategic (long-term) value to the business ◦ A business process redesign has thoroughly analyzed a series of business processes to eliminate redundancy and bureaucracy and to improve efficiency and value added. Not it is time to redesign the supporting information system for those redesigned business processes. 314
- 15. Use a Problem-Solving Approach Classical Problem-solving approach 1. Study and understand the problem, its context, and its impact. 2. Define the requirements that must be meet by any solution. 3. Identify candidate solutions that fulfill the requirements, and select the ―best‖ solution. 4. Design and/or implement the chosen solution. 5. Observe and evaluate the solution’s impact, and refine the solution accordingly. 315
- 16. The PIECES Problem-Solving Framework P the need to improve performance I the need to improve information (and data) E the need to improve economics, control costs, or increase profits C the need to improve control or security E the need to improve efficiency of people and processes S the need to improve service to customers, suppliers, partners, employees, etc.
- 17. Model-Driven Development Strategy Model-driven development – ◦ a system development strategy that emphasizes the drawing of system models to help visualize and analyze problems, define business requirements, and design information systems. ◦ Process modeling – a process-centered technique popularized by the structured analysis and design methodology that used models of business process requirements to derive effective software designs for a system. ◦ Data modeling – a data-centered technique used to model business data requirements and design database systems that fulfill those requirements. ◦ Object modeling – a technique that attempts to merge the data and process concerns into singular constructs called objects. Object models are diagrams that document a system in terms of its objects and their interactions. 317
- 18. Logical vs. Physical Models Logical model – a pictorial representation that depicts what a system is or does. Physical model – a technical pictorial representation that depicts what a system is or does and how the system is implemented. 318
- 19. Model-Driven Development Strategy Advantages Requirements often more thorough Easier to analyze alternatives Design specifications often more stable and flexible Systems can be constructed more correctly the first time Disadvantages Time consuming Models only as good as users' understanding of requirements Reduces users' role because pictures are not software Can be Inflexible 319
- 21. Opportunity Principle 1: ◦ Principle 2: ◦ Establish Phases and Activities Principle 4: ◦ Use a Problem-Solving Approach Principle 3: ◦ Get the Owners and Users Involved Justify Systems as Capital Investments Principle 5: ◦ Don’t Be Afraid to Cancel or Revise Scope
- 22. The System Development Life Cycle What are guidelines for system development? Arrange tasks into phases (groups of activities) Involve users (anyone for whom system is being built) Develop clearly defined standards (procedures company expects employees to follow)
- 23. What is a systems analyst? Responsible for designing and developing information system Liaison between users and IT professionals
- 24. What is the project team? Formed to work on project from beginning to end Consists of users, systems analyst, and other IT professionals Project leader—one member of the team who manages and controls project budget and schedule
- 25. The System Development Life Cycle What are some reasons to create or modify an information system? To correct problem in existing system To improve existing system Outside group may mandate change Competition can lead to change
- 26. What is the system proposal? Assesses feasibility of each alternative solution Recommen ds the most feasible solution for the project Presented to steering committee, which decides how system will be developed Formal request for new or modified information system Also called project request
- 28. What is the analysis phase? Conduct preliminary investigation, also called feasibility study Perform detailed analysis Read and understand the problem Interview client to be clear about the problem Develop a software specification: Clear statement of problem Basis of legal agreement Agreed between analyst and client
- 29. Why & How Play
- 30. Questioning Write a program which calculates and displays the average of a set of numbers Questions...?
- 31. Questioning • Write a program which calculates and displays the average of a set of numbers • Questions: – How many numbers in set? – What is maximum number? – Are numbers integers, or real? – What output device(s) to be used?
- 32. Inputs, Processes and Outputs
- 33. Inputs, Processes and Outputs
- 34. Inputs, Processes and Outputs
- 35. Feasibility Study Operational feasibility Measure of how suitable system development will be to the company Four feasibility tests: Schedule feasibility Economic feasibility (also called cost/benefit feasibility) Technical feasibility
- 36. What is the planning phase? Begins when steering committee receives project request Steering committee decision-making body for the company Function of committee: Review and approve project requests Prioritize project requests Allocate resources Form project development team for each approved project
- 37. What are possible solutions? Buy packaged software—prewritten software available for purchase Write own custom software—software developed at user’s request Outsource—have outside source develop software Horizontal market software—meets needs of many companies Vertical market software—designed for particular industry
- 38. Logical Design Phase Logical design – ◦ the translation of business user requirements into a system model that depicts only the business requirements and not any possible technical design or implementation of those requirements. Common synonyms include conceptual design and essential design. System model – ◦ a picture of a system that represents reality or a desired reality. System models facilitate improved communication between system users, system analysts, system designers, and system builders. Analysis paralysis – ◦ a satirical term coined to describe a common project condition in which excessive system modeling dramatically slows progress toward implementation of the intended system solution.
- 39. Physical Design & Integration Phase Physical design – ◦ the translation of business user requirements into a system model that depicts a technical implementation of the users’ business requirements. Common synonyms include technical design or implementation model. Two extreme philosophies of physical design Design by specification – ◦ physical system models and detailed specification are produced as a series of written (or computer-generated) blueprints for construction. Design by prototyping – ◦ Incomplete but functioning applications or subsystems (called prototypes) are constructed and refined based on feedback from users and other designers. 339
- 40. Construction and Testing Phase Construct and test system components ◦ Software Purchased Custom-built ◦ ◦ ◦ ◦ Databases User and System Interfaces Hardware Networks 340
- 41. Installation and Delivery Phase Deliver the system into operation (production) Deliver User training Deliver completed documentation Convert existing data 341
- 42. What is the support phase? Provides ongoing assistance after system is implemented The ongoing technical support for users of a system, as well as the maintenance required to deal with any errors, omissions, or new requirements that Conduct post-implementation system review—meeting to find out if information system is performing according to expectations Identify errors Identify enhancements Monitor system performance
- 43. System Development Documentation, Repository, and Presentations 343
- 44. Challenges in the Development Phases Difficulty of accommodating change One phase has to be complete before moving onto the next phase Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements. Only appropriate when the requirements are well-understood and changes will be fairly limited during the design process. Few business systems have stable requirements. Mostly used for large systems engineering projects where a system is developed at several sites. Not targeting all goals of Model-Driven Engineering Using model transformations which are not fully executable Not testing the model Insufficient tooling 44
- 45. Software Industry Challenges Costs Up Revenues Down Intervals Shrinking Market Expectations Up Complexity Up Stockholders : ROI Customers: Value Users : Functionality & Quality Need solutions that are flexible, expansible, survivable, sustainable, affordable and secure 2/21/2014 Seton Hall University
- 46. Legal challenges Intellectual property rights—general ◦ Application and tools Can you reuse your component? Can you use it in a competitor’s application? ◦ Proprietary confidential information Library source code, proprietary tools, data, … ◦ Test suites and case studies Performance of partner applications or process ◦ Overlapping alliances and conflicts
- 47. Legal Challenges Intellectual property rights ◦ Right to publish and disseminate Revealing experimental results ◦ Indirect intellectual property Insights developed in collaborative process Process and practices Whose law governs what?
- 48. Opportunities? Faster More cost-effective Leads to increased quality less error-prone leads to meaningful validation results in software being less sensitive to changes in personnel empowers domain experts lets advanced programmers focus on the hard stuff bridges the gap between business and IT in software being less sensitive to changes in business requirements results in software being less sensitive to changes in technology really enforces architecture captures domain knowledge provides up-to-date documentation enables to focus on business problems instead of technology provides you the ability to see your system at various levels
- 49. Our Learning's.. Development and maintenance processes our software portfolio Establish good software development practices Capture/rescue important legacy software Improve the quality of our software base: ◦ ◦ ◦ ◦ ◦ ◦ language conformance. portability (over many platforms and architectures) design and structure testing maintenance improve software quality Where possible use tools to automate, to make the process easier and more measurable Ensure our developers adopt some good practices and develop their own process of improvement! 49
- 50. What do we learn? Much of Best Practice is common sense – however is it formalised common sense The essence of Best Practice is in definition and documentation Software development should be managed like any project The Best Practice outlined is a framework in which to work The process steps have not been defined – these are the remit of the project to defined, implement and audit There are some tools that can aid a process step There is no magic bullet – software and development process improvement is a long term activity 50
- 51. Interact – with unknown Play
- 52. Job portal Candidate Registration Upload CV Upload documents Search CV