Software requirements

The software requirements are description of features and functionalities of the target system. Requirements convey the expectations of users from the software product. The requirements can be obvious or hidden, known or unknown, expected or unexpected from client’s point of view (Tutorialspoint).

For assessing user requirements, an SRS (Software Requirement Specification) document is created whereas for coding and implementation, there is a need of more specific and detailed requirements in software terms. The output of this process can directly be used into implementation in programming languages (Behera).

References:
Tutorialspoint.(n.d.). Software Requirements. Retrieved from: https://www.tutorialspoint.com/software_engineering/software_requirements.htm.
Behera, H.S. (n.d.). Lecture Notes on Software Engineering. Retrieved from: http://www.vssut.ac.in/lecture_notes/lecture1422914635.pdf.
Borlandvideo. (21 May 2009). Requirements Definition: Bringing Software Requirements to Life. Retrieved from: https://www.youtube.com/watch?v=fHjc3cJ6m00.

Testing: a critical phase in SD.

Software testing is a phase of the Software Development Life Cycle that focuses on executing a program and finding bugs. The process should validate and verify that the program meets the functional and non-functional requirements gathered in the first stage of the process.
During testing, the developers should find out if the program meets the technical and business needs that should have guided the design and coding phases. The program should work the way it was expected to and should be able to be implemented in the next stage.

Testing can be done as a process rather that a unique activity. It should take place during the whole software life cycle in small steps, to prevent defects in the code and to verify that the design is being implemented correctly.

Testing must be planned so reports and progress can be documented and the status of a program can be defined and updated. Preparations must be made by selecting conditions and designing test cases.

Static testing can be done without executing the code and it is used to verify the source code and static analysis.

Dynamic testing is done when the code is executed so results can be demonstrated. It is done during validation, some examples are unit testing, integration testing and system testing.

Uploaded by Guru99

Evaluations must be done during the testing phase to check that the needed criteria was met and whether the software passes the needed tests and can now be launched.

Software testing is a necessary part of software development because everyone makes mistakes (we are human after all) and they should be corrected because they may lead to unnecessary risks and expensive corrections. It is good to have someone else check these mistakes because they are more likely to spot these mistakes than the original

Continue reading →

Why use Design Patterns

Design patterns are a great solution to common problems during software design . These patterns aren’t a finished design that can be directly transformed into code but a sort of template one can use to solve a problem that can be applied and customized to specific situations.

Design Patterns help speed up the development process because they provide tested development paradigms, they provide solutions for issues that are not always visible at the beginning of the development process, sometimes these issues are only visible when the projects are implemented, this makes patterns a great way to avoid certain risks during and after the Software Development Life Cycle.

Patterns are based on iteration, so code can be reused to improve readability and understandability of the program in general, to avoid problems by providing general solutions that are documented.

There are three main design pattern types:

-Creational Design Patterns
These are mostly about instantiation and the creation of classes and objects by using inheritance and delegation effectively & efficiently.

Here are some examples:
• Abstract Factory
• Builder
• Factory Method
• Object Pool
• Prototype
• Singleton

-Structural Design Patterns
These patterns are about pattern composition and structure so functional interfaces can be composed.

Here are some examples:
• Adapter
• Bridge
• Composite
• Decorator
• Façade
• Flyweight
• Private Class Data
• Proxy

-Behavioral Design Patterns
These are patterns centered on object communication between objects.
• Chain of Responsibility
• Command
• Interpreter
• Iterator
• Mediator
• Memento
• Null Object
• Observer
• State
• Strategy
• Template Method
• Visitor

Sources:

Design Patterns

Designing our surroundings

Software Design focuses on the way internal modules or components of a system interact with each other so it is not the same thing as Software Architecture. This the “how” phase of the Software Development Life Cycle.

This process transforms the user requirements into a developer friendly understandable and specific format that the programmer(s) can later code and implement.
An SRS (Software Requirement Specification) document should be created to assess user requirements, and the design phase finds a solution to the problems planted during the requirement gathering phase.

Charis Tsevis - Calling... — Charis Tsevis –
Calling…
A mozaic with Apple products since 1998. (Best viewed large)
All photos courtesy by Apple
Made in Synthetik Studio Artist, Adobe Photoshop and Apple QuickTime Pro with custom scripts.

There are several design levels to be considered:

-Architectural Design: highest level of abstraction or a general blueprint.
-High-Level Design: a less abstracted view that focuses on how the components of a system can be implemented in modules.
-Detailed Design: Detailed designs of systems and subsystems that defines a logical structure for each module and the communication interfaces.

Some keys for good software design are:
-Modularization: Often used as a technique to divide a software system into many small segments called modules that should carry out independent tasks.
-Concurrency: Changing sequential execution into concurrent means splitting the software into independent modules that can be executed in parallel.
-Coupling: a measure for defining the level of inter-dependability between modules, for example: content, common, control, stamp and data.
-Cohesion: A measure for defining the intra-dependability of the elements of a module, for example: co-incidental, logical, temporal, procedural, etc.

Sources:

Difference between Software Architecture and Software Design

Software Design Basics

Software Architecture

Software architecture (not to be confused with architecture design) is mostly the externally visible components of a system.

In this phase of the Software Development Life Cycle the main concern is “what” a system should do while software Design is about “how” a system achieves its goals.
Architecture is a higher level of abstraction and it scopes all of the system, not just the modules like in the design.

Architecture is the blueprint for building the design, it aids in understanding how a certain system must behave, it must meet the technical and operational requirements. The structural elements and interfaces of the system are selected to compose the project and they are separated into modules that must later be designed.

Architecture is important because all software must have solid foundations. Common problems or failures must be detected so long term consequences can be avoided.

There are some key things to consider when building a systems architecture:

-User Empowerment
-Market Maturity
-Flexible Design
-Future Trends

Here is a video to understand the difference between software design and architecture:

Uploaded by Software Architect CA

Some software architecture styles are:

-Structure (component-based, layered)
-Shared Memory (data-centric, rule-based)
-Messaging (event-driven, asynchronous messaging)
-Adaptive Systems (plug-ins, Microkernel, reflection)
-Distributed Systems (2-tier, 3-tier, n-tier, peer2peer)

Sources:

Difference between Software Architecture and Software Design

What is Software Architecture?

UML Developers finally understanding each other.

The Unified Modeling Language or UML for short is a standard graphical notation that is made up of sets of diagrams that illustrate what the software architecture of a certain system looks like, it is easy to read so any developer can take a look at it and have a basic understanding of the project.

The design and structure of the system is modeled with UML, it can be applied to any kind of application, independently of the platform used to build it, it is a tool that helps manage large and complex systems because it brings a clearly visible structure to the architecture and design.

Ola Løvholm - DMSP UML — Ola Løvholm –
DMSP UML

UML’s main purpose it to have a stable and common design language so applications can be build and analyzed by other developers, it is a sort of blueprint to software design and architecture.

One uf the main features is the use-case diagram:
It helps development teams visalize what the functional requirements of a system are and how they are related to each other.

Sources:

The Unified Modeling Language (UML)

An introduction to the Unified Modeling Language

Essentials of Elicitation & Specification

The first step of the Software Development Lifecycle is Functional & non Functional Requirement Gathering , it is the result from the specification of the informal ideas a client has about a product. The goals of this phase are to define the needed software and hardware. It is a really important phase because failures at this stage may increase the cost of development in higher stages to ensure the customer needs.

gerard.rendell - Elicitation — gerard.rendell –
Elicitation

There are two factors to consider:

Initial Input: The idea of how a system will be created considering the needs of the client and defining a problem to be solved.

Desired Output: The requirements must be as specific as possible so the problem that needs to be solved can be completely understood.

Requirements Elicitation is mainly understanding and analyzing all of the requirements a client has for a system. Developers & engineers work closely with clients to understand the problems that need to be solved and what functionality a system should have and what hardware is optimal.

The problem is that clients usually do not have a clear idea of what they want or need and if there are many stakeholders, they will most surely have conflicting ideas. The conditions need to be met for the client to be able to solve a specific problem or achieve a certain objective and it must satisfy specific contracts, standards and specifications.

Requirements Elicitation – basic customer idea and definition.

Requirements Specification – Basic developer design and technical specifications.

Requirement analysis normaly uses one of two models: Dynamic model or Object Model. These specifications use formal (exact mathematical syntax or semanic syntax) or semi-formal notation (like UML).

In general this is a phase of understanding the stated problem that the client has and how it should be Continue reading "Essentials of Elicitation & Specification" →

The Software Development Process

Software Development Processes are the basic models that give us a rough guideline on how to organize all of the work involving the creation of a software product.

All of the methodologies are based on the Software Development Life Cycle.

Paul Downey Development process — Paul Downey
Development process

Here are some of the main approaches:

WATERFALL ( read a bit more… )
A linear model that follows a sequential flow, work is split into many phases and development happens first in one phase, gets completed and then moves to the next phase, the phases don’t overlap.

This was the first approach invented, it is very straight forward and easy to understand. This process works best for projects that do not change requirements in late stages of development because it is very hard to make changes and implement new features after early stages.

PROTOTYPING
This model focuses on creating protoypes for the client so he/she gets a better idea of how the requirements they gave are being implemented. This is a good model for testing and reduces the misunderstanding gap between developer and client.

Some types of prototyping methodologies are:
-Throwaway Prototyping
-Evolutionary Prototyping
-Incremental Prototyping

Although it is better for user involvement it can also lead to confusion over the protoypes and the final product.

SPIRAL
This method involves combining design and prototyping. This model is used mostly for expensive and complex projects, these project is composed mostly of small waterfall models, the phases go in the same order, and then prototypes are built and simulated.

This model is good for budget estimating and issue discovery at early stages of development, but it also involves a lot of time and high costs and has quite limited re-usability.

AGILE or EXTREME PROGRAMMING (read a bit more… )

OTHERS

-Lightweight Methodologies
-Rapid Application Development
-Code Continue reading "The Software Development Process" →

APIs, the new way of life.

APIs or Application Programming Interfaces are the core of our daily lives. We use these interfaces every day for most of the things we do, but… what are they?

APIs basically allow applications to communicate with other applications.

Every time we visit a website or application we leave a digital footprint on them that helps them evolve based on our experience. With the innovation of all digital things, websitesd and applications have evolved to being generated through development software and software as a service platforms.

Data Bases have allowed websites to become applications and have encouraged people to create their own content instead of just viewing it. Site content is now stored on many different databases, some you may own and some you may not and some may be public sources and some may be private.

There are a vast variety of widgets that can be implemented in our phones, computers or other devices to make our lives easier, we rely on them for practically everything.

urces:
http://101.apievangelist.com/

Waterfall Method Basics

The Waterfall Model was the first Software Development Process ever created. It is a linear model of the life cycle development model and uses no iterations, this makes it very easy to understand and use. This method requires every phase to be complete before being able to move to the next phase, there can be no overlapping. The success of this model relies on very good planning and documentation.
This model is kind of the opposite of the Agile Model.
The phases:

1. Requirement Gathering & Analysis: Ask the client what their needs and expectations are.
2. System Design: Requirements for the System and Hardware specification to define overall architecture.
3. Implementation: Program is developed in small units and tested (Unit Testing).
4. Integration and Testing: All units are put together and tested for faults and failures.
5. Deployment: After functional and non functional testing, the product is delivered.
6. Maintenance: Regular updates and issue resolving.

This model is called the waterfall method because the each phase cascades into the next one and there is no overlapping.
Advantages: Easy to understand and manage because of how specific each phase is. It allows a lot of control and departmentalization, scheduling and deadlines because of its strict order.
Disadvantages: It allows for very little revision and correction, it is very hard to go back to a previous stage after it has been completed. If documentation is not good it is very hard to maintain the product. This method has high amounts of risk and uncertainty and does not allow for flexible requirements.

Here is a little video on Agile vs Waterfall for better understanding.

Sources:

http://www.tutorialspoint.com/sdlc/sdlc_waterfall_model.htm