Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in our knowledge base article
Do you really want to delete this prezi?
Neither you, nor the coeditors you shared it with will be able to recover it again.
Make your likes visible on Facebook?
You can change this under Settings & Account at any time.
Transcript of Software development
Different software development methodologies exist and are chosen for a project based on the requirements of the customer, the developer and the system itself, also taking into account economic, social and ethical issues. These are some software development methodologies: Software Development Methodologies and Approaches The Structured approach
The Prototyping approach
Rapid Application Development (RAD)
End user approach
Agile development Software development methodologies (SDMs) began to appear in the development of information systems in the 1960s. The idea behind the first software design methodology was "to pursue the development of information system in a very deliberate, structured and methodical way". SDMs today exist for exactly this purpose; to allow a structured and organised way to create information systems. Any or all methodologies or approaches can be used by software developers in a project, depending on the circumstances. Prototyping Approach The prototyping approach is an SDM where software prototypes and iterative development are key. Prototypes are incomplete and unpolished iterations of the project.
The basic principles of the prototyping approach are:
It is not a standalone approach to software development. It is instead used to tackle part of a larger project, often using another methodology.
User is involved in the development.
Prototypes and mockups are developed following an iterative development path until they meet the users requirements.
Prototypes are developed with the expectation that they will be discarded, though it is possible to transition from prototype to a final iteration.
Understanding of the problem is needed to avoid solving the wrong problem.
Prototyping loosely follows a cycle of
Development > Refining > Demonstration
Until a suitable iteration is developed, which is then tested and implemented as the new system. Software Development Methodologies The prototype approach broad and flexible. Prototypes vary from rapidly developed mockups to functional systems. Different types of prototyping can cater to different requirements of the user, the system and the developer. Prototyping is best implemented for systems require large amounts of user-system interaction.
Advantages of prototyping include:
Possible reduction in development time and costs
Increased and improved involvement of users in the development process
Results in a tested solution that meets user requirements
Results in good interfaces due to the user-prototype interaction
Disadvantages of prototyping include:
User confusion; prototype may be interpreted as a near finished version
User or developer attachment to features or prototypes
Possibly excessive concentration of resources and time on prototype
Time for analysis is limited, leads to developer misunderstanding Rapid Application Development Rapid Application Development (RAD) is, as the name suggests, an SDM allowing for rapid development of applications. RAD generally forgoes extensive project planning in favour of rapid prototyping, so changes to the project and requirements are made on-the-fly. It is considered as a more radical approach to programming than traditional SDMs.
RAD has four phases:
Requirements Planning - key issues noted, project analysis and planning. This phase is short, lending itself to rapid development.
User Design - user interaction with models and prototypes representing all parts of the system. Is a continuous process, and allows user to modify the program through feedback.
Construction - programming and development; coding, system testing etc. Is also a continuous process, joined with user design.
Cutover - data conversion, testing, implementation, user training etc. Entire process is compressed in comparison to traditional SDMs, for faster implementation. Rapid Application Development (RAD) main focus is rapid development. It is better suited to smaller projects, or collaborative projects, not larger ones. As prototyping is a main feature of RAD it shares some strengths and weaknesses, and involves extensive user-system interaction.
Advantages of RAD include:
Promotion of a collaborative working space
Good user involvement in development; good interfaces
Disadvantages of RAD include:
User confusion; mockup may be perceived as an almost finished product
Narrow scope; limited time for analysis and planning
Nonviable for large projects; RAD does not include sufficient planning or analysis Implementation Develop Refine Demonstrate Prototyping Testing Cutover User design Construction Requirements Planning End User Approach The end user approach is where the end user of the software is also the developer. As there is no divide between user and developer, the program should easily meet user requirements. Normally the user has little to no programming experience, so the user uses tools within an application to manipulate it and 'program' a solution, and as such are removed from the details of the processes. The user-developer often creates programs where they are the only end user.
The main features of the end user approach are:
The user is also the developer.
Typically packages or other applications are used to develop the project.
The lack of formal stages; unlike other SDMs the structure is loose and the documentation is minimal/non-existent. Structured Approach The structured approach, also known as the waterfall model, is a 'classic' SDM. It is a fairly basic sequential process, and has its roots in manufacture and construction. Due to this it is a very rigid structure as its hardware (machinery) roots were often inflexible and it could have been costly to change requirements.
The main phases of the structured approach are as follows:
Defining and understanding the problem - documentation, analysis and requirements.
Planning, design and construction - documentation coding, prototyping etc.
Implementation - the system is installed and data transferred/created
Testing and evaluation - tests are conducted and performance noted.
Maintenance - system is maintained until a new system is required.
The term 'waterfall model' was coined because the processes were originally depicted as flowing down onto each other. This is somewhat indicative of the structure and the unidirectional nature of the SDM. The structured approach features extensive planning and analysis stages, and documentation. It is not a flexible SDM, and is best used for projects where the requirements are consistent and do not evolve or change rapidly. It is an engineering approach that has been applied to software engineering, and common with the 'Big Design Up Front' approach.
Advantages of the structured approach include:
Good planning and analysis.
Rigid structure; scheduling, control over project and maintenance.
Disadvantages of the structured approach include:
Superseded by many more flexible and versatile SDMs
Can result in a project running over budget/time.
Unidirectional nature can cause project failure; changing requirements is a hassle. Defining and understanding the problem Planning, design and construction Implementation Testing and evaluation Maintenance End user development is very loose in structure and documentation. It is best used for small projects where the developer is also the sole end user. Due to the fact that users often have little to no experience end user development is reliant upon packages and tools.
Advantages of end user development:
User requirements can be met with ease as the user and developer are one
Disadvantages of end user development:
Small scope; normally one developer
Limitations of packages used to develop system
Quality concerns Agile approach The agile approach is a subset of SDMs based on iterative and incremental development. Agile development focuses on evolution of the project through iterative development and separate teams with their own organisation. The term was first coined in the "Agile Manifesto" (2001). It is named as it can adapt to changing circumstances, which in reality is a common occurrence in program development.
The main principles of 'agile' SDMs are:
Small, self organising groups; allows multi-skilled developers to contribute. Promotes equality and a healthy work environment.
Iterative/incremental development (e.g. prototyping, alpha/beta stages); supports changing requirements, user interaction etc.
Working versions of programs are delivered, and the next iteration with new features is released later on.
Planning, analysis and documentation is done within the smaller teams. Each team has a common purpose, and teams may be assigned different tasks. Developed using the 'last minute idiot' methodology Agile development is widely used by companies as it is an effective SDM in the real world; requirements are constantly changing, so a more flexible and 'agile' approach is better. It can be used in most projects, and is effective for large projects as it allows smaller teams to split as equals. A multiplayer game is a good example of where agile is effective as requirements change constantly, incremental development post release is a must, and large development teams are common.
Advantages of agile SDMs:
Supports rapid development; a barebones, working version can be released and features added incrementally.
Promotes a healthy working environment - equality and multi-skilled contribution.
Adapts well to changing situations.
Documentation done on-the-fly.
Good user involvement; users test prototypes, and users test working systems and give feedback (hopefully). Disadvantages of agile SDMs:
Documentation is only done as it is needed; planning is minimal. As teams collaborate, it may cause conflicts.
Up front design may be minimal or insufficient.
Changing specifications may mean changing costs and time management, etc.
Agile development carries far more advantages than disadvantages. Defining and understanding initial problem Testing and evaluation Release working version to users Define and understand new requirements Planning, design and implementation The end product of these processes is the functional software. The functional software should be influenced by design aspects in ergonomics and inclusiveness. Software design needs to influenced by these aspects if it is to be used by a variety of users. Waterfall model RAD Agile Ergonomics and Inclusiveness Ergonomics concerns the relationship between humans (users) and their environment (software environment; the program). Ergonomic issues include injuries due to use, prevention of injuries, equipment placement, interfaces, response times etc.
Prolonged use of software may reveal issues that are not immediately noticed, e.g repetitive strain injury (from typing, clicking and other movements.
Equipment placement and design may be a concern. Software may require extra peripheral devices that need to be positioned correctly. As an example a keyboard cannot be used with ease upside down, and a mouse shaped like a pentagon is not good.
User interfaces are important in ergonomics; a UI that presents a user with the right amount of information, the right amount of options and the correct positioning is key, aesthetics also create a smoother interface. Consistency is a must. It can also help to prevent RSI, eyestrain and related injuries.
Response times can frustrate the user and can make software unusable. An easy real-world example is web page loading times.
Software design can help to prevent injuries such as RSI and eye strain with well thought out and designed UIs, and peripheral use. Proper education in posture and typing methods helps to handle ergonomic issues outside of software design. Inclusiveness concerns taking into account your intended and potential users in the software design process. It is a responsibility of the developer to make sure their software is inclusive. Various factors may include cultural issues, economic issues, social and gender aspects and disabled access.
Software and associated material should be culturally inclusive. An example of culturally inclusive software is software that is multi-lingual, that accepts many international date formats, time formats etc. and any cultural differences, like in naming. Databases could have extra name slots, not restricted to <first>, <last>, <middle>. Many multiplayer games are culturally inclusive, allowing language packages to be installed.
Economical inclusivity concerns the availability, pricing, quality and market standing of software. An example of software that is not economically inclusive is a simple calculator app for $50 dollars, where each key must be unlocked for $1.99. Economically inclusive software should be well priced, to be both a viable business venture and increase availability to markets. $0.99 iPhone apps are a good example of economic inclusivity; though some are not quality.
Gender inclusivity is important in all aspects of work and life. In software this may mean including both males and females in design choices and user testing. Gender inclusivity may also concern transgender options in databases, etc.
Disabled access in programs is important when a user has an impediment that prevents them from using software in one way or another. As an example options for visually impaired people exist in Windows, where there is an option to have the computer read information. Ergonomically designed peripherals may allow people who are missing limbs or digits to use a computer 'normally'.
Social inclusivity is the ability for many denominations to be included. Hi Top down design paradigm Top down design is the paradigm where design starts at the 'top' (the system as a whole) and then is broken down into various parts in more and more detail, until the most basic level. Top down involves understanding of the whole system. Larger systems require more breaking down than smaller systems.
Benefits of top down design, applied to a large project:
Emphasis on planning and understanding.
Modules may be developed separately; the top down view already allows the developer to see how modules will link together.
Fuller understanding of a system can lead to good design.
Modules can be developed simultaneously and are not reliant on other modules for development. Negatives of top down design, applied to a large project:
Delays construction until the design is already sufficiently detailed. Smaller modules require the bigger picture to be constructed.
Planning and design for a larger project is time consuming.
Requirements may change, requiring that the project be redesigned from top down, changing some modules. Work may be lost due to this. Roles in development In software development roles allow developers to concentrate effort and skill into areas of interest or expertise. In a medium scale software project:
The analyst's job is to analyse and research the problem, find requirements, create specifications and identify possible solutions. They do not normally engage in actual software development.
They may plan system flows, interact with designers and programmers, document specifications etc. They interact with the client to document their needs, specifications and the problem itself. They may assist the programmer in understanding user requirements.
The designer's job is to design the system, at a high level. The analyst provides specifications and possible solutions, and the designer creates structured solutions that meet the specifications and requirements. Their aim is to provide a solution that is structured, documented and meets the needs of the clients, developer, etc.
They are very involved in the design of the software, and may be involved with actual coding. They use and create flowcharts, interact with other members of the team and clients. Designers may create mockups of the project UI and structure, and assists programmers and analysts.
The programmer's job is to program (construct) the solution that the designer and the analyst created to meet user and client specifications and requirements. They code the solution so it moves from a design to a usable product. The solution must be coded correctly to ensure it solves the correct problem with minimal/no problems.
They have the necessary skills to make the design into a tangible solution. Outside of coding, they may input into designing the solution; they are the ones building it, after all. The designers and analysts may need to assist the programmers with specifications and requirements.
The clients include the end users and the management.
Clients have requirements and specifications for the project. They are the people who will use or sell the program.
In the development of a medium scale software project, clients should be interacting with the analyst, designer and maybe even programmer to ensure their needs are met. They can provide feedback on models and prototypes to assist development. CASE tools CASE tools (stands for computer aided software engineering) assist in development of software. They handle design aspects and modeling of the system and data. CASE tools also can create data flows and diagrams to show how a program is working.
An example of a CASE tool is Visual-Paradigm UML. This case tool can generate reports, create models with UML, case modeling and code engineering. In a large mutiplayer game development, CASE tools such as this assist in analysis, design and documentation of projects. This saves some manual work from being done, and also allows documentation to be consistent and universal from team to team.