se

• Software Development


  In the past, software development has been accomplished in distinct stages, where each stage must be completed before the next is commenced. Altering requirements during development was difficult and costly. Faster, more reactive approaches were required.
• Structured or Waterfall Development Approach

  1. Requirements definition

  2. Determining specifications

  3. Design

  4. Development

  5. Integration

  6. Testing and debugging

  7. Installation

  8. Maintenance
• Structured Approach


  • Consists of distinct stages, each stage needs to be completed before the next stage can commence
  • Used for large-scale projects where performance and reliability are vital requirements
  • A large audience will use the final product so even relatively minor errors may prove costly
  • Particularly suited to software development where all the requirements and specifications can be defined before any design commences
  • Generally large-scale projects requiring a full development team and the timeframe is long with a large budget
  • If safety is important and or a bespoke solution is required, then the Structured Approach is likely the most suitable
• Agile Development Approach


  • Places emphasis on the team developing the system rather than following the pre-defined structured development stages
  • Removes the need for detailed requirements and complex design documentation
  • Encourages cooperation and teamwork
  • Particularly well suited to user-centred software development and software applications that are modified regularly such that they evolve and are updated over time

  
• Agile development is characterised by small teams of developers. It is preferable for one team member to be a knowledgeable and experienced user. Small teams are better able to share ideas and work on solutions together. Larger teams tend to break into smaller groups – for agile methods to be a success everyone must be an equal member with a clear shared purpose. Often the team members are multi-skilled so all are actively contributing.
• Typical characteristics of an agile software development approach

  • Agility: Speed of getting a working solution to market or to users. Basic functionality is included initially so operational software can be released as soon as possible.
  • Adaptive: Interaction within the team and users which allows the solution to be selectively refined throughout the development process.
  • Progressive: Working versions of the software are regularly delivered. Each version adds the next most important functions.
  • Collaborative: The development team and clients collaborate closely throughout the development. Often a client representative or user is part of the team. The needs and ongoing feedback of the client and users drives the direction of the development.

  
• Agile Development Approach


  1. Determine general nature of problem

  2. Form development team

  3. Create basic plan and general design

  4. Implement initial solution

  5. Test, evaluate and release initial solution

  6. Discuss next iteration incorporating user feedback

  7. Implement next iteration

  8. Test, evaluate and release next iteration

  9. Repeat process

  
• User Stories


  • Focus on the user and what they want the software to actually do
  • Created by each different type of user
  • Prioritised and each becomes the focus of a development iteration
  • Involves one or more actors (often users, such as customers or employees)
  • Refined using suitable system models like UML (Unified Modelling Language)

  
• Agile methods are a response to the reality that intricate details are difficult to specify accurately in advance. Each part of a software solution relies heavily on many other related parts. Until the related parts exist, it is wasteful to continue designing. Much of the design will prove unworkable and will need to be redesigned or significantly altered.
• A common solution to the dilemma of outsourcing agile development is to fix the budget and time and allow the specifications to change. Once the budget and time is exhausted then the current solution becomes the final solution. To enter into such agreements requires significant trust to be established between the client and developer.
• Requirements


  Features, properties, or behaviours a system must have to achieve its purpose. Each requirement must be verifiable.
• Business Systems Analyst


  A person who analyses systems, determines requirements and designs new information systems.
• Requirements Definition


  1. Compiling a list of required outputs

  2. Examining required outputs to determine required inputs

  3. Creating models showing the flow of data through the system from inputs through the various processes to the final outputs

  4. Considering all aspects that can affect the operation of the final system

  5. Studying existing systems to ensure the new system will accomplish all existing requirements

  6. Adding new requirements

  7. Considering all elements of the system including hardware

  8. Consulting potential users to determine their needs and requirements
• Studies have shown that some 30% of software projects are abandoned well into the development cycle. Many of these cancelled projects are well over budget and were not feasible from the outset. Software developers must take steps to carefully define and understand the requirements before moving onto the design and development phases.
• Requirements need to be correctly and accurately defined so that a project can be successful. Requirements are features, properties or behaviors a system must have in order to achieve its purpose. Each requirement must be verifiable.
• Surveys


  Completed by all key personnel to determine requirements
• Business Systems Analyst


  Role in the development of Software
• Personnel with specific skills used when large products are developed using the structured approach

  • System analysts
  • Programmers
  • Software testers
• Client needs


  One of the most important considerations when determining requirements
• Client statements


  • We need to monitor sales across each of our stores
  • We need to improve customer relations
  • We want to improve our turnaround times
• Tools and techniques for accomplishing the analysis

  • Surveys
  • Interviews
  • Time management studies
  • Business analysis
• User stories


  Concise, user-focused description of features or functionality from the user's perspective
• User story template


  As a [role], I want [goal], so that [benefit/value]
• Sprint


  Development iteration in agile development
• Before each sprint, the team selects user stories from the prioritized list to work on
• At the end of each sprint, the team showcases completed user stories to stakeholders for feedback and review
• Once stakeholders are satisfied, the product increment is released, marking the end of a sprint cycle
• Developing a new product without establishing a need for the product is like putting the proverbial cart before the horse
• Mail order business needs

  • Orders must be processed more efficiently
  • Overdue accounts need to be dealt with more effectively
  • Items on backorder should always be filled in before new orders
  • Customers need to feel confident their personal details will remain confidential
  • Personal attention to customers must be maintained
• Boundary


  The delineation between a system and its environment. The boundary defines what is and isn't part of the environment
• Environment


  The circumstances and conditions that surround an information system. Everything that influences or is influenced by the system
• Items in the environment can affect the system, however the system cannot alter its environment
• Requirements


  Business requirements; expressed from the perspective of the business management and staff
• Specifications


  Written for the developers; think technical specifications
• Types of specifications


  • Functional specifications
  • Non-functional specifications
• Functional specifications


  Specifications that transform inputs into outputs
• Non-functional specifications


  Specifications that do not transform inputs into outputs, but are critical to the success of the software project
• Non-functional specifications from the developer's perspective

  • Data types
  • Data structures
  • Algorithms
  • Variables
  • Software design approach
  • Quality assurance
  • System and data models
  • Project management tools
• Non-functional specifications from the user's perspective


  • Interface design
  • Appropriate messages
  • Appropriate icons
  • Relevant data formats for display
  • Ergonomic issues
  • Relevance to the user's environment and computer configuration
  • Documentation
• Communication and feedback from users is especially important at the early stage of gathering user specifications