Pearson BTEC Level 4 Higher Nationals Certificate in
Pearson BTEC Level 4 Higher Nationals Certificate in Computing (RQF) Unit 9 – Software Development Lifecycles
Learning Outcomes By the end of this unit students will be able to: LO 1 LO 2 LO 3 LO 4 • Describe different software development lifecycles. • Explain the importance of a feasibility study. • Undertake a software development lifecycle. • Discuss the suitability of software behavioural design techniques.
LO 3 – Undertake a software development lifecycle Essential Content § Carry out software development lifecycle: o Identify requirements: stakeholders; requirements identification; requirements specification e. g. scope, inputs, outputs, processes and process descriptors; consideration of alternate solutions and security considerations; quality assurance required. o Constraints: specific to activity e. g. costs, organisational policies, legacy systems, hardware requirements.
LO 3 – Undertake a software development lifecycle Essential Content o Report documentation: structure e. g. background information, problem statements, data collection process and summary, recommendations, appendices. o Systems analysis terminology and tools: data stores and entities; data flows; process representation techniques relationships – 1: 1, 1: Many (1: M) and Many: Many (M: M). o Investigation: e. g. upgrading computer systems, designing new systems.
LO 3 – Undertake a software development lifecycle Essential Content o Techniques: examples relevant to methodology chosen e. g. Context Diagrams, Data Flow Diagrams (DFDs), Entity Relationship Diagrams (ERDs); Business Systems Options (BSOs); Technical Systems Options (TSOs); quality considerations e. g. Total Quality Management (TQM).
Identify requirements § Stakeholders o Each of these groups of people has its own requirements, interests, and needs to be met by the software system. o We refer collectively to these people as stakeholders. o Understanding the role of the stakeholder is fundamental to understanding the role of the architect in the development of a software product or system.
Identify requirements § Requirements identification o This phase is critical to the success of the project. o Expectations (whether of a client or your team) need to be fleshed out in great detail and documented. o This is an iterative process with much communication taking place between stakeholders, end users and the project team.
Identify requirements § Requirements specification o Scope • provides a framework for the project and guides the requirements collection process. • is usually the first source of information about the project available to all stakeholders before the project gets under way. o Inputs • It is important to design appropriate data input methods to prevent errors while entering data.
Identify requirements § Requirements specification o Outputs • The design of output is the most important task of any system. • During output design, developers identify the type of outputs needed, and consider the necessary output controls and prototype report layouts.
Identify requirements § Requirements specification o Processes and process descriptors • Process framing defines the process boundaries, the major activities, the actors, key metrics, the case for action, and the vision for the future process. – The process framing can then be used to draft key business requirements for the new system. • Process descriptor - A set of information that defines the status of resources allocated to a process. – When a system contains a number of processes, any of which may be active at any one time, there will be for each process a descriptor defining the status of that process.
Identify requirements § Consideration of alternate solutions and security considerations: o It is important that multiple alternatives be considered. Potential solutions (decision alternatives) should be adequately described to make them understandable to everyone involved in the development. o All of these business processes and information require some level of security processing. One type of security is required to protect the client, another to protect the corporation.
Identify requirements § Quality assurance: o Software quality assurance is the process of evaluating how well software meets the needs of the end customer. o QA revolves around three pillars: reliability, efficiency, and flexibility. In order for software to be useful, it needs to work consistently, complete tasks quickly, and be useful in a variety of situations. o Furthermore, good software also needs internal quality controls, making sure the underlying code is clean and practical.
Constraints § Constraints: specific to activity e. g. o Costs • the process of isolating and estimating costs and benefits – system costs – benefits from the system o Organisational policies • Whether the proposed system is consistent with the organization’s strategic objectives?
Report documentation § Background information o About the client business/organization and current IT system § Problem statements o Problem definition: On receiving a request from the user for systems development, an investigation is conducted to state the problem to be solved. § Data collection process and summary o process of gathering and measuring information • Quantitative Data. These are data that deal with quantities, values or numbers, making them measurable. • Qualitative Data. These data, on the other hand, deals with quality, so that they are descriptive rather than numerical in nature
Report documentation § Recommendations o E. g. features to be implemented in the new system § Appendices o An appendix contains supplementary material that is not an essential part of the text itself but which may be helpful in providing a more comprehensive understanding of the project
Report documentation § Recommendations o E. g. features to be implemented in the new system § Appendices o An appendix contains supplementary material that is not an essential part of the text itself but which may be helpful in providing a more comprehensive understanding of the project
Systems analysis terminology and tools § Data stores and entities o A data store is a place where data is stored and retrieved within the system. § Data flows o Data-flows are used to model the flow of information into the system, out of the system, and between elements within the system.
Systems analysis terminology and tools § Process representation techniques relationships – 1: 1, 1: Many (1: M) and Many: Many (M: M). o One-to-one (1: 1) • This is where one occurrence of an entity relates to only one occurrence in another entity. • For example, an employee is allocated a company car, which can only be driven by that employee. • Therefore, there is a one-to-one relationship between employee and company car.
Systems analysis terminology and tools o One-to-Many (1: M) • Is where one occurrence in an entity relates to many occurrences in another entity. • For example, taking the employee and department entities shown on the previous page, an employee works in one department but a department has many employees. • Therefore, there is a one-to-many relationship between department and employee.
Systems analysis terminology and tools o Many-to-Many (M: N) • This is where many occurrences in an entity relate to many occurrences in another entity. • For example, an employee may work on several projects at the same time and a project has a team of many employees. • Therefore, there is a many-to-many relationship between employee and project.
Systems analysis terminology and tools o Relationship cardinality
Investigation § E. g. upgrading computer systems vs. designing new systems. o To choose the option that is best, first weigh the costs, benefits and risks associated with each type of change. o So what are some reasons to implement new systems? • Many legacy system are coded in languages that are no longer widely in use, meaning that there aren’t many personnel qualified to work with them. • And in some cases, the companies that created the software in the first place no longer support it.
Investigation o If you choose to completely overhaul your current legacy system, you can use new technology to improve user experience and decrease costs over time. But as mentioned above, implementing a new system all at once can be costly. o In some cases, new systems can mean new bugs as well. o When companies choose to update their current systems rather than begin a full-scale overhaul, they gain access to potential benefits more quickly. • making changes to old systems is to add on to what currently exists.
Techniques - DFD § Context Diagrams, Data Flow Diagrams (DFDs) o A data flow diagram (DFD) illustrates how data is processed by a system in terms of inputs and outputs. o A context diagram is a top level (also known as "Level 0") data flow diagram. • It only contains one process node ("Process 0") that generalizes the function of the entire system in relationship to external entities.
Techniques - DFD § Two common systems of DFD symbols are named after their creators:
Techniques - DFD § Rules: o Naming conventions: • Processes: strong verbs • Data flows: nouns • Data stores: nouns • Entities: nouns o No more than 7 - 9 processes in each DFD. o Data flows must begin, end, or both begin & end with a process.
Techniques - DFD § Rules: o Leveling Conventions: • Numbering: The system under study in the context diagram is given number `0'. • The processes in the top level DFD are labeled consecutively by natural numbers beginning with 1. • When a process is exploded in a lower level DFD, the processes in such lower level DFD are consecutively numbered following the label of such parent process ending with a period or full-stop (for example 1. 2, 1. 2. 3, etc. ).
Techniques - DFD § Rules: o Balancing: • The set of DFDs pertaining to a system must be balanced in the sense that corresponding to each dataflow beginning or ending at a process there should be an identical dataflow in the exploded DFD.
DFD § Context Diagrams, Data Flow Diagrams (DFDs) o DFDs exist in a hierarchy, beginning with the simplest, highest, system level and ending with the lower level diagrams with detailed processes. o The DFD at the system level illustrates the context, that is, the circumstances of its environment and is called the context diagram. o This diagram contains only a single, unnumbered process bubble in the shape of a circle to represent the entire system.
DFD – Context Diagram § The context diagram Latinitas “system” with a single process bubble in the middle. Its five entities are represented by squares. The system is connected to its entities by arrows that represent data flows.
DFD – Level 1
DFD – Level 2
ERD § Entity Relationship Diagrams (ERDs) § An ERD is a means of visualizing how the information a system produces is related. There are five main components of an ERD: o Entities, which are represented by rectangles. An entity is an object or concept about which you want to store information.
ERD o Actions/Relationship, which are represented by diamond shapes, show two entities share information in the database. o In some cases, entities can be self-linked. For example, employees can supervise other employees.
ERD o Attributes, which are represented by ovals. A key attribute is the unique, distinguishing characteristic of the entity. For example, an employee's social security number might be the employee's key attribute.
ERD o Connecting lines, solid lines that connect attributes to show the relationships of entities in the diagram. o Cardinality specifies how many instances of an entity relate to one instance of another entity. o Ordinality is also closely linked to cardinality. While cardinality specifies the occurrences of a relationship, ordinality describes the relationship as either mandatory or optional. o In other words, cardinality specifies the maximum number of relationships and ordinality specifies the absolute minimum number of relationships.
ERD Employ Handle
BSO § Business Systems Options (BSOs) o A BSO defines the functional scope of a proposed solution. o At its most basic level it consists of textual descriptions of those requirements satisfied by the solution. o All BSOs must satisfy the minimum requirement as identified by user representatives. o Business Systems Options are developed during Feasibility Study and Requirements Analysis.
TSO § Technical Systems Options (TSOs) o A TSO defines a possible technical environment for the implementation of the system. o It will include descriptions of hardware and software, technical support arrangements, distribution of the system and development tools
TQM § Quality considerations e. g. Total Quality Management (TQM). o TQM is a management approach aimed at satisfying all the customer requirements, needs and expectations using a continuous improvement approach o There are three aspects of software quality: • functional quality, • structural quality • process quality
TQM § However, the quality of software is estimated by many of its attributes such as reliability, integrity, maintainability, enhance ability (extensibility), usability, portability, and reusability § The functionality of the software and the appearance of the user interface could also affect software quality. § Consequently, these characteristics can affect user satisfaction so it could be used as a measure of software quality.
TQM o Functional quality means that the software performs the tasks it is intended to do for its users correctly. Software testing commonly focuses on functional quality. o The second aspect of software quality, structural quality, means the code itself is well structured. Unlike functional quality, structural quality is hard to test for. o The third aspect, process quality, it is the quality of the development process significantly affects the value received by users, development teams, and sponsors, and all three groups have a stake in improving software quality.
References § https: //www. viewpoints-and-perspectives. info/home/stakeholders/ § https: //airbrake. io/blog/sdlc/what-is-the-software-development-life-cycle § https: //www. mitre. org/publications/systems-engineering-guide/selifecycle-building-blocks/requirements-engineering/eliciting-collecting-and -developing-requirements § https: //www. tutorialspoint. com/system_analysis_and_design/system_ana lysis_and_design_input_output_forms. htm § https: //www. computereconomics. com/article. cfm? id=2157 § https: //www. encyclopedia. com/computing/dictionaries-thesaurusespictures-and-press-releases/process-descriptor § https: //www. intertech. com/Blog/software-quality-assurance/ § https: //www. cleverism. com/qualitative-and-quantitative-data-collectionmethods/
References § https: //www. sqa. org. uk/elearning/Soft. Dev. RDS 02 CD/page_45. htm#One. One § https: //www. glowtouch. com/blog/application-development/legacysystems-replace-update-or-add-on/ § https: //www. sqa. org. uk/e-learning/SDM 03 CD/page_09. htm § https: //www. smartdraw. com/entity-relationship-diagram/ § http: //www. computing. dcu. ie/~renaat/ca 214/wvr/Introduction. ppt § https: //charadetua. files. wordpress. com/2013/10/5_2 -1. ppt § https: //pdfs. semanticscholar. org/fab 9/5 c 15 bea 8 b 3 b 237 ad 4 dfdc 40 d 7 eeb 8 2 e 2 f 76 f. pdf
- Slides: 44