Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
This document will arm students with the basic, ideal, and technically strategic knowledge needed for every IT personnel to acquire precisely for the development processes and cycles of any software. This course was put together by great professors and lecturers who have earned accolades in this field. This was done in 2024/2025 academic sessions and still in use till date.
Typology: Study notes
1 / 214
This page cannot be seen from the preview
Don't miss anything!
COURSE TITLE: Information Technology and Software Devel o p men t
Course Code
Course Title Information Technology and Software Development
Course Developer/Writer Eze, Festus Chux Department of Computer Science Ebonyi State Uni vers ity A b akali ki Course Editor Programme Leader
Course Coordinator
Below are the comprehensive objectives of the course as a whole. By meeting these
objectives, you should have achieved the aims of aims of the course as whole. In addition to
the aims above, this course sets to achieve some objectives. Thus after going through the
course, you should be able to:
Explain the concept of software development life cycle Identify the different software development models Identify the software development processes Explain how to handle software project planning Explain the software development modelling languages Explain the concept and application of Data Flow Diagrams Explain the process of software validation, verification and testing Explain the issues of state transitions and state chart Explain the process of requirement engineering, datamodel and dbms
Working through this Cou rse
To complete this course you are required to read each study unit, read the textbooks and
read other materials which may be provided by the National Open University of Nigeria.
Each unit contains self‐assessment exercises and at certain points in the course you will be
required to submit assignments for assessment purposes. At the end of the course there is
final examination. Below you will find listed all the components of the course, what you
have to do and how you should allocate your time to each unit in order to complete the
course on time and successfully.
This course demands that you spend a lot of time to study. My advice is that you optimise
the opportunity provided by the tutorial sessions where you have the opportunity of
comparing your knowledge with that of your colleagues.
The man components of the course are:
Study U n it
The study units in this course are as follows:
Module 1
Unit 1 Software Development Life Cycle
Unit 2 Software Engineering Process Models
Unit 3 Software Development Processes
Module 2
Unit 1 Universal Modelling Language (UML)
Unit 2 Data Modelling
Unit 3 Database Management System
Module 3
Unit 1 Entity Relationship
Unit 2 Data Flow Diagrams (DFDs)
Unit 3 Extreme Programming (XP)
Unit 4 Requirement Engineering
Module 4
Unit 1 State Charts, State Transition Networks and Finite State Machines
Unit 2 Software Project Planning
Unit 3 Software Validation, Verification and Testing
Note each unit consists of one or two weeks’ work and includes introduction, objectives,
reading materials, exercises, conclusions and summary, Tutor Marked Assignment (TMAs),
references and other resources. The unit directs you to work on these exercises related to
required reading. In general these exercises test you on the materials thereby assisting you
to evaluate your progress and to reinforce your comprehension of the material. Together
with the TMA these exercises will help you in achieving the stated learning objectives of the
individual units and of the course as a whole.
Presentation S ch edul e
Your course materials have important dates for early and timely completion and submission
of your TMAs and attending tutorials. You should remember that you are required to submit
Course Marking S ceme
Assignment Marks Assignments 1 ‐ 4 Four assignments,best three marks of the four count at 10% each – 30% of course marks End of course examination 70% of overall course marks Total 100% of course materials
Facilitators/Tutors and Tu t ori al s
There are 21 hours of tutorials provided in support of this course. You will be notified of the dates, times and venues of these tutorials as well as the name and phone numbers of the facilitator, as soon as you are allocated to a tutorial group.
Your facilitator will mark and comment on your assignments, keep a close watch on your progress and any difficulties you might face and provide assistance to you during the course. You are expected to mail TMA to your facilitator at least two working days before the schedule date. The TMA s will be marked by your tutor returned back to you as soon as possible.
Do not delay to contact your facilitator by telephone or email if you need assistance.
The following might lead to your needing your facilitator’s assistance:
You do not understand any part of the study or assigned reading You have difficulty with the self test You have a question or a problem with an assignment or with the grading of an assignment
Endeavour to attend tutorials. It affords you the opportunity of face to face contact with the facilitator and to ask questions which are answered instantly. You also raise problems encountered in the course of study.
Su mma r y Information Technology and Software Development is a course designed to equip you with what it takes to handle large software project. Further more you learn how to manage software systems in the house. Also you get to understand how you can design your software t o meet the clients needs avoid errors which are very expensive in software development. Furthermore by the time you are through with this course you can function effectively as a system analyst, software developer, software evaluator etc
I wish you the best and believe you will find the material very interesting.
A software user would of a necessity diligently follow five processes to procure a standard software. They are as follows:
i. Acquisition ii. Supply iii. Development iv. Operation v. Maintenance
Because the lifecycle processes cover a very large area a scope was defined. We will explain all the processes briefly but Acquisition and Development more extensively. Each phase within the lifecycle processes can be divided into different activities. This unit explains the different activities for each lifecycle process.
Activity A/ Self Assessment Exercise
1. Explain the implication of ISO 12207 in software development 2. Explain what you mean by software development life cycle 3. Describe the two approaches to software development life cycle
3.2 ACQUISITION
Acquisition covers the activities involved in initiating a project. The acquisition phase can be divided into different activities and deliverables that are completed chronologically.
Initiation: during this activity the following tasks are completed.
i. Define System requirements and obtain approval if applicable; ii. Define the general requirements of the software iii. Evaluate other options such as a purchase of an off-the-shelf product or enhancement of an existing product; iv. If an off-the-shelf product is purchased, the software requirements of this product need to be analyzed. v. Develop an acquisition plan, which can also be used during the acquisition phase vi. Define acceptance criteria. vii. Prepare Request for proposal: during this activity the following tasks are completed: a. Acquisition requirements, like System requirements and technical constraints such as target environment, are defined. b. Contract milestones for reviewing and supplier's progress audits are defined. viii. Prepare Contract: during this activity the following tasks are completed a. Selection procedure for suppliers are developed; b. Suppliers, based on the developed selection procedure, are selected; c. The tailor-made ISO/IEC 12207 standard must be included in the contract; ix. Negotiate changes: Negotiations are held with the selected suppliers; x. Update contract: Contract is updated with the result from the negotiations in the previous activity. xi. Supplier monitoring: during this activity the following tasks are completed a. Activities of the suppliers according to the agreements made are monitored; b. Work together with suppliers to guarantee timely delivery if needed. xii. Acceptance and completion: during this activity the following tasks are completed a. Acceptance tests and procedures are developed; b. Acceptance and testing on the product is conducted; c. Configuration management on the delivered product is conducted;
During the supply phase a project management plan is developed. This plan contains information about the project such as different milestones that need to be reached. This project management plan is needed during the next phase which is the development phase.
During the development phase the software product is designed, created and tested and will result in a software product ready to be sold to the customer. Throughout time many people have developed means of developing a software application. The choice of developing method often depends on the present situation. The development method which is used in many projects is the V-model. Techniques that can be used during the development are UML for designing and TMap for testing. The following are the most important steps of the V- model.
i. Define software requirements: Gather the software requirements, or demands, for the product that is to be created. ii. Create High level design: In this phase, the software development process, the software's overall structure and its nuances are defined. In terms of the client/server technology, the number of tiers needed for the package architecture, the database design, the data structure design etc. are all defined in this phase. A software development model is thus created. iii. Analysis and Design are very crucial in the whole development cycle. Any glitch in the design phase could be very expensive to solve in the later stage of the software development. Much care is taken during this phase. The logical system of the product is developed in this phase. A basic layout of the product is created. This means the setup of different modules and how they communicate with each other. This design does not contain very much detail about the modules. The different modules present in the High level design are designed separately. The modules are designed in as much detail as possible.
3.5 CODING
The code is created according to the high level design and the module design.
The design must be translated into a machine-readable form. The code generation step performs this task. If the design is performed in a detailed manner, code generation can be accomplished without much complication. Programming tools like compilers, interpreters, debuggers etc... are used to generate the code. Different high level programming languages like C, C++, Pascal, Java are used for coding. With respect to the type of application, the right programming language is chosen.
3.6 TESTING
Once the code is generated, the software program testing begins. Different testing methodologies are available to unravel the bugs that were committed during the previous phases. Different testing tools and methodologies are already available. Some companies build their own testing tools that are tailor made for their own development operations.
Activity B/self Assessment Exercise
3.7 Software Development Activities
The activities of the software development process represented in the waterfall model. There are several other models to represent this process.
Software Development Activities from wikipaedia
The important task in creating a software product is extracting the requirements or requirements analysis. Customers typically have an abstract idea of what they want as an end result, but not what software should do. Incomplete, ambiguous, or even contradictory requirements are recognized by skilled and experienced software engineers at this point. Frequently demonstrating live code may help reduce the risk that the requirements are incorrect.
Once the general requirements are gleaned from the client, an analysis of the scope of the development should be determined and clearly stated. This is often called a scope document. Certain functionality may be out of scope of the project as a function of cost or as a result of unclear requirements at the start of development. If the development is done externally, this document can be considered a legal document so that if there are ever disputes, any ambiguity of what was promised to the client can be clarified.
Domain Analysis is often the first step in attempting to design a new piece of software, whether it be an addition to an existing software, a new application, a new subsystem or a whole new system. Assuming that the developers (including the analysts) are not sufficiently knowledgeable in the subject area of the new software, the first task is to investigate the so- called "domain" of the software. The more knowledgeable they are about the domain already, the less work required. Another objective of this work is to make the analysts, who will later try to elicit and gather the requirements from the area experts, speak with them in the domain's own terminology, facilitating a better understanding of what is being said by these experts. If the analyst does not use the proper terminology it is likely that they will not be
taken seriously, thus this phase is an important prelude to extracting and gathering the requirements. If an analyst hasn't done the appropriate work confusion may ensue.
3.7.3 Specification
Specification is the task of precisely describing the software to be written, possibly in a rigorous way. In practice, most successful specifications are written to understand and fine- tune applications that were already well-developed, although safety-critical software systems are often carefully specified prior to application development. Specifications are most important for external interfaces that must remain stable. A good way to determine whether the specifications are sufficiently precise is to have a third party review the documents making sure that the requirements and Use Cases are logically sound.
3.7.4 Architecture
The architecture of a software system or software architecture refers to an abstract representation of that system. Architecture is concerned with making sure the software system will meet the requirements of the product, as well as ensuring that future requirements can be addressed. The architecture step also addresses interfaces between the software system and other software products, as well as the underlying hardware or the host operating system.
Implementation is the part of the process where software engineers actually program the code for the project.
Software testing is an integral and important part of the software development process. This part of the process ensures that bugs are recognized as early as possible.
Documenting the internal design of software for the purpose of future maintenance and enhancement is done throughout development. This may also include the authoring of an API, be it external or internal.
Deployment starts after the code is appropriately tested, is approved for release and sold or otherwise distributed into a production environment.
Software Training and Support is important because a large percentage of software projects fail because the developers fail to realize that it doesn't matter how much time and planning a development team puts into creating software if nobody in an organization ends up using it. People are often resistant to change and avoid venturing into an unfamiliar area, so as a part of the deployment phase, it is very important to have training classes for new clients of your software.
1.0 Introduction
Software systems come and go through a series of passages that account for their inception,
vi. Detailed Component Design Specification : defines the procedural methods through which the data resources within the modules of a component are transformed from required inputs into provided outputs.
vii. Component Implementation and Debugging : codifies the preceding specifications into operational source code implementations and validates their basic operation.
viii. Software Integration and Testing : affirms and sustains the overall integrity of the software system architectural configuration through verifying the consistency and completeness of implemented modules, verifying the resource interfaces and interconnections against their specifications, and validating the performance of the system and subsystems against their requirements.
ix. Documentation Revision and System Delivery : packaging and rationalizing recorded system development descriptions into systematic documents and user guides, all in a form suitable for dissemination and system support.
x. Deployment and Installation : providing directions for installing the delivered software into the local computing environment, configuring operating systems parameters and user access privileges, and running diagnostic test cases to assure the viability of basic system operation.
xi. Training and Us e: providing system users with instructional aids and guidance for understanding the system's capabilities and limits in order to effectively use the system.
xii. Software Maintenance : sustaining the useful operation of a system in its host/target environment by providing requested functional enhancements, repairs, performance improvements, and conversions.
3.1 What is a software life cycle model? A software life cycle model is either a descriptive or prescriptive characterization of how software is or should be developed. A descriptive model describes the history of how a particular software system was developed. Descriptive models may be used as the basis for understanding and improving software development processes, or for building empirically grounded prescriptive models. A prescriptive model prescribes how a new software system should be developed. Prescriptive models are used as guidelines or frameworks to organize and structure how software development activities should be performed, and in what order. Typically, it is easier and more common to articulate a prescriptive life cycle model for how software systems should be developed. This is possible since most such models are intuitive or well reasoned. This means that many idiosyncratic details that describe how a software system is built in practice can be ignored, generalized, or deferred for later consideration. This, of course, should raise concern for the relative validity and robustness of such life cycle models when developing different kinds of application systems, in different kinds of development settings, using different programming languages, with differentially skilled staff, etc. However, prescriptive models are also used to package the development tasks and
techniques for using a given set of software engineering tools or environment during a development project.
Descriptive life cycle models, on the other hand, characterize how particular software systems are actually developed in specific settings. As such, they are less common and more difficult to articulate for an obvious reason: one must observe or collect data throughout the life cycle of a software system, a period of elapsed time often measured in years. Also, descriptive models are specific to the systems observed and only generalizable through systematic comparative analysis. Therefore, this suggests the prescriptive software life cycle models will dominate attention until a sufficient base of observational data is available to articulate empirically grounded descriptive life cycle models. These two characterizations suggest that there are a variety of purposes for articulating software life cycle models. These characterizations serve as a
i. Guideline to organize, plan, staff, budget, schedule and manage software project work over organizational time, space, and computing environments. ii. Prescriptive outline for what documents to produce for delivery to client. iii. Basis for determining what software engineering tools and methodologies will be most appropriate to support different life cycle activities. iv. Framework for analyzing or estimating patterns of resource allocation and consumption during the software life cycle v. Basis for conducting empirical studies to determine what affects software productivity, cost, and overall quality.
3.2 What is a software process model? In contrast to software life cycle models, software process models often represent a networked sequence of activities, objects, transformations, and events that embody strategies for accomplishing software evolution. Such models can be used to develop more precise and formalized descriptions of software life cycle activities. Their power emerges from their utilization of a sufficiently rich notation, syntax, or semantics, often suitable for computational processing. Software process networks can be viewed as representing multiple interconnected task chains Task chains represent a non-linear sequence of actions that structure and transform available computational objects (resources) into intermediate or finished products. Non-linearity implies that the sequence of actions may be non-deterministic, iterative, accommodate multiple/parallel alternatives, as well as partially ordered to account for incremental progress. Task actions in turn can be viewed a non-linear sequences of primitive actions which denote atomic units of computing work, such as a user's selection of a command or menu entry using a mouse or keyboard. These units of cooperative work between people and computers are referred to as structured discourses of work, while task chains have become popularized under the name of workflow.
