We need to gather specific information when applying the SDLC
For new systems, we need in-depth info on how the system should work, along with the outcomes
For upgrading old systems, we need to assess how the current system works before planning changes
Observation = when we simply look at the existing system and take notes on how it functions
Questionnaires = we can create surveys or questionnaires to give to users of the system to get some real time feedback and information regarding the system
Interview = we can also interview existing users to examine their knowledge of the current system, and also to gather feedback on potential changes or upgrades
Sample Forms = we can create forms to get information from current users, similar to surveys and questionnaires
Sampling Work = also known as studying documentation, we can simply take existing documents and work and write notes based off the information provided
Create free surveys with SurveyMonkey here
Project management is the action of planning, scheduling, budgeting and tracking to achieve goals in a project or problem
Each step is fundamental to ensure that every phase of the project is well thought-out and operational
The main purpose is to plan time, cost and resources for the project or problem
The planning is generally a document that outlines more details about the project, as well as provides a roadmap
Scheduling allows us to plan each step of the project along with the expected time
We often use Gantt Charts and PERT Charts to outline the time taken for each step of the project
Scheduling allows us to work out the critical path for the project timeline
Budgeting helps us to allocate the financial resources of a project
This includes ensuring the budget can accomodate each step of the project without spending more than the project is worth
Tracking allows us to keep up to date with every aspect of the project
It's important to keep an eye on each phase of the project to ensure it's going to plan and there are no problems
Various tracking and collaboration software is available for groups working on projects, such as BaseCamp
Computer-aided Software Engineering tools help to design and implement applications in a project
They're often used to design the logical rather than physical aspects of a project or solution
Gantt Charts and PERT Charts are the most often used CASE tools in Computer Science
A Gantt Chart is a type of bar chart that illustrates a project schedule
Modern day charts show the dependency between activities (e.g. an activity that can't start until another has finished)
Gantt Charts provide an easy way to clearly see when a project phase can start based off the completed phases
A Program Evaluation Review Technique chart is another CASE tool used to help in planning projects
Specifically, they aid towards scheduling, organizing and coordinating tasks within a project
A PERT chart shows the amount of time taken on each phase, and in turn the critical, maximum and minimum pathways
Watch a video on Gantt and PERT Charts here
Check out some project management software here
[Advanced] Check out how to create a clear project plan here
Check out Tom's Planner to create free Gantt Charts online here
Documentation is essential for any information system and / or product
Some documentation helps developers and designers to understand the ins and outs of the system or project, as well as a an integral part of planning
Other documentation is created specifically to help the end-user operate the system
A system context diagram, or context diagram, is a diagram used to show the high-level processes of a system
These processes are shown along with how they interact with external entities
Data is shown as to be "flowing" between the system and external entities, as depicted with arrows
Context diagrams are a step before Level-0 DFDs (data flow diagrams) and use similar symbols
A process is represented with a circle
An external entity is represented with a rectangle
A data store is represented with two parallel lines
A data flow is represented with a straight line and arrow head in the direction of the flow
Context diagrams only show essential general processes without breaking down each step
A data flow diagram is also known as a DFD
It's the next level up from a context diagram, where we look at each process and break it up further in easy-to-read data flows
These data flows are how the system interacts with external entities, as well as databases
The processes are numbered with decimals, meaning the first process will have sub-processes in a DFD numbered as "1.1", "1.2" etc.
Data flow diagrams use the same symbols as a context diagram
Refer to the section "For you to do" below, number 2, for more on DFDs.
Source: http://flylib.com/books/en/2.148.1.49/1/
System manuals can also be referred to as internal documentation
Internal documentation refers to notes and instructions within projects, often seen only by developers
This includes comments within the source codes of a project
System manuals are generally created for developers and people within the project
User manuals can also be referred to as external documentation
External documentation is any form of manual or guide used to instruct the end-user of a system
User manuals are generally created for end-users in order to educate them on how to use the system
Create online diagrams here OR just do sketches by hand.
Learn how to create context diagrams and data flow diagrams here
Learn about Data Flow Diagrams from this Wiki 'Structured Analysis'
The System Development Life Cycle (SDLC) is a process commonly used for planning, creating, testing and deploying an information system
It can apply to software, hardware, or a combination of both
The SDLC is defined by a number of clearly grouped activities, known as phases used to develop a finished project or product
The SDLC gives us a structured, easy to follow approach when developing an information system
Phases allow us to break down each step in the development and allows for less error or discrepancies due to planning
1. Preliminary analysis.= First we define the problem of the system. Once complete we can allocate resources and prioritize tasks.
We often create a feasibility report to test if the project can be done.
It includes technical feasibility, if it is operational, if it is economically sustainable and if it fits within the schedule
This can be remembered with the acronym TOES
2. Analysis = we define the project goals based off the client or end-user's needs.
We work out a model of the current system. We create business rules based on user needs, ER diagram can start here, normalisation to search out redundancy issues.
We find out the requirements of the new system.
3. Design = we design both the physical and logical parts of the system.
The logical design = an abstract design usually by modelling. Entity Relationship Diagrams are a part of this.
The physical design = the technology-specific details from which all programming and system construction can be accomplished.
Students often jump to the physical design of most tasks in schools.
If they took time to make a logical design, the final product would be better and could be made to physical designs by students with variety.
For example a logical design for a system to improve ordering from the canteen will include an ER diagram of the improved lunch order system. The actual physical design would change according to who was making it, based on the logical (planning).
Student A may create a physical design that needed iPads to input name for lunch order. At locations in the canteen and Student B may create a physical design for a system that required a barcode scanning of an ID card. Yet both of these students are looking at a logical ERD that states, collect student name.
4. Development = we gather our resources and build and test the system.
The resources we obtain are the hardware and software that is needed.
The system is created and tested.
5. Implementation = we implement the new system into its environment.
This can be done in many ways, each with their own advantages and disadvantages.
The ways this can be done are as follows:
Direct cut = the old system is replaced fully by the new system.
Pilot = a select group are given access to trial the new system before implementing globally.
Parallel = both systems are run simultaneously until the new one is considered stable and usable.
Phased = parts of the new system are implemented as seen fit until the new system is fully installed.
6. Evaluation & Maintenance
We evaluate the performance of the system to make sure the new system is working and fits the requirements from the pre-analysis and analysis stages.
We conduct fault finding and make corrections.
Differences between logical and physical ERDs here.
In system development, you find different methods of creating a system. These are the different phases of the work involved.
Each methodology has its own advantages and disadvantages, so its important to pick one that suits your intended outcome.
A prototype is an early model or sample that is used to test functions of a product, to be replicated from or to be learned from.
Prototyping is when we use an early build of a product or system to demonstrate how it will function with live results.
Prototyping is effective as we use a real system for testing as opposed to a theoretical one.
Advantages:
It's easy to see what functionality is missing from the demo
It encourages innovation and flexible minds as new ideas can be easily tested
It requires validation to work, hence discrepencies can be easily identified
Disadvantages:
Requirements for the product may change significantly after reach build, creating more work
Identified non-functional elements may be difficult to document from the demo
The client may be unaware or uncertain about what they're looking at or what they want
The System Development Life Cycle (SDLC) is a process commonly used for planning, creating, testing and deploying an information system
It can apply to software, hardware, or a combination of both
The SDLC is defined by a number of clearly grouped activities, known as phases used to develop a finished project or product
The waterfall / cascade model is a sequential design process in which progress is seen flowing down through the stages, like a waterfall.
Each phase must be completed before the next phase can begin, hence being easy and simple to understand
A review is conducted at the end of each phase to make sure the project is being carried out correctly
Advantages:
Very simple and easy to understand
Phases do not overlap, which allows us to prioritize each phase as it happens
Great for smaller projects where the requirements are well understood
Disadvantages:
Once in the testing stage, going back is virtually impossible if it was not thought out in the concept stage
High amounts of risk and uncertainty due to large amounts of planning
Poor model for larger and ongoing projects
Not suitable for projects that are likely to change
Rapid Application Development (or RAD) is sometimes used as a general term used to describe an alternative to the waterfall method
It can also be used to describe a methodology created by James Martin
In this methodology, less emphasis is put on planning and more on development
Components (or functions) are developed simultaneously as if they were mini projects
Each component is given a deadline, after which all components are gathered and made in to a working prototype
The prototype is used to assess the user's feedback regarding requirements and expectations from the project
Advantages:
Significantly reduced development time
Encourages customer feedback
Increases re-usability of components in the system
Disadvantages:
Requires highly skilled designers and developers
High dependency on modelling skills
Depends on a strong team to identify requirements
When would we use RAD?
When we need to have a system built in a short time frame (e.g. 2 - 3 months)
When we have a high availability of designers that are able to design the product, and...
When our budget is high enough to supply numerous designers and tools needed for automated code generation
Check out ITInfo's comparison of development methodologies here
A list of software development models and methods here