eBook - ePub
Beginning Software Engineering
Rod Stephens
This is a test
Partager le livre
- English
- ePUB (adapté aux mobiles)
- Disponible sur iOS et Android
eBook - ePub
Beginning Software Engineering
Rod Stephens
DĂ©tails du livre
Aperçu du livre
Table des matiĂšres
Citations
Ă propos de ce livre
A complete introduction to building robust and reliable software Beginning Software Engineering demystifies the software engineering methodologies and techniques that professional developers use to design and build robust, efficient, and consistently reliable software. Free of jargon and assuming no previous programming, development, or management experience, this accessible guide explains important concepts and techniques that can be applied to any programming language. Each chapter ends with exercises that let you test your understanding and help you elaborate on the chapter's main concepts. Everything you need to understand waterfall, Sashimi, agile, RAD, Scrum, Kanban, Extreme Programming, and many other development models is inside!
- Describes in plain English what software engineering is
- Explains the roles and responsibilities of team members working on a software engineering project
- Outlines key phases that any software engineering effort must handle to produce applications that are powerful and dependable
- Details the most popular software development methodologies and explains the different ways they handle critical development tasks
- Incorporates exercises that expand upon each chapter's main ideas
- Includes an extensive glossary of software engineering terms
Foire aux questions
Comment puis-je résilier mon abonnement ?
Il vous suffit de vous rendre dans la section compte dans paramĂštres et de cliquer sur « RĂ©silier lâabonnement ». Câest aussi simple que cela ! Une fois que vous aurez rĂ©siliĂ© votre abonnement, il restera actif pour le reste de la pĂ©riode pour laquelle vous avez payĂ©. DĂ©couvrez-en plus ici.
Puis-je / comment puis-je télécharger des livres ?
Pour le moment, tous nos livres en format ePub adaptĂ©s aux mobiles peuvent ĂȘtre tĂ©lĂ©chargĂ©s via lâapplication. La plupart de nos PDF sont Ă©galement disponibles en tĂ©lĂ©chargement et les autres seront tĂ©lĂ©chargeables trĂšs prochainement. DĂ©couvrez-en plus ici.
Quelle est la différence entre les formules tarifaires ?
Les deux abonnements vous donnent un accĂšs complet Ă la bibliothĂšque et Ă toutes les fonctionnalitĂ©s de Perlego. Les seules diffĂ©rences sont les tarifs ainsi que la pĂ©riode dâabonnement : avec lâabonnement annuel, vous Ă©conomiserez environ 30 % par rapport Ă 12 mois dâabonnement mensuel.
Quâest-ce que Perlego ?
Nous sommes un service dâabonnement Ă des ouvrages universitaires en ligne, oĂč vous pouvez accĂ©der Ă toute une bibliothĂšque pour un prix infĂ©rieur Ă celui dâun seul livre par mois. Avec plus dâun million de livres sur plus de 1 000 sujets, nous avons ce quâil vous faut ! DĂ©couvrez-en plus ici.
Prenez-vous en charge la synthÚse vocale ?
Recherchez le symbole Ăcouter sur votre prochain livre pour voir si vous pouvez lâĂ©couter. Lâoutil Ăcouter lit le texte Ă haute voix pour vous, en surlignant le passage qui est en cours de lecture. Vous pouvez le mettre sur pause, lâaccĂ©lĂ©rer ou le ralentir. DĂ©couvrez-en plus ici.
Est-ce que Beginning Software Engineering est un PDF/ePUB en ligne ?
Oui, vous pouvez accĂ©der Ă Beginning Software Engineering par Rod Stephens en format PDF et/ou ePUB ainsi quâĂ dâautres livres populaires dans Informatik et Softwareentwicklung. Nous disposons de plus dâun million dâouvrages Ă dĂ©couvrir dans notre catalogue.
Informations
PART I
Software Engineering Step-by-Step
- CHAPTER 1: Software Engineering from 20,000 Feet
- CHAPTER 2: Before the Beginning
- CHAPTER 3: Project Management
- CHAPTER 4: Requirement Gathering
- CHAPTER 5: High-Level Design
- CHAPTER 6: Low-Level Design
- CHAPTER 7: Development
- CHAPTER 8: Testing
- CHAPTER 9: Deployment
- CHAPTER 10: Metrics
- CHAPTER 11: Maintenance
Software and cathedrals are much the same. First we build them, then we pray.âSAMUEL REDWINE
In principle, software engineering is a simple two-step process: (1) Write a best-selling program, and then (2) buy expensive toys with the profits. Unfortunately, the first step can be rather difficult. Saying âwrite a best-selling programâ is a bit like telling an author, âWrite a best-selling book,â or telling a baseball player âtriple to left.â Itâs a great idea, but knowing the goal doesnât actually help you achieve it.
To produce great software, you need to handle a huge number of complicated tasks, any one of which can fail and sink the entire project. Over the years people have developed a multitude of methodologies and techniques to help keep software projects on track. Some of these, such as the waterfall and V-model approaches, use detailed requirement specifications to exactly define the wanted results before development begins. Others, such as Scrum and agile techniques, rely on fast-paced incremental development with frequent feedback to keep a project on track. (Still others techniques, such as cowboy coding and extreme programming, sound more like action adventure films than software development techniques.)
Different development methodologies use different approaches, but they all perform roughly the same tasks. They all determine what the software should do and how it should do it. They generate the software, remove bugs from the code (some of the bugs, at least), make sure the software does more or less what it should, and deploy the finished result.
NOTE I call these basic items âtasksâ and not âstagesâ or âstepsâ because different software engineering approaches tackle them in different ways and at different times. Calling them âstagesâ or âstepsâ would probably be misleading because it would imply that all projects move through the stages in the same predictable order.
The chapters in the first part of this book describe those basic tasks that any successful software project must handle in some way. They explain the main steps in software development and describe some of the myriad ways a project can fail to handle those tasks. (The second part of the book explains how different approaches such as waterfall and agile handle those tasks.)
The first chapter in this part of the book provides an overview of software development from a high level. The subsequent chapters explain the pieces of the development process in greater detail.
CHAPTER 1
Software Engineering from 20,000 Feet
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. The other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.âC.A.R. HOARE
WHAT YOU WILL LEARN IN THIS CHAPTER:
- The basic steps required for successful software engineering
- Ways in which software engineering differs from other kinds of engineering
- How fixing one bug can lead to others
- Why it is important to detect mistakes as early as possible
In many ways, software engineering is a lot like other kinds of engineering. Whether youâre building a bridge, an airplane, a nuclear power plant, or a new and improved version of Sudoku, you need to accomplish certain tasks. For example, you need to make a plan, follow that plan, heroically overcome unexpected obstacles, and hire a great band to play at the ribbon-cutting ceremony.
The following sections describe the steps you need to take to keep a software engineering project on track. These are more or less the same for any large project although there are some important differences. Later chapters in this book provide a lot more detail about these tasks.
REQUIREMENTS GATHERING
No big project can succeed without a plan. Sometimes a project doesnât follow the plan closely, but every big project must have a plan. The plan tells project members what they should be doing, when and how long they should be doing it, and most important what the projectâs goals are. They give the project direction.
One of the first steps in a software project is figuring out the requirements. You need to find out what the customers want and what the customers need. Depending on how well defined the userâs needs are, this can be time-consuming.
WHOâS THE CUSTOMER?
Sometimes, itâs easy to tell who the customer is. If youâre writing software for another part of your own company, it may be obvious who the customers are. In that case, you can sit down with them and talk about what the software should do.
In other cases, you may have only a vague notion of who will use the finished software. For example, if youâre creating a new online card game, it may be hard to identify the customers until after you start marketing the game.
Sometimes, you may even be the customer. I write software for myself all the time. This has a lot of advantages. For example, I know exactly what I want and I know more or less how hard it will be to provide different features. (Unfortunately, I also sometimes have a hard time saying ânoâ to myself, so projects can drag on for a lot longer than they should.)
In any project, you should try to identify your customers and interact with them as much as possible so that you can design the most useful application possible.
After you determine the customersâ wants and needs (which are not always the same), you can turn them into requirements documents. Those documents tell the customers what they will be getting, and they tell the project members what they will be building.
Throughout the project, both customers and team members can refer to the requirements to see if the project is heading in the right direction. If someone suggests that the project should include a video tutorial, you can see if that was included in the requirements. If this is a new feature, you might allow that change if it would be useful and wouldnât mess up th...