What is the purpose of software documentation and the different types associated with software development?
Software documentation is written text or illustration that accompanies computer software or is embedded in the source code. It either explains how it operates or how to use it, and may mean different things to people in different roles.
Documentation is an important part of software engineering. Types of documentation include:
Requirements – Statements that identify attributes, capabilities, characteristics, or qualities of a system. This is the foundation for what will be or has been implemented.
Architecture/Design – Overview of software. Includes relations to an environment and construction principles to be used in design of software components.
Technical – Documentation of code, algorithms, interfaces, and APIs.
End user – Manuals for the end-user, system administrators and support staff.
Marketing – How to market the product and analysis of the market demand.
What are the steps in the software development life cycle?
1) Planning
2) Analysis
3) Design
4) Testing & Implementation
5) Maintenance
What occurs in the planning stage of the software development life cycle?
The planning stage involves a preliminary analysis, , propose alternative solutions, describe costs and benefits and submit a preliminary plan with recommendations.
What occurs in the analysis stage of the software development life cycle?
The analysis stage defines project goals into defined functions and operation of the solution. It is the process of gathering and interpreting facts, diagnosing problems and recommending improvements to the system. Analyzes end-user information needs and also removes any inconsistencies and incompleteness in these requirements.
A series of steps followed by the developer are:
- Collection of Facts: End user requirements are obtained through documentation, client interviews, observation and questionnaires,
- Scrutiny of the existing system: Identify pros and cons of the current system in-place, so as to carry forward the pros and avoid the cons in the new system.
- Analyzing the proposed system: Solutions to the shortcomings in step two are found and any specific user proposals are used to prepare the specifications.
What occurs in the design phase of the software development life cycle?
Design is carried out which Describes desired features and operations in detail, including screen layouts, business rules, process diagrams, pseudocode and other documentation.
Development is carried out (coding)
What occurs in the testing and implementation phase of the software development life cycle?
A special testing environment is set up then checks for errors, bugs and interoperability.
Acceptance, installation, deployment: The final stage of initial development, where the software is put into production and runs actual business. Also should include aspects such as training
What happens in the maintenance phase of the software development life cycle?
Maintenance: During the maintenance stage of the SDLC, the system is assessed to ensure it does not become obsolete. This is also where changes are made to initial software. It involves continuous evaluation of the system in terms of its performance.
What are the two main development methodologies?
Agile & Waterfall
How does the waterfall method work?
The waterfall model is one of the oldest methodologies and uses a sequential approach
where development is seen to be moving downwards through phases where the output
from each stage becomes the input for the next.
This method is strict and emphasis is placed on planning, sticking to targets and structured
documentation at the end of the development. Testing is carried out at the end of each
phase. It is an easy to implement method however problems can arise if requirements
change or a problem is brought through to the next phase as there is little room to return to
a previous stage of the development.
How does the Agile method work?
Agile methods are people oriented and allow for effective response to change. Creating a
working system that meets the needs of stakeholder and allows for implementation at different time points. Agile principles focus on delivering working software at regular short intervals and encourage practice that accommodates change at
any stage of the development process. This means that all stakeholders play an important
role in the development process facilitating feedback leading to more satisfactory
outcomes. The principles do not act as a structure for development but more as guidelines
on how to deliver software in an agile manner. Agile lends itself best to small projects of
small close teams. Development is carried out in a series of ‘sprints’ based on the
requirements of the system
What is unified modelling language (UML)?
The Unified Modeling Language (UML) is a general-purpose, developmental, modeling language in the field of software engineering, that is intended to provide a standard way to visualize the design of a system.
What are the two main types of UML views?
Static (or structural) view: emphasizes the static structure of the system using objects, attributes, operations and relationships. It includes class diagrams and composite structure diagrams. Since structure diagrams represent the structure, they are used extensively in documenting the software architecture of software systems. For example, the component diagram describes how a software system is split up into components and shows the dependencies among these components.
Dynamic (or behavioral) view: emphasizes the dynamic behavior of the system by showing collaborations among objects and changes to the internal states of objects. This view includes sequence diagrams, activity diagrams and state machine diagrams. Behavior diagrams emphasize what must happen in the system being modeled. Since behavior diagrams illustrate the behavior of a system, they are used extensively to describe the functionality of software systems. As an example, the activity diagram describes the business and operational step-by-step activities of the components in a system.
What are the main steps in the requirement gathering process?
- Requirements gathering
The developers discuss with the client and end users to know their expectations from the software - Requirement organisation
The developers prioritize and arrange the requirements in order of importance, urgency and convenience. - Negotiation and discussion
If requirements are ambiguous or there are some conflicts in requirements of various stakeholders, if they are, it is then negotiated and discussed with stakeholders. Requirements may then be prioritized and reasonably compromised.
The requirements come from various stakeholders. To remove the ambiguity and conflicts, they are discussed for clarity and correctness. Unrealistic requirements are compromised reasonably. - Documentation
All formal & informal, functional and non-functional requirements are documented and made available for next phase processing.
What are functional and non-functional requirements?
Functional requirements are those which define functions and functionality within and from the software system.
EXAMPLES -
Search option given to user to search from various invoices.
User should be able to mail any report to management.
Non functional requirements are are not related to functional aspect of software. They are implicit or expected characteristics of software, which users make assumption of. Non-functional requirements include - Security Logging Storage Configuration Performance Cost Interoperability Flexibility Disaster recovery Accessibility
What is a use case?
Use Cases are the next step in the design process after requirements gathering. Use cases integrate the requirements into a comprehensive package that describes the interaction of the user with the system
Use Cases are text documents, written in plain English, which describe a scenario in which an “Actor” interacts with the “System”.
What is an ‘actor’?
The actors are not part of the system, but are outside of it. They are the ones interacting WITH the system. The Use Case should describe the interaction between the actor and the system - what the actor does and how the system reacts. Be careful to make sure the Use Case describes only how the system reacts. This is not always a person, it can often be another part of the computer system or hardware.
What is a virtual machine?
In computing, a virtual machine (VM) is an emulation of a computer system. Virtual machines are based on computer architectures and provide functionality of a physical computer. Their implementations may involve specialized hardware, software, or a combination.
There are different kinds of virtual machines, each with different functions:
System virtual machines (also termed full virtualization VMs) provide a substitute for a real machine. They provide functionality needed to execute entire operating systems. A hypervisor uses native execution to share and manage hardware, allowing for multiple environments which are isolated from one another, yet exist on the same physical machine. Modern hypervisors use hardware-assisted virtualization, virtualization-specific hardware, primarily from the host CPUs.
Process virtual machines are designed to execute computer programs in a platform-independent environment.
What is unit testing?
Intuitively, one can view a unit as the smallest testable part of an application. In procedural programming, a unit could be an entire module, but it is more commonly an individual function or procedure. In object-oriented programming, a unit is often an entire interface, such as a class, but could be an individual method. Unit tests are short code fragments created by programmers or occasionally by white box testers during the development process. It forms the basis for component testing.
Ideally, each test case is independent from the others. Substitutes such as method stubs, mock objects, fakes, and test harnesses can be used to assist testing a module in isolation. Unit tests are typically written and run by software developers to ensure that code meets its design and behaves as intended.
Because some classes may have references to other classes, testing a class can frequently spill over into testing another class. A common example of this is classes that depend on a database: in order to test the class, the tester often writes code that interacts with the database. This is a mistake, because a unit test should usually not go outside of its own class boundary, and especially should not cross such process/network boundaries because this can introduce unacceptable performance problems to the unit test-suite. Crossing such unit boundaries turns unit tests into integration tests, and when such test cases fail, it may be unclear which component is causing the failure. Instead, the software developer should create an abstract interface around the database queries, and then implement that interface with their own mock object. By abstracting this necessary attachment from the code (temporarily reducing the net effective coupling), the independent unit can be more thoroughly tested than may have been previously achieved. This results in a higher-quality unit that is also more maintainable.
What are the benefits of unit testing?
1) Find problems early
Unit testing finds problems early in the development cycle. This includes both bugs in the programmer’s implementation and flaws or missing parts of the specification for the unit. The process of writing a thorough set of tests forces the author to think through inputs, outputs, and error conditions, and thus more crisply define the unit’s desired behavior. The cost of finding a bug before coding begins or when the code is first written is considerably lower than the cost of detecting, identifying, and correcting the bug later; bugs may also cause problems for the end-users of the software.
2) Facilitates change Unit testing allows the programmer to refactor code or upgrade system libraries at a later date, and make sure the module still works correctly (e.g., in regression testing). The procedure is to write test cases for all functions and methods so that whenever a change causes a fault, it can be quickly identified. Unit tests detect changes which may break a design contract.
3) Simplifies Integration
Unit testing may reduce uncertainty in the units themselves and can be used in a bottom-up testing style approach. By testing the parts of a program first and then testing the sum of its parts, integration testing becomes much easier
4) Documentation
Unit testing provides a sort of living documentation of the system. Developers looking to learn what functionality is provided by a unit, and how to use it, can look at the unit tests to gain a basic understanding of the unit’s interface
5) Design
When software is developed using a test-driven approach, the combination of writing the unit test to specify the interface plus the refactoring activities performed after the test has passed, may take the place of formal design. Each unit test can be seen as a design element specifying classes, methods, and observable behaviour.
What is the iterative development?
Iterative development is a way of breaking down the software development of a large application into smaller chunks. In iterative development, feature code is designed, developed and tested in repeated cycles. With each iteration, additional features can be designed, developed and tested until there is a fully functional software application ready to be deployed to customers.
e.g. Agile
What features does maintainable software have?
Maintainable software allows you to quickly and easily:
Fix a bug, without introducing a new bug as you do so
Add new features, without introducing bugs as you do so
Improve usability
Increase performance
Make a fix that prevents a bug from occurring in future
Make changes to support new environments, operating systems or tools
Bring new developers on board your project
The maintainability of software depends on a few different factors. In general, it must be easy to understand the software (how it works, what it does, and why it does it the way it does), easy to find what needs to be change, easy to make changes and easy to check that the changes have not introduced any bugs.
What are the benefits to using a version control system?
- A complete long-term change history of every file.
This means every change made by many individuals over the years. Changes include the creation and deletion of files as well as edits to their contents. Different VCS tools differ on how well they handle renaming and moving of files. This history should also include the author, date and written notes on the purpose of each change. Having the complete history enables going back to previous versions to help in root cause analysis for bugs and it is crucial when needing to fix problems in older versions of software. If the software is being actively worked on, almost everything can be considered an “older version” of the software. - Branching and merging.
Having team members work concurrently is a no-brainer, but even individuals working on their own can benefit from the ability to work on independent streams of changes. Creating a “branch” in VCS tools keeps multiple streams of work independent from each other while also providing the facility to merge that work back together, enabling developers to verify that the changes on each branch do not conflict. Many software teams adopt a practice of branching for each feature or perhaps branching for each release, or both. There are many different workflows that teams can choose from when they decide how to make use of branching and merging facilities in VCS. - Traceability.
Being able to trace each change made to the software and connect it to project management and bug tracking software such as Jira, and being able to annotate each change with a message describing the purpose and intent of the change can help not only with root cause analysis and other forensics. Having the annotated history of the code at your fingertips when you are reading the code, trying to understand what it is doing and why it is so designed can enable developers to make correct and harmonious changes that are in accord with the intended long-term design of the system. This can be especially important for working effectively with legacy code and is crucial in enabling developers to estimate future work with any accuracy.
-
Computing5
-
Data12
-
Variant Analysis & Annotation7
-
Service Development16
-
NGS File Formats18
-
NGS16
-
Pathway Analysis & Ontology13
-
Bioinformatics Tools12
-
Software Development22
-
SQL30
-
Command Line32
-
GIT21
-
Good Programming Practice10
-
Databases10
-
OSFA Station Ideas15
-
Bioinformatics Pipelines8
-
SOP Review6
-
NGS Quality19
-
Validation of NGS pipelines9
-
BPG7
