software process phases in details
- phases to promote manageability & organization distribution of effort of the development phases is 40% is spent on analysis & design, 20% on coding & auditing the code, 40% on testing & correcting errors. As you can see, testing the software is the most expensive phase due
to the evaluation of the software qualities & the corrections made on the code. Now for large project, it’s better to increase the effort in analysis & design to be able to detect errors early in the process. In this way, we don’t increase the effort in testing in the process. - documents produced
At the end of each phase,
we produce a bunch of document. This product enable effective review to make sure that all the decisions of the previous phase are still met. This product are the input for the next phase. e.g., the Requirement specification document
is the input for the software design phase. We have four types of documents produced in the life cycle.
Specifications, programs, test cases in formal documentation specifications can be semi formal, - stakeholders involved
We have four types, the customer, the developer, the user, the manager.
The customer is an individual or an organization that’s wants a software to be developed to solve specific problem.
& the customer is interested in low budget & short time delivery.
The developer is an organization developing the software. e.g., the system analyst, the software architect, the programmer, the user interface designer, & so on. The user is the person
operating & using the software. The user is interested on the software,
qualities such as time,
efficiency, combustness, correctness. The manager is the person managing
the whole software process
to ensure that the deadline & the budget. Now let’s talk about the manager role. A manager is involved
in all the phases of the project, so that he can track
the progress In each phase.
A manager should be able to respond to unforeseen problems. e.g., a member leaving the project. He should be able to manage risk examples,
changing requirements,
& role in the requirements. The manager is the intermediary between the client & the developers & also between the developers, where he should be able to resolve conflict & miscommunication.
Software Feasibility study in details
Software Feasibility study is
the first phase of the process which is actually part of software management.
Before starting the software development,
we ask ourselves two questions. The first one, is it worth it? Which means we need to determine whether the problem is worth solving. The second question is, is it feasible?
Which means assess whether there is at least one solution to the problem. We have three types of feasibility study,
economic, technical, & personnel. We conduct the economic feasibility
to evaluate the worth
& the value of the software. This feasibility study consists of three main tasks. First, we estimate the total cost
of developing the software.
Second, we determine the real benefit of the software,
either for the market or for the company. Third, to make a decision about going forward or not with a project, we weigh the development cost against the benefit. Now we have two possible scenarios.
If the cost is reasonable,
there are many benefits of the software, then definitely we develop the software system. However, if the cost is high & there are only few benefits, then we don’t go further with the project. Feasibility study should be differentiated between
the type of the software.
Now, if we are developing a customized software,
we need first, in this phase,
to clarify the requirement of the customer. & then assess in detail the real value of the software for the company. Now if we are developing a general product, then we perform an analysis of the market to
determine the real usability of the product. Now if the software is worth it, then we examine is technical & personal feasibility.
Technical feasibility study is to assess if there is at least one solution to the problem. The solution is defined in terms of algorithms, data structures, theories, data programming languages,
software tools, & so on.
Next, we conduct the personal feasibility study.
Do higher expert to the project expert in the application domain, in databases, in the software architecture, in design patterns, in user interface design, in different type of programming languages, & so on. At the end of the feasibility study phase,
we produce the following document. A general problem requirement,
the project cost for each solution, including its benefit & the size of the code, the project planning & delivery date for each solution. Then we select one solution that we follow when developing the software.
Analysis phase in details
The requirement analysis specification phase
has three tasks,
requirement elicitation,
requirement specification,
and requirement validation.
In the requirements elicitation & analysis,
we determine exactly the problem requirement.
This task requires a lot of
interactions and
brainstorming with the customer. They are, e.g., interviews & questionnaires. The second task is the requirement specification, & today we have a large number of specification languages.
e.g., use cases
and scenarios, entity relationship, formal methods, data flow diagrams, FSM Petronet, & so on. The last task is requirement validation,
which means an extensive
review to make sure that
the customer is satisfied
with the problem requirements. We have two types of requirement,
the functional & non functional requirements.
The functional requirement
describe the function and
the services offered by the software to the external environment. Functional requirements represent those external interactions
with the end users, which means the user input & system output non functional requirements
represent the software qualities.12 qualities such as portability, accuracy, time efficiency, user friendliness, security, safety, scalability, robustness, maintainability, & so on.
Produced documents in analysis
We have three documents that are produced at the end of the analysis phase.
The Requirement Specification document,
the first draft of the user manual, & the first draft of the system test plan.
The requirement specification Document
contains a list of
functional & quality requirements. Now each requirement should be precise, which means it has only one interpretation.
The requirements list should be complete.
That means all the customer requirements
have been analyzed & specified. The requirements should be
consistent to each other.
That means there are
no contradictions between a requirement. The requirement specification
document represents
the contract between
the customer & the developer. At this phase, since we have a good idea on how the users interact with the software, we can start building the user manual document. Lastly, the system test Plan
consists of a set of test cases that will be used in
the testing phase to
assess the software qualities. Here the system test Plan, we have to make sure that the program
satisfies all the functional
and quality requirements to make sure that we develop the right
system requirement specification document
represents the new problem statement,
including the functional quality requirements.
In this slide, I’ll just give you here an example of a requirement specification document. This document includes the functional requirements representing the external behavior of the software. included three examples of
qualities, robustness, security, performance.
In the robustness, we need to show how the system
should behave in the presence of incorrect user inputs. Security, who has access to what? Regarding the performance, we
specify the time constraints in this document. We also include resources such as software tools & hardware devices that we need to purchase & expert that we need to hire.
We can also indica table of data, the software process, as well as the environment where the software will be deployed.
Software design
build a high quality solution
to the problem that we
define in the analysis phase. we create
a model which is an abstraction of the real world application. Modeling is a mean to represent complex systems by
providing simplified representation & ignoring irrelevant details.
A model is usually semiformal, which means based on graphics. The software design is
divided into two sub phases. Top level or architectural design, low level or detailed design.
In the top level, we develop the software architecture representing the overall organization of the software by identifying the component, which means the subsystems or sub problems, & how the component communicate
with each other & with the external environment.
This interaction represent
the component interface.
Now in the low level design,
we refine each component into subcomponents T we reach the module. Module is a component for which we can provide the solution in terms of algorithms & data structures. The software architecture is
crucial for the success
of the software development bc we are taking important decisions regarding the organization of the software. We have several benefits of the software architecture. The first one is that the software is
understood via its architecture. That’s why the software architecture
is distributed to all the stakeholders. Software architecture allows to
split the work among developers. This way we can speed the development process bc the components are designed & solved in parallel with the software architecture,
we can manage the complexity by decomposition. Thanks to the decomposition, the software is easy to modify & test. The Computing Society, I, Triple E, gave the following definition.
Software architecture is
the fundamental organization of a system embedded in its components, the relationships to each other,
and the environment, and
the principles governing its design & evolution. two design principles to
build a maintainable software. Low Cohesion & High Cohesion. We have several well defined & widely used architecture styles that we must follow while building the architecture of any application. We can split these styles into two types,
standard & distributed architectures. Among the standard styles, we have pipes & filters, Object oriented architecture,
shared repository layer architecture, & the MVC or model view controller style. We have also more
advanced architecture styles. Regarding the second type, we take any standard architecture & deploy it on a two tier or system configuration.
The two tier style means the client server topology.
In 372, we will study
the layer & the object oriented architecture styles. With the layer style,
we use layers to organize
the application in order
to control the system complexity.
3 level architecture
three types of layers.
Presentation layer, business logic layer, data access layer.
The presentation layer is also called front end layer, User Interface Display. It handles the user interactions with the systems in terms of user input & system output. Via this layer, the user can access the services offered by the software. With this layer, we display the result into a formal & understandable by the end users.
The business logic layer is also called server back end or application layer. So each job is first to process the user interface comments,
make decisions, perform calculations & coordinate the application. Bc the business logic layer is the intermediate between the presentation layer & data layer.
Finally, the data access layer, which is also called data back end, Its job is to query, e.g., a database & store data, of course, any types of data. As you can see, each layer has only one responsibility.
Presentation layer for
the interaction with the users.
Business logic layer for processing data layer for handling data. We say that these layers are
strongly cohesive bc each layer has one rule only in the L layer style, we have one rule of interaction between layers. Each layer provides a service to the layer above it & submit a request to the layer below. Which means a layer can interact only with the layer above it & the layer below it. This means each layer has a maximum of two interactions. We call this low cap plan. Any architectural style was
developed using the two principles of strong cohesion & low caplan.
Strong cohesion means a component has one responsibility only. Low caplin means we have
very few interactions between component. In class, we will discuss in
detail how with the layer architecture we can achieve very important qualities
such as maintainability,
security, productivity, & AZ deployment. For the easy deployment, the three layer architecture can be easily deployed on a three tier configuration where
the user interplay face is
displayed on the client’s computer. The business logic layer is deployed on application server, & the data layer is deployed on a database server. Network protocols & operating systems were designed with the layer architecture.
By following that strict rule
of interaction in the class, I will provide you with a 3 layer architecture of the vending machine at the end of the software design phase.
Software implementation
The next phase is to implement the solution,
which means the design technique document. Using several programming languages, software environments, & tools,
we have seen that the design phase is a top down approach, but the coding phase is a bottom up approach. Which means in the coding phase we first implement the modules,
the algorithms & data structures. Then we implement the interactions between the modules with respect to the low level & high level design. Now, when implementing
a three layer architecture,
we use different languages for each layer. e.g., for the presentation layer,
we can use HTML, js. For the business logic layer,
we can use the .net
Platform or the Java Enterprise Edition for the data access layer, e.g., Maria database
or the file servers. At the end of this phase, we produce three main documents. The programs, the refined user manual,
& the refined system test plan.
Software testing phase
In the software testing phase, we need to make sure that we solve the problem, which means we need to verify all the functional & quality requirements as specified in the requirement specification document. testing is the process of running the program with
the intention of finding errors. It can only prove the presence of errors, but not their absence. The goal of the testing phase is to gain sufficient confidence in the software. In this phase, we test each quality. e.g., we test the correctness, which is basically the functional requirement & other qualities. e.g., robustness & time efficiency. We test the qualities using the test cases defined in the system test plan. Now, coding & testing are usually done in parallel. This makes sense, especially in software engineering as we are
dealing with large software system. Every time we implement a module, we test the module right away.
If we are implementing the
interaction among the module, we test these interactions. As you can see, testing is also a bottom up approach. This phase, we evaluate the program
against its requirement
specification document.
We have four types of testing. Unit testing, integration testing, system testing, acceptance testing.
In the unit testing, we evaluate each module separately. In the integration testing, we evaluate the interaction
among the modules in the system testing. Here we evaluate the whole system.
In the accepted testing, the testing is done by customer & end users to make sure that the customer is satisfied with the software.
When testing a module or a component, we can do it in two ways, black & white box testing. Regarding the black box testing, we evaluate the input output behavior, which means we have to make sure that the outputs are correct with respect to the user inputs.
In the white box testing, we evaluate the internal
behavior of the software.
We need to test each statement, each loop, each condition, & each path at least once. Another kind of testing is the manual testing, which is very time consuming. Now, testing has to be repeated after every change or correction made on the program.
We call this regression testing. For every change, redo the testing, bc a change in one part of the software might affect other part as it may introduce new errors.
software maintenance
Software maintenance
means any modification made to the software after delivery & requirement on the customer’s environment. Today, maintenance is a necessity
bc real world is always changing, we have a change in the requirement of the problem, change in the environment where the software resides in the project development change. Change is an intrinsic property of the software, but it is difficult to incorporate. Many errors are not removed until after software delivery. This is a serious problem bc the letter the errors are found, the more expensive it is to eliminate them. Removing errors during maintenance instead of during analysis. That means in the early phase of software development is 200 times more expensive. e.g., correcting errors in the requirement is expensive bc you need to respecify, redesign, reimplement, & retest the 40 requirements.
Maintenance cost is more than 60% of the total cost.
We have four types of software maintenance.
Corrective maintenance means fixing errors found in the programs, like errors found by the end users.
Adaptive maintenance means adapting the application according to
the changes in the environment. Changes in the software & hardware part. e.g., adapt the application to the new database management system or to the upgraded hardware devices. Perfective maintenance means adding new requirements or
improving existing requirements, both functional & quality requirements. Preventive maintenance is updating the documentation. For exam, technical & user documentation.
