Gate Degree & PG College

SOFTWARE ENGINEERING
Syllabus

UNIT-1
Introduction to Software Engineering:

The term software engineering is the product of two words, software, and engineering.
The software is a collection of integrated programs.
Software subsists of carefully-organized instructions and code written by developers on any
of various particular computer languages.
Computer programs and related documentation such as requirements, design models and user
manuals.
Engineering is the application of scientific and practical knowledge to invent, design,
build, maintain, and improve frameworks, processes, etc.

Software Engineering is required:

Software Engineering is required due to the following reasons:
o To manage Large software
o For more Scalability
o Cost Management
o To manage the dynamic nature of software
o For better quality Management
Need of Software Engineering:
The necessity of software engineering appears because of a higher rate of progress in user
requirements and the environment on which the program is working.
o Huge Programming: It is simpler to manufacture a wall than to a house or building,
similarly, as the measure of programming become extensive engineering has to step to give
it a scientific process.
o Adaptability: If the software procedure were not based on scientific and engineering ideas,
it would be simpler to re-create new software than to scale an existing one.
o Cost: As the hardware industry has demonstrated its skills and huge manufacturing has let
down the cost of computer and electronic hardware. But the cost of programming remains
high if the proper process is not adapted.
o Dynamic Nature: The continually growing and adapting nature of programming hugely
depends upon the environment in which the client works. If the quality of the software is
continually changing, new upgrades need to be done in the existing one.
o Quality Management: Better procedure of software development provides a better and
quality software product.
Characteristics of a good software engineer:
The features that good software engineers should possess are as follows:
Exposure to systematic methods, i.e., familiarity with software engineering principles.
Good technical knowledge of the project range (Domain knowledge).
Good programming abilities.
Good communication skills. These skills comprise of oral, written, and interpersonal skills.
High motivation.
Sound knowledge of fundamentals of computer science.
Intelligence.
Ability to work in a team
 Importance of Software Engineering:

The importance of Software engineering is as follows:

1. Reduces complexity: Big software is always complicated and challenging to progress.
Software engineering has a great solution to reduce the complication of any project. Software
engineering divides big problems into various small issues. And then start solving each small
issue one by one. All these small problems are solved independently to each other.
2. To minimize software cost: Software needs a lot of hardwork and software engineers are
highly paid experts. A lot of manpower is required to develop software with a large number
of codes. But in software engineering, programmers project everything and decrease all those
things that are not needed. In turn, the cost for software productions becomes less as
compared to any software that does not use software engineering method.
3. To decrease time: Anything that is not made according to the project always wastes time.
And if you are making great software, then you may need to run many codes to get the
definitive running code. This is a very time-consuming procedure, and if it is not well
handled, then this can take a lot of time. So if you are making your software according to the
software engineering method, then it will decrease a lot of time.
4. Handling big projects: Big projects are not done in a couple of days, and they need lots of
patience, planning, and management. And to invest six and seven months of any company, it
requires heaps of planning, direction, testing, and maintenance. No one can say that he has
 given four months of a company to the task, and the project is still in its first stage. Because
the company has provided many resources to the plan and it should be completed. So to
handle a big project without any problem, the company has to go for a software engineering
method.
5. Reliable software: Software should be secure, means if you have delivered the software,
then it should work for at least its given time or subscription. And if any bugs come in the
software, the company is responsible for solving all these bugs. Because in software
engineering, testing and maintenance are given, so there is no worry of its reliability.
6. Effectiveness: Effectiveness comes if anything has made according to the standards.
Software standards are the big target of companies to make it more effective. So Software
becomes more effective in the act with the help of software engineering

size factors of Software Engineering:

In software engineering, size factors play a crucial role in project estimation, planning, and
management. These factors help determine the scope, complexity, and effort required to
complete a software project. Here are some key size factors:
1. Lines of Code (LOC):
o Measures the total number of lines in the source code.
o Often used for productivity and quality metrics.
2. Function Points (FP):
o Measures the functionality provided to the user based on inputs, outputs, user interactions,
files, and external interfaces.
o Helps in comparing different software projects.
3. Use Case Points (UCP):
o Based on the number and complexity of use cases in the system.
o Considers actors and use case scenarios to estimate effort.
4. Object Points (OP):
o Measures the number of objects or classes in object-oriented design.
o Factors in object complexity and their interactions.
5. Feature Points:
o An extension of function points, taking into account additional factors like algorithm
complexity.
6. Story Points:
o Used in Agile methodologies.
o Measures the effort required to implement a user story based on complexity, risks, and
uncertainties.
7. Effort (Person-Months):
o Measures the amount of work required in terms of person-months or person-hours.
o Derived from other size factors to plan resources.
8. Software Size Metrics:
o Kilo Line of Code (KLOC): Thousands of lines of code.
o Effective Lines of Code (eLOC): Lines of code excluding comments and blank lines.
9. Complexity Metrics:
o Cyclomatic Complexity: Measures the number of linearly independent paths through a
program’s source code.
o Halstead Complexity Measures: Based on the number of operators and operands in the
code.
10. Work Breakdown Structure (WBS):
o Divides the project into smaller, manageable sections or tasks.
o Each section’s size can be estimated to sum up to the total project size.
These size factors are often used in conjunction with estimation models such as COCOMO
(Constructive Cost Model), which uses size factors to predict the effort, cost, and duration of
a software project.

Quality and productivity Factors:

Quality and productivity are two critical aspects of software engineering that significantly
influence the success of a project. Here are some important factors that affect quality and
productivity in software engineering:
Quality Factors
1. Reliability:
o The ability of the software to perform its required functions under stated conditions for a
specified period.
o Metrics: Mean Time Between Failures (MTBF), Mean Time to Repair (MTTR).
2. Maintainability:
o The ease with which the software can be modified to correct faults, improve performance, or
adapt to a changed environment.
o Metrics: Change request frequency, defect density, code complexity.
3. Usability:
o The degree to which the software can be used by specified users to achieve specified goals
with effectiveness, efficiency, and satisfaction.
o Metrics: User satisfaction surveys, task completion time, error rates.
4. Efficiency:
o The capability of the software to provide appropriate performance relative to the amount of
resources used.
o Metrics: Response time, throughput, resource utilization.
5. Portability:
o The ease with which the software can be transferred from one environment to another.
o Metrics: Number of environments supported, effort required for porting.
6. Security:
o The software's ability to protect information and data so that unauthorized persons or systems
cannot read or modify them and authorized persons or systems are not denied access.
o Metrics: Number of security incidents, time to detect and respond to security threats.
7. Functionality:
o The degree to which the software performs its intended functions.
o Metrics: Compliance with requirements, number of features implemented.
8. Interoperability:
o The ability of the software to interact with other systems or software.
o Metrics: Number of supported integrations, ease of integration.
Productivity Factors
1. Development Process:
o The methodologies and practices used during software development.
o Metrics: Development time, defect rates, adherence to schedule.
2. Team Skills and Experience:
o The knowledge, experience, and skills of the development team.
o Metrics: Team experience levels, training hours, developer productivity.
3. Tools and Technologies:
o The effectiveness of development tools, programming languages, and frameworks used.
o Metrics: Tool usage frequency, defect rates, development speed.
4. Project Management:
o The practices related to planning, tracking, and managing software projects.
o Metrics: Schedule adherence, budget adherence, project success rates.
5. Communication:
o The effectiveness of communication within the development team and with stakeholders.
o Metrics: Frequency of meetings, communication clarity, feedback loop efficiency.
6. Requirements Management:
o The process of eliciting, documenting, and managing software requirements.
o Metrics: Requirements stability, requirements clarity, changes in requirements.
7. Code Quality:
o The overall quality of the source code, including readability, maintainability, and complexity.
o Metrics: Code reviews, static code analysis results, refactoring frequency.
8. Testing and Quality Assurance:
o The processes and practices used to ensure software quality through testing and validation.
o Metrics: Test coverage, defect detection rate, defect resolution time.
9. Automation:
o The extent to which development and testing processes are automated.
o Metrics: Build frequency, deployment frequency, automated test coverage.
10. Work Environment:
o The physical and psychological conditions under which the development team works.
o Metrics: Team morale, turnover rates, work-life balance.
Balancing these quality and productivity factors is crucial for delivering high-quality
software within time and budget constraints. Effective management practices, continuous
improvement, and adopting the right tools and methodologies can significantly enhance both
quality and productivity in software engineering.
 Managerial issues in software engineering:
Managerial issues in software engineering encompass a wide range of challenges that
managers face while planning, executing, and controlling software projects. Addressing these
issues effectively is crucial for the successful delivery of software products. Here are some
of the key managerial issues:
1. Project Planning and Scheduling:
• Estimating Project Size and Effort: Accurately estimating the size and effort required for a
project can be challenging, leading to over- or under-estimation.
• Resource Allocation: Ensuring that the right resources (e.g., developers, testers) are available
and efficiently utilized throughout the project lifecycle.
• Scheduling: Creating realistic timelines and milestones, and adapting to changes in scope or
unexpected delays.
2. Risk Management:
• Identifying Risks: Recognizing potential risks early in the project, such as technical
challenges, resource shortages, or changes in requirements.
• Mitigating Risks: Developing strategies to minimize the impact of identified risks and
preparing contingency plans.
3. Scope Management:
• Scope Creep: Managing changes to the project scope to prevent uncontrolled growth and
ensure that new requirements are properly evaluated and integrated.
• Requirements Management: Ensuring that requirements are well-defined, documented, and
agreed upon by all stakeholders.
4. Quality Management:
• Quality Assurance: Implementing processes to ensure that the software meets defined quality
standards and is free of defects.
• Testing: Planning and executing comprehensive testing strategies to identify and fix issues
before deployment.
5. Team Management:
• Team Dynamics: Managing diverse teams, addressing conflicts, and fostering a collaborative
and productive work environment.
• Skill Development: Ensuring that team members have the necessary skills and providing
training or mentoring as needed.
• Motivation and Retention: Keeping the team motivated and engaged, and addressing factors
that contribute to employee turnover.
6. Communication and Collaboration:
• Stakeholder Communication: Ensuring clear and consistent communication with all
stakeholders, including clients, team members, and management.
• Collaboration Tools: Utilizing effective tools and practices to facilitate collaboration and
information sharing among team members.
7. Budget Management:
• Cost Estimation: Accurately estimating project costs and creating realistic budgets.
• Budget Control: Monitoring expenditures and ensuring that the project stays within budget.
8. Process Management:
• Adopting
Methodologies: Choosing and implementing the appropriate software development
methodologies (e.g., Agile, Waterfall) that fit the project needs.
• ProcessImprovement: Continuously evaluating and improving development processes to
enhance efficiency and quality.
9. Technology Management:
• Tool
Selection: Choosing the right tools and technologies that align with project requirements
and team capabilities.
• Keeping Up with Trends: Staying updated with the latest industry trends and advancements
to ensure that the project benefits from modern practices and technologies.
10.Change Management:
*Handling Changes: Managing changes in project scope, technology, team composition, and
other factors effectively.
*Adaptability: Ensuring that the team and processes are flexible enough to adapt to changes
without significant disruption.

11. Performance Monitoring:

*Tracking Progress: Regularly monitoring project progress against planned milestones and
performance metrics.
*Performance Metrics: Using key performance indicators (KPIs) to assess productivity,
quality, and other critical aspects.
12. Client and User Involvement:
*Requirements Gathering: Engaging clients and users in the requirements-gathering process
to ensure that the final product meets their needs.
*Feedback: Soliciting and incorporating feedback from clients and users throughout the
project lifecycle.
13. Compliance and Legal Issues:
*Regulatory Compliance: Ensuring that the software complies with relevant regulations and
standards.
*Intellectual Property: Managing intellectual property rights and ensuring that the software
does not infringe on third-party rights.
Effectively managing these issues requires a combination of strong leadership, effective
communication, and the ability to adapt to changing circumstances. By addressing these
managerial challenges, software engineering managers can increase the likelihood of
delivering successful projects on time and within budget.

Planning a Software Project:

The objective of software project planning is to provide a framework that enables the
manager to make reasonable estimates of resources, cost, and schedule. These estimates are
made within a limited time frame at the
beginning of a software project. Also they should be updated regularly as the project
progresses. The planning objective is achieved through a process of information discovery
that leads to reasonable estimates.
Software Scope:
The first activity in software project planning is the determination of software scope.
Software scope describes function, performance, constraints, interfaces, and reliability.
Functions are evaluated and in some cases refined to provide more detail prior to the
beginning of estimation. Both cost and schedule estimates are functionally oriented and
hence some degree of decomposition is often useful. Performance considerations encompass
processing and response time requirements. Constraints identify limits placed on the software
by external hardware, available memory, or other existing systems. To define scope, it is
necessary to obtain the relevant information and hence get the communication process started
between the customer and the developer. To accomplish this, a preliminary meeting or
interview is to be conducted. The analyst may start by asking context free questions. That is,
a set of questions that will lead to a basic understanding of the problem, the people who want
a solution, the nature of the solution that is desired, and the effectiveness of the first encounter
itself. The next set of questions enable the analyst to gain a better understanding of the
problem and the customer to voice his or her perceptions about a solution. The final set of
questions, known as Meta questions, focus on the effectiveness of the meeting. A team-
oriented approach, such as the Facilitated Application Specification Techniques (FAST),
helps to establish the scope of a project.
Resources :
The development resources needed are:
1. Development Environment (Hardware/Software Tools)
2. Reusable Software Components
3. Human Resources (People)
Each resource is specified with four characteristics – description of the resource, a statement
of availability, chronological time that the resource will be required, and duration of time that
the resource will be applied. The last two characteristics can be viewed as a time window.
Availability of the resource for a specified window must be established at the earliest
practical time.
Human Resources:
Both organizational positions (e.g. Manager, senior software engineer, etc.) and specialty
(e.g. Telecommunications, database, etc.) are specified. The number of people required varies
for every software project and it can be determined only after an estimate of development
effort is made.
Reusable Software Resources:
These are the software building blocks that can reduce development costs and speed up the
product delivery. The four software resource categories that should be considered as planning
proceeds are:
1.Off-the-shelf components –
Existing software that can be acquired from a third-party or that has been developed
internally for past project. These are ready for use and have been fully validated. Generally,
the cost for acquisition and integration of such components will be less than the cost to
develop equivalent software.
2. Full-experience components :
Existing specifications, designs, code, or test data developed for past projects that are similar
to the current project. Members of the current software team have had full experience in the
application area represented by these components. Therefore modifications will be relatively
low risk.
3. Partial-experience components:
Existing specifications, designs, code, or test data developed for past projects that are related
to the current project, but will require substantial modification. Members of the current
software team have only limited experience in the application area represented by these
components. Therefore modifications will have a fair degree of low risk and hence their use
for the current project must be analyzed in detail.
4. New components:
Software components that must be built by the software team specifically for the needs of
the current project.
Environmental Resources:
The environment that supports the software project, often called Software Engineering
Environment (SEE), incorporates hardware and software. Hardware provides a platform
that supports the tools required to produce the work products. A project planner must
prescribe the time window required for hardware and software and verify that these resources
will be available.
The phases of a software project :
Software projects are divided into individual phases. These phases collectively and their
chronological sequence are termed the software life cycle (see Fig. 2.2).
 Software life cycle: a time span in which a software product is developed and used, extending

to its retirement.
The cyclical nature of the model expresses the fact that the phases can be carried out
repeatedly in the development of a software product.
Requirements analysis and planning phase
Goal:

➢ Determining and documenting:

❖ Which steps need to be carried out,
❖ The nature of their mutual effects,
❖ Which parts are to be automated, and
❖ Which recourses are available for the realization of the project.
Important activities:
➢ Completing the requirements analysis,
➢ Delimiting the problem domain,
➢ Roughly sketching the components of the target system,
➢ Making an initial estimate of the scope and the economic feasibility of
the planned project, and
➢ Creating a rough project schedule.
Products:
➢ User requirements,
➢ Project contract, and
➢ Rough project
schedule. System
specification phase
Goal:
➢ a contract between the client and the software producer (precisely
specifies what the target software system must do and the premises for its
realization.)
Important activities:
➢ Specifying the system,
➢ Compiling the requirements definition,
➢ Establishing an exact project schedule,
➢ Validating the system specification, and
➢ Justifying the economic feasibility of the project.
Products:
➢ Requirements definition, and
➢ Exact project

schedule. System and

components design Goal:
➢ Determining which system components will cover which requirements in
the system specification, and
➢ How these system components will work together.
Important activities:
➢ Designing system architecture,
➢ Designing the underlying logical data model,
➢ Designing the algorithmic structure of the system components, and
➢ Validating the system architecture and the algorithms to realize the
individual system components.
Products:
➢ Description of the logical data model,
➢ Description of the system architecture,
➢ Description of the algorithmic structure of the system components, and
➢ Documentation of the design decisions.

Implementation and component test

Goal:
➢ Transforming the products of the design phase into a form that is
executable on a computer.
Important activities:
➢ Refining the algorithms for the individual components,
➢ Transferring the algorithms into a programming language (coding),
➢ Translating the logical data model into a physical one,
➢ Compiling and checking the syntactical correctness of the algorithm, and
➢ Testing, and syntactically and semantically correcting erroneous
system components.
Products:
➢ Program code of the system components,
➢ Logs of the component tests, and
➢ Physical data model.

System test
Goal:
➢ Testing the mutual effects of system components under conditions close
to reality,
➢ Detecting as many errors as possible in the software system, and
➢ Assuring that the system implementation fulfills the system specification.

Operation and maintenance

Task of software maintenance:
➢ Correcting errors that are detected during actual operation, and
➢ Carrying out system modifications and extensions.
This is normally the longest phase of the software
life cycle. Two important additional aspects:
➢ Documentation, and
➢ Quality assurance.
 During the development phases the documentation should enable
communication among the persons involved in the development;
upon completion of the development phases it supports the
utilization and maintenance of the software product.
Quality assurance encompasses analytical, design and
organizational measures for quality planning and for fulfilling quality
criteria such as correctness, reliability, user friendliness,
maintainability, efficiency and portability.
DEFINING THE PROBLEM:
Most software projects are undertaken to provide solution to
business needs. In the beginning of a software project the business
needs are often expressed informally as part of a meeting or a casual
conversation. In a more formal approach, a customer could send
Request For Information (RFI) to organizations to know their area of
expertise and domain specifications. The customer puts up a Request
For Proposal (RFP) stating the business needs. Organizations will to
provide their services will send proposals and one of the proposals is
accepted by the customer.

DEVELOPING A SOLUTION STRATEGY:

The business needs have to be understood and the role of
software in providing the solution has to be identified. Software
development requires a model to be used to drive it and tract it to
completion. The model will provide an effective roadmap for the
software team.
PLANNING THE DEVELOPMENT PROCESS:

Planning the software development process involves several

important considerations. The first consideration is to define a
product life-cycle model. A software project goes through various
phases before it is ready to be used for practical purposes. For every
project, a framework must be used to define the flow of activities such
as define, develop, test, deliver, operate, and maintain a software
product. There are many well define models that can be use. There
could be variations to these models also, depending on the
deliverables and milestones for the project. A model has to be
selected and finalized to start a project.
The following section discusses the various models such as:
a. Waterfall Model
b. Prototype Model

c. Spiral Model
d .Object-oriented life-cycle mode
Waterfall Model:

The Waterfall Model was the first Process Model to be introduced. It is also referred to as a
linear- sequential life cycle model or classic model. It is very simple to understand and use.
In a waterfall model, each phase must be completed before the next phase can begin and there
is no overlapping in the phases.
The Waterfall model is the earliest SDLC approach that was used for software development.

The waterfall Model illustrates the software development process in a linear sequential flow.
This means that any phase in the development process begins only if the previous phase is
complete. In this waterfall model, the phases do not overlap.
Waterfall approach was first SDLC Model to be used widely in Software Engineering to ensure
success of the project. In "The Waterfall" approach, the whole process of software
development is divided into separate phases. In this Waterfall model, typically, the outcome
of one phase acts as the input for the next phase sequentially.
The following illustration is a representation of the different phases of the Waterfall Model.

The sequential phases in Waterfall model are −

• Requirement Gathering and analysis − All possible requirements of the system to

be developed are captured in this phase and documented in a requirement
specification document.
• System Design − The requirement specifications from first phase are studied in this
phase and the system design is prepared. This system design helps in specifying
hardware and system requirements and helps in defining the overall system
architecture.
• Implementation − With inputs from the system design, the system is first developed
 in small programs called units, which are integrated in the next phase. Each unit is
developed and tested for its functionality, which is referred to as Unit Testing.
• Integration and Testing − All the units developed in the implementation phase are
integrated into a system after testing of each unit. Post integration the entire system
is tested for any faults and failures.
• Deployment of system − Once the functional and non-functional testing is done; the
product is deployed in the customer environment or released into the market.
• Maintenance − There are some issues which come up in the client environment. To
fix those issues, patches are released. Also to enhance the product some better
versions are released. Maintenance is done to deliver these changes in the customer
environment.
All these phases are cascaded to each other in which progress is seen as flowing steadily
downwards (like a waterfall) through the phases. The next phase is started only after the
defined set of goals areachieved for previous phase and it is signed off, so the name "Waterfall
Model". In this model, phasesdo not overlap.
Advantages:

Some of the major advantages of the Waterfall Model are as follows −

• Simple and easy to understand and use
• Phases are processed and completed one at a time.
• Works well for smaller projects where requirements are very well understood.
• It is disciplined in approach.
Disadvantages:

• No working software is produced until late during the life cycle.

• High amounts of risk and uncertainty.
• Not a good model for complex and object-oriented projects.
• Poor model for long and ongoing projects.
• Not suitable for the projects where requirements are at a moderate to high risk
of changing.So, risk and uncertainty is high with this process model.

Spiral Model:

The spiral model, initially proposed by Boehm, it is the combination of waterfall and iterative
model,Using the spiral model, the software is developed in a series of incremental releases.
Each phase in spiral model begins with planning phase and ends with evaluation phase.
The spiral model has four phases. A software project repeatedly passes through these
phases initerations called Spirals.

Planning phase:
This phase starts with gathering the business requirements in the baseline spiral. In the
subsequent spirals as the product matures, identification of system requirements, subsystem
requirements and unit requirements are all done in this phase.
This phase also includes understanding the system requirements by continuous
communication between the customer and the system analyst. At the end of the spiral, the
product is deployed in theidentified market.

Risk Analysis:
Risk Analysis includes identifying, estimating and monitoring the technical feasibility and
management risks, such as schedule slippage and cost overrun. After testing the build, at the
end of first iteration, the customer evaluates the software and provides feedback.

Engineering or construct phase:

The Construct phase refers to production of the actual software product at every spiral. In the
baseline spiral, when the product is just thought of and the design is being developed a POC
(Proof ofConcept) is developed in this phase to get customer feedback.
 Evaluation Phase:
This phase allows the customer to evaluate the output of the project to update before the
project continues to the next spiral.
Software project repeatedly passes through all these four phases.

Advantages:

• Flexible model
• Project monitoring is very easy and effective
• Risk management
• Easy and frequent feedback from users.
Dis advantages:

• It doesn’t work for smaller projects

• Risk analysis require specific expertise.
• It is costly model & complex.
• Project success is highly dependent on risk.
Prototype Model:

To overcome the disadvantages of waterfall model, this model is implemented with a special
factorcalled prototype. It is also known as revaluation model.

Step 1: Requirements gathering and analysis

A prototyping model starts with requirement analysis. In this phase, the requirements of the
systemare defined in detail. During the process, the users of the system are interviewed to
know what is their expectation from the system.

Step 2: Quick design

The second phase is a preliminary design or a quick design. In this stage, a simple design of
the system is created. However, it is not a complete design. It gives a brief idea of the system
to the user.The quick design helps in developing the prototype.

Step 3: Build a Prototype

In this phase, an actual prototype is designed based on the information gathered from quick
design.It is a small working model of the required system.
 Step 4: Initial user evaluation

In this stage, the proposed system is presented to the client for an initial evaluation. It helps
to findout the strength and weakness of the working model. Comment and suggestion are
collected fromthe customer and provided to the developer.

Step 5: Refining prototype

If the user is not happy with the current prototype, you need to refine the prototype according
to theuser's feedback and suggestions.

This phase will not over until all the requirements specified by the user are met. Once the user
issatisfied with the developed prototype, a final system is developed based on the approved
final prototype.

Step 6: Implement Product and Maintain

Once the final system is developed based on the final prototype, it is thoroughly tested and
deployedto production. The system undergoes routine maintenance for minimizing
downtime and prevent large-scale failures.

Advantages:

• Users are actively involved in development. Therefore, errors can be detected in the
initial stage of the software development process.
• Missing functionality can be identified, which helps to reduce the risk of failure as
Prototyping is also considered as a risk reduction activity.
• Helps team member to communicate effectively
• Customer satisfaction exists because the customer can feel the product at a very early
stage.
 Disadvantages:

• Prototyping is a slow and time taking process.

• The cost of developing a prototype is a total waste as the prototype is
ultimately thrown away.
• Prototyping may encourage excessive change requests.
• After seeing an early prototype model, the customers may think that the actual
product will be delivered to him soon.
• The client may lose interest in the final product when he or she is not happy with
the initial prototype.
The object-oriented life-cycle model:

• The usual division of a software project into phases remains intact with the use
of object-oriented techniques.
• The requirements analysis stage strives to achieve an understanding of the
client’s application domain.
• The tasks that a software solution must address emerge in the course of requirements
analysis.
• The requirements analysis phase remains completely independent of an
implementation technique that might be applied later.
• In the system specification phase the requirements definition describes what the
software product must do, but not how this goal is to be achieved.
• One point of divergence from conventional phase models arises because
implementation with object-oriented programming is marked by the assembly of
already existing components.

The advantages of object-oriented life-cycle model:

• Design no longer is carried out independently of the later implementation because
during the design phase we must consider which components are available for the
solution of the problem. Design and implementation become more closely
associated, and even the choice of a different programming language can lead to
completely different program structures.
• The duration of the implementation phase is reduced. In particular, (sub) products
become available much earlier to allow testing of the correctness of the design.
Incorrect decisions can be recognized and corrected earlier. This makes for closer
feedback coupling of the design and implementation phases.
• The class library containing the reusable components must be continuously
maintained. Saving at the implementation end is partially lost as they are
reinvested in this maintenance. A new job title emerges, the class librarian, who
is responsible for ensuring the efficient usability of the class library.
• During the test phase, the function of not only the new product but also of the
reused components is tested. Any deficiencies in the latter must be documented
exactly. The resulting modifications must be handled centrally in the class library
to ensure that they impact on other projects, both current and future.
• Newly created classes must be tested for their general usability. If there is a
chance that a component could be used in other projects as well, it must be
included in the class library and documented accordingly. This also means that
the new class must be announced and made accessible to other programmers
who might profit from it. This places new requirements on the in-house
communication structures.

The actual software life cycle recurs when new requirements arise in the
company that initiates a new requirements analysis stage.
The object and prototyping-oriented life-cycle model
The specification phase steadily creates new prototypes. Each time
we are confronted with the problem of having to modify or enhance
existing prototypes. If the prototypes were already implemented with
object-oriented technology, then modifications and extensions are
particularly easy to carry out. This allows an abbreviation of the
specification phase, which is particularly important when proposed
solutions are repeatedly discussed with the client. With such an
approach it is not important whether the prototype serves solely for
specification purposes or whether it is to be incrementally developed to
the final product. If no prototyping tools are available, object-oriented
programming can serve as a substitute tool for modeling user
interfaces. This particularly applies if an extensive class library is
available for user interface elements.

For incremental prototyping (i.e. if the product prototype is to be used as the

basis for the implementation of the product), object-oriented programming
also proves to be a suitable medium. Desired functionality can be added
stepwise to the prototypes without having to change the prototype itself.
These results in a clear distinction between the user interfaces modeled in the
 specification phase and the actual functionality of the program. This is
particularly important for the following reasons:
• This assures that the user interface is not changed during the implementation
of the program functionality. The user interface developed in collaboration with
the client remains as it was defined in the specification phase.
• In the implementation of the functionality, each time a subtask is completed, a
more functional prototype results, which can be tested (preferably together with
the client) and compared with the specifications? During test runs situations
sometimes arise that require rethinking the user interface. In such cases the
software life cycle retreats one step and a new user interface prototype is
constructed.
Since the user interface and the functional parts of the program are largely

decoupled, two cycles result that shares a common core. The integration of
the functional classes and the user interface classes creates a prototype that
can be tested and validated. This places new requirements on the user
interface and/or the functionality, so that the cycle begins.
Types of project planning:
Types of project planning:
 Quality Describes the quality procedures and standards
plan that will be used in a project.

Validatio Describes the approach, resources and schedule

n plan used for system validation.

Configu Describes the configuration management

ration procedures and structures to be used.
manage
ment
plan

Mai Predicts the maintenance requirements of the

nten system, maintenance costs and effort required.
ance
plan

Staff Describes how the skills and experience of the

develop project team members will be developed. See
ment
plan

PLANNING AN ORGANIZATION STRUCTURE:

Completing a software project is a team effort. The following options
are available for applying human resources to a project that will require
‘n’ people working for ‘K’ years.
• ‘n’ individuals are assigned to ‘m’ different functional tasks.
• ‘n’ individuals are assigned to ‘m’ different functional tasks (m<n) so that
informal teams are established and coordinated by project manager.
• ‘n’ individuals are organized into ‘t’ teams and each team is assigned
one/more functional tasks.
Even though the above three approaches have their pros and cons,
option 3 is most productive.
There are several roles within each software project team. Some of
the roles in a typical software project are listed below:

Desi Job Profile

gnati
on
Proje Initiates, plans, tracks and manages resources of an
ct entire project
Mana
ger

Modu A software engineer who manages and leads the team

le working
Lead on a particular module of the software project. The
er module leader will conduct reviews and has to ensure
the proper
Gate Degree & PG College

functionality of the module

Anal A software engineer who analyzes the requirements

yst gathered. Analysis of the requirements is done to get a
clear understanding of the requirements.

Dom An expert who knows the system of which the

ain software is a part. This would involve the technical
Cons knowledge of how the entities of the domain interface
ultan with the software being developed. For example, a
t banking domain consultant or a telecom domain
consultant.

Revie A software engineer who reviews artifacts like project

wer documents or code. The review can be a technical
review which scrutinizes the technical details of the
artifact. It could be a review where the reviewer
ascertains whether or not the artifact adheres to a
prescribed standard

Archi A software engineer involved in the design of the

tect solution after the analyst has clearly specified the
business requirements

Devel A software engineer, who writes the code, tests it and

oper delivers it error free

Teste A software engineer who conducts tests on the

r completed software or a unit of the software. If any
defects are found these defects are logged and a
report is sent to the owner of the tested unit.

Programming Team Structure

Every programming team must have an internal structure. The
best team structure for any particular project depends on the nature
of the project and the product, and on the characteristics of the
individual team members. Basic team structure includes:
a. Democratic team: Team Member participate in all decisions
b. Chief Programmer Team: A chief programmer is assisted and
supported by other team members.
c. Hierarchical Team: The project leader assigns tasks attend reviews and
walkthrough, detects problem areas, balances the workload and
participates in technical activities.
Democratic Team
This was first described by Weinberg as the “egoless team”. In
an egoless team goals are set and decisions made by group consensus.
Group leadership rotates from member to member based on the tasks

28
Gate Degree & PG College

to be performed and the differing abilities of the team members. Work

products (requirements, design, source code, user manual, etc) are
discussed openly and are freely examined by all team members.
Advantage:
❖ Opportunity for each team member to contribute to decision
❖ Opportunity for team members to learn from one another
❖ Increased Job satisfaction that results from good communication in
open, non-threatening work environments.
Disadvantages
❖ Communication overhead required in reaching decision,
❖ All team members must work well together,
❖ Less individual responsibility and authority can result in less initiative
and less personal drive from team members.
The chief programmer team
Baker's organizational model ([Baker 1972])

➢ Important characteristics:
• The lack of a project manager who is not personally involved in
system development
• The use of very good specialists
• The restriction of team size
➢ The chief programmer team consists of:
• The chief programmer
• The project assistant
• The project secretary
• Specialists (language specialists, programmers, test specialists).
➢ The chief programmer is actively involved in the planning,
specification and design process and, ideally, in the implementation
process as well.
➢ The chief programmer controls project progress, decides all
important questions, and assumes overall responsibility.
➢ The qualifications of the chief programmer need to be accordingly high.
➢ The project assistant is the closest technical coworker of the chief
programmer.
➢ The project assistant supports the chief programmer in all important
activities and serves as the chief programmer's representative in the latter's
absence. This team member's qualifications need to be as high as those
of the chief programmer.
➢ The project secretary relieves the chief programmer and all other

29
Gate Degree & PG College

programmers of administrative tasks.

➢ The project secretary administrates all programs and documents and
assists in project progress checks.
➢ The main task of the project secretary is the administration of the project
library.
➢ The chief programmer determines the number of specialists needed.
➢ Specialists select the implementation language, implement individual
system components, choose and employ software tools, and carry out
tests.
Advantages
• The chief programmer is directly involved in system development and can
better exercise the control function.
• Communication difficulties of pure hierarchical
organization are ameliorated. Reporting concerning project
progress is institutionalized.
• Small teams are generally more productive than large teams.
Disadvantages
• It is limited to small teams. Not every project can be handled by a small
team.
• Personnel requirements can hardly be met. Few software engineers can
meet the qualifications of a chief programmer or a project assistant.
• The project secretary has an extremely difficult and responsible job,
although it consists primarily of routine tasks, which gives it a
subordinate position. This has significant psychological disadvantages.
Due to the central position, the project secretary can easily become a
bottleneck.
The organizational model provides no replacement for the project
secretary. The loss of the project secretary would have failing
consequences for the remaining course of the project.
Hierarchical organizational model
➢ There are many ways to organize the staff of a project. For a long time the
organization of software projects oriented itself to the hierarchical
organization common to other industrial branches. Special importance
is

30
Gate Degree & PG College

31